Guide d'installation du logiciel Sun Cluster pour SE Solaris

Planification de l'environnement Sun Cluster

Cette rubrique indique comment planifier et préparer les composants ci-dessous pour l'installation et la configuration du logiciel Sun Cluster.

Pour obtenir plus d'informations sur les composants Sun Cluster, reportez-vous aux documents Présentation de Sun Cluster pour SE Solaris et Guide des notions fondamentales de Sun Cluster pour SE Solaris.

Gestion des licences

Avant de commencer l'installation du logiciel, assurez-vous de posséder les certificats de licence nécessaires. Le logiciel Sun Cluster ne nécessite pas de certificat de licence, mais chaque nœud sur lequel il est installé doit être couvert par votre contrat de licence pour le logiciel Sun Cluster.

Pour connaître les licences requises par le gestionnaire de volumes et les applications, reportez-vous aux documents d'installation de ces produits.

Patchs des logiciels

Après avoir installé chacun des logiciels, vous devez également installer les patchs éventuellement requis.

Pour obtenir des informations sur les patchs actuellement requis, reportez-vous à la rubrique Patchs et niveaux de microprogrammes requis du Notes de version de Sun Cluster 3.1 8/05 pour SE Solaris ou contactez votre prestataire de services Sun.
Pour connaître les procédures générales d'application des patchs, reportez-vous au Chapitre 8, Patchs pour logiciel et microprogramme Sun Cluster du Guide d’administration système de Sun Cluster pour SE Solaris.

Adresses IP

Vous devez définir un certain nombre d'adresses IP pour divers composants de Sun Cluster en fonction de la configuration de votre cluster. Chaque nœud de votre configuration de cluster doit avoir au moins une connexion de réseau public vers le même ensemble de sous-réseaux publics.

Le tableau ci-dessous répertorie les composants qui nécessitent des adresses IP. Ajoutez ces adresses IP aux emplacements suivants :

tout service d'attribution de noms utilisé ;
le fichier /etc/inet/hosts local de chaque nœud de cluster après l'installation de Solaris ;
le fichier /etc/inet/iphosts local de chaque nœud de cluster après l'installation de Solaris 10.

Tableau 1–3 Composants de Sun Cluster utilisant des adresses IP


Composant	Nombre d'adresses IP nécessaires
Console administrative	1 par sous-réseau.
Groupes Multiacheminement sur réseau IP	Groupes à 1seul adaptateur : 1 adresse IP principale (plus 1 adresse IP de test pour chaque adaptateur du groupe sous Solaris 8). Groupes à plusieurs adaptateurs : 1 adresse IP principale et 1 adresse IP de test pour chaque adaptateur du groupe.
Nœuds de cluster	1 par nœud et par sous-réseau.
Interface réseau de la console de domaine (Sun Fire^TM 15000)	1 par domaine.
Périphériques d'accès par console	1.
Adresses logiques	1 par ressource d'hôte logique et par sous-réseau.

Pour obtenir plus d'informations sur la planification d'adresses IP, reportez-vous au document System Administration Guide, Volume 3 (Solaris 8) ou au document System Administration Guide: IP Services (Solaris 9 ou Solaris 10).

Pour obtenir plus d'informations sur les adresses IP de test liées à la prise en charge de Multiacheminement sur réseau IP, reportez-vous au document IP Network Multipathing Administration Guide.

Périphériques d'accès par console

Vous devez disposer d'un accès par console à l'ensemble des nœuds de cluster. Si vous installez le logiciel Cluster Control Panel sur votre console administrative, vous devez indiquer le nom d'hôte du périphérique d'accès par console employé pour communiquer avec les nœuds du cluster.

Un concentrateur de terminal est utilisé pour établir la communication entre la console administrative et les consoles de nœuds du cluster.
Un serveur Sun Enterprise 10000 utilise un processeur SSP (System Service Processor) au lieu d'un concentrateur de terminal.
Un serveur Sun Fire^TM utilise un contrôleur de système au lieu d'un concentrateur de terminal.

