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 :

 

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

 

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

 

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