Ceph failure scenario

[czechsys]

Ahoj,

hraju si tu s cephem (PVE6/nautilus) v konfiguraci 3x pve node, kazdy node obsahuje mgr, mon, 2x OSD. Ceph backend je pres mesh na 10G siti, frontend pouziva 10G v lacp. Testovaci VM bezi na jednom z techto nodu.

A ted testovany scenar - tvrdy vypadek jednoho node. Behem testu bezel randrw fio na jedne VM, aby bylo videt, co to udela s diskem v cephu. Tvrdy vypadek node zpusobi, ze iowaity jsou na 100% zhruba 20+ sekund, cili zrejme tam uraduje defaultni "osd_hearbeat_grace = 20" a "osd_hearbeat_interval = 6". Pouziva to nekdo v takovehle konfiguraci, nebo to ma prenastaveny? Myslel jsem, ze preklopeni na sekundarni OSD/pgs je v ramci male chvile, takze me odstavka disku pro cely cluster v tak dlouhe dobe prekvapuje...

Diky.

[Reklama]

[Jan Forman]

3 servery je málo, výpadek jednoho vždy způsobí kritický stav. Je to opravdu naprosté minimum.

Jinak ne - nesetkal jsem se s nějakým problémem, odstavení systému s daty negeneruje žádný lag. Zpětné sesynchronizování OSD mi probíhá v řádu sekund max minut.
Pokud ale bude málo replik systém se normálně zmrazí po dobu, než se dostane do konzistentního stavu. To je ale chyba administrátora.
Běžně odebírám OSD i celé servery za provozu.

Ahoj,

hraju si tu s cephem (PVE6/nautilus) v konfiguraci 3x pve node, kazdy node obsahuje mgr, mon, 2x OSD. Ceph backend je pres mesh na 10G siti, frontend pouziva 10G v lacp. Testovaci VM bezi na jednom z techto nodu.

A ted testovany scenar - tvrdy vypadek jednoho node. Behem testu bezel randrw fio na jedne VM, aby bylo videt, co to udela s diskem v cephu. Tvrdy vypadek node zpusobi, ze iowaity jsou na 100% zhruba 20+ sekund, cili zrejme tam uraduje defaultni "osd_hearbeat_grace = 20" a "osd_hearbeat_interval = 6". Pouziva to nekdo v takovehle konfiguraci, nebo to ma prenastaveny? Myslel jsem, ze preklopeni na sekundarni OSD/pgs je v ramci male chvile, takze me odstavka disku pro cely cluster v tak dlouhe dobe prekvapuje...

Diky.

[drmartins]

Mám přesně tuhle konfiguraci co máš ty. 3x node pve/ceph 2x disk systém (hw raid) 2x disk pro osd

Tento scénář jsem zatím netestoval, pouze "smrt" nodu kde je nějaký server aby zafungovalo HA.
Můžu to zkusit tak jak popisuješ ty.
Čili jestli to dobře chápu máš nějaký VM, který ti běží třeba na nodu 1 a ty zabiješ node 3 a zajímá tě co to bude dělat s diskem v té VM?

[Jan Forman]

Pochopil jsem, že mu celý CEPH zamrzl... to se nesmí stát.

Standardně je nastaveno 3/2 (dva potvrzené zápisy a tři kopie) což je minimum pro zajištění konzistence dat.
Pokud dva systémy neodpovídají dojde k zamrznutí celého FS. Třetí kopie je zřejmě vytvářená nějakým lazy způsobem.
Disky by ale neměly být rotující (jejich seek to celé zabije). Funguje to, ale spíš jako cold-storage.

CEPH asi zatuhne jen ze dvou příčin
a) málo serverů s OSD pro potvrzení zápisu - obvykle minimálně 2x
b) velký traffic při replikaci (možná točivé HDD)

Chyba může být i nevyvážená lokace dat (disk, server, rack, místnost, budova) vzhledem k replikám. Dvě repliky na jednom serveru je špatně.
Pokud bude mít víc jak tři servery, CEPH se sám dostane do plně konzistentního stavu, na třech serverech s jedním mrtvým bude vždy "degraded".

Mám přesně tuhle konfiguraci co máš ty. 3x node pve/ceph 2x disk systém (hw raid) 2x disk pro osd

Tento scénář jsem zatím netestoval, pouze "smrt" nodu kde je nějaký server aby zafungovalo HA.
Můžu to zkusit tak jak popisuješ ty.
Čili jestli to dobře chápu máš nějaký VM, který ti běží třeba na nodu 1 a ty zabiješ node 3 a zajímá tě co to bude dělat s diskem v té VM?

[czechsys]

Mám přesně tuhle konfiguraci co máš ty. 3x node pve/ceph 2x disk systém (hw raid) 2x disk pro osd

Tento scénář jsem zatím netestoval, pouze "smrt" nodu kde je nějaký server aby zafungovalo HA.
Můžu to zkusit tak jak popisuješ ty.
Čili jestli to dobře chápu máš nějaký VM, který ti běží třeba na nodu 1 a ty zabiješ node 3 a zajímá tě co to bude dělat s diskem v té VM?

