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 suivante:

• "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 U1 Hardware Guide Documentation fournie avec votre serveur et vos périphériques de stockage
Planification de l'installation du logiciel de la grappe			Ce chapitre  "Fiches de travail et exemples de configurations pour l'installation de Sun Cluster" dans le Notes de version de Sun Cluster 3.0 U1
Installation d'une nouvelle grappe d'ajout de noeuds à une grappe existante
	Installation de l'environnement d'exploitation Solaris, du logiciel Cluster Control Panel (facultatif), 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 de Solstice DiskSuite
		VERITAS Volume Manager (VxVM)	"Installation et configuration du logiciel VxVM" Documentation de 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 U1 Data Services Installation and Configuration Guide "Fiches de travail et exemples de configurations des services de données" dans le Notes de version de Sun Cluster 3.0 U1
Mise à niveau de l'environnement d'exploitation et des logiciels de grappe, de services de données et de gestion des volumes à partir de Sun Cluster 2.2 vers Sun Cluster 3.0.			"Mise à niveau de Sun Cluster 2.2 à Sun Cluster 3.0 Update 1" "Installation et configuration du logiciel Solstice DiskSuite" ou "Installation et configuration du logiciel VxVM" Documentation du gestionnaire de volumes
Développement de services de données personnalisés			Sun Cluster 3.0 U1 Data Services Developers' Guide

Planification de l'environnement d'exploitation Solaris

Cette section explique comment planifier l'installation du logiciel Solaris dans une configuration de grappe. Pour plus d'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 plus d'informations sur la méthode d'installation scinstall de JumpStart. Reportez-vous à la documentation d'installation de Solaris pour plus d'informations sur les méthodes d'installation standard de Solaris.

Partitions du disque système

Ajoutez ces informations à la fiche de travail relative à la configuration des systèmes de fichiers locaux, disponible dans le document Notes de version de Sun Cluster 3.0 U1.

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.

• Espace d'échange : allouez au moins 750 Mo ou deux fois la taille de la mémoire physique, selon ce qui est le plus élevé.

• /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 plus d'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 exige moins de 5 Mo et 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 DiskSuite ou VxVM, 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 logiciel Sun 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 serveur autonome typique. Par conséquent, prévoyez au moins 100 Mo pour le 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 exigent chacun moins de 15 Mo.

• /opt : la structure logicielle de Sun Cluster occupe moins de 2 Mo dans le système de fichiers /opt. Cependant, chaque service de données Sun Cluster peut utiliser entre 1 et 5 Mo. Le logiciel Solstice DiskSuite n'utilise aucun espace dans le système de fichiers /opt. Le logiciel VxVM peut utiliser plus de 40 Mo si tous ses modules et outils sont installés. 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^TM Management Center (anciennement Sun Enterprise SyMON^TM) pour surveiller la grappe, vous devez disposer de 25 Mo d'espace supplémentaire sur chaque noeud pour l'agent Sun Management Center et les modules de 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, selon ce qui est le plus élevé. 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 connaître 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) le renomme ensuite en /global/.devices/node@ID-noeud, où ID-noeud représente le numéro attribué qui devient membre d'une grappe, et supprime le point de montage initial /globaldevices. Le système de fichiers /globaldevices doit offrir un espace et une capacité d'inode amplement suffisante pour la création des périphériques spéciaux en mode bloc et en mode caractère, en particulier 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 plus d'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 plus d'informations sur l'encapsulage du disque root, reportez-vous à la documentation de VxVM.

Exemple : exemples d'allocations de systèmes 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. Ce schéma sera installé avec 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 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 le répertoire root (/). 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ée	-	Tranche libre disponible pour l'encapsulage du disque root sous VxVM.
5	inutilisée	-
6	inutilisée	-
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 U1 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 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.

Correctifs logiciels

Après avoir installé chacun des logiciels, vous devez également installer les correctifs éventuellement requis. Pour des informations sur les correctifs nécessaires, reportez-vous au document Notes de version de Sun Cluster 3.0 U1 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 U1 pour les instructions 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
Concentrateur de terminal ou processeur de services système (SSP)	1
Adresses logiques	1 par ressource d'hôte logique et par sous-réseau

