OpenShift Virtualization para administradores do vSphere: introdução às configurações de rede

O OpenShift Virtualization é a solução da Red Hat para empresas que buscam a modernização, adotando a arquitetura em containers para suas aplicações, mas ainda precisam da virtualização na estratégia de implantação de data center.

Na verdade, algumas aplicações não podem ser colocadas em containers. O OpenShift Virtualization soluciona isso oferecendo um paradigma mais moderno, que gerencia a necessidade de containers e máquinas virtuais de maneira coesa em uma plataforma unificada.

A Red Hat precisa considerar o seguinte: além de oferecer funcionalidades equivalentes, como manter uma experiência semelhante às das soluções e configurações que os clientes já usam, para que a adoção da nova solução seja bem aceita?

Quando as pessoas estão acostumadas a um ecossistema de tecnologia da informação, elas geralmente tentam adaptar princípios familiares aos novos sistemas. Para muitos administradores de sistemas, o VMware vSphere é uma solução comum para a virtualização de data centers. As pessoas que trabalham nesse ambiente introduziram várias soluções de design adotadas como práticas recomendadas para a implantação e configuração de máquinas virtuais ou data centers virtuais. Muitas vezes, essas convenções parecem intuitivas para os profissionais de TI, e eles provavelmente tentariam aplicar práticas semelhantes a outros ambientes que estejam desenvolvendo.

Nesta série de posts no blog, analisaremos como as empresas e os administradores de virtualização interagiam com os ambientes de hipervisor anteriores e como executar tarefas ou configurações semelhantes no OpenShift Virtualization.

Primeiro, concentre-se no design de várias redes, comumente encontrado em outras soluções de virtualização, como o VMware vSphere. Quem conhece o ambiente sabe que os hosts ESXi geralmente aceitam várias redes, e cada rede virtual é dedicada a uma finalidade distinta no data center virtual. A segregação das redes pode ser realizada de várias maneiras, como cabear diferentes NICs físicas nos hosts para diferentes switches ou redes upstream. Outra opção é vincular VLANs adicionais em um uplink e verificar se elas estão marcadas adequadamente no vSwitch ou no vSwitch distribuído no próprio hipervisor, indicando a finalidade desejada. Geralmente, a rede é subdividida da seguinte maneira:

1. Uma rede de gerenciamento para os hosts ESXi e a máquina virtual vCenter, bem como outros hosts de gerenciamento de terceiros que sejam implantados.
2. Uma rede de migração de hosts, que permite a migração a quente de guests entre hosts ESXi, conhecida como vMotion, para fornecer alta disponibilidade.
3. Uma rede de armazenamento de hosts, para os hosts ESXi acessarem recursos de armazenamento de backup ou armazenamento mapeado para guests das máquinas virtuais.
4. Uma rede de máquinas virtuais que fornece conectividade de rede aos guests virtuais.

Além das redes listadas acima, é comum encontrar configurações e finalidades exclusivas, dependendo dos casos de uso do ambiente específico do cliente. O switching virtual, por natureza, permite implementar com facilidade um grande número de configurações variadas. Não é surpresa que as pessoas acostumadas a definir redes do modo usual se surpreendam ao decidir adotar uma solução como o OpenShift Virtualization, que atua de outra maneira.

As seções a seguir analisam os principais casos de uso identificados acima e demonstram como o OpenShift Virtualization atende a essas necessidades.

Por padrão, o OpenShift Virtualization é instalado com uma única rede de pod interna. Como ocorre com outras aplicações implantadas em um ambiente Kubernetes, a rede interna é usada para se comunicar com o próprio pod durante seu ciclo de vida. Usando o console do OpenShift, o utilitário da interface de linha de comando (CLI) virtctl ou o comando oc, você pode executar todas as funções essenciais de gerenciamento dos guests virtuais na rede da API interna. Em resumo, a rede do OpenShift Virtualization realiza as mesmas ações que um administrador esperaria da rede de gerenciamento interna do VMware vSphere.

Todas as funções de rede em um ambiente do OpenShift podem ser realizadas na rede padrão do pod. No entanto, para ter uma configuração simples, isso geralmente não é desejável, assim como acontece com as funções de gerenciamento detalhadas acima. Para algumas tarefas, como migrações de guests virtuais e acesso ao armazenamento, é bastante vantajoso ter acesso direto a redes dedicadas. Há maneiras de ajustar o desempenho de determinadas ações, como as migrações de guests, com políticas de migração para limitar a largura de banda usada. No entanto, para a maioria dos usuários corporativos, ter redes dedicadas para funções adicionais (como migrações de guests, armazenamento e acesso a guests virtuais) é desejável e mais familiar para quem já trabalhou com um ambiente do VMware vSphere.

Para isso, o OpenShift usa o plugin Multus CNI, que configura interfaces de rede, dispositivos SR-IOV ou bridges Linux adicionais disponíveis para os nós de trabalho, permitindo que sejam anexados a pods individuais conforme necessário.

Antes de instalar o Multus, o cliente deve configurar a rede subjacente de forma adequada. No caso de bridges Linux, isso é feito usando o operador nmstate. Para dispositivos SR-IOV, use o operador SR-IOV. Com o ambiente de rede configurado, o administrador pode começar a configurar uma definição de apêndice de rede, que instrui o OpenShift sobre como usar as interfaces físicas, dispositivos SR-IOV ou bridges Linux adicionais.

