Conception de la disposition des copies de bases de données

 

S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3

Dernière rubrique modifiée : 2010-11-11

Lors de la conception d’une solution à haut niveau de disponibilité pour des serveurs de boîtes aux lettres, vous devez garantir la haute disponibilité pour divers composants d’infrastructure, notamment :

• Les services d’infrastructure tels qu’Active Directory et DNS (Domain Name System)

• Les serveurs membres du groupe de disponibilité de base de données (DAG)

• Les composants de stockage individuels tels que les disques, contrôleurs de stockage et étagères de stockage

• Les composants réseau individuels tels que les routeurs, commutateurs et agrégateurs

• Les racks de serveurs et de stockage

• Les bus d’alimentation

• Les centres de données

Ces divers types de composants représentent des points de défaillance potentiels, parfois appelés domaines de défaillance. Ainsi, le niveau de disponibilité de votre DAG dépend essentiellement de la façon dont vous concevez la solution afin d’isoler et de minimiser les effets négatifs qu’une défaillance de l’un de ces domaines pourrait avoir sur votre environnement DAG. Afin que les domaines de défaillance soient indépendants les uns des autres, chacun d’eux doit disposer d’une copie de la base de données. De plus, étant donné que plusieurs copies deviendraient indisponibles à la suite d’une défaillance, une seule copie par domaine de défaillance suffit.

Par exemple, imaginez un scénario dans lequel vous auriez deux copies d’une base de données. Chaque copie est stockée sur un ensemble distinct de disques, mais les deux se trouvent dans la même baie de stockage. Si la baie de stockage tombait en panne ou devenait indisponible, les deux copies seraient alors indisponibles. Dans cet exemple, le domaine de défaillance est la baie de stockage. Une seule copie de chaque base de données de boîtes aux lettres doit se trouver sur la baie. Sinon, si la baie tombe en panne, plusieurs copies de la base de données (sinon toutes) seront indisponibles.

Lors de la planification de votre architecture de boîtes aux lettres, pensez aux points de conception supplémentaires suivants :

• Déploierez-vous plusieurs copies de bases de données ?

• Combien de copies de bases de données déploierez-vous ?

• Aurez-vous une architecture à résilience de site ?

• Quel type de modèle de résilience de serveur de boîtes aux lettres déploierez-vous ?

• Combien de serveurs de boîtes aux lettres déploierez-vous ?

• Quel modèle de sauvegarde utiliserez-vous ?

• Quelle architecture de stockage utiliserez-vous ?

Pour plus d’informations sur la planification de ces questions, voir Présentation des facteurs de haute disponibilité.

Contenu de cette rubrique

Dispositions de copies de bases de données déséquilibrées

Conception d’une disposition de copies de bases de données équilibrée

Distribution des bases de données actives dans l’exemple de scénario au cours de défaillances de serveur

Scénarios de conception

Souhaitez-vous rechercher les tâches de gestion liées à la haute disponibilité et la résilience de site ? Voir Gestion de la haute disponibilité et de la résilience de site.

Dispositions de copies de bases de données déséquilibrées

Pour comprendre comment les copies de bases de données doivent être réparties au sein d’un groupe de disponibilité de base de données (DAG), imaginez une conception DAG que Contoso, Ltd. est en train de planifier pour sa solution de serveur de boîtes aux lettres à haut niveau de disponibilité. Contoso est en train d’élaborer un DAG comprenant :

• 4 serveurs de boîtes aux lettres

• 20 bases de données de boîtes aux lettres

• 2 copies de chacune des bases de données de boîtes aux lettres

Tous les serveurs sont déployés dans un seul centre de données ; chaque serveur ayant son propre stockage dédié et étant déployé sur son propre rack de serveurs.

Contoso a besoin que deux copies de bases de données à haut niveau de disponibilité (par exemple, non retardées) soient disponibles en permanence et que la solution soit capable de subir deux interruptions de membres DAG simultanées sans effet négatif sur la disponibilité des bases de données.

D’après ces exigences, voyez ci-dessous la disposition des copies de bases de données utilisée.

