CEPH - RBD com disco Travado

Descrição do problema

Temos na FIRMA um ambiente com 10 servidores Proxmox VE (PVE) fazendo a virtualização e utilizando o CEPH como Storage. Após uma pane elétrica foi necessário fazer intervenção manual pois o sistema parou por completo e o CEPH precisava refazer a sincronia e o PVE restabelecer o cluster de virtualização.

Como um dos nós não estava entrando no ar tentei forçar a migração da VM - vou chamar aqui de vm100 - porém por alguma razão a migração não foi efetuada com sucesso, resolvi observar outras questões e depois voltar para analisar a falha de migração da vm100. Após uns 15 minutos o processo não foi concluído, permanecendo como se ainda estivesse executando, por conta da minha ansiedade resolvi reiniciar logo o node problemático.

Fazendo uma rápida contextualização, o PVE é um sistema completo de Hipervitualização que permite usar o padrão de Hiperconvergencia integrando virtualização (kvm, lxc), com storage via software (glusterfs, ceph, zfs, lvm) bem como os players de storage comuns no mercado como isci, nfs e outros, rede definida por software com ferramentas como openvswitch e outras features.

Após essa parada a VM não subia mais e nem conseguia fazer uso dos discos/imagens dispostas no RBD ( mais sobre o CEPH ), então narro abaixo os procedimentos aplicados.

Passos para ‘destravar’ os discos

De início decidir verificar como estavam as imagens dos discos.

  • O cluster CEPH estava no ar e completamente funcional
rbd info vm100-d0
rbd info vm100-d1
rbd info vm100-d2

Tanto o primeiro(vm100-d0) quanto o segundo(vm100-disk-1) disco apresentaram problemas, informando alertas em invalid-object-map-related. Por isso decidi aplicar os comandos de rebuild na imagem.

rbd object-map rebuild vm100-d0;rbd object-map rebuild vm100-d1

Infelizmente não surtiu efeito pois o processo não iniciava. Resolvi verificar em cada um dos nós se tinha algum map para imagem ainda ativo. Falando a grosso modo o processo de map é a montagem/link entre um device no linux e a imagem da vm, permitindo assim que ó qemu acesse diretamente os discos.

rbd showmapped

Ele retorna algo nesse formato:

id pool namespace image snap device
0 rbd - vm220-d-0 - /dev/rbd0
1 rbd - vm220-d-1 - /dev/rbd1
10 rbd - vm324-d1 - /dev/rbd10
11 rbd - vm324-d0 - /dev/rbd11
12 rbd - vm324-d3 - /dev/rbd12
13 rbd - vm578-d0 - /dev/rbd13
2 rbd - vm670-d1 - /dev/rbd2
3 rbd - vm19-d0 - /dev/rbd3

Nesse nó eu não identifiquei a imagem vm100-d1 ou vm100-d0 sendo usada, porém ainda tinha de testar mais 9 nós.

Como eu pretendia verificar em todos os nós, usei o seguinte comando diretamente via ssh e filtrando pela imagem que procurava - mudando o ip a cada nó - mas de modo a acelerar a tarefa:

ssh 192.168.100.x rbd showmapped  |grep vm100

Infelizmente ou felizmente nenhum dos nós estava utilizando a imagem, passei então pra outro procedimento que seria verificar onde a imagem poderia estar travada/locked, o rbd primeiro faz o lock para depois fazer o map.

rbd lock ls vm100-d0;rbd lock ls vm100-d1

E ele retornou, para cada um dos comandos:

  There is 1 exclusive lock on this image.
  Locker           ID                        Address
  client.2387462   auto 98345739485748734981 10.1.100.3:0/49587394

  There is 1 exclusive lock on this image.
  Locker           ID                        Address
  client.2387489   auto 98345739485748734983 10.1.100.1:0/49587394

Os ips diferentes se referem tanto ao nó de origem quanto ao nó de destino. Mostrando que o processo de migração realmente não foi concluído.

Resolvi então - lembre que a VM está parada - remover o lock das imagens

#rbd lock rm <imagem> <id> <locker>
rbd lock rm vm100-d0 auto\ 98345739485748734981 client.2387462 
rbd lock rm vm100-d0 auto\ 98345739485748734983 client.2387489 

Repeti o comando ‘lock ls’ para confirmar que nenhuma estava mais travada/locked. E decidi refazer o ‘object-map rebuild’ para reconstruir a imagem.

rbd object-map rebuild vm100-d0;rbd object-map rebuild vm100-d1

Dessa vez executou com sucesso, mostrando o percentual de progresso, antes ficava parado e não dava andamento.

Pedi a info de cada um dos discos para confirmar o rebuild e a remoção da mensagem de alerta na imagem.

rbd info vm100-d0

#Mensagem de retorno
#rbd image 'vm-110-disk-1':
#	size 850 GiB in 215200 objects
#	order 22 (4 MiB objects)
#	snapshot_count: 0
#	id: 5f57411b304a12
#	block_name_prefix: rbd_data.5f57411b304a12
#	format: 2
#	features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
#	op_features:
#	flags:
#	create_timestamp: Tue Apr 17 8:38:23 2018
#	access_timestamp: Tue Apr 17 8:38:23 2018
#	modify_timestamp: Tue Apr 17 8:38:23 2018

Confirmado todos os passos e discos, solicitei o reinicio da vm e tudo ocorreu com sucesso, serviços reetabelecidos.

qm start 100
  • Espero que esse artigo ajude alguém que possa a vir a ter o mesmo problema
  • CEPH v14
  • PVE 6.3

comments powered by Disqus