Exchange et le Stockage – Partie 12

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

Exchange et le Stockage – Partie 11

Bonjour,

Dans la prochaine série de billet sur le stockage dans Exchange, nous verrons les bonnes pratiques chez chaque constructeur de stockage « intelligent ».

Et nous allons commencer aujourd’hui avec EMC².

Chacun d’entre vous pourra trouver les repères dont il a besoin en fonction du constructeur avec qui il travaillera :)

Par conséquent nous n’expliquerons pas ce qui se passe derrière chaque concept (nom technique) des technologies propres à chaque constructeur.

Pour toute questions ou point qui ne vous ne semblerez pas clair n’hésitez pas à laisser des commentaires.

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 EMC² nous parlerons maintenant de VNX (nouvelle baie unifiées (Block & File)).

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

VNX5300 : 125 disks

VNX5500 : 250 disks

VNX5700 : 500 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 VNX5300 font parfaitement l’affaire.

1. Ensuite vient le type de disque
   

Les VNX supportent FC/SAS/NL-SAS/SATA/Flash(SSD)

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 FC ou 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 pour les déploiements que j’ai fait.

Je ne parle pas ici de Flash(SSD) nous en parlerons plus tard :)

1. Puis le type de RAID
   

Attention cette étape est très importante.

Sur les VNX nous pouvons choisir entre RAID 1/0 (striping + mirroring), RAID 5 (striping + parity), and RAID 6 (striping + double parity), une fois de plus dans les précédents billets nous en avons déjà parlé (performance/pénalité RAID/Ratio Data utile/Data parité/etc)

Nous choisirons dans 95% des cas du RAID 10 pour éviter une pénalité RAID forte en écriture et fournir les IOs nécessaires pour soutenir les bases de données ainsi que les logs !

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) :

• Taille des pages du cache 8KB
  
• Utiliser un set de disques uniquement pour exchange (pas de mix avec des luns pour d’autres applications)
  
• Commencer par vérifier les IOs nécessaires avant la capacité nécessaire
  
• Si vous n’utilisez pas de système de réplication, ne placer pas une database et ses logs sur le même set de disques !
  
  • Le but ici sera de placer des databases avec les logs d’autre databases (de façon croisée)
    
• Si vous utiliser un DAG ou autre système de réplication (non recommandé) vous pouvez mettre database et ses logs sur le même set de disques
  
• Attention rappel ! sans DAG vous ne pouvez pas utiliser de bases > à 200Go
  
• Les copies des databases dans le DAG ne doivent pas être sur le même set de disques (pour une même base)
  
• Bien repartir la charge sur les Storage Processor des baies
  
• Windows NTFS file système formaté en taille d’unité d’allocation de 64KB
  
• Si RAID 5 est utilisé, ne pas utiliser de metaLUNs sur plusieurs RAID Group !!
  

Si votre baie est à usage unique pour Exchange :

• Taille des pages du cache 16KB
  
• Le reste pareil
  

1. Un exemple de découpage
   

10000 utilisateurs à 1,5Go de boîte aux lettres (principe de séparation des bases de données et des logs)

1. Considérations particulière VNX
   

Parlons un peu du Flash (SSD), EMC² utilise le Flash avec 2 concepts : FAST Cache & FAST VP

Est-ce que FAST Cache améliore les performances pour Exchange 2010 ?

Et bien non ! FAST Cache n’a pas d’impacts sur Exchange (ni bonne ni mauvaise)

Si vous voulez tout de même l’utiliser, activer le uniquement sur les LUNs des bases de données (pas sur les logs).

De plus ça n’aidera pas sur le passage des tests Jetstress ! :p

Et maintenant est ce que FAST VP a un intérêt pour Exchange ?

Et bien non aussi ! Et même qu’ici il a un mauvais effet sur la technologie ! tout cela à cause de background database maintenance (BDM) (encore lui ;) ) qui fausse les statiques pour le déplacement des chunk de 1Go dans le pool.

Donc à éviter !!

Est-ce que les Thin LUNs peuvent être utilisées ?

Ce n’est pas recommandé pour le moment (les thin LUN ne sont pas recommandés lorsque l’on recherche des performances !)

Si vous voulez des informations sur le design dans des baies VMAX ou encore VPLEX, envoyez moi un mail.

Documents de références disponibles sur PowerLink :

h8127-deployment-exchange-unified-wp.pdf

h8888-Exchange2010-EMC-storage-best-practices-wp.pdf

