Switch redundancia - Bond 1 vs. Bridge STP

 ( junior013 | 2018. február 13., kedd - 17:33 )

Szervereket redundánsan szeretnék összekötni egymással, 2 switch-en keresztül (nem stackelhetőek) - kb. "mindenki mindenkivel".
Ez nyilván hurokhoz vezet, amit kezelni kell. Itt jön a címbéli kérdés, hogy Linux oldalról milyen módon jobb?

1., active-backup bonding-ba rakom a 2 interface-t - egyszerre csak 1 switch felé él a kapcsolat, viszont csak közvetlen linkvesztés esetén vált, "távolabbi" hibát nem észlel
2., bridge-be rakom a 2 interface-t és majd az STP lekezeli, mikor, hol vágja el a hurkot és melyik irányban kommunikál? - ez elvileg jobban kezelné, bármi is esik ki a rendszerből

Kérdés, hogy melyik a bevált, biztonságosabb, "szokásos" megoldás?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Egyik se.

Köszi! Bővebben?

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

A layer 2 domain más neve failure domain, de arra amit írsz nálunk vidéken külön szó is van, az a neve clusterfuck.

Mit szeretnél pontosan elérni ezzel a setuppal?

hangosan felrohogtem a clusterfuckon :))

Én ex-Oracle-s kollégáktól hallottam.
Röviden a lényege: kis apró probléma -> javítod -> felszínre kerül egy még nagyob technical debt, ami egy nagyobb problémát okoz -> javítod -> ... káosz, aka clusterfuck.

Én a "Charlie Foxtrot"-on röhögtem fel hangosan :)
https://www.urbandictionary.com/define.php?term=clusterfuck

Alapvetően hibatűrést (switch, táp, hálókártya, kábel, stb.) - minden duplán, hogy mindig legyen egy út.

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

A gond, hogy ezek egy része ellen triviálisan tudsz védekezni. A másik része ellen nagyon nehezen. Pl: Mit csinálsz, ha a hálókártya minden 10^-4 bitben hibázik? Mit csinálsz, ha időnként hibás a kapcsolat kábelhiba miatt? Mihez kezdesz, ha valamelyik köztes switchen van probléma?
Az L2 feladata, hogy eszköz és eszköz között biztosítja az átvitelt és lehetősége szerint jelezze/javítsa az L1-beli hibákat. Ez nem a teljes útvonalat jelenti, csak 2 eszköz között jelez/javít. A több útvonal kezelését, a megbízható üzenet továbbítást az L3 és L4 rétegeknek kell megoldani. Lásd: IP, TCP vs UDP.
Ne akarj mindent L2-ben megoldani. A triviális hibákat kezelheted L2-ben (pl: elszakadt a kábel), a bonyolultabbakat bízd a többi rétegre (pl: switch független kapcsolat), a ritka hibákat pedig monitorozással derítsd fel (pl: hibázik a hálókártya időnként).

Ha tényleg ethernet redundancia kell, és össze akarod kötni a switcheket, akkor semmiképp ne futtass bridge-et, legyen aktív-passzív "switch-independent" teaming. Ezzel védve vagy bármely switch kiesése, illetve bármelyik link kiesése ellen (feltéve, hogy egy gépről nem esik ki egyszerre kettő).

De általában a legutolsó dolog, amit szeretnél, az a switchek összekötése, legalábbis az ilyen switcheké.. a layer2 redundancia nem olcsó dolog. Azért kérdeztem, hogy mit szeretnél csinálni, mert nem mindegy, hogy milyen forgalmat, alkalmazást szeretnél megbízhatóbbá tenni. Pl. egy Elasticsearch nagyon jól elvan két független interfészen, ahogy az iSCSI is (csak példák), ilyesn esetben a redundancia több réteggel feljebb (és jobban) működik. Ha csak az a feladat, hogy adott IP címen elérjék egymást a szolgáltatások, akkor szintén lehet két független layer3 interfésszel dinamikus routingot használni és a szolgáltatást loopback interfészen láttatni. (Virtualizációnál, konténerezésnél is működhet, sőt..)

Leginkább iSCSI és a klasszikus multipath kialakításból vettem az ötletet - bár tény, hogy az valóban L3-on megy.
Csak sajna a KVM virtualizáció direct iSCSI block device bekötés esetén nem tud multipath-t kezelni.

Az egyéb (samba, http) szolgáltatások kevésbé életbe-vágóak, de persze nem lenne baj, ha azok is védve lennének

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Qe?

Rég kvm-eztem, de nem csak annyit mondasz neki, hogy /dev/blockdevref és itt meg aztán majd a multipath szépen elnevezi neked az eszközt?

