OBTM: Mandantenfähigkeit konfigurieren

Da Dienste im Unternehmen hoffentlich Abteilungs- oder Bereichsübergreifend eingesetzt werden, macht es Sinn das Monitoring mandantenfähig aufzusetzen. Dieses wird in OBTM durch die sog. Consumers umgesetzt. Letztendlich werden Consumers durch speziell gekennzeichnete Properties unterschieden.

Um die Mandantenfähigkeit zu aktivieren, wird also zunächst für einen Service eine neue Property angelegt über 'Create|Message Property on sayHello'

Dann wieder 'Pick from Message...' auswählen...

... und in dem sich öffnenden Dialog wieder arg0 auswählen. Beenden mit OK.

Dann wird der Haken gesetzt bei 'Map to customer through attribute'. Damit wird OBTM mitgeteilt, dass es sich um eine spezielle Property handelt, welchen den Consumer beinhaltet. Beenden mit OK.

Auch diese Property wird mit der bereits bestehenden 'Name'-Property im Properties-Tab dargestellt. Durch das Personen-Symbol vor der Property wird gekennzeichnet, dass es sich hierbei um einen Property handelt die einen Consumer identifiziert.

Ebenso wird die Consumer-Property im Properties-Tab der Transaction angezeigt.

Damit die Consumer-Property für die Greeting-Transaktion auch greift, muss in den Einstellungen der Transaction (Modify|Edit Greeting) auf dem Tab 'Segmentation' noch der Haken bei 'Enable consumer segmentation' gesetzt werden.

Um die Consumer jetzt zu erfassen, starten wir wieder den WebLogic Test Client und rufen den HelloProxy-Service ein paar Mal jeweils mit 'Bereich-1' und 'Bereich-2' auf.

Die Segmentierung der Transaktion nach Consumer lässt sich dann auf dem Tab Analysis, sub-Tab Consumer Usage anzeigen. Die 'Unknown'-Einträge sind alte Einträge aus der Zeit bevor die Segmentierung eingeschaltet war.

Auch im Bereich Consumers werden nach kurzer Zeit die beiden Bereiche angezeigt (ggf. ca. 5min. warten). Dabei werden für die beiden Mandanten unterschiedliche Laufzeiten für die Services angezeigt, nämlich für jeden Mandanten die bei der Bearbeitung seiner spezifischen Anfragen angefallenen Werte.

Verursacht man absichtlich eine Störung, z.B. indem man den SOA-Server herunterfährt und startet während der Downtime nur Anfragen für einen Mandanten (z.B. Bereich-1), dann wird auch nur für diesen das Problem angezeigt. Im Bild oben sieht man, dass die Kurven für gestartete und erfolgreich abgeschlossene Transaktionen deutlich auseinander gehen. Startet man während der Downtime keine Transaktionen für den anderen Mandanten, wird diesem auch kein Problem angezeigt.

Somit lassen sich über das Consumers-Feature von OBTM auch mandantenspezifische Auswertungen durchführen.

---> Alerting

Glassfish Cluster Konfigurieren und Servlet deployen

