Planification de la gestion des volumes

Ajoutez ces informations de planification à la Fiche de travail relative aux configurations des groupes de périphériques et à la Fiche de travail relative à la configuration du gestionnaire de volumes. Pour Solaris Volume Manager, ajoutez également ces informations de planification à la Fiche d'information sur les volumes (Solaris Volume Manager).

Cette rubrique donne les recommandations suivantes sur la planification de la gestion de volume de la configuration de votre cluster :

Sun Cluster utilise un logiciel de gestion des volumes pour regrouper les disques par groupes de périphériques pouvant être administrés comme une seule unité. Il prend en charge les logiciels Solaris Volume Manager et VERITAS Volume Manager (VxVM) que vous pouvez installer et utiliser des manières indiquées ci-dessous.

Tableau 1–4 Utilisation des gestionnaires de volumes avec Sun Cluster


Gestionnaire de volumes	Configuration requise
Solaris Volume Manager	Vous devez installer le logiciel Solaris Volume Manager sur tous les nœuds du cluster, que vous utilisiez ou non VxVM sur certains nœuds pour gérer les disques.
SPARC : VxVM avec la fonction de cluster	Vous devez installer VxVM et obtenir la licence correspondante avec la fonction de cluster sur tous les nœuds du cluster.
VxVM sans la fonction cluster	Vous devez installer VxVM et en posséder la licence seulement pour les noeuds liés aux dispositifs de stockage gérés par VxVM.
Solaris Volume Manager et VxVM	Si vous installez ces deux gestionnaires de volumes sur le même noeud, vous devez utilisez le logiciel Solaris Volume Manager pour gérer les disques locaux de chaque noeud. Les disques locaux incluent le disque racine. Utilisez VxVM pour gérer tous les disques partagés.

Pour connaître les procédures d'installation et de configuration, reportez-vous à la documentation sur le gestionnaire de volumes et à la rubrique Configuration du logiciel Solaris Volume Manager ou à Installation et configuration du logiciel VxVM. Pour plus d'informations sur l'utilisation de la gestion de volumes dans une configuration de cluster, reportez-vous à Multihost Devices du Sun Cluster Concepts Guide for Solaris OS et à Device Groups du Sun Cluster Concepts Guide for Solaris OS.

Recommandations relatives au logiciel de gestion des volumes

Tenez compte des instructions générales suivantes lors de la configuration de vos disques à l'aide d'un logiciel de gestion de volumes :

Logiciel RAID – Le logiciel Sun Cluster ne prend pas en charge le logiciel RAID
Disques multihôtes mis en miroir : vous devez mettre tous les disques multihôtes en miroir sur les unités d'extension de disque. Pour obtenir plus d'informations sur la mise en miroir des disques multihôtes, reportez-vous à la rubrique Recommandations relatives à 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 matériel RAID ainsi que de chemins d'accès aux périphériques redondants.
Root mis en miroir : la mise en miroir du disque root assure une disponibilité élevée, mais elle n'est pas obligatoire. Pour savoir comment déterminer si la mise en miroir du disque racine est ou non souhaitable, reportez-vous à la rubrique Recommandations relatives à la mise en miroir.
Attribution de nom unique – Vous pouvez avoir des des Solaris Volume Manager locaux ou des volumes VxVM utilisés en tant que périphériques sur lesquels les systèmes de fichiers /global/.devices/node@nodeid sont montés. Dans ce cas, le nom de chaque volume local sur lequel un système de fichiers /global/.devices/node@nodeid doit être monté, doit être unique sur le cluster.
Listes de nœuds – Pour être hautement disponible, un groupe de périphériques doit posséder des listes de maîtres potentiels et une stratégie de rétablissement en cas de panne identique à celles du groupe de ressources associé. Ou, si un groupe de ressources évolutives utilise plus de nœuds ou de zones que le groupe de périphériques associé, la liste des nœuds du groupe de ressources évolutives doit être un surensemble de la liste des nœuds du groupe de périphériques. Pour obtenir plus d'informations sur les listes de nœuds, reportez-vous au manuel Sun Cluster Data Services Planning and Administration Guide for Solaris OS.
Disques multihôtes – Vous devez connecter ou lier à un nœud tous les périphériques utilisés pour établir un groupe sur tous les nœuds configurés pour ce groupe de périphériques. Le logiciel Solaris Volume Manager peut contrôler automatiquement cette connexion lors de l'ajout de périphériques à un jeu de disques. Cependant, les groupes de disques VxVM configurés ne sont associés à aucun ensemble de nœuds particulier.
Disques hot spare : vous pouvez utiliser des disques hot spare pour accroître la disponibilité, mais ils ne sont pas obligatoires.

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

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

