В edição anterior Descrevi a estrutura de automação de rede. Segundo algumas pessoas, mesmo esta primeira abordagem do problema já resolveu algumas questões. E isso me deixa muito feliz, pois nosso objetivo no ciclo não é encobrir o Ansible com scripts Python, mas sim construir um sistema.

O mesmo quadro estabelece a ordem em que trataremos da questão.
E a virtualização de redes, à qual esta edição é dedicada, não se enquadra particularmente no tópico ADSM, onde analisamos a automação.

Mas vamos olhar para isso de um ângulo diferente.

Muitos serviços usam a mesma rede há muito tempo. No caso de uma operadora de telecomunicações, são 2G, 3G, LTE, banda larga e B2B, por exemplo. No caso de um DC: conectividade para diferentes clientes, Internet, armazenamento em blocos, armazenamento de objetos.

E todos os serviços exigem isolamento uns dos outros. Foi assim que surgiram as redes sobrepostas.

E todos os serviços não querem esperar que alguém os configure manualmente. Foi assim que surgiram os orquestradores e o SDN.

A primeira abordagem para a automação sistemática da rede, ou melhor, de parte dela, já foi adotada e implementada em muitos lugares: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

É disso que trataremos hoje.

Conteúdo

• razões
• Vocabulário
• Underlay - rede física
• Sobreposição – rede virtual
  • Sobreposição com ToR
  • Sobreposição do host
  • Usando tecido de tungstênio como exemplo
    • Comunicação dentro de uma única máquina física
    • Comunicação entre VMs localizadas em máquinas físicas diferentes
    • Saída para o mundo exterior

• Perguntas frequentes
• Conclusão
• Links úteis

razões

E já que estamos falando sobre isso, vale mencionar os pré-requisitos para virtualização de redes. Na verdade, este processo não começou ontem.

Você provavelmente já ouviu mais de uma vez que a rede sempre foi a parte mais inerte de qualquer sistema. E isso é verdade em todos os sentidos. A rede é a base sobre a qual tudo se baseia, e fazer alterações nela é bastante difícil - os serviços não toleram isso quando a rede está inoperante. Muitas vezes, o descomissionamento de um único nó pode derrubar uma grande parte dos aplicativos e impactar muitos clientes. Em parte, é por isso que a equipe da rede pode resistir a qualquer mudança - porque agora ela funciona de alguma forma (podemos nem saber como), mas aqui você precisa configurar algo novo e não se sabe como isso afetará a rede.

Para não esperar que os networkers insiram VLANs e não registrem nenhum serviço em cada nó da rede, surgiu a ideia de usar overlays - redes de sobreposição - das quais existem uma grande variedade: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, etc.

Seu apelo reside em duas coisas simples:

• Apenas os nós finais são configurados – os nós de trânsito não precisam ser tocados. Isso acelera significativamente o processo e, às vezes, permite excluir completamente o departamento de infraestrutura de rede do processo de introdução de novos serviços.
• A carga está escondida nas profundezas dos cabeçalhos - os nós de trânsito não precisam saber nada sobre ela, sobre o endereçamento nos hosts ou sobre as rotas da rede sobreposta. Isso significa que você precisa armazenar menos informações em tabelas, o que significa usar um dispositivo mais simples/barato.

Nesta edição não totalmente completa, não pretendo analisar todas as tecnologias possíveis, mas sim descrever a estrutura para a operação de redes sobrepostas em DCs.

Toda a série descreverá um data center que consiste em fileiras de racks idênticos nos quais o mesmo equipamento de servidor está instalado.

Este equipamento executa máquinas virtuais/contêineres/serverless que implementam serviços.

Vocabulário

No ciclo servidor Vou citar um programa que implementa o lado servidor da comunicação cliente-servidor.

As máquinas físicas em racks são chamadas de servidores não vamos.

Máquina física — computador x86 instalado em rack. O termo mais usado anfitrião. É assim que vamos chamá-lo "máquina" ou anfitrião.

