Planification de la gestion des volumes

Ajoutez ces informations de planification à la Fiche de travail relative aux configurations des groupes de périphériques de disque et à la Fiche de travail relative à la configuration du gestionnaire de volumes. Pour Solstice DiskSuite ou Solaris Volume Manager, ajoutez également ces informations de planification à la Fiche de travail relative aux métapériphériques (Solstice DiskSuite ou 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 grouper les disques par groupes de périphériques de disques pouvant être administrés comme une seule unité. Il prend en charge les logiciels Solstice DiskSuite ou 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
Solstice DiskSuite ou Solaris Volume Manager	Vous devez installer le logiciel Solstice DiskSuite ou 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.
SPARC : VxVM sans la fonction de cluster	Vous devez installer VxVM et en posséder la licence seulement pour les nœuds liés aux dispositifs de stockage gérés par VxVM.
SPARC : Solstice DiskSuite ou Solaris Volume Manager et VxVM	Si vous installez ces deux gestionnaires de volumes sur le même nœud, vous devez utilisez le logiciel Solstice DiskSuite ou Solaris Volume Manager pour gérer les disques locaux de chaque nœud. 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 Installation et configuration du logiciel Solstice DiskSuite ou Solaris Volume Manager ou SPARC : Installation et configuration du logiciel VxVM . Pour obtenir plus d'informations sur la gestion de volumes dans une configuration de cluster, reportez-vous au document Guide des notions fondamentales de Sun Cluster pour SE Solaris.

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 :

RAID : Sun Cluster ne prend pas en charge le logiciel RAID 5.
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.
Disque racine mis en miroir : la mise en miroir du disque racine 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 d'un nom unique : vous pouvez disposer de métapériphériques Solstice DiskSuite locaux, de volumes Solaris Volume Manager locaux ou de volumes VxVM utilisés comme périphériques pour monter les systèmes de fichiers /global/.devices/node@nodeid. Dans ce cas, le nom de chaque métapériphérique ou volume local utilisé pour monter un système de fichiers /global/.devices/node@nodeid doit être unique sur le cluster.
Listes des nœuds : pour être hautement disponible, un groupe de périphériques de disques doit posséder des listes de maîtres potentiels et une stratégie de rétablissement en cas de panne identiques à celles du groupe de ressources associé. Ou, si un groupe de ressources évolutives utilise plus de nœuds que le groupe de périphériques de disques 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 de disques. Pour obtenir plus d'informations sur les listes de nœuds, reportez-vous aux rubriques consacrées à la planification des groupes de ressources dans le document Sun Cluster Data Services Planning and Administration Guide for Solaris OS.
Disques multihôtes : vous pouvez connecter 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 Solstice DiskSuite ou 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 Solstice DiskSuite ou Solaris Volume Manager

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

Nom de métapériphérique/de volume local : le nom de chaque métapériphérique Solstice DiskSuite ou volume Solaris Volume Manager local utilisé pour monter un système de fichiers de périphériques globaux /global/.devices/node@nodeid 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 jeu de disques configuré avec exactement deux chaînes de disque et géré par exactement deux nœuds doit comporter des médiateurs Solstice DiskSuite ou 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 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 : tous les métapériphériques Solstice DiskSuite ou volumes Solaris Volume Manager (Solaris 9) utilisés par chaque jeu 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.

Pour prendre en charge une configuration Sun Cluster sous Solaris 8 ou Solaris 9, vous devez modifier les champs nmd et md_nsets comme suit :

Caution –
Tous les nœuds du cluster doivent disposer de fichiers /kernel/drv/md.conf identiques, quel que soit le nombre de jeux de disques servis par chacun d'eux. Le non-respect de cette consigne peut occasionner de graves erreurs de Solstice DiskSuite ou 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 Solstice DiskSuite ou 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 métapériphérique/de volume du cluster. Par exemple, si la plus haute valeur utilisée par les 15 premiers jeux de disques d'un cluster est 10, alors que celle du seizième est 1000, définissez nmd sur au moins 1000. Par ailleurs, la valeur de nmd doit être suffisamment grande pour prendre en compte chaque ID de périphérique et pour garantir que le nom de chaque métapériphérique local ou de chaque volume local est unique dans tout le cluster.
  
  La valeur maximale de noms de métapériphérique ou de volume par jeu de disques est de 8192. La valeur par défaut du champ 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 root (/) 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.

Pour obtenir plus d'informations sur le fichier md.conf, reportez-vous à la rubrique System and Startup Files du document Solstice DiskSuite 4.2.1 Reference Guide (Solaris 8) ou System Files and Startup Files du Solaris Volume Manager Administration Guide (Solaris 9 ou Solaris 10).

SPARC : 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), 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 racine : depuis VxVM 4.0, la création d'un groupe de disques racine 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 racine simples : Sun Cluster ne prend pas en charge les groupes de disques racine simples (rootdg créé sur une tranche unique) avec VxVM. 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 de disques, 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 de disques. Il est impossible d'affecter des codes mineurs se chevauchant à deux groupes de périphériques.
Journal des zones modifiées : l'utilisation de ce journal permet une récupération plus rapide des volumes aprè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. Elle ne l'est que pour les configurations suivantes :
- chemin d'E/S unique par nœud 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 nœud 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. Cette obligation ne s'applique pas aux systèmes de fichiers partagés QFS. Le logiciel Sun Cluster prend en charge les choix suivants en matière de journalisation de système de fichiers :

