Guide d'installation du logiciel Sun Cluster pour SE Solaris

Chapitre 1 Planification de la configuration Sun Cluster

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

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

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 Informations relatives aux tâches d'installation du logiciel Sun Cluster


Tâche	Instructions
Installation matérielle du cluster	Sun Cluster 3.1 - 3.2 Hardware Administration Manual for Solaris OS Documentation fournie avec votre serveur et vos périphériques de stockage
Planification de l'installation du logiciel de cluster	Chapitre 1, Planification de la configuration Sun Cluster Fiches d'installation et de configuration
Installation des packages Facultativement, installez et configurez le logiciel Sun StorEdge^TM QFS.	Installation du logiciel Sun StorEdge QFS Installation and Upgrade Guide
Établissement d'un cluster ou d'un nœud	Établissement d'un cluster ou d'un nœud
Configurez le logiciel Solaris Volume Manager.	Configuration du logiciel Solaris Volume Manager Documentation de Solaris Volume Manager
Installation et configuration du logiciel VERITAS Volume Manager (VxVM)	Installation et configuration du logiciel VxVM Documentation de VxVM
Configurez des systèmes de fichiers de cluster, le cas échéant.	Création de systèmes de fichiers de cluster
(Facultatif) Sous Solaris 10, créez des zones non globales.	Création d'une zone non globale sur un nœud de cluster
(Facultatif) SPARC : : installation et configuration du module Sun Cluster dans Sun Management Center.	SPARC : installation du module Sun Cluster pour Sun Management Center Documentation Sun Management Center
Planification, installation et configuration des services de données et des groupes de ressources Créez des systèmes de fichiers locaux à haute disponibilité, le cas échéant.	Sun Cluster Data Services Planning and Administration Guide for Solaris OS
Développement de services de données personnalisés	Sun Cluster Data Services Developer’s Guide for Solaris OS

Planification du SE Solaris

Cette rubrique explique comment planifier l'installation du logiciel Solaris dans une configuration de cluster.

Pour obtenir 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 DVD 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 un procédé d'installation personnalisé permettant d'installer à la fois le système d'exploitation Solaris et le logiciel Sun Cluster à l'aide de la méthode d'installation JumpStart. Si vous installez plusieurs nœuds de cluster, nous vous recommandons une installation en réseau.

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

Restrictions d'utilisation des fonctions du système d'exploitation Solaris

Lorsque vous envisagez d'utiliser le système d'exploitation Solaris dans un environnement Sun Cluster, vous devez tenir compte des points suivants :

Zones Solaris 10 - Installez le logiciel de structure Sun Cluster dans la zone globale uniquement.

Pour déterminer si vous pouvez installer un service de données Sun Cluster directement dans une zone non globale, reportez-vous à la documentation de ce service de données.

Le système de fichiers loopback (LOFS) doit être activé si vous configurez des zones non globales sur un nœud de cluster. Reportez-vous aux informations sur le système LOFS pour plus de détails.
LOFS (loopback file system) - Pendant la création de cluster avec la version Solaris 9 du logiciel Sun Cluster, les fonctionnalités LOFS sont désactivées par défaut. Pendant la création de cluster avec la version Solaris 10 du logiciel Sun Cluster, les fonctionnalités LOFS sont activées par défaut.

Si le cluster répond aux deux conditions suivantes, vous devez désactiver le système LOFS pour éviter des problèmes de basculement ou d'autres échecs :
- Sun Cluster HA pour NFS est configuré sur un système de fichiers local à haute disponibilité.
- Le démon automountd est en cours d'exécution.
Si le cluster ne répond qu'à l'une de ces conditions, vous pouvez activer le système LOFS en toute sécurité.

Si vous avez besoin d'activer le système LOFS et le démon automountd, excluez du schéma de montage tous les fichiers du système local à haute disponibilité exporté par Sun Cluster HA pour NFS.
Groupes d'interfaces - Les groupes d'interface Solaris ne sont pas pris en charge dans une configuration Sun Cluster. La fonctionnalité de groupes d'interfaces Solaris est désactivée par défaut pendant l'installation du logiciel Solaris. ne la réactivez pas. Reportez-vous à la page de manuel ifconfig(1M) pour plus d'informations sur les groupes d'interfaces Solaris.
arrêt de l'économie d'énergie - L'arrêt automatique de l'économie d'énergie n'est pas pris en charge par les configurations de Sun Cluster et ne doit pas être activé. Reportez-vous aux pages de manuel pmconfig(1M) et power.conf(4) pour plus d'informations.
IP Filter - Le logiciel Sun Cluster ne prend pas en charge la fonctionnalité Solaris IP Filter, mais prend en charge Solaris IP Filter pour les services de basculement.
fssnap - Le logiciel Sun Cluster ne prend pas en charge la commande fssnap, qui est une fonctionnalité d'UFS. Vous pouvez cependant utiliser la commande fssnap sur des systèmes locaux qui ne sont pas contrôlés par le logiciel Sun Cluster software. Les restrictions suivantes s'appliquent à la prise en charge fssnap :
- La commande fssnap est prise en charge sur les systèmes de fichiers locaux qui ne sont pas gérés par le logiciel Sun Cluster.
- La commande fssnap n'est pas prise en charge sur les systèmes de fichiers de cluster.
- La commande fssnap n'est pas prise en charge sur les systèmes de fichiers locaux sous le contrôle de HAStoragePlus.

À propos des groupes de logiciels Solaris

Le logiciel Sun Cluster 3.2 2/08 implique l’installation du groupe de logiciels de support système utilisateur final Solaris. Il est possible que d'autres composants de la configuration de votre cluster requièrent leurs propres logiciels Solaris. Prenez connaissance des informations présentées ci-dessous pour déterminer le groupe de logiciels Solaris que vous devez installer.

Serveurs : reportez-vous à la documentation de votre serveur pour connaître la configuration minimale requise par Solaris. Par exemple, les serveurs Sun Enterprise^TM 10000 nécessitent l'intégralité du groupe de logiciels Solaris Plus la prise en charge OEM.
adaptateurs SCI-PCI - Pour utiliser des adaptateurs SCI-PCI, disponibles dans les clusters basés SPARC uniquement ou Interface de programmation d'application de mémoire partagée distante (RSMAPI), veillez à installer les packages du logiciel RSMAPI, SUNWrsm et SUNWrsmo et pour le système d'exploitation Solaris 9 sur plates-formes basées SPARC SUNWrsmx et SUNWrsmox. Les packages RSMAPI sont inclus uniquement dans certains groupes de logiciels Solaris. Par exemple, les packages RSMAPI sont inclus dans Developer Solaris Software Group (groupe de logiciels développeur de Solaris), mais pas dans End User Solaris Software Group (groupe de logiciels utilisateur final).

Si le groupe de logiciels que vous installez n'inclut pas les packages RSMAPI, installez-les manuellement avant Sun Cluster La commande pkgadd(1M) vous permet d'installer manuellement les packages de logiciels. Pour obtenir plus d'informations sur l'utilisation de RSMAPI, reportez-vous à la section (3RSM) des pages de manuel.
Autres packages Solaris : vous devrez peut-être installer d'autres packages du logiciel Solaris ne faisant pas partie du groupe de logiciels Solaris utilisateur final. comme par exemple les packages du serveur HTTP Apache. Les logiciels d'autres éditeurs, par exemple ORACLE®, peuvent aussi nécessiter des packages de logiciels Solaris supplémentaires. Reportez-vous à la documentation du fournisseur tiers pour connaître la configuration logicielle nécessaire de Solaris.

Astuce –

Pour éviter d'avoir à installer manuellement les packages Solaris, installez la prise en charge Entire Solaris Software Group Plus OEM.

Partitions du disque système

Ajoutez ces informations à la Fiche de travail de configuration des systèmes de fichiers locaux appropriée.

Lors de l'installation du système d'exploitation Solaris, veillez à créer les partitions Sun Cluster requises et assurez-vous que toutes les partitions répondent aux conditions requises en termes d'espace minimum.

swap – L'espace swap total alloué à Solaris et au logiciel Sun Cluster ne doit pas être inférieur à 750 Mo. Pour obtenir des résultats optimaux, ajoutez au moins 512 Mo pour le logiciel Sun Cluster à l'espace requis par le système d'exploitation Solaris. En outre, vous devez allouer tout espace swap supplémentaire requis par les applications qui seront exécutées sur le noeud du cluster.

Remarque –
Si vous créez un fichier swap supplémentaire, ne le faites pas sur un périphérique global. Utilisez un disque local comme périphérique swap pour le nœud.
/globaldevices – Créez un système de fichiers d'au moins 512 Mo que l'utilitaire scinstall(1M) pourra utiliser pour les périphériques globaux.
Gestionnaire de volumes – Créez une partition de 20 Mo sur la tranche 7, destinée au gestionnaire de volumes. Si votre cluster utilise VERITAS Volume Manager (VxVM;) et que vous prévoyez d'encapsuler le disque racine, 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 du SE 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 avec tout autre système exécutant le système d'exploitation Solaris, vous pouvez configurer les répertoires racine (/), /var, /usr et /opt en tant que systèmes de fichiers séparés ou inclure tous les répertoires dans le système de fichiers racine (/). Vous trouverez ci-dessous une description du contenu logiciel des répertoires racine (/), /var, /usr et /opt dans une configuration Sun Cluster. Tenez compte de ces informations lorsque vous planifiez votre projet de partitionnement.

