Chapitre 4 Foire aux questions

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 nœud défectueux vers un autre nœud 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 nœud principal du cluster à la fois. Les autres nœuds peuvent exécuter d'autres applications, mais chaque application ne tourne que sur un seul nœud. Si un nœud principal tombe en panne, les applications fonctionnant sur ce nœud basculent vers un autre nœud et continuent de fonctionner.

  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 y avoir 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 nœud GIF tombe en panne, l'interface globale bascule sur un nœud encore actif.

  Si l'un des nœuds sur lequel tourne l'application tombe en panne, celle-ci continue de fonctionner sur les autres nœuds avec une certaine dégradation des performances jusqu'à ce que le nœud défectueux retourne dans le cluster.

FAQ concernant les systèmes de fichiers

• Puis-je faire fonctionner un ou plusieurs nœuds de cluster comme serveur(s) NFS hautement disponible(s) avec d'autres nœuds 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 Resource Group Manager ?

  Oui. Toutefois, sans le contrôle du RGM, les applications doivent être relancées manuellement après l'échec du nœud 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 nœud.

  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 nœuds accèdent à un fichier pour des opérations de lecture, écriture, verrouillage, 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 (à l'aide de chmod(1M) , par exemple) d'un système de fichiers de cluster, cela se reflète immédiatement sur tous les nœuds. 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 nœuds 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 nœud accède uniquement à son propre espace de noms de périphérique global. 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 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 ?

  SPARC: 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.

  x86: Non, cette configuration n'est pas prise en charge, car seul Solaris Volume Manager est pris en charge dans les clusters basés sur x86.

FAQ concernant les services de données

• Quels services de données SunPlex sont disponibles ?

  La liste des services de données pris en charge est incluse dans la section “Supported Products” du document Sun Cluster 3.1 9/04 Release Notes for Solaris OS .

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

  La liste des versions d'applications prises en charge est incluse dans la section “Supported Products” du document Sun Cluster 3.1 9/04 Release Notes for Solaris OS .

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

  Oui. Consultez la rubrique “Référence à la bibliothèque de développement de services de données” dans le Guide des développeurs pour les services de données Sun Cluster pour SE Solaris pour plus d'informations.

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

FAQ 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 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 SunPlex prend-il en charge le paramètre local-mac-address?=true ?

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

  Vous pouvez définir local-mac-address? avec eeprom(1M), à l'invite ok de la PROM OpenBoot sur un cluster SPARC ou avec l'utilitaire SCSI exécuté en option après l'amorçage du BIOS sur un système x86.

• Quel délai d'attente faut-il compter lorsque le IP Network Multipathing commute des adaptateurs ?

  Ce délai d'attente peut être de quelques minutes. Il est dû au fait qu'en cas de commutation du IP Network Multipathing, 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 le délai de l'entrée du cache ARP pour cette adresse IP sur le routeur n'est pas dépassé, il est possible qu'il 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.

FAQ 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 nœuds sont initialisés est-il important ?

  Dans la plupart des cas, non. L'ordre d'initialisation des nœuds est cependant important pour prévenir des phénomènes d'amnésie (reportez-vous à la rubrique À propos de la séparation en cas d'échec pour de plus amples détails à ce sujet). Par exemple, si le nœud 2 est propriétaire du périphérique de quorum et que le nœud 1 est arrêté, si vous arrêtez ensuite le nœud 2, vous devrez l'activer de nouveau avant d'activer le nœud 1. Ceci vous empêche d'activer accidentellement un nœud où les informations de configuration ne sont pas à jour.

• Dois-je mettre en miroir les disques locaux d'un nœud 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 nœud. 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 nœud de sauvegarde un nœud 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 nœud aux disques partagés.

  Reportez-vous à la rubrique “ Sauvegarde et restauration d'un cluster” dans le Guide d'administration du système Sun Cluster pour SE Solaris pour plus d'informations sur la sauvegarde et la restauration des données.

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

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

FAQ 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 nœud auquel il est connecté. En outre, chaque nœud 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 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 sur les clusters SPARC et x86. Le système SunPlex prend en charge l'interconnexion de cluster d'interface réseau SCI sur les clusters SPARC uniquement.

• 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 nœuds. 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és ou désactivés) 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 d'accès peut avoir le statut « en ligne » ou « hors ligne ». consultable à l'aide de la commande scstat(1M).

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

  nœud 1 : adaptateur 0     vers commutateur 1, port 0 nœud 1 : adaptateur 1     vers commutateur 2, port 0 nœud 2 : adaptateur 0     vers commutateur 1, port 1 nœud 2 : adaptateur 1     vers commutateur 2, port 1

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

  nœud 1 : adaptateur 0    vers nœud 2 : adaptateur 0 nœud 2 : adaptateur 1    vers nœud 2 : adaptateur 1

FAQ 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 Data Services Planning and Administration Guide pour de plus amples informations sur les exigences de configuration client.

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

FAQ 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 Sun Enterprise E10000 server 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 Sun Enterprise E10000 server 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 Sun Enterprise E10000 server, 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 nœud à partir d'une station de travail distante située n'importe où sur le réseau, même lorsque le nœud est sur la PROM OpenBoot (OBP) sur un nœud SPARC ou un sous-système d'initialisation sur un nœud x86.

• 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 nœud 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 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 #

  Reportez-vous aux manuels suivants pour en savoir plus sur la configuration et l'administration d'un concentrateur de terminaux pris en charge par Sun.

  • “ Administration de Sun Cluster : présentation” dans le Guide d'administration du système Sun Cluster pour SE Solaris

  • “Installing and Configuring the Terminal Concentrator ” dans Sun Cluster 3.x 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 ?

  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.

• SPARC: 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 SPARC: reconfiguration dynamique et lecteurs de disques et de bandes.

  • Déterminez si le lecteur est un composant du nœud principal ou du nœud secondaire. Si le lecteur est un composant du nœud 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 nœud principal, alors que vous effectuez une opération DR sur un nœud secondaire, a une incidence sur la disponibilité du cluster. Le nœud principal n'a pas d'endroit pour basculer, jusqu'à ce qu'un nouveau nœud secondaire soit défini.