Exchange 2013 et le Stockage – Partie 1 (Sizing)

Bonjour à tous,

Pour inaugurer ce premier billet sur le stockage dans Exchange 2013 quoi de mieux que commencer par une question que tout le monde se pose : Comment définir mon infrastructure quand Microsoft me dit qu’il ne faut pas utiliser les outils qui existent pour Exchange 2010 !?

La réponse vient d’être donner sur le blog de l’équipe Exchange au travers d’un billet plein de formules mathématiques 😉 voyons un peu ce qui change par rapport à Exchange 2010.

Au niveau des informations requises pour le dimensionnement rien de nouveau ! Rappel :

1 Nombre de BAL total

2 Profil IO Utilisateur (100 messages par utilisateur par jour (80 Reçus/20 Envoyés)

3 Taille moyenne d’un mail

4 Quotas

5 Nb jours pour SIR

6 Mode Outlook (cached ou pas)

7 Besoin HA (JBOD RAID-Less) / Besoin HA (RAID)

8 Installation des rôles co-localisé ou non

9 Nombre de DB Copies

10 Profondeur de protection des logs (en cas de problèmes de backup)

11 Nombre de DAG

 
 

1 – L’exemple de Microsoft

L’exemple de Microsoft est simple et permet de découper une paterne simple (building bloc) de la solution cible avec 100 000 BALs.

Profil utilisateur de 200 mails par jour avec une taille moyenne de 75Ko (ici on remarque une augmentation du nombre de mail par jour par utilisateur … deviendrait on accros aux mails ? ;p)

Quotas de 10Go : ici Microsoft montre bien la poursuite de sa volonté de pousser les utilisateurs à laisser tomber l’archivage traditionnel (commencé avec Exchange 2010) grâce à l’utilisation de stockage faible cout (NL-SAS 7200 tr/m).

Un seul site (pour simplifier le design général).

4 Copies par DB (1 Active pour 3 Passives) sans DB Lagged

Serveurs physiques (ici ils ne parlent pas de serveurs virtualisés) car ils y attachent du stockage DAS avec des tiroirs de 24 disques SAS 7200 tr/m de 4To (les 8 To ne sont pas encore disponibles bien qu’Exchange 2013 soit optimisé pour ce format qui ne va pas tarder à arriver sur le marché).

Solution HA JBOD RAID-Less : ici encore Microsoft montre bien la poursuite de sa volonté de pousser l’utilisation de stockage « non intelligent » (voir tous mes précèdent billets sur la stratégie MS avec Exchange 2010).

La solution globale doit tolérer une double panne.

2 – Passons aux formules

(La mise en pratique des formules se trouvent en 3- (plus bas))

Storage requirements

Le besoin en capacité consiste en les éléments suivant :

Storage for mailbox data (primarily based on mailbox storage quotas)

Storage for database log files

Storage for content indexing files

Overhead for growth

   
 

1 – Taille d’Une MBX sur Disque, 3 facteurs :

Mailbox storage quota

Database white space (size equal to 1 day worth of messaging content) :

a) Database Whitespace per Mailbox = per-user daily message profile x average message size

Recoverable items (SIR) (1.2 percent increase in mailbox size for a 14 day deleted item retention window + 3 percent increase in the size of the mailbox for calendar item version logging which is enabled by default)

b) Recoverable Items Folder Size = (per-user daily message profile x average message size x deleted item retention window) + (mailbox quota size x 0.012) + (mailbox quota size x 0.03)

   
 

2 – Content indexing :

20% of the database + 1 (pour autoriser les taches de maintenance à se dérouler sans problèmes)

Per-Database Content Indexing Space = database size x 0.20

Per-Volume Content Indexing Space = (average database size x (databases on the volume + 1) x 0.20)

 
 

3 – Log space

Every time you double the average message size, you must increase the logs generated per day by an additional factor of 1.9

Transaction logs at 200 messages/day with 150KB average message size = 40 logs/day (at 75KB average message size) x 1.9 = 76

Transaction logs at 200 messages/day with 300KB average message size = 40 logs/day (at 75KB average message size) x (1.9 x 2) = 152

   
 

4 – Calculate the maximum amount of space available for mailboxes

