Hiperconvergência com Proxmox e CEPH - Uma alternativa ao VMWare

Hemily Alves
29 de ago. de 2024
11 min de leitura

Nos últimos tempos muito tem se falado da incorporação da VMWare pela Broadcom e em como isto afetou o mercado, principalmente pela política comercial da nova dona da VMware e por seus preços altos, sobretudo para provedores de serviços. Pois bem, aqui vos entrego uma excelente alternativa ao VMWare, funcional, performática, escalável e Hiperconvergente.

Lei sobre o caso da Broadcom/VMware clicando aqui.

Desde o inicio da computação buscamos constantemente três coisas: Poder computacional para poder rodar cada vez mais coisas e mais rápido; Alta disponibilidade dos sistemas; E integridade dos dados.

Sair da computação tradicional para a virtualização foi um grande salto, mas ainda faltava algo mais. Com o passar do tempo através dos clusters de virtualização alcançamos a Alta Disponibilidade (HA), só que ainda tínhamos um ponto de falha, o armazenamento, assim surgiu a Hiperconvergência.

Em um cluster convencional de virtualização temos 3 grandes pilares: Computação, Armazenamento e Rede. A Hiperconvergência pode ter diversas características, a depender da pessoa com quem você fala, mas a abstração destes três pontos é característica unânime para este tipo de infraestrutura. Apenas deixando claro que a abstração total da camada de rede não é algo determinante para a hiperconvergência.

Pois bem, hoje você vai aprender a implantar uma infraestrutura hiperconvergente utilizando Proxmox como virtualizador e CEPH como sistema de armazenamento distribuído, dispensando a necessidade de um Storage.

Antes, entenda brevemente como o CEPH funciona:

OSD: O CEPH utiliza os discos/SSDs conectados aos servidores, ou como falamos popularmente, na barriga do servidor, criando um OSD (Object Storage Daemon) para cada disco. Os OSDs armazenam e replicam os dados armazenados neles para outros OSDs no cluster, obedecendo a regra de replicação configurada.

Monitor: É responsável por manter um mapa atualizado da cluster CEPH, incluindo a localização dos dados, a configuração dos OSDs, e informações sobre o estado dos nós de armazenamento, resumindo, eles garantem a consistência e o quorum, o que significa que a maioria dos monitores deve concordar sobre o estado atual do sistema para garantir a integridade dos dados. Geralmente atribuímos a função de monitor a toos os nós do cluster.

Manager: Os Managers (MGRs) desempenham um papel crucial na coleta de métricas, monitoramento de desempenho e execução de serviços adicionais que suportam a operação e administração do cluster. Eles complementam os Monitores (MONs) fornecendo informações detalhadas de status e são responsáveis por funcionalidades adicionais que não são críticas para a operação básica do cluster.

Além destas existem algumas outras funções que podem e eventualmente são atribuídas aos nós do cluster, mas focaremos nestas três que serão as utilizadas aqui hoje.

Antes de começarmos, gostaria de esclarecer que apesar de ser possível subir um ambiente de produção completamente funcional com as instruções que passarei aqui, a segurança e operacionabilidade deste ambiente demandará de muita experiência com ambientes de data center, virtualização, redes, sistemas operacionais Linux e lógica aplicada. Portanto, utilize estas instruções apenas para fins de estudo.

Sem mais delongas, vamos ao trabalho!

Para começarmos, você precisará de:

Virtualizador: VirtualBox, VMWare Workstation (utilizei este) ou o que preferir;
Imagem de instalação do proxmox que pode ser obtida clicando aqui;
Notebook ou computador/servidor com pelo menos 40 GB de Memória RAM e 1 TB de armazenamento.

Na internet você encontra diversos artigos que ensinam a baixar e instalar o VMWare Workstation PRO no Linux e Windows, não vou focar nisso.

Fazendo LAB com VMWare Workstation PRO ou Virtualbox:

Crie pelo menos 3 VMs (fiz com 4) de 8 GB de RAM e 4 núcleos de CPU cada;
Em cada VM você vai plugar 11 discos virtuais dinamicamente alocados (aqueles que crescem conforme os dados gravados neles) de 1 TB cada, 1 disco simulando o RAID 1 (espelhamento) do Sistema Operacional e 10 discos para o CEPH;
Conecte 4 placas de rede virtuais, sendo: Duas em modo bridge, acesso da interface de gerência Proxmox e conectividade das VMs; Uma para a rede Pública do CEPH, através da qual os servidores leem e escrevem dados no CEPH; E a última para a rede privada do CEPH, através da qual é realizada a replicação dos dados e comunicação dos componentes do CEPH.

