Het vlootcluster

Er is één hub voor alle cellen, geen volledige hub op het clusterbeheer van iedere cel.

Het vlootcluster staat logisch buiten de cellen, maar fysiek in AM4: zijn drie knooppunten staan in drie van de vier rekken van cel 1, op de fabric van cel 1 in het routeringsdomein platform. In de eerste levering deelt het vlootbeheer zo rekken, stroom en netwerk met cel 1, naast opslag, toegangsvoorziening, geheimenbeheer, containerregistry en versiebeheer; uitval van AM4 is uitval van het vlootbeheer.

Het vlootcluster krijgt zijn volumes en objectopslag via Data Foundation in externe modus van het opslagcluster van cel 1, zonder Multicloud Object Gateway; zijn lokale gegevensschijven blijven ongebruikt. LVM Storage is voor het clusterbeheer en het basisdienstencluster.

De knooppunten van het vlootcluster staan in drie verschillende rekken; uitval van één knooppunt of rek onderbreekt het vlootbeheer niet. De hub draait met hoge beschikbaarheid (availabilityConfig High), met de hubonderdelen grotendeels in twee exemplaren.

De samengevatte metingen van de vloot en de centrale beveiligingsvoorzieningen staan op het vlootcluster: Central van Advanced Cluster Security, de ondertekenvoorziening van Trusted Artifact Signer en de analysevoorziening voor onderdelenlijsten van Trusted Profile Analyzer. Zij staan in eigen naamruimten zonder toegang voor teams, de ondertekenvoorziening als geïsoleerde dienst; het vlootbeheer rolt hun onderdelen per cluster uit. Zij horen bij het vlootbeheer en wachten niet op de eigen bewakingsvoorziening; dat vraagt capaciteit op het vlootcluster.

De samengevatte metingen van de vloot staan in een eigen bucket in de realm platform van de objectopslag van cel 1, met een vaste lijst van metingen en zonder logboeken: ruw 7 dagen, per 5 minuten 30 dagen en per uur 90 dagen bewaard, in 200 GB. Grafana is alleen voor platformrollen; teams zien hun metingen, ook die van hun opslag, in hun eigen cluster.

De aangevraagde processor en het aangevraagde geheugen van alle onderdelen op het vlootcluster blijven onder twee derde van zijn capaciteit, zodat na uitval van één knooppunt alles op de twee andere past; één knooppunt is reserve en wordt niet uitgegeven. Bij 55 procent wordt een capaciteitsbesluit voorbereid, bij 80 procent van het gemeten maximum aantal beheerde clusters wordt uitbreiding in gang gezet.

Een referentiemeting bij de bouw van het vlootbeheer meet het gebruik per beheerd cluster (processor, geheugen, volumes en metingen) en dat van de beveiligingsvoorzieningen op het vlootcluster, met de import van tien gehoste clusters en een uitrol over alle golven als belasting. Daaruit volgt het maximum aantal beheerde clusters. De referentiemeting, de uitrolgroepen en de clusterlabels worden vastgelegd in de celregistratie.

In groeipadstap 1 beheert het vlootbeheer ten hoogste dertien clusters; meer na uitbreiding van het clusterbeheer tot 24 gehoste clusters. Groeipadstap 2 voegt de clusterset c2 en golf-2 toe via het gekoppelde routeringsdomein, met het hersteldoel in cel 2. In groeipadstap 3 en 4 sluiten meer teams, clusters en voorzieningen op locatie aan, zonder van het vlootbeheer af te hangen; een eigen GitOps-exemplaar voor een zwaar cluster komt er alleen na een ontwerpbesluit.

Platformbeheer is eindverantwoordelijk voor het vlootbeheer. Tot de overdracht bouwt het ontwikkelteam het vlootbeheer en richt het er de beveiligingsbaseline, de bewaking en de standaardinrichting van applicatieclusters mee in. De CISO-functie is eigenaar van de normen in het beleid en besluit mee over uitzonderingen; het SOC is eigenaar van de detectie. Namen en adressen van het vlootcluster staan alleen in de uitwerking per locatie en de inventaris.

Het vlootbeheer levert geen dienst aan teams, maar inrichting, beleid en overzicht aan deze afnemers. Tussen de cellen scheiden de clustersets: uitrol, beleid en beheerrechten worden per set gebonden.

Het vlootbeheer wordt in fasen opgebouwd, elk met een voorwaarde.