Chapitre 3 Architecture Sun Cluster
L'architecture Sun Cluster permet à un groupe de systèmes d'être déployé, géré et affiché comme un grand système unique.
Ce chapitre comprend les rubriques suivantes :
Environnement matériel de Sun Cluster
Un cluster est formé des composants matériels suivants :
-
Les noeuds de cluster avec disques locaux (non partagés) fournissent la plate-forme principale du cluster.
-
Le stockage multihôte fournit des disques partagés entre des noeuds.
-
Les médias amovibles sont configurés comme des périphériques globaux, comme des bandes ou des CD-ROM.
-
L'interconnexion de cluster offre un canal de communication entre les noeuds.
-
Les interfaces de réseau public activent les interfaces réseau utilisées par les systèmes client pour accéder aux services de données sur le cluster.
La Figure 3–1 illustre la manière dont les composants matériels fonctionnent ensemble.
Figure 3–1 Composants matériels de Sun Cluster
Environnement logiciel de Sun Cluster
Pour fonctionner comme un membre du cluster, un noeud doit être équipé des logiciels suivants :
-
logiciel Solaris ;
-
logiciel Sun Cluster ;
-
application de service de données ;
-
gestion du volume (SolarisTM Volume Manager ou VERITAS Volume Manager).
La configuration utilisant la gestion du volume constitue une exception. Cette configuration peut se passer d'un logiciel de gestion du volume.
La Figure 3–2 indique une vue de haut niveau des composants logiciels fonctionnant ensemble pour créer l'environnement logiciel de Sun Cluster.
Figure 3–2 Architecture logicielle de Sun Cluster
Moniteur d'appartenance au cluster
Pour assurer que les données ne s'altèrent pas, tous les noeuds doivent arriver à un accord cohérent sur l'appartenance au cluster. Si nécessaire, le moniteur d'appartenance au cluster coordonne la reconfiguration des services du cluster en réponse à une panne.
Le MAC reçoit des informations sur la connectivité aux autres noeuds depuis la couche de transport du cluster. Il utilise l'interconnexion du cluster pour échanger des informations d'état au cours d'une reconfiguration.
Après avoir détecté une modification d'appartenance au cluster, le MAC effectue une configuration synchronisée du cluster. Dans cette configuration, les ressources du cluster peuvent être redistribuées, en fonction de la nouvelle appartenance au cluster.
Le MAC s'exécute entièrement dans le noyau.
CCR (Cluster Configuration Repository)
Le CCR s'appuie sur le moniteur d'appartenance pour garantir qu'un cluster ne fonctionne que si un quorum a été atteint. Il est chargé de vérifier la cohérence des données au sein du cluster, d'effectuer des récupérations lorsque nécessaire et de faciliter les mises à jour des données.
Systèmes de fichiers de cluster
Un système de fichiers de cluster est un proxy entre les éléments suivants :
-
le noyau sur un noeud et le système de fichiers sous-jacent ;
-
le gestionnaire de volumes s'exécutant sur un noeud ayant une connexion physique vers le ou les disques.
Les systèmes de fichiers de cluster dépendent des périphériques globaux (disques, bandes, CD-ROM). Les périphériques globaux sont accessibles à partir de n'importe quel noeud du cluster à travers le même nom de fichier (par exemple, /dev/global/). Ce noeud n'a pas besoin de connexion physique au périphérique de stockage. Vous pouvez utiliser un périphérique global comme un périphérique normal, c'est-à-dire que vous pouvez créer un système de fichiers sur le périphérique global à l'aide de newfs ou mkfs.
Le système de fichiers de cluster possède les caractéristiques suivantes :
-
Les emplacements d'accès aux fichiers sont transparents. Un processus peut ouvrir un fichier situé n'importe où sur le système. De même, les processus sur tous les noeuds peuvent utiliser le même nom de chemin pour localiser un fichier.
Remarque :lorsqu'un système de fichiers de cluster lit des fichiers, il ne met pas à jour l'horaire d'accès sur ces fichiers.
-
Des protocoles de cohérence sont utilisés pour préserver la sémantique d'accès aux fichiers UNIX même lorsqu'on accède au fichier simultanément à partir de plusieurs noeuds.
-
La mise en mémoire cache extensive est utilisée avec des mouvements d'entrée/sortie de masse sans copie pour déplacer les données des fichiers de manière efficace.
-
Le système de fichiers d'un cluster fournit des fonctionnalités de verrouillage de fichiers informatif hautement disponible par le biais des interfaces fcntl(2). Les applications exécutées sur plusieurs noeuds peuvent synchroniser l'accès aux données en utilisant le verrouillage de fichiers informatif sur le fichier d'un système de fichiers du cluster. Les verrous de fichiers sont immédiatement récupérés à partir de noeuds quittant le cluster ou d’applications échouant au verrouillage.
-
L'accès aux données est assuré en continu, même en cas de pannes. Les applications ne sont pas affectées par les pannes tant qu'un chemin d'accès aux disques demeure opérationnel. Cette garantie est aussi valable pour l'accès aux disques bruts et pour toutes les opérations du système de fichiers.
-
Les systèmes de fichiers de cluster sont indépendants du système de fichiers sous-jacent et du logiciel de gestion du volume. Les systèmes de fichiers de cluster rendent global tout système de fichiers sur disque pris en charge.
Services de données évolutifs
La mise en réseau du cluster a pour premier objectif de fournir des services de données évolutifs. L'évolutivité signifie qu'en dépit de l'accroissement de la charge offerte à un service, celui-ci peut maintenir un temps de réponse constant, grâce à l'ajout de nouveaux noeuds au cluster et à l'exécution de nouvelles instances de serveur. Un service Web est un bon exemple de ce type de service. Un service de données est généralement composé de plusieurs instances tournant chacune sur des noeuds différents du cluster. Ensemble, ces instances se comportent comme un service unique face à un client distant de ce service et implémentent la fonctionnalité de ce service. Dans un service Web évolutif avec plusieurs démons httpd s'exécutant sur différents noeuds, n'importe quel démon peut servir la requête d'un client. Le démon servant la requête dépend d'une règle d'équilibrage de la charge. La réponse au client semble venir du service, et non du démon servant la requête, ce qui préserve l'apparence d'un service unique.
La figure suivante représente l'architecture d'un service de données évolutif :
Figure 3–3 Architecture d'un service de données évolutif
Les noeuds n'hébergeant pas l'interface globale (noeuds proxy) hébergent l'adresse partagée sur leur interface de bouclage. Les paquets arrivant dans l'interface globale sont distribués à d'autres noeuds de cluster, en fonction de règles d'équilibrage de la charge configurables. Les différentes règles d'équilibrage de la charge sont décrites ci-dessous.
Règles d'équilibrage de la charge
L'équilibrage de la charge permet d'améliorer les performances du service évolutif, tant en matière de temps de réponse que de rendement.
Il existe deux sortes de services de données évolutifs : les services purs et sticky. Sur un service pur, n'importe quelle instance peut répondre aux requêtes du client. Sur un service sticky, le cluster équilibre la charge des requêtes au noeud. Ces requêtes ne sont pas redirigées vers d'autres instances.
Un service pur utilise une règle d'équilibrage de la charge pondérée. Sous cette règle, les requêtes du client sont réparties de manière uniforme entre les instances de serveur du cluster. Par exemple, dans un cluster à trois noeuds où chaque noeud a le poids 1, chaque noeud traite un tiers des requêtes de n'importe quel client pour le service. Les poids peuvent être modifiés à tout moment grâce à l'interface de commande scrgadm(1M) ou à l'IUG SunPlex Manager.
Il y a deux types de services sticky : les sticky ordinaires et les sticky jocker. Les services sticky permettent à plusieurs sessions d'application simultanées utilisant plusieurs connexions TCP de partager la mémoire d'état (état de la session d'application).
Les services sticky ordinaires permettent à un client de partager l'état entre plusieurs connections TCP simultanées. Le client est dit « sticky » envers l'instance de serveur écoutant sur un port unique. Le client a la garantie que toutes ses requêtes vont vers la même instance de serveur, sous réserve que cette instance soit active et accessible et que la règle d'équilibrage de la charge ne soit pas modifiée alors que le service est en ligne.
Les services sticky joker utilisent des numéros de ports assignés de manière dynamique, mais attendent toujours des requêtes du client qu'elles aillent vers le même noeud. Le client est dit « sticky joker » sur les ports par rapport à la même adresse IP.
Stockage sur disques multihôtes
Le logiciel Sun Cluster rend les disques hautement disponibles en utilisant un stockage sur disques multihôtes, pouvant être connecté à plus d'un noeud à la fois. Le logiciel de gestion du volume peut être utilisé pour organiser ces disques dans un emplacement de stockage partagé géré par un noeud du cluster. Les disques sont ensuite configurés pour passer à un autre noeud en cas de panne. L'utilisation de disques multihôtes dans les systèmes Sun Cluster offre de nombreux avantages, notamment :
-
l'accès global aux systèmes de fichiers ;
-
les chemins d'accès multiples aux systèmes de fichiers et aux données ;
-
la tolérance aux pannes de noeuds uniques.
Interconnexion de cluster
Tous les noeuds doivent être connectés par l'interconnexion de cluster via au moins deux réseaux ou chemins d'accès redondants physiquement indépendants, afin d'éviter un point de panne unique. Alors que deux interconnexions sont requises pour la redondance, l'expansion du traffic peut en utiliser jusqu'à six afin d'éviter les goulots d'étranglement et améliorer la redondance et l'évolutivité. L'interconnexion de Sun Cluster utilise Fast Ethernet, Gigabit-Ethernet, Sun Fire Link ou l'interface SCI (SCI, IEEE 1596-1992), pour permettre des communications privées de cluster de haute performance.
Dans les environnements clustérisés, les interconnexions et protocoles à grande vitesse et faible latence sont essentiels pour les communications entre les noeuds. L'interconnexion SCI dans les systèmes Sun Cluster améliore les performances sur les cartes d'interface réseau typiques (NIC). Sun Cluster utilise l'interface RSM (RSMTM) pour la communication internodale sur un réseau Sun Fire Link. La RSM est une interface de messagerie Sun, extrêmement efficace pour les opérations de mémoire à distance.
L'interconnexion de cluster se compose des éléments matériels suivants :
-
Adaptateurs : cartes d'interface réseau résidant sur chaque noeud de cluster. Un adaptateur réseau à plusieurs interfaces peut entraîner un point de panne unique s'il tombe en panne.
-
Jonctions : commutateurs résidant hors des noeuds du cluster. Ils remplissent des fonctions d'intercommunication et de commutation vous permettant de connecter plus de deux noeuds entre eux. Dans un cluster à deux noeuds, vous n'avez pas besoin de jonction, car les noeuds peuvent être directement connectés entre eux à l'aide de câbles physiques redondants. Ces câbles redondants sont connectés à des adaptateurs redondants sur chaque noeud. Les configurations à plus de deux noeuds requièrent des jonctions.
-
Câbles : connexions physiques placées entre deux adaptateurs réseau ou entre un adaptateur et une jonction.
La Figure 3–4 indique comment sont connectés les trois composants.
Figure 3–4 Interconnexion de cluster
Groupes de multiacheminement sur réseau IP
Les adaptateurs de réseau public sont organisés en groupes IPMP (groupes de multiacheminement). Chaque groupe de multiacheminement possède un ou plusieurs adaptateurs de réseau public. Chaque adaptateur d'un groupe de multiacheminement peut être actif. Vous pouvez aussi configurer des interfaces de réserve demeurant inactives jusqu'au moment d'un basculement.
Les groupes de multiacheminement offrent la base des ressources de nom d'hôte logique et d'adresse partagée. Sur un noeud, le même groupe de multiacheminement peut héberger un nombre indéfini de ressources de nom d'hôte logique ou d'adresse partagée. Pour contrôler la connectivité de réseau public des noeuds du cluster, vous pouvez créer un multiacheminement.
Pour plus d'informations sur les ressources de nom logique et d'adresse partagée, reportez-vous au document Sun Cluster Data Services Planning and Administration Guide for Solaris OS.
Interfaces de réseau public
Les clients se connectent au cluster via des interfaces de réseau public. Chaque carte d'adaptateur réseau peut être connectée à un ou plusieurs réseaux publics, selon si elle possède plusieurs interfaces matérielles ou non. Vous pouvez définir des noeuds pour qu'ils prennent en charge plusieurs cartes d'interfaces de réseau public configurées de façon à ce qu'elles soient toutes actives, et puissent ainsi se servir mutuellement de sauvegarde en cas de basculement. En cas de défaillance d'un des adaptateurs, le logiciel Solaris de multiacheminement sur réseau IP sur Sun Cluster est invoqué pour effectuer le basculement de l'interface défaillante vers un autre adaptateur dans le groupe.
- © 2010, Oracle Corporation and/or its affiliates