Seite wählen

NETWAYS Blog

Hochverfügbarkeit bei Datenbanken, wofür ist das gut?

Hallo, ich bin Valeria, Junior-Developerin bei NETWAYS und habe mich lange damit beschäftigt, über welches Thema ich in meinem nächsten Blogpost schreiben soll. Vor Kurzem habe ich an einer MySQL-Schulung von NETWAYS teilgenommen und mich anschließend mit dem Thema der Hochverfügbarkeit bei Datenbanken in einem Projekt auseinandergesetzt. Da ich das Thema sehr interessant fand, möchte ich nun mein Wissen gerne mit Euch teilen.

  • Was bedeutet Hochverfügbarkeit?
  • Warum ist es so wichtig, Daten permanent abrufen zu können?
  • Wie kann man Hochverfügbarkeit gewährleisten?
  • Welche Varianten gibt es?
  • Fazit

 

Was bedeutet Hochverfügbarkeit?

In einer Welt, in der Daten für Unternehmen immer wichtiger werden, ist es entscheidend, dass diese Daten immer verfügbar sind. Abhilfe schafft hier Hochverfügbarkeit oder auch HADR (High Availability and Disaster Recovery). Datenbanken sind demnach so eingerichtet, dass sie selbst bei einem Ausfall eines Servers oder einer anderen kritischen Komponente, unabhängig von äußeren Einflüssen wie Hardwareausfällen, Netzwerkausfällen oder Stromausfällen, weiterhin verfügbar sind.

 

Warum ist es so wichtig, Daten permanent abrufen zu können?

Es gibt einige Bereiche, in denen Hochverfügbarkeit von Daten nicht mehr wegzudenken ist. Stell Dir vor, Du betreibst eine große E-Commerce-Plattform, welche für ein paar Stunden nicht abrufbar ist. Was passiert?

Der fehlende Zugriff auf Unternehmensdaten kann einen massiven Umsatzverlust bedeuten. Wenn ein Kunde nicht auf seine Kundendaten zugreifen kann, kann er keine Bestellungen aufgeben, wodurch potenzielle Einnahmen verloren gehen.

Dies führt in der Regel auch zu einer sinkenden Kundenzufriedenheit und/oder möglicherweise sogar zu Kundenverlusten. Wenn ein Unternehmen nicht in der Lage ist, seinen Kunden einen effektiven und reibungslosen Service zu bieten, wird er es schwer haben, neue Kunden zu gewinnen.

Wenn ein Kunde die Webseite nicht aufrufen kann, wird er sich mit großer Wahrscheinlichkeit auf die Suche nach einer anderen Webseite machen, was die Chance diesen Kunden zu gewinnen zunichte macht.

In diesem Beispiel ging es „nur“ um Verluste, die mit einer Minderung des Umsatzes einhergehen. Doch wie sieht es in anderen Bereichen aus?

Wenn Datenbanken im Bereich autonomer Fahrzeuge ausfallen, kann dies schwerwiegende Konsequenzen haben. Zum Beispiel kann es dazu führen, dass die autonomen Fahrzeuge nicht mehr in der Lage sind, ihre Umgebung korrekt wahrzunehmen und somit Unfälle oder andere sicherheitsrelevante Vorfälle verursachen.

Auch könnten wichtige Informationen wie Verkehrsdaten, Wetterinformationen oder Straßenbedingungen nicht mehr verfügbar sein, was die Sicherheit und Zuverlässigkeit der autonomen Fahrzeuge beeinträchtigen würde. Zudem könnten Service- und Wartungsprozesse beeinträchtigt werden, was zu Verzögerungen oder Ausfällen führen könnte.

Auch im Gesundheitswesen, Flugverkehr, Energieversorgung, Finanzdienstleistungen, Sicherheitsbehörden ect. spielt Hochverfügbarkeit eine große Rolle.

 

