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 cluster"

• "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 du cluster	Sun Cluster 3.0 Hardware Guide Documentation fournie avec votre serveur et vos périphériques de stockage
Planification de l'installation logicielle du cluster	Chapitre 1 Fiches de travail et exemples de configuration dans le document Notes de version de Sun Cluster 3.0
Installation des modules logiciels du cluster, du gestionnaire de volumes et des services de données	Chapitre 2
Configuration du logiciel de cluster et du logiciel de gestion des volumes	Chapitre 2 Annexe A ou Annexe B Documentation du gestionnaire de volumes
Mise à niveau des logiciels de cluster, de services de données et de gestion des volumes	Chapitre 3 Annexe A or Annexe B Documentation du gestionnaire de volumes
Planification, installation et configuration des services de données et des groupes de ressources	Sun Cluster 3.0 Data Services Installation and Configuration Guide
Utilisation de l'API	Sun Cluster 3.0 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 cluster. 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 permet d'installer à la fois l'environnement d'exploitation Solaris et le logiciel Sun Cluster en utilisant une installation JumpStart personnalisée. Si vous installez plusieurs noeuds de cluster, nous vous recommandons une installation en réseau.

Reportez-vous à la section "Utilisation de JumpStart pour installer l'environnement d'exploitation Solaris et établir de nouveaux noeuds de cluster" pour plus d'informations sur l'installation JumpStart personnalisée. 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 disposition des systèmes de fichiers locaux, fournie dans le document Notes de version de Sun Cluster 3.0.

Une fois le système d'exploitation Solaris installé, assurez-vous que les partitions Sun Cluster nécessaires sont créées et que toutes les partitions répondent aux exigences d'espace minimum.

• 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 cluster 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 nécessite moins de 5 Mo et le logiciel VxVM moins de 15 Mo. Pour de meilleurs résultats, configurez 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 le cluster 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 /var au moment de l'installation. Cependant, réservez un espace important pour les fichiers journaux. Notez également que le nombre de messages consignés sur un noeud de cluster peut être plus important que sur un serveur autonome typique. Par conséquent, prévoyez au moins 100 Mo pour /var.

• /usr : le logiciel Sun Cluster occupe moins de 25 Mo dans /usr. Les logiciels Solstice DiskSuite et VxVM nécessitent chacun moins de 15 Mo.

• /opt : le logiciel de cluster Sun Cluster utilise moins de 2 Mo dans /opt. Toutefois, chaque service de données de Sun Cluster peut utiliser entre 1 et 5 Mo. Le logiciel Solstice DiskSuite n'utilise pas d'espace dans /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 /opt. Si vous utilisez le logiciel Sun^TM Management Center (anciennement Sun Enterprise SyMON^TM) pour surveiller le cluster, 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 (la plus importante des deux). En ouvre, 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 cluster. 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 avec /global/.devices/node@ID_noeud, oy ID_noeud représente le numéro attribué à un noeud qui devient membre d'un cluster, 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 le cluster comporte un grand nombre de disques. Un système de fichiers de 100 Mo devrait largement suffire pour la plupart des configurations de cluster.

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, 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 cluster 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, s'est vue 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 libère les tranches 4 et 7 et fournit 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 cluster.
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	Dans le cas du logiciel Solstice DiskSuite, tranche utilisée pour la réplique de la base de données. Dans le cas de VxVM, la tranche est ensuite libérée, ainsi que de l'espace à la fin du disque.

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

Patchs logiciels

Après avoir installé chacun des logiciels, vous devez également installer les patchs éventuellement requis. Pour obtenir la liste des patchs nécessaires, reportez-vous au document Notes de version de Sun Cluster 3.0 ou consultez votre interlocuteur Enterprise Services ou votre prestataire de services. Reportez-vous au document Guide d'administration système de Sun Cluster 3.0 pour les instructions et procédures générales d'application des patchs.

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 cluster. Chaque noeud de votre configuration de cluster doit avoir au moins une connexion de réseau public vers le même ensemble de sous-réseaux publics.

Le tableau suivant répertorie les composants nécessitant l'affectation d'une adresse IP. Ajoutez ces adresses IP à tous les services d'attribution de noms utilisés. Ajoutez également ces adresses IP au fichier local /etc/inet/hosts sur chaque noeud de cluster après l'installation du logiciel Sun Cluster.

Tableau 1-3 Composants de Sun Cluster utilisant des adresses IP

Composant	Adresses IP nécessaires
Console administrative	1 par sous-réseau
Noeuds de cluster	1 par noeud et par sous-réseau
Concentrateur de terminal ou processeur de services système (SSP)	1
Adresses logiques	1 par ressource d'host logique et par sous-réseau

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 cluster. 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 Concepts.

