Geekly articles weekly

Automação para os mais pequenos. Parte um (que é depois de zero). Virtualização de rede

Na versão anterior, descrevi a estrutura de automação de rede. De acordo com análises de algumas pessoas, mesmo essa primeira abordagem do problema já colocou algumas perguntas nas prateleiras. E isso me deixa muito feliz, porque nosso objetivo no ciclo não é cobrir o ansible com scripts Python, mas criar um sistema.

A mesma estrutura define a ordem pela qual lidaremos com a questão.
E a virtualização de rede, à qual esse problema é dedicado, não se encaixa realmente no tema ADSM, onde analisamos a automação.

Mas vamos olhar de um ângulo diferente.

Já há muito tempo, muitos serviços usam uma rede. No caso de uma operadora, são 2G, 3G, LTE, banda larga e B2B, por exemplo. No caso do DC: conectividade para diferentes clientes, a Internet, armazenamento em bloco, armazenamento de objetos.

E todos os serviços exigem isolamento um do outro. Então apareceu redes de sobreposição.

E todos os serviços não querem esperar que uma pessoa os configure manualmente. Então apareceram orquestradores e SDN.

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

Aqui lidamos com ele hoje.



Conteúdo


  • Razões
  • Terminologia
  • Underlay - Rede física
  • Sobreposição - rede virtual

    • Sobreposição com ToR
    • Sobreposição do host
    • Estudo de caso de tecido de tungstênio

      • Comunicação dentro de uma máquina física
      • Comunicação entre VMs localizadas em diferentes máquinas físicas
      • Sair para o mundo exterior


  • Perguntas frequentes
  • Conclusão
  • Links úteis



Razões


E como falamos sobre isso, vale a pena mencionar os pré-requisitos para virtualização de rede. De fato, esse 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. Uma rede é a base sobre a qual tudo se baseia, e é muito difícil fazer alterações - os serviços não toleram quando a rede se encontra. Freqüentemente, a desativação de um único nó pode adicionar a maioria dos aplicativos e afetar muitos clientes. É em parte por isso que a equipe de rede pode resistir a qualquer mudança - porque agora de alguma forma funciona ( talvez nem saibamos como ), mas aqui precisamos configurar algo novo e não se sabe como isso afetará a rede.

Para não esperar que os provedores de rede passem pelas VLANs e não registrem nenhum serviço em cada nó da rede, as pessoas decidiram usar sobreposições - redes sobrepostas - das quais há uma grande variedade: GRE, IPinIP, MPLS, MPLS L2 / L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE etc.

Seu apelo está em duas coisas simples:

  • Somente nós finais estão configurados - você não precisa tocar em nós de trânsito. Isso acelera significativamente o processo e, às vezes, até permite excluir o departamento de infraestrutura de rede do processo de introdução de novos serviços.
  • A carga está oculta no interior dos cabeçalhos - os nós de trânsito não precisam saber nada sobre isso, sobre endereçamento em hosts, rotas da rede imposta. E isso significa que você precisa armazenar menos informações nas tabelas, portanto, adote um dispositivo mais simples / mais barato.

Nesta questão não totalmente desenvolvida, não pretendo analisar todas as tecnologias possíveis, mas descrever a estrutura para a operação de redes de sobreposição em controladores de domínio.

A série inteira descreverá um data center, consistindo em linhas de racks semelhantes nos quais o mesmo equipamento de servidor está instalado.

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





Terminologia


No loop, chamarei o servidor de um programa que implementa o lado do servidor da comunicação cliente-servidor.

Máquinas físicas em racks não serão chamadas de servidores.

A máquina física é um computador montado em rack x86. Na maioria das vezes, usamos o termo host . Então, chamaremos de " máquina " ou host .

Um hypervisor é um aplicativo em execução 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 rede, a palavra "hypervisor" é usada como sinônimo de "host".

Uma máquina virtual é um sistema operacional em execução em uma máquina física sobre um hipervisor. Para nós, dentro da estrutura deste ciclo, não é tão importante 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.