Nem, "source protocol='iscsi' name='iqn...." a host-ra fel sem húzom az iscsi lun-okat, közvetlen a Qemu teszi a VM alá. Így simán megy a live migration, úgy meg voltak más problémák is.

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Hmm... Jól értem, hogy akkor a kvm-be egy komplett iscsi initiator-t leimplementáltak, csak az meg nem tud multipath-t kezelni?

Linux blockdev szinten, ugye a két külön rétegre két külön driver, mint pl. lv(dm) és md ha a kötetkezelést és redundanciát mint analógiának tekintjük.

Mondjuk ezt en is regebben neztem, de akkor meg ugy volt, hogy libvirt stroage-kent open-iscsi-t meghivva felcsatolta automatan a iscsi tarhelyeket, nem kellett azt kezzel hozza megoldani, igy vm-hez tartozo tarhely konfigja is libvirtben volt kezelve.
Annyi hogy ehhez mar nem tudta megcsinalni a multipath-t is pluszba. De lehet azota fejlodott ez is, 3-4 evvel ezelott remlik hogy kerestem multipath tamogatast, akkor csak halvany igeretek voltak ra.

Libvirt-et nem ismerem, de kiindulva mondjuk xen-ből, ott a legtöbb ilyesmi a /etc/xen alatti scriptek.
Nem lehet, hogy itt is csak pár scriptet kellene lefejleszteni, ami szépen feldolgozza a paramétereket, felszedi az iscsi targeteket, összerakja belőle a multipath-t, és utána az mp-eszközt teszi alá a vm-nek?

Igen. Legalábbis, ~1 éve, mikor áttértem erre a megoldásra még nem tudodtt mp-t - de ahogy nézem, továbbra sem.
Előtte dm-multipath-t használtam, de teljesítményben és megbízhatóságban is gyengébbnek bizonyult.

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

a tema engem is erdekel.
pl sshzok egyik szerverrol a masikra, es kozben elviszi a baltasgyilkos az egyik switchet akkor ne szakadjon meg a kapcsolat.

aztan ennek a tovabbgondolt valtozata, ha az eger elragja az utp-t az egyik switch fele, egy masik eger meg a masik szerver switch2-be meno utpjet ragja el. (ertelem szeruen a ket switch kozott van valamilyen kapcsolat)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Hány szervereket szeretnél összekötni redundánsan?

első körben 6-ot

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Pontosan mi a cél?

Ha az egyik switchet lekapcsolod még menjen? Vagy linkszakadás esetén is maradjon egybe?

Nyilván lehetőleg mindkettő :) Vagy akadhat kártya-, interface-hiba - és természetesen nem zárható ki a felhasználói hülyeség sem :)

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

sub
--
Gábriel Ákos

... nem vagyok hálózatos de halovány emlékek az IP és routing felé mutatnának inkább, azaz lehet h egyszerűbb lenne egy réteggel feljebb megoldani.

--
Gábriel Ákos

Ha tudnak a switchek egymás közt LACP-t lebeszélni, akkor 802.3ad a portokra, és kész:
https://en.wikipedia.org/wiki/MC-LAG

Ha nem, akkor felejtsd el szerintem.

Igen, ez lenne az egyenes út, de az ilyen switch-ek nem ez az (ár)kategória sajnos

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Redundánsról volt szó

Amúgy FS switch-ekkel van tapasztalat ?

~300€-ért ez azért nem néz ki rosszul, dual táppal.

ebay: Cisco 3750G
2x30e Ft + stack kábelek.

Bocs hogy ezt mondom, de ha ennyi sincsen rá, akkor ... :)

Annál még a 2 db buta eszköz + failover team is redundánsabb (próbáltad már a stacket upgradelni?)

Alapvetően ezen már nincsen mit upgradeelni :) EOL ...
1x beállítod, és használod.

Elég sok helyen használunk Stack-elt catalyst-eket, akár még 2960-ból is, de az ajánlott 3750G-ből is, nem nagyon volt velük gond.
3750G azért jó, mert nincsen benne LACP limit.
Mivel ár érzékeny a dolog, én inkább venném ezt mint valamilyen buta, olcsó eszközt.

nah, vettem kettőt.
ha megjönnek meglátom h mit tud :)
--
Gábriel Ákos

Megjöttek. Na, a cisco tudás az amit végképp nem akartam felszedni de pár óra szívás után (konzol kábel nélkül!) fel van upgradelve, alapszinten be van konfigolva az egyik switch.
Biztos baromi jó lesz, már most látszik h tenger sokkal többet tud mint az eddigi dumb eszközeink.
Ha a webes felülete nem lenne ilyen gyász (javascript error, wtf) akkor azt mondanám 100% elégedett vagyok.

--
Gábriel Ákos

webes felulet egy Ciscon? remelem nem komolyan irtad.

