Einstellungen für Stammgruppenskalierung
Die Menge der vom High Availability Manager und diesen Komponenten verbrauchten Ressourcen nimmt mit der Größe einer Stammgruppe nicht linear zu. Beispielsweise erfordert das View-Synchrony-Protokoll, das der High Availability Manager verwendet, eine große Menge dieser Ressourcen, um eine enge Kopplung der Stammgruppenmember zu gewährleisten. Daher kann die Menge der Ressourcen, die von einer große Stammgruppe verbraucht werden, erheblich sein.
- Die Anzahl der aktiven Anwendungen.
- Der Typ der aktiven Anwendungen.
- Die verwendeten High Availability Manager Services.
Wenn Sie die Skalierbarkeit der Stammgruppen konfigurieren, müssen Sie sicherstellen, dass folgende Bedingungen zutreffen:
- Alle Prozesse in der Zelle werden ordnungsgemäß auf Stammgruppen passender Größe verteilt. Durch die ordnungsgemäße Verteilung dieser Prozesse wird die Menge der Ressourcen, die das View-Synchrony-Protokoll verbraucht, begrenzt.
- Alle Prozesse in einer bestimmten Stammgruppe werden ordnungsgemäß konfiguriert, um die in der Stammgruppe verwendeten HA-Services zu unterstützen.
Ziehen Sie in Erwägung, ein oder mehrere der folgenden Skalierungsverfahren zu implementieren, um den High Availability Manager in großen Zellen zu implementieren, auch wenn Ihr System ordnungsgemäß funktioniert. Die zwei grundlegendsten Verfahren sind folgende:
- Den High Availability Manager inaktivieren, wenn er nicht erforderlich ist.
- Die Verteilung der Prozesse auf eine Reihe von Stammgruppen und die Verwendung einer Stammgruppenbrücke, um die Stammgruppe wie erforderlich zu verbinden.
Die Größe einer Stammgruppe anpassen
- Der erste und wichtigste Aspekt ist die Einrichtung des View-Synchrony-Protokolls für eine Gruppe aktiver Stammgruppenmember. Diese Aktivität wird als View Change bezeichnet.
- Der zweite Aspekt sind die regelmäßig ablaufenden Discovery- und Fehlererkennungstasks, die der High Availability Manager im Hintergrund ausführt.
- Der dritte Aspekt ist die Ressourcennutzung, die zu berücksichtigen ist, wenn andere Produktkomponenten Services, die vom High Availability Manager bereitgestellt werden, verwenden.
- View Changes
Immer wenn das View-Synchrony-Protokoll feststellt, dass es eine Änderung in aktiven Stammgruppenmembern gibt, erstellt es eine neue View. Normalerweise findet ein View Change statt, wenn ein Stammgruppenmember gestartet oder gestoppt wird. Wenn ein Stammgruppenmember gestartet wird, öffnet es eine Verbindung zu allen anderen aktiven Stammgruppenmembern. Wird ein Stammgruppenmember gestoppt, stellen andere Stammgruppenmember fest, dass ihre offenen Verbindungen zum gestoppten Member geschlossen sind. In beiden Fällen muss das View-Synchrony-Protokoll diese Änderung rechtfertigen. Wird ein ein Member neu gestartet, muss das View-Synchrony-Protokoll eine View erstellen, die das neue Member einschließt. Wird ein Member gestoppt, muss das View-Synchrony-Protokoll eine View erstellen, die das gestoppte Member ausschließt.
Die Erstellung einer neuen View ist eine wichtige Aktivität, verbraucht aber viele Systemressourcen, insbesondere bei großen Stammgruppen.- Jedes aktive Stammgruppenmember muss seinen aktuellen Status anderen Stammgruppenmembern mitteilen. Dazu gehören auch Angaben zu den Nachrichten, die es in der aktuellen View gesendet oder empfangen hat.
- Alle Nachrichten, die in einer bestimmten View gesendet wurden, müssen von allen Empfängern empfangen und bestätigt werden, bevor eine neue View installiert werden kann. Unter normalen Betriebsbedingungen wird der Empfang dieser Nachrichten nur langsam bestätigt. Der rechtzeitige Abschluss der Nachrichtenbearbeitung an einer View-Change-Grenze erfordert eine aggressive Vorgehensweise bei der Bestätigung und der erneuten Übertragung.
- Alle Stammgruppenmember müssen Daten zu ihrem aktuellen Status übertragen, z. B. die Gruppe der anderen Stammgruppenmember, mit denen sie aktiv kommunizieren können.
Wenn die Anzahl aktiver Member zunimmt, hat die Installation einer neuen View eine größere, temporäre und nicht lineare Zunahme der CPU-Belastung durch den High Availability Manager zur Folge. Es ist wesentlich aufwändiger, ein einzelnes Member hinzuzufügen oder zu entfernen, wenn 50 andere Stammgruppenmember vorhanden sind, als dies der Fall ist, wenn 20 andere Member vorhanden sind.
Die Installation einer neuen View löst auch Statusänderungen in Produktkomponenten aus, die den High Availability Manager verwenden. Beispielsweise müssen Routentabellen gegebenenfalls aktualisiert werden, damit das gestartete oder das gestoppte Member angezeigt wird, oder aber ein Singleton-Service muss auf einem neuen Member erneut gestartet werden.
Die Installation einer neuen View resultiert schließlich in einem erheblichen temporären Spitzenwert bei der CPU-Belastung. Wenn die Stammgruppe zu stark anwächst, sind degenerierte Bedingungen für die Netztaktung das Ergebnis. Diese Bedingungen führen normalerweise dazu, dass bei dem Versuch, eine neue View zu installieren, ein Fehler auftritt. Die Behebung eines solchen Fehlers ist ebenfalls CPU-intensiv. Wenn die CPU-Ressourcen unzureichend sind oder Paging durchgeführt wird, können Fehler schnell zunehmen.
- Hintergrundtasks
Der High Availability Manager führt regelmäßig eine Reihe von Hintergrundtasks aus, z. B. prüft er den Status von HA-Singleton-Services, die er verwaltet. Die meisten dieser Hintergrundtasks verbrauchen nur wenig CPU-Ressourcen. Die Ausnahmen sind das Discovery-Protokoll und das Fehlererkennungsprotokoll, die beide einer regelmäßigen Planung unterliegen.
Das Discovery-Protokoll versucht, eine Kommunikation zwischen gegenwärtig nicht miteinander verbundenen Stammgruppenmembern einschließlich der nicht aktiven Prozesse aufzubauen. Für eine bestimmte Stammgruppe, die N Stammgruppenmember enthält, von denen M Stammgruppenmember ausgeführt werden, ergibt jede Discovery-Periode etwa M x (N – M) Discovery-Nachrichten. Daher erhöht die Erstellung vieler Prozesse, die nie gestartet werden, die CPU-Belastung durch das Discovery-Protokoll.
Analog dazu sendet jedes Stammgruppenmember bei der Ausführung des Fehlererkennungsprotokolls Überwachungssignale über alle eingerichteten Verbindungen zu anderen Stammgruppenmembern. Für M aktive Member werden M x (M-1) Überwachungssignalnachrichten gesendet. Wenn aggressive Fehlererkennung erforderlich ist, kann die Größe der Stammgruppe die CPU-Belastung aufgrund des Austausches von Überwachungssignalen erhöhen.
Kleinere Stammgruppen wirken sich positiv auf die CPU-Belastung durch diese beiden Protokolle aus. Wenn z. B. eine Stammgruppe 100 aktive Member enthält, werden in jeder Fehlererkennungsperiode 9900 Überwachungssignalnachrichten gesendet. Wenn Sie die Stammgruppe von 100 Membern in 5 kleinere Gruppen von 20 Membern unterteilen, reduziert das die Anzahl der Nachrichten auf 1900, was eine deutliche Verringerung ist.
- Externe Nutzung
- Andere Produktkomponenten, z. B. Workload-Management (WLM) und On Demand Configuration, verwenden vom High Availability Manager bereitgestellte Services, z. B. für den Austausch von dynamischen Serverstatusdaten, um Routing-Informationen zu verwalten. Die CPU-Belastung durch diese Komponenten steht in Verbindung zur Größe der Stammgruppe. Beispielsweise ist der Austausch von dynamischen Serverstatusdaten zur Erstellung von HA-Routing-Informationen von der Größe der Stammgruppe abhängig.
Prozesse zwischen mehreren Stammgruppen verteilen
- Sie können den High Availability Manager für Prozesse inaktivieren, in denen die von ihm bereitgestellten Services nicht genutzt werden.
- Sie können die Größe von Stammgruppen auf einem niedrigen Niveau halten.
Der Schlüssel zur Begrenzung der CPU-Belastung durch den High Availability Manager besteht darin, die Größe der Stammgruppe zu begrenzen. Mehrere kleine Stammgruppen sind viel besser geeignet als eine große Stammgruppe. Wenn Sie große Zellen haben, müssen Sie mehrere Stammgruppen erstellen.
Die Hardware, auf der das Produkt ausgeführt wird, ist ebenfalls ein Faktor bei der Bestimmung der für Ihre Umgebung angemessene Größe der Stammgruppe.
Unterteilen Sie große Stammgruppen in mehrere kleinere Stammgruppen. Wenn die entstehenden Stammgruppen Routing-Informationen gemeinsam nutzen müssen, können Sie Stammgruppenbrücken verwenden, um die Stammgruppen miteinander zu verbinden.
Größe von Stammgruppen
- Wenn Sie die Einstellung der angepassten Stammgruppeneigenschaft IBM_CS_WIRE_FORMAT_VERSION mit dem Wert 6.1.0 aktivieren, können Sie hinsichtlich der internen Stammgruppenprotokolle Verbesserungen erzielen. Diese Verbesserungen sind nur in Version 6.1 und höher verfügbar.
- Wenn Sie die Einstellung der angepassten Stammgruppeneigenschaft IBM_CS_HAM_PROTOCOL_VERSION mit dem Wert 6.0.2.31 aktivieren, können Sie hinsichtlich der Speicherauslastung und der Failovermerkmale der Stammgruppenbrücken erhebliche Verbesserungen erzielen.
- Sie können Einstellungen für den Transportspeichers konfigurieren.
Es gibt zwei Größeneinstellungen für Speicher und Puffer, die dem Stammgruppentransport zugeordnet sind. Die Standardwerte für diese Einstellungen
sind für kleine Stammgruppen von bis zu 50 Membern ausreichend. Bei Stammgruppen von mehr als 50 Membern müssen die Standardwerte für diese Einstellungen
erhöht werden. Anmerkung: Die Erhöhung der Werte für diese Einstellungen für den Transportspeicher führt nicht automatisch dazu, dass mehr Speicher statisch zugeordnet oder durch High Availability Manager langfristig genutzt wird.
- Stammgruppen mit bis zu 100 Membern sollten ohne Probleme funktionieren.
- Stammgruppen mit mehr als 100 Membern sollten in vielen Topologien ohne Probleme funktionieren. Es wird nicht empfohlen, die Anzahl von 200 Membern für eine Stammgruppe zu überschreiten.
Einzelne Stammgruppe auf der Basis der Anwendungskombination und der verwendeten Services anpassen
Möglicherweise müssen Sie einzelne Stammgruppen auf der Basis der Anwendungskombination und der HA-Services, die die Stammgruppenmember verwenden, anpassen.
- Legen Sie fest, wie oft das Erkennungsprotokoll und das Fehlererkennungsprotokoll ausgeführt werden, wenn die Standardeinstellungen nicht geeignet sind.
- Konfigurieren Sie den Stammgruppenkoordinator, um einen bestimmten Prozess oder eine bestimmte Prozessgruppe auszuführen.
- Partitionieren Sie den Koordinator in mehrere Instanzen, wenn der Ressourcenverbrauch durch den Koordinatorprozess erheblich ist.
- Konfigurieren Sie die Speicherkapazität, die für die DCS- und RMM-Komponenten (Distribution and Consistency Services und Reliable Multicast Messaging) verfügbar ist, um Netznachrichten zu senden, wenn Engpässe auftreten. Engpässe können unter bestimmten Bedingungen auftreten, selbst wenn die Replikation zwischen Speichern nicht eingesetzt wird.
Ephemere Portbereiche anpassen
Die Anzahl der Sockets, die eine Stammgruppe verwendet, stellt normalerweise kein großes Problem dar. Jedes Stammgruppenmember muss eine Verbindung zu jedem anderen Member dieser Stammgruppe herstellen. Daher wächst die Anzahl der Verbindungen exponenziell (n²), da jede Verbindung zwei Sockets erfordert, einen an jedem Ende der Verbindung. Da meist mehrere Systeme betroffen sind, müssen Sie sich normalerweise keine Gedanken um die Anzahl der von einer Stammgruppe verwendeten Sockets machen. Wenn Sie jedoch eine unnormal große Anzahl von Stammgruppenmembern haben, die auf einem einzelnen System ausgeführt werden, müssen Sie möglicherweise die Parameter des Betriebssystems, die sich auf ephemere Portbereiche beziehen, anpassen. Die meisten Betriebssysteme haben unterschiedliche Standardverhalten für ephemere Portbereiche.