Noms de volumes locaux – Le nom de chaque volume Solaris Volume Manager local sur lequel un système de fichiers de périphériques globaux, /global/.devices/node@nodeid, est monté, doit être unique sur le cluster. De plus, le nom ne peut pas être le même que celui d'aucun ID de périphérique.
Médiateurs à deux chaînes – Chaque ensemble de disques configuré avec exactement deux chaînes de disques et géré par exactement deux nœuds doit comporter des médiateurs Solaris Volume Manager pour l'ensemble de disques. 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 nœuds et des adaptateurs d'interface. Respectez les règles suivantes pour configurer les médiateurs à deux chaînes :
- Vous devez configurer chaque jeu de disques avec exactement deux nœuds intervenant en tant qu'hôtes médiateurs.
- Vous devez utiliser les deux mêmes nœuds pour tous les jeux de disques nécessitant des médiateurs. Ces deux nœuds doivent contrôler les jeux de disques.
- Les médiateurs ne peuvent pas être configurés pour des jeux de disques ne remplissant pas les conditions requises (deux chaînes et deux hôtes).
Pour obtenir plus d'informations, reportez-vous à la page de manuel mediator(7D).
paramètres /kernel/drv/md.conf – SPARC : Sous Solaris 9, les volumes Solaris Volume Manager qui sont utilisés par chaque ensemble de disques, sont créés à l'avance, au moment de la réinitialisation après reconfiguration. Cette reconfiguration se base sur les paramètres de configuration existant dans le fichier /kernel/drv/md.conf.

Remarque –
Avec la parution de Solaris 10, Solaris Volume Manager a été amélioré et prend désormais en charge la configuration dynamique des volumes. Il n'est plus nécessaire de modifier les paramètres nmd et md_nsets du fichier /kernel/drv/md.conf. Les nouveaux volumes sont créés de manière dynamique, selon vos besoins.

Vous devez modifier les champs nmd et md_nsets comme suit pour prendre en charge une configuration de Sun Cluster sur le SE Solaris 9 :

Caution –
Tous les nœuds de cluster doivent comprendre des fichiers /kernel/drv/md.conf identiques, quel que soit le nombre d'ensembles de disques servis par chaque nœud. Le non-respect de cette consigne peut occasionner de graves erreurs de Solaris Volume Manager et un risque de pertes de données.
- md_nsets : le champ md_nsets définit le nombre total de jeux de disques qui peuvent être créés pour un système afin de répondre aux besoins du cluster entier. Paramétrez la valeur du champ sur le nombre attendu de jeux de disques dans le cluster plus un jeu supplémentaire. Le logiciel Solaris Volume Manager utilise ce dernier pour gérer les disques privés sur l'hôte local.
  
  Le nombre maximal de jeux de disques autorisés par cluster est de 32. Il correspond à 31 jeux de disques dédiés à une utilisation générale plus un jeu destiné à la gestion de disques privés. La valeur par défaut de md_nsets est 4.
- nmd – Le champ nmd définit la valeur la plus élevée du futur nom de volume du cluster. Par exemple, si la valeur la plus élevée des noms de volume utilisés dans les 15 premiers ensembles de disques d'un cluster est égale à 10, mais que la valeur la plus élevée du volume dans le 16ème ensemble de disques est égale à 1000, définissez la valeur du nmd sur au moins 1000. En outre, la valeur de nmd doit être assez élevée pour s'assurer que suffisamment de numéros existent pour chaque nom d'ID de périphérique. Le nombre doit aussi être suffisamment élevé pour assurer que chaque nom de volume local peut être unique dans le cluster.
  
  La valeur maximale autorisée pour un nom de volume par ensemble de disques est 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 du cluster. L'augmentation de la capacité de ces champs, après la production du cluster, prend du temps. La modification de cette valeur nécessite une reconfiguration au démarrage pour chaque nœud. 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 md_nsets de sorte qu'elle soit légèrement supérieure au nombre de volumes que vous pensez utiliser.

Reportez-vous à Fichiers système et de démarrage dans le Manuel d'administration du gestionnaire de volumes Solaris (Solaris 9 ou dans Solaris 10) pour plus d'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) :

Accessibilité aux nœuds : vous devez configurer tous les groupes de disques du gestionnaire de volumes en tant que groupes de périphériques Sun Cluster ou groupes de disques locaux uniquement. Si vous ne configurez pas le groupe de disques de l'une de ces manières, les périphériques qu'il contient ne seront accessibles à aucun nœud du cluster.
- Un groupe de périphériques permet à des disques multihôtes d'être hébergés par un nœud secondaire en cas de panne du nœud principal.
- Un groupe de disques locaux uniquement n'est pas contrôlé par Sun Cluster et n'est accessible qu'à partir d'un nœud à la fois.
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), veillez à préserver la cohérence des noms sur tous les nœuds du cluster 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 nœuds. Des noms incompatibles n'ont pas d'incidence sur le comportement correct du cluster. Cependant, ils compliquent considérablement l'administration du cluster et augmentent grandement le risque d'erreurs de configuration, pouvant éventuellement engendrer des pertes de données.
Groupe de disques root – La création d'un groupe de disques root est facultative.

