Topologies pour la réplication multimaître

Vous disposez de plusieurs options pour choisir la topologie de votre déploiement qui intègre la réplication multimaître.

Liaisons connectant les domaines de service de catalogue

Une infrastructure de grilles de données de réplication est un graphique de domaines de service de catalogue interconnectés avec des liaisons bidirectionnelles. Avec une liaison, deux domaines de service de catalogue peuvent communiquer les modifications de données. Par exemple, la topologie la plus simple est une paire de domaines de service de catalogue avec une liaison unique entre eux. Les domaines de service de catalogue sont nommés par ordre alphabétique: A, B, C, etc., à partir de la gauche. Une liaison peut traverser un réseau WAN (wide area network) pour couvrir une grande distance. Même si la liaison est interrompue, vous pouvez toujours modifier les données dans l'un des domaines de services de catalogue. La topologie rapproche les modifications quand la liaison reconnecte les domaines de service de catalogue. Les liens tentent automatiquement de se reconnecter si la connexion réseau est interrompue.

Liaison

Après avoir établi les liaisons, le produit tente d'abord de rendre chaque domaine de service de catalogue identique. Ensuite, eXtreme Scale tente de maintenir identiques les conditions à mesure que des modifications se produisent dans un domaine de service de catalogue. L'objectif vise à faire de chaque domaine de service de catalogue le miroir exact d'un autre domaine de service de catalogue connecté par les liaisons. Les liaisons de réplication entre les domaines de service de catalogue permettent de copier une modification effectuée dans un domaine de service de catalogue vers les autres domaines de service de catalogue.

Topologies linéaires

Même s'il s'agit d'un déploiement simple, une topologie linéaire montre certaines qualités des liaisons. Tout d'abord, il n'est pas nécessaire qu'un domaine de service de catalogue soit directement connecté à chacun des autres domaines de services de catalogue pour recevoir des modifications. Le domaine de service de catalogue B extrait les modifications du domaine de service de catalogue A. Le domaine de service de catalogue C reçoit les modifications du domaine de service de catalogue A via le domaine de service de catalogue B, lequel connecte les domaines A et C. De même, le domaine de service de catalogue D reçoit les modifications des autres domaines de service de catalogue via le domaine de service de catalogue C. Cette fonction répartit la charge de distribution des modifications en l'éloignant de la source des modifications.

Topologie de ligne

Notez que si le domaine de service de catalogue C est défaillant, les actions suivantes se produisent :
  1. Le domaine de service de catalogue D serait orphelin jusqu'au redémarrage du domaine de service de catalogue C.
  2. Le domaine de service de catalogue C doit se synchroniser avec le domaine de service de catalogue B, lequel est une copie du domaine de service de catalogue A.
  3. Le domaine de service de catalogue D utilise le domaine de service de catalogue C pour se synchroniser avec les modifications des domaines de services de catalogues A et B. Ces modifications se sont produites initialement lorsque le domaine de service de catalogue D étaient orphelin (lorsque le domaine de service de catalogue C était arrêté).
Enfin, les domaines de service de catalogue A, B, C et D, sont de nouveau tous identiques.

Topologies en anneau

Les topologies en anneau sont un exemple de topologie encore plus résilientes. Lorsqu'un domaine de service de catalogue ou une liaison unique est défaillant, les domaines de service de catalogue restants peuvent encore obtenir des modifications. Les domaines de service de catalogue parcourent l'anneau en s'éloignant de la défaillance. Chaque domaine de service de catalogue possède au maximum deux liens vers d'autres domaines de service de catalogue, quelle que soit la taille de la topologie en anneau. Le délai de propagation des modifications peut être important. Les modifications d'un domaine de service de catalogue particulier peuvent devoir traverser plusieurs liaisons pour que tous les domaines de service de catalogue aient les modifications. Une topologie linéaire a la même caractéristique.

Topologie en anneau

Vous pouvez également déployer une topologie en anneau plus sophistiquée, avec un domaine de service de catalogue racine au centre de l'anneau. Le domaine de service de catalogue racine fait office de point central de rapprochement. Les autres domaines de service de catalogue font office de points distants de rapprochement pour les modifications se produisant dans le domaine de service de catalogue racine. Le domaine de service de catalogue racine peut arbitrer les modifications entre les domaines de service de catalogue. Si une topologie en anneau contient plusieurs anneaux autour d'un domaine de service de catalogue racine, le domaine de service de catalogue ne peut pas arbitrer les modifications dans la partie interne de l'anneau. Toutefois, les résultats de l'arbitrage sont propagés dans les domaines de service de catalogue des autres anneaux.

Topologies en étoile

