Usando Ceph como almacenamento en rede en proxectos con diferentes cargas, podemos atoparnos con varias tarefas que a primeira vista non parecen sinxelas nin triviais. Por exemplo:
- migración de datos do antigo Ceph a outro novo con uso parcial dos servidores anteriores no novo clúster;
- solución ao problema da asignación de espazo en disco en Ceph.
Tratando estes problemas, atopámonos coa necesidade de eliminar correctamente o OSD sen perder datos, o que é especialmente importante cando se tratan grandes cantidades de datos. Isto será discutido no artigo.
Os métodos descritos a continuación son relevantes para calquera versión de Ceph. Ademais, terase en conta o feito de que Ceph poida almacenar unha gran cantidade de datos: para evitar a perda de datos e outros problemas, algunhas accións "dividiranse" noutras.
Prefacio sobre OSD
Dado que dúas das tres receitas comentadas están dedicadas a OSD (), antes de mergullarse na parte práctica, brevemente sobre o que é en Ceph e por que é tan importante.
En primeiro lugar, hai que dicir que todo o clúster Ceph consta de moitos OSD. Canto máis haxa, maior será o volume de datos gratuítos en Ceph. É doado de entender dende aquí función principal OSD: Almacena datos de obxectos Ceph nos sistemas de ficheiros de todos os nodos do clúster e proporciona acceso á rede (para lectura, escritura e outras solicitudes).
Ao mesmo nivel, os parámetros de replicación establécense copiando obxectos entre diferentes OSD. E aquí podes atopar varios problemas, cuxas solucións serán discutidas a continuación.
Caso no 1. Elimina de forma segura o OSD do clúster Ceph sen perder datos
A necesidade de eliminar o OSD pode ser provocada pola eliminación do servidor do clúster -por exemplo, para substituílo por outro servidor-, que é o que nos pasou, dando lugar á redacción deste artigo. Así, o obxectivo final da manipulación é extraer todos os OSD e mons nun determinado servidor para que se poida deter.
Por comodidade e para evitar unha situación na que, mentres executamos comandos, cometemos un erro ao indicar o OSD necesario, estableceremos unha variable separada, cuxo valor será o número do OSD que se vai eliminar. Imos chamala ${ID} — aquí e abaixo, tal variable substitúe o número do OSD co que estamos a traballar.
Vexamos a condición antes de comezar a traballar:
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 eliminación do OSD, terás que facelo sen problemas reweight sobre el a cero. Deste xeito, reducimos a cantidade de datos no OSD equilibrándoo con outros OSD. Para facelo, 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 así ata cero.
É necesario un equilibrio suavepara non perder datos. Isto é especialmente certo se o OSD contén unha gran cantidade de datos. Para asegurarse de que despois de executar os comandos reweight todo foi ben, podes completalo ceph -s ou nunha xanela de terminal separada ceph -w para observar os cambios en tempo real.
Cando o OSD estea "baleirado", pode continuar coa operación estándar para eliminalo. Para iso, transfire o OSD desexado ao estado down:
ceph osd down osd.${ID}"Saquemos" o OSD do clúster:
ceph osd out osd.${ID}Detemos o servizo OSD e desmontemos a súa partición no FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Eliminar OSD de :
ceph osd crush remove osd.${ID}Imos eliminar o usuario OSD:
ceph auth del osd.${ID}E finalmente, eliminemos o propio OSD:
ceph osd rm osd.${ID}Nota: Se está a usar a versión Ceph Luminous ou superior, os pasos de eliminación de OSD anteriores pódense reducir a dous comandos:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Se, despois de completar os pasos descritos anteriormente, executa o comando ceph osd tree, entón debe quedar claro que no servidor onde se realizou o traballo xa non hai OSD para os que se realizaron as operacións anteriores:
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 camiño, teña en conta que o estado do clúster Ceph irá HEALTH_WARN, e tamén veremos unha diminución no número de OSD e na cantidade de espazo dispoñible no disco.
A continuación describiranse os pasos que serán necesarios se quere deter completamente o servidor e, en consecuencia, eliminalo de Ceph. Neste caso, é importante lembralo Antes de apagar o servidor, debes eliminar todos os OSD neste servidor.
Se non quedan máis OSD neste servidor, despois de eliminalos, debes excluír o servidor do mapa OSD hv-2executando o seguinte comando:
ceph osd crush rm hv-2
Eliminar mon dende o servidor hv-2executando o seguinte comando noutro servidor (é dicir, neste caso, en hv-1):
ceph-deploy mon destroy hv-2Despois diso, podes deter o servidor e comezar as accións posteriores (re-implementalo, etc.).
Caso no 2. Distribución de espazo en disco nun clúster Ceph xa creado
Comezo a segunda historia cun prefacio sobre PG (). O papel principal de PG en Ceph é principalmente agregar obxectos Ceph e replicalos aínda máis en OSD. A fórmula coa que pode calcular a cantidade necesaria de PG está en Documentación Ceph. Este tema tamén se discute alí con exemplos específicos.
Entón: un dos problemas comúns ao usar Ceph é o número desequilibrado de OSD e PG entre grupos en Ceph.
En primeiro lugar, por iso, pode xurdir unha situación cando se especifican demasiadas PG nun grupo pequeno, o que é esencialmente un uso irracional do espazo en disco no clúster. En segundo lugar, na práctica hai un problema máis grave: desbordamento de datos nun dos OSD. Isto implica a primeira transición do clúster ao estado HEALTH_WARN, e despois HEALTH_ERR. A razón diso é que Ceph, ao calcular a cantidade de datos dispoñible (pode averiguala mediante MAX AVAIL na saída do comando ceph df para cada grupo por separado) baséase na cantidade de datos dispoñibles no OSD. Se non hai espazo suficiente en polo menos un OSD, non se poden escribir máis datos ata que os datos se distribúan correctamente entre todos os OSD.
Paga a pena aclarar que estes problemas decídense en gran medida na fase de configuración do clúster Ceph. Unha das ferramentas que podes usar é . Coa súa axuda, calcúlase claramente a cantidade necesaria de PG. Non obstante, tamén podes recorrer a ela nunha situación na que o cluster Ceph xa configurado incorrectamente. Paga a pena aclarar aquí que, como parte do traballo de corrección, probablemente teña que reducir o número de PG, e esta función non está dispoñible nas versións antigas de Ceph (só apareceu na versión ).
Entón, imaxinemos a seguinte imaxe: o clúster ten un estado HEALTH_WARN debido a que un dos OSD queda sen espazo. Isto indicarase mediante un erro HEALTH_WARN: 1 near full osd. A continuación móstrase un algoritmo para saír desta situación.
En primeiro lugar, cómpre distribuír os datos dispoñibles entre os OSD restantes. Xa realizamos unha operación similar no primeiro caso, cando "drenamos" o nodo, coa única diferenza de que agora teremos que reducir lixeiramente reweight. Por exemplo, ata 0.95:
ceph osd reweight osd.${ID} 0.95Isto libera espazo no disco no OSD e soluciona o erro na saúde de ceph. Non obstante, como xa se mencionou, este problema prodúcese principalmente debido a unha configuración incorrecta de Ceph nas fases iniciais: é moi importante facer unha reconfiguración para que non apareza no futuro.
No noso caso particular, todo se reduce a:
- valor demasiado alto
replication_countnunha das piscinas, - demasiado PG nunha piscina e pouco noutra.
Usemos a calculadora xa mencionada. Mostra claramente o que hai que introducir e, en principio, non hai nada complicado. Despois de establecer os parámetros necesarios, obtemos as seguintes recomendacións:
Nota: Se está a configurar un clúster Ceph desde cero, outra función útil da calculadora é a xeración de comandos que crearán grupos desde cero cos parámetros especificados na táboa.
A última columna axúdache a navegar - Reconto de PG suxerido. No noso caso tamén é útil o segundo, onde se indica o parámetro de replicación, xa que decidimos cambiar o multiplicador de replicación.
Entón, primeiro cómpre cambiar os parámetros de replicación; primeiro paga a pena facelo, xa que ao reducir o multiplicador, liberaremos espazo no disco. A medida que se executa o comando, notarás que o espazo dispoñible no disco aumentará:
ceph osd pool $pool_name set $replication_size
E despois da súa finalización, cambiamos os valores dos parámetros pg_num и pgp_num do seguinte xeito:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberÉ importante: debemos cambiar o número de PGs secuencialmente en cada grupo e non cambiar os valores noutros grupos ata que desaparezan os avisos "Redundancia de datos degradada" и "n-número de páxinas degradadas".
Tamén podes comprobar que todo foi ben usando as saídas do comando ceph health detail и ceph -s.
Caso no 3. Migración dunha máquina virtual de LVM a Ceph RBD
Nunha situación na que un proxecto utiliza máquinas virtuais instaladas en servidores bare-metal alugados, a miúdo xorde o problema do almacenamento tolerante a fallos. Tamén é moi desexable que haxa espazo suficiente neste almacenamento... Outra situación habitual: hai unha máquina virtual con almacenamento local no servidor e cómpre ampliar o disco, pero non hai onde ir, porque non hai espazo libre no disco no servidor.
O problema pódese resolver de diferentes xeitos, por exemplo, migrando a outro servidor (se o hai) ou engadindo novos discos ao servidor. Pero non sempre é posible facelo, polo que migrar de LVM a Ceph pode ser unha excelente solución para este problema. Ao escoller esta opción, tamén simplificamos o proceso posterior de migración entre servidores, xa que non será necesario mover o almacenamento local dun hipervisor a outro. O único problema é que terás que deter a VM mentres se realiza o traballo.
A seguinte receita está tirada de , cuxas instrucións foron probadas en acción. Por certo, alí tamén se describe o método de migración sen problemas, porén, no noso caso simplemente non era necesario, polo que non o verificamos. Se isto é fundamental para o teu proxecto, estaremos encantados de coñecer os resultados nos comentarios.
Pasemos á parte práctica. No exemplo usamos virsh e, en consecuencia, libvirt. En primeiro lugar, asegúrese de que o grupo Ceph ao que se migrarán os datos estea conectado a libvirt:
virsh pool-dumpxml $ceph_poolA descrición do grupo debe conter datos de conexión a Ceph con datos de autorización.
O seguinte paso é que a imaxe LVM se converta en Ceph RBD. O tempo de execución depende principalmente do tamaño da imaxe:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_nameDespois da conversión, permanecerá unha imaxe LVM, que será útil se a migración da VM a RBD falla e tes que revertir os cambios. Ademais, para poder revertir rapidamente os cambios, fagamos unha copia de seguridade do ficheiro de configuración da máquina virtual:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml
... e edita o orixinal (vm_name.xml). Imos atopar un bloque cunha descrición do disco (comeza coa liña <disk type='file' device='disk'> e remata con </disk>) e redúceo á 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>Vexamos algúns detalles:
- Ao protocolo
sourceindícase o enderezo do almacenamento en Ceph RBD (este é o enderezo que indica o nome do grupo Ceph e a imaxe RBD, que se determinou na primeira fase). - No bloque
secretindícase o tipoceph, así como o UUID do segredo para conectarse a el. O seu uuid pódese atopar usando o comandovirsh secret-list. - No bloque
hostindícanse os enderezos aos monitores Ceph.
Despois de editar o ficheiro de configuración e completar a conversión de LVM a RBD, pode aplicar o ficheiro de configuración modificado e iniciar a máquina virtual:
virsh define $vm_name.xml
virsh start $vm_name
É hora de comprobar que a máquina virtual comezou correctamente: podes averiguarlo, por exemplo, conectándote a ela a través de SSH ou a través de virsh.
Se a máquina virtual funciona correctamente e non atopou ningún outro problema, pode eliminar a imaxe LVM que xa non se utiliza:
lvremove main/$vm_image_nameConclusión
Encontramos todos os casos descritos na práctica; esperamos que as instrucións axuden a outros administradores a resolver problemas similares. Se tes comentarios ou outras historias similares da túa experiencia usando Ceph, estaremos encantados de velos nos comentarios.
PS
Lea tamén no noso blog:
- «»;
- «»;
- «»;
- «».
Fonte: www.habr.com