Pour obtenir plus d'informations sur l'accès par console, reportez-vous au document Guide des notions fondamentales de Sun Cluster pour SE Solaris.

Adresses logiques

Lors de la planification d'adresses logiques, tenez compte des points suivants :

Chaque groupe de ressources de service de données qui utilise une adresse logique doit avoir un nom d'hôte spécifié pour chaque réseau public à partir duquel l'adresse logique est accessible.
L'adresse IP doit se trouver sur le sous-réseau de l'adresse IP de test utilisée par le groupe Multiacheminement sur réseau IP contenant l'adresse logique.

Pour obtenir plus d'informations, reportez-vous au document Sun Cluster Data Services Planning and Administration Guide for Solaris OS. Pour obtenir plus d'informations sur les services de données et les ressources, reportez-vous aux documents Présentation de Sun Cluster pour SE Solaris et Guide des notions fondamentales de Sun Cluster pour SE Solaris.

Réseaux publics

Les réseaux publics communiquent hors du cluster. Tenez compte des points suivants lorsque vous planifiez votre configuration de réseau public.

Les réseaux publics et le réseau privé (interconnexion de cluster) doivent utiliser des adaptateurs distincts, ou un VLAN en mode marqué doit être configuré sur des adaptateurs et des commutateurs compatibles de manière à utiliser le même adaptateur pour l'interconnexion privée et le réseau public.
Vous devez avoir au moins un réseau public connecté à tous les nœuds de cluster.
La configuration matérielle détermine le nombre maximal de connexions supplémentaires au réseau public.
Sun Cluster prend en charge les adresses IPv4 du réseau public.
Sun Cluster prend en charge les adresses IPv6 du réseau public, à certaines conditions :
- Sun Cluster ne prend pas en charge les adresses IPv6 du réseau public si l'interconnexion privée utilise des adaptateurs SCI.
- Sous Solaris 9 ou Solaris 10, Sun Cluster prend en charge les adresses IPv6 pour les services de données évolutifs et ceux de basculement.
- Sous Solaris 8, Sun Cluster prend en charge les adresses IPv6 pour les services de données de basculement uniquement.
Chaque adaptateur de réseau public doit appartenir à un groupe multi-acheminement sur réseau IP (Multiacheminement sur réseau IP). Pour obtenir plus d'informations, reportez-vous à la rubrique Groupes Multiacheminement sur réseau IP .
Tous les adaptateurs de réseau public doivent utiliser des cartes d'interface réseau prenant en charge l'affectation d'adresse MAC locale. L'affectation d'adresse MAC locale est une exigence de Multiacheminement sur réseau IP.
La variable local-mac-address? doit utiliser la valeur par défaut, true, pour les adaptateurs Ethernet. Le logiciel Sun Cluster ne prend pas en charge la valeur local-mac-address? false pour les adaptateurs Ethernet. Cette exigence est une modification apportée par rapport à Sun Cluster 3.0, qui nécessitait la variable local-mac-address? false.
Lors de l'installation de Sun Cluster sous Solaris 9 ou Solaris 10, l'utilitaire scinstall configure automatiquement un groupe Multiacheminement sur réseau IP à un seul adaptateur pour chaque adaptateur de réseau public. Pour modifier ces groupes de sauvegarde après l'installation, suivez les procédures du chapitre Administering IPMP (Tasks) du System Administration Guide: IP Services (Solaris 9 ou Solaris 10).
Sun Cluster ne prend pas en charge le filtre IP de Solaris.

Pour obtenir plus d'informations sur la planification des groupes de sauvegarde d'adaptateur de réseau public, reportez-vous à la rubrique Groupes Multiacheminement sur réseau IP . Pour obtenir plus d'informations sur les interfaces de réseau public, reportez-vous au document Guide des notions fondamentales de Sun Cluster pour SE Solaris.

