News zu Oracle

Hochverfügbarkeit hochverfügbar – das richtige Placement zum Überleben einer Node Eviction

Die Oracle Clusterware ist ein wichtiger Bestandteil der Oracle High Availability Architecture. Ressourcen, die unter Kontrolle der Clusterware stehen, werden überwacht, bei Systemstart automa­tisch hoch gefahren und nach einem Absturz neu gestartet oder auf einen anderen Server verschoben. Der Haupteinsatzzweck der Clusterware ist aber vor allem die Absicherung eines Serverausfalls.

Ein Cluster ist aufgrund seiner Komplexität anfäl­liger für Störungen in der Infrastruktur. Und eine der fatalsten Störungen ist der, auch nur vorüber­ge­hende, Ausfall des Netzwerk-Heartbeats zwischen den Clusterservern. In einem solchen Fall ist eine Kommunikation zwischen allen Clusterservern nicht mehr möglich und die Konsistenz des Clusters poten­tiell gefährdet. Wie die Oracle Clusterware darauf reagiert, ist insbe­sondere in Failover-Konstellationen von essen­ti­eller Bedeutung. Der heutige DBA-Tipp beschreibt, was du in diesem Umfeld beachten musst, damit dein High-Availability-Ansatz nicht „nach hinten losgeht“.

Split Brain und Node Eviction

Ist die Kommunikation über das Interconnect-Netzwerk länger als 30 Sekunden gestört, geht die Clusterware von einem sogenannten Split-Brain-Szenario aus. Das heißt, der Cluster betrachtet sich als in zwei oder mehr Subcluster, sogenannte Cohorts, zerfallen, die nun zwangs­läufig Gefahr laufen, ein „Eigenleben“ zu führen und damit die Konsistenz des Clusters insgesamt zu gefährden. Er reagiert darauf, indem er eine definierte Menge von Servern aus dem Cluster entfernt und sie erst wieder connecten lässt, wenn die Störung behoben ist. Dieses „Node Eviction“ genannte Verfahren wird durch einen Neustart des Clusterstacks auf den auszu­schlie­ßenden Servern oder Reboot der betrof­fenen Server realisiert.

Auswirkungen auf RAC-Datenbanken

Da die beschriebene Node Eviction mindestens mit einem Neustart des gesamten Clusterstacks verbunden ist, bedeutet Node Eviction auch immer den Abbruch einer Untermenge der aktiven Datenbanksessions. Geht man jedoch davon aus, dass Clientsessions auf RAC-Datenbanken regel­mäßig über alle Clusterserver verteilt sind, muss man sich hier keine Gedanken darüber machen, welche Server im Falle eines Split-Brain-Szenarios ausge­schlossen werden. Verhindern oder beein­flussen kann man es in diesem Fall sowieso nicht.

Auswirkungen auf Failover-Datenbanken – oder allgemein – Failover Ressourcen

Anders sieht es hingegen bei Failover Ressourcen aus. Sie laufen norma­ler­weise nur auf je einem Server des Clusters und damit ist ihr Placement durchaus relevant. Es wäre ja äußerst fatal, wenn im Falle eines Heartbeatausfalls – der für sich gesehen gar keine Auswirkung auf die Verfügbarkeit einer Datenbank hat – gerade der Server rebootet, der die produktive Datenbank betreibt, während ein Server mit Testdatenbanken oder gar ein leerer Standby überleben würde. Daher ist es wichtig, sich mit den Eviction-Regeln zu befassen.

1. Eviction Regel I

Die primäre Regel des Eviction Algorithmus besagt, dass im Split-Brain-Fall der Subcluster überlebt, in dem die meisten Server verblieben sind. Der oder die Subcluster mit Serverminderheit werden ausge­schlossen. Lässt sich anhand dieser Regel keine eindeutige Entscheidung fällen, also mehr als ein Subcluster eine Servermajorität hat (im simpelsten Fall, einem 2‑Node-Cluster, enthält jeder der beiden Subcluster einen Server), greift die Eviction Regel II. Und für diese müssen wir wiederum vier Fälle unter­scheiden, je nachdem, welche Version der Clusterware instal­liert ist. In der Grid Infrastructure Umgebung ermittelt ihr die Version eurer Clusterware mittels:

