Life-Cycle-Management für verwaltete Verbindungs-Factorys von CM Server

Dieser Artikel beschreibt Life-Cycle-Management-Tasks für CM Server.

CM Server verwendet zwei verwaltete J2C-Verbindungs-Factorys (eine für ClearCase und eine für ClearQuest), um Back-End-Serverprozesse, die mit den ClearCase- und ClearQuest-Core-Produkten kommunizieren, aufzurufen und zu steuern. Die Back-End-ONCRPC-Prozesse (ccrpc-Prozesse für ClearCase und cqrpc-Prozesse für ClearQuest) überbrücken die Lücke zwischen den J2EE- und den WebSphere-Komponenten von CM Server und den ClearCase- und ClearQuest-Core-Komponenten.

CM Server führt eine Reihe von Hintergrundtasks aus, um den gesamten Lebenszyklus jedes aufgerufenen ONCRPC-Serverprozesses einfacher verwalten und steuern zu können. Für die Ausführung dieser Tasks ist keine Administratorbeteiligung erforderlich.

Es gibt eine generische Task, die den Lebenszyklus betrifft und ein nicht produktspezifisches Life-Cycle-Management ausführt, und produktspezifische Tasks, die das Verhalten der Back-End-Serverobjekte von ClearCase und ClearQuest steuern. Jede Task verwendet konfigurierbare MBean-Attribute, um die Anzahl und Lebensdauer aktiver Serverobjekte zu steuern und die Fähigkeit des Systems, mit der Arbeitslast Schritt zu halten, aufrechtzuerhalten und gleichzeitig einen Leistungsabfall aufgrund exzessiver Ressourcenauslastung zu verhindern. Informationen zu den MBean-Attributen und ihrer Konfiguration finden Sie im Artikel Verfügbare MBean-Attribute definieren.

Generisches Life-Cycle-Management für verwaltete Verbindungs-Factorys

Die generische Life-Cycle-Management-Task betrifft alle von den Verbindungs-Factorys erstellten ONCRPC-Prozesse. Diese Task wird im CM Server aufgerufen, wenn CM Server zum ersten Mal gestartet wird. Die Task wird alle zwei Minuten ausgeführt und prüft anhand eines Tests, ob der Sicherungsprozess jedes ONCRPC-Servers noch normal funktioniert. Außerdem bereinigt die Task Überbleibsel von beendeten Serverprozessen.

Jedes Mal, wenn die Task ausgeführt wird, ruft sie eine Liste mit den Kennungen der von CM Server aufgerufenen Back-End-Serverobjekte ab, die die Markierung AKTIV haben. Jedes Back-End-Serverobjekt wird getestet, um sicherzustellen, dass ein funktionierender Sicherungsprozess aktiv ist. Für jeden ermittelten fehlerhaften Back-End-Prozess wird wie folgt die Bereinigung des Serverobjekts eingeleitet (diese Ereignisse werden durch Protokollnachrichten erfasst):
  • Das Serverobjekt wird als nicht funktionsfähig markiert, damit dem Server keine weitere Arbeit zugeteilt wird.
  • Eine Benachrichtigung hinsichtlich der MBean-Bereinigung wird in die Warteschlange gestellt, und innerhalb von fünf Sekunden wird die Benachrichtigung asynchron empfangen, und es werden alle Bereinigungsvorgänge für das fehlerhafte Serverobjekt ausgeführt.
  • Das Serverobjekt wird aus der Serverobjektliste der übergeordneten verwalteten Verbindungs-Factory entfernt.
  • Die Registrierung der MBean, die diesem Server zugeordnet ist, wird rückgängig gemacht.

Anschließend ruft die Task eine aktualisierte Liste der Server mit dem Status "STOPPING" (Kennung für inaktive Server) ab. Für jedes Serverobjekt, das länger als 30 Sekunden im Status "STOPPING" war, wird der Sicherungsprozess des Serverobjekts geprüft, um sicherzustellen, dass der Prozess tatsächlich gestoppt wurde. Ist das nicht der Fall, wird das Stoppen des Prozesses erzwungen, und der Prozess wird aus der Serverliste der Factory entfernt. Server, die nicht mindestens 30 Sekunden im Status "STOPPING" waren, werden in der Serverliste der Factory gelassen und bei der nächsten Ausführung der Task überprüft.

Produktspezifische Life-Cycle-Management-Tasks für verwaltete Verbindungs-Factorys

Zusätzliche zur generischen Life-Cycle-Management-Task steuern eine unabhängige ClearCase-Task und eine unabhängige ClearQuest-Task das produktspezifische Life-Cycle-Management der entsprechenden Back-End-Serverprozesse.

