Planification de la gestion des volumes

Ajoutez ces informations de planification à la “Disk Device Groups Worksheet” dans les Sun Cluster 3.1 Release Notes et à la “Volume Manager Configurations Worksheet” dans les Sun Cluster 3.1 Release Notes. Pour Solstice DiskSuite/Solaris Volume Manager, ajoutez également ces informations à la “Metadevices Worksheet (Solstice DiskSuite/Solaris Volume Manager)” dans les Sun Cluster 3.1 Release Notes.

Cette rubrique 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 de périphériques de disques pouvant être administrés comme une seule unité. Sun Cluster prend en charge le logiciel Solstice DiskSuite/Solaris Volume Manager, ainsi que VERITAS Volume Manager (VxVM).

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

Reportez-vous à la documentation du gestionnaire de volumes ainsi qu'aux rubriques Installation et configuration du logiciel Solstice DiskSuite/Solaris Volume Manager ou Installation et configuration du logiciel VxVM pour de plus amples informations sur l'installation et la configuration du logiciel de gestion des volumes. Pour de plus amples informations sur la gestion des volumes dans une configuration de grappe, reportez-vous au Sun Cluster 3.1 Concepts Guide.

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 périphériques d'extension de disques. Reportez-vous à la rubrique 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 racine améliore la disponibilité, mais elle n'est pas obligatoire. Reportez-vous à la rubrique Recommandations relatives à la mise en miroir pour de plus amples informations sur la mise en miroir du disque racine.
Attribution d'un nom unique : si un métapériphérique Solstice DiskSuite local ou un volume Solaris Volume Manager ou VxVM local est utilisé comme le périphérique sur lequel le système de fichiers /global/.devices/node@nodeid est monté, le nom de ce métapériphérique ou volume doit être unique sur l'ensemble de la grappe.
Listes des noeuds : pour être à haute disponibilité, un groupe de périphériques de disques doit comporter 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 de périphériques de disques associé, la liste des noeuds du groupe de ressources évolutif doit être un surensemble de la liste des noeuds du groupe de périphériques de disques. Reportez-vous aux données de planification du groupe de ressources dans le Sun Cluster 3.1 Data Services Installation and Configuration Guide pour de plus amples informations sur les listes des noeuds.
Disques multiports : vous devez connecter ou relier par un port tous les disques utilisés pour monter un groupe de périphériques au sein de la grappe à tous les noeuds configurés dans la liste des noeuds de ce groupe de périphériques. Le logiciel Solstice DiskSuite/Solaris Volume Manager 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 de partition dynamique : vous pouvez utiliser des disques de partition dynamique pour accroître la disponibilité, mais ils ne sont pas nécessaires.

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/Solaris Volume Manager

Tenez compte des points suivants lorsque vous planifiez des configurations Solstice DiskSuite/Solaris Volume Manager.

Nom de métapériphériques ou de volumes locaux : le nom de chaque métapériphérique Solstice DiskSuite ou de volume Solaris Volume Manager local doit être unique au sein de 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 géré par exactement deux noeuds doit comporter des médiateurs Solstice DiskSuite/Solaris Volume Manager. 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 adaptateurs 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 à ces critères (deux chaînes et deux hôtes). Reportez-vous à la page de manuel mediator( 7D) pour de plus amples informations.
Paramètres /kernel/drv/md.conf : tous les métapériphériques Solstice DiskSuite ou les volumes Solaris Volume Manager utilisés par chaque ensemble de disques sont créés à l'avance, au moment de l'initialisation de la reconfiguration, suivant les paramètres de configuration figurant dans le fichier /kernel/drv/md.conf.

Vous devez modifier les champs nmd et md_nsets comme suit pour prendre en charge une configuration Sun Cluster :
- 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/Solaris Volume Manager de gérer les disques privés sur l'hôte local (c'est-à-dire les métapériphériques ou les volumes ne faisant pas partie de l'ensemble de disques local).
  
  Le nombre maximum d'ensembles de disques autorisé par grappe est de 32 : 31 sont dédiés à une utilisation d'ordre général et 1 est dédié à la gestion de disques privée). La valeur par défaut de md_nsets est 4.
- nmd : ce champ définit le nombre de métapériphériques ou de volumes créés par ensemble de disques. Vous devez définir sa valeur sur le nombre maximum prévu de noms de métapériphérique ou de volume utilisés par l'un des ensembles de disques de la grappe. Par exemple, si une grappe utilise 10 métapériphériques ou volumes dans ses 15 premiers ensembles de disques, mais 1000 dans le 16ème, la valeur de nmd que vous définissez doit au moins être égale à 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 ou de volume local soit unique dans la grappe.
  
  La valeur maximale d'un nom de métapériphérique ou de volume par ensemble de disques est de 8192. La valeur par défaut de nmd est 128.
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 la reconfiguration de 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 racine (/) pour créer tous les périphériques nécessaires.

Parallèlement, définissez la valeur des champs nmd et md_nsets sur la valeur la plus basse possible. Les structures de mémoire existent pour tous les périphériques possibles conformément aux commandes nmd et md_nsets, même si vous n'avez pas créé ces périphériques. Pour des performances optimales, configurez la valeur de nmd et de md_nsets de sorte qu'elle soit légèrement supérieure au nombre de métapériphériques ou de volumes que vous utiliserez.