Em seguida, veja mais detalhes sobre a configuração de migrações ao vivo. Devido às demandas de largura de banda da migração ao vivo, muitas implantações do VMware vSphere têm uma rede dedicada para oferecer suporte ao vMotion. Quando o evento ocorre em uma infraestrutura sem uma rede dedicada à migração ao vivo, ele pode afetar negativamente os recursos de rede compartilhados, como os guests virtuais. Isso também afeta o gerenciamento do ambiente, quando um nó fica indisponível e vários guests são forçados a migrar simultaneamente. No OpenShift Virtualization, várias opções protegem os eventos de migração ao vivo de afetar negativamente a rede primária ou o desempenho do cluster.

A primeira opção é definir uma política de migração que inclua regras como, por exemplo, limitar a largura de banda disponível para as migrações. Também é possível definir uma rede dedicada para as migrações ao vivo modificando as configurações de cluster nas definições da visão geral do OpenShift Virtualization. Nesse menu, você pode limitar o número de migrações ao vivo simultâneas, preservando a largura de banda. Também é possível modificar a rede usada para as migrações.

Para fazer isso, crie uma definição de apêndice de rede para uma interface de rede dedicada nos nós de trabalho, defina uma rede privada que permita a conectividade apenas entre os nós de trabalho configurados para oferecer suporte à virtualização e selecione-a. Dessa forma, ao selecionar um guest para migração ou colocar um host em manutenção, forçando a liberação de todos os guests, a rede dedicada às migrações ao vivo é usada. Isso evita uma carga adicional na infraestrutura de rede primária do OpenShift.

A rede de recursos de armazenamento dependerá do provedor usado para o cluster do OpenShift. Muitos provedores de armazenamento têm sistemas com drivers nativos em conformidade com CSI, que aplicam automaticamente as práticas recomendadas especificadas para a conectividade do armazenamento.

Da perspectiva do OpenShift Virtualization, há algumas práticas recomendadas para configurar as classes de armazenamento para oferecer suporte a guests virtuais. Por exemplo, volumes persistentes provisionados para VMs devem estar no modo RWX, permitindo que nós adicionais acessem o volume persistente caso o guest virtual precise ser migrado para outro nó. Assim como na migração, os nós de trabalho podem ser configurados para acessar o armazenamento pela rede de gerenciamento padrão ou ter uma rede separada anexada para fornecer conectividade para volumes persistentes baseados em NFS ou iSCSI. Em muitos casos, o gerenciamento ou a rede padrão do pod no OpenShift serão encarregados de inicializar as chamadas da API para o sistema de armazenamento indicado. O driver de CSI verifica se o volume provisionado está mapeado corretamente na rede de armazenamento disponível.

Por fim, considere o acesso público às aplicações em execução na VM ou à máquina virtual diretamente. Para os usuários que ainda não estão prontos para colocar suas aplicações em containers, é possível tratar as aplicações em execução nas máquinas virtuais como aquelas executadas junto a elas nos containers. Para fazer isso, aplique uma tag à máquina virtual identificando a aplicação a qual você deseja fornecer acesso. Usando a tag de identificação, crie um serviço do Kubernetes para as portas que a aplicação na máquina virtual pode precisar. É possível expor o serviço criando uma rota do OpenShift e permitindo o acesso diretamente à aplicação, em vez de ao guest virtual como um todo, pela rede padrão do pod do OpenShift, exatamente como uma aplicação em container.

Essa maneira de acessar o guest virtual é uma etapa de transição entre a virtualização e a conteinerização de aplicações. Para quem deseja uma abordagem mais tradicional, com acesso direto ao sistema operacional guest de uma máquina virtual, crie uma definição de apêndice de rede e vincule a uma bridge Linux ou dispositivo SR-IOV disponível em cada nó de trabalho habilitado para hospedagem de guests virtuais. Isso confirma que o guest virtual recebe um IP externo atribuído a ele e que os usuários podem se conectar diretamente ao guest usando SSH ou o protocolo de acesso remoto desejado.

Ao conectar redes adicionais a guests virtuais, observe que a bridge Linux, as interfaces físicas e as tags VLAN precisam ser definidas de forma idêntica e estar disponíveis em cada nó de trabalho no cluster a fim de garantir a alta disponibilidade das máquinas virtuais guest caso elas precisem migrar para um nó diferente no cluster.

Uma maneira de ajudar os clientes a ter uma experiência tranquila é identificar formas de configurar a arquitetura de rede da solução implantada no OpenShift Virtualization para oferecer desempenho e comportamento semelhantes a outros ambientes de hipervisor conhecidos, como o VMware vSphere. Na Red Hat, acreditamos que as experiências positivas aumentam a satisfação do cliente  e a adoção das soluções, o que, por sua vez, facilita a modernização das aplicações.

Para saber mais sobre a modernização de aplicações e como o OpenShift Virtualization pode ajudar, participe de um dos nossos próximos eventos ao vivo, como o Red Hat Summit Connect ou o OpenShift Virtualization Road Show. Vamos apresentar uma visão geral da solução e um laboratório hands-on dedicado ao OpenShift Virtualization.