Cluster / Failover / Failsafe · ASPICON Newsarchiv

Oracle Clusterware modifiziert Rebootverhalten ab Version 19.13

Thilo Solbrig, Oracle Certified Master — Thu, 06 Jan 2022 15:28:19 +0000

Home → Cluster / Failover / Failsafe

Oracle Clusterware modifiziert Rebootverhalten ab Version 19.13

Verfasst von Thilo Solbrig, Oracle Certified Master
06 Januar 2022
16:28
Cluster / Failover / Failsafe, DBA Tipp, Oracle Database, Oracle Datenbank 12c /18c /19c /21c

Diverse Ereignisse im Cluster (u.a. Ausfall des Interconnects, Crash des ocssd-Prozesses) führen zu einer Node Eviction, die wiederum mit einem Reboot der betroffenen Server einhergehen kann. Wenn der Reboot die Ursache der Eviction behebt, gliedern sich die Server anschließend wieder selbständig in den Cluster ein. Dazu müssen seit Patchlevel 19.13 weitere Vorkehrungen im Betriebssystem getroffen werden.

Freeze vs. Reboot

Mit Patchlevel 19.13.0.0.211019 (Release Update 10/2021) haben wir festgestellt, dass ein betroffener Node einfriert statt zu rebooten. Die Folge davon wäre, dass sich die betroffenen Server nicht wieder selbständig in den Cluster integrieren, sondern per Remote Management Interface oder vor Ort im Serverraum manuell neu gestartet werden müssen.

Die nötige Erklärung liefert die My Oracle Support Doc ID 2821641.1:
„We enabled kernel crash dump in 19.13 for some specific scenarios. Hence CSSD agent uses ‘echo c’ instead of ‘echo b’. If the kdump is not configured, the system will appear hung and will not reboot because default “kernel.panic” parameter is set to 0.“

Daraus folgt, dass ein Clusterserver ab Patchlevel 19.13 mit aktivem kdump laufen und/oder den Kernelparameter kernel.panic=1 gesetzt haben muss.

Folgender shell-Befehl muss mindestens für eine der Komponenten „kdump“ oder „kernel.panic“ mit „ist aktiv“ antworten. Dann ist auch mit Patchlevel 19.13 oder höher ein korrektes Rebootverhalten bei einer Node Eviction gegeben:

((systemctl is-active kdump &>/dev/null && echo "kdump ist aktiv") || echo "kdump ist nicht aktiv") && (([ $(sysctl -n kernel.panic) -eq 1 ] && echo "kernel.panic ist aktiv" ) || echo "kernel.panic ist nicht aktiv")

Beispiel eines betroffenen Systems:

# ((systemctl is-active kdump &>/dev/null && echo "kdump ist aktiv") || echo "kdump ist nicht aktiv") && (([ $(sysctl -n kernel.panic) -eq 1 ] && echo "kernel.panic ist aktiv" ) || echo "kernel.panic ist nicht aktiv")
kdump ist nicht aktiv
kernel.panic ist nicht aktiv

Beispiel eines NICHT betroffenen Systems:

# ((systemctl is-active kdump &>/dev/null && echo "kdump ist aktiv") || echo "kdump ist nicht aktiv") && (([ $(sysctl -n kernel.panic) -eq 1 ] && echo "kernel.panic ist aktiv" ) || echo "kernel.panic ist nicht aktiv")
kdump ist nicht aktiv
kernel.panic ist aktiv

Fazit

Um ein sauberes Rebootverhalten auch mit Grid Infrastructure 19.13 und höher sicherzustellen, ist es dringend empfohlen, den erwähnten Test auszuführen und bei Bedarf die Betriebssystemkonfiguration entsprechend anzupassen. Nur so ist auch bei einer vorübergehenden Störung im Clusterbetrieb, die zu einer Node Eviction führt, ein stabiler Clusterbetrieb ohne manuellen Eingriff sichergestellt.

Hier findest du weitere Posts zu den Themen SQL Tuning bzw. Performance Tuning aus unserem News Bereich.

Share this article

Der Beitrag Oracle Clusterware modifiziert Rebootverhalten ab Version 19.13 erschien zuerst auf ASPICON.

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

Thilo Solbrig, Oracle Certified Master — Fri, 12 Nov 2021 07:00:33 +0000

