Teljesen rendundas halozat a server gepek fele, ha nem bizunk a switchekben sem

Hálózatok általános

Egy kitalalt eset.

Adot nehany gep aminek van egy-egy IP cime es hasznal meg multicast cimeket is.
A gepekben min. 2 db gigabit ethernet NIC van.
A gepek mondjuk tetszoleges Linuxok futtatnak.
Mindket NIC-be dugott kabelnek kulonbozo fizikai eszkozben kell vegzodnie.

BTW: Menyire megbizhato a halokartya 'link van' jelzese ?
Lehet -e ezt ugy rendundassa tenni, hogy amig nincs hiba mindket halokartya savszelleseget kozel teljesen ki tudjuk hasznalni?

Ethernet bonding a leiras szerint kulonbozo switchek fele csak Active-Passive vagy mindket switchnek ugyan azt kuldjuk modban megoldhato.
Nem igazan bizunk a 'link van' jelzesben, lehet hogy egy nagy fekete lyuk fele mennek a csomagok.

Mesehez hozza tartozik, hogy a ket halokartyas gepeinkben most megbizunk, nincs helyetesuk (cluster), de a halozati elemekrol feltetelezzuk, hogy gyakran meghibasodik valamelyik. A gepek leszakadasa a halorol, emberek halalat okozza.

Milyen protokollokkal/eszkozokkel oldanatok meg hasonlo problemat ?

  • 1749 megtekintés

( wauf | 2010. 10. 06., sze – 00:29 )

> A gepek leszakadasa a halorol, emberek halalat okozza.
"Nehany gep" allomanyt tizszeresere novelni, a foldon mindenfele elszort datacenterekben elhelyezni.

Ilyen szituaciokban amugy a bold kerdesnek semmi ertelme, a megbizhatosag 1000x fontosabb mint a teljesitmeny.

Es akkor gepX.datacenter1-bol lehet kuldeni heartbeatet gepY.datacenter[2-10]-nek mindket NICen, es nezni melyik el.

Persze ilyenkor a szinkronizaciot is meg kell oldani valahogy.

( bambano | 2010. 10. 06., sze – 00:43 )

szerintem nem lehet bondingot csinálni, ha két különböző eszközben végződnek a drótok, mert az ethernet sorrendtartását nem lehet így garantálni.

szerintem ha összebridgeled az egész hálózatot, akkor az stp üzenetek (elmaradása) ki fogják deríteni, hogy meghalt-e a link vagy sem.

ha emberhalál történik, akkor más architektúrát javasolnék, nem egy darab pc-t két hálókártyával.

Vegzodhet kulonbozo eszkozben: http://www.mjmwired.net/kernel/Documentation/networking/bonding.txt (11.2.1), Ezeket nem lattam Linuxban: http://en.wikipedia.org/wiki/DSMLT, http://en.wikipedia.org/wiki/R-SMLT.

Sorrendiseget meg tudnank orizni, ha becsomagoljuk a frameket, amiket fogado vagy a fogado fele vezeto uton rendezunk, a sokat keso frameket eldobjuk.

A kerdes szerint leszarando mi van pontosan az IP alatt csak menjen,de NIC -ek ethernetek, ill. nem feltetlenul hagyomanyos switchekbe kell kotni a kabeleket.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( Jason v | 2010. 10. 06., sze – 08:47 )

A "Link van" jelzés azt jelenti, hogy érez valami feszejt a kábelen, ami akár jel is lehet, nem többet. Nyilván egy Layer1 eszköz nem fogja tudni megnézni, hogy tudod-e pingelni a default gatewayt :-)

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

( egeresz | 2010. 10. 06., sze – 09:50 )

a kerdes/valasz lenyege az atallasi ido.
Vagyis, hiba eseten mekkora leallas es csomagvesztes fogadhato el.
A 0 masodperc es a 0 csomagvesztes nem elerheto ertek, tehat ne is szabj ilyet.

Peldaul, ha elfogadhato 30 sec leallas, es nehany csomag vesztese, akkor
linux(bridge) ket nic - ket switch, ami ossze van kotve. Ez ad egy ethernet hurkot, amiben a spanning tree jatszik (spt).

Ha 1-2 sec fogadhato el, akkor bonding, a tuloldalt specialis (dupla) switchel. (juniper vagy cisco tud olyan stackelt switchet, ahol ket kulon switchbe lehet egy 802.3ad aggregatot bekotni)

