Planification de la gestion des volumes

Ajoutez ces informations de planification à la Fiche d'information sur la configuration des groupes de périphériques et à la Fiche d'information sur les configurations 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 section fournit les directives suivantes sur la planification de la gestion des volumes de votre configuration en cluster :

• Directives concernant le gestionnaire de volumes

• Directives concernant le logiciel Solaris Volume Manager

• Directives concernant le logiciel Veritas Volume Manager

• Journalisation de système de fichiers

• Directives concernant la mise en miroir

Le logiciel Oracle Solaris Cluster utilise le gestionnaire de volumes pour regrouper les disques en groupes de périphériques pouvant être gérés comme une seule unité. Le logiciel Oracle Solaris Cluster prend en charge les logiciels Solaris Volume Manager et Veritas Volume Manager (VxVM) que vous installez ou utilisez des façons suivantes.

Tableau 1-4 Utilisation prise en charge des gestionnaires de volumes avec le logiciel Oracle Solaris Cluster

Reportez-vous à la documentation du gestionnaire de volumes et aux sections Configuration du logiciel Solaris Volume Manager ou Installation et configuration du logiciel VxVM pour connaître les instructions d’installation et de configuration du gestionnaire de volumes. Pour plus d’informations sur l’utilisation de la gestion de volumes dans une configuration en cluster, reportez-vous à la section Multihost Devices du Oracle Solaris Cluster Concepts Guide et à la section Device Groups du Oracle Solaris Cluster Concepts Guide.

Directives concernant le gestionnaire de volumes

Prenez en compte les directives suivantes lorsque vous configurez vos disques avec le gestionnaire de volumes :

• RAID logiciel – Le logiciel Oracle Solaris Cluster ne prend pas en charge le RAID logiciel 5.

• Disques multihôtes mis en miroir – Vous devez mettre en miroir tous les disques multihôtes des unités d’expansion de disque. Reportez-vous à la section Directives concernant la mise en miroir des disques multihôtes pour connaître les directives relatives à la mise en miroir des disques multihôtes. Il est inutile de procéder à la mise en miroir des logiciels si le périphérique de stockage fournit un RAID matériel ainsi que des chemins redondants vers les périphériques.

• Racine mise en miroir – La mise en miroir du disque racine assure une haute disponibilité, mais cette mise en miroir n’est pas obligatoire. Reportez-vous à la section Directives concernant la mise en miroir pour déterminer si la mise en miroir du disque racine est utile ou non.

• Attribution d’un nom unique – Il se peut que vous disposiez de volumes locaux Solaris Volume Manager ou VxVM utilisés comme périphériques sur lesquels les systèmes de fichiers /global/.devices/node@nodeid sont montés. Si tel est le cas, le nom de chaque volume local sur lequel un système de fichiers /global/.devices/node@nodeid va être monté doit être unique dans le cluster.

• Listes de nœuds – Pour assurer la haute disponibilité d’un groupe de périphériques, les listes de nœuds maîtres potentiels et la règle de basculement doivent être identiques dans tous les groupes de ressources associés. Ou si un groupe de ressources évolutives utilise davantage de nœuds que son groupe de périphériques associé, faites de la liste de nœuds du groupe de ressources évolutives un surensemble de la liste de nœuds du groupe de périphériques. Pour plus d’informations sur les listes de nœuds, reportez-vous aux informations de planification du groupe de ressources du Oracle Solaris Cluster Data Services Planning and Administration Guide.

• Disques multihôtes – Vous devez connecter tous les périphériques utilisés pour construire un groupe de périphériques à tous les nœuds configurés dans la liste de nœuds pour ce groupe de périphériques. Le logiciel Solaris Volume Manager peut automatiquement vérifier cette connexion au moment où les périphériques sont ajoutés à un ensemble de disques. Cependant, les groupes de disques VxVM configurés ne sont associés à aucun ensemble de nœuds en particulier.