Disposition initiale des copies de bases de données

À la base, la conception semble correcte car elle répartit les copies actives de chaque base de données sur les quatre membres DAG. Toutefois, cette conception pose quelques problèmes. En termes de ressources de serveurs, la disposition n’est pas optimale. Par exemple, si un serveur tombe en panne, la distribution des bases de données se trouve alors déséquilibrée, comme illustré par l’image suivante.

Disposition des copies de bases de données après défaillance d’un serveur

Suite à la défaillance de Server4, les bases de données DB16 à DB20 sont activées sur Server1 au lieu d’être réparties sur les trois serveurs restants. Il en résulte une distribution déséquilibrée des bases de données de boîtes aux lettres actives et donc une utilisation inégale des ressources de serveurs. Par rapport aux deux autres serveurs restants (Server2 et Server3), Server1 est deux fois plus sollicité.

Autre problème : le DAG ne contient pas assez de copies pour subir deux interruptions de serveurs simultanées. Une seconde défaillance de serveur entraînerait l’indisponibilité de 50 % des bases de données. Si Server1 et Server4 tombaient en panne ou devenaient indisponibles à quelques minutes d’intervalle, 10 bases de données seraient alors indisponibles, comme illustré par l’image suivante.

Disposition des copies de bases de données après défaillance de deux serveurs

Cette conception ne satisfait donc pas l’exigence principale qui consiste à tenir le choc en cas de double défaillance de serveur. Pour résister à une double défaillance de serveur et garantir que toutes les bases de données restent actives, une troisième copie doit être déployée et une nouvelle disposition doit être pensée.

Retour au début

Conception d’une disposition de copies de bases de données équilibrée

Afin de concevoir une disposition de copies de bases de données équilibrée et optimale, vous devrez peut-être revenir sur plusieurs décisions de conception. Lors de la planification de la disposition des copies de bases de données, gardez les principes de conception suivants à l’esprit :

• Assurez-vous de minimiser les défaillances multiples de copies d’une base de données de boîtes aux lettres en isolant chaque copie des autres et en les plaçant dans différents domaines de défaillance. Par exemple, ne placez pas plus d’une copie d’une base de données de boîtes aux lettres dans le même rack de serveurs ou la même baie de stockage.

• Répartissez les copies de bases de données de façon cohérente et équilibrée afin que les bases de données de boîtes aux lettres restent actives en cas de défaillance. La somme des préférences d’activation de chaque copie de base de données sur tout serveur spécifique doit être égale ou presque. Ainsi, vous obtenez une distribution à peu près équilibrée en cas de défaillance, en supposant que la réplication fonctionne et soit à jour.

Blocs de construction

Afin de respecter les principes de conception ci-dessus, nous vous recommandons de placer les copies de bases de données de façon particulière, pour garantir une répartition symétrique de toutes les copies actives sur autant de serveurs que possible. La répartition des copies de bases de données suit le concept des blocs de construction.

Le premier bloc de construction (appelé « bloc de construction de niveau 1 ») dépend du nombre de serveurs de boîtes aux lettres qui hébergeront les copies de bases de données actives. Supposons que ce nombre est N. N définit non seulement le nombre de serveurs de boîtes aux lettres, mais également le nombre de bases de données au sein du bloc de construction. Une copie de base de données active est distribuée sur chaque serveur, pour former un modèle diagonal. Comme dans l’exemple précédent, il y a 4 serveurs de boîtes aux lettres et 20 bases de données de boîtes aux lettres. La taille du premier bloc de construction de niveau 1 est de 4, comme illustré par l’image ci-dessous.

Bloc de construction de niveau 1

Le même modèle est répété pour chaque bloc de construction de niveau 1 restant. Étant donné qu’il y a 20 bases de données, il y a cinq blocs de construction de niveau 1, comme illustré par l’image ci-dessous.

Cinq blocs de construction de niveau 1 pour 20 bases de données

