Het datacenternetwerk van een cel

De fabric bestaat uit toegangsswitches in ieder rek (leaves), onderling verbonden via verdeelswitches (spines), met aparte border leaves voor de firewalls en de koppelingen naar buiten de cel. Het gerouteerde fysieke netwerk tussen de switches is de onderlaag; daaroverheen lopen de virtuele netwerken, de overlay.

Alles is dubbel uitgevoerd: twee spines, twee leaves per rek en twee border leaves. Iedere server, firewall en koppeling hangt met een bundel aan een leaf-paar met EVPN-multihoming (ESI-LAG), zonder directe verbinding tussen de twee leaves. Uitval van één kabel, poort of switch mag geen verbinding onderbreken; de testset meet de omschakeltijd.

De fabric van een cel bestaat, uitgaande van vier rekken, uit switches van de GX2-generatie uit de huidige inventaris van RWS.

Alle switches van een cel draaien één versie van NX-OS: 10.6(4)M, een onderhoudsrelease van de 10.6-lijn; terugvaloptie is de door Cisco aanbevolen release, nu 10.5(5)M. De fabriccontroller is Nexus Dashboard 4.2.1 met de fabriccontroller, als cluster van drie fysieke knooppunten of als virtueel cluster met datanodes; versie 4.3.1 volgt zodra de Ansible-collectie cisco.dcnm haar ondersteunt. Per switchmodel bevestigt de leverancier dat de release de gebruikte functies ondersteunt, zoals het opsplitsen van poorten, EVPN-multihoming, MACsec en Multi-Site, bij de acceptatie van de fase waarin de functie wordt ingezet.

Per leaf is de bandbreedte naar de servers 5 × 100 Gb plus 2 × 400 Gb, samen 1,3 Tb, tegenover 0,8 Tb aan uplinks: tussen rekken afgerond 1,6 : 1. Binnen een rek schakelt de leaf lokaal, zodat opslagverkeer binnen het rek de uplinks niet raakt. Zolang een spine uitvalt, verdubbelt de verhouding.

Er is bewust één beheer-leaf per rek, voor servermanagement, de beheerpoorten van de switches en het beheer van de netwerkapparatuur. Zij deelt de spines met het datapad, zodat het beheerpad niet volledig onafhankelijk is van de fabric; ook de fabriccontroller is langs die weg bereikbaar. Uitval raakt het apparatuurbeheer van het rek, niet rechtstreeks de dienstverlening. Dat is een vastgelegd restrisico.

De parameters van onderlaag en overlay vormen de basis van het detailontwerp per cel. De adressen en AS-nummers staan in het adresplan van de fabric.

De onderlaag gebruikt OSPF en de overlay iBGP met EVPN, met de spines als route reflectors: twee eenvoudige, goed begrepen protocollen met elk één taak. Met de spines als enige EVPN-buren vraagt een nieuwe leaf één sjabloon.

Onbekend en broadcastverkeer gaat met ingress replication, zonder multicastrouting in de onderlaag; ARP-onderdrukking en storm control beperken het broadcastverkeer. Dat houdt beheer en controle eenvoudig.

Ieder gerouteerd segment heeft een gedistribueerde anycast-gateway op alle leaves. Een virtuele machine houdt zo bij verhuizing tussen rekken dezelfde gateway en netwerkinstellingen, en verkeer wordt al op de leaf van het eigen rek gerouteerd.

Iedere overgang tussen routeringsdomeinen loopt via het firewallcluster op de border leaves, met per routeringsdomein een subinterface in een eigen koppelvlak-VLAN en een eBGP-sessie tussen de VRF op de border leaf en de firewall. De firewall kondigt de standaardroute en de reeksen van de andere domeinen aan, de fabric de reeksen van het eigen domein. Omdat de reeksen van de andere domeinen met het AS-nummer van de cel terugkomen, accepteert de border leaf per routeringsdomein het eigen AS-nummer (allowas-in), zonder standaardroute als omweg.

De koppeling met het RWS-netwerk loopt via het externe routeringsdomein op de border leaves naar de bestaande RWS-routers, met eBGP en een prefixfilter dat alleen de vastgelegde reeksen accepteert. Missiekritieke netwerken horen niet bij de fabric; hun voorgeschreven koppelvlakken sluiten in een eigen routeringsdomein aan op de border leaves.

Valt een onderdeel van de fabric weg, dan detecteren BFD en de routering het verlies en berekenen zij de overblijvende paden; multihoming en ECMP gebruiken de beschikbare leaf- en spineverbindingen. Netwerkbeheer meet in een dienstproef de werkelijke omschakeling en de werking bij lagere capaciteit.

De fabric bedient vier verkeersklassen, op basis van de DSCP-waarde die de leaf bij binnenkomst toekent, naar het VLAN of voor besturingsverkeer naar het protocol; servers markeren niet zelf. Opslag (VLAN 620 en 621) krijgt de hoogste gewogen klasse met 40 procent gegarandeerde bandbreedte (CS4), live-migratie (VLAN 630) een middenklasse (AF31) met een plafond van 25 procent per poort, en alleen het besturingsverkeer (BGP, BFD en OSPF) de beschermde klasse (CS6), niet het VXLAN-verkeer van de clusters in VLAN 660. Al het overige, ook beheerverkeer in VLAN 600 en 610, valt in de standaardklasse. Explicit Congestion Notification staat aan in alle klassen en werkt voor eindpunten die het ondersteunen.