Multilocação ou multilocação - o uso do mesmo aplicativo por diferentes clientes / serviços. Ao mesmo tempo, o isolamento dos clientes é alcançado devido à arquitetura do aplicativo e não às instâncias em execução separadamente.

ToR - Switch superior do rack - um switch montado em rack ao qual todas as máquinas físicas estão conectadas.
Além da topologia de ToR, diferentes provedores praticam End of Row (EoR) ou Middle of Row (embora este último seja uma raridade desprezível e eu não tenha visto as abreviaturas MoR).
Rede subjacente ou rede subjacente ou subjacente - infraestrutura de rede física: comutadores, roteadores, cabos.

Sobrepor rede ou sobrepor rede ou sobrepor - uma rede virtual de túneis que é executada em cima de uma rede física.

A fábrica L3 ou IP é uma tremenda invenção da humanidade, que permite entrevistas para não repetir STP e não aprender TRILL. Um conceito em que toda a rede até o nível de acesso é exclusivamente L3, sem VLANs e domínios de transmissão estendidos correspondentemente enormes. De onde vem a palavra "fábrica" ​​na próxima parte.

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

NFV - Virtualização de Funções de Rede - virtualização de dispositivos de rede, que pressupõe que parte das funções de rede possa ser lançada 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 deliberadamente simplificando a descrição para uma implementação específica para não confundir muito o leitor. Para uma leitura mais criteriosa, envie-a para a seção Links . Além disso, Roma Gorge, que critica este artigo por imprecisões, promete escrever um problema separado sobre as tecnologias de virtualização de servidor e rede, mais profundas e mais atentas aos detalhes.


Hoje, a maioria das redes pode ser claramente dividida em duas partes:

Underlay - uma rede física com uma configuração estável.
Overlay - Abstração sobre Underlay para isolar inquilinos.

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

Imagem de foco da rede:





Underlay


Underlay é uma rede física: comutadores e cabos de hardware. Os dispositivos na base sabem como chegar às máquinas físicas.



Ele se baseia em protocolos e tecnologias padrão. Além disso, como os dispositivos de hardware ainda funcionam em software proprietário que não permite a programação de chips ou a implementação de seus protocolos, respectivamente, são necessárias 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 é alterado raramente, porque sua tarefa é a conectividade IP básica entre máquinas físicas. O Underlay não sabe nada sobre serviços em execução, clientes, inquilinos - ele só precisa entregar um pacote de uma máquina para outra.
Underlay pode ser assim:

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

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

Manualmente, scripts, utilitários proprietários.

Em mais detalhes, o próximo artigo da série será dedicado à base.


Sobreposição


Overlay - uma rede de túnel virtual estendida sobre o Underlay, permite que as VMs de um cliente se comuniquem, proporcionando isolamento de outros clientes.

Os dados do cliente são encapsulados em qualquer cabeçalho de encapsulamento para transmissão em uma rede compartilhada.



Portanto, as VMs de um cliente (um serviço) podem se comunicar através da Overlay, sem nem mesmo saber o que o pacote realmente faz.

A sobreposição pode ser, por exemplo, a mesma que mencionei acima:

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

Uma rede de sobreposição geralmente é configurada e mantida através de um controlador central. A partir dele, a configuração, o Plano de controle e o Plano de dados são entregues aos dispositivos que direcionam e encapsulam o tráfego do cliente. Abaixo , analisaremos isso com exemplos.

Sim, isso é puro SDN.

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 em um ToR (switch de acesso montado em rack), como é o caso, por exemplo, no caso de uma fábrica de VXLAN.

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

No entanto, nesse caso, o switch ToR deve poder compartilhar serviços diferentes, respectivamente, e o administrador da rede deve, em certa medida, cooperar com os administradores de máquinas virtuais e fazer alterações (ainda que automaticamente) na configuração do dispositivo.



Aqui, remeterei o leitor para um artigo sobre VxLAN no hub do nosso velho amigo @bormoglotx .
Nesta apresentação com a ENOG , abordagens para a construção de uma rede DC com uma fábrica EVPN VXLAN são descritas em detalhes.

