Hochverfügbarkeit für RESTful-Dienste am Beispiel von OpenStack

Ying Feng Johansson, 123RF

Weichensteller

RESTful-Dienste erfreuen sich derzeit großer Beliebtheit, gerade im Zusammenhang mit Clouds. Um HTTP-basierte Services hochverfügbar zu machen, bietet sich dem Admin ein Füllhorn an Möglichkeiten. Auf die Kombination kommt es an!
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)

Hochverfügbarkeit ist mittlerweile ein elementarer Bestandteil jedes neuen Setups, das IT-Architekten aus der Taufe heben. Denn die Summen, die sich wegen entgangener Geschäfte und Strafzahlungen nach Ausfällen ergeben, sind oft derart hoch, dass bereits ein einziger Vorfall teurer kommt als ein von Anfang an ordentlich implementiertes High-Availability-Setup.

Auf Linux-Systemen steht dem Admin in Form des Linux-HA-Stacks mit Corosync und dem Cluster-Manager Pacemaker [1] dabei ein umfassender Werkzeugkoffer zur Verfügung, mit dem sich zuverlässig Hochverfügbarkeit realisieren lässt. Doch es muss nicht immer Pacemaker sein – es gibt auch andere Möglichkeiten, die durchaus im praktischen Einsatz sind. Geht es beispielsweise darum, die ständige Verfügbarkeit für HTTP-basierte Dienste zu gewährleisten, dann bieten sich Loadbalancer an. Gerade für die im Augenblick sehr beliebten Dienste auf Grundlage des REST-Prinzips existiert damit eine echte Alternative zu den klassischen Failover-Setups, wie sie mit Cluster-Managern machbar sind.

HA-Hintergründe

Die gängige Lehre beschreibt Hochverfügbarkeit grundsätzlich als den Zustand eines Systems, bei dem eine elementare Komponente ausfallen kann, ohne dass es zu einer längeren Downtime kommt. Ein klassischer Ansatz zur Lösung dieses Problems besteht in sogenannten Failover-Clustern nach dem Active-Passive-Prinzip. Dabei existieren mehrere Server, idealerweise mit identischer Hardware, derselben Software und auch der gleichen Konfiguration. Ein Rechner ist jeweils aktiv, ein zweiter Rechner steht parat und übernimmt bei Bedarf den Betrieb der Applikation, die zuvor auf dem ausgefallenen ersten System lief. Eine elementare Komponente in einem Setup dieser Art ist stets ein Cluster-Manager wie Pacemaker, der sich um die Überwachung der Server kümmert und bei Bedarf den Neustart des Services auf dem überlebenden System einleitet.

Damit ein Failover funktionieren kann, müssen ein paar Komponenten des Systems Hand in Hand zusammenarbeiten. Zwingend ist – wie zuvor beschrieben – eine auf beiden Servern installierte Anwendung mit identischer Konfiguration. Ein zweites wichtiges Thema sind die Daten, die die Anwendung braucht: Falls es sich zum Beispiel um eine Datenbank handelt, sollte sie die gleichen Daten auf beiden Rechnern zur Verfügung haben. Das wird beispielsweise durch Shared Storage möglich, der in Form von Cluster-Filesystemen wie GlusterFS oder Ceph oder Netzwerk-Filesystemen wie NFS oder Replikationslösungen wie DRBD daherkommen kann (DRDB kommt in Frage, wenn es sich tatsächlich um einen Zwei-Knoten-Cluster handelt).

Gute Verbindungen

Ein weiteres Thema ist die Verbindung der Clients zum hochverfügbaren Dienst: Eine echte HA-Lösung sollte es dem Clients keinesfalls vorschreiben, nach dem Failover die eigene Konfiguration zu verändern, um eine Verbindung zum neuen Server aufbauen zu können. Stattdessen arbeiten Admins hier meist mit sogenannten Virtual-IPs oder Service-IPs: Eine IP-Adresse ist dann fest an einen Dienst gebunden und stets auf dem Host zu finden, auf dem dieser Dienst zu dieser Zeit tatsächlich läuft. Wann immer ein Client eine Verbindung zu dieser Adresse aufbaut, wird er also dort auch den erwarteten Dienst finden.

Handelt es sich um eine Software, die Verbindungen im Stateful-Zustand nutzt, bei der also eine Client-Server-Verbindung permanent existiert, so sollte der Client über ein Feature verfügen, das einen automatischen Reconnect bewerkstelligt. Die Clients für die gängigen Datenbanken, also MySQL oder PostgreSQL, sind hierfür Beispiele. Deutlich einfacher im Umgang sind Stateless-Protokolle wie HTTP: Hier öffnet der Client für jede Server-Anfrage eine eigene Verbindung. Ob er beim ersten Request mit Knoten A oder Knoten B redet, ist also völlig egal. Findet in der Zwischenzeit ein Failover statt, so merkt der Client davon nichts.

Ä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

Google+

Ausgabe /2019