WebLogic-Grundlagen: die feinen Unterschiede

Der Oracle WebLogic Server ist ein skalierbarer Java-Application-Server, der für den unternehmensweiten Einsatz optimiert ist. Seit Verfügbarkeit der Version 12c wird die Java-EE-6.0-Spezifikation voll unterstützt („Full Profile“). Dadurch ist sichergestellt, dass die erforderlichen Standard-APIs zur Entwicklung verteilter Anwendungen zur Verfügung stehen, mit denen Datenbanken und Nachrichtendienste eingebunden und die Interoperabilität mit externen Systemen, Endbenutzer-Clients, Java oder Webbrowser adressiert werden können. Ergänzend dazu spielt auch die In-Memory-Grid-Lösung „Oracle Coherence“ eine immer wichtigere Rolle. Diese ermöglicht es, Zustand und Anwendungsdaten möglichst ausfallsicher und besonders skalierbar bereitzustellen.

Architektur

Bevor wir auf die Installation und Konfiguration eingehen, ist ein gemeinsames Verständnis der Grundbegriffe im WebLogic-Server-Umfeld wichtig (siehe Abbildung 1). Eine „Domain“ bildet eine logische Administrationseinheit und beinhaltet WebLogic-Server-Instanzen und deren jeweilige Ressourcen. Die einzelnen WebLogic-Server-Instanzen werden als „Managed Server“ bezeichnet. Auf genau einem Server je Domain wird die „Administration Console“-Anwendung bereitgestellt. Über diesen Server – „Admin Server“ genannt – kann die Domain konfiguriert und administriert werden.

WebLogic Server – Grundbegriffe der Architektur
Abbildung 1: WebLogic Server – Grundbegriffe der Architektur

Die kleinste Domain besteht aus einem Admin Server, der zugleich auch als Managed Server für die eigenen Anwendungen verwendet wird. Dies ist häufig in Entwicklungsumgebungen der Fall. In der Regel werden die Anwendungen auf dedizierten Managed Servern bereitgestellt. Diese können auf mehrere physische oder virtuelle Rechner verteilt werden. Soll eine Anwendung besonders skalierbar oder ausfallsicher sein, so können mehrere Managed Server mit identischen Anwendungen, Ressourcen und Diensten als „Cluster“ verbunden werden.

Die Zuordnung der Managed Server zu den jeweiligen Rechnern erfolgt über die Machine-Konfiguration. Diese Information wird zum einen durch den „Node Manager“, um bei Bedarf automatisch einen ausgefallenen Managed Server neu zu starten, und zum anderen im Cluster verwendet, um den besten Ort zur Speicherung der replizierten Session-Daten zu ermitteln. Auch Coherence-Knoten können mit dem Node Manager überwacht werden.

Viele Kunden verwenden einen Cluster oder eine Domain pro Anwendung, um so Versionsabhängigkeiten zwischen Laufzeitumgebung und Anwendungen möglichst gering zu halten. Die Architektur des WebLogic Servers ist sehr flexibel. Es lassen sich dadurch auch mehrere Anwendungen auf einem Server, einer Domain oder einem Cluster betreiben.

Der WebLogic Server verarbeitet die Anfragen über einen „Thread Pool“. Mithilfe des Work Manager werden die Anfragen optimal zur Abarbeitung organisiert. Die Priorisierung erfolgt auf Basis der definierten Regeln auf Domain- oder Anwendungs-Ebene sowie der Laufzeit-Metriken inklusive der aktuell benötigten Zeit zur Abarbeitung einer Anfrage. Der Work Manager spielt auch eine wichtige Rolle bei der Erkennung und Behandlung überlasteter WebLogic-Server-Knoten.

In WebLogic 12.1.2 ist das Konzept „Dynamic Server“ und „Dynamic Cluster“ neu eingeführt. Die Konfiguration eines dynamischen Servers wird in einem „Server Template“ hinterlegt. Ein Dynamic Cluster besteht aus einem oder mehreren Dynamic Servern, die alle auf der gleichen Konfiguration basieren. Werden zusätzliche Ressourcen benötigt, können auf Basis des Server Templates ohne manuelle Konfigurationsschritte zusätzliche Dynamic Server erzeugt und gestartet werden. Im Rahmen der Dynamic-Cluster-Konfiguration wird die maximale Größe des Clusters festgelegt, die er bei einer angenommenen Spitzenlast erreichen kann. Die Definition von „Server Name“, „Machine Name“ und „Listen Ports“ wird anhand vordefinierter Regeln und zuvor im Template hinterlegter Parameter für neue Dynamic Server im Dynamic Cluster automatisch generiert. Jetzt kann der Administrator bei Bedarf einen Dynamic Server mit dem abgeleiteten Namen starten.

