Lors de l'implémentation de la réplication multimaître, vous devez tenir compte de divers éléments dans votre conception, tels que l'arbitrage, les liaisons et les performances.
Pour éviter les collisions, choisissez un domaine de service de catalogue spécifique, appelé domaine de service de catalogue d'arbitrage comme arbitre des collisions d'un sous-ensemble de domaines de service de catalogue. Par exemple, une topologie en étoile pourra utiliser le concentrateur comme gestionnaire de collisions. Le gestionnaire de collisions ignore toutes les collisions qui sont détectées par les sous-domaines de service de catalogue. Le domaine de service de catalogue du concentrateur crée des révisions, empêchant les révisions de collisions inattendues. Le domaine de service de catalogue qui est affecté à la gestion des collisions doit se lier à tous les domaines dont il est chargé de traiter les collisions. Dans une topologie en arbre, tous les domaines parent internes traitent les collisions pour leurs enfants immédiats. En revanche, si vous utilisez une topologie en anneau, vous ne pouvez pas désigner un domaine de service de catalogue dans le fichier comme arbitre.
Topologie | Arbitrage d'application | Notes |
---|---|---|
Ligne de deux domaines de service de catalogue | Oui | Choisissez un domaine de service de catalogue comme arbitre. |
Ligne de trois domaines de service de catalogue | Oui | Le domaine de service de catalogue du milieu doit être l'arbitre. Assimilez ce domaine de service de catalogue au concentrateur dans une topologie en étoile simple. |
Ligne de plus de trois domaines de service de catalogue | Non | L'arbitrage d'application n'est pas pris en charge. |
Concentrateur avec n "rayons" | Oui | Le concentrateur avec des liens vers toutes les branches doit être le domaine de service de catalogue d'arbitrage. |
Anneau de N domaines de service de catalogue | Non | L'arbitrage d'application n'est pas pris en charge. |
Arbre dirigé acyclique (arbre n-aire) | Oui | Tous les noeuds racine doivent évaluer leurs descendants directs uniquement. |
Le temps d'attente de modification est déterminé par le nombre de domaines de service de catalogue intermédiaires par lequel un changement doit passer avant d'arriver à un domaine de service de catalogue spécifique.
Une topologie a le meilleur temps d'attente lorsqu'elle élimine les domaines de service de catalogue intermédiaires en liant chacun des domaines de service de catalogue à chacun des autres domaines de service de catalogue. Toutefois, un domaine de service de catalogue doit effectuer la réplication par rapport à son nombre de liens. Pour les topologies de grande taille, le nombre de liens à définir peut entraîner une charge administrative.
La tolérance aux pannes est déterminée par le nombre de chemins existant entre deux domaines de service de catalogue pour la réplication des modifications.
Si vous ne disposez que d'un seul lien entre une paire de domaines de service de catalogue, une défaillance de lien empêche la propagation des modifications. De même, les modifications ne sont pas propagées entre les domaines de service de catalogue si un incident de liaison se produit sur les domaines intermédiaires. Votre topologie pourrait avoir un lien unique d'un domaine de service de catalogue vers un autre de sorte que le lien passe par des domaines intermédiaires. Dans ce cas, les modifications ne sont pas propagées si l'un des domaines de service de catalogue intermédiaires est défaillant.
Supposons la topologie linéaire à quatre domaines de service de catalogue A, B, C et D :
Par exemple, si un service de catalogue donné de votre topologie en anneau est arrêté, les deux domaines contigus peuvent toujours extraire les modifications directement de l'autre.
Toutes les modifications sont propagées via le concentrateur. Par conséquent, contrairement aux topologies linéaires et en anneau, la conception en étoile peut tomber en panne si le concentrateur est défaillant.
Un domaine de service de catalogue unique est résilient à un certain degré de perte de service. Cependant, les incidents les plus importants, tels que les indisponibilités de réseau étendu ou les pertes de liaisons entre les centres de données physiques peuvent perturber les domaines de service de catalogue.
Le nombre de liaisons définies sur un domaine le service de catalogue affecte les performances. Un plus grand nombre de liaisons utilisent davantage de ressources et les performances de réplication peuvent baisser. La possibilité d'extraire les modifications pour un domaine A via d'autres domaines empêche le domaine A de répliquer ses transactions partout. La charge de la répartition des modifications dans un domaine est limitée par le nombre de liaisons qu'il utilise et non pas par le nombre de domaines dans la topologie. Cette propriété est synonyme d'évolutivité et les domaines de la topologie peuvent partager la charge de la répartition des modifications.
A <=> B <=> C <=> D <=> E
La charge de la répartition dans les domaines de service de catalogue A et E est la plus faible, car ils ont chacun une seule liaison à un domaine de service de catalogue unique. Les domaines B, C et D ont chacun une liaison avec deux domaines. Par conséquent, la charge de la répartition dans les domaines B, C, et D est le double de celle des domaines A et E. La charge de travail dépend du nombre de liaisons dans chaque domaine et non pas du nombre total de domaines dans la topologie. Par conséquent, la répartition de charge décrite demeurerait constante, même si la ligne contenait 1 000 domaines.
Tenez compte des limitations suivantes lorsque vous utilisez des topologies de réplication multimaître :
Notez que les sockets TCP utilisent un mécanisme de fenêtre dynamique pour contrôler le flux des données en vrac. Ce mécanisme limite généralement le socket à 64 Ko pour un intervalle d'aller-retour. Si l'intervalle aller-retour est de 100 ms, la bande passante est limitée à 640 Ko/s sans optimisation supplémentaire. L'utilisation intégrale de la bande passante disponible sur un lien peut nécessiter une optimisation qui est spécifique au système d'exploitation. La plupart des systèmes d'exploitation comportent des paramètres d'optimisation, y compris des options RFC 1323, permettant d'améliorer le débit sur les liaisons à forte latence.
La réplication multimaître ajoute un temps de traitement fixe par entrée de mappe pour la gestion des versions. Chaque conteneur suit également une quantité fixe de données pour chaque domaine de service de catalogue dans la topologie. Une topologie à deux domaines de service de catalogue utilise approximativement la même quantité de mémoire qu'une topologie à 50 domaines de service de catalogue. WebSphere eXtreme Scale n'utilise pas de journaux de relecture ou de files d'attente similaires dans son implémentation. Ainsi, aucune structure de récupération n'est prête si la liaison de réplication n'est pas disponible pendant un certain temps et redémarre ensuite.