Egyebkent a helyzet nem eletszeru. A gepek (oprendszer okokbol) nagysagrenddel tobbszor halnak meg, mint a halozati eszkozok.

Ugy altalaban, ha megbizhato rendszert szeretnel, akkor a kovetkezo a prioritasi sorrend:
- "rend" az oprendszerben
- ups, klima
- redundans diszkek (raid)
- minosegi hardver
- minosegi halozat (switchek)
- cluster (redundans szerver)
- redundans diszkalrendszer
- redundans network

A spanning tree atkapcsolasi ideje leveheto 12 masodpercre, ha az osszes switchen a leheto legrovidebbre veszed az idoket:

Hello time=1 (range: 1-10 sec, IEEE 802.1d default: 2 sec)
Max age=6 (range: 6-40 sec, IEEE 802.1d default: 20 sec)
Forward delay=4 (range: 4-30 sec, IEEE 802.1d default: 15 sec)

Sot mar a 26xx is EOS vagy EOL, van helyette masik, ujabbak eseten valahol olvasgattam eszkozokon atnyulo port groupolasi lehetosegrol, tipust nemtudom, de ez megoldana a problemat nem ?

Azt meg nem akartam beirni ejszaka, hogy mi kerul tobbe a cegnek, a nehany ember csaladjanak a karterites + egyeb, vagy beruhazni egy nar fent is emlitett dologba.

Ez tiszta matek, es gazdalkodas, mire mekkora az esely, es az mennyibe kerul, ha a>b akkor b, ha meg nem akkor forditva, jomunkasemberek sokan vannak, a profit meg egyedul.

A Linux jó eséllyel nem, bár meglepődnék, ha egy >5 éves nyílt protokollt olyan sokáig tartana implementálni.

Ha a Planet, meg TP-Link, meg hasonló kategóriájú távolkeleti gyártók 1-2 évvel ezelőtti switchei is tudták, akkor ugye érezzük, hogy bármilyen rendes switchben benne lesz a támogatása.

Ha 1-2 sec fogadhato el, akkor bonding, a tuloldalt specialis (dupla) switchel. (juniper vagy cisco tud olyan stackelt switchet, ahol ket kulon switchbe lehet egy 802.3ad aggregatot bekotni)

1 sec igénye esetén duplikált független hálózat, független IP (sub)net, külön IP címmel, és az alkalmazás párhuzamosan tartson fenn két kapcsolatot, egyet-egyet a két hálózatban, és alkalmazásszinten oldja meg a redundanciát. Ha pl. mindkét hálózatban elküldi ugyanazt az adatot, akkor igen jó eséllyel egyáltalán nem lesz adatkiesés.
Ha csak keepalive/timeout-jelleggel figyeli, melyik a jó, akkor a roundtrip/válaszidő függvényében lehet ilyen 1-5s körüli időn belül kezelni a kiesést - természetesen ez csak UDP-szerű cuccal megy, mert a TCP esetén ennél sokkal magasabb timeoutok vannak a protokollban.

Koszi.

A frame veszteseg elfogadhato, baj eseten.
1 perc IMHO tulelheto, de jo lenne minimalizalalni 1 sec ala.

Prioritasi sorrend szerintem jo, de nem akartam, hogy valaki felhozza a tobbit, mert most nem az a kerdes. Tekintsuk adotnak a felette levoket, ha ugy konyebb nem beszelni rola.

'(juniper vagy cisco tud olyan stackelt switchet, ahol ket kulon switchbe lehet egy 802.3ad aggregatot bekotni)'
Hogy hivjak ok ezt a kepesseget?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Hogy hivjak ok ezt a kepesseget?

- switch tud stackingot? (igen, tovabb)
- switch tud 802.3ad -t? (igen, tovabb)
(ez benne van a leirasban)

gyarto mernoket fel kell hivni, es konkretan rakerdezni, hogy a 802.3ad -t ugy is tudja-e, hogy az aggregat egyik vege az egyik eszkoben, masik vege a masik eszkozben van.

gyarto mernoket fel kell hivni, es konkretan megkerdezni, hogy a stack az olyan-e, hogy az egyik meghibasodasa eseten a masik megy tovabb, beleertve a 802.3ad linket is. Ha visszakerdez, hogy mi az a 802.3ad, akkor nem a te embered.