• Disques hot spare – Vous pouvez utiliser des disques hot spare pour augmenter la disponibilité, mais les disques hot spare ne sont pas requis.

Reportez-vous à la documentation du gestionnaire de volumes pour connaître les recommandations sur l’organisation des disques et les éventuelles restrictions supplémentaires.

Directives concernant le logiciel Solaris Volume Manager

Prenez en compte les points suivants lorsque vous planifiez les configurations Solaris Volume Manager :

• Nom de volume local – Le nom de chaque volume local Solaris Volume Manager sur lequel un système de fichiers de périphériques globaux, /global/.devices/node@nodeid, est monté, doit être unique au sein du cluster. De plus, ce nom ne peut pas être identique à l’ID d’un périphérique.

• Médiateurs à deux chaînes – Une chaîne de disques se compose d’un boîtier de disques, de ses disques physiques, des câbles reliant le boîtier aux hôtes et d'adaptateurs d’interface. Chaque ensemble de disques configuré avec exactement deux chaînes de disque et géré par exactement deux hôtes Solaris s'appelle un ensemble de disques à deux chaînes. Un tel ensemble de disques doit contenir des médiateurs à deux chaînes Solaris Volume Manager configurés. Pour configurer des médiateurs à deux chaînes, observez les règles suivantes :

  • Vous devez configurer chaque ensemble de disques sur deux ou trois hôtes agissant comme hôtes médiateurs.

  • Vous devez utiliser les hôtes pouvant gérer un ensemble de disques en tant que des médiateurs pour cet ensemble de disques. Si vous disposez d'un cluster campus, vous pouvez également configurer un troisième nœud ou un nœud non clusterisé sur le réseau du cluster sous la forme d'une troisième hôte médiateur pour améliorer la disponibilité.

  • Les médiateurs ne peuvent pas être configurés pour des ensembles de disques ne remplissant pas les conditions requises (deux chaînes et deux hôtes).

  Pour plus d’informations, reportez-vous à la page de manuel mediator(7D).

Directives concernant le logiciel Veritas Volume Manager

Prenez en compte les points suivants lorsque vous planifiez les configurations Veritas Volume Manager (VxVM).

• Accès à tous les nœuds – Vous devez configurer tous les groupes de disques du gestionnaire de volumes soit en tant que groupes de périphériques Oracle Solaris Cluster, soit en tant que groupes de disques locaux. Si vous ne configurez pas le groupe de disques de l’une de ces façons, les périphériques du groupe de disques ne seront accessibles pour aucun nœud du cluster.

  • Un groupe de périphériques active un nœud secondaire pour héberger des disques multihôtes si le nœud principal échoue.

  • Le groupe de disques locaux n’est pas placé sous le contrôle du logiciel Oracle Solaris Cluster et est accessible à partir d’un seul nœud à la fois.

• Nommage basé sur le boîtier – Si vous nommez les périphériques en fonction du boîtier, assurez-vous que vous utilisez des noms de périphériques cohérents sur tous les nœuds de cluster partageant le même stockage. VxVM ne coordonne pas ces noms. L’administrateur doit donc s’assurer que VxVM assigne le même nom aux mêmes périphériques à partir de différents nœuds. L’incohérence des noms n’aura pas d’influence sur le bon fonctionnement du cluster. Cependant, des noms incohérents compliquent grandement la gestion du cluster et augmente sensiblement la possibilité d’erreurs de configuration, menant potentiellement à une perte de données.

• Groupe de disques racine – La création d’un groupe de disques racine est facultative.

  Il est possible de créer un groupe de disques racine sur les disques suivants :

  • Le disque racine, qui doit être encapsulé.

  • Un ou plusieurs disques locaux non racine, que vous pouvez encapsuler ou initialiser.

  • Une combinaison de disques locaux non racine et de disques racine.

  Le groupe de disques racine doit être local par rapport à l’hôte Solaris.