h8849-VNX5300-20Kusers-Exchange2010.pdf

Bonne lecture

Anthony COSTESEQUE

Exchange et le Stockage – Partie 10

Bonjour,

Déjà 10 parties ! Ça passe vite !! Si ce sujet (le stockage et Exchange) vous intéresse n’hésitez pas à laisser des commentaires (vous pouvez me proposer des thèmes que vous souhaiteriez approfondir).

Exchange et le Stockage – Partie 1

Exchange et le Stockage – Partie 2

Exchange et le Stockage – Partie 3

Exchange et le Stockage – Partie 4

Exchange et le Stockage – Partie 5

Exchange et le Stockage – Partie 6

Exchange et le Stockage – Partie 7

Exchange et le Stockage – Partie 8

Exchange et le Stockage – Partie 9

Nous allons parler aujourd’hui de « background database maintenance (BDM) ou encore Checksumming (contrôle de parité) ».

Mais quelle est donc cette fonctionnalité ? Pour les personnes qui font du design coté stockage pour les bases de données, ce terme n’est pas inconnu il est présent dans la feuille de calcul au niveau des résultats de l’onglet « Role Requirements » tout en bas …

Si on fait un tour sur Technet on trouve sur cette page http://technet.microsoft.com/fr-fr/library/ee832791.aspx on trouve la définition de la fonctionnalité :

Les E/S de maintenance de la base de données en arrière-plan sont des E/S de fichier de bases de données séquentielles associées au contrôle de parité des copies de base de données actives et passives. La maintenance de base de données en arrière-plan présente les caractéristiques suivantes :

• Sur les bases de données actives, elle peut être configurée pour s’exécuter 24 × 7 ou pendant la fenêtre de maintenance en ligne. La maintenance de base de données en arrière-plan (contrôle de parité) s’exécute sur les copies de base de données passives 24 × 7. Pour en savoir plus, voir « Analyse de bases de données en ligne » dans la rubrique Nouvelles fonctionnalités de banque d’informations principales dans Exchange.
  
• Lit environ 5 Mo par seconde pour chaque base de données à analyse active (copies actives et passives). Les E/S sont séquentielles à 100 %, ce qui permet au sous-système de stockage de traiter les E/S de manière efficace.
  
• Arrête d’analyser la base de données si le contrôle de parité s’effectue en moins de 24 heures.
  
• Émet un événement d’avertissement si l’analyse ne se termine pas dans un délai de 3 jours (non configurable).
  

L’analyse de base de données en ligne (également appelée Contrôle de parité de la base de données) a également été modifiée. Dans Exchange 2007 Service Pack 1 (SP1), vous pouviez utiliser la moitié du délai de défragmentation en ligne pour ce processus d’analyse de base de données (pour s’assurer qu’Exchange lisait chaque page de votre base de données dans un délai donné afin de détecter toute corruption). Cette E/S est séquentielle à 100 % (et donc facile sur le disque) et revient sur la plupart des systèmes à un taux de parité d’environ 5 mégaoctets (Mo)/s.

Dans Exchange 2010, l’analyse de base de données en ligne contrôle simplement la parité de la base de données et exécute des opérations de blocage de banque Exchange 2010. L’espace peut être perdu en raison des blocages, l’analyse de base de données en ligne recherche et récupère l’espace perdu. Le système présent dans Exchange 2010 est conçu en considérant que chaque base de données est intégralement analysée une fois tous les trois jours. Un événement d’avertissement est déclenché si les bases de données ne sont pas analysées. Dans Exchange 2010, il existe désormais deux nœuds pour exécuter l’analyse de base de données en ligne sur les copies de base de données actives :

• Exécuter en tant que dernière tâche dans le processus de maintenance de la base de données de boîtes aux lettres. Vous pouvez configurer la durée d’exécution en modifiant la planification de la maintenance de la base de données de boîtes aux lettres. Cette option fonctionne mieux pour les plus petites bases de données dont la taille ne dépasse pas 1 téraoctet (To).
  
• Exécuter en arrière-plan 24h/24 et 7j/7, comportement par défaut. Cette option fonctionne bien pour les bases de données volumineuses, jusqu’à 2 To, où vous avez besoin de plus de temps pour contrôler la parité des bases de données. Exchange analyse la base de données une seule fois par jour et déclenche un événement d’avertissement si l’analyse ne se termine pas dans un délai de sept jours.
  

