iSCSI Multipathing v Proxmox

[czechsys]

Ahoj,

mam v ruce 2x storage (bude v HA), ktere ma byt pripojeno pres iscsi multipath. Bohuzel aplikace vyrobce resici multipath je pouze pro windows a redhat-style systemy, debian/ubuntu podporovany neni, takze s tim budeme muset trochu laborovat.

1] Kazda storage ma 4x fyzicky port do switchu, momentalne ma tedy 4x IP z jednoho iscsi subnetu.
2] Testovaci PVE ma 2x fyzicky port do switchu, openvswitch+lacp+bridge+2 virtual iscsi porty, tzn. 2 IP ze stejneho iscsi subnetu jako v 1]
3] datove toky na PVE momentalne jedou jen pres jeden iscsi port

Aby byl funkcni multipath, co je potreba?
a1] dedikovany subnet per port na storage
a2] 1 subnet per  storage
b1] dedikovany subnet per port na pve
b2] 1 subnet per pve
c1] iscsi over lacp na pve
c2] iscsi bez lacp na pve (tzn. dedikovane fyzicke porty)

Kombinace a2+b2+c2 je jasna. Ale jak se tam pak resi treba to, ze by pve mel jen 2x iscsi vs storage 4x iscsi z hlediska adresace/routovani?
Je mozna jina kombinace, ktera by byla jeste rozumne jednoducha? napr. a1+b1+c1 atd.?

Jeste je nutno vzit v uvahu, ze kazdy pve by mel propoj na obe storage, kazda v jine lokalite s jinou L3 adresaci - tedy bez roztahnuti L2. Celkove se tedy v tuto chvili jedna o 2x4 iscsi target, momentalne 2 ruzne iscsi subnety (1 per lokalita).

Diky.

[Reklama]

[Petr Branik]

V pripade problemu se budes taky radit na root.cz foru? Ja jenom ze ten multipath se obvykle nasazuje u kritickych aplikaci a u kritickych aplikaci chces mit dostupnou podporu a ne se chodit ptat na fora. Nesel bych do nepodporovaneho reseni obzvladt pokud to planujes nasadit na do vicero lokalit.

[František Ryšánek]

Aby byl funkcni multipath, co je potreba?
[a dál dotaz na kombinace IP subnety vs. porty na storage boxu]

To je dobrá otázka. Podle mého záleží, co umí ten storage box.

Pokud to má uvnitř jedinou instanci firmwaru, která vidí ty své čtyři porty jako eth0...eth3, tak bez dalšího bych řekl, že nemá smysl dávat těm čtyřem rozhraním IP adresy z jediného společného subnetu. V tom případě totiž traffic směrem ven pojede nejspíš jediným rozhraním. Aspoň takto by se choval standardní Linux.

Jak se tu nedávno probíralo, i v tom Linuxu se dá zařídit, aby "odpovědi odcházely stejným rozhraním, odkud přišel dotaz" (per TCP spojení) - ale znamená to nějaké hraní s iptables, ten storage box by musel řešit connection tracking a nějaké navazující věci... odhadem by to mohlo být procesorově náročné a tedy nežádoucí. Nebo by na to výrobce musel mít nějaký svůj vlastní modul v kernelu - nemohu vyloučit, viděl jsem už různá zvěrstva.

Uměl by ten storage box proti switchi trunking / bonding? Toto buď pomocí LACP nebo i bez. Pokud ano uměl, můžou se dvě a více rozhraní chovat jako "failover group", možná dokonce s jakýmsi load balancingem, a tím pádem ten storage box může mít klidně jedinou společnou IP adresu.

Obecně by mělo fungovat, postavit to jako dvojhvězdu. Každý PVE box po jednom fousu do každé hvězdy, každý storage box taktéž (dva porty storage boxu by zůstaly "na ocet"). A na každou L2 hvězdu jiný L3 subnet.

Grammar nazi poznámka: mít dva samostatné storage boxy připojené k jedinému hostiteli, a provozovat nad nimi nějaký (geograficky) rozprostřený mirror, to je terminologicky něco jiného, než multipath.

Multipath znamená, že máte jeden storage box (dokonce jeden LUN) vidět z jednoho hostitele dvěma nezávislými cestami. Za starých časů bych ke "sloučení do jednoho blokového zařízení" použil v Linuxu modul dm-multipath.

