Verwenden Sie den ZFS-Kopfknoten als Datenbankserver?

Ich verwende ein ZFS-gestütztes NAS mit zwei Köpfen für gemeinsam genutzten Hochverfügbarkeitsclusterspeicher, basierend auf der hier empfohlenen Architektur von Nexenta:

Die Festplatten in 1 JBOD speichern die Datenbankdateien für eine einzelne 4-TB-Postgres-Datenbank, und die Festplatten in der anderen JBOD speichern 20 TB große binäre Roh-Flatfiles (Clusterergebnisse für Kollisionssimulationen mit großen Sternobjekten). Mit anderen Worten, der JBOD, der die Postgres-Dateien sichert, verarbeitet hauptsächlich zufällige Workloads, während der JBOD, der die Simulationsergebnisse unterstützt, hauptsächlich serielle Workloads verarbeitet. Beide Kopfknoten haben 256 GB Speicher und 16 Kerne. Der Cluster hat ungefähr 200 Kerne, die jeweils eine Postgres-Sitzung verwalten, daher erwarte ich ungefähr 200 gleichzeitige Sitzungen.

Ich frage mich, ob es in meinem Setup sinnvoll ist, die ZFS-Kopfknoten gleichzeitig als gespiegeltes Paar von Postgres-Datenbankservern für meinen Cluster zu fungieren. Die einzigen Nachteile, die ich sehen kann, sind:

Weniger Flexibilität bei der Skalierung meiner Infrastruktur.
Etwas geringerer Redundanzgrad.
Begrenzte Speicher- und CPU-Ressourcen für Postgres.

Der Vorteil, den ich sehe, ist jedoch, dass ZFS in Bezug auf automatisches Failover sowieso ziemlich dumm ist und ich nicht viel Arbeit aufwenden muss, um jeden Postgres-Datenbankserver dazu zu bringen, herauszufinden, ob ein Kopfknoten ausgefallen ist, da er zusammen mit dem Kopf ausfällt Knoten.

— elleciel
quelle

PostgreSQL kann in keinem Shared-Storage-Modus ausgeführt werden. Versuche, dies zu tun, schlagen fehl. Versuche, den Schutz zu umgehen, um Sie daran zu hindern (wie das Verschieben / Ausblenden postmaster.pid), führen zu schwerwiegenden Datenbeschädigungen.

— Craig Ringer

@CraigRinger Hm, widerspricht dies wiki.postgresql.org/wiki/Shared_Storage ?

— Elleciel

Sie können es ausführen, wenn Sie absolut garantieren, dass immer nur ein Postmaster gleichzeitig auf das Datenverzeichnis zugreift. Guter STONITH / Fencing ist eine unabdingbare Voraussetzung, um eine Beschädigung der Daten zu vermeiden. Persönlich würde ich es auf keinen Fall tun. Dadurch entfallen auch die Vorteile, über die Sie sprechen - Sie müssen automatisch herausfinden, welcher Server der Haupt- / Live-Server ist usw. -, da Sie das Failover verwalten müssen.

— Craig Ringer

Ich habe die Wiki-Seite überarbeitet, um sie klarer zu gestalten. Vielen Dank für den Hinweis.

— Craig Ringer

Das macht keinen Sinn. Die HA-Lösung von Nexenta nutzt RSF-1-Clustering . Es hört sich so an, als würden Sie dies mit ZFS unter Linux ohne das RSF-1-Teil tun. Allerdings verfügt ZFS unter Linux nicht wirklich über eine Clustering-Option, sodass die Nexenta-Referenz nicht gilt. Was müssen Sie gewinnen, wenn Sie zwei Kopfknoten haben?

— ewwhite

Es können nicht zwei Postgres-Instanzen ("Cluster" in der Postgres-Terminologie) auf dieselben physischen Dateien angewendet werden.

Wenn Sie Leistung wünschen, kann Sharding hilfreich sein (zwei Instanzen mit jeweils unterschiedlichen Daten)

Wenn Sie eine hohe Verfügbarkeit wünschen, ist ein Failover mit STONITH möglicherweise die Lösung. Sie müssen sicherstellen, dass die Hardware nach der Reparatur nicht versucht, die Datenbank zu öffnen, während der zweite Knoten sie bedient.

— Jasen
quelle