Exchange your Mind

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

Archive for the ‘Stockage-2010’ Category

Exchange et le Stockage – Partie 14

Posted by Anthony Costeseque le mars 25, 2013


Bonjour à tous,

Update 09/04/2013 : pour répondre à certaines remarques que j’ai pu recevoir :)

1 – Les calculs ne sont pas présents pour la partie JBOD RAID-Less : je vous renvoie à la partie 3 (calcul DB+Logs avec la feuille Excel MBX Exchange)

    2 – Les types de disques détail :

  • Enterprise (ENT)
    • Interface dual port SAS
    • 10K, 15K tours par minutes (TPM)
    • 146, 300, 400, 450, 600GB +
    • Large Form Factor (LFF) & Small Form Factor (SFF)
  • Midline (MDL)
    • SAS – dual port
    • SATA – single port
    • 7200 TPM + LFF & SFF
    • 500GB, 750GB, 1TB, 2TB +
  • Entry (ETY) – Ne convient pas pour ExchangeEntry (ETY) – Ne convient pas pour Exchange

La référence dans la plus part des déploiements est MDL SAS 7200 tr/min, on trouve toujours du DAS pensé pour le JBOD RAID-Less chez HP avec du SATA mais c’est de plus en plus rare (la différence de prix entre le SAS et le SATA est très faible)

    3 – La prise en compte des produits tiers qui ajoute de la charge : BES, etc … -> En effet il faudra adapter en fonction de la charge que vous ajouterai sur vos serveur Mailbox

    4 – Ces calculs théoriques sont à adapter en fonction de ce que vous constaterez pendant les premiers mois de pleine production, important dans le cas du JBOD RAID-Less la charge assumée pour 1 disques 540/550 utilisateurs n’est jamais de 100% (les chances que les 550 utilisateurs sollicitent simultanément leur boite mail est à peu près comme de gagner au loto (oui je sais ça arrive ! mais ça ne m’est encore jamais arrivé :/)

    5- Pour finir ce ne sont pas des règles mais des constats que j’ai pu faire pendant ces années ou j’ai déployé de l’Exchange 2010, beaucoup de composant dans l’infrastructure peuvent influencer le rendu final !

    6 – Ne jamais oublier de valider votre infrastructure avec JetStress cela permet déjà de faire ressortir les grosses anomalies qu’il pourrait y avoir dans le design coté stockage

Je vais reprendre cette série de billets sur le stockage dans Exchange 2010, et je vous propose aujourd’hui les scenarios classiques de dimensionnement que je rencontre le plus souvent.

Direct attachement interne

(DAS)

Storage Area Network

(SAN)

Direct attachement externe

(DAS)

SANS HA

AVEC HA / RAID

AVEC HA / RAID

AVEC HA / JBOD Raid-Less

50 – 100 utilisateurs

100 – 500 utilisateurs

> 500 utilisateurs

> 3000 utilisateurs

1 Copie

2 Copies

2 Copies

>= 3 Copies

Voici le résumé.

Maintenant comment le lire :

Mon expérience dans le design d’infrastructure Exchange (2010) m’a montré que dans la plupart des cas c’est le nombre d’utilisateurs (3eme ligne) qui conditionne le reste de la solution.

Même si ce n’est pas toujours le cas pour une installation inférieur à 100 Utilisateurs le HA ne sera pas pris en charge pas Exchange mais souvent par une autre solution (souvent basé sur la technologie de virtualisation qui la soutient).

Ce tableau montre aussi que pour aller vers du DAS JBOD RAID-Less il faut un nombre d’utilisateurs important pour rentabiliser le fait de devoir avoir au moins 3 Copies pour une base.

Donc ce tableau ce lit à partir du nombre de d’utilisateurs que devra supporter votre solution de messagerie pour ensuite vous montrer le scenario le plus rependu et le plus optimal en terme de cout/fonctionnalité.

Maintenant passons au détail de chaque solution :

 
 

50 – 100 utilisateurs / SANS HA – 1 Copie

Profile I/O : 0,12 IOPS

  • 100 messages (80/20)
  • 100Ko la taille moyenne d’un mail
  • 14 jours de SIR

Bonnes pratiques : Taille de 200Go maximum

Disques de 2To 7200 tr/min

RAID Obligatoire

RAID 1 (1+1)

RAID 5 (2+1)

Building block

En partant du stockage je peux soutenir au maximum 65 IOPS sur un disque de 2To SATA 7200 tr/min mais il ne faut pas oublier la pénalité en écriture.

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

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

Bilan (SANS HA)

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 nécessaire

2To
7200 trm

RAID 1 (1+1)

2

46

322

1Go

120

3

standard

2To
7200 trm

RAID 1 (1+1)

2

46

322

2Go

68

5

standard

2To
7200 trm

RAID 5 (2+1)

4

59

410

1Go

120

4

standard

2To
7200 trm

RAID 5 (2+1)

4

59

410

2Go

68

7

enterprise

 
 

100 – 500 utilisateurs / AVEC HA – 2 Copies

Serveurs MBX : 2 minimums

Licences Windows Entreprise (pour supporter le cluster MSCS utilisé par le DAG)

Bonnes pratiques : Taille de 200Go à 2To pour une base de données

profile I/O qui passe de 0,12 à 0,1

Nombre maximum d’utilisateurs

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

    (contre 322 SANS HA)

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

    (contre 410 SANS HA)

Bilan (Avec HA) (Sur chaque serveur)

Type de disque

Niveau de RAID

Pénalité

Nombre d’IOPS supporté

Nombre d’utilisateurs

Quota maximum

Nombre de bases nécessaire

Licence Exchange nécessaire

2To
7200 trm

RAID 1 (1+1)

2

46

386

2,5Go

1

standard

2To
7200 trm

RAID 5 (2+1)

4

59

492

3Go

2

standard

 
 

> 500 utilisateurs / AVEC HA – 2 Copies / Version SAN


Cache intelligent

Introduction d’une gestion du cache intelligente permettant de minimiser au maximum la pénalité RAID


Base de référence pour vos réflexions :

Exchange 2010 Solution Reviewed Program (ESRP) – Storage v3.0

http://technet.microsoft.com/en-us/exchange/ff182054.aspx

 
 

> 3000 utilisateurs / avec HA – 3 Copies / Version JBOD RAID-Less

Introduction du JBOD RAID-Less (DAS)

Minimum 3 copies (1 active + 2 passives)

Model : 1 LUN pour la base de données et ses logs = 1 disque


Recommandation

Une large variété de type de stockages sont supportés pour Exchange 2010. Toutefois, le mode RAID-less 3 copies ou plus est la recommandation des équipes produits et du consulting Microsoft, donc validé par le support Microsoft dans les revues de supportabilité.

Concernant le taux de panne des disques SATA/SAS 7200tr/min et donc un éventuel cout d’exploitation caché, les équipes produits Exchange ont mené des tests particulièrement avancés avec les principaux constructeurs (HP, Dell, IBM, etc…)

En mode JBOD RAID-Less le « Annual Disk Failure Rate » (AFR) n’excède pas 5%.

Les constructeurs annoncent des résultats identiques et basent leurs prévisions d’intervention et remplacement de disques sur ces métriques.

Pour rappel, la maintenance des disques couvre le remplacement en 4 heures en 24X7.

3 Copies ou 4 ?

La réponse simple est 4, tout simplement car si vous avez 4 serveurs MBX reparties entre 2 salles et que la salle ou vous avez 2 copies crash complètement, vous avez une copie survivante active sur la salle 2.

Maintenant la salle revient et les synchro des copies commencent, si la salle 2 crash pendant la copie il ne reste plus rien de consistant il faut donc repartir du dernier backup !

2 copies sur chaque salle (4 au total) permettent de s’affranchir de ce scenario.

Building block

En partant du stockage je peux soutenir au maximum 65 IOPS sur un disque de 2To SATA 7200 tr/min ici aucune pénalité.

Maximum IOPS database
65 / (0,6+(1×0,4)) = 65 IOPS

Nombre maximum d’utilisateurs

(65 / (0,6+(1×0,4))) / (0,1x(1+20%)) = 540 utilisateurs

Quotas

Je suis clairement limité par les IOPS donc il ne reste plus qu’à maximiser l’espace disponible.

Je peux donc proposer comme quotas :

1,7Go maximum

Avantages/Inconvénients

SAN / RAID

  •     Compliqué à implémenter
  •     Prévoir des disques de Hot Spare (1 / 30 disques)
  •     Besoin de connaissances pour le maintien et l’administration
  •     Couteux (infrastructure Fibre Chanel)

DAS / JBOD RAID-Less

  •     Simple d’implémentation
  •     Pas de besoins de connaissances en SAN
  •     Pas de notion de Hot Spare
  •     Moins couteux (infrastructure SAS/SATA)

 
 

Bonne lecture à tous,

Pour toutes questions n’hésitez pas.

Anthony COSTESEQUE

Posted in Exchange Server 2010, Installation-2010, Performance-2010, Stockage-2010 | 1 Comment »

RDM or not RDM

Posted by Anthony Costeseque le juin 29, 2012


Là est la question !

Bonjour à tous,

La question qui revient régulièrement lorsque l’on parle de vitaliser Exchange 2010 et que le choix se porte sur l’hyperviseur de VMware vSphere, c’est quelle enveloppe utiliser pour le stockage.

RDM : Raw Device Mapping (accès direct au stockage présenté)

OU

VMFS : un Datastore formaté avec le système de fichier propriétaire de VMware, le VMFS (celui contiendra des fichiers à plat de disque dur de type .vmdk)

Détruisons tout de suite le mythe qui remonte à VMware 3.5 et précédant ! Et qui est incrusté dans l’inconscient collectif ;)

