Chapitre 4 Questions fréquemment posées

Ce chapitre donne les réponses aux questions les plus fréquemment posées sur le système Sun Cluster. Ces questions sont classées par thème.

FAQ sur la haute disponibilité

Qu'est-ce qu'un système hautement disponible ?

Le système Sun Cluster définit la haute disponibilité comme étant la capacité d'un cluster à assister l'exécution d'une application. L'application s'exécute même s'il se produit une panne qui rendrait un système serveur indisponible a priori.

Quel est le processus grâce auquel le cluster peut fournir la haute disponibilité ?

Le cluster fournit un environnement hautement disponible à travers un processus appelé basculement. Le basculement est une série d'actions exécutées par le cluster pour déplacer les ressources d'un service de données d'un noeud défectueux vers un autre noeud actif du cluster.

Quelle est la différence entre un service de données évolutif et un service de données de basculement ?

Il existe deux types de services de données hautement disponibles :

• Basculement

• Évolutif

Un service de données de basculement exécute une application sur un seul noeud principal du cluster à la fois. Les autres noeuds peuvent exécuter d'autres applications, mais chaque application ne tourne que sur un seul noeud. En cas d'échec d'un nœud principal, les applications qui s'exécutent sur ce nœud basculent sur un autre et continuent de s'exécuter.

Un service évolutif exécute une application sur plusieurs nœuds pour créer un service logique unique. Les services évolutifs utilisent tous les nœuds et processeurs du cluster sur lequel ils tournent.

Pour chaque application, un nœud héberge l'interface physique pour le cluster. Ce nœud s'appelle nœud d'interface globale (ou nœud GIF). Il peut exister plusieurs nœuds GIF dans le cluster. Chacun héberge une ou plusieurs interfaces logiques pouvant être utilisées par les services évolutifs. Ces interfaces logiques sont appelées interfaces globales. Un nœud GIF héberge une interface globale pour toutes les requêtes d'une application particulière et les distribue aux nœuds sur lesquels tourne le serveur d'application. Si le noeud GIF tombe en panne, l'interface globale bascule sur un noeud encore actif.

Si l'un des nœuds sur lequel l'application s'exécute tombe en panne, celle-ci continue de s'exécuter sur les autres nœuds, ses performances étant quelque peu réduites. Ce processus se poursuit jusqu'à ce que le nœud défectueux revienne dans le cluster.

FAQ sur les systèmes de fichiers

Puis-je exécuter un ou plusieurs des nœuds de cluster en tant que serveurs NFS hautement disponibles avec d'autres nœuds de cluster clients ?

Non, il ne faut pas faire de montage en boucle.

Puis-je utiliser un système de fichiers de cluster pour les applications qui ne sont pas sous le contrôle de Gestionnaire du groupe de ressources ?

Oui. Toutefois, sans contrôle de RGM vous devez redémarrer manuellement les applications après la panne du nœud sur lequel elles s'exécutent.

Tous les systèmes de fichiers de cluster doivent-ils posséder un point de montage dans le répertoire /global ?

Non. Toutefois, en plaçant tous les systèmes de fichiers de cluster sous le même point de montage, par exemple /global, vous en faciliterez l'organisation et la gestion.

Quelle différence y-a-t-il entre l'utilisation des systèmes de fichiers de cluster et l'exportation de systèmes de fichiers NFS ?

Il existe plusieurs différences :

1. Le système de fichiers de cluster prend en charge les périphériques globaux. NFS ne prend pas en charge l'accès distant aux périphériques.

2. Le système de fichiers de cluster a un espace de noms global. Seulement une commande de montage est requise. Avec NFS, vous devez monter le système de fichiers sur chaque noeud.

3. Le système de fichiers de cluster met en cache des fichiers plus souvent que ne le fait NFS. Par exemple, il met en cache un fichier lorsque celui-ci est utilisé par plusieurs nœuds pour des opérations de lecture, d'écriture, de verrouillage de fichiers et d'E/S asynchrones.

4. Le système de fichiers de cluster a été conçu pour exploiter les futures capacités d'interconnexion rapide du cluster apportant des fonctions de DMA distant et de zéro copie.

5. Si vous modifiez les attributs d'un fichier (par exemple, en utilisant chmod(1M)) dans un système de fichiers de cluster, la modification est immédiatement appliquée à tous les nœuds. S'il s'agit d'un système de fichiers NFS exporté, l'application de cette modification peut prendre plus de temps.

