Infraestrutura de Redes

• Implantação da Rede Pernambucana de Ensino e Pesquisa (RePEPE)
• Certificação Digital ICPEdu (SSL) no Servidor Linux
• Introdução
• 1. Conceitos e ferramentas utilizadas
• 2. Geração da requisição de certificado
• 3. Envio a requisição de certificado para a Reitoria
• 4. Hierarquia da certificação e download dos arquivos do certificado digital
• 5. Exemplo da instalação da certificação no servidor web Apache
• Instalação do certificado SSL
• Instalação de um cluster de virtualização Proxmox Hiperconvergente
• 1. Instalação do Proxmox
• 2. Configuração das redes
• 3. Atualização do Proxmox
• 4. Definição do storage local
• 5. Instalação do serviço GlusterFS
• 6. Configuração do GlusterFS na rede de Storage
• 7. Configuração do volume GlusterFS
• 8. Adição de novos servidores ao GlusterFS
• 9. Finalização do Cluster Proxmox

Implantação da Rede Pernambucana de Ensino e Pesquisa (RePEPE)

Objetivo

• Implantação da Rede Pernambucana de Ensino e Pesquisa
• Interiorização da Infraestrutura Óptica em Pernambuco
• Construção de Redes Metropolitanas e Iluminação de Trechos Interurbanos para atendimento de pontos de interesse da RNP e Governo do Estado

Estratégias

• Estabelecimento de parcerias entre RNP e Governo do Estado de Pernambuco
• Estabelecimento de parcerias com provedores para construção conjunta das Redes Metropolitanas
• Estabelecimento de parcerias com provedores para iluminação conjunta de trechos interurbanos
• Estabelecimento de parceria com a Neoenergia Pernambuco, visando redução de OPEX 

Escopo

• Construção de 5 Redes Metropolitanas em: Belo Jardim, Caruaru, Garanhuns, Serra Talhada e Vitória do Santo Antão
• Atendimento de algumas instituições de ensino e pesquisa através de infraestrutura do provedor parceiro
• Iluminação, em DWDM, de rotas interurbanas, contemplando, aproximadamente, mais de 20 municípios
• Rotas com capacidade inicial de 10 Gbps para escoamento de tráfego das redes metropolitanas até o PoP-PE, através da infraestrutura da RePEPE

Topologia Atual

Canal de 10 Gbps com saída para Salgueiro e Belo Jardim

Rotas: Serra Talhada <> Salgueiro (10G) e Serra Talhada <> Belo Jardim (10G)

Certificação Digital ICPEdu (SSL) no Servidor Linux

Procedimento de solicitação e instalação da certificação digital RNP/ICPEdu em um servidor web Apache no ambiente Linux.

Introdução

O serviço ICPedu (Certificado Corporativo da Infraestrutura de Chaves Públicas para Ensino e Pesquisa) oferecido pela RNP (Rede Nacional de Ensino e Pesquisa) provê segurança e confiabilidade no acesso aos serviços de TIC de suas Instituições membro. Através da emissão de certificados digitais do tipo SSL (Secure Socket Layer) o serviço garante autenticidade na comunicação cliente-instituição através da web, fortalecendo a confiança dos usuários, que têm a garantia de estar acessando serviços de uma Instituição idônea.

A solicitação, configuração e administração dos certificados é de responsabilidade da Instituição requerente, que deve, a princípio, gerar uma Requisição de Certificado e uma Chave Privada, para que então a certificação possa ser registrada junto a RNP. A Instituição deve então instalar o certificado validado pela Rede Nacional de Pesquisa em seus servidores. Com isso, os usuários então passarão a acessar os serviços em um ambiente criptografado e certificado.

A Reitoria do Instituto Federal do Sertão Pernambucano atua como intermediadora no registro dos certificados junto a RNP. Logo, os Campi devem solicitar a Reitoria o registro dos seus certificados. Para tanto, esse documento apresenta os passos a serem seguidos.

Mais informações podem ser obtidas na wiki do projeto ICPEdu em https://wiki.rnp.br/display/GI.

1. Conceitos e ferramentas utilizadas

Uma conexão utilizando o protocolo para conexões seguras SSL é sempre iniciada pelo cliente. Quando um usuário solicita a conexão com um site seguro, o navegador web (Firefox, Microsoft Edge, Opera, Chrome, etc.) solicita o envio do Certificado Digital e verifica se:

• O certificado enviado é confiável;
• O certificado é válido;
• O certificado está relacionado com o site que o enviou.

Uma vez que as informações acima tenham sido confirmadas, o navegador envia sua chave pública e as mensagens podem ser trocadas. Uma mensagem que tenha sido criptografada com uma chave pública somente poderá ser decifrada com a sua chave privada (simétrica) correspondente. Analogamente, a mensagem seria uma fechadura que possui duas chaves, umas para trancar (criptografar) e outra para destrancar (decifrar) a porta.

Um servidor web protegido pelo protocolo SSL utiliza o protocolo HTTPS (Hyper Text Transfer Protocol Secure), possuindo uma URL que começa em “https://", onde o S significa “secured” (seguro, protegido).

Os algoritmos de criptografia abaixo utilizam o protocolo SSL:

• DES e DAS - algoritmo de criptografia usado pelo governo americano;
• KEA - usado para a troca de chaves pelo governo americano;
• MD5 – muito usado por desenvolvedores de software para que o usuário tenha certeza que o aplicativo não foi alterado;
• RSA - Algoritmo de chave pública para criptografia e autenticação;
• SHA-1 - também usado pelo governo americano.

A versão 3.0 do SSL exige à autenticação de ambas as partes envolvidas na troca de mensagens. Ou seja, tanto cliente quanto servidor deve fazer autenticação e afirmar que são que dizem ser.

O projeto ICPEdu recomenda a ferramenta OpenSSL para a geração da Requisição de Certificado Digital. Para tanto, este guia utiliza a ferramenta OpenSSL na versão 1.1.1, versão estável presente nos repositórios padrões das distribuições Linux Debian 10 e CentOS 8.

A ferramenta OpenSSL é livre para a implementação de protocolos para Conexões Seguras SSL (Secure Sockets Layer) e Transporte Seguro TLS (Transport Layer Security) de dados em uma rede, possibilitando a criação de certificados, chaves sumarizadas, chaves públicas e privadas e a criptografia de arquivos.

Como os certificados SSL são comumente utilizados em servidores de hospedagem web para proteção de sites corporativos, será exemplificada a instalação final dos certificados digitais em um servidor web Apache versão 2.4 em ambiente Linux Debian 10 e CentOS 8. Essa versão do Apache também está presente nos repositórios padrões de ambas as distribuições.

2. Geração da requisição de certificado

O Certificate Signing Request (CSR) é um arquivo de texto criptografado contendo as informações para a solicitação do Certificado Digital. O CSR contém as informações da Instituição (nome, departamento, cidade, estado, país) e a URL onde o certificado SSL será utilizado (Common Name).

Para obter certificados digitais para os serviços computacionais é necessário:

• Chave Privada RSA 2048 bits;
• Uma requisição de certificado CSR;
• Compatibilidade com SHA-256.