Lorsque vous ajoutez une deuxième copie de base de données, vous la placez différemment pour chaque bloc de construction. Étant donné qu’un serveur héberge déjà la copie active, N – 1 serveurs sont disponibles pour héberger la deuxième copie de base de données. Étant donné que vous utilisez chacun de ces N – 1 serveurs une fois, vous obtenez une distribution complète et symétrique, qui forme le nouveau bloc de construction de taille supérieure. Par conséquent, le nouveau bloc de construction (appelé « bloc de construction de niveau 2 ») présente une taille de N × (N – 1) bases de données. Cela signifie que la deuxième copie de base de données pour la première base de données est placée sur le deuxième serveur et que chaque deuxième copie est ensuite déployée en diagonale au sein du bloc de construction. Une fois ce modèle appliqué au sein du premier bloc de construction de niveau 1, la position de départ de la deuxième copie pour le bloc suivant est décalée d’un cran de sorte que la deuxième copie démarre sur le troisième serveur.

Dans l’exemple, la taille du bloc de construction devient donc 4× (4 – 1) = 4× 3 = 12, ce qui signifie que 12 bases de données composent chaque bloc de construction de niveau 2. Pour le premier bloc de construction de niveau 1 (DB1 à DB4), la deuxième copie de DB1 est placée sur Server2, tandis que pour le deuxième bloc de construction de niveau 1 (DB5 à DB8), la deuxième copie de DB5 est placée sur Server3. Le serveur de départ pour chaque bloc de construction de niveau 1 est décalé d’un cran par rapport au bloc de construction de niveau 1 précédent. Cette disposition continue par le positionnement de la deuxième copie de DB9 sur Server4. Ainsi, si Server1 connaît une défaillance, les deuxièmes copies s’activent sur les trois serveurs restants, ce qui est autrement plus efficace que si plusieurs bases de données s’activaient sur le même serveur.

Bloc de construction de niveau 2 avec trois blocs de construction de niveau 1

Ce modèle est répété pour chaque bloc de construction de niveau 2 restant. Étant donné qu’il y a 20 bases de données, il y a deux blocs de construction de niveau 2 dans cet exemple. Notez que la deuxième copie de DB13 est placée sur Server2.

Bloc de construction de niveau 2 avec les deux blocs de construction de niveau 1 restants

Pour mieux comprendre cette logique, comparons le positionnement des copies de bases de données pour DB1, DB5 et DB9. Ces bases de données ont toutes une copie active sur Server1. Si Server1 connaît une défaillance, vous souhaitez que les deuxièmes copies des bases de données soient activées sur les différents serveurs restants afin que la distribution de la charge soit équilibrée. Pour cela, vous devez placer une deuxième copie de DB1 sur Server2, une deuxième copie de DB5 sur Server3 et une deuxième copie de DB9 sur Server4. À partir de DB13, vous répétez simplement ce modèle. Les copies de bases de données restantes sont ajoutées en diagonale, comme illustré par l’image ci-dessous.

Positionnement des copies de bases de données pour une répartition équilibrée

Notez que le second bloc de construction de niveau 2 (DB13 à DB20) contient uniquement 8 bases de données, pas 12. Par conséquent, cette conception ne sera pas complètement symétrique en cas de défaillance unique. Pour obtenir une distribution totalement symétrique, planifiez votre architecture pour que le nombre de bases de données soit un multiple de la taille de bloc de construction la plus grande. (Dans cet exemple, les nombres optimaux sont 24, 36, 48 ou 60 bases de données, etc.)

Si vous ajoutez une troisième copie de base de données, vous devez la placer différemment pour chaque groupe de N × (N – 1) bases de données. Étant donné qu’il ne vous reste plus que N – 2 serveurs disponibles pour le positionnement de la troisième copie de base de données, cela génère N – 2 variations. Le nouveau bloc de construction (appelé « bloc de construction de niveau 3 ») présente une taille de N × (N – 1) × (N – 2) bases de données. Par conséquent, la troisième copie de base de données pour la première base de données est placée sur le troisième serveur, puis chacune des troisièmes copies de bases de données est déployée en diagonale par rapport à la position de départ au sein de ce nouveau bloc de construction. Une fois le modèle appliqué pour le premier bloc de construction de niveau 1, la position de départ est décalée d’un cran de sorte que la troisième copie est placée en quatrième position.

