Cette rubrique indique comment planifier et préparer les composants présentés ci-dessous pour l'installation du logiciel Sun Cluster.
Pour de plus amples informations sur les composants Sun Cluster, reportez-vous au document Guide des notions fondamentales de Sun Cluster 3.1 10/03.
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 de plus amples informations sur les patchs éventuellement requis, reportez-vous à la rubrique “Patches and Required Firmware Levels” in Notes de version de Sun Cluster 3.1 10/03 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” in Sun Cluster 3.1 10/03 System Administration Guide.
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 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 nécessitant l'affectation d'une adresse IP. Ajoutez ces adresses IP à tous les services d'attribution de noms utilisés. Ajoutez-les également au fichier local /etc/inet/hosts sur chaque noeud de 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 de l'IPMP, reportez-vous au document IP Network Multipathing Administration Guide.
Vous devez disposer d'un accès par console à l'ensemble des noeuds 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 noeuds 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 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 Guide des notions fondamentales de Sun Cluster 3.1 10/03.
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 3.1 Data Service Planning and Administration Guide.
Pour de plus amples informations sur les ressources et les services de données, reportez-vous également au document Guide des notions fondamentales de Sun Cluster 3.1 10/03.
Cette rubrique fournit des instructions pour les composants de Sun Cluster suivants que vous configurez pendant l'installation.
Ajoutez ces informations de planification à la Fiche de travail relative aux noms des noeuds et du cluster.
Nommez le cluster au cours de l'installation de Sun Cluster. Ce nom doit être unique dans toute l'entreprise.
Ajoutez ces informations de planification à la Fiche de travail relative aux noms des noeuds et du cluster. Les informations de la plupart des autres fiches de travail sont groupées par nom de noeud.
Le nom de noeud est le nom que vous affectez à une machine lorsque vous installez l'environnement d'exploitation Solaris. Pendant l'installation de Sun Cluster, indiquez le nom de tous les noeuds que vous installez en tant que noeuds de cluster. Dans les installations à noeud unique, le nom du noeud par défaut est celui du cluster.
Ajoutez ces informations de planification à la Fiche de travail relative aux noms des noeuds et du cluster.
vous n'avez pas besoin de configurer un réseau privé pour un cluster à noeud unique.
Le logiciel Sun Cluster utilise le réseau privé pour les communications internes entre les noeuds. 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 installez le logiciel Sun Cluster sur le premier noeud du cluster. Vous pouvez accepter l'adresse de réseau privé (172.16.0.0) et le masque de réseau (255.255.0.0) par défaut ou en saisir d'autres si cette adresse est déjà utilisée dans l'entreprise.
après avoir installé le noeud en tant que membre de cluster, vous ne pouvez plus modifier l'adresse de réseau privé et le masque de réseau.
Si vous indiquez une adresse de réseau privé différente de l'adresse par défaut, elle doit répondre aux exigences suivantes :
Les deux derniers octets de l'adresse doivent être nuls.
L'adresse doit respecter les instructions de la RFC 1597 pour l'affectation des adresses réseau.
Vous pouvez contacter l'InterNIC pour obtenir des exemplaires d'RFC. 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 (Task)” in System Administration Guide: IP Services (Solaris 9) pour obtenir des instructions.
Si vous spécifiez un masque de réseau différent du masque par défaut, il doit masquer au minimum tous les bits fournis dans l'adresse du réseau privé.
Ajoutez ces informations de planification à la Fiche de travail relative aux noms des noeuds et du cluster.
Le nom d'hôte privé est le nom utilisé pour la communication entre les noeuds sur l'interface de réseau privé. Ils sont créés automatiquement lors de l'installation de Sun Cluster. Ces noms d'hôtes privés sont conformes à la convention d'attribution de noms clusternodeid_noeud-priv , où id_noeud est le numéral de l'ID du noeud interne. Lors de l'installation de Sun Cluster, ce numéro d'ID est affecté automatiquement à chaque noeud dès lors qu'il devient membre du cluster. Après l'installation, vous pouvez renommer les noms d'hôtes privés à l'aide de l'utilitaire scsetup(1M).
Ajoutez ces informations de planification à la Fiche de travail relative à l'interconnexion de cluster
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.
Les interconnexions de cluster fournissent les voies matérielles pour la communication en réseau privé entre les noeuds 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 l'installation 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 est un cluster à deux noeuds, vous devez également indiquer si votre interconnexion est connectée directement (adaptateur à adaptateur) ou utilise une jonction de transport. Si votre cluster à deux noeuds 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 noeud au cluster à l'avenir.
Reportez-vous aux pages du manuel 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, telles qu'un commutateur de réseau, indiquez le nom d'une jonction de transport pour chaque interconnexion. Vous pouvez utiliser le nom par défaut switchN, où N est un numéro affecté automatiquement à l'installation, ou créer un autre nom.
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 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 noeuds ou plus doivent utiliser des jonctions de transport. La connexion directe entre les noeuds de cluster est possible uniquement pour les clusters à deux noeuds.
Vous pouvez configurer des connexions supplémentaires au réseau privé après l'installation à l'aide de l'utilitaire scsetup(1M).
Pour de plus amples informations sur l'interconnexion de cluster, reportez-vous au document Guide des notions fondamentales de Sun Cluster 3.1 10/03.
Ajoutez ces informations de planification à la Fiche de travail relative aux 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 privés (interconnexion de cluster) doivent utiliser des adaptateurs distincts.
Vous devez avoir au moins un réseau public connecté à tous les noeuds de cluster.
Vous pouvez avoir autant de connexions supplémentaires au réseau public que votre configuration matérielle le permet.
La variable local-mac-address? doit utiliser la valeur true par défaut pour les adaptateurs Ethernet. Le logiciel Sun Cluster 3.1 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 valeur local-mac-address? false.
Reportez-vous à la rubrique Groupes IPMP pour de plus amples informations sur la planification de groupes d'adaptateurs de réseau public de secours. Pour de plus amples informations sur les interfaces de réseau public, reportez-vous au document Guide des notions fondamentales de Sun Cluster 3.1 10/03.
Ajoutez ces informations de planification à la Fiche de travail relative aux configurations des groupes de périphériques de disques.
Vous devez configurer tous les groupes de disques du gestionnaire de volumes en tant que groupes de périphériques de disques Sun Cluster. Cette configuration permet à des disques multihôtes d'être hébergés par un noeud secondaire en cas de panne du noeud principal. Tenez compte des points suivants lorsque vous planifiez des groupes de périphériques de disques.
Reprise sur panne : vous pouvez configurer des disques multiports et des périphériques du gestionnaire de volumes configurés correctement en tant que périphériques de reprise sur panne. La configuration correcte d'un périphérique du gestionnaire de volumes comprend des disques multiports et une installation correcte du gestionnaire de volumes lui-même. Cette configuration garantit que les noeuds multiples peuvent héberger le périphérique exporté. Il est impossible de configurer des lecteurs de bandes, des CD ou des disques à un seul port comme des périphériques de reprise sur panne.
Mise en miroir : vous devez mettre les disques en miroir pour protéger les données en cas de panne de disque. Pour de plus amples informations sur la mise en miroir, reportez-vous aux rubriques Recommandations relatives à la mise en miroir, Installation et configuration du logiciel Solstice DiskSuite/Solaris Volume Manager et Installation et configuration du logiciel VxVM, ainsi qu'à la documentation de votre gestionnaire de volumes.
Pour de plus amples informations sur les groupes de périphériques de disques, reportez-vous au document Guide des notions fondamentales de Sun Cluster 3.1 10/03.
Ajoutez ces informations de planification à la Fiche de travail relative aux réseaux publics.
Les groupes IPMP, 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 multi-acheminement.
Pour les groupes de multi-acheminement contenant au moins deux adaptateurs, il faut configurer une adresse IP de test pour chaque adaptateur du groupe. 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 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, ne modifiez pas la valeur de TRACK_INTERFACES_ONLY_WITH_GROUPS de yes pour no.
Le nom d'un groupe de multi-acheminement ne fait l'objet d'aucune exigence ni restriction.
Pour de plus amples informations sur l'IPMP, reportez-vous à la rubrique “Deploying Network Multipathing” du document IP Network Multipathing Administration Guide (Solaris 8) ou à la rubrique“Administering Network Multipathing (Task)” in System Administration Guide: IP Services (Solaris 9).
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 affecter des périphériques de quorum, lancez l'utilitaire scsetup(1M).
vous n'avez pas besoin de configurer des périphériques de quorum pour un cluster à noeud unique.
Tenez compte des points suivants lorsque vous planifiez des périphériques de quorum.
Minimum : un cluster à deux noeuds doit avoir au moins un disque partagé affecté en tant que périphérique de quorum. Pour les autres topologies, les périphériques de quorum sont facultatifs.
La règle du nombre impair : si plus d'un périphérique de quorum est configuré dans un cluster à deux noeuds, ou dans plusieurs noeuds directement connectés à un périphérique de quorum, configurez un nombre impair de périphériques de quorum. 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 noeuds au moins.
Pour de plus amples informations sur les périphériques de quorum, reportez-vous au document Guide des notions fondamentales de Sun Cluster 3.1 10/03.