Cloud Foundry Fail Over

Sie gehören zu den wohl meist gefürchtetsten Dingen im Geschäftsalltag und doch hatte schon jeder mit ihnen zu tun: Serverausfälle. Fehler sind menschlich und so ist kein Rechenzentrum der Welt vor Ihnen gefeit. Irgendwann trifft es jeden mal. Doch wer das Problem und den damit verbundenen Verlust von Umsätzen, den unzufriedenen Kunden und den monetären Schaden als höhere Gewalt abtut, der urteilt wohlmöglich etwas zu voreilig: Mit einer Fail-Over-Routine ist es eine Sache von wenigen Minuten Ihre Applikation von einem ins andere Rechenzentrum zu verlagern. Mit unseren bislang zwei Standorten und unserem meshStack bringen wir schon alles mit um Applikationen ausfallsicher und redundant zu gestalten, ohne sich ans Zeichenbrett setzen zu müssen, um die Infrastruktur neu zu denken. Im Fall der Fälle kann der Standort einer Applikation binnen weniger Minuten verlagert werden, ohne das Ressourcen dauerhaft geo-redundant gehalten werden müssen.  Dabei geht nicht nur der Umzug schnell von statten, sondern auch die Einrichtung. Damit bringen wir Hochverfügbarkeit in jedes Unternehmen, ob One-Man-Show, oder Großkonzern. Hochkritische Infrastrukturen können auch dauerhaft geo-redundant aufgesetzt werden, dies behandeln wir hier nicht.

Drei Schritte zum Seelenfrieden

1. Automatisches Backup Ihrer Datenbank einrichten
2. Infrastruktur in einer anderen Location replizieren
3. Backup einspielen

Vorab: DNS TTL

Wer seine Infrastruktur schnell ersetzen möchte, der benötigt natürlich auch einen flexiblen DNS-Eintrag. Um einen möglichst problemlosen und schnellen Übergang zu gewährleisten, ist es notwendig eine möglichst niedrige TTL (Time To Live) einzustellen. Der TTL-Eintrag definiert wie lange die entsprechenden Domains im DNS Cache gehalten werden.

Automatisches Backup einrichten

An dieser Stelle gehe ich davon aus, dass Sie Ihre Applikation schon in Cloud Foundry deployed haben.

Zunächst loggen Sie sich in der Cloud Foundry CLI ein. Verschaffen Sie sich einen Überblick über die laufenden Services.

cf services

Aus der Liste der laufenden Services suchen Sie sich nun den Datenbank Service aus, den Sie replizieren möchte.

cf service NAME

Nehmen Sie nun das oben genannte Kommando und ersetzen Sie "NAME" mit dem Namen Ihres Services. Cloud Foundry sollte Ihnen nun allerlei Details zu dem spezifizierten Service zurückgeben. Tatsächlich interessiert uns der erste Abschnitt aber am meisten. Er sollte in etwa so aussehen:

Service instance: todo-db
Service: PostgreSQL
Bound apps: todo-backend
Tags:
Plan: S
Description: PostgreSQL Instances
Documentation url:
Dashboard: https://postgresql.cf.eu-de-darz.msh.host/v2/authentication/************

Das Objekt unserer Begierde ist der Dashboard Eintrag. Wir kopieren die URL in unserer Browserfenster. So landen wir im Backup Manager der Datenbank. Hier haben wir die Möglichkeit zyklische Backups der Datenbank in einem Swift Container zu speichern. OpenStack Swift, ist unser Service für Object Storage. Er eignet sich hervorragend zu Ablegen von Dateien wie dem Datenbank-Dump. Die Erstellung eines Swift Containers ist kinderleicht. Navigieren Sie im Service-Menu des meshPanels unter Storage zum Punkt Objects und geben Sie den Namen des Containers ein. Wichtiger Hinweis: Da Sie im Falle eines Ausfalls in einer Location auch der Swift Storage betroffen sein kann, erstellen Sie das Swift Container in der anderen Location.

Nun, wo Sie mit einem Swift Container ausgestattet sind, müssen wir diesen noch im Backuptool hinterlegen. Das Backuptool benutzt die Swift API und genau dafür holen wir uns im meshPanel jetzt die Zugangsdaten ab. Wählen Sie im meshPanel die Location in dem Sie Ihren Swift Container erstellt haben und navigieren Sie zum untersten Punkt in der Seitenleiste "Service User". Dort geben Sie eine Beschreibung ein und wählen aus dem Dropdown-Menu Openstack. Der Service User wird erstellt, und der Browser läd ihnen eine .txt-Datei mit den Login Credentials herunter. Achtung: Die Credentials werden einmalig ausgehändigt, speichern sie diese gut oder erstellen Sie bei Verlust einen neuen Service User.

