Aspekte der Migration von Stammgruppen
Version 6 und höher stellt die Funktionalität des High Availability Manager und der Stammgruppen bereit. Dieser Artikel enthält Aspekte der Stammgruppenkonfiguration und Topologie, die die Migration beeinflussen können, falls Sie von einer Version des Produkts migrieren, die diese Funktionalität nicht enthält, beispielsweise von Version 5.1.
- High Availability Manager
- Wann sollte ein High Availability Manager verwendet werden?
- Stammgruppen
- Stammgruppentransporte
- Stammgruppenkoordinator
- Hinweise zur Stammgruppenverwaltung
- Einstellungen für Stammgruppenskalierung
Weil für Ihre Umgebung möglicherweise spezielle Planungs- und Migrationsarbeiten erforderlich sein können, sollten Sie vor der Migration von einer Version des Produkts ohne High Availability Manager auf eine Version mit dem High Availability Manager die Antworten auf folgende Fragen kennen:
- Wie sieht die geeignete Stammgruppenkonfiguration und Topologie für eine Zelle aus, nachdem sie vollständig auf Version 7.0 migriert wurde?
- Ist in einer heterogenen Umgebung die Zelle mit Version 5.x für die Verwendung der Replikation zwischen Speichern konfiguriert? Wenn ja, wie wird die Replikationsumgebung migriert? Welche Auswirkungen hat der Migrationsprozess auf die Replikation?
- Welcher JMS-Provider (falls vorhanden) wird in der Zelle mit Version 5.x verwendet?
- Welcher JMS-Provider (falls vorhanden) wird in der Zelle mit Version 7.0 verwendet?
- Wenn in der Zelle mit Version 7.0 der IBM® Standard-Messaging-Provider der Version 7.0 verwendet werden soll, sollte dann der Messaging-Provider für hohe Verfügbarkeit konfiguriert werden?
- Sollte die Wiederherstellung des Transaktionsprotokolls in der Zelle mit Version 7.0 konfiguriert werden?
Aktivitäten im Zusammenhang mit der Migration der Stammgruppe
- Der Deployment Manager wird auf Version 7.0 migriert.
- Während des Migrationsprozesses werden ein Deployment-Manager-Profil der Version 7.0 und eine Stammgruppe mit dem Namen "DefaultCoreGroup" erstellt.
- Der neue Deployment-Manager-Prozess wird zur DefaultCoreGroup hinzugefügt.
- Knoten der Version 5.x werden nacheinander auf Version 7.0 migriert. Während der Migration jedes Knotens werden der Node Agent und die Anwendungsserver auf dem betreffenden Knoten zur Gruppe "DefaultCoreGroup" hinzugefügt.
Nach Abschluss der Migration sind alle Prozesse in der Zelle der Version 5.x Member der "DefaultCoreGroup" der Version 7.0. Weil die Stammgruppe "DefaultCoreGroup" mit den Standardwerten für alle Einstellungen definiert ist, werden während des Migrationsprozesses keine bevorzugten Koordinatorserver konfiguriert und der Koordinator wird nicht auf mehrere Server verteilt. Außerdem werden während des Migrationsprozesses keine neuen High-Availability-Richtlinien erstellt und Überschreibungen der Konfiguration durch angepasste Eigenschaften sind nicht möglich.
Planung der Stammgruppentopologie
Für die meisten Topologien der Version 5.x kann eine Standardmigration eine geeignete und funktionsfähige Stammgruppentopologie der Version 7.0 erzeugen. In einigen Fällen müssen möglicherweise kleinere Änderungen an der Topologie vorgenommen werden, beispielsweise kann ein vom Standard abweichender Transport festgelegt werden oder die Stammgruppe kann für die Replikation konfiguriert werden. Wenn die Zelle der Version 5.x so groß ist, dass sie in der Topologie der Version 7.0 mehrere Stammgruppen erforderlich macht, ist allerdings eine genauere Planung erforderlich, bevor der Migrationsprozess gestartet wird, damit Änderungen der Stammgruppenkonfigurationen keine Ausfallzeiten bei den Anwendungen zur Folge haben.
Die Migration einer großen Zelle mit Version 5.x auf Version 7.0, in der mehrere Stammgruppen erforderlich sind, ist eine komplexe Aufgabe. Wenn die Topologie der Version 7.0 mehrere Stammgruppen erforderlich macht, stehen Ihnen in Bezug auf Art und Zeitpunkt der Partitionierung der Zelle in mehrere Stammgruppen eine Reihe von Möglichkeiten zur Verfügung. Die Vorgehensweise, die Sie wählen, sollte auf Faktoren wie Anzahl der Prozesse in der Zelle und Bedarf nach ständiger Verfügbarkeit der Anwendungen basieren. Während beispielsweise die übliche Empfehlung dahin geht, Stammgruppen auf ca. 50 Member zu begrenzen, liegt die praktische Begrenzung bei etwas über 50. In Topologien mit einer kleinen Anzahl Anwendungen, die auf Hochleistungsmaschinen installiert sind (Maschinen mit großen CPUs mit sehr viel Speicher), können Sie möglicherweise sogar Stammgruppen mit bis zu 200 Member verwenden. Falls in der Zelle 150 Prozesse laufen und die Verfügbarkeit der Anwendungen keine Rolle spielt, können Sie einfach die gesamte Zelle auf Version 7.0 migrieren und anschließend zusätzliche Stammgruppen erstellen. Falls die Verfügbarkeit von Anwendungen jedoch wichtig ist, sollten Sie die zusätzlichen Stammgruppen bereits während des Migrationsprozesses erstellen, damit die Stammgruppenmember nach Beendigung des Migrationsprozesses nicht gestoppt und erneut gestartet werden müssen.
- Größe der Stammgruppe
- Der wichtigste Aspekt bei der Planung ist die Größe der Stammgruppe. Standardmäßig existiert eine Stammgruppe pro Zelle. Weil Stammgruppen nicht auf einen großen Umfang skaliert werden können, sollten Sie für die Topologie der Version 7.0 zusätzliche Stammgruppen erstellen, falls die Zelle der Version 5.x groß ist. Wenn diese Stammgruppen miteinander kommunizieren sollen, müssen Sie außerdem Stammgruppenbrücken definieren.
- Stammgruppentransport
- Wird die Konfiguration des Stammgruppentransports geändert, müssen alle Member der Stammgruppe erneut gestartet werden, damit die Änderung in Kraft tritt. Daher ist eine genaue Planung erforderlich, um die Auswirkungen einer Transportänderung zu minimieren. Wird die Transportmethode für die DefaultCoreGroup geändert, sollte diese Änderung am besten unmittelbar nach der Migration des Deployment Manager erfolgen, weil zu diesem Zeitpunkt nur der Deployment Manager erneut gestartet werden muss. Wenn andere Stammgruppen erstellt werden, sollte die Transportmethode beim Erstellen der neuen Stammgruppen ordnungsgemäß konfiguriert werden.
- Überschreibungen durch angepasste Eigenschaften
- Eine Reihe von Konfigurationsparametern der Stammgruppen können durch
angepasste Eigenschaften überschrieben werden.
Die verfügbaren Überschreibungen durch angepasste Eigenschaften sind in andern Artikeln
des Information Center dokumentiert.
Jedesmal, wenn eine Überschreibung durch eine angepasste Eigenschaft hinzugefügt, entfernt oder geändert wird, müssen alle Stammgruppenmember erneut gestartet werden, damit sie die Änderung übernehmen. Daher ist eine genaue Planung erforderlich, um die Auswirkungen der Änderungen angepasster Eigenschaften zu minimieren. Falls angepasste Eigenschaften für die DefaultCoreGroup geändert werden müssen, sollte diese Änderung am besten unmittelbar nach der Migration des Deployment Manager erfolgen. Wenn andere Stammgruppen erstellt werden, sollten die angepassten Eigenschaften beim Erstellen der neuen Stammgruppen geändert werden.
- Stammgruppenkoordinator
- Die Konfiguration von bevorzugten Koordinatorservern ist ein bewährtes Verfahren. Weil der HA Manager Änderungen an der Konfiguration des Stammgruppenkoordinators dynamisch lesen und anwenden kann, ist es nicht erforderlich, alle Stammgruppenmember erneut zu starten, damit sie diese Änderung übernehmen.
Beispiel: Migration einer großen Zelle
Das folgende Beispiel veranschaulicht einige Denkprozesse, denen Sie folgen sollten, wenn Sie die Migration einer großen Zelle mit Version 5.x auf Version 7.0, in der mehrere Stammgruppen erforderlich sind, planen und ausführen. In diesem Beispiel wird davon ausgegangen, dass die Zelle mit Version 5.x folgende Topologieeigenschaften besitzt:
- Die Zelle enthält acht Knoten mit den Namen Knoten1, Knoten2, Knoten3... Knoten8, der Deployment Manager nicht eingeschlossen.
- Die Zelle enthält zehn Cluster mit den Namen Cluster1, Cluster2, Cluster3... Cluster10.
- Cluster1 bis Cluster9 enthalten jeweils 32 Anwendungsserver. Die Cluster-Member für diese Cluster sind symmetrisch auf alle Knoten verteilt, jeweils vier Anwendungsserver pro Knoten.
- Cluster10 enthält 28 Anwendungsserver. Cluster10 enthält keine Anwendungsserver auf Knoten1. Die Anwendungsserver für Cluster10 sind symmetrisch auf Knoten2 bis Knoten8 verteilt, jeweils vier Anwendungsserver pro Knoten.
- Es gibt insgesamt 316 Anwendungsserver, 8 Node Agents und einen Deployment Manager in der Zelle.
- In jedem Cluster ist eine Anwendung implementiert, die EJBs verwendet, und diese Anwendungen können miteinander kommunizieren. Daher müssen die WLM-Routing-Informationen (Work Load Management) überall in der Zelle verfügbar sein.
- Die Anwendungen müssen während der Migration ständig verfügbar sein.
- Die Migration wird über einen Zeitraum von Tagen oder Wochen ausgeführt.
Als Erstes muss bei der Planung der Stammgruppentopologie der Version 7.0 berücksichtigt werden, dass die Zelle 325 Prozesse enthält und dass die Anwendungen ständig verfügbar sein müssen. Aufgrund dieser Faktoren ist es nicht möglich, die gesamte Zelle einfach zu migrieren und anschließend die Stammgruppen zu rekonfigurieren. Als Teil des Migrationsprozesses müssen die in der Zelle enthaltenen Prozesse auf mehrere Stammgruppen verteilt werden.
Bevor Sie festlegen, wie die Prozesse der Zelle mit Version 5.x auf die neuen Stammgruppen verteilt werden sollen, müssen Sie sicherstellen, dass jede Stammgruppe mit folgenden Regeln übereinstimmt:
- Jede Stammgruppe muss mindestens einen Verwaltungsprozess enthalten. Weil jede Zelle in diesem Beispiel über neun Verwaltungsprozesse verfügt, 8 Node Agents und den Deployment Manager, beträgt die maximale Anzahl möglicher Stammgruppen in dieser Topologie neun.
- Alle Member eines Clusters müssen Member derselben Stammgruppe sein.
- Die Anzahl der Prozesse in jeder Stammgruppe sollte die empfohlene Größe von ca. 50 Membern nicht überschreiten.
- Mindestens eine der Stammgruppen muss zwei Cluster enthalten, weil Sie die Zelle nur in maximal neun Stammgruppen aufteilen können und in der Zelle mit Version 5.x zehn Cluster enthalten sind.
- Die Stammgruppe, die mehrere Cluster enthält, wird mehr als 50 Member haben, weil jeder Cluster 28 oder 32 Anwendungsserver enthält.
Obwohl die Anzahl der Member in mindestens einer Stammgruppe die empfohlene Begrenzung überschreiten wird, liegt sie noch gut im Bereich der praktischen Begrenzung und sollte kein Problem darstellen.
Weil die Anwendungen in diesem Beispiel die WLM-Routing-Informationen für jeden in der Zelle enthaltenen Cluster benötigen, müssen Stammgruppenbrücken definiert werden, damit die Kommunikation zwischen allen Stammgruppen ermöglicht wird. (Falls Sie mit der Vorgehensweise zum Festlegen einer Stammgruppenbrücke nicht vertraut sind, lesen Sie die zugehörigen Artikel zu diesem Thema.) Eine passende Topologie der Stammgruppenbrücke für dieses Beispiel enthält Folgendes:
- Einen Stammgruppenzugriffspunkt für jede Stammgruppe. Jeder Zugriffspunkt enthält die Menge der Prozesse, die die Brückenschnittstellen für die Stammgruppe bereitstellen. Die Brückenschnittstellen sind die Prozesse, die tatsächlich mit den Prozessen in anderen Stammgruppen kommunizieren.
- Zwei Brückenschnittstellen für jeden Zugriffspunkt, um zu verhindern, dass
die Stammgruppenbrücke einen
Single Point of Failure darstellt.
Diese beiden Brückenschnittstellen werden außerdem
auf zwei unterschiedliche Knoten gestellt, um
ständige Verfügbarkeit zu gewährleisten.
Bei der Auswahl der Prozesse, die als Brückenschnittstellen dienen sollen, müssen Sie beachten, dass Brückenschnittstellen zusätzlichen Speicher und CPU-Zyklen benötigen. Normalerweise eignen sich Node Agents gut als Brückenschnittstellen, weil ein Node Agent während des normalen Betriebs eine niedrigere Auslastung aufweist als ein Anwendungsserver oder der Deployment Manager.
In diesem Beispiel sind jedoch nur acht Node Agents verfügbar, die als Brückenschnittstellen dienen können. Da die Topologie aber zwei Brückenschnittstellen pro Zugriffspunkt erfordert, stehen Ihnen lediglich vier Zugriffspunkte und somit vier Stammgruppen zur Verfügung, wenn Sie nur die Node Agents als Brückenschnittstellen verwenden. Bevor sie den Migrationsprozess starten, sollten Sie daher acht eigenständige Server erstellen, die speziell als Brückenschnittstellen dienen und nicht zur Ausführung von Anwendungen verwendet werden sollen. Anschließend kann jeder Zugriffspunkt einen Node Agent und einen eigenständigen Brückenschnittstellenserver enthalten. Diese Konfiguration ergibt insgesamt acht Zugriffspunkte und acht Stammgruppen.
- Eine einzelne Gruppe von Stammgruppenzugriffspunkten, die alle Zugriffspunkte enthält.
Eine einzelne Gruppe von Stammgruppenzugriffspunkten kann sicherstellen, dass alle Brückenschnittstellenprozesse
direkt kommunizieren können.
Diese Brückenschnittstellen bilden ein vollständig verbundenes Netz.
Eine alternative Topologie würde sich bei Verwendung mehrerer Zugriffspunktgruppen ergeben. Das Ergebnis wäre eine Kettentopologie. In einer Kettentopologie wird die Kommunikation entlang der Kette von einer Brückenschnittstelle zur nächsten über zwischengeschaltete Brückenschnittstellen weitergeleitet.
Nachdem Sie nun die Konfiguration der Brückenschnittstellen für die Stammgruppen festgelegt haben, können Sie überlegen, wie die zehn Cluster, acht Node Agents, acht eigenständigen Brückenschnittstellenserver und der Deployment Manager auf Ihre acht Stammgruppen verteilt werden können. Die Prozesse sollten so gleichmäßig wie möglich auf die acht Stammgruppen verteilt werden. Die folgende Topologie ist ein gutes Beispiel dafür, wie die in der Zelle mit Version 5.x enthaltenen Prozesse gleichmäßig verteilt werden können:
- Die erste Stammgruppe, DefaultCoreGroup, enthält den Deployment Manager, den Node Agent aus Knoten1, den Brückenserver aus Knoten2 und Cluster1.
- Stammgruppe 2 enthält den Node Agent aus Knoten2, den Brückenserver aus Knoten3 und Cluster2.
- Stammgruppe 3 enthält den Node Agent aus Knoten3, den Brückenserver aus Knoten4 und Cluster3.
Die Standardtransportmethode in diesem Beispiel muss nicht geändert werden.
Weil dieses Beispiel nicht angibt, dass pro Stammgruppe mehr als ein Koordinator benötigt wird, können Sie für die Koordinatoreinstellung den Standardwert 1 beibehalten. Allerdings ist es sinnvoll, den eigenständigen Brückenschnittstellenserver, der in jeder Stammgruppe enthalten ist, als bevorzugten Koordinatorserver für die betreffende Stammgruppe festzulegen. Diese Zuordnung bewirkt, dass die von einem Koordinator erwartete Arbeitslast zunächst von den Anwendungsservern im Cluster, auf denen Anwendungen ausgeführt werden, ferngehalten wird.
Ihr Migrationsplan
Wenn Sie nach Prüfung des oben dargestellten Beispiels und nach Ausführung des ursprünglichen Planungsprozesses für die Zelle, die migriert werden soll, feststellen sollten, dass der Standardmigrationsprozess für Ihre Zieltopologie der Version 7.0 nicht geeignet ist, ist es an der Zeit, einen Plan des tatsächlichen Migrationsprozesses zu entwickeln. Dieser Plan sollte alle für zusätzliche Stammgruppen erforderlichen Schritte zur Migration von Version 5.x auf Version 7.0 enthalten sowie Antworten auf die folgenden Fragen geben:
- Wann werden die neuen Stammgruppen erstellt?
- Der beste Zeitpunkt zum Erstellen der neuen Stammgruppen ist unmittelbar nach Beendigung der Deployment-Manager-Migration. Während die neuen Stammgruppen erstellt werden, sollten Sie die bereits erwähnten angepassten Eigenschaften konfigurieren. Sie neuen Stammgruppen können entweder über die Administrationskonsole oder mit dem wsadmin-Befehl createCoreGroup erstellt werden. Die angepassten Eigenschaften müssen jedoch über die Administrationskonsole festgelegt werden.
- Welche Aktionen müssen während der Migration der Knoten ausgeführt werden?
- Während der Migration der Knoten sollten Sie folgende Aktionen ausführen:
- Den eigenständigen Anwendungsserver erstellen, der als eine Brückenschnittstelle der Stammgruppe dienen wird.
- Die Transportpuffergröße für alle Prozesse auf dem Knoten anpassen. Diese Aktion kann am besten mit einem Script ausgeführt werden.
- Die Größe des Heapspeichers auf dem Node Agent und dem eigenständigen Server anpassen, und für diese Prozesse die ausführliche Garbage-Collection aktivieren.
- Wann und wie werden Prozesse in neue Stammgruppen verschoben?
- Standardmäßig stellt der Migrationsprozess alle Prozesse in die Stammgruppe mit dem Namen
"DefaultCoreGroup". Ab einem bestimmten Zeitpunkt wird die Anzahl der Member, die in dieser Stammgruppe
enthalten sind, die Größenbegrenzung überschreiten, und Sie müssen die Prozesse auf andere Stammgruppen
verteilen.
Es ist wichtig zu wissen, dass die Prozesse gestoppt werden müssen, bevor sie verschoben werden können.
Falls eine ständige Verfügbarkeit der Anwendungen erforderlich ist,
müssen Sie die Reihenfolge, in der die Prozesse auf die verschiedenen Stammgruppen verschoben werden,
sorgfältig planen.
Der Deployment Manager, die Node Agents und die eigenständigen Anwendungsserver können entweder mithilfe der Optionen in der Administrationskonsole oder mit dem wsadmin-Befehl moveServerToCoreGroup verschoben werden.
Das Verschieben von Anwendungsservern, die in Clustern zusammengefasst sind, ist komplizierter. Normalerweise können Sie Cluster mithilfe der Optionen der Administrationskonsole oder mit dem wsadmin-Befehl moveServerToCoreGroup verschieben. Weil aber ein Cluster, das im Zuge des Migrationsprozesses vorschoben werden soll, sowohl Member der Version 7.0 als auch Member der Version 5.x enthalten kann, werden die normalen Befehle fehlschlagen, weil ein Cluster-Member der Version 5.x noch kein Member einer Stammgruppe ist. Damit ein heterogenes Cluster in eine neue Stammgruppe verschoben wird, müssen Sie den wsadmin-Befehl moveClusterToCoreGroup zusammen mit dem optionalen Parameter checkConfig verwenden.
Beispiel: Angenommen, Cluster0 verfügt über die Cluster-Member A, B, C und D. Member A befindet sich auf einem Knoten, der auf Version 7.0 migriert wurde und ist Member der Stammgruppe "DefaultCoreGroup", während sich die Cluster-Member B, C und D noch auf Knoten der Version 5.x befinden. Verwenden Sie den folgenden Befehl, um Cluster0 in die Stammgruppe CG1 zu verschieben”$AdminTask moveClusterToCoreGroup {-source CoreGroup1 –target CG1 –clusterName Cluster0 –checkConfig false}
Wenn ein Anwendungsserver migriert wird, der Teil eines Clusters ist, ermitteln die Migrationsdienstprogramme, ob andere Cluster-Member bereits migriert wurden und stellt das Member, das migriert wird, automatisch in dieselbe Stammgruppe wie die anderen Member desselben Clusters, die bereits migriert wurden.
Im vorherigen Beispiel wurde Member A in die Stammgruppe CG1 verschoben. Wenn die Knoten, die die Member B, C und D enthalten, migriert werden, werden diese Cluster-Member in die Stammgruppe CG1 anstatt in DefaultCoreGroup gestellt. Daher muss der Befehl moveClusterToCoreGroup für jeden Cluster nur einmal ausgeführt werden.
- Wann müssen die Stammgruppenbrücken konfiguriert werden?
- Wenn Sie Ihre Prozesse in mehrere Stammgruppen verschieben, müssen bereits Stammgruppenbrücken konfiguriert und aktiviert worden sein. Dies bedeutet, dass die Prozesse, die Sie in der Zieltopologie der Version 7.0 als Brückenschnittstellen verwenden möchten, möglicherweise nicht verfügbar sind, wenn sie zum ersten Mal aufgerufen werden, weil sie noch nicht von den Knoten der Version 5.x migriert wurden. Um die fortlaufende Verfügbarkeit Ihrer Anwendungen sicherzustellen, müssen Sie daher einige Anwendungsserver, die in einem Cluster zusammengefasst sind, als temporäre Brückenschnittstellen konfigurieren, während die Migration ausgeführt wird. Nachdem alle Prozesse auf Version 7.0 migriert wurden, können Sie die Konfiguration der Stammgruppenbrücke entsprechend Ihrer gewünschten Topologie für Version 7.0 anpassen.
Weitere Aspekte der Planung
Wenn in Ihrer Zielkonfiguration der Version 7.0 mehrere Stammgruppenbrücken erforderlich sind, verwenden Sie die angepasste Stammgruppeneigenschaft IBM_CS_WIRE_FORMAT_VERSION, um Verbesserungen in Bezug auf die Skalierung zu implementieren.
Wenn alle Ihre Stammgruppen über Brücken miteinander verbunden sind und wenn sie gemeinsam genutzte Daten untereinander weiterleiten, dann ist die Menge der Daten, die von den Stammgruppenmembern gemeinsam genutzt werden, wahrscheinlich sehr viel größer als im Normalfall. Daher sollten Sie mit folgenden Einstellungen die Größe des Stammgruppenspeichers erhöhen, um eine effiziente Datenübertragung zu gewährleisten:
- Legen Sie für IBM_CS_DATASTACK_MEG den Wert 100 fest.
- Setzen Sie die Transportpuffergröße aller Prozesse auf 100.
Darüber hinaus sollten Sie Faktoren wie die Größe des JVM-Heapspeichers für jeden Node Agent oder Anwendungsserver, der als Brückenschnittstelle verwendet wird, und für jeden eigenständigen Anwendungsserver, der als Koordinator verwendet wird, anpassen. Als Ausgangsbasis sollte der Heapspeicher auf 512 Megabyte erhöht werden. Sie können für diese Prozesse außerdem die ausführliche Garbage-Collection aktivieren, um im Laufe der Zeit die optimale Größe der Heapspeicher zu ermitteln.
Mögliche Migrationsabläufe
Es stehen mehrere Migrationsabläufe zur Verfügung, die Sie implementieren können, um eine erfolgreiche Migration auszuführen. Die folgenden Migrationsabläufe gehen von einem einheitlichen Ausgangspunkt aus, bei dem die Migration des Deployment Manager abgeschlossen und die Stammgruppen erstellt wurden, aber keine weiteren Aktionen ausgeführt wurden.
- Migrationsablauf 1
- In diesem Migrationsablauf werden die Regeln strikt eingehalten.
Dieser Ablauf ist aus mehreren Gründen unbefriedigend.
Während der Migration jedes Knotens müssen die Cluster verschoben werden.
Dazu müssen alle Cluster-Member gestoppt werden.
Dies kann jedoch dazu führen, dass Anwendungen nicht verfügbar sind.
Außerdem müssen bei jedem Schritt Brücken rekonfiguriert werden.
- Führen Sie die Migration für Knoten1 aus. Die Stammgruppe "DefaultCoreGroup" enthält den Deployment Manager und alle Prozesse aus Knoten1. Weil DefaultCoreGroup weniger als 50 Member enthält, ist keine weitere Aktion erforderlich.
- Führen Sie die Migration für Knoten2 aus. Die Stammgruppe "DefaultCoreGroup" enthält jetzt mehr als die empfohlene Anzahl Prozesse. Verteilen Sie die Prozesse auf 2 Stammgruppen, indem Sie die Hälfte der Cluster und den Node Agent für Knoten2 in Stammgruppe2 verschieben. Weil jetzt mehrere Stammgruppen existieren, muss ein Stammgruppenbrücke konfiguriert werden. Erstellen Sie Brückenschnittstellenserver auf den Knoten Knoten1 und Knoten2. Konfigurieren Sie die Stammgruppenbrücke in der Weise, dass sie als Brücke zwischen den beiden Stammgruppen fungiert.
- Führen Sie die Migration für Knoten3 aus. Verteilen Sie die Prozesse auf 3 Stammgruppen, indem Sie einige der Cluster aus DefaultCoreGroup und Stammgruppe2 nach Stammgruppe3 verschieben. Verschieben Sie den Node Agent für Knoten3 in Stammgruppe3. Erstellen Sie den Brückenschnittstellenserver auf Knoten3. Rekonfigurieren Sie die Stammgruppenbrücke in der Weise, dass sie als Brücke für alle drei Stammgruppen fungiert.
- Migrieren Sie danach die übrigen Knoten, bis die Migration abgeschlossen ist. Während jeder Knoten migriert wird, sind in Bezug auf die Stammgruppenbrücke eventuell weitere Aktionen zur Neuverteilung und Rekonfiguration erforderlich.
- Migrationsablauf 2
- In diesem Migrationsablauf werden die Regeln vorübergehend umgangen.
Dieser Migrationsablauf erzeugt bessere Ergebnisse,
weil laufende Anwendungsserver nicht gestoppt werden müssen, damit sie
in eine andere Stammgruppe verschoben werden können.
Bei Ausführung der Migration
werden einige Stammgruppen während eines bestimmten Zeitraums
keinen Verwaltungsprozess enthalten.
Dies ist ein technischer Verstoß gegen die Regeln,
ist aber akzeptabel, solange die Konfiguration der Stammgruppe während der Ausführung der Migration
nicht geändert wird.
- Führen Sie die Migration für Knoten1 aus. Knoten1 enthält Member als allen Clustern außer Cluster10.
- Verschieben Sie alle möglichen Cluster in die Stammgruppe, die in der geplanten Zieltopologie festgelegt ist. Der Deployment Manager, der Node Agent für Knoten1 und Cluster1 sind bereits in der Stammgruppe "DefaultCoreGroup" enthalten, daher sind für sie keine weiteren Aktionen erforderlich. Verschieben Sie Cluster2 in Stammgruppe2, Cluster3 in Stammgruppe3 usw. Erstellen Sie den Brückenserver für Knoten1, und stellen Sie ihn in Stammgruppe2.
- Konfigurieren Sie die Stammgruppenbrücke in der Weise, dass sie als Brücke für alle 8 Stammgruppen fungiert. Aus Gründen der Übersichtlichkeit wird vorübergehend nur eine Brückenschnittstelle für jeden Zugriffspunkt konfiguriert. (Auf diese Weise existiert nur ein Single Point of Failure, während die Migration ausgeführt wird.) Weil die meisten Brückenschnittstellen der geplanten Topologie noch in Version 5.x ausgeführt werden, müssen Anwendungsserver als temporäre Brückenschnittstellen in 6 der 8 Stammgruppen verwendet werden. Dazu muss eventuell der Heapspeicher auf den ausgewählten Anwendungsservern temporär erhöht werden.
- Führen Sie die Migration für Knoten2 aus. Der Migrationsprozess verschiebt die im Cluster zusammengefassten Anwendungsserver für Knoten2 in die passenden Stammgruppen. Weil Cluster10 keine Anwendungsserver auf Knoten1 enthält, muss Cluster10 manuell in Stammgruppe8 verschoben werden. Verschieben Sie den Node Agent für Knoten2 in Stammgruppe2. Erstellen Sie den Brückenserver auf Knoten2. Sie können die Brückenschnittstelle wahlweise so rekonfigurieren, dass einige der temporären Brückenschnittstellenserver auf Knoten2 enthalten sind, damit die Arbeitslast auf beide Knoten verteilt wird.
- Migrieren Sie die übrigen Knoten entsprechend dieser Vorgehensweise, bis alle Knoten migriert wurden.
- Nachdem alle Knoten migriert wurden, konfigurieren Sie die bevorzugten Koordinatorserver. Rekonfigurieren Sie die Brückenschnittstellen in der Weise, dass sie mit der geplanten Zieltopologie (zwei Brückenschnittstellenserver an jedem Zugriffspunkt) übereinstimmen. Stoppen Sie die Server, die als temporäre Brückenschnittstellen dienen, und starten Sie sie erneut. Starten Sie die neuen Brückenschnittstellenserver erneut.
- Migrationsablauf 3
- Dieser Migrationsablauf ist eine Variation des Migrationsablaufs 2.
Der Vorteil dieser Migration besteht darin, dass die ursprüngliche Brückenlast auf
drei Knoten anstatt auf einen verteilt wird.
Der Nachteil besteht darin, dass die ursprüngliche Neuverteilung der Cluster auf
die Stammgruppen nach der Migration von Knoten3 erfolgt.
Damit die Cluster verschoben werden können, müssen die Server auf den Knoten Knoten1 und Knoten2
gestoppt werden.
Dies kann die Verfügbarkeit der Anwendungen beeinträchtigen.
- Führen Sie die Migration für Knoten1 aus. Nach Ausführung dieses Schritts enthält die Stammgruppe "DefaultCoreGroup" 38 Prozesse und liegt folglich innerhalb der zulässigen Begrenzung.
- Führen Sie die Migration für Knoten2 aus. Nach Ausführung dieses Schritts enthält die Stammgruppe "DefaultCoreGroup" 79 Prozesse. Obwohl damit die empfohlene Größe überschritten ist, liegt dieser Wert noch gut im Bereich der praktischen Begrenzung.
- Führen Sie die Migration für Knoten3 aus. Verschieben Sie alle Cluster in die Stammgruppe, die in der geplanten Zieltopologie festgelegt ist. Verschieben Sie Cluster2 in Stammgruppe2, Cluster3 in Stammgruppe3 usw. Verschieben Sie die drei Node Agents in die passenden Stammgruppen. Erstellen Sie die drei Brückenschnittstellenserver und verschieben Sie sie in die passenden Stammgruppen.
- Wählen Sie in Cluster zusammengefasste Anwendungsserver aus, die als temporäre Brücken für die Stammgruppen dienen sollen, denen noch keine Brückenschnittstellen zugeordnet wurden. Erhöhen Sie die Größe des Heapspeichers auf diesen Servern. Konfigurieren Sie die Stammgruppenbrücke in der Weise, dass sie als Brücke für alle 8 Stammgruppen fungiert.
- Migrieren Sie die übrigen Knoten, bis alle Knoten migriert wurden.
- Nachdem alle Knoten migriert wurden, konfigurieren Sie die bevorzugten Koordinatoren. Rekonfigurieren Sie die Brückenschnittstellen entsprechend der geplanten Zieltopologie. Stoppen Sie Prozesse, und starten Sie sie erneut, wenn erforderlich.