Topologies pour plusieurs collectivités

Vous disposez de plusieurs options pour choisir la topologie de votre déploiement qui intègre plusieurs collectivités.

Liaisons connectant les collectivités

Une infrastructure de grilles de données de réplication est un graphique de collectivités interconnectés avec des liaisons bidirectionnelles. Avec une liaison, deux collectivités peuvent communiquer les modifications de données. Par exemple, la topologie la plus simple est une paire de collectivités avec une liaison unique entre eux. Les collectivités 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 collectivités. Les liaisons 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 collectivité identique. Ensuite, eXtreme Scale tente de maintenir identiques les conditions à mesure que des modifications se produisent dans un collectivité. L'objectif vise à faire de chaque collectivité le miroir exact d'un autre collectivité connecté par les liaisons. Les liaisons de réplication entre les collectivités permettent de copier une modification effectuée dans un collectivité vers les autres collectivités.

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 collectivité soit directement connecté à chacun des autres domaines de services de catalogue pour recevoir des modifications. Le collectivité B extrait les modifications du collectivité A. Le collectivité C reçoit les modifications du collectivité A via le collectivité B, lequel connecte les domaines A et C. De même, le collectivité D reçoit les modifications des autres collectivités via le collectivité 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 collectivité C est défaillant, les actions suivantes se produisent :
  1. Le collectivité D serait orphelin jusqu'au redémarrage du collectivité C.
  2. Le collectivité C doit se synchroniser avec le collectivité B, lequel est une copie du collectivité A.
  3. Le collectivité D utilise le collectivité C pour se synchroniser avec les modifications des domaines de services de catalogues A et B. Ces modifications se sont produites initialement lorsque le collectivité D étaient orphelin (lorsque le collectivité C était arrêté).
Enfin, les collectivités 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 collectivité ou une liaison unique est défaillant, les collectivités restants peuvent encore obtenir des modifications. Les collectivités parcourent l'anneau en s'éloignant de la défaillance. Chaque collectivité possède au maximum deux liens vers d'autres collectivités, quelle que soit la taille de la topologie en anneau. Le délai de propagation des modifications peut être important. Les modifications d'un collectivité particulier peuvent devoir traverser plusieurs liaisons pour que tous les collectivités 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 collectivité racine au centre de l'anneau. Le collectivité racine fait office de point central de rapprochement. Les autres collectivités font office de points distants de rapprochement pour les modifications se produisant dans le collectivité racine. Le collectivité racine peut arbitrer les modifications entre les collectivités. Si une topologie en anneau contient plusieurs anneaux autour d'un collectivité racine, le collectivité 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 collectivités des autres anneaux.

Topologies en étoile

Avec une topologie en étoile, les modifications parcourent un collectivité du concentrateur. Etant donné que le concentrateur est le seul collectivité intermédiaire spécifié, les topologies en étoile ont une latence inférieure. Le collectivité du concentrateur est connecté à chaque branche de collectivité via une liaison. Le concentrateur répartit les modifications entre les collectivités. 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 DataPower XC10 Appliance 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 collectivité 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 collectivité 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 collectivité 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 collectivités. 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 collectivités enfant sans mettre à jour le collectivité racine.

Topologie en arbre

Une topologie en arbre peut toujours avoir un point central de rapprochement dans le collectivité racine. Le deuxième niveau peut toujours fonctionner en tant que point de rapprochement distant pour les modifications se produisant dans le collectivité en dessous. Le collectivité racine peut arbitrer les modifications entre les collectivités sur le deuxième niveau uniquement. Vous pouvez également utiliser des arbres n-aire ayant chacun n enfants à chaque niveau. Chaque collectivité 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 collectivité 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 collectivité 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 collectivité unique.