Ono v Linuxu jde ledacos poskládat "holýma rukama" na kterékoli distribuci, ale některé distribuce mají své vlastní specifické uživatelsky příjemné nástroje...

Mimochodem než geograficky rozprostřený mirror z blokových zařízení, zvážil bych možná spíš CEPH, pokud tomu jde naproti geografické rozmístění počítačů. A tahat storage traffic skrz L3 router by mi kdysi taky připadalo jako svatokrádež. Já vím - lepším switchům je už asi dvacet let dost jedno, jestli forwardují L2 nebo L3.

[czechsys]

Aby byl funkcni multipath, co je potreba?
[a dál dotaz na kombinace IP subnety vs. porty na storage boxu]

To je dobrá otázka. Podle mého záleží, co umí ten storage box.

Pokud to má uvnitř jedinou instanci firmwaru, která vidí ty své čtyři porty jako eth0...eth3, tak bez dalšího bych řekl, že nemá smysl dávat těm čtyřem rozhraním IP adresy z jediného společného subnetu. V tom případě totiž traffic směrem ven pojede nejspíš jediným rozhraním. Aspoň takto by se choval standardní Linux.

Jak se tu nedávno probíralo, i v tom Linuxu se dá zařídit, aby "odpovědi odcházely stejným rozhraním, odkud přišel dotaz" (per TCP spojení) - ale znamená to nějaké hraní s iptables, ten storage box by musel řešit connection tracking a nějaké navazující věci... odhadem by to mohlo být procesorově náročné a tedy nežádoucí. Nebo by na to výrobce musel mít nějaký svůj vlastní modul v kernelu - nemohu vyloučit, viděl jsem už různá zvěrstva.

Tezko rict, dovnitr nevidim. Ale sitovky se daji konfigurovat L2,L3, bonding, port groupy, etc, takze...

Uměl by ten storage box proti switchi trunking / bonding? Toto buď pomocí LACP nebo i bez. Pokud ano uměl, můžou se dvě a více rozhraní chovat jako "failover group", možná dokonce s jakýmsi load balancingem, a tím pádem ten storage box může mít klidně jedinou společnou IP adresu.

Umi. Ale v pripade bondingu bude prece vykon degradovany minimalne na urovni linky ne? Jedine spojeni pve(ip:port)->box(ip:port)?

Obecně by mělo fungovat, postavit to jako dvojhvězdu. Každý PVE box po jednom fousu do každé hvězdy, každý storage box taktéž (dva porty storage boxu by zůstaly "na ocet"). A na každou L2 hvězdu jiný L3 subnet.

Grammar nazi poznámka: mít dva samostatné storage boxy připojené k jedinému hostiteli, a provozovat nad nimi nějaký (geograficky) rozprostřený mirror, to je terminologicky něco jiného, než multipath.

Multipath znamená, že máte jeden storage box (dokonce jeden LUN) vidět z jednoho hostitele dvěma nezávislými cestami. Za starých časů bych ke "sloučení do jednoho blokového zařízení" použil v Linuxu modul dm-multipath.

Nad temi boxy bude HA sluzba, takze ten mirror by nemel byt problem.

Ono v Linuxu jde ledacos poskládat "holýma rukama" na kterékoli distribuci, ale některé distribuce mají své vlastní specifické uživatelsky příjemné nástroje...

Mimochodem než geograficky rozprostřený mirror z blokových zařízení, zvážil bych možná spíš CEPH, pokud tomu jde naproti geografické rozmístění počítačů. A tahat storage traffic skrz L3 router by mi kdysi taky připadalo jako svatokrádež. Já vím - lepším switchům je už asi dvacet let dost jedno, jestli forwardují L2 nebo L3.

ceph jsme zvazovali, nakonec dostal prednost SAN. Co se tyce L3, vzdy peclive premyslime, zda roztahnute L2 ma smysl (konfiguracni schopnosti switche). Tohle je asi prvni pripad roztahnute L2 (replikace), ale iscsi zatim mame L3.