E para uma imersão mais completa nas realidades, você pode ler o livro Um tecido moderno, aberto e escalável: VXLAN EVPN .
Observo que o VXLAN é apenas um método de encapsulamento e a terminação do túnel pode ocorrer não no ToR, mas no host, como é o caso do OpenStack, por exemplo.

No entanto, a fábrica da VXLAN onde a sobreposição começa no ToR é um dos projetos de rede de sobreposição bem estabelecidos.

Sobreposição do host


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



Para fazer isso, você certamente precisará executar um aplicativo especial nos hosts, mas vale a pena.

Em primeiro lugar, executar um cliente em uma máquina Linux é mais simples, ou, digamos, geralmente possível, enquanto estiver no switch, você provavelmente terá que recorrer a soluções SDN proprietárias por enquanto, o que mata a ideia de vários fornecedores.

Em segundo lugar, a chave 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. De fato - ele não precisa se comunicar com o controlador SDN e armazenar as redes / ARPs de todos os clientes conectados - também - apenas sabe o endereço IP da máquina física, o que simplifica bastante as tabelas de comutação / roteamento.


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


A maneira mais fácil de considerar os exemplos. E, como assunto de teste, usaremos a plataforma OpenSource SDN OpenContrail, agora conhecida como Tungsten Fabric .
No final do artigo, darei algumas reflexões sobre a analogia com o OpenFlow e o OpenvSwitch.

Estudo de caso de tecido de tungstênio


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

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

Cada VM localizada no hipervisor é conectada ao vRouter desta máquina por meio da interface TAP .

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



Se houver várias redes por trás do vRouter, uma interface virtual será criada para cada uma delas, à qual um endereço IP está atribuído - será o endereço de gateway padrão.
Todas as redes de um cliente são colocadas em um VRF (uma tabela), diferente - em diferente.
Farei uma reserva aqui que não é tão simples e enviarei o curioso leitor para o final do artigo .

Para que o vRouter'y se comunique e, consequentemente, as VMs localizadas atrás deles, eles trocam informações de roteamento por meio de um controlador SDN .



Para entrar no mundo exterior, há um ponto de saída da matriz - o gateway de rede virtual VNGW - Virtual Network GateWay ( meu termo ).




Agora considere os exemplos de comunicação - e haverá clareza.


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


VM0 deseja enviar um pacote para VM2. Por enquanto, suponha que essa seja uma VM de cliente único.

Plano de dados


  1. VM-0 tem uma rota padrão em sua interface eth0. O pacote é enviado para lá.
    Essa interface eth0 está praticamente conectada ao roteador virtual vRouter por meio da interface tap0 TAP.
  2. O vRouter analisa a qual interface o pacote chegou, ou seja, a qual cliente (VRF) ele pertence, verifica o endereço do destinatário com a tabela de roteamento desse cliente.
  3. Depois de descobrir que o receptor na mesma máquina está atrás de uma porta diferente, o vRouter simplesmente envia o pacote para ele sem nenhum cabeçalho adicional - nesse caso, o vRouter já possui um registro ARP.



O pacote, neste caso, não entra na rede física - é roteado dentro do vRouter.


Plano de controle


Quando a máquina virtual inicia, o hipervisor diz a ela:

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

Por meio de uma API especial, o hypervisor se reporta ao vRouter:

  • O que você precisa para criar uma interface virtual.
  • Qual (VM) precisa criar uma rede virtual.
  • Para qual VRF vinculá-lo (VN).
  • O registro ARP estático para esta VM é qual interface possui seu endereço IP e qual endereço MAC está anexado.

E, novamente, o procedimento de interação real é simplificado para entender o conceito.


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


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

Se eles podem se comunicar diretamente depende das configurações do vRouter e do design da rede.
Por exemplo, se as VMs de ambos os clientes usam endereços públicos, ou o NAT ocorre no próprio vRouter, o roteamento direto para o vRouter também pode ser feito.

Na situação oposta, é possível atravessar espaços de endereço - você precisa passar por um servidor NAT para obter um endereço público - isso é semelhante ao acesso a redes externas, descritas abaixo.



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


