NGA – Hochverfügbarkeitskonfiguration (HAC)

Dieses Kapitel bietet einen Überblick über die Hochverfügbarkeitskonfiguration für redundante oder nicht-redundante WinCC OA-Projekte (High Availability Configuration - HAC) und erklärt die Rollen der Komponenten etcd und Patroni, die für die Einrichtung der HAC erforderlich sind.

Die HAC basiert auf den Streaming-Replication- und Hot-Standby-Funktionen eines PostgreSQL®-Clusters, der durch das Patroni-Tool verwaltet und überwacht wird. Die HAC stellt sicher, dass der PostgreSQL®-Cluster auch bei Ausfall eines Knotens oder Netzwerkverbindungen verfügbar und konsistent bleibt.

Wie in den Abbildungen Patroni-Architektur - Single- / Redundant-Projekt unterhalb gezeigt, kommunizieren die PostgreSQL®-Backends des Next Generation Archivers (NGA) in der HAC direkt mit einem Zwei-Knoten-PostgreSQL®-Cluster. Jeder der PostgreSQL®-Knoten wird von einer entsprechenden Patroni-Instanz überwacht und verwaltet. Diese arbeiten unabhängig von WinCC OA. Patroni verwaltet die PostgreSQL®-Prozesse, übernimmt das Failover von Knoten und stützt sich auf die integrierten Streaming-Replication- und Hot-Standby-Funktionen von PostgreSQL® (https://www.enterprisedb.com/docs/supported-open-source/patroni/).

In einer HAC ist Patroni so konfiguriert, dass etcd (/ˈɛtsiːdiː/, „distributed etc directory“), ein hochkonsistenter, verteilter Key-Value-Store, verwendet wird, um Clusterinformationen wie die Patroni- und PostgreSQL® -Clusterkonfiguration, den Leader-Knoten von Patroni und Diagnosedaten zu speichern. Diese Architektur unterstützt die Wahl des Patroni-Leader-Knotens und das Failover im PostgreSQL®-Cluster ohne manuelles Eingreifen.

Table 1. Patroni-Architektur - Single- / Redundant-Projekt

Patroni

Auf jedem PostgreSQL®-Datenbankserver läuft eine zugehörige Patroni-Instanz als Dienst. Sie steuert die lokalen PostgreSQL®-Prozesse und stellt Konsistenz sicher, indem sie Split-Brain-Szenarien verhindert. Zusammen bilden die Patroni-Instanzen und ihre zugehörigen PostgreSQL®-Knoten einen Patroni-Cluster. In einem Cluster wird eine Patroni-Instanz zum Leader gewählt und die zugehörige PostgreSQL®-Instanz innerhalb des PostgreSQL®-Clusters als Primary eingesetzt.

Alle anderen PostgreSQL®-Instanzen arbeiten im Standby-Modus (erlauben nur Leseoperationen) und führen kontinuierliche Write-Ahead-Logging (WAL) Streaming-Replication durch, wobei Transaktionen nahezu in Echtzeit vom Primary-Knoten übernommen werden. Dies stellt sicher, dass jeder Standby-Knoten im Falle eines Ausfalls des Primary-Knotens oder des Netzwerks schnell zum Primary im PostgreSQL®-Cluster befördert werden kann.

Etcd spielt in diesem Prozess eine entscheidende Rolle: Es dient als Konsensmechanismus für die Leader-Wahl und speichert den aktuellen Laufzeitstatus sowie die Konfiguration des Patroni-Clusters.

Jede Patroni-Instanz ist für die Initialisierung ihres zugehörigen PostgreSQL®-Knotens verantwortlich. Abhängig von ihrer Rolle verwendet die Patroni-Instanz:
  • initdb zur Initialisierung des Primary-Knotens des PostgreSQL®-Clusters
  • pg_basebackup zur Initialisierung eines Standby-Knotens vom Primary des PostgreSQL®-Clusters
Abschließend übernimmt Patroni die Beförderungen und Rückstufungen von PostgreSQL® -Knoten zu Primary oder Standby entsprechend der Rolle der zugehörigen Patroni-Knoten im Cluster. Dies ermöglicht ein automatisches Failover innerhalb des PostgreSQL® -Clusters und stellt die hohe Verfügbarkeit des PostgreSQL®-Clusters sicher.

etcd

etcd ist eine Schlüssel-Wert-Datenbank und bietet einen zuverlässigen Mechanismus für die verteilte Speicherung von Daten, die von verteilten Systemen benötigt werden. Es besteht aus einer vorzugsweise ungeraden Anzahl von Knoten, die den etcd-Cluster bilden. etcd übernimmt die Wahl des etcd-Leader-Knotens zuverlässig während Netzwerkpartitionen oder Ausfällen von etcd-Knoten.

Wie in den Abbildungen Patroni-Architektur - Single- / Redundant-Projekt gezeigt, stellt die HAC drei etcd-Knoten bereit, die zusammen als DCS für Patroni dienen. Jeder etcd-Knoten läuft als Dienst auf einer separaten Maschine, um eine hohe Verfügbarkeit sicherzustellen. Der etcd-Cluster kann den Ausfall eines Knotens tolerieren und dennoch ein Mehrheitsquorum von 2 von 3 aufrechterhalten.

Note:
Die Anzahl der Knoten kann bei Bedarf für etcd oder Patroni erhöht werden, aber im WinCC OA HAC gibt es eine feste Anzahl von drei Knoten.

Um ein stabiles und ausgewogenes Systemverhalten im Falle eines Ausfalls eines WinCC OA-Servers zu gewährleisten, darf sich kein etcd-Knoten auf einem der beiden WinCC OA-Server befinden. Daher werden im HAC zwei etcd-Knoten auf den beiden Datenbankservern verteilt, während der dritte etcd-Knoten auf einer dedizierten Maschine läuft.

Weitere Informationen zu NGA im Allgemeinen finden Sie in der NGA-Dokumentation.