DBA Community
DBA Community
|
Der Startup Prozess der Grid Infrastruktur
von Sebastian Solbach, ORACLE Deutschland B.V. & Co. KG
Während meiner Veranstaltungen zum Thema Grid Infrastruktur und Real Application Cluster wurde ich schon häufiger nach dem Startup Prozess der Grid Infrastruktur gefragt.
Die Dokumentation zur Grid Infrastruktur beschreibt zwar generell die involvierten Prozesse, bleibt aber einige interessante Informationen schuldig.
So wird nirgends auf die genaue Start-Reihenfolge eingegangen. Genauso wenig wie eine Antwort auf die Frage gegeben wird, wie Oracle das "Henne - Ei" Problem gelöst hat:
Ohne ASM keinen Zugriff auf OCR und Voting Disks und ohne OCR und Voting Disks keine Möglichkeit, ASM zu starten.
Der zentrale Startprozess
Seit 11.2 gibt es nur noch einen zentralen Prozess, der beim Systemstart über die init Datei oder als Windows Service gestartet wird: Der Oracle High Availability Service Daemon (kurz ohasd) bzw. OracleOHService.
Dieser Prozess schaut unter /etc/oracle/scls_scr/<nodename>/root/ohasdstr nach, ob der Startup des Clusters aktiviert ("enabled") ist oder vorher mit einem
# crsctl disable crsexplizit ausgeschaltet wurde. Ist dies der Fall, ist der Startup Prozess hiermit beendet und nur der ohasd läuft. Durch den Start des ohasd sind clusterweite Befehle möglich, so dass bereits ab diesem Zeitpunkt mit einem # crsctl start cluster [-n nodename]die Clusterknoten remote gestartet werden können. Die Oracle Local Registry (OLR)
Wurde der Cluster gestartet, startet der Oracle High Availability Service Daemon nun die einzelnen Prozesse über die dazugehörigen Agenten (oraagent, orarootagent, cssdagent).
Woher bekommt aber nun ohasd seine Informationen, welche Prozesse in welcher Reihenfolge und von welchem Agenten gestartet werden sollen?
Dazu bedient sich der ohasd der Oracle Local Registry (kurz OLR).
Dieses OLR ist eine lokale Informationsdatei, die ähnlich aufgebaut ist wie die Oracle Cluster Registry (OCR) und über dieselben Befehle (ocrcheck, ocrdump ocrconfig) verwaltet wird:
Jeweils mit dem Zusatz "-local". So kann man sich den Ort der OLR über den Befehl ocrcheck -local anzeigen lassen:
# ocrcheck -local
Status of Oracle Local Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 2580
Available space (kbytes) : 259540
ID : 1407447555
Device/File Name : /u01/app/11.2.0/grid/cdata/bumucsvm5.olr
Device/File integrity check succeeded
Local registry integrity check succeeded
Logical corruption check succeeded
In dieser OLR sind die Abhängigkeiten der "lokalen" Ressourcen festgelegt, die Auswirkungen auf das Startverhalten der Prozesse haben.
Im Falle der Clusterware ist jede Ressource ein Eintrag zu einem dazugehörigen Clusterware Prozess.
Allerdings muss man sich hierzu nicht die Datei in Klartext über den Befehl ocrdump
anzeigen lassen, sondern bedient sich der Anzeige über crsctl mit dem Parameter "-init":
# crsctl stat res -t -init
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.asm
1 ONLINE ONLINE bumucsvm5 Started
ora.cluster_interconnect.haip
1 ONLINE ONLINE bumucsvm5
ora.crf
1 ONLINE ONLINE bumucsvm5
ora.crsd
1 ONLINE ONLINE bumucsvm5
ora.cssd
1 ONLINE ONLINE bumucsvm5
ora.cssdmonitor
1 ONLINE ONLINE bumucsvm5
ora.ctssd
1 ONLINE ONLINE bumucsvm5 OBSERVER
ora.diskmon
1 ONLINE ONLINE bumucsvm5
ora.drivers.acfs
1 ONLINE ONLINE bumucsvm5
ora.evmd
1 ONLINE ONLINE bumucsvm5
ora.gipcd
1 ONLINE ONLINE bumucsvm5
ora.gpnpd
1 ONLINE ONLINE bumucsvm5
ora.mdnsd
1 ONLINE ONLINE bumucsvm5
Dieser Befehl ist auch nützlich um den Start der Clusterware Ressourcen zu überwachen, indem er Auskunft über den Prozess-Fortschritt gibt
(siehe Informationen in der Spalte STATE).
Erst wenn alle Ressourcen den Status "ONLINE" haben, sind auch die weiteren Cluster Ressourcen, wie
Virtuelle IP Adressen, Listener und Datenbanken über den Befehl "crsctl stat res -t" (ohne "-init") sichtbar.
Die Reihenfolge
Die Reihenfolge der Prozesse läßt sich über die Log-Dateien der Agenten und über die sogenannten "Start Abhängigkeiten" ableiten:
# crsctl stat res -p -init |grep -e "START_DEPENDENCIES" -e "^NAME"Daraus ergibt sich folgende Tabelle (bereits sortiert nach der Reihenfolge):
Ausschlaggebend sind eigentlich die "Harten Abhängigkeiten" (hard). Theoretisch könnten Ressourcen ohne Abhängigkeiten auch in einer anderen Reihenfolge gestartet werden. Eine genauere Beschreibung der unterschiedlichen Arten von Abhängigkeiten (hard, weak, pullup, dispersion) findet man in der Dokumentation im Oracle Clusterware Administration and Deployment Guide. Auch wenn manche Startprozesse fast gleichzeitig starten, bedeutet dies nicht, dass diese auch gleichzeitig abgeschlossen sind. Da auch auf "Schwache Abhängigkeiten" (weak) gewartet wird, können sogar die Prozesse einer Ressource, die später gestartet wurde, schneller den Status "ONLINE" erhalten. Die Aufgaben der einzelnen Prozesse stehen ebenfalls in der Dokumentation Oracle Clusterware Administration and Deployment Guide Das Henne - Ei Problem
Der Zugriff auf die Oracle Cluster Registry (OCR) ist erst notwendig, wenn der Cluster Ready Service Daemon (kurz crsd) startet.
Da ASM zu diesem Zeitpunkt schon läuft, stellt dies beim Starten kein Problem dar. Einzig und allein muss dafür Sorge getragen werden, dass nach einem erfolgreichen Startup die Inhalte der OLR mit der OCR
abgeglichen werden. Interessanter wird es beim Zugriff auf die Voting Disks bzw. das ASM Spfile (welches ja ebenfalls in ASM liegt). Hierzu bedient sich die Clusterware zwei unterschiedlicher Mechanismen: Die Voting Disks sind für den Cluster Synchronization Services Daemon (kurz cssd) wichtig, da dieser die Teilnahme der Knoten am Cluster steuert. Der Zugriff auf die Voting Disks muss sehr früh im Startup Prozess erfolgen, damit der Knoten dem Cluster "beitreten" kann. Der Trick hierbei ist, dass die Voting Disks im ASM Header der Infrastruktur Diskgruppe gespeichert werden. Hierdurch kann der cssd Prozess auf die Voting Disks zugreifen, auch ohne, dass ASM gestartet wurde. CSS muss lediglich auf die entsprechenden Disks der Diskgruppe zugreifen können - d.h. der Disk String muss CSS bekannt sein. Diesen bezieht der cssd Prozess aus dem Grid Plug and Play Profil $GRID_HOME/gpnp/<node>/profiles/peer/profile.xml. Etwas anders funktioniert der Zugriff von ASM auf das ASM Spfile. Die Besonderheit des ASM SPFile ist, dass es relativ klein ist, und deswegen immer in eine Allokation Unit (AU) in ASM passt. Einzelne AUs können auch heute schon leicht ausgelesen werden (ohne dass die ASM Instanz gestartet werden muss). Alles was dazu notwendig ist, ist durch den ASM Diskheader die richtige AU auf der entsprechenden Platte zu finden. Durch diese beiden Technicken kann der Clusterstack auch ohne die eigentlichen ASM Prozesse starten. Die weiteren Prozesse Sobald die Cluster Ready Services laufen (crsd) übernimmt dieser den weiteren Startup. Dies funktioniert ähnlich wie der
ohasd Prozess, nur dass der CRS seine Informationen aus der Oracle Cluster Registry (OCR) in ASM bekommt. Auch hier kann die weitere Start-Reihenfolge
mit crsctl ausgelesen werden.
# crsctl stat res -p |grep -e "START_DEPENDENCIES" -e "^NAME"Daraus ergibt sich folgende Tabelle (bereits sortiert nach der Reihenfolge):
Theoretisch ist die Start-Reihenfolge eigentlich nur von den "Harten Abhängigkeiten" (hard) bestimmt. CRS versucht, alle Prozesse "gleichzeitig" zu starten, da die Agenten allerdings sequentiell arbeiten, gibt es eine interne Reihenfolge, die aus den Log-Dateien der Agenten abzulesen ist. Wann diese Prozesse dann aber den Status "ONLINE" haben, wird von den Abhängigketien bestimmt. Beim Startup kann man sehr schön das oben beschriebene Phänomen beobachten, dass Ressourcen vor anderen gestartet werden, aber Aufgrund ihrer Abhängigkeiten erst viel später den Status "Online" anzeigen. Nützliche Links und Referenzen
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||