Das Deployment der Anwendungen verhält sich wie generell bei einem Cluster. Wurde eine Anwendung oder Ressource auf dem gesamten Cluster bereitgestellt, so steht sie auch auf den neu gestarteten Dynamic Servern zur Verfügung. Im Dynamic Cluster gibt es keine „Whole Server Migration“ und „Service Migration“. Anwendungen und Ressourcen müssen auf dem gesamten Cluster bereitgestellt werden und damit auch auf allen Dynamic Servern. Ein Dynamic Cluster gibt damit die Möglichkeit, schnell und einfach die Anzahl der WebLogic-Server-Instanzen zu erhöhen beziehungsweise wieder zu verringern.

Installation

Die WebLogic-Server-Installation kann wahlweise zentral oder dezentral organisiert werden. Die zentrale Installation könnte beispielsweise auf einem „Shared Storage“ liegen, wobei die Konfiguration auf den jeweiligen Servern hinterlegt ist, auf denen WebLogic-Server-Instanzen (JVMs) laufen sollen (siehe Abbildung 2).

WebLogic-Server-Installation und Domain
Abbildung 2: WebLogic-Server-Installation und Domain, Quelle: „Understanding WebLogic Server (12.1.2)

Bei der Installation des WebLogic Servers wurden schon immer Software (Binaries) und Konfiguration voneinander getrennt. Dies ist insbesondere dann ein großer Vorteil, wenn es darum geht, eine hochverfügbare Umgebung aufzusetzen. Die Software wird als „.jar“-Datei ausgeliefert. Die verschiedenen Varianten (siehe Tabelle 1) beziehen sich auf die verfügbaren Software-Downloads. Die Lizenzbedingungen sind gesondert zu betrachten und der „Licensing Information“ der jeweiligen WebLogic-Server-Dokumentation zu entnehmen.

WebLogic Server Distribution

Inhalt

Einsatz

wls_121200.jar

WebLogic Server, Coherence, Beispiele

Produktion, Entwicklung, Test

fmw_infra_121200.jar

Java Required Files
(inkl. Application Development Framework)

Enterprise Manager

Produktion, Entwicklung, Test

wls_1212_dev.zip

Ohne Coherence und pre-built client jars,
mit Maven-Plug-in und Sync-Plug-in

Entwicklung, Evaluierung

wls1212_dev_supplemental.zip

Beispiele, Derby-Datenbank und
WebLogic Console Help
(„non-english“) für „.zip“-Installation

Entwicklung, Evaluierung

Tabelle 1: WebLogic-Server-Distributionen

Für Evaluierungszwecke steht die Software auf dem Oracle Technologie Network zur Verfügung. Die Code-Beispiele in diesem Artikel wurden unter dem Betriebssystem Oracle Enterprise Linux und auf Basis der WebLogic-Server-Distribution „wls_121200.jar“ durchgeführt. Vor Installation des WebLogic Servers muss zunächst das passende JDK installiert sein. Für die Version 12.1.2 ist Oracle JDK 1.7 erforderlich. Weitere Informationen zur Zertifizierung sind der Fusion-Middleware-Zertifizierungsmatrix zu entnehmen.

Als Nächstes wird die Umgebungsvariable „JAVA_HOME“ gesetzt und mit in den Pfad der „PATH“-Variablen aufgenommen. Die anschließende Installation erfolgt ab der Version 12.1.2 mit dem Oracle Universal Installer. Hiervon ausgenommen ist die Installation der „.zip“-Distribution, die nach Setzen der notwendigen Umgebungsvariablen einfach entpackt wird. Die Installation über den Oracle Universal Installer (OUI) wird mit „java –jar wls_121200.jar“ gestartet.

Im Zusammenspiel mit anderen Oracle-Produkten und für produktive Umgebungen ist die Installation über den OUI unbedingt erforderlich. Bei Bedarf kann auch nur die mit dem OUI integrierte Distribution des WebLogic Servers gepatcht werden.