Wie kann man Hochverfügbarkeit gewährleisten?

  1. Vermeidung eines Single Point of Failure (SPoF). Dies beschreibt eine Komponente in einem System, bei deren Ausfall das gesamte System ausfallen würde. Ein Beispiel hierfür wäre ein Server, auf dem eine Anwendung läuft. Wenn dieser Server ausfällt, ist die Anwendung nicht mehr verfügbar.
  2. Redundanz integrieren. Dadurch wird sichergestellt, dass eine Backup-Komponente einspringen kann, falls eine Komponente ausfällt. Es ist dabei wichtig, dass ein zuverlässiges Crossover oder Failover gewährleistet ist, um einen Wechsel von der ausgefallenen Komponente zur Backup-Komponente ohne Datenverlust oder Leistungseinbußen zu ermöglichen.
  3. Monitoring. Um die Erkennbarkeit von Ausfällen zu gewährleisten, sollten Systeme über Mechanismen verfügen, um Fehler automatisch zu erkennen und zu beheben. Es sollten auch eingebaute Mechanismen zur Vermeidung von Fehlern mit gemeinsamer Ursache vorhanden sein, bei denen mehrere Komponenten gleichzeitig ausfallen können. Dadurch kann sichergestellt werden, dass Ausfälle schnell erkannt und behoben werden können, um eine schnelle Wiederherstellung des Systems zu gewährleisten.

 

Welche Varianten für Hochverfügbarkeitslösungen bei Datenbanken gibt es?

Ein häufig verwendetes Konzept ist die Verwendung von Redundanz und Replikation. Dabei werden die Daten auf mehreren Servern repliziert. Im Falle eines Serverausfalls kann ein anderer Server sofort einspringen und die Daten bereitstellen.

Es gibt zwei Arten von Replikationen: Master-Slave- und Multi-Master-Replikationen.

Bei einer Master-Slave-Replikation wird der Master-Server als Hauptserver betrachtet welcher alle Zugriffsverhältnisse beherrscht. Der Slave-Server stellt nur Lese-Zugriff zur Verfügung. Das bedeutet, dass die Suchlast auf den Slave-Servern verteilt werden kann.

Kommt es jedoch zu einem Ausfall des Master-Servers, kann dies zu einer Unterbrechung des Schreibzugriffs führen, da kein Knoten als neuer Masterknoten fungieren kann, bis der ursprüngliche Masterknoten wieder verfügbar ist. Infolgedessen ist der Masterknoten ein Single Point of Failure, der das gesamte System beeinträchtigen kann.

Bei einer Master-Slave-Kombination sollte insbesondere sichergestellt werden, das der Master-Server die indizierende Datenmenge auch bewältigen kann. Wenn große Datenmengen zu indizieren sind, empfiehlt es sich dann die Indizes aufzuteilen und mehrere Master-Server einzusetzen.

Bei einer Multi-Master-Replikation sind alle Server gleichwertig und replizieren Daten untereinander. Wenn ein Server ausfällt, übernehmen die verbleibenden Server seine Aufgaben. Doch hier wird es kniffelig. Wenn alle Server gleiches Stimmrecht haben, was passiert wenn mehrere Server an der selben Datei zeitgleich eine Änderung vornehmen?

Es kann zu einem „Split-Brain“ kommen. Jeder Knoten glaubt, dass er der Hauptknoten ist, was zu Inkonsistenzen und Datenverlust führen kann. Diese müssen manuell aufgelöst werden, bevor die Änderungen an alle Knoten weitergeleitet werden und sich der Cluster abschaltet.

Um dies zu vermeiden wird immer eine ungerade Anzahl an Knoten empfohlen, damit ein Quorum (eine Mehrheit der verfügbaren Knoten) bestimmt werden kann. Wenn beispielsweise ein Cluster aus fünf Knoten besteht, würde das Quorum aus mindestens drei Knoten bestehen. Wenn das Quorum unterschritten wird, kann es zu einem Ausfall des Clusters kommen.

