Exemples de conceptions de disponibilité

Cette section présente deux exemples de stratégies de disponibilité appliqués à une solution de communications basées sur les identités pour une entreprise de taille moyenne de 1 000 à 5 000 salariés, tel que décrit dans la section Exemple de communications basées sur les identités. La première stratégie illustre l'équilibrage de charge pour Messaging Server. La seconde illustre une solution de basculement faisant appel au logiciel Sun Cluster.

Exemple d'équilibrage de charge pour Messaging Server

Le tableau ci-dessous présente le nombre de CPU requises estimé pour chaque composant logique de Messaging Server dans l'architecture logique. Il reprend l'estimation finale calculée dans la section Mise à jour du nombre de CPU estimé .

Tableau 5–6 Ajustement de l'estimation du nombre de CPU pour les composants de support

Composant	Nombre de CPU	Mémoire
Messaging Server (MTA, entrant)	2	4 Go
Messaging Server (MTA, sortant)	2	4 Go
Messaging Server (MMP)	2	4 Go
Messaging Server (Message Store)	2	4 Go

Pour cet exemple, supposons qu'au cours de la phase de spécification technique, les exigences de qualité de service suivantes aient été formulées :

• Disponibilité : la disponibilité globale du système doit être de 99,99% (hors périodes d'indisponibilité planifiées). Une panne d'un seul système ne doit pas entraîner d'interruption des services.

• Évolutivité : aucun serveur ne doit être utilisé à plus de 80% au cours des périodes de charge de pointe et le système doit pouvoir assumer une croissance à long terme de 10% par an.

Pour répondre aux exigences de disponibilité, prévoyez deux instances de chaque composant de Messaging Server, une sur chaque serveur. Si un serveur ou un composant ne fonctionne plus, l'autre le remplace. Le schéma ci-dessous présente un diagramme du réseau correspondant à cette stratégie de disponibilité.

Sur le schéma ci-dessus, le nombre de CPU a doublé par rapport à l'estimation initiale. Cette augmentation est intervenue pour les raisons suivantes :

• En cas de panne d'un serveur, l'autre fournit la puissance de traitement nécessaire à la gestion de la charge.

• La puissance de traitement supplémentaire fournit la marge de sécurité nécessaire pour répondre à l'exigence selon laquelle aucun serveur ne doit être utilisé à plus de 80% au cours des périodes de charge de pointe.

• En ce qui concerne l'exigence d'évolutivité impliquant une croissance annuelle de la charge de 10%, la puissance de traitement supplémentaire permet d'ajouter la capacité latente requise.

Exemple de basculement à l'aide du logiciel Sun Cluster

Le schéma ci-dessous montre un exemple de stratégie de basculement pour le composant d'arrière-plan Calendar Server et la mémoire de messages de Messaging Server. Le composant d'arrière-plan Calendar Server et la mémoire de messages sont répliqués sur des serveurs matériels différents et configurés pour le basculement à l'aide du logiciel Sun Cluster. Le nombre de CPU et la mémoire correspondante sont répliqués sur chaque serveur dans Sun Cluster.

Figure 5–6 Conception avec basculement utilisant le logiciel Sun Cluster

Exemple de réplication des services d'annuaire

Les services d'annuaire peuvent être répliqués de sorte que les transactions soient réparties sur différents serveurs, ce qui accroît la disponibilité. Directory Server fournit diverses stratégies de réplication des services, dont les suivants :

• Bases de données multiples : les différentes parties d'une arborescence d'annuaire sont stockées dans des bases de données distinctes.

• Chaînage et références : relie les données distribuées dans une même arborescence d'annuaire.

• Réplication monomaître : fournit une source centrale pour la base de données maître, qui est ensuite distribuée aux répliques consommateur.

• Réplication multimaître : répartit la base de données maître entre plusieurs serveurs. Chacun d'eux répartit ensuite sa base de données entre les répliques consommateur.

Les stratégies de disponibilité pour Directory Server sont un sujet complexe que le présent manuel ne traite pas. Les sections Réplication monomaître et Réplication multimaître fournissent une présentation générale des stratégies de réplication de base. Pour plus d'informations, reportez-vous au chapitre 12, Designing a Highly Available Deployment, dans Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide.

Réplication monomaître

Le schéma ci-dessous représente une stratégie de réplication monomaître illustrant les concepts de réplication de base.

Figure 5–7 Exemple de réplication monomaître

Dans le cadre de la réplication monomaître, une instance de Directory Server gère la base de données d'annuaire maître et consigne toutes les modifications. La base de données maître est répliquée sur un certain nombre de bases de données consommateur. Les instances consommateur de Directory Server sont optimisées pour les opérations de lecture et de recherche. Toute opération d'écriture reçue par un consommateur est renvoyée vers le maître, et celui-ci met à jour les bases de données consommateur de manière régulière.

Les avantages de la réplication monomaître sont les suivants :

• instance unique de Directory Server optimisée pour les opérations de lecture et d'écriture dans la base de données ;

• nombre quelconque d'instances consommateur de Directory Server optimisées pour les opérations de lecture et de recherche ;

• évolutivité horizontale pour les instances consommateur de Directory Server.

Réplication multimaître

Le schéma ci-dessous illustre une stratégie de réplication multimaître permettant une distribution globale des accès à l'annuaire.

Avec la réplication multimaître, une ou plusieurs instances de Directory Server gèrent la base de données d'annuaire maître. Chacun de ces maîtres dispose d'un contrat de réplication décrivant les procédures de synchronisation des bases de données maître. Chaque maître est répliqué sur un nombre quelconque de bases de données consommateur. Comme dans le cadre de la réplication monomaître, les instances consommateur de Directory Server sont optimisées pour l'accès en lecture et en recherche. Toute opération d'écriture reçue par un consommateur est renvoyée vers le maître, et celui-ci met à jour les bases de données consommateur de manière régulière.

Figure 5–8 Exemple de réplication multimaître

La stratégie de réplication multimaître présente les mêmes avantages que la réplication monomaître, auxquels vient s'ajouter une disponibilité permettant l'équilibrage de charge lors des mises à jour du maître. Vous pouvez également implémenter une stratégie de disponibilité fournissant un contrôle local des opérations d'annuaire, importante pour les entreprises utilisant des centres de données distribués.