Es gibt drei verschiedene Installationstypen: „WebLogic Server“, „Coherence Server“ oder „Complete“. Bei „WebLogic Server“ werden sowohl die Komponenten für den WebLogic Server als auch für Coherence installiert. Diese Variante ist für den Aufbau einer Produktionsumgebung empfohlen. „Coherence“ erzeugt keine WebLogic Client jars. Die WebLogic-Server- und Coherence-Beispiele sind nur in der Variante „Complete“ enthalten. Abbildung 3 zeigt die Verzeichnisstruktur nach Installation der Software „wls_121200.jar“ mit dem Oracle Universal Installer.

Abbildung 3: WebLogic-Server-Verzeichnisstruktur, Quelle: Anhang B-1 „Installing and Configuring Oracle WebLogic Server and Coherence 12c (12.1.2)“

Das Unterverzeichnis „wlserver“ beinhaltet die Produktdateien des WebLogic Servers und ist auch mit seinem Pfad als „WL_HOME“ referenziert. Analog dazu sind unter „coherence“ die Coherence-Produktdateien installiert. Im Verzeichnis „oracle_common“ stehen die für den WebLogic Server übergreifenden Binaries und Bibliotheken. Im Falle einer Installation der Fusion-Middleware-Infrastruktur auf Basis von „fmw_infra_121200.jar“ sind dort auch die „java required files“ (jrf) zu finden.

Bei der Installation mit dem Oracle Universal Installer wird im Benutzerverzeichnis das „oraInventory“ angelegt beziehungsweise aktualisiert. Daher ist es auch wichtig, bei einer Deinstallation das entsprechende „./deinstall.sh“-Skript zu verwenden. Alternativ gibt es auch die Möglichkeit, die Installation im Hintergrund „silent“ auszuführen.

Wurde der Installationstyp „Complete” ausgewählt, können im Anschluss zur Installation die drei Beispiel-Domains über den „Quick Configuration Wizard“ erzeugt werden. Die Einstellungen für den Administrator, den Pfad für Domain und Anwendungen, die Listen-Adresse sowie die Ports für die Beispiel-Domains sind im „Quick Configuration Wizard“ definiert.

Konfiguration

Zur Erstellung einer Domain gibt es mit „Domain Configuration Wizard“ und „WebLogic Scripting Tool“ (WLST) zwei verschiedene Wege. „Domain Configuration Wizard“, ein grafisches Werkzeug, führt Schritt für Schritt durch die Domain-Konfiguration. Hierbei können je nach Auswahl die Einstellungen für Admin Server, Node Manager, Managed Server, Cluster und Coherence konfiguriert beziehungsweise angepasst werden. Mit Oracle WebLogic Server 12.1.2 wurden der Node Manager und die Managed Coherence Server mit in den Wizard integriert. „cd $ORACLE_HOME/oracle_common/common/bin“ und „./config.sh” starten den Domain Configuration Wizard.

Der bisherige Pfad für das „/common/bin“-Verzeichnis von WebLogic Server unter „$WL_HOME“ existiert weiterhin, wobei die dortigen Skripte auf diejenigen unter „$ORACLE_HOME/oracle_common/common/bin“ referenzieren. Als erste Domain führen wir beispielhaft folgende Konfiguration durch (siehe Tabelle 2).

Konfigurationsschritt

Beispiel Domain test1

  1. Administration Server

Server Name: AdminServer

Listen Address: All local Addresses

Listen Port: 7001

  1. Node Manager

Per Domain

Node Manager Credentials:

<nm_admin_user>

<nm_admin_password>

  1. Managed Server

Server Name: ms1 – port: 7003

Server Name: ms2 – port: 7004

Listen Address: All local Addresses

  1. Machines (Unix Machine)

Machine Name: Machine1

Listen Address: All local Addresses

Listen Port: 5556

  1. Assign Servers to Machines

Machine1: AdminServer, ms1, ms2

Tabelle 2: Beispiel Domain „test1“

Auf der linken Seite ist im „Domain Configuration Wizard“ der Ablauf der einzelnen Schritte dargestellt. Im ersten Schritt wird definiert, wo die Domain-Konfiguration hinterlegt werden soll. Für Produktionsumgebungen empfehlen wir dafür einen von der Installation getrennten Pfad.

Die Domain Location „/home/oracle/wls/user_projects/domains/test1” ist für die Domain „test1” das sogenannte „DOMAIN_HOME”. Für unsere Domain benötigen wir im zweiten Schritt lediglich das Basis Template namens „Basic WebLogic Server Domain -12.1.2.0 [wlserver*]”. Alternativ könnte man hier ein zusätzliches Oracle-spezifisches oder ein eigenes Domain-Template auswählen, das als Basis für die Konfiguration der neuen Domain verwendet werden soll.

