Kategorie: DevOps

Wo speichert ein Datenbank Docker Container seine Daten?

Frage

Die Frage, die aufgetaucht ist, ist folgende: Ich möchte einen Datenbank Docker Container zum Beispiel in OpenShift erstellen. Dies ist eine sehr einfache Sache, da OpenShift bereits Templates für diverse Datenbanklösungen wie PostgreSQL anbietet.

Die Frage ist nun: Wenn ich diese PostgreSQL Instanz verwende und fleissig Daten inserte und update – Sind diese Daten dann im Container gespeichert oder brauche ich extra einen externen Speicher?

Antwort

Docker Container sind von kurzlebiger/flüchtiger Natur – Das korrekte Englische Wort dafür ist ephemeral. Heisst, alle Daten, die ich in meinem Docker Container speichere, sind verloren, wenn ich den Container neustarte oder wenn sonst etwas mit ihm passiert.

Um Daten persistieren zu können wie etwa in einer Datenbank muss man diesen Container an einen externen Speicher anschliessen (etwa NFS, Block Storage wie SAN oder Container Native/Ready storage wie gluster/ceph). Werden die Daten dort persistiert, überdauern sie auch das brutale Töten des Docker Containers.

Wenn man dann Daten in die PostgreSQL Tabellen einfügt, schreibt es die Daten dann effektiv auf den angegebenen Speicher, den man an den Container beziehungsweise an den Pod angehängt hat.

So macht mans also richtig: Immer zuerst ein persistentes Volume anlegen und dann mit einem sogenannten Persistent Volume Claim auf diesen Speicher zugreifen.

Was ist ein verteiltes System?

13.02.2017

Grosse Applikationen in einem Unternehmen laufen heutzutage nicht mehr auf einem einzigen Rechner, sondern auf mehreren Servern. Ist eigentlich auch logisch, denn wenn der Hauptcomputer ausfallen würde und man etwa die Buchhaltungsapplikation nicht mehr verwenden könnte, wäre das nicht gerade optimal.

Läuft eine Applikation auf mehreren Servern spricht man von einem verteilten System. Bei ganz grossen Firmen ist das System nicht nur verteilt auf mehrere Server, sondern die Server selber sind auch von der Lokation her an verschiedenen Orten. Die Daten werden dann üblicherweise dupliziert und redundant gehalten. So kann ein Serverzentrum die volle Funktionalität übernehmen, wenn das zweite ausfallen würde – Am Besten so, dass der Kunde nichts davon merkt.

Was sind die Vorteile von verteilten Systemen?

Nun, wie erwähnt will man die Ausfallsicherheit eines Systems erhöhen. Stellen Sie sich vor, das Ebanking ihrer Bank würde für eine Woche ausfallen – Das wäre eine Katastrophe!

Desweiteren hat man bei einem verteilten System die Möglichkeit, bei der Überlastung eines Servers die Last auf weitere Server zu verteilen, siehe Was ist ein Load Balancer?

Aus diesen Gründen ist es daher sowieso keine Frage, ob grosse Firmen ein verteiltes System verwenden oder nicht. Systeme von Grossfirmen sind mittlerweile riesig und über etliche Jahre gewachsen. Systeme haben auch die Natur, dass sie sich ständig ändern. Daher muss die Architektur so skalierbar sein wie möglich.

Was ist eine typische Architektur eines verteilten Systems?

Eine Architektur, die man am sehr oft antrifft, ist die sogenannte Three Tier Architektur. Mit Tier ist dabei einfach eine Stufe einer Applikation gemeint.

Beim Tier 1 geht es um den Kunden, der an seinem Computer sitzt und die Anwendung er Firma benutzt. Er wird üblicherweise Client genannt. Diese Stufe findet also beim Kunden auf seinem Computer statt – Heutzutage normalerweise im Browser, da man praktisch nur noch Webapps baut statt echte Desktopprogramme.

Der Tier 2 geschieht dann bereits auf den Servern einer Firma. Dort läuft die Stufe der Anwendungsserver oder Applikationsserver. Die Benutzereingaben werden dort gesammelt und je nachdem, was gemacht werden muss, werden verschiedene Module aufgerufen. Dort ist auch der Kern oder der Wert einer Firma versteckt: In den Algorithmen und der Geschäftslogik.

Im Tier 3 geht es dann noch darum, die Daten zu persistieren und auf Datenbanken abzuspeichern.

Haben alle Firmen dieselbe Architektur?

Ha, schön wäre es! Wie es in der Natur des Menschen liegt, hat jede Firma ihre eigene Architektur und sogar innerhalb einer Firma existieren zig Architekturen, die verwendet werden. Alte Systeme werden am Leben gelassen, weil man zum Beispiel den alten Code nicht mehr versteht und lieber nichts ändert. Neue Systeme richten sich nicht an alten Systemen. Mitarbeiter werden ausgetauscht, die jeweils unterschiedliche Technologien bevorzugen oder kennen – Da passiert viel in einer wirklich grossen Firma.

