Planification de la gestion des volumes

Cette section fournit les directives suivantes sur la planification de la gestion des volumes de votre configuration en cluster :

• Directives relatives au gestionnaire de volumes

• Directives relatives au logiciel Solaris Volume Manager

• Journalisation des systèmes de fichiers

• Directives concernant la mise en miroir

Le logiciel Oracle Solaris Cluster utilise le gestionnaire de volumes pour réunir les disques dans des groupes de périphériques qui peuvent par la suite être gérés comme une seule unité. Oracle Solaris Cluster prend en charge le logiciel Solaris Volume Manager. Vous devez installer le logiciel Solaris Volume Manager sur tous les noeuds votant du cluster.

Consultez la documentation de votre gestionnaire de volumes et la section Configuration du logiciel Solaris Volume Manager pour des instructions relatives à l'installation et à la configuration du gestionnaire de volumes. Pour plus d'informations sur le recours à la gestion des volumes dans une configuration de cluster, reportez-vous aux sections Multihost Devices du manuel Oracle Solaris Cluster Concepts Guide et Device Groups du manuel Oracle Solaris Cluster Concepts Guide.

Directives relatives au gestionnaire de volumes

Tenez compte des directives générales suivantes lorsque vous configurez vos disques à l'aide du gestionnaire de volumes :

• RAID logiciel – Le logiciel Oracle Solaris Cluster ne prend pas en charge le RAID 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.

• Disque root mis en miroir – La mise en miroir du disque root assure la haute disponibilité, mais cette mise en miroir n'est pas obligatoire. Reportez-vous à la section Directives concernant la mise en miroir pour obtenir des directives sur le choix de mise en miroir du disque root.

• Nommage unique – Vous pouvez disposer de volumes Solaris Volume Manager locaux 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 il faut monter un système de fichiers /global/@ nodeid doit être unique dans tout le cluster.

• Listes de noeuds – Pour assurer la haute disponibilité d'un groupe de périphériques, les listes de noeuds 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 noeuds que son groupe de périphériques associé, faites de la liste de noeuds du groupe de ressources évolutives un surensemble de la liste de noeuds du groupe de périphériques. Pour plus d'informations sur les listes de noeuds, 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 ou insérer tous les périphériques utilisés dans la construction d'un groupe de périphériques dans tous les noeuds configurés dans la liste des noeuds de ce groupe de périphériques. Le logiciel Solaris Volume Manager peut rechercher cette connexion automatiquement au moment où les périphériques sont ajoutés à un ensemble de disques.

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

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 relatives au logiciel Solaris Volume Manager

Tenez compte des points suivants lorsque vous planifiez les configurations Solaris Volume Manager :

• Noms de volumes locaux – Le nom de chaque volume Solaris Volume Manager local sur lequel est monté un système de fichiers de périphériques globaux (/global/.devices/node@nodeid) doit être unique dans tout le cluster. En outre, le nom ne peut en aucun cas ê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 disques et géré par exactement deux hôtes Oracle Solaris s'appelle un ensemble de disques à deux chaînes. Des médiateurs à deux chaînes Solaris Volume Manager doivent être configurés sur un tel ensemble de disques. 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 noeud ou un noeud 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).

Journalisation des systèmes de fichiers

La journalisation est requise pour les systèmes de fichiers de cluster UFS. Le logiciel Oracle Solaris Cluster prend en charge la journalisation UFS Oracle Solaris.Reportez-vous à la page de manuel mount_ufs(1M) pour plus d'informations.

Solaris Volume Manager prend en charge les deux types de journalisation des systèmes 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 relatives à la mise en miroir du disque root

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 sur des périphériques isolés. Le logiciel Oracle Solaris Cluster requiert la mise en miroir de tous les disques multihôtes dans les 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 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 – Le logiciel Solaris Volume Manager prend 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 plus petit sous-miroir.

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

Directives relatives à la mise en miroir du disque root

Pour une disponibilité maximale, mettez en miroir le root (/), /usr , /var, /opt et swap sur les disques locaux. Toutefois, le logiciel Oracle Solaris Cluster ne requiert pas la mise en miroir du disque root.

Avant de choisir de mettre en miroir ou non le disque root, tenez compte des risques, de la complexité, du coût et de la durée de service pour les autres possibilités concernant le disque root. Aucune stratégie de mise en miroir ne fonctionne pour toutes les configurations. Vous pouvez être amené à prendre en compte la solution de votre représentant de services Oracle local lorsque vous décidez de la mise en miroir du disque root.

Reportez-vous à la documentation de votre gestionnaire de volumes et à la section Configuration du logiciel Solaris Volume Manager pour obtenir des instructions sur la mise de miroir du disque root.

Tenez compte des points suivants lorsque vous prenez la décision de mettre en miroir ou non le disque root.

• Disque d'initialisation – Vous pouvez configurer le miroir en tant que disque root amorçable. 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 root rend l'administration du système plus complexe. Elle complique également l'initialisation en mode monoutilisateur.

• Sauvegardes – Que vous ayez mis en miroir le disque root ou non, il est recommandé d'effectuer des sauvegardes régulières du root. 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 – N'utilisez pas un disque configuré en tant que périphérique de quorum pour mettre en miroir un disque root.

• Quorum – Dans le logiciel Solaris Volume Manager, en cas de scénarios de panne impliquant la perte du quorum de base de données d'état, vous ne pouvez pas réinitialiser le système tant qu'une maintenance n'a pas été effectuée. Reportez-vous à la documentation 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é implique la mise en miroir du disque root sur un contrôleur séparé.

• Disque root secondaire – Avec un disque root secondaire mis en miroir, si le disque root principal subit une défaillance, le travail peut continuer sur le disque root (miroir) secondaire. Plus tard, le disque root principal peut reprendre son activité normale, après un arrêt suivi d'un redémarrage ou après des erreurs d'E/S transitoires par exemple. Des initialisations ultérieures sont effectuées à l'aide du disque root principal spécifié pour le paramètre eeprom(1M) boot-device. Dans ce cas, aucune tâche de réparation manuelle n'a lieu, mais l'unité de disque commence à fonctionner, ce qui est suffisant pour une initialisation. Avec le logiciel Solaris Volume Manager, une resynchronisation se produit. Une resynchronisation requiert une étape manuelle lorsque l'unité de disque est remise en service.

  Si des modifications ont été apportées à des fichiers sur le disque root (miroir) secondaire, elles ne sont pas répercutées sur le disque root principal au cours de l'initialisation. Cette condition entraînerait la péremption du sous-miroir. Par exemple, les modifications apportées au fichier /etc/system seraient perdues. Avec le logiciel Solaris Volume Manager, certaines commandes d'administration peuvent avoir modifié le fichier /etc/system lorsque le disque root principal était hors service.

  Le programme d'initialisation ne vérifie pas si le système est en cours d'initialisation à partir d'un miroir ou d'un périphérique physique sous-jacent. La mise en miroir devient active à mi-chemin du processus d'initialisation, après le chargement des volumes. Avant ce stade, le système est par conséquent vulnérable à des problèmes liés aux sous-miroirs obsolètes.