O que fazemos · Rede: Fabric do datacenter: EVPN/VXLAN em Cisco Nexus
Dentro do Digital Realty Athens, cada servidor, chassis de blades, host de storage e firewall de cliente que operamos liga-se a um fabric leaf e spine Cisco Nexus 9000 a executar BGP EVPN com VXLAN. Cada host é dual-homed, qualquer VLAN pode viver em qualquer leaf, e o seu gateway é o mesmo endereço em todo o lado, pelo que as cargas de trabalho se movem e fazem failover sem alteração de endereços.
O que é
Um fabric Clos: spines no topo, pares de leaves por baixo, border leaves a entregar o tráfego encaminhado aos nossos edge routers. O EVPN é o control plane, pelo que os switches aprendem onde vive cada endereço através do BGP em vez de inundarem a rede para o descobrir. O VXLAN transporta cada segmento de Layer 2 através do fabric, o que significa que a sua rede não está presa ao rack onde o seu servidor calha estar.
Como o construímos
- Spines como route reflectors puros. Nenhum tunnel endpoint vive nos spines, por desenho.
- Leaves em pares vPC. Os servidores ligam-se com port-channels LACP que são verdadeiros virtual port-channels nos dois switches de um par.
- Cablagem de blades determinística. Os blade enclosures HPE c7000 ligam-se através de fabric extenders Cisco Nexus 2000, um por lado do fabric.
- Anycast gateways. Em cada leaf.
- Sem dependência de multicast. O tráfego broadcast e desconhecido é replicado por BGP ingress replication, o que mantém o underlay simples e previsível.
- Uma regra de numeração imposta por máquina. O identificador VXLAN de cada segmento deriva da sua VLAN local por uma regra fixa, com route targets explícitos. Uma verificação automática lê o mapa completo de cada leaf a cada hora, confirma que os leaves são idênticos e cumprem a regra, e compara uma impressão digital criptográfica de todo o mapa com um baseline assinado em version control. Qualquer desvio alerta um engenheiro. Uma alteração intencional tem de ser reassinada, pelo que cada alteração ao fabric tem um autor e um rasto de auditoria.
- Encaminhamento nativo para plataformas de containers. Os clusters Kubernetes e OpenShift anunciam os endereços públicos dos seus serviços no fabric por eBGP, de cada nó para os dois leaves do seu par, com BFD para deteção de falhas em menos de dois segundos e prefix lists restringidas a host routes exatas.
- Bonds que usam os dois links. Cada servidor com bond que construímos faz hashing em layer 3 e layer 4, com o lado do switch configurado em conformidade, para que os fluxos paralelos se distribuam realmente pelos dois membros.
Do que o protege
- Uma falha num único switch, link, fabric extender ou NIC que deixe o seu host offline.
- Um identificador de VLAN ou VXLAN mal escrito que ligue silenciosamente as redes de dois tenants.
- Failover lento, em que um endereço público demora minutos a mover-se em vez de segundos.
- Uma adição de rotina de uma VLAN que retire VLAN existentes de um trunk em produção.
- Pagar dois links e usar um.
Na prática
Failover comprovado por teste. Num teste de falha controlado, reiniciámos um nó de um container cluster enquanto este era o caminho preferido para um endereço público em produção. O fabric convergiu para um nó saudável cerca de três segundos depois, e o endereço público nunca saiu da tabela de encaminhamento do fabric.
Um rack de blades cablado antes de os blades chegarem. Antes do lançamento de novas plataformas de clientes, construímos a topologia completa de port-channels e vPC de um rack de blades inteiro num único lote, antes de a maioria dos blades existir fisicamente. Cada cluster de base de dados foi colocado com cada réplica num chassis diferente, para que nenhum chassis isolado possa quebrar o quórum. O dia do lançamento foi um power-on, não um trabalho de cablagem.
Os dois links de cada bond em uso. Depois de cada build com bond, lemos os contadores por porta para provar que os dois links transportam tráfego.
Porquê a EuroVPS
- Um verdadeiro fabric EVPN/VXLAN em Cisco Nexus 9000, a mesma arquitetura que as grandes empresas e os carriers executam.
- Dual-homing para cada host, não só para os caros.
- Isolamento de tenants verificado por máquina a cada hora, contra um registo assinado do que o fabric deve ser.
- Ingress de containers encaminhado nativamente com BFD, não acrescentado através de um único load balancer.
Perguntas frequentes
O meu tráfego está isolado dos outros clientes? Sim. Os seus segmentos têm os seus próprios identificadores e route targets, e a verificação de integridade horária existe precisamente para que uma ponte acidental entre tenants seja impossível de passar despercebida.
O que acontece se um switch falhar? O seu servidor está em bond nos dois switches de um par e o seu gateway existe em cada leaf. O tráfego continua pelo switch sobrevivente.
Posso ter as minhas próprias VLAN e subnets? Sim. Segmentos dedicados e subnets públicas são construídos como anycast gateways em todo o fabric, sem tocar na configuração de mais ninguém.
O meu cluster Kubernetes pode anunciar os seus próprios endereços de serviço? Sim. Fazemos peering de cada nó com o fabric por eBGP com BFD, para que um nó em falha seja contornado em segundos.
Se quer os seus servidores num fabric construído e verificado desta forma, fale com um engenheiro.
O seu próximo parceiro de infraestrutura
Vamos analisar a sua infraestrutura.
Diga-nos o que executa hoje e o que precisa de melhorar. Um engenheiro vai analisar o seu pedido e ajudar a planear o passo seguinte.
+357 222 32280
Comecemos pela sua infraestrutura.
Um pouco de contexto ajuda-nos a começar a conversa certa.