Denken Sie auch daran, dass die Three Tier Architektur wirklich nur ein ganz grundlegender, traditioneller Gedanke ist. Innerhalb einer Stufe können verschiedene Unterstufen und Technolgien zum Einsatz kommen.

Ein Client kann zum Beispiel eine mit Java und JavaScript gebaute Buchhaltungssoftware verwenden, die per REST Services mit dem Applikationsserver kommuniziert. Im Applikationsserver gibt es nun eine Applikation, welche die Benutzerdaten in einer Oracle Datenbank abspeichert und mit Java darauf zugreift. Die Buchhaltungsdaten selber werden aber an einen Cobolservice weitergereicht, der diese Daten wiederum in einer DB2 Datenbank abspeichert.

Sie sehen, in der Realität können sehr viele Stufen durchlaufen werden, wenn man in einer Webapplikation einen simplen Knopfdruck macht.

Was ist ein Load Balancer?

Nehmen wir an, Sie hätten eine Java Webapplikation in Spring programmiert. Eine hochexklusive Homepage, welche dem Besucher die Frisuren aller Formel 1 Rennfahrer zeigt. Nun möchten Sie ihr Glanzstück dem Internet zeigen.

Im einfachsten Fall erstellen Sie ein aus ihrem Java Projekt eine WAR Datei (Web Archive). Dann brauchen Sie noch einen Server, der zum Beispiel eine Linux Distribution am laufen hat. Dort installieren sie einen Tomcat (siehe Tomcat oder Websphere?) und kopieren ihre WAR Datei in den Webapps Ordner. Beim Starten von Tomcat wird ihre Webapplikation automatisch entpackt und gestartet.

Unerhoffter Erfolg

Nach einigen Wochen schauen Sie sich die Benutzerstatistiken an und sehen, wie die Zugriffe auf ihre Seite explodiert sind! Alle wollen Formel 1 Rennfahrerfrisuren bestaunen! Ihr Server kommt mit den Anfragen nicht mehr nach. Was tun?

Mehr Server müssen her

Sie brauchen mehr Server und Sie brauchen ein Load Balancing!

Sobald Sie mehrere Server am Laufen haben spricht man von einem Server Cluster (oder auch Server Farm oder Server Pool). Ein Cluster ist eine Gruppe von Servern, die gleichzeitig eine Webapplikationen laufen haben und für die Aussenwelt so erscheinen, als ob es ein einziger Server wäre.

Zwischen der Aussenwelt und den Servern liegt dann der Load Balancer. Dies kann eine Software- oder Hardwarelösung sein.

Das Ziel ist es, die Hochverfügbarkeit zu gewährleisten. Wenn ein Server ausfallen würde, können die verbleibenden Server die Anfragen übernehmen. Ein weiteres Ziel ist die Skalierbarkeit. Wenn ihre Benutzerzahlen in den Himmel schiessen, werden Sie noch mehr Server benötigen, um den Ansturm an Besuchern auszuhalten. Das System muss also skalierbar und erweiterbar sein.

Wie funktioniert jetzt ein Load Balancer?

Wenn ein Besucher auf ihre Webseite geht, tippt er eine URL wie „www.suesseformel1frisuren.ch“ in den Browser. Der Domain Name Server (DNS) schaut dann in seinem Verzeichnis und findet die IP Adresse des Servers, etwa „200.0.0.121“, welche er dem Besucher zurückgibt. Das nennt man DNS Lookup.

Der DNS Server kann nun mehrere Adressen für eine URL speichern. Jede Adresse steht dann für einen Server im Cluster. Kommt nun eine Anfrage rein, schickt der DNS Server die Adresse des ersten Servers zurück. Bei der nächsten Anfrage die des zweiten Servers, dann des dritten, dann wieder der erste und so weiter. Das ist die Round Robin-Methode.

200.0.0.121
200.0.0.122
200.0.0.123

Was ist der Vorteil dieser Methode?

Der Vorteil davon ist, dass neue Server ganz einfach der Konfiguration hinzugefügt werden können.

Was ist der Nachteil bei der Server Affinität?

Server Affinität ist die Fähigkeit, die Benutzeranfragen an einen bestimmten Server zu senden. Ein Nachteil dieser Methode ist es nämlich, dass mehrere Anfrage des gleichen Benutzers an verschiedene Server geschickt werden können. Das HTTP Protokoll ist stateless, zwei aufeinanderfolgende Anfragen wissen nichts voneinander. Um die Kontrolle über die Session eines Benutzers zu behalten, kann der Server eine der folgenden Methoden verwenden:

1. Cookies
2. Versteckte Felder
3. URL Rewriting

