Planification de la gestion des volumes

Ajoutez ces informations de planification à la "fiche de travail relative aux configurations des groupes d'unités de disques" et à la "fiche de travail relative aux configurations du gestionnaire de volumes", disponibles dans les Notes de version de Sun Cluster 3.0 12/01. Pour Solstice DiskSuite, ajoutez également ces informations de planification à la "fiche de travail relative aux métapériphériques (Solstice DiskSuite)."

Cette section 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 par unités de disque pouvant être administrées comme une seule unité. Sun Cluster prend en charge le logiciel Solstice DiskSuite, ainsi que VERITAS Volume Manager (VxVM).

Si vous utilisez le logiciel Solstice DiskSuite, 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 que vous activez la fonction de grappe VxVM, vous devez installer et utiliser VxVM sous licence sur tous les noeuds de la grappe.
Si vous utilisez VxVM et que vous n'activez pas la fonction de grappe 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 ainsi que VxVM sur un noeud, vous devez utiliser le logiciel Solstice DiskSuite pour gérer les disques locaux de chaque noeud (comme le disque root) ainsi que VxVM pour gérer tous les disques partagés.

Reportez-vous à la documentation du gestionnaire de volumes ainsi qu'aux sections "Installation et configuration du logiciel Solstice DiskSuite" ou "Installation et configuration du logiciel VxVM" pour de plus amples informations sur l'installation et la configuration du logiciel du gestionnaire de volumes. Pour de plus amples informations sur la gestion de volume dans une configuration de grappe, reportez-vous à Sun Cluster 3.0 12/01 Concepts.

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 unités d'extension de disque. Voir "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 root améliore la disponibilité, mais elle n'est pas obligatoire. Voir "Recommandations relatives à la mise en miroir" pour de plus amples informations sur la mise en miroir du disque root.
Attribution d'un nom unique : sur tout noeud de grappe, si un métapériphérique Solstice DiskSuite local ou un volume VxVM est utilisé comme le périphérique sur lequel le système de fichiers /global/.devices/node@ID-noeud est monté, le nom de ce métapériphérique ou volume doit être unique dans toute la grappe.
Listes de noeuds : pour être à haute disponibilité, un groupe d'unités de disque doit avoir des listes de maîtres potentiels et une stratégie de repli en cas de panne identiques à celles du groupe de ressources associé. Ou, si un groupe de ressources évolutif utilise plus de noeuds que le groupe d'unités de disque associé, la liste de noeuds du groupe de ressources évolutif doit être un surensemble de la liste de noeuds du groupe d'unités de disques. Reportez-vous aux instructions de planification des groupes de ressources dans le document Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide pour de plus amples informations sur les listes de noeuds.
Disques multiports : tous les disques utilisés pour construire un groupe de périphériques dans la grappe doivent être connectés, ou reliés par un port, à tous les noeuds configurés dans la liste des noeuds de ce groupe de périphériques. Le logiciel Solstice DiskSuite est capable de procéder automatiquement à cette vérification au moment 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 remplaçables à chaud : vous pouvez utiliser des disques remplaçables à chaud pour améliorer la disponibilité, mais ce n'est pas obligatoire.

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

Recommandations relatives au logiciel Solstice DiskSuite

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