Groupes Multiacheminement sur réseau IP

Ajoutez ces informations de planification à Fiche de travail relative aux réseaux publics.

Les groupes Multiacheminement sur réseau IP, qui remplacent les groupes NAFO (Network Adapter Failover, reprise sur panne de l'adaptateur réseau), assurent le contrôle et le basculement des adaptateurs de réseau public et constituent la base des ressources d'adresse réseau. Un groupe IPMP offre une haute disponibilité quand il est configuré avec au moins deux adaptateurs. Si un adaptateur échoue, toutes les adresses de l'adaptateur concerné vont vers un autre adaptateur du groupe IPMP. De cette façon, les adaptateurs du groupe IPMP préservent la connectivité du réseau public au sous-réseau auquel ils sont connectés.

Dans quels cas est-il nécessaire de configurer manuellement les groupes Multiacheminement sur réseau IP lors d'une installation Sun Cluster ?

Pour les installations Sun Cluster sous Solaris 8, vous devez configurer manuellement tous les adaptateurs de réseau public des groupes Multiacheminement sur réseau IP avec des adresses IP de test.
Si vous utilisez le programme d'installation SunPlex pour installer Sun Cluster sous Solaris 9 ou Solaris 10, certains adaptateurs de réseau public pourront demander une configuration manuelle des groupes Multiacheminement sur réseau IP.

Pour les installations Sun Cluster sous Solaris 9 ou Solaris 10, l'utilitaire scinstall associe automatiquement tous les adaptateurs de réseau public à des groupes Multiacheminement sur réseau IP à un seul adaptateur (sauf en cas d'utilisation du programme d'installation SunPlex).

Lors de la planification de vos groupes IPMP, tenez compte des points suivants.

Chaque adaptateur de réseau public doit appartenir à un groupe de multi-acheminement.
Dans les types de groupe de multiacheminement suivants, vous devez configurer une adresse IP de test pour chaque adaptateur du groupe :
- Sous Solaris 8, chacun des adaptateurs de chacun des groupes de multiacheminement nécessite une adresse IP de test.
- Sous Solaris 9 ou Solaris 10, seuls les groupes de multiacheminement comprenant deux adaptateurs ou plus nécessitent des adresses IP de test. Si un groupe de multi-acheminement contient un seul adaptateur, vous n'avez pas besoin de configurer une adresse IP de test.
Les adresses IP de test de tous les adaptateurs du même groupe de multiacheminement doivent appartenir au même sous-réseau IP.
Les adresses IP de test ne doivent pas être utilisées par des applications normales car elles ne sont pas hautement disponibles.
Dans le fichier /etc/default/mpathd, la valeur de TRACK_INTERFACES_ONLY_WITH_GROUPS doit être yes.
Le nom d'un groupe de multiacheminement ne fait l'objet d'aucune exigence ni restriction.

La plupart des procédures, instructions et restrictions présentées dans la documentation Solaris pour Multiacheminement sur réseau IP s'appliquent à la fois aux environnements de cluster et sans cluster. Pour plus d'informations sur Multiacheminement sur réseau IP, vous pouvez donc vous reporter au document Solaris approprié :

Pour Solaris 8, reportez-vous à la rubrique consacrée au déploiement IPMP du document IP Network Multipathing Administration Guide.
Pour Solaris 9, reportez-vous au Chapitre 28, Administering Network Multipathing (Task) du System Administration Guide: IP Services.
Pour Solaris 10, reportez-vous au Chapitre 31, Administering IPMP (Tasks) du System Administration Guide: IP Services.

Reportez-vous également à la rubrique Groupes de multiacheminement sur réseau IP du Présentation de Sun Cluster pour SE Solaris et au Guide des notions fondamentales de Sun Cluster pour SE Solaris.

Instructions relatives à l'utilisation du système NFS

Lorsque vous envisagez d'utiliser le système NFS (Network File System) dans un environnement Sun Cluster, vous devez tenir compte des points suivants :

Aucun nœud Sun Cluster ne peut être client NFS d'un système de fichiers exporté par Sun Cluster HA pour NFS et dont le maître soit un nœud du même cluster. Un tel montage croisé Sun Cluster HA pour NFS est interdit. Utilisez le système de fichiers du cluster pour répartir les fichiers entre les nœuds.
Les applications exécutées localement sur le cluster ne doivent pas verrouiller les fichiers sur un système de fichiers exporté via NFS. Si vous ne suivez pas cette recommandation, le blocage local (par exemple, flock(3UCB) ou fcntl(2)) risque d'entraver le redémarrage du gestionnaire de verrouillage (lockd(1M)). Lors du redémarrage, il est possible qu'un processus local bloqué soit verrouillé et que seul un client distant puisse le déverrouiller. Le comportement qui s'ensuit est imprévisible.
Sun Cluster ne prend pas en charge les options suivantes de la commande share_nfs(1M) :
- secure
- sec=dh
Toutefois, Sun Cluster prend en charge les fonctions de sécurité suivantes pour NFS :
- L'utilisation de ports sécurisés pour NFS. Pour activer les ports sécurisés pour NFS, ajoutez le paramètre d'entrée nfssrv:nfs_portmon=1 dans le fichier /etc/system des nœuds de cluster.
- L'utilisation de Kerberos avec NFS. Pour obtenir plus d'informations, reportez-vous à la rubrique Securing Sun Cluster HA for NFS With Kerberos V5 du Sun Cluster Data Service for NFS Guide for Solaris OS.

Restrictions de service

Veillez à respecter les restrictions de service suivantes dans les environnements Sun Cluster :

Ne configurez pas les nœuds du cluster en tant que routeurs (passerelles). Si le système est immobilisé, les clients ne pourront pas trouver de routeur alternatif et, de ce fait, effectuer une reprise.
Ne configurez pas les nœuds de cluster en tant que serveurs NIS ou NIS+. Il n'existe aucun service de données disponible pour NIS ou NIS+. Ils peuvent toutefois être des clients NIS ou NIS+.
N'utilisez pas de configuration Sun Cluster pour doter les systèmes client d'un service d'initialisation ou d'installation à haute disponibilité.
N'utilisez pas une configuration Sun Cluster pour fournir un service rarpd.
Si vous installez un service RPC sur le cluster, ce service ne doit utiliser aucun des numéros de programme suivants :
- 100141
- 100142
- 100248
Ces numéros sont réservés respectivement aux démons Sun Cluster rgmd_receptionist , fed et pmfd.

Si le service RPC installé utilise l'un de ces numéros, vous devez lui en attribuer un autre.
Sun Cluster ne prend pas en charge l'exécution des classes de programmation de processus à priorité élevée sur les nœuds du cluster. N'exécutez aucun des types de processus suivants sur les nœuds du cluster :
- processus s'exécutant dans la classe de programmation en temps partagé avec une priorité élevée ;
- processus s'exécutant dans la classe de programmation en temps réel.
Le logiciel Sun Cluster s'appuie sur des threads du noyau ne s'exécutant pas dans la classe en temps réel. Des processus en temps partagé s'exécutant avec une priorité supérieure à la normale ou des processus en temps réel peuvent empêcher les threads du noyau de Sun Cluster d'acquérir les cycles processeur requis.

Composants configurables de Sun Cluster

Cette rubrique fournit des instructions pour les composants de Sun Cluster suivants que vous configurez.

Ajoutez ces informations à la fiche de configuration appropriée.

Nom du cluster

Nommez le cluster au cours de la configuration de Sun Cluster. Ce nom doit être unique dans toute l'entreprise.

Noms des nœuds

Le nom de nœud est celui que vous affectez à une machine lorsque vous installez le système d'exploitation Solaris. Pendant la configuration de Sun Cluster, indiquez le nom de tous les nœuds que vous installez en tant que nœuds de cluster. Dans les installations de cluster mononœud, le nom par défaut du cluster est celui du nœud.

Réseau privé

Remarque –

pour les clusters mononœuds, il est inutile de configurer un réseau privé.

Le logiciel Sun Cluster utilise le réseau privé pour assurer les communications internes entre les nœuds. Chaque configuration Sun Cluster nécessite au moins deux connexions pour procéder à l'interconnexion du cluster sur le réseau privé. Vous indiquez l'adresse de réseau privé et le masque de réseau lorsque vous configurez le logiciel Sun Cluster sur le premier nœud du cluster. Vous pouvez soit accepter l'adresse de réseau privé par défaut (172.16.0.0) et le masque de réseau (255.255.0.0), soit indiquer d'autres choix.

Remarque –

Une fois l'exécution de l'utilitaire d'installation (scinstall, le programme d'installation SunPlex ou JumpStart) terminée et le cluster établi, vous ne pouvez plus modifier ni l'adresse, ni le masque. Vous devrez désinstaller et réinstaller le logiciel de cluster pour pouvoir utiliser une adresse de réseau privé ou un masque de réseau différent.