Available Space (excluding required free space) = Formatted capacity of the drive x (1 – free space)

Per-Volume content indexing factor = 0,2 x (1 + (1 / Databases per-volumes))

Space available for databases ans logs (excluding required free space & content indexing space) = (Formatted capacity of the drive x (1 – free space)) / (1 + (0,2 x (1 + (1 / Databases per-volumes))))

   
 

5 – Maximum database size

Maximum database size = Space available for databases ans logs / Number of Databases per-volumes

   
 

6 – Maximum users per database (capacity perspective)

Maximum users per database (capacity perspective) = Maximum database size / Mailbox Size on disk

   
 

7 – Calculate the maximum number of drives for mailbox database usage

Maximum possible databases volumes per-server = 50 maximum database copies / Nb databases copies per-volume

   
 

8 – Number of database copies per server

12 database volumes and 4 database copies per-volume, we will have 48 total database copies per server

   
 

9 – Total active copies in sample DAG = (Number of server x Number of databases copies per-server) / Number of copies for resiliency

   
 

10 – Number of DAG needed = (Number of users / Number of User per-database) / Number of active copies

This is the building block of the solution

   
 

11 – Final Users per-database = Number of Users / (Number of DAG x Number of active copies)

   
 

12 – Estimated Database Size = Final Users per-database x Mailbox Size on disk

   
 

13 – Estimated Database Consumption per-volume = Estimated Database Size x Number of database per-volume

   
 

14 – Estimated Content Index Consumption per-volume = Estimated Database Size x (Number of database per-volume + 1) x 0,20

   
 

15 – Estimated Log Space Required per-volume = Total Local Capacity Required per Database x Number of database per-volume

   
 

16 – Per-volume space utilization = (Estimated Database Consumption per-volume + Estimated Content Index Consumption per-volume + Estimated Log Space Required per-volume) x (1 / (1 – 0,05))

   
 

IOPS requirements

   
 

17 – IOPS requirements for a database = Final Users per-database x Number of Databases per-volumes x Estimated IOPS per mailbox

   
 

 
 

Example pour 50 utilisateurs avec 200 messages par jour

50 x 0.134 = 6.7 transactional IOPS (database active)

50 x 0.134 = 6.7 transactional IOPS (database passive)

   
 

Pour Microsoft : Midline SAS drives typically provide ~57.5 random IOPS (dans mes billets sur Exchange 2010 j’avais annoncé 65 IOPS (ils sont conservateurs (ce qui se comprend pour un éditeur)))

   
 

Storage bandwidth requirements

   
 

Cette partie est tres importante et souvent sous-estimée !

Dans notre exemple nous parlons beaucoup de JBOD avec l’utilisation de châssis SAS (connexion DAS avec le stockage) interne au serveur.

Pour ce modèle de configuration le background database maintenance (BDM) (voir mon billet précèdent) ne représente pas une charge à problème.

Mais pour les configuration de type RAID sur stockage intelligent (EMC / NetApp / Hitachi / etc) cela peut représenter un goulot d’étranglement sur le fait de partager un brin FC/iSCSI commun avec d’autre serveurs.

   
 

Microsoft annonce que la charge est maintenant de 1Mo/sec/database copy (comparé à 5Mo avant)

   
 

18 – Storage Bandwidth required per-server = Number of database copies per server x 1

   
 

Transport storage requirements

   
 

La partie transport étant maintenant sur le MBX (excepté le composant Front End (FE) sur le CAS) il faut la prendre en compte dans les calculs (besoin en espace et en IO).

Pour le besoin en espace il y a 2 besoins :

Queuing (inclu shadow queuing)

Safety Net (nouveau nom pour le transport dumpster)

   
 

Transport storage capacity required = sum of message content on disk in a worst-case scenario

The current day’s message traffic, along with messages which exist on disk longer than normal expiration settings (like poison queue messages)

+ Queued messages waiting for delivery

+ Messages persisted in Safety Net in case they are required for redelivery

(+ shadow queuing in which a redundant copy of all messages is stored on another server)

   
 

19 – Maximum size of the transport database

Overall Daily Messages Traffic = number of users x message profile