Ein Quorum stellt somit sicher, dass immer eine ausreichende Anzahl von Knoten verfügbar ist, um eine Abstimmung über Datenänderungen durchzuführen.

Zudem sind Multi-Master-Systeme in der Regel etwas komplexer als Master-Slave-Systeme und erfordern mehr Konfiguration und Wartung, was zu höheren Betriebskosten führen kann.

Welche der Varianten genutzt wird, hängt letztendlich von den spezifischen Anforderungen und Bedürfnissen des Datenbanksystems ab. Wenn die Anwendung eine hohe Schreiblast aufweist und eine hohe Verfügbarkeit erfordert, kann eine Multi-Master-Replikation bevorzugt werden, da sie eine effiziente Lastverteilung und eine schnelle Wiederherstellung nach einem Ausfall ermöglicht. Wenn jedoch die Schreiblast nicht so hoch ist und die Konsistenz der Daten wichtiger ist als die Verfügbarkeit, kann eine Master-Slave-Replikation bevorzugt werden, da sie eine strengere Konsistenz der Daten gewährleistet.

Fazit:

Die Bedeutung von Hochverfügbarkeit nimmt in der heutigen Zeit immer mehr zu, da die Abhängigkeit von Daten und Systemen in allen Bereichen des Lebens und der Wirtschaft zunimmt. Unternehmen müssen in der Lage sein, ihre Daten und Anwendungen rund um die Uhr zu nutzen, um wettbewerbsfähig zu bleiben und Kundenbedürfnisse zu erfüllen. Dies gilt nicht nur für große Unternehmen, sondern auch für kleine und mittelständische Unternehmen, die auf stabile und verlässliche IT-Infrastrukturen angewiesen sind. Zudem wird die Verfügbarkeit von Daten auch in immer mehr Bereichen des täglichen Lebens wichtiger, beispielsweise im Gesundheitswesen oder in der öffentlichen Verwaltung.

Valeria Thiele
Valeria Thiele
Junior Developer

Valeria unterstützt seit September 2022 das NETWAYS Managed Services Team. Als Auszubildende Fachinformatikerin für Anwendungsentwicklung packt sie stets der Ehrgeiz, etwas zu programmieren. Sie ist aber auch sehr gespannt und neugierig, was sie in ihrer Ausbildung noch alles erwarten wird. In ihrer Freizeit findet man sie nahezu überall: auf dem Bike in den Bergen, am Piano spielend, nächtelang Zocken oder Netflixen, auf Wanderwegen, in Museen interessante Dinge entdecken oder auf dem Wasser im Kajak. Sie ist einfach immer wieder auf der Suche nach neuen Entdeckungen und Abenteuern, digital wie analog, offline wie auch online.

Icinga als Buch zum dritten

Am kommenden Montag, den 27. Juni erscheint unser dritter Aufguss des Themas Icinga in Buchform. Neben der obligatorischen Aktualisierung, gibt es mit Icinga for Windows, das die bisherigen Abschnitte zur Überwachung von Windows ersetzt, auch weitere komplett neugestaltete Kapitel. Hochverfügbarkeit ist so eines. Es enthält nun einzeln ausgearbeitet Betrachtungen und Lösungsvorschläge zur Erhöhung der Verfügbarkeit aller beteiligten Software-Komponenten.

Die Erweiterung von Icinga Web 2 über Module wurde deutlich ausgebaut und umfasst nun auch Reporting sowie VSpherDB. Auch das Kapitel um den Director wurde ausgebaut und enthält nun einige praktische Beispiele zum Aufbau der Struktur, aber auch praktische Beispiele aus dem Bereich automatisierter Import.

Neben diesen Neuerungen haben sich jedoch auch bei den anderen Themen wie Plugins, Icinga DSL, Graphing, Tuning und Sicherheit Erweiterungen eingeschlichen. Das Buch erscheint als im Hardcover gebundene Ausgabe und in elektronischer Form im dpunkt Verlag und ist absofort bestellbar.

