ADMIN 11/13 stellt die besten Lösungen vor und klärt, ob Browser-Plugins, Anonymisierer sowie Verschlüsselung wirklich helfen. Weitere Themen: Small ... (mehr)

Pacemaker als Apache-Wachhund

Übrigens: Ganz gleich für welches der beiden Designs sich ein Admin auch entscheidet: Pacemaker besitzt eine überaus nützliche Funktion, was die Webserver-Prozesse auf den Backend-Hosts angeht. Denn Pacemaker kann ganz automatisch in regelmäßigen Abständen überprüfen, ob diese noch laufen. Mittels einer »clone« -Direktive kann das für alle Backend-Server auf einmal geschehen. In Abhängigkeit von der Größe des Setups bietet Pacemaker so einen echten Mehrwert. Aber Vorsicht: Mehr als 30 Knoten funktionieren in einem Pacemaker-Cluster mehr schlecht als recht, sodass 30 Knoten für einen Verbund von Backend-Servern die Maximalgröße darstellt, falls Pacemaker zum Einsatz kommen soll. Ein 2er-Set aus Apache-Ressource und clone-Direktive kann zum Beispiel so aussehen:

primitive p_apache ocf:lsb:apache2 op monitor interval="30s" timeout="20s"
clone cl_apache p_apache

Am Beispiel von OpenStack

Bis dato beschäftigt sich dieser Artikel maßgeblich mit der Frage, wie sich für RESTful-basierte APIs mittels eines Loadbalancers Hochverfügbarkeit erreichen lässt. Der oben beschriebene Weg führt zu einer Installation aus mehreren Servern mit einem kompletten Loadbalancer-Setup inklusive Backend-Hosts. Dabei lässt die Beschreibung bis dato allerdings Spezifika hinsichtlich einzelner RESTful-Lösungen aus. Besonders im Cloud-Kontext, in dem REST-Interfaces gerade eine echte Blütezeit erleben, ist die Verwendung der Schnittstellen aber sehr oft hochgradig spezifisch. OpenStack ist ein gutes Beispiel dafür: Jeder der OpenStack-Dienste hat mindestens eine API oder ist selber eines. Was gemeinhin als OpenStack-Cloud beschrieben wird, ist in Wirklichkeit eine Ansammlung von diversen Komponenten, die zusammenspielen.

Nun ist es bekanntlich bei OpenStack so, dass ein Hauptaugenmerk beim Design der Umgebung auf Skalierbarkeit in der Breite liegt. Nutzer kommunizieren ständig mit den einzelnen Komponenten und auch die Dienste selbst reden ausgiebig miteinander.

Damit sie das tun können, müssen sie aber wissen, unter welcher Adresse ein Dienst wie Glance oder Nova gerade zu erreichen ist. OpenStack verwendet für diese Aufgabe die Komponente Keystone (Abbildung 1), die in ihrer Datenbank die Liste der Endpoints pflegt. Als Endpoint bezeichnen die OpenStack-Entwickler dabei die URL einer RESTful-API, über die sie Befehle von außen entgegennimmt. Der Clou: Die Endpoint-Datenbank ist dadurch nicht statisch. Um also zum Beispiel die Adresse zu ändern, unter der Nova von allen anderen erreicht werden kann, genügt es, einfach den Endpunkt in Keystone umzuleiten.

Abbildung 1: Mittels eines Loadbalancers und Pacemaker lässt sich auch der Proxy-Server des Swift-Speichers hochverfügbar machen und ordentlich in die Breite skalieren. Pacemaker übernimmt dabei vor allem Überwachungsaufgaben.

Das sorgt für wesentlich mehr Flexibilität, als es hartkodierte Werte in Konfigurationsdateien tun würden, denn qua Design fragt jeder Client in OpenStack die Endpunkt-Adresse eines Dienstes neu ab, bevor er sich mit ihm verbindet.

Wenn in einem solchen Setup Hochverfügbarkeit für RESTful-Dienste mittels eines Loadbalancer-Setups erwünscht ist, dann umfassen die nötigen Schritte also mehr als die Installation von zusätzlichen RESTful-Diensten und HA-Proxy. Das ist ohnehin kein besonderes Problem, weil in OpenStack beliebig viele Instanzen der API-Dienste gleichzeitig vorhanden sein dürfen, solange diese im Hintergrund auf die gleiche Datenbank zugreifen. Wichtig ist aber, dass sich die Endpoint-Konfiguration in Keystone dem HA-Umstand anpasst. Ganz konkret bedeutet das, dass dort, wo vorher in der Endpoint-Datenbank die IPs der APIs selbst eingetragen waren, nun Verweise auf die Loadbalancer einzutragen sind. Keystone leitet die Benutzer bei Anfragen also an die Loadbalancer weiter, die im Hintergrund dann die Verbindung zu den Backend-Servern herstellen – wo die eigentlichen OpenStack-APIs laufen. Das Schema lässt sich sowohl für interne wie auch für externe Verbindungen realisieren (Abbildung 5).

Abbildung 5: Was chaotisch aussieht, ist in Wirklichkeit der Traffic, der zwischen dem Keystone-Client und dem Server passiert – im Bild zu sehen ist die Übermittlung eines SSL-signierten Authentifizierungstokens. Gut zu erkennen: HTTPS ist das Mittel der Wahl.