racine (/) : le logiciel Sun Cluster occupe lui-même moins de 40 Mo d'espace dans le système de fichiers racine (/). Le logiciel Solaris Volume Manager requiert moins de 5 Mo et le logiciel VxVM moins de 15 Mo. Pour bénéficier de plus d'espace et de capacité de l'inode, ajoutez au moins 100 Mo à la quantité généralement attribuée au système de fichiers racine ( /). Cet espace est utilisé dans le cadre de la création de périphériques spéciaux en mode bloc et en mode caractère utilisés par le logiciel de gestion de volumes. Cet espace supplémentaire est particulièrement nécessaire si un nombre important de disques partagés se trouve dans le cluster.
/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 nœud de cluster peut être plus important que sur un serveur autonome classique. Allouez donc au moins 100 Mo au système de fichiers /var.
/usr : le logiciel Sun Cluster occupe moins de 25 Mo d'espace dans le système de fichiers /usr. Les logiciels Solaris Volume Manager et VxVM requièrent chacun moins de 15 Mo.
/opt: le logiciel de structure Sun Cluster utilise 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 Solaris Volume Manager 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 packages 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 le cluster, vous avez besoin de 25 Mo supplémentaires sur chaque nœud pour la prise en charge de l'agent Sun Management Center et des packages de modules Sun Cluster.

Recommandations relatives au système de fichiers `/globaldevices`

Sun Cluster exige que vous réserviez un système de fichiers dédié sur l'un des disques locaux pour la gestion des périphériques globaux. Ce système de fichiers se trouve en général sur votre disque root. Cependant, si vous utilisez un stockage différent, sur lequel placer le système de fichiers, tel qu'un volume Logical Volume Manager, il ne doit pas faire partie d'un ensemble de disques partagé Solaris Volume Manager ou d'un autre groupe de disques VxVM qu'un groupe de disques root. Ce système de fichiers est monté plus tard comme un système de fichiers de cluster. Pour ce système de fichiers, utilisez le nom par défaut /globaldevices reconnu par la commande scinstall(1M).

Par la suite, la commande scinstall renomme le système de fichiers en /global/.devices/node@id_nœud, où id_nœud représente le numéro assigné à un nœud lorsque celui-ci devient un élément du cluster. Le point initial de montage, /globaldevices, est supprimé.

Le système de fichiers /globaldevices doit disposer d'espace et d'une capacité d'inode suffisants pour créer les périphériques spéciaux en mode bloc et les dispositifs de caractères spéciaux. Cette instruction est particulièrement importante si le cluster comprend un grand nombre de disques. Un système de fichiers de 512 Mo doit suffire à la plupart des configurations de cluster.

Exigences du gestionnaire de volumes

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

Si vous utilisez VERITAS Volume Manager (VxVM) et que vous envisagez d'encapsuler le disque racine, deux tranches inutilisées devront être consacrées à VxVM. En outre, vous aurez besoin d'un espace libre supplémentaire non assigné soit au début, soit à la fin du disque. Pour de plus amples informations sur l'encapsulation du disque racine, reportez-vous à la documentation VxVM.

Exemples d'allocation de système de fichiers

Le Tableau 1–2 présente un schéma de partitionnement pour un nœud de cluster occupant moins de 750 Mo de mémoire physique. Ce schéma doit être installé avec le groupe de logiciels d'utilisateur final Solaris, le logiciel Sun Cluster et le service de données Sun Cluster HA pour NFS. La dernière tranche du disque, la tranche 7, se voit allouer un petit espace destiné au gestionnaire de volumes.

Cette répartition permet d'utiliser Solaris Volume Manager ou VxVM. Si vous utilisez Solaris Volume Manager, vous pouvez réserver la tranche 7 pour la réplique de base de données d'état. 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	Sommaire	Taille allouée	Description
0	`/`	6,75 Go	Espace libre restant sur le disque après l'allocation d'espace aux tranches 1 à 7. Utilisé pour le système d’exploitation Solaris, le logiciel Sun Cluster, le logiciel de services de données, le gestionnaire de volumes, l'agent Sun Management Center et les packages de l'agent du module Sun Cluster, les systèmes de fichiers root et les logiciels de bases de données et d’applications.
1	`swap`	1 Go	512 Mo pour le système d'exploitation Solaris. 512 Mo pour le logiciel Sun Cluster.
2	chevauchement	8,43 Go	Totalité du disque.
3	`/globaldevices`	512 Mo	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'encapsulation du disque racine sous VxVM.
5	inutilisée	-	-
6	inutilisée	-	-
7	gestionnaire de volumes	20 Mo	Utilisé par le logiciel Solaris Volume Manager pour la réplique de la base de données d'état ou par VxVM pour l'installation après la libération de la tranche.

Procédures relatives aux zones non globales d'un cluster

Pour plus d'informations sur la finalité et la fonction des zones Solaris 10 d'un cluster, reportez-vous à la rubrique Support for Solaris Zones on Sun Cluster Nodes du Sun Cluster Concepts Guide for Solaris OS.

Tenez compte des points suivants lors de la création d'une zone non globale Solaris 10, nommée plus simplement une zone, sur un nœud de cluster.

Nom de zone unique : le nom de zone doit être unique dans le nœud. N'indiquez pas le même nom pour plusieurs zones sur un même nœud.
Réutilisation d'un nom de zone sur plusieurs nœuds : pour simplifier l'administration du cluster, vous pouvez utiliser le même nom pour une zone sur chaque nœud où des groupes de ressources doivent être mis en ligne dans cette zone.
Adresses IP privées : n'essayez pas d'utiliser plus d'adresses IP privées qu'il n'y en a de disponibles dans le cluster.
Montages : n'incluez pas de montages globaux dans les définitions de zones. Incluez uniquement des montages loopback.
Services de basculement : dans les clusters à plusieurs nœuds, Sun Cluster vous permet de préciser différentes zones sur le même nœud dans la liste de nœuds d'un groupe de ressources de basculement, mais ceci n'est utile que lors de tests. Si un nœud unique héberge toutes les zones de la liste de nœuds, le nœud devient un point de panne unique pour le groupe de ressources. Pour une disponibilité maximale, les zones de la liste de nœuds d'un groupe de ressources de basculement doivent se trouver sur des nœuds différents.

Dans les clusters à nœud unique, il n'existe aucun risque fonctionnel si vous indiquez plusieurs zones dans la liste de nœuds d'un groupe de ressources de basculement.
Services évolutifs : ne créez pas de zones non globales à utiliser dans un même service évolutif sur le même nœud. Chaque instance du service évolutif doit être exécutée sur un nœud de cluster différent.
LOFS : les zones Solaris requièrent que le système de fichiers loopback (LOFS) soit activé. Cependant, le service de données Sun Cluster HA pour NFS requiert que le LOFS soit désactivé afin d'éviter les problèmes de commutation ou d'autres pannes. Si vous configurez à la fois des zones non globales et Sun Cluster HA pour NFS dans votre cluster, effectuez l'une des actions suivantes pour éviter des problèmes éventuels au niveau du service de données :
- Désactivez le démon automountd.
- Dans la mappe automounter, excluez tous les fichiers appartenant au système de fichiers local hautement disponible exporté par Sun Cluster HA pour NFS. :

Planification de l'environnement Sun Cluster

Cette rubrique indique comment planifier et préparer les composants ci-dessous pour l'installation et la configuration du logiciel Sun Cluster.

Pour obtenir plus d'informations sur les composants Sun Cluster, reportez-vous à Sun Cluster Overview for Solaris OS et à Sun Cluster Concepts Guide for Solaris OS.

Octroi de licence

Assurez-vous de bien posséder les certificats de licence nécessaires avant de commencer l'installation du logiciel. Le logiciel Sun Cluster ne nécessite pas de certificat de licence, mais chaque noeud sur lequel il est installé doit être couvert par votre contrat de licence pour le logiciel Sun Cluster.

Pour connaître les licences requises par le gestionnaire de volumes et les applications, reportez-vous aux documentations d'installation de ces produits.

Patchs logiciels

Après avoir installé chacun des logiciels, vous devez également installer les patchs éventuellement requis.

Pour obtenir des informations sur les patchs actuellement requis, reportez-vous à la rubrique Patchs et niveaux requis pour les microprogrammes dans le manuel Sun Cluster 3.2 2/08 Release Notes for Solaris OS ou consultez votre fournisseur de services Sun.
Pour connaître les procédures générales d'application des patchs, reportez-vous au Chapitre 10, Patching Sun Cluster Software and Firmware du Sun Cluster System Administration Guide for Solaris OS.

Adresses IP réseau public

Pour des informations sur l'utilisation de réseaux publics par le cluster, reportez-vous à Public Network Adapters and IP network multipathing du Sun Cluster Concepts Guide for Solaris OS.

Vous devez définir un certain nombre d'adresses IP réseau public 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 qui nécessitent des adresses IP réseau public. Ajoutez ces adresses IP aux emplacements suivants :

tout service d'attribution de noms utilisé ;
le fichier /etc/inet/hosts local de chaque nœud de cluster après l'installation de Solaris ;
sous Solaris 10, le fichier /etc/inet/ipnodes de chaque nœud de cluster après l'installation de Solaris.

Tableau 1–3 Composants Sun Cluster utilisant des adresses IP réseau public


Composant	Nombre d'adresses IP nécessaires
Console administrative	1 adresse IP par sous-réseau.
Nœuds de cluster	1 adresse IP par nœud et par sous-réseau.
Interface réseau de la console de domaine (Sun Fire^TM 15000)	1 adresse IP par domaine.
(Facultatif) Zones non globales	1 adresse IP par sous-réseau.
Périphériques d'accès par console	1 adresse IP.
Adresses logiques	1 adresse IP par ressource d'hôte logique et par sous-réseau.
Serveur de quorum	1 adresse IP.

Pour plus d'informations sur la planification des adresses IP, reportez-vous au Chapitre 3, Planning Your TCP/IP Network (Task) du System Administration Guide: IP Services (Solaris 9) ou au Chapitre 2, Planning Your TCP/IP Network (Tasks) du System Administration Guide: IP Services (Solaris 10).

Périphériques d'accès par console

Vous devez disposer d'un accès par console à l'ensemble des noeuds de cluster. Si vous installez le logiciel Cluster Control Panel sur une console administrative, vous devez indiquer le nom d'hôte et le numéro de port du périphérique d'accès par console utilisé pour communiquer avec les nœuds du cluster.

