Guide d'installation du logiciel Sun Cluster 3.1

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

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 relatives à l'installation de Sun Cluster


Tâche	Pour les instructions, voir …
Installation matérielle de la grappe	Sun Cluster 3.1 Hardware Administration Manual Documentation fournie avec votre serveur et vos périphériques de stockage
Planification de l'installation du logiciel de grappe	Ce chapitre “Sun Cluster Installation and Configuration Worksheets” dans les Sun Cluster 3.1 Release Notes
Installation d'une nouvelle grappe ou ajout de noeuds à une grappe existante:Installation de l'environnement d'exploitation Solaris, du logiciel Cluster Control Panel (facultatif), de SunPlex Manager (facultatif), de la structure de la grappe et des modules logiciels de services de données.	Installation du logiciel
Installation et configuration du logiciel Solstice DiskSuite/Solaris Volume Manager.	Installation et configuration du logiciel Solstice DiskSuite/Solaris Volume Manager Documentation Solstice DiskSuite/Solaris Volume Manager
Installation et configuration du logiciel VERITAS Volume Manager (VxVM).	Installation et configuration du logiciel VxVM Documentation VxVM
Configuration de la structure de la grappe et, en option, installation et configuration de Sun Management Center.	Configuration de la grappe
Planification, installation et configuration des services de données et des groupes de ressources	Sun Cluster 3.1 Data Services Installation and Configuration Guide “Data Service Configuration Worksheets and Examples” dans les Sun Cluster 3.1 Release Notes
Développement de services de données personnalisés	Sun Cluster 3.1 Data Services Developer's Guide
Mise à niveau de Sun Cluster 3.0 vers Sun Cluster 3.1 (environnement d'exploitation Solaris, structure de la grappe, services de données et gestionnaire de volumes).	Mise à niveau de Sun Cluster 3.0 à Sun Cluster 3.1 Installation et configuration du logiciel Solstice DiskSuite/Solaris Volume Manager ou Installation et configuration du logiciel VxVM Documentation du gestionnaire de volumes

Planification de l'environnement d'exploitation Solaris

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

Choix de la méthode d'installation de Solaris

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

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

A propos des groupes de logiciels Solaris

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

Reportez-vous à la documentation de votre serveur pour connaître la configuration minimale requise par Solaris. Par exemple, les serveurs Sun Enterprise 10000 requièrent les groupes de logiciels Entire Distribution et OEM.
Si vous installez l'environnement d'exploitation Solaris 8 10/01 et prévoyez d'utiliser des adaptateurs SCI-PCI ou l'interface Remote Shared Memory Application Programming Interface (RSMAPI), vérifiez que vous avez installé les modules logiciels RSMAPI (SUNWrsm, SUNWrsmx, SUNWrsmo et SUNWrsmox). Ces modules sont compris dans le groupe de logiciels Solaris Developer System Support ou version supérieure. Si vous installez le groupe de logiciels End User System Support, utilisez la commande pkgadd(1M) pour installer ces modules RSMAPI avant le logiciel Sun Cluster. Reportez-vous aux pages de manuel relatives à Solaris 8 10/01 (3RSM) pour de plus amples informations sur l'utilisation de RSMAPI.
Vous devrez peut-être installer des modules Solaris autres que ceux du groupe de logiciels End User System Support, par exemple les modules du serveur HTTP Apache. Les logiciels d'autres éditeurs, par exemple ORACLE®, peuvent aussi nécessiter des modules Solaris supplémentaires. Reportez-vous à la documentation du fournisseur tiers pour connaître la configuration logicielle nécessaire de Solaris.

Partitions du disque système

Ajoutez ces informations dans la rubrique “Local File Systems With Mirrored Root Worksheet” figurant dans les Sun Cluster 3.1 Release Notes ou dans la rubrique “Local File Systems with Non-Mirrored Root Worksheet” figurant dans les Sun Cluster 3.1 Release Notes.

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

Swap : allouez au moins 750 Mo d'espace swap total à Solaris et au logiciel Sun Cluster. Pour de meilleurs résultats, ajoutez au moins 512 Mo pour le logiciel Sun Cluster à l'espace requis par l'environnement d'exploitation Solaris. En outre, vous devez allouer tout espace supplémentaire requis par les applications qui seront exécutées sur le noeud de la grappe.
/globaldevices : créez un système de fichiers de 512 Mo qui sera utilisé par l'utilitaire scinstall(1M) pour les périphériques globaux.
Gestionnaire de volumes : créez une partition de 20 Mo pour le gestionnaire de volumes sur une tranche située à la fin du disque (tranche 7). Si votre grappe utilise VERITAS Volume Manager (VxVM;) et que vous prévoyez d'encapsuler le disque 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 de l'environnement d'exploitation Solaris.

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

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

Comme pour tout système exécutant l'environnement d'exploitation Solaris, vous pouvez configurer les répertoires racine (/), /var, /usr et /opt en tant que systèmes de fichiers distincts ou les inclure 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.

root (/) : le logiciel Sun Cluster lui-même occupe moins de 40 Mo dans le système de fichiers racine (/). Le logiciel Solstice DiskSuite/Solaris Volume Manager requiert moins de 5 Mo et le logiciel VxVM moins de 15 Mo. Pour de meilleurs résultats, vous devez configurer un espace et une capacité d'inode supplémentaires conséquents pour la création des périphériques spéciaux en mode bloc ou caractère utilisés par le logiciel Solstice DiskSuite/Solaris Volume Manager ou VxVM, particulièrement si la grappe comporte un grand nombre de disques partagés. Par conséquent, ajoutez au moins 100 Mo à l'espace que vous alloueriez normalement à votre système de fichiers racine (/).
/var : le logiciel Sun Cluster occupe un espace négligeable dans le système de fichiers /var au moment de l'installation. Cependant, vous devez réserver un espace important pour les fichiers journaux. Notez également que le nombre de messages consignés sur un noeud de grappe peut être plus important que sur un serveur autonome typique. Allouez donc au moins 100 Mo au système de fichiers /var.
/usr : le logiciel Sun Cluster occupe moins de 25 Mo dans le système de fichiers /usr. Les logiciels Solstice DiskSuite/Solaris Volume Manager et VxVM requièrent chacun moins de 15 Mo.
/opt : la structure logicielle de Sun Cluster occupe moins de 2 Mo dans le système de fichiers /opt. Toutefois, chaque service de données de Sun Cluster peut utiliser entre 1 et 5 Mo. Le logiciel Solstice DiskSuite/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 modules et outils. En outre, la plupart des logiciels de bases de données et d'applications sont installés dans le système de fichiers /opt. Si vous utilisez le logiciel Sun Management Center pour surveiller la grappe, vous avez besoin de 25 Mo supplémentaires sur chaque noeud pour la prise en charge de l'agent Sun Management Center et des modules Sun Cluster.

Recommandations relatives à la partition de swap

La zone de swap totale allouée à Solaris et au logiciel Sun Cluster ne doit pas être inférieure à 750 Mo. Pour de meilleurs résultats, ajoutez au moins 512 Mo pour le logiciel Sun Cluster à l'espace requis par l'environnement d'exploitation Solaris. En outre, les applications de fournisseurs tiers que vous pourriez installer sur le noeud peuvent également avoir des exigences en matière de zone de swap. Le cas échéant, reportez-vous à la documentation de ces applications pour déterminer la configuration de swap nécessaire.

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

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

Exigences du gestionnaire de volumes

Si vous utilisez le logiciel Solstice DiskSuite/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 noeud 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 Solstice DiskSuite/Solaris Volume Manager fonctionne correctement. Pour de plus amples informations, reportez-vous à la documentation de Solstice DiskSuite/Solaris Volume Manager

Si vous utilisez VxVM et que vous envisagez d'encapsuler le disque racine, vous devez disposer de deux tranches inutilisées pour VxVM, ainsi que d'un espace libre et non affecté supplémentaire au début ou à la fin du disque. Pour de plus amples informations sur l'encapsulage du disque 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 noeud de grappe disposant de moins de 750 Mo de mémoire physique. Y seront installés le groupe de logiciels End User System Support de l'environnement d'exploitation Solaris, le logiciel Sun Cluster et le service de données Sun Cluster HA for NFS. La dernière tranche du disque, la tranche 7, se voit allouer une petite quantité d'espace destinée au gestionnaire de volumes.

Cette disposition permet d'utiliser le logiciel Solstice DiskSuite/Solaris Volume Manager ou VxVM. Si vous utilisez le logiciel Solstice DiskSuite/Solaris Volume Manager, vous pouvez réserver la tranche 7 pour la réplique de la 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	Contenu	Allocation (en Mo)	Description
0	`/`	6,75 Go	Espace libre restant sur le disque après l'allocation d'espace aux tranches 1 à 7. Utilisé pour l'environnement d'exploitation Solaris, le logiciel Sun Cluster, le logiciel de services de données, le gestionnaire de volumes, les modules agent Sun Management Center et Sun Cluster, les systèmes de fichiers racine et les logiciels de bases de données et d'applications.
1	swap	1 Go	512 Mo pour l'environnement 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 grappe.
4	inutilisée	-	Tranche libre disponible pour l'encapsulage du disque racine sous VxVM.
5	inutilisée	-	-
6	inutilisée	-	-
7	gestionnaire de volumes	20 Mo	Utilisé par le logiciel Solstice DiskSuite/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.

Planification de l'environnement Sun Cluster

Cette rubrique explique comment planifier et préparer l'installation du logiciel Sun Cluster. Pour de plus amples informations sur les composants de Sun Cluster, reportez-vous au Sun Cluster 3.1 Concepts Guide.

Gestion des licences

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.

Correctifs logiciels

Après avoir installé chacun des logiciels, vous devez également installer les correctifs éventuellement requis. Pour de plus amples informations sur les correctifs éventuellement requis, reportez-vous à la rubrique “Patches and Required Firmware Levels”dans les Sun Cluster 3.1 Release Notes ou consultez votre prestataire de services Sun. Reportez-vous à la rubrique “Correctifs pour logiciel et microprogramme Sun Cluster” du Guide d'administration système de Sun Cluster 3.1 pour obtenir les instructions et les procédures à suivre dans le cadre de l'application des correctifs.

Adresses IP

Vous devez définir un certain nombre d'adresses IP pour divers composants de Sun Cluster en fonction de la configuration de votre grappe. Chaque noeud de votre configuration de grappe doit avoir au moins une connexion de réseau public vers le même ensemble de sous-réseaux publics.

Le tableau suivant répertorie les composants nécessitant l'affectation d'une adresse IP. Ajoutez ces adresses IP à tous les services d'attribution de noms utilisés. Ajoutez-les également au fichier local /etc/inet/hosts sur chaque noeud de la grappe après avoir installé le logiciel Solaris.

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


Composant	Adresses IP nécessaires
console administrative	1 par sous-réseau
adaptateurs réseau	2 par adaptateur (1 adresse IP principale et 1 adresse IP de test)
Noeuds de grappe	1 par noeud et par sous-réseau
interface réseau de la console de domaines (Sun Fire 15000)	1 par domaine
dispositif d'accès par console	1
Adresses logiques	1 par ressource d'hôte logique et par sous-réseau

Dispositifs d'accès par console

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

Adresses logiques

Chaque groupe de ressources de service de données qui utilise une adresse logique doit avoir un nom d'hôte spécifié pour chaque réseau public à partir duquel l'adresse logique est accessible. Reportez-vous au Sun Cluster 3.1 Data Services Installation and Configuration Guide pour de plus amples informations et à la rubrique “Data Service Configuration Worksheets and Examples” dans les Sun Cluster 3.1 Release Notes pour consulter les fiches de planification des groupes de ressources. Pour de plus amples informations sur les ressources et les services de données, reportez-vous également au Sun Cluster 3.1 Concepts Guide.

Composants configurables de Sun Cluster

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

Nom de la grappe

Ajoutez ces informations de planification à la “Cluster and Node Names Worksheet” dans les Sun Cluster 3.1 Release Notes.

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

Noms des noeuds

Ajoutez ces informations de planification à la “Cluster and Node Names Worksheet” dans les Sun Cluster 3.1 Release Notes. Les informations de la plupart des autres fiches de travail sont groupées par nom de noeud.

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

Réseau privé

Ajoutez ces informations de planification à la “Cluster and Node Names Worksheet” dans les Sun Cluster 3.1 Release Notes.

Le logiciel Sun Cluster utilise le réseau privé pour les communications internes entre les noeuds. Sun Cluster nécessite au moins deux connexions pour procéder à l'interconnexion de la grappe sur le réseau privé. Vous indiquez l'adresse de réseau privé et le masque de réseau lorsque vous installez le logiciel Sun Cluster sur le premier noeud de la grappe. Vous pouvez accepter l'adresse de réseau privé (172.16.0.0) et le masque de réseau (255.255.0.0) par défaut ou en saisir d'autres si cette adresse est déjà utilisée dans l'entreprise.

Remarque :

après avoir installé le noeud en tant que membre de la grappe, vous ne pouvez plus modifier l'adresse de réseau privé et le masque de réseau.

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

Les deux derniers octets de l'adresse doivent être nuls.
L'adresse doit respecter les instructions de la RFC 1597 pour l'affectation des adresses réseau.

Reportez-vous à la rubrique “Planning Your TCP/IP Network” du System Administration Guide, Volume 3 (Solaris 8) ou “Planning Your TCP/IP Network (Task)” du System Administration Guide: IP Services (Solaris 9) pour connaître la procédure d'obtention de copies des RFC.

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

Masquer au moins tous les bits fournis dans l'adresse de réseau privé
Ne comporter aucun “espace vierge”

Noms d'hôtes privés

Ajoutez ces informations de planification à la rubrique “Cluster and Node Names Worksheet” dans les Sun Cluster 3.1 Release Notes.

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

Interconnexion de grappe

Ajoutez ces informations de planification à la “ Cluster Interconnect Worksheet” dans les Sun Cluster 3.1 Release Notes.

Les interconnexions de grappe fournissent les voies matérielles pour la communication en réseau privé entre les noeuds de la grappe. Chaque interconnexion se compose d'un câble placé entre deux adaptateurs de transport, entre un adaptateur de transport et une jonction de transport, ou entre deux jonctions de transport. Lors de l'installation de Sun Cluster, vous indiquez les informations de configuration suivantes pour deux interconnexions de grappes.

Adaptateurs de transport : pour les adaptateurs de transport comme les ports ou les interfaces réseau, indiquez le nom des adaptateurs de transport, ainsi que le type de transport. Si votre configuration est une grappe à deux noeuds, vous devez également indiquer si votre interconnexion est connectée directement (adaptateur à adaptateur) ou utilise une jonction de transport. Si votre grappe à deux noeuds utilise une connexion directe, vous pouvez toujours spécifier une jonction de transport pour l'interconnexion. Si vous le faites, il sera plus facile d'ajouter un autre noeud à la grappe à l'avenir.
Jonctions de transport : si vous utilisez des jonctions de transport, par exemple un commutateur réseau, indiquez leur nom pour chaque interconnexion. Vous pouvez utiliser le nom par défaut switchN, où N est un numéro affecté automatiquement à l'installation, ou créer d'autres noms.

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

Remarque :

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

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

Pour de plus amples informations sur l'interconnexion de grappe, reportez-vous au Sun Cluster 3.1 Concepts Guide.

Réseaux publics

Ajoutez ces informations de planification à la rubrique “Public Networks Worksheet” dans les Sun Cluster 3.1 Release Notes.

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

Les réseaux publics et privés (interconnexion de grappe) doivent utiliser des adaptateurs distincts.
Vous devez avoir au moins un réseau public connecté à tous les noeuds de grappe.
Vous pouvez avoir autant de connexions supplémentaires au réseau public que votre configuration matérielle le permet.
La variable local-mac-address?doit utiliser la valeur true par défaut pour les adaptateurs Ethernet. Le logiciel Sun Cluster 3.1 ne prend pas en charge la variable local-mac-address? définie sur false pour les adaptateurs Ethernet. Cette exigence est une modification apportée par rapport à Sun Cluster 3.0, qui nécessitait que la variable local-mac-address? soit définie sur false.

Reportez-vous également à la rubrique Groupes multi-acheminement sur réseau IP pour de plus amples informations sur la planification de groupes d'adaptateurs de réseau public de secours. Pour de plus amples informations sur les interfaces de réseau public, reportez-vous au Sun Cluster 3.1 Concepts Guide.

Groupes de périphériques de disques

Ajoutez ces informations de planification à la “Disk Device Groups Worksheet” dans les Sun Cluster 3.1 Release Notes.

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

Reprise sur panne : vous pouvez configurer des disques multiports et des périphériques du gestionnaire de volumes configurés correctement en tant que périphériques de reprise sur panne. La configuration d'un périphérique du gestionnaire de volumes est correcte lorsqu'elle inclut des disques multiports et un réglage correct du gestionnaire de volumes lui-même de manière à ce que le périphérique exporté puisse être hébergé par plusieurs noeuds. Il est impossible de configurer des lecteurs de bandes, des CD ou des disques à un seul port comme des périphériques de reprise sur panne.
Mise en miroir : vous devez mettre les disques en miroir pour protéger les données en cas de panne de disque. Pour de plus amples informations sur la mise en miroir, reportez-vous aux rubriques Recommandations relatives à la mise en miroir, Installation et configuration du logiciel Solstice DiskSuite/Solaris Volume Manager et Installation et configuration du logiciel VxVM, ainsi qu'à la documentation de votre gestionnaire de volumes.

Pour de plus amples informations sur les groupes de périphériques de disques, reportez-vous au Sun Cluster 3.1 Concepts Guide.

Groupes multi-acheminement sur réseau IP

Ajoutez ces informations de planification à la “Public Networks Worksheet” dans les Sun Cluster 3.1 Release Notes.

Les groupes multi-acheminement sur réseau IP , qui remplacent les groupes NAFO (reprise sur panne de l'adaptateur réseau), assurent le contrôle et le basculement des adaptateurs de réseau public et constituent la base des ressources d'adresse réseau. Si un groupe IPMP est configuré avec deux ou plusieurs adapteurs et que l'un d'entre eux tombe en panne, toutes les adresses de l'adaptateur en panne sont basculées vers un autre adaptateur du groupe IPMP. De cette façon, les adaptateurs du groupe IPMP préservent la connectivité du réseau public au sous-réseau auquel les adaptateurs du groupe IPMP sont connectés.

Tenez compte des points suivants lorsque vous planifiez vos groupes IPMP .

Chaque adaptateur de réseau public doit appartenir à un groupe Multipathing.
La variable local-mac-address?doit être définie sur la valeur true pour les adaptateurs Ethernet. Il s'agit d'une modification de l'exigence du logiciel Sun Cluster 3.0.
Vous devez configurer une adresse IP de test par adaptateur de groupe Multipathing.
Les adresses IP de test de tous les adaptateurs d'un même groupe Multipathing doivent appartenir au même sous-réseau IP.
Les adresses IP de test ne doivent pas être utilisées par des applications normales, car elles ne sont pas hautement disponibles.
Aucune exigence ni aucune restriction ne s'applique au nom des groupes Multipathing.

Pour de plus amples informations sur le IPMP, reportez-vous à la rubrique “Deploying Network Multipathing” du IP Network Multipathing Administration Guide ou à celle intitulée “Administering Network Multipathing (Task)” dans le System Administration Guide: IP Services.

Périphériques de quorum

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

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

Minimum : une grappe à deux noeuds doit avoir au moins un disque partagé affecté en tant que périphérique de quorum. Pour les autres topologies, les périphériques de quorum sont facultatifs.
Règle du nombre impair : si vous configurez plus d'un périphérique de quorum dans une grappe à deux noeuds ou dans une paire de noeuds connectée directement au périphérique de quorum, configurez un nombre impair de périphériques de quorum ayant chacun des chemins de panne complètement indépendants.
Connexion : ne connectez jamais un périphérique de quorum à plus de deux noeuds.

Pour de plus amples informations sur le quorum, reportez-vous au Sun Cluster 3.1 Concepts Guide.

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

Cette rubrique explique comment planifier les périphériques globaux et les systèmes de fichiers de grappe. Pour de plus amples informations sur les périphériques globaux et les systèmes de fichiers de grappe, reportez-vous au Sun Cluster 3.1 Concepts Guide.

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

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

Mise en miroir : vous devez mettre en miroir tous les périphériques globaux du périphérique global à haute disponibilité. Vous n'êtes pas tenu de procéder à une mise en miroir logicielle si le périphérique de stockage dispose de RAID matériel ainsi que de chemins redondants d'accès aux disques.
Disques : lorsque vous procédez à une mise en miroir, organisez les systèmes de fichiers de manière à obtenir une mise en miroir qui respecte les grappes de disques.
Disponibilité : vous devez connecter physiquement un périphérique global à plus d'un noeud de la grappe pour que ledit périphérique global soit considéré à haute disponibilité. Un périphérique global à plusieurs connexions physiques peut tolérer la défaillance d'un noeud unique. Vous pouvez configurer un périphérique global avec une seule connexion physique, mais il sera inaccessible depuis les autres noeuds en cas de panne du noeud avec la connexion.

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

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

Emplacement des points de montage : créez des points de montage dans le répertoire /global, à moins que cela ne soit pas permis par d'autres logiciels. Ce répertoire vous permet de distinguer facilement les systèmes de fichiers de la grappe, disponibles globalement, des systèmes de fichiers locaux.
Conditions de montage de VxFS : en règle générale, un système de fichiers VxFS se monte et se démonte à partir du noeud principal (c'est- à- dire du noeud qui gère le disque sur lequel le système de fichiers VxFS réside) pour garantir la réussite de l'opération. Tout montage ou démontage d'un système de fichiers VxFS à partir d'un noeud secondaire risque d'échouer.
Points de montage imbriqués : normalement, vous ne devez pas imbriquer les points de montage des systèmes de fichiers de grappe. Par exemple, ne définissez pas un système de fichiers monté sur /global/a et un autre système de fichiers monté sur /global/a/b. Si vous ne respectez pas cette règle, vous risquez des problèmes de disponibilité ainsi que de séquence d'amorçage des noeuds, si le point de montage parent est absent lorsque le système tente de monter un enfant de ce système de fichiers. La seule exception à cette règle est lorsque les périphériques des deux systèmes de fichiers ont la même connectivité au noeud physique (différentes tranches sur le même disque, par exemple).

Planification de la gestion des volumes

Ajoutez ces informations de planification à la “Disk Device Groups Worksheet” dans les Sun Cluster 3.1 Release Notes et à la “Volume Manager Configurations Worksheet” dans les Sun Cluster 3.1 Release Notes. Pour Solstice DiskSuite/Solaris Volume Manager, ajoutez également ces informations à la “Metadevices Worksheet (Solstice DiskSuite/Solaris Volume Manager)” dans les Sun Cluster 3.1 Release Notes.

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

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

Si vous utilisez le logiciel Solstice DiskSuite/Solaris Volume Manager, vous devez l'installer sur tous les noeuds de la grappe, que vous utilisiez ou non VxVM sur certains noeuds pour gérer les disques.
Si vous utilisez VxVM et activez la fonction de grappe de VxVM, vous devez installer VxVM sous licence sur tous les noeuds de la grappe.
Si vous utilisez VxVM et que vous n'activez pas la fonction de grappe de VxVM, il vous suffit d'installer VxVM et de l'utiliser sous licence sur les noeuds reliés aux périphériques de stockage gérés par VxVM.
Si vous installez le logiciel Solstice DiskSuite/Solaris Volume Manager ainsi que VxVM sur un noeud, vous devez utiliser le logiciel Solstice DiskSuite/Solaris Volume Manager pour gérer les disques locaux de chaque noeud (comme le disque racine), ainsi que VxVM pour gérer tous les disques partagés.

Reportez-vous à la documentation du gestionnaire de volumes ainsi qu'aux rubriques Installation et configuration du logiciel Solstice DiskSuite/Solaris Volume Manager ou Installation et configuration du logiciel VxVM pour de plus amples informations sur l'installation et la configuration du logiciel de gestion des volumes. Pour de plus amples informations sur la gestion des volumes dans une configuration de grappe, reportez-vous au Sun Cluster 3.1 Concepts Guide.

Recommandations relatives au logiciel de gestion des volumes

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

Disques multihôtes mis en miroir : vous devez mettre tous les disques multihôtes en miroir sur des périphériques d'extension de disques. Reportez-vous à la rubrique Mise en miroir des disques multihôtes pour de plus amples informations sur la mise en miroir des disques multihôtes. Vous n'êtes pas tenu de procéder à une mise en miroir logicielle si le périphérique de stockage dispose de RAID matériel ainsi que de chemins redondants d'accès aux disques.
Racine mise en miroir : la mise en miroir du disque racine améliore la disponibilité, mais elle n'est pas obligatoire. Reportez-vous à la rubrique Recommandations relatives à la mise en miroir pour de plus amples informations sur la mise en miroir du disque racine.
Attribution d'un nom unique : si un métapériphérique Solstice DiskSuite local ou un volume Solaris Volume Manager ou VxVM local est utilisé comme le périphérique sur lequel le système de fichiers /global/.devices/node@nodeid est monté, le nom de ce métapériphérique ou volume doit être unique sur l'ensemble de la grappe.
Listes des noeuds : pour être à haute disponibilité, un groupe de périphériques de disques doit comporter 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 de périphériques de disques associé, la liste des noeuds du groupe de ressources évolutif doit être un surensemble de la liste des noeuds du groupe de périphériques de disques. Reportez-vous aux données de planification du groupe de ressources dans le Sun Cluster 3.1 Data Services Installation and Configuration Guide pour de plus amples informations sur les listes des noeuds.
Disques multiports : vous devez connecter ou relier par un port tous les disques utilisés pour monter un groupe de périphériques au sein de la grappe à tous les noeuds configurés dans la liste des noeuds de ce groupe de périphériques. Le logiciel Solstice DiskSuite/Solaris Volume Manager est capable de procéder automatiquement à cette vérification au moment où ces disques sont ajoutés à un ensemble de disques. Cependant, les groupes de disques VxVM configurés ne sont associés à aucun ensemble de noeuds particulier.
Disques de partition dynamique : vous pouvez utiliser des disques de partition dynamique pour accroître la disponibilité, mais ils ne sont pas nécessaires.

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

Recommandations relatives au logiciel Solstice DiskSuite/Solaris Volume Manager

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

Nom de métapériphériques ou de volumes locaux : le nom de chaque métapériphérique Solstice DiskSuite ou de volume Solaris Volume Manager local doit être unique au sein de la grappe et ne peut être identique à aucun identificateur de périphérique (DID).
Médiateurs : chaque ensemble de disques configuré avec exactement deux chaînes de disque et géré par exactement deux noeuds doit comporter des médiateurs Solstice DiskSuite/Solaris Volume Manager. 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 adaptateurs d'interface. Vous devez configurer chaque ensemble de disques avec exactement deux noeuds en tant qu'hôte médiateur. Vous devez utiliser les deux mêmes noeuds pour tous les ensembles de disques nécessitant des médiateurs, et ces deux noeuds doivent être les maîtres de ces ensembles de disques. Vous ne pouvez pas configurer de médiateurs pour les ensembles de disques qui ne répondent pas à ces critères (deux chaînes et deux hôtes). Reportez-vous à la page de manuel mediator( 7D) pour de plus amples informations.
Paramètres /kernel/drv/md.conf : tous les métapériphériques Solstice DiskSuite ou les volumes Solaris Volume Manager utilisés par chaque ensemble de disques sont créés à l'avance, au moment de l'initialisation de la reconfiguration, suivant les paramètres de configuration figurant dans le fichier /kernel/drv/md.conf.

Vous devez modifier les champs nmd et md_nsets comme suit pour prendre en charge une configuration Sun Cluster :
- md_nsets : le champ md_nsets définit le nombre total d'ensembles de disques pouvant être créés pour qu'un système réponde aux besoins de la grappe. Vous devez définir la valeur de md_nsets en fonction du nombre prévu d'ensembles de disques de la grappe, plus un pour permettre au logiciel Solstice DiskSuite/Solaris Volume Manager de gérer les disques privés sur l'hôte local (c'est-à-dire les métapériphériques ou les volumes ne faisant pas partie de l'ensemble de disques local).
  
  Le nombre maximum d'ensembles de disques autorisé par grappe est de 32 : 31 sont dédiés à une utilisation d'ordre général et 1 est dédié à la gestion de disques privée). La valeur par défaut de md_nsets est 4.
- nmd : ce champ définit le nombre de métapériphériques ou de volumes créés par ensemble de disques. Vous devez définir sa valeur sur le nombre maximum prévu de noms de métapériphérique ou de volume utilisés par l'un des ensembles de disques de la grappe. Par exemple, si une grappe utilise 10 métapériphériques ou volumes dans ses 15 premiers ensembles de disques, mais 1000 dans le 16ème, la valeur de nmd que vous définissez doit au moins être égale à 1000. En outre, la valeur de nmd doit être telle qu'il y ait suffisamment de numéros pour que chaque DID et chaque nom de métapériphérique ou de volume local soit unique dans la grappe.
  
  La valeur maximale d'un nom de métapériphérique ou de volume par ensemble de disques est de 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 de la grappe. L'augmentation de ces valeurs lorsque la grappe est en cours de production prend beaucoup de temps, car elle nécessite une réinitialisation de la reconfiguration de 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 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 de md_nsets de sorte qu'elle soit légèrement supérieure au nombre de métapériphériques ou de volumes que vous utiliserez.

Attention :
les fichiers /kernel/drv/md.conf de tous les noeuds de la grappe doivent être identiques, indépendamment du nombre d'ensembles de disques desservis par chaque noeud. Le non respect de cette consigne peut occasionner de graves erreurs de Solstice DiskSuite/Solaris Volume Manager et un risque de pertes de données.

Reportez-vous également à la rubrique “System and Startup Files” du Solstice DiskSuite 4.2.1 Reference Guide ou à la rubrique “System Files and Startup Files”du Solaris Volume Manager Administration Guide pour de plus amples 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).

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 - fonction introduite par VxVM version 3.2), veillez à préserver la cohérence des noms sur tous les noeuds de la grappe qui partagent le même stockage. VxVM ne procède pas à la coordination de ces noms, il incombe donc à l'administrateur de vérifier que VxVM attribue le même nom à tous les périphériques identiques des différents noeuds. Si le non respect de cette consigne n'empêche pas la grappe de fonctionner correctement, il en complique considérablement l'administration et accroît les risques d'erreur de configuration, voire de perte de données.
Groupe de disques racine : vous devez créer un groupe de disques racine par défaut (rootdg) sur chaque noeud. Le groupe de disques rootdg peut être créé sur les disques suivants :
- Le disque racine, qui doit être encapsulé.
- Un ou plusieurs disques locaux non racine, qui peuvent être encapsulés ou initialisés.
- Une combinaison de disques racine et de disques locaux non racine
Le groupe de disques rootdg doit être local sur le noeud.
Encapsulage : les disques à encapsuler doivent posséder deux entrées de table de tranches de disque libres.
Nombre de volumes : lors de la création d'un groupe de périphériques de disques, estimez le nombre maximal de volumes que ce groupe utilisera.
- Si ce nombre de volumes est inférieur à 1000, vous pouvez utiliser les 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 de disques. Il est impossible d'affecter des codes mineurs se chevauchant à deux groupes de périphériques.
Système DRL (Dirty Region Logging) : l'utilisation du système DRL est fortement conseillé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 de système de fichiers

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

