🥇Dicas e truques no trabalho com Ceph em projetos de alta demanda

Usando o Ceph como armazenamento em rede em projetos de diferentes níveis de carga, podemos enfrentar várias tarefas que, à primeira vista, não parecem simples ou triviais. Por exemplo:

migração de dados do Ceph antigo para o novo, com uso parcial dos servidores anteriores no novo cluster;
resolução do problema de distribuição do espaço em disco no Ceph.

Ao lidar com essas tarefas, encontramos a necessidade de extrair corretamente o OSD sem perder dados, o que é especialmente relevante em grandes volumes de dados. Este é o tema deste artigo.

Os métodos descritos abaixo são aplicáveis a quaisquer versões do Ceph. Além disso, será considerado que o Ceph pode armazenar um grande volume de dados: para evitar perdas de dados e outros problemas, algumas ações serão 'divididas' em várias outras.

Prefácio sobre OSD

Como dois dos três relatos a seguir são dedicados ao OSD (Object Storage Daemon), antes de entrar na parte prática, faremos um resumo sobre o que é isso no Ceph e por que é tão importante.

Em primeiro lugar, deve-se dizer que todo o cluster Ceph é composto por muitos OSDs. Quanto mais OSDs, maior será o volume livre de dados no Ceph. Daí é fácil entender a principal função do OSD: ele armazena dados de objetos Ceph nos sistemas de arquivos de todos os nós do cluster e fornece acesso em rede a eles (para leitura, gravação e outras solicitações).

Neste mesmo nível, são definidas as configurações de replicação, copiando objetos entre diferentes OSDs. E aqui podemos encontrar diversos problemas, cuja solução será abordada a seguir.

Caso nº 1. Extração segura do OSD do cluster Ceph sem perda de dados

A necessidade de extrair um OSD pode ser causada pela retirada do servidor do cluster — por exemplo, para substituição por outro servidor — o que aconteceu conosco e motivou a escrita deste artigo. Assim, o objetivo final das manobras é extrair todos os OSDs e mon’s deste servidor para que ele possa ser desligado.

Para facilitar e evitar a situação em que erramos ao indicar o OSD correto durante a execução dos comandos, definiremos uma variável separada, cujo valor será o número do OSD a ser removido. Vamos chamá-la de ${ID} — aqui e adiante, essa variável substitui o número do OSD com o qual estamos trabalhando.

Vamos verificar o estado antes de começar os trabalhos:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF
-1       0.46857 root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
 1   ssd 0.15619      osd.1     up     1.00000  1.00000
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2     up     1.00000  1.00000

Para iniciar a remoção do OSD, será necessário realizar uma suavização reweight nele até zero. Assim, reduzimos a quantidade de dados no OSD balanceando para outros OSDs. Para isso, os seguintes comandos são executados:

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

… e assim por diante até zero.

O balanceamento suave é necessário, para não perder dados. Isso é especialmente crítico se houver uma grande quantidade de dados no OSD. Para garantir que após a execução dos comandos reweight tudo ocorreu com sucesso, pode-se executar ceph -s ou, em uma janela de terminal separada, iniciar ceph -w para observar as mudanças em tempo real.

Quando o OSD estiver "esvaziado", pode-se prosseguir com a operação padrão de remoção. Para isso, colocamos o OSD desejado no estado down:

ceph osd down osd.${ID}

"Retiramos" o OSD do cluster:

ceph osd out osd.${ID}

Pararemos o serviço OSD e desmontaremos sua partição no FS:

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

Removeremos o OSD do CRUSH map:

ceph osd crush remove osd.${ID}

Removeremos o usuário OSD:

ceph auth del osd.${ID}

E, finalmente, removeremos o próprio OSD:

ceph osd rm osd.${ID}

Nota: se você estiver usando a versão Ceph Luminous ou superior, as ações acima para remover o OSD podem ser reduzidas a dois comandos:

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

Se após a execução dos comandos descritos acima, você executar o comando ceph osd tree, deve-se ver que no servidor onde o trabalho foi realizado, não há mais OSDs para os quais as operações acima foram realizadas:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.46857      root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2    up     1.00000  1.00000

Notamos também que o estado do cluster Ceph mudará para HEALTH_WARN, e também veremos uma redução no número de OSDs e na quantidade de espaço em disco disponível.