Nach Definition des Administrations-Benutzers und -Passworts im dritten Schritt werden in Schritt vier der Betriebsmodus „development“ oder „production“ und das zu verwendende Java Development Kit (jdk) festgelegt. In Schritt fünf folgt die Wahl der Domain-Komponenten, die angepasst beziehungsweise neu konfiguriert werden sollen.

Mit WebLogic 12.1.2 wurde die Konfiguration von Coherence-Knoten als „storage enabled“-Managed-Coherence-Server in den Domain Configuration Wizard integriert. Die restlichen Schritte wurden entsprechend Tabelle 2 durchgeführt und abschließend das Erzeugen der Domain-Konfiguration „test1“ angestoßen. Die Node-Manager-Konfiguration ist Default-mäßig unter der Domain-Konfiguration „$DOMAIN_HOME/nodemanager“ hinterlegt.

Die Alternative zur Definition einer Domain ist die Konfiguration per „WebLogic Scripting Tool“ (WLST). Dahinter steht eine Jython-basierte Skript-Umgebung. WLST kann interaktiv als Kommandozeilen-Werkzeug oder als Ablauf-Umgebung für vorgefertigte Skripte verwendet werden, die ohne Administrator-Eingaben im Hintergrund laufen. Oft wird WLST extensiv zur Automatisierung von Administrationsaufgaben im WebLogic-Server-Umfeld eingesetzt. Der Start erfolgt über „cd $ORACLE_HOME/oracle_common/common/bin” und ./wlst.sh“.

Nach Starten des WLST befindet man sich im „offline“-Modus, was dem „Domain Configuration Wizard“ entspricht. Für die Ausführung bestimmter Aktionen, die Bezug auf die Domain haben, sollte die Umgebung richtig gesetzt werden, etwa durch „cd $DOMAIN_HOME/bin” und „. ./setDomainEnv.sh”.

Beispielskripte dafür, wie mit WLST eine Domain erstellt wird, sind unter „$WL_HOME/common/templates/scripts/wlst“ zu finden. Erstreckt sich eine Domain über mehrere Knoten (siehe Abbildung 1), so kann die Domain-Konfiguration mit den Befehlen „pack“ und „unpack“ auf die verschiedenen Knoten kopiert werden. Der Aufruf erfolgt aus dem Verzeichnis „$ORACLE_HOME\oracle_common\common\bin“ mit „./pack.sh“ beziehungsweise „./unpack.sh“.

Basierend auf einer gesicherten Domain-Konfiguration in Form eines Templates können neue Domains erstellt oder bestehende Domains erweitert werden. Sowohl Domain als auch Extention Templates sind über den Domain Template Builder, WLST oder den „pack“-Befehl möglich.

Administration

Das Thema „Administration“ ist vielfältig. Der Artikel geht zum einen auf die verschiedenen Werkzeuge ein, die zur Administration verwendet werden können, und zum anderen auf das Starten der Server mit dem Node Manager und WLST. Für die Administration einer Domain steht die „Administration Console“ zur Verfügung. Dies ist ein Web-Front-end mit Blick auf die aktuelle Domain-Konfiguration, das verfügbar ist, sobald der Admin Server gestartet ist.

Mit WLST kann man sich ebenfalls an einen Admin Server verbinden. In diesem Fall spricht man vom „WLST-‚Online‘-Modus“, dem die Admin Console entspricht. Wenn in der Admin Console die Aufnahmefunktion aktiviert ist, ist hinterher genau nachvollziehbar, welche WLST-Befehle ausgeführt worden sind. Beide Werkzeuge lesen die WebLogic Server MBeans, die die Domain-Konfiguration beinhalten, aus beziehungsweise aktualisieren diese. Ein Abbild der Konfiguration wird zusätzlich in der Datei „config.xml“ gehalten. Änderungen an der Konfiguration sollten immer über ein Interface und nie direkt in „config.xml“ erfolgen, um die Konsistenz sicherzustellen. Auch im „Offline“-Modus ist es möglich, sich per WLST an eine Domain zu verbinden, um die Konfiguration zu lesen oder zu verändern. Zu bestimmten Zeitpunkten, wie beim Stoppen eines Servers, wird die Konfiguration in die Datei „config.xml“ zurückgeschrieben.

Ist der WebLogic Server zusammen mit der Fusion-Middleware-Infrastruktur installiert, steht auch die Basis-Komponente des Enterprise Manager „Fusion Middleware Control“ zur Verfügung. Dabei handelt es sich ebenfalls um eine Web-basierte Administrations-Konsole, die im Gegensatz zur WebLogic Server Admin Console auch die Überwachung und das Management von Oracle-http-Server, SOA Suite, WebCenter und Identity Management umfasst.

