Cluster-Statistiken

15.10.2006 von Martin Kuppinger
Die Statistiken, die für die Analyse von Clustern und deren aktuellem Verhalten eine Rolle spielen, sind in einzelne Kategorien aufgeteilt, die sich an den verschiedenen Komponenten des Cluster-Dienstes orientieren. Die wichtigsten statistischen Daten und ihre Bedeutung stellen wir im Folgenden vor.

Die Statistiken für Cluster lassen sich in drei Gruppen aufteilen:

Betriebssystem-Statistiken
Ergänzend zu den Statistiken von Domino kann noch mit Betriebssystem-Statisitken gearbeitet werden. Diese liefern zwar keine so differenzierten Informationen zur Nutzung von Domino auf den Knoten in einem Cluster, aber ergänzende Werte zur CPU- oder Festplattenperformance, die für eine optimale Dimensionierung und Konfiguration des Clusters erforderlich sind.

Statistiken für den Cluster-Manager

Die drei wichtigsten statistischen Werte, die der Cluster-Manager liefert, sind wohl Member, AvailabilityIndex und AvailabilityThreshold. Sie liefern zentrale Informationen zur Verfügbarkeit der Knoten in einem Cluster. Die erste Information zeigt die Namen und Verfügbarkeits-Indizes der verschiedenen Knoten an. Der Verfügbarkeitsindex (AvailabilityIndex) als zweiter Wert gibt an, wie hoch die Verfügbarkeit des Servers war. Ein Wert von 0 bedeutet, dass keine Ressourcen zur Verfügung stehen. Ein Wert von 100 steht für einen überhaupt nicht ausgelasteten Server. Der AvailabilityThreshold ist schließlich ein Schwellwert. Wenn die Verfügbarkeit des Servers kleiner oder gleich diesem Wert ist, wird er in den Status busy gesetzt und nimmt keine neuen Anforderungen mehr an.

Im Zusammenhang mit diesen Parametern ist auch der ExpansionFactor von Bedeutung. Der über die notes.ini mit Server_Transinfo_Range konfigurierbare Wert wird für die Berechnung des AvailabilityIndex verwendet. Standardmäßig reicht der Wertebereich von 1 bis 64. Ein Wert von 64 gibt an, dass es 64-mal länger dauert, um eine Transaktion auszuführen, als es der Idealfall wäre. Wenn eine Transaktion so lange dauert, wird der AvailabilityIndex auf 0 gesetzt. Durch eine Verringerung des Wertes kann man die vollständige Auslastung eines Servers zu einem früheren Zeitpunkt als erreicht berechnen lassen. Ein Wert von 20 würde beispielsweise angeben, dass Transaktionen nur 20-mal so lange dauern wie in der besten Situation, damit ein Server voll ausgelastet ist.

Weitere statistische Werte

Wichtiger als dieser Wert ist aber der AvailabilityThreshold, weil man über ihn steuert, wann ein Server als stark belastet gilt. Um weitere Anforderungen an einen Server zu verhindern, kann man auch einfach diesen Schwellwert anpassen, um einen Server früher oder später als ausgelastet zu kennzeichnen und in den busy-Status zu setzen.

Eine zweite Gruppe von Parametern beginnt mit OpenRedirects.Failover. Diese Parameter liefern Informationen darüber, wie viele Anforderungen für ein Failover erfolgreich verarbeitet werden konnten bzw. gescheitert sind.

In ähnlicher Weise geben die Parameter OpenRedirects.LoadBalance an, wie viele Anforderungen wegen zu hoher Auslastung eines Servers an andere Knoten weitergegeben werden konnten, und wo das nicht funktioniert hat.

Bei beiden Gruppen von statistischen Informationen gibt es auch die Variante byPath, Sie liefern die Informationen mit Bezug auf Pfadnamen zu Datenbanken, während ansonsten mit der Replika-ID gearbeitet wird.

Die Parameter der Gruppe OpenRequest liefern Informationen zur Verarbeitung von Anforderungen. Dabei wird angegeben, wie viele Anforderungen von Clients nicht verarbeitet werden konnten, weil der gesamte Cluster oder der spezifische Server beschäftigt waren oder eine Datenbank nicht betriebsbereit war.

Weitere Statistikparameter liefern Daten zur Cluster-internen Kommunikation und zu den verwendeten Ports.

Statistiken für den Cluster-Replicator

Die Informationen zum Cluster-Replicator zeigen an, ob und wie die clusterinterne Kommunikation funktioniert.

Der Wert Servers zeigt an, wie viele andere Server Replikationsinformationen vom aktuellen Server empfangen. Die Werte für Failed und Successful geben die Gesamtzahl der fehlgeschlagenen beziehungsweise erfolgreichen Replikationsversuche an. Die Zahl bei Successful sollte natürlich wesentlich höher sein als die der Fehler.

Die verschiedenen Statistiken der Gruppe Docs informieren darüber, wie viele Dokumente durch den Cluster-Replicator in welcher Form (Hinzufügen, Ändern, Löschen) verarbeitet wurden.

Statistiken für den Internet Cluster-Manager

Nun kommen wir noch zu den Statistiken für den Internet Cluster-Manager. Auch sie lassen sich in mehrere Gruppen aufteilen. Der wichtigste Parameter ist ICM.AvailabilityIndex. Damit wird die Information zur Verfügbarkeit der Internet-Clusterdienste geliefert.

Die Werte, die mit ICM.Commands beginnen, liefern Informationen zur Verarbeitung von Anforderungen, die an den Cluster gestellt wurden. Die einzelnen Werte enthalten Daten wie die Anzahl der Befehle und Informationen zur Weiterleitung an andere Knoten im Cluster.

Interessant sind auch die drei Informationen zu ICM.Requests. Damit wird die Anzahl der Anforderungen in der vergangenen Stunde, in den letzten fünf Minuten und der letzten Minute ausgegeben.

Die beiden größten Gruppen sind ICM.Sessions.Inbound und ICM.Sessions.Outbound. Sie zeigen Informationen zu ein- und ausgehenden Sitzungen an, die vom Cluster verarbeitet werden. Dazu zählen die Anzahl der Sitzungen, die Anzahl der Bytes, die maximale Zahl paralleler Verbindungen und eine Unterscheidung zwischen SSL- und Nicht-SSL-Verbindungen.

Schließlich gibt es noch mehrere Parameter in der Gruppe ICM.Threads. Sie geben die Anzahl der Threads an, die vom Internet Cluster-Manager für die Verarbeitung von Anforderungen benötigt werden.

Insgesamt lässt sich anhand der verschiedenen Parameter sehr genau nachvollziehen, wie sich die Belastung von Clustern zu welchem Zeitpunkt gestaltet hat. Außerdem lassen sich auch Probleme leicht erkennen, wenn sich beispielsweise die Kommunikationsfehler erhöhen. Eine kontinuierliche Analyse und die Sammlung von Vergleichswerten sind daher unbedingt empfehlenswert, um sicherzustellen, dass die Cluster möglichst zu jedem Zeitpunkt optimal funktionieren.