• Groupes de disques racine simples – Les groupes de disques racine simples, qui sont créés sur une tranche unique du disque racine, ne sont pas pris en charge en tant que types de disque avec VxVM dans le logiciel Oracle Solaris Cluster. Il s’agit d’une restriction logicielle VxVM générale.

• Encapsulation – Les disques à encapsuler doivent disposer de deux entrées de tableau de tranches de disque disponibles.

• Nombre de volumes – Estimez le nombre maximal de volumes que tout groupe de périphériques peut utiliser au moment de sa création.

  • Si le nombre de volumes est inférieur à 1000, vous pouvez utiliser la numérotation mineure par défaut.

  • Si le nombre de volumes est supérieur ou égal à 1000, vous devez planifier avec précaution la façon dont les numéros mineurs sont assignés aux volumes du groupe de disques. Les attributions de numéro mineur des groupes de périphériques ne peuvent pas se chevaucher.

• Journal des zones modifiées – L’utilisation du journal des zones modifiées réduit le temps de récupération du volume suite à la panne d’un nœud. L’utilisation d’un DRL risque de réduire la capacité de traitement des E/S.

• Multiacheminement dynamique (DMP) – L’utilisation du multiacheminement dynamique seul pour gérer les multiples chemins d’E/S par hôte Solaris menant vers le stockage partagé n’est pas prise en charge. L’utilisation de DMP est prise en charge uniquement dans les configurations suivantes :

  • Un chemin d’E/S unique par hôte menant au stockage partagé du cluster est configuré.

  • Une solution multiacheminement compatible est utilisée, telle que le logiciel Multiacheminement d'E/S Solaris (MPxIO) ou EMC PowerPath, qui gère plusieurs chemins d’E/S par hôte menant au stockage du cluster partagé.

• ZFS – L’encapsulation du disque racine est incompatible avec le système de fichiers racine ZFS.

Pour plus d’informations, consultez la documentation sur l’installation de VxVM.

Journalisation de système de fichiers

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

• Journalisation UFS Solaris – Pour plus d'informations, reportez-vous à la page de manuel mount_ufs(1M).

• SPARC : journalisation Veritas File System (VxFS) – Pour plus d’informations, reportez-vous à la page de manuel mount_vxfs fournie avec le logiciel VxFS.

Solaris Volume Manager et Veritas Volume Manager prennent en charge les deux types de journalisation de système de fichiers.

Directives concernant la mise en miroir

Cette section fournit les directives suivantes sur la planification de la mise en miroir de votre configuration en cluster :

• Directives concernant la mise en miroir des disques multihôtes

• Directives concernant la mise en miroir du disque racine

Directives concernant la mise en miroir des disques multihôtes

La mise en miroir de tous les disques multihôtes dans une configuration Oracle Solaris Cluster permet à la configuration de tolérer les pannes de périphérique. Le logiciel Oracle Solaris Cluster requiert la mise en miroir de tous les disques multihôtes des unités d’expansion. Il est inutile de procéder à la mise en miroir des logiciels si le périphérique de stockage fournit un RAID matériel ainsi que des chemins redondants vers les périphériques.

Considérez les points suivants lorsque vous mettez en miroir des disques multihôtes :

• Unités d’expansion de disque séparées – Chaque sous-miroir d’un miroir ou plex donné doit résider sur une unité d’expansion multihôte différente.

• Espace disque – La mise en miroir double la quantité d’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, Oracle Solaris Cluster ne nécessite qu’une mise en miroir à deux voies.

• Tailles de périphérique différentes – Si vous placez la copie miroir sur un périphérique de taille différente, votre capacité de mise en miroir est limitée à la taille du sous-miroir ou du plex le plus petit.

Pour plus d'informations sur les disques multihôtes, reportez-vous à la section Multihost Devices du Oracle Solaris Cluster Concepts Guide.

Directives concernant la mise en miroir du disque racine

Ajoutez ces informations de planification à la Fiche d'information sur la disposition du système de fichiers local.

