Services de données évolutifs

La mise en réseau du cluster a pour premier objectif de fournir des services de données évolutifs. 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 nœuds au cluster et à l'exécution de nouvelles instances de serveur. 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 nœuds différents du cluster. Ensemble, ces instances se comportent comme un service unique face à un client distant de ce service et implémentent la fonctionnalité de ce service. Dans un service Web évolutif avec plusieurs démons httpd s'exécutant sur différents nœuds, n'importe quel démon peut servir la requête d'un 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, ce qui préserve l'apparence d'un service unique.

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

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

Les nœuds n'hébergeant pas l'interface globale (nœuds proxy) hébergent l'adresse partagée sur leur interface de bouclage. Les paquets arrivant dans l'interface globale sont distribués à d'autres nœuds de cluster, en fonction de 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 sortes 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 cluster équilibre la charge des requêtes au nœud. 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. Par exemple, dans un cluster à trois nœuds où chaque nœud a le poids 1, chaque nœud traite un tiers des requêtes de n'importe quel client pour le service. Les poids peuvent être modifiés à tout moment grâce à l'interface de commande scrgadm(1M) ou à l'interface graphique Gestionnaire SunPlex.

Il y a 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 connections 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.

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 et associé à la même adresse IP.