Un concentrateur de terminal est utilisé pour établir la communication entre la console administrative et les consoles de noeuds du cluster.
Un serveur Sun Enterprise 10000 utilise un processeur SSP (System Service Processor) au lieu d'un concentrateur de terminal.
Un serveur Sun Fire utilise un contrôleur de système au lieu d'un concentrateur de terminal.

Pour plus d'informations sur l'accès par console, reportez-vous au manuel Sun Cluster Concepts Guide for Solaris OS.

Alternativement, si vous connectez une console administrative directement aux nœuds du cluster ou via un réseau de gestion, vous fournissez alors le nom d'hôte de chaque nœud du cluster et son numéro de port série utilisé pour connecter la console administrative ou le réseau de gestion.

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.

Pour plus d'informations, reportez-vous au manuel Sun Cluster Data Services Planning and Administration Guide for Solaris OS. Pour plus d'informations sur les services de données et les ressources, reportez-vous à Sun Cluster Overview for Solaris OS et à Sun Cluster Concepts Guide for Solaris OS.

Réseaux publics

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

Séparation de réseau public et privé - Les réseaux publics et le réseau privé (interconnexion de cluster) doivent utiliser des adaptateurs différents. Vous pouvez également configurer un VLAN marqué sur des adaptateurs VLAN marqués et des commutateurs VLAN pour utiliser le même adaptateur pour l'interconnexion privée et le réseau public.
Minimum - Tous les nœuds de cluster doivent être connectés à au moins un réseau public. Les connexions de réseau public peuvent utiliser différents sous-réseaux pour différents nœuds.
Maximum - La configuration matérielle détermine le nombre maximal de connexions supplémentaires au réseau public dont vous pouvez disposer.
Services évolutifs : tous les nœuds exécutant un service évolutif doivent utiliser le même sous-réseau ou ensemble de sous-réseaux ou utiliser différents sous-réseaux pouvant être acheminés entre eux.
IPv4 : Sun Cluster prend en charge les adresses IPv4 du réseau public.
IPv6 : Sun Cluster prend en charge les adresses IPv6 du réseau public, à certaines conditions :
- Sun Cluster ne prend pas en charge les adresses IPv6 du réseau public si l'interconnexion privée utilise des adaptateurs SCI.
- Sun Cluster prend en charge les adresses IPv6 pour les services de données évolutifs et de basculement.
Groupes IPMP - Chaque adaptateur de réseau publicutilisé pour le trafic de service de données doit appartenir à un groupe Multiacheminement sur réseau IP (IPMP). Si un adaptateur de réseau public n'est pas utilisé pour le trafic de service de données, ne le configurez pas dans un groupe IPMP.

Dans la version Sun Cluster 3.2 2/08, l'utilitaire scinstall ne configure plus automatiquement de groupe IPMP à un seul adaptateur sur chaque adaptateur non configuré du réseau public pendant la création de Sun Cluster. À la place, l'utilitaire scinstall configure automatiquement un groupe IPMP à plusieurs adaptateurs pour chaque ensemble d'adaptateurs de réseau public dans le cluster utilisant le même sous-réseau. Sur Solaris 10, ces groupes sont basés sur une sonde. L'utilitaire scinstall ignore cependant les adaptateurs déjà configurés dans un groupe IPMP. Si un adaptateur dans un groupe IPMP configuré par l'utilitaire scinstall n'utilise pas le trafic de service de données, vous pouvez le supprimer du groupe.

Pour des recommandations et des instructions sur la configuration des groupes IPMP, suivez les procédures dans Partie II, Administering Interface Groups du System Administration Guide: Network Interfaces and Network Virtualization. Pour modifier les groupes IPMP après l'installation du cluster, suivez les recommandations dans How to Administer IP Network Multipathing Groups in a Cluster du Sun Cluster System Administration Guide for Solaris OS et les procédures du Chapitre 28, Administering Network Multipathing (Task) du System Administration Guide: IP Services (Solaris 9) ou Chapitre 8, Administering IPMP du System Administration Guide: Network Interfaces and Network Virtualization(Solaris 10).
Prise en charge d'adresse MAC locale - Tous les adaptateurs de réseau public doivent utiliser des cartes d'interface réseau (NIC) prenant en charge l'affectation d'adresses MAC locales. L'affectation d'adresse MAC locale est une exigence de IPMP.
local-mac-address paramètre - La variable local-mac-address? doit utiliser la valeur par défaut true pour adaptateurs Ethernet. Le logiciel Sun Cluster ne prend pas en charge la valeur local-mac-address? false pour les adaptateurs Ethernet. Cette condition est une modification apportée à Sun Cluster 3.0, qui nécessitait la valeur false pour la variable local-mac-address?.

Pour plus d'informations sur les interfaces de réseau public, reportez-vous à Sun Cluster Concepts Guide for Solaris OS.

Serveurs de quorum

Vous pouvez utiliser le logiciel de serveur de quorum Sun Cluster pour configurer un ordinateur en tant que serveur de quorum, puis configurer le serveur de quorum en tant que périphérique de quorum de votre cluster. Vous pouvez utiliser un serveur de quorum à la place ou en plus des disques SCSI et des classeurs NAS.

Lorsque vous envisagez d'utiliser un serveur de quorum dans un environnement Sun Cluster, vous devez tenir compte des points suivants :

Connexion réseau - L'ordinateur de serveur de quorum permet de se connecter à votre cluster via le réseau public.
Matériel pris en charge - Les plates-formes matérielles prises en charge pour un serveur de quorum sont les mêmes que pour un nœud de cluster.
Système d'exploitation - La configuration logicielle de Solaris pour le logiciel Sun Cluster s'applique également au logiciel de serveur de quorum.
Service pour plusieurs clusters - Vous pouvez configurer un serveur de quorum en tant que périphérique de quorum pour plusieurs clusters.
Matériel et logiciel combiné - Vous n'êtes pas obligé de configurer un serveur de quorum sur les mêmes plates-formes matérielles et logicielles les clusters auxquels il fournit le quorum. Par exemple, un ordinateur SPARC exécutant le SE Solaris peut être configuré en tant que serveur de quorum pour un cluster x86 exécutant le SE Solaris 10.
Utilisation d'un nœud de cluster en tant que serveur de quorum - Vous pouvez configurer un serveur de quorum sur un nœud de cluster afin de fournir le quorum aux clusters autres que le cluster auquel le nœud appartient. Cependant, un serveur de quorum configuré sur un nœud de cluster n'est pas hautement disponible.

Recommandations NFS

Lorsque vous envisagez d'utiliser le système NFS (Network File System) dans un environnement Sun Cluster, vous devez tenir compte des points suivants :

Client NFS : aucun nœud Sun Cluster ne peut être client NFS d'un système de fichiers exporté par Sun Cluster HA pour NFS et dont le maître soit un nœud du même cluster. Un tel montage croisé Sun Cluster HA pour NFS est interdit. Utilisez le système de fichiers du cluster pour répartir les fichiers entre les nœuds.
Protocole NFSv3 : si vous montez des systèmes de fichiers sur des nœuds de cluster à partir de serveurs NFS externes, comme des filtres NAS, et que vous utilisez le protocole NFSv3, vous ne pouvez pas procéder à des montages client NFS et du service de données Sun Cluster HA pour NFS sur le même nœud de cluster. Dans ce cas, certaines tâches du service de données Sun Cluster HA pour NFS peuvent entraîner l'arrêt et le redémarrage des démons NFS, interrompant ainsi des services NFS. Vous pouvez cependant exécuter le service de données Sun Cluster HA pour NFS en toute sécurité si vous utilisez le protocole NFSv4 pour monter des systèmes de fichiers NFS externes sur les nœuds de cluster.
Blocage : les applications exécutées localement sur le cluster ne doivent pas verrouiller les fichiers sur un système de fichiers exporté via NFS. Si vous ne suivez pas cette recommandation, le blocage local (par exemple, flock(3UCB) ou fcntl(2)) risque d'entraver le redémarrage du gestionnaire de blocage (lockd(1M)). Lors du redémarrage, il est possible qu'un processus local bloqué soit verrouillé et que seul un client distant puisse le déverrouiller. Le comportement qui s'ensuit est imprévisible.
Fonctions de sécurité NFS : Sun Cluster ne prend pas en charge les options suivantes de la commande share_nfs(1M) :
- secure
- sec=dh
Toutefois, Sun Cluster prend en charge les fonctions de sécurité suivantes pour NFS :
- L'utilisation de ports sécurisés pour NFS. Pour activer les ports sécurisés pour NFS, ajoutez le paramètre d'entrée nfssrv:nfs_portmon=1 dans le fichier /etc/system des nœuds de cluster.
- L'utilisation de Kerberos avec NFS. Pour plus d'informations, reportez-vous à Securing Sun Cluster HA for NFS With Kerberos V5 du Sun Cluster Data Service for NFS Guide for Solaris OS.

Restrictions de service

Veillez à respecter les restrictions de service suivantes dans les environnements Sun Cluster :

Routeurs - Ne configurez pas les nœuds du cluster en tant que routeurs (passerelles). Si le système est immobilisé, les clients ne pourront pas trouver de routeur alternatif et, de ce fait, effectuer une reprise.
NIS+ serveurs - Ne configurez pas nœuds de cluster en tant que serveurs NIS ou NIS+. Il n'existe aucun service de données disponible pour NIS ou NIS+. Les nœuds de cluster peuvent toutefois être des clients NIS ou NIS+.
Serveurs d'initialisation et d'installation : n'utilisez pas une configuration Sun Cluster pour fournir un service d'initialisation ou d'installation à haute disponibilité sur des systèmes clients.
RARP - N'utilisez pas de configuration Sun Cluster pour fournir un service rarpd.
numéros de programme RPC - Si vous installez un service RPC sur le cluster, le service ne doit utiliser aucun des numéros de programme suivants :
- 100141
- 100142
- 100248
Ces numéros sont réservés respectivement aux démons Sun Cluster rgmd_receptionist , fed et pmfd.

