Services de données

Le terme service de données décrit une application telle qu'Oracle ou Sun Java System 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 :

• Début

• Arrêter

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

Pour plus d'informations sur les types de services de données, voir Services de données du Présentation de Sun Cluster pour SE Solaris.

La Figure 3–4 compare une application s'exécutant sur un seul serveur d'applications (modèle de serveur unique) à la même application s'exécutant sur un cluster (modèle de serveur clusterisé). La seule différence entre les deux configurations réside dans le fait que l'application clusterisée peut s'exécuter plus rapidement et avec un niveau supérieur de disponibilité.

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

Dans le modèle de serveur unique, vous configurez l'application pour accéder au serveur par le biais d'une interface de réseau public particulier (un 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 nécessitent que vous indiquiez des noms d'hôtes logiques ou des adresses partagées comme interfaces réseau. Les noms d'hôtes logiques et les adresses partagées 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. Pour plus d'informations sur le type d'interface que vous devez spécifier, reportez-vous à l'installation et à la configuration de chaque service de données.

Une ressource réseau n'est pas associée à un serveur physique particulier. Elle peut migrer entre des serveurs physiques.

Une ressource réseau est initialement associée à un nœud, le nœud principal. En cas de panne du nœud principal, la ressource réseau et la ressource d'application basculent sur un autre nœud du cluster (un nœud secondaire). Lorsque la ressource réseau bascule, la ressource d'application continue de fonctionner sur le nœud 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 nœuds 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 également associée initialement à un nœud. Ce nœud s'appelle le nœud d'interface globale. Une adresse partagée (également appelée interface globale) est utilisée comme interface de réseau unique sur le cluster.

Le modèle de nom d'hôte logique et le modèle de service évolutif diffèrent, car dans ce dernier, chaque nœud dispose également de l'adresse partagée, configurée de manière active dans son interface de loopback. Cette configuration permet à plusieurs instances d'un service de données de s'activer simultanément sur plusieurs nœuds. Le terme « service évolutif » signifie que vous pouvez augmenter la puissance de calcul de l'application en ajoutant des nœuds de cluster supplémentaires afin d'améliorer les performances.

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

La Figure 3–6 compare la configuration à 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 nœuds. 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 des services de données

Le logiciel Sun Cluster intègre un ensemble de méthodes de gestion de services. Ces méthodes s'exécutent sous le contrôle du produit Gestionnaire du groupe de ressources (RGM), qui les utilise pour démarrer, arrêter et contrôler l'application sur les nœuds du cluster. Ces méthodes, avec les logiciels de cluster et les périphériques 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).

Outre les méthodes du logiciel Sun Cluster, le système Sun Cluster fournit également une API et plusieurs outils de développement de services de données. Ces outils permettent aux développeurs d'applications de développer les méthodes de services de données nécessaires à l'exécution d'autres applications en tant que services de données hautement disponibles avec le logiciel Sun Cluster.

Services de données de basculement

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

Avec les services de données, les instances d'application ne tournent que sur un seul nœud. Si le détecteur de pannes détecte une panne, il essaie de redémarrer l'instance sur un même nœud ou de la lancer sur un autre nœud (basculement). Le résultat dépend de 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 nœuds. Les services évolutifs utilisent les deux groupes de ressources suivants :

• un groupe de ressources évolutif, qui contient les ressources d'applications ;

• un groupe de ressources de basculement, qui contient les ressources réseau (adresses partagées) dont dépend le service évolutif.

Le groupe de ressources évolutif peut être connecté à plusieurs nœuds, 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 nœud à la fois. Tous les nœuds hébergeant un service évolutif utilisent la même adresse partagée pour héberger le service.

Les demandes de service entrent dans le cluster par le biais de l'interface de réseau unique (interface globale). Ces demandes sont ensuite distribuées aux nœuds, en fonction d'un des algorithmes prédéfinis définis par la règle d'équilibrage de charge. Le cluster peut utiliser cette règle pour équilibrer la charge de service entre plusieurs nœuds. Plusieurs interfaces globales peuvent exister sur différents nœuds qui hébergent d'autres adresses partagées.

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

S'il lui est impossible de redémarrer sur le même nœud et qu'un autre nœud non utilisé est configuré pour exécuter le service, celui-ci bascule sur le nœud non utilisé. Faute de quoi, le service continue de s'exécuter sur les nœuds restants, ce qui peut provoquer une dégradation de ses capacités de traitement.

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

La Figure 3–7 affiche un exemple de groupe de ressources de basculement et de groupes de ressources évolutifs ainsi que les dépendances qui existent entre eux pour les services évolutifs. Cet exemple présente trois groupes de ressources. Le groupe de ressources de basculement contient les ressources d'applications des serveurs DNS à haute disponibilité et les ressources réseau utilisées à la fois par les serveurs DNS à haute disponibilité et les serveurs Web Apache à haute disponibilité (disponibles uniquement sur les clusters SPARC). Les groupes de ressources évolutifs ne contiennent que les instances d'application du serveur Web Apache. Notez que des dépendances de groupes de ressources existent entre les groupes de ressources évolutifs et de basculement (lignes pleines). Par ailleurs, toutes les ressources de l'application Apache dépendent de la ressource réseau schost-2, qui est une adresse partagée (pointillés).

