Designhinweise für die Multimasterreplikation

Wenn Sie die Multimasterreplikation implementieren, müssen Sie Aspekte wie Arbitrierung, Verbindungen und Leistung beim Design berücksichtigen.

Arbitrierungshinweise für das Topologiedesign

Änderungskollisionen können auftreten, wenn dieselben Datensätze gleichzeitig an zwei Stellen geändert werden können. Konfigurieren Sie alle Katalogservicedomänen mit denselben Werten für Prozessor-, Hauptspeicher und Netzressourcen. Sie können beobachten, dass Katalogservicedomänen, die für die Kollisionsbehandlung (Arbitrierung) zuständig sind, mehr Ressourcen als andere Katalogservicedomänen verbrauchen. Kollisionen werden automatisch erkannt. Sie werden mit einem der folgenden beiden Mechanismen behoben:
  • Standardkollisionsarbiter: Standardmäßig werden die Änderungen aus der Katalogservicedomäne verwendet, deren Name in der lexikalischer Reihenfolge am niedrigsten steht. Wenn beispielsweise Katalogservicedomäne A und Domäne B einen Konflikt in Bezug auf einen Datensatz verursachen, wird die Änderung aus Katalogservicedomäne B ignoriert. Katalogservicedomäne A behält ihre Version, und der Datensatz in Katalogservicedomäne B wird geändert, so dass er dem Datensatz aus Katalogservicedomäne A entspricht. Dieses Verhalten gilt auch für Anwendungen, in denen Benutzer oder Sitzungen normalerweise gebunden sind oder eine Affinität zu einem der Datengrids haben.
  • Angepasster Kollisionsarbiter: Anwendungen können einen angepassten Arbiter bereitstellen. Wenn eine Katalogservicedomäne eine Kollision erkennt, ruft sie den Arbiter auf. Informationen zum Entwickeln eines hilfreichen angepassten Arbiters finden Sie unter Angepasste Arbiter für Replikation mehrerer Master entwickeln.
Für Topologien, in denen Kollisionen möglich sind, können Sie eine Hub- und Peripherietopologie oder eine Baumtopologie implementieren. Diese beiden Topologien sind dienlich, um ständige Kollisionen zu vermeiden, die in den folgenden Szenarien auftreten können:
  1. In mehreren Katalogservicedomänen tritt eine Kollision auftritt.
  2. Jede Katalogservicedomäne behebt die Kollision lokal, was zu Überarbeitungen führt.
  3. Die Überarbeitungen kollidieren, was zu Überarbeitungen von Überarbeitungen führt.

Zur Vermeidung von Kollisionen wählen Sie eine bestimmte Katalogservicedomäne, die so genannte Arbitrierungskatalogservicedomäne, als Kollisionsarbiter für einen Teil der Katalogservicedomänen aus. In einer Hub- und Peripherietopologie kann der Hub beispielsweise als Kollisionshandler verwendet werden. Der Peripheriekollisionshandler ignoriert alle von den Peripheriekatalogservicedomänen erkannten Kollisionen. Die Hubkatalogservicedomäne erstellt Überarbeitungen, was unerwartete Kollisionsüberarbeitungen verhindert. Die für die Behandlung von Kollisionen zugeordnete Katalogservicedomäne muss eine Verbindung zu allen Domänen haben, für die sie Kollisionen beheben soll. In einer Baumtopologie beheben alle internen übergeordneten Domänen Kollisionen für die ihnen unmittelbar untergeordneten Domänen. Wenn Sie eine Ringtopologie verwendet, ist es nicht möglich, eine einzige Katalogservicedomäne im Ring als Arbiter zu bestimmen.

In der folgenden Tabelle sind die kompatiblen Arbitrierungsansätze für die verschiedenen Topologien zusammengefasst.
Tabelle 1. Arbitrierungsansätze. Der folgenden Tabelle können Sie entnehmen, ob Anwendungsarbitrierung mit den verschiedenen Technologien kompatibel ist.
Topologie Anwendungsarbitrierung? Anmerkungen
Eine Reihe von zwei Katalogservicedomänen Ja Wählen Sie eine Katalogservicedomäne als Arbiter aus.
Eine Reihe von drei Katalogservicedomäne Ja Die mittlere Katalogservicedomäne muss der Arbiter sein. Stellen Sie sich die mittlere Katalogservicedomäne als Hub in einer einfachen Hub- und Peripherietopologie vor.
Eine Reihe von mehr als drei Katalogservicedomänen Nein Anwendungsarbitrierung wird nicht unterstützt.
Ein Hub mit N Peripheriedomänen Ja Der Hub mit den Verbindungen zu allen Peripheriedomänen muss die Arbitrierungskatalogservicedomäne sein.
Ein Ring mit N Katalogservicedomänen Nein Anwendungsarbitrierung wird nicht unterstützt.
Eine azyklische gerichtete Baumstruktur (k-näre Baumstruktur) Ja Alle Stammknoten dürfen nur die ihnen direkt untergeordneten Knoten bewerten.

Verbindungshinweise für das Topologiedesign

