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 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 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 services arrivent au cluster à travers une interface réseau unique (interface globale) et sont réparties entre les nœuds 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 nœuds. Notez qu'il peut y avoir plusieurs interfaces globales sur des nœuds différents hébergeant 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 de fonctionnement é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é. Si aucun nœud n'est disponible, l'instance d'application continue de fonctionner sur les nœuds 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 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 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é (disponibles uniquement sur les clusters SPARC). 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 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 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 nœuds, chaque nœud supporte une charge de 1. Chaque nœud 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 nœud é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 nœud. 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 nœud ; 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 nœud où fonctionne l'instance, les requêtes futures sont dirigées vers cette instance sous réserve que le nœud 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 nœuds 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 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. Si on a X = charge et A = la charge totale de tous les nœuds en activité, un nœud 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 nœud différent : la première requête 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 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.