Pour une disponibilité maximale, mettez en miroir la racine (/), /usr, /var, /opt et swap sur les disques locaux. Sous VxVM, vous encapsulez le disque racine et mettez en miroir les sous-disques générés. Cependant, le logiciel Oracle Solaris Cluster ne requiert pas la mise en miroir du disque racine.

Avant de décider de mettre le disque racine en miroir ou non, prenez en compte les risques, la complexité, le coût et le temps de service pour les différents alternatives concernant le disque racine. Aucune stratégie de mise en miroir ne fonctionne pour toutes les configurations. Au moment de décider d’effectuer ou non la mise en miroir de la racine, vous pouvez également prendre en compte la solution préférée du représentant local d'Oracle.

Reportez-vous à la documentation du gestionnaire de volumes et aux sections Configuration du logiciel Solaris Volume Manager ou Installation et configuration du logiciel VxVM pour des instructions sur la mise en miroir du disque racine.

Considérez les points suivants lorsque vous décidez de mettre en miroir le disque racine.

• Disque d’initialisation – Vous pouvez configurer le miroir en tant que disque racine initialisable. Vous pouvez ensuite effectuer une initialisation à partir du miroir si le disque d’initialisation principal tombe en panne.

• Complexité – La mise en miroir du disque racine rend la gestion du système plus complexe. La mise en miroir du disque racine complique également l’initialisation en mode monoutilisateur.

• Sauvegardes – Que vous ayez mis en miroir le disque racine ou non, il est recommandé d’effectuer des sauvegardes régulières de la racine. La mise en miroir seule ne protège pas des erreurs de gestion. Seul un plan de sauvegarde vous permet de restaurer des fichiers qui ont été modifiés ou supprimés accidentellement.

• Périphériques de quorum – Pour mettre en miroir un disque racine, n’utilisez pas un disque configuré en tant que périphérique de quorum.

• Quorum – Dans Solaris Volume Manager, dans les scénarios de panne dans lesquels le quorum de la base de données d’état est perdu, il est impossible de réinitialiser le système jusqu’à ce que des opérations de maintenance soient effectuées. Reportez-vous à la documentation de Solaris Volume Manager pour plus d’informations sur la base de données d’état et ses répliques.

• Contrôleurs séparés – La plus haute disponibilité inclut la mise en miroir du disque racine sur un contrôleur séparé.

• Disque racine secondaire – Avec un disque racine mis en miroir, le disque racine principal peut échouer mais le travail peut continuer sur le disque d’initialisation secondaire (miroir). Par la suite, le disque racine principal peut reprendre son activité, par exemple après une mise sous tension progressive ou des erreurs d’E/S transitoires. Les initialisations ultérieures sont alors effectuées par le biais du disque racine principal spécifié pour le paramètre eeprom(1M) boot-device. Dans cette situation, aucune tâche de réparation manuelle n’est effectuée, mais l’unité de disque commence à fonctionner suffisamment bien pour permettre la réinitialisation. Avec Solaris Volume Manager, une resynchronisation s’effectue. La resynchronisation requiert une intervention manuelle lorsque l’unité de disque se met à fonctionner de nouveau.

  Si des modifications ont été effectuées dans un fichier sur le disque racine secondaire (miroir), elles ne seront pas reflétées sur le disque racine principale au moment de l’initialisation. Cette condition génèrerait un sous-miroir obsolète. Par exemple, les modifications apportées au fichier /etc/system serait perdues. Avec Solaris Volume Manager, certaines commandes d’administration peuvent avoir modifié le fichier /etc/system lorsque le disque racine principal était hors service.

  Le programme d’initialisation ne vérifie pas que le système s’initialise à partir d’un miroir ou d’un périphérique miroir sous-jacent. La mise en miroir devient active au milieu du processus d’initialisation, une fois les volumes chargés. Avant cela, le système est vulnérable aux problèmes de sous-miroir obsolète.