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 de travail relative aux volumes (Solaris Volume Manager).
Cette rubrique donne les recommandations suivantes sur la planification de la gestion de volume de la configuration de votre cluster :
Recommandations relatives au logiciel de gestion des volumes
Recommandations relatives au logiciel Solaris Volume Manager
Recommandations relatives au logiciel VERITAS Volume Manager
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. |
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. |
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 un environnement de cluster, reportez-vous à la rubrique Multihost Devices du Sun Cluster Concepts Guide for Solaris OS et à la rubrique Device Groups du Sun Cluster Concepts Guide for Solaris OS.
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, 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 noms uniques – vous pouvez disposer de de Solaris Volume Manager ou de 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 utilisé pour monter un système de fichiers /global/.devices/node@nodeid doit être unique sur le cluster.
Listes de noeuds : pour être à haute disponibilité, un groupe d'unités de disque doit avoir des listes de maîtres potentiels et une stratégie de repli en cas de pannes identiques à 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 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 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.
Tenez compte des points suivants lorsque vous planifiez des configurations Solaris Volume Manager.
Noms de volumes : le nom de chaque volume Solaris Volume Manager sur lequel un système de fichiers de périphériques globaux, /global/.devices/node@nodeid, est monté doit être unique sur l'ensemble du 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 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 : SPARC : Sous le SE Solaris 9, 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.
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 Sun Cluster sur le SE Solaris 9:
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 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 de md_nsets 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 plus haute valeur des noms de volumes utilisée par les 15 premiers jeux de disques d'un cluster est 10, alors que la plus haute valeur du volume du seizième jeu de disques est 1 000, définissez nmd sur au moins 1 000. 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 volume local est unique dans tout le cluster.
La valeur maximale de noms de volumes 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 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 volumes que vous utiliserez.
Reportez-vous au chapitre System Files and Startup Files du Solaris Volume Manager Administration Guide (Solaris 9 ou Solaris 10) pour plus d'informations sur le fichier md.conf.
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édant 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 racine : 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 : les groupes de disques racine simples (rootdg créé sur une seule tranche du disque racine) 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 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.
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 (DMP) : 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 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.
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 plus d'informations, reportez-vous à la page de manuel mount_ufs(1M).
(Solaris 9 uniquement) SPARC : Solaris Volume Manager Journalisation de volumes de transaction – Reportez-vous au chapitre Transactional Volumes (Overview)) du Solaris Volume Manager Administration Guide pour plus d'informations.
Solaris Volume Manager Journalisation de volumes de transaction est supprimé du SE Solaris 10. 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.
Journalisation SPARC : VERITAS File System (VxFS) ‐ : pour plus d'informations, reportez-vous à la page de manuel 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–5 Tableau des journalisations de système de fichiers prises en charge
SPARC : Sous Solaris 9, tenez compte des points suivants lors du choix entre Journalisation UFS Solaris et Solaris Volume Manager Journalisation de volumes de transaction pour des systèmes de fichiers de cluster 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.
Un volume transactionnel gère la journalisation UFS. Le périphérique de journalisation d'un volume transactionnel est un volume que vous pouvez mettre en miroir et en bandes. 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.
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
Recommandations relatives à la mise en miroir du disque racine
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 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 Multihost Disk Storage du Sun Cluster Overview for Solaris OS et au Sun Cluster Concepts Guide for Solaris OS.
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 root 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 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 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 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 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 volumes sont chargés. Avant ce point, le système est vulnérable face aux problèmes d'obsolescence des sous-miroirs.