Home → Cluster / Failover / Failsafe

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

Verfasst von Thilo Solbrig, Oracle Certified Master
12 November 2021
08:00
Cluster / Failover / Failsafe, Datenbank, DBA Tipp, Oracle Database, Oracle Standard Edition /One /Two

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 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ä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 eine Kommunikation zwischen allen Clusterservern nicht 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 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 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.

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.

Auswirkungen auf Failover-Datenbanken – oder allgemein – Failover Ressourcen

Anders sieht es hingegen bei Failover Ressourcen 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. 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 vier Fälle unterscheiden, je nachdem, welche Version der Clusterware installiert 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 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. Solltet ihr also einen Cluster aus heterogen ausgestatteten Servern aufbauen, solltet ihr 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 Standbyserver 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)

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.

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.

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 gleichzeitig den Nachteil, dass sie keine Rücksicht auf die Anzahl der von den jeweiligen Servern bereitgestellten 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 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 ihr einen reinen Failover-Cluster betreibt – 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.

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 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 du die betreffende 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 beibehalten, aber die mgmtdb wird nun nicht mehr berücksichtigt. Damit ist die mgmtdb nicht mehr als Token für die Festlegung des präferierten 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 <> 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 selbstdefinierten Failoverressourcen dem Namensschema db. folgen, hat die quorum-Datenbank als „echte“ Clusterdatenbank das Namensschema ora..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 – eingeführt. Die Anzahl von Ressourcen, die dieses Flag auf yes gesetzt haben, fließt ebenfalls in die Gewichtung des jeweiligen Servers ein. Allerdings wurde dieses Flag nach unserer Erfahrung an selbstdefinierten Clusterressourcen nicht berücksichtigt. Eine Lösung hierfür konnte auch vom Oracle Support nicht bereitgestellt werden.

5. Eviction ab Clusterware und Datenbank 19.7 steuern

Mit Release Update 19.7 wurde das Konzept „Standard Edition High Availability“1 eingeführt. In seiner Wirkungsweise unterscheidet es sich nicht wesentlich von den bereits oben beschriebenen Failover-Datenbanken auf Basis selbstdefinierter Clusterressourcen. Drei wesentliche Verbesserungen gehen damit dennoch einher:

Die Failover-Datenbank wird jetzt vollumfänglich von Oracle unterstützt. Der Support für selbstdefinierte 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 selbstdefinierten Clusterressourcen – berücksichtigt. Damit ist eine Unterscheidung wichtiger von unwichtigen Datenbanken möglich und die Eviction basiert nicht mehr (nur) auf reiner zahlenmäß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

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,
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 selbsterstellte 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.

Share this article

Der Beitrag Hochverfügbarkeit hochverfügbar – das richtige Placement zum Überleben einer Node Eviction erschien zuerst auf ASPICON.

PostgreSQL Cluster verwalten

Michael Decker — Thu, 12 Nov 2020 12:07:00 +0000

Home → Cluster / Failover / Failsafe

PostgreSQL Cluster verwalten

Verfasst von Michael Decker
12 November 2020
13:07
Cluster / Failover / Failsafe, Datenbank, DBA Tipp, PostgreSQL, Praxistipp, Replikation, repmgr

Intro

Im Jahre 1996 wurde ein DBMS-Projekt namens “Postgres95” auf den uns heute bekannten Namen “PostgreSQL” getauft. In den folgenden Jahren erhielt PostgreSQL mit jedem neuen Release neben Sicherheitsupdates auch neue Features.

Seit Version 9.0 beherrscht PostgreSQL Streaming Replication und mit dem Release der Version 9.1 dieser Replikation auch synchron. Ab Version 9.2 konnten die Replikationsverbindungen zusätzlich auch kaskadiert werden, was den Aufbau von komplexeren Cluster-Strukturen ermöglicht.

Verwaltung von PostgreSQL Clustern mit repmgr

Selbstverständlich hast du die Möglichkeit, die Verwaltung deiner PostgreSQL Cluster händisch zu erledigen. Aber eine wirklich gute Option ist hier der Einsatz des Tools repmgr. Der repmgr ist ein Werkzeug zum Erstellen und Orchestrieren von PostgreSQL Clustern und kann mit jeder aktuell unterstützten PostgreSQL Version eingesetzt werden.