Un groupe de disques racine peut être créé sur les disques suivants :
- le disque racine, devant être encapsulé ;
- un ou plusieurs disques locaux non racine, pouvant être encapsulés ou initialisés ;
- une combinaison de disques racine et de disques locaux non racine.
Le groupe de disques racine doit être local sur le nœud.
groupes de disques root simples – Les groupes de disques root simples, qui sont créés sur une tranche unique du disque root, ne sont pas pris en charge par VxVM sur le logiciel Sun Cluster, en tant que types de disques. Il s'agit d'une restriction générale du logiciel VxVM.
Encapsulation : les disques à encapsuler doivent disposer de deux entrées libres de table de tranches.
Nombre de volumes : lors de la création d'un groupe de périphériques, estimez le nombre maximal de volumes qu'il 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. Il est impossible d'affecter des codes mineurs se chevauchant à deux groupes de périphériques.
Dirty Region Logging – L'utilisation de Dirty Region Logging (DRL) réduit le temps de récupération des volumes apès la défaillance d'un nœud. Il peut cependant réduire le débit d'E/S.
Multiacheminement dynamique : l'utilisation de cette seule fonction pour gérer plusieurs chemins d'E/S par nœud vers l'espace de stockage partagé n'est pas prise en charge. Seules les configurations suivantes prennent en charge l'utilisation de DMP :
- chemin d'E/S unique par noeud vers le stockage partagé du cluster ;
- solution de multi-acheminement prise en charge, telle que Sun Traffic Manager, EMC PowerPath ou Hiatchi HDLM et gérant plusieurs chemins d'E/S par noeud vers le stockage partagé du cluster.

Pour obtenir plus d'informations, reportez-vous à la documentation d'installation de VxVM.

Journalisation de système de fichiers

La journalisation est requise pour les systèmes de fichiers de cluster VxFS et UFS. Le logiciel Sun Cluster prend en charge les choix suivants en matière de journalisation de système de fichiers :

Journalisation UFS Solaris – Reportez-vous à la page de manuel mount_ufs(1M) pour plus d'informations.
SPARC : journalisation VERITAS File System (VxFS) (VxFS). Pour obtenir plus d'informations, reportez-vous à la page de manuel relative à mount_vxfs fournie avec VxFS.

Solaris Volume Manager et VERITAS Volume Manager prennent en charge les deux types de journalisation des systèmes de fichiers.

Recommandations relatives à la mise en miroir

Cette rubrique donne les recommandations suivantes sur la planification de la mise en miroir de la configuration de votre cluster :

Recommandations relatives à la mise en miroir des disques multihôtes

La mise en miroir de tous les disques multihôtes dans une configuration Sun Cluster permet de tolérer des pannes générées au niveau d'un seul périphérique. Sun Cluster requiert la mise en miroir de tous les disques multihôtes sur les différentes unités d'extension. Vous n'êtes pas tenu de procéder à une mise en miroir logicielle si le périphérique de stockage dispose de matériel RAID ainsi que de chemins d'accès aux périphériques redondants.

Lors de la mise en miroir de disques multihôtes, tenez compte des points suivants.

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 multihôte différente.
Espace disque : la mise en miroir double l'espace disque nécessaire.
Mise en miroir à trois voies : les logiciels 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.
Tailles de périphériques différentes – Si vous effectuez une mise en miroir vers un périphérique de taille différente, la capacité de mise en miroir se limite à la taille du plus petit sous-miroir ou plex.

Pour plus d'informations sur les disques multihôtes, reportez-vous à Multihost Disk Storage du Sun Cluster Overview for Solaris OS et à Sun Cluster Concepts Guide for Solaris OS.

Recommandations relatives à la mise en miroir du disque racine

Ajoutez ces informations de planification à la Fiche de travail de configuration des systèmes de fichiers locaux.

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 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.

Pour connaître les procédures de mise en miroir du disque racine, reportez-vous à la documentation sur le gestionnaire de volumes et à la rubrique Configuration du logiciel Solaris Volume Manager ou Installation et configuration du logiciel VxVM .

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

Disque d'initialisation : vous pouvez paramétrer le miroir afin qu'il devienne un disque root d'amorçage. Vous pourrez alors démarrer à partir du miroir en cas d'échec du disque d'amorçage principal.
Complexité : la mise en miroir du disque root complique l'administration du système, ainsi que l'initialisation en mode monoutilisateur.
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 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 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 (miroir) en cas de panne du disque racine principal. Plus tard, le disque root principal pourra être remis en service, par exemple, après une mise sous tension ou des erreurs E/S transitoires. Les initialisations ultérieures sont alors effectuées à l'aide du disque root principal, spécifié pour le paramètre eeprom(1M) boot-device. 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. Avec Solaris Volume Manager une resynchronisation a lieu. 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 (miroir) secondaire, elles ne seront pas reflétées sur le disque root principal lors de l'initialisation. Cela entraînerait un sous-miroir périmé. Par exemple, les éventuelles modifications apportées au fichier /etc/system sont perdues. Avec le logiciel Solaris Volume Manager, certaines commandes administratives peuvent avoir modifié le fichier /etc/system, pendant que le disque root principal était hors service.

Le programme d'initialisation ne vérifie pas si le système initialise à partir d'un miroir ou à partir d'un périphérique physique sous-jacent. La mise en miroir devient active à travers le processus d'initialisation, une fois que les volumes sont chargés. Avant ce point, le système est vulnérable face aux problèmes d'obsolescence des sous-miroirs.