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

• Recommandations relatives à la mise en miroir du disque root

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.

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

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

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

• Mise en miroir à trois voies : les logiciels Solstice DiskSuite ou 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 ou 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 effectuez une mise en miroir vers un disque de taille différente, la capacité de mise en miroir se limite à la taille du plus petit sous-miroir ou plex.

Pour de plus amples informations sur les disques multihôtes, reportez-vous aux documents “Multihost Disk Storage” in Sun Cluster Overview for Solaris OS et Sun Cluster Concepts Guide for Solaris OS.

Recommandations relatives à la mise en miroir du disque root

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

Avant de décider de mettre ou non le disque root en miroir, tenez compte des risques, de la complexité, du coût et du temps de maintenance pour les différentes possibilités concernant 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 root, 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 ou Solaris Volume Manager ou SPARC: Installation et configuration du logiciel VxVM pour connaître la procédure de mise en miroir du disque root.

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

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

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

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

• Quorum : sous le logiciel Solstice DiskSuite ou 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 ou 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 root doit être mis en miroir sur un contrôleur distinct.

• Disque root secondaire : avec un disque root mis en miroir, vous pouvez continuer à travailler à partir du disque root secondaire (miroir) en cas de panne du disque root 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é dans le champ 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 Solstice DiskSuite ou 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. Certaines commandes administratives de Solstice DiskSuite ou Solaris Volume Manager peuvent avoir modifié le fichier /etc/system alors que le disque root principal était hors service.

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