Plano de dados


  1. O início é exatamente o mesmo: a VM-0 envia um pacote com a VM-7 de destino (172.17.3.2) por padrão.
  2. O vRouter o recebe e, desta vez, vê que o destino está em outra máquina e é acessível através do túnel Tunnel0.
  3. Primeiro, ele desliga a etiqueta MPLS que identifica a interface remota, para que na parte traseira do vRouter possa determinar onde colocar esse pacote sem ganchos adicionais.


  4. Tunnel0 tem uma fonte 10.0.0.2, o receptor: 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. Lá e envia.



  6. O ToR1 como membro da rede Underlay sabe (por exemplo, via OSPF) como chegar à 10.0.1.2 e envia um pacote ao longo da rota. Observe que o ECMP está incluído aqui. Na ilustração, há duas próximas etapas, e diferentes fluxos serão dispostos neles por hash. No caso de uma fábrica real, provavelmente haverá 4 nextops.

    Ao mesmo tempo, ele não precisa saber o que está sob o cabeçalho IP externo. De fato, sob IP, pode haver um sanduíche do IPv6 sobre MPLS sobre Ethernet sobre MPLS sobre GRE sobre sobre grego.
  7. Por conseguinte, no lado receptor, o vRouter remove o GRE e, usando o rótulo MPLS, entende para qual interface esse pacote deve ser transmitido, retira-o e envia-o ao destinatário em sua forma original.


Plano de controle


Quando você inicia a máquina, tudo o que acontece é descrito acima.

E mais o seguinte:

  • Para cada cliente, o vRouter aloca uma tag MPLS. Essa é a etiqueta de serviço L3VPN, na qual os clientes serão divididos na mesma máquina física.
    De fato, a tag MPLS sempre é alocada pelo vRouter'om sempre - porque não se sabe antecipadamente que a máquina só interage com outras máquinas atrás do mesmo vRouter'om e isso provavelmente não é o caso.
  • O vRouter estabelece uma conexão com o controlador SDN via BGP (ou similar - no caso de TF, este é XMPP 0_o).
  • Nesta sessão, o vRouter informa ao controlador SDN as rotas para as redes conectadas:

    • Endereço de rede
    • Método de encapsulamento (MPLSoGRE, MPLSoUDP, VXLAN)
    • Etiqueta MPLS do cliente
    • Seu endereço IP como nexthop

  • O controlador SDN recebe essas rotas de todos os vRouter'ov conectados e as reflete para outras pessoas. Ou seja, ele atua como um refletor de rota.

A mesma coisa acontece na direção oposta.



A sobreposição pode mudar pelo menos a cada minuto. Algo como isso acontece em nuvens públicas, quando os clientes iniciam e desligam regularmente suas máquinas virtuais.

O controlador central assume todas as dificuldades de manter a configuração e controlar as tabelas de comutação / roteamento no vRouter.

Grosso modo, o controlador é encerrado com todos os vRouters via BGP (ou um protocolo semelhante a ele) e simplesmente transmite informações de roteamento. O BGP, por exemplo, já possui uma família de endereços para transmitir o método de encapsulamento MPLS-in-GRE ou MPLS-in-UDP .

Ao mesmo tempo, a configuração da rede Underlay não muda de forma alguma, o que, aliás, é muito mais difícil de automatizar, e é mais fácil interromper um movimento estranho.



Sair para o mundo exterior


Em algum lugar, a simulação deve terminar e, do mundo virtual, você precisa entrar no mundo 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, enfrentamos o VNF após o SDN). Vamos chamá-lo de gateway virtual.

— — . , , , , , , , , , .

, , , , ( ). , - , , — .
Com um pé, o gateway analisa a rede virtual Overlay, como uma Máquina Virtual normal, e pode interagir com todas as outras VMs. Ao mesmo tempo, ele pode encerrar em si as redes de todos os clientes e, consequentemente, realizar o roteamento entre eles.

Com o outro pé, o gateway já está olhando para a rede de backbone e sabe como acessar a Internet.




Plano de dados


