Použití NBD - Network Block Devices při virtualizaci (diskuse)

[D-Evil]

Nápad hezkej, ale bohužel jen pro jednoho hostitele virtuálních strojů :(

[Aleš Kapica]

Proč myslíš? Těch hostitelů může být klidně i víc. Já tedy osobně používám tři.

[Aleš Kapica]

Pochopitelně je ale třeba mít vytvořen odpovídající počet nbd zařízení. Já jich mám momentálně nastaveno 32, obvykle jich je jen 16.

[Aleš Kapica]

Právě že díky použití NBD nejsem vázaný na jednoho hostitele, ale mohu virtuál spustit na libovolném nodu. Ovšem to je pochopitelně krajní případ. V reálu spouštím produkční stroje pouze na dvou nodech, protože ty virtuály využívají společnou datovou oblast sdílenou přes DRBD. Na tom třetím si můžu spouštět ty, které s tím sdíleným datovým prostorem nepracují. Zbývající dva nody jsou postarší IBM stroje. Bohužel upgrade paměti by se u nich nevyplatil a jejich řadič taky stojí víceméně za houby, protože neumí hotplug. Ovšem jako záložní stroje pro ty raidy jsou ideální.

[D-Evil]

Myslel jsem to tak, že to jednotlivý zařízení (v tomhle případě RAID svazek) neni dostupný z více hostitelů naráz. Pokud to chápu správně, každej hostitel si obhospodařuje svůj vlastní RAID svazek. Nebo mi něco uniká?

[D-Evil]

Oprava: více hostitelům naráz

[Aleš Kapica]

Jo takhle..

No tak to by v podstatě šlo, akorát že v mém případě by to dávalo smysl pouze když bych chtěl ten virtuál kamsi kopírovat.

Pokud bych chtěl ten virtuál spouštět ve více instancích, tak bych použil nad tím sestaveným md zařízením xNBD server v režimu cow-target, případně proxy - podle toho jestli bych změny chtěl udržovat nebo ne a do virtuálu bych ho připojil rovnou jako nbd zařízení, tak jak jsem to dělal předtím. Jelikož by datové přenosy běžely lokálně, tak by výpadek z důvodu přerušení síťového spojení nehrozil.

[Ondrej Zajicek]

A co AoE (ATA over Ethernet), mate s nim nekdo nejake zkusenosti? To je obcas vydavano za sane alternativu k iSCSI.

[Zdeněk Burda]

Mám s ním zkušenosti - několik let bezproblémového provozu. Jen je třeba počítat s využitím pouze v interní bezpečné síti, protože se AoE nedá routovat (=> je vhodná i vyhrazená síť jen pro AoE, ale může sdílet i stávající infrastrukturu, akorát to není moc bezpečné). Chce to také síť s podporou jumbo paketů aby to bylo rozumě rychlé (při standardním mtu 1500 to dělalo jen něco kolem 10MiB/s). Na straně serveru jsem používal vblade, dá se bez problémů nacpat i do HA clusteru (heartbeat/pacemaker).

[kyytaM]

fy Coraid sa myslim na AoE specializuje. Ale nemam s tym osobne skusenosti, ale niektori ludia si to pochvaluju. Problem je myslim aj s implementaciu v linuxe, kde je viac moznosti (jedna nejaka defaultna ktora byvala ukrutne pomala a potom nejaka ovela vykonejsia - musel by som zalovit niekde v Xen mailing listoch). Kazdopadne tam bolo viacero ludi spokojnych aj ked je tam problem s bezpecnostou dat pri stratach v sieti, na co ini upozornovali.

[Aleš Kapica]

Chce to také síť s podporou jumbo paketů aby to bylo rozumě rychlé (při standardním mtu 1500 to dělalo jen něco kolem 10MiB/s).

Tak mi to při ukládání přes NBD na disk bez raid6 dělalo něco kolem 18MiB/s a teď to dělá zhruba 28MiB/s, alespoň podle toho co při kopírování hlásí mc. Při čtení je rychlejší to dělá 42MiB/s.

[Zdeněk Burda]

S AoE jsem narážel na limit gigabitu a to jak při čtení tak i při zápisu, takže s výkonem AoE problémy nebyly

[Aleš Kapica]

Hm. Skleróza je mocná čarodějka - rychlosti které jsem naměřil u nbd v single režimu jsou uvedeny v rámci odkazovaného blogpostu o sheepdogu.

[kyytaM]

Neskusal niekto porovnat vblade a ggaoed? :)

[loki]

Nebylo by prosim nejake srovnani rychlosti tohoto reseni a iSCSI? Toto je pro mne uplne nove a vypada to imho zajimave.

[Aleš Kapica]

