{"id":21436,"date":"2022-07-20T11:30:00","date_gmt":"2022-07-20T09:30:00","guid":{"rendered":"https:\/\/www.sysbus.eu\/?p=21436"},"modified":"2022-07-21T09:42:46","modified_gmt":"2022-07-21T07:42:46","slug":"hochverfuegbarkeit-bei-geschaeftskritischen-datenbanken","status":"publish","type":"post","link":"https:\/\/www.sysbus.eu\/?p=21436","title":{"rendered":"Hochverf\u00fcgbarkeit bei gesch\u00e4ftskritischen Datenbanken"},"content":{"rendered":"\n

Autor\/Redakteur: Stefan Schmit, Senior Solution Engineer EMEA bei MariaDB<\/a>\/gg<\/p>\n\n\n\n

Hochverf\u00fcgbare, leicht skalierbare und weltweit verteilte Datenbanken sind die Voraussetzung f\u00fcr globale, gesch\u00e4ftskritische Prozesse. Die technische Grundlage daf\u00fcr sind Datenbank-Cluster, die eine enorme Ausfallsicherheit bieten.<\/p>\n\n\n\n

\"\"<\/a>
Bild: MariaDB<\/figcaption><\/figure>\n\n\n\n\n\n\n\n

Daten und Datenbanken geh\u00f6ren zu den \u00fcberlebens notwendigen IT-Technologien f\u00fcr ein Unternehmen. Sie werden in jedem Fachbereich eingesetzt, alle Unternehmensfunktionen h\u00e4ngen davon ab. St\u00f6rungen und Ausf\u00e4lle summieren sich rasch zu hohen Kosten durch Umsatzverluste, Verlust von Kundenvertrauen und den Aufwand f\u00fcr die Schadensbehebung. Um dies zu vermeiden, m\u00fcssen Datenbanksysteme 24 Stunden am Tag, 7 Tage die Woche, 365 Tage im Jahr verf\u00fcgbar sein, von jedem Ort der Welt aus. Diese Rund-um-die-Uhr-Ausfallsicherheit wird als Hochverf\u00fcgbarkeit oder High Availability (HA) bezeichnet.<\/p>\n\n\n\n

Das Rezept f\u00fcr Hochverf\u00fcgbarkeit: Redundanz<\/strong><\/p>\n\n\n\n

In der Praxis ist eine 100-prozentige Verf\u00fcgbarkeit schwer zu erreichen. Denn je h\u00f6her die Ausfallsicherheit, desto gr\u00f6\u00dfer der Aufwand f\u00fcr die IT-Teams. Deshalb hat sich im IT-Servicemanagement bei Rechenzentren oder Cloud-Anbietern die Angabe einer Prozentzahl f\u00fcr die Verf\u00fcgbarkeit der Systeme etabliert. Sie beschreibt die Dauer, die ein System st\u00f6rungsfrei arbeitet, bezogen auf einen Zeitraum. Eine Verf\u00fcgbarkeit von 99,999 Prozent Ausfallsicherheit gilt als Hochverf\u00fcgbarkeit, da hier die Ausfallsicherheit extrem hoch ist und es bezogen auf ein Jahr ungef\u00e4hr f\u00fcnf Minuten Stillstand ergibt. Sie liegt aber oberhalb der Verf\u00fcgbarkeitslevel, die zum Beispiel die meisten Cloud-Anbieter grunds\u00e4tzlich anbieten.<\/p>\n\n\n\n

IT-Systeme mit dieser Eigenschaft arbeiten trotz des Ausfalls einer Komponente wie einer Festplatte weitgehend ungest\u00f6rt weiter. Erreicht wird das durch Redundanz: Jede Ressource ist mehrfach vorhanden. Ausfallzeiten durch St\u00f6rungen sind damit praktisch ausgeschlossen. Das Problem bei der Erreichung einer sehr hohen Ausfallsicherheit ist allerdings die sogenannte singul\u00e4re Fehlerquelle. Damit ist eine Ressource gemeint, die nicht redundant ausgelegt ist und deren Ausfall das Gesamtsystem zum Stillstand bringt. Hochverf\u00fcgbare Datenbanken m\u00fcssen also durch redundante Instanzen vermeiden, dass zum Beispiel ein defekter Datentr\u00e4ger (HDD oder SSD) die gesamte Anwendung blockiert. Das Grundprinzip der Hochverf\u00fcgbarkeit bei Datenbanken ist deshalb die mehrfache Speicherung derselben Daten, etwa durch Spiegelung auf zwei oder mehr Datentr\u00e4gern oder virtuellen Servern.<\/p>\n\n\n\n

Replikation der Datenbanken sch\u00fctzt vor Datenverlusten<\/strong><\/p>\n\n\n\n

Ein oft f\u00fcr Datenbank-Redundanz genutzter Ansatz ist die Primary\/Secondary-Replikation: Dabei erzeugt ein Datenbank-Proxy eine transparente Abstraktionsschicht zwischen der Anwendung und den Datenbanken. Aus Sicht der Anwendung und damit der Entwickler und Endanwender wirkt der Proxy wie eine normale Datenbankinstanz. Er ist jedoch ein Management-Dienst, hinter dem ein prim\u00e4rer Datenbank-Server (Primary) mit einer oder mehreren identischen Kopien oder Replikaten steht. Der Proxy automatisiert die Verteilung der einzelnen Schreib-\/Lese- Transaktionen auf Primary (Schreib-\/Lese-Zugriff) und Secondary (Lese-Zugriff). Ebenso automatisch gelingt der Switchover bei geplanten Wartungen an einer Instanz und der Failover beim Ausfall des Primarys.<\/p>\n\n\n\n

Dieser Ansatz ist eher f\u00fcr kleinere Unternehmen geeignet. Der deutsche Mittelstand im Maschinen- und Anlagenbau oder in der Elektroindustrie besitzt jedoch oft weltweit verteilte Niederlassungen. Hier entstehen bei einem zentralen Primary am deutschen Heimatstandort f\u00fcr die Au\u00dfenstellen erhebliche Latenzen bei Abfragen und dem Datenaustausch zwischen Primary und Secondary. Auch das Failover ist f\u00fcr moderne Anforderungen beispielsweise im E-Commerce oft zu langsam. Hier muss ein Kompromiss aus Latenz und Datenaktualit\u00e4t gefunden werden, zum Beispiel durch asynchrone Replikation zwischen Datenbanken.<\/p>\n\n\n\n\n\n\n\n

Hochverf\u00fcgbarkeit beginnt bei drei Datenbankinstanzen<\/strong><\/p>\n\n\n\n

Dabei eignen sich hochverf\u00fcgbare Datenbank-Cluster auch f\u00fcr kleinere Installationen, denn der kleinste m\u00f6gliche Cluster besteht aus drei Knoten sowie einem zus\u00e4tzlichen Server f\u00fcr den Datenbank-Proxy als Clustermanager und Backend f\u00fcr Anwendungen. Die Anzahl der Datenbankinstanzen sollte immer ungerade sein. Bei einem Ausfall muss die Mehrheit der aktiven Knoten verf\u00fcgbar sein, damit der Datenbank-Proxy einen Datenbestand f\u00fcr die Replikation ausw\u00e4hlen kann. Bei drei Knoten darf also nur ein Knoten ausfallen, ohne dass es zu Problemen kommt. Dies gilt auch f\u00fcr vier Knoten: Die Mehrheit ist drei Knoten, es darf also ebenfalls nur ein Knoten ausfallen. Diese beiden Cluster-Konfigurationen haben deshalb die gleiche Fehlertoleranz. Das Hinzuf\u00fcgen eines einzelnen Knotens bringt hier keine h\u00f6here Verf\u00fcgbarkeit.<\/p>\n\n\n\n

Die Verf\u00fcgbarkeit gilt f\u00fcr kleine Cluster mit nur drei Knoten ebenso wie f\u00fcr Installationen mit hunderten oder sogar tausenden von Knoten. Gro\u00dfe Cluster sind in der Lage, Millionen von Abfragen pro Sekunde zu verarbeiten, ohne dass die Datenintegrit\u00e4t oder die Verf\u00fcgbarkeit beeintr\u00e4chtigt wird. Dies gilt besonders f\u00fcr Cloud-Datenbanken (DBaaS, Database as a Service). DBaaS in der Cloud unterst\u00fctzt Funktionen wie Selbstheilung und automatisches Failover. Diese Automatismen des Datenbankanbieters und der Cloud Provider sind zu blitzschnellen Reaktionen In der Lage. Dadurch steigt die Verf\u00fcgbarkeit, da sich die IT-Teams der nutzenden Unternehmen nicht um die Behandlung von St\u00f6rungen k\u00fcmmern m\u00fcssen. So sind Datenbank-Cluster im eigenen Rechenzentrum oder hochverf\u00fcgbare Cloud-Datenbanken die ideale L\u00f6sung f\u00fcr alle Unternehmen, die eine kontinuierliche Hochverf\u00fcgbarkeit ihrer Datenbanken ben\u00f6tigen.<\/p>\n\n\n\n

Verteilte SQL-Datenbanken mit Shared-Nothing-Architektur<\/strong><\/p>\n\n\n\n

Verteilte SQL- Datenbanken sind eine relationale Datenbankarchitektur, bei der mehrere Instanzen (Knoten) des Datenbanksystems in einem Multi-Primary-Cluster gleichzeitig und unabh\u00e4ngig voneinander arbeiten. Sie k\u00f6nnen sich in einem oder in mehreren Rechenzentren befinden. Dabei sind sowohl physische wie auch virtuelle Server m\u00f6glich oder spezielle Cloud-Instanzen in einem Plattformangebot. Der Abstand zwischen den Rechenzentren beeinflusst allerdings die Latenz und damit die Performanz im Cluster, weshalb sie nicht zu weit voneinander entfernt sein sollten. In jedem Fall gilt: Das System synchronisiert die Datenbankinhalte und sorgt f\u00fcr einen Lastausgleich bei Transaktionen.<\/p>\n\n\n\n

Dadurch wird ein einzelner Knoten nicht zu einem Engpass, hohe Leistung und Verf\u00fcgbarkeit sind die Folge. Cluster sind in der Lage, eine enorme Menge an Transaktionen pro Sekunde zu verarbeiten, ohne dass die Datenintegrit\u00e4t oder die kontinuierliche Hochverf\u00fcgbarkeit beeintr\u00e4chtigt werden. Ein weiterer Vorteil: Cluster sind leicht skalierbar, bei Bedarf k\u00f6nnen beliebig viele Knoten hinzugef\u00fcgt oder entfernt werden. Und mit jedem zus\u00e4tzlichen Knoten w\u00e4chst auch der verf\u00fcgbare Datenbankspeicher, da die Daten \u00fcber mehr Knoten verteilt werden k\u00f6nnen.<\/p>\n\n\n\n

Verteilte SQL-Datenbanken nutzen eine sogenannte Shared-Nothing-Architektur, in der die einzelnen Knoten unabh\u00e4ngig voneinander arbeiten. Somit hat der Ausfall eines Knotens keine Auswirkung auf die anderen, die alle Lese- und Schreibzugriffe wie gewohnt weiterbearbeiten. Um aber auch die Daten weiterhin verf\u00fcgbar zu halten, werden die Daten eines Knoten auf ein oder mehrere andere Knoten verteilt. Das System erkennt automatisch den Ausfall und stellt dann die Replikate auf anderen Knoten zur weiteren Bearbeitung bereit. Sobald der ausgefallene Knoten wieder verf\u00fcgbar ist, sorgt die Datenbank automatisch daf\u00fcr, dass \u00c4nderungen an den Daten auf allen Systemen synchronisiert werden. Durch diese Redundanz ist die Ausfallsicherheit deutlich gr\u00f6\u00dfer als bei anderen Datenbankarchitekturen.<\/p>\n\n\n\n

\u00dcberregionale Replikationen zwischen Multi-Primary-Clustern lassen sich durch zus\u00e4tzlich parallelisierte Replikationsmechanismen ebenfalls hinzuf\u00fcgen, auch mit verschiedenen Topologien (Aktiv\/Passiv, Aktiv\/Aktiv, \u201cDaisy Chain\u201d Replikation). Dadurch ist ein globaler Datenaustausch zwischen einzelnen Clustern m\u00f6glich.<\/p>\n","protected":false},"excerpt":{"rendered":"

Hochverf\u00fcgbare, leicht skalierbare und weltweit verteilte Datenbanken sind die Voraussetzung f\u00fcr globale, gesch\u00e4ftskritische Prozesse. Die technische Grundlage daf\u00fcr sind Datenbank-Cluster, die eine enorme Ausfallsicherheit bieten.<\/p>\n","protected":false},"author":81,"featured_media":21438,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[8,17],"tags":[6257,2540,1857,13593,12117],"class_list":["post-21436","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-artikel","category-storage","tag-cloud","tag-cluster","tag-datenbank","tag-dbaas","tag-mariadb"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/21436","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/users\/81"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=21436"}],"version-history":[{"count":2,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/21436\/revisions"}],"predecessor-version":[{"id":21543,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/21436\/revisions\/21543"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/media\/21438"}],"wp:attachment":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=21436"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=21436"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=21436"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}