Figure 3–7 SPARC : exemple de groupe de ressources évolutif et de basculement

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

• Sticky

Un service pur est à même de faire répondre l'une de ses instances aux demandes d'un client. Un service sticky est à même de demander à un client d'envoyer des demandes à 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 chaque nœud d'un cluster à trois nœuds ait un poids de 1. Chaque nœud traitera 1/3 des demandes d'un client pour le compte de ce service. L'administrateur peut à tout moment changer les poids par le biais de l'interface de contrôle scrgadm(1M) ou de l'interface utilisateur graphique de Gestionnaire SunPlex.

Il existe deux types de services sticky : 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 connexions TCP simultanées. Le client est dit « sticky » envers l'instance du serveur écoutant sur un port unique. 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 à l'aide de trois connexions TCP différentes. Toutefois, les connexions échangent, au niveau du service, les informations de session mises en cache.

Une généralisation d'une règle sticky s'étend à plusieurs services évolutifs qui échangent des informations de session à l'arrière-plan et au niveau de la même instance. Le cas échéant, le client est dit « sticky » envers plusieurs instances de serveur sur le même nœud écoutant des ports différents.

Prenons l'exemple d'un client sur un site d'e-commerce, qui remplit son panier d'achat en utilisant le protocole HTTP sur le port 80. Le client bascule ensuite sur le protocole SSL sur le port 443 pour envoyer des données sécurisées afin de payer par carte de crédit les articles contenus dans le panier.

Les services sticky joker utilisent des numéros de port assignés de manière dynamique, mais attendent toujours des demandes du client qu'elles se dirigent vers le même nœud. Le client est dit « sticky joker » sur les ports qui ont la même adresse IP.

Un bon exemple de cette règle est le protocole FTP en mode passif. Par exemple, un client se connecte à un serveur FTP sur le port 21. Le serveur demande ensuite au client de se reconnecter à un serveur de ports d'écoute dans la plage des ports dynamiques. Toutes les demandes relatives à cette adresse IP sont transférées sur le même nœud par le biais duquel le serveur a informé le client des informations de contrôle.

La règle d'équilibrage de charge pondérée est appliquée par défaut pour chacune de ces règles sticky. Ainsi la requête initiale d'un client est dirigée vers l'instance imposée par l'équilibreur de charge. Une fois que le client a établi une affinité pour le nœud sur lequel l'instance s'exécute, les demandes futures sont dirigées sous conditions vers cette instance. Le nœud doit être accessible et la règle d'équilibrage de charge ne doit pas avoir été modifiée.

D'autres informations sur les règles d'équilibrage de charge spécifiques sont indiquées ci-dessous.

• Pondérée. La charge est répartie entre les différents nœuds en fonction de valeurs spécifiées. Cette règle est définie via l'utilisation de la valeur LB_WEIGHTED pour la propriété Load_balancing_weights. Si la charge d'un nœud 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 nœud particulier. Soit X=le poids et A=le total des poids de tous les nœuds actifs : un nœud actif peut s'attendre qu'environ X/A de toutes les nouvelles connexions soient dirigées vers lui. Toutefois, le nombre total de connexions doit être suffisamment important. Cette règle ne s'applique pas à des requêtes individuelles.

  Notez qu'elle ne fonctionne pas à tour de rôle. Si on utilisait une règle à tour de rôle (circulaire), chaque demande d'un client irait toujours vers un nœud différent. Par exemple, la première demande irait vers le nœud 1, la seconde, vers le nœud 2, etc.

• Sticky. Avec cette règle, le jeu de ports est connu au moment de la configuration des ressources d'application. Cette règle est définie via l'utilisation de la valeur LB_STICKY pour la propriété de ressource Load_balancing_policy.

• Sticky joker. Cette règle est un sur-ensemble de la règle « sticky » ordinaire. S'il s'agit d'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 via l'utilisation de la valeur LB_STICKY_WILD pour la propriété de ressource Load_balancing_policy.

Paramètres de rétablissement

Les groupes de ressources basculent d'un nœud sur un autre. Le cas échéant, le nœud secondaire d'origine devient le nouveau nœud principal. Les paramètres de rétablissement spécifient les actions qui se produisent lorsque le nœud principal d'origine est de nouveau en ligne. Vous pouvez soit autoriser le nœud principal d'origine à reprendre son rôle (rétablissement), soit permettre au nœud principal actuel de rester. Spécifiez l'option souhaitée en utilisant le paramètre de propriété du groupe de ressources Failback.

Si le nœud d'origine qui héberge le groupe de ressources est défectueux et redémarre sans arrêt, ce rétablissement peut réduire la disponibilité du groupe de ressources.

Détecteurs de pannes des services de données

Chaque service de données Sun Cluster intègre un détecteur de pannes le sondant périodiquement 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. En fonction des informations renvoyé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.