Il n’y a plus de différences de performances entre VMFS et RDM, vous ne gagnerez pas en performance en utilisant du RDM !

(Le gain ne sera absolument pas perceptible !)

Maintenant faisons une comparaison entre les deux :

RDM :

  • Mapper 1 LUN vers 1 virtual machine, donc nous avons une isolation des I/O
  • En fonction du nombre de LUNs necessaires, la limite des 256 LUNs sera rapidement atteinte !
  • Permet d’utiliser les outils de backup/réplication fournie par la baie de stockage reposant sur Volume Shadow Copy Service (VSS)
  • Support pour les disques partagés en cluster
  • Support pour l’utilisation avec VMware Site Recovery Manager
  • Support de volumes jusqu’à 64TB (RDM en mode physique)

VMFS :

  • Solution préférée, utilise tous les avantages des fonctionnalités liées au stockage présente (elle celles futures)
  • Un volume (Datastore) peut contenir plusieurs VMs (ou être dédié à une VM)
  • Augmente l’utilisation du stockage, fourni une meilleur flexibilité, une administration et un management plus simple
  • Non supporté pour les disques partagés en cluster
  • Support pour l’utilisation avec VMware Site Recovery Manager
  • Disque virtuel .vmdk limité à 2TB

 

Bilan : VMFS recommandé :)

