6 Minuten Lesezeit (1209 Worte)

WebLogic-Server - Node Manager | Magier im Verborgenen

Dienstag, 11. Juli 2017

Mit dem Node Manager steht ein mächtiges Werkzeug im WebLogic-Server zur Verfügung, um Managed-Server überwachen und bei Bedarf nachstarten zu können. Managed-Server sind die Arbeitspferde in einer WebLogic-Infrastruktur, denn auf ihnen laufen geschäftskritische JEE-Applikationen – zumindest sollte es so sein. Da diese Arbeitspferde von zentraler Bedeutung sind, müssen sie sorgfältig und zuverlässig überwacht werden. Und genau da kommt der Node Manager ins Spiel – ein Tool, das schon sehr lange zum WebLogic-Server-Repertoire gehört, welches allerdings im Ruf steht, kompliziert und schwer handhabbar zu sein. Das muss überprüft werden und daher schauen wir uns den Node Manager mit seinen Prinzipien, seinen Einsatzmöglichkeiten und seiner Wirkungsweise mal etwas genauer an.

Node-Manager-Motivation

Beim WebLogic-Server ist die Domain die große, umfassende Klammer, die alle wichtigen WLS-Komponenten wie Managed-Server, Administration Server, Cluster etc. beinhaltet. Dabei übernehmen die Managed-Server die Rolle der produktiven Einheit, d.h. sie hosten JEE-Anwendungen und stellen ihnen ihre Ressourcen, wie CPU und Hauptspeicher, zur Verfügung.

Für den reibungslosen Ablauf von JEE-Anwendungen ist somit die ständige Verfügbarkeit der Managed-Server von existentieller Bedeutung. Sie müssen sorgfältig überwacht werden und in Stresssituationen sind geeignete Reparatur- oder Restart-Maßnahmen vorzunehmen. Und genau da kommen die Stärken des Node Managers ins Spiel.

Node Manager:
Simple Aufgabe, schwierige Erfüllung

Der Node Manager hat eine gleichermaßen einfach zu beschreibende wie auch hochkomplexe Aufgabenstellung zu bewältigen – nämlich die Sicherstellung, dass sich Managed-Server jederzeit in einem arbeitsfähigen Zustand befinden, wobei „jederzeit" natürlich nicht wortwörtlich gemeint ist. Denn einem großflächigen Stromausfall mit gleichzeitigem Versagen sämtlicher Sicherungssysteme kann man nicht entkommen. In solchen Fällen ist es schlicht nicht möglich, Managed-Server am Leben zu erhalten.

Wir nehmen den eher praxisrelevanten Blickwinkel ein. Der Prozess eines Managed-Servers kann durch unterschiedliche Ereignisse in Schwierigkeiten geraten, z.B. indem der Überlauf des Hauptspeichers droht oder die maximale Anzahl gleichzeitig geöffneter Ressourcen (Dateideskriptoren, Socket-Verbindungen o.Ä.) überschritten wird. Prozessabstürze, die aus so etwas resultieren, sind im Fokus des Node Managers. Sie sollen detektiert und die Server zügig wieder hochgefahren werden.

Die Basisarchitektur

Zunächst jedoch wollen wir einige grundlegende Prinzipien des Node Managers thematisieren. Die Basis-fähigkeit des Node Mangers besteht darin, Server starten zu können. Das klingt erstmal wenig aufregend, liefert aber den Schlüssel für das Einsatzgebiet dieses Gehilfen, welches auch in Abbildung 1 schematisch dargestellt ist.
Die Funktionalität und Grundeigenschaften des Node Managers in stringenter, kontinuierlicher Erzählweise vorzustellen, fällt etwas schwer. Daher soll dies stichpunktartig erfolgen, in der Hoffnung, den etwas sperrigen Zugang zu erleichtern.

In typischen WLS-Umgebungen gibt es genau einen Node Manager pro Rechner. Rechner werden in WLS als Machine repräsentiert und deshalb bearbeitet man in der Admin-Konsole automatisch einen Node Manager, sobald man eine Machine selektiert.
Das Konzept der Machine-Zugehörigkeit bewirkt, dassalle Konfigurationsinformationen (wie host, port, protocol, ...) bei dieser Machine abgelegt sind.
Dieses Konzept hat zur Folge, dass man standardmäßig jedem Rechner eines Netzwerkes bei der Definition einer Domain eine Machine zuordnet. In Virtualisierungsumgebungen kann es sich natürlich anders verhalten.
Node Manager sollten ständig laufen, daher empfiehlt es sich, diese als Dienst auf Windows oder Daemon auf Unix zu installieren, sodass sie beim Boot-Vorgang automatisch starten. Deshalb existieren im Gegensatz zu WLS-Servern auch keine expliziten Stop-Skripte.
Starten lässt sich der Node Manager auch per WebLogic Scripting Toolkit (WLST) mit dem Kommando startNodeManager(....).
In der Datei nodemanager.properties steht die Hauptkonfiguration. Die Datei wird automatisch beim ersten Start erzeugt, sofern sie nicht schon vorliegt. Ein sehr hilfreiches Prinzip, welches einem auch an anderen Stellen im WLS-Kontext begegnet, z.B. bei der Passwortdatei boot.properties.
Beim Starten von Managed-Servern verwendet Node Manager standardmäßig eigene Parameter, die sich in der Admin-Konsole einstellen lassen (siehe Abbildung 2).

