Chapitre 4 Questions récurrentes

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

Questions récurrentes concernant la haute disponibilité

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

  Sur le système SunPlex, la haute disponibilité (HD) est la capacité d'un cluster à maintenir une application active, même lors d'une panne entraînant normalement l'indisponibilité du système serveur.

• 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 à haute disponibilité : le service de basculement et le service é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. Si un noeud principal tombe en panne, les applications fonctionnant sur ce noeud basculent vers un autre noeud et continuent de fonctionner.

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

  Pour chaque application, un noeud héberge l'interface physique pour le cluster. Ce noeud s'appelle noeud d'interface globale (ou noeud GIF). Il peut y avoir plusieurs noeuds 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 noeud GIF héberge une interface globale pour toutes les requêtes d'une application particulière et les distribue aux noeuds 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 noeuds sur lequel tourne l'application tombe en panne, celle-ci continue de fonctionner sur les autres noeuds avec une certaine dégradation des performances jusqu'à ce que le noeud défectueux retourne dans le cluster.

Questions récurrentes concernant les systèmes de fichiers

• Puis-je faire fonctionner un ou plusieurs noeuds de cluster comme serveur(s) NFS hautement disponible(s) avec d'autres noeuds comme clients ?

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

• Puis-je utiliser un système de fichiers de cluster pour des applications n'étant pas sous le contrôle du Gestionnaire du groupe de ressources ?

  Oui. Toutefois, sans le contrôle du RGM, les applications doivent être relancées manuellement après l'échec du noeud sur lequel elles fonctionnent.

• Tous les systèmes de fichiers de cluster doivent-ils avoir un point de montage sous 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 y en a plusieurs :

  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, chaque fois que plusieurs noeuds accèdent à un fichier pour des opérations de lecture, écriture, verrouillage, E/S asynchrones.

  4. Le système de fichiers de cluster prend en charge les basculements sans interruption du service si un serveur échoue. NFS prend en charge plusieurs serveurs, mais le basculement n'est possible que pour les systèmes de fichiers à lecture seule.

  5. 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.

  6. Si vous modifiez les attributs d'un fichier (à l'aide de chmod(1M) , par exemple) d'un système de fichiers de cluster, la modification se reflète immédiatement sur tous les noeuds. Avec un système de fichiers NFS exporté, cette opération peut prendre beaucoup plus de temps.

• Le système de fichiers /global/.devices/node@<nodeID> apparaît sur les noeuds de mon 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. Bien qu'ils soient globaux, on n'y accède jamais de manière globale -- chaque noeud accède uniquement à son propre espace de noms de périphérique global. Si un noeud 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.

Questions récurrentes concernant la gestion de 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 ?

  Cette configuration est prise en charge par 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.

Questions récurrentes concernant les services de données

• Quels services de données SunPlex sont disponibles ?

  Vous trouverez une liste des services de données pris en charge dans les Notes de version de Sun Cluster 3.1.

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

  Vous trouverez une liste des versions d'application prises en charge dans les Notes de version de Sun Cluster 3.1.

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

  Oui. Pour de plus amples informations, reportez-vous au document Sun Cluster 3.1 Data Services Developer's Guide et à la documentation concernant les technologies d'activation des services de données fournie avec l'API de la bibliothèque de développement des services de données (API DSDL).

• 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é pour le cas de Sun Cluster HA pour NFS, lorsque la documentation requiert l'utilisation d'une ressource LogicalHostname dans un groupe de ressources en mode basculement, les ressources SharedAddress et LogicalHostname peuvent être utilisées indifféremment. L'utilisation d'une ressource SharedAddress implique un temps système accru car le cluster est configuré pour une ressource SharedAddress et non pour LogicalHostname.

  Vous avez intérêt à utiliser une ressource SharedAddress lorsque vous configurez à la fois des services de données évolutifs et de basculement, et souhaitez que les clients puissent y accéder à l'aide du même nom d'hôte. Dans ce cas, la/les ressource(s) SharedAddress et les ressources d'application de basculement sont contenues dans un groupe de ressources, tandis que la ressource du service de données évolutif est contenue dans un groupe de ressources à part et configuré pour utiliser SharedAddress. Les services évolutifs et de basculement peuvent ensuite utiliser le même ensemble de noms d'hôtes/adresses configurés dans la ressource SharedAddress.

Questions récurrentes concernant le réseau public

• Quels adaptateurs de réseau public le système SunPlex prend-il en charge ?

  À l'heure actuelle, le système SunPlex 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 noeud a basculé) et l'ancienne adresse IP. Lorsqu'une autre machine sur le réseau reçoit un de ces paquets, elle débarrasse sa mémoire cache ARP de l'ancienne correspondance MAC-IP et utilise la nouvelle.

• Le système SunPlex prend-il en charge le paramètre local-mac-address?=true dans la PROM OpenBoot^TM (OBP) d'un adaptateur d'hôte ?

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

• Quel délai d'attente faut-il compter lorsque le multi-acheminement sur r&eacute;seau IP commute des adaptateurs ?

  Ce délai d'attente peut être de quelques minutes. Il est dû au fait qu'en cas de commutation du multi-acheminement sur r&eacute;seau IP , un ARP est envoyé en supplément. Il n'y a cependant aucune garantie que le routeur entre le client et le cluster utilise cet ARP. En effet, tant que l'entrée du cache ARP pour cette adresse IP n'est pas arrivée au bout de son délai d'exécution sur le routeur, il est possible que celui-ci utilise l'ancienne adresse MAC.

• 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.