Alle im Buch verwendeten Codebeispiel liegen auf GitHub zum Download bereit.

Auch wenn ein Buch nichts für euch sein sollte, ist aus diesem Buchprojekt vielleicht doch was für euch interessantes entstanden: der Icinga-Installer.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Schulung Clusterbau mit Pacemaker

images
Ich bin dabei eine neue Schulung vorzubereiten, Clusterbau mit Pacemaker. Die Schulung wird einen Umfang von zwei oder drei Tagen haben. Sie ist soweit fertig und bietet im groben, folgende Gliederung:

  • Grundlagen
  • Installation
  • Aufbau eines Active/Passive-Clusters
  • Hinzufügen weiterer Services
  • Active/Active Cluster
  • Storage-Replikation mit DRBD
  • Fencing

Die bisher berücksichtigten Dienste sind neben einer IP-Adresse, der Apache-Webserver, MySQL und DRBD. Natürlich existiert auch schon ein Abschnitt über Icinga, ob der es allerdings in die Endfassung schafft steht noch nicht fest. Für Vorschläge bin ich allerdings offen und hoffe von euch einige per Kommentar zu erhalten.
Auch für den Fall, dass jemandem noch interessante angrenzende Themen zu Pacemaker hat, was beim Clusterbau sonst noch interessant sein könnte, einfach als Kommentar zu diesem Blockpost.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Ja is denn schon Weihnachten? Oder wie mache ich Icinga hochverfügbar!

Wer Icinga in einer Pacemaker-Cluster-Umgebung betreiben möchte, benötigt Resource Agents. Hiermit poste ich OCF-konforme Vorschläge für icinga und ido2db.
Beide Skripte sind ähnlich aufgebaut. Die PID ist in einer Datei hinterlegt. Diese wird mit der ermittelten PID aus der Prozessliste (pgrep) und vom Commandfile bei icinga bzw. dem Socket bei ido2db verglichen. Liefern beide Vergleiche ein Wahr zurück, ist alles in Ordnung und ein Auruf mit monitor liefert ein OCF_SUCCES zurück.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

OpenLDAP: N-Way Master Replication

In diesem Artikel möchte ich kurz beschreiben, wie man aus einem einzelnen OpenLDAP-Server eine hochverfügbare Farm aufbauen kann. Voraussetzung sei hierfür ein eingerichteter Standalone-Server mit dynamischer Konfiguration im LDAP selbst (cn=config) und konfiguriertem LDAPS bzw. SSL auf Port 638. Für die hier exemplarisch verwendeten LDAP-Client-Kommandos muss zusätzlich die IPC-Unixsocket (ldapi) Schnittstelle des Servers aktiviert sein.
Für die Replikation von einem Master auf einen Slave LDAP-Server wird jeweils eine Abstarktionsschicht, Overlay genannt, im jeweiligem Server selbst „eingezogen“. Hierbei wird der Slave im LDAP-Jargon als Consumer und er Master als Provider bezeichnet. Für eine Multi-Master-Umgebung muss also jeder LDAP-Knoten Provider wie auch Consumer sein.
Zuerst machen wir aus unserem Standalone-Server einen Provider. Hierfür soll das nachfolgende Listing als provider.ldif abgespeichert sein.

dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: olcOverlay=syncprov,olcDatabase={1}bdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 0x001 ldaps://kdc01.netways.int
olcServerID: 0x002 ldaps://kdc02.netways.int

Wie dem Listing zu entnehmen ist, haben wir neben der Konfiguration cn=config, bisher lediglich einen weiteren Baum bzw. Datenbank im DBD-Format in unseren LDAP abgelegt. Bei einer weiteren Datenbank, ist ein weiterer ensprechender DN hinzuzufügen. Soll die Farm aus mehr als zwei Servern bestehen müssen ebenfalls weitere ServerIDs angefügt werden. Mit

