Recommandations relatives à la mise en miroir

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

Mise en miroir des disques multihôtes

La mise en miroir de tous les disques multihôtes dans une configuration Sun Cluster permet à la configuration de tolérer les défaillances d'un disque unique. Le logiciel Sun Cluster nécessite la mise en miroir de tous les disques multihôtes sur les unités d'extension de disque. 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.

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

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

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

• Mise en miroir à trois voies : Solstice DiskSuite et VERITAS Volume Manager (VxVM) prennent en charge la mise en miroir à trois voies. Cependant, Sun Cluster ne nécessite qu'une mise en miroir à deux voies.

• Nombre de métapériphériques : avec le logiciel Solstice DiskSuite les miroirs sont composés d'autres métapériphériques tels que des concaténations ou des bandes. Les grandes configurations peuvent comporter un grand nombre de métapériphériques. Par exemple, sept métapériphériques sont créés pour chaque système de fichiers UFS de journalisation.

• Tailles de disques différentes : si vous placez la copie miroir sur un disque d'une taille différente, votre capacité de mise en miroir est limitée à la taille du sous-miroir ou du plex le plus petit.

Pour de plus amples informations sur les disques multihôtes, reportez-vous au document Sun Cluster 3.0 12/01 Concepts.

Mise en miroir du disque root

Ajoutez ces informations à la "fiche de travail relative à la disposition des systèmes de fichiers locaux" dans Notes de version de Sun Cluster 3.0 12/01.

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 le disque root. 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 Enterprise Services.

Reportez-vous à la documentation de votre gestionnaire de volumes et aux sections "Installation et configuration du logiciel Solstice DiskSuite" ou "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 au disque root :

• Complexité : la mise en miroir du disque root complique l'administration système et l'initialisation en mode mono-utilisateur.

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

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

• Quorum : avec le logiciel Solstice DiskSuite en cas de panne entraînant la perte du quorum de la base de données d'état des métapériphériques, vous ne pouvez pas réinitialiser le système sans effectuer un minimum de maintenance. Reportez-vous à la documentation de Solstice DiskSuite pour de plus amples informations sur la base de données d'état des métapériphériques et ses répliques.

• Contrôleurs distincts : pour une disponibilité maximale, le disque root doit être mis en miroir sur un contrôleur distinct.

• Disque d'initialisation : vous pouvez définir la copie miroir comme étant un disque d'initialisation pour pouvoir démarrer à partir de cette copie en cas de panne du disque principal.

• Disque root secondaire : avec un disque root mis en miroir, vous pouvez continuer à travailler à partir du disque root secondaire (le miroir) en cas de panne du disque root principal. Plus tard, si le disque root principal fonctionne de nouveau (peut-être après un redémarrage ou en raison d'erreur d'E/S temporaires), les initialisations suivantes seront effectuées à partir du disque d'initialisation principal défini dans le champ boot-device de la PROM OpenBoot^TM. Dans ce cas, aucune tâche de réparation manuelle n'a eu lieu, mais le lecteur redémarre à un niveau suffisant pour permettre la réinitialisation. Notez qu'aucune resynchronisation de Solstice DiskSuite ne se produit. La resynchronisation nécessite une étape manuelle lors de la remise en service du lecteur.

  Si des modifications ont été apportées à des fichiers du disque root secondaire (miroir), elles ne sont pas reflétées sur le disque root principal au moment de la réinitialisation (dont les données sont alors obsolètes). Par exemple, les éventuelles modifications apportées au fichier /etc/system sont perdues. Certaines commandes administratives de Solstice DiskSuite peuvent avoir modifié le fichier /etc/system alors que le disque root principal était hors service.

  Le programme d'initialisation ne vérifie pas s'il démarre à partir d'un miroir ou d'un périphérique physique sous-jacent, et la mise en miroir s'active partiellement au cours du processus d'initialisation (après le chargement des métapériphériques). Avant ce point, le système est vulnérable face aux problèmes d'obsolescence des sous-miroirs.