Tldr: zatim resim, jak vlastne nastavit site na PVE, aby spravna kombinace adresace/portu fungovala - je tam lacp, bridge atd...proste sdilena sitova konfigurace. A nez budu predelavat na subnet per sitovy port, tak zjistuji, zda nemam botu jinde. Prvotni predpoklad je, ze ten box ten multipath umi podle ocekavani - tzn. vice IP na pve a vice IP na boxu.

[Soptadv]

Základní otázkou je jak je ta storage fyzicky řešená ?
Je to jedna krabice nebo jsou tam dva controllery ?

Pokud jsou dva controllery, tak předpokládám že každý má na sobě dva ISCSI porty.
Controllery jsou na sobě nezávislé ? Lze jeden rebootovat při zachování dostupnosti storage ?

A jak výrobce doporučuje řešit multipathing pro RedHat OS ?
Většinou je to řešeno pomocí nativního Linux multipathingu.

Co z nám já, tak konfigurace je následující:

CTRL-1 Port1 + CTRL-2 Port1 -> subnet A -> Proxmox port1
CTRL-1 Port2 + CTRL-2 Port2 -> subnet B -> Proxmox port2

Pak Linux vidí čtyřnásobek počtu LUNů prezentovaných z toho storage a pomocí nativního multipathingu jsou vytvořeny DM device nad příslušnými LUN.
Ideálně se to řeší tak že pro každý subnet je samostatný LAN switch, nebo pokud jsou to dva switche ve stacku, tak VLAN pro subnet A je na jednom switchi a VLAN pro subnet B je na druhém switchi.
Tak aby výpadek jednoho switche neovlinil oba subnety (SAN  area).
A takovéto zapojení je pak odolné i k výpadku jednoho controlleru
Samozřejmostí jsou pak Jumbo frame pro ISCSI VLAN (subnet).

Na straně serveru se pokud to jde (skoro vždycky) dedikují LAN porty čistě pro ISCSI trafic.

Co se týká umístění dvou storage ve dvou různých lokalitách, tak to je další level.
Ale vždy jsem to řešil L2 protažením ISCSI subnetů (VLAN) přes obě lokality.
O routing na ISCSI jsem se nikdy nepokoušel..

Pak další věcí je zda ty storage umí mezi sebou replikovat data a případně jakým způsobem.
Pokud storage neumí replikovat nativně, pak přichází na řadu nějaký lokální mirror (mdadm), ale to si zase moc nerozumí s HA na úrovni výpočetních node..

Chtělo by to víc informací o té storage, aspoň vendora..

[Reklama]

[R.S.]

Jak pise Soptadv, chtelo by to vendora a pripadne model storage.

Bondingu/LACP bych se vyhnul pro iSCSI, v podstate to prinasi jenom zmatek pro multipath drivery, a zbytecne to muze prodlouzit dobu na odpoved.

Vendor by mel mit popsane jake je "best practice" nastaveni, pripadne jake parametry kde nastavit pro multipath apod.

[Jose D]

..

LVM nad multipath nad iSCSI v PVE provozuju.

Pokud se chceš volně inspirovat, tak se třeba koukni do manuálu storage "EonStor DS 3000 Series Hardware Manual", kapitola 2.3.4 Ethernet - host connections. Je tam několik topologií, podle toho, jestli (ne)máš redundantní ctrl, jestli máš/chceš redundantní Ethernet atp.

[czechsys]

Diky, kouknu.

Ja jsem ted zkusil dve veci:

1] pridani 2x10Gbps sitovky a pro kazdy  iscsi port odlisny subnet, bez openvswitch/lacp
2] zmenit na openvswitchi pro ty 2x iscsi porty z jednohu subnetu na dva odlisne subnety

V obou pripadech multipath zafungoval jak ma - pouzil oba iscsi porty a v pripade 2] to pri testu i teklo po obou lacp linkach. Takze to vypada, ze jeden subnet pro vice src ip na pve nebude fungovat bez dalsi magie, takze to holt predelame na aspon 2 subnety.

[František Ryšánek]

[...] Takze to vypada, ze jeden subnet pro vice src ip na pve nebude fungovat bez dalsi magie, takze to holt predelame na aspon 2 subnety.

Palec nahoru za ověření experimentem / průzkum bojem.
A taky za to, že jste zvolil jednoduché přehledné řešení s jasně definovaným chováním.