Journalisation UFS Solaris : pour de plus amples informations, reportez-vous à la page mount_ufs(1M) du manuel.
Journalisation de trans-métapériphériques Solstice DiskSuite ou Journalisation de volumes de transaction Solaris Volume Manager : reportez-vous à la rubrique “Creating DiskSuite Objects” du Solstice DiskSuite 4.2.1 User's Guide ou à la rubrique “Transactional Volumes (Overview)” du Solaris Volume Manager Administration Guide pour de plus amples informations.
Journalisation VERITAS File System (VxFS) : reportez-vous à la page mount_vxfs du manuel fournie avec le logiciel VxFS pour de plus amples informations.

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

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


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

Tenez compte des points suivants lorsque vous faites votre choix entre Journalisation UFS Solaris et Journalisation de trans-métapériphériques.

Les volumes de transaction devraient être supprimés de l'environnement d'exploitation Solaris dans une version ultérieure de Solaris. La Journalisation UFS Solaris, disponible depuis la version Solaris 8, offre les mêmes fonctions tout en permettant d'obtenir à la fois des performances supérieures et un entête et des exigences en matière d'administration système nettement moindres.
Taille du journal de Solaris UFS : la Journalisation UFS Solaris alloue toujours le journal au moyen de l'espace libre sur le système de fichiers UFS suivant la taille du système de fichiers.
- Sur les systèmes de fichiers de moins de 1 Go, le journal occupe 1 Mo.
- Sur les systèmes de fichiers d'au moins 1 Go ou plus, le journal occupe 1 Mo par Go sur le système de fichiers, la limite maximale étant de 64 Mo.
Métapériphérique de journalisation : un trans-métapériphérique Solstice DiskSuite ou un volume Solaris Volume Manager de transaction gère la journalisation UFS. Le composant de journalisation d'un trans-métapériphérique ou d'un volume de transaction est un métapériphérique ou un volume qui permet la mise en miroir et en bande. La taille maximale du journal est de 1 Go, mais 64 Mo suffisent pour la plupart des systèmes de fichiers. La taille de journal minimale est de 1 Mo.

