Utilisation de l'interconnexion de cluster pour le trafic applicatif

Les noeuds d'un cluster doivent être reliés par de multiples connexions, constituant l'interconnexion du cluster. Pour des raisons de haute disponibilité et de performances, le logiciel de cluster utilise de nombreuses interconnexions. Pour le trafic interne (par exemple, les données de fichiers système ou les données de services évolutifs), les messages sont répartis sur toutes les interconnexions disponibles à tour de rôle.

L'interconnexion de cluster est également mise à la disposition des applications pour offrir une communication haute disponibilité entre les noeuds. Par exemple, les composants d'une application distribuée peuvent s'exécuter sur différents noeuds et avoir besoin de communiquer les uns avec les autres. En utilisant l'interconnexion de cluster plutôt que l'interconnexion publique, ces connexions peuvent tolérer une défaillance sur une liaison individuelle.

Pour utiliser l'interconnexion de cluster pour ses communications, l'application doit adopter les noms d'hosts privés configurés lors de l'installation du cluster. Par exemple, si le nom d'host privé du noeud 1 est clusternode1-priv, utilisez ce nom pour communiquer sur l'interconnexion de cluster avec le noeud 1. Les sockets TCP ouverts à l'aide de ce nom sont acheminés sur l'interconnexion de cluster et peuvent être redirigés de manière totalement transparente en cas de défaillance du réseau.

Notez que, comme les noms d'host privés peuvent être configurés durant l'installation, l'interconnexion de cluster peut utiliser n'importe quel nom choisi à ce moment là. Le nom réel peut être obtenu à l'aide de la commande scha_cluster_get(3HA) suivie de l'argument scha_privatelink_hostname_node.

Pour utiliser l'interconnexion de cluster au niveau de l'application, une simple interconnexion est établie entre deux noeuds, mais des interconnexions distinctes sont utilisées entre les différentes paires de noeuds dans la mesure du possible. Supposons par exemple qu'une application exécutée sur trois noeuds communique sur l'interconnexion de cluster. La communication entre les noeuds 1 et 2 peut avoir lieu sur l'interface hme0 et la communication entre les noeuds 1 et 3 sur l'interface qfe1. Autrement dit, les communications de l'application entre deux noeuds sont limitées à une simple interconnexion, tandis que les communications internes du cluster sont réparties sur toutes les interconnexions.

Notez que l'application partage l'interconnexion avec le trafic interne du cluster et, de ce fait, que la bande passante à la disposition de l'application dépend de la bande passante utilisée par le reste du trafic. En cas de défaillance, le trafic interne est acheminé tour à tour sur les autres interconnexions, tandis que les connexions d'application sur une interconnexion défaillante peuvent être réacheminées sur une interconnexion en bon état de fonctionnement.

Deux types d'adresses supportent l'interconnexion de cluster et la commande gethostbyname(3N) exécutée sur un nom d'host privé renvoie normalement deux adresses IP. La première adresse est appelée adresse de paire logique et la seconde adresse "par noeud" logique.

Une adresse de paire logique distincte est attribuée à chaque paire de noeuds. Ce petit réseau logique prend en charge la reprise sur panne des connexions. Chaque noeud se voit également attribuer une adresse "par noeud" fixe. Autrement dit, l'adresse de paire logique de clusternode1-priv est différente pour chaque noeud, tandis que l'adresse "par noeud" logique de clusternode1-priv est la même pour chaque noeud. Un noeud ne comporte toutefois pas d'adresse de paire logique le désignant et, de ce fait, la commande gethostbyname(clusternoeud1-priv) exécutée sur le noeud 1 renvoie uniquement l'adresse "par noeud" logique.

Notez que les applications qui acceptent des connexions sur l'interconnexion du cluster et vérifient ensuite l'adresse IP pour des raisons de sécurité doivent procéder à une nouvelle vérification de toutes les adresses IP renvoyées par la commande gethostbyname, et non pas simplement la première.

Si votre application requiert des adresses IP permanentes pour tous les points, configurez-la pour qu'elle se lie à l'adresse "par noeud" du côté client et du côté serveur de sorte que toutes les connexions semblent provenir de et se diriger vers cette adresse "par noeud".