Vous pouvez configurer l’analyse de la base de données en ligne afin qu’elle ne s’exécute pas 24h/24 et 7j/7 en désactivant la case à cocher (si vous ne voulez pas de surcharge d’E/S pendant une période de pointe). Dans ce cas, la dernière partie de la fenêtre d’analyse de la base de données en ligne sert à contrôler la parité de la base de données et à récupérer l’espace perdu.

Pour plus d’informations sur la configuration de la maintenance de base de données, consultez la rubrique Gérer des bases de données de boîtes aux lettres.

 

Que faut-il retenir ? Et bien :

1. Le process peut être ajusté (la plage d’exécution) sur les bases de données actives.
   
2. Le process ne peut pas être ajusté sur les bases de données passives !!
   
3. Ce sont uniquement des IOs séquentielles en lecture d’une taille supérieure à ceux des bases de données ! ils font 256KB contre 32KB pour les databases.
   
4. Chaque base (active ou passive) doit être intégralement vérifiée tous les 3 jours
   
5. Il faut compter 5MB/s par bases de données dans les calculs de bande passante entre les serveurs et le stockage
   
6. On en déduit que plus les bases sont grandes plus on réduit le nombre de bases et donc moins on est touché par le background database maintenance !
   
7. Si on est pas en mode HA pour utiliser des bases de 2To on est obligé d’utiliser des bases de 200Go max, on voit vite que le nombre de bases va augmenter et donc on sera beaucoup plus touché par le background database maintenance !!
   

 

Passons à un exemple, dans mon billet Partie 9 nous avons vu un design pour 22000 utilisateurs.

En version JBOD RAID-Less nous avions calculé 40 bases de données actives et 120 bases de données passives pour un total de 160 bases de données (sur 4 serveurs)

Le calcul est simple … 160*5=800MB/s ce n’est pas négligeable … !! Vous voyez maintenant l’importance de cette fonctionnalité en termes de charge !

Pour être sur que tout le monde voit bien, on parle ici de MB, Mega Byte, pas de Mega bite ! En Mb cela nous donne environ 8000Mb/s (soit environ 8Gb/s).

Maintenant je pense que tout le monde se pose des questions ;) comment est-ce possible ?

Tout d’abord il faut ramener le ration à « par serveur » donc /4, ce qui nous donne 200MB/s soit environ 2Gb/s

Dans notre scenario JBOD RAID-Less nous aurions pu utiliser des baies de stockage HP MDS600 en attachement SAS 6Gb/s.

Un serveur est double attaché (à un switch SAS) à 1 MDS600 donc il a potentiellement 2x6Gb/s soit 12Gb/s de bande passante possible.

Donc tout va bien :) nous avons 4 serveurs avec chacun 1 MDS600 donc la charge est supportée ! (nous sommes en attachement directe SAS (l’idée du JBOD RAID-Less))

Maintenant passons à la version RAID ! Nous avions calculé 28 bases de données actives et 28 bases de données passives pour un total de 56 bases de données (sur 4 serveurs)

Le calcul reste le même 56*5=280MB/s soit environ 2800Mb/s (environ 2,8Gb/s)

Ramenons le à « par serveur » donc /4, nous avons par serveur 70MB/s donc environ 700Mb/s à soutenir.

Nos serveurs sont double attachés en fibre à des switch FC, en règle général les équipements fibres sont en 4Gb/s (le 8Gb/ est chère et moins rependu) nous avons donc 2x4Gb/s soit 8Gb/s de disponible.

Jusqu’ici tout va bien on soutien largement la charge ! Mais attention, en règle générale dans ce type de configuration, nous ne ciblons qu’une seul baie de stockage ! Souvent reliée à 2 fabric SAN par 4 fibres 4Gb/s (2 Chemins par fabric).

Donc nos 4 serveurs vont charger les 4 ports de la baie. Si vous avez bien designez votre infra (bien reparti les LUN sur les 2 contrôleurs, etc) les 2,8Gb/s ne vous poserons pas de problèmes !

 

Vous ferez donc plus attention à l’avenir lors de vos design sur la partie bande passante à soutenir :p

Pour toutes questions n’hésitez pas !

Bon calculs :)

Anthony COSTESEQUE

Exchange et le Stockage – Partie 8

Les précédents billets sur le stockage dans Exchange :

Exchange et le Stockage – Partie 1

Exchange et le Stockage – Partie 2

Exchange et le Stockage – Partie 3

