Office Servers and Services

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

Exchange et le Stockage – Partie 12

Posted by Anthony Costeseque sur mai 25, 2012


Bonjour à tous,

Apres une longue absence:/ en ce moment (c’est en permanence en fait) mais particulièrement ces 4 derniers mois, le planning était très chaud.

Mais reprenons là où nous avions arrêté, comment déployer au mieux (best practices) votre solution exchange 2010 en fonction des différents constructeurs.

Nous avons vu dans la Partie 11 comment faire EMC² (ce post sera complété dans un proche avenir suite aux différentes annonces faites à l’EMC² Word 2012 qui c’est déroulé cette semaine à Las Vegas).

Nous allons voir aujourd’hui Hitachi (HDS) !

  1. Commençons par le commencement le type de la baie !

Il est évident que le model sera conditionné par la taille de votre future infrastructure : Le nombre d’utilisateurs et la taille des boîtes aux lettres étant les principaux facteurs.

Chez Hitachi (HDS) nous parlerons maintenant de Hitachi Unified Storage 100 Family (HUS (nouvelle baie unifiées)).

Le standard sera une HUS130 et pour les déploiements plus importants on passera sur un HUS150 (le plus important étant le nombre maximum de disque supporté)

HUS110 : 120 disks

HUS130 : 252 disks

HUS150 : 960 disks

En règle générale sur un déploiement d’au moins 10000 utilisateurs on a souvent 2 salles (voir 2 sites) pour la Haute Disponibilité et donc 2 HUS130 font parfaitement l’affaire.


Un exemple d’implémentation (ici sur des HUS 150 mais sur des HUS 130 c’est très bien aussi)

Prenons un exemple de design de solution pour 8000 utilisateurs

  1. Ensuite vient le type de disque

Les HUS supportent SAS/NL-SAS

Nous l’avons vu dans les précédents billets, Exchange est optimisé du côté des IO permettant l’utilisation de disque 7200tr/m donc la règle est la suivante :

Faible IOs requis et large capacité de boîtes aux lettres (2Go) -> On utilisera du NL-SAS (ou encore du SATA) 7200 tr/m

Important IOs requis et faible capacité de boites aux lettres (<1Go) -> On utilisera du SAS 10000 tr/m voir 15000 tr/m (si besoin)

Jusqu’à maintenant j’ai toujours vu du NL-SAS 7200 tr/m de 2To.

  1. Puis le type de RAID (bien lire le concept d’Hitachi)

Attention cette étape est très importante.

Concept : Sur les HUS nous utiliserons « Hitachi Dynamic Provisioning » qui s’appuie sur l’utilisation de Pools (Dynamic Provisioning Pool (DP Pool)) constitués de plusieurs RAID Group.

On provisionnera dans ces DP Pools des Dynamic Provisioning Virtual Volumes (DP-VOLs)

Pour les RAID Group nous utiliserons du RAID 1/0 (2+2) (striping + mirroring)


Avec Schéma ça aide :)

Découpage :


Ici nous avons bien une séparation de domaine de Risques pour les DBs et Logs.

Nous créerons donc 2 Dynamic Provisioning Pools (DP Pools) :

  • DB Pool avec 7 RAID Group 1/0 (2+2)
  • Logs Pool avec 2 RAID Group 1/0 (2+2)

A partir du DB Pool nous créerons 8 Dynamic Provisioning Virtual Volumes (DP-VOLs) de 1200GB chacun pour contenir les 8 DB requises (1000 utilisateurs par DBs)

A partir du Logs Pool nous créerons 8 Dynamic Provisioning Virtual Volumes (DP-VOLs) de 120GB chacun pour contenir les 8 espaces de Logs requis (pour les 8 DBs)

  1. Le type de connexion

Stockage « intelligent » donc pas de DAS que du SAN en FC ou iSCSI.

Je vous recommande du FC pour les 8Gb/s de bande passante (2 ports FC de 4Gb/s en roud robin)
ainsi que la faible latence !

