Bom pessoal, nos últimos posts, Parte 1 e Parte 2, falamos sobre os serviços de DR (Distributed Router) e SR (Service Router) executados nos Logical Routers, no post 2 também comentamos que os Logical Routers podem ser do tipo Tier0 e Tier1, dependendo da arquitetura escolhida.
O objetivo deste post será abordar com mais detalhes os Edge-Nodes.
Edge-Nodes
Como mencionado anteriormente, serviços statefull como conectividade Norte-Sul, NAT, Load Balance, VPN etc que não podem ser executados como serviços distribuídos no Kernel de cada Host, são providos pelo Service Router (SR), que podem ser implementados tanto em Tier0 quanto em Tier1.
Quando serviços statefull são consumidos, como exemplo o tráfego saindo de uma VM para a internet (N-S), este tráfego passa necessariamente por um appliance virtual, no caso do tráfego norte-sul, sabemos também que ele passa por uma instância T0, mas se analisarmos a lista de VM’s do ambiente, veremos que não existe nenhum appliance virtual para um T0, quando realizamos o deploy de um T0, obrigatóriamente temos que informar à qual Edge-Node ou cluster de Edge-nodes ele será vinculado, os Edge-node sim são appliances virtuais e podem ser visualizados por exemplo na estrutura do vCenter.
Existem duas possibilidades para se realizar o deploy de Edge-nodes, na forma de uma VM, sendo feito o deploy pelo NSX Manager, e na forma Bare-Metal, feito o deploy através de uma ISO.
Desta forma, os Edges são de fato os responsáveis por prover roteamento e conectividade com o ambiente externo ao NSX-T, quando configuramos um uplink no Tier-0, na verdade estamos informando que aquele objeto lógico ( T0 ) utiliza como provedor de serviços statefull determinado Edge, e que a interface que será utilizada como uplink na verdade é uma interface do Edge.
Edge-nodes geralmente são implementados em clusters próprios ou clusters de gerência, geralmente são implementados em Hosts os quais estão o mais próximo possível de roteadores, ToR’s e Firewalls responsáveis pelo roteamento da rede, já que o tráfego Norte-Sul é canalizado por meio deles, essa arquitetura não é pré-requisito, e sim uma recomendação:
fonte: vmware.com
Algumas considerações merecem atenção antes de partirmos para o deploy de um Edge como exemplo.
No post 4, abordaremos com mais detalhes as Transport Zones do tipo Overlay e VLAN, porém é importante lembrarmos que as redes L2 criadas no NSX-V ou NSX-T (logical Switches), são encapsuladas por uma rede Overlay, isso permite que essas redes sejam transportadas através de todo o data center e até mesmo entre data centers distintos, as redes L2 então recebem uma TAG VNI (Virtual Network Identifier), então são transportadas através de uma única VLAN ou passando por todo um backbone roteavel L3, no NSX-V, o protocolo utilizado para overlay de rede era o VXLAN, já no NSX-T, temos o GENEVE. Para que esse tráfego seja “tunelado / encapsulado”, cada Host (ESXi, KVM etc) e os Edge-Nodes devem possuir uma interface do tipo TEP (Tunnel Endpoint). Não se preocupe, veremos isso com mais detalhes no post 4.
O que temos que manter em mente aqui é, interfaces TEP de cada host (seja em ESXi, KVM etc), devem ser estendidas a interfaces TEP também dos Edge-nodes VM, para que exista então túneis overlay entre eles, a rede overlay entre os hosts esxi e edge vms não precisa ser exatamente ser exatamente a mesma rede IP, mas o IP dos TEP’s devem ser alcançáveis entre si.
Exemplo de Overlay utilizando a mesma rede:
Exemplo de Overlay utilizando redes diferentes, porém, roteavel:
Uma observação importante aqui, existe uma limitação na arquitetura, que acredito ser a realidade em Labs onde existe somente um servidor com apenas uma interface física, interfaces TEP dos Hosts ESXi e interfaces TEP das Edge VMs no mesmo vSwitch/Uplink não é suportado. Uma VM de Edge-node executando dentro de um host ESXi deve ter sua interface TEP colocada em seu próprio vSwitch / vmnic, e então ser roteada através de um appliance terceiro.
Mantenha em mente também que as VM’s de Edge-Nodes devem ter ao menos uma das suas interfaces no Transport Zone do tipo VLAN, interfaces do tipo VLAN serão as interfaces utilizadas como “Uplink” dos Edges, elas serão ligadas à portgroups VLAN’s dos Hosts ESXi e serão utilizadas para tráfego Norte-Sul.
As VM’s de Edge-node possuem um ou mais switches virtuais dentro delas, os uplinks de cada um desses switches virtuais então são conectados aos portgroups do Distributed Switch (VDS). Em suma, cada VM Edge-Node terá três ou mais interfaces, 1 de gerenciamento, 1 para trafego Overlay e uma ou mais para trafego VLAN para ligação com a rede física.
Ao criar um novo Edge, considero uma boa prática a criação de ao menos dois switches virtuais dentro do Edge, um para Transport Zone Overlay, e um para Transporte Zone VLAN, esses switches virtuais existiram apenas dentro dos Edges e não serão visíveis no vCenter. Veremos a criação de um Edge logo, por enquanto, observe as duas imagens que resumem a estrutura de um Edge.
Visão de um edge e seus virtual switches:
fonte: docs.vmware.com
Visão geral do edge em meu lab:
Como visto anteriormente, um Edge VM tem quatro interfaces, a interface eth0 será sempre utilizada para gerência, não participando de roteamento ou serviços statefull, as outras interfaces recebem um prefixo “fp-eth<x>“, essas interfaces são utilizadas como Uplink’s entre os switch virtuais do Edge com o PortGroup assinado à elas no VDS/N-VDS, as interfaces do tipo fp-eth utilizam a tecnologia DPDK, uma tecnologia criada em Linux para processamento mais rápido dos pacotes e alta disponibilidade, já que o tráfego será canalizado nos Edges.
Deploy de um Edge como exemplo:
Para o deploy de um Edge, entreNSX Manager, em Syste, depois Fabric –> Nodes -> Edge Transport Nodes. Clique então em + ADD EDGE VM
Dê um nome ao Edge, a informação do FQDN também será solicitada nessa tela, também é muito importante realizar o sizing correto do Edge, visto que algumas soluções como quantidade de Load Balancers dependem do tamanho escolhido, se o intuito também for utilizar kubernetes através do Tanzu, será obrigatório a escolha do edge como Large. Importante ressaltar também a importância de cadastrar esse FQDN nos DNS Servers:
Na próxima tela, configure em qual cluster/host/datastore a VM do Edge estará rodando, similar a qualquer deploy de VM/OVA/OVF.
Já na tela seguinte, serão solicitadas informações da interface de gerência, aquela interface eth0 mostrada anteriormente, lembre-se, essa interface será apenas de gerência, não participando de roteamento, serviços statefull, nada. Eu conectei essa interface em um Portgroup do VDS que está configurado como VLAN15, repare, aqui não foi feito nenhuma configuração de VLAN, ela já está configurada no meu portgroup no VDS
A seguir, uma imagem que mostra meu VDS01, com o portgroup configurado como VLAN ID 15:
A ultima tela e mais importante é onde configuraremos os switches virtuais internos do Edge, transporte zone etc, fiquem tranquilos pois falaremos mais de Transporte Zone no proximo post, mas tenha em mente que iremos configurar dois switches virtuais (do tipo N-VDS) dentro desse Edge VM:
– Um para o transporte zone de Overlay, que pertencerá a rede com a interface TEP, a qual será conectada aos TEP’s de cada um dos ESXi do ambiente
– E outro switch virtual interno para o transporte zone VLAN, que contará com os Uplinks ligados aos portgroups do meu VDS, os quais serão utilizados como conexão ao mundo físico exterior.
O primeiro virtual switch interno será o de overlay. Crie um nome para esse switch, lembre-se, ele existe internamente no Edge, não será visto no vCenter, e nem deveria ser o mesmo nome do VDS utilizado no ambiente virtual
Após, clique em Create New Transport Zone, e configure o TZ como overlay:
Em Uplink Profile, crie um Uplink Profile novo ou utilize os já existentes, no meu caso, utilizarei um profile já existe com somente um uplink, o “nsx-edge-single-nic-uplink-profile”.
Caso deseje criar novos profiles, uma das informações solicitadas será Transport VLAN, lembre se, os uplinks dos switches internos do Edge já serão conectados à portgroups com VLANs já configuradas neles, ou seja, não é necessário configurar VLAN alguma nesse meu exemplo, deixando como “0”, no NSX, VLAN 0 é a mesma coisa que nenhuma Tag de VLAN.
Como esse é um Switch interno virtual para o Transporte Zone de Overlay, precisamos configurar em IP Assignment um Pool de IP’s disponíveis para as interfaces TEP ou então configurar manualmente uma lista, eu já havia pré-configurado meu Pool de TEP’s para Edges na rede 192.168.17.x/24.
Em Uplinks, irei selecionar um Portgroup do meu VDS correspondente a VLAN17 do meu lab.
Repare novamente que não foi configurado VLAN para o UPlink , pois estou escolhendo um portgroup que já consta tag de VLAN:
Informações do meu PortGroup no vCenter:
Agora crie outro switch virtual interno para o Transporte Zone de VLAN, que será utilizado para trafego Norte-Sul.
Novamente, em Uplink profile eu não configurei nenhuma VLAN no profile, permanecendo como “0”.
Repare que com transporte zone do tipo VLAN, não é necessário definir um Pool de IP, já que não existirá interfaces TEP.
O uplink utilizado aqui é um portgroup VLAN50, que utilizo como rede de Uplink para o restante do meu ambiente:
Após alguns minutos, o deploy do Edge estará finalizado, será possível validar informações como IP do TEP que irá fechar conexão overlay com os ESXi’s, IP de gerência do Edge, em qual Host ele está rodando etc.
IMPORTANTE, repare na imagem anterior que em Tunnels consta como “Not Available”, esses são os túneis TEP com os ESXi’s, consta como not available porquê até esse momento não existia nenhuma VM em meu ambiente conectada à um Logical Switch e então tendo seu tráfego canalizado para o restante do ambiente através do Edge (Logical Switches e como “linkar” um T0 ao Edge são conversas para outro post), mas resolvi subir uma VM Centos e fazer com que o trafego Norte-Sul dela passe pelo Edge, sendo assim, um túnel com o TEP do ESXi que esse CentOS está rodando foi estabelecido:
Bom pessoal , é isso, no próximo post falaremos mais sobre Transporte Zones Overlay e VLAN, qual utilizar em cada caso.
Obrigado.