Planification de la configuration d'Oracle Solaris Cluster. Oracle Solaris Cluster 3.3
1
1
Planification de la configuration d'Oracle
Solaris Cluster
Ce chapitre fournit des informations et des directives de planification spécifiques à une configuration Oracle Solaris Cluster 3.3 3/13.
Ce chapitre contient les informations générales suivantes :
■
■
■
■
■
“Recherche des tâches d'installation Oracle Solaris Cluster” à la page 11
“Planification du SE Oracle Solaris” à la page 12
“Planification de l'environnement Oracle Solaris Cluster” à la page 22
“Planification de la gestion des volumes” à la page 49
Recherche des tâches d'installation Oracle Solaris Cluster
Le tableau suivant indique où trouver les instructions des différentes tâches d'installation d'Oracle Solaris Cluster et l'ordre dans lequel ces tâches doivent être effectuées.
TABLEAU 1–1
Informations sur les tâches d'installation du logiciel Oracle Solaris Cluster
Tâche Instructions
Paramétrage du matériel du cluster.
Oracle Solaris Cluster 3.3 3/13 Hardware Administration Manual
Documentation fournie avec vos périphériques de stockage et de serveur
Planification de l'installation du logiciel du cluster global.
Chapitre 1, “Planification de la configuration d'Oracle Solaris
Installation des packages logiciels. Installation et configuration du logiciel Sun QFS (facultatif).
“Installation du logiciel” à la page 55
Utilisation de Sun QFS et Sun Storage Archive Manager avec
Oracle Solaris Cluster
11
Planification du SE Oracle Solaris
TABLEAU 1–1
Tâche
Informations sur les tâches d'installation du logiciel Oracle Solaris Cluster
Instructions
(Suite)
Etablissement d'un nouveau cluster global ou d'un nouveau noeud de cluster global.
Configuration du logiciel Solaris Volume Manager.
“Etablissement d'un nouveau cluster global ou d'un nouveau noeud de cluster global” à la page 80
“Configuration du logiciel Solaris Volume Manager” à la page 165
Solaris Volume Manager Administration Guide
Configuration des systèmes de fichiers de cluster, le cas échéant.
“Création de systèmes de fichiers de cluster” à la page 193
(Facultatif) Création de zones non globales.
“Configuration d'une zone non globale sur un noeud de cluster global” à la page 211
(Facultatif) Création de clusters de zones.
Planification, installation et configuration des groupes de ressources et des services de données. Création de systèmes de fichiers locaux hautement disponibles, le cas échéant.
Développement de services de données personnalisés.
“Configuration d'un cluster de zones” à la page 217
Oracle Solaris Cluster Data Services Planning and Administration
Guide
Oracle Solaris Cluster Data Services Developer’s Guide
Planification du SE Oracle Solaris
Cette section contient les instructions suivantes concernant la planification de l'installation du logiciel Oracle Solaris dans une configuration en cluster :
■
■
■
■
■
■
“Directives concernant la sélection d'une méthode d'installation d'Oracle Solaris”
“Restrictions concernant les fonctions du SE Oracle Solaris” à la page 13
“Considérations relatives aux groupes de logiciels Oracle Solaris” à la page 14
“Partitions de disque système” à la page 15
“Directives pour les zones non globales d'un cluster global” à la page 19
“Directives SPARC : pour Oracle VM Server for SPARC dans un cluster” à la page 20 .
Pour plus d'informations sur le logiciel Oracle Solaris, reportez-vous à la documentation sur l'installation d'Oracle Solaris.
12
Directives concernant la sélection d'une méthode d'installation d'Oracle Solaris
Vous pouvez installer le logiciel Oracle Solaris à partir d'un DVD-ROM local ou d'un serveur d'installation réseau à l'aide de la méthode d'installation JumpStart d'Oracle Solaris. De plus, le logiciel Oracle Solaris Cluster offre une méthode personnalisée pour installer à la fois le SE
Oracle Solaris et le logiciel Oracle Solaris Cluster à l'aide de la méthode d'installation JumpStart.
Si vous installez plusieurs noeuds de cluster, envisagez une installation en réseau.
Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification du SE Oracle Solaris
Pour plus d'informations sur la méthode d'installation JumpStart scinstall, reportez-vous à la section
“Installation et configuration d'Oracle Solaris et du logiciel Oracle Solaris Cluster
(JumpStart)” à la page 100 . Reportez-vous à la documentation d'installation Oracle Solaris pour
plus d'informations sur les méthodes d'installation Oracle Solaris standard.
Restrictions concernant les fonctions du SE
Oracle Solaris
Prenez en compte les points suivants si vous prévoyez d'utiliser le SE Solaris dans une configuration Oracle Solaris Cluster :
■
■
Zones Oracle Solaris
– Installez le logiciel de structure Oracle Solaris Cluster uniquement dans la zone globale.
Pour déterminer si vous pouvez installer un service de données Oracle Solaris Cluster directement dans une zone non globale, reportez-vous à la documentation de ce service de données.
Si vous configurez des zones non globales sur un noeud de cluster global, le système de fichiers loopback (LOFS) doit être activé. Reportez-vous aux informations relatives au LOFS pour obtenir des considérations supplémentaires.
Système de fichiers loopback (LOFS)
– Au cours de la création d'un cluster, la fonction
LOFS est désactivée par défaut. Si le cluster respecte les conditions suivantes, vous devez désactiver la fonction LOFS afin d'éviter entre autres les problèmes de commutation :
■
■
Oracle Solaris Cluster HA pour NFS (HA pour NFS) est configuré sur un système de fichiers locaux hautement disponible.
Le démon automountd est en cours d'exécution.
Si le cluster respecte au moins l'une de ces conditions, vous pouvez activer LOFS en toute sécurité.
■
■
Si vous avez besoin que le système LOFS et le démon automountd soient tous les deux activés, excluez de la carte de l'agent de montage automatique tous les fichiers faisant partie du système de fichiers local hautement disponible exporté par HA pour NFS.
Arrêt pour économie d'énergie
– L'arrêt automatique pour économie d'énergie n'est pas pris en charge dans les configurations Oracle Solaris Cluster et ne doit pas être activé. Pour plus d'informations, reportez-vous aux pages de manuel pmconfig
(1M) et power.conf
(4) .
Fonction IP Filter
– Le logiciel Oracle Solaris Cluster ne prend pas en charge Oracle Solaris
IP Filter pour les services évolutifs, mais uniquement pour les services de basculement.
Respectez les directives et restrictions suivantes lorsque vous configurez Oracle Solaris IP
Filter dans un cluster :
■
Le routage NAT n'est pas pris en charge.
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 13
Planification du SE Oracle Solaris
■
■
■
■
L'utilisation de NAT pour la traduction d'adresses locales est prise en charge. Dans la mesure où la traduction NAT réécrit les paquets sur le réseau, elle n'a aucune incidence sur le logiciel du cluster.
Les règles de filtrage avec état ne sont pas prises en charge seul le filtrage sans état est pris en charge. Oracle Solaris Cluster repose sur Multipathing sur réseau IP (IPMP) pour la surveillance des réseaux publics, qui ne fonctionne pas avec des règles de filtrage avec
état.
fssnap
– Le logiciel Oracle Solaris Cluster ne prend pas en charge la commande fssnap, qui est une fonction d'UFS. Cependant, vous pouvez utiliser la commande fssnap sur les systèmes locaux qui ne sont pas contrôlés par le logiciel Oracle Solaris Cluster. Les restrictions suivantes s'appliquent à la prise en charge de fssnap :
■
■
La commande fssnap est prise en charge sur les systèmes de fichiers locaux non gérés par le logiciel Oracle Solaris Cluster.
La commande fssnap n'est pas prise en charge sur les systèmes de fichiers de cluster.
La commande fssnap n'est pas prise en charge sur les systèmes de fichiers locaux sous le contrôle de HAStoragePlus.
14
Considérations relatives aux groupes de logiciels
Oracle Solaris
Le logiciel Oracle Solaris Cluster 3.3 3/13 nécessite au minimum le groupe de logiciels Oracle
Solaris Utilisateur final (SUNWCuser). Toutefois, d'autres composants de la configuration du cluster peuvent avoir leurs propres besoins en matière de logiciels Oracle Solaris. Tenez compte des informations suivantes lorsque vous déterminez le groupe de logiciels Oracle Solaris que vous installez.
■
■
Serveurs
– Vérifiez si la documentation de votre serveur répertorie des exigences en matière de configuration Oracle Solaris.
Packages Oracle Solaris supplémentaires
– Il peut s'avérer nécessaire d'installer d'autres packages logiciels Oracle Solaris qui ne font pas partie du groupe de logiciels Oracle Solaris
Utilisateur final. Le serveur HTTP Apache et le logiciel Trusted Extensions sont deux exemples qui nécessitent des packages figurant dans un groupe de logiciels supérieur au groupe Utilisateur final. Les logiciels tiers peuvent également nécessiter des packages logiciels Oracle Solaris supplémentaires. Reportez-vous à la documentation des produits tiers pour savoir si elle contient une configuration requise Oracle Solaris.
Astuce –
Pour éviter d'avoir à installer manuellement les packages logiciels Oracle Solaris, installez le groupe de logiciels Oracle Solaris complet plus support OEM.
Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification du SE Oracle Solaris
■
Minimisation de package Oracle Solaris
– Reportez-vous à l'article 1544605.1 “Solaris
Cluster and Solaris OS Minimization Support Required Packages Group” à l'adresse
(http://support.oracle.com) pour plus d'informations.
Partitions de disque système
Lorsque vous installez le SE Solaris, assurez-vous que vous créez les partitions Oracle Solaris
Cluster requises et que celles-ci disposent toutes de l'espace minimal requis.
■
swap
– La quantité totale d'espace de swap allouée à Oracle Solaris et au logiciel Oracle
Solaris Cluster ne doit pas être inférieure à 750 Mo. Pour des résultats optimisés, ajoutez au moins 512 Mo pour le logiciel Oracle Solaris Cluster à la quantité requise par le SE Oracle
Solaris. De plus, allouez la quantité de swap supplémentaire requise par les applications exécutées sur l'hôte Oracle Solaris.
Remarque –
Si vous créez un fichier swap supplémentaire, ne créez pas le fichier swap sur un périphérique global. Utilisez uniquement un disque local en tant que périphérique swap pour l'hôte.
■
■
(Facultatif) /globaldevices – Par défaut, un périphérique lofi est utilisé pour l'espace de noms des périphériques globaux. Toutefois, vous pouvez également créer un système de fichiers dont la taille est au moins égale à 512 Mo et qui sera exécuté par l'utilitaire scinstall pour les périphériques globaux. Il faut nommer ce système de fichiers
/globaldevices
.
Les fonctionnalités et les performances sont équivalentes pour ces deux options. Toutefois, un périphérique lofi s'utilise beaucoup plus facilement et offre davantage de flexibilité lorsqu'une partition de disque n'est pas disponible.
Gestionnaire de volumes
– Créez une partition de 20 Mo sur la tranche 7 pour le gestionnaire de volumes.
Pour remplir ces conditions, vous devez personnaliser le partitionnement si vous effectuez une installation interactive du SE Oracle Solaris.
Pour plus d'informations sur la planification de partitions, reportez-vous aux directives suivantes :
■
■
■
“Directives relatives au système de fichiers root (/)” à la page 16
“Directives pour le système de fichiers /globaldevices ” à la page 16
“Configuration requise pour le gestionnaire de volumes” à la page 17
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 15
Planification du SE Oracle Solaris
Directives relatives au système de fichiers root (/)
Comme avec n'importe quel autre système exécutant le SE Oracle Solaris, vous pouvez configurer les répertoires root (/), /var, /usr et /opt en tant que systèmes de fichiers distincts.
Vous pouvez également inclure tous les répertoires dans le système de fichiers root (/).
La section suivante décrit le contenu logiciel des répertoires root ( /), /var, /usr et /opt dans une configuration Oracle Solaris Cluster. Tentez compte des informations suivantes lorsque vous planifiez votre schéma de partitionnement.
■
■
■
■ root (/) – Le logiciel Oracle Solaris Cluster lui-même occupe moins de 40 Mo d'espace dans le système de fichiers root ( /). Le logiciel Solaris Volume Manager nécessite moins de 5 Mo.
Pour configurer un espace supplémentaire et une capacité inode importants, ajoutez au moins 100 Mo à l'espace que vous alloueriez normalement à votre système de fichiers root
(/). Cet espace est utilisé pour la création de périphériques spéciaux en mode bloc et en mode caractère, utilisés par le logiciel de gestion des volumes. Vous devez allouer cet espace supplémentaire en particulier si le cluster contient un grand nombre de disques partagés.
Sur le SE Oracle Solaris 10, le périphérique lofi nécessite 100 Mo pour l'espace de noms des périphériques globaux.
/var
– Le logiciel Oracle Solaris Cluster occupe une faible quantité d'espace dans le système de fichiers /var lors de l'installation. Cependant, vous devez conserver un espace de disque important pour les fichiers journaux. De plus, davantage de messages peuvent être journalisés sur un noeud en cluster que sur un serveur autonome standard. Allouez au moins 100 Mo au système de fichiers /var.
/usr
– Le logiciel Oracle Solaris Cluster occupe moins de 25 Mo d'espace dans le système de fichiers /usr. Le logiciel Solaris Volume Manager requiert moins de 15 Mo.
/opt
– Le logiciel de structure Oracle Solaris Cluster occupe moins de 2 Mo dans le système de fichiers /opt. Cependant, chaque service de données Oracle Solaris Cluster peut utiliser entre 1 et 5 Mo. Le logiciel Solaris Volume Manager ne consomme aucun espace dans le système de fichiers /opt.
En outre, la plupart des logiciels d'applications et de bases de données sont installés dans le système de fichiers /opt.
16
■
■
Directives pour le système de fichiers /globaldevices
Le logiciel Oracle Solaris Cluster propose deux choix d'emplacements pour héberger l'espace de noms de périphériques globaux :
Périphérique lofi (valeur par défaut)
Système de fichiers dédié sur l'un des disques locaux
Lorsque vous utilisez un périphérique lofi pour l'espace de noms de périphériques globaux, vous devez respecter les exigences suivantes :
Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification du SE Oracle Solaris
■
■
■
Utilisation dédiée
– Le périphérique lofi qui héberge l'espace de noms de périphériques globaux ne peut être utilisé à aucune autre fin. Si vous avez besoin d'un périphérique lofi pour une autre utilisation, créez un nouveau périphérique lofi à cet effet.
Exigences en matière de montage
– Le périphérique lofi ne doit pas être démonté.
Identification de l'espace de noms
– Après la configuration du cluster, vous pouvez exécuter la commande lofiadm pour identifier le périphérique lofi correspondant à l'espace de noms des périphériques globaux /.globaldevices.
En revanche, si vous configurez un système de fichiers /globaldevices dédié pour l'espace de noms de périphériques globaux, respectez les directives et les exigences suivantes :
■
■
■
■
Emplacement
- Le système de fichiers /globaldevices se situe généralement sur votre disque root. Toutefois, si vous utilisez un emplacement de stockage différent sur lequel localiser le système de fichiers de périphériques globaux, tel qu'un volume du gestionnaire de volumes logiques, il ne doit pas faire partie d'un ensemble de disques partagés Solaris
Volume Manager. Ce système de fichiers est monté ultérieurement en tant que système de fichiers de cluster UFS. Nommez ce système de fichiers /globaldevices (nom par défaut reconnu par la commande scinstall
(1M) ).
Type de système de fichiers requis
- Aucun type de système de fichiers différent de UFS n'est valide pour le système de fichiers de périphériques globaux. N'essayez pas de modifier le type de système de fichiers après la création du système de fichiers de périphériques globaux.
Cependant, un système de fichiers de périphériques globaux UFS peut coexister sur un noeud avec d'autres systèmes de fichiers root qui utilisent ZFS.
Nom de l'espace de noms configuré
- La commande scinstall renomme ensuite le système de fichiers /global/.devices/node@nodeid, où nodeid représente le numéro attribué à un hôte Oracle Solaris quand il devient membre du cluster global. Le point de montage /globaldevices d'origine est supprimé.
Espace requis
- Le système de fichiers /globaldevices doit disposer d'un espace conséquent et d'une capacité inode importante pour la création de périphériques spéciaux en mode bloc et en mode caractère. Cette directive est particulièrement importante si un grand nombre de disques figurent dans le cluster. Créez un système de fichiers dont la taille est au moins égale à 512 Mo et dont la densité est égale à 512, comme suit :
# newfs -i 512
globaldevices-partition
Ce nombre d'inodes doit suffire pour la plupart des configurations en cluster.
Configuration requise pour le gestionnaire de volumes
Pour le logiciel Solaris Volume Manager, vous devez réserver une tranche sur le disque root pour la création de la réplique de base de données d'état. Réservez notamment une tranche à cet usage sur chaque disque local. Cependant, si vous disposez uniquement d'un disque local sur un hôte Oracle Solaris, il vous faudra peut-être créer trois répliques de base de données d'état dans
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 17
Planification du SE Oracle Solaris la même tranche pour assurer le bon fonctionnement du logiciel Solaris Volume Manager. Pour plus d'informations, consultez la documentation de votre logiciel Solaris Volume Manager.
Exemple - Allocation au sein d'un système de fichiers
Le
illustre un schéma de partitionnement pour un hôte Oracle Solaris d'une capacité inférieure à 750 Mo de mémoire physique. Il faut installer ce schéma avec le groupe de logiciels Oracle Solaris Utilisateur final, le logiciel Oracle Solaris Cluster et le service de données
Oracle Solaris Cluster HA pour NFS. Une faible quantité d'espace est allouée à la dernière tranche du disque (7), destinée au gestionnaire de volumes.
Si vous disposez d'un périphérique lofi pour l'espace de noms de périphériques globaux, vous pouvez utiliser la tranche 3 dans un autre but ou ajouter une étiquette pour signaler qu'elle est disponible.
Le logiciel Solaris Volume Manager permet d'utiliser la tranche 7 pour la réplique de base de données d'état. Cette organisation offre les deux tranches libres nécessaires (4 et 7) et de l'espace libre à la fin du disque.
TABLEAU 1–2
Exemple d'allocation au sein d'un système de fichiers
Tranche
0
1
4
5
6
7
2
3
Contenu
/ swap overlap
/globaldevices aucun aucun aucun gestionnaire de volumes
Allocation (taille)
6.75GB
1GB
8.43GB
512MB
-
-
-
20MB
Description
Espace libre restant sur le disque après l'allocation d'espace aux tranches 1 à 7.
Utilisée pour le SE Oracle Solaris, le logiciel Oracle Solaris Cluster, le logiciel de service de données, le gestionnaire de volumes, les systèmes de fichiers root, la base de données et les logiciels d'application.
512 Mo pour le SE Oracle Solaris.
512 Mo pour le logiciel Oracle Solaris Cluster.
L'ensemble du disque.
Le logiciel Oracle Solaris Cluster affecte ultérieurement à cette tranche un autre point de montage et monte la tranche en tant que le système de fichiers de cluster. Si vous choisissez d'utiliser un périphérique lofi au lieu d'une partition dédiée, laissez la tranche 3 disponible.
-
-
-
Utilisée par le logiciel Solaris Volume Manager pour la réplique de base de données d'état.
18 Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification du SE Oracle Solaris
Directives pour les zones non globales d'un cluster global
Pour plus d'informations sur l'utilisation et les fonctionnalités des zones Oracle Solaris dans un cluster, reportez-vous à la section “Support for Oracle Solaris Zones” du manuel Oracle Solaris
Cluster Concepts Guide
.
Pour obtenir des directives sur la configuration d'un cluster de zones non globales, reportez-vous à la section
“Clusters de zones” à la page 39 .
Tenez compte des points suivants lorsque vous créez une zone non globale Oracle Solaris 10, simplement appelée zone, sur un noeud de cluster global.
■
■
■
■
■
■
■
■
Nom de zone unique
– Le nom de zone doit être unique sur l'hôte Oracle Solaris.
Réutilisation d'un nom de zone sur des noeuds multiples
– Pour simplifier la gestion du cluster, vous pouvez utiliser un même nom pour une zone sur chaque noeud où les groupes de ressources sont destinés à être mis en ligne dans cette zone.
Adresses IP privées
– Ne tentez pas d'utiliser plus d'adresses IP que celles disponibles dans le cluster.
Montages
– N'incluez pas de montages globaux dans les définitions de zone. Incluez uniquement les montages loopback.
Services de basculement
– Dans les clusters à hôtes multiples, le logiciel Oracle Solaris
Cluster vous permet de définir différentes zones sur un même hôte Oracle Solaris dans la liste de noeuds du groupe de ressources de basculement ; toutefois, cette opération est uniquement utile en phase de test. Si un hôte unique contient toutes les zones de la liste des noeuds, le noeud devient un point unique d'échec pour le groupe de ressources. Pour une disponibilité supérieure, les zones faisant partie de la liste de noeuds du groupe de ressources de basculement doivent se trouver sur des hôtes différents.
Dans le cas des clusters à hôte unique, aucun risque fonctionnel n'existe si vous définissez des zones multiples dans la liste de noeuds du groupe de ressources de basculement.
Services évolutifs
– Ne créez pas de zones non globales destinées à être utilisées dans le même service évolutif sur le même hôte Oracle Solaris. Chaque instance du service évolutif doit être exécutée sur un hôte différent.
Systèmes de fichiers de cluster
- Pour les systèmes de fichiers de cluster utilisant UFS, n'ajoutez pas de système de fichiers de cluster directement à une zone non globale à l'aide de la commande zonecfs. A la place, configurez une ressource HAStoragePlus, qui gère le montage du système de fichiers de cluster dans la zone globale et effectue un montage loopback du système de fichiers de cluster dans la zone non globale.
Système de fichiers loopback
– Oracle Solaris Zones requiert l'activation du système de fichiers loopback. Cependant, le service de données Oracle Solaris Cluster HA pour NFS requiert la désactivation du système de fichiers loopback, afin d'éviter d'éventuels problèmes de commutation ou des pannes. Si vous configurez à la fois des zones non globales et Oracle
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 19
Planification du SE Oracle Solaris
■
Solaris Cluster HA pour NFS dans votre cluster, effectuez l'une des actions suivantes afin d'éviter d'éventuels problèmes dans le service de données :
■
■
Désactivez le démon automountd.
Excluez du mappage de l'agent de montage automatique tous les fichiers faisant partie du système de fichiers local hautement disponible exporté par Oracle Solaris Cluster HA pour NFS.
Zones IP exclusives
– Les directives suivantes s'appliquent aux zones non globales à adresse
IP exclusive :
■
Groupes de ressources de noms d'hôtes logiques
– Dans un groupe de ressources contenant une ressource LogicalHostname, si la liste de noeuds contient une zone non globale dont la propriété ip-type est définie sur exclusive, cette même propriété doit
être définie sur exclusive pour toutes les zones de la liste de noeuds. Notez que la propriété ip-type d'une zone globale est toujours définie sur shared ; une zone globale ne peut donc pas coexister dans une liste de noeuds contenant des zones qui présentent la propriété ip-type=exclusive. Cette restriction s'applique uniquement aux versions du SE Oracle Solaris utilisant la propriété ip-type des zones Oracle Solaris.
■
■
■
Groupes IPMP
– Pour tous les adaptateurs de réseau public utilisés pour le trafic de services de données dans la zone non globale, il faut configurer manuellement les groupes IPMP dans tous les fichiers /etc/hostname. adapter de la zone. Ces informations ne sont pas héritées d'une zone globale. Pour obtenir des directives et des instructions relatives à la configuration des groupes IPMP, suivez les procédures décrites dans la Partie V, “IPMP” du manuel Administration d’Oracle Solaris : Services IP .
Dépendance des noms d'hôtes privés
- Les zones IP exclusives ne peuvent pas dépendre des noms d'hôtes privés ni des adresses privées du cluster.
Ressources d'adresses partagées
– Les ressources d'adresses partagées ne peuvent pas utiliser des zones IP exclusives.
20
Directives SPARC : pour Oracle VM Server for SPARC dans un cluster
Tenez compte des points suivants lorsque vous créez un domaine d'E/S ou un domaine invité
Oracle VM Server for SPARC sur une machine en cluster physique pouvant faire office d'hyperviseur SPARC :
■
■
Configuration requise de l'unité logique SCSI
– Le périphérique de stockage partagé virtuel, ou l'arrière-plan du disque virtuel, d'un domaine invité Oracle VM Server for
SPARC doit être une unité logique SCSI entière dans le domaine d'E/S. Vous ne pouvez pas choisir un périphérique virtuel de façon arbitraire.
Séparation
– N'exportez pas une unité logique de stockage vers plusieurs domaines invités sur la même machine physique, à moins que vous ne désactiviez également la séparation pour ce périphérique. Autrement, si deux domaines invités différents sur la même machine
Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification du SE Oracle Solaris
■
■
■
■ sont visibles pour un périphérique, ce dernier est séparé dès que l'un des domaines invités est inaccessible. La séparation du périphérique engendrera une erreur grave au niveau des autres domaines invités tentant d'accéder à ce périphérique.
Isolation du réseau
– Les domaines invités situés sur la même machine physique mais configurés dans différents clusters doivent être isolés les uns des autres sur le réseau. Utilisez l'une des méthodes suivantes :
■
■
Configurez les clusters pour utiliser des interfaces réseau différentes dans le domaine d'E/S du réseau privé.
Utilisez différentes adresses réseau pour chacun des clusters.
Mise en réseau dans des domaines invités
– Les paquets de réseau ayant pour destination ou origine des domaines invités doivent parcourir des domaines de service pour atteindre les pilotes de réseau par le biais de commutateurs virtuels. Les commutateurs virtuels utilisent des threads de noeud s'exécutant en fonction de la priorité système. Les threads du commutateur virtuel doivent pouvoir acquérir les ressources CPU nécessaires pour effectuer des opérations de cluster critiques, y compris les pulsations, l'appartenance, les points de contrôle, etc. La configuration de commutateurs virtuels avec le paramètre mode=sc permet la gestion efficace des paquets de pulsations du cluster. Cependant, la fiabilité des autres opérations critiques de cluster peuvent être améliorées par l'ajout de ressources CPU supplémentaires au domaine de service, par le biais des charges de travail suivantes :
■
Charge d'interruption élevée, due par exemple à des E/S réseau ou disque. En cas de charge extrême, les commutateurs virtuels peuvent empêcher les threads système (y compris les threads de commutateurs virtuels) de s'exécuter pendant une longue période.
■
Les threads en temps réel sont généralement très gourmands en ressources CPU. Les threads en temps réel ont une priorité supérieure aux threads du commutateur virtuel, ce qui peut restreindre les ressources CPU pour les threads de commutateur virtuel durant une longue période.
Stockage non partagé
- Pour le stockage non partagé, comme les images de SE du domaine invité Oracle VM Server for SPARC, vous pouvez utiliser n'importe quel type de périphérique virtuel. Vous pouvez renforcer un tel périphérique virtuel en implémentant par exemple des fichiers et des volumes dans le domaine d'E/S. Néanmoins, ne copiez pas de fichiers et ne clonez pas de volumes dans le domaine d'E/S dans le but de les mapper dans différents domaines invités du même cluster. Une copie ou un clonage de cette nature engendrerait des problèmes car les périphériques virtuels résultants auraient la même identité de périphérique dans différents domaines invités. Créez toujours un nouveau fichier ou périphérique dans le domaine d'E/S, auquel est assigné un ID de périphérique unique, puis mappez le nouveau fichier ou périphérique dans un autre domaine invité.
Exportation de périphériques de stockage à partir de domaines d'E/S
– Si vous configurez un cluster composé de domaines d'E/S Oracle VM Server for SPARC, n'exportez pas ses périphériques de stockage vers d'autres domaines invités exécutant également le logiciel
Oracle Solaris Cluster.
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 21
Planification de l'environnement Oracle Solaris Cluster
■
■
■
Multipathing d'E/S Oracle Solaris
– N'exécutez pas le logiciel de multipathing d'E/S Oracle
Solaris (MPxIO) à partir de domaines invités. Au lieu de cela, exécutez le logiciel de multipathing d'E/S Oracle Solaris dans le domaine d'E/S et exportez-le vers les domaines invités.
Multipathing de disque virtuel
- Ne configurez pas la fonctionnalité multipathing de disque virtuel d'Oracle VM Server for SPARC sur un domaine logique configuré en tant que noeud de cluster.
Plage d'adresses IP d'interconnexion privée
– Le réseau privé est partagé par tous les domaines invités créés sur la même machine physique et il est visible par tous ces domaines.
Avant de spécifier une plage d'adresses IP de réseau privé (destinée à un cluster de domaine invité) à l'utilitaire scinstall, assurez-vous que cette plage n'est pas déjà utilisée par une autre domaine hôte sur la même machine physique.
Pour plus d'informations sur Oracle VM Server for SPARC, reportez-vous au
Logical Domains
(LDoms) 1.0.3 Administration Guide
.
Planification de l'environnement Oracle Solaris Cluster
Cette section fournit des directives sur la planification et la préparation des composants suivants pour l'installation et la configuration du logiciel Oracle Solaris Cluster :
■
■
■
■
■
■
■
■
■
■
■
■
“Octroi de licence” à la page 22
“Patchs logiciels” à la page 23
“Adresses IP du réseau public” à la page 23
“Périphériques d'accès à la console” à la page 24
“Adresses logiques” à la page 24
“Réseaux publics” à la page 25
“Configuration du serveur de quorum” à la page 26
“Directives concernant NFS” à la page 27
“Restrictions de service” à la page 28
“Protocole NTP (protocole d'heure réseau)” à la page 29
“Composants configurables d'Oracle Solaris Cluster” à la page 30
“Clusters de zones” à la page 39
Pour des informations détaillées sur les composants d'Oracle Solaris Cluster, reportez-vous au manuel
Oracle Solaris Cluster Concepts Guide
.
22
Octroi de licence
Assurez-vous que vous disposez de tous les certificats de licence nécessaires avant de commencer l'installation du logiciel. Le logiciel Oracle Solaris Cluster ne requiert aucun certificat de licence mais chaque noeud installé avec le logiciel Oracle Solaris Cluster doit être couvert par le contrat de licence du logiciel Oracle Solaris Cluster.
Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification de l'environnement Oracle Solaris Cluster
Pour connaître les conditions d'octroi de licence du gestionnaire de volumes et des applications, reportez-vous à la documentation sur l'installation de ces produits.
Patchs logiciels
Après l'installation de chaque produit logiciel, vous devez également installer les patchs requis.
Pour assurer le fonctionnement correct du cluster, veillez à maintenir le même niveau de patch sur tous les noeuds du cluster.
■
■
Pour plus d'informations sur les patchs nécessaires, reportez-vous à la section “Patchs et niveaux de microprogramme requis” du manuel Notes de version
d’Oracle Solaris Cluster 3.3 3/13
ou contactez votre fournisseur de services Oracle.
Pour obtenir des directives générales et des procédures pour l'application de patchs, reportez-vous au Chapitre 11, “Application de patchs au logiciel et au microprogramme d’Oracle Solaris Cluster” du manuel Guide d’administration système d’Oracle Solaris Cluster .
Adresses IP du réseau public
Pour plus d'informations sur l'utilisation des réseaux publics par le cluster, reportez-vous à la section “Public Network Adapters and IP Network Multipathing” du manuel Oracle Solaris
Cluster Concepts Guide
.
Il faut configurer un certain nombre d'adresses IP de réseau public pour plusieurs composants
Oracle Solaris Cluster en fonction de la configuration de votre cluster. Chaque hôte Oracle
Solaris de la configuration en cluster doit disposer d'au moins une connexion de réseau public au même ensemble de sous-réseaux publics.
Le tableau suivant répertorie les composants requérant l'attribution d'adresses IP de réseau public. Ajoutez ces adresses IP aux emplacements suivants :
■
■
■
Tout service de noms utilisé
Le fichier local /etc/inet/hosts sur chaque noeud de cluster global, après l'installation du logiciel Oracle Solaris
Le fichier local /etc/inet/hosts sur une zone non globale à adresse IP exclusive
TABLEAU 1–3
Les composants Oracle Solaris Cluster utilisant des adresses IP du réseau public
Composant
Console d'administration
Noeuds de cluster global
Noeuds de cluster de zones
Nombre d'adresses IP nécessaires
1 adresse IP par sous-réseau.
1 adresse IP par noeud et par sous-réseau.
1 adresse IP par noeud et par sous-réseau.
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 23
Planification de l'environnement Oracle Solaris Cluster
24
TABLEAU 1–3
Composant
Les composants Oracle Solaris Cluster utilisant des adresses IP du réseau public
Nombre d'adresses IP nécessaires
1 adresse IP par domaine.
Interface réseau de la console du domaine (Sun Fire
15000)
(Facultatif) Zones non globales
Périphérique d'accès par console
Adresses logiques
1 adresse IP par sous-réseau.
1 adresse IP.
1 adresse IP par ressource d'hôte logique et par sous-réseau.
(Suite)
Pour plus d'informations sur la planification d'adresses IP, reportez-vous au Chapitre 2,
“Planification de votre réseau TCP/IP (tâches)” du manuel Administration d’Oracle Solaris :
Services IP
.
Périphériques d'accès à la console
Vous devez bénéficier d'un accès par console à tous les noeuds de cluster. Si vous installez le logiciel Panneau de contrôle de cluster sur une console d'administration, vous devez indiquer le nom d'hôte et le numéro de port du périphérique d'accès à la console utilisé pour communiquer avec les noeuds de cluster.
■
■
Un concentrateur de terminal assure la communication entre la console d'administration et les consoles des noeuds du cluster global.
Un serveur Sun Fire utilise un contrôleur de système à la place d'un concentrateur de terminal.
Pour des informations détaillées sur l'accès à la console, reportez-vous au manuel
Oracle Solaris
Cluster Concepts Guide
.
Par ailleurs, si vous connectez une console d'administration directement aux noeuds de cluster ou via un réseau de gestion, indiquez à la place le nom d'hôte de chaque noeud de cluster global et le numéro de port série par le biais duquel il se connecte à la console d'administration ou au réseau de gestion.
Adresses logiques
Il faut spécifier le nom d'hôte de chaque groupe de ressources de service de données utilisant une adresse logique sur chaque réseau public à partir duquel il est possible d'accéder à l'adresse logique.
Pour plus d'informations, reportez-vous au
Oracle Solaris Cluster Data Services Planning and
Administration Guide
. Pour plus d'informations sur les services et ressources de données, reportez-vous également au manuel
Oracle Solaris Cluster Concepts Guide
.
Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification de l'environnement Oracle Solaris Cluster
Réseaux publics
Les réseaux publics communiquent en dehors du cluster. Tenez compte des points suivants lorsque vous planifiez votre configuration de réseau public :
■
■
■
■
■
■
■
Séparation des réseaux publics et privés
– Les réseaux publics et le réseau privé
(interconnexion de cluster) doivent utiliser des adaptateurs séparés, ou vous devez configurer des VLAN avec balises sur des adaptateurs et des commutateurs compatibles pour utiliser le même adaptateur pour l'interconnexion privée et le réseau public.
Minimum
– Tous les noeuds de cluster doivent être connectés à au moins un réseau public.
Les connexions de réseau public peuvent utilisent des sous-réseaux différents pour des noeuds différents.
Maximum
– Vous pouvez ajouter autant de connexions de réseau public que vous le souhaitez, dans la mesure où votre configuration matérielle vous le permet.
Services évolutifs
– Tous les noeuds exécutant un service évolutif doivent utiliser soit le même sous-réseau ou ensemble de sous-réseaux soit des sous-réseaux différents acheminables entre eux.
IPv4
– Le logiciel Oracle Solaris Cluster prend en charge des adresses IPv4 sur le réseau public.
IPv6
– Le logiciel Oracle Solaris Cluster prend en charge les adresses IPv6 sur le réseau public à la fois pour les services de données de basculement et évolutifs.
Groupes IPMP
– Chaque adaptateur de réseau public utilisé pour le trafic de service de données doit appartenir à un groupe Multipathing sur réseau IP (IPMP). Si un adaptateur de réseau public n'est pas utilisé pour le trafic de service de données, il n'est pas nécessaire de le configurer dans un groupe IPMP.
L'utilitaire scinstall configure automatiquement un groupe IPMP de plusieurs adaptateurs pour chaque ensemble d'adaptateurs de réseau public situé sur le même sous-réseau. Ces groupes sont basés sur une sonde.
L'utilitaire scinstall ignore les adaptateurs déjà configurés dans un groupe IPMP. Vous pouvez utiliser des groupes IPMP basés sur une sonde ou un lien dans un cluster. Les groupes IPMP basés sur une sonde qui testent l'adresse IP cible offrent la meilleure protection car ils reconnaissent davantage de conditions susceptibles de compromettre la disponibilité.
Si un adaptateur appartenant à un groupe IPMP configuré par l'utilitaire scinstall n'est pas destiné à être utilisé pour le trafic du service de données, vous pouvez supprimer cet adaptateur du groupe.
Pour obtenir des directives et des instructions relatives à la configuration des groupes IPMP, suivez les procédures décrites dans la Partie V, “IPMP” du manuel Administration d’Oracle
Solaris : Services IP
. Pour modifier les groupes IPMP après l'installation du cluster, suivez les directives de la section “Administration des groupes de multipathing sur réseau IP dans un
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 25
Planification de l'environnement Oracle Solaris Cluster
■
■ cluster” du manuel Guide d’administration système d’Oracle Solaris Cluster et les procédures décrites au Chapitre 28, “Administration d’IPMP (tâches)” du manuel Administration
d’Oracle Solaris : Services IP
.
Prise en charge des adresses MAC locales
– Tous les adaptateurs de réseau public doivent utiliser des cartes d'interface réseau prenant en charge l'attribution d'une adresse MAC.
L'attribution d'une adresse MAC locale est une condition requise par IPMP.
Paramètre local-mac-address – La variable local-mac-address? doit utiliser la valeur par défaut true pour les adaptateurs Ethernet. Le logiciel Oracle Solaris Cluster ne prend pas en charge une valeur local-mac-address? false pour les adaptateurs Ethernet.
Pour plus d'information sur les interfaces de réseau public, reportez-vous au manuel
Oracle
Solaris Cluster Concepts Guide
.
26
Configuration du serveur de quorum
Vous pouvez utiliser le logiciel Quorum Server d'Oracle Solaris Cluster (Quorum Server) pour configurer une machine en tant que serveur de quorum, puis configurer ce dernier en tant que périphérique de quorum du cluster. Vous pouvez utiliser un serveur de quorum à la place ou en plus des disques partagés et des gestionnaires de fichiers NAS.
Prenez en compte les points suivants si vous prévoyez d'utiliser un serveur de quorum dans une configuration Oracle Solaris Cluster.
■
■
■
■
■
Connexion réseau
– Le serveur de quorum se connecte à votre cluster par le biais du réseau public.
Matériel pris en charge
– Les plates-formes matérielles prises en charge pour un serveur de quorum sont les mêmes que pour le noeud de cluster global.
Système d'exploitation
– La configuration requise par le logiciel Oracle Solaris pour le logiciel Oracle Solaris Cluster s'applique également au logiciel Quorum Server.
Service apporté à plusieurs clusters
– Vous pouvez configurer un serveur de quorum installé avec le logiciel de serveur de quorum Oracle Solaris Cluster 3.3 3/13 en tant que périphérique de quorum sur plusieurs clusters.
Combinaison matérielle et logicielle hétérogène
– Il n'est pas nécessaire de configurer un serveur de quorum sur la même plate-forme matérielle et logicielle que les clusters auxquels il fournit le quorum. Par exemple, une machine SPARC exécutant le SE Oracle Solaris 10 peut être configurée en tant que serveur de quorum pour un cluster x86 exécutant le SE
Oracle Solaris 10.
En outre, un cluster exécutant le logiciel Oracle Solaris Cluster 3.3 3/13 peut recourir à un serveur de quorum qui exécute une version différente du logiciel que le cluster.
Reportez-vous au tableau d'interopérabilité du serveur de quorum dans le Oracle Solaris
Cluster 4 Compatibility Guide (http://www.oracle.com/
Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification de l'environnement Oracle Solaris Cluster
■
■ technetwork/server-storage/solaris-cluster/overview/ solariscluster4-compatibilityguide-1429037.pdf
) pour plus d'informations sur la combinaison des versions logicielles.
Algorithme du Spanning Tree
– Vous devez désactiver l'algorithme du Spanning Tree sur les commutateurs Ethernet pour les ports connectés au réseau public de cluster sur lequel le serveur le quorum s'exécutera.
Utilisation d'un noeud de cluster en tant que serveur de quorum
– Vous pouvez configurer un serveur de quorum sur un noeud de cluster pour fournir un quorum aux clusters différents du cluster auquel le noeud appartient. Cependant, un serveur de quorum configuré sur un noeud de cluster n'est pas hautement disponible.
Directives concernant NFS
Tenez compte des points suivants si vous prévoyez d'utiliser un système de fichiers réseau
(NFS) dans une configuration Oracle Solaris Cluster.
■
■
■
■
■
■
Client NFS
– Aucun noeud Oracle Solaris Cluster ne peut être un client NFS de système de fichiers exporté par Oracle Solaris Cluster HA pour NFS (HA pour NFS) géré sur un noeud de ce même cluster. Ce montage croisé de HA pour NFS est interdit. Utilisez le système de fichiers de cluster pour partager les fichiers entre les noeuds du cluster global.
Protocole NFSv3
– Si vous montez des systèmes de fichiers sur les noeuds de cluster à partir de serveurs NFS externes, tels que des gestionnaires de fichiers NAS, et si vous utilisez le protocole NFSv3, vous ne pouvez pas exécuter les montages de client NFS et le service de données HA pour NFS sur le même noeud de cluster. Si vous le faites néanmoins, certaines activités du service de données HA pour NFS peuvent entraîner l'arrêt et la réinitialisation des démons NFS, interrompant ainsi les services NFS. Cependant, vous pouvez exécuter en toute sécurité le service de données HA pour NFS si vous utilisez le protocole NFSv4 pour monter des systèmes de fichiers NFS externes sur les noeuds du cluster.
Verrouillage
– Les applications qui s'exécutent localement sur le cluster ne doivent pas verrouiller les fichiers sur un système de fichiers exporté par le biais de NFS. Sinon, le blocage local (par exemple, flock(3UCB) ou fcntl(2)) pourrait interférer avec la capacité de réinitialisation du gestionnaire de verrous (lockd(1M)). Au cours de la réinitialisation, un processus local bloqué peut obtenir un verrouillage destiné à être récupéré par un client distant. Cette situation entraînerait un comportement imprévisible.
Fonctions de sécurité NFS
– Le logiciel Oracle Solaris Cluster ne prend pas en charge les options suivantes de la commande share_nfs
(1M) : secure sec=dh
Cependant, le logiciel Oracle Solaris Cluster prend en charge les fonctions de sécurité suivantes pour NFS :
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 27
Planification de l'environnement Oracle Solaris Cluster
■
■
■
L'utilisation de ports sécurisés pour NFS. Pour activer des ports sécurisés pour NFS, ajoutez l'entrée nfssrv:nfs_portmon=1 au fichier /etc/system sur les noeuds de cluster.
L'utilisation de Kerberos avec NFS. Pour plus d'informations, reportez-vous à la section
“Securing HA for NFS With Kerberos V5” du manuel Oracle Solaris Cluster Data Service
for Network File System (NFS) Guide
.
Séparation
– Les clusters de zones prennent en charge la séparation de l'ensemble des périphériques NAS, des baies de stockage et des disques partagés pris en charge.
28
Restrictions de service
Prenez en compte les restrictions de service suivantes pour les configurations Oracle Solaris
Cluster :
■
■
■
■
■
Routeurs
– Ne configurez pas des noeuds de cluster en tant que routeurs (passerelles) pour les raisons suivantes :
■
■
Les protocoles de routage peuvent diffuser par inadvertance l'interconnexion du cluster en tant que réseau public ouvert aux autres routeurs, malgré la présence du paramètre
IFF_PRIVATE sur les interfaces d'interconnexion.
Il se peut que les protocoles de routage interfèrent dans le basculement des adresses IP sur des noeuds de cluster ayant un impact sur l'accès client.
■
Les protocoles de routage peuvent compromettre le bon fonctionnement des services
évolutifs s'ils acceptent et suppriment des paquets de réseau client au lieu de transférer les paquets aux autres noeuds du cluster.
Serveurs NIS+
– Ne configurez pas de noeuds de cluster en tant que serveurs NIS ou NIS+.
Aucun service de données n'est disponible pour NIS ou NIS+. Cependant, des noeuds de cluster peuvent être des clients NIS ou NIS+.
■
■
■
Serveurs d'installation et d'initialisation
– N'utilisez pas de configuration Oracle Solaris
Cluster pour fournir un service d'installation ou d'initialisation hautement disponible sur les systèmes client.
RARP
– N'utilisez pas une configuration Oracle Solaris Cluster pour fournir un service rarpd
.
Numéros de programme RPC
– Si vous installez un service RPC sur le cluster, il ne doit utiliser aucun des numéros de programme suivants :
100141
100142
100248
Ces numéros sont réservés respectivement aux démons Oracle Solaris Cluster rgmd_receptionist
, fed et pmfd.
Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification de l'environnement Oracle Solaris Cluster
■
Si le service RPC que vous installez utilise également l'un de ces numéros de programme, vous devez modifier ce service RPC pour utiliser un autre numéro de programme.
Classes de planification
– Le logiciel Oracle Solaris Cluster ne prend pas en charge l'exécution de classes de planification de processus haute priorité sur les noeuds de cluster.
N'exécutez pas les types de processus suivants sur les noeuds de cluster :
■
■
Processus s'exécutant dans la classe de programmation de partage de temps avec une priorité élevée
Processus s'exécutant dans la classe de programmation en temps réel
Le logiciel Oracle Solaris Cluster se repose sur les threads de noyau qui ne s'exécutent pas dans la classe de programmation en temps réel. D'autres processus de partage de temps s'exécutant selon une priorité supérieure à la normale ou les processus en temps réel peuvent empêcher les threads de noyau Oracle Solaris Cluster d'acquérir les cycles de CPU nécessaires.
Protocole NTP (protocole d'heure réseau)
Prenez en compte les directives suivantes pour le protocole NTP :
■
■
■
Synchronisation
– La première condition requise lorsque vous configurez NTP ou tout utilitaire de synchronisation d'heure dans le cluster est que tous les noeuds du cluster doivent être synchronisés sur la même heure.
Précision
– L'importance de la précision de l'heure sur les noeuds individuels est secondaire par rapport à la synchronisation de l'heure d'un noeud à l'autre. Vous êtes libre de configurer NTP selon vos besoins si cette condition de synchronisation est respectée.
Messages d'erreur relatifs aux noeuds inexistants
– A moins que vous n'ayez installé votre propre fichier /etc/inet/ntp.conf, la commande scinstall installe un fichier ntp.conf
par défaut à votre place. Le fichier par défaut est livré avec des références concernant le nombre maximal de noeuds. Par conséquent, le démon xntpd
(1M) peut générer des messages d'erreur relatifs à certaines de ces références lors de l'initialisation. Vous pouvez ignorer ces messages en toute sécurité. Reportez-vous à la section
“Configuration du protocole d'heure réseau (NTP)” à la page 155
pour plus d'informations sur la suppression de ces messages dans des conditions de cluster habituellement normales.
Reportez-vous au manuel
Oracle Solaris Cluster Concepts Guide
pour plus d'informations sur l'heure du cluster. Reportez-vous au fichier modèle /etc/inet/ntp.cluster pour obtenir des directives supplémentaires sur la configuration NTP pour une configuration Oracle Solaris
Cluster.
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 29
Planification de l'environnement Oracle Solaris Cluster
Composants configurables d'Oracle Solaris Cluster
Cette section contient des directives concernant les composants Oracle Solaris Cluster que vous configurez :
■
■
■
■
■
■
■
■
“Nom du cluster global” à la page 30
“Noms de noeud votant de cluster global et ID de noeud” à la page 30
“Configuration du réseau privé” à la page 31
“Noms d'hôtes privés” à la page 34
“Interconnexion de cluster” à la page 34
“Séparation globale” à la page 37
“Périphériques de quorum” à la page 38
Nom du cluster global
Spécifiez un nom pour le cluster global au cours de la configuration d'Oracle Solaris Cluster. Le nom de cluster global doit être unique au sein de la société.
Pour plus d'informations sur l'attribution d'un nom à un cluster de zones, reportez-vous à la section
“Clusters de zones” à la page 39 .
30
Noms de noeud votant de cluster global et ID de noeud
Le nom d'un noeud votant dans un cluster global est identique au nom que vous assignez à l'hôte physique ou virtuel lorsque vous y installez le SE Oracle Solaris. Reportez-vous à la page de manuel hosts
(4) pour plus d'informations sur les conventions de nommage.
Dans une installation de cluster à hôte unique, le nom de cluster par défaut est celui du noeud votant.
Au cours de la configuration d'Oracle Solaris Cluster, vous devez spécifier le nom des noeuds votants que vous installez dans le cluster global.
Un numéro d'ID est assigné à chaque noeud de cluster à usage interne du cluster. Cette numérotation démarre à partir du chiffre 1. Les numéros d'ID de noeud sont assignés à chaque noeud de cluster selon leur ordre d'entrée dans le cluster. Si vous configurez tous les noeuds du cluster en une seule opération, le noeud à partir duquel vous exécutez l'utilitaire scinstall correspond au dernier noeud auquel un numéro d'ID a été assigné. Vous ne pouvez pas modifier le numéro d'ID d'un noeud après avoir assigné ce dernier à un cluster.
Lorsqu'un noeud devient membre du cluster, il reçoit le numéro d'ID de noeud le plus petit possible. Si un noeud est supprimé du cluster, son ID peut être assigné à un nouveau noeud. Par exemple, dans un cluster composé de quatre noeuds, si le noeud portant l'ID 3 est supprimé et si un noeud est ajouté, l'ID qui lui est assigné est 3 (et non 5).
Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification de l'environnement Oracle Solaris Cluster
Si vous souhaitez que les numéros d'ID de noeud assignés correspondent à certains noeuds de cluster, configurez les noeuds de cluster un par un dans l'ordre dans lequel vous souhaitez assigner les numéros d'ID de noeud. Par exemple, pour assigner le numéro 1 à l'ID de noeud du logiciel du cluster dans la propriété phys-schost-1, configurez ce noeud en tant que noeud de cautionnement du cluster. Si vous ajoutez ensuite la propriété phys-schost-2 au cluster établi par la propriété phys-schost-1, l'ID de noeud 2 est assigné à la propriété phys-schost-2.
Pour plus d'informations sur les noms de noeuds dans un cluster de zones, reportez-vous à la section
“Clusters de zones” à la page 39 .
■
■
Noms de zones
Une zone non globale marquée native est un noeud potentiel valide d'une liste de noeuds de groupe de ressources. Respectez la convention de nommage nodename:zonename pour indiquer une zone non globale dans une commande Oracle Solaris Cluster.
nodename est le nom de l'hôte Oracle Solaris.
zonename est le nom affecté à la zone non globale lorsque vous créez la zone sur le noeud votant. Le nom de la zone doit être unique sur le noeud. Toutefois, vous pouvez utiliser le même nom de zone sur différents noeuds votant. Le nom de noeud différent dans
nodename: zonename rend le nom de zone non globale unique dans le cluster.
Pour spécifier la zone globale, il suffit d'indiquer le nom du noeud votant.
Pour plus d'informations sur un cluster de zones non globales, reportez-vous à la section
“Clusters de zones” à la page 39 .
Vous pouvez désactiver la fonctionnalité du cluster pour une zone globale sélectionnée. Un utilisateur root connecté à l'une de ces zones n'est pas en mesure de détecter ou de perturber le fonctionnement du cluster. Pour obtenir des instructions, reportez-vous à la section “Denying
Cluster Services for a Non-Global Zone” du manuel Oracle Solaris Cluster Data Service for
Solaris Containers Guide
.
Configuration du réseau privé
Remarque –
Il n'est pas nécessaire de configurer un réseau privé pour un cluster global à hôte unique. L'utilitaire scinstall assigne automatiquement l'adresse et le masque de réseau du réseau privé par défaut, même si aucun réseau privé n'est utilisé par le cluster.
Le logiciel Oracle Solaris Cluster utilise le réseau privé pour la communication interne entre les noeuds et les zones non globales gérés par le logiciel Oracle Solaris Cluster. Une configuration
Oracle Solaris Cluster requiert au moins deux connexions à l'interconnexion de cluster sur le réseau privé. Lorsque vous configurez le logiciel Oracle Solaris Cluster sur le premier noeud du cluster, vous spécifiez l'adresse et le masque de réseau du réseau privé de l'une des façons suivantes :
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 31
Planification de l'environnement Oracle Solaris Cluster
■
Acceptez l'adresse du réseau privé par défaut (172.16.0.0) ainsi que le masque de réseau par défaut (255.255.240.0). Cette plage d'adresses IP accepte un maximum de 64 noeuds votants et zones non globales, 12 clusters de zones et 10 réseaux privés.
Remarque –
Le nombre maximal de noeuds votants qu'une plage d'adresses IP peut accepter ne reflète pas le nombre maximal de noeuds votants que la configuration matérielle et logicielle peut actuellement prendre en charge.
■
■
■
Spécifiez une autre adresse de réseau privé admissible et acceptez le masque de réseau par défaut.
Acceptez l'adresse de réseau privé par défaut et spécifiez un autre masque de réseau.
Spécifiez une autre adresse de réseau privé et un autre masque de réseau.
Si vous choisissez de spécifier un autre masque de réseau, l'utilitaire scinstall vous demande le nombre de noeuds et de réseaux privés que vous souhaitez voir pris en charge par la plage d'adresses IP. L'utilitaire vous demande également le nombre de clusters de zones à prendre en charge. Le nombre de noeuds de cluster global que vous spécifiez doit également inclure le nombre requis de zones non globales non clusterisées que le réseau privé utilisera.
L'utilitaire calcule le masque de réseau pour la plage d'adresses IP minimale prenant en charge le nombre de noeuds, clusters de zones et réseaux privés que vous spécifiez. Il se peut que le masque de réseau calculé prenne en charge davantage de noeuds, zones non globales, clusters de zones et réseaux privés que le nombre défini. L'utilitaire scinstall calcule également un second masque de réseau, ce qui représente le minimum requis pour prendre en charge deux fois plus de noeuds, clusters de zones et réseaux privés. Ce second masque de réseau permet au cluster de s'adapter à une croissance ultérieure, sans avoir à reconfigurer la plage d'adresses IP.
L'utilitaire vous demande alors quel masque de réseau choisir. Vous pouvez spécifier l'un des masques de réseau calculés ou en choisir un autre. Le masque de réseau que vous spécifiez doit au minimum prendre en charge le nombre de noeuds et de réseaux privés que vous indiquez dans l'utilitaire.
32 Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification de l'environnement Oracle Solaris Cluster
Remarque –
Il peut être nécessaire de modifier la plage d'adresses IP privées du cluster pour prendre en charge des noeuds votant, des zones non globales, des clusters de zones et des réseaux privés supplémentaires.
Pour modifier l'adresse et le masque de réseau du réseau privé une fois le cluster établi, reportez-vous à la section “Modification de l’adresse du réseau privé ou de la plage d’adresses d’un cluster existant” du manuel Guide d’administration système d’Oracle Solaris Cluster . Vous devez réduire le cluster pour effectuer ces modifications.
Cependant, le cluster peut rester en mode cluster si vous exécutez la commande cluster set-netprops pour modifier uniquement le masque de réseau. Pour tout cluster de zones déjà configuré dans le cluster, les sous-réseaux IP privés et les adresses IP privées correspondantes allouées à ce cluster de zones seront également mis à jour.
Si vous spécifiez une adresse de réseau privé autre que celle par défaut, cette adresse doit respecter les conditions suivantes :
■
■
■
■
Taille de l'adresse et du masque de réseau
– L'adresse de réseau privé ne peut pas être plus courte que le masque de réseau. Pour exemple, vous pouvez utiliser l'adresse de réseau privé
172.16.10.0
avec le masque de réseau 255.255.255.0. Toutefois, vous ne pouvez pas utiliser une adresse de réseau privé de type 172.16.10.0 avec un masque de réseau de type
255.255.0.0
.
Adresses acceptées
– L'adresse doit être incluse dans le bloc d'adresses que RFC 1918 réserve à une utilisation dans des réseaux privés. Vous pouvez contacter InterNIC pour obtenir des copies de documents RFC (Request For Comments) ou consulter les documents
RFC en ligne à l'adresse suivante : http://www.rfcs.org
.
Utilisation dans plusieurs clusters
– Vous pouvez utiliser la même adresse de réseau privé dans plusieurs clusters à condition que les clusters se trouvent sur des réseaux privés différents. Les adresses de réseau IP privé ne sont pas accessibles depuis l'extérieur du cluster physique.
Pour les domaines invités Oracle VM Server for SPARC créés sur la même machine physique et connectés au même commutateur virtuel, le réseau privé est partagé par ces domaines invités et visible pour tous ces domaines. Procédez avec précaution avant de spécifier la plage d'adresses IP de réseau privé dans l'utilitaire scinstall que le cluster d'un domaine invité doit utiliser. Assurez-vous que la plage d'adresses n'est pas déjà utilisée par un autre domaine invité existant sur la même machine physique et partageant son commutateur virtuel.
Adaptateurs VLAN partagés par plusieurs clusters
– Les configurations Oracle Solaris
Cluster prennent en charge le partage du même adaptateur VLAN d'une interconnexion privée entre plusieurs clusters. Il n'est pas impératif de configurer un VLAN distinct pour chaque cluster. Toutefois, limiter l'utilisation d'un VLAN à un seul cluster offre un meilleur isolement des erreurs et une meilleure résilience d'interconnexion.
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 33
Planification de l'environnement Oracle Solaris Cluster
34
■
IPv6
– Le logiciel Oracle Solaris Cluster ne prend pas en charge les adresses IPv6 pour l'interconnexion privée. Le système configure des adresses IPv6 sur les adaptateurs de réseau privé afin de prendre en charge les services évolutifs utilisant des adresses IPv6. Toutefois, la communication internodale sur le réseau privé n'utilise pas ces adresses IPv6.
Pour plus d'informations sur les réseaux privés, reportez-vous au Chapitre 2, “Planification de votre réseau TCP/IP (tâches)” du manuel Administration d’Oracle Solaris : Services IP
Noms d'hôtes privés
Ce nom d'hôte privé est le nom utilisé pour la communication internodale par le biais de l'interface de réseau privé. Les noms d'hôtes privés sont automatiquement créés au cours de la configuration d'un cluster global ou d'un cluster de zones dans Oracle Solaris Cluster. Ces noms d'hôtes privés respectent la convention de nommage clusternodenodeid -priv, où nodeid correspond à la partie numérique de l'ID du noeud interne. Au cours de la configuration d'Oracle Solaris Cluster, le numéro d'ID de noeud est automatiquement assigné à chaque noeud votant lorsque le noeud devient un membre de cluster. Un noeud votant du cluster global et un noeud d'un cluster de zones peuvent tous les deux avoir le même nom d'hôte privé, mais chaque nom d'hôte a une adresse IP de réseau privé différente.
Une fois un cluster global configuré, vous pouvez renommer le nom de ses hôtes privés par le biais de l'utilitaire clsetup
(1CL) . Il vous est actuellement impossible de renommer le nom d'hôte privé d'un noeud de cluster de zones.
La création d'un nom d'hôte privé pour une zone non globale est facultative. Il n'existe aucune convention de nommage pour le nom d'hôte privé d'une zone non globale.
■
■
Interconnexion de cluster
Les interconnexions de cluster fournissent le chemin matériel nécessaire à la communication entre les noeuds de cluster sur le réseau privé. Chaque interconnexion consiste en un câble connecté de l'une des façons suivantes :
Entre deux adaptateurs de transport
Entre un adaptateur de transport et un commutateur de transport
Pour plus d'informations sur la finalité et le rôle de l'interconnexion de cluster, reportez-vous à la section “Cluster Interconnect” du manuel Oracle Solaris Cluster Concepts Guide .
Remarque –
Il est inutile de configurer une interconnexion de cluster pour un cluster à hôte unique. Cependant, si vous prévoyez d'ajouter éventuellement des noeuds votants supplémentaires à une configuration en cluster à hôte unique, il peut être utile de configurer l'interconnexion de cluster en prévision d'une utilisation ultérieure.
Pendant la configuration d'Oracle Solaris Cluster, vous devez spécifier les informations de configuration d'une ou deux interconnexions du cluster.
Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification de l'environnement Oracle Solaris Cluster
■
■
Si le nombre de ports d'adaptateurs disponibles est limité, vous pouvez utiliser des VLAN avec balises pour partager le même adaptateur avec les réseaux privé et public. Pour plus d'informations, reportez-vous aux directives concernant les adaptateurs VLAN avec balises
à la section
“Adaptateurs de transport” à la page 35 .
Vous pouvez configurer une à six interconnexions de cluster dans un cluster. Bien qu'une seule interconnexion de cluster réduise le nombre de ports d'adaptateurs utilisés pour l'interconnexion privée, cela ne permet pas la redondance et diminue la disponibilité. Si une interconnexion unique échoue, le risque que le cluster doive effectuer une récupération automatique est plus élevé. Dans la mesure du possible, installez deux interconnexions de cluster (ou plus) pour bénéficier de la redondance et de l'évolutivité et d'une disponibilité plus importante, en évitant un point de panne unique.
Une fois le cluster établi, vous pouvez configurer des interconnexions de clusters supplémentaires (six maximum) à l'aide de l'utilitaire clsetup
(1CL) .
Pour connaître les directives concernant le matériel d'interconnexion de cluster, reportez-vous
à la section “Interconnect Requirements and Restrictions” du manuel Oracle Solaris
Cluster 3.3 3/13 Hardware Administration Manual
. Pour des informations générales sur l'interconnexion de cluster, reportez-vous à la section “Cluster Interconnect” du manuel Oracle
Solaris Cluster Concepts Guide
.
Adaptateurs de transport
Pour les adaptateurs de transport, tels que les ports des interfaces réseau, spécifiez le nom de l'adaptateur de réseau et le type de transport. Si votre configuration est un cluster à deux hôtes, vous pouvez également spécifier si votre interconnexion est une connexion point à point
(adaptateur à adaptateur) ou si elle utilise un commutateur de transport.
Prenez en compte les différentes directives et restrictions suivantes :
■
■
■
IPv6
– Le logiciel Oracle Solaris Cluster ne prend pas en charge les communications IPv6 sur les interconnexions privées.
Attribution d'une adresse MAC locale
– Tous les adaptateurs de réseau privé doivent utiliser des cartes d'interface réseau (NIC) prenant en charge l'attribution d'une adresse
MAC locale. Les adresses IPv6 de type lien local (requises sur les adaptateurs de réseau privé pour prendre en charge les adresses de réseau public IPv6) sont dérivées des adresses MAC locales.
Adaptateurs VLAN avec balises
– Le logiciel Oracle Solaris Cluster prend en charge les réseaux VLAN pour partager un adaptateur entre l'interconnexion de cluster privé et le réseau public. Pour configurer un adaptateur VLAN avec balises pour l'interconnexion de cluster, spécifiez le nom de l'adaptateur et son ID de réseau VLAN (VID) de l'une des manières suivantes :
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 35
Planification de l'environnement Oracle Solaris Cluster
■
■
Indiquez le nom de l'adaptateur habituel, qui est le nom du périphérique plus un numéro d'instance ou PPA (point physique de connexion). Par exemple, le nom d'instance 2 d'un adaptateur Cassini Gigabit Ethernet est ce2. Si l'utilitaire scinstall vous demande si l'adaptateur fait partie d'un LAN virtuel partagé, répondez yes et spécifiez le numéro
VID de l'adaptateur.
Spécifiez l'adaptateur par son nom de périphérique virtuel VLAN. Le nom est composé du nom de l'adaptateur suivi du numéro d'instance VLAN. Le numéro d'instance VLAN est dérivé de la formule (1000*V)+N, où V est le numéro VID et N le point physique de connexion.
Par exemple, avec un VID défini sur 73 sur l'adaptateur ce2, le numéro d'instance VLAN doit être calculé de la façon suivante : (1000*73)+2. Vous devez donc nommer l'adaptateur ce73002 pour indiquer qu'il fait partie d'un LAN virtuel partagé.
■
■
Pour plus d'informations sur la configuration d'un VLAN dans un cluster, reportez-vous à la section “Configuring VLANs as Private Interconnect Networks” du manuel Oracle Solaris
Cluster 3.3 3/13 Hardware Administration Manual
. Pour obtenir des informations générales sur les VLAN, reportez-vous à la section “Administration de réseaux locaux virtuels” du manuel Administration d’Oracle Solaris : Services IP .
SPARC : Domaines invités Oracle VM Server for SPARC
– Spécifiez les noms d'adaptateur en indiquant leur nom virtuel vnetN, tels que vnet0 et vnet1. Les noms d'adaptateur virtuels sont enregistrés dans le fichier /etc/path_to_inst.
Interfaces logiques évolutives
– L'usage des interfaces logiques évolutives est réservé au logiciel Oracle Solaris Cluster.
Reportez-vous à la famille des pages de manuel scconf_trans_adap_*(1M) pour obtenir des informations sur un adaptateur de transport spécifique.
Commutateurs de transport
Si vous utilisez des commutateurs de transport, tels qu'un commutateur de réseau, spécifiez un nom de commutateur de réseau pour chaque interconnexion. Vous pouvez utiliser le nom par défaut switchN, où N correspond au numéro automatiquement assigné au cours de la configuration, ou définir un autre nom.
Spécifiez également le nom du port de commutateur ou acceptez le nom par défaut. Le nom de port par défaut correspond au numéro d'ID du noeud interne de l'hôte Oracle Solaris hébergeant l'extrémité du câble de l'adaptateur. Cependant, vous ne pouvez pas utiliser le nom de port par défaut pour certains types d'adaptateur.
Remarque –
Les clusters comprenant trois noeuds votants ou plus doivent utiliser des commutateurs de transport. La connexion directe entre les noeuds de cluster de vote est prise en charge uniquement pour les clusters à deux hôtes.
36 Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification de l'environnement Oracle Solaris Cluster
Si votre cluster à deux hôtes est connecté directement, vous pouvez néanmoins spécifier un commutateur de transport pour l'interconnexion.
Astuce –
Si vous spécifiez un commutateur de transport, vous pouvez ajouter plus facilement un autre noeud votant au cluster par la suite.
Séparation globale
La séparation est un mécanisme utilisé par le cluster pour protéger l'intégrité des données d'un disque partagé en cas de situation de
"split-brain". Par défaut, l'utilitaire scinstall en mode standard maintient activée la séparation globale et chaque disque partagé de la configuration utilise le paramètre de séparation globale par défaut de prefer3. Le protocole SCSI-3 est utilisé avec le paramètre prefer3.
En mode personnalisé, l'utilitaire scinstall vous demande de désactiver la séparation globale.
Dans la plupart des cas, répondez No pour maintenir la séparation globale activée. Dans certains cas, vous pouvez néanmoins désactiver la séparation globale.
Attention –
Si vous désactivez la séparation dans d'autres situations que celles décrites ci-après, vos données risquent d'être endommagées lors du basculement de l'application. Prenez en compte cet aspect lorsque vous désactivez la séparation.
Les situations dans lesquelles vous pouvez désactiver la séparation globale sont les suivantes :
■
■
Le stockage partagé ne permet pas la prise en charge des réservations SCSI.
Si vous désactivez la séparation pour un disque partagé que vous configurez ensuite en tant que périphérique de quorum, le périphérique utilise le protocole de quorum du logiciel, que le disque prenne en charge le protocole SCSI-2 ou SCSI-3. Le quorum du logiciel est un protocole du logiciel Oracle Solaris Cluster qui émule une forme de réservations de groupe persistant (PGR) SCSI.
Vous souhaitez permettre aux systèmes en dehors du cluster d'accéder au périphérique de stockage lié au cluster.
Si vous désactivez la séparation globale au cours de la configuration en cluster, la séparation est désactivée pour tous les disques partagés du cluster. Une fois le cluster configuré, vous pouvez modifier le protocole de séparation globale ou remplacer le protocole de séparation des disques partagés individuels. Cependant, pour modifier le protocole de séparation d'un périphérique de quorum, vous devez annuler la configuration du périphérique de quorum. Définissez ensuite le nouveau protocole de séparation du disque et reconfigurez ce dernier en tant que périphérique de quorum.
Pour plus d'informations sur la séparation, reportez-vous à la section “Failfast Mechanism” du manuel Oracle Solaris Cluster Concepts Guide . Pour plus d'informations sur la définition du
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 37
Planification de l'environnement Oracle Solaris Cluster
38 protocole de séparation des disques partagés individuels, reportez-vous à la page de manuel cldevice
(1CL) . Pour plus d'informations sur le paramètre de séparation globale, reportez-vous
à la page de manuel cluster
(1CL) .
Périphériques de quorum
Les configurations Oracle Solaris Cluster utilisent des périphériques de quorum pour maintenir l'intégrité des données et des ressources. Si le cluster perd temporairement la connexion avec un noeud votant, le périphérique de quorum permet de prévenir des problèmes d'amnésie ou de
"split-brain" lorsque le noeud de cluster de vote tente de rejoindre le cluster. Pour plus d'informations sur la finalité et le rôle des périphériques de quorum, reportez-vous à la section
“Quorum and Quorum Devices” du manuel Oracle Solaris Cluster Concepts Guide .
Au cours de l'installation Oracle Solaris Cluster d'un cluster à deux hôtes, vous pouvez choisir de laisser l'utilitaire scinstall configurer automatiquement un disque partagé disponible dans la configuration en tant que périphérique de quorum. Les disques partagés incluent tout périphérique Sun NAS configuré pour être utilisé en tant que disque partagé. L'utilitaire scinstall suppose que tous les disques partagés disponibles sont pris en charge en tant que périphériques de quorum.
Si vous souhaitez utiliser un serveur de quorum en tant que périphérique de quorum, vous l'ajoutez à la configuration du cluster après la fin du traitement de scinstall. Pour plus d'informations sur les serveurs de quorum, reportez-vous à la section
“Configuration du serveur de quorum” à la page 26 .
Après l'installation, vous pouvez également configurer des périphériques de quorum supplémentaires à l'aide de l'utilitaire clsetup.
Remarque –
Il est inutile de configurer des périphériques de quorum pour un cluster à hôte unique.
Si votre configuration en cluster inclut des périphériques tiers de stockage partagés dont l'utilisation en tant que périphériques de quorum n'est pas prise en charge, vous devez exécuter l'utilitaire clsetup pour configurer le quorum manuellement.
Tenez compte des points suivants lorsque vous planifiez les périphériques de quorum.
■
■
Minimum
– Un cluster à deux hôtes doit comprendre au moins un périphérique de quorum, qui peut être un disque partagé, un serveur de quorum ou un périphérique NAS.
Pour d'autres topologies, les périphériques de quorum sont optionnels.
Règle de nombre impair
– Si plusieurs périphériques de quorum sont configurés dans un cluster à deux hôtes ou dans une paire d'hôtes directement connectée au périphérique de quorum, configurez un nombre impair de périphériques de quorum. Cette configuration permet de s'assurer que les périphériques de quorum ont des chemins de panne complètement indépendants.
Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification de l'environnement Oracle Solaris Cluster
■
■
■
■
■
■
■
Distribution des votes de quorum
– Pour assurer la disponibilité optimale du cluster, assurez-vous que le nombre total de votes des périphériques de quorum est inférieur au nombre total de votes des noeuds votants. Sinon, les noeuds ne peuvent pas former un cluster si tous les périphériques de quorum sont indisponibles, même si tous les noeuds fonctionnent.
Connexion
– Vous devez connecter un périphérique de quorum à au moins deux noeuds votants.
Protocole de séparation SCSI
– Lorsqu'un périphérique de quorum de disque partagé SCSI est configuré, son protocole de séparation est automatiquement défini sur SCSI-2 dans un cluster à deux hôtes ou sur SCSI-3 dans un cluster à trois noeuds votant ou plus.
Modification du protocole de séparation de périphériques de quorum
– Pour les disques
SCSI configurés en tant que périphérique de quorum, vous devez annuler la configuration du périphérique de quorum avant d'activer ou de désactiver son protocole de séparation
SCSI.
Protocole de quorum du logiciel
– Vous pouvez configurer des disques partagés ne prenant pas en charge le protocole SCSI, tels que des disques SATA, en tant que périphériques de quorum. Vous devez désactiver la séparation pour de tels disques. Les disques doivent alors utiliser le protocole de quorum du logiciel, qui émule des réservations de groupe persistant
(PGR) SCSI.
Le protocole de quorum du logiciel doit également être utilisé par des disques partagés SCSI si la séparation est désactivée pour ces disques.
Périphériques répliqués
– Le logiciel Oracle Solaris Cluster ne prend pas en charge les périphériques répliqués en tant que périphériques de quorum.
Pools de stockage ZFS
– N'ajoutez pas un périphérique de quorum configuré à un pool de stockage ZFS. Lorsqu'un périphérique de quorum configuré est ajouté au pool de stockage
ZFS, le disque est réétiqueté en tant que disque EFI et les informations de quorum sont perdues. Le disque ne peut alors plus fournir un vote de quorum au cluster.
Une fois un disque dans un pool de stockage, vous pouvez configurer ce disque en tant que périphérique de quorum. Ou vous pouvez annuler la configuration du périphérique de quorum, l'ajouter au pool de stockage, puis reconfigurer le disque en tant que périphérique de quorum.
Pour plus d'informations sur les périphériques de quorum, reportez-vous à la section “Quorum and Quorum Devices” du manuel Oracle Solaris Cluster Concepts Guide .
Clusters de zones
Un cluster de zones est un cluster composé de zones Oracle Solaris non globales. Tous les noeuds d'un cluster de zones sont configurés en tant que zones non globales de la marque
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 39
Planification de l'environnement Oracle Solaris Cluster
40 cluster
. Aucun autre type de marque n'est autorisé dans un cluster de zones. Vous pouvez exécuter les services pris en charge sur le cluster de zones similaire à un cluster global, avec l'isolement fourni par les zones Oracle Solaris.
Vous pouvez exécuter l'utilitaire clsetup pour créer un cluster de zones et ajouter une adresse de réseau, un système de fichiers, un pool de stockage ZFS ou un périphérique de stockage.
Vous pouvez également utiliser une interface de ligne de commande (l'utilitaire clzonecluster
) pour créer un cluster de zones, apporter des modifications à la configuration et supprimer un cluster de zones. Pour plus d'informations sur l'exécution de l'utilitaire clzonecluster
, reportez-vous à la page de manuel clzonecluster
(1CL) .
Tenez compte des points suivants lorsque vous planifiez la création d'un cluster de zones.
■
■
■
“Conditions requises et directives concernant le cluster global” à la page 40
“Conditions requises et directives concernant le cluster de zones” à la page 41
“Directives pour Trusted Extensions dans un cluster de zones” à la page 42
Conditions requises et directives concernant le cluster global
■
■
■
■
■
Cluster global
– Le cluster de zones doit être configuré sur une configuration Oracle Solaris
Cluster globale. Un cluster de zones ne peut pas être configuré sans un cluster global sous-jacent.
Mode cluster
– Le noeud votant du cluster global à partir duquel vous avez créé ou modifié un cluster de zones doit être en mode cluster. Si les autres noeuds votants sont en mode non cluster lorsque vous gérez un cluster de zones, les modifications apportées sont propagées à ces noeuds lorsqu'ils repassent en mode cluster.
Adresses IP privées appropriées
– La plage d'adresses IP privées du cluster global doit inclure suffisamment de sous-réseaux d'adresses IP disponibles pouvant être utilisés par le nouveau cluster de zones. Si le nombre de sous-réseaux disponibles est insuffisant, la création du cluster de zones échoue.
Modifications apportées à la plage d'adresses IP privées
– Les sous-réseaux IP privés et les adresses IP privées correspondantes disponibles pour les clusters de zones sont automatiquement mis à jour si la plage d'adresses IP privées du cluster global est modifiée. Si un cluster de zones est supprimé, l'infrastructure de cluster libère les adresses IP privées qui
étaient utilisées par ce cluster de zones, permettant ainsi d'utiliser les adresses à d'autres fins au sein du cluster global et les rendant utilisables par tout autre cluster de zones dépendant du cluster global.
■
■
■
Périphériques pris en charge
– Les périphériques pris en charge avec des zones Oracle
Solaris peuvent être exportés vers un cluster de zones. De tels périphériques incluent les
éléments suivants :
Périphériques de disque Oracle Solaris (cNt XdYsZ)
Périphériques DID (/dev/did/*dsk/dN)
Ensembles de disques multipropriétaires (/dev/md/setname/*dsk/d N)
Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification de l'environnement Oracle Solaris Cluster
■
■
■
■
Conditions requises et directives concernant le cluster de zones
Répartition de noeuds
– Vous ne pouvez pas héberger plusieurs noeuds du même cluster de zones sur la même machine hôte. Un hôte peut prendre en charge plusieurs noeud de clusters de zones tant que chaque noeud de clusters de zones de cet hôte fait partie d'un cluster de zones différent.
Création de noeuds
– Vous devez créer au moins un noeud de cluster de zones au moment de créer le cluster de zones. Vous pouvez exécuter l'utilitaire clsetup ou la commande clzonecluster pour créer le cluster de zones. Le nom de chaque noeud de cluster de zones doit être unique. L'infrastructure crée automatiquement une zone non globale sous-jacente sur chaque hôte prenant en charge le cluster de zones. Le même nom de zones est attribué à chaque zone non globale. Ce nom est identique au nom attribué au cluster de zones lorsque vous créez le cluster. Par exemple, si vous créez un cluster de zones portant le nom zc1, la zone non globale correspondante sur chaque hôte prenant en charge le cluster de zones porte également le nom zc1.
Nom de cluster
– Chaque nom de cluster de zones doit être unique sur l'ensemble du cluster de machines hébergeant le cluster global. Le nom d'un cluster de zones ne peut pas être
également utilisé par une zone non globale ailleurs dans le cluster des machines et ne peut pas être identique au nom d'un noeud de cluster global. Vous ne pouvez pas utiliser
"all" ou
"global" comme nom de cluster de zones. Il s'agit de noms réservés.
Adresses IP de réseau public
– Vous pouvez attribuer une adresse IP de réseau public spécifique à chaque noeud de cluster de zones.
Remarque –
Si vous ne configurez pas une adresse IP pour chaque noeud de cluster de zones, deux conséquences s'ensuivent :
■
■
Le cluster de zones concerné n'est pas en mesure de configurer des périphériques NAS en vue de les utiliser dans le cluster de zones. Le cluster utilise l'adresse IP du noeud de cluster de zones lors de la communication avec le périphérique NAS, si bien que l'absence d'adresse IP empêche la prise en charge de la séparation des périphériques NAS par le cluster.
Le logiciel de gestion du cluster active n'importe quelle autre l'adresse IP de l'hôte sur n'importe quelle carte d'interface réseau.
■
■
Noms d'hôtes privés
– Au cours de la création du cluster de zones, un nom d'hôte privé est automatiquement créé pour chaque noeud du cluster de zones, de la même façon que les noms d'hôtes sont créés dans les clusters globaux. Il vous est actuellement impossible de renommer le nom d'hôte privé d'un noeud de cluster de zones. Pour plus d'informations sur les noms d'hôtes privés, reportez-vous à la section
“Noms d'hôtes privés” à la page 34 .
Marques Oracle Solaris Zones
– Tous les noeuds d'un cluster de zones sont configurés en tant que zones non globales marquées cluster. Aucun autre type de marque n'est autorisé dans un cluster de zones.
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 41
Planification de l'environnement Oracle Solaris Cluster
42
■
■
■
Propriété de type de ressource Global_zone=TRUE – Pour enregistrer un type de ressource utilisant la propriété de type de ressource Global_zone=TRUE, le fichier de type de ressource doit se trouver sous le répertoire /usr/cluster/global/rgm/rtreg/ du cluster de zones. Si ce fichier de type de ressource se trouve à un autre emplacement, la commande permettant d'enregistrer le type de ressource est rejetée.
Conversion en noeud de cluster de zones
– Vous ne pouvez pas ajouter à un cluster de zones une zone non globale se trouvant en dehors de ce dernier. Il faut exécuter uniquement la commande clzonecluster pour ajouter des noeuds à un cluster de zones.
Systèmes de fichiers
– Vous pouvez exécuter l'utilitaire clsetup ou la commande clzonecluster pour ajouter les types de systèmes de fichiers suivants à utiliser par un cluster de zones. Pour exporter un système de fichiers vers un cluster de zones, vous pouvez utiliser soit un point de montage direct, soit un point de montage loopback. L'ajout d'un système de fichiers à l'aide de l'utilitaire clsetup s'effectue dans l'étendue du cluster, ce qui a une incidence sur l'ensemble du cluster de zones.
■
Montage direct :
■
Système de fichiers local UFS
■
■
Système de fichiers autonome QFS
Système de fichiers partagé QFS, uniquement dans le cas d'une utilisation à des fins de support d'Oracle Real Application Clusters
■
■
■
ZFS (exporté en tant qu'ensemble de données)
Système de fichiers NFS à partir de périphériques NAS pris en charge
Montage loopback :
■
Système de fichiers local UFS
■
■
■
Système de fichiers autonome QFS
Système de fichiers partagé QFS (uniquement lorsqu'ils sont utilisés pour prendre en charge Oracle Real Application Clusters)
Système de fichiers de cluster UFS
■
Vous configurez une ressource HAStoragePlus ou ScalMountPoint pour gérer le montage du système de fichiers.
Séparation
– Les clusters de zones prennent en charge la séparation de l'ensemble des périphériques NAS, des baies de stockage et des disques partagés pris en charge.
■
Directives pour Trusted Extensions dans un cluster de zones
Tenez compte des points suivants lorsque vous utilisez la fonction Trusted Extensions dans un cluster de zones Oracle Solaris :
Prise en charge du cluster de zones uniquement
– Dans une configuration d'Oracle Solaris
Cluster lorsque Trusted Extensions est activé, les applications doivent uniquement s'exécuter dans un cluster de zones. Aucune autre des zones non globales ne peut être
Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification de l'environnement Oracle Solaris Cluster
■
■
■
■
■
■
■ utilisée sur le cluster. Il faut exécuter uniquement la commande clzonecluster pour créer un cluster de zones. N'utilisez pas la commande txzonemgr pour créer une zone non globale sur un cluster dont l'option Trusted Extensions est activée.
Etendue de Trusted Extensions
– Vous pouvez activer ou désactiver Trusted Extensions pour la configuration de l'intégralité du cluster. Lorsque Trusted Extensions est activé, toutes les zones non globales dans la configuration du cluster doivent faire partie de l'un des clusters de zones dans le cluster. Vous ne pouvez pas configurer un autre type de zone non globale sans risque pour la sécurité.
Adresses IP
– Chaque cluster de zones mettant en oeuvre Trusted Extensions doit utiliser ses propres adresses IP. La fonction de mise en réseau spéciale de Trusted Extensions qui permet de partager une adresse IP entre plusieurs zones non globales n'est pas prise en charge avec le logiciel Oracle Solaris Cluster.
Montages loopback
– Vous ne pouvez pas procéder à des montages loopback qui disposent d'autorisations en écriture dans un cluster de zones utilisant Trusted Extensions. Utilisez uniquement des montages directs de systèmes de fichiers permettant l'accès en écriture ou des montages loopback qui ne disposent que d'autorisations en lecture.
Systèmes de fichiers
– Ne configurez pas le périphérique global sur lequel repose un système de fichiers dans le cluster de zones. Configurez uniquement le système de fichiers proprement dit dans le cluster de zones.
Nom du périphérique de stockage
– N'ajoutez pas de tranche individuelle d'un périphérique de stockage dans un cluster de zones. Vous devez ajouter le périphérique complet à un cluster de zones unique. L'utilisation de tranches du même périphérique de stockage dans des clusters de zones différents compromet la sécurité de ces clusters.
Installation d'applications
– Installez des applications uniquement dans le cluster de zones ou dans le cluster global, puis effectuez une exportation vers le cluster de zones en utilisant les montages loopback en lecture seule.
Isolement de cluster de zones
– Lorsque Trusted Extensions est utilisé, le nom d'un cluster de zones est une étiquette de sécurité. Dans certains cas, l'étiquette de sécurité elle-même peut également se composer d'informations ne pouvant pas être divulguées, et le nom d'une ressource ou d'un groupe de ressources peut être une information sensible ne pouvant pas non plus être divulguée. Lorsqu'une dépendance de ressource inter-cluster ou une affinité de groupe de ressources inter-cluster est configurée, le nom de l'autre cluster devient visible, de même que le nom de toute ressource ou groupe de ressources affecté. Par conséquent, avant d'établir toute relation inter-cluster, évaluez si ces informations peuvent être rendues visibles, en fonction de vos besoins.
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 43
Planification des périphériques globaux, des groupes de périphériques et des systèmes de fichiers de cluster
Planification des périphériques globaux, des groupes de périphériques et des systèmes de fichiers de cluster
Cette section fournit les directives suivantes pour la planification des périphériques globaux et des systèmes de fichiers de cluster :
■
■
■
■
■
“Planification des périphériques globaux” à la page 44
“Planification des groupes de périphériques” à la page 45
“Planification des systèmes de fichiers de cluster” à la page 45
“Choix des options de montage pour les systèmes de fichiers de cluster UFS” à la page 47
“Informations sur le montage pour les systèmes de fichiers de cluster” à la page 48
Planification des périphériques globaux
Pour plus d'informations sur la finalité et le rôle des périphériques globaux, reportez-vous à la section “Global Devices” du manuel Oracle Solaris Cluster Concepts Guide .
Le logiciel Oracle Solaris Cluster ne requiert aucune organisation de disques ni taille de système de fichiers spécifique. Tenez compte des points suivants lorsque vous planifiez l'organisation des périphériques globaux.
■
■
■
■
■
Mise en miroir
– Vous devez mettre en miroir tous les périphériques globaux pour que le périphérique global soit considéré comme hautement disponible. 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 disques.
Disques
– Lorsque vous procédez à une mise en miroir, organisez les systèmes de fichiers de façon à ce qu'ils soient mis en miroir d'une baie de disques à une autre.
Disponibilité
– Vous devez connecter physiquement un périphérique global à plus d'un noeud votant dans le cluster pour le périphérique global à considérer comme hautement disponible. Un périphérique global ayant des connexions physiques multiples peut tolérer la panne d'un noeud. Un périphérique global doté d'une seule connexion physique est pris en charge, mais le périphérique global devient inaccessible depuis les autres noeuds votants si le noeud doté de la connexion est en panne.
Périphériques swap
– Ne créez pas de fichier swap sur un périphérique global.
Zones non globales
– Les périphériques globaux ne sont pas directement accessibles depuis une zone non globale. Seules les données du système de fichiers de cluster sont accessibles à partir d'une zone non globale.
44 Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification des périphériques globaux, des groupes de périphériques et des systèmes de fichiers de cluster
Planification des groupes de périphériques
Pour plus d'informations sur la finalité et le rôle des groupes de périphériques, reportez-vous à la section “Device Groups” du manuel Oracle Solaris Cluster Concepts Guide .
Tenez compte des points suivants lorsque vous planifiez les groupes de périphériques.
■
■
■
Basculement
– Vous pouvez configurer des disques multihôtes et des périphériques de gestionnaire des volumes configurés en conséquence en tant que périphériques de basculement. Une configuration appropriée du périphérique de gestionnaire de volumes inclut des disques multihôte et le paramétrage du gestionnaire de volumes. Cette configuration permet de s'assurer que des noeuds votants multiples peuvent héberger le périphérique exporté. Vous ne pouvez pas configurer des lecteurs de bande, des CD-ROM ou des DVD-ROM, ni des périphériques à port unique en tant que périphériques de basculement.
Mise en miroir
– Vous devez mettre en miroir les disques afin de protéger les données en cas de panne du disque. Pour des directives supplémentaires, reportez-vous à la section
“Directives concernant la mise en miroir” à la page 52 . Reportez-vous à la section
“Configuration du logiciel Solaris Volume Manager” à la page 165
et consultez la documentation de votre gestionnaire de volumes pour des instructions relatives à la mise en miroir.
Réplication basée sur le stockage
– Les disques d'un groupe de périphériques doivent tous
être soit répliqués, soit non répliqués. Un groupe de périphériques ne peut pas accepter une combinaison de disques répliqués et non répliqués.
Planification des systèmes de fichiers de cluster
Pour plus d'informations sur la finalité et le rôle des systèmes de fichier de cluster, reportez-vous
à la section “Cluster File Systems” du manuel Oracle Solaris Cluster Concepts Guide .
Remarque –
Vous pouvez également configurer des systèmes de fichiers locaux hautement disponibles. Cela peut permettre d'obtenir de meilleures performances pour la prise en charge d'un service de données avec de nombreuses E/S ou d'utiliser certaines fonctions des systèmes de fichiers non prises en charge dans un système de fichiers de cluster. Pour plus d'informations, reportez-vous à la section “Enabling Highly Available Local File Systems” du manuel Oracle
Solaris Cluster Data Services Planning and Administration Guide
.
Tenez compte des points suivants lorsque vous planifiez des systèmes de fichiers de cluster.
■
Quotas
– Les quotas ne sont pas pris en charge sur les systèmes de fichiers de cluster.
Cependant, les quotas sont pris en charge sur les systèmes de fichiers locaux hautement disponibles.
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 45
Planification des périphériques globaux, des groupes de périphériques et des systèmes de fichiers de cluster
46
■
■
■
Zones non globales
– Si vous devez accéder à un système de fichiers de cluster à partir d'une zone non globale, celui-ci doit d'abord être monté dans la zone globale. Le système de fichiers de cluster est ensuite monté dans la zone non globale à l'aide d'un montage loopback. Par conséquent, le système de fichiers loopback (LOFS) doit être activé dans un cluster contenant des zones non globales.
Clusters de zones
– Vous ne pouvez pas configurer de systèmes de fichiers de cluster mettant en oeuvre UFS pour une utilisation dans un cluster de zones. Utilisez à la place des systèmes de fichiers locaux hautement disponibles. Vous pouvez utiliser un système de fichiers partagé QFS dans un cluster de zones uniquement pour assurer la prise en charge d'Oracle RAC.
Système de fichiers loopback (LOFS)
– Pendant la création du cluster, le système LOFS est activé par défaut. Vous devez désactiver manuellement LOFS sur chaque noeud de cluster de vote si le cluster respecte les deux conditions suivantes :
■
Oracle Solaris Cluster HA pour NFS (HA pour NFS) est configuré sur un système de fichiers local à haute disponibilité.
■
Le démon automountd est en cours d'exécution.
Si le cluster respecte ces deux conditions, vous devez désactiver la fonction LOFS afin d'éviter entre autres les problèmes de commutation : Si le cluster respecte au moins l'une de ces conditions, vous pouvez activer LOFS en toute sécurité.
■
■
Si vous avez besoin que le système LOFS et le démon automountd soient tous les deux activés, excluez de la carte de l'agent de montage automatique tous les fichiers faisant partie du système de fichiers local hautement disponible exporté par HA pour NFS.
Fichiers journaux de comptabilisation des processus
– N'enregistrez pas les fichiers journaux de comptabilisation des processus sur un système de fichiers de cluster ou un système de fichiers local hautement disponible. Une commutation serait bloquée par des
écritures dans le fichier journal, ce qui entraînerait le blocage du noeud. Utilisez uniquement un système de fichiers local pour conserver les fichiers journaux de comptabilisation des processus.
Extrémités de communication
– Le système de fichiers de cluster ne prend en charge aucune des fonctions de système de fichiers du logiciel Oracle Solaris permettant de définir une extrémité de communication dans l'espace de noms du système de fichiers.
■
■
Bien que vous puissiez créer un socket de domaine UNIX dont le nom correspond à un nom de chemin dans le système de fichiers de cluster, le socket ne survivrait pas au basculement du noeud.
Tout FIFO ou canal nommé que vous créez dans un système de fichiers de cluster n'est pas accessible de façon globale.
Par conséquent, ne tentez pas d'utiliser la commande fattach à partir d'un autre noeud que le noeud local.
Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification des périphériques globaux, des groupes de périphériques et des systèmes de fichiers de cluster
■
■
■
■
Fichiers spéciaux du périphérique
– Ni les fichiers spéciaux de type bloc ni les fichiers spéciaux de type caractère sont pris en charge dans un système de fichiers de cluster. Pour spécifier un nom de chemin pour un noeud de périphérique dans un système de fichiers de cluster, créez un lien symbolique vers le nom de périphérique du répertoire /dev. N'utilisez pas la commande mknod dans ce but.
atime
– Les systèmes de fichiers de cluster ne maintiennent pas atime.
ctime
– Lorsque vous accédez à un fichier d'un système de fichiers de cluster, il se peut que la mise à jour du paramètre ctime du fichier soit retardée.
Installation des applications
- Si vous souhaitez que les données binaires d'une application hautement disponible résident sur un système de fichiers de cluster, installez l'application uniquement une fois que le système de fichiers de cluster est configuré.
Choix des options de montage pour les systèmes de fichiers de cluster UFS
Cette section décrit les conditions et restrictions des options de montage des systèmes de fichiers de cluster UFS.
Remarque –
Vous pouvez également configurer ces types de systèmes de fichiers de cluster et d'autres types de systèmes de fichiers en tant que systèmes de fichiers locaux hautement disponibles. Pour plus d'informations, reportez-vous à la section “Enabling Highly Available
Local File Systems” du manuel Oracle Solaris Cluster Data Services Planning and
Administration Guide
.
Suivez ces directives pour déterminer les options de montage à utiliser lorsque vous créez votre système de fichiers de cluster.
Option de montage
global logging forcedirectio
Utilisation
Obligatoire
Obligatoire
Conditionnelle
Description
Cette option rend le système de fichiers visible de façon globale pour tous les noeuds du cluster.
Cette option active la journalisation.
Cette option est requise uniquement pour les systèmes de fichiers de cluster qui hébergeront les fichiers de données, les fichiers journaux et les fichiers de contrôle
RDBMS Oracle Real Application Clusters.
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 47
Planification des périphériques globaux, des groupes de périphériques et des systèmes de fichiers de cluster
Option de montage
onerror=panic syncdir
Utilisation
Obligatoire
Facultative
Description
Il est inutile de spécifier explicitement l'option de montage onerror=panic dans le fichier /etc/vfstab. Cette option de montage est déjà la valeur par défaut si aucune autre option de montage onerror n'est spécifiée.
Remarque –
Seule l'option de montage onerror=panic est prise en charge par le logiciel
Oracle Solaris Cluster. N'utilisez pas les options de montage onerror=umount ou onerror=lock
. Ces options de montage ne sont pas prises en charge sur les systèmes de fichiers de cluster pour les raisons suivantes :
■ L'option de montage onerror=umount ou onerror=lock peut entraîner le verrouillage du système de fichiers de cluster ou le blocage de son accès. Cela peut se produire si le système de fichiers de cluster rencontre un problème d'altération de fichier.
■ L'option de montage onerror=umount ou onerror=lock peut rendre impossible le montage du système de fichiers de cluster. Cette condition peut entraîner le blocage des applications utilisant le système de fichiers de cluster ou empêcher leur arrêt.
Un noeud peut requérir une réinitialisation pour sortir de ces états.
Si vous spécifiez syncdir, le comportement de systèmes de fichiers est conforme avec la norme POSIX pour l'appel système write(). Si la commande write() réussit, cette option de montage assure qu'un espace suffisant est disponible sur le disque.
Si vous ne spécifiez pas syncdir, le même comportement observé avec les systèmes de fichiers UFS se produit. Lorsque vous ne spécifiez pas syncdir, les performances d'écriture qui allouent des blocs de disque (lorsque vous ajoutez des données à un fichier, par exemple) peuvent augmenter significativement. Cependant, dans certains cas, sans syncdir, l'insuffisance d'espace (ENOSPC) ne serait pas signalée avant la fermeture du fichier.
Après un basculement, ENOSPC n'apparaît que très brièvement à la fermeture. Avec syncdir
, comme avec POSIX, l'insuffisance d'espace est détectée avant la fermeture.
Reportez-vous à la page de manuel mount_ufs
(1M) pour plus d'informations sur les options de montage UFS.
48
Informations sur le montage pour les systèmes de fichiers de cluster
Tenez compte des points suivants lorsque vous planifiez les points de montage des systèmes de fichiers de cluster.
■
Emplacement de point de montage
– Créez des points de montage pour les systèmes de fichiers de cluster dans le répertoire /global, à moins que vos autres logiciels ne l'interdisent. Le répertoire /global vous permet de distinguer plus facilement les systèmes de fichiers de cluster (disponibles de façon globale) et les systèmes de fichiers locaux.
Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification de la gestion des volumes
■
Points de montage imbriqués
– De façon générale, il ne faut pas imbriquer les points de montage des systèmes de fichiers de cluster. Par exemple, ne configurez pas un système de fichiers monté sur /global/a et un autre système de fichiers monté sur /global/a/b.
Ignorer cette règle peut entraîner des problèmes de disponibilité et d'ordre d'initialisation des noeuds. Ces problèmes sont susceptibles de se produire si le point de montage parent n'est pas présent lorsque le système tente de monter un enfant de ce système de fichiers.
Si les périphériques pour les deux systèmes de fichiers ont la même connectivité à l'hôte physique, cette règle n'est pas appliquée pour les systèmes de fichiers de cluster sur UFS. La présence de plusieurs tranches sur le même disque est un exemple.
Remarque –
Cette restriction continue de s'appliquer aux systèmes de fichiers partagés QFS, même si les deux périphériques de systèmes de fichiers ont la même connectivité à l'hôte physique.
■ forcedirectio
– Le logiciel Oracle Solaris Cluster ne prend pas en charge l'exécution des fichiers binaires en dehors des systèmes de fichiers binaires montés par le biais de l'option de montage forcedirectio.
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” à la page 50
“Directives relatives au logiciel Solaris Volume Manager” à la page 51
“Journalisation des systèmes de fichiers” à la page 51
“Directives concernant la mise en miroir” à la page 52
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” à la page 165
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
.
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 49
Planification de la gestion des volumes
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” à la page 52
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” à la page 52
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.
50 Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification de la gestion des volumes
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.
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 51
Planification de la gestion des volumes
52
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” à la page 52
“Directives relatives à la mise en miroir du disque root” à la page 52
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” à la page 165
pour obtenir des instructions sur la mise de miroir du disque root.
Guide d'installation du logiciel Oracle Solaris Cluster • Septembre 2013, E39389–03
Planification de la gestion des volumes
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.
Chapitre 1 • Planification de la configuration d'Oracle Solaris Cluster 53
54
