Office Servers and Services

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

Exchange et le Stockage – Partie 3

Posted by Anthony Costeseque sur juillet 31, 2011


Alors aujourd’hui nous allons voir comment nous sommes arrivés à 550 utilisateurs par axe dans une configuration JBOD (disque de 2To SAS 7200 tr/m).

 

Pour cela nous allons voir comment utiliser la feuille de calcul fournie pour l’équipe d’exchange :

http://gallery.technet.microsoft.com/v144-of-the-Exchange-2010-1912958d

Aujourd’hui en version 17.2

 

Avant de commencer, les notes sont importantes !

Nous ne sommes pas dans un environnement multi rôle pour la partie calcul besoin CPU

Pour la partie calcul I/O un surplus de 20% est pris en compte

Les calculs ne prennent pas en compte les applications tierces qui pourraient générer des I/O en plus des bases de données Exchange (un antivirus par exemple aura un impact important !)

L’utilisation de plusieurs profils de mailbox (VIP à 2Go, normal à 1Go, autre à 500Mo) sera distribué dans les bases de données générées, il n’y a pas de bases de données dédiées (il faudra faire vous-même vos calculs dans le cas où vous souhaitez réserver des bases de données par profile)

 

Maintenant pour commencer nous avons besoin de déterminer un certain nombre d’informations concernant nos futures boîtes aux lettres utilisateurs :

  1. Le nombre d’utilisateurs que la solution devra supporter
  2. La taille des boîtes aux lettres (Quota)
  3. L’utilisation des boîtes aux lettres par utilisateur (profile I/O d’une boîte aux lettres)
    1. Nombre de mails reçus/envoyés par jour pour 1 utilisateur
    2. Taille moyenne d’un mail
  4. Profondeur du Single Item Recovery

 

Dans notre exemple nous partirons sur cette configuration :

11000 boîtes aux lettres

On commence à 1Go de Quota

Profile I/O :

    100 messages (80/20)

    200Ko la taille moyenne d’un mail

14 jours de SIR

 

L’environnement :


L’important ici est que nous voulons du JBOD dans il nous faut 4Copies par base de données (1 active et 3 passive) donc il nous faut au moins 4 serveurs MBX.

Important un certain nombre de « garde-fou » est présent pour éviter les mauvaises surprises une fois la solution en place (le matériel installée).

  1. Data Overhead Factor : défaut à 20% (correspond à un ajout de 20% à la taille de la base de données calculée)
  2. LUN Free Space : défaut à 20% (correspond au fait que les bonnes pratiques recommandes de ne pas remplir entièrement l’espace disponible (sur le disque ou dans une LUN), tous les outils de monitoring remontent des erreurs à partir d’une certaine capacité atteinte … si vous ne voulez pas avoir des warning en permanence il faudra laisser de la place (20% étant une bonne valeur pour commencer))
  3. I/O Overhead Factor : défaut 20% (correspond à un ajout de 20% sur les I/O calculés pour les bases de données et les logs)

 


Ici nous remplissons notre profile d’utilisateurs.

Rien de particulier pour compléter des champs.

 


La partie backup est très importante car elle est la gardienne du bon déroulement de la gestion des logs dans notre solution !

Dans la plupart des cas vous utiliserez un logiciel de sauvegarde qui s’appuiera sur le writer VSS d’exchange 2010 au travers du VSS de Windows (Software VSS Backup/Restore).

Le modèle standard étant une full par semaine et le reste du temps en incrémental.

Chaque full ou incrémental videra les logs générés sur la base de données qui aura été correctement sauvegardée.

Donc si un backup ne se passe pas correctement les logs ne sont pas vidés et par conséquent il faut prévoir de faire rentrer plus de logs que prévus en cas de problèmes ! Car rappelez-vous nous sommes dans un model 1 Disque = 1 LUN = 1 DB + ses logs.

Si les logs grossissent trop, ils vont remplir le disque et si le disque est rempli, que l’on ne peut plus écrire de logs, c’est la base de données qui est démontée et le service pour les utilisateurs qui se trouvaient dessus, interrompu !!!

Donc ici nous avons 3 jours de tolérance au disfonctionnement du backup.

Dans le design final nous aurons donc dans un disque de 2To la place pour 1 Database + 3 jours de logs (même si en fonctionnement nominal nous ne consommerons que 1 Database + 1 jour de logs).

 


Nous allons maintenant choisir le type de disques que nous utiliserons.

Ici des 2To en SAS 3,5 pouces 7200 tr/m

 

Pour finir nous allons légèrement modifier les valeurs de référence pour les calculs (au niveau des IOPS) :)

Attention il faudra vraiment que vous sachiez ce que vous faites dans votre design car vous perdrez un garde-fou caché pour éviter les mauvaises surprises à la fin.

 