Dans cet exemple, la taille du bloc de construction devient donc 4 × (4 – 1) × (4 – 2) = 4 × 3 × 2 = 24, ce qui signifie que 24 bases de données composent chaque bloc de construction de niveau 3. Pour respecter le modèle de positionnement de bases de données symétrique, placez la troisième copie de DB1 sur Server3 (qui est le premier serveur disponible car Server1 héberge la première copie et Server2 héberge la deuxième copie), puis décalez chaque copie supplémentaire d’un cran jusqu’à ce que vous atteigniez la fin du premier bloc de construction de niveau 1. Pour le bloc de construction suivant, là encore, placez la troisième copie de base de données sur le serveur disponible suivant (Server4) et continuez ainsi jusqu’à atteindre DB12, qui marque la fin du premier bloc de construction de niveau 2. Pour les bases de données DB13 à DB20, suivez le même modèle, mais décalez le positionnement de la troisième copie d’un cran pour qu’elle ne se trouve pas sur les mêmes serveurs que la troisième copie des bases de données DB1 à DB12.

Disposition équilibrée avec trois copies de bases de données et quatre serveurs

Là encore, pour mieux comprendre cette logique, comparons le positionnement des copies pour les bases de données DB1 à DB13. La copie active de ces bases de données est hébergée sur Server1 et la deuxième copie de base de données est hébergée sur Server2. Si ces serveurs connaissent une défaillance, vous souhaitez que les troisièmes copies des bases de données soient activées sur les différents serveurs restants afin que la distribution de la charge soit équilibrée. Pour cela, placez la troisième copie de DB1 sur Server3 et la troisième copie de DB13 sur Server4. Des paires similaires sont formées par DB2 et DB14, DB3 et DB15, etc. À partir de DB25, il vous suffit de répéter ce modèle (cet exemple n’illustre pas autant de bases de données).

Notez que le bloc de construction de niveau 3 (DB1 à DB20) contient uniquement 20 bases de données, pas 24. Par conséquent, cette conception ne sera pas complètement symétrique en cas de double défaillance. Là encore, pour obtenir une distribution totalement symétrique, planifiez votre architecture pour que le nombre de bases de données soit un multiple de la taille de bloc de construction la plus grande. (Dans cet exemple, les nombres optimaux sont 24, 48 ou 72 bases de données, etc.)

Si vous ajoutez une quatrième copie de base de données, vous devez la placer différemment pour chaque groupe de N × (N – 1) × (N – 2) bases de données. Le nouveau bloc de construction présente alors N × (N – 1) × (N – 2) × (N – 3) bases de données. La même approche logique est appliquée et garantit l’équilibre de la distribution des bases de données au sein du nouveau bloc de construction en cas de défaillance de trois serveurs.

Cet exemple de quatre serveurs ne laisse place qu’à une variation pour le positionnement de la quatrième copie de base de données (car il ne reste qu’un serveur). Par conséquent, la taille de bloc de construction reste effectivement à 24, comme l’illustre la formule correspondante : 4 × 3 × 2 × (4 – 3) = 4 × 3 × 2 × 1 = 24.

Si vous continuez à ajouter des copies de bases de données, la taille du bloc de construction augmente de sorte que la formule générale de la taille de bloc de construction est Perm(N,M) = N × (N – 1) … (N – M + 1) = N!/(N – M)! = CNMM!, où N = nombre de serveurs et M = nombre de copies de bases de données. Cela devient évident lorsque vous réalisez que vous atteignez une distribution complète et symétrique des copies de bases de données en sélectionnant toutes les permutations possibles de M copies de bases de données à travers N serveurs disponibles.

Cette méthodologie a toutefois ses limites :

• Le déploiement d’un nombre de bases de données qui ne serait pas un multiple de la plus grande taille de bloc de construction résulte en une distribution asymétrique des bases de données actives en cas de défaillance.

