Vlákno názorů k článku
Uzel NIX.CZ postihl částečný výpadek, došlo k poruše portu od Otto M. - Ja k tomu mam laicky vstup. Mame v...

Jeste stale existuji propojovaci body, kde je L3 prvek koncovych siti v propojovaci infrastrukture povinny :-)

Je to "jenom" o nakladech, ktere jsou ochotne zucastnene site nest. Takze uplne sci-fi to neni. Jen je to ponekud neekonomicke a prakticky vsechny site v zapadnim svete dnes povazuji roztahanou ethernet infrastrukturu za rozumnou miru risku.

Coz je OK, ony to plati, ony urcuji pravidla.

Ja to uchopit zvladnu - ale realita je holt dnes takova, ze L2 segment prakticky jakekoliv peeringove platformy mas dnes roztahanej na hodne velke geograficke vzdalenosti od samotneho uzlu. Ethernet neroztazeny dal za hranice propojovaci platformy je z kategorie sci-fi :-)

Pred zavorku si vzdy vytknete, ze nakonec stejne musite nekomu verit a ze dalsim limitnim parametrem byva obvykle cena.

Napriklad pre ceske prostredi by se velmi pravdepodobne vyplatilo misto budovani dalsi nezavisle infrastruktury v Praze udelat konecne plnohodnotny propojovaci uzel v Brne.

Dane kdyz pisu dve platformy, tak myslim dve platformy :-) To samozrejme znamena, ze nemas ethernet roztazenej dal za hranice propojovaci platformy. Verim, ze to zvladnes uchopit.

A proto pisu, ze je to drahy jak pro ISP, tak pro propojovaci uzel.

Dve platformy ...a pak ti je "omylem" propoji switch nejakeho pripojeneho ISPcka k oboum platformam, protoze routery a porty do nich jsou pekelne drahy... takze se setri :D Samozrejme, ze neco muzou pochytat ruzne security konfigurace na vstupu, ale to je opet o tom, ze v jeji implementaci muze byt chyba a ochrana na vstupu nemusi zafungovat presne dle ocekavani :-) Aneb nic neni dokonale.

Teoreticky jde ledacos - treba se po vzoru zahranicnich IXu posunout k pokrocilejsim techologiim interne postavenymi nad L3 infrastrukturou (tzn. napr MPLS/VPLS), kde jsou vetsi moznosti i u te diagnostiky. Komplexita techto techologii ale nicmene muze prinest problemy nove, jine - a navic jak uz padlo, ani zahranicnim uzlum nevyhybaji. Nic neni dokonale, aktualne je dulezita detailni analyza vsech okolnosti incidentu a to rozhodne neni jednoducha vec. Podstatne je, ze situaci se v rozumne kratkem case podarilo stabilizovat a uzel dovest do stavu, kdy je provoz vymenovan bez problemu. Ona i historie NIX.CZ pamatuje vypadky vyrazne vetsi a veselejsi...

A ano, cena je v dusledku jednim z faktoru, co hraje vyznamnou roli. U vyse zmineneho predevsim za softwarove licence (kdy nelze opomijet ani fakt, ze oproti NIX.CZ jsou u zahranicnich uzlu oprenych o zminene technologie koncove ceny vyssi, tedy maji lepsi financni moznosti). A samozrejme i v tomto bode je rozhodujici vule clenu - kteri o techto vecech vrcholove (zkrze schvaleny rozpocet) rozhoduji. V zasade ale soucasne reseni neni duvod rozporovat ve sve podstate, prostor pro zlepsovani je samozrejme vzdy (a urcite se resi prubezne).

Technicke reseni situace je, ze mate dve nijak nepropojene propojovaci platformy od ruznych vyrobcu.

Co je pomerne neprakticke z hlediska nakladu jak pro propojovaci bod, tak pro zucastnene site.

Já nic neobhajuji, já vám jenom vysvětluju, že mezi „něco je špatně“ a „vím, že je něco špatně, a dokonce i vím, co je špatně“ je rozdíl. V předchozích příspěvcích jste to totiž zaměňoval.

snad se shodneme aspon na tom, ze ping skutecne nestaci
co treba skutecny testovaci provoz mezi jasne urcenymi A a B a C, dorazi/nedorazi a podle toho jednam
Zatím se na tom evidentně neshodnete ani sám se sebou. Ping je totiž přesně ten „skutečný testovací provoz“. A pokud jste myslel spíš „skutečný“ než „testovací“, uvědomte si, že byste pak na 100 Gbit/s portu pak mohl přenést jen 50 Gbit/s skutečného provozu, protože byste těch zbývajících 50 Gbit/s potřeboval na přenos toho ověřovacího provozu.