Hipervisor — um aplicativo executado em uma máquina física que emula os recursos físicos nos quais as máquinas virtuais são executadas. Às vezes, na literatura e na Internet, a palavra “hipervisor” é usada como sinônimo de “host”.

Máquina virtual - um sistema operacional executado em uma máquina física sobre um hipervisor. Para nós neste ciclo, realmente não importa se é realmente uma máquina virtual ou apenas um contêiner. Vamos chamá-lo de "VM«

Inquilino é um conceito amplo que definirei neste artigo como um serviço separado ou um cliente separado.

Múltiplos inquilinos ou multitenancy - o uso do mesmo aplicativo por diferentes clientes/serviços. Ao mesmo tempo, o isolamento dos clientes entre si é alcançado graças à arquitetura do aplicativo, e não por meio de instâncias executadas separadamente.

ToR — Switch na parte superior do rack - um switch instalado em um rack ao qual todas as máquinas físicas estão conectadas.

Além da topologia ToR, vários provedores praticam End of Row (EoR) ou Middle of Row (embora o último seja uma raridade depreciativa e eu não tenha visto a abreviatura MoR).

Rede subjacente ou a rede subjacente ou subjacência é a infra-estrutura física da rede: switches, roteadores, cabos.

Rede de sobreposição ou rede de sobreposição ou sobreposição - uma rede virtual de túneis executada sobre uma rede física.

Tecido L3 ou tecido IP - uma incrível invenção da humanidade que permite evitar repetir STP e aprender TRILL para entrevistas. Um conceito em que toda a rede até ao nível de acesso é exclusivamente L3, sem VLANs e, consequentemente, enormes domínios de transmissão alargados. Veremos de onde vem a palavra “fábrica” na próxima parte.

SDN - Rede definida por software. Quase não precisa de uma introdução. Uma abordagem ao gerenciamento de rede onde as alterações na rede não são feitas por uma pessoa, mas por um programa. Geralmente significa mover o plano de controle além dos dispositivos finais da rede para o controlador.

NFV — Virtualização de funções de rede — virtualização de dispositivos de rede, sugerindo que algumas funções de rede podem ser executadas na forma de máquinas virtuais ou contêineres para acelerar a implementação de novos serviços, organizar o encadeamento de serviços e escalabilidade horizontal mais simples.

VNF - Função de rede virtual. Dispositivo virtual específico: roteador, switch, firewall, NAT, IPS/IDS, etc.

Agora estou simplificando deliberadamente a descrição para uma implementação específica, para não confundir muito o leitor. Para uma leitura mais cuidadosa, remeto-o para a seção referências. Além disso, Roma Gorge, que critica este artigo pelas imprecisões, promete escrever uma edição separada sobre tecnologias de virtualização de servidores e redes, mais aprofundada e atenta aos detalhes.

A maioria das redes hoje pode ser claramente dividida em duas partes:

Underlay — uma rede física com configuração estável.
Sobreposição — abstração sobre Underlay para isolar inquilinos.

Isto é verdade tanto para o caso do DC (que analisaremos neste artigo) quanto para o ISP (que não analisaremos, porque já foi SDSM). Com redes empresariais, é claro, a situação é um pouco diferente.

Foto com foco na rede:

Underlay

Underlay é uma rede física: switches e cabos de hardware. Dispositivos subterrâneos sabem como alcançar máquinas físicas.

Baseia-se em protocolos e tecnologias padrão. Até porque os dispositivos de hardware até hoje operam em software proprietário que não permite nem programar o chip nem implementar seus próprios protocolos; portanto, é necessária compatibilidade com outros fornecedores e padronização.

Mas alguém como o Google pode se dar ao luxo de desenvolver seus próprios switches e abandonar os protocolos geralmente aceitos. Mas LAN_DC não é o Google.