Exchange et le Stockage – Partie 4

Exchange et le Stockage – Partie 5

Exchange et le Stockage – Partie 6

Exchange et le Stockage – Partie 7

 

Comment Microsoft fait pour supporter plus d’un billion d’emails par jour ?

C’est que nous allons voir aujourd’hui.

 

Le 22 septembre Chris Jones SVP Windows Live écrit un billet sur “A petabyte per week”

http://windowsteamblog.com/windows_live/b/windowslive/archive/2011/09/22/a-petabyte-per-week.aspx

Décrivant les changements qui vont se mettre en place chez Microsoft autour du stockage de la messagerie Hotmail.

 

Historiquement Hotmail repose sur du RAID, à l’heure ou Microsoft prône le JBOD/RAID-Less avec Exchange 2010 il était temps qu’ils montrent l’exemple

 

On quitte le RAID

 

Jusqu’à maintenant un mail d’un utilisateur se trouve sur plusieurs RAID Group, ce qui permet dans le cas de la perte d’une grappe complète (pire scenario) de ne pas perdre ce mail.

Cela était intéressant jusqu’à l’arrivé des disques de grande capacité (supérieur à 1To).

 

On passe au JBOD (Just a Bunch of Disks)

L’unité n’est plus la LUN (Logical Unit) compose de X Disques mais le disque.

Les problèmes doivent maintenant être traité par le software, là ou avant c’était le contrôleur qui s’en chargé.

Sur tout du côté des erreurs sur les disques qui corrompt les données ! Avec du RAID, grâce à la parité (sur du RAID5 par exemple) la donnée peut être reconstruite. Sans RAID il faut que la partie software soit captable de corriger ce type de problèmes.

Tout comme Exchange 2010 le code pour Hotmail scan en permanence les disques pour vérifier qu’il n’y a pas de corruptions et le cas échéant, les corrige.

Maintenant que l’intelligence est dans le software, à tout moment on sait combien de copie d’un mail sont disponibles, s’il est trop faible des copies sont créées ailleurs, etc.

Il y a aussi la partie metadata du mail (l’état lu/non lu, classement dans un répertoire, etc) qui sont-elles stockées séparément du mail.

 

Le problème du JBOD se situe surtout sur la rapidité et le nombre d’actions (IOPS) dont il est capable.

Dans le contexte d’Hotmail cela représente un vrai goulot d’étranglement !

D’out l’ajout d’une partie SSD (Solid State Drive) ou encore Flash Storage pour limiter cette effet.

Etant donnée le prix de ces disques encore très élevé, ils ne servent qu’à aider et ne peuvent remplacer le JBOD.

 

En fait ce qui représente le plus de charge sur les disques sont la metadata lié aux mails ! L’état d’un mail lu / non lu, son classement dans les répertoires, les conversations (position des mails dans une conversation), synchronisation des téléphones mobiles, etc

Ces données représentent une quantité minime par rapport aux mails eux-mêmes.

 

Le but sera donc de mettre les metadatas sur du SSD et les mails sur du JBOD.

 

La migration a déjà commencé, il y a environ 30 Millions de personnes sur le JBOD et 100 Millions qui vont être migrées dans les prochains mois.

 

Anthony COSTESEQUE.

Exchange et le Stockage – Partie 7

Aujourd’hui nous allons voir un peu l’incidence de cette taille de block (taille de page) à 32KO sur la partie Backup.

Le backup ne peut se faire aujourd’hui qu’en mode VSS (Volume Shadow Copy Service) à l’aide d’un provider (l’un des 3 composants primaires de VSS (provider, requestor et writer)).

Pour plus d’informations sur VSS je vous renvoie vers un ancien billet que j’ai écrit : http://diskshadow.fr/microsoft/volume-shadow-copy-service-vss-details.html

Le but de tout cela est de lors du lancement d’un backup de bases de données Exchange, faire en sorte que le backup soit « Application Consistent » (qui correspond à un état de la base de données « Clean ») à l’inverse d’un backup de type « Crash Consistent » (qui correspond à un état de la base de données « Dirty »).

Comment fait-on pour avoir un backup Clean ?

Et bien l’outil de backup va grâce à son requestor discuter avec VSS qui a son tour va utiliser un writer (celui d’exchange) pour faire en sorte que la(es) base(s) de données soit dans un état consistant (« Clean ») et ainsi, créer un snapshot (un point dans le temps (une shadow copy)).

