Applikationsüberwachung mit 11gR2 Grid Infrastruktur - Am Beispiel der DBConsole
von Sebastian Solbach, ORACLE Deutschland GmbH

Eine Real Application Cluster Datenbank mit der Oracle eigenen Clusterware aufzubauen, ist nur ein kleiner, wenn auch sehr bedeutender Bestandteil der 11gR2 Grid Infrastruktur. Da es sich aber bei der in der Grid Infrastruktur enthaltenen Clusterware um eine vollwertige Clusterware handelt, können auch andere Applikationen und Prozesse damit überwacht werden. Leider bietet Oracle im Gegensatz zu seiner Solaris Clusterware nur wenig vorgefertigte Agenten und Skripte hierzu an, da die Clusterware vornehmlich für den RAC zur Verfügung steht. Die bestehenden Agenten und Whitepaper finden sich auf der Oracle Clusterware Seite. Hierzu gehört SAP, RAC One Node, Golden Gate, Oracle VM Manager und bei älteren Clusterware Releases auch ein Whitepaper zum Cold Failover einer Oracle Datenbank.

Mit 11gR2 Clusterware wurden aber eben diese Funktionalität erheblich erweitert: So gibt es nicht nur die graphische Verwaltung im Database Control und im Enterprise Manager Grid Control der Clusterware Ressourcen (Applikation und Prozesse, die überwacht werden), sondern auch verbesserte Skripte und mehr Möglichkeiten Abhängigkeiten zwischen den einzelnen Ressourcen zu definieren.

Bei vielen Installation der Grid Infrastruktur finden sich selbstverständlich auch Oracle Datenbanken, sei es nun als einzelne Instanz oder als Real Application Cluster. Damit einher geht häufig auch die Installation des Database Controls oder des Enterprise Management Agents. Diese Prozesse sind jedoch nicht, wie die Oracle Datenbankprozesse, automatisch in die Überwachung der Clusterware eingebunden.

Eine gute Gelegenheit, die neuen Funktionalitäten der Oracle Clusterware an dem Beispiel der Einbindung der Datenbank Console zu zeigen. Da die Datenbank Console aus 2 Prozessen besteht:

  • Dem Agenten, der auf jedem Server innerhalb des Clusters laufen sollte
  • Der Java Oberfläche, die genau auf einem Server im Cluster läuft
kann der erste Teil dieses Konzept auch leicht auf den Enterprise Management Agent übertragen werden.

Der Tipp gliedert sich in 2 Teile:
  • Einem allgemeinen Teil zur Überwachung aller dbconsole Prozesse
  • Einem fortgeschrittenen Teil mit Einschränkunen zur Rekonfiguration der Java Oberfläche

Anmerkung: Bilder zum Tipp werden sichtbar, indem man mit der Maus über das Brillen Icon fährt.


Um das Bild wieder zu verkleinern, auf das Bild klicken.

Überwachung des Database Control Agenten

Bevor Applikationen bzw. Prozesse von der Clusterware überwacht werden können, braucht es ein sogenanntes "Aktions-Skript" oder einen Agenten. Der Unterschied zwischen einem Aktions-Skript und einem Agenten ist neben der Programmiersprache (Skripte sind Perl oder ganz einfach Shell Skripte, Agenten meistens C-Programme) auch die Art, wie die Oracle Clusterware mit diesen kommuniziert. Wird der Agent direkt angesprochen, so funktioniert dies bei Skripten immer über den Umweg des Skript Agenten. Ein Agent kann auch direkt Informationen an die Clusterware schicken (ohne extra aufgerufen worden zu sein), während die Skripte immer erst auf "Anfrage" der Clusterware tätig werden.

Neu mit 11gR2 ist, dass ein Skript neben den bisherigen START, STOP und CHECK auch eine CLEAN Funktion besitzt. Einige Beispiele zu Agenten und aktuellen Failover Skripten finden sich unter $GRID_HOME/crs/demo.

Das dbcagent Skript

Das folgende Skript steuert die DBConsole auf allen Knoten:

#!/bin/bash
#              
# dbcagent.sh - script to start and stop the dbconsole 11gR2 agent
#
# description: Oracle 11gR2 database console agent

