Entenda o Open vSwitch e sua aplicação em nuvens públicas e privadas

Você que tem trabalhado com containers e VMs (máquinas virtuais) em nuvens públicas e privadas já deve ter ouvido falar do Open vSwitch (OVS). Ele é um switch virtual que conecta os pods do seu Kubernetes (K8S), que isola os projetos do seu OpenShift/OKD e que disponibiliza os serviços das VMs do seu OpenStack para o mundo. Se você quer saber como o OVS consegue fornecer as redes virtuais que atendem todos esses cenários e vários outros, este post é o que estava procurando.

Sobre o Open vSwitch (OVS)

O propósito de um switch ethernet virtual (físico ou virtual) é transportar os dados entre as suas portas. Cada uma dessas portas normalmente está conectada a um outro componente de rede, como um outro switch, uma VM ou até mesmo um conjunto de containers.

Importante! O Open vSwitch usa tabelas para decidir o que fazer com cada quadro ou pacote, são as tabelas de fluxo (flow tables). Cada tabela é uma lista de regras ordenadas em função de uma prioridade; as de maior prioridade são avaliadas antes. Quando as condições de seleção de uma regra são atendidas, as ações dela são executadas, como alterar o pacote, enviar ele para uma porta de saída ou saltar para outra tabela.

Cenário 1

No cenário mais simples o comportamento do switch é chamado de hub, conectando as portas como um meio físico único de comunicação e replicando cada pacote de uma porta para todas as outras portas, como na figura 1 a seguir.

Figura 1: Hub

A tabela de fluxo do switch da figura 1 está representada abaixo de forma simplificada. Ela contém apenas uma regra, com a menor prioridade, que será usada para todas as mensagens. A ação ‘normal’ (às vezes chamada de flood) dessa regra faz com que a mensagem seja retransmitida para todas as portas do switch, exceto para a porta de onde a mensagem foi recebida. Esse é o comportamento padrão de um switch virtual que acabou de ser criado no OVS.

Cenário 2

Também é possível segmentar suas portas para isolar umas das outras. Na figura 2 vemos que as quatro VMs conseguem se comunicar entre si apenas duas a duas. Nesse caso o switch se comporta como se ele fosse dois switches independentes.

Figura 2: Segmentos independentes

Existem muitas formas de organizar os fluxos para este cenário, mas para este exemplo vamos usar mais de uma tabela, com ações que as conectam, assim como vamos evitar a ação ‘normal’. Quando usamos mais de uma tabela, a tabela 0 é o ponto de partida para o processamento de todo fluxo.

Tabela 0:

Tabela 1:

Tabela 2:

Quando uma mensagem chega por uma porta, o tratamento dela passa pela tabela 0 para a tabela do seu respectivo segmento de rede, que redireciona para a outra porta do segmento (ou outras portas). Se o processamento chega ao final de uma tabela sem encontrar uma regra que seja adequada, o quadro é descartado, já que não temos regras padrão nas tabelas.

Cenário 3

O terceiro cenário é similar ao primeiro, com a diferença de que o switch aprende quais MACs estão por trás de cada porta, então quando uma porta envia um quadro com MAC de destino conhecido, o switch consegue enviar a mensagem apenas para a porta (ou mais de uma) que alcança aquele destinatário. É apenas quando o MAC de destino não é conhecido que a mensagem é transmitida para todas as outras portas. E qualquer mensagem chegando com um MAC de origem desconhecido faz com que o switch aprenda que atrás daquela porta tem aquele MAC, assim mensagens de resposta podem ser enviadas apenas para aquela porta. Isso é chamado MAC learning (aprendizado de MAC) e os switches com essa capacidade são chamados de bridges (pontes).

Obs.: Alguns controladores de SDN (Software Defined Network) dão ainda um passo adiante com a estratégia l2population (população da camada 2), em que a bridge é ensinada sobre quais MACs estão por trás de uma porta assim que as portas são criadas e destruídas.

Figura 3: Bridge

Tabela 0:

Tabela 1:

Então pelo exemplo da figura 3 com a sua tabela de fluxo, podemos investigar o que acontece com um quadro que chega em uma das portas da bridge:

• Quando a VM1 (MAC 00:00:00:00:00:01, resumido como MAC:01 na figura) da porta 1 envia uma mensagem para a VM2 (MAC 00:00:00:00:00:02, resumido como MAC:02 na figura), o switch já conhece o MAC de origem, salta para a tabela 1 e encontra a regra que diz que mensagens para o MAC:02 devem ser enviadas apenas para a porta 2.
• Contudo, quando a mesma VM1 envia uma mensagem para a VM3 (MAC 00:00:00:00:00:03, resumido como MAC:03 na figura), o switch também conhece o MAC de origem e salta para a tabela 1, mas as primeiras duas regras da tabela 1 não atendem esse destinatário, então a última regra é usada para retransmitir para todas as outras portas (2 e 3).
• E quando uma mensagem é proveniente da VM3, o switch não conhece esse remetente então usará a regra padrão da tabela 0 para aprender sobre essa nova relação entre MAC e porta, enquanto que ao mesmo tempo salta para a tabela 1, decidindo o destino da mensagem em função do MAC de destino.

