Load Balancing und High Availability

Siehe auch

LB: Apache, HAProxy u.a.

Layer 4 (TCP) Load Balancer (LB) arbeiten rein auf der Netzwerkschicht und damit applikationsunabhängig. Sie lassen sich also genau so vor MariaDB oder RabbitMQ stellen wie vor Webserver-Landschaften. Dafür verstehen sie Protokoll-Eigenheiten nicht, und können daher beispielsweise keine Spezialitäten wie Cookies oder Sticky Sessions für HTTP umsetzen. Bei TLS-Terminierung ist ein Layer 7 Loadbalancer Pflicht.

Layer 4 (TCP):

  • HAProxy

  • Istio (für Container)

  • Seasaw

Layer 7 (Applikationsprotokoll):

  • Apache (HTTP(S), FTP)

  • HAProxy (nur HTTP(S))

  • Nginx (nur HTTP(S))

HA: Corosync & Pacemaker vs Keepalived

TLDR:

  • Pacemaker sorgt dafür, dass eine Ressource (z.B. eine Datenbank wie SAP HANA) maximal einmal auf dem letzten aktiven Primary-Node in einem Cluster startet. Der Start der Ressource wird verhindert, wenn kein Primary ermittelt werden kann.

  • Keepalived sorgt dagegen dafür, dass immer ein Service (z.B. ein Webserver) verfügbar ist.

Ausführlicher:

Generell werden Corosync (ein Cluster Communication Manager) und Pacemaker (ein Cluster Resource Manager) dazu verwendet, einen Cluster aufzubauen, der eine Ressource maximal einmal anbietet. Dazu werden Features wie „Resource Fencing“ und STONITH angeboten. Die Datensicherheit wiegt höher als die Verfügbarkeit: Es werden lieber gar keine Services angeboten, als zum Beispiel ein Split-Brain aufgrund von paralellen Schreibzugriffen zu riskieren.

Keepalived hingegen sorgt dafür, dass ein Service auf jeden Fall aufrufbar ist.

Zwar kann man mit etwas Konfigurationsaufwand mit beiden Produkten beide Ziele abdecken, allerdings merkt man dabei deutlich, das die Applikationen nicht dafür ausgelegt sind. Siehe http://www.formilux.org/archives/haproxy/1003/3259.html.

Resource Fencing und STONITH:

Ein Quorum löst nur das Dilemma, welche Seite die Ressourcen übernehmen soll. Eine Garantie zum exklusiven Zugriff erfordert zusätzlich „Resource Fencing“. Selbst wenn die Minderheit der Knoten bei einem Split Brain wegen mangelnden Quorums ihre Ressourcen stoppt, weiss die Mehrzahl immer noch nicht, ob der Vorgang erfolgreich ist und wie lange er dauert.

Bei aktivem „Resource Fencing“ ruft ein Knoten vor der Übernahme einer Ressource einen Agenten auf und wartet auf dessen positive Rückmeldung. Bleibt diese aus, beispielsweise beim gleichzeitigen Kommunikationsausfall zur Fencing-Hardware, übernimmt der Node keine Ressourcen. Hier wiegt die Datensicherheit erneut höher als die Verfügbarkeit. In den meisten Fällen kommt dann „Shoot The Other Node In The Head“ (STONITH) zum Einsatz, wobei in der Regel der Minderheit der Knoten die Stromzufuhr entzogen wird.

Mitgelieferte STONITH-Agenten findet man mit stonith -L, ihre Parameter via stonith -m -tNAME. Dieser Mechanismus kommt auch bei einem vom Administrator initiierten Umzug einer Ressource zum Einsatz, wenn der abgebende Knoten unfähig ist, die Ressource innerhalb der Zeitvorgaben (stop timeout) zu stoppen.

Die Konfiguration dieser STONITH-Agenten hängt stark von der verbauten Hardware ab, in den meisten Fällen kommen schaltbare Stromleisten oder „Remote Management Boards“ (BMC, IPMI) mit eigener Stromzufuhr zum Einsatz.

Quelle: Seilschaft, iX 1/2011

Built on 2024-11-18