UMS HA Health-Check(Statusprüfung) – Analyse Ihrer IGEL UMS High-Availability- und Distributed-UMS-Systeme

Mit dem UMS HA Health-Check(Statusprüfung) können Sie eine Gesamtprüfung Ihrer IGEL Universal Management Suite(UMS) Multiinstanz-Installation durchführen. Dabei wird gerpüft ob die Interaktion zwischen den Komponenten des High Availability-Sytsems (HA) oder der Distributed UMS funktioniert, insbesondere, ob die Komponenten Nachrichten und Daten austauschen können.

Die Berechtigung zur Nutzung der UMS HA Health-Check(Statusprüfung) Funktion kann unter System > Administrator accounts eingestellt werden, siehe Allgemeine Administratorrechte.

Menüpfad: Menüleiste > Help > UMS HA Health-Check(Statusprüfung)

Um Ihre HA-Umgebung / Distributed UMS zu überprüfen, gehen Sie wie folgt vor:

Stellen Sie sicher, dass die Server und die darauf installierten Komponenten im normalen Betriebsmodus sind.
Gehen Sie in der Menüleiste auf Help > UMS HA Health-Check.
Deaktivieren Sie das Kontrollkästchen Clear cached performance data before check, wenn Sie möchten, dass die gepufferten Daten aus früheren Läufen in die Analyse einbezogen werden.

Nachdem die erforderlichen Daten gesammelt und analysiert wurden, öffnet sich ein Fenster, in dem die Ergebnisse und die entsprechenden Empfehlungen in einer Reihe von Registerkarten dargestellt werden. Jede Registerkarte hat eine Schaltfläche Show Details, die einen detaillierten Analysebericht im HTML-Format öffnet. Die Beschreibung der einzelnen Registerkarten und des HTML-Berichts finden Sie weiter unten.

Nachrichten (Messaging)

Diese Prüfung ermittelt, ob die Komponenten laufen und Nachrichten austauschen können. Es wird ein Ping-Test zwischen den Komponenten einer High Availability Installation auf jedem Server durchgeführt. Die Liste zeigt das Ergebnis mit der Angabe der Übertragungszeit für jede Kombination der Komponenten. Die Übertragungszeit gibt für den UMS HA an, ob das ActiveMQ-Messaging innerhalb des Subnetzes funktioniert oder nicht.

Wenn Sie eine Distributed UMS-Installation haben, können die unter Messaging angezeigten Ergebnisse ignoriert werden, da der UMS HA Health-Check hauptsächlich die Leistung des ActiveMQ-Messaging der UMS High Availability (innerhalb des Subnetzes) überprüft. Für die Distributed UMS zeigt die Registerkarte Messaging die Nachrichtenverzögerung über die Datenbank an, die ca. 30 Sekunden beträgt.

Derzeit können Sie auch Folgendes ignorieren:

die Messaging-Ergebnisse des UMS HA Health-Checks, wenn Ihre UMS HA-Installation ohne IGEL UMS Load Balancer in verschiedenen Subnetzen oder in einer Cloud-Umgebung betrieben wird
Fehlermeldungen von Watchdogs, wenn Sie einen UMS HA ohne IGEL UMS Load Balancer haben

Die Gründe, warum Messaging zwischen Komponenten nicht möglich ist, sind in der Regel die folgenden:

Eine der Komponenten läuft überhaupt nicht.
Die notwendigen Ports, 61616 und 6155, sind in der Firewall nicht geöffnet. Siehe IGEL UMS Kommunikationsports.
Die Systemzeit auf den Servern ist sehr unterschiedlich.

Um Probleme mit Ihrer HA-Installation zu vermeiden, stellen Sie sicher, dass die Zeit auf den Servern des HA-Netzwerks nicht mehr als eine Minute voneinander abweicht. Nach jeder manuellen Zeitumstellung müssen die HA-Dienste auf dem jeweiligen Server neu gestartet werden.

Das IGEL Netzwerktoken unterscheidet sich zwischen den Komponenten. Dies kann beispielsweise dadurch geschehen, dass bei der Installation weiterer UMS Server / UMS Load Balancer innerhalb eines HA-Netzwerks ein neues IGEL Netzwerktoken generiert wird, anstatt das ursprünglich bei der Installation des ersten UMS Servers erstellte Netzwerktoken zu verwenden.

WebDav

Dieser Check prüft, ob die UMS Server Dateien über WebDav austauschen können. WebDav ist für die Synchronisation von Dateien zwischen den UMS Servern zwingend erforderlich. Siehe auch Welche Dateien werden zwischen den IGEL UMS Servern automatisch synchronisiert?.

Mögliche Gründe für den Fehler sind folgende:

Eine der Komponenten läuft überhaupt nicht.
WebDav-Port 8443 ist in der Firewall nicht geöffnet.

Port 30001

Port 30001 wird für Verbindungen zwischen den Geräten und dem UMS Load Balancer verwendet. Da der Test kein Gerät imitieren kann, versuchen die UMS Server, sich über Port 30001 mit dem UMS Load Balancer zu verbinden.

Mögliche Gründe für einen Fehlschlag sind folgende:

Eine der Komponenten läuft gar nicht.
Port 30001 ist in der Firewall nicht geöffnet.

Port 30002

Port 30002 wird vom UMS Load Balancer für die Weiterleitung von Anfragen vom Gerät an den UMS Server verwendet.

Mögliche Fehlerursachen sind folgende:

Eine der Komponenten läuft überhaupt nicht.
Port 30002 ist in der Firewall nicht geöffnet.

Zertifikate

Dieser Check vergleicht die auf dem UMS Server gespeicherten Zertifikate mit denen auf dem UMS Load Balancer.

Ein möglicher Grund für das Scheitern kann folgender sein:

Fehler in der Kommunikation zwischen den Komponenten aufgrund der unterschiedlichen IGEL Netzwerktokens, siehe den obigen Abschnitt "Messaging".

Weitere Prüfungen

Werden weitere Probleme festgestellt, werden hier die entsprechenden Ergebnisse und Empfehlungen angezeigt.

Detalierter Bericht

Ein detaillierter Bericht, der nach einem Klick auf die Schaltfläche Show Details im HTML-Format generiert wird, liefert einige zusätzliche Informationen.

Tipp zur Kontaktaufnahme mit dem IGEL Support

Wenn die genannten Empfehlungen nicht zur Lösung der Probleme beigetragen haben, speichern Sie den HTML-Bericht und senden Sie ihn zusammen mit dem Archiv mit den Support-Informationen an den IGEL Support, das in der Menüleiste unter Help> Save support information erstellt werden kann.

Rollen: Die Prüfung zeigt anhand der Ergebnisse, welche Rollen für die Server möglich sind.

Beispiel:

Konfigurationsinformationen: Zeigt die Konfigurationsinformationen, wie sie von den Prozessen bereitgestellt werden. Für einen UMS Load Balancer, d.h. UMS Broker-Prozess, werden die bekannten Server dieses Load Balancers angezeigt.

Prozess-Info: Gibt einen Überblick über die Prozesse.

Zertifikat-Fingerprints: Zeigt Fingerprints der Zertifikate, die in der Datenbank auf dem UMS Server und der tc.keystore Datei auf dem UMS Load Balancer gespeichert sind.