Eine weitere Aufgabe der Administration ist das Starten und Stoppen der Server in der Umgebung. Hier gibt es mehrere Möglichkeiten. Wie der Admin Server und die Managed Server per WLST über den Node Manager gestartet werden, kann unten entnommen werden. Dies könnte auch Inhalt einer Skript-basierten Lösung sein.

Den WebLogic Server starten

cd $DOMAIN_HOME/bin
. ./setDomainEnv.sh

WebLogic Scripting Tool starten

java weblogic.WLST

Node Manager starten

startNodeManager(verbose=’true’,Node
ManagerHome=’/home/oracle/wls1212/
user_projects/domains/test1/nodemanager’,
ListenPort=’5556’)

Mit Node-Manager verbinden

nmConnect(‘<nm_admin_user>’,’<nm_admin_password>’,
’localhost’,’5556’,’te
st1’,’/home/oracle/wls1212/
user_projects/
domains/test1’,’ssl’,’true’)

Admin Server über Node Manager das erste Mal starten

prps=makePropertiesObject(‚Username
=weblogic;Password=welcome1‘)
nmStart(‚AdminServer‘,props=prps)

Admin Server ab dem zweiten Mal starten

nmStart(’AdminServer‘)

WLST mit Admin Server verbinden

connect(’weblogic‘,‘welcome1‘,‘localho
st:7001‘)

Benutzername und Passwort verschlüsselt mitgeben, siehe WLST-Befehl „storeUser- Config()“

prps = makePropertiesObject(“AdminURL
=http://wlsdev.de.oracle.com:7001
;Username=weblogic;Password=welco
me1“)

Managed Server das erste Mal starten

nmStart(‘ms1’,props=prps)
nmStart(‘ms2’,props=prps)

Managed Server ab dem zweiten Mal starten

nmStart(‘ms1’)
nmStart(‘ms2’)

Alle Server, die über den Node Manager gestartet wurden, werden auch von diesem überwacht und werden im Falle eines ungeplanten Ausfalls automatisch wieder gestartet. Ein geplantes Herunterfahren muss dann auch immer per WLST via Node Manager mit „nmKill(‚ServerName‘)“ oder über die Admin Console erfolgen.

In der Regel ist ein WebLogic Server für alle unterstützten Protokolle über einen Port erreichbar. Für administrative Aufgaben gibt es die Möglichkeit, einen eigenen Port zu konfigurieren, für den implizit ein eigener „Administration Channel“ mit „Protokoll:Listenadresse:Port“ generiert wird. Dies ermöglicht das Starten von Servern im Standby-Modus und die Durchführung administrativer Aufgaben, ohne dass die Anwendungen verfügbar sind. Dadurch wird unter anderem der Netzwerk-Verkehr auf dem produktiven Port minimiert. Zusätzlich können „Network Channel“, bestehend aus „Protokoll:Listenadresse:Port“, für verschiedene Protokolle jeweils mit dediziertem Port definiert werden, die physisch bestimmten Netzwerkkarten zugeordnet sind.

Die Admin Console ermöglicht den Blick auf eine Domain. Im Gegensatz dazu bietet Oracle Enterprise Manager Cloud Control 12c mit dem WebLogic-Management-Pack die Möglichkeit, mehrere Domänen zu überwachen und zu administrieren. Ein Kernbereich des Enterprise Manager ist die Möglichkeit der Diagnose, um möglichst frühzeitig Probleme zu erkennen und beheben zu können. Dazu gehören sowohl der tiefe Blick in die JVM bis hin auf die Datenbank als auch die Nachverfolgbarkeit von Transaktionen über mehrere Schichten hinweg. In vielen Bereichen lassen sich die Informationen in Echtzeit und aus der Historie betrachten. Der Automatisierungsgrad für wiederkehrende Aufgaben kann erheblich erhöht werden.

Insgesamt sichert der Einsatz des WebLogic-Management-Packs eine höhere Service-Qualität und ein Minimum an geplanten und ungeplanten Ausfallzeiten. Der Betrieb wird im gesamten Lebenszyklus einer Applikation unterstützt und der Administrator behält zu jeder Zeit den Überblick über die gesamten WebLogic-Server-Umgebungen, auch wenn diese komplexer sind.

10.09.2013 Java, Middleware
Von: Sylvie Lübeck