Nekem nem életcél ez, hanem egy eszköz amin túl kellene lenni hamar.
Most éppen a java-s alkalmazást gyűröm, azt nagy nehezen sikerült életre lehelni (java6 lol)

--
Gábriel Ákos

"nem jól használod(tm)"

A cli-t akarod használni. Hidd el nekem, minden más interface sokkal nagyobb szopás...

Volt dolgom IBM bladecenterben BNT switchel.

A gui eleve szopás.
A saját cli-je csak simán szopás.

És a cli-jét át lehetett kapcsolni cisco-szerű módba. (Persze, ha jól rémlik akkor csak reboot árán)
Rohadtul nem a Cisco észjárása szerint van szervezve a rendszer. Inkább a cisco cli-jének szintaxisára ráerőszakolták a bnt agyfasz logikáját. De még így is ez a fajta mód volt a managelésére a legkisebb szopás.

Én úgy emlékszem, hogy csak valami advanced firmware esetén lehetett átkapcsolni CLI módban.

Köpedék az a switch.

+1

Nekunk az egesz kulso es belso halo 3750X es 3750G-re epul, 2960-as distro switchekkel.
Virtualis IP HSRP-vel es minden redundans, plusz OSPF a switchek es a routerek kozott, ha kieses van.

Amugy a stack egy opcio, de en nem hasznalom, mert nincs felesleges 3750X a haloban, ami kivalthatna, ha upgrade van. Parban futnak es ossze vannak kotve tronkkel. Ha kihal az egyik, akkor a masik atveszi a virtualis IP-t az osszes VLAN-ban.

Persze mivel a szerzo nem tud HSRP virtualis IP-t hasznalni switch szinten, igy neki marad a Linux keepalived mindket switchen, ket extra geppel.

Amugy SIP rendszereknel, minden "nagy" gyarto bondingot hasznal, active-passive moddal, pont a redundancia miatt.

Bocs, azt külön nem emeltem ki, de azért szerverek között manapság már (min.) 10Gbe-ről beszélünk - abban nézd a stackelhető és a "szóló" közti árkülönbséget!

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

quanta lb6m ?

Szintén nem új modell, de ennek megfelelően az ára sem húzos!
Ebay-en még újat is lehet találni!

Nem biztos, hogy van adat vagy csomag átviteli igény 10Gb-re ... alapvetően ritkán van kihajtva.

A kérdező írta "de azért szerverek között manapság már (min.) 10Gbe-ről beszélünk", és költséghatékony legyen, ezért irtam a quanta-t.

Kicsi pénzért technika híján maradsz Te,mint redundancia, és folyamatosan monitorozol mindent, aztán ha gond van: odagaloppozol,és elhárítod a hibát.
Onnantól kezdve,h redundancia kell hatványozódik mindennek az ára.
Amit nem lehet megoldani pénzzel, azt sok pénzzel kell megoldani. Ez az informatika egyik mai alapvetése.
:)


Nem csak az M$ számol furán... A Zinternet lenne ilyen gyors?
65% [62 Sources 1528 kB/6239 kB 24%] 3062 PB/s 0s

+1

Szerintem ne akarj stack-et vagyis ha igen akkor valódi stack legyen, minimum egy Dell N2000 ami már alapból tudja.

Az ethernet meg HP Virtual Stacking dolgokat elfelejteném, több kiesésed lesz velük mintha lenne egy tartalék switched, de persze én is csináltam már Force10/Dell switchen és működött de az a kérdés, hogy FW upgrade esetén is ugyanolyan jó lesz-e.

Egy minőségibb switche önmagában is elég stabil. Legyen managed és toljál rá monitoringot, hogy lássad a sérült csomagok számát, link állapotot, stb.

Körülnéztem és találtam ilyeneket:

Cisco SF500-24
TP-LINK T1700G-28TQ
Ubiquiti ES-24-LITE
Netgear GS728TSB

1. Active-passive jó lehet, csak használj ARP monitoringot, ne csak link figyelést.

Ez így miért nem jó?

auto bond0
iface bond0 inet static
address 192.168.xx.xx
netmask 255.255.255.0
broadcast 192.168.xx.255
gateway 192.168.xx.xx
slaves eth0 eth1
bond_mode balance-alb
bond_miimon 100
bond_downdelay 200
bond_updelay 200

Az STP felejtős alapvetően.
A bonding pedig rendes MLAG támogatás nélkül nem igazán redundáns, ergó megfelelő switch hardver is kell hozzá.
További alternatíva még a dinamikus IP routing, ami viszont a szerverfunkciók virtuális IP-hez kötésével használható, ergó vagy VM, vagy valami LXC-szerű konténer, vagy policy-based IP routing fog kelleni, ha maga a szoftver nem tudja az összes IP forgalmát IP-hez kötni (a szoftverek igen jelentős része ezt nem tudja).