ORACLE_BASE=/opt/oracle
ORACLE_HOME=$ORACLE_BASE/product/11.2.0/db
LD_LIBRARY_PATH=$ORACLE_HOME/lib
ORACLE_SID=buvmrac
ORACLE_UNQNAME=$ORACLE_SID
PATH=$ORACLE_HOME/bin:$PATH

export ORACLE_BASE
export ORACLE_HOME
export LD_LIBRARY_PATH
export ORACLE_SID
export ORACLE_UNQNAME
export PATH

agent_start () {
  $ORACLE_HOME/bin/emctl start dbconsole 
}

agent_stop () {
  $ORACLE_HOME/bin/emctl stop dbconsole 
}

agent_check () {
  $ORACLE_HOME/bin/emctl status agent 
}

agent_clean () {
  until [ -z "$1" ]
  do
    process=$(ps -e -v --cols 10000 "$1" |grep "ORACLE_UNQNAME=$ORACLE_UNQNAME") 
    if [ -n "$process" ]
      then
      echo "Killing process " $1
      kill -9 $1               
    fi
    shift
  done
  exit 0
}       

case "$1" in
  start)
	agent_start	
	;;
  stop)
	agent_stop	
	;;
  check)
    agent_check
	;;
  clean)
    agent_clean $(ps -C emagent -o pid=) 
    ;;
  *)
	echo $"Usage: `basename $0` {start|stop|status|clean}"
	exit 1
esac
Dieses Skript, sollte nun auf jeden Knoten kopiert werden. Alternativ kann dies auch beim Erzeugen im Enterprise Manager (DB Console oder Grid Control) auf alle Knoten verteilt werden. Noch besser ist dieses Skript auf einem gemeinsam benutzten Verzeichnis (in ACFS) aufgehoben.

Anlegen der "Lokalen" Cluster Ressource

Am leichtesten kann man die Ressourcen mit dem Enterprise Manager selber registrieren. Ob wir dabei "seine" eigene Überwachung einrichten, oder die von einer anderen DBConsole bzw. EM Agenten kann erst einmal egal sein. D.h. bei der Einrichtung sollten alle DBConsolen per emctl start dbconsole gestartet sein.

Nach der Anmeldung zum "Cluster" Tabulator wechseln:

=> Administration

=> Manage Resources

=> Anmelden als Benutzer oracle (nicht als root!), da das Database Control mit den Berechtigungen des Benutzers oracle gestartet wird

=> Add Resource
Beim nächsten Bild wählt man einen geeigneten Namen und Beschreibung. Der Ressourcen Typ ist "local_resource", da die DBConsole Lokal auf jedem Knoten laufen muss (wegen dem Agenten). Ebenfalls sollte die Ressource nach Anlegen gestartet werden, damit die Informationen in der Clusterware gleich auf dem Status "Online" stehen (im Moment laufen die Prozesse ja, da wir mit der DBConsole arbeiten). Als Aktions-Programm nehmen wir "Use Action Script" und wählen das geeignete Skript auf den Rechnern aus.

Alternativ kann das Aktions-Skript auch direkt in den Browser kopiert werden, wenn man "Create New Action Script" wählt

Im "Attributes" Bereich passen wir die einzelnen Attribute an. Hierzu gehört, wie oft versucht werden soll, die DBConsole zu starten, bevor diese mit dem Status "OFFLINE" gekennzeichnet wird, oder in welchen Abständen die Clusterware prüfen sollte, ob der Agent noch läuft bzw. ein Restart erforderlich ist. Jede Aktion kann mit einem Timeout versehen werden, da das Starten, Stoppen und der Check beim emctl status agent einige Zeit in Anspruch nehmen kann. Ich empfehle 120 Sekunden

Bei den "Advanced Settings":

Könnten unterschiedliche Parameter pro Knoten angegeben werden:

Dies ist aber nicht notwendig. Ebenso braucht die DBConsole keine Abhängigkeiten auf andere Ressourcen. So ist es nicht notwendig, dass die Datenbank gestartet ist, um mit der DBConsole zu arbeiten. Sollte dies so sein, so würde man eine "HARD Dependency" mit "Pullup Dependency" (automatisches Starten der Datenbank) definieren. Maximal denkbar ist eine "Weak Dependency" auf die Datenbank Ressource.

