Vlákno názorů k článku Výpadek u hostingové firmy Ignum vyřadil na několik hodin weby klientů od zakaznik srverhosting - Muj monitoring mi vypadek zaevidoval v rozsahu 16.05-16.35...

Muj monitoring mi vypadek zaevidoval v rozsahu 16.05-16.35 (mame tam server hosting). Na helpdesku sem cekal asi 15minut, behem kterych stihli vyridit tusim tri hovory (ze zakaznika cislo 12 se ze me stal zakaznik cislo 10) - nedokazi si to vysvetlit jinak, nez ze jeden operator tam obsluhuje vice front, pac o cem by si v prumeru pet minut povidali, v situaci kdy sou v prdeli switche...

Ale ne, operator horko tezko vysvetlovel, ze tam vazne voda netece ... a nikdo mu to nechtel verit.

veřím že to pěkne schytali v noci tam často sedí lidi kteří absolutně nemají páru o čem mluví. Nicméně to je asi ta móda 1'st level supportu aneb jak chránit duševní zdraví skutečných adminů.

Přijde mi to ale takové kostrbaté vysvětlení, přece jenom DC by měla mít infrastrukturu topologie mnoha hvězd takže ono přelevání problémů je nějaké podivné. Top of rack switche navíc předpokládám používají dva, následně bonding nebo desetigigo na top of line/dc a tradá na routery a do světa.

Ale jo taky jsem musel vést válku z vlatními zaměstnanci na téma 3 samostatné PBX nebo tři propojené, nakonec jsem vyhrál ale byl to boj. taky mi tvrdili že je protokol pro failover a právě ten nezafungoval (byla nějaká podivná ztrátovost takže to ani nejelo/nefungovalo ale ani nezdetekovalo rozpad/nefunkčnos­t).

Se mi v siti zblaznila sitovka jednoho stroje ... zajimavy to bylo predevsim tim, ze to negenerovalo zadny vyznamny traffic, ale narust latenci v cely siti byl ohromnej (stovky ms v gigovy siti + i PL). Takze to neslo zadnym "normalnim" zpusobem najit. Protoze sem to potreboval co nejryhlejs najit, tak sem nakonec skoncil u rychleho a efektivniho puleni ... odpojovanim casti site.

Takze bych se podivnym podivnostem zas tak nedivil ...

měl jste zvážit blackout a připojovat až to najdete. ale my máme půlení taky, racku jsou dva rack switche a ty jdou do tří různých topofrack a prostě stát se to může ale pak je otázka dejme tomu půl hodiny až hodiny ne čtyř.

navíc je rozdíl DC a nějakej korporát v DC je vše vázáno a autentifikováno na port takže dopátrat se anomálie by neměl být takovej problém, resp by to měl být set donekonečna se opakujících udalostí. byť asi ne uplně trénovaných např pomocí "chaos monkey" procesů.