In dieser Textdatei sind nun alle nötigen Informationen vorhanden. Wir wechseln nun also wieder zum Datenbank Dashboard. Hier wählen wir unter dem Punkt "Backend Endpoints" die Schaltfläche "Create File Endpoint". Öffnen Sie die, im vorherigen Schritt erstellte, Textdatei. Um das ganze etwas abzukürzen mache ich eine kleine Gegenüberstellung welche Elemente aus der Textdatei (links) in welche Felder im Webinterface (rechts) gehören.

API Endpoint --> Authentification URL
Username --> Username
Password --> Password
OS_USER_DOMAIN_NAME --> Domain
OS_PROJECT_NAME --> Project

Abschließend geben Sie den Namen des Containers an, den Sie in einem der vorangegangenen Schritte erstellt haben.

Backup Plan erstellen

Nun haben wir alle Komponenten zusammengeführt um Backups zu erstellen. Abschließend möchten wir noch einen Backup Plan erstellen, der periodisch Backups unserer Datenbank in den gerade verlinkten Container speichert.

Dazu gehen wir wieder auf das Datenbank Dashboard und wählen die Schaltfläche "Create Backup Plan" aus. Für die Frequenz des Backups, nutzen Sie die Spring Cron Syntax. Mit dieser Angabe zum Beispiel 0 0 , läuft ihr Backupjob stündlich. Die "Retention Period" gibt an wie viele Backups behalten werden sollen. Der "Retention Style" sagt dabei aus, wie die vorangegangene Eingabe zu interpretieren ist: Wählt man Beispielsweise als "Retention Period" zwei, und als Retention Style "Day" dann bleiben die Backups der letzten beiden Tage erhalten. Im Dropdown Menü "File Destination" wählen Sie den eben verlinkten Swift Container.

Über die Backup Plans und verschiedene File Destinations können Sie die Redundanz des Backups erhöhen und beispielsweise auf Swift Container aus mehreren Rechenzentren gleichzeitig Backupen.

Im Problemfall

Tritt der Fall der Fälle nun ein und das Rechenzentrum in dem Ihre Applikation läuft ist nicht mehr erreichbar, können Sie nun einfach Ihre Infrastruktur im anderen Rechenzentrum replizieren.

Replikation

Dafür loggen Sie sich im meshPanel ein und wählen die alternative Location aus. Sie loggen Sich über die Cloud-Foundry-CLI ein. Zunächst erstellen Sie den Datenbank Service, den Sie für Ihre Applikation benötigen.

cf marketplace #Zeigt die verfügbaren Services im Marketplace
cf create-service MySQL S Name #erstellt den Service MySQL in der Größe S mit dem Namen "Name"

In der neuen Infrastruktur befindet sich nun zunächst nur eine leere Datenbank, welche im nächsten Schritt wiederhergestellt wird.
Neben der Datenbank ist allerdings ebenfalls ihre Applikation notwendig. Da Sie die Applikation ja bereits in der alten Infrastruktur deployed haben, sind alle notwendigen Anpassungen für Cloud Foundry bereits abgeschlossen. Sie navigieren nun also nur noch mit ihrem Terminal in den Ordner in dem die Applikation gespeichert haben und führen das Deployment mittels cf push aus.

Nachdem Ihre Applikation erfolgreich deployed wurde, müssen Sie diese noch mit ihrem frisch erstellten Datenbankservice verbinden. Vorsicht: Häufig sind die Bindings auch schon im "manifest.yml" der Applikation definiert. Achten Sie darauf, dass der Name ihres Datenbankservices mit dem in der manifest.yml übereinstimmt oder ändern Sie das Manifest nachträglich.

cf bind-service myapp mydb

Backup Einspielen

Dann lassen Sie sich mittels bashscript cf service Name die Dashboard URL anzeigen, öffnen das Dashboard, und tragen ihre Credentials aus der ".txt"-Datei des Service Users unter der Rubrik Restore ein. Das Schema wurde weiter oben schon ausführlich beschrieben und ist hier identisch. Abschließend klicken Sie auf Restore. Ihre Datenbank müsste jetzt also auf dem selben Stand sein wie jene, die zur Zeit von einem Ausfall betroffen ist

DNS Einträge ändern

Jetzt wo Ihre Applikation auf einem anderen Server läuft, müssen Sie selbstverständlich auch die DNS Einträge umstellen.