Faire un clic droit sur un des onglets de la feuille de calcul et choisir Afficher

 


Choisir Tables

 


Ces valeurs sont vraiment faibles, elles font référence à

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

Dans lequel on peut lire :

« Considering each large form factor 7.2K SATA disk generates 55 random IOPS, there are no concerns that the disk can’t handle the I/O requirements of the database. »

 

Les références SAS plus proches de la réalité sont : 65-70 IOPS

Nous allons donc passer la valeur pour le SAS 7200 tours en 3,5 pouces à 66 IOPS

 


 

Maintenant passons au résultat dans l’onglet Role Requirement :


Déplier la partie masquer de la feuille et allons voir un peu dans le détail ce qui nous est proposé :


Dans la partie Database Calculations tout est dit :)

Nous avons la notion de Database par I/O et par Capacité

En effet nous pouvons mettre 816 MBX de 1Go sur un axe de 2To avec 3 jours de logs max seulement nous sommes limités par les I/O max qui peuvent être fournis par notre axe (qui sont de 66 dans notre cas) et par conséquent cela nous ramène à 550 MBX maximum !

Donc avec 550MBX notre disque n’est pas utilisé de façon optimale.

Le but sera donc maintenant d’atteindre la capacité maximale pour une boîte aux lettres, nous permettant d’utiliser au maximum notre disque.

 

Maintenant passons notre quota à 2Go


 

Et retournons voir le détail


Nous sommes allés trop loin (le capacity driver doit rester >= à l’I/O driver)

 


Avec 1,5Go nous sommes bons

 


Avec 1,6Go on dépasse

 

Donc notre point d’optimisation est bien 550 Utilisateurs avec un Quota de 1,5Go par base de données

 


Notre base de données fait 1221Go + 3 jours de logs 133Go

Si j’ajoute 20% avec la base de données cela me fait : 1465,2Go

Donc au total nous consommons 1465,2 + 133 = 1598,2Go

 

Maintenant passons à l’info qui surprend toujours … la taille réel d’un disque après formatage :

La taille commerciale 2TB (2To), malheureusement, est comptée en 10^3 bytes (1000) mais la réalité est 2^10 bytes (1024).

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

Il nous faudrait aussi enlever la taille de la table d’allocation NTFS après formatage (mais on parle en centaine de Mo, donc négligeable)

Si on enlève les 20% de LUN free space reserve on obtient : 1906,688 – 20% = 1525,3504Go (pour mettre notre database + ses logs)

 

Nous avons calculé 1598,2Go donc la feuille de calcul est un peu généreuse :) mais nous retrouvons bien notre optimisation totale de l’espace (en comptant les garde-fous)

 

Pour le détail des calculs des IO, le voici :

La formule pour la base de données :

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

550×0,1x(1+20%)=66 IOPS

    Note : lors des tests de charge avec JetStress (nous verrons comment faire plus tard) il faudra avoir comme objectif les vrai IOPS sans le garde-fou de 20% donc : 55IOPS

La formule pour les logs :

Le profil de charge est 60% d’I/O de type « lecture » (40% en « écriture ») pour la base de données donc :

66-60%=26,4 IOPS en écriture

66-26,4=39,6 IOPS en lecture

Chaque log stream génère 50% des I/O de type écriture de la base de données donc : 26,4/2=13,2 IOPS de type écriture par flux de logs par Disque (LUN).

Et 10% des IOPS en écriture 13,2 soit 1,3 IOPS de type lecture par flux de logs par Disque (LUN).

 

Donc nous avons au final :

66 IOPS pour la base de données

13,2+1,3=14,5 IOPS pour les logs de cette base de données

C’est bien ce que le tableau nous donne (voir la capture plus haut)

 

Voilà comment nous sommes arrivé à un building block au niveau des bases de données de :

550 Utilisateurs sur un disque SAS 3,5 pouces de 7200 tr/m avec 1,5Go de quotas (100 messages par jour d’une taille moyenne de 200Ko) et 3 jours de tolérance à la panne pour le backup ainsi que 20% d’espace disponible dans le disque.

 

La prochaine fois nous verrons comment calculer pour des configurations plus modestes et donc avec moins de 4 serveurs MBX en DAG (JBOB non possible donc en RAID).

 

Pour toutes questions n’hésitez pas.

Bon calculs :)

 

Anthony COSTESEQUE

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

  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 […]

  2. […] Partie 3 – 550 Utilisateurs sur 1 disque SAS ?! […]

  3. […] Exchange et le Stockage – Partie 3 […]

Laisser un commentaire

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

Logo WordPress.com

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

Image Twitter

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

Photo Facebook

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

Photo Google+

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

Connexion à %s

 
%d blogueurs aiment cette page :