Prosli jsme si vypadkem serveru a jak tomu predchazet

Ahoj, minuly patek v podvecer jsme u Gigaserveru zazili nehezke momenty. Vsechny weby komplet padly a to cca na dve hodiny. Ofiko vyjadreni mame toto: "Výpadek byl způsobem chybou v síti, což zapříčinilo, že některé servery nebyly dostupné ze sítě internet. Po zaznamenání výpadku došlo ihned k jeho řešení a všechny naše služby byly postupně obnovovány do běžného provozu. Uvedený výpadek neměl žádný dopad na klientská data na jednotlivých serverech. E-mailové služby, nebyly výpadkem vůbec ovlivněny." Jak se tohle v praxi resi, respektive jak se tomu predchazi? Vlastni servery? Tam je prece riziko vypadku nebo napadeni asi jeste vetsi, protoze neni v pozadi komplet firma s techniky. Tam doufam, ze vzdy bude tym techniku, ktery to da do pucu. Vlastni server a nejaka externi sprava rozhodne lepsi vysledky mit nebude. Resi tohle sluzby jako CDN? Podle me ne, ale nevyznam se v tom. Moje premysleni vede smerem, kdyz mam treba podnikovou mobilni appku, do toho CRMko a jedeme na vlastnim serveru u Giga a spadne to, tak jsme v pytli. Nejede nic. Co dělat? Když se live musí stahovat data ze serveru z API, tak pokud padne služba poskytovatele, je konec. Diky za vase zkusenosti a tipy, jak sluzby udelat kvalitnejsi a podobnym pruserum predchazet.

Někteří to řeší tak, že mají v záloze další řešení, jiného providera. Je velmi malá šance, že vypadnou oba najednou. Tím vykrejou tyhle několikahodinové výpadky. Jak je to řešené technicky, to netuším.

Buďte rád, že to bylo jen tak málo. Být například u wedos tak se tady upíšete k smrti :-D Vždy a všechno někdy vypadne, elektřina, internet, kabelová televize. Dvě hodiny jsou věci co jednou za čas jde zkousnout. Druhá možnost je vytvořit si své sítě, servery, zálohy, centrály, náhradní zdroje.

CDN tomuto predchazet nebude - CDN serviruje pouze staticky obsah, dynamicky obsah se stejne musi pocitat na nejakem plnohodnotnem serveru. Na predchazeni tohoto tento typu vypadku je nejjistejsi reseni mit vice serveru ve vice lokalitach a k tomu mit zarizenej anycast DNS. Na druhou stranu je to trochu overkill, jen na zajisteni nonstop dostupnosti, pokud to neni nejaka kriticka sluzba a je treba si polozit otazku, jestli se vam to vyplati, vzhledem k tomu, jak casto takovejhle vypadek nastane.

V první řadě to nelze nikdy na 100 % vyřešit, můžeš jen minimalizovat rizika. Pak vše záleží na rozpočtu, znalostech a rizicích, možností je velké množství a zkusím tady popsat ty nejčastější varianty z mé blubliny.Hodně drahé řešení je takové, že se používá anycast IP provoz (tvoji IP adresu má více serverů zároveň a více serverů na ní může odpověď) a provozovatel podle toho kde jsi směřuje tvůj provoz na nejbližší dostupné datacentrum/server, tak to třeba řeší Google, bezvýpadkové to není, ale má to vysokou míru odolnosti, také vysokou cenu na provoz, musíš mít nonstop někoho, kdo vše hlídá, celý systém je velice živý a těžký na konfiguraci a tedy chyby.Někdy stačí se s provozovatelem domluvit a zaplatit si u nich služby pro vyšší dostupnost, občas to mají i dobře řešené a umí se ti o to postarat, ale nikdy nemáš záruku, že neudělají chybu jako tady a nespadne jim to celé. Tohle bývá dominanta cloudů, které poskytují velké mnosžví k tomu určený služeb, zpravidla ale provozní náklady skáčou násobně.Pro nízkorozpočtové klienty nabízím řešení poloautomatického přepnutí na záložního provozovatele, doba výpadku může být třeba do 15 min a náklady na provoz jsou asi dvojnásobné, při výpadků může dojít k malé ztrátě dat, lze ošetřit aplikačně. Princip je jednoduchý, aplikace běží nezávisle u dvou poskytovatelů, jakmile u jednoho nastanou problémy, přepne se provoz na druhý hosting. Tady samozřejmě pomáhá třeba CDN, která umožňuje daleko rychlejší přepnutí s menším výpadkem. Výhodné je, že to lze poměrně levně postavit skoro pro každou aplikaci ne za moc peněz. Alternativou je mít kompletní zálohy staré pár desítek minut a umět si svoji aplikaci vč. databáze postavit z nuly a mít to odzkoušené u jiných hostingů, vyhneš se dvojitému placení hostingu, ale musíš počítat s delší prodlevou (těžko stíhatelné do 2 hod jako byl tenhle výpadek).Nejčastější řešení, které zajišťuji je ale rozkročená aplikace přes více serverů, více datacenter a více lokalit. Sice mám pořád jednoho poskytovatele, ale ten mi interně garantuje, že každá z částí je nezávislá a mně to stačí. Problém je s aplikační částí, celá logika aplikace s tím musí do posledního šroubku počítat, často je nutné nenechat kámen na kameni a vše složitě přizpůsobit a otestovat, v tomhle režimu třeba funguje stát, banky a operátoři. Vévodí tomu ale placený SW a technologie, zakládat to na open source je poměrně náročné na znalosti.Pro různé intranetové aplikace se často dělají lokální instance, které mohou fungovat i při výpadku internetu, fungují jako ostrovní systém a zajistí se nepřerušení provozu, aplikace s tím samozřejmě musí také počítat, hlavní náklady pak vznikají, když se znovu mají připojit zpátky do sítě po výpadku, tam často ten proces je poloautomatický, málokdy plně automatický.Před každým projektem si ale sedneme a projdeme si jednotlivá rizika, náklady, které způsobí nedostupnost a ztráta dat, stanovíme si kritické časové intervaly, projdeme a zmapujeme celý systém a následně se domluvíme, co dává smysl řešit a co naopak. Zpravidla vždy se z původních vizí, že chceme mít 100 % dostupnost, nula výpadků stává něco jako, že 2 hod nám vlastně tolik nevadí, hlavně že neztratíme data, máme zálohy dostupné i během výpadku a existuje záložní kanál, jak informovat uživatele, zákazníky.