Si vous indiquez une adresse de réseau privé différente de l'adresse par défaut, elle doit répondre aux exigences suivantes :

Elle doit se terminer par deux zéros, comme l'adresse par défaut 172.16.0.0. Le logiciel Sun Cluster requiert les 16 derniers bits de l'espace de l'adresse pour son usage personnel.
L'adresse doit figurer dans le bloc d'adresses dont l'utilisation est réservée par la demande de commentaires RFC 1918 dans les réseaux privés. Vous pouvez contacter le centre InterNIC pour obtenir des RFC ou les afficher en ligne à partir de l'adresse http://www.rfcs.org.
Vous pouvez utiliser la même adresse de réseau privé dans plusieurs cluster. Les adresses de réseaux IP privés ne sont pas accessibles de l'extérieur du cluster.
Sun Cluster ne prend pas en charge les adresses IPv6 pour l'interconnexion privée. Le système configure les adresses IPv6 sur les adaptateurs de réseau privé pour prendre en charge les services évolutifs utilisant les adresses IPv6. Toutefois, la communication entre les nœuds du réseau privé n'utilise pas ces adresses IPv6.

Même si l'utilitaire scinstall permet d'indiquer un autre masque de réseau, il est recommandé d'accepter le masque de réseau par défaut (255.255.0.0). En effet, il n'y a aucun avantage à indiquer un masque de réseau représentant un réseau plus grand et l'utilitaire scinstall n'accepte pas de masque représentant un réseau plus petit.

