Dotaz: Nastavení RSTP mezi servery a switchem

[Zdeněk Zámečník]

Ahoj, našel by se tu někdo zkušený, kdo by mi poradil s nastavením RSTP pro následující zapojení?

+------------+                           +------------+
|SWITCH A    +---------------------------+SWITCH B    |
+------------+                           +------------+
      |                                        |
      |                                        |
      |                                        |
      |       +------------------------+       |
      |       |      +-----------+     |       |
      |       |      |           |     |       |
+------------------------+  +------------------------+
|  eth0    eth1   eth2   |  |  eth2   eth1   eth0    |
|  10gbit  40gbit 40gbit |  |  40gbit 40gbit 10gbit  |
|    |        |     |    |  |    |      |     |      |
|    |        +-----+    |  |    +------+     |      |
|    |        |          |  |           |     |      |
|    |      bond0        |  |         bond0   |      |
|    |        |          |  |           |     |      |
|    +--------+          |  |           +-----+      |
|    |                   |  |                 |      |
|    br0                 |  |                br0     |
|    br0.10 VLAN10       |  |        VLAN10  br0.10  |
|    br0.20 VLAN20       |  |        VLAN20  br0.20  |
|    br0.30 VLAN30       |  |        VLAN30  br0.30  |
|                        |  |                        |
|       SERVER A         |  |        SERVER B        |
+------------------------+  +------------------------+

Myšlenka je poměrně jednoduchá. Jedná se o dva servery, které jsou napřímo propojeny 40Gb síťovkami. Cílem mého snažení je, aby servery mezi sebou komunikovaly napřímo a vše ostatní přes switche ven. Myslel jsem si, že vše naházím do bridgů, jak je vidět na "obrázku" a pomocí RSTP na switchích se pak vždy jedna z 10Gb cest zablokuje. STP na bridgi v linuxu jsem vypnul. Je ta myšlenka správná? Případně řešili byste to jinak? Nedaří se mi to totiž dostat do provozuschopného stavu (cyklí se to). Je nutné na switchích konfigurovat MSTP nebo vystačím se samotným RSTP? Všechny porty na switchi jsou VLAN trunky. S MSTP nemám žádné zkušenosti, zkoušel jsem to s ním nastavit, ale výsledek byl podobný.

Odpovědi

[L!80r]

Routing nebo nějaké forma per vlan spanning tree a nastavení priorit.

[Max]

Já bych to tak neřešil. Představa, že všechno zaloopuju a pak se spolehnu na to, že to RSTP vyřeší, to není nic, co by se mi líbilo.
Pokud potřebuješ rychlou komunikaci mezi servery, tak ok, ale proč by i přes ty servery pak měla jít komunikace ven?
LACP mezi servery evidentně máš, ty switche jsou ve stacku? Můžeš proti nim ty servery také připojit v LACP (jeden kabel do jednoho switche, druhý do druhého a spojit LACPem/bondx/teamx)?
Zdar Max

[Zdeněk Zámečník]

Můj první záměr a zároveň pokus bylo použití levných switchů (T1700G-28TQ), které umí stack. A do obou jsem poslal 4x1Gbit LACPem. S tím, že tu 40G linku jsem provozoval uplně odděleně. Problém těch switchů byl, že se to chovalo podivně - stačilo odpojit jakýkoliv kabel a ten switch v tu chvíli ztratil obvykle 5-8 ICMP paketů na všech portech! Pokud jsem jeden ze switchů vypnul, tak to bylo mnohem horší. Řešil jsem to s výrobcem a bylo mi řečeno, že je to vlastnost. Na nějaké další pokusy se stackem jsem v tu chvíli ztratil chuť.

Rozhoupal jsem se to celé přestavět a koupil 10G switche (Ubiquiti EdgeSwitch 16 Xg), které neumí stack a jednoportové 10G síťovky do serverů. A celé to zapojil tak, že právě tu redundanci zajistím skrz 40G síťovky. S tím, že to celé pohlídá RSTP, který jsem popravdě nikdy na podobné věci nepoužíval.