[oracle@c-tso-rac01(grid12c +ASM1) ~]$ crsctl query crs activeversion
Oracle Clusterware active version on the cluster is [12.1.0.2.0]

2. Eviction Regel bis Clusterware 12.1.0.1

Bis einschließlich Clusterware Version 12.1.0.1 überlebt der Subcluster, in dem sich der Server mit der niedrigsten Nodenumber befindet. Diese Nodenumber wird fortlaufend an die Clusterserver vergeben und ergibt sich aus dem Zeitpunkt, zu dem der betref­fende Server dem Cluster hinzu­gefügt wird – praktisch entspricht die Nodenumber also der Installationsreihenfolge, solange Server nicht aus dem Cluster gelöscht und später wieder hinzu­gefügt werden. Die Nodenumbers können in der Grid Infrastructure Umgebung ermittelt werden über:

[oracle@c-tso-rac01(grid12c +ASM1) ~]$ olsnodes -n
c-tso-rac01 1
c-tso-rac02 2

Eine nachträg­liche Änderung der Nodenumber ist nur durch Entfernen und Wiedereinfügen des betref­fenden Servers in den Cluster möglich. Solltet ihr also einen Cluster aus heterogen ausge­stat­teten Servern aufbauen, solltet ihr bereits die Installation der Clusterware entspre­chend planen und die Server nach abstei­gender Wichtigkeit instal­lieren. Bei homogen ausge­stat­teten Servern ist eine solche Überlegung nicht erfor­derlich. Einzige Ausnahme hiervon bildet ein Failover-Cluster, in dem von der 10-Tage-Regel Gebrauch gemacht werden soll. Hier muss zwingend und unver­än­derlich genau ein Standbyserver festgelegt werden, der dann auch nur vorüber­gehend Datenbanken betreiben darf. Für diese Rolle würde man folglich den Server mit der größten Nodenumber auswählen.

Gehen wir von obigem Beispiel, einem 2‑Node-Cluster aus den Servern c‑tso-rac01 und c‑tso-rac02 aus, wird im Fall eines Heartbeatausfalles immer der Server mit der Nodenumber 1, also c‑tso-rac01, überleben. Folglich sollten dort auch die wichti­geren Ressourcen platziert werden.
Andernfalls passiert folgendes:

  • Die produktive Datenbank befindet sich auf dem Server mit der höheren Nodenumber (c‑tso-rac02)
Screenshot Prod on 2 online
  • Eine Störung des Interconnect führt zum Ausschluss des Servers c‑tso-rac02. Folglich wird die produktive Datenbank proddb dort gestoppt und auf dem verblei­benden Server c‑tso-rac01 neu gestartet.
Screenshot Prod on 2 offline
  • Mit Ende des Switchover ist die produktive Datenbank zwar wieder verfügbar. Es sind aber im Zuge des Failovers sämtliche Sitzungen verloren gegangen, die Datenbank war unter Umständen mehrere Minuten nicht verfügbar und abhängig von der Anwendung können noch erheb­liche Wiederanlaufaufwände anfallen.

  • Die vergleichs­weise unwich­tigen Dev- und Testdatenbanken hingegen waren in keiner Weise vom Ausfall des Heartbeats betroffen.
  •  

Das oben beschriebene Ausschlussverfahren lässt sich dann auch im ocssd.log der Clusterware nachverfolgen:

2016-08-01 19:16:19.943: [ CSSD][2446112512]clssnmCheckDskInfo: My cohort: 2
2016-08-01 19:16:19.943: [ CSSD][2446112512]clssnmCheckDskInfo: Surviving cohort: 1
2016-08-01 19:16:19.943: [ CSSD][2446112512](:CSSNM00008:)clssnmCheckDskInfo: Aborting local node to avoid splitbrain. Cohort of 1 nodes with leader 2, c-tso-rac02,
is smaller than cohort of 1 nodes led by node 1, c-tso-rac01, based on map type 2

