News
DBA-Tipp: Hochverfügbarkeit hochverfügbar – das richtige Placement zum Überleben einer Node Eviction

Die Information ist ein schnelllebiges Gut. Jeden Tag werden wir mit hunderten Informationen zugemüllt. Deshalb sind wir bestrebt uns auf das Wesentliche zu konzentrieren und nur substantiell nachhaltige Informationen bereitzustellen.

Icon Unternehmen

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

Gleichzeitig ist ein Cluster aber aufgrund seiner Komplexität anfälliger für Störungen in der Infrastruktur. Und eine der fatalsten Störungen ist der, auch nur vorübergehende, Ausfall des Netzwerk-Heartbeats zwischen den Clusterservern. In einem solchen Fall ist keine Kommunikation zwischen allen Clusterservern mehr möglich und die Konsistenz des Clusters potentiell gefährdet. Wie die Oracle Clusterware darauf reagiert, ist insbesondere in Failover-Konstellationen von essentieller Bedeutung. Der heutige DBA-Tipp beschreibt, was Sie in diesem Umfeld beachten müssen, damit Ihr High-Availability-Ansatz nicht „nach hinten losgeht“.

1 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 zwangslä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 auszuschließenden Servern oder Reboot der betroffenen Server realisiert.

1.1 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 regelmäßig über alle Clusterserver verteilt sind, muss man sich hier keine Gedanken darüber machen, welche Server im Falle eines Split-Brain-Szenarios ausgeschlossen werden. Verhindern oder beeinflussen kann man es in diesem Fall sowieso nicht.

1.2 Auswirkungen auf Failover-Datenbanken - oder allgemein - Failoverressourcen

Anders sieht es hingegen bei Failoverressourcen aus. Sie laufen normalerweise 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.3 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 ausgeschlossen.

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 zwei Fälle unterscheiden, je nachdem, welche Version der Clusterware installiert ist. In der Grid Infrastructure Umgebung ermitteln Sie die Version Ihrer 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]

1.4 Eviction Regel IIa

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 betreffende Server dem Cluster hinzugefügt wird – praktisch entspricht die Nodenumber also der Installationsreihenfolge, solange Server nicht  aus dem Cluster gelöscht und später wieder hinzugefü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ägliche Änderung der Nodenumber ist nur durch Entfernen und Wiedereinfügen des betreffenden Servers in den Cluster möglich. Sollten Sie also einen Cluster aus heterogen ausgestatteten Servern aufbauen, sollten Sie also bereits die Installation der Clusterware entsprechend planen und die Server nach absteigender Wichtigkeit installieren. Bei homogen ausgestatteten Servern ist eine solche Überlegung nicht erforderlich. Einzige Ausnahme hiervon bildet ein Failover-Cluster, in dem von der 10-Tage-Regel Gebrauch gemacht werden soll. Hier muss zwingend und unveränderlich genau ein Standby Server festgelegt werden, der dann auch nur vorübergehend 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 wichtigeren Ressourcen platziert werden.

Andernfalls passiert folgendes:

  • Die produktive Datenbank befindet sich auf dem Server mit der höheren Nodenumber (c-tso-rac02).

    Eviction Regel IIa
     
  • 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 verbleibenden Server c-tso-rac01 neu gestartet.

    Eviction Regel IIa
     
  • 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 erhebliche Wiederanlaufaufwände anfallen.
  • Die vergleichsweise unwichtigen 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 wiederholen. 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 ausgeschlossen und alle drei Datenbanken auf dem Node 1 neu gestartet.

In einem Cluster mit drei oder mehr Servern ist der Ausfall nicht so einfach vorhersehbar. Im ungünstigen 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 ausgeschlossen. Da aber eben genau das nicht vorhersehbar ist, ist man auch hier zumindest statistisch gesehen besser aufgestellt, wenn man die wichtigsten Ressourcen auf dem Server mit der niedrigsten Nodenumber platziert.

Das bis 12.1.0.1 implementierte Verhalten hat einen wesentlichen Vorteil – es ist zu einem großen Teil plan- und vorhersehbar. Insbesondere gilt das für einen 2-Node-Cluster, einer der wahrscheinlich am häufigsten verwendeten Clusterinstallationen, zumindest im Standard Edition-Umfeld.

1.5 Eviction Regel IIb

Diese eben in 1.4 beschriebene,  statische Evictionregel bis Version 12.1.0.1 hat jedoch gleichzeitig den Nachteil, dass sie keine Rücksicht auf die Anzahl der von den jeweiligen Servern bereitgestellten Ressourcen nimmt. Wie bereits in Kapitel 1.4 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 grundlegend 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 eingeführte Management Database mgmtdb, also Ressourcen vom Typ ora.database.type, ora.service.type und ora.mgmtdb.type. Failover-Datenbanken oder andere selbstdefinierte 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 Sie einen reinen Failover-Cluster betreiben – also nicht auch noch RAC-Datenbanken vertreten sind – dann wird bei der Zählung der entscheidungsrelevanten Ressourcen also zwangsläufig nur die mgmtdb berücksichtigt. 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.

Eviction Regel IIb

Um die Management Database (mgmtdb) auf den Clusternode mit der niedrigsten Nodenumber zu verschieben, setzen Sie 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öchten Sie Ihre produktive(n) Datenbank(en) auf den selben Server wie die mgmtdb verschieben, tun Sie das mit:

crsctl 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 entsprechenden 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 Sie die betreffende Datenbank nicht verschieben können, weil Ihnen kein Wartungsfenster zur Verfügung steht, könnten Sie 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 lassen Sie natürlich die mgmtdb  nie auf dem Standby Server laufen. Der Standby Server sollte auch mit Clusterware 12.1.0.2 derjenige mit der höchsten Nodenumber sein.

2 Fazit

Der Einsatz der Oracle Clusterware ist ein wichtiger Bestandteil einer zuverlässigen Hochverfügbarkeitslösung. Gleichzeitig handelt es sich dabei aber um ein komplexes Produkt, das insbesondere 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ücksichtigt 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 und
  • ab Clusterware 12.1.0.2 auf dem selben Node wie die Management Database (mgmtdb) platziert sind. 
  • Bei Clustern mit mehr als zwei Servern ist es zudem anzuraten, die mgmtdb auf dem Node mit der niedrigsten Nodenumber zu platzieren.