Qué hacemos · Red: Fabric del datacenter: EVPN/VXLAN sobre Cisco Nexus
Dentro de Digital Realty Athens, cada servidor, chasis de blades, host de storage y firewall de cliente que operamos se conecta a un fabric leaf y spine Cisco Nexus 9000 que ejecuta BGP EVPN con VXLAN. Cada host es dual-homed, cualquier VLAN puede vivir en cualquier leaf y su gateway es la misma dirección en todas partes, de modo que las cargas de trabajo se mueven y conmutan sin renumerar.
Qué es
Un fabric Clos: spines arriba, pares de leaves debajo, border leaves que entregan el tráfico enrutado a nuestros routers de borde. EVPN es el plano de control, así que los switches aprenden dónde vive cada dirección a través de BGP en lugar de inundar la red para averiguarlo. VXLAN transporta cada segmento de capa 2 a través del fabric, lo que significa que su red no está atada al rack en el que casualmente está su servidor.
Cómo lo construimos
- Spines como route reflectors puros. Ningún extremo de túnel vive en los spines, por diseño.
- Leaves en pares vPC. Los servidores se conectan con port-channels LACP que son verdaderos port-channels virtuales a través de los dos switches de un par.
- Cableado determinista de los blades. Los chasis de blades HPE c7000 se conectan a través de fabric extenders Cisco Nexus 2000, uno por cada lado del fabric.
- Gateways anycast. En cada leaf.
- Sin dependencia de multicast. El tráfico de difusión y el desconocido se replican mediante ingress replication de BGP, lo que mantiene el underlay simple y predecible.
- Una regla de numeración aplicada por máquina. El identificador VXLAN de cada segmento se deriva de su VLAN local mediante una regla fija, con route targets explícitos. Una comprobación automática lee el mapa completo de cada leaf cada hora, confirma que los leaves son idénticos y obedecen la regla, y compara una huella criptográfica de todo el mapa con una línea base firmada en control de versiones. Una desviación avisa a un ingeniero. Un cambio intencionado tiene que volver a firmarse, así que cada cambio en el fabric lleva un autor y un rastro de auditoría.
- Enrutamiento nativo para plataformas de contenedores. Los clústeres Kubernetes y OpenShift anuncian las direcciones públicas de sus servicios hacia el fabric por eBGP desde cada nodo a los dos leaves de su par, con BFD para detectar fallos en menos de dos segundos y prefix lists ajustadas a host routes exactas.
- Bonds que usan los dos enlaces. Cada servidor con bond que construimos hace hash en capa 3 y capa 4, con el lado del switch configurado igual, de modo que los flujos paralelos se reparten de verdad entre los dos miembros.
De qué le protege
- De que el fallo de un solo switch, enlace, fabric extender o NIC deje su host fuera de línea.
- De que un identificador de VLAN o VXLAN mal escrito una en silencio las redes de dos tenants.
- De un failover lento, en el que una dirección pública tarda minutos en moverse en lugar de segundos.
- De que una adición rutinaria de VLAN retire las VLAN existentes de un trunk en producción.
- De pagar dos enlaces y usar uno.
En la práctica
Failover demostrado con una prueba. En una prueba de fallo controlada reiniciamos un nodo de un clúster de contenedores mientras era la ruta preferida de una dirección pública en producción. El fabric convergió sobre un nodo sano unos tres segundos después, y la dirección pública nunca salió de la tabla de enrutamiento del fabric.
Un rack de blades cableado antes de que llegaran los blades. Antes de lanzar nuevas plataformas de clientes, construimos la topología completa de port-channels y vPC de un rack de blades entero en un solo lote, antes de que la mayoría de los blades existieran físicamente. Cada clúster de bases de datos se colocó con cada réplica en un chasis distinto, de modo que ningún chasis por sí solo puede romper el quórum. El día del lanzamiento fue un encendido, no una jornada de cableado.
Los dos enlaces de cada bond en uso. Después de cada construcción con bond leemos los contadores por puerto para demostrar que los dos enlaces transportan tráfico.
Por qué EuroVPS
- Un fabric EVPN/VXLAN real sobre Cisco Nexus 9000, la misma arquitectura que ejecutan las grandes empresas y los operadores.
- Dual-homing para cada host, no solo para los caros.
- Aislamiento entre tenants comprobado por máquina cada hora, frente a un registro firmado de lo que el fabric debe ser.
- Ingress de contenedores enrutado de forma nativa con BFD, no añadido a través de un único balanceador de carga.
Preguntas frecuentes
¿Mi tráfico está aislado del de otros clientes? Sí. Sus segmentos llevan sus propios identificadores y route targets, y la comprobación de integridad horaria existe precisamente para que un puente accidental entre tenants sea imposible de pasar por alto.
¿Qué ocurre si falla un switch? Su servidor tiene bond a través de los dos switches de un par y su gateway existe en cada leaf. El tráfico continúa por el switch que sigue en pie.
¿Puedo tener mis propias VLAN y subredes? Sí. Los segmentos dedicados y las subredes públicas se construyen como gateways anycast a través del fabric, sin tocar la configuración de nadie más.
¿Puede mi clúster Kubernetes anunciar sus propias direcciones de servicio? Sí. Emparejamos cada nodo con el fabric por eBGP con BFD, de modo que un nodo caído queda fuera de la ruta en segundos.
Si quiere sus servidores en un fabric construido y comprobado así, hable con un ingeniero.
Su próximo socio de infraestructura
Veamos su infraestructura.
Cuéntenos qué ejecuta hoy y qué necesita mejorar. Un ingeniero revisará su solicitud y le ayudará a planificar el siguiente paso.
+357 222 32280
Empecemos por su infraestructura.
Un poco de contexto nos ayuda a empezar la conversación adecuada.