Attention :
les fichiers /kernel/drv/md.conf de tous les noeuds de la grappe doivent être identiques, indépendamment du nombre d'ensembles de disques desservis par chaque noeud. Le non respect de cette consigne peut occasionner de graves erreurs de Solstice DiskSuite/Solaris Volume Manager et un risque de pertes de données.

Reportez-vous également à la rubrique “System and Startup Files” du Solstice DiskSuite 4.2.1 Reference Guide ou à la rubrique “System Files and Startup Files”du Solaris Volume Manager Administration Guide pour de plus amples informations sur le fichier md.conf.

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 (Enclosure-Based Naming - 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 racine : vous devez créer un groupe de disques racine par défaut (rootdg) sur chaque noeud. Le groupe de disques rootdg peut être créé sur les disques suivants :
- Le disque racine, qui doit être encapsulé.
- Un ou plusieurs disques locaux non racine, qui peuvent être encapsulés ou initialisés.
- Une combinaison de disques racine et de disques locaux non racine
Le groupe de disques rootdg doit être local sur le noeud.
Encapsulage : les disques à encapsuler doivent posséder deux entrées de table de tranches de disque libres.
Nombre de volumes : lors de la création d'un groupe de périphériques 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 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 de périphériques de disques. Il est impossible d'affecter des codes mineurs se chevauchant à deux groupes de périphériques.
Système DRL (Dirty Region Logging) : l'utilisation du système DRL est fortement conseillé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 de système de fichiers

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

Journalisation UFS Solaris : pour de plus amples informations, reportez-vous à la page mount_ufs(1M) du manuel.
Journalisation de trans-métapériphériques Solstice DiskSuite ou Journalisation de volumes de transaction Solaris Volume Manager : reportez-vous à la rubrique “Creating DiskSuite Objects” du Solstice DiskSuite 4.2.1 User's Guide ou à la rubrique “Transactional Volumes (Overview)” du Solaris Volume Manager Administration Guide pour de plus amples informations.
Journalisation VERITAS File System (VxFS) : reportez-vous à la page mount_vxfs du manuel fournie avec le logiciel VxFS pour de plus amples informations.

Le tableau suivant répertorie les journalisations de systèmes de fichiers prises 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 Volume Manager	Journalisation UFS Solaris, Journalisation de trans-métapériphériques Solstice DiskSuite, Journalisation de volumes de transaction Solaris Volume Manager ou Journalisation VxFS
VERITAS Volume Manager	Journalisation UFS Solaris, Journalisation VxFS

Tenez compte des points suivants lorsque vous faites votre choix entre Journalisation UFS Solaris et Journalisation de trans-métapériphériques.

Les volumes de transaction devraient être supprimés de l'environnement d'exploitation Solaris dans une version ultérieure de Solaris. La Journalisation UFS Solaris, disponible depuis la version Solaris 8, offre les mêmes fonctions tout en permettant d'obtenir à la fois des performances supérieures et un entête et des exigences en matière d'administration système nettement moindres.
Taille du journal de Solaris UFS : la Journalisation UFS Solaris alloue toujours le journal au moyen de l'espace libre sur le système de fichiers UFS suivant 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 ou un volume Solaris Volume Manager de transaction gère la journalisation UFS. Le composant de journalisation d'un trans-métapériphérique ou d'un volume de transaction est un métapériphérique ou un volume qui permet la mise en miroir et en bande. 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.

Recommandations relatives à la mise en miroir

Cette rubrique 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 duplication de tous les disques multihôtes sur les periphériques 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 d'accès aux disques redondants.

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

Périphériques d'extension de disque distincts : chaque sous-miroir d'un miroir ou d'un plex donné doit résider dans un périphérique d'extension de disque multihôte different.
Espace disque : la mise en miroir double l'espace disque nécessaire.
Mise en miroir à trois voies : les logiciels Solstice DiskSuite/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/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 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 Sun Cluster 3.1 Concepts Guide.

Mise en miroir du disque racine

Ajoutez ces informations de planification à la “Local File Systems With Mirrored Root Worksheet” dans les Sun Cluster 3.1 Release Notes.

Pour une disponibilité maximale, mettez en miroir les systèmes de fichiers racine (/), /usr, /var, /opt et swap sur les disques locaux. Sous VxVM, vous encapsulez le disque racine et dupliquez les sous-disques générés. Le logiciel Sun Cluster n'impose pas de mise en miroir du disque racine.

Avant de décider de mettre ou non le disque racine 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 racine, 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/Solaris Volume Manager ou Installation et configuration du logiciel VxVM pour connaître la procédure de mise en miroir du disque racine.

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

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.
Complexité : la duplication du disque racine complique l'administration du système et le démarrage en mode mono-utilisateur.
Sauvegardes : qu'il soit ou non mis en miroir, le disque racine 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 racine en miroir.
Quorum : sous le logiciel Solstice DiskSuite/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/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 racine doit être mis en miroir sur un contrôleur distinct.
Disque racine secondaire : avec un disque racine mis en miroir, vous pouvez continuer à travailler à partir du disque racine secondaire (le miroir) en cas de panne du disque racine principal. Plus tard, si le disque racine principal fonctionne de nouveau (peut-être après un redémarrage ou en raison d'une erreur d'E/S temporaire), 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/Solaris Volume Manager 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 racine secondaire (miroir), elles ne sont pas reflétées sur le disque racine 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/Solaris Volume Manager peuvent avoir modifié le fichier /etc/system alors que le disque racine principal était hors service.

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