Genom att använda Ceph som nätverkslagring i projekt med olika belastningar kan vi stöta på olika uppgifter som vid första anblicken inte verkar enkla eller triviala. Till exempel:
- migrering av data från gamla Ceph till nya med partiell användning av tidigare servrar i det nya klustret;
- lösning på problemet med diskutrymmesallokering i Ceph.
När vi hanterar sådana problem står vi inför behovet av att korrekt ta bort OSD utan att förlora data, vilket är särskilt viktigt när vi hanterar stora mängder data. Detta kommer att diskuteras i artikeln.
Metoderna som beskrivs nedan är relevanta för alla versioner av Ceph. Dessutom kommer det faktum att Ceph kan lagra en stor mängd data att beaktas: för att förhindra dataförlust och andra problem kommer vissa åtgärder att "delas upp" i flera andra.
Förord om OSD
Eftersom två av de tre diskuterade recepten är dedikerade till OSD (), innan du dyker in i den praktiska delen - kortfattat om vad det är i Ceph och varför det är så viktigt.
Först och främst ska det sägas att hela Ceph-klustret består av många OSD:er. Ju fler det finns, desto större är den fria datavolymen i Ceph. Det är lätt att förstå härifrån huvud OSD-funktion: Den lagrar Ceph-objektdata i filsystemen för alla klusternoder och ger nätverksåtkomst till den (för läsning, skrivning och andra förfrågningar).
På samma nivå ställs replikeringsparametrar genom att kopiera objekt mellan olika OSD:er. Och här kan du stöta på olika problem, vars lösningar kommer att diskuteras nedan.
Mål nr 1. Ta bort OSD på ett säkert sätt från Ceph-klustret utan att förlora data
Behovet av att ta bort OSD kan orsakas av att servern tas bort från klustret - till exempel för att ersätta den med en annan server - vilket är vad som hände oss, vilket ledde till att denna artikel skrevs. Det slutliga målet med manipulation är alltså att extrahera alla OSD:er och mons på en given server så att den kan stoppas.
För enkelhetens skull och för att undvika en situation där vi, när vi utför kommandon, gör ett misstag när vi anger önskad OSD, kommer vi att ställa in en separat variabel, vars värde kommer att vara numret på den OSD som ska raderas. Låt oss ringa henne ${ID} — här och nedan ersätter en sådan variabel numret på OSD som vi arbetar med.
Låt oss titta på tillståndet innan vi börjar arbeta:
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
För att initiera borttagning av OSD, måste du utföra smidigt reweight på den till noll. På så sätt minskar vi mängden data i OSD genom att balansera den mot andra OSD. För att göra detta, kör följande kommandon:
ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78... och så vidare till noll.
Smidig balansering krävsför att inte förlora data. Detta gäller särskilt om OSD innehåller en stor mängd data. För att se till att efter att ha utfört kommandona reweight allt gick bra, du kan slutföra det ceph -s eller i en separat terminalfönsterkörning ceph -w för att observera förändringar i realtid.
När OSD är "tömd" kan du fortsätta med standardåtgärden för att ta bort den. För att göra detta, överför önskad OSD till tillståndet down:
ceph osd down osd.${ID}Låt oss "dra" OSD ut ur klustret:
ceph osd out osd.${ID}Låt oss stoppa OSD-tjänsten och avmontera dess partition i FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Ta bort OSD från :
ceph osd crush remove osd.${ID}Låt oss ta bort OSD-användaren:
ceph auth del osd.${ID}Och slutligen, låt oss ta bort själva OSD:
ceph osd rm osd.${ID}Notera: Om du använder Ceph Luminous version eller högre, kan ovanstående OSD-borttagningsstegen reduceras till två kommandon:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Om du, efter att ha slutfört stegen som beskrivs ovan, kör kommandot ceph osd tree, då bör det vara tydligt att på servern där arbetet utfördes finns det inte längre OSD:er för vilka ovanstående operationer utfördes:
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
Längs vägen, notera att tillståndet för Ceph-klustret kommer att gå till HEALTH_WARN, och vi kommer också att se en minskning av antalet OSD:er och mängden tillgängligt diskutrymme.
Följande kommer att beskriva de steg som kommer att krävas om du vill stoppa servern helt och följaktligen ta bort den från Ceph. I det här fallet är det viktigt att komma ihåg det Innan du stänger av servern måste du ta bort alla OSD:er på denna server.
Om det inte finns fler OSD:er kvar på den här servern måste du utesluta servern från OSD-kartan efter att ha tagit bort dem hv-2genom att köra följande kommando:
ceph osd crush rm hv-2
Radera mon från servern hv-2genom att köra kommandot nedan på en annan server (dvs i det här fallet på hv-1):
ceph-deploy mon destroy hv-2Efter detta kan du stoppa servern och påbörja efterföljande åtgärder (ominstallera den, etc.).
Mål nr 2. Fördelning av diskutrymme i ett redan skapat Ceph-kluster
Jag börjar den andra berättelsen med ett förord om PG (). Huvudrollen för PG i Ceph är i första hand att aggregera Ceph-objekt och ytterligare replikera dem i OSD. Formeln med vilken du kan beräkna den nödvändiga mängden PG finns i Ceph dokumentation. Även denna fråga diskuteras där med konkreta exempel.
Så: ett av de vanliga problemen när man använder Ceph är det obalanserade antalet OSD och PG mellan pooler i Ceph.
För det första, på grund av detta, kan en situation uppstå när för många PG:er specificeras i en liten pool, vilket i huvudsak är en irrationell användning av diskutrymme i klustret. För det andra finns det i praktiken ett allvarligare problem: dataspill i en av OSD:erna. Detta innebär att klustret först övergår till staten HEALTH_WARN, och då HEALTH_ERR. Anledningen till detta är att Ceph, när man beräknar den tillgängliga mängden data (du kan ta reda på det genom MAX AVAIL i kommandoutgången ceph df för varje pool separat) baseras på mängden tillgänglig data i OSD. Om det inte finns tillräckligt med utrymme i minst en OSD, kan inte mer data skrivas förrän data är korrekt fördelade mellan alla OSD:er.
Det är värt att klargöra att dessa problem bestäms till stor del i Ceph-klusterkonfigurationsstadiet. Ett av verktygen du kan använda är . Med dess hjälp beräknas den nödvändiga mängden PG tydligt. Men du kan också ta till det i en situation där Ceph-klustret redan felaktigt konfigurerad. Det är värt att förtydliga här att som en del av korrigeringsarbetet kommer du sannolikt att behöva minska antalet PG:er, och den här funktionen är inte tillgänglig i äldre versioner av Ceph (den dök bara upp i version ).
Så låt oss föreställa oss följande bild: klustret har en status HEALTH_WARN på grund av att en av OSD:erna har slut på utrymme. Detta kommer att indikeras av ett fel HEALTH_WARN: 1 near full osd. Nedan finns en algoritm för att komma ur den här situationen.
Först och främst måste du distribuera tillgängliga data mellan de återstående OSD:erna. Vi utförde redan en liknande operation i det första fallet, när vi "tömde" noden - med den enda skillnaden att nu måste vi minska något reweight. Till exempel, upp till 0.95:
ceph osd reweight osd.${ID} 0.95Detta frigör diskutrymme i OSD och åtgärdar felet i ceph-hälsan. Men som redan nämnts uppstår detta problem främst på grund av felaktig konfiguration av Ceph i de inledande stadierna: det är mycket viktigt att göra en omkonfiguration så att den inte dyker upp i framtiden.
I vårt specifika fall kom det hela till:
- värde för högt
replication_counti en av poolerna, - för mycket PG i en pool och för lite i en annan.
Låt oss använda den redan nämnda kalkylatorn. Det visar tydligt vad som behöver matas in och i princip är det inget komplicerat. Efter att ha ställt in de nödvändiga parametrarna får vi följande rekommendationer:
Notera: Om du ställer in ett Ceph-kluster från början, är en annan användbar funktion i räknaren genereringen av kommandon som skapar pooler från grunden med de parametrar som anges i tabellen.
Den sista kolumnen hjälper dig att navigera - Föreslaget antal PG. I vårt fall är den andra också användbar, där replikeringsparametern anges, eftersom vi bestämde oss för att ändra replikeringsmultiplikatorn.
Så först måste du ändra replikeringsparametrarna - detta är värt att göra först, eftersom genom att minska multiplikatorn kommer vi att frigöra diskutrymme. När kommandot körs kommer du att märka att det tillgängliga diskutrymmet ökar:
ceph osd pool $pool_name set $replication_size
Och efter att den är klar ändrar vi parametervärdena pg_num и pgp_num enligt följande:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberDet är viktigt: vi måste ändra antalet PGs sekventiellt i varje pool och inte ändra värdena i andra pooler förrän varningarna försvinner "Försämrad dataredundans" и "n-antal sidor försämrade".
Du kan också kontrollera att allt gick bra med hjälp av kommandoutgångarna ceph health detail и ceph -s.
Mål nr 3. Migrera en virtuell maskin från LVM till Ceph RBD
I en situation där ett projekt använder virtuella maskiner installerade på hyrda bare-metal-servrar, uppstår ofta problemet med feltolerant lagring. Det är också mycket önskvärt att det finns tillräckligt med utrymme i denna lagring... En annan vanlig situation: det finns en virtuell maskin med lokal lagring på servern och du behöver utöka disken, men det finns ingenstans att ta vägen, eftersom det inte finns någon ledigt diskutrymme kvar på servern.
Problemet kan lösas på olika sätt – till exempel genom att migrera till en annan server (om det finns en) eller lägga till nya diskar på servern. Men det är inte alltid möjligt att göra detta, så att migrera från LVM till Ceph kan vara en utmärkt lösning på detta problem. Genom att välja det här alternativet förenklar vi också den vidare processen för migrering mellan servrar, eftersom det inte finns något behov av att flytta lokal lagring från en hypervisor till en annan. Den enda haken är att du måste stoppa den virtuella datorn medan arbetet utförs.
Följande recept är hämtat från , vars instruktioner har testats i praktiken. Förresten, metoden för problemfri migration beskrivs också där, men i vårt fall behövdes det helt enkelt inte, så vi kontrollerade det inte. Om detta är avgörande för ditt projekt, kommer vi gärna att höra om resultatet i kommentarerna.
Låt oss gå vidare till den praktiska delen. I exemplet använder vi virsh och följaktligen libvirt. Se först till att Ceph-poolen som data ska migreras till är ansluten till libvirt:
virsh pool-dumpxml $ceph_poolPoolbeskrivningen ska innehålla anslutningsdata till Ceph med behörighetsdata.
Nästa steg är att LVM-bilden konverteras till Ceph RBD. Exekveringstiden beror främst på bildens storlek:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_nameEfter konverteringen kommer en LVM-bild att finnas kvar, vilket kommer att vara användbart om migreringen av den virtuella datorn till RBD misslyckas och du måste återställa ändringarna. För att snabbt kunna återställa ändringar, låt oss också göra en säkerhetskopia av den virtuella maskinens konfigurationsfil:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml
... och redigera originalet (vm_name.xml). Låt oss hitta ett block med en beskrivning av disken (börjar med raden <disk type='file' device='disk'> och slutar med </disk>) och reducera den till följande form:
<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>Låt oss titta på några detaljer:
- Till protokollet
sourceadressen till lagringen i Ceph RBD anges (detta är adressen som anger namnet på Ceph-poolen och RBD-bilden, som fastställdes i det första steget). - I kvarteret
secrettyp angesceph, samt UUID för hemligheten för att ansluta till den. Dess uuid kan hittas med kommandotvirsh secret-list. - I kvarteret
hostadresser till Ceph-monitorer anges.
Efter att ha redigerat konfigurationsfilen och slutfört konverteringen från LVM till RBD kan du tillämpa den modifierade konfigurationsfilen och starta den virtuella maskinen:
virsh define $vm_name.xml
virsh start $vm_name
Det är dags att kontrollera att den virtuella maskinen startade korrekt: du kan till exempel ta reda på det genom att ansluta till den via SSH eller via virsh.
Om den virtuella maskinen fungerar korrekt och du inte har hittat några andra problem, kan du ta bort LVM-bilden som inte längre används:
lvremove main/$vm_image_nameSlutsats
Vi stötte på alla beskrivna fall i praktiken - vi hoppas att instruktionerna kommer att hjälpa andra administratörer att lösa liknande problem. Om du har kommentarer eller andra liknande berättelser från din erfarenhet av att använda Ceph, kommer vi gärna att se dem i kommentarerna!
PS
Läs även på vår blogg:
- «";
- «";
- «";
- «".
Källa: will.com