Das Prinzip ist dabei jeweils dasselbe: Wenn ein Benutzer eine erste Anfrage macht, erstellt der Server ein Token, welches diesen Benutzer identifiziert. Dieses Token wird dann an den Benutzer geliefert, und dieser schickt immer das gleiche Token bei folgenden Anfragen. Somit kann der Load Balancer die Anfragen des gleichen Tokens immer an den gleichen Server schicken.

Ein Problem hierbei ist allerdings, dass der Browser die IP Adresse des Servers cached. Wenn dieser Cache abläuft, macht der Browser eine neue Anfrage und erhält gegebenfalls eine andere IP als vorher.

Was ist der Nachteil bei der hohen Verfügbarkeit?

Hat man einen Cluster mit 5 Servern und einer dieser Server geht offline, kann es dennoch vorkommen, dass Anfragen an diesen Server geschickt werden. Um dies zu verhindern prüfen moderne Router regelmässig, ob die Server noch angesprochen werden können.

Gibt es noch andere Load Balancing Algorithmen?

Ja, statt eines Round Robins könnte man etwa wählen, dass jeweils derjenige Server die nächste Anfrage erhält, welcher momentan am wenigsten offene Verbindungen zu Clients hat.

Oder man konfiguriert ein IP Hashing, bei dem man anhand der IP Adresse des Benutzers feststellt, an welchen Server er weitergeleitet wird.

Hardware und Software Load Balancers

Bei Load Balancers gibt es Lösungen als Hardware wie auch als Software.

Ein Hardware Load Balancer hat etwa den Vorteil, dass er selber eine virtuelle Ip Adresse besitzt, die er der Aussenwelt zeigen kann. Diese virtuelle Ip repräsentiert quasi den gesamten Cluster. Kommt nun eine neue Anfrage rein, überschreibt der Load Balancer den Request Header mit der effektiven Adresse eines Servers.

Der Vorteil ist hier, dass man Server einfach entfernen kann und nicht Gefahr läuft, dass dennoch ein Benutzer auf diesen Server connected – Schliesslich wird der gesamte Cluster durch die eine virtuelle IP repräsentiert. Das Problem ist, dass Hardware Load Balancer nicht in gesicherten HTTPS Verbindungen laufen, weil dort die Nachrichten SSL-verschlüselt sind und den Load Balancer daran hindern, auf die Informationen zuzugreifen. Die Server Affinität ist somit bei HTTPS nicht gegeben. Für die Entschlüsslung müsste ein Web Server Proxy vor den Cluster gehängt werden.

Software Load Balancer werden auch Application Delivery Controller (ADC) genannt, welche gut mit Virtual Appliances umgehen können – Also etwa ein Betriebssystem, Tomcat und Webapplikation als geschnürtes Paket.

Momentan mal! Virtual Applicances? Huh?

Genau. Am Anfang habe ich das einfachste Beispiel gemacht: Sie kaufen einen physischen Server, stellen ihn in einen Raum und installieren zum Beispiel eine Linux Distribution mit Tomcat auf dieser Maschine. Dort läuft dann ihre Webapplikation.

In den heutigen Firmen ist dieses einfache Beispiel aber mittlerweile ziemlich entfernt von der Realität. Stellen Sie sich vor, eine Firma müsste für jede Webapplikation eine bis mehrere physische Server unterhalten. Das wäre ein viel zu grosser Aufwand.

Stattdessen läuft heute mittlerweile so ziemlich alles virtualisiert – So virtualisiert, wie man sich das kaum vorstellen kann. Eine grosse Firma hat etwa eine gewisse Serverlandschaft zur Verfügung. Auf dieser Serverlandschaft laufen alle ihre Webapplikationen – Aber alle stets virtualisiert. Ihre Formel 1 Frisuren-Applikation ist dann etwa nur ein virtuelles Image, in dem schon alles enthalten ist: Applikation, Betriebssystem und Tomcat. So kann man die Applikation auf beliebig vielen Servern starten und wieder verschwinden lassen, ganz wie man es benötigt (Punkt Skalierbarkeit).

Liefert man eine neue Version seiner Applikation, macht das Entwicklungsteam oftmals gleich das Gesamtpaket (also das ganze Image) für den Betrieb bereit, welcher dieser nur noch deployen kann. Entgegen meinem Artikel Was ist DevOps? ist die Entwicklung und der Betrieb oftmals noch in verschiedenen Teams. Die Entwickler entwickeln, die Betriebsleute installieren.

Nun, es geht sogar noch weiter, aber ich muss wohl langsam zum Ende kommen. Weitere interessante Themen sind etwa Docker, bei dem man die Applikation auch noch vom Betriebssystem abkoppelt, oder serverless code, bei dem alles irgendwo in der Cloud läuft. Aber diese Geschichte erzähle ich ein anderes Mal.