Pour obtenir plus d'informations sur les réseaux privés, reportez-vous à la rubrique Planning Your TCP/IP Network du document System Administration Guide, Volume 3 (Solaris 8) ou à la rubrique Planning Your TCP/IP Network (Tasks) du document System Administration Guide: IP Services (Solaris 9 ou Solaris 10) .

Noms d'hôtes privés

Le nom d'hôte privé est le nom utilisé pour la communication entre les nœuds sur l'interface de réseau privé. Ces noms sont créés automatiquement lors de la configuration de Sun Cluster. Il sont conformes à la convention d'attribution de nom clusternodenodeid -priv (nodeid représente le numéro de l'ID du nœud interne). Lors de la configuration de Sun Cluster, ce numéro d'ID est affecté automatiquement à chaque nœud dès lors qu'il devient élément du cluster. Après la configuration du cluster, vous pouvez modifier les noms d'hôtes privés à l'aide de l'utilitaire scsetup(1M).

Interconnexion de cluster

Remarque –

pour les clusters mononœuds, il est inutile de configurer une interconnexion de cluster. Cependant, si vous prévoyez d'ajouter des nœuds à une configuration de cluster mononœud, vous souhaiterez probablement configurer l'interconnexion de cluster pour une utilisation future.

Les interconnexions de cluster fournissent les voies matérielles pour la communication en réseau privé entre les nœuds du cluster. Chaque interconnexion consiste en un câble connecté de l'une des manières suivantes :