Le writer va utiliser un provider (celui de l’os natif ou un provider spécial fourni par une application de backup) pour maintenir le snapshot (shadow copy) tout au long du backup.

Une fois le backup terminée, en règle générale, tout est nettoyé (les snapshot sont supprimés).

Important : pour que la base de données soit en état « Clean » lors de l’appel du writer, une interruption de service à lieu (les IOs sont figés) et le snapshot est créée ! À partir de là les IOs reprennent.

Je vous rassure l’interruption ne dure que 10sec maximum avant qu’un time out n’intervienne pour mettre le backup en erreur.

Durant la vie du snapshot (généralement le temps du backup) COFW intervient (Copy On First Write) toutes modifications qui interviennent dans les bases de données sont enregistrées sur les disques mais les blocks originaux partent dans la réserve utilisée par VSS (par défaut le fameux répertoire « C:\System Volume Information » inaccessible au commun des mortels)

Le provider natif de Windows (dans Windows 2008 R2) qui s’appuie sur VOLSNAP.sys, utilise des blocks de 16KO.

Donc lorsqu’un snapshot est en court toutes écritures est interceptée par le provider, permettant au block original de se déplacer dans la snapshot reserve, mais même s’il n’y a que 1byte de modifié, ce sera 16KO qui seront déplacés !

De plus si une écriture à lieu sur plus de 16KO alors c’est tous les blocks modifiés qui sont déplacés.

 

Revenons à Exchange et ses tailles de page.

Exchange 2003 4KO

Exchange 2007 8KO

Exchange 2010 32KO

Prenons Exchange 2003, si une écriture de 4KO était contenue dans 1 block de 16KO alors c’était 16KO qui partaient vers la snapshot reserve ! De plus si ces 4KO touchaient 2 Blocks de 16KO alors c’était 32KO qui partaient dans la réserve !!

Donc 4KO de modif = soit +16KO ou au pire +32KO !! On commence à comprendre l’importance de laisser de la place sur les disques qui supportent les bases de données :) pour peu que le backup tourne longtemps et qu’il y ait de l’activité ça peut vite grossir.

 

Donc pour Exchange 2010, une écriture de 32KO fera forcement 2 Blocks de 16KO au mieux et au pire 48KO !

Une modif de 32KO = soit +32KO ou au pire +48KO !

 

Maintenant attention ! Si votre solution de backup install son propre provider il est très important de vérifier quelle est la taille de block qu’elle utilise. Si par exemple elle utilise des blocks de 1024KO on imagine vite l’impact !

Une modif de 32KO = soit +1024KO ou au pire +2048KO !! (1Mo ou 2Mo)

 

Donc attention.

Pour toutes questions n’hésitez pas.

Anthony COSTESEQUE.

Exchange et le Stockage – Partie 6

Aujourd’hui nous allons aller plus loin sur les I/Os dans Exchange 2010.

Nous avons dit qu’une application avait un profil de charge (workload) défini par :

I/O size (La taille des requêtes I/O)

Access pattern (Sequential ou Random ou encore entre les deux)

Footprint (La quantité totale de données disponible accédée dans le disque)

Command type (Read ou Write ou encore les deux)

 

Nous avons déjà vu la partie Command type (Read ou Write ou encore les deux)

Database : 60% Read / 40% Write

Logs : 50% Read / 50% Write

 

La partie Footprint depend de beaucoup de facteurs, ce n’est pas le but de ce billet.

 

La partie Access pattern (Sequential ou Random ou encore entre les deux) est intéressante :

Avec exchange 2010 les I/O séquentiels ont été augmenté grâce à de nouvelles fonctionnalités comme la défragmentation Online et les scans des databases Online.

Toutes les données sont stockées dans les bases de données qui sont constituées de B-trees, qui sont à leur tour composées de pages (la plus petite unité).

Ces pages sont défragmentées en ligne régulièrement, ce qui permet de réaliser des lectures séquentielles plus longues !

 

Et maintenant le plus intéressant, l’I/O size (La taille des requêtes I/O)

Nous avons définie dans la Partie 1, ce qu’est un I/O

Un I/O correspond à la plus petite quantité de données transférées depuis ou vers une application.

Sa taille peut être de 8/16/32/64/128/256KB

Et nous venons de voir plus haut que la plus petite unité dans une base de données est la “page”.

Nous pouvons donc en déduire la taille de nos I/O pour les bases de données Exchange 2010 :

1 I/O = 1 page = 32Ko