Bislang lief das Beispiel-Servlet in einem ungeclusterten Glassfish Server. Jetzt soll das selbe Servlet im Cluster deployed werden. Hierzu muss zunächst ein Cluster über die Admin-Console (http://localhost:4848/common/index.jsf) konfiguriert werden.

Hierzu unter Clusters den 'New'-Button klicken

Im dem erscheinenden Dialog bekommt der Cluster einen Namen ("cluster1") und es können gleich zwei Instanzen (entsprechend den Managed Servern im WLS) angelegt werden. 'OK' beendet den Dialog.

Der Cluster muss vor der Benutzung  noch gestartet werden. Hierzu wird der Haken vor 'cluster1' gesetzt und via 'Start Cluster' der Cluster gestartet.

Per Klick links im Baum auf 'Clusters', dann rechts auf den Tab 'Instances' werden die beiden gerade konfigurierten Instanzen im Status 'Running' angezeigt.

Zurück in NetBeans wird zur Sicherheit ein kompletter Build des Projekts durchgeführt (Shift+F11).

Das Deployment auf den Cluster per GUI wird von NetBeans nicht unterstützt. Daher erfolgt das Deployment aus der Admin Console. Links im Baum auf 'cluster1', dann rechts auf den Tab 'Applications' und den Button 'Deploy' klicken.

Über den Browse-Button wird die .war-Datei ausgewählt, z.B. D:\Project\NetBeansProjects\SimpleCluster\dist\SimpleCluster.war. Der Type wird gesetzt auf 'Web Application'. Deployed wird mit 'OK'.

Die Anwendung 'SimpleCluster' wird jetzt unter 'Applications' angezeigt. Per Klick auf den Anwendungsnamen geht es in die Details.

Hier werden weitere Details zu der Web-Application angezeigt. über den 'Launch'-Link lässt sich die Anwendung ausführen.

In einem neuen Browser-Fenster werden die verschiedenen Links zur Anwendung angezeigt. Per Klick auf einen davon gelangt man auf die jeweilige Seite.

Es wird zunächst die Default-Seite index.jsp angezeigt. Um auf das Servlet zu kommen, wird an die URL der Name des Servlets angehängt, in diesem Fall ist die komplette URL also http://localhost:28080/SimpleCluster/Simple.

Über mehrmaliges Neuladen werden die bisherigen Aufrufe hochgezählt.

In einem zweiten Browser kann die gleiche URL auf dem Port der jeweils anderen Instanz geöffnet werden. Somit lassen sich beide Zähler unabhängig voneinander hochzählen.

Damit ist der Glassfish-Cluster aufgesetzt und die Anwendung in beide Instanzen deployed.

Das Loadbalancing über den Apache funktioniert grundsätzlich analog zum Loadbalancing des WebLogic Server. Allerdings ist das mod_loadbalancer.so des Glassfish Servers zwar bereits für den Oracle HTTP Server zertifiziert, es gibt aber noch keine automatisierte Installationsroutine.
Die manuelle Installation ist beschrieben unter http://docs.oracle.com/cd/E18930_01/html/821-2426/gktke.html#scrolltoc, aber nicht Bestandteil dieses Tutorials.

WebLogic und OHS: Loadbalancing konfigurieren

Das Loadbalancing für den WebLogic Server wird im Oracle HTTP Server über das Modul mod_wl_ohs durchgeführt. Dieses wird über die Konfigurationsdatei mod_wl_ohs.conf im jeweiligen Instanzverzeichnis konfiguriert. In diesem Beispiel ist es die d:\Oracle\Middleware.11116\Oracle_WT11116\instances\instance1\config\OHS\ohs11116\mod_wl_ohs.conf

 Nach der Installation befindet sich dort bereits eine leere mod_wl_ohs.conf, in der die benötigten Einträge ergänzt werden können. Im Bereich für das weblogic_module (zwischen <IfModule ...> und </IfModule>) werden hierzu zwei Zeilen ergänzt, so daß der gesamte Bereich wie folgt aussieht:

<IfModule weblogic_module>
#      WebLogicHost <WEBLOGIC_HOST>
#      WebLogicPort <WEBLOGIC_PORT>
#      Debug ON
#      WLLogFile /tmp/weblogic.log
#      MatchExpression *.jsp
    WebLogicCluster    localhost:7003,localhost:7004
    MatchExpression /*
</IfModule>

Dier erste Zeile mit 'WebLogicCluster' gibt an, auf welche Adressen und Ports weitergeleitet werden soll. In diesem Fall die beiden Managed Server auf dem lokalen Rechner auf den Ports 7003 und 7004.
Die zweite Zeile 'MatchExpression' gibt an, welche Anfragen weitergeleitet werden sollen. In diesem einfachen Beispiel wird einfach alle ('/*') weitergeleitet.

Jetzt muss der OHS einmal neu gestartet werden, damit die geänderte Konfiguration eingelesen wird.

Der Neustart erfolgt über opmnctl stopall und anschliessendem opmnctl startall.

Jetzt kann das Loadbalancing mit dem in der vorherigen Übung installierten Servlet getestet werden. Hierzu wird das Servlet nicht mehr über die Ports des jeweiligen Managed Server, sondern über den Port (7777), also

http://localhost:7777/clusterapp/cluster

Das Ergebnis sieht dann auch erst einmal - wenig verwunderlich - genau so aus wie beim Aufruf der ungeclusterten Variante.

In einem der beiden Kommandozeilen-Fenster der Managed Server sind dann auch die Aufrufe zu sehen. Dies ist die Instanz, welche die aktuelle Session bedient. Um einen Ausfall zu simulieren, wird das Fenster einfach einmal geschlossen.

Drückt man jetzt den Reload-Button im Browser, fällt auf dass es dieses Mal einen kleinen Moment dauert, bis der Server antwortet. Hier findet jetzt der Failover statt. Nach einer kurzen Schrecksekunde kommt dann aber die Antwort und der Zähler liefert den nächsten Wert.

Im Kommandozeilen-Fenster der verbleibenden Instanz kann man dann auch sehen, wie die neuen Aufrufe bedient werden. Auch wird eine kurze Warnung ausgegeben, daß ein Failover erfolgte.

Damit ist das Clustering-Beispiel für den Weblogic Server abgeschlossen.

Weblogic Cluster: OHS 11.1.1.6 installieren

Um ein Loadbalancing zwischen den beiden Managed Servern im Weblogic Cluster aufzusetzen kann der Oracle HTTP Server (OHS), eine von Oracle supportete Version des Apache, genutzt werden. Dieser ist standardmässig nicht im Lieferumfang des WebLogic Servers enthalten und muss nachinstalliert werden. Gestartet wird der Installer über setup.exe bzw. setup.sh von Disk1 des Installationspacketes.

Weiter ...

Für die Entwicklungsumgebung können die Softwareupdates übersprungen werden.

Installieren und konfigurieren

Systemvoraussetzungen überprüfen

Als Installationsverzeichnis das bestehende WLS 11.1.1.6 Home auswählen

 Die Sicherheitsupdates können abgeschaltet werden

Der Web Cache wird für dieses Beispiel nicht benötigt

Der Management Server der Domain wird hier konfiguriert

Die Instanz bekommt hier einen eindeutigen Namen

Automatische Port-Konfiguration ist OK.

Zusammenfassung und 'Installieren' klicken.

Weiter ...

und Fertig stellen.

Das Ergebnis kann mit dem opmn überprüft werden. Hierzu muss das opmnctl aus der gerade angelegten Instanz benutzt werden. Also in diesem Fall d:\Oracle\Middleware.11116\Oracle_WT11116\instances\instance1\bin\opmnctl status

Damit läuft der Oracle HTTP Server. Im nächsten Schritt muss nur noch das Loadbalancing konfiguriert werden.

Servlet aus JDeveloper in Weblogic Cluster deployen

In den vorigen HowTo's wurde das Servlet erstellt und der Cluster aufgesetzt. Zum Deployment wird das Projekt mit dem Servlet wieder im JDeveloper geöffnet.
Die Konfiguration der Session Replication erfolgt im proprietären Deployment Descriptor des jeweiligen Application Servers. Für den Weblogic Server erfolgt dies in der weblogic.xml.

Diese wird erstellt per Rechtsklick auf das Projekt und Auswahl von 'New...'

Auswahl von General|Deployment Descriptors|WebLogic Deployment Descriptor ...

weblogic.xml auswählen ...

die neuste angebotene Version nehmen ...

der dritte Schritt wird automatisch übersprungen, in der Zusammenfassung 'Finish' auswählen. Die neue weblogic.xml öffnet sich automatisch.

Im Editor für die weblogic.xml unter 'Session' den Abschnitt 'Persisten Store' öffnen und als 'Store Type' REPLICATED_IF_CLUSTERED auswählen um die Session Replication zu aktivieren.

Das Ergebnis kann überprüft werden, wenn man unten im Editor für die weblogic.xml per Tab-Reiter von 'Overview' auf 'Source' umstellt. Die weblogic.xml kann danach gespeichert und geschlossen werden.

Das Servlet ist damit fertig konfiguriert, im nächsten Schritt wird das eigentliche Deployment durchgeführt.

Hierzu wieder per Rechtsklick auf das Projekt das Popup-Menü öffnen und dieses Mal 'Deploy' auswählen. Weil noch kein Deployment Profile vorhanden ist, kann dort nur die Option 'New Deployment Profile...' ausgewählt werden.

Als 'Profile Type' wird hier 'WAR File' gewählt und ein Name kann vergeben werden, z.B. clusterapp und mit OK schliessen.

Hier sollte die Context Root auf etwas handlicheres gesetzt werden, wie hier z.B. clusterapp. Dann mit OK beenden.

Bei erneuter Auswahl von 'Deploy' lässt sich jetzt das soeben eingerichtete Profil auswählen.

Die Anwendung soll auf einen Application Server deployed werden.

Allerdings sollte noch keiner eingerichtet sein. Diesen bekommt man per Klick auf das grüne Plus-Zeichen (Add an Application Server)

Die Verbindung bekommt einen Namen (hier: WLcluster) und als Connection Type wird die höchste angebotene WebLogic Version ausgewählt (bei JDeveloper 11.1.2.1.0 ist es WebLogic 10.3).

Benutzername und Password werden benötigt.

Hier muss vor allem die Domain geändert werden, der Rest kann bei einer Standardinstallation so bleiben.

Sicherheitshalber sollte die Verbindung getestet werden.

Und 'Finish'.

Danach wird der Server als mögliches Ziel angeboten und kann hier ausgewählt werden.

Der JDeveloper erkennt den Cluster. Bei der Auswahl der Ziele sollte auf 'Deploy to selected instances in the Domain' umgestellt werden und in der Auswahlbox nur der Cluster gewählt werden.

Zusammenfassung und 'Finish'

Wenn unten im Log 'Deployment finished' erscheint, hat alles geklappt (ggf. auf den Deployment-Tab umschalten).

Zum testen kann man mit zwei verschiedenen Browsern die URL auf den beiden Ports für die beiden Managed Server im Cluster aufrufen, z.B. http://localhost:7004/clusterapp/cluster.

In beiden Browser-Fenstern kann man jetzt in jeweils eigenen Sessions die Zähler erhöhen.

In den beiden Fenstern der Managed Server lassen sich die Aufrufe nachverfolgen.

Damit ist die Anwendung im Cluster verteilt, im nächsten Schritt geht es darum, hierfür den Loadbalancer aufzusetzen.