Ou seja, o processo fica assim:

  1. A VM-0, tendo padronizado tudo no mesmo vRouter, envia um pacote com um destino no mundo externo (185.147.83.177) para a interface eth0.
  2. O vRouter recebe esse pacote e faz uma pesquisa de 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 desligue primeiro o MPLS- O rótulo deste cliente que o VNGW1 espera.
  3. O vRouter empacota o pacote original nos cabeçalhos MPLS, GRE e novos IP e o envia para o ToR1 10.0.0.1 por padrão.
  4. Uma rede subjacente entrega o pacote ao gateway VNGW1.
  5. O gateway VNGW1 remove os cabeçalhos de encapsulamento GRE e MPLS, vê o endereço de destino, consulta sua tabela de roteamento e entende que é direcionado para a Internet - ou seja, em Tela cheia ou Padrão. Se necessário, executa a conversão NAT.
  6. Do VNGW até a fronteira, pode haver uma rede IP regular, o que é improvável.
    Pode ser uma rede MPLS clássica (IGP + LDP / RSVP TE), pode ser uma fábrica de volta com uma LU BGP ou um túnel GRE do VNGW até a fronteira através da rede IP.
    Seja como for, o VNGW1 executa os encapsulamentos necessários e envia o pacote original para a borda.



O tráfego na direção oposta segue as mesmas etapas na ordem oposta.

  1. VNGW1
  2. , , Tunnel1 (MPLSoGRE MPLSoUDP).
  3. , MPLS, GRE/UDP IP ToR3 10.0.255.1.
    — IP- vRouter', — 10.0.0.2.
  4. vRouter'.
  5. vRouter GRE/UDP, MPLS- IP- TAP-, eth0 .




Control Plane


O VNGW1 estabelece uma vizinhança BGP com um controlador SDN, do qual recebe todas as informações de roteamento sobre clientes: qual endereço IP (vRouter) é usado para identificar qual cliente e com qual rótulo MPLS ele se identifica.

Da mesma forma, ele próprio informa ao controlador SDN a rota padrão com o rótulo deste cliente, indicando-se como nexthop. E então esse padrão chega ao vRouter'y.

Os VNGWs normalmente roteam agregação ou conversão NAT.

E na direção oposta, ele fornece exatamente essa rota agregada para uma sessão com pensionistas ou refletores de rota. E a partir deles recebe uma rota padrão ou Full-View, ou qualquer outra coisa.

Em termos de encapsulamento e troca de tráfego, o VNGW não é diferente do vRouter.
Se você expandir um pouco a área, poderá adicionar outros dispositivos de rede ao VNGW e ao vRouter, como firewalls, farms de purificação ou enriquecimento de tráfego, IPS e assim por diante.

E com a ajuda da criação sucessiva de VRF e o anúncio correto das rotas, você pode fazer o loop de tráfego como desejar, chamado de Service Chaining.

Ou seja, aqui o controlador SDN atua como um refletor de rota entre o VNGW, o vRouter'ami e outros dispositivos de rede.

Mas, de fato, o controlador também libera informações sobre ACLs e PBRs (Policy Based Routing), forçando os fluxos de tráfego individuais a serem diferentes do que a rota lhes diz.





Perguntas frequentes



Por que você está sempre fazendo uma observação do GRE / UDP?

Bem, em geral, pode-se dizer que é específico do tecido de tungstênio - você pode ignorá-lo completamente.

Mas se você aceitar, o próprio TF, enquanto ainda é um OpenContrail, suporta os dois encapsulamentos: MPLS no GRE e MPLS no UDP.

O UDP é bom porque na porta de origem em seu cabeçalho é muito fácil codificar uma função de hash da porta IP + Proto + original, o que permitirá o balanceamento.

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

Até algum tempo, os roteadores, se soubessem usar túneis dinâmicos, somente no MPLSoGRE, e apenas muito recentemente, aprenderiam no MPLSoUDP. Portanto, você sempre deve fazer um comentário sobre a possibilidade de dois encapsulamentos diferentes.

Para ser justo, vale a pena notar que o TF suporta totalmente a conectividade L2 usando VXLAN.


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

No Data Plane, eles funcionam aproximadamente da mesma forma, o Control Plane difere significativamente. O Tungsten Fabric usa o XMPP para fornecer informações de rota ao vRouter, enquanto o Openflow trabalha no OpenStack.


