Identification des stratégies de disponibilité

Lors de l'établissement d'une stratégie relative aux exigences de disponibilité, examinez les interactions entre composants et l'analyse d'utilisation pour identifier les solutions de disponibilité à envisager. Effectuez cette analyse composant par composant pour trouver la solution répondant le mieux aux exigences de disponibilité et de basculement.

Vous pouvez par exemple vous poser les questions suivantes pour mettre en place votre stratégie de disponibilité :

• Quel est le degré de disponibilité spécifié (quatre ou cinq neuf, par exemple) ?

• Quelles sont les spécifications de performances en cas de basculement (50 %, par exemple) ?

• L'analyse d'utilisation identifie-t-elle des périodes d'utilisation de pointe ?

• Quelles sont les considérations géographiques à prendre en compte ?

La stratégie de disponibilité choisie doit également tenir compte des exigences en termes d'entretien (voir section Conception pour une utilisation optimale des ressources). Évitez les solutions complexes exigeant des efforts de maintenance et d'administration importants.

Stratégies de disponibilité

Les stratégies de disponibilité possibles pour les déploiements Java Enterprise System sont les suivantes :

• Équilibrage de charge : utilisez des composants matériels et logiciels redondants pour répartir la charge de traitement. Un équilibreur de charge dirige une demande de service vers une des instances symétriques de ce service. Si une instance échoue, les autres peuvent assumer sa charge de travail.

• Basculement : implique la gestion de matériels et de logiciels redondants afin que l'accès aux services et que la sécurité des données essentielles ne soient pas compromis en cas de problème lié à un composant.

  Le logiciel Sun Cluster propose une solution de basculement pour les données essentielles gérées par des composants d'arrière-plan tels la mémoire des messages pour Messaging Server et les données de calendrier pour Calendar Server.

• Réplication des services : cette fonction fournit plusieurs sources d'accès aux même données. Directory Server propose de nombreuses stratégies de réplication et de synchronisation pour l'accès aux annuaires LDAP.

Les sections ci-après décrivent des exemples de solutions de disponibilité fournissant divers niveaux d'équilibrage de charge, de basculement et de réplication des services.

Système à serveur unique

Toutes les ressources de traitement d'un service sont placées sur un seul serveur. Si ce dernier tombe en panne, le service ne peut plus fonctionner.

Figure 5–2 Système à serveur unique

Sun fournit des serveurs haut de gamme permettant de bénéficier des avantages suivants :

• remplacement et reconfiguration des composants matériels en cours d'exécution du système ;

• possibilité d'exécuter plusieurs applications dans des domaines sécurisés sur le serveur ;

• possibilité de mettre à niveau la capacité, les performances et la configuration des E/S sans redémarrer le système.

Un serveur haut de gamme coûte généralement plus cher qu'un système multiserveur comparable. Toutefois, il se révèle plus économique en termes d'administration, de contrôle et d'hébergement. Les systèmes multiserveurs offrent une plus grande souplesse en termes d'équilibrage de charge, de basculement et de suppression de points de panne uniques.

Systèmes à redondance horizontale

Les serveurs redondants parallèles offrant des fonctions d'équilibrage de charge et de basculement, ils permettent d'améliorer la disponibilité de plusieurs façons. Le schéma ci-dessous montre deux serveurs répliqués constituant un système à basculement N+1. Dans ce type de système, un serveur supplémentaire est destiné à assumer 100 % de la charge en cas de panne de l'autre serveur.

Figure 5–3 Système à basculement N+1 avec deux serveurs

La puissance de traitement de chaque serveur dans des Systèmes à redondance horizontale (voir ci-dessus) est identique. Un serveur peut à lui seul satisfaire les exigences de performances. L'autre serveur offre exactement les mêmes performances lorsqu'il est utilisé en tant que serveur de rechange.

Dans ce type de conception, 100% des performances sont assurées en cas de basculement. En revanche, les investissements matériels élevés sans amélioration des performances (puisque l'un des serveurs est utilisé en cas de basculement uniquement) représentent un inconvénient majeur.

Le schéma suivant illustre un système mettant en œuvre l'équilibrage de charge et le basculement, et répartissant les performances entre deux serveurs.

Figure 5–4 Équilibrage de charge et basculement entre deux serveurs

Dans le système représenté à la section Systèmes à redondance horizontale, si un serveur tombe en panne, tous les services restent disponibles, mais pas à 100 %. En effet, le second serveur comporte six CPU qui permettent de prendre en charge 60 % de la charge totale (10 CPU).

Cette conception offre l'avantage d'autoriser une capacité latente (deux CPU) lorsque les deux serveurs sont disponibles.

Le schéma ci-dessous illustre une répartition des performances et de l'équilibrage de charge entre plusieurs serveurs.

Figure 5–5 Répartition de la charge entre n serveurs

La conception illustrée à la section Systèmes à redondance horizontale comportant cinq serveurs, si l'un d'eux tombe en panne, les autres fournissent un total de huit CPU, soit 80 % des exigences de performances (10 CPU). Si vous ajoutez un serveur doté de deux CPU, vous obtenez une conception N+1. En cas de panne de l'un des serveurs, 100 % des performances sont maintenues grâce aux autres serveurs.

Cette solution offre les avantages suivants :

• performance accrue en cas de panne d'un serveur ;

• disponibilité même en cas de panne de plusieurs serveurs ;

• possibilité de mettre les serveurs hors service pour la maintenance et les mises à niveau ;

• dépenses réduites, car plusieurs serveurs d'entrée de gamme coûtent moins cher qu'un seul serveur haut de gamme.

Toutefois, plus le nombre de serveurs augmente, plus les coûts d'administration et de maintenance sont élevés, sans compter les frais d'hébergement des serveurs dans un centre de données. De plus, il arrive un moment où l'ajout de serveurs finit par entraîner plus d'inconvénients que d'avantages.

Logiciel Sun Cluster

Dans les situations exigeant un degré élevé de disponibilité (quatre ou cinq neuf), vous pouvez envisager d'intégrer le logiciel Sun Cluster dans votre conception de déploiement. Un cluster associe des serveurs redondants à des ressources de stockage et d'autres ressources réseau. Les serveurs d'un cluster sont en communication permanente les uns avec les autres. En cas de mise hors ligne d'un serveur, les autres dispositifs du cluster l'isolent et font basculer les applications ou les données du nœud en panne vers un autre nœud. Le basculement s'effectue rapidement sans que les utilisateurs du système aient à subir une longue interruption des services.

Sun Cluster exige du matériel supplémentaire spécialisé et des connaissances particulières en matière de configuration, d'administration et de maintenance.

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.