Services de données

Le terme service de données décrit une application tiers telle qu'Oracle ou Sun ONE Web Server, configurée pour fonctionner sur un cluster plutôt que sur un seul serveur. Un service de données se compose d'une application, de fichiers de configuration Sun Cluster spécialisés et de méthodes de gestion Sun Cluster contrôlant les actions suivantes de l'application :

• le démarrage ;

• l'arrêt ;

• le contrôle et la prise de mesures correctives.

La Figure 3–4 compare une application fonctionnant sur un seul serveur d'applications (modèle de serveur unique) à la même application fonctionnant sur un cluster (modèle de serveur clusterisé). Notez que du point de vue de l'utilisateur, il n'y a aucune différence entre les deux configurations si ce n'est que l'application clusterisée peut être plus rapide et que son niveau de disponibilité est plus élevé.

Figure 3–4 Configuration standard et configuration client/serveur clusterisée

Dans le modèle de serveur unique, l'application est configurée pour accéder au serveur à travers une interface de réseau public particulière (nom d'hôte). Le nom d'hôte est associé à ce serveur physique.

Dans le modèle de serveur clusterisé, l'interface de réseau public est un nom d'hôte logique ou une adresse partagée. Le terme ressources réseau se rapporte à la fois aux noms d'hôtes logiques et aux adresses partagées.

Certains services de données vous demandent de spécifier soit les noms d'hôtes logiques, soit les adresses partagées comme interfaces réseau : ils ne sont pas interchangeables. D'autres services de données vous permettent de spécifier les noms d'hôtes logiques comme les adresses partagées. Reportez-vous à l'installation et à la configuration de chaque service de données pour déterminer plus précisément le type d'interface que vous devez spécifier.

Une ressource réseau n'est pas associée à un serveur physique spécifique : elle peut se déplacer entre les serveurs physiques.

Une ressource réseau est initialement associée à un noeud, le noeud principal. Si le noeud principal échoue, la ressource réseau et la ressource d'application basculent sur un autre noeud du cluster (noeud secondaire). Lorsque la ressource réseau bascule, la ressource d'application continue de fonctionner sur le noeud secondaire après un bref laps de temps.

La Figure 3–5 compare le modèle de serveur unique au modèle de serveur clusterisé. Notez que dans le modèle de serveur clusterisé, une ressource réseau (nom d'hôte logique dans cet exemple) peut se déplacer entre plusieurs noeuds du cluster. L'application est configurée pour utiliser ce nom d'hôte logique à la place d'un nom d'hôte associé à un serveur particulier.

Figure 3–5 Nom d'hôte fixe et nom d'hôte logique

Une adresse partagée est aussi initialement associée à un noeud. Ce noeud s'appelle le noeud d'interface globale (ou noeud GIF) . Une adresse partagée est utilisée comme interface de réseau simple vers le cluster. Elle est connue sous le nom d'interface globale.

La différence entre le modèle de nom d'hôte logique et le modèle de service évolutif est que dans ce dernier, chaque noeud possède aussi une adresse partagée activement configurée sur son interface de bouclage. Cette configuration permet d'avoir plusieurs instances d'un service de données actives sur plusieurs noeuds simultanément. Le terme « service évolutif » signifie que vous pouvez augmenter la puissance de calcul de l'application en ajoutant des noeuds de cluster supplémentaires afin d'améliorer les performances.

En cas d'échec du noeud GIF, l'adresse partagée peut être mise sur un autre noeud où tourne aussi une instance de l'application (faisant ainsi de cet autre noeud le nouveau noeud GIF). L'adresse partagée peut également basculer sur un autre noeud du cluster n'ayant pas exécuté l'application auparavant.

La Figure 3–6 compare la configuration de serveur unique à la configuration de service évolutif clusterisé. Notez que dans la configuration service évolutif, l'adresse partagée est présente sur tous les noeuds. De la même façon qu'un nom d'hôte logique est utilisé dans un service de données à basculement, l'application est configurée pour utiliser cette adresse partagée à la place d'un nom d'hôte associé à un serveur particulier.

Figure 3–6 Nom d'hôte fixe et adresse partagée

Méthodes de services de données

Le logiciel Sun Cluster intègre un ensemble de méthodes de gestion de services. Ces méthodes fonctionnent sous le contrôle du Gestionnaire du groupe de ressources (RGM), qui les utilise pour démarrer, arrêter et contrôler l'application sur les noeuds du cluster. Ces méthodes, avec les logiciels de cluster et les disques multihôtes, permettent aux applications de devenir des services de données évolutifs ou de basculement.

Le gestionnaire du groupe de ressources (RGM) gère aussi les ressources du cluster, notamment les instances d'une application et les ressources réseau (noms d'hôtes logiques et adresses partagées).

