Planification de la gestion des volumes

Ajoutez ces informations de planification aux fiches de travail relatives au gestionnaire de volumes, disponible dans le document Notes de version de Sun Cluster 3.0 U1. Pour Solstice DiskSuite, ajoutez aussi 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 en groupes d'unités de disque pouvant être administrés 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 activez sa fonction de grappe, vous devez installer et obtenir la licence de VxVM sur tous les noeuds de la grappe.
Si vous utilisez VxVM et n'activez pas sa fonction de grappe, vous ne devez installer et obtenir la licence de VxVM que sur les noeuds liés aux périphériques de stockage qui seront gérés par VxVM.
Si vous installez à la fois le logiciel Solstice DiskSuite et VxVM sur un noeud, vous devez utiliser le logiciel Solstice DiskSuite pour gérer les disques locaux de chaque noeud (comme le disque root) et 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 plus d'informations sur l'installation et la configuration du logiciel du gestionnaire de volumes. Pour plus d'informations sur la gestion des volumes dans une configuration de grappe, reportez-vous au document Sun Cluster 3.0 U1 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 plus d'informations sur la mise en miroir des disques multihôtes.
Root mis en miroir : la mise en miroir du disque root assure une haute disponibilité, mais elle n'est pas obligatoire. Voir "Recommandations relatives à la mise en miroir" pour plus d'informations sur la mise en miroir du disque root.
Noms uniques : sur tout noeud de grappe, si un métapériphérique Solstice DiskSuite ou un volume VxVM est utilisé comme périphérique de montage pour le système de fichiers /global/.devices/node@id_noeud, 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 U1 Data Services Installation and Configuration Guide pour plus d'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. En outre, lorsque vous enregistrez des ensembles de disques Solstice DiskSuite, des groupes de disques VxVM ou des ensembles individuels de périphériques globaux en tant que groupes de périphériques globaux, vous ne pouvez effectuer qu'une vérification limitée de la connectivité.
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 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 ayant exactement deux noeuds pour maîtres doit avoir 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 à critères (deux chaînes et deux hôtes). Reportez-vous à la page de manuel mediator(7) pour plus d'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 du démarrage de la reconfiguration, en fonction des paramètres de configuration trouvés dans le fichier /kernel/drv/md.conf. Les champs du fichier 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 - ce champ 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 à 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 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 : ce champ 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 en 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 règle peut entraîner des erreurs graves 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).

Groupe de disques root : vous devez créer un groupe d'unités de disque root par défaut (rootdg) sur chaque noeud. Ce groupe de disques 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 : estimez le nombre maximal de volumes qu'un groupe d'unités de disques utilisera au moment de la création de ce groupe.
- 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 :

Solaris UFS logging
Journalisation UFS pour les trans-métapériphériques Solstice DiskSuite

Pour plus d'informations sur Solstice DiskSuite trans metadevice UFS logging, reportez-vous à la documentation de Solstice DiskSuite. Pour plus d'informations sur Solaris UFS logging, reportez-vous à la page de manuel mount_ufs(1M).

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	Solaris UFS loggingSolstice DiskSuite trans metadevice UFS logging,
VERITAS Volume Manager	Solaris UFS logging

Tenez compte des points suivants lorsque vous choisissez entre la Solaris UFS logging et la Solstice DiskSuite trans metadevice UFS logging pour votre gestionnaire de volumes Solstice DiskSuite.

Taille du journal de Solaris UFS : Solaris UFS logging 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 du journal : 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. Vous pouvez créer un journal de 1 Go maximum, 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 plus d'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.

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 différente.
Espace disque : la mise en miroir double l'espace disque nécessaire.
Mise en miroir à trois voies : le logiciel 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 plus d'informations sur les disques multihôtes, reportez-vous au document Sun Cluster 3.0 U1 Concepts.

Mise en miroir du disque root

Ajoutez ces informations de planification à la fiche de travail relative à la configuration des systèmes de fichiers locaux, disponible dans le document Notes de version de Sun Cluster 3.0 U1.

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 mettez en miroir les sous-disques générés. Cependant, la mise en miroir du disque root n'est pas obligatoire pour Sun Cluster.

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 savoir comment appliquer la mise en miroir au disque root, vous pouvez prendre conseil auprès de votre interlocuteur Enterprise Services.

Reportez-vous à la documentation du gestionnaire de volumes et à la section "Installation et configuration du logiciel Solstice DiskSuite" ou "Installation et configuration du logiciel VxVM" pour plus d'informations sur la 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 plus d'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'erreurs 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.