Da auch nichts angehalten werden muss, wenn ein emctl stop dbconsole ausgeführt wird, lassen wir auch die "Hard Stop Dependencies" weg und klicken "Submit". Der abschließende Bildschirm zeigt dann den crsctl Befehl der als Benutzer oracle ausgeführt wird.

Hat alles geklappt, sieht man folgendes:



Wurden die Skripte schon vorher manuell an den richtigen Ort kopiert, hätte man selbstverständlich auch den Befehl direkt (als Benutzer oracle) ausführen können:

$ crsctl add resource dbcagent -type local_resource 
-attr " ACTION_SCRIPT=/opt/grid/crs/public/dbcagent_actionScript.sh, 
DESCRIPTION=Local DB Console Ressource for DB Console Agent, DEGREE=1, 
ENABLED=1, AUTO_START=restore, START_TIMEOUT=120, UPTIME_THRESHOLD=1h, 
CHECK_INTERVAL=60, STOP_TIMEOUT=120, SCRIPT_TIMEOUT=120, RESTART_ATTEMPTS=3, 
OFFLINE_CHECK_INTERVAL=60, START_DEPENDENCIES=, STOP_DEPENDENCIES="
Allerdings bietet die DBConsole doch etwas mehr Komfort und weniger Fehleranfälligkeit. Außerdem werden die Ressourcen nicht gleich automatisch gestartet, wie man auch mit dem crsctl nach erfolgreichem Ausführen sehen kann:
[root@bumucsvm1 ~]# crsctl stat res -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
dbcagent
               OFFLINE OFFLINE      bumucsvm1
               OFFLINE OFFLINE      bumucsvm2
               OFFLINE OFFLINE      bumucsvm3
...
Mit einem crsctl start res dbcagent lässt sich dieses aber schnell beheben.

Für die meisten Systeme sollte diese einfach Überwachung der DBConsolen komplett ausreichend sein, denn damit ist gewährleistet, dass die DBConsole bzw. EM Agent Prozesse immer auf den Knoten gestartet werden und auch gestartet bleiben. Anzumerken sei noch, dass die Ressourcen mit crsctl stop res dbcagent gestoppt werden sollten, falls Wartungsarbeiten am DBControl mit emca vorgenommen werden, wie z.B. eine Rekonfiguration. Denn sonst startet die Clusterware die Prozesse automatisch wieder, die während einer solchen Aktion nicht laufen sollten!

Für Fortgeschrittene: Automatische Rekonfiguration der DBConsole

Dieser Teil beinhaltet mehrere Schritte, so muss als erstes eine Virtuelle IP Adresse (VIP) angelegt werden, die immer mit der Java Oberfläche der DBConsole wandert. Als nächstes muss das Aktions-Skript dafür sorgen, dass beim Starten auf einem anderen Knoten, die Java Oberfläche mit Hilfe des emca -reconfig dbcontrol -cluster umkonfiguriert wird. Dabei gab es bei meinen Tests leider 3 kleine "Unschönheiten":
  • Da bei der DBConsole der Agent nicht getrennt von der Java Oberfläche gesteuert werden kann, sondern alles über emctl start dbconsole gestartet wird, ist eine einfache Trennung zwischen dem "dbcagent" und der "dbconsole" leider nicht möglich. Dies würde man durch eine harte Abhängigkeit (Hard Dependencies) abfangen. Leider ist dies jedoch nicht möglich, da der Befehl emca -reconfig dbcontrol -cluster alle Agenten kurzzeitig stoppt. Dies wiederum steht im Konflikt mit der dbcagent Ressource, da diese auf dem Status "Online" steht und somit ein Stoppen nicht zulässt, bzw. gleich wieder startet. Deswegen werden im Skript selber crsctl Befehle zur Steuerung der dbcagent Ressource eingesetzt. Dies ist zwar nicht besonders schön, aber durch diesen Umstand unumgänglich.
  • Nach der ersten Rekonfiguration mit emca -reconfig dbcontrol -cluster auf einem neuen Knoten lief die DBConsole nicht als "secure". Dadurch wurde eine Kommunikation der Agenten mit dem DBControl verhindert. Dies ist zwar leicht mit einem emctl secure dbconsole auf jedem Knoten zu beheben, tritt aber nur bei der ersten Rekonfiguration pro Knoten auf. D.h. damit dieses Skript einwandfrei funktioniert, müssen zuerst einmal alle Knoten "durchgeschaltet" worden sein. Erschwerend kommt hinzu, dass z.B. bei der Verwendung von Serverpools die Datenbank nicht auf allen Knoten läuft und die Java Oberfläche nur auf einem Knoten laufen kann, auf der auch die zugehörige Datenbankinstanz vorhanden ist. Der Aufwand das emctl secure dbconsole im Skript zu verankern und nur bei Bedarf (auf allen Knoten) aufzurufen wurde Aufgrund der nächsten Einschränkung nicht getätigt:
  • Die (Um)Konfiguration des Database Controls funktioniert im Moment nur wenn alle Knoten im Cluster verfügbar sind.