Zatím nebylo. Protože ono to testování rychlostí je v takovém prostředí dost ošidné.

Průměrné hodnoty které mi vykazuje mc jsem zmínil výše. Také doporučuji okouknout můj blogpost o sheepdogu,tehdy jsem rovněž dělal menší testíky.

[loki]

Proctu a okouknu. Dekuji.

[cita]

Jaky ma smysl resit RAID nekde jinde nez v SAN/NAS? nebrete to jako provokaci, zajima me proc resit sw raid na hypervizorech a ne o vrstvu niz/driv.

[frEon]

taky bych daval raid uz na ulozisti uz jenom pro to, abych zapisovana data neposilal po siti 2x (raid 1)

[Aleš Kapica]

Když ti odejde úložiště, nebo konektivita k úložišti, jsi v háji. Ten cluster sám je defakto úložiště poskládané z relativně levných komponent. Jeho výhoda je v tom, že jej lze jako celek průběžně a s minimálními náklady upgradovat.

[frEon]

jo, takhle to ma vlastne smysl

[David Jaša]

Domnívám se, že tohle by mohlo uspokojivě řešit právě iSCSI, jenže v době kdy jsem to zkoušel jsem neměl podporu pro iSCSI target v jádře zakompilovanou.

Jedné testovací instanci RHEVu jsem jednou omylem vypl tgtd. Prvním příznakem byly pauznuté VM, po pohledu na storage jsem si uvědomil, odkud vítr vane. Po znovunahození tgtd se všechno znovu rozjelo... Takže přesně toto iSCSI řeší.

BTW když zmiňuju RHEV, blíží se vydání oVirtu 1.0.

[Aleš Kapica]

Takže přesně toto iSCSI řeší.

No. Je otázkou, jestli to řeší iSCSI, nebo infrastruktura RHEVu.

Je-li totiž virtuál zapauzován dříve, než jeho kernel zaregistruje chyby na blokovém zařízení, je to v pohodě - to jsem zkoušel.

Jenže pokud zapauzován není, tak se objeví chyby při práci s blokovým zařízením a je konec. On sice dál jede, ale fakticky je kaput a žádný reconnect už nepomůže.

Navíc já nepotřebuji aby se stroje zapauzovaly, ale aby jely při odstavení libovolného stroje a to mi právě zajišťuje ten raid.

[Aleš Kapica]

Původně jsem uvažoval, že by mi iSCSI mohlo ušetřit minimálně jednu operaci, jenže když se blokové zařízení jednou dostane do stavu failed, tak se stejně musí vyhodit z raidu a znovu přidat. Takže jsem se rozhodnul to nakonec pořešit agentem pro pacemaker. Ale zatím je to ve fázi: chystám se na to..

[David Jaša]

Teď jsem si znovu přečetl #20 a spíš mě napadá - proč nepoužívat už hotové clusterovací/distribuované úložiště?

[Aleš Kapica]

Nedá mi to, a musím se otázat co si vlastně pod pojmem "hotové clusterovací/distribuované úložiště" představujete. A také by mě zajímalo, jakou máte představu o objemu našich finančních prostředků pro nákup hardware.

Pokud jde o zvolené technologie, vždy je třeba kloubit více hledisek. I když se to možná tak nezdá, řešení které používám je jednoduché a spolehlivé - i když cesta k němu jednoduchá nebyla. Ojetý hardware z druhé ruky sebou vždy nese pravděpodobnost záludné chyby, která se těžko hledá a hledat chybu tam kde problematice nerozumím je tak snadné.

Náš cluster vznikl evolucí. Nejdřív byl jeden virtualizační stroj, pak druhý jako záložní a třetí se koupil protože vybyly nějaké prachy. Kromě toho, že se v jeho prostředí virtualizuje několik linuxových strojů, které poskytují nejrůznější služby, tak ho využívám zároveň i jako kompilační farmu pro kernel - přeci jenom je rozdíl mezi 5 minutami v clusteru a hodinou na notebooku.

Ale ať jen tak neplácám, tak popíšu jeden z virtuálů. Stroj support má systémový disk složený z toho nbd raidu. Patří k těm větším - jako jediný virtuál na něm má i databáze. Jiné stroje, jako např. aa4cc používají externí databázový stroj. Virtualizace jede přes KVM a QEMU. Kromě lokálně uložených starších webů u kterých už k žádnému nárůstu dat nedojde, publikuje na web osobní adresáře z novellu, jako jsou např. roboti. Všechny adresáře, které průběžně bobtnají jsou ve skutečnosti součástí jednoho, do virtuálu namountovaného přes p9, adresáře ze sdíleného úložiště. Celý tento stroj podle potřeby mění hostitele, aniž by bylo nutno cokoliv kopírovat.