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

• Patchs logiciels

• Adresses IP de réseau public

• Périphériques d'accès par console

• Adresses logiques

• Réseaux publics

• Serveurs de quorum

• Directives concernant NFS

• Restrictions de service

• Protocole NTP (Network Time Protocol)

• Composants Oracle Solaris Cluster configurables

• Clusters de zones

Pour plus d'informations sur les composants Oracle Solaris Cluster, reportez-vous au Oracle Solaris Cluster Concepts Guide.

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 nœud installé avec le logiciel Oracle Solaris Cluster doit être couvert par le contrat de licence du logiciel 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 logiciel, vous devez installer les patchs correspondants. Pour que le cluster puisse fonctionner correctement, assurez-vous de maintenir le même niveau de patch pour tous les nœuds de cluster.

• Pour plus d'informations sur les patchs requis, reportez-vous à la section Patchs et niveaux des microprogrammes requis du Notes de version d’Oracle Solaris Cluster 3.3 5/11 ou consultez votre fournisseur de services Oracle.

• Pour connaître les instructions et procédures concernant l’application de patchs, reportez-vous au Chapitre 11, Mise à jour du logiciel ou installation d’un microprogramme Oracle Solaris Cluster du Guide d’administration système d’Oracle Solaris Cluster.

Adresses IP de réseau public

Pour plus d’informations sur l’utilisation de réseaux publics par le cluster, reportez-vous à la section Public Network Adapters and IP Network Multipathing du Oracle Solaris Cluster Concepts Guide .

Vous devez configurer un certain nombre d’adresses IP de réseau public pour plusieurs composants Oracle Solaris Cluster, en fonction de votre configuration en cluster. Chaque hôte Solaris de la configuration en cluster doit disposer d’au moins une connexion de réseau public vers le 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 nommage utilisé

• Le fichier local /etc/inet/hosts sur chaque nœud de cluster global, après l’installation du logiciel 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 Nombre d’adresses IP nécessaires Console d’administration 1 adresse IP par sous-réseau Nœud de cluster global 1 adresse IP par nœud et par sous-réseau Nœuds de cluster de zones 1 adresse IP par nœud et par sous-réseau Interface réseau de la console du domaine (Sun Fire 15000) 1 adresse IP par domaine (Facultatif) Zones non globales 1 adresse IP par sous-réseau Périphérique d’accès par console 1 adresse IP Adresses logiques 1 adresse IP par ressource d’hôte logique et par sous-réseau

Pour plus d'informations sur la planification des adresses IP, reportez-vous au Chapitre 2, Planification de votre réseau TCP/IP (tâches) du Guide d’administration système : services IP.

Périphériques d’accès par console

Vous devez bénéficier d’un accès par console à tous les nœuds de cluster. Si vous installez le logiciel Cluster Control Panel sur une console d’administration, vous devez fournir le nom d’hôte et le numéro de port du périphérique d’accès par console utilisé pour communiquer avec les nœuds du cluster.

• Un concentrateur de terminaux est utilisé pour la communication entre la console d’administration et les consoles de nœuds du cluster global.

• Un serveur Sun Enterprise 10000 utilise un processeur de services système au lieu d’un concentrateur de terminaux.

• Un serveur Sun Fire utilise un contrôleur système au lieu d’un concentrateur de terminaux.

Pour plus d’informations sur l’accès par console, reportez-vous au Oracle Solaris Cluster Concepts Guide.

Si vous connectez une console d’administration directement aux nœuds de cluster ou par le biais d’un réseau de gestion, vous fournissez à la place le nom d’hôte de chaque nœud de cluster global et son numéro de port série utilisé pour se connecter à la console d’administration ou au réseau de gestion.

Adresses logiques

Chaque groupe de ressources de service de données utilisant une adresse logique doit avoir un nom d’hôte spécifié pour chaque réseau public permettant 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 de données et les ressources, reportez-vous également au Oracle Solaris Cluster Concepts Guide.

Réseaux publics

Les réseaux publics communiquent en dehors du cluster. Prenez en compte les 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 nœuds 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 nœuds 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 nœuds 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.