Dieses Szenario liese sich beliebig oft wieder­holen. Selbst wenn sich alle drei Datenbanken auf dem Node 2 befänden und der Node 1 damit quasi idle wäre, würde im Fall einer Heartbeatstörung der Node 2 aus dem Cluster ausge­schlossen und alle drei Datenbanken auf dem Node 1 neu gestartet.

In einem Cluster mit drei oder mehr Servern ist der Ausfall nicht so einfach vorher­sehbar. Im ungüns­tigen Fall splittet sich hier vielleicht nur der Server 1 aufgrund eines NIC-Fehlers vom Cluster ab. Dann bilden die Nodes 2 und 3 den größeren Subcluster und 1 würde ausge­schlossen. Da aber eben genau das nicht vorher­sehbar ist, ist man auch hier zumindest statis­tisch gesehen besser aufge­stellt, wenn man die wichtigsten Ressourcen auf dem Server mit der niedrigsten Nodenumber platziert.

Das bis 12.1.0.1 imple­men­tierte Verhalten hat einen wesent­lichen Vorteil – es ist zu einem großen Teil plan- und vorher­sehbar. Insbesondere gilt das für einen 2‑Node-Cluster, einer der wahrscheinlich am häufigsten verwen­deten Clusterinstallationen, zumindest im Standard-Edition-Umfeld.

3. Eviction ab Clusterware 12.1.0.2 steuern

Diese eben in Punkt 2 beschriebene, statische Evictionregel bis Version 12.1.0.1 hat jedoch gleich­zeitig den Nachteil, dass sie keine Rücksicht auf die Anzahl der von den jewei­ligen Servern bereit­ge­stellten Ressourcen nimmt. Wie bereits in Punkt 2 erwähnt, würde unter Umständen auch ein vollkommen leerer Server zu Lasten eines Servers überleben, auf dem zahlreiche Datenbanken laufen. Vor allem im Hinblick auf den Cloud-Ansatz und policy-managed Clusterressourcen wurde Regel II mit Version 12.1.0.2 der Clusterware grund­legend verändert.

Der Ausschluss aus dem Cluster wird nicht mehr nur auf Basis der Nodenumber entschieden, sondern primär von der Anzahl der Datenbanken und Datenbankservices auf den infrage kommenden Servern abhängig gemacht. Es überlebt nun der Subcluster, auf dem in Summe mehr Services laufen. Leider zählen hierbei aber nur „echte“ RAC-Datenbanken und ‑services und die in 12.1.0.2 einge­führte Management Database mgmtdb, also Ressourcen vom Typ ora.database.type, ora.service.type und ora.mgmtdb.type. Failover-Datenbanken oder andere selbst­de­fi­nierte Clusterressourcen werden nicht in die Berechnung einbezogen.

Im Falle eines Gleichstandes der Anzahl Datenbanken und ‑services greift weiterhin die Eviction Regel IIa, d.h. der Subcluster, in dem die niedrigste Nodenumber vertreten ist, wird überleben.

Gehen wir davon aus, dass ihr einen reinen Failover-Cluster betreibt – also nicht auch noch RAC-Datenbanken vertreten sind – dann wird bei der Zählung der entschei­dungs­re­le­vanten Ressourcen also zwangs­läufig nur die mgmtdb berück­sichtigt. Folglich sollten alle wichtigen Datenbanken auf dem selben Node laufen, auf dem sich auch die mgmtdb befindet. Die Chance, dass diese ein split-brain-Szenario überleben, ist damit am höchsten.

Screenshot MGMTDB

Um die Management Database (mgmtdb) auf den Clusternode mit der niedrigsten Nodenumber zu verschieben, setzt ihr in der Grid Infrastructre Umgebung folgenden Befehl ab:

srvctl relocate mgmtdb -node $(olsnodes -n|sort -nk2,2|head -1|awk '{print $1}')