Mit diesem praktischen Werkzeug können Cluster von beliebiger Größe angelegt und verwaltet werden, inklusive kaskadierter Standby-Instanzen. Zusätzlich können Standby-Instanzen zum Master promoted und die Replikationsverbindungen zwischen einzelnen Instanzen geschwenkt werden. Dabei greift repmgr ausschließlich auf vorhandene Funktionen und Werkzeuge von PostgreSQL zurück.

repmgr unterstützt auch bei der Re-Integration von ehemaligen Master-Instanzen in einen Cluster und dies sogar nach Split-Brain Szenarien – entsprechende PostgreSQL-Konfiguration vorausgesetzt. Ebenso ist es natürlich auch möglich, einzelne Instanzen wieder aus dem Cluster heraus zu lösen.

Neben dem manuellen Switchover ist der automatische Failover ein weiteres nettes Feature, welches den repmgr zu einem vielseitigen Werkzeug macht. Bei Bedarf und als Versicherung gegen Split-Brain Szenarien bei Störung der Netzwerkverbindung zwischen den Instanzen kann eine sogenannte “Witness-Instanz” eingesetzt werden. Diese kann die Failover-Entscheidung bestätigen oder ablehnen.

repmgr greift nur auf die systemd-Services für die PostgreSQL-Instanzen und die jeweilige Master- oder Standby-Konfiguration zu. Dadurch können innerhalb des Clusters die meisten Parameter weiter individuell festgelegt werden. Beispielsweise können verschiedene Replikationsverbindungen innerhalb des selben Clusters synchron und asynchron betrieben werden. Damit behält man auch hier die erforderliche Flexibilität.

Trotz aller Möglichkeiten und der zahlreichen Funktionen die sonst nur große kommerzielle Lösungen bieten, bleibt das Einrichten und Bedienen vergleichsweise einfach. Das macht repmgr (für uns) zum bevorzugten Werkzeug für Master-Standby-Cluster bei PostgreSQL Datenbanken.

Du interessierst dich für andere Artikel rund um dieses Thema? Dann findest du hier weitere Posts rund um PostgreSQL Datenbanken oder auch HA Technologien wie Cluster, Failsafe oder Failover.

Share this article

Der Beitrag PostgreSQL Cluster verwalten erschien zuerst auf ASPICON.

Microsoft SQL Server on VMware – Verfügbarkeit

The hidden DBA — Wed, 11 Nov 2020 07:53:00 +0000

Home → Cluster / Failover / Failsafe

Microsoft SQL Server on VMware – Verfügbarkeit

Verfasst von The hidden DBA
11 November 2020
08:53
AlwaysOn Availability Groups, AlwaysOn Failover Cluster, Cluster / Failover / Failsafe, DBA Tipp, Microsoft, SQL Server, VMware

In diesem Tipp werden Überlegungen zum Betrieb von einem hochverfügbaren Microsoft SQL Server auf einer VMware vSphere Plattform beschrieben.

VMware vSphere ist in vielen Unternehmen der Standard für die Betriebssystem-Virtualisierung. Bei der Konfiguration einer virtuellen Maschine für einen Microsoft SQL Server gibt es allerdings ein paar Dinge zu beachten. Und nicht jede Hochverfügbarkeitslösung vom SQL Server ist auch für VMware vSphere geeignet oder sinnvoll.

Anfangsüberlegungen

Zunächst sollte man die Architektur des aktuellen VMware Clusters und der gewünschten Verfügbarkeit des SQL Servers betrachten.

Was soll mit einer hoch verfügbaren Lösung erreicht werden?

eine maximal Ausfallzeit von 15 Minuten?
ein Patchen der Windows oder Linux Betriebssysteme ohne Ausfall der Instanzen oder Wartungsfenster für die Anwendungen?
Sollen bestimmte Workloads auf weitere, nur lesbare Instanzen ausgelagert werden?
Benötigt man, aus Compliance Gründen, eine Möglichkeit zum Betrieb der Instanz in einem anderen Brandabschnitt oder Rechenzentrum?

Wenn man sich diese Fragen am Anfang stellt, sollte die Entscheidung, welche Lösung am Ende in Frage kommt, leichter zu beantworten sein.

