SerrNovik - Fotolia

Zwischen Bare-Metal und virtuellen Maschinen als Container-Host wählen

Container können sowohl auf Bare-Metal-Server als auch innerhalb virtueller Maschinen ausgeführt werden. Beide Ansätze bieten Vor- und Nachteile.

Die Vorteile der Container-Virtualisierung sind mittlerweile jeder IT-Abteilung bekannt. Aber wie sieht es mit der für Container am besten geeigneten Infrastruktur aus? Sind Bare-Metal-Server die bessere Hosting-Plattform für Docker und andere Container-Umgebungen oder sollte man hierfür doch auf virtuelle Maschinen setzen?

Die Antwort hängt wie so oft von vielen verschiedenen Faktoren ab. In diesem Artikel beleuchten wir die Vor- und Nachteile der Bare-Metal-Bereitstellung sowie von virtuellen Maschinen als Container-Host und konzentrieren uns dabei auf Docker. Im Großen und Ganzen lassen sich die Schlüsse aber auch auf andere Container-Plattformen übertragen.

Bare-Metal oder virtuelle Maschine als Virtualisierungs-Host?

Die unterschiedlichen Vor- und Nachteile von Bare-Metal-Bereitstellungen gegenüber virtuellen Maschinen als Virtualisierungs-Plattform dürften an sich nichts Neues sein. CTOs beschäftigen sich mit dieser Frage, seit die Virtualisierung Anfang der 2000er Jahre in Rechenzentren einzog, also lange bevor irgendjemand je von Docker gehört hätte.

In aller Kürze bietet die Bare-Metal-Bereitstellung folgende Vorteile:

  • Eine höhere Performance, weil keine Systemressourcen für die Hardwareemulation verwendet werden müssen.
  • Die voll Nutzbarkeit der gesamten Ressourcen, weil keine Ressourcen für Spitzenzeiten vorgehalten werden müssen, die abseits der Hochphase ungenutzt bleiben.
  • Einfachere Verwaltung, weil es weniger Hosts, Netzwerke und Disks in der Infrastruktur gibt.

Virtuelle Maschinen wiederum bringen andere Vorteile mit sich:

  • Die Möglichkeit, Applikationen einfach zwischen Hosts zu migrieren, indem das VM-Image von einem Server zum anderen übertragen wird.
  • Die Isolierung von Applikationen, die in unterschiedlichen virtuellen Maschinen ausgeführt werden, was zu einer höheren Sicherheit führt und die Komplexität reduzieren kann.
  • Die Möglichkeit, über die gesamte Infrastruktur eine konsistente Softwareumgebung aufrecht zu erhalten, auch wenn die zugrundeliegenden Hosts aus unterschiedlichen physischen Servern bestehen.

Virtuelle Maschinen bedeuten aber auch den einen oder anderen Nachteil:

  • Server werden oft nicht effizient ausgenutzt. Wenn einem Server-Host beispielsweise Speicher zugewiesen wird, um ein VM-Disk-Image zu erstellen, dann ist dieser Speicherplatz natürlich nicht mehr für andere Zwecke verfügbar – auch wenn die erstellte Disk gar nicht den gesamten zugewiesenen Speicherplatz benötigt.
  • Virtuelle Maschinen können nicht direkt auf physische Hardware zugreifen. Wenn beispielsweise bestimmte Compute-Aufgaben einer virtuellen Maschine an die GPU des Hosts ausgelagert werden soll, dann ist das nicht ohne weiteres möglich, weil die virtuelle Maschine über die Virtualisierungs-Schicht von der zugrundeliegenden Hardware abstrahiert wurde.
  • Virtuelle Maschinen sind in der Regel nicht so leistungsstark wie physische Server, weil für das Emulieren der Hardware der virtuellen Server Ressourcen benötigt werden.

Moderne Virtualisierungs-Lösungen bieten Möglichkeiten, diese Einschränkungen virtueller Maschinen weitgehend aufzuheben. So kann beispielsweise ein dynamisches Disk-Image erstellt werden, dessen Speichergröße sich dem Wachstum der virtuellen Maschine anpasst. Auf diese Weise wird verhindert, dass Speicherplatz auf dem Host unnötig geblockt wird, noch bevor er tatsächlich von einem Gast genutzt wird. Genauso können auch Pass-Through-Konfigurationen eingerichtet werden, um virtuellen Maschinen direkten Zugang zur physischen Hardware des Hosts zu gewähren.

Weitere Artikel zur Container-Virtualisierung:

Kostenloses E-Handbook zur Container-Virtualisierung.

Überfällige Fragen im Zusammenhang mit Containern.

Mit CentOS und systemd zum ersten Linux-Container.

Damit erzielt man aber nicht immer das gewünschte Ergebnis, manche dieser Funktionen lassen sich beispielsweise nicht auf allen Host- oder Gast-Betriebssystemen einsetzen, zudem entstehen so zusätzliche administrative Lasten. Wenn eine Anwendung am besten auf Bare-Metal-Server läuft, dann sollte man sie auch ganz einfach auf Bare-Metal-Server betreiben.

Oder aber man betreibt die Applikation innerhalb eines Containers auf einem Bare-Metal-Server, um so das Beste aus beiden Welten zu erhalten.

Container auf Bare-Metal-Hosts