Questions récurrentes concernant les membres du 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. L'ordre d'initialisation des noeuds est cependant important pour prévenir des phénomènes d'amnésie (reportez-vous à la rubrique Quorum et périphériques de quorum pour de plus amples détails sur 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. Ceci vous empêche d'activer accidentellement un noeud où les informations de configuration ne sont pas à jour.

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

  Oui. Bien que cette mise en miroir ne soit pas obligatoire, elle empêche que l'échec d'un disque non mis en miroir n'arrête le noeud. 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. Une des méthodes consiste à avoir comme noeud de sauvegarde un noeud auquel est rattaché un lecteur/bibliothèque de bandes. Le système de fichiers de cluster est ensuite utilisé pour sauvegarder les données. Ne connectez pas ce noeud aux disques partagés.

  Reportez-vous au Guide d'administration syst&egrave;me de Sun Cluster 3.1 pour obtenir des informations complémentaires sur les procédures de sauvegarde et de restauration.

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

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

Questions récurrentes concernant le stockage du cluster

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

  Le stockage multihôte est hautement disponible parce qu'il peut survivre à la perte d'un disque, grâce à la mise en miroir (ou grâce aux contrôleurs matériels RAID-5). 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.

Questions récurrentes concernant l'interconnexion de cluster

• Quelles interconnexions de cluster le système SunPlex prend-il en charge ?

  À l'heure actuelle, le système SunPlex prend en charge Ethernet (100BASE-T Fast Ethernet et 1000BASE-SX Gb) et les interconnexions de cluster de l'interface de réseau SCSI.

• Quelle est la différence entre un « câble » et un « chemin » de transport ?

  Les câbles de transport de cluster sont configurés pour utiliser des adaptateurs et 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. Les câbles ont un « état », (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. Ils ne sont pas sondés et il est ainsi impossible de connaître leur statut. L'état d'un câble peut être affiché à l'aide de la commande scconf - p.

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

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

  noeud 1 : adaptateur 0     vers commutateur 1, port 0 noeud 1 : adaptateur 1     vers commutateur 2, port 0 noeud 2 : adaptateur 0     vers commutateur 1, port 1 noeud 2 : adaptateur 1     vers commutateur 2, port 1

  Deux chemins d'accès possibles peuvent être formés à partir de ces quatre câbles.

  noeud 1 : adaptateur 0    vers noeud 2 : adaptateur 0 noeud 2 : adaptateur 1    vers noeud 2 : adaptateur 1

Questions récurrentes concernant 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 à n'importe quel 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. Reportez-vous aux chapitres individuels du document Sun Cluster 3.1 Data Services Installation and Configuration Guide pour de plus amples informations sur les exigences de configuration client.

Questions récurrentes concernant la console administrative

• Le système SunPlex requiert-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 SunPlex n'exige pas l'utilisation d'une console administrative dédiée ; cette dernière présente cependant les avantages suivants :

  • 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 a-t-elle besoin d'être située « près » du cluster, dans la même pièce par exemple ?

  Consultez votre fournisseur de services. Ce dernier peut demander à ce que la console soit placée près 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 plus d'un cluster, si les contraintes relatives à la distance sont 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.

Questions récurrentes concernant les concentrateurs de terminaux et les SSP

• Le système SunPlex requiert-il un concentrateur de terminaux ?

  Les versions Sun Cluster 3.0 et ultérieures peuvent fonctionner sans concentrateur de terminaux. Ce n'était pas le cas de la version Sun Cluster 2.2, nécessitant un concentrateur de terminaux pour la fonction de séparation en cas d'échec.

• Je constate que la plupart des serveurs SunPlex utilisent un concentrateur de terminaux, mais le Serveur Sun Enterprise E10000 n'en utilise pas. Pour quelle raison ?

  Le concentrateur de terminaux constitue en effet un convertisseur série/Ethernet pour la plupart des serveurs. Son port de console est un port série. Le Serveur Sun Enterprise E10000 n'a pas de console série. C'est le SSP (System Service Processor) qui sert de console, à travers un port Ethernet ou un port jtag. Dans le Serveur Sun Enterprise E10000, le SSP est toujours utilisé comme console.

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

  L'utilisation d'un concentrateur de terminaux fournit un accès au niveau de la console à chaque noeud à partir d'une station de travail distante située n'importe où sur le réseau, même lorsque le noeud est sur la PROM OpenBoot (OBP).

• Que dois-je savoir si je veux utiliser un concentrateur de terminaux non pris en charge par Sun ?

  La principale différence entre le concentrateur de terminaux pris en charge par Sun et les autres consoles est que le premier contient des microprogrammes spéciaux empêchant le concentrateur de terminaux d'envoyer une coupure (ou break) à la console au moment où il s'initialise. Notez que si vous possédez une console susceptible d'envoyer une coupure, ou un signal pouvant être interprété comme tel à la console, le noeud est arrêté.

• Puis-je libérer le port verrouillé d'un concentrateur de terminaux pris en charge par Sun sans pour autant le réinitialiser ?

  Oui. Notez que le numéro de port qui a besoin d'être réinitialisé et procédez de la manière suivante :

  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 #

  Reportez-vous au Guide d'administration syst&egrave;me de Sun Cluster 3.1 pour obtenir de plus amples informations sur la configuration et l'administration du concentrateur de terminaux pris en charge par Sun.

• 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 noeud 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 ?

  Généralement, le concentrateur de terminaux est relié à un petit réseau utilisé par les administrateurs système et non accessible aux autres clients. Vous pouvez contrôler la sécurité en limitant l'accès à ce réseau particulier.

• Comment utiliser la reconfiguration dynamique avec un lecteur de disques ou de bandes ?

  • 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, allez à la rubrique Reconfiguration dynamique et 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 noeud principal, vous devez commuter les noeuds 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.