Namespace stellt MacBooks ins Rack: Was iOS-Builds im Rechenzentrum kosten

Namespace, ein Anbieter von Build- und Testumgebungen, hat im Rechenzentrum Hunderte MacBook Pro aufgestellt. Kirill Nikolaev beschreibt im Namespace-Blog vom 3. November 2026, warum: Mac minis, die im Januar bestellt wurden, kamen im Juli. Der Text ist eine Anbieterquelle. Er enthält brauchbare Details, aber alle Zahlen darin sind Angaben von Namespace, die wir nicht nachgemessen haben.

Ein Mac-Rack im Rechenzentrum ist eine Reihe von Apple-Rechnern, die per IP-KVM aus der Ferne bedient werden und als Build-Hosts für macOS und iOS dienen. Weil Apple je Mac nur zwei macOS-Gäste zulässt, teilt sich jeder Rechner in höchstens zwei virtuelle Maschinen. iOS-Apps lassen sich nur auf macOS bauen, der iOS-Simulator läuft nur dort, und für den App Store verlangt Apple eine aktuelle Xcode-Version.

Warum Laptops und was daran hängt

Namespace nennt Mac minis die bessere Wahl für ein Rechenzentrum, aber nicht lieferbar. Jedes MacBook hängt deshalb an einem IP-KVM, denn bei Laptops lassen sich manche Wartungsschritte nur über die grafische Oberfläche ausführen. Dazu kommt ein externer 10-Gbit-Ethernet-Adapter. Laut Beitrag sind es vier Kabel je Laptop, 48 Kabel je Regalbrett und zwölf Netzwerkkabel dazu. Daraus folgt, dass ein Brett zwölf Rechner trägt; das steht so nicht im Text.

Am häufigsten fiel nicht MagSafe aus, sondern das HDMI-Kabel, das beim Anfassen des Regals herausrutscht. Namespace hat nach eigener Angabe den gesamten lieferbaren Vorrat eines passenden Kabels aufgekauft.

Die FileVault-Falle

Nach einem ungeplanten Neustart verlangt ein MacBook mit FileVault ein Passwort, bevor die Platte zugänglich ist. Die Eingabeaufforderung steht auf dem Bildschirm eines geschlossenen Laptops. Laut Namespace verschwindet sie nach fünf Minuten von einem externen Monitor, also auch vom KVM-Bild.

Seit macOS 26 Tahoe lässt sich das Laufwerk per SSH entsperren. Apples Handbuchseite apple_ssh_and_filevault(7) beschreibt das mit Passwort-Anmeldung, solange die Datenpartition gesperrt ist. Auf Laptops läuft dieses Fenster laut Namespace ebenfalls nach fünf Minuten ab; die Handbuchseite nennt keine Frist. Der Ausweg war, den Einschaltknopf zu drücken und rechtzeitig zu entsperren.

Wer einen Neustart selbst auslöst, kann fdesetup authrestart benutzen. Der Befehl startet neu und lässt die Platte entsperrt. Er greift nur bei geplanten Neustarts, nicht beim Stromausfall.

Zwei VMs je Mac

Namespace nutzt Apples Virtualization-Framework. Das Hypervisor-Framework scheidet aus, weil es macOS nicht starten kann. Die Grenze von zwei macOS-VMs je physischem Mac steht im Lizenztext: Abschnitt 2B (iii) erlaubt bis zu zwei zusätzliche Instanzen, unter anderem für Softwareentwicklung und Tests. Das Eclectic Light Company hat das 2022 für Monterey nachgelesen und gemessen: Die dritte VM bricht mit dem Fehler „maximum supported number of active virtual machines has been reached“ ab. Den aktuellen Lizenztext haben wir nicht selbst gelesen.

Aus der Grenze folgt Namespaces Zuschnitt. Ein 14-Kern-Mac-mini wird in Instanzen mit 6 oder 12 Kernen geteilt, ein 18-Kern-MacBook in Instanzen mit 8 oder 16 Kernen, ein paar Kerne bleiben für die Verwaltung. Gemeint sind vermutlich zwei Hälften zu 6 beziehungsweise 8 Kernen; das ist eine Schlussfolgerung aus den Zahlen, im Text steht es nicht.

Das Netzwerk der Gäste läuft über einen Userspace-TCP/IP-Stack aus Googles gVisor, damit Namespace jeden Paketweg kontrolliert und Egress-Regeln durchsetzen kann. Der Preis ist ein Umweg über Prozessgrenzen. Laut Namespace erreichen macOS-Instanzen damit 4 Gbit/s Upstream, gemessen mit Fast.com und unterhalb der Leitungsrate.

500-GB-Images im Rechenzentrum verteilen

Ein macOS-Image mit mehreren Xcode-Versionen und iOS-Runtimes wächst laut Namespace auf 500 GB, mehrere Varianten auf 2 TB. Namespace legt die Images als Sparse-Layer in seiner OCI-Registry ab: Leere Bereiche kosten wenige Bytes, ein Image mit zusätzlichem Xcode teilt sich die Basisschicht mit dem Vorgänger.

Auf die Knoten kommen die Images per Peer-to-Peer-Verteilung. Bei einer Verteilung von 500 GB an Hunderte bis Tausende Knoten rechnet Namespace mit rund einem halben Petabyte, das in einigen Dutzend Minuten Terabit pro Sekunde am zentralen Register bedeuten würde. Jeder Block wird deshalb einmal aus dem Register geholt und dann zwischen Nachbarknoten weitergereicht. Auf der Platte nutzt Namespace Sparse-Dateien und Klone von APFS (cp -c oder der Systemaufruf clonefile), sodass Löcher und gemeinsame Blöcke keinen Platz belegen. Die Platte dient als Quelle der VM, ein Netzwerk-Blockgerät wäre durch die Prozessgrenze zu langsam.

Wir haben keine dieser Zahlen nachgemessen. Eine Gegenprobe zu Netzwerk, Verteilung und Fünf-Minuten-Fenster haben wir nicht gefunden; die Diskussion auf Hacker News bringt keine Messungen dazu.

Was das für uns heißt

In unserem Hosts-Inventar kommt kein Mac vor, der Beitrag ist Marktbeobachtung und kein Erfahrungsbericht. Für die Planung von iOS-Builds lassen sich drei Dinge mitnehmen: Je Mac sind es höchstens zwei macOS-Gäste, Lieferzeiten für Mac minis waren 2026 lang, und ein Rechner mit FileVault braucht einen Plan für ungeplante Neustarts. Wer Build- und Testkapazität plant, findet Anknüpfungspunkte im Hub Server, Proxmox und Netzwerk. Wie sich VM und Container für Workloads unterscheiden, steht in Proxmox: GPU-VM oder LXC. Zur Beratung rund um Infrastruktur gibt es die Seite Leistungen.

Offen bleibt für jeden, der Macs ins Rack stellen will: Funktioniert der Plan für den Neustart ohne Hände vor Ort, bevor die erste Maschine ausfällt?

Weiterführende Quellen

• Namespace, Mac at Any Scale (Kirill Nikolaev): namespace.so
• Apple, SSH und FileVault: apple_ssh_and_filevault(7)
• Eclectic Light Company, Wie Apple VMs begrenzt: eclecticlight.co
• Apple, Lizenztexte aller macOS-Versionen (Index, nicht gelesen): apple.com/legal/sla
• Diskussion auf Hacker News: news.ycombinator.com