Cosa facciamo · Rete: Fabric del datacenter: EVPN/VXLAN su Cisco Nexus
Dentro il Digital Realty Athens, ogni server, chassis blade, host di storage e firewall cliente che gestiamo si collega a un fabric leaf e spine Cisco Nexus 9000 con BGP EVPN e VXLAN. Ogni host è dual-homed, qualsiasi VLAN può vivere su qualsiasi leaf, e il vostro gateway ha lo stesso indirizzo ovunque, così i carichi di lavoro si spostano e fanno failover senza cambiare indirizzi.
Cos'è
Un fabric Clos: spine in alto, coppie di leaf sotto, border leaf che consegnano il traffico instradato ai nostri router di edge. EVPN è il piano di controllo, quindi gli switch imparano dove vive ogni indirizzo tramite BGP invece di inondare la rete per scoprirlo. VXLAN trasporta ogni segmento di Layer 2 attraverso il fabric, il che significa che la vostra rete non è legata al rack in cui si trova per caso il vostro server.
Come lo costruiamo
- Spine come puri route reflector. Nessun endpoint di tunnel vive sugli spine, per progettazione.
- Leaf in coppie vPC. I server si collegano con port-channel LACP che sono veri virtual port-channel attraverso entrambi gli switch di una coppia.
- Cablaggio deterministico dei blade. Gli enclosure blade HPE c7000 si collegano tramite fabric extender Cisco Nexus 2000, uno per lato del fabric.
- Gateway anycast. Su ogni leaf.
- Nessuna dipendenza dal multicast. Il traffico broadcast e sconosciuto è replicato tramite ingress replication BGP, il che mantiene l'underlay semplice e prevedibile.
- Una regola di numerazione applicata dalla macchina. L'identificatore VXLAN di ogni segmento deriva dalla sua VLAN locale secondo una regola fissa, con route target espliciti. Un controllo automatico legge la mappa completa da ogni leaf ogni ora, conferma che i leaf siano identici e rispettino la regola, e confronta un'impronta crittografica dell'intera mappa con una baseline firmata nel version control. La deriva avvisa un ingegnere. Una modifica voluta deve essere firmata di nuovo, così ogni cambiamento del fabric porta con sé un autore e una traccia di audit.
- Routing nativo per le piattaforme container. I cluster Kubernetes e OpenShift annunciano gli indirizzi pubblici dei loro servizi nel fabric via eBGP da ogni nodo verso entrambi i leaf della sua coppia, con BFD per rilevare i guasti in meno di due secondi e prefix list ristrette alle sole host route esatte.
- Bond che usano entrambi i link. Ogni server in bond che costruiamo fa hashing su layer 3 e layer 4, con il lato switch impostato in modo corrispondente, così i flussi paralleli si distribuiscono davvero su entrambi i membri.
Da cosa vi protegge
- Da un guasto di un singolo switch, link, fabric extender o NIC che mette offline il vostro host.
- Da un identificatore VLAN o VXLAN digitato male che collega silenziosamente le reti di due tenant.
- Da un failover lento, in cui un indirizzo pubblico impiega minuti a spostarsi invece di secondi.
- Da un'aggiunta di VLAN di routine che toglie le VLAN esistenti da un trunk attivo.
- Dal pagare due link e usarne uno.
In pratica
Failover provato con un test. In un test di guasto controllato abbiamo riavviato un nodo di un cluster container mentre era il percorso preferito per un indirizzo pubblico attivo. Il fabric è converso su un nodo sano circa tre secondi dopo, e l'indirizzo pubblico non ha mai lasciato la tabella di routing del fabric.
Un rack blade cablato prima dell'arrivo dei blade. In vista del lancio di nuove piattaforme cliente, abbiamo costruito la topologia completa di port-channel e vPC per un intero rack blade in un unico lotto, prima che la maggior parte dei blade esistesse fisicamente. Ogni cluster di database è stato collocato con ogni replica in uno chassis diverso, così nessun singolo chassis può rompere il quorum. Il giorno del lancio è stata un'accensione, non un lavoro di cablaggio.
Entrambi i link di ogni bond in uso. Dopo ogni build in bond leggiamo i contatori per porta per dimostrare che entrambi i link trasportano traffico.
Perché EuroVPS
- Un vero fabric EVPN/VXLAN su Cisco Nexus 9000, la stessa architettura che usano le grandi aziende e i carrier.
- Dual-homing per ogni host, non solo per quelli costosi.
- Isolamento dei tenant verificato dalla macchina ogni ora, rispetto a un registro firmato di come il fabric deve essere.
- Ingress dei container instradato nativamente con BFD, non aggiunto a posteriori tramite un singolo load balancer.
Domande frequenti
Il mio traffico è isolato da quello degli altri clienti? Sì. I vostri segmenti hanno identificatori e route target propri, e il controllo di integrità orario esiste proprio per rendere impossibile non accorgersi di un ponte accidentale tra tenant.
Cosa succede se uno switch si guasta? Il vostro server è in bond su entrambi gli switch di una coppia e il vostro gateway esiste su ogni leaf. Il traffico continua sullo switch superstite.
Posso avere VLAN e subnet mie? Sì. Segmenti dedicati e subnet pubbliche sono costruiti come gateway anycast attraverso il fabric, senza toccare la configurazione di nessun altro.
Il mio cluster Kubernetes può annunciare i propri indirizzi di servizio? Sì. Facciamo peering di ogni nodo con il fabric via eBGP con BFD, così un nodo guasto viene aggirato in pochi secondi.
Se volete i vostri server su un fabric costruito e verificato così, parla con un ingegnere.
Il vostro prossimo partner per l'infrastruttura
Guardiamo la vostra infrastruttura.
Raccontateci cosa fate girare oggi e cosa deve migliorare. Un ingegnere esaminerà la vostra richiesta e vi aiuterà a pianificare il passo successivo.
+357 222 32280
Partiamo dalla vostra infrastruttura.
Un po' di contesto ci aiuta a iniziare la conversazione giusta.