• Groupe IPMP – Chaque adaptateur du réseau public utilisé pour le trafic de service de données doit appartenir à un groupe Multiacheminement 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 à adaptateurs multiples pour chaque ensemble d’adaptateurs de réseau public du cluster qui utilise 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. Mais les groupes IPMP basés sur une sonde, qui teste l’adresse IP cible, offrent une protection supérieure en reconnaissant 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 configurer les groupes IPMP, suivez la procédure de la section Partie VI, IPMP du Guide d’administration système : services IP. Pour modifier les groupes IPMP après l’installation de cluster, suivez les instructions de la section Administration des groupes de multiacheminement sur réseau IP dans un cluster du Guide d’administration système d’Oracle Solaris Cluster et les procédures du Chapitre 31, Administration d’IPMP (tâches) du Guide d’administration système : services IP.

• Prise en charge des adresses MAC locales – Tous les adaptateurs de réseau public doivent utiliser des cartes 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 (Vrai) pour les adaptateurs Ethernet. Le logiciel Oracle Solaris Cluster n’autorise pas la définition de la valeur local-mac-address? sur false pour les adaptateurs Ethernet.

Pour plus d’informations sur les interfaces de réseau public, reportez-vous à la section Oracle Solaris Cluster Concepts Guide.

Serveurs de quorum

Vous pouvez utiliser le logiciel Quorum Server de 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 nœud de cluster global.

• Système d’exploitation – La configuration Solaris requise par le logiciel Oracle Solaris Cluster s’applique également au logiciel du serveur de quorum.

• Prise en charge des zones non globales - Un serveur de quorum peut être installé et configuré dans une zone non globale.

• Service à des clusters multiples – Vous pouvez configurer un serveur de quorum en tant que périphérique de quorum pour plusieurs clusters.

• Combinaison matérielle et logicielle – Il n’est pas nécessaire de configurer un serveur de quorum sur la même plate-forme matérielle et logicielle que le ou les clusters auxquels elle fournit le quorum. Par exemple, une machine SPARC exécutant le SE Solaris 10 peut être configurée en tant que serveur de quorum pour un cluster x86 exécutant le SE Solaris 10.

• 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 de serveur de quorum s’exécutera.

• Utilisation d’un nœud de cluster en tant de serveur de quorum – Vous pouvez configurer un serveur de quorum sur un nœud de cluster pour fournir un quorum aux clusters autres que le cluster auquel le nœud appartient. Cependant, un serveur de quorum configuré sur un nœud de cluster n’est pas hautement disponible.

Directives concernant NFS

Prenez en compte les 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 nœud Oracle Solaris Cluster ne peut être un client NFS pour un système de fichiers exporté par Oracle Solaris Cluster HA pour NFS (HA pour NFS) géré sur un nœud de ce même cluster. Ce montage croisé de HA pour NFS est interdit. Utilisez le système de fichiers du cluster pour partager les fichiers entre les nœuds du cluster global.