Cette taille a été augmentée dans la version 2010 pour améliorer les performances.

Pour historique :

En 2003 la taille d’un page été de 4Ko

En 2007 la taille est passée à 8Ko

 

Donc dans Exchange 2010 la lecture ou l’écriture de données dans une base de données se fait par morceau de 32Ko.

 

Pour toutes questions n’hésitez pas.

Anthony COSTESEQUE.

Exchange et le Stockage – Partie 5

Voici le tableau recapitulatif des best practise (bonnes pratiques) qu’il faut suivre lors du design et installation d’Exchange 2010

Pour toutes questions n’hésitez pas.

Anthony COSTESEQUE

Exchange et le Stockage – Partie 4

Aujourd’hui nous allons voir ce que nous pouvons faire dans une configuration plus modeste (dans laquelle nous n’avons pas 4 MBX et donc pas la possibilité d’avoir 4 Copies de Database (1 Active + 3 passives) pour pouvoir utiliser du JBOD).

Nous pouvons avoir 2 types de configuration :

Sans HA avec par exemple 1 seul serveur et tous les rôles ensembles.

Avec HA et donc au moins 2 serveurs MBX (nous pourrons aussi avoir tous les rôles ensembles sur les 2 serveurs).

 

Tout d’abord la première limitation (best practise)

http://technet.microsoft.com/en-us/library/ee832792.aspx

Sans HA : taille maximale de la base de données -> 200Go

Avec HA : taille maximale de la base de données -> 2To

(Le maximum supporté (mais non recommandé) étant 16To)

 

Ensuite, n’étant pas en JBOD nous allons devoir utiliser du RAID et donc introduire le facteur pénalité au niveau des I/O.

En effet lorsque nous sommes en RAID, un I/O (de type écriture) qui arrive au niveau du contrôleur RAID, qui gère notre grappe de disques physiques sur lequel repose notre LUN, ne requière pas qu’une simple écriture ou lecture.

Prenons du RAID5 (le plus commun) nous avons une pénalité de 4 en écriture car :

Une fois que l’I/O arrive dans le contrôleur nous avons besoin de 2 opérations de lecture et 2 opérations d’écriture pour achever l’écriture de cet I/O dans notre stockage.

1. Lecture de la donnée non modifiée (qui va être mise à jour)
   
2. Lecture de la parité associée
   
3. Calcule de nouvelle parité (nouvelle donnée avec la parité récupérée précédemment)
   
4. Ecriture nouvelle donnée
   
5. Ecriture nouvelle parité associée
   

 

Donc 1 I/O en écriture sur une LUN en RAID5 équivaut à 4 I/O en réalité, et c’est ce facteur que nous devons prendre en compte dans notre dimensionnement.

 

Tableau des pénalités :

Niveau RAID	Lecture	Ecriture
RAID 0	1	1
RAID 1 ou RAID 10	1	2
RAID 5	1	4
RAID 6	1	6

 

Pour minimiser l’impact de cette pénalité le stockage de type entreprise (EMC², Netapp, etc) utilise un cache et des algorithmes d’optimisation.

Mais tout cela marche très bien sur des I/O de type séquentiels et non aléatoire (random), encore une fois tout le travail de l’équipe d’exchange et d’optimiser la gestion de ses I/O pour les rendre au maximum séquentiels.

Nous sommes aujourd’hui avec Exchange 2010 sur 60% d’I/O séquentiels pour 40% d’I/O aléatoires.

 

Mais nous avons une configuration plus modeste et nous nous appuierons sur le contrôleur RAID de notre serveur donc il ne faudra pas trop s’attendre à des miracles.

Nous aurons à notre disposition un cache tout petit et des algorithmes basiques.

 

Alors maintenant voyons nos calculs :

 

1. Sans HA
   

 

Pour minimiser les couts nous retrouverons souvent un serveur physique avec 5 disques.

2 disques en RAID 1 pour le système et les applications

2 disques en RAID 1 pour les bases de données et les logs

    Ou

3 disques en RAID 5 pour les bases de données et les logs

Si nous utilisons des disques standards nous aurons souvent des spindles à 7200 tours/min en 3,5 pouces SAS

 

Je vais répondre à une question que vous devez surement vous poser, à savoir pourquoi du RAID 1 pour les databases.

Et bien étant donné que nous sommes sur une petite configuration c’est moins gênant de perdre 50% de volumétrie (alors que l’on n’en perd que 1 disque sur du RAID 5).