Pour toutes questions n’hésitez pas.

Anthony COSTESEQUE

Posted in 1-EXCHANGE 2010, Exchange 2010 Service Pack 1, Performance-2010, Stockage-2010 | 1 Comment »

Exchange et le Stockage – Partie 13

Posted by Anthony Costeseque le juin 11, 2012


Bonjour à tous,

Nous avons vu dans la Partie 11 comment faire sur EMC² VNX

Nous avons vu dans la Partie 12 comment faire sur Hitachi (HDS) !

Aujourd’hui nous allons voir comment déployer au mieux (best practices) votre solution exchange 2010 sur NetApp.

  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 NetApp nous parlerons de Fabric-Attached Storage (FAS).

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

FAS3210 : 240 disks

FAS3240 : 600 disks

FAS3270 : 960 disks


Un exemple d’implémentation (ici un FAS3210 HA pair (2 Contrôleurs : FAS3210-1 / FAS3210-2))

Pour ce type de configuration et pour éviter toute mauvaise surprise je vous conseille d’ajouter 1 carte « Flash Cache » de 256GB sur chaque contrôleur :)

Prenons un exemple de design de solution pour 6000 utilisateurs :

L’idée ici est d’avoir 2 serveurs MBX (3000 utilisateurs par serveur) en DAG

    Sur chaque serveur 4 DBs actives / 4 DBs passives

    Sur chaque DB : 750 users avec 2GB de quota

    Total dans le DAG 8 DBs Actives / 8 DBs Passives

Pour séparer les domaines de risques nous mettons toutes les DBs actives dans 2 Aggregats sur le contrôleur 1 et toutes les DBs passives dans 2 aggregats sur le contrôleur 2

  1. Ensuite vient le type de disque