A ferramenta OpenSSL é usada para criar a Chave Privada (arquivo .key) e a Solicitação de Assinatura de Certificado (arquivo .csr). Ambas devem ser geradas conforme os comandos abaixo.

• Geração da chave privada:

openssl genpkey -algorithm RSA -out exemplo.ifsertao-pe.edu.br.key -pkeyopt rsa_keygen_bits:2048

• Geração da requisição de certificado CSR:

openssl req -new -key exemplo.ifsertao-pe.edu.br.key -out exemplo.ifsertao-pe.edu.br.csr

O comando anterior requisitará as informações da Instituição para a Solicitação de Assinatura de Certificado. Os campos devem ser preenchidos conforme o servidor que receberá a certificação, no caso do exemplo abaixo, um servidor web identificado pelo domínio exemplo.ifsertao-pe.edu.br (campo Common Name):

Country name (2 letter code) [xx]: BR
State or province name (full name) []: Pernambuco
Locality name (eg, City) [Default City]: Cidade
Organization Name (eg, company) [Default Company Ltd]: IFSertaoPE
Organizational Unit Name (eg, section) [ ]: Campi
Common Name (eg your name or your server’s hostname) []: exemplo.ifsertao-pe.edu.br
Email Address: []: email.solicitante@ifsertao-pe.edu.br
A challenge password []:
An optional company name []:

Observar o seguinte no preenchimento dos campos anteriores:

• Os seguintes caracteres não são aceitos: < > ~ ! @ # $ % ^ * / \ ( ) ?.,&;
• O campo “Common Name” deve ser o nome completo (o domínio) do serviço cadastrado no DNS, ou seja, a exata URL onde o certificado vai ser utilizado;
• O campo “Organization Name” deve ser o nome oficial da Instituição, igual ao existente no cartão do CNPJ;
• Os campos “A challenge password” e “An optional company name” podem ficar em branco.

O arquivo .csr será gerado, sendo possível conferir os dados informados na requisição utilizando o comando:

openssl req -inform PEM -in exemplo.ifsertao-pe.edu.br.csr -text

É recomendado armazenar os arquivos exemplo.ifsertao-pe.edu.br.key e exemplo.ifsertao-pe.edu.br.csr em um local seguro, mantendo backup deles.

3. Envio a requisição de certificado para a Reitoria

O arquivo exemplo.ifsertao-pe.edu.br.csr gerado na sessão anterior deve ser enviado a Gerencia de Rede da Reitoria, informando o domínio do servidor e a funcionalidade dele. Para tanto, é necessário abrir um chamado na central de serviços do SUAP.

O arquivo exemplo.ifsertao-pe.edu.br.key, também gerado na sessão anterior, não deve ser enviado a Reitoria, devendo ser preservado em local seguro para posterior instalação nos servidores a serem protegidos.

A Reitoria então retornará o arquivo correspondente a certificação final. Dúvidas podem ser tratadas pelo e-mail redes@ifsertao-pe.edu.br.

4. Hierarquia da certificação e download dos arquivos do certificado digital

Como exemplo, para um certificado emitido pelo serviço de AC SSL Corporativa da ICPEdu para o domínio *.rnp.br, a estrutura da cadeia de certificação será:

Neste caso o certificado do domínio *.rnp.br possui:

• Os certificados ICPEdu e Trusted Root CA SHA256 G2 como certificados intermediários;
• O certificado GlobalSign como o certificado raiz da cadeia de certificação.

Com a certificação final recebida da Gerência de Redes da Reitoria, a cadeia de certificados pode ser instalada em definitivo no servidor a ser protegido. Para tanto, é necessário realizar o download dos arquivos da cadeia da certificação, como segue:

• Baixar os certificados Raiz e Intermediário (gs_root.pem e intermediate.pem) disponível no link [link para download].

• Baixar o arquivo enviado pela Gerência de Redes da Reitoria, correspondente ao certificado emitido através da AC SSL Corporativa da ICPEDU, salvando-o com o nome <seudomínio>.crt (seguindo o exemplo deste guia, exemplo.ifsertao-pe.edu.br.crt).

5. Exemplo da instalação da certificação no servidor web Apache

De posse dos 3 arquivos anteriores (gs_root.pem, intermediate.pem e exemplo.ifsertao-pe.edu.br.crt), e da Chave Privada gerada na sessão 2 deste guia (exemplo.ifsertao-pe.edu.br.key), a cadeia de certificados pode ser instalada em definitivo no servidor que fará uso da certificação. No exemplo deste guia, o servidor a ser protegido é um Servidor Web identificado pelo domínio exemplo.ifsertao-pe.edu.br.

A instalação compreende basicamente a cópia dos arquivos para uma pasta específica do servidor, fazendo-se necessário ainda realizar algumas configurações para que os arquivos da certificação sejam localizados pelo serviço web e para que ele possa fazer uso do protocolo SSL através do HTTPS.

Por padrão o diretório /etc/ssl/ é utilizado para armazenar os certificados do servidor. Contudo, este exemplo usa a pasta <pasta_do_apache>/ssl/icpedu/, devendo-se copiar os arquivos anteriores para ela. O CentOS utiliza a pasta /etc/httpd/ como diretório padrão do serviço Apache, enquanto o Debian utiliza /etc/apache2/. Para tanto, os comandos abaixo podem ser utilizados:

mkdir <pasta_do_apache>/ssl/icpedu/
cd <pasta_onde_os_arquivos_foram_baixados>
cp *.pem *.crt *key <pasta_do_apache>/ssl/icpedu/

Por padrão, os arquivos de configuração dos sites do Apache no CentOS ficam em /etc/httpd/conf.d. No Debian, ficam localizados em /etc/apache2/sites-available/. Este exemplo considera que a pasta padrão no CentOS foi alterada para seguir o padrão do Debian, como segue:

• Criação dos diretórios:

mkdir -p /etc/httpd/sites-available
mkdir -p /etc/httpd/sites-enabled

• Edição do arquivo /etc/httpd/conf/httpd.conf para que o Apache enxergue o diretório criado /etc/httpd/sites-enabled, inserindo a seguinte linha no final do arquivo:

IncludeOptional sites-enabled/*.conf

Este exemplo habilita o SSL para o site “Site Exemplo” presente no diretório /var/www/html/siteexemplo/, com seu arquivo de configuração definido no arquivo <pasta_do_apache>/sites-available/siteexemplo.conf e habilitado pelo link correspondente em <pasta_do_apache>/sites-enabled/siteexemplo.conf. Para tanto, os seguintes comandos podem ser utilizados:

mkdir /var/www/html/siteexemplo
touch /var/www/html/siteexemplo/index.html
touch <pasta_do_apache>/sites-available/siteexemplo.conf
ln -s <pasta_do_apache>/sites-available/siteexemplo.conf <pasta_do_apache>/sites-enabled/siteexemplo.conf

Para fazer uso dos certificados, o arquivo <pasta_do_apache>/sites-available/siteexemplo.conf deve ser editado como o exemplo abaixo:

<VirtualHost <server_name>:443>
  
  DocumentRoot “/var/www/html/siteexemplo”
  SSLEngine on
  ServerName <server_name>:443
  
  SSLCACertificateFile <pasta_do_apache>/ssl/icpedu/gs_root.pem
  SSLCertificateChainFile <pasta_do_apache>/ssl/icpedu/intermediate.pem
  SSLCertificateFile <pasta_do_apache>/ssl/icpedu/exemplo.ifsertao-pe.edu.br.crt
  SSLCertificateKeyFile <pasta_do_apache>/ssl/icpedu/exemplo.ifsertao-pe.edu.br.key
  
  <Directory “/var/www/html/siteexemplo/”>
    DirectoryIndex index.html
    Options FollowSymLinks
    AllowOverride All
    Require all granted
  <Directory>

</VirtualHost>

Antes de testar o acesso, deve-se verificar se a porta HTTPS (443) está liberada no Firewall, caso o servidor faça uso de um. Pode ser necessário ainda habilitar o módulo SSL no servidor:

• No CentOS:

yum install mod_ssl

• No Debian:

a2enmod ssl

Para finalizar a instalação deve-se reiniciar os serviços com um dos comandos:

systemctl restart httpd
apache2ctl restart
shutdown -r now

O acesso HTTPS pode ser testado em um navegador web com a url https://exemplo.ifsertao-pe.edu.br/siteexemplo. A página web “Site Exemplo” deve ser exibida, significando que a conexão está sendo encriptada e que o certificado foi reconhecido pelo navegador devido ao cadeado ao lado da url. A figura abaixo exemplifica o acesso ao site web do domínio *rnp.br protegido por seu certificado digital.

Instalação do certificado SSL

• Consultar no DNS  qual a máquina responsável por redirecionar o serviço (VM própria ou proxy).

Na máquina do serviço a ter o certificado instalado:

• Acessar a pasta /etc/nginx e conferir no diretório conf.d os arquivos de configuração serviço.conf e onde estão localizados os certificados (geralmente /etc/ssl/icpedu);
• Acessar o diretório dos certificados e mover os agora expirados para uma pasta de "antigos":

sudo mv serviço.ifsertao* antigos/

• Criar arquivos CSR, KEY, CRT para cada nome de domínio (ex.: ifsertao-pe e ifsertaope):
  • CSR e KEY:
    
    • utilizar script  ./gerar_csr.sh para criar a requisição (.csr) e a chave (.key);
  • CRT:
    • emitir certificado no site da Global Sign e criar arquivo serviço.crt contendo o conteúdo do certificado.

NGINX:

• Criar arquivo serviço.pem concatenando três arquivos (para cada nome de domínio):
  • serviço.crt
  • root (gs_root.pem)
  • intermediate.pem

cat serviço.crt intermediate.pem gs_root.pem > serviço.pem
caso retorne "Permissão negada":
sudo bash -c "cat serviço.crt intermediate.pem gs_root.pem > serviço.pem" 

• Testar arquivos de configuração em uso pelo NGINX:

nginx -t

• Reiniciar serviço do NGINX e verificar status:

systemctl restart nginx

systemctl status nginx

APACHE

• O apache utiliza de forma separadadois arquivos criados no processo (a chave .key e o certificado .crt).
• Testar arquivos de configuração em uso pelo Apache:

apachectl configtest

• Reiniciar serviço do Apache e verificar status:

systemctl restart httpd (apache)

systemctl status httpd (apache)

• Acessar página do serviço pelo navegador e verificar a validade do certificado.

Instalação de um cluster de virtualização Proxmox Hiperconvergente

Este manual contempla a instalação de um ambiente de virtualização hiperconvergente utilizando o hipervisor Proxmox com o sistema de arquivos distribuído GlusterFS. A solução foi definida em um Cluster com 3 servidores físicos utilizando Storage Local em cada um para o armazenamento das Máquinas Virtuais. O serviço GlusterFS garantirá a hiperconvergência ao realizar o espelhamento das VMs em todos os servidores do Cluster.

1. Instalação do Proxmox

O hipervisor Proxmox e o serviço GlusterFS deve ser instalado nos 3 Servidores (ou Hosts) que farão parte do Cluster Hiperconvergente. Contudo, há a possibilidade de se instalar todos eles e configurar o Cluster simultaneamente ou instalar somente um Servidor para que os outros 2 sejam instalados e adicionados no Cluster futuramente. A implementação do Cluster em si é realizada somente no tópico 7 deste manual, abrangendo ambos os casos.

O primeiro caso é interessante quando os 3 Servidores estão "zerados" e podem ser formatados sem problemas, enquanto o segundo é interessante quando a Unidade não pode formatar os Hosts ao mesmo tempo por já ter um ambiente de virtualização em produção, devendo então instalar o Proxmox em um Server a parte, migrar as Máquinas Virtuais para ele, e montar o Cluster posteriormente. O Campus deve seguir esse manual de acordo com um desses dois cenários.

Antes da instalação do Proxmox nos Servidores é necessário que:

• Os discos estejam configurados em RAID 5 ou RAID 0;
• Os Servidores tenham 4 interfaces de rede, sendo que a primeira, a segunda e a terceira estejam conectadas a uma porta do tipo Trunk no Switch e a quarta esteja em uma porta do tipo Access no Switch na vlan de Storage.

Já na instalação, a definição dos nomes dos Hosts deve seguir o padrão:

• host <NUMERO_DO_HOST> . <NOME_DO_CAMPUS> . ifsertao-pe.edu.br

Considerando a instalação na Reitoria como exemplo:

• host1.reitoria.ifsertao-pe.edu.br (para o primeiro Servidor do Cluster)
• host2.reitoria.ifsertao-pe.edu.br (para o segundo Servidor do Cluster)
• host3.reitoria.ifsertao-pe.edu.br (para o terceiro Servidor do Cluster)

O IP de gerenciamento dos Hosts deve esta na vlan Virtualização (rede 192.168.100.0/24 como exemplo):

• 192.168.100.101/24 (para o primeiro Servidor do Cluster)
• 192.168.100.102/24 (para o segundo Servidor do Cluster)
• 192.168.100.103/24 (para o terceiro Servidor do Cluster)

E o IP para o tráfego das VMs deve ficar na vlan de Storage (rede 192.168.200.0/24 como exemplo):

• 192.168.200.101/24 (para o primeiro Servidor do Cluster)
• 192.168.200.102/24 (para o segundo Servidor do Cluster)
• 192.168.200.103/24 (para o terceiro Servidor do Cluster)

Dadas as considerações iniciais, as telas seguintes descrevem a instalação inicial do Proxmox.

Na tela inicial da instalação do Proxmox clicar em "Install Proxmox VE".

Na segunda tela clicar em "I agree" para aceitar os termos de uso da ferramenta.

Na tela seguinte deve-se selecionar o disco ao qual o Proxmox será instalado, no campo "Target Harddisk". Selecionar o primeiro disco /dev/sda (que é o padrão) e clicar em opções. Na janela que se abre (Harddisk options) configurar conforme o print abaixo, definindo 60GB no campo "hdsize" (o restante do espaço em disco será alocado posteriormente para definição do Storage das Máquinas Virtuais), o campo "maxroot" também com 60GB e o "maxvz" com 0 (zero). Isso fará com que o Proxmox não crie a automaticamente uma partição para o Storage das VMs (ele cria por padrão), pois isso será feito manualmente depois.

Definir a Zona de Tempo e a Localização conforme abaixo.

Inserir a senha de root e um e-mail válido, conforme abaixo.

No passo seguinte inserir as configurações da interface de gerenciamento do servidor. O exemplo abaixo seria o primeiro host da Reitoria:

• O campo "Management Interface" deve constar a primeira interface do host (no exemplo ela foi identificada como enp0s3, mas nos servidores Dell pode ser eno1);
• No campo "Hostname (FQDN)" inserir o nome do Host conforme o padrão acima.
• No campo "IP Address (CIRD)" inseir o IP do host na rede de Virtualização;
• No campo "Gateway" inserir o Gateway do host na rede de Virtualização;
• E no campo "DNS Server" o IP do servidor DNS.

Por fim, na próxima tela revisar as configurações, clicar em "Install" e aguardar a finalização.

2. Configuração das redes

Cada servidor do Cluster Proxmox deve ter um adaptador de rede com 4 portas, logo, as configurações de rede a seguir devem ser aplicadas em todos os servidores que farão parte do Cluster. Considerando isso, foi definido o seguinte:

• A porta 1 para definição das redes DMZs e para a interface de gerenciamento do Proxmox;
• A porta 2 para definição das redes LANs;
• A porta 3 para definição das redes WANs;
• A porta 4 para o tráfego de storage das VMs;

2.1 CONFIGURAÇÃO PARA AS REDES DMZs E PARA O GERENCIAMENTO DO HOST

A configuração da porta 1 deve ser feita diretamente pelo shell do host e não pela interface Web do Proxmox, pois pode-se gerar inconsistência na configuração e perder a conexão com o host, devido a necessidade de se configurar um IP estático para gerenciamento do host na rede de Virtualização e ao mesmo tempo viabilizar o tráfego das demais redes DMZs pela mesma porta. Para isso, foi definido na porta 1 uma bridge para o tráfego de todas as DMZs, e dentro dessa bridge uma vlan na rede de Virtualização para o gerenciamento do host. 

A porta 1 (eno1) no /etc/network/interfaces deve ser configurada da seguinte forma:

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet manual
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids <ID_DMZ_1> <ID_DMZ_2> <ID_DMZ_N>
#DMZs <ID_DMZ_1> <ID_DMZ_2> <ID_DMZ_N>

auto vmbr0.<ID_DMZ_VIRTUALIZACAO>
iface vmbr0.<ID_DMZ_VIRTUALIZACAO> inet static
        address 192.168.100.101/24
        gateway 192.168.100.1
#Gerenciamento do host

Em seguida reiniciar o serviço de rede com:

service networking restart

2.2 CONFIGURAÇÃO PARA AS REDES LANs

A porta 2 (eno2) deve ser configurada somente com uma bridge. Com a interface de gerenciamento configurada, é possível configurar ela e as demais portas pela interface web do Proxmox, contudo, não há opção para setar o parâmetro "bridge-vids" pelo navegador. Esse parâmetro serve para evitar que uma VM da rede DMZ seja configurada acidentalmente na porta de rede do Proxmox dedicada as redes LANs por exemplo, visto que ele restringe as Vlans que podem passar pela porta.

A configuração da porta 2 (eno2) no /etc/network/interfaces deve ficar da seguinte forma:

iface eno2 inet manual

auto vmbr1
iface vmbr1 inet manual
        bridge-ports eno2
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids <ID_LAN_1> <ID_LAN_2> <ID_LAN_N>
#LANs <ID_LAN_1> <ID_LAN_2> <ID_LAN_N>

2.3 CONFIGURAÇÃO PARA AS REDES WANs

A configuração da porta 3 (eno3) deve ficar da seguinte forma no /etc/network/interfaces. Caso o Campus possua 2 links de internet, deve-se colocar sua Vlan correspondente no parâmetro "bridge-vids":

iface eno3 inet manual

auto vmbr2
iface vmbr2 inet manual
        bridge-ports eno3
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids <ID_WAN_1> <ID_WAN_2> <ID_WAN_N>
#WANs <ID_WAN_1> <ID_WAN_2> <ID_WAN_N>

2.4 CONFIGURAÇÃO DA REDE DE STORAGE

auto eno4
iface eno4 inet static
        address 192.168.200.101/24
#Storage

Com todas as redes configuradas, deve-se reiniciar o serviço de rede com:

service networking restart

2.5 CONFIGURAÇÃO DO /etc/hosts

O arquivo /etc/hosts deve ser configurado para que a comunicação entre os Servidores ocorram pelo nome e não somente por IP. Como exemplo, o seguinte conteúdo deve ser adicionado nele (lembrando que os IPs abaixo são só exemplos e devem ser ajustados para o IP real do Campus):

192.168.100.101 host1.reitoria.ifsertao-pe.edu.br host1
192.168.100.102 host2.reitoria.ifsertao-pe.edu.br host2
192.168.100.103 host3.reitoria.ifsertao-pe.edu.br host3

192.168.200.101 gluster1.reitoria.ifsertao-pe.edu.br gluster1
192.168.200.102 gluster2.reitoria.ifsertao-pe.edu.br gluster2
192.168.200.103 gluster3.reitoria.ifsertao-pe.edu.br gluster3

3. Atualização do Proxmox

Para atualização do Proxmox deve-se substituir seu repositório da versão Enterprise para a versão No-Subscription. Isso é necessário em todos os servidores que farão parte do Cluster Proxmox. Através da interface web pelo navegador, acessada pelo endereço e porta https://<IP_DO_HOST>:8006, deve-se desabilitar a versão Enterprise do repositório conforme tela a seguir:

Em seguida adicionar o repositório da versão sem subscrição conforme segue:

Por fim, realizar o "Refresh" das bases dos repositórios (update) e realizar a atualização dos pacotes em si (upgrade). Ao executar o upgrade, abrirá uma janela de linha de comando listando os pacotes e pedindo confirmação. Confirmar e aguardar o término. É recomendado reiniciar o servidor depois do processo.

É possível realizar esse procedimento pelo shell também, com os comandos:

# Retira o repositório do Proxmox Enterprise.
sed -i 's/^/#/g' /etc/apt/sources.list.d/pve-enterprise.list

# Insere o repositório da versão sem subscrição.
echo "deb [arch=amd64] http://download.proxmox.com/debian/pve bullseye pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list
wget https://enterprise.proxmox.com/debian/proxmox-release-bullseye.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bullseye.gpg

# Atualiza os pacotes.
apt-get update -y && apt-get upgrade -y

4. Definição do storage local

Início da configuração do Storage para as Máquinas Virtuais. O GlusterFS será configurado em cima de uma partição LVM. Essa partição utilizará parte do espaço em disco não alocado na instalação do Proxmox, que teve só 60GB alocado para o sistema. Os passos seguintes devem ser executados em todos os hosts do Cluster Proxmox através do shell de cada host.

Para o particionamento em si deve executado o comando seguinte: 

cfdisk

Selecionar o espaço livre e criar uma nova partição em "New".

Deve-se definir o tamanho da partição. No exemplo foi definido 2TB de um espaço disponível de 2.4TB. O objetivo disso é deixar um espaço livre para uso futuro, como aumentar a partição / (barra) do sistema caso ela fique cheia com o tempo, por exemplo. Esse espaço pode até ser utilizado para aumentar a própria partição do storage local caso seja necessário no futuro. O Campus pode definir a quantidade desse espaço de acordo com o armazenamento que estiver disponível.

Com a partição criada (/dev/sda4), deve-se definir seu tipo como LVM ainda no cfdisk, conforme telas a seguir:

Por fim, aplicar as configurações  em "Write", confirmar as mudanças com "yes" e sair do cfdisk em "Quit".

Com a partição definida, deve-se formatar ela em uma estrutura LVM do tipo Thin, começando com a criação do disco físico no LVM com o comando:

pvcreate /dev/sda4

Com o disco físico criado,  deve-se criar também o Volume Group (de nome "gfs") e adicionar o Physical Disk (/dev/sda4) ao grupo:

vgcreate gfs /dev/sda4

Os comandos a seguir criam um Volume Lógico do tipo Thin, que é recomendado pela documentação do GlusterFS (o serviço de storage a ser utilizado para o armazenamento das VMs). O primeiro comando cria um Logical Volume de nome "vmstg" com 1GB utilizando o Volume Group criado no comando anterior. O segundo converte o Logical Volume criado para o tipo Thin. O terceiro cria de fato o Logical Volume com 100% do espaço livre do Volume Group "gfs" que contém o Physical Disk /dev/sda4 (os 2TB particionados anteriormente).

lvcreate -L 1GB -n vmstg gfs
lvconvert --type thin-pool gfs/vmstg
lvextend -l 100%FREE gfs/vmstg

Para verificar se tudo ocorreu com sucesso utilizar o comando seguinte:

lvscan

Mostrará o seguinte:

...
ACTIVE '/dev/gfs/vmstg' [<2.00 TiB] inherit
...

Com a partição definida e configurada como LVM, ela deve ser formatada e montada para uso. Para a formação, o comando seguinte deve ser executado:

mkfs.xfs /dev/mapper/gfs-vmstg

Deve-se criar um ponto de montagem para a partição:

mkdir -p /mnt/lv/vmstg

Testar a montagem da partição utilizando a pasta criada como ponto de montagem:

mount -t xfs /dev/mapper/gfs-vmstg /mnt/lv/vmstg

Para verificar se deu certo executar o comando seguinte:

df -h

Mostrará o seguinte resultado:

...
/dev/mapper/gfs-vmstg  2.0T   15G  2.0T   1% /mnt/lv/vmstg

Com o teste da montagem realizado com sucesso, deve-se desmontar a partição com o comando:

umount /mnt/lv/vmstg

Com a montagem da partição testada, é necessário configurar a montagem no boot do sistema, pois ela não será montada automaticamente caso o servidor seja reiniciado. O comando a seguir cria o arquivo responsável pela montagem e disponibiliza-o para edição (pode ser utilizado tanto o vim quando o nano):

vim /etc/systemd/system/vmstg.service

Deve inserir o seguinte conteúdo e salvar em seguida:

[Unit]
Description=Montagem da partição LVM vmstg

[Service]
Type=simple
RemainAfterExit=yes
ExecStart=/etc/init.d/vmstg.sh start
ExecStop=/etc/init.d/vmstg.sh stop
ExecReload=/etc/init.d/vmstg.sh restart

[Install]
WantedBy=multi-user.target

Em seguida deve-se carregar o serviço de montagem criado pelo arquivo anterior no serviço Systemd com o comando:

systemctl daemon-reload

É necessário ainda criar o script que fará a montagem em si (o arquivo /etc/init.d/vmstg.sh utilizado dentro do arquivo anterior). Para isso, deve executar:

vim /etc/init.d/vmstg.sh

E inserir o seguinte conteúdo:

#!/bin/bash

case "$1" in
start)
   mount -t xfs /dev/mapper/gfs-vmstg /mnt/lv/vmstg
   ;;
stop)
   umount /mnt/lv/vmstg
   ;;
restart)
   $0 stop
   $0 start
   ;;
status)
   ;;
*)
   echo "Usage: $0 {start|stop|status|restart}"
esac

exit 0

Como o arquivo trata-se de um script, ele deve ter permissões de execução, atribuídas pelo seguinte comando:

chmod +x /etc/init.d/vmstg.sh

Agora deve-se habilitar a montagem em si no boot do sistema:

systemctl enable vmstg.service

Iniciar o serviço de montagem e verificar seu status:

systemctl start vmstg.service
systemctl status vmstg.service

Deve mostrar o seguinte resultado (active):

vmstg.service - Montagem da partição LVM vmstg
     Loaded: loaded (/etc/systemd/system/vmstg.service; enabled; vendor preset: enabled)
     Active: active (exited) since Thu 2022-12-22 17:41:13 -03; 10min ago
    Process: 1401 ExecStart=/etc/init.d/vmstg.sh start (code=exited, status=0/SUCCESS)
   Main PID: 1401 (code=exited, status=0/SUCCESS)
        CPU: 20ms

Para verificar a partição montada deve-se executar o seguinte comando:

df -h

Mostrará o seguinte resultado:

...
/dev/mapper/gfs-vmstg  2.0T   15G  2.0T   1% /mnt/lv/vmstg

Configuração do particionamento finalizada. É interessante reiniciar o servidor e testar se a montagem ocorreu com sucesso automaticamente no boot do sistema, utilizando os 3 comandos anteriores.

5. Instalação do serviço GlusterFS

O serviço GlusterFS deve ser instalados em todos os Hosts do Cluster Proxmox. Ele será o responsável pela hiperconvergência ao realizar o espelhamento das Máquinas Virtuais entre os Servidores.

A princípio deve-se configurar o repositório da ferramenta. Os comandos seguintes adicionam o repositório do Gluster na versão 10 para o sistema Debian 10 Bullseye (que é o SO base do Proxmox na versão 7):

wget -O - https://download.gluster.org/pub/gluster/glusterfs/10/rsa.pub | apt-key add -
echo deb [arch=amd64] https://download.gluster.org/pub/gluster/glusterfs/10/10.2/Debian/bullseye/amd64/apt/ bullseye main > /etc/apt/sources.list.d/gluster.list

É necessário atualizar os pacotes com os pacotes do repositório adicionado (e aproveitar para atualizar o sistema):

apt-get update -y && apt-get upgrade -y

Agora deve-se instalar o daemon do GlusterFS:

apt-get install glusterfs-server -y

O comando seguinte inicializa os serviços utilizados pelo Gluster:

systemctl start gluster-ta-volume.service
systemctl start glusterd.service
systemctl start glustereventsd.service
systemctl start glusterfssharedstorage.service

Para verificar se o serviço foi iniciado e instalado com sucesso:

systemctl status glusterd.service

Por fim, habilita-se o serviço Gluster no boot do sistema:

systemctl enable glusterd.service

6. Configuração do GlusterFS na rede de Storage

Com o Gluster instalado, é necessário configurá-lo para ele utilizar a rede de storage para a replica das Máquinas Virtuais. Como definido anteriormente, será utilizada a porta 4 do adaptador de rede de cada servidor. Logo, os comandos seguintes devem ser realizados todos os servidores do Cluster Proxmox.

O comando seguinte verifica em qual rede e porta o Gluster está escutando:

ss -atpn | grep glusterd

Mostrará o seguinte:

LISTEN  0  1024  0.0.0.0:24007  0.0.0.0:*  users:(("glusterd",pid=945,fd=11))

Na saída do comando há a informação "0.0.0.0:24007", indicando que o serviço está escutando em qualquer rede pela por 24007.

Para configuração do Gluster na rede de Storage, é necessário editar o arquivo seguinte:

vim /etc/glusterfs/glusterd.vol

Com o arquivo aberto para edição, deve-se procurar a linha "option transport.socket.listen-port 24007" e inserir o seguinte conteúdo abaixo dela. Deve-se adaptar o nome "gluster1.reitoria.ifsertao-pe.edu.br" de acordo com o Campus e com o Host que está sendo configurado:

option transport.rdma.bind-address gluster1.reitoria.ifsertao-pe.edu.br
option transport.socket.bind-address gluster1.reitoria.ifsertao-pe.edu.br
option transport.tcp.bind-address gluster1.reitoria.ifsertao-pe.edu.br

Reiniciar o  Gluster:

systemctl restart glusterd.service

Por fim, deve-se verificar se as configurações foram realizadas com sucesso:

ss -atpn | grep glusterd

Deve mostrar o seguinte:

LISTEN  0  1024  192.168.200.101:24007  0.0.0.0:*  users:(("glusterd",pid=945,fd=11))

Na saída do comando é possível verificar que agora o Gluster está utilizando a rede de Storage com a informação "192.168.200.101:24007".

7. Configuração do volume GlusterFS

Neste ponto o armazenamento local para as Máquinas Virtuais encontra-se definido na partição /dev/sda4 e montado na pasta /mnt/lv/vmstg, e o serviço Gluster instalado, configurado e funcional. Com isso, faz-se necessário definir um Volume Gluster que utilize a partição montada, para que a ferramenta viabilize a hiperconvergência com a replica das VMs entre os servidores.

Caso os 3 Servidores estejam com o Proxmox instalado, configurado, e o serviço Gluster também instalado e configurado, deve-se seguir os passos do tópico seguinte (7.1. CRIAÇÃO DO VOLUME DO TIPO RÉPLICA NOS 3 SERVDIORES). Caso somente 1 Servidor esteja nesse estado, deve-se pular o tópico seguinte e ir para o próximo (7.2. CRIAÇÃO DO VOLUME DO TIPO DISTRIBUÍDO EM 1 SERVIDOR).

7.1. CRIAÇÃO DO VOLUME DO TIPO RÉPLICA NOS 3 SERVIDORES

Neste cenário será criado um Volume Gluster do tipo Replicado simultaneamente nos 3 Servidores, visto que todos eles já possuem o Proxmox com o GlusterFS.

Os comandos seguintes só devem ser executados em um Hosts, sendo que os demais são configurados automaticamente pelo serviço Gluster.

Para verificar a definição atual do serviço Gluster, deve-se executar:

gluster pool list
gluster peer status

Mostrará o seguinte resultado, pois não há nenhum volume definido e os outros servidores ainda não fazem parte do Gluster:

UUID                                    Hostname        State
f65851be-3a13-4e43-9ba3-45a9054c4e5a    localhost       Connected 

Number of Peers: 0

A princípio é necessário adicionar os demais Servers ao pool do Gluster. Considerando que o pool está sendo configurado a partir do host 1, é necessário adicionar os Host 2 e 3 (mais uma vez, adaptar os nomes conforme o Campus):

gluster peer probe gluster2.reitoria.ifsertao-pe.edu.br

gluster peer probe gluster3.reitoria.ifsertao-pe.edu.br

Para conferir se foram adicionados:

gluster pool list
gluster peer status

Mostrará o seguinte resultado:

9e90a572-3d33-458e-a202-f0d9be1054bb  gluster2.reitoria.ifsertao-pe.edu.br  Connected 
06e41fd6-88fd-4c70-afca-e9b5ca80c144  gluster3.reitoria.ifsertao-pe.edu.br  Connected 
989a97bc-3743-48e3-864f-f226369610ce  localhost

Number of Peers: 3

Neste ponto o Volume Gluster pode ser criado. É interessante executar o comando seguinte antes. Ele indicará que nenhum volume foi configurado ainda.

gluster volume info

O comando seguinte cria o Volume GlusterFS, de nome "VMS" do tipo Réplica nos 3 Hosts. Conforme especificado após o nome dos Hosts no comando (depois do ":"), o volume utilizará o diretório /mnt/lv/vmstg onde a partição LVM foi montada anteriormente.

gluster volume create VMS replica 3 gluster1.reitoria.ifsertao-pe.edu.br:/mnt/lv/vmstg/vms gluster2.reitoria.ifsertao-pe.edu.br:/mnt/lv/vmstg/vms gluster3.reitoria.ifsertao-pe.edu.br:/mnt/lv/vmstg/vms

Agora é necessário iniciar o volume criado:

gluster volume start VMS

Para verifica o volume criado:

gluster volume info

Mostrará o seguinte resultado:

Volume Name: VMS
Type: Replicate
Volume ID: 632140b2-528a-40d1-a075-dc460b2ec023
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: gluster1.reitoria.ifsertao-pe.edu.br:/mnt/lv/vmstg/vms
Brick2: gluster2.reitoria.ifsertao-pe.edu.br:/mnt/lv/vmstg/vms
Brick3: gluster3.reitoria.ifsertao-pe.edu.br:/mnt/lv/vmstg/vms
Options Reconfigured:
cluster.granular-entry-heal: on
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off

Na saída é possível observar que o volume de nome "VMS" do tipo "Replicate" foi criado e iniciado e possui com 3 Bricks, indicando que o volume está configurado com os 3 Servidores.

É interessante acessar os outros 2 Servidores e verificar se o volume foi criado neles, executando os comandos de verificação anteriores:

gluster pool list

gluster peer status

gluster volume info

Neste ponto o volume está criado, inicializado, mas ainda não pode ser utilizado. É necessário montá-lo em um ponto de montagem (assim como foi feito na partição LVM anteriormente), executando os comandos seguintes.

Deve-se criar o ponto de montagem nos 3 Hosts do Cluster:

mkdir -p /vms

Deve-se configurar em seguida a montagem automática no boot do sistema, executando o seguinte comando:

No Host 1:

echo "gluster1:VMS /vms glusterfs defaults,_netdev,x-systemd.automount,backupvolfile-server=gluster2,backupvolfile-server=gluster3 0 0" >> /etc/fstab

No Host 2:

echo "gluster2:VMS /vms glusterfs defaults,_netdev,x-systemd.automount,backupvolfile-server=gluster1,backupvolfile-server=gluster3 0 0" >> /etc/fstab

No Host 3:

echo "gluster3:VMS /vms glusterfs defaults,_netdev,x-systemd.automount,backupvolfile-server=gluster1,backupvolfile-server=gluster2 0 0" >> /etc/fstab

Em cada Host executar a montagem em si com:

mount -a

E verificar se montou com sucesso:

df -h

Mostrará o seguinte resultado (exemplo da saída no Host 1):

...
gluster1:VMS  2.0T  35G  2.0T  2% /vms

Para testar se os dados estão sendo replicados executar o seguinte comando somente em um dos Hosts (serão criados 10 arquivos no volume Gluster configurado e montado em /vms):

for i in `seq -w 1 10`; do cp -rp /var/log/messages /vms/copy-test-$i; done

Então deve-se acessar cada Servidor e verificar se os arquivos estão presentes com o comando:

ls -lA /vms/copy*

Mostrará o seguinte resultado:

-rw-r----- 1 root adm 320784 Oct  4 16:37 /vms/copy-test-01
-rw-r----- 1 root adm 320784 Oct  4 16:37 /vms/copy-test-02
-rw-r----- 1 root adm 320784 Oct  4 16:37 /vms/copy-test-03
-rw-r----- 1 root adm 320784 Oct  4 16:37 /vms/copy-test-04
-rw-r----- 1 root adm 320784 Oct  4 16:37 /vms/copy-test-05
-rw-r----- 1 root adm 320784 Oct  4 16:37 /vms/copy-test-06
-rw-r----- 1 root adm 320784 Oct  4 16:37 /vms/copy-test-07
-rw-r----- 1 root adm 320784 Oct  4 16:37 /vms/copy-test-08
-rw-r----- 1 root adm 320784 Oct  4 16:37 /vms/copy-test-09
-rw-r----- 1 root adm 320784 Oct  4 16:37 /vms/copy-test-10

O Volume GlusterFS criado e montado em /vms funciona como uma espécie de link para a partição LVM /dev/sda4, que foi criada anteriormente no tópico 4 deste manual. Logo, é interessante conferir também, em cada Host, se os arquivos foram criados na pasta onde a partição LVM foi montada (/mnt/lv/vmstg/vms). Os mesmos arquivos serão listados com o comando:

ls -lA /mnt/lv/vmstg/vms/copy*

Deve-se remover os arquivos criados para teste executando o seguinte comando em somente 1 dos Hosts (nos outros 2 serão removidos automaticamente pelo Gluster):

rm /vms/copy*

Com isso o Cluster de armazenamento hiperconvegente está configurado e pronto para uso. Contudo, ainda é necessário realizar o procedimento do capítulo 9 deste manual para que o Proxmox possa usar ele de fato. Logo, deve-se pular o tópico seguinte deste capítulo, pular também o capítulo 8. ADIÇÃO DE NOVOS SERVIDORES AO GLUSTERFS e ir seguir direto para o capítulo 9. FINALIZAÇÃO DO CLUSTER PROXMOX.

7.2. CRIAÇÃO DO VOLUME DO TIPO DISTRIBUÍDO EM 1 SERVIDOR

Neste cenário será criado um Volume Gluster do tipo Distribuído, já que não é possível criar um volume do tipo Replicado com somente somente 1 Servidor rodando o Proxmox com o GlusterFS. Quando os outros 2 Servidores forem unidos ao pool do serviço Gluster, esse volume será convertido para o tipo Réplica.

Para verificar a definição atual do serviço Gluster, deve-se executar:

gluster pool list
gluster peer status

Mostrará o seguinte resultado, pois não há nenhum volume definido e os outros Servidores ainda não fazem parte do Gluster:

UUID                                    Hostname        State
f65851be-3a13-4e43-9ba3-45a9054c4e5a    localhost       Connected 

Number of Peers: 0

É interessante executar o comando seguinte antes de se criar o volume. Ele indicará que nenhum volume foi configurado ainda.

gluster volume info

O comando seguinte cria o Volume GlusterFS, de nome "VMS" do tipo Distribuído no Host. Conforme especificado após o nome do Host no comando (depois do ":"), o volume utilizará o diretório /mnt/lv/vmstg onde a partição LVM foi montada anteriormente (mais uma vez, adaptar os nomes conforme o Campus).

gluster volume create VMS gluster1.reitoria.ifsertao-pe.edu.br:/mnt/lv/vmstg/vms

Agora é necessário iniciar o volume criado:

gluster volume start VMS

Para verificar o volume criado:

gluster volume info

Mostrará o seguinte resultado:

Volume Name: VMS
Type: Distribute
Volume ID: ...
Status: Started
Snapshot Count: 0
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: gluster1.reitoria.ifsertao-pe.edu.br:/mnt/lv/vmstg/vms
Options Reconfigured:
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on

Na saída é possível observar que o volume de nome "VMS" do tipo "Distribute" foi criado e iniciado e possui com 1 Brick no Host 1, indicando que ele só foi configurado no Host atual.

Neste ponto o volume está criado, inicializado, mas ainda não pode ser utilizado. É necessário montar ele executando os comandos seguintes.

Deve-se criar o ponto de montagem:

mkdir -p /vms

Deve-se configurar em seguida a montagem automática no boot do sistema, executando o seguinte comando:

echo "gluster1:VMS /vms glusterfs defaults,_netdev,x-systemd.automount 0 0" >> /etc/fstab

Por fim deve-se realizar a montagem em si e verificar se montou com sucesso:

mount -a

df -h

Mostrará o seguinte resultado:

...
gluster1:VMS  2.0T  35G  2.0T  2% /vms

Com isso o serviço GlusterFS está configurado e o Volume "VMS" está funcional no Host em questão. Contudo, a solução deste manual ainda não foi finalizada, pois ela consiste em um Cluster Hiperconvergente com 3 Servidores.

Caso não se possa finalizar o Cluster ainda (para preservar o atual ambiente de virtualização em produção no Campus, por exemplo), deve-se seguir direto para o capítulo 9. FINALIZAÇÃO DO CLUSTER PROXMOX a fim de se configurar o Storage GlusterFS no Proxmox. Caso contrário, deve-se continuar no capítulo 8. ADIÇÃO DE NOVOS SERVIDORES AO GLUSTERFS.

8. Adição de novos servidores ao GlusterFS

O serviço GlusterFS é bastante flexível, podendo-se adicionar/remover Servidores ao Cluster de armazenamento a qualquer momento. Este capítulo descreve como novos Hosts podem ser adicionados, sendo importante caso a implementação da solução deste manual tenha tenha seguido o tópico 7.2. CRIAÇÃO DO VOLUME DO TIPO DISTRIBUÍDO EM 1 SERVIDOR.

Caso se tenha seguido o tópico 7.1. CRIAÇÃO DO VOLUME DO TIPO REPLICADO NOS 3 SERVIDORES esse capítulo é desnecessário, a não ser que se deseje adicionar um 4 Servidor ao Cluster.

Para os comandos seguintes será considerado que a etapa do tópico 7.2. CRIAÇÃO DO VOLUME DO TIPO DISTRIBUÍDO EM 1 SERVIDOR foi realizada no Host 1, e que o Host 2 e o Host 3 serão adicionados ao volume GlusterFS já configurado no primeiro, formando então o Cluster de armazenamento Hiperconvergente da solução deste manual. Considera-se ainda que Hosts 2 e 3 estão prontos para fazer parte do Cluster, com todas as etapas dos capítulos de 1 ao 6 executadas neles.

No Servidor 1 deve ser executados os comandos a seguir.

Para verificar que há somente 1 servidor no pool do Gluster do Host 1:

gluster pool list
gluster peer status

Mostrará o seguinte resultado:

UUID                                    Hostname        State
f65851be-3a13-4e43-9ba3-45a9054c4e5a    localhost       Connected 

Number of Peers: 0

Para adicionar os demais hosts ao pool:

gluster peer probe gluster2.reitoria.ifsertao-pe.edu.br

gluster peer probe gluster3.reitoria.ifsertao-pe.edu.br

Verificar novamente o pool do Gluster:

gluster pool list
gluster peer status

Mostrará o seguinte resultado:

9e90a572-3d33-458e-a202-f0d9be1054bb  gluster2.reitoria.ifsertao-pe.edu.br  Connected 
06e41fd6-88fd-4c70-afca-e9b5ca80c144  gluster3.reitoria.ifsertao-pe.edu.br  Connected 
989a97bc-3743-48e3-864f-f226369610ce  localhost

Number of Peers: 3

Agora, é interessante verificar também o Volume configurado anteriormente no Host 1:

gluster volume info

Mostrará o volume "VMS" do tipo "Distribute" com somente 1 brick correspondente ao Host 1, pois o volume Gluster ainda não foi configurado com os novos Servidores. Apenas a conexão entre eles foi feita nos comandos anteriores:

Volume Name: VMS
Type: Distribute
Volume ID: ...
Status: Started
Snapshot Count: 0
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: gluster1.reitoria.ifsertao-pe.edu.br:/mnt/lv/vmstg/vms
Options Reconfigured:
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on

Os comandos seguintes configuram o volume para utilizar também os novos Servidores. É possível adicionar os outros 2 Hosts simultaneamente ou 1 após o outro. Em ambos os casos, com os comandos a seguir o volume será convertido do tipo Distribuído para o tipo Replicado.

Adição simultânea:

gluster volume add-brick VMS replica 3 gluster2.reitoria.ifsertao-pe.edu.br:/mnt/lv/vmstg/vms gluster3.reitoria.ifsertao-pe.edu.br:/mnt/lv/vmstg/vms

Adição separada:

gluster volume add-brick VMS replica 2 gluster2.reitoria.ifsertao-pe.edu.br:/mnt/lv/vmstg/vms

gluster volume add-brick VMS replica 3 gluster3.reitoria.ifsertao-pe.edu.br:/mnt/lv/vmstg/vms

Para conferir o volume:

gluster volume info

Mostrará:

Volume Name: VMS
Type: Replicate
Volume ID: 632140b2-528a-40d1-a075-dc460b2ec023
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: gluster1.reitoria.ifsertao-pe.edu.br:/mnt/lv/vmstg/vms
Brick2: gluster2.reitoria.ifsertao-pe.edu.br:/mnt/lv/vmstg/vms
Brick3: gluster3.reitoria.ifsertao-pe.edu.br:/mnt/lv/vmstg/vms
Options Reconfigured:
cluster.granular-entry-heal: on
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off

Neste ponto o volume "VMS" está montado somente no Host 1 e a réplica não funcionará. É necessário realizar ainda algumas configurações, agora nos 3 Hosts do Cluster:

No Host 1:

Desmontar o volume.

umount /vms

Editar o arquivo /etc/fstab e substituir a linha:

gluster1:VMS /vms glusterfs defaults,_netdev,x-systemd.automount 0 0

Para:

gluster1:VMS /vms glusterfs defaults,_netdev,x-systemd.automount,backupvolfile-server=gluster2,backupvolfile-server=gluster3 0 0

Realizar a montagem novamente e verificar se montou com sucesso:

mount -a

df -h

Mostrará o seguinte resultado:

...
gluster1:VMS  2.0T  35G  2.0T  2% /vms

No Host 2:

Deve-se criar o ponto de montagem:

mkdir -p /vms

Deve-se configurar em seguida a montagem automática no boot do sistema, executando o seguinte comando:

echo "host2:VMS /vms glusterfs defaults,_netdev,x-systemd.automount,backupvolfile-server=gluster1,backupvolfile-server=gluster3 0 0" >> /etc/fstab

Realizar a montagem em si e verificar se montou com sucesso:

mount -a

df -h

Mostrará o seguinte resultado:

...
gluster2:VMS  2.0T  35G  2.0T  2% /vms

No Host 3:

Criar o ponto de montagem:

mkdir -p /vms

Configurar em seguida a montagem automática no boot do sistema:

echo "gluster3:VMS /vms glusterfs defaults,_netdev,x-systemd.automount,backupvolfile-server=gluster1,backupvolfile-server=gluster2 0 0" >> /etc/fstab

Realizar a montagem em si e verificar se montou com sucesso:

mount -a

df -h

Mostrará o seguinte resultado:

...
gluster3:VMS  2.0T  35G  2.0T  2% /vms

Com isso o Cluster de armazenamento hiperconvegente está configurado e pronto para uso. Contudo, ainda é necessário realizar o procedimento do capítulo seguinte para que o Proxmox possa usar ele de fato.

9. Finalização do Cluster Proxmox

Finalizando a solução deste manual, o Cluster Proxmox deve ser criado e o Storage Gluster deve ser configurado nele. Deve-se acessar um dos Hosts pelo navegador (o Host 1 por exemplo https://192.168.100.101:8006), e criar o Cluster como segue:

Na janela que se abre, em "Cluster Name" inserir o nome do Campus e em "Cluster Network" escolher o IP de gerenciamento do Host (o IP do Host na rede de Virtualização).

Com o Cluster criado, deve -se clicar em "Join Information".

Na janela que se abre, copiar o código gerado em "Copy Information". Esse código será utilizado para inserir os demais Hosts no Cluster.

Como foi utilizado o Host 1 para a criação do Cluster, os próximos passos devem ser realizados nos Hosts 2 e 3 para adicioná-los ao Cluster. Deve-se acessar a interface web do Host 2 em https://192.168.100.102:8006 (e posteriormente o Host 3) e clicar em "Join Cluster" como segue:

Na janela que se abre deve-se colar o código copiado anteriormente do Host 1 no campo "Information", inserir a senha de root do Host 1 no campo "Password", e em "Cluster Network" selecionar o IP da interface de gerenciamento do Host 2. Segue exemplo:

Com isso, o Cluster está criado.

Agora é necessário setar o Storage GlusterFS para as VMs, como segue:

O Cluster Hiperconvergente Proxmox está finalizado e pronto para uso. Isso conclui a solução deste manual.