Journalisation UFS Solaris : pour obtenir plus d'informations, reportez-vous à la page de manuel mount_ufs(1M).
Journalisation de trans-métapériphériques Solstice DiskSuite ou Journalisation de volumes de transaction Solaris Volume Manager : reportez-vous au Chapitre 2, Creating DiskSuite Objects du Solstice DiskSuite 4.2.1 User’s Guide ou à la rubrique Transactional Volumes (Overview) du Solaris Volume Manager Administration Guide. Les volumes transactionnels ne sont plus valides depuis la version Solaris 10 de Solaris Volume Manager.
SPARC : journalisation Système de fichiers VERITAS (VxFS). Pour obtenir plus d'informations, reportez-vous à la page de manuel relative à mount_vxfs fournie avec VxFS.

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

Tableau 1–5 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 ou Solaris Volume Manager	Journalisation UFS Solaris Journalisation de trans-métapériphériques Solstice DiskSuite Journalisation de volumes de transaction Solaris Volume Manager Journalisation VxFS
SPARC : VERITAS Volume Manager	Journalisation UFS Solaris Journalisation VxFS

Lors du choix entre la Journalisation UFS Solaris et la Journalisation de trans-métapériphériquesSolstice DiskSuite/Journalisation de volumes de transaction Solaris Volume Manager pour les systèmes de fichiers de cluster UFS, tenez compte des points suivants :

Solaris Volume Manager Journalisation de volumes de transaction (anciennement Solstice DiskSuite Journalisation de trans-métapériphériques) sera supprimée du système d'exploitation Solaris dans une version à venir. La Journalisation UFS Solaris offre les mêmes possibilités mais avec des performances optimales, ainsi que des conditions d'administration système et une surcharge allégées.
Taille du journal de Solaris UFS : la Journalisation UFS Solaris alloue toujours le journal avec 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/volume de transaction de journalisation : un trans-métapériphérique Solstice DiskSuite ou un volume de transaction Solaris Volume Manager 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 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 Solstice DiskSuite ou 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 disques différentes : si vous effectuez une mise en miroir vers un disque de taille différente, la capacité de mise en miroir se limite à la taille du plus petit sous-miroir ou plex.

Pour obtenir plus d'informations sur les disques multihôtes, reportez--vous à la rubrique Stockage sur disques multihôtes du Présentation de Sun Cluster pour SE Solaris et au Guide des notions fondamentales de Sun Cluster pour SE Solaris.

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

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 Installation et configuration du logiciel Solstice DiskSuite ou Solaris Volume Manager ou SPARC : 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 racine 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 racine 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 Solstice DiskSuite ou 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 ou 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 racine principal pourra être remis en service, par exemple, après une mise sous tension ou des erreurs E/S transitoires. Les initialisations qui suivront seront effectuées sur le disque racine principal indiqué 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 Solstice DiskSuite ou 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 racine (miroir) secondaire, elles ne seront pas reflétées sur le disque racine 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 Solstice DiskSuite ou Solaris Volume Manager, certaines commandes administratives sont susceptibles de modifier le fichier /etc/system tandis que le disque racine principal est 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 métapériphériques ou les volumes sont chargés. Avant ce point, le système est vulnérable face aux problèmes d'obsolescence des sous-miroirs.