L’iSCSI est bien aussi mais demande tout de même des switch dédiés pour le trafic stockage (optimisés iSCSI si possible) mais le problème vient surtout de la bande passante disponible ! De façon classique nous avons 2Gb/s (2 ports Ethernet de 1Gb/s en roud robin) qui peuvent vite représenter un goulot d’étranglement sur des infrastructures importantes ! (rappelez-vous le background database maintenance (BDM) et son besoin en bande passante !). Les ports iSCSI 10Gb/s existent pour les VNX et peuvent représenter une alternative intéressante mais vos switch Ethernet devront les supporter !

Si vous pensez mettre en place une infrastructure FCoE (10Gb) alors pas de problèmes du moment que toute la chaine est prévue pour ! (switch Nexus etc).

  1. Enfin les recommandations générales

Si votre baie est multi usage (pas uniquement Exchange) :

  • Au moment du formatage de votre LU, mettre l’ALU à 64KB pour les DB et 4KB pour les Logs
  • Pas de problèmes d’alignement des disques avec Windows 2008 R2 (aligné à 1MB)
  • Eviter de mixer les Workload d’Exchange avec d’autres applications (dans les 2 DP Pools que nous avons créé dans notre exemple)
  • Utiliser Hitachi Dynamic Link Manager pour la partie MultiPathing (éviter le soft de multipathing natif à l’OS)
  • Utiliser Hitachi Dynamic Provisioning (HDP) comme nous l’avons vu dans notre exemple
  • Due à la différence des paterns d’IO pour les DB et Logs, séparer les DBs des Logs en utilisant plusieurs DP Pools (comme vu dans notre exemple)
  • Vous pouvez utiliser du RAID-5 ou du RAID-10 pour les DBs et Logs, mais l’utilisation du RAID-10 apporte une pénalité en écriture moindre et des temps de réponses meilleurs ! (et en plus une reconstruction de disque suite à remplacement de disque HS plus rapide !)
  • Les Logs LU doivent être d’au moins 10% la taille du LU des DBs (mais peut être supérieur en fonction du nombre de jours de retentions que vous souhaitez (attention si vous utilisez des Lagged Databases))
  • L’utilisation de LU concaténées n’est pas recommandé
  • L’utilisation des DAGs avec au moins 2 DBs (1 active et 1 passive) est recommandée (pas besoin de mécanisme au niveau du stockage pour la résilience)
  • Isoler la copie active de la copie passive soit entre plusieurs HDP soit entre 2 ou + baies (le cas dans notre exemple (2 baies))
  • Utiliser des LUs plus grande pour réduire le nombre de DBs (Maximum recommandé 2TB pour les DBs)

Pour toutes questions n’hésitez pas !

Bonne lecture :)

La prochaine fois nous parlerons de NetApp.

Anthony COSTESEQUE

3 Réponses to “Exchange et le Stockage – Partie 12”

  1. benoit said

    Concenrnant l’utlisation d’Hitachi Dynamic Link Manager pour la partie MultiPathing : y a t’il une raison en particulier pour cette recommandation sachant que le MPIO de windows 2008 R2 fonctionne plutot bien (?)

    • Anthony Costeseque said

      Bonjour Benoit,
      Le discourt est le même chez tous les constructeurs :
      – Le soft de MiltiPath du constructeur est en phase optimale avec l’intelligence frontale de la baie, il sait comment envoyer les block de façon optimale pour le maximum de performances.
      – De plus un nombre plus important de policies de gestion du MultiPath est disponible
      – Mais le plus intéressant concerne la policy « Round Robin » : Il s’agit plus que d’une alternance basique comme le fait le soft interne à l’OS de multipath
      – Ensuite la gestion des path dead ou des coupures de lien est beaucoup détectée et gérée par le soft du constructeur qui pourra parler à la baie et déclencher des opérations que ne pourraient faire le soft interne de l’OS
      Mais si le soft du constructeur n’est pas obligatoire il est fortement recommandé et permet de gagner significativement en performance pour en justifier le coût🙂
      Cordialement,
      Anthony COSTESEQUE

  2. […] Partie 12 – Bonnes pratiques avec Hitachi […]

Laisser un commentaire

Choisissez une méthode de connexion pour poster votre commentaire:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

 
%d blogueurs aiment cette page :