Warum landen hunderte MacBooks in einem Rechenzentrum statt auf Schreibtischen? Die Antwort beginnt bei einer Regel von Apple und endet bei Kabelmanagement, Kühlkörpern und Festplattenverschlüsselung. Der Betreiber von Namespace Labs beschreibt in einem Erfahrungsbericht, was hinter seinem Video vom Auspacken der Geräte steckt. Ein Mac-Datacenter ist eine Notlösung mit viel Ingenieursarbeit.
Man kann sich das wie eine Profiküche vorstellen. Die Rezepte kommen vom Hersteller und ändern sich im Wochenrhythmus, die Zutaten sind riesig, und gekocht werden muss trotzdem jeden Tag. Wer diese Küche betreibt, kann sich nicht aussuchen, ob ihm die neuen Rezepte passen. Er kann nur dafür sorgen, dass die Küche sauber, kühl und schnell wieder einsatzbereit ist.
Warum sich iOS-Apps ohne echten Mac nicht bauen lassen
Der Ausgangspunkt ist einfach: Wer eine iOS-App bauen und testen will, braucht einen Mac. Der iOS-Simulator läuft ausschließlich unter macOS, und für die Veröffentlichung im App Store verlangt Apple eine aktuelle Xcode-Version. Alternative Werkzeugketten wie xtool bezeichnet der Autor als interessant, aber noch nicht als ernsthaften Ersatz. Und weil inzwischen auch Coding-Agenten kompilieren, testen und Fehler reproduzieren müssen, wächst der Bedarf an echten Macs eher, als dass er sinkt.
Für einen Anbieter wie Namespace Labs ist das die Grundlage des Geschäftsmodells. Kunden mieten remote Macs für die iOS-App-Entwicklung, weil ihre eigenen Rechner nicht skalieren und weil ein einzelner Laptop nicht hundert Builds parallel schafft. Der Autor beschreibt sein Angebot als Mac-Hosting, das sich anfühlt wie eine lokale Maschine, im Hintergrund aber aus einer Flotte von Geräten in einem Rack besteht. Dass sein Video vom Auspacken hunderter MacBook Pros millionenfach gesehen wurde, passt zu dieser Spannung: erst absurd, dann rational.
Warum es MacBooks statt Mac Minis wurden
Für ein Rechenzentrum wäre der Mac Mini die naheliegende Wahl. Er hat zwar nur eine rudimentäre Fernwartung, keine redundante Stromversorgung und ein Gehäuse, das die Kühlung je nach Einbaulage erschwert – aber das sind bekannte Probleme, mit denen man umgehen kann. Das Problem war die Lieferzeit: Der Versuch, ein paar hundert Minis zu bestellen, brachte eine Lieferung im Juli auf eine Bestellung im Januar. Lieferketten sind durcheinandergeraten; das ist kein Ausreißer, sondern Normalzustand.
Dazu kommt Apples Eigenheit, neue Prozessorgenerationen nicht gleichzeitig an alle Geräteklassen auszuliefern. Laut dem Bericht bekam der Mac Mini zehn Monate lang keine M5-Kerne und wurde dann plötzlich mit M6 ausgestattet, bevor andere Modelle überhaupt so weit waren. Wer Kunden die neueste Hardware verspricht, kann darauf nicht warten. Also entstand das Projekt „MacBook im Rechenzentrum“ – nicht aus Begeisterung für Laptops, sondern weil sie verfügbar waren. Aus dem Provisorium wurden eigene Mac-Racks für Rechenzentren, mit Halterungen, Kabelplänen und belüfteten Böden.
Mittlerweile entspannt sich die Lage. M5- und M6-Minis sowie Mac Studios kommen in die Flotte und sind im Rechenzentrum deutlich einfacher zu handhaben: eingebaute 10-Gigabit-Netzwerkkarte, automatischer Neustart nach Stromausfall und vollständige Konfiguration über MDM. Auch dort setzt das Team auf selbst gefertigte Regale, deren Luftführung mit Strömungssimulation getestet wurde. Die Montage selbst ist unspektakulär: auspacken, zehn Geräte in die Halterung, Strom und Netzwerk anschließen, einmal den berüchtigt ungünstig platzierten Einschaltknopf drücken. Danach übernimmt die Automatisierung.
Kabel, Hitze und unerwartete Störfälle
Jedes MacBook im Rack bekommt einen IP-KVM für die Fernwartung – also eine Art Bildschirm- und Tastatur-Fernbedienung über das Netzwerk –, eine externe 10-Gigabit-Netzwerkkarte und Strom. Das sind vier Kabel pro Laptop, achtundvierzig pro Regalboden, dazu zwölf für Ethernet und die Verkabelung der KVM-Einheiten. Sorgfältiges Kabelmanagement ist Pflicht. Dazu kommt Wärme, die bei geschlossenen Laptops an genau den falschen Stellen entsteht; aktuell kommen eigens gefertigte Halterungen zum Einsatz, die Hitze von den Hotspots abziehen und heiße Luft gezielt wegleiten, statt sie auf die Nachbargeräte zu blasen.
Probleme gab es trotzdem, nur andere als erwartet. Im Video hätten viele auf MagSafe gewettet, weil ein versehentlich gelöster Stecker den Laptop vom Strom trennt. Tatsächlich ist das selten passiert. Der unzuverlässigste Stecker im Rack ist HDMI: dick, unflexibel und bei jeder Berührung des Regals kurz davor herauszufallen. Inzwischen hat das Team nach eigener Aussage nahezu perfekte Kabel gefunden – und gleich den gesamten verfügbaren Bestand aufgekauft.
Wesentlich unangenehmer ist FileVault. Startet ein MacBook ungeplant neu, verlangt es ein Passwort zum Entsperren der Festplatte, und dieser Dialog erscheint auf dem Bildschirm eines zugeklappten Laptops irgendwo im Rack. Die KVM-Verbindung hilft nur bedingt, weil der Passwortdialog nach fünf Minuten Inaktivität verschwindet. Selbst die in macOS Tahoe eingeführte SSH-Entsperrung läuft auf Laptops nach fünf Minuten ab. Der Ausweg ist ein physikalischer Neustart per Knopfdruck; viel Zeit bleibt dabei nicht. Alternativ rät der Autor zu einem Neustart mit entsperrt bleibendem Datenträger über fdesetup authrestart.
Dazu gesellen sich schlichte Fehler. Unter bestimmten Bedingungen verliert eine externe USB-Netzwerkkarte ihre Funktion und meldet weder Strom noch Link, unabhängig von Kabel, Karte oder Switch-Port. Die Lösung ist unspektakulär: In den Netzwerkeinstellungen den Dienst löschen und neu anlegen, danach läuft die Karte wieder. In Architekturzeichnungen stehen solche Details nicht. Sie entscheiden aber, ob eine Flotte stabil bleibt.
Wie aus einem Mac zwei Instanzen werden – und warum nicht mehr
Jede Instanz ist eine virtuelle Maschine. Namespace integriert mehrere VM-Engines in eine Plattform, damit Linux, Windows und macOS mit denselben Funktionen laufen – Cache-Volumes, Telemetrie, VPC-Anbindungen. Für macOS nutzt das Team Apples Virtualization-Framework, das sich architektonisch mit Firecracker vergleichen lässt: Es bildet generische VM-Operationen und typische Peripherie ab. Die tiefere Ebene, das Hypervisor-Framework, ähnelt eher der KVM-Schnittstelle unter Linux und wird beispielsweise von QEMU verwendet. Sie erlaubt mehr Kontrolle, kann aber kein macOS ausführen, weil dafür eine proprietäre Umgebung nötig wäre, die Dritte nicht nachbauen können.
Die harte Grenze kommt von Apple selbst: Pro physischem Mac sind nur zwei macOS-VMs erlaubt. Das gilt auch für einen Mac Pro mit 24 Kernen und 192 GB Speicher. Diese Beschränkung schlägt direkt auf das Produkt durch, weil sich Ressourcen nur halbieren lassen. So laufen auf 14-Kern-Mac-Minis Instanzen mit 6 oder 12 Kernen, auf 18-Kern-MacBooks solche mit 8 oder 16 – ein paar Kerne bleiben für den Verwaltungsaufwand übrig. Wer Mac-Ressourcen einkauft, kauft also immer in Zweierpackungen, ob es passt oder nicht.
Beim Networking reichen Brücken- und NAT-Modi des Virtualization-Frameworks für vertrauenswürdige Workloads auf einem lokalen Rechner. Namespace führt jedoch fremden Code aus und muss Richtlinien durchsetzen, teils vom Kunden selbst definiert. Deshalb verarbeitet das Team jedes Paket in Software, auf Basis eines Userspace-TCP/IP-Stacks aus Googles gVisor-Projekt, der als Gateway und Firewall für die Instanzen dient. Das kostet Tempo: Der VMM-Prozess muss Pakete per IPC an den Host-Prozess übergeben, was sich nur mit konsequenter Batch-Verarbeitung halbwegs kaschieren lässt. Am Ende stehen rund 4 Gbit/s pro Instanz – ordentlich, aber kein Spitzenwert. An Ansätzen, die IPC für Netzwerkverarbeitung ganz vermeiden, wird gearbeitet.
Von 500-GB-Images zu macOS-Instanzen in Sekunden
Die erste VM ist schnell gebaut: IPSW-Restore-Image herunterladen, mit UTM, Tart oder einem der vielen Wrapper starten, den Setup-Assistenten durchklicken, Xcode installieren. Das Problem beginnt beim Testen. Mehrere iOS-Versionen bedeuten mehrere Runtime-Pakete, und die sind groß. Kommt die Xcode-Beta dazu, wächst das Image auf 500 GB. Für eine zweite macOS-Version zum Gegentesten kommen weitere 500 GB hinzu, für die nächste Developer Preview noch einmal.
Eine Xcode-Beta beschädigt außerdem still die stabilen Xcode-Versionen auf demselben System, weil die Installation die globalen Versionen von CoreDevice und CoreSimulator anhebt. Fehler aus dem Beta-Simulator tauchen dann in angeblich stabilen Builds auf. Also braucht es getrennte Image-Varianten mit und ohne Vorabversionen – und plötzlich liegen zwei Terabyte an Abbildern herum, die über hunderte Maschinen verteilt und aktuell gehalten werden müssen.
Deshalb ist das Bauen der Images ein reproduzierbarer Prozess. Ein Skript arbeitet wie ein menschlicher Nutzer: Es führt Shell-Befehle aus, klickt durch Oberflächen und startet VMs neu. Wo immer möglich, nutzt es Apples eigene Steuerelemente, damit sich die VM nicht anders verhält als ein lokaler Rechner. Die Abfolge steht als Workflow in einer YAML-Datei, jede Operation ist VM-Steuerung, Shell-Skript oder programmatische Interaktion. So lassen sich neue Xcode-Versionen wenige Stunden nach Apples Release bereitstellen, und neue macOS-Instanzen starten in Sekunden statt in der Zeit, die eine manuelle Installation kosten würde.
Was das für Teams bedeutet
Knapp ist weniger die Hardware als die Orchestrierung. Ein Mac im Rack ist erst dann nützlich, wenn jemand Kabel, Kühlung, Firmware-Dialoge, Netzwerkpfade und Images beherrscht. Die Zwei-VM-Grenze von Apple bestimmt dabei die Packungsgrößen und damit indirekt den Preis jeder Mac-Instanz. Wer Mac-Hosting einkauft, sollte diese Zahl kennen, weil sie erklärt, warum die kleineren Instanzen nicht beliebig klein werden.
Für Teams, die iOS-Apps bauen, ändert sich dadurch vor allem der Umgang mit Xcode-Versionen. Wer gegen drei iOS-Versionen und zwei Xcode-Stände testen muss, hat mit einem eigenen Mac pro Kombination schnell ein Regal voller Laptops. Der praktische Wert eines Mac-Datacenters liegt deshalb weniger im Ersatz des Entwicklerrechners als in Hintergrundinfrastruktur für Builds, Tests und Agenten, die ohne Unterbrechung laufen sollen.
Wer das Video mit den hunderten MacBooks gesehen hat, findet den Anblick weiter seltsam. Dahinter stecken App-Store-Regeln, Lieferzeiten, Verschlüsselung und die Grenze von zwei erlaubten VMs. Ein MacBook im Rechenzentrum ist deshalb keine schöne Lösung, aber eine, die sich aus den Randbedingungen ergibt.
Quelle: namespace.so