Adresses logiques

Chaque groupe de ressources de service de données qui utilise une adresse logique doit avoir un nom d'host spécifié pour chaque réseau public à partir duquel l'adresse logique est accessible. Reportez-vous au Sun Cluster 3.0 Data Services Installation and Configuration Guide pour obtenir des informations et des fiches de travail pour la planification des groupes de ressources. Pour plus d'informations sur les services de données et les ressources, reportez-vous également à Sun Cluster 3.0 Concepts.

Composants configurables de Sun Cluster

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

Nom du cluster

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

Vous indiquez un nom pour le cluster 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 cluster, disponible dans le document Notes de version de Sun Cluster 3.0. Les informations de la plupart des autres fiches de travail sont groupées par nom de noeud.

Le nom de noeud est le nom que vous affectez à une machine pendant l'installation de l'environnement d'exploitation Solaris. Pendant l'installation de Sun Cluster, vous indiquez le nom de tous les noeuds que vous installez en tant que noeuds de cluster.

Réseau privé

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

Le logiciel Sun Cluster utilise le réseau privé pour les communications internes entre les noeuds. Il nécessite au moins deux connexions vers l'interconnexion de cluster sur le réseau privé. Vous indiquez l'adresse de réseau privé et le netmask pendant l'installation du logiciel Sun Cluster sur le premier noeud du cluster. Vous pouvez accepter l'adresse de réseau privé (172.16.0.0) et le netmask (255.255.0.0) par défaut ou taper des choix différents si cette adresse est déjà utilisée dans l'entreprise.

---

Remarque :

Après avoir installé le noeud en tant que membre du cluster, vous ne pouvez plus modifier l'adresse de réseau privé et le netmask.

---

Si vous indiquez une adresse de réseau privé différente de l'adresse par défaut, elle doit répondre aux exigences suivantes :

• Les deux derniers octets de l'adresse doivent être nuls.

• L'adresse doit respecter les instructions de la RFC 1597 pour l'affectation d'adresses réseau.

  Reportez-vous au document TCP/IP and Data Communications Administration Guide pour savoir comment obtenir des copies des RFC.

Si vous indiquez un netmask différent de celui fourni par défaut, il doit répondre aux exigences suivantes :

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

• N'avoir aucun "trou".

Interconnexion de cluster

Ajoutez ces informations de planification à la fiche de travail relative aux interconnexions de cluster fournie dans le document Notes de version de Sun Cluster 3.0.

L'interconnexion de cluster fournit les composants matériels nécessaires aux noeuds du cluster pour communiquer sur un réseau privé. Chaque interconnexion se compose d'un câble entre deux adaptateurs de transport, entre un adaptateur de transport et une jonction de transport, ou entre deux jonctions de transport. Lors de l'installation de Sun Cluster, vous fournissez des informations de configuration pour deux interconnexions de cluster.

• Adaptateurs de transport : pour les adaptateurs de transport, tels que les ports sur les interfaces réseau, indiquez les noms des adaptateurs de transport et le type de transport. Si votre configuration est un cluster à deux noeuds, vous devez également indiquer si votre interconnexion est connectée directement (adaptateur à adaptateur) ou utilise une jonction de transport.

• Jonctions de transport : si vous utilisez des jonctions de transport, par exemple un commutateur réseau, indiquez leurs noms pour chaque interconnexion. Le nom par défaut est switchN, oy N est un nombre affecté automatiquement lors de l'installation. Indiquez également le nom du port de jonction ou acceptez le nom par défaut. Le nom de port par défaut est identique à l'ID du noeud qui héberge l'extrémité adaptateur du câble. Cependant, vous ne pouvez pas utiliser le nom de port par défaut pour certains types d'adaptateurs, tels que SCI.

---

Remarque :

Les clusters à trois noeuds ou plus doivent utiliser des jonctions de transport. La connexion directe entre les noeuds de cluster est possible uniquement pour les clusters à deux noeuds.

---

Vous pouvez configurer des connexions supplémentaires au réseau privé après l'installation à l'aide de l'utilitaire scsetup(1M).

Pour plus d'informations sur les interconnexions de cluster, reportez-vous au document Sun Cluster 3.0 Concepts.

Noms d'host privés

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