entre deux adaptateurs de transport ;
entre un adaptateur de transport et une jonction de transport ;
entre deux jonctions de transport.

Lors de la configuration de Sun Cluster, vous fournissez des informations de configuration pour deux interconnexions de cluster. Vous pourrez configurer d'autres connexions de réseau privé après avoir établi le cluster à l'aide de l'utilitaire scsetup(1M).

Pour obtenir plus d'informations sur les périphériques d'interconnexion de cluster, reportez-vous à la rubrique Interconnect Requirements and Restrictions du Sun Cluster 3.0-3.1 Hardware Administration Manual for Solaris OS. Pour obtenir des informations générales sur l'interconnexion de cluster, reportez-vous à la rubrique Interconnexion de cluster du Présentation de Sun Cluster pour SE Solaris et au Guide des notions fondamentales de Sun Cluster pour SE Solaris.

Adaptateurs de transport

Pour les adaptateurs de transport, tels que les ports sur les interfaces réseau, indiquez le nom des adaptateurs et le type de transport. Si votre configuration repose sur un cluster à deux nœuds, vous devez également indiquer si l'interconnexion fait l'objet d'une liaison directe (adaptateur à adaptateur) ou si elle utilise une jonction de transport.

Tenez compte des instructions et restrictions suivantes :

IPv6 : Sun Cluster ne prend pas en charge les communications IPv6 sur les interconnexions privées.
Affectation d'adresse MAC locale : tous les adaptateurs de réseau privé doivent utiliser des cartes d'interface réseau prenant en charge l'affectation d'adresse MAC locale. Les adresses IPv6 à portée locale, requises sur les adaptateurs de réseau privé pour prendre en charge les adresses IPv6 de réseau public, sont dérivées des adresses MAC locales.
Adaptateurs VLAN en mode marqué : Sun Cluster prend en charge les réseaux locaux virtuels (VLAN) pour partager un adaptateur entre l'interconnexion privée et le réseau public. Lorsque vous configurez un adaptateur VLAN en mode marqué pour l'interconnexion privée, indiquez le nom de l'adaptateur et son ID VLAN (VID) de l'une des manières suivantes :
- Indiquez le nom usuel de l'adaptateur, c'est-à-dire le nom du périphérique, suivi du numéro de l'instance ou du point physique de connexion. Par exemple, le nom de l'instance 2 d'un adaptateur Gigabit Ethernet de Cassini serait ce2. Si l'utilitaire scinstall vous demande si l'adaptateur appartient à un réseau local virtuel partagé, répondez yes et indiquez le numéro VID.
- Indiquez l'adaptateur par son nom de périphérique VLAN. Ce nom se compose du nom de l'adaptateur et du numéro de l'instance VLAN. Le numéro de l'instance VLAN est obtenu par la formule (1000*V)+N (V étant le numéro VID et N, le point physique de connexion).
  
  Par exemple, pour le VID 73 sur l'adaptateur ce2, vous calculez le numéro de l'instance VLAN par la formule (1000*73)+2. Vous devez donc désigner l'adaptateur par le nom ce73002 pour indiquer son appartenance à un réseau local virtuel partagé.
Pour obtenir plus d'informations sur les réseaux locaux virtuels, reportez-vous à la rubrique Configuring VLANs du document Solaris 9 9/04 Sun Hardware Platform Guide.
Adaptateurs SCI SBus : l'interface SCI (Scalable Coherent Interface) SBus n'est pas prise en charge dans le cadre d'une interconnexion de cluster. En revanche, l'interface SCI–PCI l'est.
Interfaces de réseau logique : les interfaces de réseau logique sont réservées à Sun Cluster.