A seguir, serão descritas as ações necessárias caso você deseje desligar completamente o servidor e, consequentemente, removê-lo do Ceph. Nesse caso, é importante lembrar que antes de desligar o servidor é preciso retirar todos os OSDs neste servidor.

Se não houver mais OSDs neste servidor, após sua remoção, deve-se excluir o servidor da mapa OSD hv-2, executando o seguinte comando:

ceph osd crush rm hv-2

Removemos mon do servidor hv-2, executando o comando abaixo em outro servidor (ou seja, neste caso — em hv-1):

ceph-deploy mon destroy hv-2

Após isso, você pode parar o servidor e prosseguir com as próximas etapas (como a sua reimplantação, etc.).

Caso nº 2. Distribuição do espaço em disco em um cluster Ceph já criado

Começarei a segunda história com uma introdução sobre PG (Placement Groups). O papel principal do PG no Ceph é, em primeiro lugar, agregar objetos Ceph e replicá-los nos OSD. A fórmula com a qual se pode calcular a quantidade necessária de PG está na seção correspondente documentação do Ceph. Esse assunto é abordado lá com exemplos concretos.

Assim está: um dos problemas comuns durante a operação do Ceph é a quantidade desigual de OSD e PG entre os pools no Ceph.

Primeiro, isso pode levar a uma situação em que um número excessivo de PG é especificado em um pool pequeno, o que é, na essência, um uso irracional do espaço em disco no cluster. Em segundo lugar, na prática, surge um problema mais sério: a saturação de dados em um dos OSD. Isso faz com que o cluster mude primeiro para um estado HEALTH_WARN, e depois para HEALTH_ERR. O culpado é que o Ceph, ao calcular o volume de dados disponíveis (que pode ser obtido por meio de MAX AVAIL na saída do comando ceph df para cada pool separadamente) se baseia no volume de dados disponíveis nos OSD. Se pelo menos um OSD não tiver espaço suficiente, não será possível gravar mais dados até que esses sejam distribuídos corretamente entre todos os OSD.

Cabe destacar que esses problemas são em sua maior parte resolvidos na etapa de configuração do cluster Ceph. Uma das ferramentas que podem ser utilizadas é Ceph PGCalc. Com ela, calcula-se visualmente a quantidade necessária de PG. No entanto, pode-se recorrer a ela também em situações em que o cluster Ceph já está configurado incorretamente. Aqui deve-se esclarecer que no âmbito dos trabalhos de correção, você provavelmente precisará reduzir a quantidade de PG, e essa possibilidade não está disponível nas versões antigas do Ceph (só apareceu a partir da versão Nautilus).

Portanto, imagine a seguinte situação: o cluster tem status HEALTH_WARN porque um dos OSD está ficando sem espaço. Isso será indicado pelo erro HEALTH_WARN: 1 near full osd. Abaixo está o algoritmo para sair dessa situação.

Primeiro, é necessário distribuir os dados existentes entre os outros OSDs. Já realizamos essa operação no primeiro caso, quando 'esgotamos' o nó - com a única diferença de que agora será necessário reduzir ligeiramente. reweightPor exemplo, para 0.95:

ceph osd reweight osd.${ID} 0.95

Assim, o espaço em disco no OSD é liberado e o erro no ceph health é corrigido. No entanto, como já mencionado, esse problema ocorre principalmente devido à configuração incorreta do Ceph nas etapas iniciais: é muito importante realizar a reconfiguração para que não se manifeste no futuro.

Em nosso caso específico, tudo se baseava em:

um valor muito alto replication_count em um dos pools,
um número de PG muito elevado em um pool e muito baixo em outro.

Vamos usar a calculadora já mencionada. Ela mostra claramente o que deve ser inserido e, na verdade, não há nada de complicado. Definidos os parâmetros necessários, obtemos as seguintes recomendações:

Nota: se você estiver configurando um cluster Ceph do zero, uma função útil da calculadora será a geração de comandos que criarão pools do zero com os parâmetros especificados na tabela.

O último coluna ajuda a se orientar - Suggested PG Count. No nosso caso, a segunda coluna também é útil, que indica o parâmetro de replicação, uma vez que decidimos alterar o fator de replicação.