Im Idealfall enthält eine Topologie die Mindestanzahl an Verbindungen und optimiert gleichzeitig Kompromisse zwischen Latenzzeit für Änderungen, Fehlertoleranz und Leistungsmerkmale.
  • Latenzzeit bei Änderungen

    Die Latenzzeit bei Änderungen wird durch die Anzahl zwischengeschalteter Katalogservicedomänen bestimmt, die eine Änderung durchlaufen muss, bevor sie in einer bestimmten Katalogservicedomäne ankommt.

    Eine Topologie weist die beste Latenzzeit bei Änderungen auf, wenn zwischengeschaltete Katalogservicedomänen wegfallen, weil jede Katalogservicedomäne mit jeder anderen Katalogservicedomäne verbunden wird. Eine Katalogservicedomäne muss jedoch proportional zur Anzahl ihrer Verbindungen Replikationsarbeiten ausführen. In großen Topologien kann die reine Anzahl zu definierender Verbindungen einen hohen Verwaltungsaufwand darstellen.

    Die Geschwindigkeit, mit der eine Änderung in andere Katalogservicedomänen kopiert wird, richtet sich nach weiteren Faktoren, wie z. B.:
    • Prozessor- und Netzbandbreite in der Quellenkatalogservicedomäne
    • Anzahl zwischengeschalteter Katalogservicedomänen und Verbindungen zwischen der Quellen- und der Zielkatalogservicedomäne
    • Prozessor- und Netzressourcen, die der Quellenkatalogservicedomäne, der Zielkatalogservicedomäne und den zwischengeschalteten Katalogservicedomänen zur Verfügung stehen
  • Fehlertoleranz

    Die Fehlertoleranz wird durch die Anzahl der existierenden Pfade zwischen zwei Katalogservicedomänen für die Änderungsreplikation bestimmt.

    Wenn Sie nur eine einzige Verbindung zwischen zwei Katalogservicedomänen haben, wird die Weitergabe von Änderungen aufgrund eines Verbindungsfehlers nicht zugelassen. Änderungen zwischen Katalogservicedomänen werden auch nicht weitergegeben, wenn bei einer der zwischengeschalteten Domänen ein Verbindungsfehler auftritt. Ihre Topologie kann eine einzige Verbindung von einer Katalogservicedomäne zu einer anderen Katalogservicedomäne enthalten, die über zwischengeschaltete Domänen führt. In diesem Fall werden Änderungen nicht weitergegeben, wenn eine der zwischengeschalteten Katalogservicedomänen ausfällt.

    Stellen Sie sich eine Reihentopologie mit vier Katalogservicedomänen, A, B, C und D, vor:

    Reihentopologie

    Wenn eine der folgenden Bedingungen zutrifft, sieht die Domäne D Änderungen von Domäne A nicht:
    • Die Domäne A ist aktiv, und die Domäne B ist inaktiv.
    • Die Domänen A und B sind aktiv, und die Domäne C ist inaktiv.
    • Die Verbindung zwischen A und B ist inaktiv.
    • Die Verbindung zwischen B und C ist inaktiv.
    • Die Verbindung zwischen C und D ist inaktiv.
    In einer Ringtopologie hingegen kann jede Katalogservicedomäne Änderungen aus jeder Richtung empfangen.

    Ringtopologie

    Wenn beispielsweise ein bestimmter Katalogservice in Ihrer Ringtopologie inaktiv ist, können die beiden benachbarten Domänen weiterhin Änderungen direkt voneinander extrahieren.

    Alle Änderungen werden über den Hub weitergegeben. Damit ist das Hub- und Peripheriedesign im Gegensatz zu den Reihen- und Ringtopologien für Störungen anfällig, wenn der Hub ausfällt.

    Hub- und Peripherietopologie

    Ein einzige Katalogservicedomäne ist gegen eine bestimmte Anzahl von Serviceausfällen widerstandsfähig. Weiterreichende Ausfälle wie beispielsweise Netzausfälle oder Ausfälle von Verbindungen zwischen physischen Rechenzentren können jedoch den Betrieb Ihrer Katalogservicedomänen unterbrechen.

  • Verbindungen und Leistung

    Die Anzahl der in einer Katalogservicedomäne definierten Verbindungen wirkt sich auf die Leistung aus. Je mehr Verbindungen definiert werden, desto mehr Ressourcen werden benötigt, und deshalb kann die Replikationsleistung abnehmen. Die Möglichkeit, Änderungen für Domäne A über andere Domänen anzurufen, entlastet die Domäne A effektiv von der Replikation ihrer Transaktionen in allen Domänen. Die Änderungsverteilungslast in einer Domäne wird durch die Anzahl der verwendeten Verbindungen und nicht durch die Anzahl der Domänen in der Topologie beschränkt. Diese Lasteigenschaft unterstützt Skalierbarkeit, damit sich die Domänen in der Topologie die Last der Änderungsverteilung teilen können.

    Eine Katalogservicedomäne kann Änderungen indirekt über andere Katalogservicedomänen abrufen. Stellen Sie sich eine Reihentopologie mit fünf Katalogservicedomänen vor.
    A <=> B <=> C <=> D <=> E
    • A bezieht Änderungen von B, C, D und E über B.
    • B bezieht Änderungen von A und C direkt und Änderungen von D und E über C.
    • C bezieht Änderungen von B und D direkt und Änderungen von A über B und Änderungen von E über D.
    • D bezieht Änderungen von C und E direkt und Änderungen von A und B über C.
    • E bezieht Änderungen von D direkt und Änderungen von A, B und C über D.

    Die Verteilungslast ist in den Katalogservicedomänen A und E am geringsten, weil sie jeweils nur eine Verbindung zu einer einzigen Katalogservicedomäne haben. Die Domänen B, C und D haben jeweils eine Verbindung zu zwei Domänen. Somit ist die Verteilungslast in den Domänen B, C und D doppelt so hoch wie die Last in den Domänen A und E. Die Arbeitslast richtet sich nach der Anzahl der Verbindungen in jeder Domäne und nicht nach der Gesamtanzahl der Domänen in der Topologie. Die beschriebene Verteilung der Last bliebe damit auch bei 1000 Domänen in der Reihe konstant.

Leistungshinweise für die Multimasterreplikation

Berücksichtigen Sie bei der Verwendung von Multimaster-Replikationstopologien die folgenden Einschränkungen: