Chapitre 3 Architecture Sun Cluster

L'architecture Sun Cluster permet de déployer, de gérer et d'afficher un groupe de systèmes comme un grand système unique.

Ce chapitre se compose des sections suivantes

• Environnement matériel de Sun Cluster

• Environnement logiciel de Sun Cluster

• Services de données évolutifs

• Stockage sur disques multihôtes

• Interconnexion de cluster

• Groupes de multiacheminement sur réseau IP

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 nœuds.

• 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 représente les relations entre les composants matériels.

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 (Solaris^TM 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 fournit une représentation fonctionnelle des composants logiciels constituant 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 nœuds doivent arriver à un accord cohérent sur l'appartenance au cluster. Si nécessaire, le CMM 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 CMM 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 CMM s'exécute entièrement dans le noyau.

Référentiel de configuration du cluster (CCR)

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 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 nœud 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 nœud du cluster à travers le même nom de fichier (par exemple, /dev/global/). Ce nœud 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 nœuds.

• 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 nœuds 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é, 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 de volumes. Les systèmes de fichiers de cluster rendent globaux tous les systèmes de fichiers sur les disques 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 nœuds 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 nœuds 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 nœuds, 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 nœuds n'hébergeant pas l'interface globale (nœuds proxy) hébergent l'adresse partagée sur leur interface de bouclage. Les paquets arrivant dans l'interface globale sont distribués à d'autres nœuds 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 : pur 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 nœud. Ces dernières 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 nœuds où chaque nœud a le poids 1, chaque nœud 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'interface graphique Gestionnaire SunPlex.

Il y a deux types de services sticky : sticky ordinaire et sticky joker. 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 du 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 et associé à 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 nœud du cluster. Les disques sont ensuite configurés pour passer à un autre nœud 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 nœuds 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, InfiniBand, 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 nœuds. 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 Remote Shared Memory (RSM^TM) 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.

Le pilote RSM Reliable Datagram Transport (RSMRDT) se compose d'un pilote créé sur l'API RSM et d'une bibliothèque qui exporte l'interface API RSMRDT. Ce pilote fournit des performances améliorées Oracle Parallel Server/Real Application Clusters. Les fonctions d'équilibrage de charge et de haute disponibilité sont également améliorées car étant fournies directement avec le pilote, elles sont disponibles de manière transparente pour les clients.

L'interconnexion de cluster se compose des éléments matériels suivants :

• Adaptateurs : cartes d'interface réseau résidant sur chaque nœud 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 à l'extérieur des nœuds de cluster. Ils remplissent des fonctions d'intercommunication et de commutation vous permettant de connecter plus de deux nœuds entre eux. Dans un cluster à deux nœuds, vous n'avez pas besoin de jonction, car les nœuds 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 nœud. Les configurations à plus de deux noeuds requièrent des jonctions.

• Câbles : connexions placées entre deux adaptateurs réseau ou entre un adaptateur et une jonction.

La Figure 3–4 représente l'interconnexion des 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 multi-acheminement 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 fournissent à 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 d'hôte logique et d'adresse partagée, reportez-vous au manuel 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 nœuds 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.