Verliesvrije levering (Priority Flow Control) wordt niet ingericht. Zij komt pas aan de orde bij RDMA voor AI-werklasten, in een eigen klasse en na een eigen proef.

De onderlaag heeft MTU 9216, zodat segmenten met MTU 9000 passen: VXLAN over IPv4 voegt 50 bytes toe en tunneleindpunten fragmenteren niet. Opslag- en migratiesegmenten hebben MTU 9000 van begin tot eind; het ingangssegment heeft MTU 1500.

De fabric is code. De datacenterregistratie is de bron, een pijplijn maakt en toetst de configuratie, en niemand wijzigt rechtstreeks op een switch. Netwerkbeheer beoordeelt iedere wijziging als wijzigingsvoorstel. Een wijziging buiten de pijplijn om, ook via het noodaccount, is een afwijking: zij wordt gemeld en de pijplijn herstelt de bedoelde toestand uit versiebeheer.

Een wijziging loopt langs een vaste keten van registratie tot switch, met bij iedere schakel een controle. Het leverpad gebruikt dezelfde keten voor het segment van een applicatiecluster.

De fabriccontroller vergelijkt dagelijks de werkelijke configuratie met de bedoelde. Een handmatige wijziging wordt binnen een dag als afwijking gemeld en niet stilzwijgend overschreven zolang de oorzaak onbekend is; daarna herstelt de pijplijn de bedoelde toestand. Netwerkbeheer krijgt wekelijks een overzicht.

Zonder fabriccontroller rendert de Ansible-collectie cisco.nxos de configuratie uit dezelfde bron, en past het uitvoeringsknooppunt van de automatisering in VLAN 600 haar per switch toe, in dezelfde volgorde. De doorlopende vergelijking van bedoelde en werkelijke configuratie moet dan apart worden ingericht.

Iedere oplevering en wijziging van de fabric wordt met dezelfde testset getoetst; de resultaten zijn het bewijs.

De testset gebruikt Ansible en de opdrachtregel van de leverancier. Zij wordt bij oplevering volledig uitgevoerd, na iedere wijziging voor het geraakte deel en ieder half jaar opnieuw; het verslag hoort bij het bewijs van de oplevering en van iedere fase van de routekaart. Batfish en pyATS worden alleen ingezet als zij in de leeromgeving aantoonbaar waarde toevoegen.

De fabric van een cel is gereed als zij de volledige testset doorstaat, de zonematrix in de opslagplaats Beleid overeenkomt met de werkelijke regels en de routetabellen per routeringsdomein met de bedoelde toestand, een ongeldig voorstel wordt geweigerd, een handmatige wijziging binnen een dag wordt gemeld, en een applicatiecluster zijn segment via het leverpad krijgt en weer kwijtraakt.

Alle switches sturen streaming telemetry (gRPC dial-out) naar de eigen bewakingsvoorziening zodra die in bedrijf is: poorten, wachtrijen, BGP- en EVPN-toestand en VTEP-tellers; tot dan leveren de eigen bewaking van de fabric en de bestaande apparatuurbewaking die gegevens. SNMP loopt via de snmp_exporter. Syslog gaat naar de SIEM en sFlow van de leaves als steekproef naar de netwerkweergave van het SOC. Meldingen volgen bij een verbinding of buur die wegvalt, BFD-uitval, een inconsistent Ethernet-segment, MTU-fouten, wachtrijverlies boven 0,1 procent en bandbreedte boven 60 procent op een bundel of uplink.

Switches worden alleen beheerd via SSH en de NX-API, vanuit VLAN 600: vanaf de beheerwerkplek en vanaf het uitvoeringsknooppunt van de automatisering, dat de nacontrole, de testset en de uitrol zonder controller uitvoert. De centrale aanmelding loopt via de AAA-voorziening van netwerkbeheer tegen de directory, met een tweede factor via de beheerwerkplek; de lokale beheerder bestaat alleen als noodaccount in de kluis. Iedere opdracht gaat via het auditlogboek naar de SIEM.

Het besturingsvlak is beschermd: authenticatie op BGP met TCP-AO en op OSPF met HMAC-SHA, volgens de cryptografietabel van RWS; BFD; control-plane policing volgens het strikte profiel; alleen de vastgelegde buren; prefixfilters en een maximum aantal prefixen op iedere externe sessie; ongebruikte diensten en poorten uitgeschakeld. De NX-OS-beelden zijn ondertekend en starten beveiligd, en de basislijn van software en configuratie staat in versiebeheer. De beheer-leaf en de fabriccontroller staan alleen in het beheerdomein.

Servermanagementinterfaces (iLO) staan op een eigen poort in het apparatuurbeheernetwerk (VLAN 600), zonder standaardaccounts. Alleen bronnen die de zonematrix toestaat, zoals de beheerwerkplek en het firmwarebeheer, bereiken ze; van buiten dat netwerk alleen de bewaking met SNMP versie 3 en Redfish, tot groeipadstap 2 de bestaande apparatuurbewaking en daarna de eigen bewakingsvoorziening. IPMI via LAN staat uit, alleen HTTPS met TLS 1.2 of hoger is open, de aanmelding loopt via de directory met persoonlijke accounts waar mogelijk, ongebruikte diensten zijn uitgeschakeld en de lokale beheerder ligt in de kluis.