Dotaz: iSCSI & souborový systém

[Want]

Jaké máte zkušenosti?

Odpovědi

[xxl]

Doma na tom provozuji btrfs. A dobrý. Ale pravděpodobně tě zajímá nějaké větší nasazení.

[Want]

No, jak se to vezme. Nemám s ním (iSCSI) žádné zkušenosti a narazil jsem na problém, který by byl snadno řešitelný, kdybych měl k dispozici paralelní připojení nezávislé na hlavním switchi. Tak jak jsem to míval kdysi - jeden hloupý 1GB switch.

Centralizace sítě má své výhody, ale i značné nevýhody. Viz schéma dole. A případný síťový problém, který vyřadí na určitý čas přístup k iSCSI způsobí, že se souborový systém přemountuje do stavu read-only, kdežto u NFS se jen pozastaví.

Mám v hlavě několik možných řešení. Jednou z variant by mohlo být nasazení XFS, které by dočasnou nedostupnost sítě mohlo ustát, protože hodně využívá RAM a té mám poměrně dost. Jenom si nejsem jist jestli by se to po obnově síťové komunikace srovnalo, nebo ne.

Nejlepší řešení by byl sheepdog který byl na tohle ideální, jenže ten se už bohužel nevyvíjí.

[X]

S mensim polem zadny problem, s vetsim radeji FC/FCoE. Zalezi o jakem HW a setupu se bavime. Podle otazky hadam o zadnem..

[Want]

Hádáš špatně. Setup je jasný. V disklessu jede docker, jenže ten neumí persistentní změny zapisovat přes NFS. iSCSI je řešení. Háček je v tom, že veškerá komunikace jde přes hlavní switch. A pokud ho někdo uvaří tím, že zasmyčkuje porty, vyhodnotí ten výpadek I/O FS jako chybu a přepne do read-only módu. Důsledky doufám vysvětlovat nemusím.

[X]

I ta tvoje 'sheepdog' mrtvola podporuje iSCSI. Preber si to v hlave a laskave nemichej low level protokol s nejakym block level problemem. Ptal jsi se na iSCSI. Pokud mas nejaky problem na vyzsi urovni nedavej hloupe otazky jako "ma nekdo zkusenosti z iSCSI". Jo nekdo ma. Debilni otazka = debilni odpoved.

[Want]

Ptal jsem se na iSCSI a FS. Objasnil jsem i proč. Z toho co píšeš o sheepdogu je zjevné, že o tom víš kulové, ale hraješ si chytráka.

[X]

Ne neptal:

Jaké máte zkušenosti?

Mam zkusenosti s nasazenim na stredne velke pole. Pomohlo? Asi ne. Zaloz novy dotaz a napis co konkretne resis za problem. Pak se muzeme bavit.

[Want]

To máš z toho, že nečteš titulek dotazu.

Problém, který řeším je dán podstatou iSCSI. Možná je i řešitelný nějakými parametry - to je to s čím nemám zkušenosti. U NFS, když nedostane klient data, pozastaví činnost, dokud server neodpoví. Čekal bych podobné chování. Jenomže iSCSI není FS. A souborový systém reaguje na problém tím, že se remountne do RO protože nemůže zapisovat, ale po obnově konektivity už se do původního stavu nevrátí. A je otázkou co vůbec s těmi daty dělá.

Před 13 lety, jsem u jednoho stroje přišel o data, protože měl do raidu přidaný špatný disk. Přidal ho tam kolega, který se překlepnul. Ale přišel jsem na to až o měsíc později, když po restartu stroj nenaběhnul. Od té doby jedu všechno diskless.

Kdyby ten docker akceptoval kontejnery sdílené přes NFS, tak jako singularity, bylo by to v pohodě. Jenže on si potřebuje splácat vlastní stack a to nad NFS nešlo. Proto jsem nadhodil otázku: "iSCSI & FS: Jaké máte zkušenosti?"

Já použil Btrfs, ale třeba jsou pro tenhle use case jiné FS vhodnější.

[X]

Jenomže iSCSI není FS.

Tim bych mozna zacal. iSCSI je protokol pro storage area network, SAN. Mam pole a misto toho abych ho bouchnul do serveru ho spristupnim po siti tak, aby vypadalo jako primo pripojene. Je te dedikovana infrastruktura bezici mimo "starndartni sit". Je to urcite to co potrebujes? Problem lidsky faktor, jako nekdo zapojil spatne kabel, nekdo pridal spatny disk ti iSCSI pomuze tak, ze pri multiplath to jeden vytzeny kabel nezabije a na SAN swich se vetsinou stejne nesaha. Pole ktera se iSCSI pripojuji, jsou liny level nez "kolega podelal raid" a vymenuji za jizdy bez problemu(nevim jak je to s polema co maj supliky zezhora..).

[Want]

