Cette section explique comment planifier et préparer l'installation du logiciel Sun Cluster. Pour obtenir des informations détaillées sur les composants de Sun Cluster, reportez-vous au document Sun Cluster 3.0 Concepts.
Assurez-vous de bien avoir 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 la liste des patchs nécessaires, reportez-vous au document Notes de version de Sun Cluster 3.0 ou consultez votre interlocuteur Enterprise Services ou votre prestataire de services. Reportez-vous au document Guide d'administration système de Sun Cluster 3.0 pour les instructions et procédures générales d'application des patchs.
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 également ces adresses IP au fichier local /etc/inet/hosts sur chaque noeud de cluster après l'installation du logiciel Sun Cluster.
Tableau 1-3 Composants de Sun Cluster utilisant des adresses IP
Composant |
Adresses IP nécessaires |
---|---|
Console administrative |
1 par sous-réseau |
Noeuds de cluster |
1 par noeud et par sous-réseau |
Concentrateur de terminal ou processeur de services système (SSP) |
1 |
Adresses logiques |
1 par ressource d'host logique et par sous-réseau |
Un concentrateur de terminal assure la communication entre la console administrative et les consoles de noeuds de cluster. Les serveurs Sun EnterpriseTM E10000 n'utilisent pas un concentrateur de terminal, mais un processeur de services système (ou SSP - System Service Processor). Pour plus d'informations sur l'accès aux consoles, reportez-vous à Sun Cluster 3.0 Concepts.
Chaque groupe de ressources de service de données qui utilise une adresse logique doit avoir un nom d'host spécifié pour chaque réseau public à partir duquel l'adresse logique est accessible. Reportez-vous au Sun Cluster 3.0 Data Services Installation and Configuration Guide pour obtenir des informations et des fiches de travail pour la planification des groupes de ressources. Pour plus d'informations sur les services de données et les ressources, reportez-vous également à Sun Cluster 3.0 Concepts.
Cette section fournit des instructions pour les composants de Sun Cluster que vous configurez pendant l'installation.
Ajoutez ces informations de planification à la fiche de travail relative aux noms de noeud et de cluster, disponible dans le document Notes de version de Sun Cluster 3.0.
Vous indiquez un nom pour le cluster pendant 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 de noeud et de cluster, disponible dans le document Notes de version de Sun Cluster 3.0. 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 pendant l'installation de l'environnement d'exploitation Solaris. Pendant l'installation de Sun Cluster, vous indiquez le nom de tous les noeuds que vous installez en tant que noeuds de cluster.
Ajoutez ces informations de planification à la fiche de travail relative aux noms de noeud et de cluster, disponible dans le document Notes de version de Sun Cluster 3.0.
Le logiciel Sun Cluster utilise le réseau privé pour les communications internes entre les noeuds. Il nécessite au moins deux connexions vers l'interconnexion de cluster sur le réseau privé. Vous indiquez l'adresse de réseau privé et le netmask pendant l'installation du logiciel Sun Cluster sur le premier noeud du cluster. Vous pouvez accepter l'adresse de réseau privé (172.16.0.0) et le netmask (255.255.0.0) par défaut ou taper des choix différents si cette adresse est déjà utilisée dans l'entreprise.
Après avoir installé le noeud en tant que membre du cluster, vous ne pouvez plus modifier l'adresse de réseau privé et le netmask.
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 d'adresses réseau.
Reportez-vous au document TCP/IP and Data Communications Administration Guide pour savoir comment obtenir des copies des RFC.
Si vous indiquez un netmask différent de celui fourni par défaut, il doit répondre aux exigences suivantes :
Masquer au moins tous les bits fournis dans l'adresse de réseau privé.
N'avoir aucun "trou".
Ajoutez ces informations de planification à la fiche de travail relative aux interconnexions de cluster fournie dans le document Notes de version de Sun Cluster 3.0.
L'interconnexion de cluster fournit les composants matériels nécessaires aux noeuds du cluster pour communiquer sur un réseau privé. Chaque interconnexion se compose d'un câble entre deux adaptateurs de transport, entre un adaptateur de transport et une jonction de transport, ou entre deux jonctions de transport. Lors de l'installation de Sun Cluster, vous fournissez des informations de configuration pour deux interconnexions de cluster.
Adaptateurs de transport : pour les adaptateurs de transport, tels que les ports sur les interfaces réseau, indiquez les noms des adaptateurs de transport et 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.
Jonctions de transport : si vous utilisez des jonctions de transport, par exemple un commutateur réseau, indiquez leurs noms pour chaque interconnexion. Le nom par défaut est switchN, oy N est un nombre affecté automatiquement lors de l'installation. 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 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.
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 plus d'informations sur les interconnexions de cluster, reportez-vous au document Sun Cluster 3.0 Concepts.
Ajoutez ces informations de planification à la fiche de travail relative aux noms de noeud et de cluster, disponible dans le document Notes de version de Sun Cluster 3.0.
Le nom d'host privé est le nom utilisé pour la communication entre les noeuds sur l'interface de réseau privé. Les noms d'host privés sont créés automatiquement lors de l'installation de Sun Cluster et respectent la convention de désignation clusternodeid_noeud-priv, oy id_noeud est le numéro de l'ID de noeud interne. Ce numéro est affecté automatiquement lors de l'installation de Sun Cluster pour chaque noeud qui devient membre du cluster. Après l'installation, vous pouvez modifier les noms d'host privés à l'aide de l'utilitaire scsetup(1M).
Ajoutez ces informations de planification à la fiche de travail relative aux réseaux publics, disponible dans le document Notes de version de Sun Cluster 3.0.
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.
Reportez-vous également à la section "Groupes NAFO" pour plus d'informations sur la planification de groupes d'adaptateurs de réseau public de secours. Pour plus d'informations sur les interfaces de réseau public, reportez-vous au document Sun Cluster 3.0 Concepts.
Ajoutez ces informations de planification à la fiche de travail relative aux configurations des groupes d'unités de disque, disponible dans le document dans Notes de version de Sun Cluster 3.0.
Vous devez configurer tous les groupes de disques du gestionnaire de volumes en tant que groupes d'unités de disque Sun Cluster. Cette configuration permet à des disques multihosts 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 d'unités de disque :
Reprise sur panne : vous pouvez configurer des disques multiports et des unités du gestionnaire de volumes configurés correctement en tant qu'unités de reprise sur panne. La configuration d'une unité du gestionnaire de volumes est correcte lorsqu'elle inclut des disques multiports et un réglage correct du gestionnaire de volumes lui-même de manière que le périphérique exporté puisse être hébergé par plusieurs noeuds. Il est impossible de configurer des lecteurs de bandes, des CD-ROM ou des disques monoports en tant qu'unités 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. Reportez-vous à la documentation de votre gestionnaire de volumes pour plus d'informations sur la mise en miroir.
Pour plus d'informations sur les groupes d'unités de disque, reportez-vous au document Sun Cluster 3.0 Concepts.
Ajoutez ces informations de planification à la fiche de travail relative aux réseaux publics, disponible dans le document Notes de version de Sun Cluster 3.0.
Un groupe NAFO (reprise sur panne de l'adaptateur réseau) permet la surveillance et la reprise sur panne des adaptateurs de réseau public. Il constitue la base des ressources d'adresse réseau. En cas de panne de l'adaptateur actif d'un groupe NAFO comportant plusieurs adaptateurs, toutes ses adresses sont transférées sur un autre adaptateur du groupe NAFO. De cette manière, l'adaptateur du groupe NAFO peut maintenir la connectivité de réseau public vers le sous-réseau auquel les adaptateurs du groupe NAFO se connectent.
Tenez compte des points suivants lorsque vous planifiez vos groupes NAFO :
Chaque adaptateur de réseau public doit appartenir à un groupe NAFO.
Chaque noeud ne peut comporter qu'un groupe NAFO par sous-réseau.
Un seul adaptateur dans un groupe NAFO donné peut avoir une association de nom d'host, sous la forme d'un fichier /etc/hostname.adaptateur.
La convention de désignation du groupe NAFO est nafoN, oy N est le numéro fourni lors de la création du groupe NAFO.
Pour plus d'informations sur la reprise sur panne des adaptateurs réseau, reportez-vous au document Sun Cluster 3.0 Concepts.
Les configurations 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).
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.
Règle du nombre impair : si vous configurez plus d'un périphérique de quorum dans un cluster à deux noeuds ou dans une paire de noeuds connectée directement au périphérique de quorum, configurez un nombre impair de périphériques de quorum ayant chacun des chemins de panne complètement indépendants.
Connexion : un périphérique de quorum ne peut pas être connecté à plus de deux noeuds.
Pour plus d'informations sur le quorum, reportez-vous au document Sun Cluster 3.0 Concepts.