O underlay muda relativamente raramente porque seu objetivo é a conectividade IP básica entre máquinas físicas. O Underlay não sabe nada sobre os serviços, clientes ou locatários executados nele - ele só precisa entregar o pacote de uma máquina para outra.
O underlay poderia ser assim:

• IPv4+OSPF
• IPv6+ISIS+BGP+L3VPN
• L2+TRILO
• L2+STP

A rede Underlay é configurada da forma clássica: CLI/GUI/NETCONF.

Manualmente, scripts, utilitários proprietários.

O próximo artigo da série será dedicado ao underlay com mais detalhes.

Sobreposição

Overlay é uma rede virtual de túneis estendidos sobre Underlay, que permite que VMs de um cliente se comuniquem entre si, ao mesmo tempo que fornece isolamento de outros clientes.

Os dados do cliente são encapsulados em alguns cabeçalhos de tunelamento para transmissão pela rede pública.

Assim, as VMs de um cliente (um serviço) podem se comunicar entre si por meio do Overlay, mesmo sem saber qual caminho o pacote realmente percorre.

A sobreposição poderia ser, por exemplo, como mencionei acima:

• Túnel GRE
• VXLAN
• EVPN
• L3VPN
• GENEVE

Uma rede sobreposta normalmente é configurada e mantida por meio de um controlador central. A partir dele, a configuração, Plano de Controle e Plano de Dados são entregues aos dispositivos que roteiam e encapsulam o tráfego do cliente. Um pouco abaixo Vejamos isso com exemplos.

Sim, este é o SDN em sua forma mais pura.

Existem duas abordagens fundamentalmente diferentes para organizar uma rede Overlay:

1. Sobreposição com ToR
2. Sobreposição do host

Sobreposição com ToR

A sobreposição pode começar no switch de acesso (ToR) localizado no rack, como acontece, por exemplo, no caso de uma malha VXLAN.

Este é um mecanismo testado pelo tempo em redes ISP e todos os fornecedores de equipamentos de rede o suportam.

Porém, neste caso, o switch ToR deve ser capaz de separar os vários serviços, respectivamente, e o administrador da rede deve, até certo ponto, cooperar com os administradores da máquina virtual e fazer alterações (ainda que automaticamente) na configuração dos dispositivos. .

Aqui vou encaminhar o leitor para um artigo sobre VxLAN em Habré nosso velho amigo @bormoglotx.
Neste apresentações com ENOG abordagens para construir uma rede DC com uma malha EVPN VXLAN são descritas em detalhes.

E para uma imersão mais completa na realidade, você pode ler o livro de Tsiska Uma estrutura moderna, aberta e escalável: VXLAN EVPN.

Observo que VXLAN é apenas um método de encapsulamento e o encerramento de túneis pode ocorrer não no ToR, mas no host, como acontece no caso do OpenStack, por exemplo.

No entanto, a malha VXLAN, onde a sobreposição começa no ToR, é um dos designs de rede de sobreposição estabelecidos.

Sobreposição do host

Outra abordagem é iniciar e encerrar túneis nos hosts finais.
Neste caso, a rede (Underlay) permanece o mais simples e estática possível.
E o próprio host faz todo o encapsulamento necessário.

É claro que isso exigirá a execução de um aplicativo especial nos hosts, mas vale a pena.

Em primeiro lugar, executar um cliente em uma máquina Linux é mais fácil ou, digamos, até possível, enquanto em um switch você provavelmente terá que recorrer a soluções SDN proprietárias, o que mata a ideia de multifornecedor.

Em segundo lugar, a mudança ToR neste caso pode ser deixada o mais simples possível, tanto do ponto de vista do Plano de Controle quanto do Plano de Dados. Na verdade, então ele não precisa se comunicar com o controlador SDN, e também não precisa armazenar as redes/ARPs de todos os clientes conectados - basta saber o endereço IP da máquina física, o que simplifica muito a comutação/ tabelas de roteamento.

Na série ADSM, escolho a abordagem de sobreposição do host - então apenas conversaremos sobre isso e não retornaremos à fábrica VXLAN.