Concentrateur de terminal ou processeur de services système (SSP)

Un concentrateur de terminal assure la communication entre la console administrative et les consoles de noeuds de grappe. Les serveurs Sun Enterprise^TM 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 U1 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 Sun Cluster 3.0 U1 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 U1 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 fiche de travail relative aux noms de noeud et de grappe, disponible dans le document Notes de version de Sun Cluster 3.0 U1.

Vous indiquez un nom pour la grappe pendant l'installation de Sun Cluster. Ce nom doit être unique dans toute l'entreprise.

Noms des noeuds

Ajoutez ces informations de planification à la fiche de travail relative aux noms de noeud et de grappe, disponible dans le document Notes de version de Sun Cluster 3.0 U1. 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 fiche de travail relative aux noms de noeud et de grappe, disponible dans le document Notes de version de Sun Cluster 3.0 U1.

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 grappe 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 de la grappe. 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 des données différentes 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 savoir comment obtenir des 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é.

• N'avoir aucun "trou".

Noms d'hôte privés

Ajoutez ces informations de planification à la fiche de travail relative aux noms de noeud et de grappe, disponible dans le document Notes de version de Sun Cluster 3.0 U1.

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 lors de l'installation de Sun Cluster et respectent la convention de désignation clusternodeid_noeud-priv, où id_noeud est le numéro de l'ID de noeud interne. Lors de l'installation de Sun Cluster, ce numéro est affecté automatiquement à chaque noeud qui 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 fournie dans le document Notes de version de Sun Cluster 3.0 U1.

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 grappe.

• 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 un nom de jonction pour chaque interconnexion. Vous pouvez utiliser le nom par défaut, switchN, où N est un nombre affecté automatiquement lors de 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 plus d'informations sur les interconnexions de grappe, reportez-vous au document Sun Cluster 3.0 U1 Concepts.

Réseaux publics

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 U1.

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 utiliser la valeur par défaut false. Le logiciel Sun Cluster ne prend pas en charge la valeur true pour cette variable.

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 U1 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 disque, disponible dans le document Notes de version de Sun Cluster 3.0 U1.

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 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 plus d'informations. Reportez-vous aux sections "Installation et configuration du logiciel Solstice DiskSuite" ou "Installation et configuration du logiciel VxVM" et à 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 disques, reportez-vous au document Sun Cluster 3.0 U1 Concepts.

Groupes NAFO

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 U1.

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 suivants points 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'hôte, sous la forme d'un fichier /etc/nom_hôte.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 plus d'informations sur la reprise sur panne des adaptateurs réseau, reportez-vous au document Sun Cluster 3.0 U1 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 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 une grappe à 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 U1 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 plus d'informations sur les périphériques globaux et les systèmes de fichiers de grappe, reportez-vous au document Sun Cluster 3.0 U1 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 : tous les périphériques globaux doivent être mis en miroir pour être considérés comme des périphériques haute disponibilité.

• Disques : lors de la mise en miroir, disposez les disques de manière qu'ils soient mis en miroir sur des plateaux de disques.

• Disponibilité : un périphérique global doit avoir une connexion physique avec plusieurs noeuds de la grappe pour être considéré comme hautement disponible. 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. L'utilisation de ce répertoire permet de distinguer facilement les systèmes de fichiers de grappe, qui sont 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. Le non-respect de cette règle peut entraîner des problèmes de disponibilité et d'ordre d'initialisation des noeuds si le point de montage parent n'est pas présent lorsque le système tente de monter un point 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 aux fiches de travail relatives au gestionnaire de volumes, disponible dans le document Notes de version de Sun Cluster 3.0 U1. Pour Solstice DiskSuite, ajoutez aussi 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 en groupes d'unités de disque pouvant être administrés 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 activez sa fonction de grappe, vous devez installer et obtenir la licence de VxVM sur tous les noeuds de la grappe.

