Opbouw van het platform

Het platform bestaat uit beheercellen onder één vlootbeheer. Iedere cel heeft een eigen clusterbeheer, werkervirtualisatie, opslagcluster en basisdienstencluster, en wordt afzonderlijk onderhouden en hersteld, zodat een storing, fout of aanval binnen de cel blijft.

In de eerste implementatie heeft ieder datacenter één beheercel: de eerste levering bouwt beheercel 1 in AM4, groeipadstap 2 beheercel 2 in AM2. Cel en datacenter vallen zo samen als storingsgebied: uitval van een datacenter is uitval van één cel, en de overname van een bedrijfskritische dienst is overname naar het andere datacenter, per dienst voorbereid en beproefd.

Opslag, stroomvoorziening, geheimen en beheerrechten zijn per cel gescheiden; anders raakt één storing of één gestolen beheerrecht alsnog beide cellen. Iedere cel heeft daarvoor eigen platformclusters, een eigen geheimenbeheer met een eigen tussen-CA, een eigen toegangsvoorziening en identiteitsbeheer en een eigen fabric.

Een cel is niet aan een locatie gebonden: meer cellen per datacenter of een cel elders blijven mogelijk zonder ander ontwerp. De plaatsing van iedere volgende cel wordt beoordeeld op herstel en gedeelde afhankelijkheden, waaronder verstoringen die beide Amsterdamse locaties tegelijk treffen; die vangen de cellen in AM4 en AM2 niet op. Een nieuwe cel, een andere plaats voor een cel of een cel over twee datacenters vraagt daarom een ontwerpbesluit over herstel en gedeelde afhankelijkheden.

Het platform kent vijf soorten platformclusters, elk met een eigen kerntaak: het vlootbeheer voor de hele vloot, buiten de cellen, en per cel het clusterbeheer, de werkervirtualisatie, het opslagcluster en het basisdienstencluster. Hun servers en capaciteit liggen vast bij de clusters zelf.

In de doelsituatie met twee cellen, vanaf groeipadstap 2, staat het vlootbeheer boven de twee beheercellen. Per cel draaien de clusters, virtuele machines, databases en het opslagcluster, met daaromheen de netwerk-, beveiligings-, identiteits- en herstelvoorzieningen. De onveranderbare kopie en de herstelkern staan buiten de cellen; het tweede exemplaar van een bedrijfskritische dienst staat in de andere cel.

Het vlootbeheer staat op een eigen compact cluster buiten de cellen: één overzicht en één uitrol voor alle cellen, en bij uitval van het vlootbeheer draaien de clusters door. In de eerste levering gebruikt het vlootcluster nog het opslagcluster, de toegangsvoorziening en de basisdiensten van cel 1; verlies van cel 1 raakt dan ook het vlootbeheer.

De besturing van applicatieclusters is gehoste besturing op het clusterbeheer: ieder team krijgt een eigen cluster met een eigen versie en onderhoudsvenster binnen de ondersteunde versiecombinaties, tegen beperkte beheerlast. Een gehoste besturing vraagt een fractie van de middelen van drie eigen besturingsknooppunten.

Werkers draaien als virtuele machines op een eigen cluster voor werkervirtualisatie. Die virtualisatie is zelf een cluster van het platform, met hetzelfde vlootbeheer, dezelfde toelatingscontrole voor de werkerbeelden en dezelfde back-up, en is uit code te herbouwen; werkers worden vervangen, niet ter plaatse bijgewerkt.

Iedere cel heeft een apart opslagcluster op eigen servers. De opslag staat los van de clusters die haar gebruiken en wordt afzonderlijk onderhouden en hersteld; verlies van één server of een heel rek uit een gezonde toestand kost geen gegevens.

De basisdiensten staan per cel op een eigen compact cluster, zodat een cel zelfstandig werkt en herstelt. Basisdiensten die hun gegevens zelf repliceren, gebruiken lokale opslag, zodat het geheimenbeheer bruikbaar blijft bij herstel van het opslagcluster, zolang de ontgrendelsleutel buiten de cel, de naam- en tijdvoorziening en de toegang beschikbaar zijn.

Herstel loopt via de back-upvoorziening van RWS. De herstelomgeving wordt op afroep uit code opgebouwd met capaciteit uit de reserve van de andere cel en daarna weer verwijderd; die reserve moet dan ook de overname van bedrijfskritische diensten dragen.

Firewalls zijn de enige overgang tussen zones en verkeer is standaard dicht. Een team declareert een verbinding en het platform legt haar aan; de zonecontrole toetst haar vooraf aan de zonematrix, zodat geen gedeclareerde verbinding buiten die matrix om ontstaat. Routes en netwerkbeleid dwingen dit ook af; secundaire interfaces en het hostnetwerk vallen buiten het netwerkbeleid en mogen alleen als de dienstbeschrijving ze vermeldt.

Vlootbrede rollen en gedeelde voorzieningen kunnen wel beide cellen raken: het vlootbeheer, het versiebeheer, de ondertekening, RWS-HR en de directory als bronnen van het identiteitsbeheer, de certificaatvoorziening (PKI), de automatisering, de onderlaag van het netwerk en externe diensten. Daarvoor gelden aparte maatregelen, waaronder een beproeving van een gecompromitteerd vlootbeheer in de toets herstel na een aanval. Toegangsvoorziening en identiteitsbeheer zelf zijn per cel.

Buiten de cellen staan, naast het vlootbeheer, de herstelvoorzieningen: een onveranderbare kopie van alle back-ups op de bestaande back-upvoorziening van RWS, en de herstelkern. Zij staan buiten de normale beheerrechten van het platform, zodat herstelmateriaal en noodtoegang niet alleen in de getroffen cel zitten.