É mais fácil ver exemplos. E como cobaia usaremos a plataforma OpenSource SDN OpenContrail, agora conhecida como Tecido de tungstênio.

No final do artigo darei algumas reflexões sobre a analogia com OpenFlow e OpenvSwitch.

Usando tecido de tungstênio como exemplo

Cada máquina física possui vRouter - um roteador virtual que conhece as redes conectadas a ele e a quais clientes elas pertencem - essencialmente um roteador PE. Para cada cliente mantém uma tabela de roteamento isolada (leia VRF). E o vRouter realmente faz tunelamento de sobreposição.

Um pouco mais sobre o vRouter está no final do artigo.

Cada VM localizada no hipervisor está conectada ao vRouter desta máquina via Interface TAP.

TAP - Terminal Access Point - uma interface virtual no kernel Linux que permite a interação em rede.

Se houver várias redes atrás do vRouter, será criada uma interface virtual para cada uma delas, à qual será atribuído um endereço IP - este será o endereço do gateway padrão.
Todas as redes de um cliente são colocadas em um VRF (uma mesa), diferentes - em diferentes.
Farei aqui um aviso de que nem tudo é tão simples e encaminharei o leitor curioso para o final do artigo.

Para que os vRouters se comuniquem entre si e, consequentemente, com as VMs localizadas atrás deles, eles trocam informações de roteamento via Controlador SDN.

Para sair para o mundo exterior, existe um ponto de saída da matriz - um gateway de rede virtual VNGW — Gateway de rede virtual (meu mandato).

Agora vejamos exemplos de comunicações - e haverá clareza.

Comunicação dentro de uma única máquina física

VM0 deseja enviar um pacote para VM2. Vamos supor por enquanto que esta é uma VM de cliente único.

Plano de Dados

1. VM-0 possui uma rota padrão para sua interface eth0. O pacote é enviado para lá.
   Esta interface eth0 está realmente conectada virtualmente ao roteador virtual vRouter através da interface TAP tap0.
2. O vRouter analisa em qual interface o pacote veio, ou seja, a qual cliente (VRF) ele pertence, e verifica o endereço do destinatário com a tabela de roteamento deste cliente.
3. Tendo detectado que o destinatário na mesma máquina está em uma porta diferente, o vRouter simplesmente envia o pacote para ele sem nenhum cabeçalho adicional - neste caso, o vRouter já possui uma entrada ARP.

Nesse caso, o pacote não entra na rede física – ele é roteado dentro do vRouter.

Avião de Controle

Quando a máquina virtual é iniciada, o hipervisor informa:

• Seu próprio endereço IP.
• A rota padrão é através do endereço IP do vRouter nesta rede.

O hipervisor se reporta ao vRouter por meio de uma API especial:

• O que você precisa para criar uma interface virtual.
• Que tipo de rede virtual ela (VM) precisa criar?
• A qual VRF (VN) vinculá-lo.
• Uma entrada ARP estática para esta VM - qual interface está por trás de seu endereço IP e a qual endereço MAC ela está associada.

Novamente, o procedimento de interação real é simplificado para fins de compreensão do conceito.

Assim, o vRouter vê todas as VMs de um cliente em uma determinada máquina como redes diretamente conectadas e pode rotear entre elas por conta própria.

Mas VM0 e VM1 pertencem a clientes diferentes e, portanto, estão em tabelas vRouter diferentes.

Se eles podem se comunicar diretamente entre si depende das configurações do vRouter e do design da rede.
Por exemplo, se as VMs de ambos os clientes usarem endereços públicos ou se o NAT ocorrer no próprio vRouter, o roteamento direto para o vRouter poderá ser feito.

Na situação oposta, é possível cruzar espaços de endereçamento - é necessário passar por um servidor NAT para obter um endereço público - isso é semelhante ao acesso a redes externas, discutidas a seguir.

Comunicação entre VMs localizadas em máquinas físicas diferentes

Plano de Dados