[trekker.dk]

Můj první záměr a zároveň pokus bylo použití levných switchů (T1700G-28TQ), které umí stack. A do obou jsem poslal 4x1Gbit LACPem. S tím, že tu 40G linku jsem provozoval uplně odděleně. Problém těch switchů byl, že se to chovalo podivně - stačilo odpojit jakýkoliv kabel a ten switch v tu chvíli ztratil obvykle 5-8 ICMP paketů na všech portech! Pokud jsem jeden ze switchů vypnul, tak to bylo mnohem horší. Řešil jsem to s výrobcem a bylo mi řečeno, že je to vlastnost. Na nějaké další pokusy se stackem jsem v tu chvíli ztratil chuť.

U switchů je na tohle potřeba dávat bacha. Řešil jsem něco podobného - switch to umí, paráda, podíváme se, co o tom lidi píšou na netu: "při výpadku jednoho switche stack 20s nebo minutu neswitchuje, když switch zapojíte zpátky, tak to neswitchuje 20s, podle výrobce je to vlastnost, je potřeba 4x dražší switch".

Rozhoupal jsem se to celé přestavět a koupil 10G switche (Ubiquiti EdgeSwitch 16 Xg), které neumí stack a jednoportové 10G síťovky do serverů.

To chápu, pokud někdo ví o 10G switchích, které umí stack a nestojí 200+ kKč jeden, tak bych o tom rád věděl.

A celé to zapojil tak, že právě tu redundanci zajistím skrz 40G síťovky. S tím, že to celé pohlídá RSTP, který jsem popravdě nikdy na podobné věci nepoužíval.

No, teoreticky by to tak, jak to máte zapojené a nastavené, mělo fungovat tak, jak chcete. Když je STP na těch linuxech vypnuté, měly by switche shodit buď tu linku mezi sebou, nebo jednu mezi switchem a serverem. Pokud to nefunguje, tak bych zkusil tcpdump na tom Linuxu a zkusit vysledovat, jestli tam něco nazahazuje BPDU rámce, kterými se ta smyčka detekuje.

Jinak bych ale souhlasil s Maxem, tohle řešení je dost divné. Nehledě na to, že ten bridge je čistě softwarová záležitost, takže je otázka, jestli přes něj těch 10Gbit vůbec projde.

Řešil jsem něco podobného (corosync cluster mezi více servery, switche neumí stackovat) a udělal jsem to jednoduše tak, že mám switche (4) zapojené do kruhu a MSTP na tom. Každý server je zapojený do dvou switchů přes bond rozhraní v režimu active-passive. Zkoušel jsem tomu různě vytahovat kabely a podle všeho jsem si nikam nenapsal, co se dělo, ale mám za to, že z toho byly výpadky do 3 sekund, což by ten cluster měl přežít.

Je tu samozřejmě jedna možnost, jak to může vypadnout: když jeden z těch switchů vytuhne, ale nevypne se, tj. připojené servery na svých síťovkách nebudou mít link down. V takovém případě ten bond nemá důvod přepnout aktivní linku na druhý switch a server nebude v síti. Dá se to řešit tak, že ten bond do sítě posílá nějaké pakety (ARP nebo echo request IIRC) a prohlásí tu linku za nefunkční, když se nic nevrací - což ovšem samozřejmě znamená, že musí běžet to, co na ty pakety má odpovídat.

Nebo se to dá řešit tak, že když po vás někdo chce HA řešení, tak se holt musí plácnout přes kapsu a koupit pořádné switche. (Akorát teda pokud chcete 10Gbit a stack, tak si připravte tak půl milionu.)

Jinak k RSTP vs. MSTP - dokud bude fyzická topologie té sítě pro všechny VLANy stejná, stačí vám RSTP. Pokud ne, musíte počítat s tím, že RSTP řeší čistě fyzickou síť bez ohledu na VLANy a tudíž že přeruší i smyčky, které vzhledem k nastavení VLAN ve skutečnosti smyčku netvoří. V takových případech musíte použít MSTP

