Mat Ceph als Netzwierklagerung a Projete mat verschiddene Lasten kënne mir verschidden Aufgaben begéinen, déi op den éischte Bléck net einfach oder trivial schéngen. Zum Beispill:
- Migratioun vun Donnéeën aus al Ceph zu engem neie mat deelweis Notzung vun virdrun Serveren am neie Stärekoup;
- Léisung fir de Problem vun der Disk Space Allocation am Ceph.
Wann Dir mat esou Probleemer këmmert, si mir konfrontéiert mat der Bedierfnes fir den OSD korrekt ze läschen ouni Daten ze verléieren, wat besonnesch wichteg ass wann Dir mat grousse Quantitéiten un Daten handelt. Dëst wäert am Artikel diskutéiert ginn.
D'Methoden hei ënnendrënner beschriwwe sinn relevant fir all Versioun vum Ceph. Zousätzlech gëtt d'Tatsaach berücksichtegt datt Ceph eng grouss Quantitéit un Daten späichere kann: fir Datenverloscht an aner Probleemer ze verhënneren, ginn e puer Aktiounen an e puer aner "opgedeelt".
Virwuert iwwer OSD
Zënter zwee vun den dräi diskutéierte Rezepter sinn OSD gewidmet (), ier Dir an de prakteschen Deel daucht - kuerz iwwer wat et am Ceph ass a firwat et sou wichteg ass.
Als éischt sollt et gesot ginn datt de ganze Ceph-Cluster aus villen OSDs besteet. Wat méi et gëtt, wat méi grouss ass de gratis Datevolumen am Ceph. Et ass einfach ze verstoen vun hei Haapt OSD Funktioun: Et späichert Ceph-Objetdaten op de Dateiesystemer vun all Clusterknoten a bitt Netzwierkzougang derzou (fir Liesen, Schreiwen an aner Ufroen).
Um selwechten Niveau gi Replikatiounsparameter gesat andeems Objekter tëscht verschiddenen OSDs kopéiert ginn. An hei kënnt Dir verschidde Problemer begéinen, d'Léisungen fir déi hei ënnen diskutéiert ginn.
Fall Nummer 1. Sécher OSD aus Ceph Stärekoup ewechzehuelen ouni Daten Verléierer
De Besoin fir den OSD ze läschen kann verursaacht ginn andeems de Server aus dem Cluster ewechgeholl gëtt - zum Beispill, fir en duerch en anere Server ze ersetzen - wat ass wat mat eis geschitt ass, wat d'Schreiwe vun dësem Artikel entsteet. Also ass d'ultimativ Zil vun der Manipulatioun all OSDs a Mons op engem bestëmmte Server ze extrahieren sou datt et gestoppt ka ginn.
Fir d'Bequemlechkeet a fir eng Situatioun ze vermeiden, wou mir beim Ausféieren vun Kommandoen e Feeler maachen fir den erfuerderlechen OSD unzeweisen, setzen mir eng separat Variabel, dee Wäert ass d'Zuel vun der OSD déi geläscht gëtt. Loosst eis hir ruffen ${ID} - hei an ënnen, esou eng Variabel ersetzt d'Zuel vun der OSD mat deem mir schaffen.
Loosst eis d'Konditioun kucken ier Dir mat der Aarbecht ufänkt:
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
Fir d'OSD Entfernung unzefänken, musst Dir glat Leeschtunge reweight op et op null. Op dës Manéier reduzéiere mir d'Quantitéit vun Daten am OSD andeems se se op aner OSDs balancéieren. Fir dëst ze maachen, lafen déi folgend Kommandoen:
ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78... an esou weider bis null.
Glat Balance néidegfir net Daten ze verléieren. Dëst ass besonnesch wouer wann den OSD eng grouss Quantitéit un Daten enthält. Fir sécherzestellen datt nom Ausféierung vun de Kommandoen reweight alles goung gutt, Dir kënnt et fäerdeg bréngen ceph -s oder an enger separater Terminalfenster lafen ceph -w fir Ännerungen an Echtzäit ze observéieren.
Wann den OSD "eidel" ass, kënnt Dir mat der Standardoperatioun virgoen fir se ze läschen. Fir dëst ze maachen, transferéiert de gewënschten OSD an de Staat down:
ceph osd down osd.${ID}Loosst eis den OSD aus dem Cluster "zéien":
ceph osd out osd.${ID}Loosst eis den OSD Service stoppen a seng Partition an der FS unmount:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Ewechzehuelen OSD aus :
ceph osd crush remove osd.${ID}Loosst eis den OSD Benotzer läschen:
ceph auth del osd.${ID}A schliisslech loosst eis den OSD selwer ewechhuelen:
ceph osd rm osd.${ID}Remarque: Wann Dir Ceph Luminous Versioun oder méi héich benotzt, da kënnen déi uewe genannte OSD Entfernungsschrëtt op zwee Kommandoen reduzéiert ginn:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Wann Dir, nodeems Dir d'Schrëtt hei uewen beschriwwen hutt, de Kommando ausféiert ceph osd tree, da sollt et kloer sinn datt um Server, wou d'Aarbecht gemaach gouf, et keng OSDs méi sinn, fir déi déi uewe genannte Operatioune gemaach goufen:
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
Laanscht de Wee, Note datt de Staat vun der Ceph Stärekoup wäert goen HEALTH_WARN, a mir wäerten och eng Ofsenkung vun der Unzuel vun OSDs an der Quantitéit vum verfügbaren Disk Space gesinn.
Déi folgend beschreift d'Schrëtt déi erfuerderlech sinn wann Dir de Server komplett wëllt stoppen an deementspriechend aus Ceph ewechhuelen. An dësem Fall ass et wichteg ze erënneren Ier Dir de Server ausschalt, musst Dir all OSDs ewechhuelen op dësem Server.
Wann et keng OSDs méi op dësem Server sinn, da musst Dir de Server aus der OSD Kaart ausschléissen nodeems Dir se ewechgeholl hutt hv-2andeems Dir de folgende Kommando ausféiert:
ceph osd crush rm hv-2
Läschen mon vum Server hv-2andeems Dir de Kommando hei drënner op engem anere Server leeft (dh an dësem Fall op hv-1):
ceph-deploy mon destroy hv-2Duerno kënnt Dir de Server stoppen a spéider Aktiounen unzefänken (ne-deployéieren, asw.).
Fall Nummer 2. Verdeelung vun Disk Space an engem scho geschaf Ceph Cluster
Ech fänken déi zweet Geschicht mat engem Virwuert iwwer PG un (). D'Haaptroll vum PG am Ceph ass haaptsächlech fir Ceph Objeten ze aggregéieren an se weider an OSD ze replizéieren. D'Formel mat där Dir den erfuerderleche Betrag vu PG berechne kënnt ass an Ceph Dokumentatioun. Dëst Thema gëtt och do mat spezifesche Beispiller diskutéiert.
Also: ee vun de gemeinsame Probleemer wann Dir Ceph benotzt ass déi onbalancéiert Zuel vun OSD a PG tëscht Poolen am Ceph.
Als éischt, wéinst dësem, kann eng Situatioun entstoen wann ze vill PGs an engem klenge Pool spezifizéiert ginn, wat am Wesentlechen eng irrational Notzung vun Disk Space am Cluster ass. Zweetens, an der Praxis gëtt et e méi eeschte Problem: Dateniwwerfloss an engem vun den OSDs. Dëst beinhalt de Stärekoup éischten Iwwergang an de Staat HEALTH_WARN, an dann HEALTH_ERR. De Grond dofir ass datt de Ceph, wann Dir déi verfügbar Betrag vun Daten berechent (Dir kënnt et erausfannen duerch MAX AVAIL am Kommando Ausgang ceph df fir all Pool separat) baséiert op der Quantitéit vun verfügbaren Donnéeën am OSD. Wann et net genuch Plaz an mindestens engem OSD ass, kënne keng Donnéeë méi geschriwwe ginn bis d'Donnéeën richteg ënner all OSDs verdeelt sinn.
Et ass derwäert ze klären datt dës Problemer sinn haaptsächlech op der Ceph Stärekoup Configuratioun Etapp entscheet. Ee vun den Tools déi Dir benotze kënnt ass . Mat senger Hëllef gëtt déi erfuerderlech Quantitéit u PG kloer berechent. Wéi och ëmmer, Dir kënnt et och an enger Situatioun zréckgräifen wou de Ceph Cluster schonn falsch konfiguréiert. Et ass derwäert hei ze klären datt als Deel vun der Fixaarbecht Dir héchstwahrscheinlech d'Zuel vun de PGs reduzéiere musst, an dës Feature ass net an eeler Versioune vu Ceph verfügbar (et ass nëmmen an der Versioun erschéngt) ).
Also, loosst eis dat folgend Bild virstellen: de Stärekoup huet e Status HEALTH_WARN wéinst engem vun den OSD aus Plaz lafen. Dëst gëtt duerch e Feeler uginn HEALTH_WARN: 1 near full osd. Drënner ass en Algorithmus fir aus dëser Situatioun erauszekommen.
Als éischt musst Dir déi verfügbar Daten tëscht de verbleiwen OSDs verdeelen. Mir hunn schonn eng ähnlech Operatioun am éischte Fall gemaach, wa mir den Node "drainéiert" hunn - mam eenzegen Ënnerscheed datt mir elo liicht reduzéieren mussen reweight. Zum Beispill, bis zu 0.95:
ceph osd reweight osd.${ID} 0.95Dëst befreit Disk Space am OSD a fixéiert de Feeler an der Ceph Gesondheet. Wéi och ëmmer, wéi scho gesot, geschitt dëse Problem haaptsächlech wéinst der falscher Konfiguratioun vum Ceph an den initialen Etappen: et ass ganz wichteg eng Rekonfiguratioun ze maachen, sou datt et net an der Zukunft erscheint.
An eisem spezifesche Fall ass et alles erofgaangen:
- Wäert ze héich
replication_countan engem vun de Schwämm, - zevill PG an engem Pool an ze wéineg an engem aneren.
Loosst eis de scho genannte Rechner benotzen. Et weist kloer wat agefouert muss ginn an am Prinzip gëtt et näischt komplizéiert. Nodeems Dir déi néideg Parameter gesat hutt, kréien mir déi folgend Empfehlungen:
Remarque: Wann Dir e Ceph-Cluster vun Null opstellt, ass eng aner nëtzlech Funktioun vum Rechner d'Generatioun vu Kommandoen, déi Poole vun Null erstellen mat de Parameteren, déi an der Tabell spezifizéiert sinn.
Déi lescht Kolonn hëlleft Iech navigéieren - Proposéiert PG Grof. An eisem Fall ass déi zweet och nëtzlech, wou de Replikatiounsparameter uginn ass, well mir decidéiert hunn de Replikatiounsmultiplikator z'änneren.
Also, als éischt musst Dir d'Replikatiounsparameter änneren - dat ass et derwäert fir d'éischt ze maachen, well duerch d'Reduktioun vum Multiplikator wäerte mir Disk Space befreien. Wéi de Kommando ausféiert, mierkt Dir datt de verfügbaren Disk Space eropgeet:
ceph osd pool $pool_name set $replication_size
A no senger Fäerdegstellung änneren mir d'Parameterwäerter pg_num и pgp_num wéi folgend:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberwichteg: Mir mussen d'Zuel vun de PGs sequenziell an all Pool änneren an d'Wäerter net an anere Poole änneren bis d'Warnungen verschwannen "Degradéiert Datenredundanz" и "n-Zuel vu Säiten ofgebaut".
Dir kënnt och kontrolléieren ob alles gutt gaang ass mat de Kommandoausgaben ceph health detail и ceph -s.
Fall Nummer 3. Migratioun vun enger virtueller Maschinn vu LVM op Ceph RBD
An enger Situatioun wou e Projet virtuelle Maschinnen benotzt, déi op gelounte Bare-Metal Server installéiert sinn, entsteet dacks d'Fro vun der Feeler-toleranter Lagerung. Et ass och ganz wënschenswäert datt et genuch Plaz an dëser Späichere gëtt ... Eng aner gemeinsam Situatioun: et gëtt eng virtuell Maschinn mat lokaler Späichere um Server an Dir musst d'Disk ausbauen, awer et ass néierens ze goen, well et gëtt keng fräi Plaatz op de Server lénks.
De Problem kann op verschidde Weeër geléist ginn - zum Beispill andeems Dir op en anere Server migréiert (wann et een ass) oder nei Disken op de Server bäigefüügt. Awer et ass net ëmmer méiglech dëst ze maachen, sou datt d'Migratioun vu LVM op Ceph kann eng exzellent Léisung fir dëse Problem sinn. Andeems Dir dës Optioun auswielt, vereinfachen mir och de weidere Prozess vun der Migratioun tëscht Serveren, well et net néideg ass fir lokal Späichere vun engem Hypervisor op en aneren ze réckelen. Deen eenzege Fang ass datt Dir de VM muss stoppen wärend d'Aarbecht duerchgefouert gëtt.
Déi folgend Rezept ass geholl aus , d'Instruktioune vun deenen an Aktioun getest goufen. Iwwregens, d'Methode vun der schiefloser Migratioun gëtt och do beschriwwen, allerdéngs war et an eisem Fall einfach net gebraucht, also hu mir et net kontrolléiert. Wann dëst kritesch fir Äre Projet ass, wäerte mir frou iwwer d'Resultater an de Kommentaren ze héieren.
Loosst eis op de prakteschen Deel goen. Am Beispill benotze mir virsh an deementspriechend libvirt. Als éischt gitt sécher datt de Ceph Pool, op deen d'Daten migréiert ginn, mat libvirt verbonne sinn:
virsh pool-dumpxml $ceph_poolDe Poolbeschreiwung muss Verbindungsdaten op Ceph mat Autorisatiounsdaten enthalen.
De nächste Schrëtt ass datt de LVM Bild op Ceph RBD ëmgewandelt gëtt. D'Ausféierungszäit hänkt virun allem vun der Gréisst vum Bild of:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_nameNo der Konversioun bleift e LVM Bild, wat nëtzlech ass wann d'Migratioun vum VM op RBD klappt an Dir musst d'Ännerungen zréckrollen. Och, fir séier Ännerungen zréckzekréien, loosst eis e Backup vun der virtueller Maschinn Konfiguratiounsdatei maachen:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml
... an d'Original änneren (vm_name.xml). Loosst eis e Block mat enger Beschreiwung vun der Disk fannen (fänkt mat der Linn un <disk type='file' device='disk'> an endet mat </disk>) a reduzéiere se op déi folgend 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>Loosst eis e puer Detailer kucken:
- Zum Protokoll
sourced'Adress fir d'Lagerung am Ceph RBD gëtt uginn (dëst ass d'Adress, déi den Numm vum Ceph-Pool an d'RBD-Bild uginn, wat an der éischter Etapp festgeluecht gouf). - Am Block
secretTyp gëtt uginnceph, wéi och d'UUID vum Geheimnis fir ze verbannen. Säin uuid kann mam Kommando fonnt ginnvirsh secret-list. - Am Block
hostAdressen op Ceph Monitore ginn uginn.
Nodeems Dir d'Konfiguratiounsdatei geännert hutt an d'LVM zu RBD Konversioun ofgeschloss hutt, kënnt Dir déi geännert Konfiguratiounsdatei uwenden an déi virtuell Maschinn starten:
virsh define $vm_name.xml
virsh start $vm_name
Et ass Zäit fir ze kontrolléieren ob d'virtuell Maschinn richteg ugefaang huet: Dir kënnt erausfannen, zum Beispill, andeems Dir Iech iwwer SSH oder iwwer verbënnt virsh.
Wann déi virtuell Maschinn richteg funktionnéiert an Dir keng aner Probleemer fonnt hutt, da kënnt Dir d'LVM Bild läschen dat net méi benotzt gëtt:
lvremove main/$vm_image_nameKonklusioun
Mir hunn all déi beschriwwe Fäll an der Praxis begéint - mir hoffen datt d'Instruktioune aner Administrateuren hëllefen ähnlech Problemer ze léisen. Wann Dir Kommentaren oder aner ähnlech Geschichten aus Ärer Erfahrung mat Ceph hutt, wäerte mir frou se an de Kommentaren ze gesinn!
PS
Liest och op eisem Blog:
- «";
- «";
- «";
- «".
Source: will.com