Seznam měl výpadek kvůli proudu

Nejde vam take prihlasit se do SKlik?

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.

Hm, tak třeba mail rozhraní mi nejede už několk dní, tuším od neděle, a nejde to ani teď!! - "NĚKTERÁ Z KOMPONENT SYSTÉMU NEBĚŽÍ" Hmmm... :(

Takové hostingové centrum nemá záložní napájení? To se mi nechce věřit.

Ma, ale pokud vypadnou pojistky az za zaloznim zdrojem, tak je to na dve veci. (Nevim, jestli tohle byl presne ten pripad.)

Ještě ve dvě v noci nic nešlo, ale to je asi normální, asi není sranda vše po takovém výpadku zprovoznit

Ještě po třetí ráno nejel.

nejel ani když si to psal :D

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 :)

Takze tak...

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.

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.

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

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

No teda ja bych se citil jak blbec kdybych v hostingovem centru se zarucenym zalohovanym napajeni jeste daval kazdy server na UPS ...

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

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.

Vcera asi pul dne nejelo me oblibene radio Akropolis. Ani ogg stream, ani webserver, nic! Uz jsem se lek, ze se snad zrusili nebo co :-/

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.

Mají to řádně dojebkané, Seznam, smail, novinky.cz,... nic nejede jak ma!

Byl jsem dnes na stránkách apc.cz a narazil jsem na tuhle tiskovou zprávu:

Případová studie TTC Teleport

TTC Teleport: Tam, kde nikdy nevypadne elektřina

Kvůli velkému rozsahu sem dávám jen hlavičku, ostatní si můžete dočíst na www.apc.cz

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

Sorry, ale pokud mají 300 serverů a nahazují to ručně, tak si nic jiného než výpadky elektřiny nezaslouží.

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.

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 :)

.. naivko ;))

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?