{"id":92570,"date":"2020-08-28T19:42:21","date_gmt":"2020-08-28T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker"},"modified":"2020-08-28T19:42:21","modified_gmt":"2020-08-28T17:42:21","slug":"modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","title":{"rendered":"Modellierung fehlertoleranter Cluster auf Basis von PostgreSQL und Pacemaker","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Einf\u00fchrung<\/h1>\n

<\/p>\n

Vor einiger Zeit wurde mir die Aufgabe gestellt, ein ausfallsicheres Cluster zu entwickeln f\u00fcr PostgreSQL<\/a><\/noindex>, das in mehreren Rechenzentren innerhalb einer Stadt \u00fcber Glasfasern verbunden ist und in der Lage ist, den Ausfall (zum Beispiel durch Stromausfall) eines Rechenzentrums zu \u00fcberstehen. Als Software, die f\u00fcr die Ausfallsicherheit verantwortlich ist, habe ich mich f\u00fcr entschieden Pacemaker<\/a><\/noindex>, weil dies die offizielle L\u00f6sung von RedHat zur Erstellung ausfallsicherer Cluster ist. Sie hat den Vorteil, dass RedHat Support daf\u00fcr bereitstellt und dass diese L\u00f6sung universell (modular) ist. Mit ihrer Hilfe kann die Ausfallsicherheit nicht nur f\u00fcr PostgreSQL, sondern auch f\u00fcr andere Dienste gew\u00e4hrleistet werden, entweder durch die Verwendung standardm\u00e4\u00dfiger Module oder durch die Erstellung solcher Module f\u00fcr spezifische Bed\u00fcrfnisse.<\/p>\n

<\/p>\n

Zu dieser L\u00f6sung stellte sich die berechtigte Frage: Wie ausfallsicher wird das ausfallsichere Cluster sein? Um dies zu untersuchen, habe ich einen Teststand entwickelt, der verschiedene Ausf\u00e4lle an den Knoten des Clusters simuliert, auf die Wiederherstellung der Betriebsf\u00e4higkeit wartet, den ausgefallenen Knoten wiederherstellt und die Tests im Kreis fortsetzt. Urspr\u00fcnglich wurde dieses Projekt hapgsql genannt, aber im Laufe der Zeit hat mir der Name, der nur einen Vokal enth\u00e4lt, nicht mehr gefallen. Daher begann ich, ausfallsichere Datenbanken (und die auf sie verweisenden float IPs) zu nennen krogan<\/strong> (eine Figur aus einem Computerspiel, bei dem alle wichtigen Organe verdoppelt sind), w\u00e4hrend ich die Knoten, Cluster und das gesamte Projekt als tuchanka<\/strong> (den Planeten, auf dem die Kroganer leben) benannte.<\/p>\n

<\/p>\n

Jetzt hat die F\u00fchrung genehmigt, das Projekt als Open Source unter der MIT-Lizenz zu ver\u00f6ffentlichen.<\/a><\/noindex>Das README wird in K\u00fcrze ins Englische \u00fcbersetzt (da erwartet wird, dass die Hauptnutzer Entwickler von Pacemaker und PostgreSQL sein werden), und die alte russische Version des README habe ich entschieden, (teilweise) in Form dieses Artikels zu gestalten.<\/p>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/a><\/noindex><\/p>\n

Die Cluster werden auf virtuellen Maschinen VirtualBox<\/a><\/noindex>bereitgestellt. Insgesamt werden 12 virtuelle Maschinen bereitgestellt (insgesamt 36GiB), die 4 ausfallsichere Cluster bilden (verschiedene Varianten). Die ersten beiden Cluster bestehen aus zwei PostgreSQL-Servern, die in verschiedenen Rechenzentren untergebracht sind, und einem gemeinsamen Server witness<\/em> c quorum device<\/strong> (untergebracht auf einer g\u00fcnstigen virtuellen Maschine im dritten Rechenzentrum), der die Ungewissheit l\u00f6st 50%\/50%<\/strong>, indem er seine Stimme einer der Parteien gibt. Der dritte Cluster ist in drei Rechenzentren: ein Master, zwei Slaves, ohne quorum device<\/strong>. Der vierte Cluster besteht aus vier PostgreSQL-Servern, zwei in jedem Rechenzentrum: einem Master und den \u00fcbrigen Replikaten, und verwendet ebenfalls witness<\/em> c quorum device<\/strong>. Der vierte Cluster h\u00e4lt den Ausfall von zwei Servern oder eines Rechenzentrums stand. Diese L\u00f6sung kann bei Bedarf auf eine gr\u00f6\u00dfere Anzahl von Replikaten skaliert werden.<\/p>\n

<\/p>\n

Echtzeit-Dienst ntpd<\/a><\/noindex> wurde ebenfalls f\u00fcr Fehlertoleranz umkonfiguriert, verwendet dabei aber die Methode ntpd<\/code> (orphan mode<\/em>). Der Hauptserver witness<\/em> fungiert als zentraler NTP-Server, verteilt seine Zeit an alle Cluster und synchronisiert damit alle Server untereinander. Wenn witness<\/em> ein Server ausf\u00e4llt oder isoliert wird, beginnt einer der Server im Cluster (innerhalb des Clusters) seine Zeit zu verteilen. Ein unterst\u00fctzender zwischenspeichernder HTTP-Proxy<\/strong> wurde ebenfalls aufgestellt, witness<\/em>mit dessen Hilfe die anderen virtuellen Maschinen Zugriff auf die Yum-Repositories haben. In der Realit\u00e4t werden solche Dienste wie Echtzeit und Proxy sicherlich auf dedizierten Servern gehostet, w\u00e4hrend sie im Stand auf witness<\/em> aus wirtschaftlichen Gr\u00fcnden in Virtual Machines platziert sind.<\/p>\n

<\/p>\n

Versionen<\/h1>\n

<\/p>\n

v0. Funktioniert mit CentOS 7 und PostgreSQL 11 auf VirtualBox 6.1.<\/p>\n

<\/p>\n

Clusterstruktur<\/h1>\n

<\/p>\n

Alle Cluster sind daf\u00fcr ausgelegt, in mehreren Rechenzentren untergebracht zu werden, sind in einem flachen Netzwerk verbunden und m\u00fcssen den Ausfall oder die Netzwerkarbeit eines Rechenzentrums \u00fcberstehen. Daher nicht m\u00f6glich ist<\/strong> verwendet man zur Schutz gegen split-brain<\/strong> die Standardtechnologie Pacemaker, die als STONITH<\/em> (Shoot The Other Node In The Head) oder Fencing<\/em>. Ihr Kern besteht darin, dass, wenn die Knoten im Cluster anfangen, zu vermuten, dass mit einem bestimmten Knoten etwas nicht stimmt, er nicht reagiert oder sich nicht korrekt verh\u00e4lt, sie ihn gezwungen \u00fcber \"externe\" Ger\u00e4te, wie zum Beispiel die IPMI-Steuerkarte oder USV, abschalten. Aber dies funktioniert nur in F\u00e4llen, in denen bei einem einzelnen Ausfall des Servers IPMI oder USV weiter funktionieren. Hier ist jedoch Schutz gegen einen weitaus katastrophalen Ausfall geplant, bei dem das gesamte Rechenzentrum ausf\u00e4llt (zum Beispiel durch Stromausfall). Und bei solch einem Ausfall werden auch alle stonith<\/em>-Ger\u00e4te (IPMI, USV usw.) nicht funktionieren.<\/p>\n

<\/p>\n

Stattdessen basiert das System auf der Idee des Quorums. Alle Knoten haben eine Stimme, und nur die Knoten, die mehr als die H\u00e4lfte aller Knoten sehen, k\u00f6nnen arbeiten. Diese Anzahl \"mehr als die H\u00e4lfte + 1\" wird genannt Quota<\/strong>. Wenn das Quorum nicht erreicht wird, entscheidet der Knoten, dass er sich in Netzwerkkonnotation befindet und seine Ressourcen deaktivieren muss, d.h. es ist so eine Schutz vor Split-Brain<\/strong>. Wenn die Software, die f\u00fcr dieses Verhalten verantwortlich ist, nicht funktioniert, sollte ein Watchdog, zum Beispiel auf Basis von IPMI, aktiv werden.<\/p>\n

<\/p>\n

Wenn die Anzahl der Knoten gerade ist (Cluster in zwei Rechenzentren), kann es zu einer sogenannten Unsicherheit kommen 50%\/50%<\/strong> (fifty-fifty<\/em>), wenn eine Netzwerktrennung das Cluster genau in der Mitte teilt. Daher wird f\u00fcr eine gerade Anzahl von Knoten quorum device<\/strong> ein unaufdringlicher Daemon hinzugef\u00fcgt, der auf der g\u00fcnstigsten virtuellen Maschine im dritten Rechenzentrum ausgef\u00fchrt werden kann. Er gibt seine Stimme einem der Segmente (das er sieht) und l\u00f6st somit die 50%\/50% Unsicherheit auf. Den Server, auf dem das Quorum-Ger\u00e4t ausgef\u00fchrt wird, habe ich genannt witness<\/em> (Terminologie aus repmgr, hat mir gefallen).<\/p>\n

<\/p>\n

Ressourcen k\u00f6nnen von einem Ort zum anderen verschoben werden, zum Beispiel von fehlerhaften Servern zu funktionierenden, oder auf Anweisung der Systemadministratoren. Damit die Clients wissen, wo sich die ben\u00f6tigten Ressourcen befinden (wohin sie sich verbinden sollen?), werden schwebende IPs<\/em> (schwebende IP<\/strong>). Das sind IPs, die Pacemaker zwischen den Knoten verschieben kann (alles befindet sich in einem flachen Netzwerk). Jede von ihnen repr\u00e4sentiert eine Ressource (Dienst) und wird dort sein, wo man sich verbinden muss, um Zugriff auf diesen Dienst (in unserem Fall die DB) zu erhalten.<\/p>\n

<\/p>\n

Tuchanka1 (Schema mit Verdichtung)<\/h2>\n

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Die Idee war, dass wir viele kleine Datenbanken mit geringer Last haben, f\u00fcr die es sich nicht lohnt, einen dedizierten Slave-Server im Hot-Standby-Modus f\u00fcr read-only-Transaktionen zu unterhalten (es besteht keine Notwendigkeit f\u00fcr eine solche Ressourcenverschwendung).<\/p>\n

<\/p>\n

In jedem Rechenzentrum gibt es einen Server. Auf jedem Server laufen zwei Instanzen von PostgreSQL (in der Terminologie von PostgreSQL werden sie Cluster genannt, aber um Verwirrung zu vermeiden, nenne ich sie Instanzen, analog zu anderen Datenbanken, w\u00e4hrend ich Cluster nur f\u00fcr die Pacemaker-Cluster verwenden werde). Eine Instanz l\u00e4uft im Master-Modus und bietet ausschlie\u00dflich Dienstleistungen an (nur auf sie zeigt die Float-IP). Die zweite Instanz funktioniert als Slave f\u00fcr das zweite Rechenzentrum und wird nur Dienstleistungen anbieten, wenn ihr Master ausf\u00e4llt. Da eine Instanz (der Master) die meisten Dienste (Anfragen) bereitstellt, werden alle Serverressourcen f\u00fcr den Master optimiert (Speicher wird f\u00fcr den Cache shared_buffers bereitgestellt usw.), jedoch so, dass auch die zweite Instanz \u00fcber ausreichend Ressourcen verf\u00fcgt (auch wenn deren Leistung \u00fcber den Dateisystem-Cache suboptimal ist) f\u00fcr den Fall eines Ausfalls eines der Rechenzentren. Der Slave bietet keine Dienste an (f\u00fchrt keine Read-Only-Anfragen aus), solange der Cluster normal l\u00e4uft, um Ressourcenkriege mit dem Master auf demselben Ger\u00e4t zu vermeiden.<\/p>\n

<\/p>\n

Im Fall von zwei Knoten ist die Fehlertoleranz nur bei asynchroner Replikation m\u00f6glich, da bei synchroner Replikation der Ausfall des Slaves zur Unterbrechung des Masters f\u00fchrt.<\/p>\n

<\/p>\n

Ausfall Witness<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Ausfall Witness (quorum device<\/em>) werde ich nur f\u00fcr das Cluster Tuchanka1 betrachten, f\u00fcr alle anderen wird die Situation die gleiche sein. Bei einem Ausfall des Witness \u00e4ndert sich in der Cluster-Struktur nichts, alles funktioniert weiterhin wie gehabt. Aber das Quorum wird 2 aus 3 betragen, und jeder weitere Ausfall wird daher fatal f\u00fcr den Cluster sein. Es wird dennoch notwendig sein, es dringend zu reparieren.<\/p>\n

<\/p>\n

Ausfall Tuchanka1<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Ausfall eines der Rechenzentren f\u00fcr Tuchanka1. In diesem Fall witness<\/em> gibt es seine Stimme dem zweiten Knoten im zweiten Rechenzentrum. Dort verwandelt sich der ehemalige Slave in einen Master, sodass auf einem Server beide Master laufen und beide ihre Float-IPs haben.<\/p>\n

<\/p>\n

Tuchanka2 (klassisch)<\/h2>\n

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Klassisches Schema mit zwei Knoten. Auf einem l\u00e4uft der Master, auf dem anderen der Slave. Beide k\u00f6nnen Anfragen verarbeiten (der Slave nur Read-Only), daher zeigen beide Float-IPs an: krogan2 \u2014 auf den Master, krogan2s1 \u2014 auf den Slave. Die Fehlertoleranz ist sowohl beim Master als auch beim Slave gegeben.<\/p>\n

<\/p>\n

Im Fall von zwei Knoten ist die Fehlertoleranz nur bei asynchroner Replikation m\u00f6glich, denn bei synchroner Replikation f\u00fchrt der Ausfall des Slaves zur Unterbrechung des Masters.<\/p>\n

<\/p>\n

Ausfall Tuchanka2<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Beim Ausfall eines der Rechenzentren witness<\/em> Er stimmt f\u00fcr die zweite. Auf dem einzigen funktionierenden Rechenzentrum wird ein Master erstellt, auf den beide float IPs zeigen: die Master- und die Slave-IP. Selbstverst\u00e4ndlich muss die Instanz so konfiguriert sein, dass sie \u00fcber ausreichend Ressourcen (Limits f\u00fcr Verbindungen usw.) verf\u00fcgt, um gleichzeitig alle Verbindungen und Anfragen von der Master- und Slave-float-IP zu akzeptieren. Das bedeutet, dass sie bei normalem Betrieb \u00fcber ausreichende Limits verf\u00fcgen muss.<\/p>\n

<\/p>\n

Tuchanka4 (viele Slaves)<\/h2>\n

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Es gibt bereits eine andere Extremit\u00e4t. Manchmal gibt es Datenbanken, die sehr viele read-only-Anfragen erhalten (ein typischer Fall einer stark belasteten Website). Tuchanka4 ist eine Situation, in der es drei oder mehr Slaves geben kann, um solche Anfragen zu verarbeiten, aber dennoch nicht zu viele. Bei einer sehr gro\u00dfen Anzahl von Slaves muss ein hierarchisches Replikationssystem erfunden werden. Im minimalen Fall (auf dem Bild) gibt es in jedem der beiden Rechenzentren zwei Server, auf jedem davon l\u00e4uft eine PostgreSQL-Instanz.<\/p>\n

<\/p>\n

Eine weitere Besonderheit dieses Schemas ist, dass hier bereits eine synchrone Replikation eingerichtet werden kann. Diese ist so konfiguriert, dass sie nach M\u00f6glichkeit in ein anderes Rechenzentrum repliziert, und nicht auf eine Replik im selben Rechenzentrum, in dem sich der Master befindet. Die float IP zeigt auf den Master und auf jeden Slave. Im Idealfall sollte zwischen den Slaves eine Anfragerobustheit hergestellt werden. sql proxy<\/em>, zum Beispiel auf der Clientseite. Verschiedene Typen von Clients ben\u00f6tigen m\u00f6glicherweise unterschiedliche Typen sql proxy<\/em>, und nur die Entwickler der Clients wissen, welcher Typ welcher ben\u00f6tigt. Diese Funktionalit\u00e4t kann sowohl von einem externen Daemon als auch von einer Client-Bibliothek (Connection Pool) usw. realisiert werden. All dies liegt au\u00dferhalb des Themas der hochverf\u00fcgbaren Datenbankcluster (Hochverf\u00fcgbarkeit SQL proxy<\/em> l\u00e4sst sich unabh\u00e4ngig realisieren, zusammen mit der Klientenverf\u00fcgbarkeit).<\/p>\n

<\/p>\n

Ausfall Tuchanka4<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Bei einem Ausfall eines Rechenzentrums (d.h. zwei Server) stimmt der Witness f\u00fcr den zweiten. Infolgedessen arbeiten in dem zweiten Rechenzentrum zwei Server: auf einem l\u00e4uft der Master, und auf diesen zeigt die Master-float-IP (f\u00fcr die Annahme von read-write-Anfragen); und auf dem zweiten Server arbeitet ein Slave mit synchroner Replikation, und auf diesen zeigt eine der Slave-float-IPs (f\u00fcr read-only-Anfragen).<\/p>\n

<\/p>\n

Das erste, was zu beachten ist: Arbeitsf\u00e4hige Slave-float-IPs werden nicht alle sein, sondern nur eine. Und f\u00fcr die korrekte Arbeit mit dieser muss sichergestellt sein, dass sql proxy<\/em> Alle Anfragen wurden an die einzig verbleibende float IP umgeleitet; falls nicht, sql proxy<\/em> kann man alle float IPs der Slaves durch Kommas in der URL f\u00fcr die Verbindung auflisten. In diesem Fall wird die libpq<\/em> Verbindung zum ersten aktiven IP hergestellt, so ist es im System f\u00fcr automatisiertes Testen implementiert. M\u00f6glicherweise wird es in anderen Bibliotheken, wie JDBC, nicht so funktionieren, und es ist erforderlich, sql proxy<\/em>. Dies wurde so gemacht, weil f\u00fcr float IPs der Slaves ein Verbot besteht, gleichzeitig auf demselben Server zu laufen, damit sie gleichm\u00e4\u00dfig \u00fcber die Slave-Server verteilt werden, wenn mehrere betrieben werden.<\/p>\n

<\/p>\n

Zweitens: Selbst im Falle eines Ausfalls des Rechenzentrums wird die synchrone Replikation erhalten bleiben. Und selbst wenn ein sekund\u00e4rer Ausfall passiert, also wenn einer der beiden Server im verbleibenden Rechenzentrum ausf\u00e4llt, wird der Cluster zwar aufh\u00f6ren, Dienste anzubieten, jedoch die Informationen \u00fcber alle best\u00e4tigten Transaktionen, f\u00fcr die er eine Commit-Best\u00e4tigung gegeben hat, behalten (keine Informationsverluste bei sekund\u00e4ren Ausf\u00e4llen).<\/p>\n

<\/p>\n

Tuchanka3 (3 Rechenzentren)<\/h2>\n

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Dies ist ein Cluster f\u00fcr eine Situation, in der es drei voll funktionierende Rechenzentren gibt, in denen jeweils ein voll funktionierender DB-Server vorhanden ist. In diesem Fall quorum device<\/em> nicht n\u00f6tig. In einem Rechenzentrum l\u00e4uft der Master, in den beiden anderen \u2014 Slaves. Die Replikation ist synchron, vom Typ ANY (slave1, slave2), das hei\u00dft, der Kunde erh\u00e4lt die Best\u00e4tigung des Commits, wenn einer der Slaves zuerst antwortet, dass er den Commit angenommen hat. Es gibt eine float IP f\u00fcr den Master und zwei f\u00fcr die Slaves. Im Gegensatz zu Tuchanka4 sind alle drei float IPs ausfallsicher. F\u00fcr die Lastenverteilung von read-only SQL-Anfragen kann man sql proxy<\/em> (mit separater Ausfallsicherheit) verwenden, oder der einen H\u00e4lfte der Kunden eine Slave-float IP zuweisen und der anderen H\u00e4lfte die zweite.<\/p>\n

<\/p>\n

Ausfall Tuchanka3<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Im Falle eines Ausfalls eines der Rechenzentren bleiben zwei \u00fcbrig. In einem ist der Master und die float IP vom Master aktiv, im anderen \u2014 ein Slave und beide Slave-float IPs (auf der Instanz sollte eine doppelte Ressourcensicherung vorhanden sein, um alle Verbindungen von beiden Slave-float IPs anzunehmen). Zwischen Master und Slave gibt es eine synchrone Replikation. Au\u00dferdem wird der Cluster die Informationen \u00fcber die best\u00e4tigten und abgeschlossenen Transaktionen beibehalten (keine Informationsverluste) im Fall der Zerst\u00f6rung zweier Rechenzentren (sofern sie nicht gleichzeitig zerst\u00f6rt werden).<\/p>\n

<\/p>\n

Eine detaillierte Beschreibung der Dateistruktur und der Bereitstellung habe ich beschlossen, nicht einzuf\u00fcgen. Wer spielen m\u00f6chte, kann das alles im README nachlesen. Ich gebe nur die Beschreibung des automatisierten Testsystems an.<\/em><\/p>\n

<\/p>\n

Automatisches Testsystem<\/h1>\n

<\/p>\n

Zur \u00dcberpr\u00fcfung der Ausfallsicherheit von Clustern unter Simulation verschiedener St\u00f6rungen wurde ein automatisches Testsystem entwickelt. Es wird durch ein Skript gestartet test\/failure<\/code>. Das Skript kann Cluster-IDs als Parameter annehmen, die getestet werden sollen. Zum Beispiel dieser Befehl:<\/p>\n

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
testet nur den zweiten und dritten Cluster. Wenn keine Parameter angegeben sind, werden alle Cluster getestet. Alle Cluster werden parallel getestet, und die Ergebnisse werden im Tmux-Paneel ausgegeben. Tmux verwendet einen dedizierten Tmux-Server, daher kann das Skript aus dem Standard-Tmux gestartet werden, wodurch ein verschachtelter Tmux entsteht. Ich empfehle, ein gro\u00dfes Terminal mit kleiner Schriftgr\u00f6\u00dfe zu verwenden. Vor Beginn des Tests werden alle VMs auf den Snapshot zum Zeitpunkt des Skriptabschlusses zur\u00fcckgesetzt. setup<\/code>.<\/p>\n
<\/p>\n
\"Modellierung<\/p>\n
<\/p>\n
Das Terminal ist in Spalten entsprechend der Anzahl der getesteten Cluster aufgeteilt, standardm\u00e4\u00dfig (im Screenshot) sind es vier. Ich werde den Inhalt der Spalten am Beispiel von Tuchanka2 weiter erl\u00e4utern. Die Paneele auf dem Screenshot sind nummeriert:<\/p>\n
<\/p>\n
    \n
  1. Hier werden die Statistiken der Tests angezeigt. Spalten:\n