Több általam üzemeltetett szerver ott van elhelyezve. Monitoring szerint nekünk pl voda irányba volt kiesés, de az viszonylag rövid ideig (30p). Nemzetközi irányban viszont kb 3-4 órás kieésünk volt, de ott is csak bizonyos subnetek nem mentek. Pl..: németországi vagy svájci tartományok nem mentek, de UK igen. Kicsit olyan mintha valami megborult routing lett volna a ludas. Próbáltam érdeklődni de egyenlőre semmi tajékoztatást nem kaptam, telefonban említettek valami tranzit ISP gondot, de hát abból is illik többet tartani ha egyikkel gond van tudd áttolni (akár magasabb tarnzit ktsg mellett is) a forgalmadat egy másikon keresztül.
Traceroute szerint pl amazonos subnet beli cím GTT-ig eljuott és ott akadt meg a dolog.
Kérdés ilyenkor a nálunk felmerült kötbért ki fizeti meg vajon? Ekkora kiesés már bőven túl mutat a vállalt 99.99-es rendelkezésre álláson...
Még anno a DoclerNet idejében is eljátszották egyszer ezt a dolgot hogy semmi tájékoztatás amikor falspozitív tűzriadó volt és megindult az oltás, aztán kb 1 évvel ezelőtt a L2 loop a core networkön és most ez...
L1 supportosokat sajnálom akikre ilyenkor nagyon sok telefon és feszkó hárul az ügyfelek részéről, akik tájékoztatás hiányában okkal ingerültek. Nem értem ez a fajta hozzáállást. Miért nem lehet ilyenkor egy kör emalt kiküldeni hogy srácok gond van, dolgozunk rajta? Valószínűleg megtizeledelődnek a telefonhívások száma...
Kérdés ilyenkor a nálunk felmerült kötbért ki fizeti meg vajon? Ekkora kiesés már bőven túl mutat a vállalt 99.99-es rendelkezésre álláson...
A kötbér tipikusan a rendelkezésre álláson túli állásidőre eső arányos havidíj. Szóval, ha esetleg két hétig állnak, akkor visszaadnak kb. kétheti havidíjat.
99.99%-ot vállalnak ha VPC-vel (MLAG, ki hogy ismeri) van biztosítva az adott ügyfélnek a hálózati elérés. Mivel nekünk saját hálózati eszközünk van náluk amiben 2 különböző hálózati eszközből kapunk active-active LACP-ot így véleményem szerint igenis vonatkozik ránk a 4 kilences SLA a hálózatra amit az ÁSZF-ben írnak.
Ha a hiba következtében a szolgáltatást nem lehet igénybe venni, és ezzel a Szolgáltató a jelen ÁSZF 2. mellékletében meghatározott éves rendelkezésre állási szintet nem éri el, a kötbér mértéke minden hibásan teljesített, hiba-elhárítási célértéket meghaladó nap után a hiba bejelentését megelőző, az előző hat hónapban az Ügyfél által a szolgáltatási szerződés alapján az adott szolgáltatással kapcsolatban kifizetett díj átlaga alapján egy napra vetített összeg. [...] A felelősség ezen korlátozását az ügyfél kifejezetten elfogadja.
Összefoglalom: ha a 99,99 százalék felett kiesik akár egy egész nap, akkor kapsz vissza egy napnyi pénzt, mint kötbért. Ha több nap, akkor több napnyi pénzt.
Bizonyítottan a Szolgáltató hibájából előállt teljes adatvesztés esetén Szolgáltató általány kártérítést köteles fizetni az ügyfél részére. Az általány kártérítés összege megegyezik a Szolgáltatásra eső tárgyhavi díj, előre fizetés esetén a díjnak az adott hónapra eső összegével.
Összefoglalom: ha elveszett minden adat, mert mondjuk leégett a picsába az adatközpont, akkor kapsz vissza egyhavi pénzt.
Namost, ha ennél sokkal-sokkal rosszabb feltétellel vállatál sokkal-sokkal több kötbért az ügyfeleid részére, akkor magadra vess.
Az a helyzet, hogy egy DC-ben nem lehet 100%-ot vállalni. Ezt a kockázatot nem neked, hanem annak kell futnia, akinek ez az igénye. Egyre inkább olyan történetek múlnak ezeken, hogy valójában akinek fontos, az tudja, hogy neki mi és mennyit ér. Aztán miután tudja, rá fog jönni, hogy nem a szerver háttér lesz a szűk keresztmetszet, hanem az alkalmazása. A külföldi elérés redundánssá tétele nem lesz egyszerű eset egyébként, és neked kell magadnak megoldani, mert valszin a helyi szolgáltatónál ha megáll "A" router (jelentsen ez bármilyen szuperrendundáns dolgot), akkor ugye a te szuperrendundás cuccodnak kell átállnia a másik vonalra, ami független az előzőtől. Jellemzően ezek a kérdések ott kerülnek elengedésre, amikor a beruházásnál a nullák is nehezen olvashatóak ki.
Ha felhővel dobálódzik valaki, akkor elsőre javaslom a NAGYBETŰS angol jogi szövegekben a SHALL NOT BE LIABLE tételeit megnézni, aztán pedig azt, hogy ha mondjuk két site-on oldja meg felhőben, akkor mennyire pörög fel a számláló. Alkalmazást nyilván össze lehet rakni úgy, hogy mögötte dinamikus lehessen a dolog felhőileg, de ismét pörögni fog a számláló. Szóval ha fizeti az illető, akkor jó.
Rendelkezésre állásban a szerződésben megadják, hogy mire mit vállalnak, és ott is annyi a dolog, hogy az arra időszakra eső díjat, esetleg 1,5-2x-eset jóváírják neked. Értelem szerűen, hogy ha ott épp huszmilliárd eurónyi bámi megállt, akkor az előző pontok szerint azért ezt csak az tudja vállalni, akinek ez fontos.
Ma reggel az egyik core hálózati eszközünk meghibásodott és a hibás működéséből adódóan az IP hálózatunk nem megfelelően működött. Ezért volt tapasztalható, hogy egyes hálózatokból nem volt elérhető a Servergarden hálózata.
Sajnos a hiba kiküszöbölése miatt jelentős átalakítást kellett végeznünk a hálózatunkon és ehhez mindkét eszközünket újra kellett indítani.
Egy-egy ilyen beavatkozás alkalmával a hálózati forgalmat igyekeztünk átterelni az éppen aktív eszközre, hogy legalább részlegesen elérhetőek legyenek a szolgáltatások. Ez elég sok ideig tartott és kétszer is el kellett végeznünk.
Amint mindkét eszközt újraindítottuk és visszaállítottuk a nemzetközi és belföldi kapcsolatokat, ismét megindult a forgalom. Ezután névfeloldási és levelezési problémákat jeleztek ügyfeleink, amit további beállításokkal kellett kiküszöbölnünk.
A legutolsó módosításokat 12:15-kor végeztük el, amik után megszűntek a névfeloldási/levelezési problémák is.
2024.02.21.
07:40-07:50 - Hálózati forgalmak átterelése aktív eszközre.
08:15-09:55 - Core hálózati eszközök újraindítása, hálózati kapcsolatok és forgalmat átterelése másik aktív eszközre. Hálózat IP routing beállításainak átalakítása.
12:15 - Teljes helyreállás. Névfeloldási és levelezési hibák is megszűntek.
A fenti események tapasztalatai alapján hozzálátunk a hálózati kiszolgáló környezet áttervezéséhez, hogy megelőzzünk minden hasonló hibalehetőséget.
Az okozott kellemetlenségekért ezúton szíves elnézésüket kérjük.
"
Lefordítom: két egyforma doboz közül az egyik totál megkotlott, csereeszköz nuku, nem akarnak SPoF-ot, emiatt másik, párban lévő eszközre rakták át a funkcióit. Szerinteeem...
Nekünk pont ezért van VPC (MLAG) kérve tőlük a hálózati eszközünkbe. Így elvileg az egyik core eszköz megpusztulása esetén is működnie kellene a dolognak. Pont ezért kértük hogy ne legyen SPoF a hálózati eszköz. Most már csak a mi eszközünk a SPoF de azon is dolgozunk hogy ne így legyen... Plusz manapság már megoldható hogy mindkét core eszköz egyszerre legyen aktív és funkcionáljon GW-ként. Arista eszközökből raktam már ilyet össze, mindkettőn futnak ugyanazok a BGP sessionök, mindegyiknek van két uplinkje (külön belföld/külföld ami 1-1 BGP sessiönt jelent). Ha megkotlik az egyik nem történik semmi megy tovább az élet, max néhány csomag veszik amikre még pont ő válaszolt ARP-n előtte... Mielőtt valaki felhozná hogy mivan a BGP session másik oldalán igen, az upstream ISP-nél is külön eszközbe mennek a kapcsolatok hogy ott se legyen ilyesféle SPoF. Múltkor pont volt náluk leállás, ami nálunk úgy jelentkezett hogy elveszett az egyik külföldi kapcsolatunk a karbantartás idejére. Nyilván ha az Arista ajánlása miatt ugyanolyan HW típusok és SW verziók miatt pont egyszerre kotlik meg mind a kettő akkor akkor RIP...
Ha a túloldalon egy szolgáltató van, akkor ha ő kihullik, nincs hova redundánskodnod. Ha van saját IP tartományotok, akkor BGP-vel teljesen független másik "külföldet" (egyéb elérést adó peering partnert...) lehet igénybe venni, hogy valóban redundáns legyél. A BGP nem tudom mennyire gyorsan tud váltani, de gyanítom, hogy lennének meglepetések, amikor valahol nem vagy félig áll át ilyen szinten, de valamilyen laufnak lennie kell.
itt a bgp csak a szolgaltato routere kozott balanszol: ha egyik core megmakkan, akkor bgp gyorsan eszreveszi es masik core lesz a defgw. nyilvan sajat routerek + szolgaltato cucca keresztbe-kasul be van kotve.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
nem teljesen, mindkét eszköz egyszerre aktív GW, nincs timeout mint a HSRP-nél amig átbillen a floating IP a másik, tartalék eszközre. vARP-vel van megcsinálva, mindkét core eszköz fenn tartja a BGP kapcsolatokat, természtesen az összes leaf switch bekötve mindkét core eszközbe, MLAG-al, így nincs blocked port és nincs kiesés STP konvergálás miatt. Ha meg netán kiesne valamelyik core eszközről valamelyik uplink (pl szolgáltató oldali hiba vagy karbantartás miatt) akkor a két eszköz közötti közvetlen linken megy a forgalom kifelé, nyilván legalább akkora sávszél van a két eszköz között amekkora szumma a kiefelé menő linkek sávszélje egy-egy core eszközből, hogy ez se legyen szűk keresztnetszet. Nyilván sok zsé megvenni egy rakat hálózati eszközt ami nem kevés áramot éget el havi szinten plusz fenntartani az extra kapcsolatokat az ISP felé amikor fele sávval is bőven el tudnánk üzemelni de egyszer esik ami esik...
jah valami ilyesmi volt. kifele mindket cucc forgalmazott, befele volt csak egyik n5k-re a forgalom. nem en raktam ossze, rendes hozzaerto guru csinalta, nemvolt vele gond.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Szerintem azert nem akkora nagy elvaras hogy 2 routered legyen, ami valojaban egy jobb l3 switch is lehet. A 2. linkeket (backup) jelkepes osszegert megkapod (pl.: bix, ip transit etc).
Ettol lesz backup nem? Onnan indulsz hogy van 1 routered amiben vegzodik egy IXP es NxTransit, aztan odateszel megegy routert ami megkapja a backup vonalakat.
Ebbol: https://hup.hu/comment/3030196#comment-3030196 nekem ez jott le.
Az egy erdekes "TE" kerdes, hogy a tranzit szolgaltatok novelese a mixben redundancia/backup vagy inkabb minoseg novelese.
Pl.: egy NTT+Cogent mix mennyire csereszabatosak a mogottuk levo as cone-t tekintve, persze ez az enterspajz vonalon ritkan fordul elo mint kerdes, ahol kapnak egy 0/0-t es helo.
Nos hiába tervezed meg jól, ha mondjuk szoftverhiba, speciális hardware hiba (pl. nem áll át a passzív eszközre a történet, mert nem veszi észre a párja "elköszönését). Nem mellesleg egy távoli galaxisban volt olyan, hogy egy fél ország megállt, mert egy neves gyártó szupereszköze a "fővonal" elvágása utána nem tudta hirtelen merre van az előre, hiába volt konfig.
Az ilyen kijelentésektől érdemes tartózkodni, amíg nem csak formálisan bizonyítottan 100%-os rendelkezésre állást raktál össze, hanem a valóságban is működőt. :) Ez még eddig igen keveseknek sikerült, mert valójában beláthatatlan bonyolultságú történetről beszélünk. Amikor jönnek azzal, hogy "ne álljon meg soha", akkor azért erősen tikkelek már. (Nem pont nekem kellene összerakni, mert biztos lenne olyan mágus aki ebben otthon van, de nem csodatévő azért, és lehet, hogy a megbízás előtt a kedves igénylőt elvinné a mentő az ártól. :( .)
Aktuális kedvencem a "designed to a price point". Azaz egy mezei esetben döntsük el, hogy mi ellen akarunk védekezni, milyen mélységben éri meg belemászni a dologba, és nem konkrétan nekünk IT-nak, hanem akinek ez a valós igénye.
Hozzászólások
T hálózatból nem láttam őket, máshonnan igen
"Jelenleg egy váraltan hálózati hiba következett be, aminek már megkezdtük az elhárítását. Amennyiben a hiba elhárul úgy értesíteni fogjuk Önt erről.
Üdvözlettel,
Servergarden Kft. / Tech. Support"
Akkor a szokásos: kiásta a markoló. Sajnos van személyes tapasztalatom is vele mennyire maceras helyre hozni es behajtani az okozott kárt.
Milyen okozott kárra gondolsz itt?
Van nem váratlan hálózati hiba is vajon? illetve: Jelenleg .... következett (ftw?)
Van, amit valamilyen hardware vagy sw megoldással ki tudsz védeni, és nincs (érdemi) kiesés. :)
Több általam üzemeltetett szerver ott van elhelyezve. Monitoring szerint nekünk pl voda irányba volt kiesés, de az viszonylag rövid ideig (30p). Nemzetközi irányban viszont kb 3-4 órás kieésünk volt, de ott is csak bizonyos subnetek nem mentek. Pl..: németországi vagy svájci tartományok nem mentek, de UK igen. Kicsit olyan mintha valami megborult routing lett volna a ludas. Próbáltam érdeklődni de egyenlőre semmi tajékoztatást nem kaptam, telefonban említettek valami tranzit ISP gondot, de hát abból is illik többet tartani ha egyikkel gond van tudd áttolni (akár magasabb tarnzit ktsg mellett is) a forgalmadat egy másikon keresztül.
Traceroute szerint pl amazonos subnet beli cím GTT-ig eljuott és ott akadt meg a dolog.
Kérdés ilyenkor a nálunk felmerült kötbért ki fizeti meg vajon? Ekkora kiesés már bőven túl mutat a vállalt 99.99-es rendelkezésre álláson...
Még anno a DoclerNet idejében is eljátszották egyszer ezt a dolgot hogy semmi tájékoztatás amikor falspozitív tűzriadó volt és megindult az oltás, aztán kb 1 évvel ezelőtt a L2 loop a core networkön és most ez...
L1 supportosokat sajnálom akikre ilyenkor nagyon sok telefon és feszkó hárul az ügyfelek részéről, akik tájékoztatás hiányában okkal ingerültek. Nem értem ez a fajta hozzáállást. Miért nem lehet ilyenkor egy kör emalt kiküldeni hogy srácok gond van, dolgozunk rajta? Valószínűleg megtizeledelődnek a telefonhívások száma...
nem kotekedes gyanant, de amugy mire vallalnak pontosan rendelkezesre allast?
A kötbér tipikusan a rendelkezésre álláson túli állásidőre eső arányos havidíj. Szóval, ha esetleg két hétig állnak, akkor visszaadnak kb. kétheti havidíjat.
https://iotguru.cloud
fixme, de ilyen SLA-t max az áramra és a klimatizálásra szoktak vállalni...
Hálózati elérésre is van SLA, belföldi külföldi iránytól akár függően, meg a válaszidőt néha beteszik, de azért ez beláthatóan nehéz ügy.
nem azt mondtam, h nincsen - hanem arra céloztam, h arra nem ekkora...
99.99%-ot vállalnak ha VPC-vel (MLAG, ki hogy ismeri) van biztosítva az adott ügyfélnek a hálózati elérés. Mivel nekünk saját hálózati eszközünk van náluk amiben 2 különböző hálózati eszközből kapunk active-active LACP-ot így véleményem szerint igenis vonatkozik ránk a 4 kilences SLA a hálózatra amit az ÁSZF-ben írnak.
ÁSZF-et olvastad amúgy?
Összefoglalom: ha a 99,99 százalék felett kiesik akár egy egész nap, akkor kapsz vissza egy napnyi pénzt, mint kötbért. Ha több nap, akkor több napnyi pénzt.
Összefoglalom: ha elveszett minden adat, mert mondjuk leégett a picsába az adatközpont, akkor kapsz vissza egyhavi pénzt.
Namost, ha ennél sokkal-sokkal rosszabb feltétellel vállatál sokkal-sokkal több kötbért az ügyfeleid részére, akkor magadra vess.
https://iotguru.cloud
Az a helyzet, hogy egy DC-ben nem lehet 100%-ot vállalni. Ezt a kockázatot nem neked, hanem annak kell futnia, akinek ez az igénye. Egyre inkább olyan történetek múlnak ezeken, hogy valójában akinek fontos, az tudja, hogy neki mi és mennyit ér. Aztán miután tudja, rá fog jönni, hogy nem a szerver háttér lesz a szűk keresztmetszet, hanem az alkalmazása. A külföldi elérés redundánssá tétele nem lesz egyszerű eset egyébként, és neked kell magadnak megoldani, mert valszin a helyi szolgáltatónál ha megáll "A" router (jelentsen ez bármilyen szuperrendundáns dolgot), akkor ugye a te szuperrendundás cuccodnak kell átállnia a másik vonalra, ami független az előzőtől. Jellemzően ezek a kérdések ott kerülnek elengedésre, amikor a beruházásnál a nullák is nehezen olvashatóak ki.
Ha felhővel dobálódzik valaki, akkor elsőre javaslom a NAGYBETŰS angol jogi szövegekben a SHALL NOT BE LIABLE tételeit megnézni, aztán pedig azt, hogy ha mondjuk két site-on oldja meg felhőben, akkor mennyire pörög fel a számláló. Alkalmazást nyilván össze lehet rakni úgy, hogy mögötte dinamikus lehessen a dolog felhőileg, de ismét pörögni fog a számláló. Szóval ha fizeti az illető, akkor jó.
Rendelkezésre állásban a szerződésben megadják, hogy mire mit vállalnak, és ott is annyi a dolog, hogy az arra időszakra eső díjat, esetleg 1,5-2x-eset jóváírják neked. Értelem szerűen, hogy ha ott épp huszmilliárd eurónyi bámi megállt, akkor az előző pontok szerint azért ezt csak az tudja vállalni, akinek ez fontos.
> Kérdés ilyenkor a nálunk felmerült kötbért ki fizeti meg vajon?
Ezt hogy érted?
egyelőre*
"Tisztelt Ügyfelünk!
Ma reggel az egyik core hálózati eszközünk meghibásodott és a hibás működéséből adódóan az IP hálózatunk nem megfelelően működött. Ezért volt tapasztalható, hogy egyes hálózatokból nem volt elérhető a Servergarden hálózata.
Sajnos a hiba kiküszöbölése miatt jelentős átalakítást kellett végeznünk a hálózatunkon és ehhez mindkét eszközünket újra kellett indítani.
Egy-egy ilyen beavatkozás alkalmával a hálózati forgalmat igyekeztünk átterelni az éppen aktív eszközre, hogy legalább részlegesen elérhetőek legyenek a szolgáltatások. Ez elég sok ideig tartott és kétszer is el kellett végeznünk.
Amint mindkét eszközt újraindítottuk és visszaállítottuk a nemzetközi és belföldi kapcsolatokat, ismét megindult a forgalom. Ezután névfeloldási és levelezési problémákat jeleztek ügyfeleink, amit további beállításokkal kellett kiküszöbölnünk.
A legutolsó módosításokat 12:15-kor végeztük el, amik után megszűntek a névfeloldási/levelezési problémák is.
2024.02.21.
07:40-07:50 - Hálózati forgalmak átterelése aktív eszközre.
08:15-09:55 - Core hálózati eszközök újraindítása, hálózati kapcsolatok és forgalmat átterelése másik aktív eszközre. Hálózat IP routing beállításainak átalakítása.
12:15 - Teljes helyreállás. Névfeloldási és levelezési hibák is megszűntek.
A fenti események tapasztalatai alapján hozzálátunk a hálózati kiszolgáló környezet áttervezéséhez, hogy megelőzzünk minden hasonló hibalehetőséget.
Az okozott kellemetlenségekért ezúton szíves elnézésüket kérjük.
"
-.-
Ehhez képest bizonyos irányok meg most sem mennek.
Micsoda architektura lehet az ahol 1 eszkoz kiesese miatt ujra kell tervezni a halozatot on-the-fly es minden egyes eszkozt ujrainditani :)))
Tervezes magasiskolaja :)))
Lefordítom: két egyforma doboz közül az egyik totál megkotlott, csereeszköz nuku, nem akarnak SPoF-ot, emiatt másik, párban lévő eszközre rakták át a funkcióit. Szerinteeem...
Nekünk pont ezért van VPC (MLAG) kérve tőlük a hálózati eszközünkbe. Így elvileg az egyik core eszköz megpusztulása esetén is működnie kellene a dolognak. Pont ezért kértük hogy ne legyen SPoF a hálózati eszköz. Most már csak a mi eszközünk a SPoF de azon is dolgozunk hogy ne így legyen... Plusz manapság már megoldható hogy mindkét core eszköz egyszerre legyen aktív és funkcionáljon GW-ként. Arista eszközökből raktam már ilyet össze, mindkettőn futnak ugyanazok a BGP sessionök, mindegyiknek van két uplinkje (külön belföld/külföld ami 1-1 BGP sessiönt jelent). Ha megkotlik az egyik nem történik semmi megy tovább az élet, max néhány csomag veszik amikre még pont ő válaszolt ARP-n előtte... Mielőtt valaki felhozná hogy mivan a BGP session másik oldalán igen, az upstream ISP-nél is külön eszközbe mennek a kapcsolatok hogy ott se legyen ilyesféle SPoF. Múltkor pont volt náluk leállás, ami nálunk úgy jelentkezett hogy elveszett az egyik külföldi kapcsolatunk a karbantartás idejére. Nyilván ha az Arista ajánlása miatt ugyanolyan HW típusok és SW verziók miatt pont egyszerre kotlik meg mind a kettő akkor akkor RIP...
Miaz a kulfold meg belfold?
Erősen sarkítva az hogy a hazai tartományokhoz tartozó route-ok jönnek az egyik kapcsolaton míg a másik jellemzően a többi.
Ha a túloldalon egy szolgáltató van, akkor ha ő kihullik, nincs hova redundánskodnod. Ha van saját IP tartományotok, akkor BGP-vel teljesen független másik "külföldet" (egyéb elérést adó peering partnert...) lehet igénybe venni, hogy valóban redundáns legyél. A BGP nem tudom mennyire gyorsan tud váltani, de gyanítom, hogy lennének meglepetések, amikor valahol nem vagy félig áll át ilyen szinten, de valamilyen laufnak lennie kell.
itt a bgp csak a szolgaltato routere kozott balanszol: ha egyik core megmakkan, akkor bgp gyorsan eszreveszi es masik core lesz a defgw. nyilvan sajat routerek + szolgaltato cucca keresztbe-kasul be van kotve.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
nem teljesen, mindkét eszköz egyszerre aktív GW, nincs timeout mint a HSRP-nél amig átbillen a floating IP a másik, tartalék eszközre. vARP-vel van megcsinálva, mindkét core eszköz fenn tartja a BGP kapcsolatokat, természtesen az összes leaf switch bekötve mindkét core eszközbe, MLAG-al, így nincs blocked port és nincs kiesés STP konvergálás miatt. Ha meg netán kiesne valamelyik core eszközről valamelyik uplink (pl szolgáltató oldali hiba vagy karbantartás miatt) akkor a két eszköz közötti közvetlen linken megy a forgalom kifelé, nyilván legalább akkora sávszél van a két eszköz között amekkora szumma a kiefelé menő linkek sávszélje egy-egy core eszközből, hogy ez se legyen szűk keresztnetszet. Nyilván sok zsé megvenni egy rakat hálózati eszközt ami nem kevés áramot éget el havi szinten plusz fenntartani az extra kapcsolatokat az ISP felé amikor fele sávval is bőven el tudnánk üzemelni de egyszer esik ami esik...
jah valami ilyesmi volt. kifele mindket cucc forgalmazott, befele volt csak egyik n5k-re a forgalom. nem en raktam ossze, rendes hozzaerto guru csinalta, nemvolt vele gond.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
A leaf es a "core" kozott nem lehetett volna mar valami evpn? Ezekkel az mlag-okkal es egyeb l2 csodakkal mindig szep szopasok tudnak lenni.
ez valami tozsdei cucchoz kell? mashol nehezne tudok elkepzelni ekkora HA igenyt _es_ hogy penz is legyen ra...
Szerintem azert nem akkora nagy elvaras hogy 2 routered legyen, ami valojaban egy jobb l3 switch is lehet. A 2. linkeket (backup) jelkepes osszegert megkapod (pl.: bix, ip transit etc).
a backup (második) link ára akkor lesz jelképes - ha azonos szolgáltatónál veszed igénybe...
Ettol lesz backup nem? Onnan indulsz hogy van 1 routered amiben vegzodik egy IXP es NxTransit, aztan odateszel megegy routert ami megkapja a backup vonalakat.
Ebbol: https://hup.hu/comment/3030196#comment-3030196 nekem ez jott le.
Az egy erdekes "TE" kerdes, hogy a tranzit szolgaltatok novelese a mixben redundancia/backup vagy inkabb minoseg novelese.
Pl.: egy NTT+Cogent mix mennyire csereszabatosak a mogottuk levo as cone-t tekintve, persze ez az enterspajz vonalon ritkan fordul elo mint kerdes, ahol kapnak egy 0/0-t es helo.
igen, csak nem mindegy, hogy a szolgáltató eszközét "backup-olod" vagy magát a szolgáltatást :-)
Természetesen utóbbira is vannak egészen jó konstrukciók - pl úgy tudom, RackForest-től lehet venni sávszélességet, havi forgalom alapján.
Nos hiába tervezed meg jól, ha mondjuk szoftverhiba, speciális hardware hiba (pl. nem áll át a passzív eszközre a történet, mert nem veszi észre a párja "elköszönését). Nem mellesleg egy távoli galaxisban volt olyan, hogy egy fél ország megállt, mert egy neves gyártó szupereszköze a "fővonal" elvágása utána nem tudta hirtelen merre van az előre, hiába volt konfig.
Az ilyen kijelentésektől érdemes tartózkodni, amíg nem csak formálisan bizonyítottan 100%-os rendelkezésre állást raktál össze, hanem a valóságban is működőt. :) Ez még eddig igen keveseknek sikerült, mert valójában beláthatatlan bonyolultságú történetről beszélünk. Amikor jönnek azzal, hogy "ne álljon meg soha", akkor azért erősen tikkelek már. (Nem pont nekem kellene összerakni, mert biztos lenne olyan mágus aki ebben otthon van, de nem csodatévő azért, és lehet, hogy a megbízás előtt a kedves igénylőt elvinné a mentő az ártól. :( .)
Aktuális kedvencem a "designed to a price point". Azaz egy mezei esetben döntsük el, hogy mi ellen akarunk védekezni, milyen mélységben éri meg belemászni a dologba, és nem konkrétan nekünk IT-nak, hanem akinek ez a valós igénye.
nekem ma reggel elegge akadozott, meg hajnalban nem jottek meg emailek, de delelott helyreallt magatol