© zffoto/Shutterstock.com
Cloud Compendium
Teil 3: CPU, Multiplexing, Netzwerk, Service Discovery und mehr

Nur das Beste für Container

In den vergangenen Jahren haben wir unsere Anwendungen in Container verpackt, um sie zu isolieren und leicht auslieferbar zu machen. Nun kämpfen wir damit, Anwendungen mit persistenten Daten in Containern zu betreiben, um sie fehlertoleranter und skalierbarer zu machen. Daher betreiben wir Datenbanken meistens in separaten Clustern, weil es noch relativ schwer ist, sie sinnvoll in Containern zu orchestrieren. Das bedeutet allerdings, dass wir unsere gesamte Infrastruktur nicht optimal ausnutzen und Skalierungseffekte zwischen zustandslosen und zustandsbehafteten Anwendungen verschenken. Aber was bedeutet es eigentlich, eine Datenbank in einen Container zu stecken?

Johannes Unterstein


ArtikelserieTeil 1: Motivation, Fehler und Beefy ServerTeil 2: Speicheroptionen und Back-upsTeil 3: CPU, Multiplexing, Netzwerk, Service Discovery und mehrTeil 4: Deep-dive in die Containerorchestrierung und Kubernetes

Im vorigen Teil haben wir uns mit verschiedenen Arten von Speicher, Clustern und Back-ups beschäftigt. Wir haben diskutiert, wie wir Technologien aus diesen drei Bereichen sinnvoll kombinieren können, um eine möglichst robuste und fehlertolerante, aber trotzdem performante Datenbank zu betreiben. In diesem Teil wollen wir uns nun einige Aspekte genauer anschauen und ihre Performanz vergleichen, um zu sehen, wie stark sich die beschriebenen Eigenarten wirklich in unseren Umgebungen auswirken. Weiterhin wollen wir diskutieren, welche Auswirkungen Container auf die Nutzung von CPU beziehungsweise Arbeitsspeicher haben, und über was wir uns noch Gedanken machen sollten, wenn wir Container in Produktion bewegen wollen.

Genug Palaver, her mit den Zahlen!

Warum es sinnvoll erscheint, Overlay 2 im Vergleich zu Overlay 1 zu verwenden, haben wir bereits zuvor erörtert. Das Schöne ist, dass wir Docker mit dem Storage-Treiber konfigurieren können, den wir gerne hätten, und auf diese Weise wunderbar die Performanz miteinander vergleichen können. Welcher Storage-Treiber aktuell konfiguriert ist, sieht man übrigens, wenn man docker info ausführt.

Unser Testkandidat ist ein Docker Image mit dem Namen neo-technology/overlay-pull, das die Größe von 1,17 GB hat. In Abbildung 1 sehen wir die Ergebnisse von jeweils drei Messungen, die ich mit dem Befehl time docker pull neo-technology/overlay-pull durchgeführt habe. Die Messung fand auf meinem Laptop statt, und die Images befanden sich in der Docker Registry von GCP. Es wurden immer abwechselnd die Werte von Overlay 1 und Overlay 2 gemessen und kein Netflix oder YouTube währenddessen an- oder abgeschaltet. Wir sehen also, dass wir von ungefähr zweieinhalb Minuten auf eine Minute heruntergekommen sind, allein bei einem docker pull. Die Performanz verhält sich ähnlich, wenn wir schreibende Transaktionen gegen die Datenbank durchführen, die Overlay 1 bzw. Overlay 2 verwendet.

Abb. 1: Messergebnisse „time docker pull neo-technology/overlay-pull“

Cluster, lokaler Speicher und entfernter Speicher

Es macht also einen Unterschied, ob ich Overlay 1 oder Overlay 2 benutze. Aber wie verhält sich das Ganze denn nun im Vergleich zu entferntem Speicher und Clustern? Für diesen Zweck habe ich im Zuge einer Vortragsvorbereitung vor...

