Planification de la gestion des volumes

Cette section explique comment planifier la gestion des volumes pour votre configuration de cluster.

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). Vous ne pouvez utiliser qu'un gestionnaire de volumes au sein d'une même configuration de cluster. Reportez-vous à la documentation du gestionnaire de volumes et à l'Annexe A ou à l'Annexe B pour obtenir des instructions sur la configuration du logiciel de gestion de volumes. Pour plus d'informations sur la gestion des volumes dans une configuration de cluster, reportez-vous au document Sun Cluster 3.0 Concepts.

Ajoutez ces informations de planification aux fiches de travail relatives à la configuration des groupes d'unités de disque et à la configuration du gestionnaire de volumes disponibles dans le document Notes de version de Sun Cluster 3.0, et, le cas échéant, à la fiche de travail relative aux métapériphériques (Solstice DiskSuite) disponible dans le document Notes de version de Sun Cluster 3.0.

Recommandations relatives au logiciel de gestion des volumes

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

Disques multihosts mis en miroir : vous devez mettre tous les disques multihosts en miroir sur des unités d'extension de disque. Voir "Mise en miroir des disques multihosts" pour plus d'informations sur la mise en miroir des disques multihosts.
Root mis 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 plus d'informations sur la mise en miroir du disque root.
Noms uniques : sur tout noeud de cluster, 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 tout le cluster.
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 disque. Reportez-vous aux instructions de planification des groupes de ressources dans le document Sun Cluster 3.0 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 le cluster 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 oy 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 remplagables à chaud : vous pouvez utiliser des disques remplagables à 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 à Solstice DiskSuite

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

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'host 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 hosts). 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 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 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 du cluster. Par exemple, si un cluster 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. Le nombre maximal de métapériphériques autorisé par ensemble de disques est de 8192.
- 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 du cluster. Vous devez définir la valeur de md_nsets en fonction du nombre prévu d'ensembles de disques du cluster, plus un pour permettre au logiciel Solstice DiskSuite de gérer les disques privés sur l'host 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és par cluster est de 32.
Définissez ces champs au moment de l'installation en tenant compte des éventuelles extensions futures du cluster. L'augmentation de ces valeurs lorsque le cluster est 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 cluster 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 des pertes de données.

Recommandations relatives à 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 disque utilisera au moment de la création de ce groupe.
- 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 d'unités de disque. Il est impossible d'affecter des codes 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 les systèmes de fichiers de cluster. Sun Cluster prend en charge les systèmes de fichiers de journalisation suivants :

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

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) et au Solaris Transition Guide.

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	Solstice DiskSuite trans-metadevice UFS logging, Solaris 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 : avec Solstice DiskSuite trans-metadevice UFS logging, le trans-périphérique utilisé pour la journalisation crée un métapériphérique. Le journal reste cependant un métapériphérique distinct que vous pouvez mettre en miroir et en bandes. En outre, le logiciel Solstice DiskSuite permet de créer un système de fichiers de journalisation maximum de 1 To.

Recommandations relatives à la mise en miroir

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

Mise en miroir des disques multihosts

La mise en miroir de tous les disques multihosts 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 multihosts sur les unités d'extension de disque.

Tenez compte des points suivants lors de la mise en miroir des disques multihosts.

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 multihost différente.
Espace disque : la mise en miroir double l'espace disque nécessaire.
Mise en miroir à trois voies : VERITAS 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 : 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 le les disques multihosts, reportez-vous au document Sun Cluster 3.0 Concepts.

Mise en miroir du disque root

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 le disque root en miroir, tenez compte des risques, de la complexité, du co{t et du temps de maintenance des différentes alternatives. Il n'existe pas de stratégie de mise en miroir valable pour toutes les configurations. Pour savoir si vous devez ou non appliquer la mise en miroir au disque root, contactez votre interlocuteur Enterprise Services.

Reportez-vous à la documentation du gestionnaire de volumes et à l'Annexe A ou à l'Annexe B 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.
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.
Contrtleurs distincts : pour une disponibilité maximale, le disque root doit être mis en miroir sur un contrtleur 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 sont 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 stade, le système est particulièrement sensible aux problèmes d'obsolescence des sous-miroirs.