Wat de werkervirtualisatie per applicatiecluster en per afnemer draagt: de infra-naamruimte, de virtuele werkers en hun maten, de beelden, de opslag, de virtuele servers als dienst, fysieke werkers en GPU-knooppunten.
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
De werkervirtualisatie draagt per applicatiecluster een afgeschermde infra-naamruimte met de virtuele werkers van dat
cluster, en vanaf groeipadstap 3 per afnemer een naamruimte met virtuele servers. Werkers hebben drie vaste maten,
starten uit vrijgegeven beelden en worden bij iedere update vervangen. Fysieke werkers en GPU-knooppunten zijn
varianten die later komen.
Waarom zo
Omdat werkers en virtuele servers hetzelfde patroon volgen, vraagt een nieuwe afname geen eigen ontwerp: naamruimte,
identiteit, netwerk en quotum ontstaan samen uit het leverpad en verdwijnen samen bij beëindiging. Vaste maten en
vrijgegeven beelden houden de capaciteit voorspelbaar en de software herleidbaar. De opslag van teams blijft buiten de
werkervirtualisatie, zodat ieder cluster een eigen ruimte en eigen sleutels op het opslagcluster heeft.
Wat de werkervirtualisatie per applicatiecluster draagt, is één geheel: de naamruimte clusters-<naam>, de technische identiteit met haar rol, het localnet-netwerk, het quotum en, bij een cluster met volumes, het label voor het netwerk op VLAN 620 met de adresreeks daarop, die alleen het leverpad zet. Het leverpad maakt het geheel vóór de werkers en verwijdert het na de werkers en vóór het segment. Het quotum is het maximumaantal werkers plus één, maal de werkermaat, met een rootvolume van 64 GiB per werker.
Toelichting
De infra-naamruimte wordt nooit gedeeld, en een cluster heet nooit clusters. Gevolg: de capaciteitsboekhouding rekent met maxima. Een negatieve proef bij aanmaken en verwijderen toont de begrenzing van de identiteit aan.
Het clusterbeheer maakt de werkers als virtuele machines in clusters-<naam>, met de technische identiteit van het cluster, een rootvolume van 64 GiB op de RBD-klasse van de werkervirtualisatie, het clustersegment als eerste aansluiting en, bij een applicatiecluster met volumes, VLAN 620 als tweede. Zonder het clusternetwerk van de werkervirtualisatie (attach-default-network false) bereiken zij haar API niet. Bij een update komt eerst een nieuwe werker bij (maxSurge 1).
Werkers hebben drie vaste maten, als exemplaarsoorten van de virtualisatie: S met 4 vCPU en 16 GB, M met 8 vCPU en 32 GB en L met 16 vCPU en 64 GB geheugen. Dezelfde maten gelden voor de NodePool; een andere maat kan alleen met een ontwerpbesluit.
Toelichting
Vaste maten houden de capaciteit voorspelbaar en de plaatsing eenvoudig.
Werkers en het besturingssysteem van de knooppunten worden vervangen, niet ter plekke bijgewerkt. Alleen de firmware en het besturingssysteem van virtuele servers worden ter plekke bijgewerkt, naar een basislijn.
Toelichting
Zo blijft een werker gelijk aan versiebeheer. Gevolg: er is ruimte en quotum nodig voor één extra werker.
Standaardbeelden worden niet automatisch geïmporteerd: alleen vrijgegeven beelden op inhoudskenmerk starten, ook op het basisdienstencluster. Het werkerbeeld is het onveranderbare besturingssysteem uit de releaseversie van het gastcluster, via de spiegel en op inhoudskenmerk in de clusterdefinitie; een nieuwe versie vervangt alle werkers en doorloopt dezelfde toelatingscontrole. Een virtuele server start uit één basisbeeld per servervariant, van de leverancier via de spiegel of door RWS samengesteld met het pijplijnsjabloon of via de toelatingsroute, met onderdelenlijst en handtekening; de automatisering controleert de handtekening vóór de vrijgave. Platformmachines, zoals de leden van de externe verkeersverdeling en de herstelservers, starten langs dezelfde route.
Toelichting
Een nieuw beeld is zo altijd een bewuste vrijgave. De beelden van virtuele servers staan op inhoudskenmerk in een platformnaamruimte van de werkervirtualisatie, de servervariant in de opslagplaats Catalogus. Het beeld van de leden van de externe verkeersverdeling bevat rsyslog met TLS-doorsturing naar de SIEM, de terugvaloptie voor hun audit.
Teams krijgen geen opslag via de werkervirtualisatie. Ieder applicatiecluster met volumes koppelt over VLAN 620 rechtstreeks aan het opslagcluster, met een eigen ruimte en eigen sleutels; een cluster zonder volumes krijgt geen opslagkoppeling en geen aansluiting op VLAN 620. Alleen clusters in de herstelzone krijgen hun volumes via de gastklasse van de werkervirtualisatie, zonder VLAN 620 en dus zonder pad naar de opslag van productie, tot hun terugkeer naar productie.
Toelichting
Aanvaard restrisico: een in de herstelzone teruggezet applicatiecluster heeft zijn volumes in de ruimte van de werkervirtualisatie, zonder eigen sleutels; de zone heeft geen route naar productie en wordt na gebruik verwijderd. Gevolg: het /22 van VLAN 620 wordt een capaciteitsgrens. Valt het clusterbeheer terug op storageDriver Manual, dan staat de gastklasse in teamnaamruimten op quotum 0.
Virtuele servers als dienst volgen hetzelfde patroon als de werkers: een naamruimte met quotum per afnemer, exemplaarsoorten, vrijgegeven beelden, het segment van het profiel en gedeclareerde netwerken uit de dienstbeschrijving. Het segment per profiel is VLAN 650 voor ontwikkelen en beproeven, 651 voor reguliere en 652 voor bedrijfskritische productie. Een virtuele server krijgt een vast adres, en de console loopt via de beheerwerkplek.
Toelichting
Weigerend beleid voor meervoudige netwerken scheidt de afnemers op een segment. Dat is een acceptatiecriterium dat vóór de vrijgave van de dienst moet zijn aangetoond, met een eigen segment per afnemer als terugvaloptie.
Het team start, stopt en herstelt zijn virtuele servers via zelfservice; het platform onderhoudt het besturingssysteem, met eindpuntbeveiliging in de gast (Tanium en Trellix, voor Windows Microsoft Windows Defender). Een bestaande machine gaat over na een migratieproef, met de oude machine als terugvaloptie tot de acceptatie.
Toelichting
De gastbesturingssystemen zijn Red Hat Enterprise Linux en Windows Server, per servervariant geschikt bevonden; Linux-servers krijgen hun updates via de Linux-updatedienst van RWS.
De werkervirtualisatie heeft geen eigen dienstprofiel. Voor ieder profiel gelden ten hoogste 2 seconden onderbreking bij live-migratie, onderhoud zonder uitval van werkers en een herstart binnen 30 minuten na de melding van een serveruitval. Een virtuele server met één exemplaar ligt tot die herstart stil; wie dat niet mag, kiest twee exemplaren in verschillende rekken of het profiel bedrijfskritische productie.
Fysieke werkers zijn servers van het type van de werkervirtualisatie voor één applicatiecluster, een variant naast de virtuele werkers. Zij tellen niet mee in de capaciteit van de werkervirtualisatie en komen niet in de eerste levering, want het sjabloon kent alleen de drie werkermaten.
GPU-knooppunten vormen in de werkervirtualisatie een eigen groep, met een markering die alleen machines met een GPU-aanvraag toelaat en met één GPU-knooppunt als reserve. Een GPU gaat in zijn geheel door doorgifte naar één virtuele werker, zonder opdeling; virtuele servers krijgen geen GPU. Zo’n werker verhuist niet live, maar wordt bij onderhoud vervangen op een ander GPU-knooppunt.
Toelichting
Reden: één werkerpad en dezelfde aansluiting als een gewoon werkerknooppunt. De GPU-knooppunten hebben ieder twee GPU’s van 96 GB en komen in groeipadstap 3.