nespix - stock.adobe.com
Containercluster auf Bare Metal für das App Hosting
Cluster für Anwendungscontainer lassen sich Bare Metal auf dedizierter HCI-Hardware hosten. Wir erklären, welche Anforderungen, Designs und Software-Stacks Sie dafür brauchen.
In DevOps- und IT-Engineering-Kreisen gibt es eine heiße Debatte um die beste Infrastruktur für Container, bei der drei Architekturoptionen zur Auswahl stehen: Private- versus Public-Cloud-Infrastruktur, Cloud-VM-Instanzen versus Container as a Service und Containerknoten auf VMs versus Bare-Metal-Server.
Letztere Frage – Bare-Metal-Containercluster oder die Containerknoten auf VMs (virtuellen Maschinen) – ist sowohl für Cloud-Betreiber als auch für die Unternehmens-IT relevant. Realistisch gesehen ist sie jedoch nur für Unternehmen mit privaten Containerclustern ein Thema, da Hyperscaler nach anderen Regeln spielen, als gewöhnliche IT-Abteilungen.
Die Entscheidung hängt davon ab, ob in Ihrem Szenario der Verwaltungskomfort und die Flexibilität von VMs wichtiger sind, oder die Einfachheit (insbesondere bei der Vernetzung) von Bare-Metal-Implementierungen. Wir erklären, für wen sich welche Variante besser eignet und welche Best Practices es für Bare-Metal-Containercluster gibt.
Argumente für und gegen virtuelle Maschinen und Bare-Metal-Container
Die Wahl zwischen VMs und Containern auf Bare Metal hängt häufig von der Art der Anwendung ab, die Sie ausführen möchten. Monolithische Legacy-Anwendungen, die für die Mainframe- oder Client-Server-Ära geschrieben und seitdem containerisiert wurden, können beispielsweise viele der Workload-Orchestrierungsfunktionen von Kubernetes nicht sinnvoll nutzen.
Hier ist es besser, VM-Cluster zu verwenden, bei denen Ausfallsicherheitsfunktionen wie Image-Snapshots und Workload-Migration (zum Beispiel mit vMotion) wertvolle Tools zur Verbesserung der Anwendungsverfügbarkeit sind und den Aufwand für den Betrieb mit zwei Virtualisierungsebenen rechtfertigen.
Im Gegensatz dazu sind Cloud- oder Container-native Anwendungen, die aus Microservices bestehen und für die Verteilung auf mehrere Containerknoten konzipiert sind, die geklont, neu gestartet und verschoben werden können, gut für das Hosten auf Bare-Metal-Umgebungen geeignet.
Anbieter von Containersoftware gewichten diese Vor- und Nachteile selbstverständlich abhängig von ihrer eigenen Systemarchitektur. VMware versucht beispielsweise stets, die Vorzüge von Kubernetes auf VMs hevorzustreichen. Der Anbieter hat beträchtlich Forschungs- und Entwicklungsressourcen in die zugrunde liegenden Technologie für sein Produkt Tanzu gesteckt.
Tanzu soll den Verwaltungsaufwand für VMs minimieren und die Integration von Kubernetes- und vSphere-Verwaltungsfunktionen über eine einzige Schnittstelle ermöglichen.
Der Leistungsunterschied zwischen VMs und Bare-Metal hängt von den Workloads ab
Um die Funktionsfähigkeit von VM-gehosteten Containern zu demonstrieren, führte VMware Tests an einer großen Java-Workload durch, die acht virtuelle CPUs (vCPUs) und 42 GB RAM auf einem einzelnen 44-Core-Server mit 512 GB RAM erfordert. Die Tester stellten zehn Kubernetes Pods auf identischen Computern bereit, von denen einer den Vorläufer von VMware Tanzu (damals Codename Project Pacific) und ein anderer eine Bare-Metal-Linux-Distribution ausführte, die Docker unterstützt.
Diese Tests ergaben, dass die VMware-Implementierung ohne Optimierung acht Prozent mehr Anwendungsdurchsatz bot. Sie kamen aber zum umgekehrten Ergebnis, wenn Container-Workloads an einen bestimmten Knoten gebunden wurden. Das Fixieren von Workloads steht jedoch dem eigentlichen Sinn einer Clusterumgebung entgegen und das Ausführen einer Workload mit acht vCPUs und 42 GB ist nicht repräsentativ für moderne Anwendungen und verstößt gegen die Entwurfsprinzipien schlanker, granularer Microservices.
Im Gegensatz dazu zeigte eine ältere Leistungsstudie Running Containers on Bare Metal vs. VMs: Performance and Benefits (2017) des HCI-Anbieters Stratoscale (Hyper-converged Infrastructure, hyperkonvergente Infrastruktur), dass Bare-Metal-Instanzen VM-basierte Container deutlich übertrafen: Das Ausführen von Kubernetes und Containern auf Bare-Metal-Computern erzielte eine deutlich geringere Latenz – etwa dreimal weniger als das Ausführen von Kubernetes auf VMs. Die CPU-Auslastung auf VMs im Vergleich zu Bare Metal war in einigen Fällen viel höher.
Stratoscale stellte außerdem fest, dass Workloads, die direkten Zugriff auf Hardware wie GPUs (Graphics Processing Unit, Grafikprozessor) erfordern, manchmal in Containern auf VMs überhaupt nicht laufen können. Diese Problematik wird jedoch durch Hardware-Virtualisierungstechnologien wie Single-Root-E/A-Virtualisierung (SR-IOV) für Netzwerkschnittstellen und Bitfusion für GPUs gemildert, wenn nicht sogar beseitigt.
Diamanti argumentierte in seinem Whitepaper Five Reasons You Should Run Containers on Bare Metal, Not VMs, dass Container, die in VMs laufen, teilweise das Fünffache der Infrastruktur benötigen, um dieselben Workload-Container auf Bare Metal auszuführen.
Dafür gibt Diamanti zwei Gründe an:
- Bare-Metal-Systeme können eine Ressourcenauslastung von bis zu 90 Prozent für containerisierte Workloads erreichen, gegenüber 15 Prozent für VM-basierte Container-Hosts, da für jeden Knoten ein vollständiges Gastbetriebssystem ausgeführt werden muss.
- System- (insbesondere Netzwerk-) Ressourcenkonflikte, auch bekannt als das Problem mit lauten Nachbarn (Noisy Neighbor), auf stark ausgelasteten Servern sind auf VM-Hosts stärker ausgeprägt – wiederum aufgrund der gemeinsamen Nutzung von Hardware durch mehrere vollständige Betriebssysteme.
Über die Vor- und Nachteile für die Leistung lässt sich demnach trefflich streiten. Der klarste Vorteil von Bare-Metal-Container-Umgebungen sind die Kosten. Auch, wenn die Anzahl der erforderlichen Hosts möglicherweise nicht um die genannten 80 Prozent abnimmt, sind weniger Lizenzgebühren und eine Verwaltungsschicht im Gegensatz zu zweien konkrete finanzielle und betriebliche Vorteile gegenüber dem Hosting von Containern in einer VM-Umgebung, die ansonsten keinen Zweck erfüllt. Da Bare-Metal-Server normalerweise eine leichtgewichtige Linux-Distribution wie Fedora CoreOS verwenden, entfallen auch teure Hypervisor-Lizenzgebühren, auch bekannt als VMware-Steuer.
VMware versucht, diesen administrativen Nachteil durch die Integration der Kubernetes-Verwaltungsfunktionen in vSphere zu verringern. Das Hinzufügen einer virtuellen Abstraktionsschicht bedeutet jedoch, dass VM-basierte Cluster in Bare-Metal-Umgebungen immer zusätzlichen administrativen Aufwand erfordern.
Beachten Sie, dass diese zusätzlichen Kosten sich rechnen, wenn ein Unternehmen Ausfallsicherheitsfunktionen benötigt, zum Beispiel die Migration von Workloads auf andere Cluster und das Erstellen von Image-Snapshots. Containerumgebungen können diese Anforderungen zwar auch erfüllen, jedoch auf andere Weise. So können Nutzer Kubernetes in mehreren Zonen ausführen und zentralisierte Container-Repositorys für Anwendungs-Images verwenden.
So bauen Sie ein Bare-Metal-Cluster auf
Beim Systemdesign sind Bare-Metal- und VM-basierte Cluster sich sehr ähnlich. Da Kubernetes so gut darin ist, Workloads auf Pod-Knoten zu verteilen, ist es am besten, die Knoten so dicht, standardisiert und unkompliziert wie möglich zu halten.
Deshalb bestehen Containercluster normalerweise aus 1HE- oder 2HE-Knoten (Höheneinheit, Unit, U) mit oder ohne lokalen Speicher. Moderne Container-Stacks wie Diamanti, OpenShift und Platform9 enthalten jedoch Container-native Speicher- und Netzwerkschichten– Container Storage Interface und Container Network Interface in Kubernetes-Sprache.
Deshalb bauen einige Unternehmen Bare-Metal-Container-Cluster auf HCI mit lokalen NVMe- oder SATA-Laufwerken auf. Serveranbieter wie Cisco, Dell EMC und HPE sowie Kubernetes-Spezialisten wie Diamanti bieten hyperkonvergente Produkte an, häufig mit einer vorgefertigten Kubernetes-Distribution, die für Containercluster entwickelt wurde. Hierbei handelt es sich um 1HE- oder 2HE-Chassis mit 1U- oder 2U-Servern und integrierten Netzwerkkarten (Network Interface Card, NICs) und Speicher.
Eine beispielhafte Infrastruktur hätte die folgenden Spezifikationen: Um den Overhead virtueller Overlay-Netzwerke auf dem Host-Prozessor zu minimieren und das Aufteilen einer einzelnen Netzwerkkarte in virtuelle Slices zu ermöglichen, umfasst eine typische Konfiguration zwei (aus Redundanzgründen) SmartNICs. Diese unterstützen SR-IOV für die Hardwarevirtualisierung, das Overlay-Netzwerk – zum Beispiel NVGRE (Network-Virtualisierung mit Generic Routing Encapsulation), Paketverarbeitung und Entlastungen zugunsten der Servicequalität, um die für Anwendungs-Workloads verfügbaren CPU-Ressourcen zu maximieren.
Bare-Metal-Containercluster haben einen hohen Dichtefaktor
Die obigen Konfigurationen bieten 40 bis 80 CPU-Kerne und bis zu 32 TB Datenspeicher pro Rack-Einheit mit 9,6 GB RAM pro Kern. Jeder Cluster benötigt mindestens drei Masterknoten – aus Redundanzgründen wird empfohlen, eine ungerade Anzahl von Knoten zu verwenden, um auch bei Ausfällen ein Quorum herstellen zu können – und zwei Switches zusammen mit einem 48-port-10/25/100-Gigabit-Ethernet-Gerät mit einer HE. Darüber hinaus erfordert jede Containerumgebung mindestens jeweils einen Server für den Netzwerk-Boot und für das Clustermanagement.
Ein maximal konfigurierter One-Rack-Cluster mit 36 Worker Nodes würde also 1.440 Rechenkerne mit jeweils 9,6 GB RAM und insgesamt 0,4 bis 1,4 Petabyte NVMe-Speicher umfassen. Bei der Planung einer Containerumgebung werden IT-Abteilungen, die für VMware- oder Windows-Systeme bereits hohe Lizenzgebühren zahlen, wahrscheinlich den Komfort einer einzelnen Verwaltungsumgebung mit den Workload-Migrations- und Sicherungsfunktionen von VMware vorziehen.
Alle anderen, die moderne Anwendungen mit containergestützten Microservices erstellen, sollten wahrscheinlich den VM-Overhead umgehen und direkt zu Bare-Metal-Containerclustern wechseln. So erhalten sie viel mehr Freiheit bei der Wahl der Hard- und Software.