Si le service RPC installé utilise l'un de ces numéros, vous devez lui en attribuer un autre.
Classes de programmation - Le logiciel Sun Cluster ne prend pas en charge l'exécution de classes de programmation à processus de haute priorité sur les nœuds de cluster. N'exécutez aucun des types de processus suivants sur les nœuds du cluster :
- processus s'exécutant dans la classe de programmation en temps partagé avec une priorité élevée ;
- processus s'exécutant dans la classe de programmation en temps réel.
Le logiciel Sun Cluster s'appuie sur des threads du noyau ne s'exécutant pas dans la classe en temps réel. D'autres processus en temps partagé s'exécutant avec une priorité supérieure à la normale ou des processus en temps réel peuvent empêcher les threads du noyau de Sun Cluster d'acquérir les cycles CPU requis.

Composants configurables de Sun Cluster

Cette rubrique fournit des instructions pour les composants de Sun Cluster suivants que vous configurez.

Ajoutez ces informations à la fiche de configuration appropriée.

Nom du cluster

Nommez le cluster au cours de la configuration de Sun Cluster. Ce nom doit être unique dans toute l'entreprise.

Noms des noeuds

Le nom du nœud de cluster est celui que vous affectez à une machine lorsque vous l'installez avec le système d'exploitation Solaris. Reportez-vous à la page de manuel hosts(4) pour plus d'informations sur les exigences d'attribution de nom.

Dans les installations de cluster à un nœud, le nom par défaut du cluster est celui du nœud.

Pendant la configuration de Sun Cluster, indiquez le nom de tous les nœuds que vous installez dans le cluster.

Noms des zones

Sous Solaris 10, la convention d'attribution du nom nodename :zonename vous permet de spécifier une zone non globale à une commande Sun Cluster.

nodename est le nom du nœud de cluster.
zonename est le nom attribué à la zone non globale à la création de la zone sur le nœud. Le nom de zone doit être unique sur le nœud. Vous pouvez cependant utiliser le même nom de zone sur différents nœuds car le nom de nœud différent nodename:zonename rend le nom de la zone non globale unique dans le cluster.

Pour spécifier la zone globale, ne spécifiez que le nom de nœud.

Réseau privé

Remarque –

vous n'avez pas besoin de configurer un réseau privé pour un cluster à noeud unique. L'utilitaire scinstall attribue automatiquement l'adresse réseau privé et le masque réseau par défaut, même si le cluster n'utilise pas de réseau privé.

Sun Cluster utilise le réseau privé pour la communication interne entre les nœuds et entre les zones non globales gérés par Sun Cluster. La configuration de Sun Cluster nécessite au moins deux connexions pour procéder à l'interconnexion du cluster sur le réseau privé. Lorsque vous configurez Sun Cluster sur le premier nœud du cluster, spécifiez l'adresse réseau privé et le masque réseau de l'une des manières suivantes :

Acceptez l'adresse réseau privé (172.16.0.0) et le masque réseau (255.255.248.0) par défaut. Cette plage d'adresses IP accepte un maximum combiné de 64 nœuds et zones non globales et un maximum de 10 réseaux privés.

Remarque –
Le nombre maximum de nœuds pouvant être accepté par une plage d'adresses IP ne représente pas le nombre maximum de nœuds que la configuration matérielle peut prendre en charge.
Spécifiez une autre adresse réseau privé autorisée et acceptez le masque réseau par défaut.
Acceptez l'adresse réseau privé par défaut et spécifiez un autre masque réseau.
Spécifiez une autre adresse réseau privé et un autre masque réseau.

Si vous choisissez de spécifier un autre masque réseau, l'utilitaire scinstall vous invite à indiquer le nombre de nœuds et de réseaux privés pouvant être acceptés par la plage d'adresses IP. Le nombre de nœuds spécifié doit également inclure le nombre de zones non globales que le réseau privé pourra utiliser.

L'utilitaire calcule le masque réseau pour la plage d'adresses IP minimum qui prendra en charge le nombre de nœuds et de réseaux privés spécifié. Le masque réseau calculé peut prendre en charge plus que le nombre de nœuds fourni, zones non globales incluses, et de réseaux privés. L'utilitaire scinstall calcule également un second masque réseau qui pourrait être le minimum pour prendre en charge deux fois le nombre de nœuds et de réseaux privés. Ce second masque réseau pourrait permettre au cluster d'accepter une croissance future sans devoir reconfigurer la plage d'adresses IP.

L'utilitaire vous demande ensuite le masque réseau souhaité. Vous pouvez spécifier l'un des masques réseau calculés ou en fournir un autre. Le masque réseau spécifié doit au minimum prendre en charge le nombre de nœuds et de réseaux privés indiqué à l'utilitaire.

Remarque –

Pour modifier l'adresse réseau privé et le masque réseau après l'établissement du cluster, reportez-vous à la rubrique How to Change the Private Network Address or Address Range of an Existing Cluster du Sun Cluster System Administration Guide for Solaris OS. Vous devez arrêter le cluster pour apporter ces modifications.

Une modification de la plage d'adresses IP privées peut être nécessaire pour prendre en charge l'ajout de nœuds, zones non globales incluses, ou de réseaux privés.

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

Taille d'adresse et de masque réseau : l'adresse réseau privé ne peut pas être inférieure au masque réseau. Par exemple, vous pouvez utiliser l'adresse réseau privé 172.16.10.0 avec le masque réseau 255.255.255.0, mais vous ne pouvez pas utiliser l'adresse réseau privé 172.16.10.0 avec le masque réseau 255.255.0.0.
Adresses acceptables - L'adresse doit figurer dans un bloc d'adresses dont l'utilisation est réservée par la demande de commentaires RFC 1918 dans les réseaux privés. Vous pouvez contacter le centre InterNIC pour obtenir des RFC ou les afficher en ligne à partir de l'adresse http://www.rfcs.org.
Utiliser dans plusieurs clusters : vous pouvez utiliser la même adresse réseau privé dans plusieurs clusters. Les adresses de réseaux IP privés ne sont pas accessibles de l'extérieur du cluster.
IPv6 - Sun Cluster ne prend pas en charge les adresses IPv6 pour l'interconnexion privée. Le système configure les adresses IPv6 sur les adaptateurs de réseau privé pour prendre en charge les services évolutifs utilisant les adresses IPv6. Toutefois, la communication entre les nœuds du réseau privé n'utilise pas ces adresses IPv6.

Reportez-vous à Planifier votre réseau TCP/IP (Tâches), dans le Manuel d'administration système : Services IP (Solaris 9 ou Solaris 10) pour plus d'informations sur les réseaux privés.

Noms d'hôtes privés

Le nom d'hôte privé est le nom utilisé pour la communication entre les nœuds sur l'interface de réseau privé. Ils sont créés automatiquement lors de la configuration de Sun Cluster. Il sont conformes à la convention d'attribution de nom nœud de clusternodeid -priv (nodeid représente le numéro de l'ID du nœud interne). Lors de la configuration de Sun Cluster, ce numéro d'ID est affecté automatiquement à chaque nœud dès lors qu'il devient élément du cluster. Après la configuration du cluster, vous pouvez modifier les noms d'hôtes privés à l'aide de l'utilitaire clsetup(1CL).

Sous Solaris 10, la création d'un nom d'hôte privé pour une zone non globale est facultative. Il n'existe pas de convention d'attribution de nom pour l'hôte privé d'une zone non globale.

Interconnexion de cluster

Les interconnexions de cluster fournissent les voies matérielles pour la communication en réseau privé entre les nœuds du cluster. Chaque interconnexion consiste en un câble connecté de l'une des manières suivantes :

entre deux adaptateurs de transport ;
Entre un adaptateur de transport et un commutateur de transport

Pour plus d'informations sur la finalité et la fonction de l'interconnexion de cluster, reportez-vous à la rubrique Cluster Interconnect du Sun Cluster Concepts Guide for Solaris OS.

Remarque –

vous n'avez pas besoin de configurer une interconnexion de cluster pour un cluster à noeud unique. Cependant, si vous prévoyez d'ajouter par la suite des noeuds à une configuration de cluster à noeud unique, vous souhaiterez probablement configurer l'interconnexion de cluster pour une utilisation future.

Pendant la configuration de Sun Cluster, spécifiez les informations de configuration de une ou deux interconnexions de cluster.

L'utilisation de deux interconnexions de cluster offre une plus grande disponibilité. Si le nombre de ports d'adaptateur disponibles est limité, vous pouvez utiliser des VLANs marqués pour que le réseau public et le réseau privé partagent le même adaptateur. Pour plus d'informations, reportez-vous aux recommandations sur les adaptateurs VLAN marqués dans la rubrique Adaptateurs de transport.
L'utilisation d'une interconnexion de cluster permet de réduire le nombre de ports d'adaptateur utilisés pour l'interconnexion privée mais offre une moins grande disponibilité. En outre, le cluster passe moins de temps en recupération automatique si l'interconnexion privée unique échoue.

Vous pouvez configurer les interconnexions de cluster supplémentaires lorsque le cluster est établi à l'aide de l'utilitaire clsetup(1CL).

Pour obtenir des recommandations sur le matériel d'interconnexion de cluster, reportez-vous à la rubrique Interconnect Requirements and Restrictions du Sun Cluster 3.1 - 3.2 Hardware Administration Manual for Solaris OS. Pour des informations générales sur l'interconnexion de cluster, reportez-vous à Cluster-Interconnect Components du Sun Cluster Overview for Solaris OS et au Sun Cluster Concepts Guide for Solaris OS.

Adaptateurs de transport