Ale take nema smysl vymyslet radoby-odborne pusobici konstrukce o tom, jak by to slo resit. Nikdo se po zadech neplaca - NIX.CZ problemy i na socialnich sitich verejne priznal, nic nezatloukali a i smerem ke clenum sla samozrejme podrobnejsi informace a posbirali se relevantni data a cele to dale resi s dodavatelem technologie - a to nikdy neni na jedno odpoledne (coz vi kazdy, kdo s podobnymi technologiemi dela).

Na linkove agregaci na druhe vrstve, kde je nejspis (dnes uz bezny) adaptivni load-balancing? (o nejakych komplexnejsich moznostech modernich zarizeni nemluve?) :-) Ne, ze by to neslo dopocitat, co kudy zrovna potece - ale to se muze kazdou chvili zmenit - tudiz by se to musel neustale kontrolovat, zda zvolena kombinace skutecne cili, kam cilit ma a merici algoritmus podle toho soustavne upravovat... ne, skutecne to neni tak jednoduche vygenerovat testovaci provoz dle te specifikace - jak se na prvni pohled muze jevit a postavit na tom nejake spolehlive mereni. A i tak se muze stat, ze shodou blbych nahod ten testovaci provoz bude ten, co zrovna projde (jako viditelne prosle nejaka minoritni cast provozu v dane problemove lince).

Proc nebyl problemovy port z poolu automaticky vyrazen se samozrejme zjistuje - nicmene ta analyza asi chvili potrva. K podobnym incidentum obcas dochazi i v jinych velkych uzlech v zahranici - vse je ostatne zavisle na nejakem software (nad pomerne komplexnim hardware) a zadny software nikdy neni bez chyb a v okrajovych pripadech nemusi vse zafungovat dle ocekavani - tak uz to v IT holt chodi.

tady to trvali velmi dlouho nez byl dany port vyrazen z poolu
Já bych si zase tipnul, že od okamžiku zjištění, že je port vadný, po jeho vyřazení z poolu, uběhl krátký čas. Vy si stále chybně představujete situaci, že víte, že chyba je v nějakém konkrétním portu.

Promiňte mi tu upřímnost, ale píšete jako hlupák. Samozřejmě, že divně se chovající port je ve skutečnosti port, který selhal. Stále ale nechápete, že je rozdíl mezi faktickým stavem (port selhal) a zdánlivým stavem, který plyne z nějakého monitoringu. Pokud port selže „vhodným“ způsobem tak, že přes něj část komunikace jde, je obvykle těžké to detekovat.

Zkuste si místo automatického monitoringu představit sám sebe. Třeba z grafů provozu zjistíte, že je něco špatně, tak to začnete zjišťovat. Pingnete přes všechny porty a všude se odpověď vrátí ve stanoveném limitu. Prohlásíte na základě tohohle testu „aha, port 8 selhal“? Asi těžko, budete si dál myslet, že ten port funguje.

Ono platí takové pravidlo, že když se něco po…kazí tak, že to úplně vyhoří, spadne, odpojí se atd., je to vlastně výborný stav, protože přesně víte co a proč nefunguje. Bohužel ne všechny chyby jsou takhle disciplinované.

SPOF by to byl, kdyby ten port odesel a provoz nemel kudy jinudy jit. Coz rozhodne nebyl tento pripad - afektovana byla pouze cast provozu - ta cast, ktera mela tu smulu, ze v ramci linkove agregace mela projit onim problemovym propojem (a ktere nejake data take prenasel - jen bohuzel z nejakeho duvodu ne vse, co mel). Kdyby se to rozpadlo uplne, nikdo by si niceho ani nevsimnul.

K saturaci zadneho paterniho propoje nedoslo a to ani behem reseni problemu - kapacitni rezervy jsou dostatecne. Statistiky paternich linek jsou pripojenym clenum pristupne, tak se to tom muzou sami presvedcit (coz "jinde" zvykem rozhodne neni).

Ta vaše reakce zase vypadá, že nevíte, co je to SPOF. To „F“ v té zkratce znamená „failure“ nebo-li „selhání“. Většina řešení proti SPOF je založená na tom, že se právě to selhání detekuje a přepne se na nějaké záložní řešení, vyřadí se daná věc z aktivní služby apod. Podle různých popisů závady na tom portu to ale vypadá, že ten port neselhal, ale jenom se choval divně. Když vám ze SPOF to F chybí nebo nevíte, kde je, těžko podnikat nějaká opatření.

Skutecny problem (kdy dochazelo ke ztratam) byl jen v case cca 14:30 - 15:40, nikoliv sedm hodin. A ano, jeden port muze negativne ovlivnit ledacos, pokud se nechova v dusledku nejake ne zrovna bezne zavady korektne a je soucasne aktivni soucasti linkove agregace.

Rozpusteni clenove NIXu v planu dozajiste nemaji - neni pro to rozhodne zadny racionalni duvod :-) Traffic vyjadreny (v tomto pripade narozdil od jinych alespon nezavisle pripojenymi cleny overitelnym) cislem neni vsechno... narozdil od jinych "moznosti" jde porad o uzel rizeny (pripojenou) komunitou.