Názory k článku Výpadek u hostingové firmy Ignum vyřadil na několik hodin weby klientů

Vaše VDS reagují na výpadek konektivity tím, že se na několik hodin vypnou? Připadá mi, že neříkáte celou pravdu.

co je vds?

mozna pres tu sit byly namapovany disky?

VDS = asi zkratka pro virtualni dedikovany server?

tak server je snad buď dedikovaný, nebo virtuální, ne ?

kdyz dojde k vypadku aspon s klienty komunikuji...

Jj, bezte vsichni k wedosu, ten nema vypadky, ten rovnou ztraci data klientu a obnovuje je z tyden starych zaloh :)

A co takhle si resit zalohovani svym resenim podle svych parametru a na casove bazi sobe vlastni?

To se u nich fakt stává? Už jsem kolem Vánoc reinstaloval jeden server, který u nich bez zjevné příčiny zkolaboval. Zákaznická podpora tehdy usilovně tvrdila, že jsem to jistě způsobil sám nějakým neodborným zásahem.

Ač se to nezdá, tak takovýto výpadek není technického charakteru. Může za to především personální oddělení :).

Když pes běhá po ulici a kouše lidi, tak to taky není chyba toho psa - on sám se nepustil :).

A pokud běžná rutinní údržba systémů může být naplánována a provedena takovým způsobem, že se stane tohle... Tak není primární vina na tom, kdo to takto provedl, ale především na tom, kdo ho k tomu pustil :-D.

Miluji odporniky, kteri v zivote neudelali chybu. Zvlast kdyz to jsou velci sefove a velkopodnikatele ...

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ů.