Ano, presne tak. 3 servery, VM bezi na jednom z nich, zabiju node, na kterem ta VM zrovna nebezi.

[Reklama]

[czechsys]

3 servery je málo, výpadek jednoho vždy způsobí kritický stav. Je to opravdu naprosté minimum.

Jinak ne - nesetkal jsem se s nějakým problémem, odstavení systému s daty negeneruje žádný lag. Zpětné sesynchronizování OSD mi probíhá v řádu sekund max minut.
Pokud ale bude málo replik systém se normálně zmrazí po dobu, než se dostane do konzistentního stavu. To je ale chyba administrátora.
Běžně odebírám OSD i celé servery za provozu.

Ahoj,

hraju si tu s cephem (PVE6/nautilus) v konfiguraci 3x pve node, kazdy node obsahuje mgr, mon, 2x OSD. Ceph backend je pres mesh na 10G siti, frontend pouziva 10G v lacp. Testovaci VM bezi na jednom z techto nodu.

A ted testovany scenar - tvrdy vypadek jednoho node. Behem testu bezel randrw fio na jedne VM, aby bylo videt, co to udela s diskem v cephu. Tvrdy vypadek node zpusobi, ze iowaity jsou na 100% zhruba 20+ sekund, cili zrejme tam uraduje defaultni "osd_hearbeat_grace = 20" a "osd_hearbeat_interval = 6". Pouziva to nekdo v takovehle konfiguraci, nebo to ma prenastaveny? Myslel jsem, ze preklopeni na sekundarni OSD/pgs je v ramci male chvile, takze me odstavka disku pro cely cluster v tak dlouhe dobe prekvapuje...

Diky.

Vim, 3 je malo, ale je to minimum. Replika je nastavena na 3/2. I pri tomhle by ten ceph mel zustat konzistentni (resp. presneji funkcni), ale ten lag je necekany.

[czechsys]

Kód [Vybrat] Rozbalit

2019-09-19 15:23:15.079162 mon.pve-02 [INF] mon.pve-02 calling monitor election
2019-09-19 15:23:15.084649 mon.pve-01 [INF] mon.pve-01 calling monitor election
2019-09-19 15:23:20.089482 mon.pve-01 [INF] mon.pve-01 is new leader, mons pve-01,pve-02 in quorum (ranks 0,1)
2019-09-19 15:23:20.101932 mon.pve-01 [WRN] Health check failed: 1/3 mons down, quorum pve-01,pve-02 (MON_DOWN)
2019-09-19 15:23:20.109589 mon.pve-01 [WRN] overall HEALTH_WARN 1/3 mons down, quorum pve-01,pve-02
2019-09-19 15:23:51.061755 mon.pve-01 [INF] osd.4 failed (root=default,host=pve-03) (2 reporters from different host after 45.419694 >= grace 43.284224)
2019-09-19 15:23:51.061853 mon.pve-01 [INF] osd.5 failed (root=default,host=pve-03) (2 reporters from different host after 45.419658 >= grace 43.284224)
2019-09-19 15:23:51.066934 mon.pve-01 [WRN] Health check failed: 2 osds down (OSD_DOWN)
2019-09-19 15:23:51.067001 mon.pve-01 [WRN] Health check failed: 1 host (2 osds) down (OSD_HOST_DOWN)
2019-09-19 15:23:55.091491 mon.pve-01 [WRN] Health check failed: Degraded data redundancy: 42211/126633 objects degraded (33.333%), 256 pgs degraded (PG_DEGRADED)
2019-09-19 15:24:53.145278 mon.pve-01 [WRN] Health check update: Degraded data redundancy: 42211/126633 objects degraded (33.333%), 256 pgs degraded, 256 pgs undersized (PG_DEGRADED)

[drmartins]

Tady to jen říká, že mu vypadli disky a že se snaží ty pg který jsou degradovaný rozházet po ostatních discích.
Pokud vim, tak ceph dělá tyhle věci dost nevybíravě a nejde mu takový proces ani ionicenout. Takže jestli tam máš točivé disky a jen málo disků, tak ceph začne ty osdčka rozhazovat po jiných živých osd a tim to zabije.
Takže bych to nepřizusoval ten tvůj problém cephu jako takovému, ale opravdu spíše té hw vybavenosti. Kdyby tam těch disků bylo více a byly to ssdčka, bylo by to mnohem rychlejší a myslím, že ty VMka by to pak pocítili jen lehce.

[czechsys]

Vsechny tri servery jsou komplet ssd. Pri 3/2 a 3 nodech by k zadnemu presouvani pg nemelo dojit. Ani se to nedeje - ceph je ve stavu 2/2 ALE je tam xx vterin doba, kdy ceph posle iopsy na nulu.

Viz priloha (netdata snapshot) pri fio randrw ve VM a odstreleni jednoho ceph nodu natvrdo.