Utilizando Ceph como armazenamento de rede em projetos com diferentes cargas, podemos nos deparar com diversas tarefas que à primeira vista não parecem simples ou triviais. Por exemplo:
- migração de dados do Ceph antigo para o novo com utilização parcial dos servidores anteriores do novo cluster;
- solução para o problema de alocação de espaço em disco no Ceph.
Ao lidar com tais problemas, nos deparamos com a necessidade de remover corretamente o OSD sem perder dados, o que é especialmente importante quando se trata de grandes quantidades de dados. Isso será discutido no artigo.
Os métodos descritos abaixo são relevantes para qualquer versão do Ceph. Além disso, será levado em consideração o fato de o Ceph poder armazenar uma grande quantidade de dados: para evitar perda de dados e outros problemas, algumas ações serão “divididas” em diversas outras.
Prefácio sobre OSD
Como duas das três receitas discutidas são dedicadas ao OSD (), antes de mergulhar na parte prática – brevemente sobre o que é o Ceph e por que é tão importante.
Em primeiro lugar, deve-se dizer que todo o cluster Ceph consiste em muitos OSDs. Quanto mais houver, maior será o volume de dados livres no Ceph. É fácil entender daqui função OSD principal: ele armazena dados de objetos Ceph nos sistemas de arquivos de todos os nós do cluster e fornece acesso de rede a eles (para leitura, gravação e outras solicitações).
No mesmo nível, os parâmetros de replicação são definidos copiando objetos entre diferentes OSDs. E aqui você pode encontrar vários problemas, cujas soluções serão discutidas a seguir.
Caso nº 1. Remova com segurança o OSD do cluster Ceph sem perder dados
A necessidade de remoção do OSD pode ser causada pela remoção do servidor do cluster - por exemplo, para substituí-lo por outro servidor - que foi o que aconteceu conosco, dando origem à escrita deste artigo. Assim, o objetivo final da manipulação é extrair todos os OSDs e mons de um determinado servidor para que ele possa ser interrompido.
Por conveniência e para evitar uma situação em que, ao executar comandos, cometemos um erro ao indicar o OSD necessário, definiremos uma variável separada, cujo valor será o número do OSD a ser excluído. Vamos ligar para ela ${ID} — aqui e abaixo, tal variável substitui o número do OSD com o qual estamos trabalhando.
Vejamos a condição antes de começar o trabalho:
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, você precisará executar suavemente reweight nele para zero. Desta forma, reduzimos a quantidade de dados no OSD, equilibrando-os com outros OSDs. Para fazer isso, execute os seguintes comandos:
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.
É necessário um balanceamento suavepara não perder dados. Isto é especialmente verdadeiro se o OSD contiver uma grande quantidade de dados. Para ter certeza de que depois de executar os comandos reweight tudo correu bem, você pode concluí-lo ceph -s ou em uma janela de terminal separada, execute ceph -w para observar mudanças em tempo real.
Quando o OSD estiver “esvaziado”, você pode prosseguir com a operação padrão para removê-lo. Para fazer isso, transfira o OSD desejado para o estado down:
ceph osd down osd.${ID}Vamos “puxar” o OSD para fora do cluster:
ceph osd out osd.${ID}Vamos parar o serviço OSD e desmontar sua partição no FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Remover OSD de :
ceph osd crush remove osd.${ID}Vamos deletar o usuário OSD:
ceph auth del osd.${ID}E finalmente, vamos remover o próprio OSD:
ceph osd rm osd.${ID}Nota: se você estiver usando a versão Ceph Luminous ou superior, as etapas de remoção do OSD acima podem ser reduzidas a dois comandos:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Se, após concluir as etapas descritas acima, você executar o comando ceph osd tree, então deve ficar claro que no servidor onde o trabalho foi executado não existem mais OSDs para os quais as operações acima foram executadas:
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
Ao longo do caminho, observe que o estado do cluster Ceph irá para HEALTH_WARN, e também veremos uma diminuição no número de OSDs e na quantidade de espaço disponível em disco.
A seguir serão descritas as etapas que serão necessárias se você quiser interromper completamente o servidor e, consequentemente, removê-lo do Ceph. Neste caso, é importante lembrar que Antes de desligar o servidor, você deve remover todos os OSDs neste servidor.
Se não houver mais OSDs neste servidor, depois de removê-los, você precisará excluir o servidor do mapa OSD hv-2executando o seguinte comando:
ceph osd crush rm hv-2
Excluir mon do servidor hv-2executando o comando abaixo em outro servidor (ou seja, neste caso, em hv-1):
ceph-deploy mon destroy hv-2Depois disso, você pode parar o servidor e iniciar as ações subsequentes (reimplantá-lo, etc.).
Caso nº 2. Distribuição de espaço em disco em um cluster Ceph já criado
Começarei a segunda história com um prefácio sobre PG (). A principal função do PG no Ceph é principalmente agregar objetos Ceph e replicá-los ainda mais no OSD. A fórmula com a qual você pode calcular a quantidade necessária de PG está em Documentação do Ceph. Esta questão também é discutida lá com exemplos específicos.
Portanto: um dos problemas comuns ao usar o Ceph é o número desequilibrado de OSD e PG entre pools no Ceph.
Em primeiro lugar, por causa disso, pode surgir uma situação quando muitos PGs são especificados em um pool pequeno, o que é essencialmente um uso irracional do espaço em disco no cluster. Em segundo lugar, na prática existe um problema mais grave: o excesso de dados num dos OSD. Isso implica que o cluster primeiro faça a transição para o estado HEALTH_WARN, e depois HEALTH_ERR. A razão para isso é que o Ceph, ao calcular a quantidade de dados disponíveis (você pode descobrir por MAX AVAIL na saída do comando ceph df para cada pool separadamente) baseia-se na quantidade de dados disponíveis no OSD. Se não houver espaço suficiente em pelo menos um OSD, nenhum outro dado poderá ser gravado até que os dados sejam distribuídos adequadamente entre todos os OSDs.
Vale esclarecer que esses problemas são amplamente decididos no estágio de configuração do cluster Ceph. Uma das ferramentas que você pode usar é . Com sua ajuda, a quantidade necessária de PG é calculada com clareza. No entanto, você também pode recorrer a ele em uma situação em que o cluster do Ceph já configurado incorretamente. Vale esclarecer aqui que como parte do trabalho de correção você provavelmente precisará reduzir o número de PGs, e esse recurso não está disponível em versões mais antigas do Ceph (ele só apareceu na versão ).
Então, vamos imaginar a seguinte imagem: o cluster tem um status HEALTH_WARN devido a um dos OSD ficar sem espaço. Isso será indicado por um erro HEALTH_WARN: 1 near full osd. Abaixo está um algoritmo para sair dessa situação.
Primeiro de tudo, você precisa distribuir os dados disponíveis entre os OSDs restantes. Já realizamos operação semelhante no primeiro caso, quando “drenamos” o nó - com a única diferença que agora precisaremos reduzir um pouco reweight. Por exemplo, até 0.95:
ceph osd reweight osd.${ID} 0.95Isso libera espaço em disco no OSD e corrige o erro de integridade do ceph. Porém, como já mencionado, esse problema ocorre principalmente devido à configuração incorreta do Ceph nos estágios iniciais: é muito importante fazer uma reconfiguração para que ela não apareça no futuro.
No nosso caso particular, tudo se resumiu a:
- valor muito alto
replication_countem uma das piscinas, - muito PG em um pool e pouco em outro.
Vamos usar a calculadora já mencionada. Mostra claramente o que precisa ser inserido e, em princípio, não há nada complicado. Depois de definir os parâmetros necessários, obtemos as seguintes recomendações:
Nota: se você estiver configurando um cluster Ceph do zero, outra função útil da calculadora é a geração de comandos que criarão pools do zero com os parâmetros especificados na tabela.
A última coluna ajuda você a navegar - Contagem de PG sugerida. No nosso caso, o segundo também é útil, onde é indicado o parâmetro de replicação, pois decidimos alterar o multiplicador de replicação.
Então, primeiro você precisa alterar os parâmetros de replicação - vale a pena fazer isso primeiro, pois ao reduzir o multiplicador, liberaremos espaço em disco. À medida que o comando for executado, você notará que o espaço disponível em disco aumentará:
ceph osd pool $pool_name set $replication_size
E após sua conclusão, alteramos os valores dos parâmetros pg_num и pgp_num da seguinte maneira:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberÉ importante: devemos alterar o número de PGs sequencialmente em cada pool e não alterar os valores nos outros pools até que os avisos desapareçam "Redundância de dados degradada" и "n-número de páginas degradadas".
Você também pode verificar se tudo correu bem usando as saídas de comando ceph health detail и ceph -s.
Caso nº 3. Migrando uma máquina virtual do LVM para o Ceph RBD
Em uma situação em que um projeto usa máquinas virtuais instaladas em servidores bare-metal alugados, surge frequentemente o problema do armazenamento tolerante a falhas. Também é muito desejável que haja espaço suficiente neste armazenamento... Outra situação comum: existe uma máquina virtual com armazenamento local no servidor e você precisa expandir o disco, mas não tem para onde ir, porque não há espaço livre em disco restante no servidor.
O problema pode ser resolvido de diferentes maneiras - por exemplo, migrando para outro servidor (se houver) ou adicionando novos discos ao servidor. Mas nem sempre é possível fazer isso, então migrar do LVM para o Ceph pode ser uma excelente solução para esse problema. Ao escolher esta opção, também simplificamos o posterior processo de migração entre servidores, uma vez que não haverá necessidade de mover o armazenamento local de um hipervisor para outro. O único problema é que você terá que parar a VM enquanto o trabalho está sendo realizado.
A seguinte receita foi retirada de , cujas instruções foram testadas em ação. Por falar nisso, o método de migração sem complicações também é descrito lá, no entanto, no nosso caso, simplesmente não era necessário, por isso não o verificamos. Se isso for crítico para o seu projeto, teremos o maior prazer em saber dos resultados nos comentários.
Vamos passar para a parte prática. No exemplo usamos virsh e, consequentemente, libvirt. Primeiro, certifique-se de que o pool do Ceph para o qual os dados serão migrados esteja conectado à libvirt:
virsh pool-dumpxml $ceph_poolA descrição do pool deve conter dados de conexão ao Ceph com dados de autorização.
A próxima etapa é que a imagem LVM seja convertida em 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_nameApós a conversão, uma imagem LVM permanecerá, o que será útil se a migração da VM para RBD falhar e você precisar reverter as alterações. Além disso, para poder reverter as alterações rapidamente, vamos fazer 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 edite o original (vm_name.xml). Vamos encontrar um bloco com uma descrição do disco (começa com a linha <disk type='file' device='disk'> e termina com </disk>) e reduzi-lo para a seguinte forma:
<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
<secret type='ceph' uuid='sec-ret-uu-id'/>
</auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
<host name='10.0.0.1' port='6789'/>
<host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>Vejamos alguns detalhes:
- Para o protocolo
sourceé indicado o endereço de armazenamento no Ceph RBD (este é o endereço que indica o nome do pool do Ceph e a imagem RBD, que foi determinada na primeira etapa). - No bloco
secrettipo é indicadoceph, bem como o UUID do segredo para conectar-se a ele. Seu uuid pode ser encontrado usando o comandovirsh secret-list. - No bloco
hostendereços para monitores Ceph são indicados.
Depois de editar o arquivo de configuração e concluir a conversão de LVM em RBD, você pode aplicar o arquivo de configuração modificado e iniciar a máquina virtual:
virsh define $vm_name.xml
virsh start $vm_name
É hora de verificar se a máquina virtual iniciou corretamente: você pode descobrir, por exemplo, conectando-se a ela via SSH ou via virsh.
Se a máquina virtual estiver funcionando corretamente e você não encontrar nenhum outro problema, poderá excluir a imagem LVM que não é mais usada:
lvremove main/$vm_image_nameConclusão
Encontramos todos os casos descritos na prática - esperamos que as instruções ajudem outros administradores a resolver problemas semelhantes. Se você tiver comentários ou outras histórias semelhantes sobre sua experiência com o Ceph, ficaremos felizes em vê-los nos comentários!
PS
Leia também em nosso blog:
- «";
- «";
- «";
- «".
Fonte: habr.com