Cloud Compendium
Teil 3: CPU, Multiplexing, Netzwerk, Service Discovery und mehr

Nur das Beste für Container

In den vergangenen Jahren haben wir unsere Anwendungen in Container verpackt, um sie zu isolieren und leicht auslieferbar zu machen. Nun kämpfen wir damit, Anwendungen mit persistenten Daten in Containern zu betreiben, um sie fehlertoleranter und skalierbarer zu machen. Daher betreiben wir Datenbanken meistens in separaten Clustern, weil es noch relativ schwer ist, sie sinnvoll in Containern zu orchestrieren. Das bedeutet allerdings, dass wir unsere gesamte Infrastruktur nicht optimal ausnutzen und Skalierungseffekte zwischen zustandslosen und zustandsbehafteten Anwendungen verschenken. Aber was bedeutet es eigentlich, eine Datenbank in einen Container zu stecken?

Johannes Unterstein


ArtikelserieTeil 1: Motivation, Fehler und Beefy ServerTeil 2: Speicheroptionen und Back-upsTeil 3: CPU, Multiplexing, Netzwerk, Service Discovery und mehrTeil 4: Deep-dive in die Containerorchestrierung und Kubernetes

Im vorigen Teil haben wir uns mit verschiedenen Arten von Speicher, Clustern und Back-ups beschäftigt. Wir haben diskutiert, wie wir Technologien aus diesen drei Bereichen sinnvoll kombinieren können, um eine möglichst robuste und fehlertolerante, aber trotzdem performante Datenbank zu betreiben. In diesem Teil wollen wir uns nun einige Aspekte genauer anschauen und ihre Performanz vergleichen, um zu sehen, wie stark sich die beschriebenen Eigenarten wirklich in unseren Umgebungen auswirken. Weiterhin wollen wir diskutieren, welche Auswirkungen Container auf die Nutzung von CPU beziehungsweise Arbeitsspeicher haben, und über was wir uns noch Gedanken machen sollten, wenn wir Container in Produktion bewegen wollen.

Genug Palaver, her mit den Zahlen!

Warum es sinnvoll erscheint, Overlay 2 im Vergleich zu Overlay 1 zu verwenden, haben wir bereits zuvor erörtert. Das Schöne ist, dass wir Docker mit dem Storage-Treiber konfigurieren können, den wir gerne hätten, und auf diese Weise wunderbar die Performanz miteinander vergleichen können. Welcher Storage-Treiber aktuell konfiguriert ist, sieht man übrigens, wenn man docker info ausführt.

Unser Testkandidat ist ein Docker Image mit dem Namen neo-technology/overlay-pull, das die Größe von 1,17 GB hat. In Abbildung 1 sehen wir die Ergebnisse von jeweils drei Messungen, die ich mit dem Befehl time docker pull neo-technology/overlay-pull durchgeführt habe. Die Messung fand auf meinem Laptop statt, und die Images befanden sich in der Docker Registry von GCP. Es wurden immer abwechselnd die Werte von Overlay 1 und Overlay 2 gemessen und kein Netflix oder YouTube währenddessen an- oder abgeschaltet. Wir sehen also, dass wir von ungefähr zweieinhalb Minuten auf eine Minute heruntergekommen sind, allein bei einem docker pull. Die Performanz verhält sich ähnlich, wenn wir schreibende Transaktionen gegen die Datenbank durchführen, die Overlay 1 bzw. Overlay 2 verwendet.

Abb. 1: Messergebnisse „time docker pull neo-technology/overlay-pull“

Cluster, lokaler Speicher und entfernter Speicher

Es macht also einen Unterschied, ob ich Overlay 1 oder Overlay 2 benutze. Aber wie verhält sich das Ganze denn nun im Vergleich zu entferntem Speicher und Clustern? Für diesen Zweck habe ich im Zuge einer Vortragsvorbereitung vor...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang