Server, Betriebssysteme, virtuelle Maschinen, Container und Cloud-Dienste

Ein Server ist einfach ein Computer, der dient

Ein Server ist ein Computer, dessen Aufgabe es ist, auf Anfragen zu warten und sie zu beantworten: Webseiten, API-Aufrufe, Datenbankabfragen, Dateien. Das Wort beschreibt eine Rolle, keine besondere Art von Maschine. Ein Laptop, auf dem eine kleine Webanwendung läuft, ist ein Server, solange er Anfragen beantwortet; ein Rack-Server in einem Rechenzentrum ist ein Server, weil er nie etwas anderes tut. Dasselbe Wort steht auch für das Programm, das die Anfragen bedient (ein „Webserver“ wie nginx), daher kommt es auf den Zusammenhang an.

Server-Hardware hat dieselben Bestandteile wie jeder Computer (siehe Was Software ist): Prozessoren, Arbeitsspeicher, Massenspeicher und Netzwerkkarten. Der Unterschied liegt in der Gewichtung. Server haben meist viele Prozessorkerne, viel Arbeitsspeicher, redundante Netzteile und Festplatten, damit ein defektes Teil die Maschine nicht stoppt, eine Fernwartung, damit niemand im Raum sein muss, und überhaupt keinen Bildschirm und keine Tastatur. Sie sind dafür gebaut, jahrelang ohne Ausschalten zu laufen.

Die meisten Server im Internet laufen unter Linux oder einem anderen Unix-artigen Betriebssystem; Windows Server ist in Organisationen verbreitet, die auf Microsoft-Produkte setzen. Ein Server-Betriebssystem erledigt dieselben Aufgaben wie das auf Ihrem Laptop (Prozesse ausführen, Arbeitsspeicher und Dateien verwalten, mit dem Netzwerk kommunizieren), wird aber meist über eine Textkommandozeile per Fernverbindung administriert und ist so konfiguriert, dass es sich automatisch statt von Hand neu aufbauen lässt.

Rechenzentren: wo die Server wohnen

Server stehen in einem Rechenzentrum: einem Gebäude, das um ihre Bedürfnisse herum entworfen ist. Tausende Maschinen sitzen in Racks und werden mit Luft oder Flüssigkeit gekühlt, weil sie fast ihren gesamten Strom in Wärme umwandeln. Der Strom kommt über mehr als eine Zuleitung, abgesichert durch Batterien für die ersten Sekunden eines Ausfalls und danach durch Dieselgeneratoren. Netzwerkverbindungen kommen von mehreren Anbietern. Für die Türen braucht man Ausweise und oft auch Fingerabdrücke.

Eine Organisation kann ein eigenes Rechenzentrum betreiben oder Rack-Fläche in einem fremden mieten (Colocation genannt), und vor etwa 2006 war das fast die einzige Wahl. Server selbst zu betreiben (On-Premises) bedeutet, Maschinen Monate vor dem Bedarf zu kaufen, zu schätzen, wie viele, für sie zu bezahlen, ob sie ausgelastet sind oder nicht, und Leute zu beschäftigen, die nachts defekte Festplatten tauschen. Diese Kosten und diese Unbeweglichkeit sind das Problem, das die Cloud lösen wollte.

Virtuelle Maschinen: viele Computer in einem

Ein typischer Server ist größtenteils untätig, wenn er nur eine Anwendung ausführt. Eine virtuelle Maschine (VM) lässt eine physische Maschine so tun, als wäre sie mehrere. Jede VM hält sich für einen vollständigen Computer mit eigenen Prozessoren, eigenem Arbeitsspeicher, eigener Festplatte und Netzwerkkarte und führt ein eigenes Betriebssystem aus, den sogenannten Gast. Eine Softwareschicht namens Hypervisor teilt die echte Hardware unter den VMs auf und hält sie voneinander getrennt, sodass ein Absturz oder Angriff in einer die anderen nicht erreicht. Manche Hypervisoren laufen direkt auf der Hardware (VMware ESXi, Microsoft Hyper-V, KVM, das Teil von Linux ist); andere laufen als Anwendung auf einem normalen Betriebssystem (VirtualBox).

