Composants configurables d'Oracle Solaris Cluster

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

• Nom du cluster global

• Noms de noeud de cluster global et ID de noeud

• Configuration du réseau privé

• Noms d'hôtes privés

• Interconnexion de cluster

• Séparation globale

• Périphériques de quorum

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.

Noms de noeud de cluster global et ID de noeud

Le nom d'un noeud 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.

Lors de l'installation d'un cluster à hôte unique, le nom du cluster par défaut correspond au nom du noeud.

Au cours de la configuration d'Oracle Solaris Cluster, vous devez spécifier le nom des noeuds que vous installez dans le cluster global. Le nom de noeud doit être le même que la sortie de la commande uname -n.

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 de noeud 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 renvoyant l'ID de noeud 3 est supprimé et si un noeud est ajouté, l'ID assigné au nouveau noeud est égal à 3 et non pas à 5.

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

Configuration du réseau privé

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 :

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

  ---

  Remarque -  Le nombre maximal de noeuds qu'une plage d'adresses IP peut accepter ne reflète pas le nombre maximal de noeuds 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.

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 des clusters multiples – 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.

• Oracle VM Server for SPARC - Lorsque des domaines invités sont 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. Vous ne devez pas configurer un VLAN distinct pour chaque cluster. Toutefois, pour optimiser l'isolation des erreurs et la résilience d'interconnexion, limitez l'utilisation d'un VLAN à un seul cluster.

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

Reportez-vous à la section Planification du développement du réseau dans Oracle Solaris 11.2 pour plus d'informations à propos des réseaux privés.

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 clusternode node-id -priv, où node-id correspond à la partie numérique de l'ID du noeud interne. Au cours de la configuration d'Oracle Solaris Cluster, un numéro d'ID de noeud est automatiquement assigné à un noeud lorsque celui-ci devient membre du cluster. Un noeud du cluster global et un noeud d'un cluster de zones peuvent tous deux porter 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 .

Pendant la configuration d'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.

Une fois le cluster établi, vous pouvez configurer des interconnexions de clusters supplémentaires (six maximum) à l'aide de l'utilitaire clsetup.

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 4.2 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, lesquelles sont requises sur les adaptateurs de réseau privé pour prendre en charge les adresses de réseau public IPv6 des services de données évolutifs, 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. Il faut exécuter la commande dladm create-vlan pour configurer l'adaptateur en tant qu'adaptateur VLAN avec balises avant de le configurer avec le cluster.

  Pour configurer un adaptateur VLAN avec balises pour l'interconnexion de cluster, spécifiez l'adaptateur en indiquant 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 net2, le numéro d'instance VLAN doit être calculé de la façon suivante : (1000*73)+2. Vous devez donc nommer l'adaptateur net73002 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 4.2 Hardware Administration Manual . Pour plus d'informations sur la création et l'administration des VLAN, reportez-vous à la page de manuel dladm(1M) et au Chapitre 3, Réseaux virtuels à l’aide de la configuration de réseaux locaux virtuels du manuel Gestion des liaisons de données réseau dans Oracle Solaris 11.2 .

• SPARC : Oracle VM Server for SPARCDomaines invités – Spécifiez les noms d'adaptateur en indiquant leur nom virtuel vnetN, comme vnet0 et vnet1. Les noms d'adaptateur virtuels sont enregistrés dans le fichier /etc/path_to_inst.

• Interfaces réseau logiques – L'usage des interfaces réseau logiques est réservé au logiciel Oracle Solaris Cluster.

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

Les clusters comprenant trois noeuds ou plus doivent utiliser des commutateurs de transport. La connexion directe entre les noeuds de cluster est prise en charge uniquement pour les clusters à deux hôtes. 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 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.

Si un périphérique ne parvient pas à utiliser le protocole SCSI-3, il convient d'utiliser plutôt le paramètre pathcount, où le protocole de séparation du disque partagé est choisi en fonction du nombre de chemins DID liés au disque. Les périphériques non SCSI-3 sont limités à deux chemins de périphérique DID au sein du cluster. La séparation peut être désactivée pour tous les périphériques qui ne prennent pas en charge la séparation SCSI-3 ou SCSI-2. Toutefois, l'intégrité des données pour ces périphériques ne peut pas être garantie dans les situations de split-brain.

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.

---

Mise en garde  -  Si vous désactivez la séparation dans d'autres situations que celles décrites dans le présent manuel, 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 protocole de séparation des disques partagés individuels, reportez-vous à la page de manuel cldevice(1CL). Pour plus d'informations sur la définition 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. En cas de déconnexion temporaire entre le cluster et un noeud, le périphérique de quorum permet de prévenir les problèmes d'amnésie ou de "split-brain" lorsque le noeud concerné 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 par 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. 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 ou un périphérique NAS d'Oracle ZFS Storage Appliance en tant que périphérique de quorum, configurez-le une fois que le processus scinstall est terminé.

Après l'installation, vous pouvez également configurer des périphériques de quorum supplémentaires à l'aide de l'utilitaire clsetup.

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 plus d'un périphérique de quorum est configuré 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.

• 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. Sinon, les noeuds ne peuvent pas former un cluster lorsque 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.

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

• Procotole de quorum 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 .