Der Back-End-ONCRPC-Server von ClearQuest (auch als cqrpc-Prozess bezeichnet) ist ein Multithread-Prozess. Es gibt normalerweise eine kleine Anzahl von cqrpc-Prozessen, die jederzeit ausgeführt werden können. Der Back-End-ONCRPC-Server von ClearCase (auch als ccrpc-Prozess bezeichnet) ist ein Single-Thread-Prozess. Es gibt normalerweise viele dieser Prozesse, die jederzeit ausgeführt werden können. Die produktspezifischen verwalteten Verbindungs-Factorys verwenden konfigurierbare MBean-Attribute, um die Anzahl und Lebensdauer aktiver Prozesse zu steuern und die Fähigkeit des Systems, mit der Arbeitslast Schritt zu halten, aufrechtzuerhalten und gleichzeitig einen Leistungsabfall aufgrund exzessiver Ressourcenauslastung zu verhindern.

Life-Cycle-Management für verwaltete Verbindungs-Factorys von ClearCase

Es gibt eine Reihe von MBean-Schlüsselattributen, die verwendet werden, um die Anzahl zu aktivierender ccrpc-Prozesse zu steuern. Die Standardeinstellungen für diese Parameter müssen möglicherweise geändert werden, je nachdem, auf welchem System CM Server installiert ist und welche Servernutzung, basierend auf Auslastung und Kapazität, erwartet wird:
  • Das MBEan-Attribut CcServerFactoryMBean.serverThresholdCount gibt einen Grenzwert für die Anzahl der CCRPC-Servern an. Wird dieser Grenzwert erreicht, ein integriertes Life-Cycle-Management in der verwalteten Verbindungs-Factory von ClearCase auslöst.
  • Das MBEan-Attribut CcServerFactoryMBean.maxServerCount gibt die maximale Anzahl der CCRPC-Server an, die in der verwalteten Verbindungs-Factory von ClearCase gleichzeitig erstellt werden können.
  • Das MBean-Attribut CcServerFactoryMBean.maxServersPerCredential verhindert, dass Clientanwendungen zu viele Threads pro Benutzersitzung erstellen.

Diese Werte können mit dem Befehlszeilendienstprogramm wsadmin angepasst werden. Informationen zu den MBean-Attributen und ihrer Konfiguration finden Sie im Artikel Verfügbare MBean-Attribute definieren. Parameter wie Speichergröße, Prozessorgeschwindigkeit und andere Systemattribute steuern, wie diese und andere CcServerFactoryMBean-Werte gesetzt werden sollen.

Wenn eine ClearCase-Anforderung von einem Client an CM Server gesendet wird, wird versucht, ein Back-End-Serverobjekt zur Verarbeitung der Anforderung abzurufen. Die folgenden integrierten Prüfungen werden für jede eingehende Anforderung durchgeführt:
  • In der Liste der Serverobjekte von ClearCase wird nicht ausgelasteter Server gesucht, der die Anforderung ausführen könnte. Ein Serverobjekt wird als ausgelastet betrachtet, wenn er bereits eine andere Anforderung verarbeitet. Wenn ein vorhandenes Serverobjekt nicht ausgelastet ist und die Berechtigungsnachweise für die Anforderung erbringt, wird die Anforderung von diesem Serverobjekt bearbeitet.
  • Wenn keine vorhandenen Serverobjekte die Berechtigungsnachweise erbringen können bzw. wenn die vorhandenen Serverobjekte ausgelastet sind, muss ein neues Serverobjekt erstellt und der Anforderung zugeordnet werden. Das ist nur möglich, wenn die verwaltete Verbindungs-Factory die entsprechende Kapazität aufweist:
    • Wenn die im Attribut CcServerFactoryMBean.maxServersPerCredential oder die im Attribut CcServerFactoryMBean.maxServerCount definierte Anzahl ccrpc-Server erreicht ist, geht der Worker-Thread, der für die Verarbeitung der Clientanforderungen vorgesehen ist, in eine Warte-und-Wiederholungsschleife. In den Attributen TeamServerMBean.maxProcureServerAttempts und TeamServerMBean.procureServerInterval ist festgelegt, wie oft und wie lange (in Sekunden) versucht wird, einen Server anzufordern.
    • Wenn kein Server angefordert werden kann, wird die Clientanforderung zurückgewiesen. (Andernfalls wird ein neues Serverobjekt erstellt und der Anforderung zugeordnet.)

Zusätzlich zu den oben genannten integrierten Prüfungen, die beim Eingehen jeder Anforderung durchgeführt werden, führt eine ClearCase-spezifische Life-Cycle-Management-Task die folgenden untergeordneten Tasks aus:

Alle zwei Minuten wird eine Liste aller ccrpc-Server, die einen bestimmte Zeitraum (in Sekunden) oder länger inaktiv waren (Wert ist im Attribut CcServerFactoryMBean.idleServerInterval definiert), erstellt, und jeder Server in dieser Liste wird wie folgt gestoppt:
  • Die Serverinstanz wird in den Status "STOPPING" versetzt, damit dem Server keine weitere Arbeit zugeteilt wird.
  • Eine Benachrichtigung zum Beenden der MBean (MBean TERMINATE) wird in die Warteschlange gestellt, und innerhalb von fünf Sekunden wird die Benachrichtigung asynchron empfangen, und es werden alle Bereinigungsvorgänge für das Serverobjekt ausgeführt.
  • Eine RPC-Nachricht zum Systemabschluss (shutdown) wird an den ccrpc-Serverprozess gesendet, und die Serverinstanz wechselt in den Status "STOPPED".
  • Die aktuelle Uhrzeit wird in der Serverinstanz erfasst und gespeichert, so dass die generische CheckServer-Task weiß, wie lange der Server im Status "STOPPED" war.
  • Die Serverobjektinstanz wird aus der Serverliste der Verbindungs-Factory entfernt.
  • Die Registrierung der MBean, die diesem Server zugeordnet ist, wird rückgängig gemacht.

Life-Cycle-Management für verwaltete Verbindungs-Factorys von ClearQuest

Das Life-Cycle-Management von ClearQuest besteht aus einer Hintergrundtask, die alle zwei Minuten ausgeführt wird, und aus einigen Prüfungen im Vordergrund, die pro Client ausgeführt werden, wenn die Anforderungen verarbeitet werden. Die Prüfungen werden ausgeführt, um festzustellen, ob Grenzwerte für kritische Ressourcen erreicht wurden:
  • Wenn ein zeitgesteuerter Stopp und Neustart aktiviert ist (d. h., wenn der im Attribut CqServerFactoryMBean.recycleServerLifetimeLimit definierte Wert größer als null ist und alle cqrpc-Serverobjekte mindestens so lange aktiv waren wie durch den Wert angegeben), wird das cqrpc-Serverobjekt für Stopp und Neustart vorgesehen und entsprechend markiert.
  • Wenn eine Clientanforderung abgeschlossen ist, wird eine Prüfung ausgeführt, um festzustellen, ob das cqrpc-Serverobjekt mindestens eine bestimmte Anzahl von RPC-Aufrufen verarbeitet hat (der Wert ist im Attribut CqServerFactoryMBean.recycleServerOncrpcCallLimit definiert). Ist das der Fall, wird das cqrpc-Serverobjekt für Stopp und Neustart vorgesehen und entsprechend markiert.
  • Wenn eine Clientanforderung eingeht und der Sitzungszähler inkrementell erhöht wird, wird eine Prüfung ausgeführt, um festzustellen, ob das cqrpc-Serverobjekt mindestens eine bestimmte Anzahl von HTTP-Sitzungen erstellt hat (der Wert ist im Attribut CqServerFactoryMBean.recycleServerHttpSessionLimit definiert). Ist das der Fall, wird das cqrpc-Serverobjekt für Stopp und Neustart vorgesehen und entsprechend markiert. In diesem Fall wird ein neues cqrpc-Serverobjekt gestartet, um die eingehende Anforderung zu verarbeiten.

Die verwaltete Verbindungs-Factory von ClearQuest stoppt cqrpc-Serverprozesse und startet sie erneut, anstatt sie zu beenden (wie das die verwaltete Verbindungs-Factory von ClearCase für nicht mehr benötigte ccrpc-Serverobjekte tut). Der Grund dafür ist, dass cqrpc-Serverobjekte möglicherweise Elemente wie Abfragen oder Datensätze enthalten, die festgeschrieben werden sollen. Daher wird eine Nachfrist für alle zur Festschreibung anstehenden Arbeitsvorgänge eingeräumt.

Stopp und Neustart eines cqrpc-Serverobjekts setzen sich aus folgenden Aktionen zusammen:
  • Das Serverobjekt wird in den Status "STOPPING" (Status für Stopp und Neustart) versetzt, damit dem Server keine weitere Arbeit zugeteilt wird.
  • Eine Benachrichtigung zu Stopp und Neustart der MBean (MBean RECYCLE) wird in die Warteschlange gestellt. Die Benachrichtigung wird innerhalb von fünf Sekunden asynchron empfangen. Alle schreibgeschützten Sitzungen (READ-ONLY), die dem Serverobjekt zugeordnet sind, werden für erneute Zuordnung zu einem neuen Serverobjekt markiert, wenn die nächste Anforderung für diese Sitzung eingeht.

    Sitzungen, in denen bereits eine Lese-/Schreibaktion (READ-WRITE) ausgeführt wird (d. h., eine Transaktion, bei der eine Abfrage oder ein Datensatz festgeschrieben wird) wird eine Nachfrist (der Wert in Sekunden ist im Attribut CqServerFactoryMBean.recyclingPeriod definiert) zum Festschreiben der ausstehenden Arbeitsvorgänge eingeräumt. Wenn die Arbeit festgeschrieben ist oder der im Attribut CqServerFactoryMBean.recyclingPeriod definierte Wert erreicht ist, wird das Objekt in den Status "STOPPED" versetzt, sein Sicherungsprozess wird beendet, und das Serverobjekt wird aus der Serverliste der verwalteten Verbindungs-Factory von ClearQuest entfernt.


Feedback