Considérations de conception pour la réplication multimaître

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.

Points concernant l'arbitrage à prendre en considération dans la conception des topologies

Des collisions entre des modifications peuvent se produire s'il est possible à des enregistrements identiques d'être modifiés simultanément en deux endroits différents. Configurez chaque domaine de service de catalogue pour que les domaines aient le même nombre de processeurs, la même quantité de mémoire et le même nombre de ressources réseau. Vous remarquerez sans doute que des domaines de service de catalogue d'exécution gérant les collisions de modifications (arbitrage) utilisent plus de ressources que d'autres domaines de service de catalogue. Les collisions sont détectées de manière automatique. Elles sont traitées avec l'un des deux mécanismes suivants :
  • Arbitre par défaut : le protocole par défaut doit utiliser les modifications du domaine de service de catalogue occupant la position la moins basse alphabétiquement. Par exemple, si les domaines de service de catalogue A et B génèrent un conflit pour un enregistrement, la modification du domaine de service de catalogue B est ignorée. Le domaine de service de catalogue A conserve sa version et l'enregistrement dans le domaine de service de catalogue B est modifié pour qu'il corresponde à l'enregistrement du domaine de service de catalogue A. Ce comportement s'applique également aux applications où les utilisateurs ou les sessions sont normalement liés ou ont une affinité à l'une des grilles de données.
  • Arbitre personnalisé : les applications peuvent fournir un arbitre personnalisé. Lorsqu'un domaine de service de catalogue détecte une collision, il démarre l'arbitre. Pour plus d'informations sur le développement d'un arbitre personnalisé utile, voir Développement d'arbitres personnalisés pour la réplication multi-maître.
Pour les topologies dans lesquelles les collisions sont possibles, songez à implémenter une topologie en étoile ou en arbre. Les deux topologies sont propices à éviter les collisions constantes, ce qui peut se produire dans les scénarios suivants :
  1. Plusieurs domaines de service de catalogue sont affectés par une collision.
  2. Chaque domaine de service de catalogue gère la collision en local, ce qui produit des révisions.
  3. Les révisions entrent en collision, d'où des révisions de révisions.

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.

Le tableau qui suit récapitule les approches en matière d'arbitrage qui sont les plus compatibles avec les diverses topologies.
Tableau 1. Approches en matière d'arbitrage. Ce tableau énonce si l'arbitrage entre applications est compatible avec les diverses topologies.
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.

Points concernant les liens à prendre en considération dans la conception des topologies

Dans l'idéal, une topologie comprend le minimum de liens tout en optimisant les compromis entre les temps d'attente des modifications, la tolérance aux pannes et les caractéristiques de performances.
  • Temps d'attente des modifications

    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 vitesse à laquelle une modification est copiée vers les autres domaines de service de catalogue dépend de facteurs supplémentaires, tels que :
    • Bande passante du processeur et du réseau dans le domaine de service de catalogue source
    • Nombre de domaines de service de catalogue intermédiaire et de liens entre la source et la cible du domaine de service de catalogue source et cible
    • Ressources en processeur et en réseau disponibles pour les domaines de service de catalogue source, cible et intermédiaires
  • Tolérance aux pannes

    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 :

    Topologie de ligne

    Si l'une de ces conditions existe, le domaine D ne voit pas les modification de A :
    • Le domaine A est actif et B est arrêté.
    • Les domaines A et B sont actifs et C est arrêté.
    • Le lien entre A et B ne fonctionne pas.
    • Le lien entre B et C ne fonctionne pas.
    • Le lien entre C et D est arrêté.
    En revanche, avec une topologie en anneau, chaque domaine de service de catalogue peut recevoir les modifications dans un sens ou dans l'autre.

    Topologie en anneau

    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.

    Topologie en étoile

    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.

  • Liaison et performances

    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.

    Un domaine de service de catalogue peut extraire les modifications indirectement via d'autres domaines de service de catalogue. Supposons une topologie linéaire avec cinq domaines de service de catalogue.
    A <=> B <=> C <=> D <=> E
    • A extrait les modifications de B, C, D, et E via B
    • B extrait les modifications directement de A et de C et les modifications de D et de E via C
    • C extrait les modifications directement de B et de D et les modifications de A via B et de E via D
    • D extrait les modifications directement de C et de E et les modifications de A et de B via C
    • E extrait les modifications directement de D et les modifications de A, B et C via D

    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.

Considérations relatives aux performances de réplication multimaître

Tenez compte des limitations suivantes lorsque vous utilisez des topologies de réplication multimaître :