Bohuzel je to slozitejsi. Fyzicke disky mivaji cache, RAIDove radice taky. Databazovy server obvykle nema moznost pockat, az budou data fyzicky ulozena na disku - ten si mysli, ze je vsechno OK uz kdyz jsou v cache radice. Proti vypadku proudu (zvlast fyzickemu, kdy mohlo dojit k nejakemu kolisani) se softwarove branit prakticky nelze, klicova je hardwarova odolnost jednotlivych komponent. Druha vec je, ze tato hardwarova odolnost by mela byt vetsi u profesionalnich serveru nez u bezneho desktopoveho HW.
No, prave proto se doporucuje transakcni logy a vubec soubory tvorici tablespace databazi umistovat na RAID s vypnutou kesi pro zapis (staci pro cteni) - diky tomu, ze ctecich operaci e o par radu vice nez zapisovych tak to vetsinou vykonove neni zadny problem...
Ale tfuj, jednak tento konkretni problem beze zbytku resi Write-Through cache... a navic, ona takova financne bezcenna zalezitost jako baterie, ktera je schopna zapsat vse z radice na disk za dobu kratsi nez 1s je dobra vec... A to, ze se server ma korektne vypnout je otazka spoluprace UPS a stroje... (a to i po vypadku jisticu)... On-line UPS nejsou nejlevnejsi, ale pokud chcete 100% bezpeci, tak jinak nez redundanci toho nedosahnete...
Pokud mate redundantni zdroje a centrum Vam nedoda dve nezavisle vetve (dedikovane od centralniho jistice pouze Vam, o sdilenem segmentu vubec neuvazuji) energie to nevidim jako nenormalni... Ta pretizenost UPS je podivna, jak uz bylo naznaceno, kdyz nabeh (coz je taky spicka jak hrom) pred generatorem (coz je doba nezanedbatelna) unesla v pohode...
Tech problemu bylo vcera zrejme vic.
V pul devate vypadl jeden spoj net4netu (ke kteremu je pripojen i Seznam) do nixu, cast provozu se preroutovala pres druhy spoj.
Zrejme to bylo nasledkem vypadku nejakeho optickeho switche (at uz kvuli ztrate napajeni nebo z jineho duvodu). Spoj nabehl v 11 vecer, jestli zaroven s tim nabehl i seznam, to nevim, uz jsem byl offline :)
Na Seznamu vylaďují drobné chyby, ale nějak se jim to nedaří a začalo to zhruba před 2 týdny(zmizly ikony v diskuzi) a dnes to má pokračování - nejde se přihlásit do diskuze.
Ak ma niekto jeden server, tak ak nabehne, tak staci len skontrolovat, ci bezia vsetky dolezite veci.
Ak ma niekto viac serverov, tak nie su navzajom nezavysle.
Mame servery v GTS, nie je ich 300 :)) ale ak chcem aby vsetko bezalo ako ma, tak ich musim nahadzovat v urcitom poradi. Napr. file-servery, ktore su na ostatne namountovane cez nfs musim pochopitelne nahodit ako prve. Taktiez databazove serveru musia byt skor. Az po nich mozem nahodit web servery a nakoniec cache servery. V opacnom poradi, pripadne vsetko naraz, by to znamenalo, ze to nenabehne korektne a bolo by nutne vela veci restartovat a nahadzovat rucne.
Takyto postup sa tazko planuje, aby to nabehlo automaticky samo. Preto uplne chapem, ze Seznam sa prebudzal postupne. Ono dost pravdepodobne, po nabehu napajania museli servery najprv povypinat, aby ich zase nahodili tak ako treba....
je patek 12hod a mail porad nejede a seznam dela jakoby nic. Maily na helpdesk se vraceji jako nedorucitelne a tlf je permanente obsazen. Co jim brani v tom, aby dali nejakym zpusobem vedet, co se deje? To tam maj vsichni dovolenou?
Heh zasada prvni-1 - kdyz poucuju ostatni, ridim se alespon pravidly, ktera jim vtloukam...:-)
Aneb transakce (a je uplne putna, co si pod timto abstraktnim pojmem predstavite za implementaci) se odroluje a jede se dal, zadna potvrzena data v haji, zadne rozpadle systemy...
net4neti swicthe jsou umisteny v TTC, takze byly bez napajeni.
Seznam skutecne nejel dele, maji tusim pres 300 serveru a prece jen nikdo nemuze byt staveny na reseni tak rozsahleho vypadku do 30 minut, to by musel u kazdeho serveru stat jeden clovek. Jenze v noci pred svatecnim dnem byla pulka republiky pod parou, takze jestli sehnali 4 zive adminy tak to bylo moc, navic tim ze se dlouho probirala sit net4net, tak se tam admini asi nedostali vzdalene, museli jet na misto a potom zase narazite na nedostatek konzoli na kterych je mozne neco delat. I kdyz 4 vlastni tam seznam asi ma. Navic kdyz slo dolu napajeni, tak tam byly asi velke napetove vykyvy, takze stroje byly obecne v horsim stavu, nez kdyby je jen tak nekdo vypnul.
A ze cendra keca o rozsahu vypadku tak nejak patri k jeho koloritu.
...proc by meli admini jednotlive servery ozivovat z konzole. Pokud slo opravdu jen o vypadek proudu, takovy server by mel byt schopny opetovne nastartovat sam, at uz je jeden, nebo tri stovky :/
asi je velikej problem otestovat dostupnost sluzby a tim pockat s bootovanim systemu ..... ale proste tam nikdo s nicim takovym nepocital a treba delali takovou vec prvne v zivote :) nebo vy si rebootujete takovou farmu 2x mesicne jen tak z nudy ? poucej se a priste jim to bude makat :)
Pravidlo cislo jedna.
Cemu nerozumim, do toho nemluvim a nasloucham, nebo se ptam.
Pokud vypnes samostatny server korektne a znovy ho zapnes, tak ve vetsine pripadu vse pojede jak ma.
Pokud mas serverove clustery, provazane servery, externi diskova pole a jine vopicarny a zcela nekorektne v pulce relaci vypnes proud, tak si tim cely system rozsypes.
Nekonzistence databazi, nekorektne zapsana data na diskovych polich, atd.
Stejne tak zapinani tak rozsahleho systemu - site serveru neni zadna prdel. Musis to nahazovat postupne, u vseho overovat funkcnost a konzistenci dat, zapinat jednotlive casti postupne, podle predem daneho postupu. Tak aby vse jelo jak ma.
A mezi tim jeste resit chyby dane nekorektnim vypnutim.
Tohle neni zadna prdel, kdyz mas 6 serveru a diskovych poli. Natoz kdyz jich mas stovky.
Ale chapu, ze pro nekoho, kdo ma doma jeden SOHO routrik a 3 desktopy, ze pro nej to muze byt spanelska vesnice. Pak se ale takovy uzivatel muze zdrzet chytrackejch kecu.
takze zrejme prispevek jednoho z adminu seznamu, ktery si kdysi usetril praci a ted ma fofry :)
Doby kdy me jeden domaci routrik a 2 desktopy zamestnaly na 24h denne jsou pryc. Sice nespravuju 300 serveru, ale sakra dobre vim, jake problemy muzou nastat pri takovem vypadku.
Ale na tohle se ma myslet uz od zacatku, delat neco jen "na pul" je k nicemu...
Jo, tak začalo to maily, to předevčírem a včera i celým Seznamem. Ten dělá opět mrtvého brouka.... Ale není to jen Malešicemi, je to i dalšími... Takže, milý Ivo, prosím o soustředění se na jistotu a bezpečnost a energetické zázemí... nešlo to od cca 20:30 do 3:30 a ještě dnes se zobrazovaly staré informace na HP...
No výpadek byl od půl devátý někdy do jedenácti nebo půl dvanáctý, potom všechno naběhlo. Kromě seznamu, ten se z toho rozsypal a ještě teď to možná neni úplně v pořádku.
Server by se měl postarat sám o sebe. Pokud nemůže něco udělat jako třeba to přimountování, tak by měl počkata až to bude možné a pak pokračovat dál v nahazování ostatních věcí. Jestli to opravdu mají jak popisuješ tak se divím, že jim to ještě jede.
Pokud ma mala firmicka 10 serveru s MySQL a PHP, tak opravdu se mohou po zapnuti sami nahodit.
U slozitejsich systemu, napr banka, seznam, je automaticke nahazovani silenost, protoze vzajemna provazanost systemu je moc velka.
Napr. Oracle je na nestandartni vypnuti tak haklive, ze je lepsi to vzdy prekontrolovat rucne. Uz jsem par databazi ktere se dostaly do stavu corrupted po vypadku produ videl.
Take napr. aplikacni servery (weblogic) se nahazuji (startuji) treba 15 minut.
Troufam si tvrdit, ze Centrum by to prezilo lip (pokud by nebyla nejaka velka smula). Koneckoncu, nedavno na Naganu vypadla klima, takze se dost serveru prehralo a poroucelo dolu (coz je horsi, nez kdyby jen vypadl proud) a taky nebyl problem.
Druha vec je, ze moc neverim tomu, ze by se neztratily vubec zadne maily... To by se musela informace o mailu pred poslanim OK na SMTP DATA prikaz fdatasync()ovat na disk. Coz by zbrzdovalo a v pripade ukladani informaci do DB je to i dost obtizne proveditelne.
Pravidlo cislo jedna.
Cemu nerozumim, do toho nemluvim a nasloucham, nebo se ptam.
Pokud vypnes samostatny server korektne a znovy ho zapnes, tak ve vetsine pripadu vse pojede jak ma.
Pokud mas serverove clustery, provazane servery, externi diskova pole a jine vopicarny a zcela nekorektne v pulce relaci vypnes proud, tak si tim cely system rozsypes.
Nekonzistence databazi, nekorektne zapsana data na diskovych polich, atd.
Stejne tak zapinani tak rozsahleho systemu - site serveru neni zadna prdel. Musis to nahazovat postupne, u vseho overovat funkcnost a konzistenci dat, zapinat jednotlive casti postupne, podle predem daneho postupu. Tak aby vse jelo jak ma.
A mezi tim jeste resit chyby dane nekorektnim vypnutim.
Tohle neni zadna prdel, kdyz mas 6 serveru a diskovych poli. Natoz kdyz jich mas stovky.
Ale chapu, ze pro nekoho, kdo ma doma jeden SOHO routrik a 3 desktopy, ze pro nej to muze byt spanelska vesnice. Pak se ale takovy uzivatel muze zdrzet chytrackejch kecu.
...staci se podivat na verejne statistiky NIXu a je videt, ze k vypadku doslo jiz po pul devate - nikoliv v pul desate, jak publikum presvedcuje mladenec Cendru ;)