Pour les adaptateurs de transport, tels que les ports sur les interfaces réseau, indiquez le nom des adaptateurs et le type de transport. Si votre configuration repose sur un cluster à deux nœuds, vous devez également indiquer si l'interconnexion fait l'objet d'une liaison point-à-point ou si elle utilise un commutateur de transport.

Tenez compte des instructions et restrictions suivantes :

IPv6 - Le logiciel Sun Cluster ne prend pas en charge les communications IPv6 sur les interconnexions privées.
Affectation d'adresse MAC locale : tous les adaptateurs de réseau privé doivent utiliser des cartes d'interface réseau prenant en charge l'affectation d'adresse MAC locale. Les adresses IPv6 à portée locale, requises sur les adaptateurs de réseau privé pour prendre en charge les adresses IPv6 de réseau public, sont dérivées des adresses MAC locales.
Adaptateurs VLAN marqués – Le logiciel Sun Cluster prend en charge les réseaux VLAN (Virtual Local Area Networks) marqués pour partager un adaptateur entre l'interconnexion privée et le réseau public. Lorsque vous configurez un adaptateur VLAN en mode marqué pour l'interconnexion de cluster, indiquez le nom de l'adaptateur et son ID VLAN (VID) de l'une des manières suivantes :
- Indiquez le nom usuel de l'adaptateur, c'est-à-dire le nom du périphérique, suivi du numéro de l'instance ou du point physique de connexion. Par exemple, le nom de l'instance 2 d'un adaptateur Gigabit Ethernet de Cassini serait ce2. Si l'utilitaire scinstall vous demande si l'adaptateur appartient à un réseau local virtuel partagé, répondez yes et indiquez le numéro VID.
- Indiquez l'adaptateur par son nom de périphérique VLAN. Ce nom se compose du nom de l'adaptateur et du numéro de l'instance VLAN. Le numéro de l'instance VLAN est obtenu par la formule (1000*V)+N (V étant le numéro VID et N, le point physique de connexion).
  
  Par exemple, pour VID 73 sur l'adaptateur ce2, le numéro d'instance VLAN calculé pourrait être (1000*73)+2. Vous pourriez alors attribuer à l'adaptateur le nom ce73002 pour indiquer qu'il fait partie d'un LAN virtuel partagé.
Pour plus d'informations sur la configuration d'un VLAN dans un cluster, reportez-vous à Configuring VLANs as Private Interconnect Networks du Sun Cluster 3.1 - 3.2 Hardware Administration Manual for Solaris OS. Pour plus d'informations sur les VLAN, reportez-vous à Administering Virtual Local Area Networks du System Administration Guide: IP Services.
adaptateurs SBus SCI – L'interface SCI (Scalable Coherent Interface) SBus n'est pas prise en charge dans le cadre d'une interconnexion de cluster. En revanche, l'interface SCI-PCI l'est.
Interfaces de réseau logique : les interfaces de réseau logique sont réservées à Sun Cluster.

Pour obtenir plus d'informations sur un adaptateur de transport en particulier, reportez-vous aux pagesde manuel scconf_trans_adap_*(1M).

Commutateurs de transport

Si vous utilisez des commutateurs de transport, tels que commutateur réseau, indiquez un nom de commutateur de transport pour chaque interconnexion. Vous pouvez utiliser le nom par défaut switchN, où N est un numéro automatiquement assigné pendant la configuration ou créer un autre nom.

Indiquez également le nom du port de commutateur ou acceptez le nom par défaut. Le nom de port par défaut est identique à l'ID de noeud interne du noeud qui héberge l'extrémité adaptateur du câble. Cependant, vous ne pouvez pas utiliser le nom de port par défaut pour certains types d'adaptateurs, tels que SCI-PCI.

Remarque –

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

Si votre cluster à deux nœuds utilise une connexion directe, vous pouvez toujours spécifier un commutateur de transport pour l'interconnexion.

Astuce –

Si vous le faites, il sera plus facile d'ajouter un autre nœud au cluster à l'avenir.

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 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 plus d'informations sur la finalité et la fonction des périphériques de quorum, reportez-vous à la rubrique Quorum and Quorum Devices du Sun Cluster Concepts Guide for Solaris OS.

Pendant que Sun Cluster installe un cluster à deux nœuds, vous pouvez choisir de laisser l'utilitaire scinstall configurer automatiquement un périphérique de quorum SCSI ou un périphérique Sun NAS. Vous pouvez choisir ce périphérique de quorum à partir des disques de stockage SCSI disponibles et des périphériques Sun NAS. L'utilitaire scinstall suppose que tous les disques de stockage partagés et disponibles peuvent être utilisés comme périphériques de quorum.

Si vous souhaitez utiliser un serveur de quorum ou un périphérique Network Appliance NAS en tant que périphérique de quorum, configurez-le une fois le traitement scinstall terminé.

Après l'installation, vous pouvez également configurer d'autres périphériques de quorum à l'aide de l'utilitaire clsetup(1CL).

Remarque –

vous n'avez pas besoin de configurer des périphériques de quorum pour un cluster à noeud unique.

Si votre configuration de cluster ne vous autorise pas à utiliser des périphériques partagés de stockage tiers comme périphériques de quorum, vous devez exécuter l'utilitaire clsetup pour configurer manuellement le quorum.

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

Minimum – Un cluster à deux nœuds doit comprendre au moins un périphérique de quorum, qui peut être un disque SCSI partagé, un serveur de quorum ou un périphérique NAS. Pour les autres topologies, les périphériques de quorum sont facultatifs.
Règle du nombre impair : si plusieurs périphériques de quorum sont configurés dans un cluster à deux nœuds ou dans une paire de nœuds directement connectée au périphérique de quorum, vous devez vous assurer qu'ils sont en nombre impair. Cette configuration garantit que les périphériques de quorum ont des chemins défaillants complètement indépendants les uns des autres.
Distribution de votes de quorum : pour une meilleure disponibilité du cluster, veillez à ce que le nombre total de votes associés aux périphériques de quorum soit inférieur au nombre total de votes associés aux nœuds. Sinon, vos nœuds ne pourraient pas constituer un cluster en cas d'indisponibilité de tous les périphériques de quorum, et ce même si tous les nœuds fonctionnent.
Connexion : vous devez connecter un périphérique de quorum à deux nœuds au moins.
protocole de séparation SCSI – Lorsqu'un périphérique de quorum SCSI est configuré, son protocole SCSI est automatiquement défini sur SCSI-2 dans un cluster à deux nœuds ou sur SCSI-3 dans un cluster à trois nœuds ou plus. Vous ne pouvez pas modifier le protocole SCSI d'un périphérique après qu'il a été configuré en tant que périphérique de quorum.
Périphériques répliqués – Le logiciel Sun Cluster ne prend pas en charge les périphériques répliqués en tant que périphériques de quorum.
pools de stockage ZFS - N'ajoutez pas de périphérique de quorum configuré à un pool de stockage ZFS. Lorsqu'un périphérique de quorum configuré est ajouté à un pool de stockage ZFS, le disque est redésigné en tant que disque EFI et les informations de configuration de quorum sont perdues. Le disque ne peut plus fournir de vote de quorum au cluster.

Vous pouvez configurer un disque en tant que périphérique de quorum une fois placé dans un pool de stockage. Vous pouvez également annuler la configuration du périphérique de quorum, l'ajouter au pool de stockage, puis reconfigurer le disque en tant que périphérique de quorum.

Pour plus d'informations sur les périphériques de quorum, reportez-vous aux rubriques Quorum and Quorum Devices du Sun Cluster Concepts Guide for Solaris OS et Quorum Devices du Sun Cluster Overview for Solaris OS.

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

Cette rubrique fournit les recommandations suivantes sur la planification des périphériques globaux et des systèmes de fichiers de cluster :

Périphériques globaux

Pour plus d'informations sur la finalité et la fonction des périphériques globaux, reportez-vous aux rubriques Global Devices, Local Devices, and Device Groups du Sun Cluster Overview for Solaris OS et Global Devices du Sun Cluster Concepts Guide for Solaris OS.

Sun Cluster n'impose pas de contraintes particulières en matière de disposition des disques ou de taille des système de fichiers. Tenez compte des points suivants lors de la planification de la disposition des périphériques globaux.

Mise en miroir : vous devez mettre en miroir tous les périphériques globaux afin que le périphérique global soit considéré comme hautement disponible. Vous n'êtes pas tenu de procéder à une mise en miroir logicielle si le périphérique de stockage dispose de matériel RAID ainsi que de chemins d'accès aux disques redondants.
Disques : lorsque vous effectuez une mise en miroir, organisez les systèmes de fichiers de sorte qu'ils soient mis en miroir sur les baies de disques.
Disponibilité : vous devez connecter physiquement un périphérique global à plusieurs nœuds du cluster 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 nœud 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.
Périphériques de swap : ne créez pas un fichier de swap sur un périphérique global.
Zones non globales - Les périphériques globaux ne sont pas directement accessibles à partir d'une zone non globale. Seules les données de système de fichiers de cluster sont accessibles depuis une zone non globale.

Groupes de périphériques

Pour plus d'informations sur la finalité et la fonction des groupes de périphériques, reportez-vous aux rubriques Global Devices, Local Devices, and Device Groups du Sun Cluster Overview for Solaris OS et Device Groups du Sun Cluster Concepts Guide for Solaris OS.

Ajoutez ces informations de planification à la Fiche de travail relative aux configurations des groupes de périphériques.

Tenez compte des points suivants lorsque vous planifiez des groupes de périphériques.

