Ein inhomogener Management Cluster ist ein Management Cluster bestehend aus einem SE Server mit allen Units (MU, HNC, SU x86) mit der Version V6.2 und einem weiteren SE Server mit allen Units (MU, HNC, SU x86) mit der Version V6.3. Diese Situation kann auftreten, wenn die beiden Server eines Management Clusters in zwei Schritten hochgerüstet werden.
Generell kann gesagt werden, dass neue Funktionen für Units mit der Version V6.2 nicht verwendet werden sollten, auch wenn die neuen Funktionen für sie angezeigt werden.
Dieses Kapitel behandelt spezielle Themen und Einschränkungen, die in einem inhomogenen Management Cluster berücksichtigt werden müssen.
Zustände der Units
In V6.3 können neue Systemzustände (System-Status) für Units auftreten:
- Wenn der Ressourcenmonitor (ResMon) ein Ressourcenproblem feststellt, wird der System-Status für diese Unit auf WARNING gesetzt.
- Wenn eine AU nur für die HW-Überwachung registriert wurde, wird ihr System-Status auf NOT_MONITORED gesetzt.
Diese Zustände sind in älteren Versionen bzw. in V6.2 nicht vorgesehen.
Daher gibt es bei V6.2 MUs folgende Einschränkungen:
- Übersichtsfenster für Units und Systeme
- Units: Die AUs mit dem System-Status NOT_MONITORED und die Units mit dem System-Status WARNING werden mit dem allgemein für UNKNOWN / NOT_ACCESSIBLE verwendeten Symbol angezeigt.
- Systeme: Die den NOT_MONITORED-AUs zugeordneten Systeme sind Native-AU-Systeme und werden mit dem allgemein für UNKNOWN / NOT_ACCESSIBLE verwendeten Symbol angezeigt.
- In den Tabellen fehlen die entsprechenden Filterwerte.
- Die SEM-Menüs für diese Units werden nicht angezeigt oder sind aufgrund des unbekannten Status eingeschränkt.
(Hardware, Geräte, Systeme) - SEM Dashboard: Aufgrund des unbekannten Wertes ist die Zählung im Dashboard nicht korrekt:
- In der Kachelansicht werden die NOT_MONITORED-AUs nicht gezählt, so dass der Zähler aller Units nicht die Summe der Units für die einzelnen Zustände ist.
- In der Listenansicht fehlen die NOT_MONITORED-AUs und die Summe pro Zeile passt nicht.
- In der Listenansicht fehlen die Native-AU-Systeme der NOT_MONITORED-AUs und die Summe pro Zeile passt nicht.
Audit-Logging-Einträge
Hinsichtlich der An- und Abmeldung wurde das Audit Logging in V6.3 um neue Eintragstypen erweitert.
In V6.2 sind diese Eintragstypen nicht bekannt, so dass in der Spalte Typ interne Werte wie "login_successful" oder "logout" angezeigt werden.
In V6.3 fehlen auch die richtigen Filterwerte für diese Eintragstypen.
Alarm-Management und komponentenspezifische Benachrichtigung
- Mail- und Trap-Empfänger, die auf V6.2 MUs erstellt (oder ab V6.2 durch CSR wiederhergestellt) wurden, werden auf V6.3 MUs so dargestellt und behandelt, als wären sie für Komponente = ANY definiert und können nicht von einem neuen Eintrag mit expliziter Angabe von Komponente = ANY unterschieden werden. (In dieser Situation kann es zu doppelten Einträgen kommen und Alarme werden doppelt gesendet. Es macht keinen Unterschied, welcher Eintrag gelöscht wird).
Falls sie komponentenspezifisch gemacht werden müssen, sind sie zu löschen und neu anzulegen. - Mail- und Trap-Empfänger, die auf V6.3 MUs mit dem gleichen Empfänger, aber mit unterschiedlichen Komponenten erstellt wurden, werden auf V6.2 MUs als Duplikate angezeigt.
Ist der Cluster Manager eine V6.2 MU, werden Alarme für diese Empfänger mehrfach und unabhängig von den angegebenen Komponenten gesendet.
IORSF-Dateien erzeugen und auf den SVP übertragen
Die Generierung von IORSF-Dateien und deren Übertragung auf den SVP erfolgt immer auf der MU mit dem Status ACTIVE bezüglich der SVP-Konsole der SU /390 des jeweiligen Servers.
Einschränkung:
Auf MU mit der Version V6.2 sind die neuen Funktionen nicht vorhanden.
Wenn eine solche MU aufgerufen wird, führt dies zu einem Fehler: “Not Found. The requested URL ... was not found on this server”.
IORSF-Dateiliste aktualisieren
- In großen Konfigurationen mit vielen BS2000-Geräten kann die Aktualisierung der IORSF-Dateiliste sehr lange dauern und den für den Dialog von SEM eingestellten Timeout-Wert überschreiten. In diesem Fall wird der Dialog mit einer Fehlermeldung abgebrochen.
Dies geschieht bei V6.2-MUs, bei denen der Dialog mit der Meldung "Die LAN-Verbindung wurde unterbrochen und das Ergebnis der Aktion konnte nicht ermittelt werden" abgebrochen wird.
Trotzdem wird die Aktualisierung der IORSF-Dateiliste im Hintergrund fortgesetzt und erfolgreich beendet.
Bei V6.3-MUs geschieht dies nicht.
Daher wird dem Anwender empfohlen, diesen SEM-Dialog immer auf einer V6.3-MU aufzurufen, auch wenn es sich bei den betroffenen MUs um V6.2-MUs handelt. - Beim Aufbau eines Clusters gehen die IORSF-Datei und die Gerätelisten für einen der beiden Server verloren.
Bitte überprüfen Sie die IORSF-Datei- und Gerätelisten auf beiden Servern und aktualisieren Sie diese gegebenenfalls.
Setzen des Namens der SU /390
Einschränkung:
Der Name einer SU /390, die zu einem Server mit Units der Version V6.2 gehört, kann gesetzt werden.
Dies ist aber nicht empfehlenswert:
Der Name wird auf den MUs mit Version V6.3 nur für eine kurze Zeit angezeigt und verschwindet bald.
Aufruf der SVP-Konsole
Einschränkung:
In einem inhomogenen Management Cluster kann auf die SVP-Konsole nur über den SE Manager einer MU desselben SE Servers zugegriffen werden, zu dem auch die SU /390 gehört.
(-> Verwenden Sie eine V6.2-MU für die SVP-Konsole auf einem V6.2-Server und verwenden Sie eine V6.3-MU für die SVP-Konsole auf einem V6.3-Server!)
Aufruf des Schattenterminals
Einschränkung:
In einem inhomogenen Management Cluster ist das Schattenterminal auf einer MU nur über den SE Manager einer MU desselben SE Servers erreichbar, zu dem auch die adressierte MU gehört.
(-> Verwenden Sie eine V6.2-MU für das Schattenterminal auf einem V6.2-Server und verwenden Sie eine V6.3-MU für das Schattenterminal auf einem V6.3-Server!)
Installation von Hot Fixes in einem inhomogenen Management Cluster
Das Format der Hot Fixes wurde in M2000/HNC/X2000 V6.3 geändert.
Altes Formatbeispiel (<= V6.2): MV6.2A0501.A099999990-H05
Neues Formatbeispiel (>= V6.3): MV6.3A0456H012
Bedeutung von MV6.3A0456H012:
- Der 2. Increment des Hot Fix 01 für M2000 V6.3A0456.
- Ein Hot Fix fasst generell die Korrekturen für mehrere Probleme (PMs) zusammen.
Einschränkung:
In einem inhomogenen Management Cluster können Hot Fixes nur über den SE Manager einer MU des gleichen SE Servers hochgeladen werden, zu dem die Ziel-Unit gehört. (-> Verwenden Sie V6.2-MUs zum Hochladen von V6.2-HFs und V6.3-MUs zum Hochladen von V6.3-HFs!)
Neue Hauptfenster
In V6.3 gibt es im Vergleich zu V6.2 drei neue Hauptfenster:
- Systeme -> <SU /390> -> SVP-Konsole
- Hardware -> Units -> Update Übersicht
- Service -> Information
Wechselt man die MU (über die Header-Funktionalität) von einer V6.3 zu einer V6.2-MU und eines dieser Fenster ist geöffnet, so wird das entsprechende Fenster nicht gefunden und es wird "Not Found / Die angeforderte URL ... wurde auf diesem Server nicht gefunden" angezeigt.
Situative Abhängigkeiten (Cluster Manager auf V6.2 MU, MU abgeschaltet, ...)
Läuft der Cluster Manager auf einer V6.2 MU, so werden die sogenannten globalen Daten auf dieser MU ermittelt.
Dies bedeutet, dass einige in V6.3 eingeführte Daten nicht verfügbar sind und auf der V6.3-Seite bzw. bei V6.3-Units einige Einschränkungen bestehen.
- System-Status WARNING für Units:
- Da der Ressourcen-Monitor nicht aufgerufen wird, wird es keinen Status WARNING geben.
- Das Ereignis "State of unit '<hostname>' changed from '<oldstate>' to 'WARNING'" wird nicht erzeugt.
- IP-Netzwerke
- Die Ursachen für die von NORMAL abweichenden Zustände werden nicht erkannt und werden nicht angezeigt.
- Auch das Warnsymbol im Dashboard wird nicht angezeigt.
Falls die V6.3-MUs ausgeschaltet sind und die Abfrageprozesse auf den V6.2-MUs laufen, gibt es einige zusätzliche Einschränkungen:
- System NOT_MONITORED für Geräte:
- Dieser Systemstatus ist in V6.2 nicht bekannt. Stattdessen wird der Status UNCONFIGURED angezeigt.
CLI remoteCommand
Einschränkung:
In einem inhomogenen Management Cluster sollte remoteCommand nur innerhalb eines Servers verwendet werden, d.h. MU und Ziel-Unit (derzeit SU x86) sollten sich im selben Server befinden. (-> Verwenden Sie für remoteCommand-Aufrufe V6.2-MUs für V6.2-SUs und V6.3-MUs für V6.3-SUs!)