Anlegen der Applikations-VIP

Damit die Java Console immer unter demselben Namen zu erreichen ist, wird eine zusätzliche VIP benötigt: Dazu klickt man im "Manage Resource Screen" auf "Add Application VIP"

Gibt der VIP Ressource einen Namen, das Netzwerk (Default 1), die neue VIP Adresse und verwendet den Benutzer root

Nochmals den Benutzer root bestätigen...

...und die VIP ist erfolgreich angelegt.

Auch hier hätte man als Benutzer root einfach folgenden Befehl ausführen können:

# appvipcfg create -network=1 -ip=10.165.244.111 -vipname=dbconsole.vip -user=root
Wichtig! Da die Java Console im nächsten Schritt wieder als Benutzer oracle angelegt wird, und die VIP mit der Java Oberfläche wandert (und umgekehrt), braucht der Benutzer Ausführungsberechtigungen auf die VIP. Diese Berechtigungen werden mit folgendem Befehl zugewiesen:
# crsctl setperm res dbconsole.vip -u user:oracle:r-x

Das Actions-Skript der DBConsole

Wie oben schon erwähnt, ist hier das Besondere, dass für die Kontrolle der DBConsole (zum Starten und Stoppen) crsctl und die dbcagent Ressource verwendet wird. Des Weiteren wird nach dem Java Prozess geprüft und nur, wenn dieser auf dem Server auf dem die Ressource gestartet wird, nicht gefunden wird, eine Rekonfiguration über emca angestoßen.

#!/bin/bash
#
# dbconsole.sh - script to start and stop the java interface of the dbconsole 11gR2
#
# description: Oracle 11gR2 database console

ORACLE_BASE=/opt/oracle
ORACLE_HOME=$ORACLE_BASE/product/11.2.0/db
GRID_HOME=/opt/grid
LD_LIBRARY_PATH=$ORACLE_HOME/lib
ORACLE_SID=buvmrac
ORACLE_UNQNAME=$ORACLE_SID
PATH=$ORACLE_HOME/bin:$GRID_HOME/bin:$PATH
HOST=$(/bin/hostname)

export ORACLE_BASE
export ORACLE_HOME
export LD_LIBRARY_PATH
export ORACLE_SID
export ORACLE_UNQNAME
export GRID_HOME
export HOST
export PATH

dbconsole_start () {
  $GRID_HOME/bin/crsctl start res dbcagent -n ${HOST/.*/}
  process=$(ps -e -o pid,cmd |grep java|grep _$ORACLE_UNQNAME/config/server.xml)
  if [ -z "$process" ]
    then
      $GRID_HOME/bin/crsctl stop res dbcagent
      $ORACLE_HOME/bin/emca -reconfig dbcontrol -cluster -silent -DB_UNIQUE_NAME $ORACLE_UNQNAME -SERVICE_NAME $ORACLE_SID 
  fi
}

dbconsole_stop () {
  $GRID_HOME/bin/crsctl stop res dbcagent -n ${HOST/.*/} 
}

dbconsole_check () {
  $ORACLE_HOME/bin/emctl status dbconsole
}

dbconsole_clean () {
  $GRID_HOME/bin/crsctl stop res dbcagent -n ${HOST/.*/} 
}       

case "$1" in
  start)
	dbconsole_start 
	;;
  stop)
	dbconsole_stop	
	;;
  check)
    dbconsole_check
	;;
  clean)
    dbconsole_clean
    ;;
  *)
	echo $"Usage: `basename $0` {start|stop|check|clean}"
	exit 1