[Zdeněk Zámečník]

Díky za komentáře. Po dnešním bádání jsem zjistil, že bridge v Linuxu neforwarduje BPDU pakety, pokud je na něm STP vypnutý. Nenašel jsem žádnou možnost (kromě patche), jak toto chování změnit. Pokud STP v Linuxu zapnu, chová se to o poznání lépe, ale ty switche s Linuxem se nedomluví a po cca 10 vteřinách se to začně různě cyklit, ačkoliv v podstatně menším měřítku než dříve. Další možností se jeví mstpd, který ale není vhodný do produkčního prostředí.

[Pedro]

Na ES16XG byla nedavno beta verze firmware, ktera umela stacky. To by stalo za test.

[snajpa]

Ja obecne nemam rad reseni na L2 vrstve, tak se jim snazim vyhybat, co se da. V pripade takhle malyho setupu je to asi burt, ale kdyz to clovek takhle zacne a pak projekt roste, exploduje to pod rukama... Zalezi teda, co je po ceste za krabky a co umi. Neni to zadna magie ;)

[Zdeněk Zámečník]

Krabičky viz komentář výše. Motivací, proč to mít všechno na stejné vrstvě je, že na těch serverech provozuju corosync, který komunikuje multicastem. Takže nějaké routování nepřipadá v úvahu. Možná to nějak jde, ale nevím jak a hlavně mám obavy, že to bude nepřehledné oproti spanning tree. Chtěl bych mít možnost tam přidat další nody do clusteru a získat tím také funkční quorum.

Možná to byla naivní představa, ale já se s tím nějak poperu. Šlo mi hlavně o to ujistit se, že ta moje myšlenka může fungovat.

[trekker.dk]

Jako že každý server broadcastuje "moje IP adresy jsou tady" přes nějakou spojovou síť a místo switche tam je router?

[snajpa]

Presne tak. S Broadcom StrataXGS jako switchorouterem to neni problem, 150ns port to port, az 128k v4 + 64k v6 rout... V porovnani s resenim MAC tabulek a obecne problemu na L2, tohle cca “musi” chodit. Druhym dechem dodavam, ze je potreba nahodit BFD a mit zapnutou podporu ECMP na switchich. Takove Delly S4048 z druhe roky jsou za uplnou hubicku (my je berem za nejakych 1400 EUR bez DPH a dopravy z UK).

[trekker.dk]

Takove Delly S4048 z druhe roky jsou za uplnou hubicku (my je berem za nejakych 1400 EUR bez DPH a dopravy z UK).

Tak moment, 48x10Gbit + 6x40Gbit, podporuje stacking, to celé za 40kKč (plus SFP moduly, hádám)? Ehm, v čem je háček?

Akorat tedy se nic nebroadcastuje, ve vpsFree setupu mame na kazdem portu toho switche proste navazanou jednu BGP session na spojovacce.

Jo, to jsem myslel. Asi, přece jenom v BGP a BGP terminologii se úplně nevyznám.

[snajpa]

Akorat tedy se nic nebroadcastuje, ve vpsFree setupu mame na kazdem portu toho switche proste navazanou jednu BGP session na spojovacce. Route server neni moc potreba, ty x86tky v tech switchich na route servery staci v siti do tech 64k prefixu v poho.

[V.]

Neměly by být ty síťovky pro 10Gb a 40Gb nějak oddělené? Tj. proč je u serveruA ta spojka mezi br0 a bond0? Jaká je konfigurace br0, ten tam musí být, když už mam 3 bridge pro 3 síťovky?

[Zdeněk Zámečník]

Vypadá to, že jsem zvítězil bez zbytečných kompromisů. Standardní Linuxové bondy a bridge jsem nahradil Open vSwitch a vše funguje naprosto perfektně. Navíc jsem tím získal možnost nastavit pro každou VLAN jiné MTU.