Le nom d'host privé est le nom utilisé pour la communication entre les noeuds sur l'interface de réseau privé. Les noms d'host privés sont créés automatiquement lors de l'installation de Sun Cluster et respectent la convention de désignation clusternodeid_noeud-priv, oy id_noeud est le numéro de l'ID de noeud interne. Ce numéro est affecté automatiquement lors de l'installation de Sun Cluster pour chaque noeud qui devient membre du cluster. Après l'installation, vous pouvez modifier les noms d'host privés à l'aide de l'utilitaire scsetup(1M).

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.

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

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

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

• Vous pouvez avoir autant de connexions supplémentaires au réseau public que votre configuration matérielle le permet.

Reportez-vous également à la section "Groupes NAFO" pour plus d'informations sur la planification de groupes d'adaptateurs de réseau public de secours. Pour plus d'informations sur les interfaces de réseau public, reportez-vous au document Sun Cluster 3.0 Concepts.

Groupes d'unités de disque

Ajoutez ces informations de planification à la fiche de travail relative aux configurations des groupes d'unités de disque, disponible dans le document dans Notes de version de Sun Cluster 3.0.

Vous devez configurer tous les groupes de disques du gestionnaire de volumes en tant que groupes d'unités de disque Sun Cluster. Cette configuration permet à des disques multihosts d'être hébergés par un noeud secondaire en cas de panne du noeud principal. Tenez compte des points suivants lorsque vous planifiez des groupes d'unités de disque :

• Reprise sur panne : vous pouvez configurer des disques multiports et des unités du gestionnaire de volumes configurés correctement en tant qu'unités de reprise sur panne. La configuration d'une unité du gestionnaire de volumes est correcte lorsqu'elle inclut des disques multiports et un réglage correct du gestionnaire de volumes lui-même de manière que le périphérique exporté puisse être hébergé par plusieurs noeuds. Il est impossible de configurer des lecteurs de bandes, des CD-ROM ou des disques monoports en tant qu'unités de reprise sur panne.

• Mise en miroir : vous devez mettre les disques en miroir pour protéger les données en cas de panne de disque. Reportez-vous à la documentation de votre gestionnaire de volumes pour plus d'informations sur la mise en miroir.

Pour plus d'informations sur les groupes d'unités de disque, reportez-vous au document Sun Cluster 3.0 Concepts.

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.

Un groupe NAFO (reprise sur panne de l'adaptateur réseau) permet la surveillance et la reprise sur panne des adaptateurs de réseau public. Il constitue la base des ressources d'adresse réseau. En cas de panne de l'adaptateur actif d'un groupe NAFO comportant plusieurs adaptateurs, toutes ses adresses sont transférées sur un autre adaptateur du groupe NAFO. De cette manière, l'adaptateur du groupe NAFO peut maintenir la connectivité de réseau public vers le sous-réseau auquel les adaptateurs du groupe NAFO se connectent.

Tenez compte des points suivants lorsque vous planifiez vos groupes NAFO :

• Chaque adaptateur de réseau public doit appartenir à un groupe NAFO.

• Chaque noeud ne peut comporter qu'un groupe NAFO par sous-réseau.

• Un seul adaptateur dans un groupe NAFO donné peut avoir une association de nom d'host, sous la forme d'un fichier /etc/hostname.adaptateur.

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

Pour plus d'informations sur la reprise sur panne des adaptateurs réseau, reportez-vous au document Sun Cluster 3.0 Concepts.

Périphériques de quorum

Les configurations Sun Cluster utilisent des périphériques de quorum pour préserver l'intégrité des données et des ressources. Si le cluster perd temporairement la connexion à un noeud, le périphérique de quorum évite les problèmes "d'amnésie" ou de dédoublement lorsque le noeud tente de rejoindre le cluster. Pour affecter des périphériques de quorum, lancez l'utilitaire scsetup(1M).

Tenez compte des points suivants lorsque vous planifiez des périphériques de quorum :

• Minimum : un cluster à deux noeuds doit avoir au moins un disque partagé affecté en tant que périphérique de quorum. Pour les autres topologies, les périphériques de quorum sont facultatifs.

• Règle du nombre impair : si vous configurez plus d'un périphérique de quorum dans un cluster à deux noeuds ou dans une paire de noeuds connectée directement au périphérique de quorum, configurez un nombre impair de périphériques de quorum ayant chacun des chemins de panne complètement indépendants.

• Connexion : un périphérique de quorum ne peut pas être connecté à plus de deux noeuds.

Pour plus d'informations sur le quorum, reportez-vous au document Sun Cluster 3.0 Concepts.

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

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

Recommandations relatives aux systèmes de fichiers de cluster 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. Cependant, tenez compte des points suivants lorsque vous planifiez la disposition de vos périphériques globaux et de vos systèmes de fichiers de cluster :

• 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 unités d'extension de disque.

• Disponibilité : un périphérique global doit avoir une connexion physique avec plusieurs noeuds du cluster pour être considéré comme hautement disponible. Cette configuration 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 cluster

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

• 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 cluster, 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 cluster. Par exemple, ne définissez par 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, car le point de montage parent risque de ne pas être présent. 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

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

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). Vous ne pouvez utiliser qu'un gestionnaire de volumes au sein d'une même configuration de cluster. Reportez-vous à la documentation du gestionnaire de volumes et à l'Annexe A ou à l'Annexe B pour obtenir des instructions sur la configuration du logiciel de gestion de volumes. Pour plus d'informations sur la gestion des volumes dans une configuration de cluster, reportez-vous au document Sun Cluster 3.0 Concepts.