Pour obtenir plus d'informations sur un adaptateur de transport en particulier, reportez-vous aux pagesde manuel scconf_trans_adap_*(1M).

Jonctions de transport

Si vous utilisez des jonctions de transport (par exemple, des commutateurs réseau), indiquez un nom de jonction de transport pour chaque interconnexion. Vous pouvez utiliser le nom par défaut switchN, où N est un numéro affecté automatiquement à la configuration, ou créer un autre nom. Il existe une exception à cette règle : l'adaptateur Sun Fire Link nécessite le nom de jonction sw-rsm N. L'utilitaire scinstall utilise automatiquement ce nom de jonction lorsque vous indiquez qu'il s'agit d'un adaptateur Sun Fire Link (wrsmN).

Indiquez également le nom du port de la jonction ou acceptez le nom par défaut. Le nom de port par défaut est identique à l'ID de nœud interne du nœud qui héberge l'extrémité adaptateur du câble. Cependant, vous ne pouvez pas utiliser le nom de port par défaut pour certains types d'adaptateurs, tels que SCI-PCI.

Remarque –

les clusters à trois nœuds ou plus doivent utiliser des jonctions de transport. La connexion directe entre les nœuds de cluster est possible uniquement pour les clusters à deux nœuds.

Si votre cluster à deux nœuds utilise une connexion directe, vous pouvez toujours spécifier une jonction de transport pour l'interconnexion.

Astuce –

si vous le faites, il sera plus facile d'ajouter un autre nœud au cluster à l'avenir.

Périphériques de quorum

Les configurations de Sun Cluster utilisent des périphériques de quorum pour préserver l'intégrité des données et des ressources. Si le cluster perd temporairement la connexion à un nœud, le périphérique de quorum évite les problèmes “d'amnésie” ou de dédoublement lorsque le nœud tente de rejoindre le cluster. Lors de l'installation d'un cluster à deux nœuds sous Sun Cluster, l'utilitaire scinstall configure automatiquement un périphérique de quorum. Le périphérique de quorum est choisi parmi les disques de stockage partagés et disponibles. L'utilitaire scinstall suppose que tous les disques de stockage partagés et disponibles peuvent être utilisés comme périphériques de quorum. Après l'installation, vous pouvez également configurer des périphériques de quorum supplémentaires à l'aide de l'utilitaire scsetup(1M).

Remarque –

vous n'avez pas besoin de configurer des périphériques de quorum pour un cluster à nœud unique.

Si votre configuration de cluster ne vous autorise pas à utiliser des périphériques partagés de stockage tierrs comme périphériques de quorum, vous devez exécuter l'utilitaire scsetup pour configurer manuellement le quorum.

Tenez compte des points suivants lorsque vous planifiez des périphériques de quorum.

Minimum: un cluster à deux nœuds doit avoir au moins un périphérique de quorum (disque partagé ou périphérique NAS Network Appliance). Pour les autres topologies, les périphériques de quorum sont facultatifs.
Règle du nombre impair : si plusieurs périphériques de quorum sont configurés dans un cluster à deux nœuds ou dans une paire de nœuds directement connectée au périphérique de quorum, vous devez vous assurer qu'ils sont en nombre impair. Cette configuration garantit que les périphériques de quorum ont des chemins défaillants complètement indépendants les uns des autres.
Connexion : vous devez connecter un périphérique de quorum à deux nœuds au moins.

Pour obtenir plus d'informations sur les périphériques de quorum, reportez-vous aux rubriques Quorum et périphériques de quorum du Guide des notions fondamentales de Sun Cluster pour SE Solaris et Périphériques de quorum du Présentation de Sun Cluster pour SE Solaris.