1. O início é exatamente o mesmo: VM-0 envia um pacote com destino VM-7 (172.17.3.2) como padrão.
2. O vRouter recebe e desta vez vê que o destino está em uma máquina diferente e é acessível através do Tunnel0.
3. Primeiro, ele pendura um rótulo MPLS identificando a interface remota, para que no verso o vRouter possa determinar onde colocar esse pacote sem pesquisas adicionais.

   

4. Tunnel0 tem origem 10.0.0.2, destino: 10.0.1.2.
   O vRouter adiciona cabeçalhos GRE (ou UDP) e um novo IP ao pacote original.
5. A tabela de roteamento do vRouter possui uma rota padrão através do endereço ToR1 10.0.0.1. É para onde ele envia.

   
   

6. ToR1, como membro da rede Underlay, sabe (por exemplo, via OSPF) como chegar a 10.0.1.2 e envia o pacote ao longo da rota. Observe que o ECMP está habilitado aqui. Existem dois próximos saltos na ilustração e diferentes threads serão classificados neles por hash. No caso de uma fábrica real, haverá mais provavelmente 4 próximos saltos.

   Ao mesmo tempo, ele não precisa saber o que está sob o cabeçalho IP externo. Isto é, de fato, sob IP pode haver um sanduíche de IPv6 sobre MPLS sobre Ethernet sobre MPLS sobre GRE sobre grego.

7. Assim, do lado receptor, o vRouter remove o GRE e, por meio da tag MPLS, entende para qual interface esse pacote deve ser enviado, retira-o e envia-o em sua forma original ao destinatário.

Avião de Controle

Quando você liga o carro, acontece a mesma coisa descrita acima.

E mais o seguinte:

• Para cada cliente, o vRouter aloca uma tag MPLS. Este é o rótulo de serviço L3VPN, pelo qual os clientes serão separados dentro da mesma máquina física.
  

  Na verdade, a tag MPLS é sempre alocada incondicionalmente pelo vRouter – afinal, não se sabe de antemão que a máquina só irá interagir com outras máquinas atrás do mesmo vRouter e muito provavelmente isso nem é verdade.

• O vRouter estabelece uma conexão com o controlador SDN usando o protocolo BGP (ou similar - no caso do TF, é XMPP 0_o).
• Através desta sessão, o vRouter reporta rotas para redes conectadas ao controlador SDN:
  • Endereço de rede
  • Método de encapsulamento (MPLSoGRE, MPLSoUDP, VXLAN)
  • Marca de cliente MPLS
  • Seu endereço IP como nexthop

• O controlador SDN recebe essas rotas de todos os vRouters conectados e as reflete para outros. Ou seja, atua como um Refletor de Rota.

A mesma coisa acontece na direção oposta.

A sobreposição pode mudar pelo menos a cada minuto. Isso é aproximadamente o que acontece nas nuvens públicas, onde os clientes iniciam e desligam regularmente suas máquinas virtuais.

O controlador central cuida de toda a complexidade de manutenção da configuração e monitoramento das tabelas de comutação/roteamento no vRouter.

Grosso modo, o controlador se comunica com todos os vRouters via BGP (ou protocolo semelhante) e simplesmente transmite informações de roteamento. O BGP, por exemplo, já possui Address-Family para transmitir o método de encapsulamento MPLS-em-GRE ou MPLS-em-UDP.

Ao mesmo tempo, a configuração da rede Underlay não muda em nada, o que, aliás, é muito mais difícil de automatizar e mais fácil de quebrar com um movimento desajeitado.

Saída para o mundo exterior

Em algum lugar a simulação deve terminar e você precisa sair do mundo virtual para o real. E você precisa de um gateway de telefone público.

Duas abordagens são praticadas:

1. Um roteador de hardware está instalado.
2. É lançado um dispositivo que implementa as funções de um roteador (sim, seguindo o SDN, também encontramos o VNF). Vamos chamá-lo de gateway virtual.