Recommandations relatives à la mise en miroir

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

Mise en miroir des disques multihôtes

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

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

Périphériques d'extension de disque distincts : chaque sous-miroir d'un miroir ou d'un plex donné doit résider dans un périphérique d'extension de disque multihôte different.
Espace disque : la mise en miroir double l'espace disque nécessaire.
Mise en miroir à trois voies : les logiciels Solstice DiskSuite/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.
Nombre de métapériphériques ou de volumes : sous Solstice DiskSuite/Solaris Volume Manager, les miroirs sont en fait d'autres métapériphériques Solstice DiskSuite ou volumes Solaris Volume Manager tels que des concaténations ou des bandes. Les grandes configurations peuvent comporter un grand nombre de métapériphériques ou de volumes.
Tailles de disques différentes : si vous placez la copie miroir sur un disque d'une taille différente, votre capacité de mise en miroir est limitée à la taille du sous-miroir ou du plex le plus petit.

Pour de plus amples informations sur les disques multihôtes, reportez-vous au Sun Cluster 3.1 Concepts Guide.

Mise en miroir du disque racine

Ajoutez ces informations de planification à la “Local File Systems With Mirrored Root Worksheet” dans les Sun Cluster 3.1 Release Notes.

Pour une disponibilité maximale, mettez en miroir les systèmes de fichiers racine (/), /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.