Le FAS supportent FC/SAS/NL-SAS/SATA

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 ou 1To.

  1. Puis le type de RAID (bien lire le concept de NetApp)

Attention cette étape est très importante.

Concept : Sur les FAS nous utiliserons des « Aggregats » composé de RAID Group en RAID DP (Dual Parity (RAID 6 sauf que disques de partités fixes))

On provisionnera dans les Aggregats des FlexVol lesquelles contiendront des LUNs (sous forme de fichiers plats) (Data ONTAP étant File non Block)

Pour les RAID Group nous n’avons pas le choix c’est du RAID-DP


Avec un schéma ça aide :)

Découpage :


Nous utilisons des disques SATA 1TB 7,2K

Pour les DB Actives sur le contrôleur 1

    aggr1 (RAID Group de 14 disques (RAID-DP (12+2)) : 5 premier FlexVol (4 pour les DBs & 1 pour les logs de ces 4 DBs)

    aggr2 (RAID Group de 14 disques (RAID-DP (12+2)) : 5 FlexVol suivant (4 pour les DBs & 1 pour les logs de ces 4 DBs)

On fait la même chose sur le contrôleur 2 pour les DB Passives

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

Database LUN Size : 1650GB

Logs LUN Size : 100GB

  1. Le type de connexion

Stockage « intelligent » donc SAN en FC ou iSCSI.

Je vous recommande du FC pour les 16Gb/s de bande passante (4 ports FC de 4Gb/s en (2 par contrôleur))
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
  • Utiliser des FlexVol dédiés pour vos Databases
  • Utiliser des FlexVol dédiés pour vos logs
  • NetApp recommande d’avoir 10% d’espace dispo dans les FlexVol
  • Utiliser SnapDrive pour provisionner vos LUNs :p cela sera plus simple que de le faire à la main !
  • Faire bien attention au nombre d’axe par aggregat (dans notre exemple on utilise des 1To si on passait sur des 2To cela diviserait par 2 le nombre d’axe et la solution de ne serait plus du tout possible (pas assez de nombre d’IOPS pour soutenir la charge))

Reference : Document NetApp TR-3824.pdf

Pour toutes questions n’hésitez pas !

Bonne lecture :)

La prochaine fois nous parlerons de HP.

Anthony COSTESEQUE

Posted in 1-EXCHANGE 2010, Exchange 2010 SP2, Performance-2010, Stockage-2010 | 1 Comment »

Exchange et le Stockage – Partie 12

Posted by Anthony Costeseque le 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

Posted in 1-EXCHANGE 2010, Exchange 2010 SP2, Performance-2010, Stockage-2010 | 3 Comments »

Exchange et le Stockage – Partie 11

Posted by Anthony Costeseque le décembre 4, 2011


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

Posted in Exchange 2010 Service Pack 1, Exchange Server 2010, Performance-2010, Stockage-2010 | 1 Comment »

Exchange et le Stockage – Partie 10

Posted by Anthony Costeseque le novembre 20, 2011


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

Posted in Exchange 2010 Service Pack 1, Performance-2010, Stockage-2010 | 2 Comments »

Exchange et le Stockage – Partie 8

Posted by Anthony Costeseque le octobre 9, 2011


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.

Posted in 1-EXCHANGE 2010, Exchange 2010 Service Pack 1, Performance-2010, Stockage-2010 | 3 Comments »

Exchange et le Stockage – Partie 7

Posted by Anthony Costeseque le août 28, 2011


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.

Posted in 1-EXCHANGE 2010, Exchange 2010 Service Pack 1, Sauvegarde-2010, Stockage-2010 | 1 Comment »

Exchange et le Stockage – Partie 6

Posted by Anthony Costeseque le août 21, 2011


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.

Posted in 1-EXCHANGE 2010, Exchange 2010 Service Pack 1, Performance-2010, Stockage-2010 | 1 Comment »

Exchange et le Stockage – Partie 5

Posted by Anthony Costeseque le août 14, 2011


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

Posted in 1-EXCHANGE 2010, Exchange 2010 Service Pack 1, Exchange Server 2010, Stockage-2010 | 1 Comment »

 
Suivre

Recevez les nouvelles publications par mail.

Rejoignez 221 autres abonnés