• Si vous utilisez VxVM et n'activez pas sa fonction de grappe, vous ne devez installer et obtenir la licence de VxVM que sur les noeuds liés aux périphériques de stockage qui seront gérés par VxVM.

• Si vous installez à la fois le logiciel Solstice DiskSuite et VxVM sur un noeud, vous devez utiliser le logiciel Solstice DiskSuite pour gérer les disques locaux de chaque noeud (comme le disque root) et 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 plus d'informations sur l'installation et la configuration du logiciel du gestionnaire de volumes. Pour plus d'informations sur la gestion des volumes dans une configuration de grappe, reportez-vous au document Sun Cluster 3.0 U1 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 plus d'informations sur la mise en miroir des disques multihôtes.

• Root mis en miroir : la mise en miroir du disque root assure une haute disponibilité, mais elle n'est pas obligatoire. Voir "Recommandations relatives à la mise en miroir" pour plus d'informations sur la mise en miroir du disque root.

• Noms uniques : sur tout noeud de grappe, si un métapériphérique Solstice DiskSuite ou un volume VxVM est utilisé comme périphérique de montage pour le système de fichiers /global/.devices/node@id_noeud, 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 U1 Data Services Installation and Configuration Guide pour plus d'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. En outre, lorsque vous enregistrez des ensembles de disques Solstice DiskSuite, des groupes de disques VxVM ou des ensembles individuels de périphériques globaux en tant que groupes de périphériques globaux, vous ne pouvez effectuer qu'une vérification limitée de la connectivité.

• 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 la grappe 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 disque et ayant exactement deux noeuds pour maîtres doit avoir 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 à critères (deux chaînes et deux hôtes). Reportez-vous à la page de manuel mediator(7) pour plus d'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 du démarrage de la reconfiguration, en fonction des paramètres de configuration trouvés dans le fichier /kernel/drv/md.conf. Les champs du fichier 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 - ce champ 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 à 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 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 : ce champ 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 en 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 règle peut entraîner des erreurs graves 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).

• Groupe de disques root : vous devez créer un groupe d'unités de disque root par défaut (rootdg) sur chaque noeud. Ce groupe de disques 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 : estimez le nombre maximal de volumes qu'un groupe d'unités de disques utilisera au moment de la création de ce groupe.

  • 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 :

• Solaris UFS logging

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

Pour plus d'informations sur Solstice DiskSuite trans metadevice UFS logging, reportez-vous à la documentation de Solstice DiskSuite. Pour plus d'informations sur Solaris UFS logging, reportez-vous à la page de manuel mount_ufs(1M).

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	Solaris UFS loggingSolstice DiskSuite trans metadevice UFS logging,
VERITAS Volume Manager	Solaris UFS logging

Tenez compte des points suivants lorsque vous choisissez entre la Solaris UFS logging et la Solstice DiskSuite trans metadevice UFS logging pour votre gestionnaire de volumes Solstice DiskSuite.

• Taille du journal de Solaris UFS : Solaris UFS logging 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 du journal : 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. Vous pouvez créer un journal de 1 Go maximum, 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 plus d'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.

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 différente.

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

• Mise en miroir à trois voies : le logiciel 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 plus d'informations sur les disques multihôtes, reportez-vous au document Sun Cluster 3.0 U1 Concepts.

Mise en miroir du disque root

Ajoutez ces informations de planification à la fiche de travail relative à la configuration des systèmes de fichiers locaux, disponible dans le document Notes de version de Sun Cluster 3.0 U1.

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 mettez en miroir les sous-disques générés. Cependant, la mise en miroir du disque root n'est pas obligatoire pour Sun Cluster.

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 savoir comment appliquer la mise en miroir au disque root, vous pouvez prendre conseil auprès de votre interlocuteur Enterprise Services.

Reportez-vous à la documentation du gestionnaire de volumes et à la section "Installation et configuration du logiciel Solstice DiskSuite" ou "Installation et configuration du logiciel VxVM" pour plus d'informations sur la 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 plus d'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'erreurs 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.