Utilitzant Ceph com a emmagatzematge de xarxa en projectes amb diferents càrregues, ens podem trobar amb diverses tasques que a primera vista no semblen senzilles ni trivials. Per exemple:
- migració de dades de l'antic Ceph a un de nou amb ús parcial dels servidors anteriors del nou clúster;
- solució al problema de l'assignació d'espai en disc a Ceph.
En tractar aquests problemes, ens enfrontem a la necessitat d'eliminar correctament l'OSD sense perdre dades, cosa que és especialment important quan es tracta de grans quantitats de dades. Això es discutirà a l'article.
Els mètodes que es descriuen a continuació són rellevants per a qualsevol versió de Ceph. A més, es tindrà en compte el fet que Ceph pugui emmagatzemar una gran quantitat de dades: per evitar la pèrdua de dades i altres problemes, algunes accions es "dividiran" en diverses altres.
Pròleg sobre OSD
Com que dues de les tres receptes comentades estan dedicades a OSD (), abans d'aprofundir en la part pràctica: breument sobre què és a Ceph i per què és tan important.
En primer lloc, cal dir que tot el clúster Ceph consta de molts OSD. Com més n'hi ha, més gran serà el volum de dades gratuïtes a Ceph. És fàcil d'entendre des d'aquí funció OSD principal: Emmagatzema les dades d'objectes Ceph als sistemes de fitxers de tots els nodes del clúster i hi proporciona accés a la xarxa (per llegir, escriure i altres peticions).
Al mateix nivell, els paràmetres de replicació s'estableixen copiant objectes entre diferents OSD. I aquí podeu trobar-vos amb diversos problemes, les solucions als quals es discutiran a continuació.
Cas núm. 1. Elimineu l'OSD de forma segura del clúster Ceph sense perdre dades
La necessitat d'eliminar l'OSD pot ser provocada per l'eliminació del servidor del clúster -per exemple, per substituir-lo per un altre servidor-, que és el que ens va passar, donant lloc a la redacció d'aquest article. Així, l'objectiu final de la manipulació és extreure tots els OSD i mons d'un servidor determinat perquè es pugui aturar.
Per comoditat i per evitar una situació en què, mentre executem ordres, cometem un error en indicar l'OSD requerit, establirem una variable separada, el valor de la qual serà el número de l'OSD a eliminar. Anem a cridar-la ${ID} — aquí i a continuació, aquesta variable substitueix el número de l'OSD amb el qual estem treballant.
Vegem l'estat abans de començar a treballar:
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
Per iniciar l'eliminació de l'OSD, haureu de fer-ho sense problemes reweight sobre ell a zero. D'aquesta manera, reduïm la quantitat de dades a l'OSD equilibrant-les amb altres OSD. Per fer-ho, executeu les ordres següents:
ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78... i així fins a zero.
Cal un equilibri suauper no perdre dades. Això és especialment cert si l'OSD conté una gran quantitat de dades. Per assegurar-se que després d'executar les ordres reweight tot ha anat bé, pots completar-ho ceph -s o en una finestra de terminal independent ceph -w per observar els canvis en temps real.
Quan l'OSD estigui "buidat", podeu continuar amb l'operació estàndard per eliminar-lo. Per fer-ho, transferiu l'OSD desitjat a l'estat down:
ceph osd down osd.${ID}"Treurem" l'OSD del clúster:
ceph osd out osd.${ID}Aturem el servei OSD i desmuntem la seva partició al FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Elimina l'OSD de :
ceph osd crush remove osd.${ID}Suprimim l'usuari OSD:
ceph auth del osd.${ID}I, finalment, eliminem el propi OSD:
ceph osd rm osd.${ID}Nota: Si utilitzeu la versió Ceph Luminous o superior, els passos d'eliminació de l'OSD anteriors es poden reduir a dues ordres:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Si, després de completar els passos descrits anteriorment, executeu l'ordre ceph osd tree, llavors hauria de quedar clar que al servidor on s'ha realitzat el treball ja no hi ha OSD per als quals s'hagin realitzat les operacions anteriors:
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
Durant el camí, tingueu en compte que anirà a l'estat del clúster Ceph HEALTH_WARN, i també veurem una disminució en el nombre d'OSD i la quantitat d'espai disponible en disc.
A continuació es descriuen els passos que caldrà si voleu aturar completament el servidor i, en conseqüència, eliminar-lo de Ceph. En aquest cas, és important recordar-ho Abans d'apagar el servidor, heu d'eliminar tots els OSD en aquest servidor.
Si no queden més OSD en aquest servidor, després d'eliminar-los, heu d'excloure el servidor del mapa OSD hv-2executant l'ordre següent:
ceph osd crush rm hv-2
Suprimeix mon des del servidor hv-2executant l'ordre següent en un altre servidor (és a dir, en aquest cas, a hv-1):
ceph-deploy mon destroy hv-2Després d'això, podeu aturar el servidor i començar accions posteriors (tornar-lo a desplegar, etc.).
Cas núm 2. Distribució de l'espai en disc en un clúster Ceph ja creat
Començaré la segona història amb un prefaci sobre PG (). El paper principal de PG a Ceph és principalment agregar objectes Ceph i replicar-los encara més en OSD. La fórmula amb la qual podeu calcular la quantitat necessària de PG es troba Documentació Ceph. Aquest tema també es tracta allà amb exemples concrets.
Per tant: un dels problemes habituals quan s'utilitza Ceph és el nombre desequilibrat d'OSD i PG entre grups de Ceph.
En primer lloc, per això, pot sorgir una situació quan s'especifiquen massa PG en un grup petit, que és essencialment un ús irracional de l'espai de disc al clúster. En segon lloc, a la pràctica hi ha un problema més greu: el desbordament de dades en un dels OSD. Això implica que el clúster passi primer a l'estat HEALTH_WARN, i llavors HEALTH_ERR. El motiu d'això és que Ceph, quan calcula la quantitat de dades disponible (pots esbrinar-ho per MAX AVAIL a la sortida d'ordres ceph df per a cada grup per separat) es basa en la quantitat de dades disponibles a l'OSD. Si no hi ha prou espai en almenys un OSD, no es poden escriure més dades fins que les dades es distribueixin correctament entre tots els OSD.
Val la pena aclarir que aquests problemes es decideixen en gran part en l'etapa de configuració del clúster Ceph. Una de les eines que podeu utilitzar és . Amb la seva ajuda, es calcula clarament la quantitat necessària de PG. Tanmateix, també podeu recórrer-hi en una situació en què el cluster Ceph ja configurat incorrectament. Val la pena aclarir aquí que, com a part del treball de correcció, probablement haureu de reduir el nombre de PG, i aquesta característica no està disponible a les versions anteriors de Ceph (només va aparèixer a la versió). ).
Per tant, imaginem la següent imatge: el clúster té un estat HEALTH_WARN a causa d'un dels OSD que es queda sense espai. Això s'indicarà amb un error HEALTH_WARN: 1 near full osd. A continuació es mostra un algorisme per sortir d'aquesta situació.
En primer lloc, heu de distribuir les dades disponibles entre els OSD restants. Ja vam realitzar una operació similar en el primer cas, quan vam "drenar" el node, amb l'única diferència que ara haurem de reduir lleugerament reweight. Per exemple, fins a 0.95:
ceph osd reweight osd.${ID} 0.95Això allibera espai en disc a l'OSD i corregeix l'error de salut de ceph. Tanmateix, com ja s'ha comentat, aquest problema es produeix principalment per una configuració incorrecta de Ceph en les etapes inicials: és molt important fer una reconfiguració perquè no aparegui en el futur.
En el nostre cas particular, tot es va reduir a:
- valor massa alt
replication_counten una de les piscines, - massa PG en una piscina i massa poc en una altra.
Utilitzem la calculadora ja esmentada. Mostra clarament què cal introduir i, en principi, no hi ha res complicat. Un cop establerts els paràmetres necessaris, obtenim les següents recomanacions:
Nota: Si esteu configurant un clúster Ceph des de zero, una altra funció útil de la calculadora és la generació d'ordres que crearan grups des de zero amb els paràmetres especificats a la taula.
L'última columna us ajuda a navegar - Recompte de PG suggerit. En el nostre cas també és útil el segon, on s'indica el paràmetre de replicació, ja que hem decidit canviar el multiplicador de replicació.
Per tant, primer heu de canviar els paràmetres de replicació; primer val la pena fer-ho, ja que reduint el multiplicador, alliberarem espai al disc. A mesura que s'executa l'ordre, notareu que augmentarà l'espai disponible en disc:
ceph osd pool $pool_name set $replication_size
I un cop finalitzada, canviem els valors dels paràmetres pg_num и pgp_num de la manera següent:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberÉs important: hem de canviar el nombre de PGs seqüencialment a cada pool i no canviar els valors en altres pools fins que desapareguin els avisos "Redundància de dades degradada" и "n-nombre de pàgines degradades".
També podeu comprovar que tot ha anat bé mitjançant les sortides de l'ordre ceph health detail и ceph -s.
Cas núm 3. Migració d'una màquina virtual de LVM a Ceph RBD
En una situació en què un projecte utilitza màquines virtuals instal·lades en servidors de metall nu llogats, sovint sorgeix el problema de l'emmagatzematge tolerant a errors. També és molt desitjable que hi hagi prou espai en aquest emmagatzematge... Una altra situació habitual: hi ha una màquina virtual amb emmagatzematge local al servidor i cal ampliar el disc, però no hi ha on anar, perquè no hi ha espai lliure al disc al servidor.
El problema es pot resoldre de diferents maneres, per exemple, migrant a un altre servidor (si n'hi ha) o afegint nous discs al servidor. Però no sempre és possible fer-ho, de manera que migrar de LVM a Ceph pot ser una solució excel·lent a aquest problema. En triar aquesta opció, també simplifiquem el procés posterior de migració entre servidors, ja que no caldrà moure l'emmagatzematge local d'un hipervisor a un altre. L'únic problema és que haureu d'aturar la VM mentre es duu a terme el treball.
La següent recepta està extreta de , les instruccions de les quals s'han provat en acció. A propòsit, també s'hi descriu el mètode de migració sense problemes, però, en el nostre cas simplement no era necessari, així que no ho vam comprovar. Si això és fonamental per al vostre projecte, estarem encantats de conèixer els resultats als comentaris.
Passem a la part pràctica. A l'exemple fem servir virsh i, en conseqüència, libvirt. Primer, assegureu-vos que el grup Ceph al qual es migraran les dades estigui connectat a libvirt:
virsh pool-dumpxml $ceph_poolLa descripció del grup ha de contenir dades de connexió a Ceph amb dades d'autorització.
El següent pas és que la imatge LVM es converteixi a Ceph RBD. El temps d'execució depèn principalment de la mida de la imatge:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_nameDesprés de la conversió, es mantindrà una imatge LVM, que serà útil si la migració de la VM a RBD falla i heu de revertir els canvis. A més, per poder revertir ràpidament els canvis, fem una còpia de seguretat del fitxer de configuració de la màquina virtual:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml
... i edita l'original (vm_name.xml). Busquem un bloc amb una descripció del disc (comencen amb la línia <disk type='file' device='disk'> i acaba amb </disk>) i reduir-lo a la forma següent:
<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>Vegem alguns detalls:
- Al protocol
sources'indica l'adreça de l'emmagatzematge a Ceph RBD (aquesta és l'adreça que indica el nom del grup Ceph i la imatge RBD, que es va determinar en la primera etapa). - Al bloc
secrets'indica el tipusceph, així com l'UUID del secret per connectar-s'hi. El seu uuid es pot trobar mitjançant l'ordrevirsh secret-list. - Al bloc
hosts'indiquen les adreces als monitors de Ceph.
Després d'editar el fitxer de configuració i completar la conversió de LVM a RBD, podeu aplicar el fitxer de configuració modificat i iniciar la màquina virtual:
virsh define $vm_name.xml
virsh start $vm_name
És el moment de comprovar que la màquina virtual s'ha iniciat correctament: ho podeu saber, per exemple, connectant-hi mitjançant SSH o mitjançant virsh.
Si la màquina virtual funciona correctament i no heu trobat cap altre problema, podeu eliminar la imatge LVM que ja no s'utilitza:
lvremove main/$vm_image_nameConclusió
Ens hem trobat amb tots els casos descrits a la pràctica: esperem que les instruccions ajudin altres administradors a resoldre problemes similars. Si teniu comentaris o altres històries similars de la vostra experiència amb Ceph, estarem encantats de veure'ls als comentaris!
PS
Llegeix també al nostre blog:
- «»;
- «»;
- «»;
- «».
Font: www.habr.com