Observação: As duas placas de rede dedicadas ao CEPH podem ser criadas no modo internal-network, LAN Segment ou algo similar, que seria o mais próximo de uma vLan que você terá em virtualizadores como os mencionados. Separadas em duas internal-networks/Lan Segments distintas.

Minhas VMs do LAB ficaram assim:

Fazendo LAB (ou produção) com servidor físico:

Você criará um Raid 1 (espelhamento) para o sistema operacional;

Discos/SSDs do armazenamento/CEPH apresentados diretamente ao Sistema Operacional ou em modo passthrough;

Duas ou quatro placas de rede SFP+ 10 Gb/s que com a seguinte configuração: Link Aggregation 1 (ao menos uma porta de cada placa de rede) destinado às vLANs de gerência e das VMs; Link Aggregation 2 (ao menos uma porta de cada placa de rede) destinado à rede pública do CEPH; Link Aggregation 3 (ao menos uma porta de cada placa de rede) destinado à rede privada/cluster do CEPH;

O Link Aggregation 1 deve ser configurado em modo Trunk no switch, com isto poderão passar nele todas as vLans destinadas à comunicação das VMs.

Observação: Esta informação vale tanto para LAB quanto produção, CEPH NÃO FOI FEITO PARA TRABALHAR COM RAID. Já trabalhei com CEPH em produção utilizando raid 0 (striping), pois a controladora instalada nos servidores não possuía o modo passthrough, que permite a apresentação direta dos discos ao Sistema Operacional, desta forma criamos um raid 0 para cada disco (isto mesmo, um disco só por raid 0) e apresentamos estes volumes raid ao CEPH, mas esta é uma abordagem não convencional e não recomendada.

ETAPA 1 - Instalação dos nodes Proxmox

Seleciona esta opção para iniciar a instalação:

Aceite o contrato de Licença:

Selecione o disco/SSD ou volume raid 1 destinado à instalação do Sistema Operacional:

Selecione time-zone, país e teclado:

Defina sua senha e o e-mail a ser utilizado pelo Proxmox:

Seleciona o Link Aggregation ou placa de rede virtual destinado ao acesso à interface de gerência do ProxMox, defina o hostname e configurações de IP. Aqui vale uma observação, se sua instalação é em ambiente físico com vlans, uma forma de facilitar este primeiro acesso até que você possa configurar as vLans e bridges na interface do proxmox é deixar inicialmente o LAGG de gerência em modo access:

Marque a caixa para que o servidor seja reiniciado automaticamente após a instalação:

Aguarde até que o processo de instalação seja finalizado:

Após a instalação concluir, ao acessar a interface proxmox esta é a tela que você verá

Configuração de rede em servidor físico com vLans