SSL im Handumdrehen

Die im Artikel beschriebene Vorgehensweise ermöglicht es Admins, RESTful-Komponenten über Loadbalancing hochverfügbar zu machen. Wer obendrein SSL für seine Dienste anbieten möchte, bekommt das Feature in Loadbalancer-Setups quasi als Nebeneffekt hinzu, denn praktisch jeder Loadbalancer bietet auch die Möglichkeit einer SSL-Verschlüsselung. Der im Artikel vorgestellte HAProxy [3] kann das ausdrücklich seit Version 1.5. Die Idee ist im Grunde simpel: Die Verbindung zwischen Client und Loadbalancer ist verschlüsselt, die Verbindung zwischen Balancer und dem eigentlichen Zielhost aber nicht. Das ist insofern zu verschmerzen, als dass die Daten auch beim SSL-gestützten Loadbalancing ja zumindest die Zielplattform erreicht haben. Wäre diese kompromittiert, so würde sich das in der Regel sowohl auf den Webserver wie auch auf die Balancer erstrecken, und irgendeine Form von Verschlüsselung wäre so oder so im Verdacht, bereits aufgebrochen zu sein. De facto macht es also keinen Unterschied, wo die SSL-Verbindung terminiert, solange sie das erst im Wirkungsbereich der Zielplattform tut und nicht außerhalb.

Loadbalancing per DNS?

Grundsätzlich existieren mehrere Möglichkeiten, um Loadbalancing zu realisieren. Eine besteht in der Lösung, die dieser Artikel vorstellt: Dabei kommt eine Loadbalancing-Software zum Einsatz, die eingehende Verbindungen entgegennimmt, danach auf die Backend-Server im Hintergrund verteilt und nebenbei noch SSL quasi als ein Neben-Feature mitbringt.

Wer ohne Loadbalancer-Software auskommen möchte, kann alternativ auf DNS-basiertes Round-Robin-Balancing setzen, sollte sich aber der Nachteile bewusst sein, die eine solche Lösung mit sich bringt. Da wäre zunächst die Tatsache, dass sich DNS-Einträge nicht von jetzt auf gleich ändern lassen. Ein DNS-Eintrag, der fünf A-Records hat, wird im Falle des Ausfalls einer der Zielserver dazu führen, das 20 von 100 Clients eine Fehlermeldung erhalten. Vermeiden ließe sich das Problem nur dadurch, dass die Ziel-IPs selbst wiederum in einem Pacemaker-Cluster verwaltet werden, so dass zu keinem Zeitpunkt eine IP-Adresse fehlt.

Ein solches Szenario bietet außerdem keine Möglichkeit, über den Loadbalancer selbst die Webserver im Hintergrund zu prüfen. Es ist ja durchaus denkbar, dass ein »httpd« nicht funktioniert, obwohl er unter seiner üblichen IP-Adresse erreichbar ist – zum Beispiel, weil lokal auf dem Zielserver selbst ein Problem existiert. Loadbalancer-Programme bieten häufig Monitoring-Funktionen an, die sogar soweit gehen, dass sie sich per HTTP mit dem Backend-Server verbinden und prüfen, ob die als Antwort auf ihren Request ausgelieferte Seite den Inhalt hat, den sie haben soll. Der Admin würde in solchen Fällen typischerweise eine eigene Monitoring-Seite bauen, die im Hintergrund verschiedene Checks durchführt und am Ende schließlich "Everything works" ausgibt – erhält der Balancer diesen Text ausgeliefert, betrachtet er das Backend als in Ordnung; andernfalls wirft er es automatisch aus der Konfiguration und leitet neue Verbindungen dorthin erst wieder weiter, wenn das Backend erneut den Dienst aufgenommen hat.

Im Austausch für die genannten Nachteile bietet DNS-Loadbalancing die Option, eine zu wartende Software-Komponente weniger im Setup zu haben. Insbesondere für einfache, kleine Dienste bietet sich das Balancing per DNS insofern an. Und wer ganz große Setups baut, kann die beiden Methoden auch gewinnbringend miteinander kombinieren: Denkbar wäre zum Beispiel, mehrere aktive Loadbalancer zu betreiben, die Clients über DNS-LB erreichen. Die Balancer selbst bilden dann wieder einen HA-Cluster mit Pacemaker, der sich um die Hochverfügbarkeit der IP-Adressen kümmert. So wäre bereits die Last, die auf den Loadbalancern liegt, auf mehrere Systeme verteilbar.

Einige Anwendungen bauen übrigens fest darauf, dass sie sich um SSL selbst gar nicht zu kümmern brauchen – OpenStack Swift ist ein gutes Beispiel: Der Dienst hat zwar die Möglichkeit, über die RESTful-Komponente »swift-proxy« SSL-Zertifikate auszuliefern, doch ist dieses Feature in der Dokumentation nur zu Testzwecken freigegeben. Wer Swift produktiv mit SSL einsetzen möchte, soll das über eine Loadbalancer-Lösung (Abbildung 4) erledigen.

Abbildung 4: Keystone ist das Telefonbuch der OpenStack-Cloud. Wenn auf alice.local jeweils ein Loadbalancer am betreffenden Port läuft, funktioniert das Setup wie gewünscht.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2021