Die Virtualisierung hat die Wirtschaftlichkeit von Servern verändert. Eine Maschine lässt sich mit VMs verschiedener Teams oder Kunden füllen. Eine VM ist eine Menge von Dateien, daher kann sie kopiert, gesichert, auf eine andere Maschine verschoben und in Minuten angelegt werden, statt bestellt und geliefert zu werden. Beachten Sie, dass „virtuelle Maschine“ hier anders gemeint ist als bei den Sprach-VMs wie der Java Virtual Machine, die in Was Software ist erwähnt wird: Jene führen Programme aus, diese bilden ganze Computer nach.

Container: die Anwendung mit allem ausliefern, was sie braucht

Jeder Entwickler kennt den Satz „Bei mir funktioniert es“. Das Programm hängt von einer bestimmten Sprachversion, bestimmten Bibliotheken und bestimmten Einstellungen ab, und auf dem Server sind sie leicht anders. Ein Container löst das, indem er eine Anwendung zusammen mit allem, was sie zum Laufen braucht (ihrer Laufzeitumgebung, ihren Bibliotheken, ihrer Konfiguration), in eine Standardeinheit verpackt, die auf einem Laptop, einem Testserver oder in der Cloud gleich läuft. Der Name kommt von Schiffscontainern: genormten Kisten, die jeder Kran, jedes Schiff und jeder Lkw handhaben kann, ohne zu wissen, was darin ist.

Das Paket ist ein Container-Image: eine schreibgeschützte, versionierte Datei, gebaut nach einem kurzen Rezept (bei Docker ein Dockerfile). Eine laufende Kopie eines Images ist ein Container. Docker, 2013 veröffentlicht, machte das für Entwicklungsteams im Alltag praktikabel, und sein Image-Format ist heute ein offener Standard, den die Open Container Initiative pflegt, sodass andere Werkzeuge dieselben Images bauen und ausführen können.

Der entscheidende Unterschied zu einer VM ist, was geteilt wird. Eine VM bildet Hardware nach und führt ein ganzes Gastbetriebssystem aus. Ein Container ist ein isolierter Prozess: Er teilt sich den Kernel des Host-Betriebssystems (den Kern des Betriebssystems, der Hardware, Arbeitsspeicher und Prozesse steuert) mit anderen Containern, und die Isolationsfunktionen des Kernels geben ihm eine eigene Sicht auf Dateien, Prozesse und Netzwerk. Container starten daher in Sekunden oder schneller und belegen Megabytes statt Gigabytes, sodass Dutzende dort laufen können, wo nur wenige VMs Platz hätten. Der Preis ist eine schwächere Isolation, weil jeder Container von dem einen gemeinsamen Kernel abhängt; deshalb betreiben Cloud-Anbieter die Container ihrer Kunden häufig innerhalb von VMs und kombinieren so beides.

