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 disques et à la Fiche de travail relative aux configurations du gestionnaire de volumes. Pour Solstice DiskSuite/Solaris Volume Manager, ajoutez également ces informations de planification à la Fiche de travail relative aux métapériphériques (Solstice DiskSuite/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/Solaris Volume Manager et VERITAS Volume Manager (VxVM) que vous pouvez installer et utiliser des manières indiquées ci-dessous.

Tableau 1–4 Gestionnaires de volumes pris en charge par Sun Cluster


Logiciel de gestionnaire de volume	Conditions requises
Solstice DiskSuite/Solaris Volume Manager	Vous devez installer le logiciel Solstice DiskSuite/Solaris Volume Manager sur tous les noeuds du cluster, que vous utilisiez ou non VxVM sur certains noeuds pour gérer les disques.
VxVM avec la fonction du cluster	Vous devez installer VxVM et en posséder la licence avec la fonction cluster sur tous les noeuds 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.
Solstice DiskSuite/Solaris Volume Manager et VxVM à la fois	Si vous installez ces deux gestionnaires de volumes sur le même noeud, vous devez utilisez le logiciel Solstice DiskSuite/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.

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 cluster, reportez-vous au document Guide des notions fondamentales de Sun Cluster 3.1 10/03.

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 :

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 Recommandations relatives à la 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 matériel RAID ainsi que de chemins d'accès aux disques redondants.
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 de nom unique : vous pouvez avoir des métapériphériques Solstice DiskSuite locaux, des volumes Solaris Volume Manager locaux, ou des volumes VxVM utilisés en tant que périphériques sur lesquels sont montés des systèmes de fichiers /global/.devices/node@id_noeud. Si tel est le cas, le nom de chaque métapériphérique local ou volume local doit être unique dans tout le cluster.
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 de ressources dans le document Sun Cluster 3.1 Data Service Planning and Administration 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 du cluster à tous les noeuds configurés dans la liste des noeuds de ce groupe de périphériques. Le logiciel Solstice DiskSuite/Solaris Volume Manager peut contrôler automatiquement cette connexion au moment où des 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 hot spare : vous pouvez utiliser des disques hot spare 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.

Noms des métapériphériques locaux ou des volumes : le nom de chaque métapériphérique Solstice DiskSuite ou volume Solaris Volume Manager doit être unique dans tout le cluster. De plus, le nom ne peut pas être le même que celui d'aucun ID de périphérique.
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. Respectez les règles suivantes pour configurer les médiateurs :
- 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. Ces deux noeuds doivent maîtriser 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 groupe de disques sont créés à l'avance, au moment de l'initialisation de la reconfiguration. Cette reconfiguration se base sur les paramètres de configuration existant dans le fichier /kernel/drv/md.conf.

Caution –
les fichiers /kernel/drv/md.conf de tous les noeuds du cluster 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.

Vous devez modifier les champs nmd et md_nsets comme indiqué ci-dessous 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 du cluster. Réglez la valeur de md_nsets sur le nombre d'ensembles de disques envisagé du cluster plus un supplémentaire. Solstice DiskSuite/Solaris Volume Manager utilise l'ensemble de disques supplémentaire pour gérer les disques privés sur l'hôte local. Les disques privés sont ces métapériphériques ou volumes absents de l'ensemble de disques local.
  
  Le nombre maximal d'ensembles de disques autorisés par cluster est de 32. Ce nombre comprend 31 ensembles de disques d'utilisation générale plus un ensemble de disques pour la gestion de disques privés. 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. Définissez sa valeur sur le nombre maximum prévu de métapériphériques ou volumes utilisés par l'un des ensembles de disques du cluster. Par exemple, si un cluster 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 être au moins égale à 1000. Cette valeur doit également être suffisamment importante pour s'assurer qu'il existe assez de nombres pour l'ID de chaque 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 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 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 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 nmdet 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.

Reportez-vous à la rubrique “System and Startup Files” du document Solstice DiskSuite 4.2.1 Reference Guide ou à la rubrique “System Files and Startup Files” in Solaris Volume Manager Administration Guide pour obtenir 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) :

Attribution de noms basée sur la délimitation : l'attribution de noms basée sur la délimitation est une fonction introduite dans le logiciel VxVM version 3.2. Si vous l'utilisez pour des périphériques, assurez-vous d'utiliser des noms de périphériques compatibles sur tous les noeuds du cluster partageant 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. Des noms incompatibles n'ont pas d'incidence sur le comportement correct du cluster. Cependant, cela complique considérablement l'administration du cluster et augmente grandement le risque d'erreurs de configuration, pouvant éventuellement engendrer des pertes 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, 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 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.
Journal des zones modifiées : l'utilisation du journal des zones modifiées permet une récupération plus rapide des volumes après un échec de noeud. Il peut cependant réduire le débit d'E/S.
DMP (multi-acheminement dynamique) : le DMP n'est pas pris en charge par les configurations Sun Cluster. Si vous utilisez VxVM dans une configuration avec plusieurs chemins par noeud, vous devez alors utiliser une autre solution de multi-acheminement telle que Sun StorEdge Traffic Manager ou EMC PowerPath. Cependant, l'activation du DMP sur des systèmes ne comportant qu'un seul chemin par noeud ne pose aucun problème.

Journalisation de système de fichiers

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

Journalisation UFS Solaris : pour de plus amples 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 à la rubrique “Creating DiskSuite Objects” in Solstice DiskSuite 4.2.1 User's Guide ou à la rubrique “Transactional Volumes (Overview)” in 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–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/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

Prenez en compte les points suivants lorsque vous faites votre choix entre la Journalisation UFS Solaris et la Journalisation de trans-métapériphériques Solstice DiskSuite/Journalisation de volumes de transaction Solaris Volume Manager :

La Journalisation de volumes de transaction Solaris Volume Manager (anciennement Journalisation de trans-métapériphériques Solstice DiskSuite) doit être supprimée de l'environnement d'exploitation Solaris dans une prochaine version de Solaris. 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 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/volume de transaction 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 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 à 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 périphé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 matériel RAID 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 différent.
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 effectuez une mise en miroir vers un disque de taille différente, votre capacité de mise en miroir se limite à la taille du plus petit sous-miroir ou plex.

Pour de plus amples informations sur les disques multihôtes, reportez-vous au document Guide des notions fondamentales de Sun Cluster 3.1 10/03.

Recommandations relatives à la mise en miroir du disque racine

Ajoutez ces informations de planification à la Fiche de travail relative à la 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.

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 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/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 (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 ultérieures sont alors effectuées à l'aide du disque racine principal spécifié 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. Avec Solstice DiskSuite/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. 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 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.