En plus des méthodes fournies par le logiciel Sun Cluster, le système SunPlex intègre également une API (interface de programme d'application) et plusieurs outils de développement de services de données. Ces outils permettent aux programmeurs de développer les méthodes de services de données nécessaires pour que les autres applications fonctionnent comme des services de données à haute disponibilité avec le logiciel Sun Cluster.

Services de données de basculement

Si le noeud sur lequel le service de données fonctionne (noeud principal) échoue, le service est déplacé vers un autre noeud opérationnel sans intervention de l'utilisateur. Les services de basculement utilisent un groupe de ressources de basculement contenant les ressources des instances d'application et les ressources réseau (noms d'hôtes logiques). Les noms d'hôtes logiques sont des adresses IP pouvant être configurées sur un noeud puis automatiquement retirées pour être configurées sur un autre noeud.

Avec les services de données, les instances d'application ne tournent que sur un seul noeud. Si le détecteur de pannes rencontre une erreur, il essaie soit de redémarrer l'instance sur le même noeud, soit de la démarrer sur un autre noeud (basculement), selon la configuration du service de données.

Services de données évolutifs

Le service de données évolutif permet d'avoir des instances fonctionnant sur plusieurs noeuds. Les services évolutifs utilisent deux groupes de ressources : un groupe de ressources évolutif contenant les ressources d'application, et un groupe de ressources de basculement contenant les ressources réseau (adresses partagées) dont dépend le service évolutif. Le groupe de ressources évolutif peut être connecté à plusieurs noeuds, permettant ainsi à plusieurs instances du service de fonctionner en même temps. Le groupe de ressources de basculement hébergeant les adresses partagées ne peut être connecté qu'à un seul noeud à la fois. Tous les noeuds hébergeant un service évolutif utilisent la même adresse partagée pour héberger le service.

Les demandes de services arrivent au cluster à travers une interface réseau unique (interface globale) et sont réparties entre les noeuds en fonction de l'un des algorithmes prédéfinis par la règle d'équilibrage de la charge. Le cluster peut utiliser cette règle pour équilibrer la charge de service entre plusieurs noeuds. Notez qu'il peut y avoir plusieurs interfaces globales sur des noeuds différents hébergeant d'autres adresses partagées.

Avec les services évolutifs, les instances d'application tournent sur plusieurs noeuds en même temps. Si le noeud hébergeant l'interface globale échoue, celle-ci bascule sur un autre noeud. Si une instance d'application en cours de fonctionnement échoue, elle essaie de redémarrer sur le même noeud.

S'il lui est impossible de redémarrer sur le même noeud et qu'un autre noeud non utilisé est configuré pour exécuter le service, celui-ci bascule sur le noeud non utilisé. Si aucun noeud n'est disponible, l'instance d'application continue de fonctionner sur les noeuds restants et peut ainsi entraîner une dégradation des performances du service.

l'état TCP de chaque instance d'application est conservé sur le noeud contenant l'instance et non sur le noeud d'interface globale. Ainsi, l'échec du noeud d'interface globale n'a pas d'incidence sur la connexion.

La Figure 3–7 montre un exemple de groupe de ressources évolutif et de groupe de ressources de basculement avec leurs dépendances dans le cadre de services évolutifs. Cet exemple présente trois groupes de ressources. Le groupe de ressources de basculement contient les ressources d'application des serveurs DNS à haute disponibilité et les ressources réseau utilisées à la fois par les serveurs DNS et les serveurs Web Apache à haute disponibilité. Les groupes de ressources évolutifs ne contiennent que les instances d'application du serveur Web Apache. Notez qu'il existe des dépendances entre les groupes de ressources évolutifs et de basculement (lignes continues) et que toutes les ressources d'application Apache dépendent de la ressource réseau schost-2, qui est une adresse partagée (ligne en trait tireté).

Figure 3–7 Exemple de groupe de ressources évolutif et de basculement

Architecture de service évolutif

L'objectif principal d'un réseau en cluster est de fournir de l'évolutivité aux services de données. L'évolutivité signifie qu'en dépit de l'accroissement de la charge offerte à un service, celui-ci peut maintenir un temps de réponse constant grâce à l'ajout de nouveaux noeuds au cluster et à l'exécution de nouvelles instances de serveur. Ce service est appelé service de données évolutif. Un service Web est un bon exemple de ce type de service. Un service de données est généralement composé de plusieurs instances tournant chacune sur des noeuds différents du cluster. Ensemble, ces instances se comportent comme un service unique du point de vue d'un client distant et implémentent la fonctionnalité du service. On peut par exemple avoir un service Web évolutif composé de plusieurs démons httpd fonctionnant sur des noeuds différents. Chaque démon httpd peut servir une requête client. Le démon servant la requête dépend d'une règle d'équilibrage de la charge. La réponse au client semble venir du service, et non du démon servant la requête, et l'apparence d'un service unique est ainsi préservée.

Un service évolutif comporte :

• la prise en charge d'infrastructures de réseau pour les services évolutifs ;

• l'équilibrage de la charge ;

• la prise en charge de services de données et de gestion de réseaux (à l'aide du Gestionnaire du groupe de ressources).

La figure suivante représente l'architecture d'un service de données évolutif :

Figure 3–8 Architecture d'un service de données évolutif

Les noeuds n'étant pas hébergés par l'interface globale (noeuds proxy) hébergent l'adresse partagée sur leur interface de bouclage. Les paquets arrivant dans l'interface globale sont distribués à d'autres noeuds du cluster en fonction des règles d'équilibrage de la charge configurables. Les différentes règles d'équilibrage de la charge sont décrites ci-dessous.

Règles d'équilibrage de la charge

L'équilibrage de la charge permet d'améliorer les performances du service évolutif, tant en matière de temps de réponse que de rendement.

Il existe deux classes de services de données évolutifs : pur et sticky. Sur un service pur, n'importe quelle instance peut répondre aux requêtes du client. Sur un service sticky, le client envoie les requêtes à la même instance. Ces dernières ne sont pas redirigées vers d'autres instances.

Un service pur utilise une règle d'équilibrage de la charge pondérée. Sous cette règle, les requêtes du client sont réparties de manière uniforme entre les instances de serveur du cluster. Supposons par exemple que dans un cluster à trois noeuds, chaque noeud supporte une charge de 1. Chaque noeud servira 1/3 des requêtes d'un client pour le compte de ce service. Les charges peuvent être modifiées à tout moment par l'administrateur à l'aide de l'interface de la commande scrgadm(1M) ou de l'interface utilisateur graphique de gestion de SunPlex.

Un service sticky peut être de deux types : sticky ordinaire et sticky joker. Les services sticky permettent à plusieurs sessions d'application simultanées utilisant plusieurs connexions TCP de partager la mémoire d'état (état de la session d'application).

Les services sticky ordinaires permettent à un client de partager l'état entre plusieurs connections TCP simultanées. Le client est dit « sticky » par rapport à cette instance de serveur écoutant sur un seul port. Le client a la garantie que toutes ses requêtes vont vers la même instance de serveur, sous réserve que cette instance soit active et accessible et que la règle d'équilibrage de la charge ne soit pas modifiée alors que le service est en ligne.

Par exemple, un navigateur Web du client se connecte à une adresse IP partagée sur le port 80 en utilisant trois connexions TCP différentes, mais les connexions échangent entre elles des informations de session en mémoire cache lors de l'exécution du service.

La généralisation d'une règle sticky s'étend à plusieurs services évolutifs échangeant des informations de session en arrière-plan au même moment. Lorsque ces services échangent des informations de session en arrière plan au même moment, le client est dit « sticky » par rapport à ces multiples instances de serveur sur le même noeud écoutant sur des ports différents.

Par exemple, le client d'un site de commerce électronique remplit sa carte d'achats en utilisant le protocole HTTP ordinaire sur le port 80, mais il bascule vers le protocole SSL sur le port 443 pour envoyer les données sécurisées relatives au paiement de ces achats par carte de crédit.

Les services sticky joker utilisent des numéros de ports assignés de manière dynamique, mais attendent toujours des requêtes du client qu'elles aillent vers le même noeud. Le client est dit « sticky joker » sur les ports par rapport à la même adresse IP.

Un bon exemple de cette règle est le protocole FTP en mode passif. Un client se connecte à un serveur FTP sur le port 21 et est ensuite informé par le serveur de se connecter de nouveau à un serveur de ports d'écoute sur une plage de ports dynamiques. Toutes les requêtes pour cette adresse IP sont envoyées au même noeud ; celui que le serveur a désigné au client à travers les informations de contrôle.

Notez que pour chacune de ces règles sticky, la règle de la charge pondérée est activée par défaut, ainsi, la requête initiale d'un client est dirigée vers l'instance désignée par l'équilibreur de la charge. Après que le client a défini une affinité pour le noeud où fonctionne l'instance, les requêtes futures sont dirigées vers cette instance sous réserve que le noeud soit accessible et que la règle d'équilibrage de la charge ne soit pas modifiée.

Vous trouverez ci-après des détails complémentaires concernant des règles d'équilibrage de la charge spécifiques.

• Pondérée. La charge est répartie entre les différents noeuds en fonction de valeurs spécifiées. Cette règle est définie par la valeur équilibrage_lignes_pondéré de la propriété poids_équilibrage_lignes. Si la charge d'un noeud n'est pas explicitement définie, elle sera par défaut égale à 1.

  La règle pondérée redirige un certain pourcentage du trafic provenant des clients vers un noeud particulier. Si on a X = charge et A = la charge totale de tous les noeuds en activité, un noeud actif supportera approximativement X/A du total des nouvelles connexions, lorsque le nombre total de connexions est suffisamment élevé. Cette règle ne s'applique pas à des requêtes individuelles.

  Notez qu'elle ne fonctionne pas à tour de rôle. Si c'était le cas, chaque requête d'un client irait vers un noeud différent : la première requête vers le noeud 1, la seconde vers le noeud 2, etc.

• Sticky. Avec cette règle, l'ensemble de ports est connu au moment de la configuration des ressources d'application. Cette règle est définie par la valeur équilibrage_lignes_sticky de la propriété de la ressource règle_équilibrage_charge.

• Sticky joker. Cette règle est un sur-ensemble de la règle « sticky » ordinaire. Dans un service évolutif identifié par l'adresse IP, les ports sont assignés par le serveur (et ne sont pas connus à l'avance). Les ports peuvent varier. Cette règle est définie par la valeur équilibrage_lignes_sticky_joker de la propriété de la ressource règle_équilibrage_charge.

Paramètres de rétablissement

Les groupes de ressources basculent d'un noeud vers un autre noeud. Lorsque ce basculement se produit, le noeud secondaire d'origine devient principal. Les paramètres de rétablissement spécifient les actions qui auront lieu lorsque le noeud principal d'origine sera de nouveau en ligne. Vous pouvez soit autoriser le noeud principal d'origine à reprendre son rôle (rétablissement), soit permettre au noeud principal actuel de rester. L'option choisie peut être spécifiée à l'aide du paramètre rétablissement de la propriété du groupe de ressources.

Dans certains cas, si le noeud d'origine hébergeant le groupe de ressources échoue et se réinitialise souvent, la définition du paramètre de rétablissement pourrait réduire la disponibilité du groupe de ressources.

Détecteurs de pannes des services de données

Chaque service de données SunPlex intègre un détecteur de pannes sondant périodiquement le service de données pour vérifier son état. Un détecteur de pannes vérifie que le(s) démon(s) de l'application fonctionnent et que les clients sont servis. Sur la base des informations retournées par les sondes, des actions prédéfinies telles que le redémarrage des démons ou le déclenchement d'un basculement peuvent être initiées.