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