# ldapmodify -Y EXTERNAL -H ldapi:/// -f provider.ldif

kann nun die Konfiguration erweitert werden. Hier kann man nun auch erahnen, dass jede Datenbank einzeln synchronisiert wird. Das folgende Listing auth.ldif macht dies klarer ersichtlich, da wir hier für jede Datenbank die Authenfizierung anpassen werden.

dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=config

add: olcRootPW
olcRootPW: {SSHA}4KIL4Ob3SLaLqbe/AyMO80KALdBUWj6M

Dieses Listing ist jedoch nur mit

# ldapmodify -Y EXTERNAL -H ldapi:/// -f auth.ldif

hinzuzufügen, wenn in der Datenbank cn=config für den Benutzer cn=config noch kein Passwort gesetzt hat. Bei unserer zweiten Datenbank {1}bdb gehen wir davon aus, dass der RootDN cn=admin,dc=netways,dc=int lautet und ein Passwort gesetzt ist.
Die beiden folgenden Listings consumer_0.ldif und consumer_1.ldif konfigurieren unseren LDAP-Server zusätzlich als Consumer.

dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=ldaps://kdc01.netways.int binddn=“cn=config“ bindmethod=simple credentials=PASSWORD searchbase=“cn=config“ type=refreshAndPersist retry=“5 +“ timeout=1
olcSyncRepl: rid=002 provider=ldaps://kdc02.netways.int binddn=“cn=config“ bindmethod=simple credentials=PASSWORD searchbase=“cn=config“ type=refreshAndPersist retry=“5 +“ timeout=1

add: olcMirrorMode
olcMirrorMode: TRUE

dn: olcDatabase={1}bdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=003 provider=ldaps://kdc01.netways.int binddn=“cn=admin,dc=netways,dc=int“ bindmethod=simple credentials=PASSWORD searchbase=“dc=netways,dc=int“ type=refreshAndPersist interval=00:00:00:10 retry=“5 +“ timeout=1
olcSyncRepl: rid=004 provider=ldaps://kdc02.netways.int binddn=“cn=admin,dc=netways,dc=int“ bindmethod=simple credentials=PASSWORD searchbase=“dc=netways,dc0int“ type=refreshAndPersist interval=00:00:00:10 retry=“5 +“ timeout=1

add: olcMirrorMode
olcMirrorMode: TRUE


# ldapmodify -Y EXTERNAL -H ldapi:/// -f consumer_0.ldif
# ldapmodify -Y EXTERNAL -H ldapi:/// -f consumer_1.ldif

aktivieren den jeweiligen Consumer, der nun via LDAPS und Simple Authentification, die zu synchronisierenden Daten vom jeweilgen Provider ausliest. Um die Performance der Synchronisation zu erhöhen sollte man unbedingt noch jeweils einen Index auf entryUUID und entryCSN setzen.

dn: olcDatabase={1}bdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryUUID eq
olcDIndex: entryCSN eq

Das wars schon. Jetzt beschäftigen wir uns mit dem zweiten Knoten unserer Farm. Dieser wird zunächst wie ein Standalone Server konfiguriert. Zubeachten ist, dass z.B. die Zertifikate unter dem selben Pfad und mit dem selben Namen abzulegen sind, da wir auf beiden Knoten, die selbe Konfiguration verwenden werden. Nachdem wir auf unserem fertig konfigurierten Knoten, die Konfiguration mit

# slapcat -n 0 -l config.ldif

gesichert haben und auf unseren zweiten Knoten kopiert haben, spielen wir diese auf dem neuen Knoten mit

# slapadd -F /etc/openldap/slapd.d -n 0 -l config.ldif

wieder ein und starten den LDAP-Server. Von nun an werden beide Datenbanken repliziert.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.