Das Verschieben der mgmtdb kann im laufenden Betrieb erfolgen und hat keine Auswirkungen auf die übrigen Clusterressourcen.

Möchtest du deine produktive(n) Datenbank(en) auf den selben Server wie die mgmtdb verschieben, tust du das mit:

rsctl relocate resource db.proddb -n $(srvctl status mgmtdb|grep 'is running on node'|awk 'NF>1{print $NF}')

Das wäre aber mit einem Neustart der entspre­chenden Datenbank verbunden, wenn sie nicht zufällig bereits auf dem richtigen Server liegt. Besser ist es daher, die Datenbank gleich auf dem richtigen Server zu starten:

crsctl start resource db.proddb -n $(srvctl status mgmtdb|grep 'is running on node'|awk 'NF>1{print $NF}')

Falls du die betref­fende Datenbank nicht verschieben kannst, weil dir kein Wartungsfenster zur Verfügung steht, kannst du aber zumindest noch die mgmtdb auf diesen Server verschieben und damit seine Überlebenswahrscheinlichkeit anheben:

srvctl relocate mgmtdb -node $(crsctl status resource db.proddb|grep '^STATE'|awk 'NF>1{print $NF}')

In einem Failover-Cluster mit Nutzung der 10-Tage-Regel lässt du natürlich die mgmtdb nie auf dem Standbyserver laufen. Der Standbyserver sollte auch mit Clusterware 12.1.0.2 derjenige mit der höchsten Nodenumber sein.

4. Eviction ab Clusterware 12.2.0.1 steuern

Mit Clusterware 12.2 wurde die Gewichtung nach Datenbanken und Services aus 12.1.0.2 beibe­halten, aber die mgmtdb wird nun nicht mehr berück­sichtigt. Damit ist die mgmtdb nicht mehr als Token für die Festlegung des präfe­rierten Servers nutzbar. Wir behelfen uns hier mit einer Datenbankinstanz „quorum“, die nur im nomount-Mode betrieben wird.

[oracle@c-tso-rac01 ~]$ echo -e \
"db_name=quorum\nsga_target=2G\nuse_large_pages=false" \
>$ORACLE_HOME/dbs/initquorum.ora

[oracle@c-tso-rac01 ~]$ export ORACLE_SID=quorum

[oracle@c-tso-rac01 ~]$ sqlplus -S / as sysdba <<sql
> create spfile='+DG_DATA/spfilequorum.ora' from pfile;
> sql
File created.

[oracle@c-tso-rac01 ~]$ srvctl add database \
-d quorum -o $ORACLE_HOME -p +DG_DATA/spfilequorum.ora \
-c single -x c-tso-rac02 -s nomount

[oracle@c-tso-rac01 ~]$ srvctl start database -d quorum

Ihre einzige Aufgabe ist es, als für die Eviction zählbare ora.database.type-Ressource zu fungieren. Sichtbar ist der Unterschied hier auch im Ressourcenname. Während die selbst­de­fi­nierten Failoverressourcen dem Namensschema db.<dbname> folgen, hat die quorum-Datenbank als „echte“ Clusterdatenbank das Namensschema ora.<dbname>.db. Diese Datenbank muss folglich auf der selben Seite wie die wichtigen Datenbanken laufen.

Ebenfalls mit 12.2 wurde an Clusterressourcen ein neues Flag – CSS_CRITICAL – einge­führt. Die Anzahl von Ressourcen, die dieses Flag auf yes gesetzt haben, fließt ebenfalls in die Gewichtung des jewei­ligen Servers ein. Allerdings wurde dieses Flag nach unserer Erfahrung an selbst­de­fi­nierten Clusterressourcen nicht berück­sichtigt. Eine Lösung hierfür konnte auch vom Oracle Support nicht bereit­ge­stellt werden.

Screenshot Quorum

5. Eviction ab Clusterware und Datenbank 19.7 steuern

