Wenn es ins Geld gehen darf – oder auch nicht Hardware by Code - Bare Metal und Serverless

Zwei völlig gegenteilige Modelle der Softwarebereitstellung wälzen die IT-Landschaft um. Serverless verspricht mehr Effizienz und höhere Kosteneinsparungen gegenüber konventioneller Virtualisierung. Bare-Metal-Clouds (nicht bloß „Hosts“!) stellen das Gegenteil in Aussicht: mehr Performance und kürzere Latenzen — wenn es ins Geld gehen darf.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

DataCore Software GmbH

„Wir sind jetzt in einer Welt, in der Datencentern eine breite Auswahl an anpassungsfähiger, programmierbarer Hardware zur Verfügung steht“, beobachtet Dan R. K. Ports, Leiter eines Forschungsprojektes im Bereich des In-Network-Computings an der Systems Research Group bei Microsoft. In-Network-Computing mag noch in den Kinderschuhen stecken (siehe dazu auch den Bericht: „Flache Storage-Hierarchien und Memory-Pools treffen auf Gen-Z-Connectivity, Paradigmenwechsel angesagt: Memory-driven und/ oder In-Network-Computing“, doch dieser und andere neue Ansätze zur „Cloudifizierung“ von Rechenzentrums-Workloads schaffen willkommene Alternativen, wenn es darum geht, die Bereitstellung von Datencenter-Diensten kundengerechter zu gestalten. Serverless und Bare-Metal-Clouds erheben diesen Anspruch für zwei unterschiedliche Zielgruppen.

Bare-Metal-Clouds (und -Server)

Bei einer Bare-Metal-Umgebung ist von einem Computersystem oder einem Netzwerk die Rede, in dem eine virtuelle Maschine direkt auf der Hardware und nicht innerhalb des Host-Betriebssystems (also nicht auf einem Hypervisor) installiert wird.

Diese Art der Anwendungsbereitstellung bietet eine verbesserte Isolierung der Laufzeitumgebung, unter anderem gegenüber der VM-Virtualisierung und der Containerisierung, allerdings geht dieser zusätzliche Schutz zu Lasten der Systemdichte und schlägt sich somit in höheren Betriebskosten nieder.

Gemeinsam genutzte Hardware ist bekannterweise anfällig für Fehler in Hardwareschutzmechanismen. Beispiele bekannter Verwundbarkeiten beinhalten „Rowhammer“ (ein Datenleck via DRAM und neuerdings auch ECC-Speicher), „Spectre“ (eine CPU-Verwundbarkeit durch Verzweigungsvorhersage und spekulative Ausführung von Befehlssätzen) und „Meltdown“ (das Auslesen von Kernel-Speicher aus dem User-Space durch unzureichende Speicherisolierung des Betriebssystems). Doch auch Bare-Metal ist nicht frei von Überraschungen (siehe unten: „Die Achilles-Ferse von Bare-Metal-Clouds: Firmware-Verwundbarkeiten der Controller“).

Hardware pur

Bei einem Bare-Metal-Server handelt es sich um einen physischen Single-Tenant-Server. Ein dedizierter Server bietet einem einzigen Kunden exklusiven administrativen Zugang. Ein Beispiel sind die „BM“-Hosts der „Telekom Cloud“.

Eine Bare-Metal-Cloud besteht aus mehreren solchen Bare-Metal-Servern, die sich mit Hilfe von Cloud-Orchestrierungswerkzeugen des jeweiligen Infrastrukturanbieters provisionieren lassen. Der Nutzer einer solchen Bare-Metal-Cloud kann alle Elemente der physischen Infrastruktur und des darauf aufbauenden Stacks (fern)steuern. Im Gegensatz zu konventionellen dedizierten Servern besteht hierbei jedoch nicht die Notwendigkeit, eigene Hardware in einem Rechenzentrum betreiben zu müssen.

Die Bereitstellung einer Bare-Metal-Cloud kann folgende Elemente umfassen:

• dedizierte Server mit oder ohne eine virtualisierte Umgebung, welche der Kunde exklusiv steuert und verwaltet,

• spezielle, proprietäre Speichergeräte (SANs) oder dedizierte Teile eines Multi-Tenant-SANs,

• dedizierte Switches oder dedizierte Ports von einem Multi-Tenant-Switch,

• spezielle Load-Balancer oder Firewalls oder dedizierte Ports von einem Multi-Tenant-Load-Balancer oder einer Firewall.

Die Orchestrierung von Bare-Metal-Umgebungen

Die Orchestrierung einer Bare-Metal-Cloud erfordert entsprechende Mechanismen. Auf Cloud-fähigen Bare-Metal-Servern kommt hierzu ein nativer Hypervisor, der so genannte Type-1-Hypervisor, zum Einsatz (auch Bare-Metal-Hypervisor genannt). Ein nativer Hypervisor setzt — im Gegensatz zu einem gehosteten Hypervisor — direkt auf der jeweiligen Hardware auf.

Ein Bare-Metal-Server mit einem Hypervisor ermöglicht den Betrieb mehrerer Gastsysteme. Benutzeranwendungen laufen in diesem Fall separat in virtualisierten Gastbetriebssystemen und nicht direkt auf dem Hypervisor. Als native Hypervisoren kommen zum Beispiel „KVM“, die native Virtualisierungsfunktion des Linux-Kernels, „Microsoft Hyper-V“, „vSphere“ von VMware oder „Citrix XenServer“ in Frage.

Eine Bare-Metal-Cloud bewährt sich als das mit Abstand kostengünstigste Heim für Media-Streaming und andere bandbreitenlastige oder latenzsensible Anwendungen wie KI-Workloads oder das Internet der Dinge. Sie bietet ein definiertes Kontingent an garantierten Kapazitäten und eine weitaus geringere Latenz gegenüber einer Public-Cloud.

Eine Bare-Metal-Cloud empfiehlt sich bei vorhersehbaren Arbeitslasten mit hohen Ansprüchen an die Latenz; in diesem Szenario bietet eine Bare-Metal-Cloud-Umgebung potenziell sogar niedrigere Fixkosten als eine öffentliche Cloud, verspricht die Iomart Hosting Limited, eine Pionierin Software-definierter Netze und Bare-Metal-Clouds aus Schottland.

Die Achilles-Ferse von Bare-Metal-Clouds: Firmware-Verwundbarkeiten der Controller

Doch Bare-Metal-Orchestrierung hat auch seine Macken. Werkzeuge zum Verwalten von Bare-Metal-Clouds lassen sich zum Angriff auf Rechenzentren missbrauchen. Selbst IBM fiel kürzlich einer solchen Attacke zum Opfer.

Laut einem Bericht des Sicherheitsspezialisten Eclypsium vom Februar 2019 können Cyber-Täter eine Firmware-Verwundbarkeit gemieteter Bare-Metal-Server für Attacken gegen deren Nutzer (nach einem Firmware-Upgrade mit Malware) missbrauchen. Bei der Attacke gegen IBM-Kunden, die im Februar 2019 in das Licht der Öffentlichkeit rückte, machten sich die Angreifer die Cloudborne-Verwundbarkeit in der Firmware der Basisboard-Management-Controller von Supermicro zu Nutze, die IBM in seinen Servern einsetzt.

Das Problem beschränke sich jedoch nicht auf Supermicro und IBM. Auch andere Firmware und andere Anbieter von Bare-Metal-Clouds sind zutiefst verwundbar.

Die Gegenmaßnahmen

Datencenter-Manager müssten unbedingt Gegenmaßnahmen ergreifen, so Eclypsium. Sie müssten sich mit jeder Bereitstellung ihrer Bare-Metal-Server und -Clouds vergewissern, dass ihre Hardware nicht manipuliert wurde, und alle Patches ordnungsgemäß einspielen. Server müssten eigentlich nach jedem Gebrauch sorgfältig reinigt werden, und zwar nicht nur die Betriebssystemebene, sondern auch die Firmware, rät Eclypsium.

Rechenzentren sollten außerdem mit jeder Server-Wiederherstellung sicherstellen, dass die Passwörter und Protokolle des Basisboard-Management-Controller ebenfalls gelöscht werden, damit sich diese Informationen nicht auf den nächsten Kunden übertragen können.

Den Nutzern von Bare-Metal-Clouds empfehlen die Sicherheitsexperten von Eclypsium, die Firmware-Version unbedingt zu überprüfen und gegebenenfalls die Firmware selbst neu zu installieren. Eine bereits verseuchte Firmware könne sich allerdings mit der falschen Versionsnummer identifizieren und auch ein gelungenes Upgrade vortäuschen.

Bei Unstimmigkeiten sind Rechenzentrumskunden gut beraten, den Datacenter-Betreiber umgehend zu benachrichtigen, damit dieser die erforderlichen Gegenmaßnahmen einleiten kann.

Weg von containerisierten Microservices?

Die traditionelle Art der Bereitstellung von Anwendungen erfordert die Provisionierung eines Host entweder auf Bare-Metal oder in einer virtuellen Maschine. Viele Arten von Workloads wie beispielsweise Web-Anwendungen erfordern eine kontinuierliche Dienstbereitschaft der Server. Die Systeme verbrauchen ständig Energie und nehmen Arbeitszeit der Administratoren in Anspruch.

Die Administratoren müssen die erforderlichen Software-Updates einspielen, die Belastung der provisionierten Serverressourcen aktiv verwalten und andere Wartungsaufgaben durchführen, um einen unterbrechungsfreien Betrieb der betreffenden Anwendung und deren Cybersicherheit zu gewährleisten.

In größeren Unternehmen sind die Tätigkeitsbereiche der Server-Administration und der Anwendungsentwicklung voneinander getrennt; ein Team kümmert sich um die Funktionsbereitschaft der Infrastruktur, ein anderes Team um die Funktionsbereitschaft der Web-Anwendung. Diese Arbeitsteilung schafft den nötigen Raum für hochspezialisierte Kompetenzen, bremst jedoch die Anwendungsentwicklung aus.

Denn zu sprunghafte Optimierungen des Infrastrukturunterbaus — zum Beispiel Updates der Server-Betriebssystems — können die Anwendungsausführung außer Gefecht setzen, und so werden diese Änderungen auf die lange Bank geschoben, was ja wiederum die Software-Entwicklung ausbremst. Denn Upgrades der Entwicklungsumgebung erfordern nicht selten gewisse Aktualisierungen der Laufzeitumgebung. Das Ganze dreht sich im Kreis.

Kleinere Unternehmen versuchen das Problem dadurch zu entschärfen, dass sie Wartung der Server den Web-Entwicklern übertragen. So geht aber der administrative Aufwand zwangsweise zu Lasten der Funktionalität der Anwendungen, da sich die Coders mit beiden Aufgabenbereichen auseinandersetzen. Eine perfekte Lösung scheint es also nicht zu geben.

…und hin zu Serverless

Containerisierte Microservice-Architekturen haben den Nutzern neue Modelle der Anwendungsbereitstellung in Aussicht gestellt.

Durch den gemeinsam genutzten Kernel und die ebenfalls gemeinsam genutzten Systemdienste sind Container typischerweise weitaus leichtgewichtiger als VMs (ein Container nimmt nur einige Megabyte in Anspruch, also einen Bruchteil der Gigabyte-Größe einer virtuellen Maschine) und somit auch leichter portabel. Auf bereits laufenden Hosts lassen sie sich weitaus schneller als VMs initialisieren, da die Letzteren ein ganzes Gast-Betriebssystem erst noch hochfahren müssen. (Container lassen sich im Übrigen nicht nur auf Bare-Metal-Hosts, sondern auch innerhalb von VMs ausführen.)

Alleine die Fähigkeit zur schnellen Bereitstellung kann die Skalierbarkeit, die Hochverfügbarkeit und die Widerstandsfähigkeit containerisierter Anwendungen erhöhen. Doch diese Vorteile materialisieren sich natürlich erst dann, wenn die betreffenden Container nicht alle auf demselben physischen Host laufen. Damit das Deployment die benötigten Merkmale aufweist, wacht über die Container eine Orchestrierungs-Werkzeug wie „Kubernetes“.

Doch die Containerisierung ändert noch nichts an dem grundlegenden Problem: der aufwändigen, kostspieligen Server-Administration. Container-Orchestrierung bringt unbestrittene Vorteile. Sie erleichtert den Nutzer um die Administration der Infrastrukturschicht — nicht jedoch um die Verwaltung der Orchestrierungsschicht. Serverless verspricht Abhilfe.

Bei Serverless (siehe auch: „“) handelt es sich um einen Cloud-nativen Modus der Anwendungsausführung, bei dem für die Aufgaben der Infrastrukturverwaltung wie die Provisionierung von Servern, Clustern und Storage, die Wartung des Betriebssystems, das Einspielen von Software-Upgrades und die dynamische Kapazitätsbereitstellung, nur der Cloud-Anbieter verantwortlich zeichnet.

Beim Serverless Computing sind die Server des Cloud-Dienstleisters unsichtbar für den Benutzer. Die Implikationen für die Anwendungsentwicklung, -Bereitstellung und (auf Grund unzureichender Dienstisolierung) für die Cybersicherheit können im Einzelfall sehr weitreichend sein.

Zur Ausführung in einer serverlosen Laufzeitumgebung muss der Anwendungscode typischerweise in Form von ausführbaren Funktionen vorliegen. Diese Funktionen orchestrieren dann verteilte, containerisierte Microservices. Die Bereitstellung monolithischer Anwendungen ist zwar prinzipiell nicht unmöglich, gestaltet sich jedoch als eher problematisch. Funktionen zur Bereitstellung monolithischer Anwendungen ziehen aus den Vorteilen von Serverless keinen Nutzen.

Darüber stellen „serverlose“ Anwendungsarchitekturen ihre eigenen Cyber-sicherheitstechnischen Anforderungen an die Implementierung.

Serverless, Bare Metal in OpenStack Rocky und Stein

OpenStack trägt diesen neuen Trends bereits Rechnung. Das führende Cloud-Orchestrierungsframework stellte die Weichen auf Bare-Metal-Clouds und Serverless bereits im „Rocky“-Release (vom August 2018).

In der aktuellen Version von OpenStack „Stein“ (benannt im Übrigen nach der Berliner Steinstraße), nimmt die OpenStack-Gemeinde unter anderem die Unterstützung für Beschleuniger, die Anforderungen der Hochverfügbarkeit und nicht zuletzt die Upgrade-Prozedur ins Visier.

Das sind die Neuheiten in der 19. OpenStack-Version

Ein Stein zum anderen

Die meisten OpenStack-Anwender hinkten nämlich einige Release-Zyklen der aktuellen Version des Frameworks hinterher, enthüllte neulich Jonathan Bryce, Geschäftsführer der OpenStack Foundation und Mitgründer der Rackspace-Cloud. Viele dieser Nutzer konnten aus den Innovationen in Rocky kaum noch Nutzen ziehen. In Zukunft soll es möglich sein, mehrere Releases des Frameworks komfortabel zu überspringen.

Die OpenStack-Version von Rocky brachte mit sich Verbesserungen des Bare-Metal-Bereitstellungsdiensts Ironic sowie Unterstützung für Serverless-Computing bei öffentlichen Cloud-Anbietern über das neue Project „Qinling“ für Function-as-a-Service-Dienste in Open Stack. Diese Neuerungen tragen der Bedeutung dieser neuen Modelle der Bereitstellung von Web-Anwendungen Rechnung.

Qinling unterstützt mehrere Container-Orchestrierungs-Engines (darunter Kubernetes und „Swarm“) und mehrere alternative Backend-Speicher für Funktionscode, einschließlich lokalem Speicher, „Swift“ und „S3“ via Plug-Ins. Qinling soll die Bereitstellung praktisch beliebiger Anwendungen oder Backend-Dienste mit „Zero Administration“ ermöglichen, Skalierbarkeit und Hochverfügbarkeit mit eingeschlossen. Der Funktionscode lässt sich durch andere OpenStack-Dienste auslösen oder direkt durch Ereignisse in einer Web-Anwendung oder einer mobilen App auslösen.

*Das Autoren-Duo

Die Autoren des Artikels, Anna Kobylinska und Filipe Pereira Martins, arbeiten für McKinley Denali Inc. (USA).

(ID:45913895)