Parte do problema ao realizarmos a migração de uma VM ou Container entre dois servidores na rede é garantir uma rápida reconfiguração da rede, de modo que todo tráfego ativo que antes ia para o servidor antigo seja encaminhado para o servidor novo. Uma forma de realizar este tipo de mudança é utilizar a tecnologia Openflow.
Neste tutorial aprenderemos como configurar o switch Openflow Open Virtual Switch (OvS) para readequar o encaminhamento de tráfego de Containers e/ou VMs após sua migração.
Vamos abordar aqui apenas as configurações referentes ao OvS, com os comandos necessários para habilitar a migração na rede, levando em consideração os Protocolos de rede, Portas de entrada e saída e Endereços IP. Lembramos que a migração do Container e/ou VM independe desta configuração, já que aqui estamos interessados apenas na reconfiguração da rede. Detalhes sobre a migração de Containers podem ser encontrados em outro post (Migração de Containers utilizando Criu e LXC).
Vamos ao conteúdo prático deste material!
No primeiro momento é necessário criar uma bridge virtual. É por ela que o controlador irá se comunicar com as outras interfaces de rede.
$ sudo ovs-vsctl add-br <nomedabridge>
Daqui para frente denominaremos a bridge criada de ofbr. Após criada a bridge devemos adicionar as interfaces do host que estarão ligadas a bridge. Ex:
$ sudo ovs-vsctl add-port br0 ofbr
Após isso, quaisquer máquinas cujas interfaces estejam ligadas ao switch já estarão aptas a se comunicar, já que o OvS, por padrão, configura o switch virtual para atuar como um comutador Ethernet normal que realiza auto-aprendizado dos MACs das máquinas conectadas ao swicth, bem como o repasse de pacotes baseado em endereços MAC. Para visualizar esta regra padrão pode-se listar todas as regras Openflow presentes em seu switch por meio do comando
$ sudo ovs-ofctl dump-flows <nomedabridge>
Assim você poderá visualizar a configuração atual e também acompanhar quaisquer alterações nas regras. Para remover todas as regras instaladas em um switch OvS execute
$ sudo ovs-ofctl del-flows <nomedabridge>
Para devolver a regra padrão executa-se o comando abaixo:
$ sudo ovs-ofctl add-flow <nomedabridge> actions=NORMAL
Vale lembrar que a regra inserida tem prioridade 32768 (a prioridade padrão quando que nenhuma é especificada) e que para que uma regra se sobreponha a esta, é preciso que sua prioridade seja maior.
Em seguida já podemos configurar o OvS para fazermos a migração.
$ sudo ovs-ofctl add-flow ofbr priority=50000,dl_type=0x0800,nw_proto=6,nw_src=10.0.0.10,nw_dst=10.0.0.1,tp_dst=5000,actions=output:1
$ sudo ovs-ofctl add-flow ofbr priority=50000,dl_type=0x0800,nw_proto=6,nw_src=10.0.0.1,nw_dst=10.0.0.10,tp_src=5000,actions=output:2
Estes comandos que acabamos adicionar criam regras de entrada e saída de pacotes entre os hosts 10.0.0.1 e 10.0.0.10 de nossa rede. É necessário inserir as duas regras no switch para que seja possível o envio de dados em ambos os sentidos. Vamos agora esmiuçar cada comando da linha acima.
add-flow —> Adiciona regra à bridge
ofbr ———> nome da bridge
priority —–> Define a prioridade da regra sobre as demais. Caso não seja citado ela tomará a numeração padrão que é 32768. Os limites para prioridade das regras vai de 0 à 65536. Fora disso você verá a mensagem de erro: ovs-ofctl: invalid priority
dl_type —–> Aqui especificamos o Ethertype, isto é, o número que corresponde ao protocolo do datagrama que é carregado pelo quadro Ethernet. É bom dar uma olhada nos diferentes tipos de Ethertype. O dl_type=0x0800 quer dizer que a regra criada está restrita à datagramas IPv4.
nw_proto —> Número do protocolo que corresponde ao segmento encapsulado no datagrama IP. No exemplo em questão, utilizamos o valor 6 que corresponde ao TCP.
nw_src ——> Endereço IPv4 de saída.
nw_dst ——> Endereço IPv4 de destino.
tp_dst ou tp_src ——-> Porta de destino ou origemda camada de Transporte, respectivamente. No exemplo, a aplicação executa no servidor na porta 5000.
actions ——> Por último temos o trecho da regra que define a ação que será tomada pelo OvS. Em nosso exemplo, a ação diz ao switch o que fazer com os pacotes que venham a combinar com a regra inserida. No nosso exemplo, encaminhamos todo o tráfego para a interface onde se encontra o servidor (primeira regra) e para o cliente (segunda regra).
Espero que vocês tenham gostado e que este tutorial possa auxiliá-los em seu projeto ou pesquisa.
Objetivo, claro e didático.Parabéns Saulo!
CurtirCurtir