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–5 Gestionnaires de volumes pris en charge par Sun Cluster


Logiciel de gestionnaire de volume	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 cluster	Vous devez installer VxVM,et en posséder la licence, avec la fonction cluster sur tous les nœuds du cluster.
SPARC : VxVM sans la fonction 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 utiliser le logiciel Solstice DiskSuite ou Solaris Volume Manager pour gérer les disques locaux de chaque nœud. Les disques locaux incluent le disque root. 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 ou Solaris Volume Manager ou SPARC: 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 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 : 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. 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 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. Reportez-vous à la rubrique Recommandations relatives à la mise en miroir pour de plus amples informations sur la mise en miroir du disque root.
Attribution de noms uniques : vous pouvez disposer de métapériphériques Solstice DiskSuite locaux, de volumes Solaris Volume Manager locaux ou de volumes VxVM utilisés en tant que périphériques sur lesquels sont montés les systèmes de fichiers /global/.devices/node@id_nœud. 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 nœuds : 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 nœuds que le groupe de périphériques de disques associé, la liste des nœuds du groupe de ressources évolutif doit être un surensemble de la liste des nœuds du groupe de périphériques de disques. Reportez-vous aux informations de planification de ressources dans le document Sun Cluster Data Service Planning and Administration Guide for Solaris OS pour de plus amples informations sur les listes des nœuds.
Disques multihôtes : vous devez connecter ou relier par un port, tous les périphériques utilisés dans le cadre de l'élaboration d'un groupe de périphériques au sein du cluster à tous les nœuds configurés dans la liste de nœuds du 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.

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 à 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).
Reportez-vous à la page man mediator( 7D) pour de plus amples informations.
Paramètres /kernel/drv/md.conf : tous les métapériphériques Solstice DiskSuite ou tous les volumes Solaris Volume Manager utilisés par chacun des jeux de disques sont créés à l'avance, lors 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 –
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.

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 de jeux de disques pouvant être créés afin qu'un système réponde 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. Les disques privés sont les métapériphériques ou volumes absents du jeu de disques 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 le nombre de métapériphériques ou de volumes créés pour chacun des jeux de disques. Définissez sa valeur sur le nombre maximum prévu de métapériphériques ou de volumes utilisés par l'un des jeux de disques du cluster. Par exemple, si un cluster utilise 10 métapériphériques ou volumes dans les 15 premiers jeux de disques, mais 1000 métapériphériques ou volumes dans le 16e jeu, vous devez paramétrer le champ nmd sur une valeur supérieure ou égale à 1000. De même, cette valeur doit être suffisamment grande afin de garantir qu'il existe au moins autant de numéros que de noms IDP 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.

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” du document Solaris Volume Manager Administration Guide pour obtenir de plus amples informations sur le fichier md.conf.

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, 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 root : si vous utilisez VxVM 3.5 ou version antérieure, vous devez créer un groupe de disques root sur chacun des nœuds. Pour VxVM 4.0, la création d'un groupe de disques root est facultative.

Un groupe de disques root peut être créé sur les disques suivants :
- le disque root, devant être encapsulé ;
- un ou plusieurs disques locaux non root, pouvant être encapsulés ou initialisés ;
- une combinaison de disques root et de disques locaux non root.
Le groupe de disques root doit être local sur le nœud.
Groupes de disques root simples : les groupes de disques root simples (rootdg créé sur une seule tranche du disque root) ne sont pas pris en charge en tant que types de disques avec le logiciel VxVM sur Sun Cluster. Il s'agit d'une restriction générale du logiciel VxVM.
Encapsulation : les disques à encapsuler doivent disposer de 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 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 multiacheminement 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 de plus amples informations, reportez-vous à la documentation d'installation de VxVM.

Journalisation de système de fichiers

La journalisation des systèmes de fichiers de cluster UFS et VxFS est requise. 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 plus d'informations, reportez-vous à la page man mount_ufs(1M).
Solstice DiskSuite Journalisation de trans-métapériphériques ou Solaris Volume Manager Journalisation de volumes de transaction : pour plus d'informations, reportez-vous à la rubrique “Creating DiskSuite Objects” du manuel Solstice DiskSuite 4.2.1 User's Guide ou à la rubrique “Transactional Volumes (Overview)” du manuel Solaris Volume Manager Administration Guide.
Journalisation SPARC : Système de fichiers VERITAS (VxFS) : pour plus d'informations, reportez-vous à la page man mount_vxfs fournie avec le logiciel VxFS.

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

Tableau 1–6 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 Solstice DiskSuite Journalisation de trans-métapériphériques Solaris Volume Manager Journalisation de volumes de transaction Journalisation VxFS
SPARC : 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 Solstice DiskSuite Journalisation de trans-métapériphériques/Solaris Volume Manager Journalisation de volumes de transaction pour les systèmes de fichiers de cluster UFS :

Solaris Volume Manager Journalisation de volumes de transaction (anciennement Solstice DiskSuite Journalisation de trans-métapériphériques) doit être supprimée du système 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 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.

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

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.
Nombre de métapériphériques ou de volumes : sous Solstice DiskSuite ou 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, la 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 aux documents “Multihost Disk Storage” in Sun Cluster Overview for Solaris OS et Sun Cluster Concepts Guide for Solaris OS.

Recommandations relatives à la mise en miroir du disque root

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 root et dupliquez les sous-disques générés. Le logiciel Sun Cluster n'impose pas de mise en miroir du disque root.

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

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

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 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.
Périphériques de quorum : n'utilisez pas de disque configuré en tant que périphérique de quorum pour mettre un disque root 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 root doit être mis en miroir sur un contrôleur distinct.
Disque root secondaire : avec un disque root mis en miroir, vous pouvez continuer à travailler à partir du disque root secondaire (miroir) en cas de panne du disque root 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é dans le champ 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 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. Certaines commandes administratives de Solstice DiskSuite ou Solaris Volume Manager peuvent avoir modifié le fichier /etc/system alors que le disque root principal était hors service.

Le programme d'initialisation ne vérifie pas si le système s'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.