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 à Sun Cluster Overview for Solaris OS et à Sun Cluster Concepts Guide for Solaris OS.
Assurez-vous de bien posséder les certificats de licence nécessaires avant de commencer l'installation du logiciel. Le logiciel Sun Cluster ne nécessite pas de certificat de licence, mais chaque noeud 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 documentations d'installation de ces produits.
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 requis pour les microprogrammes dans le manuel Sun Cluster 3.2 2/08 Release Notes for Solaris OS ou consultez votre fournisseur de services Sun.
Pour connaître les procédures générales d'application des patchs, reportez-vous au Chapitre 10, Patching Sun Cluster Software and Firmware du Sun Cluster System Administration Guide for Solaris OS.
Pour des informations sur l'utilisation de réseaux publics par le cluster, reportez-vous à Public Network Adapters and IP network multipathing du Sun Cluster Concepts Guide for Solaris OS.
Vous devez définir un certain nombre d'adresses IP réseau public pour divers composants de Sun Cluster en fonction de la configuration de votre cluster. Chaque noeud 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 suivant répertorie les composants qui nécessitent des adresses IP réseau public. 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 ;
sous Solaris 10, le fichier /etc/inet/ipnodes de chaque nœud de cluster après l'installation de Solaris.
Pour plus d'informations sur la planification des adresses IP, reportez-vous au Chapitre 3, Planning Your TCP/IP Network (Task) du System Administration Guide: IP Services (Solaris 9) ou au Chapitre 2, Planning Your TCP/IP Network (Tasks) du System Administration Guide: IP Services (Solaris 10).
Vous devez disposer d'un accès par console à l'ensemble des noeuds de cluster. Si vous installez le logiciel Cluster Control Panel sur une console administrative, vous devez indiquer le nom d'hôte et le numéro de port du périphérique d'accès par console utilisé 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 noeuds 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 utilise un contrôleur de système au lieu d'un concentrateur de terminal.
Pour plus d'informations sur l'accès par console, reportez-vous au manuel Sun Cluster Concepts Guide for Solaris OS.
Alternativement, si vous connectez une console administrative directement aux nœuds du cluster ou via un réseau de gestion, vous fournissez alors le nom d'hôte de chaque nœud du cluster et son numéro de port série utilisé pour connecter la console administrative ou le réseau de gestion.
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.
Pour plus d'informations, reportez-vous au manuel Sun Cluster Data Services Planning and Administration Guide for Solaris OS. Pour plus d'informations sur les services de données et les ressources, reportez-vous à Sun Cluster Overview for Solaris OS et à Sun Cluster Concepts Guide for Solaris OS.
Les réseaux publics communiquent hors du cluster. Tenez compte des points suivants lorsque vous planifiez votre configuration de réseau public.
Séparation de réseau public et privé - Les réseaux publics et le réseau privé (interconnexion de cluster) doivent utiliser des adaptateurs différents. Vous pouvez également configurer un VLAN marqué sur des adaptateurs VLAN marqués et des commutateurs VLAN pour utiliser le même adaptateur pour l'interconnexion privée et le réseau public.
Minimum - Tous les nœuds de cluster doivent être connectés à au moins un réseau public. Les connexions de réseau public peuvent utiliser différents sous-réseaux pour différents nœuds.
Maximum - La configuration matérielle détermine le nombre maximal de connexions supplémentaires au réseau public dont vous pouvez disposer.
Services évolutifs : tous les nœuds exécutant un service évolutif doivent utiliser le même sous-réseau ou ensemble de sous-réseaux ou utiliser différents sous-réseaux pouvant être acheminés entre eux.
IPv4 : Sun Cluster prend en charge les adresses IPv4 du réseau public.
IPv6 : 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.
Sun Cluster prend en charge les adresses IPv6 pour les services de données évolutifs et de basculement.
Groupes IPMP - Chaque adaptateur de réseau publicutilisé pour le trafic de service de données doit appartenir à un groupe Multiacheminement sur réseau IP (IPMP). Si un adaptateur de réseau public n'est pas utilisé pour le trafic de service de données, ne le configurez pas dans un groupe IPMP.
Dans la version Sun Cluster 3.2 2/08, l'utilitaire scinstall ne configure plus automatiquement de groupe IPMP à un seul adaptateur sur chaque adaptateur non configuré du réseau public pendant la création de Sun Cluster. À la place, l'utilitaire scinstall configure automatiquement un groupe IPMP à plusieurs adaptateurs pour chaque ensemble d'adaptateurs de réseau public dans le cluster utilisant le même sous-réseau. Sur Solaris 10, ces groupes sont basés sur une sonde. L'utilitaire scinstall ignore cependant les adaptateurs déjà configurés dans un groupe IPMP. Si un adaptateur dans un groupe IPMP configuré par l'utilitaire scinstall n'utilise pas le trafic de service de données, vous pouvez le supprimer du groupe.
Pour des recommandations et des instructions sur la configuration des groupes IPMP, suivez les procédures dans Partie II, Administering Interface Groups du System Administration Guide: Network Interfaces and Network Virtualization. Pour modifier les groupes IPMP après l'installation du cluster, suivez les recommandations dans How to Administer IP Network Multipathing Groups in a Cluster du Sun Cluster System Administration Guide for Solaris OS et les procédures du Chapitre 28, Administering Network Multipathing (Task) du System Administration Guide: IP Services (Solaris 9) ou Chapitre 8, Administering IPMP du System Administration Guide: Network Interfaces and Network Virtualization(Solaris 10).
Prise en charge d'adresse MAC locale - Tous les adaptateurs de réseau public doivent utiliser des cartes d'interface réseau (NIC) prenant en charge l'affectation d'adresses MAC locales. L'affectation d'adresse MAC locale est une exigence de IPMP.
local-mac-address paramètre - La variable local-mac-address? doit utiliser la valeur par défaut true pour adaptateurs Ethernet. Le logiciel Sun Cluster ne prend pas en charge la valeur local-mac-address? false pour les adaptateurs Ethernet. Cette condition est une modification apportée à Sun Cluster 3.0, qui nécessitait la valeur false pour la variable local-mac-address?.
Pour plus d'informations sur les interfaces de réseau public, reportez-vous à Sun Cluster Concepts Guide for Solaris OS.
Vous pouvez utiliser le logiciel de serveur de quorum Sun Cluster pour configurer un ordinateur en tant que serveur de quorum, puis configurer le serveur de quorum en tant que périphérique de quorum de votre cluster. Vous pouvez utiliser un serveur de quorum à la place ou en plus des disques SCSI et des classeurs NAS.
Lorsque vous envisagez d'utiliser un serveur de quorum dans un environnement Sun Cluster, vous devez tenir compte des points suivants :
Connexion réseau - L'ordinateur de serveur de quorum permet de se connecter à votre cluster via le réseau public.
Matériel pris en charge - Les plates-formes matérielles prises en charge pour un serveur de quorum sont les mêmes que pour un nœud de cluster.
Système d'exploitation - La configuration logicielle de Solaris pour le logiciel Sun Cluster s'applique également au logiciel de serveur de quorum.
Service pour plusieurs clusters - Vous pouvez configurer un serveur de quorum en tant que périphérique de quorum pour plusieurs clusters.
Matériel et logiciel combiné - Vous n'êtes pas obligé de configurer un serveur de quorum sur les mêmes plates-formes matérielles et logicielles les clusters auxquels il fournit le quorum. Par exemple, un ordinateur SPARC exécutant le SE Solaris peut être configuré en tant que serveur de quorum pour un cluster x86 exécutant le SE Solaris 10.
Utilisation d'un nœud de cluster en tant que serveur de quorum - Vous pouvez configurer un serveur de quorum sur un nœud de cluster afin de fournir le quorum aux clusters autres que le cluster auquel le nœud appartient. Cependant, un serveur de quorum configuré sur un nœud de cluster n'est pas hautement disponible.
Lorsque vous envisagez d'utiliser le système NFS (Network File System) dans un environnement Sun Cluster, vous devez tenir compte des points suivants :
Client NFS : 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.
Protocole NFSv3 : si vous montez des systèmes de fichiers sur des nœuds de cluster à partir de serveurs NFS externes, comme des filtres NAS, et que vous utilisez le protocole NFSv3, vous ne pouvez pas procéder à des montages client NFS et du service de données Sun Cluster HA pour NFS sur le même nœud de cluster. Dans ce cas, certaines tâches du service de données Sun Cluster HA pour NFS peuvent entraîner l'arrêt et le redémarrage des démons NFS, interrompant ainsi des services NFS. Vous pouvez cependant exécuter le service de données Sun Cluster HA pour NFS en toute sécurité si vous utilisez le protocole NFSv4 pour monter des systèmes de fichiers NFS externes sur les nœuds de cluster.
Blocage : 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 blocage (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.
Fonctions de sécurité NFS : 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 plus d'informations, reportez-vous à Securing Sun Cluster HA for NFS With Kerberos V5 du Sun Cluster Data Service for NFS Guide for Solaris OS.
Veillez à respecter les restrictions de service suivantes dans les environnements Sun Cluster :
Routeurs - 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.
NIS+ serveurs - Ne configurez pas nœuds de cluster en tant que serveurs NIS ou NIS+. Il n'existe aucun service de données disponible pour NIS ou NIS+. Les nœuds de cluster peuvent toutefois être des clients NIS ou NIS+.
Serveurs d'initialisation et d'installation : n'utilisez pas une configuration Sun Cluster pour fournir un service d'initialisation ou d'installation à haute disponibilité sur des systèmes clients.
RARP - N'utilisez pas de configuration Sun Cluster pour fournir un service rarpd.
numéros de programme RPC - Si vous installez un service RPC sur le cluster, le 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.
Classes de programmation - Le logiciel Sun Cluster ne prend pas en charge l'exécution de classes de programmation à processus de haute priorité sur les nœuds de 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. D'autres 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 CPU requis.
Cette rubrique fournit des instructions pour les composants de Sun Cluster suivants que vous configurez.
Ajoutez ces informations à la fiche de configuration appropriée.
Nommez le cluster au cours de la configuration de Sun Cluster. Ce nom doit être unique dans toute l'entreprise.
Le nom du nœud de cluster est celui que vous affectez à une machine lorsque vous l'installez avec le système d'exploitation Solaris. Reportez-vous à la page de manuel hosts(4) pour plus d'informations sur les exigences d'attribution de nom.
Dans les installations de cluster à un nœud, le nom par défaut du cluster est celui du nœud.
Pendant la configuration de Sun Cluster, indiquez le nom de tous les nœuds que vous installez dans le cluster.
Sous Solaris 10, la convention d'attribution du nom nodename :zonename vous permet de spécifier une zone non globale à une commande Sun Cluster.
nodename est le nom du nœud de cluster.
zonename est le nom attribué à la zone non globale à la création de la zone sur le nœud. Le nom de zone doit être unique sur le nœud. Vous pouvez cependant utiliser le même nom de zone sur différents nœuds car le nom de nœud différent nodename:zonename rend le nom de la zone non globale unique dans le cluster.
Pour spécifier la zone globale, ne spécifiez que le nom de nœud.
vous n'avez pas besoin de configurer un réseau privé pour un cluster à noeud unique. L'utilitaire scinstall attribue automatiquement l'adresse réseau privé et le masque réseau par défaut, même si le cluster n'utilise pas de réseau privé.
Sun Cluster utilise le réseau privé pour la communication interne entre les nœuds et entre les zones non globales gérés par Sun Cluster. La configuration de Sun Cluster nécessite au moins deux connexions pour procéder à l'interconnexion du cluster sur le réseau privé. Lorsque vous configurez Sun Cluster sur le premier nœud du cluster, spécifiez l'adresse réseau privé et le masque réseau de l'une des manières suivantes :
Acceptez l'adresse réseau privé (172.16.0.0) et le masque réseau (255.255.248.0) par défaut. Cette plage d'adresses IP accepte un maximum combiné de 64 nœuds et zones non globales et un maximum de 10 réseaux privés.
Le nombre maximum de nœuds pouvant être accepté par une plage d'adresses IP ne représente pas le nombre maximum de nœuds que la configuration matérielle peut prendre en charge.
Spécifiez une autre adresse réseau privé autorisée et acceptez le masque réseau par défaut.
Acceptez l'adresse réseau privé par défaut et spécifiez un autre masque réseau.
Spécifiez une autre adresse réseau privé et un autre masque réseau.
Si vous choisissez de spécifier un autre masque réseau, l'utilitaire scinstall vous invite à indiquer le nombre de nœuds et de réseaux privés pouvant être acceptés par la plage d'adresses IP. Le nombre de nœuds spécifié doit également inclure le nombre de zones non globales que le réseau privé pourra utiliser.
L'utilitaire calcule le masque réseau pour la plage d'adresses IP minimum qui prendra en charge le nombre de nœuds et de réseaux privés spécifié. Le masque réseau calculé peut prendre en charge plus que le nombre de nœuds fourni, zones non globales incluses, et de réseaux privés. L'utilitaire scinstall calcule également un second masque réseau qui pourrait être le minimum pour prendre en charge deux fois le nombre de nœuds et de réseaux privés. Ce second masque réseau pourrait permettre au cluster d'accepter une croissance future sans devoir reconfigurer la plage d'adresses IP.
L'utilitaire vous demande ensuite le masque réseau souhaité. Vous pouvez spécifier l'un des masques réseau calculés ou en fournir un autre. Le masque réseau spécifié doit au minimum prendre en charge le nombre de nœuds et de réseaux privés indiqué à l'utilitaire.
Pour modifier l'adresse réseau privé et le masque réseau après l'établissement du cluster, reportez-vous à la rubrique How to Change the Private Network Address or Address Range of an Existing Cluster du Sun Cluster System Administration Guide for Solaris OS. Vous devez arrêter le cluster pour apporter ces modifications.
Une modification de la plage d'adresses IP privées peut être nécessaire pour prendre en charge l'ajout de nœuds, zones non globales incluses, ou de réseaux privés.
Si vous indiquez une adresse de réseau privé différente de l'adresse par défaut, elle doit répondre aux exigences suivantes :
Taille d'adresse et de masque réseau : l'adresse réseau privé ne peut pas être inférieure au masque réseau. Par exemple, vous pouvez utiliser l'adresse réseau privé 172.16.10.0 avec le masque réseau 255.255.255.0, mais vous ne pouvez pas utiliser l'adresse réseau privé 172.16.10.0 avec le masque réseau 255.255.0.0.
Adresses acceptables - L'adresse doit figurer dans un 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.
Utiliser dans plusieurs clusters : vous pouvez utiliser la même adresse réseau privé dans plusieurs clusters. Les adresses de réseaux IP privés ne sont pas accessibles de l'extérieur du cluster.
IPv6 - 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.
Reportez-vous à Planifier votre réseau TCP/IP (Tâches), dans le Manuel d'administration système : Services IP (Solaris 9 ou Solaris 10) pour plus d'informations sur les réseaux 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é. Ils sont créés automatiquement lors de la configuration de Sun Cluster. Il sont conformes à la convention d'attribution de nom nœud de clusternodeid -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 clsetup(1CL).
Sous Solaris 10, la création d'un nom d'hôte privé pour une zone non globale est facultative. Il n'existe pas de convention d'attribution de nom pour l'hôte privé d'une zone non globale.
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 un commutateur de transport
Pour plus d'informations sur la finalité et la fonction de l'interconnexion de cluster, reportez-vous à la rubrique Cluster Interconnect du Sun Cluster Concepts Guide for Solaris OS.
vous n'avez pas besoin de configurer une interconnexion de cluster pour un cluster à noeud unique. Cependant, si vous prévoyez d'ajouter par la suite des noeuds à une configuration de cluster à noeud unique, vous souhaiterez probablement configurer l'interconnexion de cluster pour une utilisation future.
Pendant la configuration de Sun Cluster, spécifiez les informations de configuration de une ou deux interconnexions de cluster.
L'utilisation de deux interconnexions de cluster offre une plus grande disponibilité. Si le nombre de ports d'adaptateur disponibles est limité, vous pouvez utiliser des VLANs marqués pour que le réseau public et le réseau privé partagent le même adaptateur. Pour plus d'informations, reportez-vous aux recommandations sur les adaptateurs VLAN marqués dans la rubrique Adaptateurs de transport.
L'utilisation d'une interconnexion de cluster permet de réduire le nombre de ports d'adaptateur utilisés pour l'interconnexion privée mais offre une moins grande disponibilité. En outre, le cluster passe moins de temps en recupération automatique si l'interconnexion privée unique échoue.
Vous pouvez configurer les interconnexions de cluster supplémentaires lorsque le cluster est établi à l'aide de l'utilitaire clsetup(1CL).
Pour obtenir des recommandations sur le matériel d'interconnexion de cluster, reportez-vous à la rubrique Interconnect Requirements and Restrictions du Sun Cluster 3.1 - 3.2 Hardware Administration Manual for Solaris OS. Pour des informations générales sur l'interconnexion de cluster, reportez-vous à Cluster-Interconnect Components du Sun Cluster Overview for Solaris OS et au Sun Cluster Concepts Guide for Solaris OS.
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 point-à-point ou si elle utilise un commutateur de transport.
Tenez compte des instructions et restrictions suivantes :
IPv6 - Le logiciel 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 marqués – Le logiciel Sun Cluster prend en charge les réseaux VLAN (Virtual Local Area Networks) marqués 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 de cluster, 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 VID 73 sur l'adaptateur ce2, le numéro d'instance VLAN calculé pourrait être (1000*73)+2. Vous pourriez alors attribuer à l'adaptateur le nom ce73002 pour indiquer qu'il fait partie d'un LAN virtuel partagé.
Pour plus d'informations sur la configuration d'un VLAN dans un cluster, reportez-vous à Configuring VLANs as Private Interconnect Networks du Sun Cluster 3.1 - 3.2 Hardware Administration Manual for Solaris OS. Pour plus d'informations sur les VLAN, reportez-vous à Administering Virtual Local Area Networks du System Administration Guide: IP Services.
adaptateurs SBus SCI – 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).
Si vous utilisez des commutateurs de transport, tels que commutateur réseau, indiquez un nom de commutateur de transport pour chaque interconnexion. Vous pouvez utiliser le nom par défaut switchN, où N est un numéro automatiquement assigné pendant la configuration ou créer un autre nom.
Indiquez également le nom du port de commutateur ou acceptez le nom par défaut. Le nom de port par défaut est identique à l'ID de noeud interne du noeud 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.
Les clusters à trois nœuds ou plus doivent utiliser des commutateurs de transport. La connexion directe entre les noeuds de cluster est possible uniquement pour les clusters à deux noeuds.
Si votre cluster à deux nœuds utilise une connexion directe, vous pouvez toujours spécifier un commutateur de transport pour l'interconnexion.
Si vous le faites, il sera plus facile d'ajouter un autre nœud au cluster à l'avenir.
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 noeud, le périphérique de quorum évite les problèmes “d'amnésie” ou de dédoublement lorsque le noeud tente de rejoindre le cluster. Pour plus d'informations sur la finalité et la fonction des périphériques de quorum, reportez-vous à la rubrique Quorum and Quorum Devices du Sun Cluster Concepts Guide for Solaris OS.
Pendant que Sun Cluster installe un cluster à deux nœuds, vous pouvez choisir de laisser l'utilitaire scinstall configurer automatiquement un périphérique de quorum SCSI ou un périphérique Sun NAS. Vous pouvez choisir ce périphérique de quorum à partir des disques de stockage SCSI disponibles et des périphériques Sun NAS. L'utilitaire scinstall suppose que tous les disques de stockage partagés et disponibles peuvent être utilisés comme périphériques de quorum.
Si vous souhaitez utiliser un serveur de quorum ou un périphérique Network Appliance NAS en tant que périphérique de quorum, configurez-le une fois le traitement scinstall terminé.
Après l'installation, vous pouvez également configurer d'autres périphériques de quorum à l'aide de l'utilitaire clsetup(1CL).
vous n'avez pas besoin de configurer des périphériques de quorum pour un cluster à noeud unique.
Si votre configuration de cluster ne vous autorise pas à utiliser des périphériques partagés de stockage tiers comme périphériques de quorum, vous devez exécuter l'utilitaire clsetup 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 comprendre au moins un périphérique de quorum, qui peut être un disque SCSI partagé, un serveur de quorum ou un périphérique NAS. 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.
Distribution de votes de quorum : pour une meilleure disponibilité du cluster, veillez à ce que le nombre total de votes associés aux périphériques de quorum soit inférieur au nombre total de votes associés aux nœuds. Sinon, vos nœuds ne pourraient pas constituer un cluster en cas d'indisponibilité de tous les périphériques de quorum, et ce même si tous les nœuds fonctionnent.
Connexion : vous devez connecter un périphérique de quorum à deux nœuds au moins.
protocole de séparation SCSI – Lorsqu'un périphérique de quorum SCSI est configuré, son protocole SCSI est automatiquement défini sur SCSI-2 dans un cluster à deux nœuds ou sur SCSI-3 dans un cluster à trois nœuds ou plus. Vous ne pouvez pas modifier le protocole SCSI d'un périphérique après qu'il a été configuré en tant que périphérique de quorum.
Périphériques répliqués – Le logiciel Sun Cluster ne prend pas en charge les périphériques répliqués en tant que périphériques de quorum.
pools de stockage ZFS - N'ajoutez pas de périphérique de quorum configuré à un pool de stockage ZFS. Lorsqu'un périphérique de quorum configuré est ajouté à un pool de stockage ZFS, le disque est redésigné en tant que disque EFI et les informations de configuration de quorum sont perdues. Le disque ne peut plus fournir de vote de quorum au cluster.
Vous pouvez configurer un disque en tant que périphérique de quorum une fois placé dans un pool de stockage. Vous pouvez également annuler la configuration du périphérique de quorum, l'ajouter au pool de stockage, puis reconfigurer le disque en tant que périphérique de quorum.
Pour plus d'informations sur les périphériques de quorum, reportez-vous aux rubriques Quorum and Quorum Devices du Sun Cluster Concepts Guide for Solaris OS et Quorum Devices du Sun Cluster Overview for Solaris OS.