A vantagem da segunda abordagem é a escalabilidade horizontal barata - não há energia suficiente - lançamos outra máquina virtual com gateway. Em qualquer máquina física, sem ter que procurar racks, unidades, potências livres, comprar o próprio hardware, transportá-lo, instalá-lo, trocá-lo, configurá-lo e depois também trocar componentes defeituosos nele.

As desvantagens de um gateway virtual são que uma unidade de roteador físico ainda é muito mais poderosa do que uma máquina virtual multi-core, e seu software, adaptado à sua própria base de hardware, funciona muito mais estável (não). Também é difícil negar o fato de que o complexo de hardware e software simplesmente funciona, exigindo apenas configuração, enquanto lançar e manter um gateway virtual é uma tarefa para engenheiros experientes.

Com um pé, o gateway olha para a rede virtual Overlay, como uma máquina virtual normal, e pode interagir com todas as outras VMs. Ao mesmo tempo, pode encerrar as redes de todos os clientes e, consequentemente, realizar o roteamento entre eles.

Com o outro pé, o gateway olha para a rede backbone e sabe como entrar na Internet.

Plano de Dados

Ou seja, o processo fica assim:

1. VM-0, tendo como padrão o mesmo vRouter, envia um pacote com destino no mundo externo (185.147.83.177) para a interface eth0.
2. O vRouter recebe este pacote e procura o endereço de destino na tabela de roteamento - encontra a rota padrão através do gateway VNGW1 através do Túnel 1.
   Ele também vê que este é um túnel GRE com SIP 10.0.0.2 e DIP 10.0.255.2, e também precisa primeiro anexar o rótulo MPLS deste cliente, que o VNGW1 espera.
3. O vRouter empacota o pacote inicial com MPLS, GRE e novos cabeçalhos IP e o envia para o endereço ToR1 10.0.0.1 por padrão.
4. A rede subjacente entrega o pacote ao gateway VNGW1.
5. O gateway VNGW1 remove os cabeçalhos de tunelamento GRE e MPLS, vê o endereço de destino, consulta sua tabela de roteamento e entende que está direcionado para a Internet – ou seja, através de Full View ou Default. Se necessário, realiza a tradução NAT.
6. Poderia haver uma rede IP regular de VNGW até a fronteira, o que é improvável.
   Pode haver uma rede MPLS clássica (IGP+LDP/RSVP TE), pode haver uma malha traseira com BGP LU ou um túnel GRE de VNGW até a fronteira através de uma rede IP.
   Seja como for, o VNGW1 realiza os encapsulamentos necessários e envia o pacote inicial até a fronteira.

O tráfego no sentido oposto segue as mesmas etapas na ordem oposta.

1. A fronteira descarta o pacote para VNGW1
2. Ele o despe, olha o endereço do destinatário e vê que ele está acessível através do túnel Tunnel1 (MPLSoGRE ou MPLSoUDP).
3. Assim, ele anexa um rótulo MPLS, um cabeçalho GRE/UDP e um novo IP e os envia para seu ToR3 10.0.255.1.
   O endereço de destino do túnel é o endereço IP do vRouter atrás do qual a VM de destino está localizada – 10.0.0.2.
4. A rede subjacente entrega o pacote ao vRouter desejado.
5. O vRouter de destino lê GRE/UDP, identifica a interface usando o rótulo MPLS e envia um pacote IP simples para sua interface TAP associada à eth0 da VM.

Avião de Controle

O VNGW1 estabelece uma vizinhança BGP com um controlador SDN, do qual recebe todas as informações de roteamento dos clientes: qual endereço IP (vRouter) está por trás de qual cliente e por qual rótulo MPLS ele é identificado.

Da mesma forma, ele próprio informa ao controlador SDN a rota padrão com o rótulo deste cliente, indicando-se como o próximo salto. E então esse padrão chega aos vRouters.

No VNGW, geralmente ocorre agregação de rotas ou tradução NAT.

