« Lorsque plusieurs Mac mini M4 clustervps partagent un même dépôt CephFS inter-régions, la cohérence ne se joue plus seulement sur le réseau : le cache client, les sessions MDS et les promotions rsync des artefacts se disputent la même enveloppe disque 1 To / 2 To. » Ce guide propose une matrice décisionnelle, des exemples exécutables (ceph.conf, rsync), une checklist de jalons et des renvois vers JuiceFS S3, NFSv4.1 & rsync et le centre d’aide pour cadrer l’exploitation.

1. Cache client agressif sans budget disque. Un client_readahead élevé accélère la compilation distribuée mais gonfle les lectures anticipées sur l’APFS local ; sans corrélation avec les graphes MDS, les équipes interprètent à tort un goulet côté CPU alors que le SSD approche déjà le premier jalon critique.

2. Timeouts MDS mal calibrés. Un mds_session_timeout trop court provoque des reprises de session pendant les phases de linking Xcode ; trop long, il retient des capacités MDS après incident et retarde le basculement propre vers un pair sain.

3. rsync concurrent sur le même sous-arbre. Deux pipelines qui poussent des binaires vers le même chemin logique CephFS créent des fenêtres de cohérence ambiguës ; croisez cette lecture avec SeaweedFS & jalons disque pour harmoniser les plafonds réseau et les files d’attente.

Matrice décisionnelle : cache client, MDS, rsync et jalons 1 To / 2 To

Objectif : arbitrer latence perçue contre marge disque sur une grappe homogène de Mac mini M4 ; les valeurs numériques restent des ordres de grandeur à valider sur votre contrat WAN clustervps. Lisez la matrice de haut en bas : d’abord le comportement du client CephFS, ensuite la durée de vie des sessions MDS, enfin le couple débit rsync et pourcentages APFS observés sur volumes 1 To ou 2 To.

Lecture transverse. Si votre charge mélange fichiers petits et promotions massives, comparez explicitement ce profil à la couche JuiceFS + cache S3 : la matrice ci-dessous reste valable conceptuellement, mais les noms de paramètres et les points de friction diffèrent.
Profil de chargeCache client (readahead)MDS (sessions)rsync (débit · concurrence)Jalons 1 To / 2 To
Builds Xcode parallèlesreadahead modéré (quelques MiB) pour limiter l’ondée disque localetimeouts médians, surveillance des reprises sur WAN--bwlimit 6000–10000, une file active par tenant70 % : réduire workers ; 80 % : couper promotions ; 90 % : stopper rsync & auditer inodes
Caches dépendances partagésreadahead bas sur chemins chauds, plus haut sur archives immuablestolérance légèrement plus longue pour limiter les reconnexions3000–8000, deux files sérialisées par préfixe70 % : décaler fenêtre ; 2 To : surveiller doubles écritures cross-tenant
Promotion d’artefacts lourdsreadahead minimal le long du transferttimeouts alignés sur la durée max d’un rsync unique8000–14000 + --partial-dir, jamais plus de deux rsync concurrents80 % : backoff exponentiel ; 90 % : ionice idle + file unique
Audit / observabilitéreadahead quasi nul sur chemins témoinstimeouts courts pour détecter clients bloquésdry-run hebdomadaire, un job70 % : alerter ; 1 To : prioriser purge locale avant nouvelle montée en charge

Exemples exécutables : fragment ceph.conf et rsync plafonné

Placez ces extraits dans votre dépôt d’infrastructure versionné ; adaptez les chemins de secret et les noms de cluster avant déploiement sur les nœuds Mac mini M4.

[client]
client_readahead_max_bytes = 4194304
client_readahead_max_periods = 4

[mds]
mds_session_timeout = 600
mds_log_max_segments = 50
nice -n 10 ionice -c2 -n7 rsync -a --delete-delay \
  --bwlimit=8192 --partial-dir=.rsync-partial --timeout=300 \
  ./DerivedData-export/ user@ceph-gw:/volumes/ci/artifacts/tenantA/

Verrous multi-projets : éviter la collision CI sur CephFS

Sur une grappe partagée, séparez physiquement ou logiquement les répertoires par produit, puis imposez un verrou d’écriture unique (fichier atomique, lease distant ou orchestrateur) avant toute promotion rsync vers CephFS. Pour les équipes qui combinent orchestration et état distant, prolongez la lecture avec Nomad, affinités & build lock et Pulumi, leases d’état & build lock afin d’aligner fenêtres de build et fenêtres de synchronisation.

Démarche opératoire en six étapes (preuve par ticket)

Chaque étape doit produire un artefact traçable (ticket, merge request ou capture Grafana) pour que les régions distantes rejouent le même scénario sans ambiguïté opérationnelle.

  1. Cartographier les chemins CephFS. Listez préfixes par tenant, droits POSIX attendus et volumes APFS locaux utilisés comme cache ou zone de staging.
  2. Baseliner le client. Déployez le fragment ceph.conf ci-dessus, mesurez latence MDS et taux de reprise sur une charge synthétique représentative.
  3. Encadrer rsync. Intégrez la commande plafonnée dans launchd ou votre scheduler CI ; journalisez débit réel vs --bwlimit.
  4. Activer les jalons disque. Branchez df et df -i sur alertes 70 / 80 / 90 % avec playbooks documentés dans l’aide clustervps.
  5. Tester la panne partielle. Coupez le lien WAN ~45 s pendant un rsync, observez reprise MDS et intégrité des fichiers partiels.
  6. Capacité & extension. Si le jalon 80 % devient récurrent sur 1 To, planifiez montée vers 2 To ou nœuds additionnels via l’achat avant d’augmenter encore le readahead client.

Checklist jalons disque & informations réutilisables

Seuil APFSSSD 1 ToSSD 2 To
70 %réduire readahead et parallélisme rsyncauditer espaces réservés et doubles pipelines
80 %couper promotions non critiques, conserver observabilité MDSdécaler fenêtres CephFS hors heures de pointe CI
90 %stopper nouveaux montages clients, purger caches locauxévacuer artefacts + vérifier df -i avant toute remontée
  • Paramètre : viser au moins 12–15 % d’espace libre sur le volume hébergeant le staging rsync avant toute campagne nocturne inter-régions.
  • Paramètre : conserver un écart d’au moins 30 % entre débit WAN contractuel et somme des --bwlimit actifs pour absorber les bursts MDS.
  • Gouvernance : toute modification de mds_session_timeout ou de préfixe CephFS est un changement d’API interne : double revue obligatoire.
Note d’exploitation. Les clés exactes de configuration CephFS évoluent avec la version du cluster ; confrontez toujours ces extraits à la documentation de votre fournisseur Ceph et à l’image système clustervps avant généralisation multi-région.
Capacité CephFS & grappe Mac M4

Étendez vos nœuds avant que le cache et rsync saturent le disque

Ajoutez des Mac mini M4 ou passez à des SSD 2 To pour séparer clients CephFS lourds et exécuteurs CI : parcours achat, tarifs et aide pour dimensionner SSH/VNC et la facturation mensuelle clustervps.

Acheter ou agrandir la grappe Mac M4 Comparer forfaits & capacités disque