Le système de fichiers /global/.devices/node@nodeID s'affiche sur mes nœuds de cluster. Puis-je l'utiliser pour stocker des données destinées à être hautement disponibles et globales ?

Ces systèmes de fichiers stockent l'espace de noms des périphériques globaux. Ils ne sont pas destinés à une utilisation générale. Ils sont globaux, mais sans être accessibles d'une manière globale—chaque nœud accède seulement à son propre espace de noms des périphériques globaux. Si un nœud a échoué, les autres ne peuvent pas accéder à son espace de noms. Ces systèmes de fichiers ne sont pas hautement disponibles. Ils ne doivent pas être utilisés pour stocker des données accessibles globalement ou hautement disponibles.

FAQ sur la gestion des volumes

Dois-je mettre en miroir tous les périphériques de disque ?

Pour qu'un périphérique de disque soit considéré comme hautement disponible, il doit être mis en miroir ou utiliser le matériel RAID 5. Tous les services de données doivent utiliser des périphériques de disque hautement disponibles ou des systèmes de fichiers de cluster montés sur ce type de périphériques. Ces configurations peuvent supporter des pannes de disque uniques.

Puis-je utiliser deux gestionnaires de volumes différents pour les disques locaux (disque d'initialisation) et pour les disques multihôtes ?

SPARC : cette configuration est prise en charge, le logiciel Solaris Volume Manager gérant les disques locaux et VERITAS Volume Manager gérant les disques multihôtes. Aucune autre combinaison n'est prise en charge.

x86: non, cette configuration n'est pas prise en charge, car seul le logiciel Solaris Volume Manager est pris en charge sur les clusters x86.

FAQ sur les services de données

Quels sont les services de données Sun Cluster disponibles ?

La liste des services de données pris en charge figure dans Produits pris en charge du Notes de version de Sun Cluster 3.1 8/05 pour SE Solaris.

Quelles sont les versions d'application prises en charge par les services de données Sun Cluster ?

La liste des versions d'application prises en charge figure dans Produits pris en charge du Notes de version de Sun Cluster 3.1 8/05 pour SE Solaris.

Puis-je écrire mon propre service de données ?

Oui. Pour plus d'informations, voir Chapitre 11, Fonctions de l’API de la bibliothèque DSDL du Guide du développeur de services de données Sun Cluster pour SE Solaris.

Lors de la création des ressources réseau, dois-je spécifier les adresses IP numériques ou les noms d'hôtes ?

Le meilleur moyen de spécifier les ressources réseau est d'utiliser le nom d'hôte UNIX plutôt que l'adresse IP numérique.

Lors de la création de ressources réseau, quelle est la différence entre l'utilisation d'un nom d'hôte logique (ressource LogicalHostname) et l'utilisation d'une adresse partagée (ressource SharedAddress) ?

Excepté dans le cas de Sun Cluster HA pour NFS, où la documentation conseille d'utiliser une ressource LogicalHostname dans un groupe de ressources en mode Failover, vous pouvez utiliser de façon interchangeable la ressource SharedAddress ou la ressource LogicalHostname. L'utilisation d'une ressource SharedAddress implique un temps système supplémentaire car le logiciel de mise en réseau de cluster est configuré pour une ressource SharedAddress, mais pas pour une ressource LogicalHostname.

L'avantage lié à l'utilisation d'une ressource SharedAddress est manifeste si vous configurez à la fois des services de données évolutifs et de basculement et souhaitez que les clients puissent accéder à ces deux services en utilisant un même nom d'hôte. Dans ce cas, les ressources SharedAddress ainsi que la ressource d'application de basculement sont contenues dans un seul groupe de ressources. La ressource de service évolutif est contenue dans un groupe de ressources distinct et configurée pour utiliser la ressource SharedAddress. Les services évolutif et de basculement peuvent alors utiliser le même ensemble de noms d'hôte/adresses configurés dans la ressource SharedAddress.

FAQ sur les réseaux publics

Quels sont les adaptateurs de réseau public pris en charge par le système Sun Cluster ?

Actuellement, le système Sun Cluster prend en charge les adaptateurs de réseau public Ethernet (10/100BASE-T et 1000BASE-SX Gb). De nouvelles interfaces pouvant être prises en charge dans le futur, informez-vous auprès de votre représentant Sun.

Quel est le rôle de l'adresse MAC au cours d'un basculement ?

Lorsqu'un basculement se produit, de nouveaux paquets du protocole ARP (Address Resolution Protocol) sont générés et diffusés. Ils contiennent la nouvelle adresse MAC (du nouvel adaptateur physique vers lequel le nœud a basculé) et l'ancienne adresse IP. Lorsqu'une autre machine sur le réseau reçoit un de ces paquets, elle vide son cache ARP de l'ancien mappage MAC-IP et utilise le nouveau.

Le système Sun Cluster prend-il en charge la définition local-mac-address?=true ?

Oui. En fait, le multiacheminement sur réseau IP requiert la définition de local-mac-address? sur true.

Vous pouvez définir local-mac-address? sur eeprom(1M), à l'invite ok de la PROM OpenBoot dans un cluster SPARC. Vous pouvez également définir l'adresse MAC avec l'utilitaire SCSI que vous pouvez exécuter après le démarrage du BIOS sur un cluster x86.

Quel est le délai d'attente lorsque multi-acheminement sur réseau IP effectue un basculement entre les adaptateurs ?

Ce délai d'attente peut être de quelques minutes. En effet, lors d'un basculement multi-acheminement sur réseau IP, un ARP gratuit est envoyé. Toutefois, il n'est pas certain que le routeur situé entre le client et le cluster utilisera l'ARP gratuit. Ainsi, tant que le délai d'attente de l'entrée de cache ARP correspondant à cette adresse IP n'a pas expiré, l'entrée peut utiliser l'adresse MAC périmée.

Combien de temps faut-il pour détecter la panne d'un adaptateur réseau ?

Le temps de détection de la panne par défaut est de 10 secondes. L'algorithme essaie de se conformer à ce temps de détection, mais le temps réel dépend de la charge du réseau.

FAQ sur les membres de cluster

Tous les membres du cluster doivent-ils avoir le même mot de passe racine ?

Non, ce n'est pas obligatoire. Toutefois, en adoptant le même mot de passe, vous simplifierez l'administration du cluster.

L'ordre dans lequel les noeuds sont initialisés est-il important ?

Dans la plupart des cas, non. Cependant l'ordre d'initialisation est important pour empêcher l'amnésie. Par exemple, si le noeud 2 est propriétaire du périphérique de quorum et que le noeud 1 est arrêté, si vous arrêtez ensuite le noeud 2, vous devrez l'activer de nouveau avant d'activer le noeud 1. Cet ordre vous empêche d'activer par inadvertance un nœud avec des informations de configuration de cluster périmées. Pour plus d'informations sur l'amnésie, voir À propos de la séparation en cas d'échec .

Dois-je mettre en miroir les disques locaux d'un noeud du cluster ?

Oui. Bien que cette mise en miroir ne soit pas indispensable, elle empêche l'arrêt du nœud du cluster en cas de panne d'un disque non mis en miroir. Cette mise en miroir a cependant pour conséquence d'augmenter la charge d'administration du système.

Quels sont les problèmes liés à la sauvegarde des membres du cluster ?

Il existe plusieurs méthodes de sauvegarde d'un cluster. Vous pouvez disposer d'un nœud configuré comme nœud de sauvegarde, accompagné d'un lecteur de bande ou d'une bibliothèque. Le système de fichiers de cluster est ensuite utilisé pour sauvegarder les données. Ne connectez pas ce noeud aux disques partagés.

Pour plus d'informations sur la sauvegarde et la restauration des données, voir Chapitre 9, Sauvegarde et restauration d’un cluster du Guide d’administration système de Sun Cluster pour SE Solaris.

Quand un noeud est-il suffisamment sain pour être utilisé comme noeud secondaire ?

Solaris 8 et Solaris 9 :

Après une réinitialisation, un nœud est suffisamment sain pour devenir nœud secondaire lorsqu'il affiche l'invite de connexion.

Solaris:

Un nœud est suffisamment sain pour devenir un nœud secondaire lorsque le jalon multi-user-server est en cours d'exécution.

# svcs -a | grep multi-user-server:default

FAQ sur le stockage de cluster

Qu'est-ce qui rend le stockage multihôte hautement disponible ?

Il est hautement disponible, car il peut survivre à la perte d'un disque en raison de la mise en miroir (ou des contrôleurs RAID-5 basés sur le matériel). Un périphérique de stockage multihôte ayant plus d'une connexion hôte, il peut aussi résister à la perte d'un noeud auquel il est connecté. En outre, chaque noeud possède des chemins d'accès redondants vers le périphérique de stockage auquel il est relié afin de supporter les pannes des adaptateurs de bus hôtes, des câbles ou des contrôleurs de disques.

FAQ sur l'interconnexion de cluster

Quelles sont les interconnexions de cluster prises en charge par le système Sun Cluster ?

Actuellement, le système Sun Cluster prend en charge les interconnexions de cluster suivantes :

• Ethernet (100BASE-T Fast Ethernet et 1000BASE-SX Gb) sur les clusters SPARC et x86 ;

• Infiniband sur les clusters SPARC et x86 ;

• SCI uniquement sur les clusters SPARC.

Quelle est la différence entre un « câble » et un « chemin » d'accès ?

Les câbles de transport intracluster sont configurés à l'aide des adaptateurs et des commutateurs de transport. Les câbles relient les adaptateurs et les commutateurs d'un composant à l'autre. Le gestionnaire de la topologie du cluster utilise les câbles disponibles pour établir des chemins d'accès de bout en bout entre les noeuds. Un câble ne correspond pas directement à un chemin d'accès.

Les câbles sont « activés » et « désactivés » de manière statique par un administrateur. On parle « d'état » des câbles (activé ou désactivé), mais pas de « statut ». Si un câble est désactivé, c'est comme s'il n'était pas configuré. Les câbles désactivés ne peuvent pas être utilisés comme chemins d'accès. Leur état n'est pas connu puisqu'ils n'ont pas été testés. La commande scconf -p vous permet d'obtenir l'état d'un câble.

Les chemins d'accès sont définis de manière dynamique par le gestionnaire de topologie du cluster, déterminant également leur « statut ». Un chemin d'accès peut avoir le statut « en ligne » ou « hors ligne ». La commande scstat(1M) vous permet d'obtenir le statut d'un chemin d'accès.

Prenons l'exemple suivant d'un cluster à deux noeuds avec quatre câbles.

node1:adapter0      to switch1, port0
node1:adapter1      to switch2, port0
node2:adapter0      to switch1, port1
node2:adapter1      to switch2, port1

Deux chemins d'accès sont possibles à partir de ces quatre câbles.

node1:adapter0    to node2:adapter0
node2:adapter1    to node2:adapter1

FAQ sur les systèmes client

Dois-je prendre en compte certains besoins ou restrictions spécifiques au client dans le cadre de l'utilisation d'un cluster ?

Les systèmes client se connectent au cluster comme ils le feraient à tout autre serveur. En fonction de l'application du service de données, vous pouvez dans certains cas avoir à installer un logiciel client ou procéder à d'autres modifications de configuration pour que le client puisse se connecter à l'application du service de données. Pour plus d'informations sur la configuration requise côté client, voir Chapitre 1, Planning for Sun Cluster Data Services du Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

FAQ sur la console administrative

Le système Sun Cluster nécessite-t-il une console administrative ?

Oui.

La console administrative doit-elle être dédiée au cluster ou peut-elle être utilisée pour d'autres tâches ?

Le système Sun Cluster ne requiert pas de console administrative dédiée, mais si vous n'en utilisez qu'une, vous bénéficierez des avantages décrits ci-dessous.

• Elle permet une gestion centralisée des clusters en regroupant les outils de gestion et de console sur la même machine.

• Elle peut permettre une résolution plus rapide des problèmes par votre fournisseur de services matériels.

La console administrative doit-elle être située « à proximité » du cluster, par exemple, dans la même pièce ?

Consultez votre fournisseur de services. Ce fournisseur peut exiger que la console soit située à proximité du cluster. Il n'existe cependant aucune raison technique pour que la console soit placée dans la même pièce.

Une console administrative peut-elle servir plusieurs clusters si des conditions de proximité sont également respectées ?

Oui. Il est possible de contrôler plusieurs clusters à partir d'une seule console administrative. Vous pouvez aussi partager un seul concentrateur de terminaux entre les clusters.

FAQ sur le concentrateur de terminaux ou le processeur de services système (SSP)

Le système Sun Cluster nécessite-t-il un concentrateur de terminaux ?

Depuis Sun Cluster version 3.0, aucune version du logiciel ne nécessite de concentrateur de terminaux pour s'exécuter. Contrairement à Sun Cluster version 2.2, qui nécessitait un concentrateur de terminaux pour la séparation en cas d'échec, les versions ultérieures ne dépendent pas du concentrateur de terminaux.

La plupart des serveurs Sun Cluster utilisent un concentrateur de terminaux, contrairement au serveur Sun Enterprise E1000. Pourquoi ?

Le concentrateur de terminaux constitue en effet un convertisseur série/Ethernet pour la plupart des serveurs. La console du concentrateur de terminaux dispose d'un port série. Le serveur Sun Enterprise E1000 ne possède pas de console série. C'est le SSP (System Service Processor) qui sert de console, à travers un port Ethernet ou un port jtag. Vous utilisez toujours SSP pour les consoles des serveurs Sun Enterprise E1000.

Quels sont les avantages de l'utilisation d'un concentrateur de terminaux ?

Un concentrateur de terminaux permet à chaque nœud d'une station de travail distante, quel que soit son emplacement sur le réseau, d'accéder à la console. Cet accès est fourni même lorsque le nœud est situé à l'invite de la PROM OpenBoot s'il s'agit d'un nœud SPARC ou sur un sous-système d'initialisation s'il s'agit d'un nœud x86.

Si j'utilise un concentrateur de terminaux que Sun ne prend pas en charge, que dois-je savoir pour l'habiliter ?

La principale différence entre le concentrateur de terminaux pris en charge par Sun et les autres périphériques de console réside dans le fait que le premier possède un microprogramme spécial. Ce microprogramme empêche le concentrateur de terminaux d'envoyer une valeur d'interruption à la console lors de son initialisation. Si vous possédez un périphérique de console qui peut envoyer une valeur de ce type ou un signal pouvant être interprété comme tel, la valeur d'interruption désactive le nœud.

Puis-je libérer un port verrouillé du concentrateur de terminaux pris en charge par Sun sans le réinitialiser ?

Oui. Notez le numéro de port à réinitialiser et entrez les commandes suivantes :

telnet tc
Entrez le nom ou le numéro de port annexe : cli
annexe : su -
annex# admin
admin : reset numéro_port
admin : quit
annex# hangup
#

Pour plus d'informations sur la configuration et l'administration du concentrateur de terminaux pris en charge par Sun, reportez-vous aux manuels suivants :

• Présentation de l’administration de Sun Cluster du Guide d’administration système de Sun Cluster pour SE Solaris

• Chapitre 2, Installing and Configuring the Terminal Concentrator du Sun Cluster 3.0-3.1 Hardware Administration Manual for Solaris OS

Que se passe-t-il si le concentrateur de terminaux tombe en panne ? Dois-je en avoir un autre à disposition ?

Non. Le cluster garde toute sa disponibilité en cas de panne du concentrateur de terminaux. Vous perdez la capacité de vous connecter aux consoles du nœud jusqu'à ce que le concentrateur soit de nouveau en service.

Qu'en est-il de la sécurité lorsque j'utilise un concentrateur de terminaux ?

En général, le concentrateur de terminaux est connecté à un petit réseau utilisé par les administrateurs système, et non à un réseau utilisé pour les autres accès client. Vous pouvez contrôler la sécurité en limitant l'accès à ce réseau particulier.

SPARC : comment utiliser la reconfiguration dynamique avec un lecteur de disques ou de bandes ?

Procédez comme suit :

• Déterminez si le lecteur de disques ou de bandes fait partie d'un groupe de périphériques actif. Si ce n'est pas le cas, des opérations de suppression par reconfiguration dynamique peuvent être effectuées sur ce lecteur.

• Si l'opération de suppression par reconfiguration dynamique touche un lecteur de disques ou de bandes actif, le système rejette l'opération et identifie les lecteurs susceptibles d'être affectés par cette opération. Si le lecteur fait partie d'un groupe de périphériques actif, accédez à SPARC : Clustering DR : éléments à prendre en compte pour les lecteurs de disques et de bandes .

• Déterminez si le lecteur est un composant du noeud principal ou du noeud secondaire. Si le lecteur est un composant du noeud secondaire, vous pouvez y effectuer l'opération de suppression par reconfiguration dynamique.

• Si le lecteur est un composant du nœud principal, vous devez commuter les nœuds principal et secondaire avant d'effectuer l'opération de suppression par reconfiguration dynamique sur ce périphérique.

tout échec sur le noeud principal, alors que vous effectuez une opération DR sur un noeud secondaire, a une incidence sur la disponibilité du cluster. Le noeud principal n'a pas d'endroit pour basculer, jusqu'à ce qu'un nouveau noeud secondaire soit défini.