Les bases feront 200 Go maximum pour héberger nos utilisateurs et rentrerons sur 2To (en RAID 1) nous utiliserons donc 2 disques.

Elles rentreraient aussi sur du RAID 5 même en comptant la pénalité supplémentaire mais par contre nous devrions utiliser 3 disques !

 

Nous allons utiliser le même type de profile que dans la partie 3 :

Profile I/O :

100 messages (80/20)

200Ko la taille moyenne d’un mail

14 jours de SIR

 

Partons sur une cible de 100 boîtes aux lettres à héberger

 

(Adapter en fonction de vos besoins avec les tableaux présents ici : http://technet.microsoft.com/en-us/library/ee712771(EXCHG.140).aspx)

C’est très important car si vous avez bien 100 mails par jour le profile est 0,12 alors qu’avec 150 on passe à 0,18)

 

Maintenant calculons :

La formule pour la charge en I/O est la même que vue en partie 3 :

Database Volume I/O = Number of Mailboxes x IOPS Profile x (1 + I/O Overhead Growth Factor)

100×0.12x(1+20%)=14,4 IOPS

Nous prendrons comme cible 15 IOPS

Ajoutons maintenant la pénalité :

Pour rappel une database représente 60% de lecture 40% d’écriture donc avec la formule (%Lecture + Pénalité(%Ecriture) nous obtenons :

RAID 1 de 2 : (0,6+(2×0,4))x15 = 21 IOPS

RAID 5 de 4 : (0,6+(4×0,4))x15 = 33 IOPS

 

Nous devons donc pouvoir soutenir 21 IOPS avec notre stockage.

 

Pour calculer le nombre de disques pour soutenir notre charge, voici la formule

nombre de disques = ((%Lecture + Pénalité(%Ecriture))(IOPS cible))/IOPS max par disque

 

En RAID 1 : ((0,6+(2×0,4))x15)/65=0,32 donc nous pouvons soutenir notre charge sur 2 disques en RAID 1

En RAID 5 : ((0,6+(4×0,4))x15)/65=0,50 donc nous pouvons aussi soutenir notre charge sur 3 disques en RAID 5

 

Maintenant essayons de définir nos building block, en partant du stockage je peux soutenir maximum 65 IOPS sur un disque de 2To SAS 7200 tours/min, donc :

Maximum IOPS database =

65 / (0,6+(2×0,4)) = 46,43 disons 46 IOPS pour du RAID 1

(65×2) / (0,6+(4×0,4)) = 59,09 disons 59 IOPS pour du RAID 5 (2+1)

 

Nous sommes presque arrivé au bout :

Nombre maximum d’utilisateurs =

(65 / (0,6+(2×0,4))) / (0,12x(1+20%)) = 322,42 disons 322 utilisateurs en RAID 1

((65×2) / (0,6+(4×0,4))) / (0,12x(1+20%)) = 410,35 disons 410 utilisateurs en RAID 5 (2+1)

 

Mais nous n’avons pas pris en compte les quotas car pour rappel nous sommes limités à une base de 200Go

Pour finir :

322 utilisateurs pourront avoir un quotas maximum de 210Mo pour tous les mettre dans 1 base de 200Go en RAID 1

410 utilisateurs pourront avoir un quotas maximum de 100Mo pour tous les mettre dans 1 base de 200Go en RAID 5

 

Donc nous voyons bien ici que nous sommes limités par la taille des boites aux lettres (Quota)

Si nous prenons des quotas à 1Go nous pouvons mettre 120 utilisateurs par base de 200Go

Si nous prenons des quotas à 2Go nous pouvons mettre 68 utilisateurs par base de 200Go

 

Récapitulatif

Type de disque	Niveau de RAID	Pénalité	Nombre d’IOPS supporté	Nombre d’utilisateurs	Quota	Nombre d’utilisateurs par base de 200Go	Nombre de bases nécessaire	Licence Exchange necessaire
SAS 2To 7200 trm	RAID 1 (1+1)	2	46	322	1Go	120	3	standard
SAS 2To 7200 trm	RAID 1 (1+1)	2	46	322	2Go	68	5	standard
SAS 2To 7200 trm	RAID 5 (2+1)	4	59	410	1Go	120	4	standard
SAS 2To 7200 trm	RAID 5 (2+1)	4	59	410	2Go	68	7	enterprise

 

1. Avec HA
   

 

Ce qui va changer avec le HA c’est le nombre de serveurs MBX qui passe à 2 minimums ainsi que les licences Windows utilisées qui sont de type Entreprise (pour supporter le cluster MSCS utilisé par le DAG).

Mais surtout, nous passons de 200Go à 2To comme taille de Database en best practise!

Attention à ne pas oublier si vous installez tous les rôles Exchange sur vos 2 serveurs, le cluster MSCS étant obligatoire pour le rôle MBX en mode DAG, vous ne pourrez pas utiliser le cluster NLB pour vos rôles CAS, vous devrez recourir à un boitier externe de load balancing.

 

Coté calcul la seul chose qui change sera la taille limite à 2To (best practise) et le profile I/O qui passe de 0,12 à 0,1 et donc :

 

RAID 1 avec 2 disques de 2To = 2To de volumétrie exploitable

RAID 5 avec 3 disques de 2To = 4To de volumétrie exploitable

 

Je vous passe toutes les étapes qui sont les même que précédemment et vais directement à l’essentiel :

 

Nombre maximum d’utilisateurs =

(65 / (0,6+(2×0,4))) / (0,1x(1+20%)) = 386,90 disons 386 utilisateurs en RAID 1

((65×2) / (0,6+(4×0,4))) / (0,1x(1+20%)) = 492,42 disons 492 utilisateurs en RAID 5 (2+1)

 

Mais nous n’avons pas pris en compte les quotas car pour rappel nous sommes limités à une base de 2To

Donc la vrai taille de notre disque de 2To est : 2×0.931 = 1,862TB (To) = 1906,688Go (comme vu dans la partie 3)

En RAID 1 nous aurons donc 1906,688Go de disponible (1 LUN).

En RAID 5 nous aurons donc 2×1906,688Go soit 3813,376Go de disponible (2 LUNs).

 

Pour la donnée exchange nous avons toujours le garde-fou de 20% par LUN donc :

En RAID 1 nous avons 1906,688 – 20% = 1525,3504Go (pour mettre notre database + ses logs)

En RAID 5 nous avons 2×1525,3504Go = 3050,7008Go (pour mettre 2 databases + leurs logs)

 

Pour finir :

322 utilisateurs pourront avoir un quotas maximum de 2,5Go pour tous les mettre dans 1 LUN de 2To en RAID 1

492 utilisateurs pourront avoir un quotas maximum de 3Go pour tous les mettre dans 2 LUNs de 2To en RAID 5 (2+1)

 

Donc nous voyons bien ici que nous sommes limités par le nombre d’IO maximum que peut fournir notre grappe RAID !

Si nous baissons les quotas nous ne pourrons pas mettre plus d’utilisateurs !!

 

Récapitulatif

Type de disque	Niveau de RAID	Pénalité	Nombre d’IOPS supporté	Nombre d’utilisateurs	Quota maximum	Nombre de bases nécessaire	Licence Exchange necessaire
SAS 2To 7200 trm	RAID 1 (1+1)	2	46	386	2,5Go	1	standard
SAS 2To 7200 trm	RAID 5 (2+1)	4	59	492	3Go	2	standard

 

Nous sommes arrivés au bout de cette partie :)

Nous verrons dans la prochaine les best practise sur les volumes et le RAID à respecter pour être dans des conditions optimales.

 

Si vous avez des questions n’hésitez pas.

Anthony COSTESEQUE

Exchange calculateur version 14.2

Une nouvelle version du calculateur Exchange est disponible sur le site de l’équipe produit

Une nouvelle page est dédiée à l’explication pour l’utilisation de ce calculateur

http://msexchangeteam.com/archive/2009/11/09/453117.aspx

Téléchargement : http://msexchangeteam.com/files/12/attachments/entry453145.aspx

Bonne lecture !

David

Exchange Storage Calc Update : Version 12.8

Petite information régulière maintenant avec un certain nombre de mises à jour, merci Ross J

Il est maintenant possible de faire des calculs pour faire de l’actif / actif et beaucoup d’autres choses

Fonctionnement du calculateur : http://msexchangeteam.com/archive/2009/11/09/453117.aspx

Suivi des modifications : http://msexchangeteam.com/archive/2010/01/22/453859.aspx

Equipe produit : http://msexchangeteam.com/archive/2010/09/17/456327.aspx

Téléchargement direct : http://msexchangeteam.com/files/453145/download.aspx

Ouvrez vos Excel !

David Pekmez