Overall Transport DB Size = average message size x overall daily message traffic x (1 + (percentage of messages queued x maximum queue days) + Safety Net hold days) x 2 copies for high availability

   
 

20 – Per-server transport DB size

Per-server transport DB size = Overall Transport DB Size / (worst-case failure event in the target design)

   
 

21 – Transport IO throughput required

Constat fait par Microsoft : 1 DB write IO per message and virtually no DB read IO, with an average message size of ~75KB

Pour l’instant Microsoft préconise : Our best practices guidance for the transport database is to leave it in the Exchange install path (likely on the OS drive)

Attention bien vérifier que le contrôleur du disque supporte le « protected write cache »

Si le contrôleur permet des optimisations sur le cache en lecture/écriture, voir s’il est possible de mettre 100% de cache en écriture.

   
 

Processor requirements

   
 

   
 

Il faut tout d’abord trouver le SPECint_rate2006 score, il existe plusieurs méthode, voici celle que je vous conseil :

a – Récupérer le Processor Query Tool de Scott Alexander OU aller sur le site Standard Performance Evaluation Corporation dans la section Results > CPU2006 > Search all SPECint_rate2006

b – Choisir Processor et mettre votre model de processor

c – Recuperrer pour votre serveur le « Result », le nombre de « Core » ainsi que la « Baseline »

d – Per-core SPECint_rate2006 score = Result / Core

e – Per-core SPECint_rate2006 Baseline score = Baseline / Core

   
 

22 – Estimated available Exchange workload megacycles = ((Per-core SPECint_rate2006 score x MHz per-core of baseline plateform) / (Baseline per-core score value)) x Number of Core

Attention la bonne pratique est de ne pas être au-dessus des 80% de charge CPU sur 1 serveur

   
 

23 – Exchange workload megacycles required = Number of users x ((Mcycles per User on Active DB Copy + (Number of Passive Copies x Mcycles per User on Passive DB Copy))

   
 

24 – Exchange workload megacycles required per-server = Number of Active Copies per-server x Number of Users per-database x Mcycles per User on Active DB Copy) + (Number of Passive Copies per-server x Number of Users per-database x Mcycles per User on Passive DB Copy)

   
 

25 – Peak average CPU in worst-case failure = (Exchange workload megacycles required per-server / Estimated available Exchange workload megacycles) x 100

   
 

Memory requirements (Multi-Role)

   
 

Pour le calcul de la mémoire il nous faut connaitre le nombre d’utilisateurs total par serveur (toute Copie comprises (Active et passive)).

La colocalisation des rôles a aussi une incidence.

La mémoire est consommé par :

ESE database cache

New content indexing technology

Various Exchange services (provide transactional services to end-users / handle background processing of data)

   
 

   
 

26 – Total memory required per-server MBX = (worst-case active database copies per-server x users per-database x memory per-active mailbox)

   
 

27 – Total memory required per-server CAS = 2Go + (2Go x ((worst-case active database copies per-server x users per-database x mbx mcycles per-user) x 0,25) / (per-core mcycles))

   
 

28 – Total memory required per-server Final = Total memory required per-server MBX + Total memory required per-server CAS

   
 

NOTE : Pour un fonctionnement optimale du moteur ESE sur des configurations tres petites ou les valeurs seraient beaucoup moindre, voici le minimum de mémoire à respecter :

Ce tableau est à lire nombre total de Copies par serveur (Active + Passive)

   
 

Processor / Memory requirements (Separate Role)

   
 

Dans le cas de rôle séparés il faut calculer le besoin pour le CAS en CPU et Mémoire.

   
 

Pour la partie CPU nous avons besoin de 25% des megacycles utilisés pour supporter les « active users » sur le rôle Mailbox (MBX)

1:4 ratio (1 CPU CAS pour 4 CPU Mailbox) (dans Exchange 2010 le ratio était de 3:4 … !!)

Une autre façon est de prendre 25% du nombre total de megacycle requis pour tous les utilisateurs actifs

   
 

29 – CAS Required Mcycles = Number of users x Mcycles per User on Active DB Copy x 0,25

   
 

Tout en respectant les 80% max de charge CPU

30 – Number of CAS server required = CAS Required Mcycles / (Estimated available Exchange workload megacycles x 0,8)

