Proxmox Ceph mizéria

Virtualizáció

Sziasztok!

A címbeli témában elkövettem egy kisebb hibát és most nem igazán tudom hogyan tudnám helyrehozni.

A szerverekben lévő hdd-k egy részét lecserélném ssd-re, amihez gondoltam létrehozok egy új poolt, amit meg is csináltam a webes felületen és itt jönnek a problémák. Az új poolt nevezzük SSD-nek ugyan azzal a crush rule id-val hozta létre mint a meglévő HDD-t, a pg számokat szépen össze is adta és ha ssd-t adok hozzá az osd-khez akkor azt a HDD poolba teszi bele. Az SSD poolt nem merem törölni, mert a törléshez kell az ID is ami egyezik a HDD-ével. Kérdésem az lenne, hogy helyre tudom e ezt hozni, illetve, hogy tudok egy egy szerveren egyszerre több poolt is használni?

  • 798 megtekintés

( Darkfish | 2020. 02. 04., k – 08:11 )

Szerkesztve: 2020. 02. 04., k – 08:26

A "crush rule id" kevered a "pool id"-val. A "crush rule id" egy szabály ami azt határozza meg, hogy a poolban lévő pg-ket hogyan helyezze el az osd-ken. A neve proxmoxban ha jól emlékszem replicated-rule. A proxmoxban a webes felületről nem tudsz létrehozni különféle rule-okat és az OSD eszköz tipusát sem tudod állítani (bár ezt talán már jól állítja be a 6-os proxmox alapból).

Ezért a leírásod alapján szerintem a destroynál feltett kérésre (megtévesztő módon) neked a pool nevével (SSD) kell válaszolni és csak "SSD" pool-t fogja törölni.

Ha olyan poolt szeretnél ami csak az ssd class-ű eszközeiden van, akkor:

 

1,  ellenőrizni kell az osd-k class-ét és ha proxmox nem találta el akkor első körben azt kell beállítani:

ceph osd crush rm-device-class osd.X

ceph osd crush set-device-class ssd osd.X

 

2, létre kell hozni bash-ből egy rule-t ami jelzi, hogy az adott rule-t használó pool csak "ssd" class-szű osd-kre kerüljön:

ceph osd crush rule create-replicated ssd-rule default host sdd

 

3,  majd utána létre kell hozni (akár a webes felületen) poolt a megfelelő rule-t kiválasztva.

 

ui.: a rossz hír, hogyha szét akarod választani a tartalmat akkor kell egy hdd és egy ssd rule és ezeknek megfelelő pool. Vagyis a mostani meglévő pool-dat nem fogod tudni "értelmesen" használni, mert a rendszer automatikusan szétteríti a eszközökön. Valami olyasmit kéne csinálni, hogy a meglévő poolon crush rule-t cserélni (ideális esetben a ssd berakása előtt.) De abban nem vagyok biztos, hogy 1, ezt lehet-e, 2, éles rendszeren én nem biztos hogy nekivágnék. Vagy persze előbb megcsinálni a két pool-t majd a régiről átmásolni a megfelelőbe a tartalmat és végén törölni eredeti poolt.

( dzsambo | 2020. 04. 09., cs – 12:28 )

Sziasztok!

Köszi az eddigi segítséget.

Időközben megtörtént a váltás és ügyesen gallyra is vágtam ( este nem adunk ilyan parancsot amiben nem vagyunk biztosak ), szóval lett egy újratelepítés az egészből. Szerencsére adatvesztés nélkül megúsztam.

Időközben elkezdtem bővíteni az poolt és bekapcsoltam az autoscale funkciót és belőttem 90%-ra, de nem akar semmit sem csinálni. Mindenhol azt olvastam, hogy ennyi kell csak, de nekem nem foglalkozik vele.

root@szerver1:~# ceph osd pool autoscale-status
POOL       SIZE TARGET SIZE RATE RAW CAPACITY  RATIO TARGET RATIO BIAS PG_NUM NEW PG_NUM AUTOSCALE
ssd-pool 11244G                   3.0       60343G        0.5590       0.9000      1.0    800                    on

 

Mit sikerült félrenéznem megint?

[OFF]

Na ezt se tudtam, mindíg tanul az ember valamit. :)

[/OFF]

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

Az élet ott kezdődik, amikor rájössz, hogy szart sem kell bizonyítanod senkinek

Ha meg akarod nevettetni Istent, készíts tervet!

Szerintem semmit. Nem feltétlen kell azonnal látványos dologra számítanod, akkor fog változtatni ha szükség van rá. (Szép nagy SSD poolod van. Hány SSD?)

+ javasolt extra fícsör: https://ceph.io/update/new-in-nautilus-device-management-and-failure-pr…

szerintem a legfontosabbak:

Objects can now be brought in sync during recovery by copying only the modified portion of the object, reducing tail latencies during recovery.

BlueStore has received several improvements and performance updates, including improved accounting for “omap” (key/value) object data by pool, improved cache memory management, and a reduced allocation unit size for SSD devices. (Note that by default, the first time each OSD starts after upgrading to octopus it will trigger a conversion that may take from a few minutes to a few hours, depending on the amount of stored “omap” data.)

Clone operations now preserve the sparseness of the underlying RBD image.

Images can be online re-sparsified to reduce the usage of zeroed extents.

  • MDS daemons can now be assigned to manage a particular file system via the new mds_join_fs option.

  • MDS now aggressively asks idle clients to trim caps which improves stability when file system load changes

kivancsi leszek a bluestore perfre, van egy 110 NVMes clusterunk amin majd akarok merni, de a virus miatt leallt az elet, es nincs bennuk 100gs kartya...

nem igazán, egy kis cég egyik üzletágán melózom és ez plusz az egész rendszergazdiság/hálózat üzemeltetés félig hobbi/munkaidőn túli szóval nagy tapasztalatom sincs semmiben.

Kérdezni cégen belül nem tudok senkitől sem, egyedül meg nehéz plusz kicsit bennem van a félsz, mert ha elcseszek valamit annak következményei lesznek a termelésben.

Szóval egyenlőre marad ez a megoldás, plusz ez biztos kompatibilis az aktuális proxmox-szal.

Köszi, akkor várok vele, azt hittem lesz valami látványos dolog is benne. Azt hittem ha bekapcsolom és kiterjesztem a méretet akkor szépen megfogja növelni a PG-ok számát.

Jelenleg kicsit túllőttem a célon, ez elérhető kapacitás alig több mint felet használom csak ki.

Jelenleg 92db elosztva 10 db nodeba, 800-as és 400-as ssd-k vegyesen. Köszi a plusz infót, ezt eddig nem is tudtam, hogy van benne.