# Start from an image that already has Python installed
FROM python:3.12-slim
WORKDIR /app
# Bake the libraries into the image
COPY requirements.txt .
RUN pip install -r requirements.txt
# Add the application code
COPY . .
EXPOSE 8000
CMD ["python", "-m", "uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Einen Container auszuführen ist einfach. Hunderte auf Dutzenden Maschinen zu betreiben, abgestürzte neu zu starten, bei steigendem Verkehr Kopien hinzuzufügen und neue Versionen ohne Ausfallzeit auszurollen ist es nicht. Diese Aufgabe übernimmt ein Orchestrator, von denen Kubernetes der bekannteste ist; er wird in Container und Orchestrierung behandelt.

Die Cloud: Rechenleistung minutenweise mieten

Cloud-Computing bedeutet, Rechenressourcen über das Internet bei Bedarf von einem Anbieter zu mieten, der riesige Rechenzentren betreibt: Amazon Web Services (AWS), Microsoft Azure und Google Cloud sind die größten, daneben gibt es viele weitere. Das US National Institute of Standards and Technology (NIST) veröffentlichte 2011 die meistzitierte Definition, die Special Publication 800-145. Sie nennt fünf wesentliche Merkmale: Selbstbedienung nach Bedarf (Sie legen Ressourcen selbst an, über eine Website oder eine API, ohne irgendwo anzurufen), breiter Netzwerkzugang, Ressourcenbündelung (viele Kunden teilen sich die Hardware des Anbieters), schnelle Elastizität (die Kapazität wächst und schrumpft rasch) und gemessene Dienstleistung (Sie zahlen für das, was Sie nutzen).

Die Analogie ist der Strom. Fabriken betrieben einst eigene Generatoren; heute hängen sie am Netz und zahlen pro Kilowattstunde. Mit der Cloud kann ein Start-up für einen Nachmittag hundert Server mieten, um einen Launch zu testen, und hört auf zu zahlen, sobald es sie zurückgibt. Das ist Pay-as-you-go-Abrechnung. Sie macht aus einer großen Anfangsinvestition laufende Kosten und belohnt Systeme, die Kapazität abschalten können, wenn sie nicht gebraucht wird. Sie schafft aber auch ein neues Risiko: Kosten, die unbemerkt wachsen, weil nichts jemanden daran hindert, Ressourcen anzulegen und sie zu vergessen.

IaaS, PaaS, SaaS und Serverless: Wie viel verwalten Sie selbst?

Cloud-Dienste unterscheiden sich vor allem darin, wie viel vom Stack der Anbieter für Sie verwaltet. NIST definierte drei Servicemodelle; ein viertes, Serverless, wurde populär, nachdem AWS 2014 seinen Dienst Lambda gestartet hatte. Eine beliebte Eselsbrücke ist Pizza: Sie können sie zu Hause machen, eine fertige zum Aufbacken kaufen, eine liefern lassen oder essen gehen. Jeder Schritt gibt mehr Arbeit an jemand anderen ab und nimmt Ihnen einige Wahlmöglichkeiten.

„Serverless“ heißt nicht, dass es keine Server gibt; es heißt, dass Sie sie nie sehen oder verwalten. Sie laden eine Funktion hoch, legen fest, welche Ereignisse sie auslösen (eine HTTP-Anfrage, eine eintreffende Datei, eine Nachricht in einer Queue), und der Anbieter führt so viele Kopien aus wie nötig und rechnet pro Ausführung und pro Millisekunde ab. Das ist günstig bei sprunghaftem oder geringem Verkehr und erfordert fast keinen Betriebsaufwand. Die Kosten zeigen sich an anderer Stelle: Der erste Aufruf nach einer ruhigen Phase kann langsam sein, während der Anbieter die Funktion startet (ein Kaltstart), es gibt Grenzen dafür, wie lange eine Funktion laufen darf, und bei gleichmäßig hohem Verkehr können die Kosten die eines einfachen Servers übersteigen. Kapitel 6 behandelt Serverless-Architekturen ausführlich.

Zwischen diesen Modellen liegen die Managed Services: Datenbanken, Message Queues, Caches, Objektspeicher, Suchmaschinen und vieles mehr, die der Anbieter installiert, betreibt, patcht, sichert und skaliert. Eine verwaltete Datenbank zu nutzen, statt selbst eine auf einer VM zu installieren, verlagert viel Betriebsarbeit zum Anbieter. Die Abwägung, behandelt in FinOps und Lock-in, besteht darin, dass ein System umso schwerer umzuziehen ist, je mehr anbieterspezifische Dienste es nutzt.

Regionen, Availability Zones und Content Delivery Networks

Cloud-Anbieter gruppieren ihre Rechenzentren nach Geografie. Eine Region ist ein geografisches Gebiet (etwa Irland, Frankfurt oder Virginia) mit einer eigenen, getrennten Gruppe von Rechenzentren, isoliert von anderen Regionen. Jede Region ist in mehrere Availability Zones unterteilt: physisch getrennte Gruppen aus einem oder mehreren Rechenzentren, jede mit unabhängiger Stromversorgung, Kühlung und Vernetzung, typischerweise Kilometer voneinander entfernt, aber nah genug für schnelle Verbindungen untereinander. Ein Brand, ein Hochwasser oder ein Stromausfall sollte höchstens eine Zone lahmlegen.

Das gibt Architekten eine Auswahl an Schutzstufen. Kopien einer Anwendung in zwei oder drei Zonen einer Region zu betreiben übersteht den Verlust eines Rechenzentrums bei kaum zusätzlicher Latenz; der Betrieb in zwei Regionen übersteht den Verlust einer ganzen Region, macht es aber viel schwieriger, die Daten synchron zu halten. Regionen sind auch für Recht und Latenz wichtig: Datenschutzvorschriften können verlangen, dass personenbezogene Daten in einem bestimmten Rechtsraum bleiben, und Nutzer werden aus einer nahen Region schneller bedient, weil kein Netzwerk die Lichtgeschwindigkeit schlagen kann (siehe Wie Computer kommunizieren).

Ein Content Delivery Network (CDN) treibt das weiter für Inhalte, die sich nicht pro Nutzer ändern, etwa Bilder, Stylesheets, Skripte und Videos. Es hält Kopien auf Servern an Hunderten Standorten, sogenannten Edge-Standorten, sodass ein Nutzer in Nairobi die Produktfotos des Shops aus einer nahen Stadt abruft statt aus einem Rechenzentrum in Europa. Die Seite lädt schneller, und die eigenen Server des Shops bearbeiten weit weniger Anfragen. Viele CDNs fangen auch Angriffsverkehr ab und können kleine Codestücke an der Edge ausführen.

Vertikal und horizontal skalieren

Wenn ein System mehr Arbeit bewältigen muss, gibt es zwei grundlegende Schritte. Vertikale Skalierung (Scale-up) bedeutet eine größere Maschine: mehr Kerne, mehr Arbeitsspeicher. Sie erfordert keine Änderung an der Software, was ihr großer Vorteil ist, aber es gibt eine größte Maschine, die man kaufen kann, nahe der Spitze wird es unverhältnismäßig teuer, und eine Maschine ist immer noch ein einzelner Ausfallpunkt. Horizontale Skalierung (Scale-out) bedeutet mehr Maschinen, die sich die Arbeit teilen, meist hinter einem Load Balancer, der die Anfragen auf sie verteilt und keine mehr an ausgefallene schickt. Sie reicht viel weiter und übersteht Maschinenausfälle, aber nur, wenn die Software dafür ausgelegt ist: Ein Server darf zum Beispiel die Session eines Nutzers nicht nur im eigenen Arbeitsspeicher halten oder hochgeladene Dateien nur auf der eigenen Festplatte speichern, wenn die nächste Anfrage des Nutzers bei einem anderen Server landen kann.

Die Cloud macht horizontale Skalierung attraktiv, weil eine zusätzliche Maschine nur einen API-Aufruf kostet und Autoscaling Kopien automatisch hinzufügen und entfernen kann, wenn sich die Last ändert. Datenbanken sind meist am schwersten horizontal zu skalieren, weshalb Kapitel 7 einen Abschnitt der Replikation und Partitionierung widmet.

Warum das für die Architektur wichtig ist

Wo Software läuft, ist heute eine Architekturentscheidung und kein nachträglicher Gedanke. Die Wahl zwischen VMs, Containern, Plattformen und Funktionen prägt die Kosten, wie schnell das Team Releases ausliefern kann, wie das System skaliert und was passiert, wenn ein Rechenzentrum ausfällt. Regionen und Zonen machen aus Verfügbarkeitszielen konkrete Deployment-Pläne; Managed Services tauschen Betriebsarbeit gegen die Abhängigkeit von einem Anbieter. Kapitel 9 entwickelt Skalierungsstrategien, und Kapitel 10 behandelt Cloud-Service- und Bereitstellungsmodelle, Container und Infrastruktur in professioneller Tiefe.