Basculement : vous pouvez définir des disques multihôtes et des périphériques de gestionnaire de volumes correctement configurés comme périphériques de basculement. Pour qu'un périphérique du gestionnaire de volumes soit correctement configuré, il doit comporter des disques multihôtes et le gestionnaire de volumes doit lui-même être correctement configuré. Cette configuration garantit que les nœuds multiples peuvent héberger le périphérique exporté. Il est impossible de configurer des lecteurs de bandes, des lecteurs de CD-ROM ou de DVD-ROM, ou des périphériques à un seul port comme périphériques de basculement.
Mise en miroir : vous devez mettre les disques en miroir pour protéger les données en cas de défaillance du disque. Pour obtenir plus d'informations, reportez-vous à la rubrique Recommandations relatives à la mise en miroir. Pour connaître la procédure de mise en miroir, reportez-vous à la rubrique Configuration du logiciel Solaris Volume Manager ou à Installation et configuration du logiciel VxVM et à la documentation sur votre gestionnaire de volumes.
Réplication en fonction du stockage - Les disques compris dans un groupe de périphériques doivent être tous répliqués ou aucun ne doit l'être. Un groupe de périphériques ne peut pas utiliser des disques répliqués et non répliqués.

Systèmes de fichiers Cluster

Pour plus d'informations sur la finalité et la fonction des systèmes de fichiers de cluster, reportez-vous aux rubriques Cluster File Systems du Sun Cluster Overview for Solaris OS et Cluster File Systems du Sun Cluster Concepts Guide for Solaris OS.

Remarque –

Alternativement vous pouvez configurer des systèmes de fichiers locaux à haute disponibilité. Ceci permet d'obtenir une meilleure performance de prise en charge d'un service de données avec des E/S élevées ou d'utiliser certaines fonctions de système de fichiers non prises en charge dans un système de fichiers de cluster. Pour plus d'informations, reportez-vous à la rubrique Enabling Highly Available Local File Systems du Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

Lorsque vous planifiez les systèmes de fichiers de cluster, tenez compte des points suivants :

Quotas - Les quotas ne sont pas pris en charge dans les systèmes de fichiers de cluster. Ils le sont cependant sur les systèmes de fichiers locaux à haute disponibilité.
Zones non globales - Si vous devez accéder à un système de fichiers de cluster depuis une zone non globale, il doit être initialement monté dans la zone globale. Le système de fichiers de cluster est ensuite monté dans la zone non globale à l'aide d'un montage loopback. Le système de fichiers loopback (LOFS) doit donc être activé dans un cluster contenant des zones non globales.
Système de fichiers loopback (LOFS) - Pendant la création du cluster avec la version Solaris 9 du logiciel Sun Cluster, le système LOFS est désactivé par défaut. Pendant la création de cluster avec la version Solaris 10 du logiciel Sun Cluster, le système LOFS est activé par défaut.

Vous devez désactiver manuellement LOFS sur chaque nœud de cluster si le cluster répond aux deux conditions suivantes :
- Sun Cluster HA pour NFS est configuré sur un système de fichiers local à haute disponibilité.
- Le démon automountd est en cours d'exécution.
Si le cluster répond à ces deux conditions, vous devez désactiver le système LOFS pour éviter des problèmes de basculement ou d'autres échecs : Si le cluster ne répond qu'à l'une de ces conditions, vous pouvez activer le système LOFS en toute sécurité.

Si vous avez besoin d'activer le système LOFS et le démon automountd, excluez du schéma de montage tous les fichiers du système local à haute disponibilité exporté par Sun Cluster HA pour NFS.
Fichiers journaux de comptabilisation des processus : ne placez pas les fichiers journaux de comptabilisation des processus dans un système de fichiers de cluster ni dans un système de fichiers local à haute disponibilité. La journalisation empêcherait un basculement et provoquerait un blocage du nœud. Utilisez seulement un système de fichiers local pour contenir les fichiers journaux de comptabilisation des processus.
Points limites de communication - Le système de fichiers de cluster ne prend en charge aucune des fonctions de système de fichiers du logiciel Solaris selon lesquelles il est possible d'insérer un point limite de communication dans l'espace de noms du système de fichiers.
- Bien que vous puissiez créer un socket de domaine UNIX portant le nom d'un chemin dans le système de fichiers de cluster, ce socket ne résistera pas à un basculement du nœud.
- Tout FIFO ou canal nommé créé sur un système de fichiers de cluster est globalement inaccessible.
Par conséquent, évitez d'utiliser la commande fattach à partir de tout autre nœud que le nœud local.
Fichiers spéciaux de périphériques : les fichiers spéciaux en mode bloc et en mode caractère sont pris en charge dans un système de fichiers de cluster. Pour spécifier un nom de chemin vers un nœud de périphérique dans un système de fichiers de cluster, créez un lien symbolique vers le nom du périphérique dans le répertoire /dev. N'utilisez pas la commande mknod pour faire cela.
moment a : les systèmes de fichiers de cluster ne conservent pas moment a.
ctime : lorsque vous accédez à un fichier d'un système de fichiers de cluster, la mise à jour de moment c du fichier peut être différée.
Installation d'applications - Si vous souhaitez placer les binaires d'une application à haute disponibilité sur un système de fichiers de cluster, n'installez l'application qu'une fois le système de fichiers de cluster configuré. De même, si l'application est installée à l'aide du programme Sun Java System installer et qu'elle dépend de composants partagés, installez les composants non installés avec l'application sur tous les nœuds du cluster.

Sélection d'options de montage pour des systèmes de fichiers de cluster

Cette section décrit les exigences et restrictions relatives aux types de systèmes de fichiers de cluster suivants :

Remarque –

Vous pouvez également configurer ces types et d'autres encore en tant que systèmes de fichiers locaux à haute disponibilité. Pour plus d'informations, reportez-vous à la rubrique Enabling Highly Available Local File Systems du Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

Suivez ces procédures pour déterminer les options de montage à utiliser lors de la création de vos systèmes de fichiers de cluster.

Systèmes de fichiers de cluster UFS

Option de montage	Utilisation	Description
`global`	requise	Cette option rend le système de fichiers globalement visible de tous les noeuds du cluster.
`journalisation`	requise	Cette option active la consignation.
`forcer direction`	Conditionnelle	Cette option n'est nécessaire qu'aux systèmes de fichiers de cluster qui hébergeront des fichiers de données, fichiers journaux et fichiers de contrôle Oracle RAC RDBMS. Remarque – Oracle RAC n'est pris en charge que sur les clusters SPARC.
`erreur=panique`	requise	Vous n'êtes pas obligé de définir explicitement l'option de montage `erreur=panique` dans le fichier `/etc/vfstab`. Elle constitue déjà la valeur par défaut si aucune autre option de montage `erreur` n'est spécifiée. Remarque – Seule l'option de montage `erreur=panique` est prise en charge par Sun Cluster. N'utilisez pas les options de montage `erreur=démonter` ou `erreur=verrouiller`. Elles ne sont pas prises en charge par les systèmes de fichiers de cluster pour les raisons suivantes : L'utilisation des options de montage `erreur=démonter` ou `erreur=verrouiller` peut verrouiller le système de fichiers de cluster ou le rendre inaccessible. Cette situation peut se présenter si le système de fichiers de cluster a subi une corruption de fichiers. Les options de montage `erreur=démonter` et `erreur=verrouiller` peuvent rendre le système de fichiers non démontable. Cette situation peut ainsi provoquer le blocage d'applications utilisant le système de fichiers de cluster, ou l'impossibilité de tuer les applications. Pour que ce type de noeud récupère, il peut être nécessaire de le réinitialiser.
`dir sync`	FACULTATIF	En spécifiant `dir sync`, vous êtes assuré que le comportement de votre système de fichiers est compatible avec POSIX pour l'appel système `write()`. Si l'option de montage `write()` réussit, cela garantit un espace suffisant sur le disque. Si vous ne spécifiez pas `dir sync`, le comportement est le même que celui des systèmes de fichiers UFS. En effet, le fait de ne pas spécifier `dir sync` peut considérablement améliorer les performances des écritures qui allouent des blocs de disque, par exemple lors de l'ajout de données à la fin d'un fichier. Cependant, dans certains cas, si vous n'utilisez pas `dir sync` vous ne découvrirez que l'espace est insuffisant (`ENOSPC`) qu'au moment de la fermeture d'un fichier. Vous voyez `ENOSPC` fermé seulement pendant une très courte durée après le basculement, tandis qu'avec `dir sync` (et le comportement POSIX), la situation d'espace insuffisant serait découverte avant la fermeture.

Reportez-vous à la page de manuel mount_ufs(1M) pour obtenir plus d'informations sur les options de montage UFS.

Systèmes de fichiers de cluster VxFS

Option de montage	Utilisation	Description
`global`	requise	Cette option rend le système de fichiers globalement visible de tous les noeuds du cluster.
`journal`	requise	Cette option active la consignation.

Reportez-vous à la page de manuel VxFS mount_vxfs et à la rubrique Overview of Administering Cluster File Systems du Sun Cluster System Administration Guide for Solaris OS pour plus d'informations sur les options de montage de VxFS.

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 de point de montage – Créez des points de montage pour les systèmes de fichiers de cluster dans le répertoire /global, sauf si d'autres logiciels vous en empêchent. Ce répertoire vous permet de distinguer facilement les systèmes de fichiers de cluster globaux, des systèmes de fichiers locaux.
Condition de montage SPARC : VxFS – Si vous utilisez VERITAS File System (VxFS) (VxFS), vous devez monter et démonter globalement les systèmes de fichiers VxFS depuis le nœud principal. Le nœud principal contrôle le disque sur lequel se trouve le système de fichiers VxFS. Cette méthode assure la réussite des opérations de montage et de démontage. Tout montage ou démontage d'un système de fichiers VxFS à partir d'un nœud secondaire risque d'échouer.
Restrictions de fonctionnalité SPARC : VxFS -

Les fonctionnalités VxFS suivantes ne sont pas prises en charge dans un système de fichiers de cluster Sun Cluster 3.2. Ces dernières sont cependant prises en charge dans un système de fichiers local.
- E/S rapide ;
- Instantanés
- points de contrôle du stockage ;
- options de montage spécifiques au logiciel VxFS :
  - convosync (Convertir O_SYNC) ;
  - mincache ;
  - qlog, delaylog, tmplog ;
