Chapitre 1 Planification de la configuration Sun Cluster

Ce chapitre fournit des informations et des instructions pour la planification et l'installation d'une configuration Sun Cluster.

Les informations présentées dans ce chapitre sont les suivantes :

• "Emplacement des tâches d'installation de Sun Cluster"

• "Planification de l'environnement d'exploitation Solaris"

• "Planification de l'environnement Sun Cluster"

• "Planification des périphériques globaux et des systèmes de fichiers de grappe"

• "Planification de la gestion des volumes"

Emplacement des tâches d'installation de Sun Cluster

Le tableau suivant indique l'emplacement des instructions pour diverses tâches d'installation de Sun Cluster et l'ordre dans lequel vous devez procéder.

Tableau 1-1 Emplacement des informations sur les tâches d'installation du logiciel Sun Cluster

Tâche			Pour les instructions, voir ...
Installation matérielle de la grappe			Sun Cluster 3.0 12/01 Hardware Guide Documentation fournie avec votre serveur et vos périphériques de stockage
Planification de l'installation du logiciel de grappe			Ce chapitre  "Fiches de configuration de l'installation de Sun Cluster et exemples" dans Notes de version de Sun Cluster 3.0 12/01
Installation d'une nouvelle grappe ou ajout de noeuds à une grappe existante
	Installation de l'environnement d'exploitation Solaris, du logiciel Cluster Control Panel (facultatif), de SunPlex Manager (facultatif), de la structure logicielle de la grappe et des modules logiciels de services de données		"Installation du logiciel"
	Installation et configuration du logiciel de gestion des volumes
		Solstice DiskSuite	"Installation et configuration du logiciel Solstice DiskSuite" Documentation Solstice DiskSuite
		VERITAS Volume Manager (VxVM)	"Installation et configuration du logiciel VxVM" Documentation VxVM
	Configuration de la structure logicielle de la grappe et, en option, installation et configuration de Sun Management Center		"Configuration de la grappe"
	Planification, installation et configuration des services de données et des groupes de ressources		Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide "Fiches de configuration des services de données et exemples" dans Notes de version de Sun Cluster 3.0 12/01
