Wenn Sie die Multimasterreplikation implementieren, müssen Sie Aspekte wie Arbitrierung, Verbindungen und Leistung beim Design berücksichtigen.
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.
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. |
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 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:
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.
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.
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.
A <=> B <=> C <=> D <=> E
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.
Berücksichtigen Sie bei der Verwendung von Multimaster-Replikationstopologien die folgenden Einschränkungen:
TCP-Sockets verwenden, wie bereits erwähnt, einen Sliding-Window-Mechanismus, um den Fluss von Massendaten zu steuern. Dieser Mechanismus beschränkt den Socket gewöhnlich auf 64 KB in einem Umlaufintervall. Wenn das Umlaufintervall 100 ms lang ist, ist die Bandbreite ohne Optimierung auf 640 KB/Sekunde beschränkt. Um die verfügbare Bandbreite einer Verbindung vollständig nutzen zu können, müssen unter Umständen spezielle Optimierungstasks für ein Betriebssystem ausgeführt werden. Die meisten Betriebssysteme haben Optimierungsparameter, einschließlich Optionen für RFC 1323, um den Durchsatz über Verbindungen mit hoher Latenzzeit zu verbessern.
Bei der Multimasterreplikation entsteht ein fester Verarbeitungsaufwand pro Map-Eintrag für die Versionssteuerung. Außerdem überwacht jeder Container ein festes Datenvolumen für jede Katalogservicedomäne in der Topologie. Eine Topologie mit zwei Katalogservicedomänen belegt ungefähr denselben Speicher wie eine Topologie mit 50 Katalogservicedomänen. WebSphere eXtreme Scale verwendet keine Wiedergabeprotokolle oder ähnlichen Warteschlangen in der Implementierung. Deshalb ist keine Wiederherstellungsstruktur verfügbar, wenn eine Replikationsverbindung über einen längeren Zeitraum hinweg und nach späteren Neustarts nicht verfügbar ist.