esac
Hier finden Sie das Skript direkt zum Download.

Anlegen der Cluster Ressource

Wieder als Benutzer oracle: "Add Resource"

Einfügen des Skripts (wenn nicht vorher schon auf die Knoten kopiert):

Wieder Namen und Beschreibung vergeben, allerdings diesmal den Typus "Cluster Resource" auswählen. Interessant ist hier, dass neben der Kardinalität (die wir bei 1 belassen)

die Platzierung der Ressource auf bestimmte Server bzw. Serverpools beschränkt werden kann. Da in meinem Fall die Datenbank an den Serverpool ora.bu gebunden ist, beschränke ich die Ressource genau auf diese Server (da die Java Konsole nur auf einem Knoten laufen kann, auf dem auch eine Instanz der zugehörigen Datenbank vorhanden ist).

Da bei einer Rekonfiguration der Start Prozess der DB Console sehr lange braucht, sollte der Start Timeout diesmal dementsprechend "hoch" gewählt werden (600 Sekunden).

Diesmal erzeugen wir eine harte Abhängigkeit auf die dbconsole.vip (die auch gleich mit gestartet werden soll: Pullup)

und legen auch eine harte Stopp Abhängigkeit fest, wenn die VIP gestoppt wird,

so dass unsere Abhängigkeiten nun wie folgt aussehen:

Nach einem "Submit", ist zu erkennen, welche Arbeit der Enterprise Manager einem abgenommen hat:

Nach dem Klick auf "Continue" sollte man nun Folgendes sehen:

Es sei denn, die Applikations-VIP lief zu diesem Zeitpunkt auf einem anderen Knoten als die jetzige Java Oberfläche. In diesem Fall bewirkt dies, dass nun schon die erste Rekonfiguration stattfindet. Deswegen bietet vielleicht in diesem Falle der manuelle Befehl etwas mehr Kontrolle:

$ crsctl add resource dbconsole -type cluster_resource 
-attr " ACTION_SCRIPT=/opt/grid/crs/public/dbconsole_actionScript.sh, 
DESCRIPTION=Ressource for Java DB Console, DEGREE=1, ENABLED=1, 
AUTO_START=restore, START_TIMEOUT=600, UPTIME_THRESHOLD=1h, CHECK_INTERVAL=60, 
STOP_TIMEOUT=120, SCRIPT_TIMEOUT=60, RESTART_ATTEMPTS=3, OFFLINE_CHECK_INTERVAL=0, 
START_DEPENDENCIES=hard(dbconsole.vip) pullup(dbconsole.vip), 
STOP_DEPENDENCIES=hard(dbconsole.vip),CARDINALITY=1, FAILURE_INTERVAL=0, 
FAILURE_THRESHOLD=0, SERVER_POOLS=ora.bu, PLACEMENT=restricted, LOAD=1, ACTIVE_PLACEMENT=0"
Bleibt am Ende nur noch das Ganze intensiv zu testen, zu stoppen, zu starten und "umzuspeichern" (relocate):
$ crsctl start res dbconsole
$ crsctl stop res dbconsole
$ crsctl relocate res dbconsole -f
Hinweis: Logs zu meinen Tests waren im $GRID_HOME/log/<hostname>/agent/crsd/ora_oc4j_type_oracle/ora_oc4j_type_oracle.log Log zu finden. Dies liegt daran, dass die Log-Informationen zu Ressourcen Typen "local_resource" und "cluster_resource" mit dem Namen auftauchen, unter dem die erste Ressource in diesem Typ beim Cluster Start gestartet wurde. Deswegen ist es auch empfohlen eigene Ressource Typen anzulegen (abgeleitet von Lokalen bzw. Cluster Ressourcen).

Ich hoffe Ihnen mit diesem Tipp einige Hinweise auf die Integration von Applikationen in die Clusterware gegeben zu haben und vielleicht auch Lust, dies mal selber auszuprobieren und zu erweitern.

Nützliche Links und Referenzen

  • OracleŽ Clusterware Administration and Deployment Guide 11g Release 2 (11.2) 5 Making Applications Highly Available Using Oracle Clusterware
  • Zurück zur Community-Seite