Ajouter le nombre de serveurs pour palier à la haute disponible souhaitée (tolérant à 1 ou 2 pannes)

   
 

Pour la partie mémoire le calcul est le même que dans Exchange 2010

31 – Total memory required per-server CAS = 2Go + (2Go x (((Total number of users / Worst cas number of CAS server) x mbx mcycles per-user) x 0,25) / (per-core mcycles))

   
 

Active Directory capacity for Exchange 2013

   
 

Pas de changement par rapport à Exchange 2010

1 Catalogue Global CPU pour 8 Mailbox CPU (ratio 1:8)

   
 

32 – AD GC CPU required = ((Number of user x Mcycles per User on Active DB Copy) / per-core mcycles) / 8

   
 

33 – Number of AD GC server required = AD GC CPU required / Core per-server

Ajouter le nombre de serveurs pour palier à la haute disponible souhaitée (tolérant à 1 ou 2 pannes)

   
 

NOTE : pour la mémoire sur les AD GC server il faut juste prévoir la possibilité de charger la taille complète de la DB AD (NTDS.DIT) dans la RAM.

   
 

Note sur l’Hyperthreading

A désactiver sur tous les serveurs !

Exchange 2013 do not outweigh the negative impacts. It turns out that there can be a significant impact to memory utilization on Exchange servers when hyperthreading is enabled due to the way the .NET server garbage collector allocates heaps.

   
 

3 – Passons à la mise en pratique des formules avec l’exemple de Microsoft

   
 

1 – MBX Size

Quotas : 10Go

White Space : 200 messages/day x 75KB = 14.65Mo

SIR : (200 messages/day x 75KB x 14 days) + (10GB x 0.012) + (10GB x 0.03) = 210,000KB + 125,819.12K + 314,572.8KB = 635.16MB

Mailbox Size on disk = 10GB mailbox quota + 14.65MB database whitespace + 635.16MB Recoverable Items Folder = 10.63GB

   
 

2 – Content indexing :

Index : 100Go database size x (2 databases + 1) x 0.20 = 60Go

   
 

3 – Log Space :

users per database at 65

1% of our users are moved per week in a single day

support 3 days of logs in the case of failed copies or servers

Log Capacity to Support 3 Days of Truncation Failure = (65 mailboxes/database x 40 logs/day x 1MB log size) x 3 days = 7.62Go

Log Capacity to Support 1% mailbox moves per week = 65 mailboxes/database x 0.01 x 10.63GB mailbox size = 6.91Go

Total Local Capacity Required per Database = 7.62GB + 6.91GB = 14.53Go

   
 

4 – calculate the maximum amount of space available for mailboxes

Space available for databases sans logs (excluding required free space & content indexing space) = (3725 x (1 – 0,05)) / (1 + (0,2 x (1 + (1 / 4)))) = 2831

   
 

5 – Maximum database size sans logs = 2831 / 4 = 707,75

   
 

6 – Maximum users per database (capacity perspective) = 708 / 10,63 = 66,604

   
 

7 – Maximum possible databases volumes per-server = 50 / 4 = 12,5

   
 

8 – 48 DB per server

   
 

9 – Total active copies in sample DAG = (16 x 48) / 4 = 192

   
 

10 – Number of DAG needed = (100000 / 66) / 192 = 7,8914

   
 

11 – Final Users per-database = 100000 / (8 x 192) = 65,1042

   
 

12 – Estimated Database Size = 65 x 10,63 = 690,95

   
 

13 – Database Consumption per-volume = 690,95 x 4 = 2763,8

   
 

14 – Estimated content index Consumption = 690,95 x (4 + 1) x 0,20 = 690,95

   
 

15 – Log Space Required per-volume = 14,53 x 4 = 58,12

   
 

16 – Per-volume space utilization = (2763,8 + 690,95 + 58,12) x (1 / (1 – 0,05)) = 3697,7579Go

   
 

17 – IOPS requirements for a database = 65 x 4 x 0,134 = 34,84 IOPS

Il faut ajouter les IOPS pour les Logs et le BDM, mais tout cela rentre bien sur 1 Disque de 57.5 IOPS max

   
 