Abb. 1: Übersicht von wichtigen Komponenten in einer WLS-Umgebung. Zwei Rechner (Machine A und B) sind dargestellt, auf denen Node Manager und weitere Server laufen

Abb. 2: Hier werden Startparameter für Managed-Server eingetragen, die der Node Manager verwendet

Node-Manager-Ausprägung: Shell-Skripte oder Java-Prozess

Die Beschaffenheit des Node Managers kommt in zwei Varianten daher, einmal als Shell-Skripte oder aber als eigenständiger Java-Prozess.Die Ansammlung von Shell-Skripten gilt als leichter handhabbar, kann allerdings häufig nicht die Einhaltung von allerstrengsten Sicherheitsrichtlinien gewährleisten. Im Fall des Remote-Zugriffs auf den Node Manager (die Admin- Konsole möchte z.B. remote einen Managed-Server starten) muss dieser Zugriff per SSH bewerkstelligt werden.

Zum anderen kann der Node Manager als echter Java-Prozess laufen, der seinen Dienst ressourcenschonend im Hintergrund versieht und im Fall von externer Kommunikation SSL (Secure-Socket-Layer)-Verbindungen nutzen sollte. Das ist unter sicherheitsrelevanten Aspekten betrachtet dringend anzuraten, lässt sich aber auch umgehen, indem man plain text als Protokoll verwendet. Hierbei darf man nicht vergessen, die Einstellung auf beiden Seiten der Kommunikation vorzunehmen, also sowohl im Administrationsserver als auch beim Node Manager.

Die Funktionsweise des Node Managers lässt sich gut anhand einer kleinen Sequenz von Linux-Kommandos veranschaulichen, mit dem user oracle auf dem Rechner wls01. Die Domain besteht aus einem Admin-Server und einem Managed Server (Managed01).

Der Node Manager läuft im Hintergrund und wenn man den Prozess des Managed-Servers per Kommando kill -9 hart abschießt, wird er unverzüglich neu gestartet (siehe Abbildung 3).

oracle@wls01]$ date; jps –lv|grep weblogic.Server
Mo 27. Feb 10:39:54 CET 2017
4162 weblogic.Server -Dweblogic.Name=Managed01
2693 weblogic.Server -Dweblogic.Name=AdminServer
[oracle@wls01]$ kill -9 4162
[oracle@wls01]$ date; jps –lv|grep weblogic.Server
Mo 27. Feb 10:39:56 CET 2017
4395 weblogic.Server -Dweblogic.Name=Managed01
2693 weblogic.Server -Dweblogic.Name=AdminServer

Abb. 3: Neustart des Managed-Servers

Node Manager, Admin-Konsole und WLST: eine Ménage-à-trois

Es umgibt den Node Manager eine gewisse Aura der Geheimnisse oder des unnahbaren, spröden Zugangs zu ihm. Das hat sehr wahrscheinlich seine Ursache darin, dass das Tool wenig bis gar keine Interaktionen mit menschlichen Anwendern benötigt. Der Node Manager ist lediglich initial von Administratoren korrekt einzurichten, agiert als Dienst im Hintergrund und fährt automatisch bei Systemstart hoch. Andererseits kann man ihm keine Beziehungslosigkeit vorwerfen. Im Gegenteil, der Node Manager unterhält eine Ménage-à-trois, eine heftige, vielfältige Dreiecksbeziehung, und zwar einmal mit WLST (WebLogic Scripting Toolkit) und zum anderen mit der Admin-Konsole. Mittels WLST kann der Node Manager z.B. gestartet werden, das Kommando nmStart() erlaubt dieses und stellt eine variantenreiche Auswahl an Parametereinstellungen bereit. Der Start kann entweder lokal (eigener Rechner) oder remote unter Angabe von Host und Port erfolgen.

Der Zugriff aus der Admin-Konsole heraus wurde schon thematisiert. Beim Start des Managed-Servers aus der Konsole heraus, hat der Node Manager seine Finger im Spiel (siehe Abbildung 4).

Abb. 4: Auszug der Admin-Konsole beim vergeblichen Versuch, einen Managed-Server zu starten. Das kann nicht funktionieren, denn der zugehörige Node Manager ist nicht verfügbar

Fazit

Dieser Artikel handelt vom Node Manager im WebLogic- Server mit seinen Aufgaben, seinem Einsatzgebiet und der Funktionsweise. Seine oft unterschätze Leistungsfähigkeit ist mit diesem Artikel im Ansatz sichtbar geworden. In einem weiteren Artikel zu diesem Tool wollen wir dann mehr in technische Details eintauchen, denn das WLST-Kommando nmEnroll(...) beispielsweise, bietet ganz hilfreiche Dienste, die anfangs überraschen und die man später nicht mehr missen möchte. Selbstverständlich bietet die ORDIX AG im Seminar „WebLogic-Server-Administration" auch eine Einführung in diese wichtige und spannende Thematik an. Wir helfen Ihnen sehr gerne bei weiteren Fragen.