Red Hats aktuelle Hinweise zur Skalierung von Satellite-Beständen mit Capsule Servern erinnern daran, dass Managementskalierung vor allem Topologie ist. Capsules bringen Content, Provisionierung und ausgewählte Dienste näher an verwaltete Hosts, senken zentrale Last und vermeiden unnötigen WAN-Verkehr. Ein hoher Hostzähler allein ist jedoch ein schwächerer Grund als eine klare Netz-, Latenz-, Sicherheits- oder Verfügbarkeitsgrenze.
Bedeutung für den Betrieb
Das Design beginnt mit Datenflüssen. Wo entsteht Content? Welche Standorte erreichen den Satellite Server? Wie registrieren sich Hosts? Welche Dienste stellt eine Capsule bereit? Wie verhält sich Synchronisierung über langsame oder eingeschränkte Verbindungen? Eine Capsule am falschen Ende einer unzuverlässigen Route verschiebt den Engpass, ohne das Wartungsfenster zu verbessern.
Kapazität wird nach Arbeitsprofil und nicht nur nach Knotenanzahl gemessen. Content-Synchronisierung, Paketdownloads, Provisionierung, Reporting und parallele Wartung belasten CPU, Speicher, Datenträger und Netz unterschiedlich. Kleine Außenstellen mit engen Fenstern können schärfere Spitzen erzeugen als große Zentralstandorte. Monitoring umfasst daher Warteschlangen, Sync-Dauer, Storage-Wachstum, Dienstzustand und fehlgeschlagene Aktionen.
Eine kontrollierte Erweiterung pilotiert einen Standort, erfasst die Ausgangslast zentral und testet Content-Promotion, Hostregistrierung, Patchbetrieb, Capsule-Ausfall und Resynchronisierung. DNS, Zertifikate, Firewallregeln, Backups und Lifecycle-Upgrades gehören in dasselbe Runbook. Verteiltes Management reduziert Abhängigkeit nur, wenn jede verteilte Komponente selbst wiederherstellbar ist.
Praktische Konsequenz
Die praktische Schlussfolgerung: Capsule Server sind keine generischen Skalierungseinheiten, sondern Betriebsgrenzen mit eigenem Zustand und eigenen Fehlerbildern. Sie gehören dorthin, wo Lokalität oder Isolation messbar nötig sind, werden aus beobachteter Arbeit dimensioniert und erhalten klare Verantwortung für Content und Recovery.