Crie uma bond em modo LACP (layer2+3) escolhendo como slave as interfaces destinadas ao Link Aggregation 1, como o exemplo abaixo (para o bound CEPH utilize MTU de 9000 ou 9014:

Crie uma Linux vLAN, conforme abaixo. Obs: se no nome você digitar "bondX.vlan", automaticamente os campos vLAN RAW device e vLAN Tag são preenchidos:

Após criar a Bond e as vLANS a ela associadas, basta criar uma bridge para cada vLAN, conforme abaixo:

Esta bridge que é o resultado final de cada configuração de vLAN que será selecionada para que a Máquina Virtual trabalhe na vLAN desejada. Na bridge não se aplica endereço IP, os campos devem ficar em branco.

Lembra da vLAN destinada à gestão do Proxmox que recomendei colocar em access no começo da explicação? Agora você pode criar ela também, mas diferente das demais, para a bridge dela você atribuirá endereço IP e demais configurações de gateway, etc.

Já os bond/LAGG destinados ao CEPH, podem ser deixados em modo access, pois irão lidar com apenas uma vLAN cada. Para eles não há necessidade de criar bridge.

Agora vamos à configuração de rede no Ambiente de LAB virtual

Nomeie a primeira interface virtual como MGMT_Slave, pois ela será utilizada para criar a bridge da gerência do Proxmox:

Faça o mesmo para a interface que será utilizada para a bridge que as VMs utilização para se comunicar com a rede local:

Configure a interface para a rede pública do CEPH:

Configure a interface para a rede privada do CEPH:

Configure a Bridge que será utilizada pelas VMs e selecione a interface slave sob a qual ela será criada:

Isto feito, aplique as configurações criadas, se tudo correr bem você não perderá o acesso ao seu Proxmox:

Configurando os repositórios e Atualizando o Proxmox

Na tela de configurações de repositório, CEPH enterprise e PVE enterprise e clique em disable, eles só são úteis quando você assina a subscrição de suporte da ProxMox:

Adicione o repositório gratuito do Proxmox:

Adicione o repositório gratuito do CEPH Reef (versão mais atual neste momento):

Conecte por SSH no host proxmox e rode o comando abaixo para carregar o cache dos repositórios:

Aplique todas as atualizações disponíveis com o comando abaixo e confirme digitando Y e enter após finalizar isto em todos os nodes, reinicie-os:

Repita as etapas acima em cada um dos nodes Proxmox.

Agora vamos criar o cluster Proxmox

Em um dos servidores configurados, clique em Datacenter > Cluster > Create Cluster, defina um nome para seu cluster e selecione a interface de rede que você utiliza para acessar o Proxmox, isto fará com que o cluster utilize esta interface para comunicação entre os nodes e também para transferir VMs, etc:

Quando você ver esta tela, a configuração do cluster foi finalizada:

Agora a tela de cluster aparece desta forma, mas com apenas um servidor:

Incluindo demais nodes no cluster

Na tela em que você está, clique em Join Information > Copy Information:

Nos nodes a serem incluídos no cluster, acesse via interface web > Datacenter > Cluster > Join Information:

Ao colar as informações a tela muda, neste momento é só digitar a senha, selecionar a mesma rede selecionada no node anterior ao criar o cluster e clicar em Join "Seu-Cluster":

Ao fazer isto, você verá uma janela de progresso que normalmente dá erro, a menos que a página seja atualizada, mas eu costumo acessar o primeiro servidor que foi configurado e verificar se esta máquina já está verde e na lista de nodes do cluster:

Caso você veja a máquina verde no cluster significa que a configuração foi concluída e você só precisa atualizar a página da máquina recém adicionada ao cluster:

Após atualizar você verá que a máquina recém adicionada já se reconhece como membro do cluster e também reconhece os demais membros, no caso, apenas a máquina 01 até o momento:

Repita o processo até que todas as suas máquinas sejam configuradas no cluster:

Configuração do Cluster CEPH (Armazenamento Distribuído)

Na primeira máquina do cluster (ou qualquer outra), clique em "Nome do node" > Ceph > Install CEPH:

Selecione a versão mais atual do CEPH e o repositório:

Confirme digitando Y e enter:

Quando ver esta mensagem, avance:

Nesta tela selecione a rede pública do CEPH, a rede Privada/Cluster, quantidade de réplicas e quantidade mínima de replicas dos dados no CEPH. Vale observar que quanto mais réplicas, mais segurança, entretanto, menos área disponível para armazenamento. Você precisará encontrar o número ideal para o seu ambiente:

Entenda mais sobre replicas do CEPH clicando aqui.

A partir daqui vamos apenas instalar o CEPH nos demais nodes, mas a configuração será replicada deste node atual para eles automaticamente:

Instalando no node 02 (para instalar o CEPH no node 02 e demais nodes, acesse o console de cada um diretamente no navegador, não faça via console do primeiro node ou qualquer outro):

Siga esta etapa conforme feito no primeiro node:

Aqui também:

Siga em frente:

Aqui a coisa muda, não é mais necessário realizar configuração. Lembra? A configuração feita no primeiro node é replicada aos demais:

É só finalizar e repetir nos demais servidores, lembrando de acessar cada um individualmente via navegador:

Uma vez instalado o CEPH em todos os nodes, abra qualquer um deles via navegador, clique no node > CEPH > Monitor > Create > Crie um monitor para cada node do cluster (um por vez), com exceção do primeiro node, que ao instalar o CEPH já recebe um monitor:

Ficará assim:

Repita o processo na sessão "Manager":

Chegou a parte que nos dará um pouco de trabalho, pode ser automatizada via shell script, mas aqui o foco é aprender a criar manualmente, então, bora lá!

Obs: esta etapa tem que ser feita node por node. Você abre um deles no navegador e realiza o processo, ao finalizar, continua no console do mesmo node no navegador,mas clica no próximo node no menu lateral esquerdo (onde aparecem os nodes).

Clique no primeiro node > CEPH > OSD > Create OSD > Selecione o disco/SSD a ser utilizado para criar este OSD:

Selecione o tipo desta unidade de armazenamento (HDD, SSD ou NVMe):

Clique em criar:

Após finalizar a criação pode clicar em Reload na tela dos OSDs que seu novo OSD aparecerá e já será colocado online no cluster:

Repita o processo para todos os discos/SSDs disponíveis na tela de criação de OSDs:

Ao finalizar, repita o processo nos demais nodes, lembrando sempre de clicar no próximo nodes no menu lateral esquerdo:

Ao finalizar você verá os OSDs de todos os nodes:

OSDs criados, agora precisamos criar o Pool de armazenamento que receberá os dados das VMs.

Clique em qualquer um dos nodes no menu lateral esquerdo > CEPH > Pools > Create, aqui você dará um nome ao seu Pool, a configuração ideal para seu pool vai depender muito do seu ambiente, não existe receita de bolo. Para entender melhor as opções, veja a documentação clicando aqui:

Uma vez que seu pool é criado ele aparece como um storage RBD mapeado em todos os nodes do cluster. Para saber mais sobre volumes RBD, clique aqui:

Antes que eu esqueça, o CEPH se baseia no timestamp dos dados para saber se a cópia é atual ou defasada, inclusive já tive problemas em clusters de produção por conta de relógio fora de sincronia. Para evitar isto vamos instalar o chrony para atuar como NTP client em todos os nodes do cluster.

Instale o chrony:

Configure um pool NTP para ele no arquivo: /etc/chrony/chrony.conf

Reinicie o serviço com o comando:

Monitore se o relógio sincronizou com o comando:

Obs: pode ser a que sincronização demore alguns minutos, não grave nada no CEPH até que ela finalize.

Após isto o cluster ceph estará ok

Você também pode verificar o status da saúde do cluster CEPH via CLI:

Nesta ponto seu cluster Proxmox com CEPH já está pronto e funcional, mas se você perder um node, ainda precisará migrar manualmente as VMs que rodavam nele para outros nodes. Vamos resolver isto!

Alta Disponibilidade e vMotion

Após as configuração do cluster, suba uma VM de testes:

Importante armazenar esta VM no Pool/RBD criado:

Com a VM ligada, vamos migrá-la:

Selecione o node destino:

Quando visualizar esta mensagem significa que sua VM foi migrada com sucesso para o node escolhido. Obs: Live migration (sem desligar a VM):

Obs: Durante as migrações a VM pode sofrer uma pequena pause de cerca de 1 segundo, sem comprometê-la ou corromper seus dados.

Mas ainda assim, se um node cair, você precisará realizar a migração das VMs de forma manual. Então vamos automatizar isto!

Clique no Datacenter > HA > Groups > Crie um HA Group:

Vamos entender os campos:

ID: nome do grupo de HA;
Restricted: Imagine que seu cluster tem oito nodes e você criou dois grupos de HA com quatro nodes cada. Se a sua VM fizer parte do primeiro grupo e ele estiver com esta configuração ativada, caso todos os nodes deste grupo falhem, ela não será levantada no grupo restante;
NoFailBack: Impede que em caso de retorno de um node que estava em falha, as VMs que estavam nele retornem automaticamente, visto que se for uma falha intermitente no node pode atrapalhar a utilização das VMs;
Priority: Define a prioridade que cada node tem para receber as VMs do grupo.

Adicionar a VM ao HA

Clique em Datacenter > HA > ADD selecione a VM e demais campos conforme indicado abaixo e clique em ADD:

Para consultar a documentação sobre as opções desta tela leia isto.

HA configurado e VM adicionada:

Um último ajuste para garantir que as VMs sejam migradas e iniciadas em caso de falha do node:

Em Datacenter clique em Options > HA Settiong > Migrate:

Para testar vamos desligar o servidor onde a VM está rodando (faça isto conectando via navegador em outro servidor):

Como pode ver na imagem abaixo, ao desligar o servidor a VM que rodava nele levou 5 segundos para ser migrada para outro node e foi migrada à quente, sem desligar:

Finalmente concluímos a implantação e você pode estudar e praticar.

Aqui vale uma observação:

A maioria das pessoas confunde HA com Fault Tolerance. No HA garantimos a disponibilidade do recurso computacional mesmo em caso de falha de um dos nodes, entretanto, nem sempre a VM se mantém ligada.

Para realizar o vMotion entre nodes, os blocos de memória RAM da VM precisam ser migrados do node atual para o novo node, da mesma forma os processos também precisam ser migrados, mas como fazer isso em um desligamento abrupto? Não tem como! Neste caso a VM será reiniciada em um novo node.

Entretanto, ao clicar em desligar um node, o serviço do HA garantirá que o node se mantenha ligado até que a migração seja finalizada.

Agora se você precisa de Fault Tolerance, isto pode ser feito no ambiente que criamos, mas duplicará o consumo de recursos para as VMs que contarem com esta proteção. Mas isto é assunto para um novo artigo. Espero que tenham gostado e caso tenham dúvidas, me chamem no chat!

Um grande abraço!

Autor: Guilherme Campos