E na outra direção envia exatamente essa rota agregada para a sessão com bordas ou Refletores de Rota. E deles recebe a rota padrão ou Full-View, ou outra coisa.

Em termos de encapsulamento e troca de tráfego, o VNGW não é diferente do vRouter.
Se você expandir um pouco o escopo, poderá adicionar outros dispositivos de rede aos VNGWs e vRouters, como firewalls, limpeza de tráfego ou farms de enriquecimento, IPS e assim por diante.

E com a ajuda da criação sequencial de VRFs e do anúncio correto das rotas, você pode forçar o tráfego a circular da maneira que desejar, o que é chamado de Service Chaining.

Ou seja, também aqui o controlador SDN atua como um Route-Reflector entre VNGWs, vRouters e outros dispositivos de rede.

Mas, na verdade, o controlador também libera informações sobre ACL e PBR (Policy Based Routing), fazendo com que os fluxos de tráfego individuais sigam de maneira diferente do que a rota indica.

Perguntas frequentes

Por que você continua fazendo a observação GRE/UDP?

Bem, em geral, pode-se dizer que isso é específico do tecido de tungstênio - você não precisa levar isso em consideração.

Mas se considerarmos isso, o próprio TF, embora ainda OpenContrail, suportava ambos os encapsulamentos: MPLS em GRE e MPLS em UDP.

O UDP é bom porque na Porta Fonte é muito fácil codificar uma função hash do IP+Proto+Port original em seu cabeçalho, o que permitirá fazer o balanceamento.

No caso do GRE, infelizmente, existem apenas cabeçalhos IP e GRE externos, que são iguais para todo o tráfego encapsulado e não se fala em balanceamento - poucas pessoas conseguem olhar tão profundamente no pacote.

Até algum tempo, os roteadores, se soubessem usar túneis dinâmicos, o faziam apenas em MPLSoGRE, e só muito recentemente aprenderam a usar MPLSoUDP. Portanto, sempre temos que observar a possibilidade de dois encapsulamentos diferentes.

Para ser justo, é importante notar que o TF oferece suporte total à conectividade L2 usando VXLAN.

Você prometeu traçar paralelos com o OpenFlow.
Eles realmente estão pedindo isso. O vSwitch no mesmo OpenStack faz coisas muito semelhantes, usando VXLAN, que, aliás, também possui um cabeçalho UDP.

No Plano de Dados eles funcionam aproximadamente da mesma forma; o Plano de Controle difere significativamente. O Tungsten Fabric usa XMPP para fornecer informações de roteamento ao vRouter, enquanto o OpenStack executa o Openflow.

Você pode me contar um pouco mais sobre o vRouter?
Está dividido em duas partes: vRouter Agent e vRouter Forwarder.

O primeiro roda no User Space do SO host e se comunica com o controlador SDN, trocando informações sobre rotas, VRFs e ACLs.

O segundo implementa o Data Plane - geralmente no Kernel Space, mas também pode ser executado em SmartNICs - placas de rede com CPU e um chip de comutação programável separado, que permite remover a carga da CPU da máquina host e tornar a rede mais rápida e mais previsível.

Outro cenário possível é que o vRouter seja um aplicativo DPDK no User Space.

O vRouter Agent envia configurações para o vRouter Forwarder.

O que é uma rede virtual?
Mencionei no início do artigo sobre VRF que cada inquilino está vinculado ao seu próprio VRF. E se isso bastasse para uma compreensão superficial do funcionamento da rede sobreposta, então na próxima iteração é necessário fazer esclarecimentos.

Normalmente, em mecanismos de virtualização, a entidade Rede Virtual (você pode considerar isso um nome próprio) é introduzida separadamente dos clientes/locatários/máquinas virtuais - uma coisa completamente independente. E esta Rede Virtual já pode ser conectada através de interfaces a um locatário, a outro, a dois, ou em qualquer lugar. Assim, por exemplo, o Service Chaining é implementado quando o tráfego precisa passar por determinados nós na sequência necessária, simplesmente criando e conectando Redes Virtuais na sequência correta.