• Le déploiement d’architectures visant à limiter les défaillances de domaines multiples peut résulter en une distribution asymétrique des bases de données actives en cas de défaillance. En effet, les définitions des domaines de défaillance imposent des restrictions sur le positionnement des copies de bases de données, qui cassent la symétrie du modèle.

• Le déploiement de solutions à résilience de site générant des événements de basculements de bases de données hors site peut résulter en une distribution asymétrique des bases de données activées dans le centre de données secondaire au cours d’événements de défaillance de serveur du centre de données principal.

Retour au début

Distribution des bases de données actives dans l’exemple de scénario au cours de défaillances de serveur

En reprenant l’exemple précédent, en cas de défaillance d’un serveur (par exemple, Server4), les bases de données de boîtes aux lettres actives sont distribuées comme illustré par l’image ci-dessous. La deuxième copie est activée pour DB4, DB8, DB12, DB16 et DB20, comme l’indique la mention Active en orange.

Distribution des copies de bases de données actives après défaillance d’un serveur

En cas de double défaillance de serveur (la troisième copie est activée pour plusieurs bases de données, comme l’indique la mention Active en vert), les deux serveurs restants, Server1 et Server3, présenteront un nombre égal de bases de données de boîtes aux lettres activées.

Distribution des copies de bases de données actives après double défaillance de serveur

Toutefois, étant donné que le nombre de bases de données de cet exemple n’est pas un multiple de la plus grande taille de bloc de construction (24 bases de données), certains événements de double défaillance de serveur ne résulteront pas en une distribution symétrique.

Distribution des copies de bases de données actives après une autre double défaillance de serveur

Retour au début

Scénarios de conception

Pour comprendre le principe de conception de la disposition des copies de bases de données, y compris la formule mathématique associée, prenons deux autres dispositions architecturales.

Scénario de conception : Solution à résilience de site avec distribution des utilisateurs actifs/passifs

Dans ce scénario, Contoso décide de déployer l’architecture suivante :

• Le groupe de disponibilité de base de données (DAG) est étendu sur deux centres de données fonctionnant selon un modèle de distribution des utilisateurs actifs/passifs.

• Chaque serveur est déployé dans un rack de serveurs distinct.

• La solution de stockage de chaque serveur est isolée de celle des autres serveurs du centre de données.

• Il y a quatre serveurs de boîtes aux lettres par centre de données.

• Il y a 24 bases de données de boîtes aux lettres au total.

• L’objectif est d’avoir quatre copies de bases de données à haut niveau de disponibilité pour résister à une double défaillance de serveur ou à la défaillance d’un centre de données.

Dans cet exemple, le bloc de construction de niveau 1 est égal à 4, les bases de données sont regroupées par quatre et les copies actives sont réparties sur les quatre serveurs du bloc de construction.

Distribution équilibrée de la première copie à travers un bloc de construction

Pour chaque serveur hébergeant des copies actives, la deuxième copie est distribuée aussi équitablement que possible à travers l’ensemble des serveurs membres restants, en respectant un modèle en diagonale puisque chaque copie est isolée des autres. Dans cet exemple, le bloc de construction de niveau 2 est égal à 12 et se répète toutes les 12 bases de données.

Distribution équilibrée de la deuxième copie à travers un bloc de construction

Étant donné que cette solution à résilience de site est destinée à un modèle de distribution d’utilisateurs actifs/passifs avec un nombre égal de serveurs et de copies de bases de données dans les deux centres de données, la troisième copie de base de données est placée en diagonale à travers Server5 et Server6, d’après une valeur de bloc de construction de niveau 1 égale à 4. Cela garantit la mise en miroir de Server5 et Server6 par rapport au positionnement de la première copie de base de données sur les serveurs Server1 à Server4.

Distribution équilibrée d’une troisième copie à travers le second bloc de construction