VMware Verfügbarkeit vs. SQL Server Verfügbarkeit

Verfügbarkeit durch VMware Cluster

Wiederherstellungszeit: ca. 5 – 10 Minuten
Installations- und Wartungsaufwand: gering

Wer einen VMware Cluster aus mehreren ESXi Knoten mit einem zentralen SAN oder vSAN betreibt, erhält damit schon eine Verfügbarkeit der virtuellen Maschinen im Falle eines Hardwareausfalls. Falls also einer der Hardware ESXi Knoten ausfällt, wird die virtuelle Maschine auf einem anderen Knoten neu gestartet. Das bedeutet wiederum, dass das komplette Windows System wie nach einem Power Off neu gestartet wird und die Datenbank anschließend auf Integrität vom SQL Server Dienst geprüft wird. Falls zum Zeitpunkt des Ausfalls gerade eine Transaktion ausgeführt wurde, ist diese nicht in der Datenbank. Die Datenbankdateien an sich könnten auch Schaden genommen haben. Eine vernünftige Backup Strategie ist in diesem Fall unabdingbar. Alle Benutzerdatenbanken sollten im vollständigen Wiederherstellungsmodus betrieben werden und Transaktionslog Backups alle 10 – 15 Minuten auf ein externes Laufwerk erfolgen.

Verfügbarkeit durch SQL Server AlwaysOn Failover Cluster

Wiederherstellungszeit: ca. 1 – 5 Minuten
Installations- und Wartungsaufwand: Mittel bis Hoch (Je nach Anzahl der Instanzen)

Eine der ältesten Hochverfügbarkeitstechniken für den Microsoft SQL Server ist der Failover Cluster. Hierbei wird die Datenbankinstanz auf einem zentralen, gemeinsamen Speicher (SAN) betrieben und 2 oder mehr Knoten, stehen dem Cluster zur Verfügung. Dabei ist die Instanz immer auf einem der Knoten gestartet. Fällt einer der Knoten aus, startet der SQL Server Dienst automatisch auf einem anderen, im Cluster verfügbaren Knoten. Da hierbei der Neustart des gesamten Windows Systems entfällt und nur der SQL Server Dienst gestartet werden muss, verringert sich die Wiederherstellungszeit.

Durch die Konfiguration des Failover Clusters erhöht sich allerdings die Komplexität des Setups. Aus VMware Sicht muss vermieden werden, dass die zum Cluster gehörenden Knoten auf dem gleichen ESXi Host betrieben werden. Weiterhin muss ein SAN Speicher an die virtuellen Maschinen angebunden werden, was laut Supportrichtlinien entweder über ein RAW Device oder über einen iSCSI Device im Betriebssystem realisiert werden muss.

Verfügbarkeit durch SQL Server AlwaysOn Availability Groups

Wiederherstellungszeit: ca. 1 – 30 Sekunden
Installations- und Wartungsaufwand: Mittel bis Hoch (je nach Anzahl der Instanzen und Availability Groups)

Eine neuere Verfügbarkeitstechnik (seit dem SQL Server 2012) sind die AlwaysOn Availability Groups. Hierbei werden die Datenbanken zwischen einer oder mehreren Instanzen gespiegelt. d.h. hier wird auf mehreren Servern der Speicherplatz für die Datenbank benötigt, da der jeweils lokale Speicher benutzt wird.
Da die Datenbankkopien jederzeit synchron gehalten werden, ist der Failover innerhalb weniger Sekunden erledigt. Zu Grunde liegt hier ebenfalls ein Windows Server Failover Cluster, der allerdings nur die IP Adresse für den Datenbanklistener zwischen den Knoten verschiebt.

Durch die Synchronisierung entsteht allerdings zusätzlicher Netzwerktraffic und der Speicher für die doppelte Datenhaltung.

Fazit

Wer eine nur moderate Verfügbarkeit benötigt, sollte auf die zusätzliche Komplexität mit einem Failover Cluster oder Availability Groups verzichten und die Verfügbarkeit durch den VMware Cluster bereitstellen.

Share this article

Der Beitrag Microsoft SQL Server on VMware – Verfügbarkeit erschien zuerst auf ASPICON.