18 – Storage Bandwidth required per-server = 48 x 1 = 48 Mo/s (ce qui représente environ 500Mb/s (la moitié d’une connexion 1Gb/s))

Donc plus de problèmes pour une liaison iSCSI 1Gb/s

Aucun problème pour une liaison FC 4Gb/s ou 8Gb/s

   
 

19 – Overall Transport DB Size = 75 x (100000 x 200) x (1 + (0,5 x 2) + 2) x 2 = 1,2E10

1,2E10 / 1024 / 1024 = 11444,0918 Go

 

20 – Notre target design avec le building block calculé (1DAG de 16 nœuds) est de 8 DAG, donc nous avons un total de 128 nœuds (oui serveurs :p mais on parle de 100000 utilisateurs)

Le design doit être tolérant à une double panne (par DAG) donc dans le pire des cas il reste en ligne 128 – (8 x 2) = 112 serveurs

Per-server transport DB size = 11444,0918 / 112 = 102,1794 Go

   
 

21 – Pour le processeur E5-2630 sur serveur ProLiant DL380p Gen8 (2.30 GHz)

Result = 430

Baseline = 414

Core = 12

per-core SPECint_rate2006 score = 430 / 12 = 35,8333

Per-core SPECint_rate2006 Baseline score = 414 / 12 = 34,5

   
 

22 – Estimated available Exchange workload megacycles = ((35,8333 x 2000) / (34,5)) = 2077,2928

x 12 = 24927,513 MHz

   
 

23 – Exchange workload megacycles required = 100000 x (10,63 + (3 x 2,74)) = 1885000

   
 

24 – Exchange workload megacycles required per-server = (16 x 65 x 10,63) + (32 x 65 x 2,74) = 16754,4 MHz

   
 

25 – Peak average CPU in worst-case failure = (16754,4 / 24927,513) x 100 = 67,2125%

Nous sommes bien en dessous des 80% de charge des bonnes pratiques

   
 

26 – Total memory required per-server = 16 x 65 x 48 = 49920 Mo

49920 / 1024 = 48,75 Go

Arrondi à une valeur classique de provisionning de mémoire, 64Go

   
 

27 – Total memory required per-server CAS = 2 + (2 x ((16 x 65 x 8,50 x 0,25) / 2077,2928)) = 4,1278 Go

   
 

28 – Total memory required per-server Final = 48,75 + 4,1278 = 52,8778 Go

Nous avons déjà arrondi à 64Go donc la mémoire est suffisante

   
 

29 – CAS Required Mcycles = 100000 x 8,5 x 0,25 = 212500 MHz

   
 

30 – Number of CAS server required = 212500 / (24927,513 x 0,8) = 10,6559

Soit 11 serveurs

Dans notre exemple nous voulons être tolérante à 2 pannes dont il faudra 13 serveurs

   
 

31 – Total memory required per-server CAS = 2 + 2 x (((100000 / 11) x 8,50 x 0,25) / 2077,2928) = 20,5994 Go

Arrondi à une valeur classique de provisionning de mémoire, 24Go

   
 

32 – AD GC CPU required = ((100000 x 8,50) / 2077,2928) / 8 = 51,1483 CPUs

   
 

33 – Number of AD GC server required = 51,1483 / 12 = 4,2624

Il nous faut donc 5 serveurs AD GC pour supporter les 100000 utilisateurs

Nous souhaitons être tolérant à une double panne donc il nous faut au final 7 serveurs AD GC

   
 

3 – Note sur le matériel utilisé par Microsoft

Le matériel que semble utiliser Microsoft est Hewlett-Packard DL380p Gen8 server avec processeur Intel Xeon E6-2650 2 GHz (16 cœurs)

Serveurs 2U avec dans le châssis 12 disques (dont 10 4To SAS 7200 tr/m) :

2 en RAID 1 : pour le operating system, Exchange install path, transport queue database, and other ancillary files

10 en JBOD RAID-Less : pour les DB

   
 

formatted capacity of ~3725Go (pour 4TB)

Nous sommes arrivés à la fin de ce billet !! Nous avons vu pas moins de 33 formules de calculs …

Pour ceux qui sont toujours là ;p n’hésitez pas si vous avez des questions.

Bonne lecture,

Anthony COSTESEQUE