Amennyiben igen/igen a valasz, ugy meg kell kerni, hogy egy tesztlaborban ezt mutassa be.
Mivel 3 misi helybol a cucc, be fogjak mutatni.
Nem valasz eseten nagy a valoszinusege, hogy nem tudja.

( saabi v | 2010. 10. 06., sze – 11:20 )

BTW: Menyire megbizhato a halokartya 'link van' jelzese ?

Semennyire. Ez csak a hálózati kártya és a legközelebbi switch közötti kábeles kapcsolat meglétét jelzi. A HP Servieguardban nem véletlenül működik úgy a hálózatfigyelés, hogy forgalommal kapcsolatos paramétereket lehet beállítani. Nem linket figyel, hanem adatforgalmat. Bejövőt, kimenőt vagy mindkettőt.

Lehet -e ezt ugy rendundassa tenni, hogy amig nincs hiba mindket halokartya savszelleseget kozel teljesen ki tudjuk hasznalni?

Úgy tudom, vannak úgynevezett stackelhető switchek, melyek összekötve egynek számítanak, tehát működik a trunking, de ha az egyik elromlik, a másik folytatja a munkát egymagában. Én nem vagyok hálózati szakember és erről a switchről egy baráti beszélgetés során hallottam, magam sose láttam ilyet.

Ave, Saabi.
ps: asszem erről beszélek.

( saabi v | 2010. 10. 06., sze – 11:26 )

Másik gondolatom a virtualizáció. Ha olyan sok pénz forog a kockán, mint azt fenn írtad, akkor nem érdemes a vason és az oprendszeren spórolni. Akkor pedig VMWare Sphere. Melyben van olyan lehetőség, hogy egy virtuális gépet két host párhuzamosan futasson. Ezesetben az egyik elhalása esetén a másik igen rövid időn belül átveszi a munkát a virtuális gép újraindítása nélkül.
Erről a képességről is csak egy beszélgetés során szereztem tudomást, így részletek számomra e kérdésben nem ismertek.

Ave, Saabi.
ps: ja, hogy csak a hálózat érdekes? Akkor fentiek feleslegesek.

( battila | 2010. 10. 06., sze – 13:22 )

Ha jol tudoma Cisconak van valami load balancere (load shering?). Abba megy bele az internet, moge felkotogeted az n darab szervered, amin fent van a szolgaltatas, es az okos cisco kutyu csak annak kuld kerest, aki el es virul.

Lehet, hogy nem is cisco? Az biztos, hogy olyan 10-12 misi darabja. Most valahogy nem talalom a neten, bar nem fektettem bele tul sok energiat.

Az a baj, hogy ez nagyon specialis terulet. A legtobb helyen meg van engedve a 5-30 perces allasido, ami elegendo egy HA switch-hez. Ebben az esetben en valami cloudcomputing-ra tudnek gondolni. Van egy nagy frontend sok interface-vel es hihetetlen reakcioidovel, mogotte a felhoben ott futkoraszik az alkalmazasod.
Tartok tole, hogy ezt hazibarkacs eszkozokkel nem fogod tudni megvalositani, vagyis ugy nem, hogy 100%-osan mindig mukodjon. A sok ezer dolcsi meg elegendo indok rendes szolgaltatas kiepitesehez.

Igazad van, nem konkretan ez volt a kerdes, de ez a teljes problemajara megoldas. Nem kell kulon szenvednie a halokartyak kiesesevel, a vas/applikacio halalozasaval.Marmitn a cloudcomp.
A loadbalancer az a halozati kiesesre megoldas.Nem kell hakolnia. Radug n gepet, a lb meg eldonti, hogy ki el. Raadasul clusterbe lehet kotni az lb-ket, hogy ha kihullik, ne legyen kieses. Igy megoldja a switchek, protokolok, megvalositas, ios bug, bonding, ... problemakat.

( djsmiley v | 2010. 10. 07., cs – 07:52 )

Ha csak ethernet oldalrol erdekes a kerdes, akkor bonding + vmi layer 3 cisco switch stackwise-al ossehuzva (pl. 3750), igy van switch "failovered" is.
Ha emberek halnak meg, akkor meg kvara nem x86, es kvara nem 2 smc desktop kartya :)