Portanto, primeiro será necessário alterar os parâmetros de replicação - isso deve ser feito em primeiro lugar, pois, ao reduzir o fator, liberaremos espaço em disco. Durante a execução do comando, pode-se observar que o valor do espaço em disco disponível aumentará:

ceph osd pool $pool_name set $replication_size

E após sua conclusão - alteramos os valores dos parâmetros pg_num e pgp_num da seguinte forma:

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

Importante: devemos alterar sequencialmente a quantidade de PG em cada pool e não alterar os valores em outros pools até que os avisos se extinguam. ‘Degraded data redundancy’ e ‘n-number of pgs degraded’.

Pode-se verificar se tudo ocorreu com sucesso também pelos resultados dos comandos ceph health detail e ceph -s.

Caso nº 3. Migração de máquina virtual de LVM para Ceph RBD

Em situações em que um projeto utiliza máquinas virtuais instaladas em servidores bare-metal alugados, frequentemente surge a questão do armazenamento de alta disponibilidade. E também é muito desejável que haja espaço suficiente nesse armazenamento... Outra situação comum é ter uma máquina virtual com armazenamento local no servidor e precisar expandir o disco, mas não há como, pois não há espaço livre em disco no servidor.

O problema pode ser resolvido de várias maneiras — por exemplo, migrando para outro servidor (se houver) ou adicionando novos discos ao servidor. Mas nem sempre isso é possível, por isso a migração de LVM para Ceph pode ser uma excelente solução para esse problema. Ao optar por essa alternativa, também simplificamos o processo de migração entre servidores, uma vez que não será necessário mover o armazenamento local de um hipervisor para outro. A única complicação é que será necessário parar a VM durante o processo.

Como receita a seguir, foi utilizado um artigo deste blog, cujas instruções foram testadas na prática. Aliás, também é descrito o método de migração sem complicações, no entanto, no nosso caso, isso simplesmente não foi necessário, portanto não o testamos. Se isso for crítico para o seu projeto — ficaríamos felizes em saber os resultados nos comentários.

Vamos iniciar a parte prática. No exemplo, utilizamos o virsh e, consequentemente, o libvirt. Para começar, verifique se o pool do Ceph, para o qual os dados serão migrados, está conectado ao libvirt:

virsh pool-dumpxml $ceph_pool

Na descrição do pool devem constar os dados de conexão com o Ceph com as informações de autenticação.

A próxima etapa consiste em converter a imagem LVM para Ceph RBD. O tempo de execução depende principalmente do tamanho da imagem:

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

Após a conversão, permanecerá a imagem LVM, que será útil caso a migração da VM para o RBD não funcione e seja necessário reverter as alterações. Além disso — para a possibilidade de reverter rapidamente as alterações — faremos um backup do arquivo de configuração da máquina virtual:

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

… e editaremos o original (vm_name.xml). Vamos encontrar o bloco com a descrição do disco (começa com a linha <disk type='file' device='disk'> e termina em </disk>) e levá-lo à seguinte forma:

Vamos analisar alguns detalhes:

No protocolo source é indicado o endereço do armazenamento no Ceph RBD (este é o endereço que inclui o nome do pool Ceph e a imagem RBD, que foi definida na primeira etapa).
Na seção secret é indicado o tipo ceph, assim como o UUID do segredo para a conexão. Seu uuid pode ser obtido com o comando virsh secret-list.
Na seção host são indicados os endereços dos monitores Ceph.

Após editar o arquivo de configuração e concluir a conversão de LVM para RBD, é possível aplicar o arquivo de configuração alterado e iniciar a máquina virtual:

virsh define $vm_name.xml
virsh start $vm_name

É o momento de verificar se a máquina virtual foi iniciada corretamente: isso pode ser feito, por exemplo, conectando-se a ela via SSH ou através de virsh.

Se a máquina virtual estiver funcionando corretamente e você não encontrar outros problemas, pode remover a imagem LVM que não está mais em uso:

lvremove main/$vm_image_name

Conclusão

Todos os casos descritos ocorreram na prática — esperamos que as instruções ajudem outros administradores a resolver problemas similares. Se você tiver comentários ou outras histórias semelhantes da experiência com o Ceph — ficaremos felizes em vê-las nos comentários!