Takové problémy bohužel vždy způsobuje lidský faktor. Tyhle problémy se začaly vyskytovat od chvíle, kdy se přešlo na Fortinet. Velká propustnost = velké problémy, které se hůř řeší - když ti vaří železo. Ale na druhou stranu, jsou na dálku řešitelné. A dočasně nedostupné iSCSI by nemělo vést k trvalé nedostupnosti služby.

[X]

Neco jako docasne nedostupne iSCSI, by vzhledem k 'multipath' a vysoke redundanci konektivity s polem vubec nemelo nastat. Takove pole ma vetsinou hned nekolik dualnich karet. Je to take jina trida zarizeni a neni to zrovna levne. Nicmene hadam by se to dalo postavit i "na kolene" na normalnim linux stroji, ovsem bude to dost studia a prace.

[RealJ]

Alesi, resis dusledek a ne pricinu. Pokud mas funkcni sit tak je uplne fuk co mas za fs. Ze ti nekdo umi zacyklit tvuj switch je problem admina toho switche. Spravne udelana sit se neposere u vytrhnuti nejakeho kabelu ze zdi nebo ze nekdo zastrci kabel ze switche zpatky do switche. Pokud se chces bavit konkretne, tak i dnes provozuji na iscsi apfs, provozoval jsem nad tim ext4 a bez problemu.

[Want]

Dík za odpověď. Jak už jsem tu několikrát zmínil, topologie není v mé kompetenci a řekl bych, že to jak vypadá je výsledkem mnoha kompromisů, protože narážíme na limity všude možně.

Jinak nechci nemožné, ale uznáš sám, že nelze situaci řešit tím, že začneš dělat maintainera opuštěného software, kvůli projektu co má běžet dva roky. Na druhou stranu ale nemůžeš dopustit, aby kvůli lidské chybě ten projekt přišel o nasbíraná data, na kterých staví.

Primární chyba je v tom, že ta aplikace, co to sbírá, se distribuuje zabalená v docker stacku.

[Max]

Proč by neměl umět zapisovat persistentní změny přes nfs?
Jinak co je těmi smyčkami myšleno? Běžná síť by se s nimi měla umět rychle vypořádat a k výpadkům by nemělo docházet. Tj. RSTP/MSTP, Loop Protection, BPDU Guard apod.
Zdar Max

[Want]

Maxi, ty víš, že je síť mimo mou kompetenci. Vzpomínáš na naši poslední debatu v Šumavské? O firewallu? Momentálně panuje všeobecná posedlost kyberbezpečností, ale zdrojem skutečného nebezpečí je hloupost. Zopakovala se situace, která se podle mého přesvědčení neměla opakovat. A v měřítku mnohem horším než prvně.

Když se to stalo prvně, bylo to ještě v éře, kdy jsem používal vde switch. Takže bylo ihned jasné na kterém subnetu to vaří. Konektivita tehdy byla pouze 1Gbit, takže se to nikde jinde nestihlo projevit.

No. A teď se to projevilo takhle. Naštěstí nejde (zatím) o produkční nasazení. Ovšem remount do read-only stavu není zrovna to co chceš, protože ti zůstávájí data viset v RAM.

[efa]

By me zajimalo, jakypak chovani bys jako cekal, kdyz necemu odpojis disk, coz je presne situace kdyz ti zdechne iscsi. A aby se to nedelo, tak ze VZDY pouzivaji NEJMENE 2 switche a stejne tak pole ma NEJMENE dva controlery, a kazdy jeden stroj je pripojen ke vsem switchum stejne jako to pole, takze pravdepodobnost vypadku se limituje na naprosty minimum.

Pokud si to bastlis na jednom switchi za 5korun, tak to celkem logicky nemuze fungovat.

[Want]

Ty jsi mi nějak chytrý. Jen to čtení ti moc nejde.

[efa]

Zato ty ses zjevne uplnej blb.

"Háček je v tom, že veškerá komunikace jde přes hlavní switch"

Koupis si trikolku a cekas od toho ze to bude mit 1000 koni a zaroven to bude litat i plavat.

[PetebLazar]

Pokud se nepletu tak úplnost multi-path zajišťovalo využití Dual-Port HDD (FC/SAS), případně SSD.

[Want]

Ten sheepdog byl přesně na tyhle situace stavěný. Měl zajistit běh infrastruktury i v případě že byla přerušena konektivita např. při zemětřesení (vyvíjel to japonec).

[polish]

Asi bych nespolehal na timeouty filesystemu. Oddelit SAN sit od bezneho internet provozu a nasadit multipath - vice nezavislych tras.

[Want]

Jasně, vyřešilo by to přímé propojení těch dvou strojů, ale bohužel, to už není v mé kompetenci. A nejsem si ani jist, zdali je to možné. Samozřejmě existuje i varianta protlačit přes NFS celé virtuální blokové zařízení. Používám to, ale jen při spouštění, kdy se nic nezapisuje.

[Peter Golis]