- système de fichiers de cluster VERITAS (requiert la fonction de cluster VxVM et VERITAS Cluster Server).
Les avis de cache peuvent être utilisés, mais ils ne s'appliquent qu'au nœud sélectionné.

Toutes les autres fonctionnalités et options VxFS prises en charge dans un système de fichiers de cluster sont prises en charge par le logiciel Sun Cluster 3.2. Pour de plus amples informations sur les options de VxFS prises en charge dans une configuration de cluster, reportez-vous à la documentation de VxFS.
Imbrication des points de montage : normalement, vous ne devez pas imbriquer les points de montage des systèmes de fichiers de cluster. 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 de rencontrer des problèmes de disponibilité et d'ordre d'initialisation des nœuds. Ces problèmes peuvent survenir si le point de montage parent est absent au moment où le système tente de monter un fils de ce système de fichiers. La seule exception à cette règle s'applique lorsque les périphériques des deux systèmes de fichiers possèdent la même connectivité de nœud physique, par exemple, différentes tranches du même disque.
forcedirectio - Le logiciel Sun Cluster ne prend pas en charge l'exécution de binaires en dehors de systèmes de fichiers de cluster montés à l'aide de l'option forcedirectio.

Planification de la gestion des volumes

Ajoutez ces informations de planification à la Fiche de travail relative aux configurations des groupes de périphériques et à la Fiche de travail relative à la configuration du gestionnaire de volumes. Pour Solaris Volume Manager, ajoutez également ces informations de planification à la Fiche d'information sur les volumes (Solaris Volume Manager).

Cette rubrique donne les recommandations suivantes sur la planification de la gestion de volume de la configuration de votre cluster :

Sun Cluster utilise un logiciel de gestion des volumes pour regrouper les disques par groupes de périphériques pouvant être administrés comme une seule unité. Il prend en charge les logiciels Solaris Volume Manager et VERITAS Volume Manager (VxVM) que vous pouvez installer et utiliser des manières indiquées ci-dessous.

Tableau 1–4 Utilisation des gestionnaires de volumes avec Sun Cluster


Gestionnaire de volumes	Configuration requise
Solaris Volume Manager	Vous devez installer le logiciel Solaris Volume Manager sur tous les nœuds du cluster, que vous utilisiez ou non VxVM sur certains nœuds pour gérer les disques.
SPARC : VxVM avec la fonction de cluster	Vous devez installer VxVM et obtenir la licence correspondante avec la fonction de cluster sur tous les nœuds du cluster.
VxVM sans la fonction cluster	Vous devez installer VxVM et en posséder la licence seulement pour les noeuds liés aux dispositifs de stockage gérés par VxVM.
Solaris Volume Manager et VxVM	Si vous installez ces deux gestionnaires de volumes sur le même noeud, vous devez utilisez le logiciel Solaris Volume Manager pour gérer les disques locaux de chaque noeud. Les disques locaux incluent le disque racine. Utilisez VxVM pour gérer tous les disques partagés.

Pour connaître les procédures d'installation et de configuration, reportez-vous à la documentation sur le gestionnaire de volumes et à la rubrique Configuration du logiciel Solaris Volume Manager ou à Installation et configuration du logiciel VxVM. Pour plus d'informations sur l'utilisation de la gestion de volumes dans une configuration de cluster, reportez-vous à Multihost Devices du Sun Cluster Concepts Guide for Solaris OS et à Device Groups du Sun Cluster Concepts Guide for Solaris OS.

Recommandations relatives au logiciel de gestion des volumes

Tenez compte des instructions générales suivantes lors de la configuration de vos disques à l'aide d'un logiciel de gestion de volumes :

Logiciel RAID – Le logiciel Sun Cluster ne prend pas en charge le logiciel RAID
Disques multihôtes mis en miroir : vous devez mettre tous les disques multihôtes en miroir sur les unités d'extension de disque. Pour obtenir plus d'informations sur la mise en miroir des disques multihôtes, reportez-vous à la rubrique Recommandations relatives à 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 matériel RAID ainsi que de chemins d'accès aux périphériques redondants.
Root mis en miroir : la mise en miroir du disque root assure une disponibilité élevée, mais elle n'est pas obligatoire. Pour savoir comment déterminer si la mise en miroir du disque racine est ou non souhaitable, reportez-vous à la rubrique Recommandations relatives à la mise en miroir.
Attribution de nom unique – Vous pouvez avoir des des Solaris Volume Manager locaux ou des volumes VxVM utilisés en tant que périphériques sur lesquels les systèmes de fichiers /global/.devices/node@nodeid sont montés. Dans ce cas, le nom de chaque volume local sur lequel un système de fichiers /global/.devices/node@nodeid doit être monté, doit être unique sur le cluster.
Listes de nœuds – Pour être hautement disponible, un groupe de périphériques doit posséder des listes de maîtres potentiels et une stratégie de rétablissement en cas de panne identique à celles du groupe de ressources associé. Ou, si un groupe de ressources évolutives utilise plus de nœuds ou de zones que le groupe de périphériques associé, la liste des nœuds du groupe de ressources évolutives doit être un surensemble de la liste des nœuds du groupe de périphériques. Pour obtenir plus d'informations sur les listes de nœuds, reportez-vous au manuel Sun Cluster Data Services Planning and Administration Guide for Solaris OS.
Disques multihôtes – Vous devez connecter ou lier à un nœud tous les périphériques utilisés pour établir un groupe sur tous les nœuds configurés pour ce groupe de périphériques. Le logiciel Solaris Volume Manager peut contrôler automatiquement cette connexion lors de l'ajout de périphériques à un jeu de disques. Cependant, les groupes de disques VxVM configurés ne sont associés à aucun ensemble de nœuds particulier.
Disques hot spare : vous pouvez utiliser des disques hot spare pour accroître la disponibilité, mais ils ne sont pas obligatoires.

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 Solaris Volume Manager

Tenez compte des points suivants lorsque vous planifiez des configurations Solaris Volume Manager.

Noms de volumes locaux – Le nom de chaque volume Solaris Volume Manager local sur lequel un système de fichiers de périphériques globaux, /global/.devices/node@nodeid, est monté, doit être unique sur le cluster. De plus, le nom ne peut pas être le même que celui d'aucun ID de périphérique.
Médiateurs à deux chaînes – Chaque ensemble de disques configuré avec exactement deux chaînes de disques et géré par exactement deux nœuds doit comporter des médiateurs Solaris Volume Manager pour l'ensemble de disques. 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 nœuds et des adaptateurs d'interface. Respectez les règles suivantes pour configurer les médiateurs à deux chaînes :
- Vous devez configurer chaque jeu de disques avec exactement deux nœuds intervenant en tant qu'hôtes médiateurs.
- Vous devez utiliser les deux mêmes nœuds pour tous les jeux de disques nécessitant des médiateurs. Ces deux nœuds doivent contrôler les jeux de disques.
- Les médiateurs ne peuvent pas être configurés pour des jeux de disques ne remplissant pas les conditions requises (deux chaînes et deux hôtes).
Pour obtenir plus d'informations, reportez-vous à la page de manuel mediator(7D).
paramètres /kernel/drv/md.conf – SPARC : Sous Solaris 9, les volumes Solaris Volume Manager qui sont utilisés par chaque ensemble de disques, sont créés à l'avance, au moment de la réinitialisation après reconfiguration. Cette reconfiguration se base sur les paramètres de configuration existant dans le fichier /kernel/drv/md.conf.

Remarque –
Avec la parution de Solaris 10, Solaris Volume Manager a été amélioré et prend désormais en charge la configuration dynamique des volumes. Il n'est plus nécessaire de modifier les paramètres nmd et md_nsets du fichier /kernel/drv/md.conf. Les nouveaux volumes sont créés de manière dynamique, selon vos besoins.

Vous devez modifier les champs nmd et md_nsets comme suit pour prendre en charge une configuration de Sun Cluster sur le SE Solaris 9 :

Caution –
Tous les nœuds de cluster doivent comprendre des fichiers /kernel/drv/md.conf identiques, quel que soit le nombre d'ensembles de disques servis par chaque nœud. Le non-respect de cette consigne peut occasionner de graves erreurs de Solaris Volume Manager et un risque de pertes de données.
- md_nsets : le champ md_nsets définit le nombre total de jeux de disques qui peuvent être créés pour un système afin de répondre aux besoins du cluster entier. Paramétrez la valeur du champ sur le nombre attendu de jeux de disques dans le cluster plus un jeu supplémentaire. Le logiciel Solaris Volume Manager utilise ce dernier pour gérer les disques privés sur l'hôte local.
  
  Le nombre maximal de jeux de disques autorisés par cluster est de 32. Il correspond à 31 jeux de disques dédiés à une utilisation générale plus un jeu destiné à la gestion de disques privés. La valeur par défaut de md_nsets est 4.
- nmd – Le champ nmd définit la valeur la plus élevée du futur nom de volume du cluster. Par exemple, si la valeur la plus élevée des noms de volume utilisés dans les 15 premiers ensembles de disques d'un cluster est égale à 10, mais que la valeur la plus élevée du volume dans le 16ème ensemble de disques est égale à 1000, définissez la valeur du nmd sur au moins 1000. En outre, la valeur de nmd doit être assez élevée pour s'assurer que suffisamment de numéros existent pour chaque nom d'ID de périphérique. Le nombre doit aussi être suffisamment élevé pour assurer que chaque nom de volume local peut être unique dans le cluster.
  
  La valeur maximale autorisée pour un nom de volume par ensemble de disques est 8192. La valeur par défaut de nmd est 128.
