Mit Zonen können Sie die Shardverteilung steuern. Zonen sind benutzerdefinierte logische Gruppierungen physischer Server. Im Folgenden finden Sie Beispiele für verschiedene Zonentypen: verschiedene Blade-Server, Blade-Server-Gehäuse, Stockwerke, Gebäude oder verschiedene geografische Standorte in einer Umgebung mit mehreren Rechenzentren. Ein weiterer Anwendungsfall für Zonen sind virtualisierte Umgebungen, in denen viele Serverinstanzen, jeweils mit einer eindeutigen IP-Adresse, auf demselben physischen Server ausgeführt werden.
Der klassische Beispiel- und Anwendungsfall für Zonen sind zwei oder mehr Rechenzentren, die über verschiedene geografische Standorte verteilt sind. Bei verteilten Rechenzentren wird das Datengrid über verschiedene Standorte verteilt, um bei Fehlern in den Rechenzentrum eine Möglichkeit der Wiederherstellung zu haben. Sie können beispielsweise sicherstellen, dass ein vollständiger Satz asynchroner Replikat-Shards für Ihr Datengrid in einem fernen Rechenzentrum verfügbar ist. Diese Strategie ermöglicht Ihnen nach einem Fehler im lokalen Rechenzentrum eine transparente Wiederherstellung ohne Datenverlust. Rechenzentren selbst haben Hochgeschwindigkeitsnetze mit geringen Latenzzeiten. Die Kommunikation zwischen zwei Rechenzentren hat jedoch höhere Latenzzeiten. Synchrone Replikate werden in jedem Rechenzentrum verwendet, in dem die geringen Latenzzeiten die Auswirkungen der Replikation auf die Antwortzeiten minimiert. Die asynchrone Replikation verringert die Auswirkungen auf die Antwortzeiten. Die geografische Entfernung gewährleistet die Verfügbarkeit der Daten, falls im lokalen Rechenzentrum ein Fehler auftritt.
Im folgenden Beispiel haben die primären Shards für die Zone "Chicago" Replikate in der Zone "London". Primäre Shards für die Zone "London" haben Replikate in der Zone "Chicago".
Die Shard-Verteilung wird mit drei Konfigurationseinstellungen in eXtreme Scale gesteuert:
In den folgenden Abschnitten sind die verschiedenen Optionen, flexibel in aufsteigender Reihenfolge ihrer Komplexität, beschrieben.
Definieren Sie in Ihrer XML-Implementierungsdatei developmentMode="false".
Dieser einfache Schritt aktiviert die erste Shard-Verteilungsrichtlinie in eXtreme Scale.
Weitere Informationen zur XML-Datei finden Sie unter XML-Deskriptordatei für Implementierungsrichtlinie.
Richtlinie 1: Shards für dieselbe Partition werden auf separate physische Server verteilt.
Stellen Sie sich eine einfaches Beispiel eines Datengrids mit einem einzigen Replikat-Shard vor. Bei dieser Richtlinie befinden sich die primären Shards und Replikat-Shards für jede Partition auf verschiedenen physischen Servern. Wenn einer der physischen Server ausfällt, gehen keine Daten verloren. Das primäre Shard oder Replikat-Shard für jede Partition befindet sich auf unterschiedlichen Servern, die nicht ausgefallen sind, oder beide Shards befinden sich auf einem anderen physischen Server, der nicht ausgefallen ist.
Die hohe Verfügbarkeit und Einfachheit dieser Richtlinie macht die Richtlinie zur effizientesten Einstellung für alle Produktionsumgebungen. In vielen Fällen ist die Anwendung dieser Richtlinie der einzige erforderliche Schritt für eine effiziente Steuerung der Shard-Verteilung in Ihrer Umgebung.
Wenn Sie diese Richtlinie anwenden, wird ein physischer Server anhand einer IP-Adresse identifiziert. Shards werden an Container-Server verteilt. Container-Server haben eine IP-Adresse, z. B. den Parameter -listenerHost im Script startOgServer. Mehrere Container-Server können dieselbe IP-Adresse haben.
Da ein physischer Server mehrere IP-Adressen hat, können Sie den nächsten Schritt ausführen, um Ihre Umgebung noch differenzierter zu steuern.
Container-Server werden mit dem Parameter -zone im Script "startOgServer" Zonen zugeordnet. In einer Umgebung von WebSphere Application Server werden Zonen über Knotengruppen mit einem bestimmten Namensformat definiert: Replikationszone<Zone>. Auf diese Weise wählen Sie den Namen und die Zugehörigkeit Ihrer Zonen aus. Weitere Informationen finden Sie unter Zonen für Container-Server definieren.
Richtlinie 2: Shards für dieselbe Partition werden separaten Zonen zugeordnet.
Angenommen, Sie erweitern das Datengridbeispiel mit einem einzigen Replikat-Shard, indem Sie es auf zwei Rechenzentren verteilen. Definieren Sie jedes Rechenzentrum als unabhängige Zone. Verwenden Sie den Zonennamen "DC1" für die Container-Server im ersten Rechenzentrum und den Namen "DC2" für die Container-Server im zweiten Rechenzentrum. Bei dieser Richtlinie befinden sich die primären Shards und die Replikat-Shards für jede Partition in verschiedenen Rechenzentren. Wenn ein Rechenzentrum ausfällt, gehen keine Daten verloren. Das primäre Shard oder das Replikat-Shard jeder Partition befindet sich im anderen Rechenzentrum.
Mit dieser Richtlinie können Sie die Shard-Verteilung durch die Definition von Zonen steuern. Sie wählen Ihre physische oder logische Grenze bzw. gewünschte Gruppierung aus. Anschließend wählen Sie einen eindeutigen Zonennamen für jede Gruppe aus und starten die Container-Server in jeder Ihrer Zonen mit dem Namen der entsprechenden Zone. Damit verteilt eXtreme Scale die Shards so, dass Shards für dieselbe Partition separaten Zonen zugeordnet werden.
Weitere Informationen finden Sie im Abschnitt Beispiel: Zonendefinitionen in der XML-Implementierungsrichtliniendeskriptordatei.
Im Folgenden werden verschiedene Anwendungsfälle für Shard-Verteilungsstrategien beschrieben:
Schrittweise Upgrades
Stellen Sie sich ein Szenario vor, in dem Sie schrittweise Upgrades auf Ihre physischen Server anwenden möchten, einschließlich Wartungspaketen, die einen Neustart der Implementierung erfordern. Angenommen, Sie haben in diesem Beispiel ein Datengrid, das auf 20 physische Server mit einem einzigen synchronen Replikat verteilt ist. Jetzt möchten Sie 10 der physischen Server für Wartungszwecke gleichzeitig herunterfahren.Wenn Sie Gruppen von 10 physischen Servern herunterfahren, darf keine Partition ihre primären und Replikat-Shards auf den Servern haben, die Sie beenden. Andernfalls gehen die Daten dieser Partition verloren.
Die einfachste Lösung ist die Definition einer dritten Zone. Anstelle von zwei Zonen mit jeweils 10 physischen Servern verwenden Sie drei Zonen: zwei mit sieben physischen Servern und eine mit sechs. Die Verteilung der Daten auf mehrere Zonen ermöglicht ein besseres Failover im Hinblick auf die Verfügbarkeit.
Eine Alternative zur Definition einer weiteren Zone ist das Hinzufügen eines Replikats.
Upgrade von eXtreme Scale durchführen
Wenn Sie das schrittweise Upgrade der eXtreme-Scale-Software mit Datengrids durchführen, die Livedaten enthalten, müssen Sie die folgenden Punkte berücksichtigen. Die Softwareversion des Katalogservice muss größer-gleich den Softwareversionen des Container-Servers sein. Aktualisieren Sie bei einer schrittweisen Strategie zuerst alle Katalogserver. Weitere Informationen zum Durchführen des Upgrades für Ihre Implementierung finden Sie im Artikel eXtreme-Scale-Server aktualisieren.
Datenmodell ändern
Ein zugehöriger Aspekt ist die Vorgehensweise beim Ändern des Datenmodells oder Schemas der Objekte, die im Datengrid gespeichert werden, ohne Ausfallzeiten zu verursachen. Es würde zu Unterbrechungen des Betriebs kommen, wenn Sie das Datenmodell ändern, indem Sie das Datengrid stoppen und anschließend mit den aktualisierten Datenmodellklassen im Klassenpfad des Container-Servers erneut starten, woraufhin das Datengrid erneut geladen wird. Alternativ könnten Sie ein neues Datengrid mit dem neuen Schema starten, die Daten aus dem alten Datengrid in das neue Schema kopieren und das alte Datengrid beenden.
Virtualisierung
Cloud-Computing und Virtualisierung sind gängige aufstrebende Technologien. eXtreme Scale stellt standardmäßig sicher, dass zwei Shards für dieselbe Partition niemals derselben IP-Adresse zugeordnet werden (siehe die Beschreibung der Richtlinie 1). Wenn Sie die Implementierung in virtuellen Images wie VMware durchführen, können viele Serverinstanzen mit jeweils einer eindeutigen IP-Adresse auf demselben physischen Server ausgeführt werden. Um sicherzustellen, dass Replikate nur separaten physischen Servern zugeordnet werden, können Sie Zonen verwenden, um das Problem zu lösen. Gruppieren Sie Ihre physischen Server in Zonen, und verwenden Sie Zonenverteilungsregeln, damit die primären Shards und die Replikat-Shards in separaten Zonen verwaltet werden.
Zonen für Weitverkehrsnetze (WAN)
Sie können ein einzelnes eXtreme-Scale-Datengrid auf mehrere Gebäude oder Rechenzentren mit langsameren Netzverbindungen implementieren. Langsamere Netzverbindungen führen zu einer geringeren Bandbreite und zu einer höheren Latenzzeit. Das Risiko von Netzpartitionen ist in diesem Modus aufgrund der Netzüberlastung und anderen Faktoren ebenfalls erhöht.
Zur Bewältigung dieser Risiken organisiert der eXtreme-Scale-Katalogservice Container-Server in Stammgruppen, die Überwachungssignale austauschen, um Ausfälle von Container-Servern zu erkennen. Diese Stammgruppen können nicht auf mehrere Zonen verteilt werden. Ein führendes Member in jeder Stammgruppe überträgt die Zugehörigkeitsdaten mit Push an den Katalogservice. Der Katalogservice prüft alle gemeldeten Fehler, bevor er auf die Zugehörigkeitsinformationen reagiert, indem er Überwachungssignale mit dem fraglichen Container-Server austauscht. Wenn der Katalogservice eine falsche Fehlererkennung feststellt, führt er keine Aktionen aus. Die Stammgruppenpartition wird schnell wiederhergestellt. Außerdem sendet der Katalogservice in regelmäßigen Abständen Überwachungssignale an das führende Member jeder Stammgruppe, um Fälle von Stammgruppenisolation zu behandeln.