Portanto, como tal, não existe correspondência direta entre a Rede Virtual e o inquilino.

Conclusão

Esta é uma descrição muito superficial da operação de uma rede virtual com sobreposição do host e um controlador SDN. Mas não importa qual plataforma de virtualização você escolha hoje, ela funcionará de maneira semelhante, seja VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric ou Juniper Contrail. Eles diferirão nos tipos de encapsulamentos e cabeçalhos, protocolos para entrega de informações aos dispositivos de rede finais, mas o princípio de uma rede sobreposta configurável por software trabalhando em cima de uma rede subjacente relativamente simples e estática permanecerá o mesmo.
Podemos dizer que hoje o SDN baseado em uma rede sobreposta ganhou o campo da criação de uma nuvem privada. No entanto, isso não significa que o Openflow não tenha lugar no mundo moderno - ele é usado no OpenStacke e no mesmo VMWare NSX, até onde eu sei, o Google o utiliza para configurar a rede subterrânea.

Abaixo forneci links para materiais mais detalhados se você quiser estudar o assunto mais profundamente.

E o nosso Underlay?

Mas em geral, nada. Ele não mudou completamente. Tudo o que ele precisa fazer no caso de uma sobreposição do host é atualizar rotas e ARPs à medida que vRouter/VNGW aparecem e desaparecem e transportam pacotes entre eles.

Vamos formular uma lista de requisitos para a rede Underlay.

1. Ser capaz de usar algum tipo de protocolo de roteamento, na nossa situação - BGP.
2. Ter largura de banda ampla, de preferência sem excesso de assinaturas, para que os pacotes não sejam perdidos por sobrecargas.
3. Apoiar o ECMP é parte integrante da estrutura.
4. Ser capaz de fornecer QoS, incluindo coisas complicadas como ECN.
5. Apoiar o NETCONF é uma base para o futuro.

Dediquei muito pouco tempo aqui ao trabalho da própria rede Underlay. Isso ocorre porque mais adiante na série irei me concentrar nisso e só abordaremos Overlay de passagem.

Obviamente, estou limitando severamente a todos nós usando como exemplo uma rede DC construída em uma fábrica Cloz com roteamento IP puro e uma sobreposição do host.

No entanto, estou confiante de que qualquer rede que tenha um design pode ser descrita em termos formais e automatizada. Só que meu objetivo aqui é entender as abordagens da automação, e não confundir a todos resolvendo o problema de uma forma geral.

Como parte do ADSM, Roman Gorge e eu planejamos publicar uma edição separada sobre a virtualização do poder computacional e sua interação com a virtualização de redes. Manter contato.

Links úteis

• Arquitetura de tecido de tungstênio.
• sobre:nuvem. 6 horas sobre Yandex.Cloud, que também cobre a rede virtual no TF.
• O que é o vSwitch aberto?
• Introdução ao VxLAN.
• RFC 7348. Rede local virtual extensível (VXLAN): uma estrutura para sobreposição de redes virtualizadas de camada 2 em redes de camada 3.
  
• Abordagem Scaleway para VXLAN EVPN Fabric. Ele fala sobre toda a rede DC, incluindo Underlay, Overlay, abordagens para multi-homing e gerenciamento.

Obrigado

• Gorga Romana - ex-apresentador do podcast linkmeup e agora especialista na área de plataformas em nuvem. Para comentários e edições. Bem, estamos aguardando seu artigo mais aprofundado sobre virtualização em um futuro próximo.
• Alexandre Shalimov - meu colega e especialista na área de desenvolvimento de redes virtuais. Para comentários e edições.
• Valentin Sinitsyn - meu colega e especialista na área de Tecido de Tungstênio. Para comentários e edições.
• Artem Chernobay — ilustrador linkmeup. Para KDPV.
• Alexandre Limonov. Para o meme "autômato".

Fonte: habr.com