Netwerk en scheiding van afnemers

Beheer, opslag, live-migratie en machineverkeer hebben ieder een eigen VLAN, en verkeer tussen zones volgt de vaste stromen van de zonematrix. De knooppunten staan in de zone platform (vrf-platform, VLAN 610 ongetagd op br-ex) en iLO heeft een eigen poort in VLAN 600; de machines hangen via localnet-netwerken in de segmenten van hun zone. VLAN 620 voor opslag en VLAN 630 voor live-migratie hebben geen gateway.

Ieder gehost cluster heeft een eigen localnet-segment in de fabric, dat met het cluster ontstaat en verdwijnt: voor een applicatiecluster een /26 uit de reeks van zijn profiel (VLAN 1000–1999) met een anycast-gateway, voor de gehoste platformclusters (bouw, portaal en besturing van het dienstennetwerk) een VLAN uit 700–709 met L2-VNI 10700–10709 en een /26 uit de platformreeks in vrf-platform. Het leverpad legt het segment aan op de trunks van alle werkerknooppunten. Clusters en herstelservers in de herstelzone hangen aan VLAN 690 in vrf-herstel, dat daarom ook op die trunks staat.

Een virtuele werker heeft alleen het segment van zijn cluster, dat bij het routeringsdomein van het profiel hoort, en bij een cluster met volumes VLAN 620 met een vast adres uit de reeks van zijn cluster; nooit het clusternetwerk van de werkervirtualisatie.

Alleen werkers van clusters met volumes krijgen een aansluiting op het opslagclientnetwerk (VLAN 620, MTU 9000), alleen beschikbaar in hun naamruimte clusters-<naam>. Zo wordt hun opslagverkeer niet gerouteerd en is er geen route naar de opslag. De aansluiting valt buiten het netwerkbeleid van het cluster; toegangslijsten op de leaf laten alleen verkeer naar opslagknooppunten en objectgateways toe, niet tussen werkers.

Een naamruimte krijgt een secundair netwerk alleen als de dienstbeschrijving het vermeldt, en alleen platformbeheer definieert clusterbrede netwerken: het werkernetwerk van een applicatiecluster is clusterbreed gedefinieerd, maar alleen beschikbaar in clusters-<naam>. Op een segment voor virtuele machines is verkeer tussen afnemers geweigerd.

VLAN 650 ligt in vrf-afn-p1: in de eerste levering met alleen proefmachines van het platform, vanaf groeipadstap 3 met virtuele servers in het profiel ontwikkelen en beproeven. Virtuele servers in reguliere en bedrijfskritische productie krijgen VLAN 651 in vrf-afn-p2 en VLAN 652 in vrf-afn-p3 (L2-VNI 10651 en 10652), elk een /23 per cel.

Het netwerkbeleid van een cluster dekt secundaire interfaces niet, dus machines van verschillende afnemers op één localnet-segment zijn niet vanzelf gescheiden. Vanaf groeipadstap 3 scheidt standaard weigerend beleid voor meervoudige netwerken (MultiNetworkPolicy) de naamruimten op dat segment. Werkt dat beleid niet op localnet-netwerken, dan krijgt iedere afnemer een eigen segment met VLAN en /26 uit de reeks van zijn profiel.

Vanaf groeipadstap 3 wordt bond0.660 de VTEP voor bestaande netwerkverbanden van virtuele servers, met een VNI uit 20000–29999 per verband. Tot dan loopt zo’n verband als localnet-netwerk op zijn eigen VLAN.

De netwerkdefinities voor machines hebben geen adresbeheer (IPAM). Op hun clustersegment krijgen virtuele werkers hun adres daarom via DHCP uit Infoblox, doorgegeven door de anycast-gateway; de reeks laat het ingangsadres en andere vaste adressen van het cluster vrij, en de uitgifte wordt dagelijks vergeleken met de clusterinventaris. Op VLAN 620 (zonder gateway) en VLAN 690 (herstelzone) is er geen DHCP: iedere werker krijgt daar een vast adres uit een reeks per cluster van het maximumaantal werkers plus één, binnen het /22 van de cel of de herstelreeks, gereserveerd in Infoblox, geregistreerd in NetBox en vastgelegd in de netwerkconfiguratie van de NodePool. Het leverpad reserveert de reeks vóór de werkers en geeft haar na beëindiging vrij, en registreert per afname de netwerken en statische adressen.

De werkervirtualisatie heeft alleen de vaste verbindingen in de tabel.

API en ingang van de werkervirtualisatie hebben een certificaat uit de tussen-CA van de cel via cert-manager, ten hoogste 90 dagen geldig en na twee derde van de looptijd vernieuwd, met het TLS-profiel Modern waar alle clients dat ondersteunen, anders Intermediate. Migratie- en opslagverkeer zijn altijd versleuteld: migratieverkeer met TLS en automatisch vernieuwde interne certificaten van de virtualisatie, zonder instelling die dat uitzet, en opslagverkeer met messenger v2 in de beveiligde modus, ook vanuit de werkers. De cryptografie volgt per pad de cryptografietabel van RWS.

De werkervirtualisatie krijgt geen IPsec tussen de knooppunten, net als de andere platformclusters; zij versleutelt per verkeerssoort. Het machineverkeer loopt niet over het clusternetwerk, en EVPN werkt niet met IPsec.