Ajoutez ces informations de planification aux fiches de travail relatives à la configuration des groupes d'unités de disque et à la configuration du gestionnaire de volumes disponibles dans le document Notes de version de Sun Cluster 3.0, et, le cas échéant, à la fiche de travail relative aux métapériphériques (Solstice DiskSuite) disponible dans le document Notes de version de Sun Cluster 3.0.

Recommandations relatives au logiciel de gestion des volumes

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

• Disques multihosts mis en miroir : vous devez mettre tous les disques multihosts en miroir sur des unités d'extension de disque. Voir "Mise en miroir des disques multihosts" pour plus d'informations sur la mise en miroir des disques multihosts.

• Root mis 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 plus d'informations sur la mise en miroir du disque root.

• Noms uniques : sur tout noeud de cluster, 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 tout le cluster.

• 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 disque. Reportez-vous aux instructions de planification des groupes de ressources dans le document Sun Cluster 3.0 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 le cluster 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 oy 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 remplagables à chaud : vous pouvez utiliser des disques remplagables à 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 à Solstice DiskSuite

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

• 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'host 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 hosts). 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 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 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 du cluster. Par exemple, si un cluster 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. Le nombre maximal de métapériphériques autorisé par ensemble de disques est de 8192.

  • 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 du cluster. Vous devez définir la valeur de md_nsets en fonction du nombre prévu d'ensembles de disques du cluster, plus un pour permettre au logiciel Solstice DiskSuite de gérer les disques privés sur l'host 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és par cluster est de 32.

  Définissez ces champs au moment de l'installation en tenant compte des éventuelles extensions futures du cluster. L'augmentation de ces valeurs lorsque le cluster est 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 cluster 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 des pertes de données.

  ---

Recommandations relatives à 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 disque utilisera au moment de la création de ce groupe.

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

  • Si ce nombre est supérieur ou égal à 1000, vous devez prévoir avec soin le mode d'affectation des codes mineurs aux volumes du groupe d'unités de disque. Il est impossible d'affecter des codes 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 les systèmes de fichiers de cluster. Sun Cluster prend en charge les systèmes de fichiers de journalisation suivants :

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

• Solaris UFS logging

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) et au Solaris Transition Guide.

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	Solstice DiskSuite trans-metadevice UFS logging, Solaris 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 : avec Solstice DiskSuite trans-metadevice UFS logging, le trans-périphérique utilisé pour la journalisation crée un métapériphérique. Le journal reste cependant un métapériphérique distinct que vous pouvez mettre en miroir et en bandes. En outre, le logiciel Solstice DiskSuite permet de créer un système de fichiers de journalisation maximum de 1 To.

Recommandations relatives à la mise en miroir

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

Mise en miroir des disques multihosts

La mise en miroir de tous les disques multihosts 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 multihosts sur les unités d'extension de disque.

Tenez compte des points suivants lors de la mise en miroir des disques multihosts.

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

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

• Mise en miroir à trois voies : VERITAS Volume Manager 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 le les disques multihosts, reportez-vous au document Sun Cluster 3.0 Concepts.

Mise en miroir du disque root

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 le disque root en miroir, tenez compte des risques, de la complexité, du co{t et du temps de maintenance des différentes alternatives. Il n'existe pas de stratégie de mise en miroir valable pour toutes les configurations. Pour savoir si vous devez ou non appliquer la mise en miroir au disque root, contactez votre interlocuteur Enterprise Services.

Reportez-vous à la documentation du gestionnaire de volumes et à l'Annexe A ou à l'Annexe B 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.

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

• Contrtleurs distincts : pour une disponibilité maximale, le disque root doit être mis en miroir sur un contrtleur 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 sont 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 stade, le système est particulièrement sensible aux problèmes d'obsolescence des sous-miroirs.