Mit Release Update 19.7 wurde das Konzept „Standard Edition High Availability“1 einge­führt. In seiner Wirkungsweise unter­scheidet es sich nicht wesentlich von den bereits oben beschrie­benen Failover-Datenbanken auf Basis selbst­de­fi­nierter Clusterressourcen. Drei wesent­liche Verbesserungen gehen damit dennoch einher:

  • Die Failover-Datenbank wird jetzt vollum­fänglich von Oracle unter­stützt. Der Support für selbst­de­fi­nierte Failoverresourcen endete hingegen am Failoverscript.

  • Die Failover-Datenbank ist jetzt eine „echte“ Clusterdatenbank einschließlich der Kommunikation sqlplus ↔ Clusterware. Das heißt, ein Starten oder Stoppen per sqlplus wird nun auch von der Clusterware bemerkt und im Clusterstatus widerspiegelt.

  • Eine Gewichtung per CSS_CRITICAL wird nun – im Gegensatz zu selbst­de­fi­nierten Clusterressourcen – berück­sichtigt. Damit ist eine Unterscheidung wichtiger von unwich­tigen Datenbanken möglich und die Eviction basiert nicht mehr (nur) auf reiner zahlen­mä­ßiger Überlegenheit von Datenbanken auf einem gegenüber dem anderen Server.
oracle@c-tso-rac01 ~]$ srvctl add database -db proddb \
-oraclehome $ORACLE_HOME -dbtype single \
-spfile +DG_DATA/PRODDB/PARAMETERFILE/spfile.383.1087569801 \
-node "c-tso-rac01,c-tso-rac02" \
-css_critical YES

[oracle@c-tso-rac01 ~]$ srvctl add database -db testdb \
-oraclehome $ORACLE_HOME -dbtype single \
-spfile SPFILE=+DG_DATA/TESTDB/PARAMETERFILE/spfile.294.1087569729 \
-node "c-tso-rac01,c-tso-rac02" \
-css_critical NO

[oracle@c-tso-rac01 ~]$ srvctl add database -db devdb \
-oraclehome $ORACLE_HOME -dbtype single \
-spfile +DG_DATA/DEVDB/PARAMETERFILE/spfile.295.1087574423 \
-node "c-tso-rac01,c-tso-rac02" \
-css_critical NO

[oracle@c-tso-rac01 ~]$ srvctl start database -db testdb -node c-tso-rac01
[oracle@c-tso-rac01 ~]$ srvctl start database -db devdb -node c-tso-rac01
[oracle@c-tso-rac01 ~]$ srvctl start database -db proddb -node c-tso-rac02
Screenshot Seha

Fazit

Der Einsatz der Oracle Clusterware ist ein wichtiger Bestandteil einer zuver­läs­sigen Hochverfügbarkeitslösung. Gleichzeitig handelt es sich dabei aber um ein komplexes Produkt, das insbe­sondere auf Störungen in seinen Kommunikationswegen empfindlich reagiert. Um die Auswirkungen dieser Störungen auf wichtige Ressourcen zu minimieren, müssen bei ihrer Platzierung nicht nur die Leistungsfähigkeit der Server berück­sichtigt werden – sie sollte in Clustern ohnehin homogen sein – sondern auch die Auswirkungen einer möglichen Node Eviction.

Failoversysteme auf Oracle Clusterware sind am wenigsten wahrscheinlich von Node Evictions betroffen, wenn die wichtigen Ressourcen

  • bis Clusterware 12.1.0.1 auf dem Node mit der niedrigsten Nodenumber,

  • ab Clusterware 12.1.0.2 auf dem selben Node wie die Management Database (mgmtdb),

  • ab Clusterware 12.2.0.1 auf dem selben Node wie eine selbst­er­stellte quorum-Ressource platziert sind.

  • für Standard Edition Datenbanken als Failoverressourcen ist ab Clusterware und Datenbank 19.7 die Nutzung von „Standard Edition High Availability“ die beste Lösung.
Hier findest du weitere Posts zu den Themen Oracle Database und DBA Tipps aus unserem News Bereich. 
icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook 
Twitter 
LinkedIn 
XING 
WhatsApp 
Email