Kleine Einführungsseite zu ceph und Kubernetes als Konzept.

17 files changed, 75 insertions, 0 deletions

diff --git a/Infrastruktur/Hosting/ceph-outage.dia b/Infrastruktur/Hosting/ceph-outage.dia
new file mode 100644
index 00000000..5626b329
--- /dev/null
+++ b/Infrastruktur/Hosting/ceph-outage.dia
diff --git a/Infrastruktur/Hosting/ceph-outage.png b/Infrastruktur/Hosting/ceph-outage.png
new file mode 100644
index 00000000..cbe59e17
--- /dev/null
+++ b/Infrastruktur/Hosting/ceph-outage.png
diff --git a/Infrastruktur/Hosting/ceph-overview.dia b/Infrastruktur/Hosting/ceph-overview.dia
new file mode 100644
index 00000000..98001fbb
--- /dev/null
+++ b/Infrastruktur/Hosting/ceph-overview.dia
diff --git a/Infrastruktur/Hosting/ceph-overview.png b/Infrastruktur/Hosting/ceph-overview.png
new file mode 100644
index 00000000..4935409a
--- /dev/null
+++ b/Infrastruktur/Hosting/ceph-overview.png
diff --git a/Infrastruktur/Hosting/ceph-writing.dia b/Infrastruktur/Hosting/ceph-writing.dia
new file mode 100644
index 00000000..bdc6ab17
--- /dev/null
+++ b/Infrastruktur/Hosting/ceph-writing.dia
diff --git a/Infrastruktur/Hosting/ceph-writing.png b/Infrastruktur/Hosting/ceph-writing.png
new file mode 100644
index 00000000..f918f3cc
--- /dev/null
+++ b/Infrastruktur/Hosting/ceph-writing.png
diff --git a/Infrastruktur/Hosting/kubernetes-and-ceph.mdwn b/Infrastruktur/Hosting/kubernetes-and-ceph.mdwn
new file mode 100644
index 00000000..9b92956b
--- /dev/null
+++ b/Infrastruktur/Hosting/kubernetes-and-ceph.mdwn
@@ -0,0 +1,75 @@
+[[!meta title="Kubernetes und Ceph"]]
+
+Wir benutzen für das Hosting der Dienste der Starship Factory die Dienste [Kubernetes](https://kubernetes.io/) und [ceph](https://ceph.io/). Für Details bitte die Dokumentation der jeweiligen Dienste konsolutieren, aber hier gibt es eine Übersicht der Funktionalität.
+
+# Dienste auf verteilten Serversystemen
+
+Die Grundlage des Hostingsystems basiert darauf, dass unsere Dienste nicht auf einem Server laufen, sondern auf vielen. Dies hat verschiedene Gründe, die auch in den vergangenen Erfahrungen der Starship Factory begründet sind:
+
+* **Ausfallsicherheit**: der Ausfall eines einzelnen Servers führt nicht mehr zwingend dazu, dass die Dienste (Webseite etc) der Starship Factory nicht mehr funktionieren.
+* **Kapazität**: alleine das Blog benötigt im Moment (September 2019) einen gesamten Server, um die Webseite darzustellen. Es gibt allerdings noch andere Dienste, die wir betreiben wollen.
+* **Mean Time To Recovery**: im Falle eines Serverausfalls haben wir früher oft tagelang keine funktionierenden Dienste (Webseite) etc gehabt, da jemand die Zeit finden musste, die Daten aus irgendwelchen Backups über Leitungen mit langsamem Upload wieder auf einen anderen Server einzuspielen. Mit einem guten verteilten Serversystem ist die Webseite nach einer Minute wieder online.
+
+## Grundlagen
+
+Jeder Server kann im Prinzip als eine Ansammlung von "Ressourcen" angesehen werden. Er verfügt über einen (oder mehrere) Prozessor(en) mit einer bestimmten Anzahl Kerne, eine bestimmte Menge an Arbeitsspeicher (RAM) und einer Ansammlung von Festplatten und/oder SSDs.
+
+[[!img resources-to-manage.png align="left" size="" alt="Ein Server als eine Menge an Ressourcen"]]
+
+In unserem Falle werden vereinfacht gesagt die CPU-Kerne sowie der Arbeitsspeicher des Servers durch ein System namens "Kubernetes" verwaltet, während Datenspeicher (Festplatten, SSDs, etc) durch ein anderes System namens "ceph" verwaltet werden.
+
+[[!img kubernetes-service.png align="left" size="" alt="Ein Dienst erhält seine Ressourcen von Kubernetes und Ceph"]]
+
+Ein Dienst, so wie zum Beispiel der Datenbankserver [PostgreSQL](https://postgresql.org/), konsumiert hingegen eine bestimmte Menge an Ressourcen.
+
+In unserem Beispiel gehen wir davon aus, dass wir eine einzige Instanz ausführen wollen, und auf dem darunter liegenden Server 2 CPU-Kerne und 4 Gigabyte RAM für PostgreSQL reservieren. Diese werden von Kubernetes zur Verfügung gestellt, indem PostgreSQL auf einem Server gestartet wird, welcher noch genügend Ressourcen zur Verfügung hat.
+
+Allerdings muss die Datenbank auch irgendwo gespeichert werden. Das geschieht mit dem Speicherverwaltungssystem "ceph", welches in diesem Fall für PostgreSQL 1 Terabyte zur Verfügung stellt, um die Datenbank permanent abzuspeichern. Die Datenbank wird dabei nicht auf dem lokalen Server gespeichert, sondern im "ceph"-System (siehe unten).
+
+# Kubernetes
+
+Kubernetes verwaltet die Ausführung gewünschter Dienste auf einer Ansammlung von Servern.
+
+## Übersicht
+
+[[!img kubernetes-overview.png align="left" size="" alt="Übersicht über Kubernetes mit den Master-Diensten und den Servern, welche die tatsächlichen Dienste ausführen"]]
+
+Dazu bedient es sich einer Liste von sogenannten "Master"-Prozessen (API server, Controller Manager, Scheduler), welche die Ausführung der Dienste im Serververbund (Cluster) überwachen. Diese Master stehen im Kontakt miteinander und stellen sicher, dass jeder die komplette Übersicht hat, was der aktuelle Zustand des Clusters ist. Jeder der Master ist gleichberechtigt, so dass es egal ist, welchem Master man eine Anfrage sendet.
+
+[[!img kubernetes-launching.png align="left" size="" alt="Ein Benutzer sendet eine Anfrage, 3 Dienste auf dem Kubernetes-Cluster auszuführen. Die Kubernetes-Master übernehmen die Verteilung der Dienste, die Kubernetes-Nodes übernehmen die tatsächliche Ausführung."]]
+
+Möchte man nun einen Dienst auf dem Kubernetes-Cluster starten, sendet man eine entsprechend formatierte Anfrage an einen Kubernetes-Master. Dieser ermittelt mögliche Server, auf welchen der Dienst ausgeführt werden könnte, und instruiert diese, den Dienst so wie vorkonfiguriert zu starten.
+
+Die betroffenen Server finden dann die notwendigen Ressourcen, führen etwaige Konfigurationsschritte aus und starten den Dienst, welcher ab dann im Cluster verfügbar ist.
+
+[[!img kubernetes-outage.png align="left" size="" alt="Ein Server ist nicht verfügbar. Der Kubernetes Master findet einen anderen Server, um den Dienst künftig auszuführen."]]
+
+Fällt nun einer der Server im Kubernetes-Cluster aus, sucht der Kubernetes Master selbstständig für jeden betroffenen Dienst einen anderen Server aus, auf welchem er stattdessen ausgeführt werden könnte.
+
+# ceph
+
+ceph verwaltet die Speicherung beliebiger Daten auf einer Ansammlung von Festplatten in verschiedenen Servern.
+
+## Übersicht
+
+[[!img ceph-overview.png align="left" size="" alt="Übersicht über ceph mit den Manager-Diensten und den Festplatten, auf welchen Daten gespeichert werden"]]
+
+Ähnlich wie Kubernetes ist ceph aufgeteilt in sogenannte Manager-Prozesse (Manager, Monitor, Metadata Server) und die einzelnen Festplatten (Object Storage Daemons). Die Manager-Prozesse stellen die sichere Speicherung von Daten innerhalb des Clusters sicher und stellen dabei sicher, dass jeder Manager eine Übersicht über den kompletten aktuellen Stand des Clusters hat. Auch hier sind die Manager gleichberechtigt und gleichzeitig aktiv.
+
+[[!img ceph-writing.png align="left" size="" alt="Schreibvorgänge von Benutzern von Ceph werden an mehrere Festplatten verteilt"]]
+
+Schreibt nun eine Benutzerin (oder ein Dienst) Daten in das Ceph-System, fragt sie beim Manager, welche Festplatten noch genug freie Kapazität haben. Dann sendet sie die Daten an jeden der Server, damit dieser es auf die jeweilige Festplatte schreiben kann. Der Manager stellt dabei sicher, dass die Daten nicht auf mehreren Festplatten auf demselben Server gespeichert werden (oder auf Wunsch auch in unterschiedlichen Räumen / Datacentern / Ländern / was auch immer).
+
+Als Resultat existieren nun 3 Kopien der Daten im Cluster. Zum Lesen kann die Benutzerin oder der Dienst einen beliebigen der drei Server anfragen.
+
+[[!img ceph-outage.png align="left" size="" alt="Ein Server oder eine Festplatte ist nicht verfügbar. Der Ceph Manager instruiert einen anderen Server, eine neue Kopie der Daten anzufertigen."]]
+
+Fällt nun ein Server oder eine Festplatte aus, schreitet der Manager-Prozess ein und instruiert einen anderen Server, auf einer anderen Festplatte eine neue Kopie der Daten anzufertigen.
+
+## Arten von Datenspeichern
+
+Daten können in Ceph auf verschiedene Arten gespeichert werden. Dadurch können verschiedene Use-Cases abgedeckt werden.
+
+* Rados Block Devices funktionieren wie virtuelle Festplatten. Sie können von genau einem Dienst verwendet werden und funktionieren quasi transparent als Speichermedien.
+* Das Rados-System erlaubt das Lesen und Schreiben von Dateien ("Objekten") mittels einer speziellen API (i.e. man muss Dienste speziell dafür entwickeln). Je nach Design der Programme können beliebig viele Dienste darauf zugreifen.
+* Das Ceph File System (CephFS) erlaubt das Speichern vieler Dateien in einer Art virtueller Festplatte, auf welche viele Dienste gleichzeitig zugreifen können; es ist jedoch bedeutend langsamer als Rados Block Devices und verbraucht mehr CPU und RAM.
diff --git a/Infrastruktur/Hosting/kubernetes-launching.dia b/Infrastruktur/Hosting/kubernetes-launching.dia
new file mode 100644
index 00000000..5e561b44
--- /dev/null
+++ b/Infrastruktur/Hosting/kubernetes-launching.dia
diff --git a/Infrastruktur/Hosting/kubernetes-launching.png b/Infrastruktur/Hosting/kubernetes-launching.png
new file mode 100644
index 00000000..5314232b
--- /dev/null
+++ b/Infrastruktur/Hosting/kubernetes-launching.png
diff --git a/Infrastruktur/Hosting/kubernetes-outage.dia b/Infrastruktur/Hosting/kubernetes-outage.dia
new file mode 100644
index 00000000..92b2a902
--- /dev/null
+++ b/Infrastruktur/Hosting/kubernetes-outage.dia
diff --git a/Infrastruktur/Hosting/kubernetes-outage.png b/Infrastruktur/Hosting/kubernetes-outage.png
new file mode 100644
index 00000000..06f6a535
--- /dev/null
+++ b/Infrastruktur/Hosting/kubernetes-outage.png
diff --git a/Infrastruktur/Hosting/kubernetes-overview.dia b/Infrastruktur/Hosting/kubernetes-overview.dia
new file mode 100644
index 00000000..c2036c80
--- /dev/null
+++ b/Infrastruktur/Hosting/kubernetes-overview.dia
diff --git a/Infrastruktur/Hosting/kubernetes-overview.png b/Infrastruktur/Hosting/kubernetes-overview.png
new file mode 100644
index 00000000..313bf19a
--- /dev/null
+++ b/Infrastruktur/Hosting/kubernetes-overview.png
diff --git a/Infrastruktur/Hosting/kubernetes-service.dia b/Infrastruktur/Hosting/kubernetes-service.dia
new file mode 100644
index 00000000..cee81a31
--- /dev/null
+++ b/Infrastruktur/Hosting/kubernetes-service.dia
diff --git a/Infrastruktur/Hosting/kubernetes-service.png b/Infrastruktur/Hosting/kubernetes-service.png
new file mode 100644
index 00000000..d0f9ef3a
--- /dev/null
+++ b/Infrastruktur/Hosting/kubernetes-service.png
diff --git a/Infrastruktur/Hosting/resources-to-manage.dia b/Infrastruktur/Hosting/resources-to-manage.dia
new file mode 100644
index 00000000..fff99c5b
--- /dev/null
+++ b/Infrastruktur/Hosting/resources-to-manage.dia
diff --git a/Infrastruktur/Hosting/resources-to-manage.png b/Infrastruktur/Hosting/resources-to-manage.png
new file mode 100644
index 00000000..02e7ff27
--- /dev/null
+++ b/Infrastruktur/Hosting/resources-to-manage.png