Posso ter um pouco mais sobre o vRouter?
Ele é dividido em duas partes: vRouter Agent e vRouter Forwarder.

O primeiro é iniciado no Espaço do Usuário do SO host e se comunica com o controlador SDN, trocando informações sobre rotas, VRF e ACL.

O segundo implementa o Data Plane - geralmente no Kernel Space, mas também pode ser iniciado em SmartNICs - placas de rede com uma 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 previsível.

Outro cenário é possível quando o vRouter é um aplicativo DPDK no Espaço do Usuário.

O vRouter Agent descarta as configurações no vRouter Forwarder.


O que é rede virtual?
Mencionei no início do artigo sobre o VRF que cada inquilino está anexado ao seu VRF. E se isso foi suficiente para uma compreensão superficial do trabalho da rede de sobreposição, já na próxima iteração é necessário fazer esclarecimentos.

Geralmente, nos mecanismos de virtualização, a entidade de rede virtual (você pode usar como nome próprio) é apresentada separadamente dos clientes / locatários / máquinas virtuais - é algo bastante independente. E essa rede virtual através das interfaces já pode ser conectada em um inquilino, no outro, em dois, mas pelo menos onde. Assim, por exemplo, o Service Chaining é implementado quando o tráfego precisa ser passado por determinados nós na sequência desejada, simplesmente criando e chamando Redes Virtuais na sequência correta.

Portanto, como tal, não há 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 uma sobreposição do host e do controlador SDN. Mas não importa qual plataforma de virtualização você adote hoje, ela funcionará de maneira semelhante, seja VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric ou Juniper Contrail. Eles diferem nos tipos de encapsulamento e cabeçalhos, protocolos para fornecer informações aos dispositivos de rede finais, mas o princípio de uma rede de sobreposição ajustada por software que trabalha sobre uma rede de subjacência relativamente simples e estática permanecerá o mesmo.
Podemos dizer que, nas áreas de criação de uma nuvem privada até o momento, o SDN baseado na rede de sobreposição venceu. 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, tanto quanto eu sei, o Google o usa para configurar a rede subjacente.

Abaixo, dei links para materiais mais detalhados, se você quiser estudar a questão mais profundamente.

E qual é 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 quando o vRouter / VNGW aparecer e desaparecer e arrastar pacotes entre eles.

Vamos formular uma lista de requisitos para uma rede Underlay.

  1. Ser capaz de algum protocolo de roteamento, em nossa situação - BGP.
  2. , , - .
  3. ECMP — .
  4. QoS, , ECN.
  5. NETCONF — .

Dediquei muito pouco tempo ao trabalho da própria rede Underlay. Isso ocorre porque, mais tarde na série, focarei nisso e tocaremos em Overlay apenas de passagem.

Obviamente, limitei severamente a todos nós, usando como exemplo a rede DC construída na fábrica de Klose com roteamento IP puro e sobreposição do host.

No entanto, tenho certeza de que qualquer rede que tenha um design pode ser descrita em termos formais e automatizada. É que estou buscando o objetivo de entender as abordagens da automação e não confundir todo mundo, resolvendo o problema de uma maneira geral.

Como parte do ADSM, Roman Gorge e eu planejamos publicar um problema separado sobre a virtualização do poder da computação e sua interação com a virtualização de rede. Fique em contato.


Links úteis



Obrigado

  • Roman Gorge , ex-principal host do podcast linkmeup e agora especialista no campo de plataformas em nuvem. Para comentários e edições. Bem, esperamos um artigo mais aprofundado sobre virtualização em um futuro próximo.
  • Alexander Shalimov , meu colega e especialista no desenvolvimento de redes virtuais. Para comentários e edições.
  • Valentina Sinitsyna , minha colega e especialista em tecidos de tungstênio. Para comentários e edições.
  • Artyom Chernobay - ilustrador linkmeup. Para KDPV.
  • Alexander Limonov. Para o meme "automato".

Source: https://habr.com/ru/post/pt458622/

More articles:


All Articles