Étant donné que cette solution à résilience de site est destinée à un modèle de distribution d’utilisateurs actifs/passifs avec un nombre égal de serveurs et de copies de bases de données dans les deux centres de données, la quatrième copie de base de données est placée en diagonale à travers Server5 et Server6, d’après une valeur de bloc de construction de niveau 2 égale à 12. Cela garantit la mise en miroir de Server5 et Server6 par rapport au positionnement de la deuxième copie de base de données sur les serveurs Server1 à Server4.

Distribution équilibrée d’une quatrième copie à travers le second bloc de construction

En cas de défaillance de serveur, les trois serveurs restants du centre de données principal présenteront un nombre égal de bases de données de boîtes aux lettres activées (8 par serveur).

Distribution des copies de bases de données actives après défaillance d’un serveur

En cas de double défaillance de serveur, les deux serveurs restants du centre de données principal présenteront un nombre égal de bases de données de boîtes aux lettres activées (10 par serveur), tandis que 4 bases de données seront activées dans le centre de données secondaire.

Distribution des copies de bases de données actives après une double défaillance de serveur

Scénario de conception : Plusieurs domaines de défaillance

Dans cet exemple, Wingtip Toys décide de déployer l’architecture suivante :

• Tous les serveurs sont déployés dans un seul centre de données.

• Les serveurs sont regroupés par trois.

• Chacun des trois serveurs est placé dans le même rack avec sa solution de stockage.

• Il y a 3 racks au total, soit 9 serveurs.

• Il y a 18 bases de données de boîtes aux lettres au total.

• L’objectif est d’avoir trois copies de bases de données à haut niveau de disponibilité pour résister à la défaillance de deux serveurs membres ou à la défaillance d’un rack.

Dans cet exemple, le bloc de construction de niveau 1 est égal à 6, les bases de données sont regroupées par 6 et les copies actives sont réparties sur les six serveurs du bloc de construction.

Disposition des copies de bases de données pour le bloc de construction de niveau 1

Pour chaque serveur hébergeant des copies actives, la deuxième copie de base de données est répartie aussi équitablement que possible sur les serveurs membres restants, tout en garantissant que deux copies de la même base de données ne soient pas placées dans le même rack de serveurs. Dans cet exemple, à la place de la formule N × (N – 1) de bloc de construction de niveau 2, la formule N × (N – 2) est utilisée pour garantir que deux copies de la même base de données ne soient pas placées dans le même rack. Cela signifie que le bloc de construction de niveau 2 est égal à 6 × 4 = 24.

Disposition des premières et deuxièmes copies de bases de données

La troisième copie de base de données est placée en diagonale à travers les serveurs, là encore pour garantir que plusieurs copies de la même base de données ne soient pas placées dans le même rack de serveurs. Dans cet exemple, à la place de la formule N × (N – 2) de bloc de construction de niveau 3, la formule N × (N – 2) × (N – 4) est utilisée pour garantir que deux copies de la même base de données ne soient pas placées dans le même rack. Cela signifie que le bloc de construction de niveau 3 est égal à 6 × 4 x 2 = 48.

Disposition des premières, deuxièmes et troisièmes copies de bases de données

En cas de défaillance de serveur, les cinq serveurs restants du centre de données principal présenteront un nombre à peu près égal de bases de données de boîtes aux lettres activées. Quatre serveurs auront 10 bases de données activées par serveur, tandis qu’un serveur (le partenaire rack de celui en panne) aura 8 bases de données activées.

Disposition et nombre de bases de données actives après une défaillance de serveur

Si deux défaillances de serveurs surviennent en même temps (dans différents racks), les quatre serveurs restants auront un nombre à peu près égal de bases de données de boîtes aux lettres activées.

Disposition et nombre de bases de données actives après une double défaillance de serveur (dans différents racks)

Si deux défaillances de serveurs surviennent en même temps (dans le même rack), les quatre serveurs restants auront un nombre égal de bases de données de boîtes aux lettres activées.

Disposition et nombre de bases de données actives après une double défaillance de serveur (dans le même rack)

Retour au début

 © 2010 Microsoft Corporation. Tous droits réservés.