Reportez-vous à la documentation de votre gestionnaire de volumes, ainsi qu'aux rubriques Installation et configuration du logiciel Solstice DiskSuite/Solaris Volume Manager ou Installation et configuration du logiciel VxVM pour connaître la procédure de mise en miroir du disque racine.

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

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.
Complexité : la duplication du disque racine complique l'administration du système et le démarrage en mode mono-utilisateur.
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 Solstice DiskSuite/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 Solstice DiskSuite/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 (le miroir) en cas de panne du disque racine principal. Plus tard, si le disque racine principal fonctionne de nouveau (peut-être après un redémarrage ou en raison d'une erreur d'E/S temporaire), les initialisations suivantes seront effectuées à partir du disque d'initialisation principal défini dans le champ boot-device de la PROM OpenBoot^TM. Dans ce cas, aucune tâche de réparation manuelle n'a eu lieu, mais le lecteur redémarre à un niveau suffisant pour permettre la réinitialisation. Notez qu'aucune resynchronisation de Solstice DiskSuite/Solaris Volume Manager 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 racine secondaire (miroir), elles ne sont pas reflétées sur le disque racine 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/Solaris Volume Manager peuvent avoir modifié le fichier /etc/system alors que le disque racine principal était hors service.

Le programme d'initialisation ne vérifie pas si le système 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 ou des volumes). Avant ce point, le système est vulnérable face aux problèmes d'obsolescence des sous-miroirs.