Wenn Container auf Bare-Metal-Hosts bereitgestellt werden, dann lassen sich viele Vorteile virtueller Maschinen realisieren, ohne dabei aber die Nachteil der Virtualisierung in Kauf nehmen zu müssen. Werden  Container auf Bare-Metal-Server ausgeführt, gibt es folgende Vorteile:

  • Zugriff auf die physische Hardware, ohne dabei auf Pass-Through-Konfigurationen Rückgriff nehmen zu müssen, weil die Anwendung auf dem gleichen Betriebssystem ausgeführt wird, das den Host-Server betreibt.
  • Optimale Ausnutzung der Systemressourcen. Auch wenn man natürlich dedizierte Obergrenzen für Compute-, Storage- und Netzwerkressourcen festlegen kann, ist dies bei Containern selten wirklich nötig. Ein Container-Host ist selbstständig in der Lage, seine Ressourcen je nach Bedarf an die gehosteten Container weiterzugeben.
  • Bare-Metal-Performance für alle darauf ausgeführten Anwendungen, weil keine Ressourcen für die Hardwareemulation benötigt werden.

Gleichzeitig bietet ein Bare-Metal-Container-Host aber auch folgende Vorteile, die sonst nur über virtuelle Maschinen möglich sind:

  • Die Möglichkeit, Anwendungen innerhalb portabler Umgebungen bereitzustellen, die sich leicht von einem Host zu einem anderen verschieben lassen.
  • App-Isolierung. Natürlich schaffen Container keine so isolierte Umgebung wie virtuelle Maschinen, aber es ist durchaus möglich, die Interaktion der darauf ausgeführten Anwendungen miteinander zu unterbinden und die Rechte und Ressourcenzugriffe eines jeden Containers einzuschränken.

Kurz gesagt sind Container auf Bare-Metal-Hardware so etwas wie die Quadratur des Kreises. Man erhält damit alle Vorteile der Bare-Metal-Virtualisierung, während sich gleichzeitig viele Vorteile virtueller Maschinen realisieren lassen.

Gründe gegen den Einsatz von Bare-Metal-Hosts

Bei all den Vorzügen kann man sich natürlich fragen, warum man dann Container nicht einfach immer auf Bare-Metal-Server bereitstellen sollte. Wenn dieser Ansatz das Beste aus beiden Welten vereint, warum dann einen anderen Weg gehen? In manchen Fällen gibt es aber auch Nachteile, wenn Container auf Bare-Metal statt innerhalb virtueller Maschinen gehostet werden:

  • Das Upgrade physischer Server ist komplex. Wenn die Bare-Metal-Server durch neuere ersetzt werden sollen, dann muss auch die komplette Container-Umgebung auf den neuen Servern völlig neu aufgesetzt werden. Wird die Container-Umgebung stattdessen über ein VM-Image erstellt, dann kann das Image einfach von einem alten auf einen neuen Server migriert werden.
  • Die meisten Clouds setzen virtuelle Maschinen voraus. Natürlich gibt es auch Bare-Metal-Hosts wie Rackspace OnMetal oder Oracles Bare Metal Cloud Services, im Großen und Ganzen bieten Public-Cloud-Anbieter aber vor allem virtuelle Maschinen an. Wenn auf diesen Plattformen Container eingesetzt werden sollen, dann ist dies eben lediglich über virtuelle Maschinen möglich.
  • Container-Plattformen unterstützen nicht alle Hardware- und Softwarekonfigurationen. Heutzutage lässt sich fast jedes beliebige Betriebssystem über Virtualisierungs-Plattformen wie VMware oder KVM hosten. Und die Virtualisierungs-Plattformen wiederum können auf nahezu jedem Host-Betriebssystem oder Server ausgeführt werden.
  • Bei Docker sieht die Sache aber etwas anders aus. Docker läuft als Bare-Metal-Bereitstellung lediglich auf Linux und auf bestimmten Windows-Server-Versionen. Wenn man also Docker auf Bare-Metal-Server mit Windows Server 2012 betreiben möchte, dann müsste man zunächst eine virtuelle Maschine auf dem Windows-Host installieren.
  • Linux-Container laufen nicht auf einem Windows-Host. Aus einem ähnlichen Grund können Linux-Container nur auf einem Linux-Host ausgeführt werden. Wenn also ein Bare-Metal-Windows-Server zum Hosten von Docker-Containern und Linux-Applikationen genutzt werden soll, dann muss zunächst eine Linux-VM auf dem Windows Server installiert werden, die dann die Umgebung zum Docker-Hosting beinhaltet.
  • Bare-Metal-Server bieten keine Rollback-Funktion. Eine äußerst nützliche Funktion in den meisten modernen Virtualisierungs-Plattformen ist die Möglichkeit, Snapshots einer virtuellen Maschine anzufertigen und dann zu einem späteren Zeitpunkt ein Rollback zu diesem Zustand durchzuführen. Mit Bare-Metal-Server ist dies nicht möglich. Auch wenn man technisch gesehen Rollback-Features des Betriebssystems oder Dateisystems einsetzen könnte, sind diese bei Weitem nicht so nahtlos integriert und bequem zu nutzen wie Snapshots auf VM-Ebene. Die Idee von Snapshots und Rollbacks ergibt für Container wenig Sinn. Container sind ihrem Wesen nach äußerst kurzlebig, daher gibt es hier kaum etwas, was in einen früheren Zustand zurückversetzt werden könnte. Die einzige Möglichkeit, in Container-Umgebungen Rollbacks zu verwenden, führt damit über das Hosten der Container auf virtuellen Maschinen.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!

Erfahren Sie mehr über Cloud Computing

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close