Noms de métapériphériques locaux : chaque nom de métapériphérique local doit être unique dans le cluster 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 disques et sous le contrôle de deux noeuds doit comporter des médiateurs Solstice DiskSuite configurés. Une chaîne de disque se compose d'une baie de disques avec ses disques physiques, des câbles de la baie vers le ou les noeuds et des cartes d'interface. Vous devez configurer chaque ensemble de disques avec exactement deux noeuds en tant qu'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 aux critères deux chaînes et deux hôtes. Reportez-vous à la page de manuel mediator(7) pour de plus amples informations.
Paramètres de /kernel/drv/md.conf : tous les métapériphériques utilisés par chaque ensemble de disques sont créés à l'avance, au moment de l'initialisation de la reconfiguration, en fonction des paramètres de configuration trouvés dans le fichier /kernel/drv/md.conf. Les champs du md.conf sont décrits dans la documentation de Solstice DiskSuite. Vous devez modifier les champs nmd et md_nsets comme suit pour prendre en charge une configuration Sun Cluster.
- nmd : le champ nmd définit le nombre de métapériphériques créés pour chaque ensemble de disques. Vous devez définir sa valeur en fonction du nombre maximum prévu de métapériphériques utilisés par l'un des ensembles de disques de la grappe. Par exemple, si une grappe utilise 10 métapériphériques dans ses 15 premiers ensembles de disques, mais 1000 dans le 16ème, vous devez définir la valeur de nmd sur au moins 1000. En outre, la valeur de nmd doit être telle qu'il y ait suffisamment de numéros pour que chaque DID et que chaque nom de métapériphérique local soit unique dans la grappe. Le nombre maximal de métapériphériques autorisé par ensemble de disques est de 8192. Le nombre par défaut est de 128 par ensemble de disques.
- 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 de gérer les disques privés sur l'hôte local (c'est à dire les métapériphériques ne faisant pas partie de l'ensemble de disques local). Le nombre maximal d'ensembles de disques autorisé par grappe est de 32. Le nombre par défaut est 4.
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 reconfiguration pour chaque noeud. Si vous reportez cette opération, cela augmente également la probabilité d'erreurs d'allocation d'espace dans le système de fichiers root (/) pour créer tous les périphériques nécessaires.

Attention :
Tous les noeuds de grappe doivent avoir des fichiers /kernel/drv/md.conf identiques, quel que soit le nombre d'ensembles de disques desservis par chaque noeud. Le non respect de cette consigne peut occasionner de graves erreurs de Solstice DiskSuite et un risque de pertes de données.

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 (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 root : vous devez créer un groupe d'unités de disques root par défaut (rootdg) sur chaque noeud. Le groupe de disques rootdg peut être créé sur les disques suivants.
- Le disque root, qui doit être encapsulé.
- Un ou plusieurs disques locaux non-root, qui peuvent être encapsulés ou initialisés.
- Une combinaison de disques root et de disques locaux non-root
Le groupe de disques rootdg doit être local sur le noeud.
Encapsulage : les disques à encapsuler doivent disposer de deux entrées de table de tranches de disque libres.
Nombre de volumes : lors de la création d'un groupe d'unités 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 numéros de mineur par défaut.
- Si ce nombre est supérieur ou égal à 1000, vous devez prévoir avec soin le mode d'affectation des numéros mineurs aux volumes du groupe d'unités de disques. Il est impossible d'affecter des numéros de mineurs se chevauchant à deux groupes de périphériques.
DRL : l'utilisation du système DRL (Dirty Region Logging) est vivement recommandée mais pas obligatoire. Le système DRL permet de réduire le temps de restauration des volumes en cas de panne du noeud. Il peut cependant réduire le débit d'E/S.

Journalisation du système de fichiers

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

Journalisation UFS Solaris
Journalisation UFS pour les trans-métapériphériques Solstice DiskSuite
Journalisation VERITAS File System (VxFS)

Pour de plus amples informations sur la journalisation UFS pour les trans-métapériphériques, reportez-vous à la documentation de Solstice DiskSuite. Pour de plus amples informations sur la journalisation UFS Solaris, reportez-vous à la page de manuel mount_ufs(1M). Pour de plus amples informations sur la journalisation VxFS, reportez-vous à la page de manuel mount_vxfs(1M) fournie avec le logiciel VxVM.

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

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


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

Tenez compte des points suivants si vous devez choisir entre Journalisation UFS Solaris et Journalisation UFS pour les trans-métapériphériques Solstice DiskSuite.

Taille du journal de Solaris UFS : Journalisation UFS Solaris alloue toujours le journal en utilisant l'espace libre sur le système de fichiers UFS et selon la taille du système de fichiers.
- Sur les systèmes de fichiers de moins de 1 Go, le journal occupe 1 Mo.
- Sur les systèmes de fichiers d'au moins 1 Go ou plus, le journal occupe 1 Mo par Go sur le système de fichiers, la limite maximale étant de 64 Mo.
Métapériphérique de journalisation : un trans-métapériphérique Solstice DiskSuite gère la journalisation UFS. Le périphérique de journalisation d'un trans-métapériphérique est un métapériphérique que vous pouvez mettre en miroir et en bandes. 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. Reportez-vous à la documentation de Solstice DiskSuite pour de plus amples informations sur la journalisation à l'aide de trans-métapériphériques.

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.