Cette rubrique indique comment planifier et préparer les composants ci-dessous pour l'installation et la configuration du logiciel Sun Cluster.
Pour obtenir des informations détaillées sur les composants Sun Cluster, consultez les documents 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 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 documentations d'installation de ces produits.
Après avoir installé chacun des logiciels, vous devez également installer les patchs éventuellement requis.
Pour de plus amples informations sur les patchs éventuellement requis, reportez-vous à la rubrique “Patches and Required Firmware Levels” du document Sun Cluster Release Notes for Solaris OS ou consultez votre prestataire de services Sun.
Pour obtenir des instructions et des procédures générales sur l'application des patchs, reportez-vous à la rubrique “Patching Sun Cluster Software and Firmware” du document Sun Cluster System Administration Guide for Solaris OS.
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 suivant répertorie les composants nécessitant l'affectation d'une adresse IP. Ajoutez ces adresses IP à tous les services d'attribution de noms utilisés. Ajoutez également ces adresses IP au fichier /etc/inet/hosts local sur chacun des nœuds du cluster après avoir installé le logiciel Solaris.
Pour de plus amples informations sur les adresses IP, reportez-vous aux documents System Administration Guide, Volume 3 (Solaris 8) ou System Administration Guide: IP Services (Solaris 9).
Pour de plus amples informations sur les adresses IP de test pour la prise en charge du Multiacheminement sur réseau IP, reportez-vous au document IP Network Multipathing Administration Guide.
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 FireTM utilise un contrôleur de système au lieu d'un concentrateur de terminal.
Pour de plus amples informations sur l'accès aux consoles, reportez-vous au document Sun Cluster Concepts Guide for Solaris OS.
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 de plus amples informations, reportez-vous au document Sun Cluster Data Service Planning and Administration Guide for Solaris OS.
Pour de plus amples informations sur les ressources et les services de données, reportez-vous également aux documents 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.
Les réseaux publics et privés (interconnexion de cluster) doivent utiliser des adaptateurs distincts.
Vous devez avoir au moins un réseau public connecté à tous les nœuds de cluster.
Vous pouvez disposer d'autant de connexions supplémentaires au réseau public que votre configuration matérielle le permet.
Le logiciel Sun Cluster prend en charge les adresses IPv4 et IPv6 sur le réseau public dans le cadre des services de données évolutifs ou de basculement. En revanche, il ne prend pas en charge les communications IPv6 sur réseaux privés.
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.
Au cours de l'installation de Sun Cluster, l'utilitaire scinstall configure automatiquement un groupe Multiacheminement sur réseau IP à adaptateur unique pour chacun des adaptateurs du réseau public. Pour modifier ces groupes de secours une fois l'installation effectuée, suivez la procédure indiquée sous la rubrique “Deploying Network Multipathing” du document IP Network Multipathing Administration Guide (Solaris 8) ou sous la rubrique “Administering Network Multipathing (Task)” du System Administration Guide: IP Services (Solaris 9).
Voir la rubrique Groupes Multiacheminement sur réseau IP pour obtenir des instructions sur la planification de groupes de sauvegarde d'adaptateurs de réseau public. Pour de plus amples informations sur les interfaces de réseau public, reportez-vous au document Sun Cluster Concepts Guide for Solaris OS.
Lorsque vous envisagez d'utiliser le système NFS (Network File System) dans un environnement Sun Cluster, vous devez prendre en considération les points suivants :
Aucun nœud Sun Cluster ne peut être le client NFS d'un système de fichiers exporté Sun Cluster HA pour NFS contrôlé sur un nœud du même cluster. Un tel montage croisé de Sun Cluster HA pour NFS est interdit. Utilisez le système de fichiers de 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é par le biais du système NFS. Sinon, un blocage local (par exemple, flock(3UCB) ou fcntl (2)) risque d'empêcher le gestionnaire de verrouillage (lockd) de redémarrer. 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 Secure NFS, ni l'utilisation de Kerberos avec NFS. Plus particulièrement, Sun Cluster ne prend pas en charge les options secure et kerberos dans le sous-système share_nfs(1M).
En revanche, Sun Cluster prend en charge l'utilisation de ports sécurisés avec NFS. Pour en bénéficier, vous devez ajouter l'entrée set nfssrv:nfs_portmon=1 dans le fichier /etc/system sur les nœuds du cluster.
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+. Les nœuds 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 de processus de priorité élevée dans des classes de programmation 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. 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 travail relative à la configuration appropriée.
Tableau 1–4 Fiches de travail relatives à la configuration de Sun Cluster
Fiche de configuration |
Emplacement |
---|---|
Tableau 2–2 (valeurs par défaut) ou Tableau 2–3 (personnalisation) |
Procédure de configuration du logiciel Sun Cluster sur tous les nœuds(scinstall) |
Installation et configuration du logiciel Sun Cluster (SunPlex Installer) |
|
Installation de Solaris et du logiciel Sun Cluster (JumpStart) |
|
Procédure de configuration du logiciel Sun Cluster sur d'autres nœuds du cluster (scinstall) |
Nommez le cluster au cours de la configuration de Sun Cluster. Ce nom doit être unique dans toute l'entreprise.
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 à nœud unique, le nom du nœud par défaut est celui du cluster.
vous n'avez pas besoin de configurer un réseau privé pour un cluster à nœud unique.
Le logiciel Sun Cluster utilise le réseau privé pour les communications internes entre les nœuds. La configuration de 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é (172.16.0.0) et le masque de réseau (255.255.0.0) par défaut, soit entrer ceux de votre choix si l'adresse par défaut est déjà utilisée dans l'entreprise.
Une fois l'exécution de l'utilitaire d'installation (scinstall, SunPlex Installer 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 dans le cadre d'interconnexions privées.
Bien que l'utilitaire scinstall vous permette d'indiquer un autre masque de réseau, il est préférable d'accepter celui par défaut, à savoir 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 plus d'informations sur les réseaux privés, reportez-vous à la rubrique “Planning Your TCP/IP Network” du manuel System Administration Guide, Volume 3 (Solaris 8) ou à la rubrique “Planning Your TCP/IP Network (Task)” du manuel System Administration Guide: IP Services (Solaris 9).
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. Ces noms d'hôtes privés sont conformes à la convention d'attribution de noms clusternodeid_nœud-priv, où id_nœud est le numéral 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 membre du cluster. Une fois le cluster configuré, vous pouvez modifier les noms d'hôtes privés à l'aide de l'utilitaire scsetup(1M).
vous n'avez pas besoin de configurer une interconnexion de cluster pour un cluster à nœud unique. Cependant, si vous prévoyez d'ajouter par la suite des nœuds à une configuration de cluster à nœud unique, 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 indiquez les informations de configuration suivantes pour deux interconnexions de clusters.
Adaptateurs de transport : pour les adaptateurs de transport comme les ports ou les interfaces réseau, indiquez le nom des adaptateurs de transport, ainsi que 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. Si votre cluster à deux nœuds utilise une connexion directe, vous pouvez toujours spécifier une jonction de transport pour l'interconnexion.
si vous le faites, il sera plus facile d'ajouter un autre nœud au cluster à l'avenir.
Prenez en considération les instructions et contraintes suivantes :
Adaptateurs SCI SBus : l'interface SCI (Scalable Coherent Interface) SBus n'est pas prise en charge dans le cadre d'une interconnexion en cluster. En revanche, l'interface SCI–PCI l'est.
Interfaces réseau logique : leur utilisation est réservée à Sun Cluster.
Reportez-vous aux pages man scconf_trans_adap_*(1M) pour de plus amples informations sur un adaptateur de transport spécifique.
Jonctions de transport : si vous utilisez des jonctions de transport, par exemple un commutateur réseau, indiquez leur nom 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. L'adaptateur Sun Firelink constitue une exception ; il requiert le nom de jonction sw-rsmN. scinstall utilise automatiquement ce nom de jonction lorsqu'un adaptateur Sun Firelink est spécifié (wrsmN).
Indiquez également le nom du port de 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.
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.
Une fois le cluster établi, vous pouvez configurer des connexions supplémentaires au réseau privé à l'aide de l'utilitaire scsetup(1M).
Pour de plus amples informations concernant l'interconnexion de cluster, reportez-vous à la rubrique “Cluster Interconnect” des documents Sun Cluster Overview for Solaris OS et Sun Cluster Concepts Guide for Solaris OS.
Ajoutez ces informations de planification à la Fiche de travail relative aux réseaux publics.
Les groupes Multiacheminement sur réseau IP, qui remplacent les groupes NAFO (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.
Prenez les points suivants en considération lorsque vous planifiez les groupes IPMP.
Chaque adaptateur de réseau public doit appartenir à un groupe de multiacheminement.
Pour les groupes de multiacheminement contenant au moins deux adaptateurs, il faut configurer une adresse IP de test pour chaque adaptateur du groupe. Si un groupe de multiacheminement contient un seul adaptateur, vous n'avez pas besoin de configurer une adresse IP de test.
Les adresses IP de test pour tous les adaptateurs du même groupe de multi-acheminement doivent appartenir à un seul 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 propriété TRACK_INTERFACES_ONLY_WITH_GROUPS doit être paramétrée sur 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'applique à la fois aux environnements cluster et non-cluster. Pour plus d'informations sur Multiacheminement sur réseau IP, vous pouvez donc vous reporter au document Solaris approprié :
pour le système d'exploitation Solaris 8, voir la rubrique “Deploying Network Multipathing” du manuel IP Network Multipathing Administration Guide ;
pour Solaris 9, voir la rubrique “Administering Network Multipathing (Task)” du manuel System Administration Guide: IP Services.
Consultez également la rubrique “IP Network Multipathing Groups” des documents Sun Cluster Overview for Solaris OS et Sun Cluster Concepts Guide for Solaris OS.
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. Vous pouvez configurer les périphériques de quorum à l'aide de l'utilitaire scsetup(1M).
vous n'avez pas besoin de configurer des périphériques de quorum pour un cluster à nœud unique.
Tenez compte des points suivants lorsque vous planifiez des périphériques de quorum.
Minimum : un cluster à deux nœuds doit disposer d'au moins un disque partagé désigné comme périphérique de quorum. 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 plus d'informations sur les périphériques de quorum, reportez-vous à la rubrique “Quorum and Quorum Devices” du manuel Sun Cluster Concepts Guide for Solaris OS et à la rubrique “ Quorum Devices” du manuel Sun Cluster Overview for Solaris OS.