2026 Multi-Region Mac mini M4
Nomad-Batch-Affinität, Buildsperre & 1TB/2TB-Entscheidungsmatrix

Dieser Leitfaden verzahnt Nomad mit der Artefakt-Logik aus Mac mini M4 Multi-Region-Cluster: rsync-Matrix & Buildsperren, der Registry-/DNS-Matrix in Split-DNS & Artefakt-Registry auf M4-Mehrregionen-Clustern sowie Session-Hinweisen aus Mosh vs. SSH bei geteilten Mac mini M4. Lesen Sie die Tabellen unten als Ergänzung, nicht als Ersatz für Ihre Retention- und Backup-Policies.

Typische Bruchstellen im Parallel-Betrieb

1. Zu grobe Platzierung: Ohne einheitliche meta-Keys landen schwere Xcode-Batches auf beliebigen Clients; Latenz und thermische Drossel springen, ohne dass der Scheduler es als Fehler meldet.

2. Schein-Parallelität: Zwei Nomad-Allocations rufen dieselbe xcodebuild-Pipeline auf demselben Checkout auf — ohne Buildsperre korruptieren DerivedData und Zwischenartefakte.

3. Kapazitätsblindheit: Auf 1TB-SSDs füllen mehrere parallele Archive und rsync-Ziele den freien Speicher schneller als Monitoring-Alerts; 2TB-Knoten brauchen andere Warnschwellen und längere Retention-Fenster.

Entscheidungsmatrix: 1TB- vs. 2TB-Speicher-Wasserstände

Die folgende Matrix ist eine Arbeitshypothese für dedizierte Mac mini M4-Knoten mit parallelem CI; passen Sie die Gigabyte-Schwellen an Ihre DerivedData-Hygiene und an die Fan-out-Breite aus dem rsync-Artikel an.

SSD-Profil	Warn-Wasserstand (frei)	Hard-Stop / Scheduling	Skalierungs-Hinweis
1TB (Parallel-CI)	< ca. 220 GB frei über 24h gleitend	Keine neuen großen Batch-Allocations auf dem Knoten; Cleanup-Job vorschalten	Golden Node strikt; rsync-Ziele kompakt halten
2TB (Parallel-CI)	< ca. 380 GB frei über 24h gleitend	Fan-out drosseln; parallele Archive auf zweiten Knoten verlagern	Längere Artefakt-Retention möglich; trotzdem Quoten pro Pool

Client-Metadaten, Affinität und ausführbare Constraints

Stempeln Sie jeden Nomad-Client mit konsistenten Metadaten: Region, batch_heavy=true, Xcode-Minor, SSD-Größe und optional eine golden_artifact=true-Marke für den Knoten, der als einziger nach außen rsync-t. Im Job-HCL trennen Sie hart und weich: affinity mit operator = "=" erzwingt passende Chips und Pools; ein zweiter Block mit weight bevorzugt thermisch kühlere oder näher am Registry-Endpunkt liegende Hosts — ohne harte Ausschlüsse bei Wartungsfenstern.

Im Beispiel unten verlangt der Job einen M4-Pool in eu-west, bevorzugt einen als golden markierten Host und lehnt Knoten ohne Batch-Tag ab. Der constraint-Abschnitt mit distinct_hosts verhindert, dass zwei schwere Compiler-Allocations auf derselben Maschine landen, wenn Sie mehrere Instanzen des Jobs starten — ein häufiges Muster bei parallel gekoppelten Build-Pipelines.

job "ios-batch-m4" {
  region      = "global"
  datacenters = ["dc1"]
  type        = "batch"

  group "compile" {
    count = 2

    constraint {
      operator = "distinct_hosts"
      value    = "true"
    }

    affinity {
      attribute = "${node.meta.region}"
      operator  = "="
      value     = "eu-west"
      weight    = 80
    }

    affinity {
      attribute = "${node.meta.golden_artifact}"
      operator  = "="
      value     = "true"
      weight    = 50
    }

    task "build" {
      driver = "exec"

      config {
        command = "/bin/bash"
        args    = ["-lc", "flock -n /var/tmp/repo.lock ./scripts/ci_build.sh"]
      }

      resources {
        cpu    = 12000
        memory = 24576
      }
    }
  }
}

Erläuterung in Kurzform: Der äußere job-Block definiert Batch-Semantik; group bündelt Tasks. constraint distinct_hosts ist der harte Schutz vor Doppelbelegung pro Host bei count > 1. Die affinity-Blöcke sind gewichtete Wünsche — der Scheduler darf ausweichen, solange keine harten constraint-Verletzungen entstehen. Im task-Template kapselt flock die eigentliche Buildsperre; -n beendet mit klarem Fehlercode, den Nomad als nicht retry-würdig oder mit Backoff werten kann.

Anbindung an rsync-Artefakte nach dem Batch

Wenn der Build auf dem Golden Node endet, sollte ein zweiter Schritt — entweder als Folge-Task in derselben Group oder als parametrisierter dispatch_payload-Job — genau die rsync-Profile aus der Artefakt-Matrix ausführt: gleiche Quelle, gleiche Exclude-Listen, --delete-delay nur nach erfolgreicher Prüfsumme. So bleibt die Nomad-Orchestrierung die Wahrheit über wann synchronisiert wird; rsync bleibt Transport — nicht Steuerlogik.

Rollout in fünf Schritten

1. Client-meta auf allen Mac mini M4-Hosts vereinheitlichen und mit nomad node status gegen eine Referenzdatei diffen.
2. Batch-Jobs mit Affinität und distinct_hosts in Staging ausrollen; thermische und I/O-Metriken pro Knoten dokumentieren.
3. Buildsperre im Task testen: absichtlich zwei Allocations auf denselben Checkout — eine muss deterministisch scheitern oder warten.
4. rsync-Schritt an Matrix koppeln; nach jedem Lauf freien Speicher gegen die 1TB/2TB-Wasserstände prüfen.
5. Bei wiederholter Warnstufe horizontal skalieren (zweiter M4-Knoten) statt Schwellen nur zu erhöhen — sonst verschieben Sie das Problem in die WAN-Latenz.

Kennzahlen und Parameter zum Zitieren

• Ressourcen-Faustregel: Pro schwerem iOS-Batch 12–16 vCPU und 24–32 GB RAM im resources-Block reservieren, sonst triggert der Scheduler Fremdverdrängung auf demselben M4.
• Sperrgranularität: Eine flock-Datei pro Repo-Arbeitsbaum, nicht global pro Host — vermeidet falsche Serialisierung unabhängiger Projekte.
• Skalierungs-Wasserstand: Wenn der gleitende 24h-Mindestfreiraum dreimal unter die Warnlinie fällt, ist ein zusätzlicher Knoten kostengünstiger als tiefer STORCH-Cleanup in Produktionsfenstern.

Steuerelement	Wirkung im Parallel-Cluster	Typischer Fehler
Affinity weight	Bevorzugt Region/Golden Node, ohne harte Ausschlüsse	Gewichte zu hoch gesetzt — Scheduler kann keine Ausweichknoten finden
constraint distinct_hosts	Verhindert doppelte schwere Allocations auf einem Host	Mit count=1 gesetzt — bringt keinen Mehrwert
flock Buildsperre	Serialisiert Schreibzugriffe auf gemeinsame Trees	Lock-Pfad auf temporärem Volume — nach Reboot weg