Mise à niveau de Sun Cluster 2.2 à Sun Cluster 3.0 (environnement d'exploitation Solaris, structure de la grappe, services de données et logiciel de gestion des volumes)			"Mise à niveau de Sun Cluster 2.2 à Sun Cluster 3.0 Update 2" "Installation et configuration du logiciel Solstice DiskSuite" ou "Installation et configuration du logiciel VxVM" Documentation du gestionnaire de volumes
Mise à niveau de Sun Cluster 3.0 7/01 (Mise à jour 1) à Sun Cluster 3.0 12/01 (environnement d'exploitation Solaris, structure de la grappe et logiciel de services de données)			"Mise à niveau vers une version mise à jour du logiciel Sun Cluster 3.0 "
Développement de services de données personnalisés			Sun Cluster 3.0 12/01 Data Services Developer's Guide

Planification de l'environnement d'exploitation Solaris

Cette section explique comment planifier l'installation du logiciel Solaris dans une configuration de grappe. Pour de plus amples informations sur le logiciel Solaris, reportez-vous à la documentation d'installation de Solaris.

Choix de la méthode d'installation de Solaris

Vous pouvez installer le logiciel Solaris à partir d'un lecteur de CD-ROM local ou d'un serveur d'installation réseau en utilisant la méthode d'installation JumpStart^TM. En outre, le logiciel Sun Cluster offre une méthode personnalisée permettant d'installer à la fois l'environnement d'exploitation Solaris et le logiciel Sun Cluster avec JumpStart. Si vous installez plusieurs noeuds de grappe, nous vous recommandons une installation en réseau.

Reportez-vous à la section "Installation de Solaris et du logiciel Sun Cluster (JumpStart)" pour de plus amples informations sur la méthode d'installation scinstall de JumpStart. Reportez-vous à la documentation d'installation de Solaris pour de plus amples informations sur les méthodes d'installation standard de Solaris.

A propos des groupes de logiciels Solaris

Le logiciel Sun Cluster 3.0 implique l'installation du groupe de logiciels Solaris End User System Support. Il est possible que d'autres composants de la configuration de votre grappe requièrent leurs propres logiciels Solaris. Prenez connaissance des informations ci-dessous pour déterminer le groupe de logiciels Solaris que vous devez installer.

• Reportez-vous à la documentation de votre serveur pour connaître la configuration minimale requise par Solaris. Par exemple, les serveurs Sun Enterprise^TM E10000 requièrent l'installation du groupe de logiciels Entire Distribution + OEM.

• Si vous installez l'environnement d'exploitation Solaris 8 Update 6 et envisagez d'utiliser des adaptateurs SCI-PCI ou l'interface Remote Shared Memory Application Programming Interface (RSMAPI), vous devez installer les modules RSMAPI (SUNWrsm, SUNWrsmx, SUNWrsmo et SUNWrsmox). Ces modules sont compris dans le groupe de logiciels Solaris Developer System Support ou version supérieure. Si vous installez le groupe de logiciels End User System Support, utilisez la commande pkgadd(1M) pour installer les modules RSMAPI avant d'installer le logiciel Sun Cluster. Reportez-vous aux pages de la section Solaris 8 Update 6 (3RSM) pour de plus amples informations sur l'utilisation de l'interface RSMAPI.

• Vous devrez peut-être installer des modules de Solaris autres que ceux du groupe de logiciels End User System Support, par exemple les modules du serveur HTTP Apache. Les logiciels d'autres éditeurs, par exemple ORACLE®, peuvent aussi nécessiter des modules Solaris supplémentaires. Reportez-vous à la documentation du fournisseur tiers pour connaître la configuration logicielle nécessaire de Solaris.

Partitions du disque système

Ajoutez ces informations à la "fiche de travail relative à la disposition des systèmes de fichiers locaux" disponible dans les Notes de version de Sun Cluster 3.0 12/01.

Lorsque vous installez l'environnement d'exploitation Solaris, veillez à créer les partitions Sun Cluster requises et à ce que toutes les partitions répondent aux exigences d'espace minimales.

• swap : allouez au moins 750 Mo ou le double de la mémoire physique (la plus importante des deux).

• /globaldevices  : créez un système de fichiers de 100 Mo qui sera utilisé par l'utilitaire scinstall(1M) pour les périphériques globaux.

• Gestionnaire de volumes : créez une partition de 10 Mo pour le gestionnaire de volumes sur une tranche située à la fin du disque (tranche 7). Si votre grappe utilise VERITAS Volume Manager (VxVM) et que vous prévoyez d'encapsuler le disque root, vous avez besoin de deux tranches inutilisées pour VxVM.

Pour répondre à ces exigences, vous devez personnaliser le partitionnement si vous effectuez une installation interactive de l'environnement d'exploitation Solaris.

Reportez-vous aux instructions suivantes pour de plus amples informations sur la planification des partitions.

Recommandations relatives au système de fichiers root (/)

Comme pour tout système exécutant l'environnement d'exploitation Solaris, vous pouvez configurer les répertoires root (/), /var, /usr et /opt en tant que systèmes de fichiers distincts ou les inclure dans le système de fichiers root (/). Vous trouverez ci-dessous une description du contenu logiciel des répertoires root (/), /var, /usr et /opt dans une configuration Sun Cluster. Tenez compte de ces informations lorsque vous planifiez votre projet de partitionnement.

• root (/)  : le logiciel Sun Cluster lui-même occupe moins de 40 Mo dans le système de fichiers root (/). Le logiciel Solstice DiskSuite^TM requiert moins de 5 Mo et le logiciel VxVM moins de 15 Mo. Pour de meilleurs résultats, vous devez configurer un espace et une capacité d'inode supplémentaires conséquents pour la création des périphériques spéciaux en mode bloc ou caractère utilisés par le logiciel Solstice DiskSuiteVxVM, particulièrement si la grappe comporte un grand nombre de disques partagés. Par conséquent, ajoutez au moins 100  Mo à l'espace que vous alloueriez normalement à votre système de fichiers root (/).

• /var : le logicielSun Cluster occupe un espace négligeable dans le système de fichiers /var au moment de l'installation. Cependant, vous devez réserver un espace important pour les fichiers journaux. Notez également que le nombre de messages consignés sur un noeud de grappe peut être plus important que sur un serveur autonome typique. Allouez donc au moins 100 Mo au système de fichiers /var.

• /usr  : le logiciel Sun Cluster occupe moins de 25 Mo dans le système de fichiers /usr. Les logiciels Solstice DiskSuite et VxVM requièrent chacun moins de 15  Mo.

• /opt  : la structure logicielle Sun Cluster occupe moins de 2 Mo dans le système de fichiers /opt. Toutefois, chaque service de données de Sun Cluster peut utiliser entre 1 et 5 Mo. Le logiciel Solstice DiskSuite n'occupe aucun espace dans le système de fichiers /opt. Le logiciel VxVM peut utiliser plus de 40 Mo si vous installez tous ses modules et outils. En outre, la plupart des logiciels de bases de données et d'applications sont installés dans le système de fichiers /opt. Si vous utilisez le logiciel Sun Management Center pour surveiller la grappe, vous avez besoin de 25 Mo supplémentaires sur chaque noeud pour la prise en charge de l'agent Sun Management Center et des modules Sun Cluster.

Recommandations relatives à la partition de swap

La taille minimale de la partition de swap est de 750 Mo ou deux fois la taille de la mémoire physique de la machine (la plus importante des deux). En outre, les autres applications que vous pouvez installer peuvent également avoir des exigences en matière d'espace de swap. Le cas échéant, reportez-vous à la documentation de ces applications pour déterminer la configuration de swap nécessaire.

Recommandations relatives au système de fichiers /globaldevices

Le logiciel Sun Cluster nécessite qu'un système de fichiers spécial soit réservé sur l'un des disques locaux pour la gestion des périphériques globaux. Ce système de fichiers doit être distinct car il sera par la suite monté en tant que système de fichiers de grappe. Nommez ce système de fichiers /globaldevices ; il s'agit du nom par défaut reconnu par la commande scinstall(1M). La commande scinstall(1M) renomme ensuite le système de fichiers /global/.devices/node@ID-noeud, où ID-noeud représente un nombre affecté au noeud lorsqu'il devient membre d'une grappe, et le point de montage initial est supprimé. Le système de fichiers /globaldevices doit disposer d'un espace conséquent et d'une capacité inode pour la création des interfaces en mode bloc et des dispositifs alphanumériques spéciaux, surtout si la grappe comporte un grand nombre de disques. Un système de fichiers de 100 Mo devrait largement suffire pour la plupart des configurations de grappe.

Exigences du gestionnaire de volumes

Si vous utilisez le logiciel Solstice DiskSuite vous devez réserver une tranche sur le disque root pour la création de la réplique de la base de données. Notez que cela concerne chacun des disques locaux. Cependant, si un noeud ne comporte qu'un seul disque local, vous devrez peut-être créer trois répliques de la base de données dans la même tranche pour que le logiciel Solstice DiskSuite fonctionne correctement. Pour de plus amples'informations, reportez-vous à la documentation de Solstice DiskSuite

Si vous utilisez VxVM et que vous envisagez d'encapsuler le disque root, vous devez disposer de deux tranches inutilisées pour VxVM, ainsi que d'un espace libre et non affecté supplémentaire au début ou à la fin du disque. Pour de plus amples'informations sur l'encapsulage du disque root, reportez-vous à la documentation de VxVM.

Exemples d'allocation de système de fichiers

Le Tableau 1-2 présente un schéma de partitionnement pour un noeud de grappe disposant de moins de 750 Mo de mémoire physique. Y seront installés le groupe de logiciels End User System Support de l'environnement d'exploitation Solaris, le logiciel Sun Cluster et le service de données Sun Cluster HA for NFS. La dernière tranche du disque, la tranche 7, se voit allouer une petite quantité d'espace destinée au gestionnaire de volumes.

Cette disposition permet d'utiliser le logiciel Solstice DiskSuite ou VxVM. Si vous utilisez le logiciel Solstice DiskSuite, utilisez la tranche 7 pour la réplique de la base de données. Si vous utilisez VxVM, vous pourrez libérer la tranche 7 ultérieurement en lui affectant une longueur nulle. Cette disposition fournit les deux tranches libres nécessaires (tranches 4 et 7) ainsi qu'un espace disque inutilisé à la fin du disque.

Tableau 1-2 Exemples d'allocations de systèmes de fichiers

Tranche	Contenu	Allocation (en Mo)	Description
0	/	1168	441 Mo pour l'environnement d'exploitation Solaris.  100 Mo supplémentaires pour la racine (/). 100 Mo supplémentaires pour /var. 25 Mo pour le logiciel Sun Cluster.   55 Mo pour le logiciel de gestion des volumes.  1 Mo pour le logiciel Sun Cluster HA for NFS.  25 Mo pour l'agent Sun Management Center et les modules d'agent Sun Cluster.  421 Mo (espace libre restant sur le disque) en prévision d'une éventuelle utilisation par les logiciels de bases de données et d'applications.
1	swap	750	Taille minimale lorsque la taille de la mémoire physique est inférieure à 750 Mo.
2	chevauchement	2028	Totalité du disque.
3	/globaldevices	100	Le logiciel Sun Cluster affectera ultérieurement un autre point de montage à cette tranche et la montera en tant que système de fichiers de grappe.
4	inutilisé	-	Tranche libre disponible pour l'encapsulation du disque racine sous VxVM.
5	inutilisé	-
6	inutilisé	-
7	gestionnaire de volumes	10	Utilisée par le logiciel Solstice DiskSuite pour la réplique de la base de données, ou par VxVM pour l'installation une fois la tranche libérée.

Planification de l'environnement Sun Cluster

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 12/01 Concepts.

Gestion des licences

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 le logiciel Sun Cluster 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.

Correctifs logiciels

Après avoir installé chacun des logiciels, vous devez également installer les correctifs éventuellement requis. Pour connaître les correctifs nécessaires, reportez-vous au document Notes de version de Sun Cluster 3.0 12/01 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 12/01 pour connaître les consignes et procédures générales d'application des correctifs.

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 grappe. Chaque noeud de votre configuration de grappe 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 grappe après l'installation du logiciel Solaris.

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 grappe	1 par noeud et par sous-réseau
Dispositif d'accès par console	1
Adresses logiques	1 par ressource d'hôte logique et par sous-réseau

Dispositifs d'accès par console

Vous devez disposer d'un accès par console à l'ensemble des noeuds de la grappe. Si vous installez le logiciel Cluster Control Panel sur votre console administrative, vous devez indiquer le nom d'hôte du dispositif d'accès par console employé pour communiquer avec les noeuds de la grappe. Un concentrateur de terminal peut être utilisé pour établir la communication entre la console administrative et les consoles de noeuds de la grappe. Un serveur Sun Enterprise E10000 utilise un processeur SSP (System Service Processor) au lieu d'un concentrateur de terminal. Un serveur Sun Fire^TM utilise un contrôleur système. Pour de plus amples informations sur l'accès aux consoles, reportez-vous à Sun Cluster 3.0 12/01 Concepts.

Adresses logiques

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. Reportez-vous au document Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide pour de plus amples informations et pour consulter les fiches de planification des groupes de ressources. Pour de plus amples informations sur les services de données et les ressources, reportez-vous également à Sun Cluster 3.0 12/01 Concepts.

Composants configurables de Sun Cluster

Cette section fournit des instructions pour les composants de Sun Cluster que vous configurez pendant l'installation.

Nom de la grappe

Ajoutez ces informations de planification à la "feuille de travail des noms des noeuds et de la grappe" dans Notes de version de Sun Cluster 3.0 12/01.

Vous nommez la grappe au cours de l'installation de Sun Cluster. Ce nom doit être unique dans toute l'entreprise.

Noms des noeuds

Ajoutez ces informations de planification à la "feuille de travail des noms des noeuds et de la grappe" dans Notes de version de Sun Cluster 3.0 12/01. 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, vous indiquez le nom de tous les noeuds que vous installez en tant que noeuds de grappe.

Réseau privé

Ajoutez ces informations de planification à la "feuille de travail des noms des noeuds et de la grappe" dans Notes de version de Sun Cluster 3.0 12/01.

Le logiciel Sun Cluster utilise le réseau privé pour les communications internes entre les noeuds. Sun Cluster nécessite au moins deux connexions pour procéder à l'interconnexion de la grappe sur le réseau privé. Vous indiquez l'adresse du réseau privé et le masque de réseau lorsque vous installez le logiciel Sun Cluster sur le premier noeud de la grappe. 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.

---

Remarque :

Après avoir installé le noeud en tant que membre de la grappe, vous ne pouvez plus modifier l'adresse de réseau privé ni 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 d'adresses réseau

  Reportez-vous au document TCP/IP and Data Communications Administration Guide pour connaître la procédure d'obtention de copies des RFC.

Si vous indiquez un masque de réseau différent du masque par défaut, il doit répondre aux exigences suivantes :

• Masquer au moins tous les bits fournis dans l'adresse de réseau privé

• Ne comporter aucun "espace vierge"

Noms d'hôtes privés

Ajoutez ces informations de planification à la "feuille de travail des noms des noeuds et de la grappe" dans Notes de version de Sun Cluster 3.0 12/01.

Le nom d'hôte privé est le nom utilisé pour la communication entre les noeuds sur l'interface de réseau privé. Les noms d'hôte privés sont créés automatiquement au cours de l'installation de Sun Cluster et respectent la convention d'appellation clusternodeID-noeud-priv, où ID-noeud est le numéro de référence de l'ID du noeud interne. C'est lors de l'installation de Sun Cluster que ce numéro d'ID est affecté automatiquement à chaque noeud dès lors qu'il devient membre de la grappe. Après l'installation, vous pouvez modifier les noms d'hôte privés à l'aide de l'utilitaire scsetup(1M).

Interconnexion de grappe

Ajoutez ces informations de planification à la fiche de travail relative aux interconnexions de grappe du document Notes de version de Sun Cluster 3.0 12/01.

L'interconnexion de grappe fournit les voies matérielles pour la communication en réseau privé entre les noeuds de la grappe. Chaque interconnexion se compose d'un câble placé 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 indiquez les informations de configuration suivantes pour deux interconnexions de grappes.

• 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 une grappe à deux noeuds, vous devez également indiquer si votre interconnexion est connectée directement (adaptateur à adaptateur) ou utilise une jonction de transport. Si votre grappe à 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 à la grappe à l'avenir.

• Jonctions de transport : si vous utilisez des jonctions de transport, par exemple un commutateur réseau, indiquez leurs noms 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 d'autres noms.

  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.

---

Remarque :

Les grappes à trois noeuds ou plus doivent utiliser des jonctions de transport. La connexion directe entre les noeuds de grappe est possible uniquement pour les grappes à 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 les interconnexions de grappe, reportez-vous au document Sun Cluster 3.0 12/01 Concepts.

Réseaux publics

Ajoutez ces informations de planification à la fiche de travail relative aux réseaux publics, disponible dans les Notes de version de Sun Cluster 3.0 12/01.

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

• Les réseaux publics et privés (interconnexion de grappe) doivent utiliser des adaptateurs distincts.

• Vous devez avoir au moins un réseau public connecté à tous les noeuds de grappe.

• 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 être réglée sur la valeur par défaut false. Le logiciel Sun Cluster ne prend pas en charge la valeur local-mac-address réglée sur true.

Reportez-vous également à la section "Groupes NAFO" 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 Sun Cluster 3.0 12/01 Concepts.

Groupes d'unités de disques

Ajoutez ces informations de planification à la "fiche de travail relative aux configurations des groupes d'unités de disques", disponible dans les Notes de version de Sun Cluster 3.0 12/01.

Vous devez configurer tous les groupes de disques du gestionnaire de volumes en tant que groupes d'unités 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 d'unités de disques.

• 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 à ce 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 à 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. Reportez-vous à la section "Recommandations relatives à la mise en miroir" pour de plus amples informations. Reportez-vous à "Installation et configuration du logiciel Solstice DiskSuite" ou à "Installation et configuration du logiciel VxVM" et à la documentation de votre gestionnaire de volumes pour de plus amples informations sur la mise en miroir.

Pour de plus amples informations sur les groupes d'unités de disques, reportez-vous au document Sun Cluster 3.0 12/01 Concepts.

Groupes NAFO

Ajoutez ces informations de planification à la "fiche de travail relative aux réseaux publics", disponible dans les Notes de version de Sun Cluster 3.0 12/01.

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. Si un groupe NAFO comporte plusieurs adaptateurs et que l'adaptateur actif tombe en panne, toutes les adresses du groupe sont transférées sur un autre adaptateur du même groupe. 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 d'un groupe NAFO donné peut être associé à un nom d'hôte, sous la forme /etc/hostname.adaptateur.

• La convention de désignation du groupe NAFO est nafoN, où N est le numéro fourni lors de la création du groupe NAFO.

Pour de plus amples informations sur la reprise sur panne de l'adaptateur réseau, reportez-vous à Sun Cluster 3.0 12/01 Concepts.

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 la grappe 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 la grappe. 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 : une grappe à 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 : ne connectez jamais un périphérique de quorum à plus de deux noeuds.

Pour de plus amples informations sur le quorum, reportez-vous à Sun Cluster 3.0 12/01 Concepts.

Planification des périphériques globaux et des systèmes de fichiers de grappe

Cette section explique comment planifier les périphériques globaux et les systèmes de fichiers de grappe. Pour de plus amples informations sur les périphériques globaux et les systèmes de fichiers de grappe, reportez-vous au document Sun Cluster 3.0 12/01 Concepts.

Recommandations relatives aux systèmes de fichiers de grappe et aux périphériques globaux à haute disponibilité

Sun Cluster n'impose pas de contraintes particulières en matière de disposition de disque ou de taille de système de fichiers. Tenez cependant compte des points suivants lorsque vous planifiez la disposition de vos périphériques globaux et de vos systèmes de fichiers de grappe.

• Mise en miroir : vous devez mettre en miroir tous les périphériques globaux du périphérique global à haute disponibilité. Vous n'êtes pas tenu de procéder à une mise en miroir logicielle si le périphérique de stockage dispose de RAID matériel ainsi que de chemins redondants d'accès aux disques.

• Disques : lorsque vous procédez à une mise en miroir, organisez les disques de manière à obtenir une mise en miroir qui respecte les grappes de disques.

• Disponibilité : vous devez connecter physiquement un périphérique global à plus d'un noeud de la grappe pour que ledit périphérique global soit considéré à haute disponibilité. Un périphérique global à plusieurs connexions physiques peut tolérer la défaillance d'un noeud unique. Vous pouvez configurer un périphérique global avec une seule connexion physique, mais il sera inaccessible depuis les autres noeuds en cas de panne du noeud avec la connexion.

Informations de montage pour les systèmes de fichiers de grappe

Tenez compte des points suivants lorsque vous planifiez des points de montage pour les systèmes de fichiers de grappe.

• Emplacement du point de montage : créez les points de montage dans le répertoire /global à moins d'une interdiction par d'autres produits logiciels. Ce répertoire vous permet de distinguer facilement les systèmes de fichiers de la grappe, disponibles globalement, des systèmes de fichiers locaux.

• Points de montage imbriqués : normalement, vous ne devez pas imbriquer les points de montage des systèmes de fichiers de grappe. Par exemple, ne définissez pas un système de fichiers monté sur /global/a et un autre système de fichiers monté sur /global/a/b. Si vous ne respectez pas cette règle, vous risquez des problèmes de disponibilité ainsi que de séquence d'amorçage des noeuds, si le point de montage parent est absent lorsque le système tente de monter un enfant de ce système de fichiers. La seule exception à cette règle est lorsque les périphériques des deux systèmes de fichiers ont la même connectivité au noeud physique (différentes tranches sur le même disque, par exemple).

Planification de la gestion des volumes

Ajoutez ces informations de planification à la "fiche de travail relative aux configurations des groupes d'unités de disques" et à la "fiche de travail relative aux configurations du gestionnaire de volumes", disponibles dans les Notes de version de Sun Cluster 3.0 12/01. Pour Solstice DiskSuite, ajoutez également ces informations de planification à la "fiche de travail relative aux métapériphériques (Solstice DiskSuite)."

Cette section explique comment planifier la gestion des volumes pour votre configuration de grappe.

Sun Cluster utilise un logiciel de gestion des volumes pour grouper les disques par unités de disque pouvant être administrées comme une seule unité. Sun Cluster prend en charge le logiciel Solstice DiskSuite, ainsi que VERITAS Volume Manager (VxVM).

• Si vous utilisez le logiciel Solstice DiskSuite, vous devez l'installer sur tous les noeuds de la grappe, que vous utilisiez ou non VxVM sur certains noeuds pour gérer les disques.

• Si vous utilisez VxVM et que vous activez la fonction de grappe VxVM, vous devez installer et utiliser VxVM sous licence sur tous les noeuds de la grappe.

• Si vous utilisez VxVM et que vous n'activez pas la fonction de grappe VxVM, il vous suffit d'installer VxVM et de l'utiliser sous licence sur les noeuds reliés aux périphériques de stockage gérés par VxVM.

• Si vous installez le logiciel Solstice DiskSuite ainsi que VxVM sur un noeud, vous devez utiliser le logiciel Solstice DiskSuite pour gérer les disques locaux de chaque noeud (comme le disque root) ainsi que VxVM pour gérer tous les disques partagés.

Reportez-vous à la documentation du gestionnaire de volumes ainsi qu'aux sections "Installation et configuration du logiciel Solstice DiskSuite" ou "Installation et configuration du logiciel VxVM" pour de plus amples informations sur l'installation et la configuration du logiciel du gestionnaire de volumes. Pour de plus amples informations sur la gestion de volume dans une configuration de grappe, reportez-vous à Sun Cluster 3.0 12/01 Concepts.

Recommandations relatives au logiciel de gestion des volumes

Tenez compte des recommandations générales suivantes lorsque vous configurez vos disques.

• Disques multihôtes mis en miroir : vous devez mettre tous les disques multihôtes en miroir sur des unités d'extension de disque. Voir "Mise en miroir des disques multihôtes" pour de plus amples informations sur la mise en miroir des disques multihôtes. Vous n'êtes pas tenu de procéder à une mise en miroir logicielle si le périphérique de stockage dispose de RAID matériel ainsi que de chemins redondants d'accès aux disques.

• Racine mise en miroir : la mise en miroir du disque root améliore la disponibilité, mais elle n'est pas obligatoire. Voir "Recommandations relatives à la mise en miroir" pour de plus amples informations sur la mise en miroir du disque root.

• Attribution d'un nom unique : sur tout noeud de grappe, si un métapériphérique Solstice DiskSuite local ou un volume VxVM est utilisé comme le périphérique sur lequel le système de fichiers /global/.devices/node@ID-noeud est monté, le nom de ce métapériphérique ou volume doit être unique dans toute la grappe.

• Listes de noeuds : pour être à haute disponibilité, un groupe d'unités de disque doit avoir des listes de maîtres potentiels et une stratégie de repli en cas de panne identiques à celles du groupe de ressources associé. Ou, si un groupe de ressources évolutif utilise plus de noeuds que le groupe d'unités de disque associé, la liste de noeuds du groupe de ressources évolutif doit être un surensemble de la liste de noeuds du groupe d'unités de disques. Reportez-vous aux instructions de planification des groupes de ressources dans le document Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide pour de plus amples informations sur les listes de noeuds.

• Disques multiports : tous les disques utilisés pour construire un groupe de périphériques dans la grappe doivent être connectés, ou reliés par un port, à tous les noeuds configurés dans la liste des noeuds de ce groupe de périphériques. Le logiciel Solstice DiskSuite est capable de procéder automatiquement à cette vérification au moment où ces disques sont ajoutés à un ensemble de disques. Cependant, les groupes de disques VxVM configurés ne sont associés à aucun ensemble de noeuds particulier.

• Disques remplaçables à chaud : vous pouvez utiliser des disques remplaçables à chaud pour améliorer la disponibilité, mais ce n'est pas obligatoire.

Reportez-vous à la documentation de votre gestionnaire de volumes pour connaître les recommandations de disposition du disque et les restrictions supplémentaires.

Recommandations relatives au logiciel Solstice DiskSuite

Tenez compte des points suivants lorsque vous planifiez des configurations Solstice DiskSuite.

• Noms de métapériphériques locaux : chaque nom de métapériphérique local doit être unique dans le cluster et ne peut être identique à aucun identificateur de périphérique (DID).

• Médiateurs : chaque ensemble de disques configuré avec exactement deux chaînes de disques et sous le contrôle de deux noeuds doit comporter des médiateurs Solstice DiskSuite configurés. Une chaîne de disque se compose d'une baie de disques avec ses disques physiques, des câbles de la baie vers le ou les noeuds et des cartes d'interface. Vous devez configurer chaque ensemble de disques avec exactement deux noeuds en tant qu'hôte médiateur. Vous devez utiliser les deux mêmes noeuds pour tous les ensembles de disques nécessitant des médiateurs, et ces deux noeuds doivent être les maîtres de ces ensembles de disques. Vous ne pouvez pas configurer de médiateurs pour les ensembles de disques qui ne répondent pas aux critères deux chaînes et deux hôtes. Reportez-vous à la page de manuel mediator(7) pour de plus amples informations.

• Paramètres de /kernel/drv/md.conf : tous les métapériphériques utilisés par chaque ensemble de disques sont créés à l'avance, au moment de l'initialisation de la reconfiguration, en fonction des paramètres de configuration trouvés dans le fichier /kernel/drv/md.conf. Les champs du md.conf sont décrits dans la documentation de Solstice DiskSuite. Vous devez modifier les champs nmd et md_nsets comme suit pour prendre en charge une configuration Sun Cluster.

  • nmd : le champ nmd définit le nombre de métapériphériques créés pour chaque ensemble de disques. Vous devez définir sa valeur en fonction du nombre maximum prévu de métapériphériques utilisés par l'un des ensembles de disques de la grappe. Par exemple, si une grappe utilise 10 métapériphériques dans ses 15 premiers ensembles de disques, mais 1000 dans le 16ème, vous devez définir la valeur de nmd sur au moins 1000. En outre, la valeur de nmd doit être telle qu'il y ait suffisamment de numéros pour que chaque DID et que chaque nom de métapériphérique local soit unique dans la grappe. Le nombre maximal de métapériphériques autorisé par ensemble de disques est de 8192. Le nombre par défaut est de 128 par ensemble de disques.

  • md_nsets : le champ md_nsets définit le nombre total d'ensembles de disques pouvant être créés pour qu'un système réponde aux besoins de la grappe. Vous devez définir la valeur de md_nsets en fonction du nombre prévu d'ensembles de disques de la grappe, plus un pour permettre au logiciel Solstice DiskSuite de gérer les disques privés sur l'hôte local (c'est à dire les métapériphériques ne faisant pas partie de l'ensemble de disques local). Le nombre maximal d'ensembles de disques autorisé par grappe est de 32. Le nombre par défaut est 4.

  Définissez ces champs au moment de l'installation en tenant compte des éventuelles extensions futures de la grappe. L'augmentation de ces valeurs lorsque la grappe est en cours de production prend beaucoup de temps car elle nécessite une réinitialisation de reconfiguration pour chaque noeud. Si vous reportez cette opération, cela augmente également la probabilité d'erreurs d'allocation d'espace dans le système de fichiers root (/) pour créer tous les périphériques nécessaires.

  ---

  Attention :

  Tous les noeuds de grappe doivent avoir des fichiers /kernel/drv/md.conf identiques, quel que soit le nombre d'ensembles de disques desservis par chaque noeud. Le non respect de cette consigne peut occasionner de graves erreurs de Solstice DiskSuite et un risque de pertes de données.

  ---

Recommandations relatives au logiciel VERITAS Volume Manager

Tenez compte des points suivants lorsque vous planifiez des configurations VERITAS Volume Manager (VxVM).

• Convention d'appellation d'après la baie : si vous décidez de nommer les périphériques d'après la baie qu'ils occupent (fonction introduite par VxVM version 3.2), veillez à préserver la cohérence des noms sur tous les noeuds de la grappe qui partagent le même stockage. VxVM ne procède pas à la coordination de ces noms, il incombe donc à l'administrateur de vérifier que VxVM attribue le même nom à tous les périphériques identiques des différents noeuds. Si le non respect de cette consigne n'empêche pas la grappe de fonctionner correctement, il en complique considérablement l'administration et accroît les risques d'erreur de configuration, voire de perte de données.

• Groupe de disques root : vous devez créer un groupe d'unités de disques root par défaut (rootdg) sur chaque noeud. Le groupe de disques rootdg peut être créé sur les disques suivants.

  • Le disque root, qui doit être encapsulé.

  • Un ou plusieurs disques locaux non-root, qui peuvent être encapsulés ou initialisés.

  • Une combinaison de disques root et de disques locaux non-root

  Le groupe de disques rootdg doit être local sur le noeud.

• Encapsulage : les disques à encapsuler doivent disposer de deux entrées de table de tranches de disque libres.

• Nombre de volumes : lors de la création d'un groupe d'unités de disques, estimez le nombre maximal de volumes que ce groupe utilisera.

  • Si ce nombre de volumes est inférieur à 1000, vous pouvez utiliser les numéros de mineur par défaut.

  • Si ce nombre est supérieur ou égal à 1000, vous devez prévoir avec soin le mode d'affectation des numéros mineurs aux volumes du groupe d'unités de disques. Il est impossible d'affecter des numéros de mineurs se chevauchant à deux groupes de périphériques.

• DRL : l'utilisation du système DRL (Dirty Region Logging) est vivement recommandée mais pas obligatoire. Le système DRL permet de réduire le temps de restauration des volumes en cas de panne du noeud. Il peut cependant réduire le débit d'E/S.

Journalisation du système de fichiers

La journalisation est obligatoire pour tous les systèmes de fichiers de grappe. Sun Cluster prend en charge les systèmes de fichiers de journalisation suivants :

• Journalisation UFS Solaris

• Journalisation UFS pour les trans-métapériphériques Solstice DiskSuite

• Journalisation VERITAS File System (VxFS)

Pour de plus amples informations sur la journalisation UFS pour les trans-métapériphériques, reportez-vous à la documentation de Solstice DiskSuite. Pour de plus amples informations sur la journalisation UFS Solaris, reportez-vous à la page de manuel mount_ufs(1M). Pour de plus amples informations sur la journalisation VxFS, reportez-vous à la page de manuel mount_vxfs(1M) fournie avec le logiciel VxVM.

Le tableau suivant répertorie les systèmes de fichiers de journalisation pris en charge par chaque gestionnaire de volumes.

Tableau 1-4 Tableau des journalisations de système de fichiers prises en charge

Gestionnaire de volumes	Journalisation de système de fichiers prise en charge
Solstice DiskSuite	Journalisation UFS Solaris, Journalisation UFS pour les trans-métapériphériques Solstice DiskSuite, VxFS
VERITAS Volume Manager	Journalisation UFS Solaris, VxFS

Tenez compte des points suivants si vous devez choisir entre Journalisation UFS Solaris et Journalisation UFS pour les trans-métapériphériques Solstice DiskSuite.

• Taille du journal de Solaris UFS : Journalisation UFS Solaris alloue toujours le journal en utilisant l'espace libre sur le système de fichiers UFS et selon la taille du système de fichiers.

  • Sur les systèmes de fichiers de moins de 1 Go, le journal occupe 1 Mo.

  • Sur les systèmes de fichiers d'au moins 1 Go ou plus, le journal occupe 1 Mo par Go sur le système de fichiers, la limite maximale étant de 64 Mo.

• Métapériphérique de journalisation : un trans-métapériphérique Solstice DiskSuite gère la journalisation UFS. Le périphérique de journalisation d'un trans-métapériphérique est un métapériphérique que vous pouvez mettre en miroir et en bandes. La taille maximale du journal est de 1 Go, mais 64 Mo suffisent pour la plupart des systèmes de fichiers. La taille de journal minimale est de 1 Mo. Reportez-vous à la documentation de Solstice DiskSuite pour de plus amples informations sur la journalisation à l'aide de trans-métapériphériques.

Recommandations relatives à la mise en miroir

Cette section explique comment planifier la mise en miroir de votre configuration de grappe.

Mise en miroir des disques multihôtes

La mise en miroir de tous les disques multihôtes dans une configuration Sun Cluster permet à la configuration de tolérer les défaillances d'un disque unique. Le logiciel Sun Cluster nécessite la mise en miroir de tous les disques multihôtes sur les unités d'extension de disque. Vous n'êtes pas tenu de procéder à une mise en miroir logicielle si le périphérique de stockage dispose de RAID matériel ainsi que de chemins redondants d'accès aux disques.

Tenez compte des points suivants lors de la mise en miroir des disques multihôtes.

• Unités d'extension de disque distinctes : chaque sous-miroir d'un miroir ou d'un plex donné doit résider dans une unité d'extension de disque multihôte differente.

• Espace disque : la mise en miroir double l'espace disque nécessaire.

• Mise en miroir à trois voies : Solstice DiskSuite et VERITAS Volume Manager (VxVM) prennent en charge la mise en miroir à trois voies. Cependant, Sun Cluster ne nécessite qu'une mise en miroir à deux voies.

• Nombre de métapériphériques : avec le logiciel Solstice DiskSuite les miroirs sont composés d'autres métapériphériques tels que des concaténations ou des bandes. Les grandes configurations peuvent comporter un grand nombre de métapériphériques. Par exemple, sept métapériphériques sont créés pour chaque système de fichiers UFS de journalisation.

• Tailles de disques différentes : si vous placez la copie miroir sur un disque d'une taille différente, votre capacité de mise en miroir est limitée à la taille du sous-miroir ou du plex le plus petit.

Pour de plus amples informations sur les disques multihôtes, reportez-vous au document Sun Cluster 3.0 12/01 Concepts.

Mise en miroir du disque root

Ajoutez ces informations à la "fiche de travail relative à la disposition des systèmes de fichiers locaux" dans Notes de version de Sun Cluster 3.0 12/01.

Pour une disponibilité maximale, mettez en miroir les systèmes de fichiers root (/), /usr, /var, /opt, et swap sur les disques locaux. Sous VxVM, vous encapsulez le disque root et dupliquez les sous-disques générés. Le logiciel Sun Cluster n'impose pas de mise en miroir du disque root.

Avant de décider de mettre ou non le disque root en miroir, tenez compte des risques, de la complexité, du coût et du temps de maintenance pour les différentes possibilités concernant le disque root. Il n'existe pas de stratégie de mise en miroir valable pour toutes les configurations. Pour appliquer la mise en miroir au disque root, n'hésitez pas à prendre conseil auprès de votre interlocuteur Enterprise Services.

Reportez-vous à la documentation de votre gestionnaire de volumes et aux sections "Installation et configuration du logiciel Solstice DiskSuite" ou "Installation et configuration du logiciel VxVM" pour connaître la procédure de mise en miroir du disque root.

Tenez compte des points suivants pour décider d'appliquer ou non la mise en miroir au disque root :

• Complexité : la mise en miroir du disque root complique l'administration système et l'initialisation en mode mono-utilisateur.

• Sauvegardes : qu'il soit ou non mis en miroir, le disque root doit faire l'objet de sauvegardes régulières. La mise en miroir à elle seule ne protège pas contre les erreurs administratives. Seul un plan de sauvegarde vous permet de récupérer des fichiers accidentellement altérés ou supprimés.

• Périphériques de quorum : n'utilisez pas un disque configuré comme périphérique de quorum pour mettre en miroir un disque root.

• Quorum : avec le logiciel Solstice DiskSuite en cas de panne entraînant la perte du quorum de la base de données d'état des métapériphériques, vous ne pouvez pas réinitialiser le système sans effectuer un minimum de maintenance. Reportez-vous à la documentation de Solstice DiskSuite pour de plus amples informations sur la base de données d'état des métapériphériques et ses répliques.

• Contrôleurs distincts : pour une disponibilité maximale, le disque root doit être mis en miroir sur un contrôleur distinct.

• Disque d'initialisation : vous pouvez définir la copie miroir comme étant un disque d'initialisation pour pouvoir démarrer à partir de cette copie en cas de panne du disque principal.

• Disque root secondaire : avec un disque root mis en miroir, vous pouvez continuer à travailler à partir du disque root secondaire (le miroir) en cas de panne du disque root principal. Plus tard, si le disque root principal fonctionne de nouveau (peut-être après un redémarrage ou en raison d'erreur d'E/S temporaires), les initialisations suivantes seront effectuées à partir du disque d'initialisation principal défini dans le champ boot-device de la PROM OpenBoot^TM. Dans ce cas, aucune tâche de réparation manuelle n'a eu lieu, mais le lecteur redémarre à un niveau suffisant pour permettre la réinitialisation. Notez qu'aucune resynchronisation de Solstice DiskSuite ne se produit. La resynchronisation nécessite une étape manuelle lors de la remise en service du lecteur.

  Si des modifications ont été apportées à des fichiers du disque root secondaire (miroir), elles ne sont pas reflétées sur le disque root principal au moment de la réinitialisation (dont les données sont alors obsolètes). Par exemple, les éventuelles modifications apportées au fichier /etc/system sont perdues. Certaines commandes administratives de Solstice DiskSuite peuvent avoir modifié le fichier /etc/system alors que le disque root principal était hors service.

  Le programme d'initialisation ne vérifie pas s'il démarre à partir d'un miroir ou d'un périphérique physique sous-jacent, et la mise en miroir s'active partiellement au cours du processus d'initialisation (après le chargement des métapériphériques). Avant ce point, le système est vulnérable face aux problèmes d'obsolescence des sous-miroirs.