Obs.: O aprendizado no OVS será adicionar regras com prioridades adequadas (acima das regras padrão) nas duas tabelas. Contudo, isso pode depender de uma comunicação extra do OVS com o controlador de SDN, que veremos posteriormente.

Cenário 4

Subindo mais uma camada, um switch também pode fazer o roteamento de pacotes IP entre as sub-redes. Na figura 4, as VMs 1 e 2 estão em sub-redes e segmentos isolados das VMs 3 e 4. Também existe uma porta a mais (representada como uma barra em ciano conectada nas duas sub-redes), presente em ambos os segmentos. Essa porta é usada para rotear pacotes de um segmento para o outro e também de dentro para fora do roteador. E esse roteamento é feito com base em endereçamentos IP de redes e de hosts em cada componente da rede.

Na figura, cada segmento tem agora uma sub-rede diferente (VMs 1 e 2: 10.10.0.0/24; VMs 3 e 4: 10.20.0.0/24) e cada VM tem agora um endereço IP dentro da sua respectiva sub-rede (VM1: 10.10.0.101, VM2: 10.10.0.102, VM3: 10.20.0.101 e VM4: 10.20.0.102). Como a porta extra pertence aos dois segmentos, ela recebe dois endereços (10.10.0.1 e 10.20.0.1).

Assim, quando um pacote de uma sub-rede é destinado para a outra sub-rede, ele será endereçado para o IP da interface do roteador. E a porta receberá o pacote por um segmento e retransmitirá para o outro segmento, de acordo com as regras de roteamento contidas no roteador.

Figura 4: Duas subredes com roteamento

Cenário 5

E por fim, chegamos à última configuração, em que cada nó (do OpenStack, do OpenShift/OKD ou do Kubernetes) contém VMs, containers e outros serviços à disposição para o usuário final. Cada serviço tem as suas redes, sub-redes, portas, roteadores, firewalls, FIPs (floating IPs), VPNs, balanceadores de carga e outros componentes de rede em uma topologia arbitrariamente complexa.

Figura 5: dois nós com rede provedora e OVS controlado por OpenFlow

A figura 5 mostra dois desses nós. Eles contêm VMs que comunicam-se umas com as outras e com o mundo exterior através da rede provedora (desenhada em verde abaixo deles). O roteamento de cada OVS para o outro através da rede provedora é similar ao roteamento da figura 4, mas roteando pacotes através de uma interface externa adicionada no switch. Quando essa é uma interface da rede física do host, a rede provedora é chamada de flat e as VMs e containers têm acesso a outras máquinas físicas da sua infraestrutura. Quando essa é uma interface de tunelamento (VXLAN, GRE, Geneve…), a rede provedora é chamada de overlay network. Por fim, a rede provedora também pode ser uma VLAN.

Como pudemos perceber, o OVS apenas segue as regras das suas tabelas de fluxo, mas não as preenche (exceto possivelmente quando aprendendo MACs e IPs, mas ainda assim ele raramente faz isso sozinho). Isso significa que precisa existir um componente na nossa solução que preencha essas tabelas dos OVS com os mapeamentos de fluxos adequados para cada nó. Esse componente é chamado de controlador de SDN (SDN controller). No OpenStack esse papel é preenchido pelo Neutron; e no OpenShift/OKD pelo OpenShift SDN.

Quando o OVS é iniciado, ele recebe um conjunto de regras de fluxo através do protocolo OpenFlow (desenhado em vermelho entre os OVSs). Elas são criadas e enviadas pelo controlador de SDN, que não só conhece as VMs e containers atendidos por cada instância do OVS, como também as conexões que aquele switch deve rotear ou bloquear. Ao longo do tempo de vida do OVS, é comum que o controlador de SDN fique constantemente em contato com o OVS fornecendo atualizações das regras de fluxo, testando a saúde do OVS (para chaveamento de recursos no caso de falha) e respondendo requisições pontuais que o OVS pode fazer. Um exemplo de requisição é quando o OVS encontra um MAC novo através de uma porta e consulta o controlador sobre o que fazer: adicionar nas tabelas de fluxo como rotas novas, adicionar regras de bloqueio, notificar a equipe de segurança ou qualquer outra ação que seja adequada para a situação.

Próximos passos

Essa foi uma descrição bem simplificada do Open vSwitch e como ele é encaixado nas grandes soluções consumidoras de SDNs. Então, assim como no desenho do Van Oktop, você ainda precisa adicionar uns pequenos detalhes e terá sua solução completa:

Alguns links de referência sobre esses últimos detalhes:

• Dissecando o Faucet: Uma descrição detalhada de como um dos controladores de SDN mais simples organiza as tabelas do OVS
• OVS Avançado: Comandos de controle do OVS e explicações de usos avançados e depurações do OVS
• Conceitos e teoria de OpenFlow: Como o OpenFlow é usado para controlar os fluxos de dados em um ou mais switches virtuais

CURSOSCONSULTORIA    CONTATO