• Protocole NFSv3 – Si vous montez des systèmes de fichiers sur les nœuds 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 nœud 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 nœuds 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 verrouillage (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. Le comportement serait alors 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 :

  • 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 nœuds de cluster.

  • L’utilisation de Kerberos avec NFS. Pour plus d'informations, reportez-vous à la section Securing HA for NFS With Kerberos V5 du 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.

Restrictions de service

Prenez en compte les restrictions de service suivantes pour les configurations Oracle Solaris Cluster :

• Routeurs – Ne configurez pas des nœuds 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 nœuds 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 nœuds du cluster.

• Serveurs NIS+ – Ne configurez pas de nœuds de cluster en tant que serveurs NIS ou NIS+. Aucun service de données n’est disponible pour NIS ou NIS+. Cependant, des nœuds de cluster peuvent être des clients NIS ou NIS+.

• Serveurs d’initialisation et d’installation – N’utilisez pas une configuration Oracle Solaris Cluster pour fournir un service d’initialisation ou d’installation hautement disponible sur les systèmes client.

• RARP – N’utilisez pas une configuration Oracle Solaris Cluster pour fournir un service rarpd.

• Numéros du programme RPC – Si vous installez un service RPC sur le cluster, le service 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.

  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 nœuds de cluster. N’exécutez pas les types de processus suivants sur les nœuds 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 (Network Time Protocol)

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 nœuds du cluster doivent être synchronisés sur la même heure.

• Précision – L’importance de la précision de l’heure sur les nœuds individuels est secondaire par rapport à la synchronisation de l’heure d’un nœud à l’autre. Vous êtes libre de configurer NTP selon vos besoins si cette condition de synchronisation est respectée.

• Message d’erreur concernant les nœuds non existants – À moins que vous ayez installé le fichier /etc/inet/ntp.conf, la commande scinstall installe pour vous un fichier ntp.conf par défaut. Le fichier par défaut est envoyé avec des références à un nombre maximal de nœuds. Par conséquent, il se peut que le démon xntpd(1M) génère des messages d’erreur concernant certaines de ces références au moment de l’initialisation. Vous pouvez ignorer ces messages. Reportez-vous à la section Configuration du protocole NTP pour plus d’informations sur la façon de supprimer ces messages dans des conditions de cluster normales.

Pour plus d’informations sur l’heure des clusters, reportez-vous au Oracle Solaris Cluster Concepts Guide. Pour savoir comment configurer le protocole NTP d'une configuration Oracle Solaris Cluster, reportez-vous au fichier de modèle /etc/inet/ntp.cluster.

Composants Oracle Solaris Cluster configurables

Cette section contient des directives concernant les composants Oracle Solaris Cluster que vous configurez :

• Nom du cluster global

• Noms de nud votant de cluster global et ID de nud

• Noms de zones

• Réseau privé

• Noms d'hôte privé

• Interconnexion de cluster

• Séparation globale

• Périphériques de quorum

Ajoutez cette information à la fiche de planification de configuration appropriée.

Nom du cluster global

Spécifiez un nom pour le cluster global au cours de la configuration de 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.

Noms de nœud votant de cluster global et ID de nœud

Le nom d’un nœud votant dans un cluster global est identique au nom que vous assignez à l’hôte physique ou virtuel lorsque vous l’installez sur le système d’exploitation Solaris. Reportez-vous à la page de manuel hosts(4) pour plus d’informations sur les conventions de nommage.

Pour l’installation d’un cluster à hôte unique, le nom de cluster par défaut est le nom du nœud votant.

Au cours de la configuration de Oracle Solaris Cluster, vous devez spécifier le nom des nœuds votants que vous installez dans le cluster global.

Un numéro d'ID de nœud est assigné à chaque nœud de cluster à usage interne du cluster. Cette numérotation démarre à partir du chiffre 1. Les numéros d'ID de nœud sont assignés à chaque nœud de cluster selon leur ordre d'entrée dans le cluster. Si vous configurez tous les nœuds du cluster en une seule opération, le nœud à partir duquel vous exécutez l'utilitaire scinstall correspond au dernier nœud auquel un numéro d'ID de nœud a été assigné. Vous ne pouvez pas modifier le numéro d'ID d'un nœud après avoir assigné ce dernier à un cluster.

Lorsqu'un nœud devient membre du cluster, il reçoit le numéro d'ID de nœud le plus petit possible. Si un nœud est supprimé du cluster, son ID peut être assigné à un nouveau nœud. Par exemple, dans un cluster composé de quatre nœuds, si le nœud renvoyant l'ID de nœud 3 est supprimé et si un nœud est ajouté, l'ID assigné au nouveau nœud est égal à 3 et non pas à 5.

Si vous souhaitez que les numéros d'ID de nœud assignés correspondent à certains nœuds de cluster, configurez les nœuds de cluster un par un dans l'ordre dans lequel vous souhaitez assigner les numéros d'ID de nœud. Par exemple, pour assigner le numéro 1 à l'ID de nœud du logiciel du cluster dans la propriété phys-schost-1, configurez ce nœud en tant que nœud comme nœud de cautionnement du cluster. Si vous ajoutez ensuite la propriété phys-schost-2 au cluster établit par la propriété phys-schost-1, l'ID de nœud 2 est assigné à la propriété phys-schost-2.

Pour plus d’informations sur les noms de nœud dans un cluster de zones, reportez-vous à la section Clusters de zones.

Noms de zones

Une zone non globale portant la marque native constitue un nœud potentiel valide faisant partie de la liste de nœuds d'un groupe de ressources. Utilisez la convention de nommage nodename:zonename pour spécifier une zone non globale dans une commande Oracle Solaris Cluster.

• nodename correspond au nom de l’hôte Solaris.

• zonename correspond au nom que vous assignez à la zone non globale lorsque vous créez la zone sur le nœud votant. La zone doit être unique sur le nœud. Cependant, vous pouvez utiliser le même nom de zones sur différents nœuds votants. Le nom de nœud différent dans nodename:zonename rend le nom de zones non globale unique dans le cluster.

Pour spécifier la zone globale, vous devez spécifier uniquement le nom du nœud votant.

Pour plus d’informations sur les clusters de zones non globales, reportez-vous à la section Clusters de zones.

Vous pouvez désactiver les fonctionnalités de cluster sur une zone non globale sélectionnée. Un utilisateur racine connecté à l'une de ces zones ne peut pas découvrir ou interrompre le fonctionnement du cluster. Pour obtenir des instructions supplémentaires, reportez-vous à

Réseau privé

Le logiciel Oracle Solaris Cluster utilise le réseau privé pour la communication interne entre les nœuds 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 nœud du cluster, vous spécifiez l’adresse et le masque de réseau du réseau privé de l’une des façons suivantes :

• 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 nœuds votants et de zones non globales, 12 zones de clusters et 10 réseaux privés.

  ---

  Remarque - Le nombre maximal de nœuds votants qu’une plage d’adresses IP peut accepter ne reflète pas le nombre maximal de nœuds 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 nœuds 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 nœuds 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 nœuds, 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 nœuds, 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 nœuds, 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 sous-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 nœuds et de réseaux privés que vous indiquez dans l’utilitaire.

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. Par contre, vous ne pouvez pas utiliser l’adresse de réseau privé 172.16.10.0 avec le masque de réseau 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 des clusters multiples – Vous pouvez utiliser la même adresse de réseau privé dans plus d’un cluster, à la 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 Sun Logical Domains (LDoms) 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 est visible par l’ensemble d’entre eux. 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. Vous ne devez pas configurer un adaptateur VLAN pour chaque cluster. Toutefois, si vous limitez l'utilisation d'un adaptateur VLAN à un seul cluster, vous isolerez plus facilement les erreurs et vous obtiendrez une meilleure résilience d'interconnexion.

• 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. La communication internodale sur le réseau privé n’utilise pas ces adresses IPv6.

Pour plus d’informations sur les réseaux privé, reportez-vous à la section Chapitre 2, Planification de votre réseau TCP/IP (tâches) du Guide d’administration système : services IP.

Noms d’hôte privé

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ôte privé 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ôte privé respectent la convention de nommage clusternode nodeid -priv, où nodeid correspond à la partie numérique de l’ID du nœud interne. Au cours de la configuration de Oracle Solaris Cluster, le numéro d’ID de nœud est automatiquement assigné à chaque nœud votant lorsque le nœud devient un membre de cluster. Un nœud votant du cluster global et un nœud 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 ces 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 nœud 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 nœuds 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 l’objectif et la fonction de l’interconnexion de cluster, reportez-vous à la section Cluster Interconnect du Oracle Solaris Cluster Concepts Guide.

Pendant la configuration de Oracle Solaris Cluster, vous devez spécifier les informations de configuration d'une ou deux interconnexions du 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.

• 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.

Vous pouvez configurer des interconnexions de cluster supplémentaires (six maximum) une fois le cluster établi, à 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 Oracle Solaris Cluster 3.3 Hardware Administration Manual. Pour obtenir des informations générales sur l'interconnexion de cluster, reportez-vous à la section Cluster Interconnect du 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 VLAN de l’une des façons suivantes :

  • Spécifiez le nom de l’adaptateur habituel, qui correspond au nom du périphérique suivi du numéro d’instance ou du point physique de connexion. Par exemple, le nom de l’instance 2 d’un adaptateur Cassini Gigabit Ethernet serait ce2. Si l’utilitaire scinstall demande si l’adaptateur fait partie d’un LAN virtuel partagé, répondez yes (oui) et spécifiez le numéro VID de l’adaptateur.

  • Spécifiez l’adaptateur par son nom d’adaptateur 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 correspond au numéro VID (identifiant VLAN) et N est 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 adaptateur VLAN dans un cluster, reportez-vous à la section Configuring VLANs as Private Interconnect Networks du Oracle Solaris Cluster 3.3 Hardware Administration Manual. Pour des informations générales sur le VLAN, reportez-vous à la section Administration de réseaux locaux virtuels du Guide d’administration système : services IP.

• SPARC : domaines invités Sun Logical Domains – Spécifiez le nom des adaptateurs virtuel comme suit :vnetN. Par exemple : 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 de pages de manuel scconf_trans_adap_*(1M) pour plus d’informations sur un adaptateur de transport spécifique.

Commutateurs de transport

Si vous utilisez des commutateurs de transport, tel 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 nœud interne de l’hôte Solaris hébergeant l’adaptateur du câble. Cependant, vous ne pouvez pas utiliser le nom de port par défaut pour certains types d’adaptateur.

Si votre cluster à deux hôtes est connecté directement, vous pouvez néanmoins spécifier un commutateur de transport pour l’interconnexion.

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 la séparation globale activée et chaque disque partagé de la configuration utilise le paramètre de séparation globale par défaut de pathcount. Avec le paramètre pathcount, le protocole de séparation pour chaque disque partagé est choisi en fonction du nombre de chemins DID liés au disque.

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. Cependant, vous pouvez désactiver la séparation globale pour faire face aux situations 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 Oracle Solaris Cluster Concepts Guide. Pour plus d’informations sur la définition du 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 nœud votant, le périphérique de quorum permet de prévenir des problèmes d’amnésie ou de "split-brain" lorsque le nœud de cluster de vote tente de rejoindre le cluster. Pour plus d’informations sur l’objectif et la fonction des périphériques de quorum, reportez-vous à la section Quorum and Quorum Devices du 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 en tant de périphérique de quorum un disque partagé disponible dans la configuration. Les disques partagés incluent tout périphérique NAS Sun 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, un périphérique NAS Oracle Sun Storage 7000 Unified Storage System ou un périphérique NAS pour solution réseau, configurez-le une fois le traitement de la commande scinstall terminé.

Après l’installation, vous pouvez également configurer des périphériques de quorum supplémentaires par le biais de l’utilitaire clsetup(1CL).

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 utiliser l’utilitaire clsetup pour configurer le quorum manuellement.

Prenez en compte les 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 plus d’un périphérique de quorum est configuré dans un cluster à deux nœuds 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.

• 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 nœuds votants. Cependant, les nœuds ne peuvent pas former un cluster si tous les périphériques de quorum sont indisponibles, même si tous les nœuds fonctionnent.

• Connexion – Vous devez connecter un périphérique de quorum à au moins deux nœuds 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 nœuds votants 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 être également utilisé par des disques partagés SCSI si la séparation est désactivée pour de tels 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 Oracle Solaris Cluster Concepts Guide.

Clusters de zones

Un cluster de zones est un cluster comprenant des zones de conteneurs Solaris non globales. Tous les nœuds d’un cluster de zones sont configurés en tant que zones non globales de la marque 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 Solaris.

Prenez en compte les points suivants lorsque vous planifiez la création d’un cluster de zones.

• Conditions requises et directives concernant le cluster global

• Conditions requises et directives concernant le cluster de zones

• Directives pour Trusted Extensions dans un cluster de zones

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 nœud votant du cluster global à partir duquel vous avez créé ou modifié un cluster de zones doit être en mode cluster. Si les autres nœuds votants sont en mode non cluster lorsque vous gérez un cluster de zones, les modifications apportées sont propagées à ces nœuds lorsqu’ils repassent en mode cluster.

• Adresses IP privées appropriés – 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 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 Solaris (cNtXdYsZ)

  • Périphériques DID (/dev/did/*dsk/dN)

  • Ensembles de disques multipropriétaires Solaris Volume Manager et Solaris Volume Manager pour Sun Cluster (/dev/md/setname/*dsk/dN)

Conditions requises et directives concernant le cluster de zones

• Répartition de nœuds – Vous ne pouvez pas héberger plusieurs nœuds du même cluster de zones sur la même machine hôte. Un hôte peut prendre en charge plusieurs nœud de clusters de zones tant que chaque nœud de clusters de zones de cet hôte fait partie d'un cluster de zones différent.

• Création de nœud – Vous devez créer au moins un nœud de cluster de zones au moment de créer le cluster de zones. Le nom de chaque nœud 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 nœud 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 nœud de cluster de zones.

  ---

  Remarque - Si vous ne configurez pas d'adresse IP pour chaque nœud de cluster de zones, deux événements se produisent :

  • Cette zone de cluster spécifique ne sera pas en mesure de configurer les périphériques NAS en vue de leur utilisation dans le cluster de zones. Le cluster utilise l'adresse IP du nœud de cluster de zones lors de la communication avec le périphérique NAS, de sorte que l'absence d'adresse IP empêche le cluster de pouvoir séparer les périphériques NAS.

  • Le logiciel de gestion du cluster activera l'adresse IP de n'importe quel hôte logique sur n'importe quelle carte d'interface réseau.

  ---

• Noms d’hôte privé – Au cours de la création du cluster de zones, un nom d’hôte privé est automatiquement créé pour chaque nœud du cluster de zones, de la même façon que les noms d’hôte sont créés dans les clusters globaux. Il vous est actuellement impossible de renommer le nom d’hôte privé d’un nœud de cluster de zones. Pour plus d’informations sur les noms d’hôte privé, reportez-vous à la section Noms d'hôte privé.

• Marque de zones Solaris – Tous les nœuds d’un cluster de zones sont configurés en tant que zones non globales de la marque cluster. Aucun autre type de marque n’est autorisé dans un cluster de zones.

• 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 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 nœud de cluster de zones – Vous ne pouvez pas ajouter à un cluster de zones une zone non globale se trouvant en dehors de ce dernier. Vous devez utiliser uniquement la commande clzonecluster pour ajouter des nœuds à un cluster de zones.

• Systèmes de fichiers – Vous pouvez utiliser la commande clzonecluster pour ajouter les types de systèmes de fichiers suivants qu’un cluster de zones peut utiliser. 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.

  • Montage direct :

    • Systèmes de fichiers local UFS

    • Systèmes de fichiers local VxFS

    • Systèmes de fichiers autonome QFS

    • Systèmes de fichiers partagés QFS (uniquement lorsqu’ils sont utilisés pour prendre en charge Oracle RAC (Real Application Clusters))

    • Systèmes de fichiers ZFS (exporté en tant qu'ensemble de données)

    • Systèmes de fichiers NFS à partir de périphériques NAS pris en charge

  • Montage loopback :

    • Systèmes de fichiers local UFS

    • Systèmes de fichiers local VxFS

    • Systèmes de fichiers autonome QFS

    • Systèmes de fichiers partagé QFS (uniquement lorsqu’ils sont utilisés pour prendre en charge Oracle RAC (Real Application Clusters))

    • Systèmes de fichiers de cluster UFS

    • Systèmes de fichiers de cluster VxFS

  Vous pouvez configurer 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

Prenez en compte les points suivants lorsque vous utilisez la fonction Trusted Extensions d'Oracle Solaris dans un cluster de zones :

• Prise en charge dans un cluster de zones uniquement – Dans une configuration Oracle Solaris Cluster avec la fonction Trusted Extensions activée, les applications doivent être exécutées uniquement dans un cluster de zones. Aucune autre zone non globale ne peut être utilisée sur le cluster. Vous devez utiliser 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 la fonction Trusted Extensions est activée.

• Étendue de la fonction Trusted Extensions – Vous pouvez activer ou désactiver la fonction Trusted Extensions pour toute la configuration du cluster. Lorsque la fonction Trusted Extensions est activée, toutes les zones non globales de votre configuration de cluster doivent appartenir à un cluster de zones. Vous ne pouvez configurer aucun autre type de zone non globale sans compromettre la sécurité.

• Adresses IP – Chaque cluster de zones utilisant la fonction Trusted Extensions doit utiliser ses propres adresses IP. La fonction de mise en réseau spéciale dans Trusted Extensions permettant 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 utiliser des montages loopback disposant d'autorisations en écriture dans un cluster de zones utilisant la fonction Trusted Extensions. Utilisez uniquement des points de montage directs sur les systèmes de fichiers permettant un accès en écriture ou utilisez des points de montage loopback permettant uniquement un accès en lecture seule.

• Systèmes de fichiers – Ne configurez pas dans le cluster de zones le périphérique global se trouvant en dessous d'un système de fichiers. Vous ne devez configurer que le système de fichiers dans le cluster de zones.

• Nom de périphérique de stockage – N'ajoutez pas une tranche individuelle d'un périphérique de stockage à un cluster de zones. Vous devez ajouter le périphérique en entier à un cluster de zones unique. L'utilisation de tranches du même périphérique de stockage dans plusieurs clusters de zones compromet la sécurité de ces derniers.

• Installation d'applications – Installez les applications uniquement dans le cluster de zones ou dans le cluster global, puis exportez-les vers le cluster de zones en utilisant des points de montage loopback en lecture seule.

• Isolation de cluster de zones – Lorsque la fonction Trusted Extensions est utilisée, le nom d'un cluster de zones correspond à une étiquette de sécurité. Dans certains cas, l'étiquette de sécurité peut elle-même contenir également des informations qui ne doivent pas être dévoilées. Le nom d'une ressource ou d'un groupe de ressources peut constituer une information sensible qui ne doit pas être dévoilée. Lorsqu'une dépendance ou une affinité de ressource entre clusters est configurée, le nom de l'autre cluster s'affiche également, ainsi que le nom de toutes les ressources ou de tous les groupes de ressources affectés. Par conséquent, avant d'établir des relations entre les clusters, vérifiez si ces informations peuvent être mises à disposition, selon vos besoins.