Ako to čítam, tak nerozumiem jednej veci. Naozaj tam máte úmyselne vytvorený Single Point of Failure, a ten odstavuje kritickú časť infraštruktúry bežiacu v kontajneroch?

Alebo to nie je kritická časť infraštruktúry ktorej nevadia výpadky, a nie je čo riešiť?

[Want]

Uvádím výše - je to mimo mou kompetenci. Spousta věcí se mění a je to jak s očkováním proti slintavce a kulhavce. Nikdy neuhlídáš všechno. A teď se to prostě sešlo, takže se ukázala slabina, která by většinu lidí nenapadla ani ve snu. Nemůžu vědět, kdy se něco podobného stane zas, ale mohu zvolit technické řešení, které bude robustní - tak jako je robustní ta disklessová infrastruktura. S tou ten incident neudělal nic. A nebýt toho, že se remountlo to Btrfs, netušil bych, že se něco dělo.

[Peter Golis]

To by naozaj nikoho nenapadlo že jediný switch je SPOF. A zaujímalo by ma čo nastane ak ten switch čírou náhodou odíde do kremíkového neba.

A ak ten výpadok neurobil nič s tou bezdiskovou infraštruktúrou, tak to obkukaj a nasaď to rovnakým štýlom.

Inak docker naozaj nevie pracovať s trvalým úložiskom cez NFS? Pýtam sa pre kamaráta.

[Want]

Když si ho postavíš sám, tak jo. Jenže to, co mám za úkol rozjet už postaveno je. Je to několik kontejnerů co vzájemně spolupracují, žel ten klíčový má nějaký konfigurační problém. Takže není čas zkoumat, jak to je ubastleno uvnitř, protože to ještě nejede, jak by mělo.

[efa]

To mas marny, on po tobe chce reseni jak na lavku ze shnilyho prkna pres potok dostat nalozenej kamion.

Ten jeho switch je tak neco za petikorunu vytazenyho z popelnice, protoze nic normlaniho smycku ani nezapne. Klidne si to vyzkousej.

iSCSI mam jak na vyhrazeny tak na sdileny infrastrukture, a zadnej problem s tim neni. Ma to trosicku horsi latence nez FC, ale to je vse. Na druhou stranu ... je to sranda (proti FC) o poznani levnejsi a vyrazne univerzalnejsi. Protoze narozdil od FC si to proste muzu attachnout k libovolnymu cemukoli na siti.

Resit chovani pri vypadku s jednim switchem, je presne stejny, jako resit fail raidu s jednim diskem.

[Peter Golis]

On dostal úlohu: Tak sa to pokazilo, urob s tým niečo aby to neblblo. A delegoval to na internetové fórum. Má zaujímavú náplň práce.

[X]

Ptal se na zkusenosti. Zase bych ho tak negriloval. Presnou situaci vi jenom Want.

[Peter Golis]

Skúsenosti má kde kto, obvykle veľmi dobré keďže iSCSI sa používa na redundantných pripojeniach.

Potom to ale upresnil s nezmyselnými obmedzeniami typu že tam je SPOF, alebo kontajnery boli šité horúcou ihlou a nemajú podporu NFS.

Neviem čo mu bráni vytvoriť korektne nové kontajnery, a prehodiť do nich údaje. Asi je ten návod naňho zložitý, a on očakáva info kam má kliknúť popri rannej káve.

Holt, antonym Want je tu pojem.

[Want]

Ty vole Golis. Nebudu ti vykládat o věcech do kterých tobě ani mně nic není. To podstatné ses dozvěděl. Nejsem velmistr vesmíru jak si někteří naivně myslí, protože kdyby jo, bylo by všechno jinak. Ptal jsem se na zkušenosti s iSCSI a FS. To je opravdu takový problém napsat používám nad tím tenhle FS protože tohle a tohle?

Chápu, že se někdo o své zkušenosti dělit nechce. Co nechápu, je ta potřeba mít blbé kecy a vyjadřovat se k problému, který jen v plné nahotě ukázal slabiny řešení, které ale není z mojí hlavy. Mým cílem je ošéfovat i takovou situaci. Ne říkat někomu jinému jak má co dělat.

[Peter Golis]

Používal som, ale kvôli latencii bol prechod na FC.

Tyvole Want, nabudúce nechaj navrhovať topológiu niekoho iného. A tie narýchlo zbastlené kontajnery radšej zmigruj ako som povedal na novo a korektne vytvorené.

Zas si sa nezaprel ako majster sveta.

[Want]

Topologie sítě není v mé kompetenci jestli jsi to dosud nepochopil. O situaci víš kulové, takže si svoje moudra strč za klobouk. Já se k tvým schopnostem - pokud sis toho ještě nevšiml - také nevyjadřuji.

[Peter Golis]

To som pochopil, a preto som spomínal že máš nanovo a korektne vytvoriť tie kontajnery, a zmigrovať im dáta.

Ak si nepochopil ten prehľadný návod čo som ti nalinkoval až pod nos, tak to radšej zabaľ.