diff options
author | Cedric Spindler <cedric.spindler@gmail.com> | 2019-09-10 19:06:27 +0200 |
---|---|---|
committer | Cedric Spindler <cedric.spindler@gmail.com> | 2019-09-10 19:06:27 +0200 |
commit | f5a900cbd90e324da52087a93237563f7815c087 (patch) | |
tree | de1e05ba24e8aa31df3779254a026b793c811322 /Infrastruktur | |
parent | 325dc086f73c010188532f2fc9d1792db75cd78c (diff) |
Fit images to container
Diffstat (limited to 'Infrastruktur')
-rw-r--r-- | Infrastruktur/Hosting/kubernetes-and-ceph.mdwn | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/Infrastruktur/Hosting/kubernetes-and-ceph.mdwn b/Infrastruktur/Hosting/kubernetes-and-ceph.mdwn index 9b92956b..7f2ab070 100644 --- a/Infrastruktur/Hosting/kubernetes-and-ceph.mdwn +++ b/Infrastruktur/Hosting/kubernetes-and-ceph.mdwn @@ -14,11 +14,11 @@ Die Grundlage des Hostingsystems basiert darauf, dass unsere Dienste nicht auf e 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"]] +[[!img resources-to-manage.png align="left" size="" class="img-fill-container" 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"]] +[[!img kubernetes-service.png align="left" size="" class="img-fill-container" 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. @@ -32,17 +32,17 @@ Kubernetes verwaltet die Ausführung gewünschter Dienste auf einer Ansammlung v ## Ü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"]] +[[!img kubernetes-overview.png align="left" size="" class="img-fill-container" 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."]] +[[!img kubernetes-launching.png align="left" size="" class="img-fill-container" 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."]] +[[!img kubernetes-outage.png align="left" size="" class="img-fill-container" 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. @@ -52,17 +52,17 @@ ceph verwaltet die Speicherung beliebiger Daten auf einer Ansammlung von Festpla ## Übersicht -[[!img ceph-overview.png align="left" size="" alt="Übersicht über ceph mit den Manager-Diensten und den Festplatten, auf welchen Daten gespeichert werden"]] +[[!img ceph-overview.png align="left" size="" class="img-fill-container" 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"]] +[[!img ceph-writing.png align="left" size="" class="img-fill-container" 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."]] +[[!img ceph-outage.png align="left" size="" class="img-fill-container" 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. |