Définissez ces champs au moment de l'installation en tenant compte des éventuelles extensions futures du cluster. L'augmentation de la capacité de ces champs, après la production du cluster, prend du temps. La modification de cette valeur nécessite une reconfiguration au démarrage pour chaque nœud. Si vous reportez cette opération, cela augmente également la probabilité d'erreurs d'allocation d'espace dans le système de fichiers racine (/) pour créer tous les périphériques nécessaires.

Parallèlement, définissez la valeur des champs nmd et md_nsets sur la valeur la plus basse possible. Les structures de mémoire existent pour tous les périphériques possibles conformément aux commandes nmd et md_nsets, même si vous n'avez pas créé ces périphériques. Pour des performances optimales, configurez la valeur de nmd et md_nsets de sorte qu'elle soit légèrement supérieure au nombre de volumes que vous pensez utiliser.

Reportez-vous à Fichiers système et de démarrage dans le Manuel d'administration du gestionnaire de volumes Solaris (Solaris 9 ou dans Solaris 10) pour plus d'informations sur le fichier md.conf.

Recommandations relatives au logiciel VERITAS Volume Manager

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

Accessibilité aux nœuds : vous devez configurer tous les groupes de disques du gestionnaire de volumes en tant que groupes de périphériques Sun Cluster ou groupes de disques locaux uniquement. Si vous ne configurez pas le groupe de disques de l'une de ces manières, les périphériques qu'il contient ne seront accessibles à aucun nœud du cluster.
- Un groupe de périphériques permet à des disques multihôtes d'être hébergés par un nœud secondaire en cas de panne du nœud principal.
- Un groupe de disques locaux uniquement n'est pas contrôlé par Sun Cluster et n'est accessible qu'à partir d'un nœud à la fois.
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 (Enclosure-Based Naming), veillez à préserver la cohérence des noms sur tous les nœuds du cluster 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 nœuds. Des noms incompatibles n'ont pas d'incidence sur le comportement correct du cluster. Cependant, ils compliquent considérablement l'administration du cluster et augmentent grandement le risque d'erreurs de configuration, pouvant éventuellement engendrer des pertes de données.
Groupe de disques root – La création d'un groupe de disques root est facultative.

Un groupe de disques racine peut être créé sur les disques suivants :
- le disque racine, devant être encapsulé ;
- un ou plusieurs disques locaux non racine, pouvant être encapsulés ou initialisés ;
- une combinaison de disques racine et de disques locaux non racine.
Le groupe de disques racine doit être local sur le nœud.
groupes de disques root simples – Les groupes de disques root simples, qui sont créés sur une tranche unique du disque root, ne sont pas pris en charge par VxVM sur le logiciel Sun Cluster, en tant que types de disques. Il s'agit d'une restriction générale du logiciel VxVM.
Encapsulation : les disques à encapsuler doivent disposer de deux entrées libres de table de tranches.
Nombre de volumes : lors de la création d'un groupe de périphériques, estimez le nombre maximal de volumes qu'il utilisera.
- 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 de périphériques. Il est impossible d'affecter des codes mineurs se chevauchant à deux groupes de périphériques.
Dirty Region Logging – L'utilisation de Dirty Region Logging (DRL) réduit le temps de récupération des volumes apès la défaillance d'un nœud. Il peut cependant réduire le débit d'E/S.
Multiacheminement dynamique : l'utilisation de cette seule fonction pour gérer plusieurs chemins d'E/S par nœud vers l'espace de stockage partagé n'est pas prise en charge. Seules les configurations suivantes prennent en charge l'utilisation de DMP :
- chemin d'E/S unique par noeud vers le stockage partagé du cluster ;
- solution de multi-acheminement prise en charge, telle que Sun Traffic Manager, EMC PowerPath ou Hiatchi HDLM et gérant plusieurs chemins d'E/S par noeud vers le stockage partagé du cluster.

Pour obtenir plus d'informations, reportez-vous à la documentation d'installation de VxVM.

Journalisation de système de fichiers

La journalisation est requise pour les systèmes de fichiers de cluster VxFS et UFS. Le logiciel Sun Cluster prend en charge les choix suivants en matière de journalisation de système de fichiers :

Journalisation UFS Solaris – Reportez-vous à la page de manuel mount_ufs(1M) pour plus d'informations.
SPARC : journalisation VERITAS File System (VxFS) (VxFS). Pour obtenir plus d'informations, reportez-vous à la page de manuel relative à mount_vxfs fournie avec VxFS.

Solaris Volume Manager et VERITAS Volume Manager prennent en charge les deux types de journalisation des systèmes de fichiers.

Recommandations relatives à la mise en miroir

Cette rubrique donne les recommandations suivantes sur la planification de la mise en miroir de la configuration de votre cluster :

Recommandations relatives à la mise en miroir des disques multihôtes

La mise en miroir de tous les disques multihôtes dans une configuration Sun Cluster permet de tolérer des pannes générées au niveau d'un seul périphérique. Sun Cluster requiert la mise en miroir de tous les disques multihôtes sur les différentes unités d'extension. Vous n'êtes pas tenu de procéder à une mise en miroir logicielle si le périphérique de stockage dispose de matériel RAID ainsi que de chemins d'accès aux périphériques redondants.

Lors de la mise en miroir de disques multihôtes, tenez compte des points suivants.

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 multihôte différente.
Espace disque : la mise en miroir double l'espace disque nécessaire.
Mise en miroir à trois voies : les logiciels Solaris 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.
Tailles de périphériques différentes – Si vous effectuez une mise en miroir vers un périphérique de taille différente, la capacité de mise en miroir se limite à la taille du plus petit sous-miroir ou plex.

Pour plus d'informations sur les disques multihôtes, reportez-vous à Multihost Disk Storage du Sun Cluster Overview for Solaris OS et à Sun Cluster Concepts Guide for Solaris OS.

Recommandations relatives à la mise en miroir du disque racine

Ajoutez ces informations de planification à la Fiche de travail de configuration des systèmes de fichiers locaux.

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 racine et dupliquez les sous-disques générés. Le logiciel Sun Cluster n'impose pas de mise en miroir du disque racine.

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

Pour connaître les procédures de mise en miroir du disque racine, reportez-vous à la documentation sur le gestionnaire de volumes et à la rubrique Configuration du logiciel Solaris Volume Manager ou Installation et configuration du logiciel VxVM .

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

Disque d'initialisation : vous pouvez paramétrer le miroir afin qu'il devienne un disque root d'amorçage. Vous pourrez alors démarrer à partir du miroir en cas d'échec du disque d'amorçage principal.
Complexité : la mise en miroir du disque root complique l'administration du système, ainsi que l'initialisation en mode monoutilisateur.
Sauvegardes : qu'il soit ou non mis en miroir, le disque racine 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 de disque configuré en tant que périphérique de quorum pour mettre un disque racine en miroir.
Quorum : sous le logiciel Solaris Volume Manager, 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 Solaris Volume Manager pour de plus amples informations sur la base de données d'état et ses répliques.
Contrôleurs distincts : pour une disponibilité maximale, le disque racine doit être mis en miroir sur un contrôleur distinct.
Disque racine secondaire : avec un disque racine mis en miroir, vous pouvez continuer à travailler à partir du disque racine secondaire (miroir) en cas de panne du disque racine principal. Plus tard, le disque root principal pourra être remis en service, par exemple, après une mise sous tension ou des erreurs E/S transitoires. Les initialisations ultérieures sont alors effectuées à l'aide du disque root principal, spécifié pour le paramètre eeprom(1M) boot-device. 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. Avec Solaris Volume Manager une resynchronisation a lieu. 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 (miroir) secondaire, elles ne seront pas reflétées sur le disque root principal lors de l'initialisation. Cela entraînerait un sous-miroir périmé. Par exemple, les éventuelles modifications apportées au fichier /etc/system sont perdues. Avec le logiciel Solaris Volume Manager, certaines commandes administratives peuvent avoir modifié le fichier /etc/system, pendant que le disque root principal était hors service.

Le programme d'initialisation ne vérifie pas si le système initialise à partir d'un miroir ou à partir d'un périphérique physique sous-jacent. La mise en miroir devient active à travers le processus d'initialisation, une fois que les volumes sont chargés. Avant ce point, le système est vulnérable face aux problèmes d'obsolescence des sous-miroirs.

Chapitre 1 Planification de la configuration Sun Cluster

Tâches d'installation de Sun Cluster

Planification du SE Solaris

Choix de la méthode d'installation de Solaris

Restrictions d'utilisation des fonctions du système d'exploitation Solaris

À propos des groupes de logiciels Solaris

Partitions du disque système

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

Recommandations relatives au système de fichiers /globaldevices

Exigences du gestionnaire de volumes

Exemples d'allocation de système de fichiers

Procédures relatives aux zones non globales d'un cluster

Planification de l'environnement Sun Cluster

Octroi de licence

Patchs logiciels

Adresses IP réseau public

Périphériques d'accès par console

Adresses logiques

Réseaux publics

Serveurs de quorum

Recommandations NFS

Restrictions de service

Composants configurables de Sun Cluster

Nom du cluster

Noms des noeuds

Noms des zones

Réseau privé

Noms d'hôtes privés

Interconnexion de cluster

Adaptateurs de transport

Commutateurs de transport

Périphériques de quorum

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

Périphériques globaux

Groupes de périphériques

Systèmes de fichiers Cluster

Sélection d'options de montage pour des systèmes de fichiers de cluster

Systèmes de fichiers de cluster UFS

Systèmes de fichiers de cluster VxFS

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

Planification de la gestion des volumes

Recommandations relatives au logiciel de gestion des volumes

Recommandations relatives au logiciel Solaris Volume Manager

Recommandations relatives au logiciel VERITAS Volume Manager

Journalisation de système de fichiers

Recommandations relatives à la mise en miroir

Recommandations relatives à la mise en miroir des disques multihôtes

Recommandations relatives à la mise en miroir du disque racine

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

Recommandations relatives au système de fichiers `/globaldevices`