Avec une topologie en étoile, les modifications parcourent un domaine de service de catalogue du concentrateur. Etant donné que le concentrateur est le seul domaine de service de catalogue intermédiaire spécifié, les topologies en étoile ont une latence inférieure. Le domaine de service de catalogue du concentrateur est connecté à chaque branche de domaine de service de catalogue via une liaison. Le concentrateur répartit les modifications entre les domaines de service de catalogue. Il fait office de point de rapprochement pour les collisions. Dans un environnement soumis à une fréquence élevée de modifications, le concentrateur peut avoir besoin de s'exécuter sur plus de matériels que les branches pour rester synchronisé. WebSphere eXtreme Scale est conçu pour évoluer de manière linéaire, ce qui signifie que l'on peut, si nécessaire, étoffer le concentrateur sans difficultés. Toutefois, si le concentrateur tombe en panne, les modifications ne sont pas distribuées jusqu'à ce qu'il redémarre. Toutes les modifications sur les branches du sous-domaine de services de catalogue seront réparties après la reconnexion du concentrateur.

Topologie en étoile

Vous pouvez également utiliser une stratégie avec les clients intégralement répliqués, une variante de la topologie qui utilise une paire de serveurs s'exécutant comme concentrateur. Chaque client crée une grille de données à conteneur unique autonome avec un catalogue dans la machine virtuelle Java client. Un client utilise sa grille de données pour se connecter au catalogue du concentrateur. Cette connexion provoque la synchronisation du client avec le concentrateur dès que le client obtient une connexion au concentrateur.

Toutes les modifications effectuées par le client sont locales pour le client et elles sont répliquées vers le concentrateur de manière asynchrone. Le concentrateur joue le rôle de domaine de service de catalogue d'arbitrage, répartissant les modifications à tous les clients connectés. La topologie de clients intégralement répliqués fournit un cache L2 fiable pour un associateur relationnel d'objets comme OpenJPA. Les modifications sont réparties rapidement via le concentrateur entre les machines virtuelles client. Si la taille du cache peut être contenue dans le segment de mémoire disponible, la topologie est une architecture fiable pour ce style de cache L2.

Si nécessaire, utilisez plusieurs partitions pour échelonner le domaine de service de catalogue concentrateur sur plusieurs machines virtuelles Java. Etant donné que toutes les données doivent toujours tenir sur une seule machine virtuelle Java client, plusieurs partitions augmentent la capacité du concentrateur à répartir et à arbitrer les modifications. Cependant, plusieurs partitions ne changent pas la capacité d'un domaine de service de catalogue unique.

Topologies en arbre

Vous pouvez également utiliser un arbre dirigé acyclique. Un arbre acyclique n'a pas de cycles ou de boucles, et une configuration dirigée limite les liaisons aux parents et enfants existants uniquement. Cette configuration est utile pour les topologies disposant d'un grand nombre de domaines de service de catalogue. Dans ces topologies, il n'est pas pratique d'avoir un concentrateur central connecté à chaque branche. Ce type de topologie peut également être utile lorsque vous devez ajouter des domaines de service de catalogue enfant sans mettre à jour le domaine de service de catalogue racine.

Topologie en arbre

Une topologie en arbre peut toujours avoir un point central de rapprochement dans le domaine de service de catalogue racine. Le deuxième niveau peut toujours fonctionner en tant que point de rapprochement distant pour les modifications se produisant dans le domaine de service de catalogue en dessous. Le domaine de service de catalogue racine peut arbitrer les modifications entre les domaines de service de catalogue sur le deuxième niveau uniquement. Vous pouvez également utiliser des arbres n-aire ayant chacun n enfants à chaque niveau. Chaque domaine de service de catalogue se connecte à n liaisons.

Clients intégralement répliqués

Cette variante de la topologie implique une paire de serveurs s'exécutant comme concentrateur. Chaque client crée une grille de données à conteneur unique autonome avec un catalogue dans la machine virtuelle Java client. Un client utilise sa grille de données pour se connecter au catalogue du concentrateur, ce qui provoque la synchronisation du client avec le concentrateur dès que le client obtient une connexion au concentrateur.

Toutes les modifications effectuées par le client sont locales pour le client et elles sont répliquées vers le concentrateur de manière asynchrone. Le concentrateur joue le rôle de domaine de service de catalogue d'arbitrage, répartissant les modifications à tous les clients connectés. La topologie de clients intégralement répliqués fournit un bon cache de niveau 2 pour un associateur relationnel d'objets comme OpenJPA. Les modifications sont réparties rapidement via le concentrateur entre les machines virtuelles client. Tant que la taille du cache peut être contenue dans l'espace de segment mémoire disponible des clients, cette topologie est une architecture tout à fait indiquée pour ce style de cache de niveau 2.

Si nécessaire, utilisez plusieurs partitions pour échelonner le domaine de service de catalogue concentrateur sur plusieurs machines virtuelles Java. Toutes les données devant tenir sur une seule machine virtuelle Java, l'utilisation de partitions multiples augmente la capacité du concentrateur à répartir et à arbitrer les modifications, mais elle ne change pas la capacité d'un domaine de service de catalogue unique.