Názory k článku Výpadek TTC ochromil 200 tisíc e-mailových schránek Seznamu

Vážení, toto jsem poslal do helpdesk@seznam.cz bez odezvy: Dnes asi před hodinou došlo k nežádoucímu smazání všech mých odesl. i doručených mailů, které jsme tvořili skoro rok.
Ve 22.20h tam ještě byly. Pak jsem to zavřel, a teď po 2 hod tam není ani čárka. Vidím to doma. Šlo by maily prosím obnovit? 28.7.06 23.49h
Děkuji Novák
--------------------------------------------------------------------------------
PS:rupert.upert@centrum.cz mi ukradl všechny maily!Někdo asi prolomil mé heslo a pozměnil Vaše nastavení přesměrování takto:

Adresa: rupert.upert@centrum.cz Sem zadejte emailovou adresu, na kterou má být přesměrována vaše pošta.

Filtry pro příchozí poštu
Číslo Název Stav Posun
1. Vždy pošli upozornění na eucz@atlas.cz Přišel nový email! zapnutý upravit Přesuň o úroveň výš Přesuň o úroveň níž
2. Vždy pošli zprávu na adresu rupert.upert@centrum.cz zapnutý upravit Přesuň o úroveň výš Přesuň o úroveň níž
3. Vždy zprávu hned smaž zapnutý upravit Přesuň o úroveň výš Přesuň o úroveň níž

Tušíte kdo mi to provedl? Toho rupert.upert@centrum.cz bych mohl žalovat? Víte o něm něco? Jsem v tom sám? Jak získat mé maily zpět? I ten mail od Vás ze cca 31.7.2006-pošlete mi jej prosím znovu?
Děkuji Novák a7a@seznam.cz

btw. a mirku uklidni se :P
to že si bfu neznamená,že je linux špatný
narozdíl od windows jsou unixové systémy nejstabilnější os ;)
windows bych na server nedal nikdy,to rači 5 let starou distribuci linuxu :F

naprosto souhlasim, mám linux na kompu s 233Mhz a jel mi dohromady celkem týden dokud sem ho nevypl, CPU load se pohybovalo od 99-100% :) a linux vesele šlapal, chtěl bych vidět okna na třeba kompu s 1GHz procesorem a 256MB RAM, lol už to vidim. Navic souhlasim s tim, že u takto obrovský diskových polí je vypádek elktriky katastrofa, nadruhou stranu mě taky během toho týdne vypadla elektrika, PC jsem v pohodě nahodil a akorát co se mi neuložilo, tak bylo jedno nastavení session. Už vidim jak by na podobnem stroji jely 95 či 98 wokna, už vidim, jak by mě zastavil scandisk při startu.

Každopádně borcům stohodle telehouse bych ukroutil ručiččky a poslal je s tim i někam na ukrajinu, to by mě zajímalo jak to kontrolovali, když se jim to druhý den posralo. Tohle si můžu dovolit já doma, když seeduju torrenty, a ne telehouse takového rozměru, že je tam i seznam.

Taky jsem čekal, pak mi je obnovili, ale bez neobnovili složky, adresy, ani filtry. Takže mi všechnu pečlivě roztříděnou poštu nahrnuli do Doručené.

Chtel bych se zeptat uzivatelu emailu, jestli take jeste nekdo ceka na obnovu svym mailu kvuli vypadku na seznam.cz nekdy minuly tyden, uz nevim presne kdy to bylo, ale vim, ze ubehl vic nez tyden a me se porad zobrazuje cervene upozorneni-Obnova mailu potrva nekolik dnu...blablabal...
dvakrat uz sem psal na seznam helpdesk seznam.teamu a ani se neobtezovali odpovedet...
zajimalo by me kolik lidi jeste takto ceka na sve maily a adresy

Mily ziak strednej/zakladnej skoly. Kolko kernel panic-v si videl osobne na kolkych strojoch nasadenych na kriticke aplikacie?

Ale Michale,

ze jsi to s tou svoji sestrou nemyslel vazne ;-)

Stejnosměrného napájení se výpadek nedotkl...
jo telco zařízení používají 48 V DC ... to jen IT bazmek používá 230 V AC...

Sloušné telco zařízení je napájeno takto... Suměrňovač a zdroj 48 V který trvale dobíjí baterky a znich je napájeno vše potřebné... žádné UPS invetrory atd...

Před tím je samozřejmě pořádný diesel nebo spíše dva až tři...

Tak to je rozdíl mezi telco a IT mimo jiné...

Hmm, 98% mi nepřipadá mnoho na kvalitní redundanci. Mezi námi ošetření proti úderu blesku může být i značným problémem. Záleží na vodivosti okolní půdy, jejím geologickém složení a rovněž technologii silnorozvodů po domě nemůžeš podcenit.

Uder blesku (i primy) jiz lze dneska technicky osetrit. Ostatne i kvalitnejsi rodinne domky dneska dokazi prezit primy uder na 98% bez poskozeni doma elektroniky. Pri investici radove par desitek tisic do svodicu bleskovych proudu a omezovacu prepeti.

No je pravda že používám verzi 5, ještě na okraj MySQL běží na kuse šrotu (P4 2.4GHz, IDE disk)
ORACLE má HP Proliant Xeon s 10k disky 1.5TB RAID5
Takže ani nesrovnávám rovnocenný hardware na tu workstajšnu bych se ORACLE bál spustit :)
Každopádně v něčem je rychlejší ORACLE v něčem MySQL
ORACLE se vyznačuje tím že je v něm ukrutnej bordel (jak starej hrad v karpatech) spousta věcí postrádá logiku
Přenositelnost mezi jednotlivými verzemi je bídná (fungovalo vám to v 9i? v 10g nebude :)
Nezkoušel někdo IBM DB2? Vypadá mnohem lépe, alespoň na můj první subjektivní dojem

Kazdopadne poznamka, ze NTFS je zurnalovaci byla trochu zbytecna, vzhledem k tomu, ze i v puvodnim prispevku ten clovek psal, ze NTFS je zurnalovaci.

IBMka dodava v oblasti storage pouze lown end to mid end, high end reseni vubec nemaji. A tohle konkretni pole je spise jedno z tech levnejsich co nabizeji.

No, nevim jesli tohle je zrovna low end :o). Rekl bych, ze spise stredni trida. Lowendy si predstavuji trochu jinak :o).

Asi takhle, doma mam router samozrejme nastaven tak, ze se pri obnoveni napajeni zapne, ale v datacentru je A) vzdy obsluha B) neni zadny velky problem realizovat to automaticky.

V tech vice "homemade" datacentrech se pouzivaji naprosto bezne dnes uz snad vyhradne ATX zdroje, MB ... proste bezna PC. Neni problem si od kazdeho vytahnout ten spravny kusdrat a dovest jej na panel s tlacitky + pripadne pridat nejakou trivialni elektroniku ktera nebude mit na starost nic vic, nez se po nabehu napeti pocka po definovany cas (nekdy jak znamo to padne opakovane v kratkych intervalech) a pak zacne v definovanych intervalech spoustet jednotlive stroje. Signalizace uspesneho startu je pak uz otazkou trivialniho scriptu.

Nepochybuju, ze je totez mozne u profi HW do racku. Pripadne pripada v uvahu trivialni reseni pomoci stykacu pro jednotlive racky.

Nebylo by nahodou lepsi vracet obe ty IP ? On uz by si to klient nejak prebral.

Predne, v profi data centru startuje generator temer okamzite, maximalne do dvou minut. UPSka je tak na pokryti mzikoveho vypadku ale ne na to, aby udrzovala stroje v behu.

A to nemluvim o tom, ze v zadnem pripade nesmi dojit k takovemu vybiti baterii aby se stroje nestihly korektne vypnout. Doma si muzete dovolit vypinat stroj pri 20% nebo mene, ale v data centru by melo jit vse dolu tak pri 50% aby se to bez problemu stihlo => po cca 5ti minutach provozu bez generatoru by se mely zacit stroje shazovat.

Prave u tech profiku bych ocekaval, ze akumulatory pravidelne meni nebo alespon premeri, coz je trivialni operace. Otestovat celou UPS nebo alespon jeji jednotlive vetve neni taky nic tak sloziteho. Pri predpokladu, ze mam alespon jednu vetev jako zalozni muzu vzdy prepnout na ni a otestovat postupne celou UPS.

=> pokud to funguje jak ma, tak 2 minuty trva nez nabehne generator, kdyz umre, zbyva jeste 8 minut provozu na UPS => po dalsich 3ch minutach vydava UPS pokyn k vypnuti vsem strojum.

Mimochodem, telefoni ustredna musi mit dostatecne zdroje k udrzeni plneho provozu po dobu 48hodin + nouzoveho provozu alespon tyden (mozna to je dokonce 14 dnu). Nouzovym provozem se rozumi odpojeni domacnosti a firem - v provozu zustavaji verejne automaty, urady, nouzove linky.

Pokud vim, subselecty jsou pouzitelne az v 5.x verzi a ta je jeste v hodne bourlive se vyvyjejicim stadiu.

jo, je to tady ke stazeni. Zipnute PDFko http://www-5.ibm.com/cz/bluerose/download/2_2006.zip

Pouzil lowendovou storage, takze az tak moc moznosti nemaji. Evidentne primarni pri rozhodovani byly penize, ale u firmy stredni velikosti jako je Seznam je to vcelku pochopitelne.

Dneska už mi také oba vrací náhodné výsledky. Asi něco změnili na konfiguraci. Stejně je to podle špatně, protože to nevede k výběru lepší trasy pro zákazníka.

Pro spekulanty ohledne HW Seznamu bych doporucil podivat se na posledni Blue Rose (vestnik IBM http://www-5.ibm.com/cz/bluerose/download/2_2006.zip), kde je rozhovor s Pavlem Zimou, ktery je okoreneny i par obrazky a hovori tam o konkretnich serverech, o konkretnich diskovych polich. Co ty pole umoznuji ci neumoznuji si lze pak jednoduse dohledat na strankach vyrobce :o). Myslim, ze uz otazku Remote Mirror Copy intenzivne resi, alepson se to tvrdi v kuloarech. Co se tyce pouzite technologie HW, tak si myslim, ze Seznam pouzil v dane kategorii jedno z nej reseni pri opravdu optimalnim pomeru cena / vykon a to se nebavime o polich za 50 tis, ktere si nekde umota Ferda v obyvaku ze Sata disku z Alzasoftu.

> obecne jsou disaster recovery techniky nasazovane u
> kritickych aplikaci a ty v naproste vetsine pripadu maji
> tendenci ke znacne slozitosti.

Souhlas.

> 15, 20, 50 km to je fuk, tohle neni geograficka zaloha...

Mozna vas to prekvapi, ale praxe rika, ze 15+ km JE geograficka zaloha. Minimalne v realnem svete to tak funguje. Pred nejakou dobou jsem shanel ruzne reference na opravdu vzdalene clustery a s vyjimkou Ameriky, kde zejmena na Floride byva zvykem mit zalozni datacentrum opravdu daleko (velmi casto az na East Coast - West Coast vzdalenost) jsou v Evrope ale i na dalsich mistech zdaleka nejcastejsi geograficke mirrory na vzdalenost jednotek maximalne malych desitek kilometru. Nejsou dokonce neobvykla ani disaster recovery reseni pres ulici, i kdyz to je i na mne docela podcenene.
Co se tyce privodu energie, tak u nas to funguje tak, ze kriticke businesses (rozvodne zavody, plynarny, banky, ...) maji domluveny v pripade nestesti dodavky ze statnich rezerv. Takze pokud vypadne proud nejenom, ze generatory udrzi nejakou dobu datacentrum v provozu, ale v pripade nutnosti prijede i "statni cisterna" naftu doplnit.
Co se tyce extremnich katastrof jako treba jaderna havarie a podobne, tak je treba si uvedomit, ze datacentrum neni zdaleka jedine slabe misto. Klasickym prikladem bylo jedenacte zari, kdy vetsina firem umistenych ve dvojcatech a okoli mela zalohovana datacentra v nepostizene oblasti, ale presto nebyly schopny fungovat po utocich tydny az mesice. Ne kvuli problemum s IT infrastrukturou, ale proste proto, ze nedokazaly zvladnout vzniknuty chaos.
A to je primarni limit pri velkych nestestich. Neni to o tom, ze dojde ke zniceni prilis blizkeho datacentra, ale o tom, ze firma neni vojenska jednotka, aby dokazala fungovat pri zniceni linie veleni a ztratach personalu v desitkach procent. Je pekne, ze dokazete preclusterovat na dveste kilometru vzdalene servery, ale nedokazete preclusterovat lidi.
Treba takova burza v NY nemela po 9/11 zadne neresitelne problemy s IT, ale stejne radeji na tyden prerusila obchodovani, protoze vznikly chaos nebylo mozne zvladnout a obnovit funkcnost.
Reseno ve zkratce: "pokud dojde k havarii srovnatelne s Cernobylem, nikdo nebude resit jestli mu funguje nebo nefunguje zalozni datacentrum, protoze vsichni budou mit uplne jine starosti.

> Ta komplikovanost zavisi od aplikace. To co popsal u
> mailu je pomerne realne a neni to zas tak slozite.

Ano, nicmene obecne jsou disaster recovery techniky nasazovane u kritickych aplikaci a ty v naproste vetsine pripadu maji tendenci ke znacne slozitosti. Dat dohromady rozjety databazovy cluster, kde neni problem mit radove vysoke stovky ruzne provazanych tabulek je nekde mezi velmi komplikovanym az nemoznym.

Tak to s windows asi moc neumíte, v práci administruji dva win 2000 servery a BSOD jsem ještě neviděl, uptime jsem měl 290 dní, pak se firma stěhovala do jiných prostor, takže se server musel odpojit.
To s přehazováním disků je asi jasné, linux má většinu známých chipsetů kompilované v jádře které se spouští hned při startu, takže mu přechod např. z via na intel nebude dělat problém. Ale nic proti, osobně harddisky nepřehazuji z jednoho serveru do jiného. Server je od toho aby poskytoval služby a ne aby se s ním experimentovalo. Taktéž existují záložní servery, které při výpadku primárního budou nadále obsluhovat uživatele.

A jeste jedna dulezita vec: Stejne nad temi daty musi byt nejaka aplikace, ktera je spravuje (viz moje odpoved vyse), takze pouzitim diskoveho pole se tem rizikum nevyhnete.

Nevim, proc s tim srovnavate aplikaci Centra, ta je o mnoho jednodussi, nez GFS - odpovida moznostem Centra.

To že bagrista překopne 22 kv kabel a nevšimne si toho je poměrně nereálné, mohlo by mu být nápadné proč má v lžíci vypálený díry :-D

Ajta - objevil jsem ve svém příspěvku nepřesnost. ATX zdroj hodí inrush špičku po výpadku i v případě, že je BIOS nakonfigurovaný, aby se stroj automaticky nezapínal. Tohle soft zapínání totiž funguje z větve standby power, která v každém případě potřebuje nabitý vstupní kondík, a ten se v každém případě připojuje silovým kolébkovým vypínačem na zadní straně zdroje, pokud ho zdroj vůbec má...

Odpusťte mi to rýpnutí na téma Internet vs. atomová elektrárna, problém s inrushem bude v obou případech.

Rozdíl bude až v následném zvýšeném odběru při rozběhu(nabíjení výstupu zdroje, roztáčení disků apod.). Tento odběr by neměl překročit štítkový odběr zdroje.

zrovna ctu blue rose - firemni casopis IBM a je tu super clanek kde Ludmila Hamplova ze spolecnosti Servodata zpovida Pavla Zimu -tech reditele Seznamu.
Obsah si domyslete sami.
Nemam nic proti IBM, sami je masivne pouzivame, muj zaver je: at vymyslite cokoliv, vzdy se to vyse.e jinde. Toliko mych cca 25 let v IT.

Uz jsem psal, ze zaklad je udelat tu aplikaci jednoduchou.

Navic si uvedomte, ze i superprofesionalni pole je porad jenom disk a potrebujete nad nim nejakou aplikaci, ktera ta data spravuje. A ta taky neni uplne jednoducha (spis mozna slozitejsi), taky muze nadelat pekne briklule, taky na ni stoji uzivatelska data a taky potrebujete lidi, co ji rozumi.

Jinak pokud to reseni bezi a je dobre zdokumentovane (coz si chce samozrejme pohlidat), tak neni zasadni problem, aby se ho naucil jiny schopny programator.

Samozrejme kdyz budu ne-SW firma a shodou okolnosti budu potrebovat velke redundantni pole, tak si asi koupim hotove reseni. Ale pokud tak jako tak potrebuju mit ve firme schopne programatory, tak to zas takove riziko navic neni.

To byl vtip, byl za tim smajlik, nemyslel jsem to ve zlem ;-)

Ale to neustale zduraznovani "profesionality" reseni mi prislo dost obchodnicke. Neco jako "nejprodavanejsi pojisteni" nebo tak.

http://labs.google.com/papers/gfs.html

Hm, já bych řekl, že ke správnému náběhu serverů může sloužit třeba IPMI nebo sériová konzole, a nikdo nemusí servery obcházet, ne?

I ty nejlevnější servery za pár korun tuto výbavu mají, třeba tyhle 1U: http://www.msi.com.tw/program/products/server/svr/pro_svr_detail.php?UID=551

No zkoušel jsem to před týdnem i dnes opakovaně vícekrát (nejméně 10x) a vždy vrací IP adresu opačného providera, než u kterého ten nameserver je.

Což je podle mě špatně, protože DNS klient zpravidla používá odpověď z lépe dostupného nameserveru, a použité řešení vždy nasměruje uživatale tou trasou, které je pro něj horší. Jak je to v případě výpadku jedné trasy nevím, minulé úterý při výpadku to házelo adresy úplně stejně, jako dnes, to jest křížem, i když byl seznam down.

Jak to je jinde:
Pri beznem testu jednoho DSA doslo k poruse na DSA, odesel
generator.
V patek mel bagrista provadet skryvku zeminy, bohuzel se mu
pokazil bagr a tak to delal v sobotu, kdy nebyli jaksi lide
na kontrolu. Prestoze mel delat skryku zeminy tak skryval tak, ze sundal jedno 22kV vedeni, aniz by si toho vsiml.
(ony se ty vedeni nekde sbihaji a tam provadel skryvku)
Za chvilku sundal i to druhe, toho uz si vsiml.
Pri najezdu druheho DSA se zadrel pastorek starteru
(taky bezne prochazi kontrolou startu a behu),zustal v kole a sundal DSA.
Tak to jelo cca 1hod. z baterek.
Co myslite ze bylo pote :(
Lokalitu radeji neuvedu, mam duvod.

Jak to je jinde:
Pri beznem testu jednoho DSA doslo k poruse na DSA, odesel
generator.
V patek mel bagrista provadet skryvku zeminy, bohuzel se mu
pokazil bagr a tak to delal v sobotu, kdy nebyli jaksi lide
na kontrolu. Prestoze mel delat skryku zeminy tak skryval tak, ze sundal jedno 22kV vedeni, aniz by si toho vsiml.
(ony se ty vedeni nekde sbihaji a tam provadel skryvku)
Za chvilku sundal i to druhe, toho uz si vsiml.
Pri najezdu druheho DSA se zadrel pastorek starteru
(taky bezne prochazi kontrolou startu a behu),zustal v kole a sundal DSA.
Tak to jelo cca 1hod. z baterek.
Co myslite ze bylo pote :(
Lokalitu radeji neuvedu, mam duvod.

Asi pul roku stara featura. A vraci to zaznamy funkcniho providera, pripadne na stridacku vsech provideru.

> Cluster SW to tudiz resi nastavitelnym parametrem (obvykle
> radove minuty) po ktery se zastavi zpracovani

No potes koste :-)

> Jinak bych jeste dodal, ze rozjety cluster rozhodne
> nevyresite na "vyssi vrstve abstrakce" at uz jde o soubory
> nebo o databazi. Jedine misto kde lze takovy stav vyresit je
> aplikacni vrstva a to jeste velmi komplikovane.

Ta komplikovanost zavisi od aplikace. To co popsal u mailu je pomerne realne a neni to zas tak slozite.

Nojo taky mám všechny servery tak nastavený... :-) Hned se zapnou, těžko říct co je dobrej nápad.
Každopádně obcházet tolik serverů vypnout je a pak zase postupně nahazovat asi není zrovna velká legrace. Když jsem dělal u jistého soukromého rádia tak bylo normální že celej barák jel na hranici možností a jakýkoliv výpadek proudu znamenal všechno vypnout a postupně zapínat. Velká UPSka taky vydržela 40 minut, ale zapínání pulzních zdrojů neměla v oblibě. Vždycky na ní mrklo přetížení :) ošklivej pocit obzvlášť když jsem to měl na starosti tak se člověk skoro modlil ať nechcípne.

Hmm, na 230V je inrush při zapnutí opravdu velký. Někteří výrobci udávají pětinásobek maximálního trvalého štítkového příkonu spínaného napájecího zdroje, podle mého je tahle hodnota stejně podle palce. Vstupní odpor vybitého zdroje prakticky odpovídá "pár drátům do zkratu", a PFC na tom nic nemění.
Pomalý náběh (nabíjení vstupního kondíku) jsem u počítačového zdroje ještě nepotkal.

Jakékoli konkrétní číslo ve stovkách procent je podle mého lehce nepodložené, zatížené "dělením nulou". Takové naddimenzování výkonových částí není úplně jednoduché zařídit, hlavně to není levné. Podle mého to není správný přístup k problému.

Teoreticky by se to na straně UPS dalo ošetřit tak, že by UPS měla omezení výstupního proudu a definovaný provoz do zkratu po nějakou omezenou dobu (jednotky sekund). Těžko říct, nakolik by to bylo obvodově složité a uregulovatelné.
Pro počítačové UPSky všech výkonových kategorií by to rozhodně dávalo smysl.
Fakt je, že prakticky jsem takovou UPS taky neviděl.

Terminologická poznámka: "smart" UPSky od APC jsou "smart" v tom smyslu, že zvládají komunikaci nějakým protokolem po RS232, tj. nikoli pouze primitivní diskrétní/logickou signalizaci přes režijní modemové signály sériového portu jako levnější modely. Nevím o tom, že by menší "smart" UPSky měly nějakou explicitní podporu pro omezení inrush špičky.

Fakt je, že větší počet malých UPSek by se s inrush špičkou mohl vyrovnat lépe než jedna velká. Zejména malé offline UPSky, které obsahují klasické trafo na 50 Hz dimenzované na cca 20-50% jmenovitého výkonu, mají omezení výstupního proudu jaksi v základní výbavě :-)

Mimochodem, to přetížení UPSky po opětovném naběhnutí po výpadku je druhotný problém. Obsluha to zjistí, obejde počítače, vypne vypínače, nahodí jističe a jede se dál. Primárním problémem je sám výpadek proudu - ten způsobil narušení souborových systémů.

Na okraj:
Technici "od Internetu", když si kupují server s ATX zdrojem, obvykle požádají o BIOS předkonfigurovaný tak, aby server po výpadku napájení rovnou naběhl - aby nemuseli po výpadku cestovat do serverovny.

Mluvil jsem na toto téma s člověkem, který má na starosti nějaké méně důležité servery v atomové elektrárně - a ten naopak tvrdil, že žádá vždy server předkonfigurovaný tak, aby po výpadku napájení hlavně zůstal vypnutý - že je lepší, když obsluha servery obejde, po jednom nahodí a zkontroluje úspěšný start.

> Vyborne! Konecne odesli obchodnici s HW
>
To Vas zklamu, mne taky zivi hardware - maly hardware :-> Velky hardware jsem zatim videl jenom zdalky zamceny ve skrini nebo zdokumentovany v manualech. Maly hardware, male problemy... Ale soubeh optickych tras jsem prakticky obcas potkal.

Asi na tom něco bude, ale u bodu 6 je jasný zádrhel 200% je málo.
Pulzní zdroj při zapnutí hází velkou špičku, a to při tom množství serverů musí být pěkná rána to by chtělo dimenzovat aspoň 1000%
Připojení serverů najednou musí bejt pěknej šok pro UPS
Ani se nedivím že to neutáhne...
Nedivíte se že když zapnete počítač tak blikne žárovka?
Proudový náraz je opravdu velmi velký zařízení se musí
připojovat postupně.

Nevšiml jsem si, jestli tady někdo dával odkaz na tiskovou zprávu APC TTC Teleport: Tam, kde nikdy nevypadne elektřina

Je tam poměrně podrobně popsáno, jak je zálohování TTC Teleportu uděláno. Pár nejasností ale zbývá:

Do objektu jsou přivedeny dvě nezávislé vysokonapěťové přípojky 22kV. To vypadly (nebo byly podle IL okolo 20 h plánovaně odpojeny) obě dvě? A jsou pak opravdu nezávislé?

Podle TZ APC je zálohování zajištěno dieselagregátem s výkonem 1 MW a zásobou nafty na 10 hodin, pro překlenutí jeho náběhu jsou použity dvě UPS 240 kW, která každá zvládne až 200 % zátěž pod dobu 1 minuty. Kapacita baterií má vystačit na 30 minut provozu.

No a co se (údajně) přihodilo:
1. Byly odpojeny obě vysokonapěťobé přípojky 22 kV.
2. Po dobu náběho motorgenerátoru jedou UPS jen z baterií, což pro ně není snad žádný problém, když jsou online?
3. Naběhne motorgenerátor a po 20 minutách se přehřeje a automaticky vypne.
4. Zátěž opět přebírají UPS (mají vydržet 30 minut)
5. Ve skutečnosti jsou ale baterie vybité už za 10 minut, a celá serverovna zrácí napájení bez toho, aby byly servery korektně shozeny. (UPS jsou dvě, vypadly obě současně?)
6. Poté, co po 12 minutách ve 20:47 naběhla síť, jedna z UPS nevydržela vysokou zátěž při zapnutí (Jak je to s tou 200% odolností? Jaká je skutečná zátěž při zapnutí?)
7. Nějakou blíže neurčenou dobu tedy běžela serverovna na jednu 240 kW online UPS a druhá část byla zřejmě připojena napřímo (UPS má "Automatic internal bypass").

Takže je nejasné, jak je to s tou nezávislostí dvou VN přípojek a k čemu vlastně jsou, jak je to s výdrží UPS (10 nebo 30 minut?) a proč jedna nevydržela náběh.

Z hlediska uživatelů by bylo zajímavé vědět, jestli je k dipozici z těch UPS nějaká signalizace, umožňující včasný shutdown, pokud ne, tak je to myslím podstatná chyba, pokud ano, tak proč nebyly servery korektně vypnuty?

Seznam také asi mohl a měl udělat mnohem víc - minimálně u serverů a diskových polí, které jsou kriticky závislé na korektním vypnutí, měly být instalovány malé inteligentní UPS s řízeným náběhem, které by zaručily dodávku proudu po dobu shutdownu.

Máte někdo nějaké informace, ať už co se skutečně přihodilo a jak je to zařízené v TTC Teleport, nebo jak se to dělá jinde?

Vyborne! Konecne odesli obchodnici s HW a nastoupil nekdo, kdo problemu rozumi a je schopen analyzy :-)

Je spravne receno, ze problem je v tom, ze HW pole neni schopno samo o sobe resit nektere situace bez dalsich informaci (omezujicich podminek) z aplikacni vrstvy. (Ani kdyby na nem delalo tisic programatoru sto let tak neni ;-)

Ten system co popisujete je docela realisticky. A jak se muze pan anonym (co jsem si s nim psal predtim) presvedcit, neni ani nijak slozity.

Co se tyce opetovneho sesynchronizovani, tak jednosmerne operace (smazani, pokud je tak udelane) jsou bezproblemove. U ostatnich (o/odznacovani mailu, presun mezi slozkami) proste bude vysledek "nejaky" a da se zajistit, aby konecny stav odpovidal (u konfliktnich operaci) stavu na jedne a replik.

Myslím že je škoda se dohadovat o tom jestli MySQL je horší než nějaké jiné komerční produkty. Sám mám 1TB dat v MySQL a 30GB v ORACLE a rychlejší se jeví MySQL. Dokonce jsem zažil jak chybně zvolený dotaz úplně zmrazí ORACLE (CPU 100%) odezva ostatních tablespace otřesná. MySQL bezproblémů odbaví dotaz v jiné databázi (zátěž CPU cca 80%)
Místo standardní 0.001s to ale trvalo obrovských 0.7s
Oracle nicméně odpovídal v řádu mnoha sekund
Všechno je relativní...

Pletete dohromady par ne zcela souvisejicich veci. Neni rozhodne pravdou, ze "na vrstvě blokových zařízení nelze splitbrain automatizovaně vyřešit". Split-brain je jednoznacne definovana situace ke ktere dochazi relativne casto (rekneme jednou za par let na kazdem clusteru) a kterou kazdy clusterovy software automaticky resi. Jde o ztratu meziinstancniho propoje pri zachovani funkcnosti cluster heartbeat. Reseni je posoudit stav vsech zucastnenych instanci a nasledne urcit, ktera pujde dolu a ktera prevezme cinnost. Jedinym problemem v tomto pripade je casovy usek po ktery se bude split-brain vyhodnocovat. Na jednu stranu je vhodne to udelat co nejrychleji, protoze dokud je cluster ve split-brain nelze provest zadne transakce a system je nedostupny, na druhou stranu neni ucelne pri kratkodobem vypadku provest failover, protoze to neni zrovna end user friendly operace. Cluster SW to tudiz resi nastavitelnym parametrem (obvykle radove minuty) po ktery se zastavi zpracovani a ceka se na obnoveni spoje nebo na rezignaci na nej a nevyhnutelny failover.
To o cem vy mluvite je rozpojeni clusteru pri zachovani funkcnosti obou. K necemu podobnemu v prvni rade nesmi dojit a cluster SW neco takoveho nedovoli.
Jinak bych jeste dodal, ze rozjety cluster rozhodne nevyresite na "vyssi vrstve abstrakce" at uz jde o soubory nebo o databazi. Jedine misto kde lze takovy stav vyresit je aplikacni vrstva a to jeste velmi komplikovane.

Atlas ma sice zalozni MX u jineho poskytovatele:

lemming@lemming:~$ host -t mx atlas.cz
atlas.cz mail is handled by 10 mx1.mail-atlas.net.
atlas.cz mail is handled by 20 mx2.mail-atlas.net.
atlas.cz mail is handled by 300 mx3.mail-atlas.net.
lemming@lemming:~$ host mx1.mail-atlas.net.
mx1.mail-atlas.net has address 212.47.13.100
lemming@lemming:~$ host mx2.mail-atlas.net.
mx2.mail-atlas.net has address 212.47.13.151
lemming@lemming:~$ host mx3.mail-atlas.net.
mx3.mail-atlas.net has address 194.212.229.244

Ale nameservery ma na jednom subnetu:

lemming@lemming:~$ host -t ns atlas.cz
atlas.cz name server ns1.atlas.cz.
atlas.cz name server ns2.atlas.cz.
lemming@lemming:~$ host ns1.atlas.cz.
ns1.atlas.cz has address 212.47.13.5
lemming@lemming:~$ host ns2.atlas.cz.
ns2.atlas.cz has address 212.47.13.226

Zajimave.

Prave, ze jsem. V nasich podminkach je voda jediny problem. Musite si uvedomit, ze pri rozmerech Prahy je mozne naimplementovat geograficky cluster na vzdalenost 15 km. S vyjimkou hurikanu, zemetreseni, tsunami a par dalsich u nas se nevyskytujicich atrakci zadne jine katastrofy nezasahuji tak sirokou oblast soucasne.
Tudiz praxe v CR (a obecne v Evrope) je takova nedelat geograficke clustery na vetsi vzdalenosti, protoze neprinasi vyssi zabezpeceni a dopady prodluzovani vzdalenosti jsou znacne a obtizne (pokud vubec) resitelne.

Všude jsou uváděny IDE disky v softwarovém RAID-1 takže o diskovém poli nic netuším (k čemu bude?)

První článek jsem zaregistroval na Živě a mluvila o výpadku konektivity net4net do NIXu, tak jsem se díval, jak je to u Seznamu s konektivitou a DNS.

DNS servery jsou dva:
ns.seznam.cz 82.100.0.150 (AS9148 = net4net)
ms.seznam.cz 194.228.3.117 (AS5610 = Telefonica O2)

A teď pozor - kouzlo:

;; ANSWER SECTION:
www.seznam.cz. 300 IN A 194.228.32.3

;; Query time: 6 msec
;; SERVER: 82.100.0.150#53(82.100.0.150)
;; WHEN: Tue Jul 11 17:40:37 2006
;; MSG SIZE rcvd: 47


;; ANSWER SECTION:
www.seznam.cz. 300 IN A 212.80.76.3

;; Query time: 6 msec
;; SERVER: 194.228.3.117#53(194.228.3.117)
;; WHEN: Tue Jul 11 17:40:10 2006
;; MSG SIZE rcvd: 47

Tedy name server 82.100.0.150 v síti net4net vrací adresu web serveru 194.228.32.3 v síti Telefoniky O2 a name server 194.228.3.117 v síti Telefoniky O2 vrací adresu web serveru 212.80.76.3 v síti net4net.

Tedy pokud vypadne konektivita net4net, dostanu adresu web serveru v síti net4net, pokud vypadne Telefonica O2, tak dostanu adresu webu v síti Telefonica O2, tedy výpadek kterékoliv konektivity způsobí nedostupnost www.seznam.cz.

Je tohle efekt, který adminové Seznamu zamýšleli? Nemělo to být právě naopak?

Nebo jsem jenom něco nepochopil?

S velkými UPSkami krizové zkušenosti nemám, takže nemohu mluvit úplně z první ruky. Všechny UPSky jsou podle mých zkušeností dimenzovány na provoz po určitou minimální dobu: řekněme 10-20 minut. Baterie jsou vybíjeny velmi vysokým proudem v poměru ke kapacitě. Offline UPSky mají poddimenzované chladiče. Chlazení by měly mít bez problému online UPSky, což je i případ sálových UPS s výkonem řádově v desítkách kW - ale s baterkami jsou na tom velké UPSky podobně jako malé. Jednak jde o stejnou technologii akumulátorů, druhak může "velká" skříňová UPSka dokonce obsahovat hromadu klasických malých 8Ah akumulátorů, prostě protože jsou levnější a s danou kapacitou se dají snáz poskládat na odpovídající napětí a výkon.

U malých UPSek mě nikdy nepřekvapí, když baterka lehne rychleji než by si UPSka myslela - a že už jsem to několikrát viděl.
Inteligence malých UPSek kulhá (IQ tykve), velká UPSka by měla mít lepší odhad a hlášení poklesu napětí.

Olověná baterka po několika letech provozu už neutáhne tolik, jako zamlada. Dodavatelé velkých UPS a stejnosměrných telekomunikačních zdrojů dnes často standardně nabízejí "bezúdržbové" zapouzdřené olověné akumulátory, a slibují jim životnost řádově 20 let (na základě katalogových listů výrobce akumulátorů), přestože daný model pochopitelně nikdo nikdy takto neotestoval - jedná se o životnost projektovanou/extrapolovanou. Drby z oboru říkají, že lepší spolehlivost je dlouhodobě dosahována s "dolévacími" bateriemi, za jejichž stav a údržbu je někdo konkrétní odpovědný. A to se bavíme o profi staničních bateriích s kapacitou v desítkách až stovkách Ah, ne o malých 8Ah cihličkách.

Konec konců, jestliže UPSka vyčerpala skoro celou kapacitu, a pak korektně naskočil generátor, nelze míti UPSce zazlé, že to takřka okamžitě vzdala, když generátor po pár minutách zase chcípnul.

Poznámka o stejnosměrných zdrojích, které přežily, mi připomněla vyprávění veteránů z oboru. Telekomunikační "stejnosměrný zdroj" o jmenovitém napětí -48V má pro konkrétní jmenovitý odběr (výkon) řádově větší kapacitu baterek (časovou výdrž), než srovnatelná UPSka. Můžeme to chápat jako věc tradice - stejnosměrný zdroj pro telefonní ústřednu je stavěn na delší provoz bez dobíjení, třeba až několik dní.
Pokud jsou z takového zdroje napájeny počítače, ať už přímo nebo přes trvale běžící "střídač" (invertor) na 230V, prakticky nehrozí překvapivý okamžitý výpadek - baterie jsou vybíjeny poměrně rozumným proudem a bývají pečlivěji opatrovány údržbou, než baterie v "počítačové" UPSce.
Pro uživatele hostingových služeb je stejnosměrný telekomunikační zdroj taková fajnová online UPSka se superdlouhou výdrží. Bohužel je to luxus i cenově.

Cvičení krizových stavů je taky trochu problém. Třeba ten generátor: jestli ho testovali při venkovní teplotě 25C, nebo v noci při 20C, a on jim musel nakonec běžet při 33C, tak mě problém zase tolik nepřekvapuje.

Kromě toho fatální krizový stav někdy nejde bezezbytku nasimulovat, z organizačních nebo technických důvodů. Třeba při testování RAIDu na chování v kritické situaci prakticky není možné nasimulovat širší spektrum možných závad (RAID řadič, elektronika disku, fyzická ztráta sektorů) - prakticky můžete jenom zkusit za chodu vyrvat disk a vyměnit ho za jiný. Přitom odpojení disku za chodu je prakticky poměrně nepravděpodobná závada...

Letadlum? :)

Zhruba tak. Jinak udajne pouzivaji tri kopie.

To me taky dostalo :-)

To je přesně ono, jde o koncepční problém.
Na vrstvě blokových zařízení nelze splitbrain automatizovaně vyřešit.
Sebevětší a sebedražší geograficky distribuovaný RAID má v tomto achilovu patu.

Ostatně průchodnost v poměru ke kapacitě bude u velkých monoistických RAIDů taky problém. A to nemluvím o nutnosti vícenásobného paralelního mountování takového velikého disku...

Tyto problémy lze často výhodně řešit "taktickým ústupem na vyšší vrstvu abstrakce" - clusteringem na vrstvě souborové, databázové, aplikační.

Pokud se bavíme o mailu, tak při scénáři "split brain" mail dorazí z divokého internetu buď na jeden nebo druhý ostrůvek, které se zrovna vzájemně nevidí. Tím je pro vnější svět přijat. Může se mu přiřadit nějaké generované jméno souboru (zaručeně unikátní napříč clusterem), nebo se uloží do databáze (opět se zaručeně globálně unikátním identifikátorem), nebo konkrétně v případě mailu se pro zaindexování použije message ID obsažené ve zprávě, které je samo o sobě unikátní.

V momentě, kdy se oba ostrůvky opět navzájem uvidí, není velký problém křížem zmirrorovat data na úrovni souborů či databázových záznamů, ať už podle syntetických unikátních klíčů nebo podle SMTP message ID...

Asi by nebyl problém dořešit také transakce typu mazání, přesunů apod. - pokud by při split-brainu zůstal v chodu webový interface pro uživatele...

Pokud máš na mysli hospodářské výsledky, stačí se kouknout do Seznamu evidovaných listin na www.justice.cz

Kde jsem tvrdil, ze zalozni DNS neni potreba ? Neni to dlouho co sem skoro padl na zadek pri pohledu na zalozni DNS na stejnem subnetu (jsou tam pro jistotu dva :) ) coz samozrejme znamenalo, ze dotycny hoster se pri vypadku temer vyparil z internetu.

A když jí budeš mít na kopci, tak ti zase do ní budou mlátit blesky :-))))))))

RedHat koupil GFS s firmou Sistina. RedHat/Sistina "Global File System" umožňuje clustering na úrovni storage sběrnice (dnes prakticky SCSI nebo FibreChannel). V zásadě umožňuje jeden SCSI disk namountovat paralelně na více počítačích. Aby všechny počítače v clusteru viděly tatáž data, uložená na společném disku.

GoogleFS je něco dost jiného. Vypadá to zřejmě zhruba tak, že v clusteru každý počítač drží jenom kus celkového souborového systému, nebo řekněme datové základny, pokud to navenek nemá podobu klasického stromového souborového jmenného systému. Existuje jakýsi virtuální společný souborový systém, a existuje mechanismus, jak se dostat ke konkrétním datům někde v tomto virtuálním společném systému. Kromě toho, že je systém distribuovaný, patrně obsahuje také solidní míru redundance... Jak přesně vypadá "společný jmenný systém" GoogleFS, to netuším.
Osobně bych GoogleFS zařadil do kategorie aplikačních clusterů, které s výhodou využívají specifického charakteru dat, atomicitu transakcí na co nejvyšší úrovni apod.

Prabvda pravdouci.

Navic fsync() nestaci, vetsinu kdyz uz, tak pouzivat fdatasync() a to vetsinou docela dost zpomaluje. Koneckoncu, fsync() by mel teoreticky nahradit zurnalovaci FS a ten tam maji nasazeny.

jedna se o dva ruzne distribuovane systemy - shodou okolnosti se stejnou zkratkou
http://en.wikipedia.org/wiki/Global_File_System
http://en.wikipedia.org/wiki/Google_File_System

Nebyl bych tak útočný. Když si představím několik desítek vláken útočících na I/O scheduler, nebude žádná legrace to dát do kupy. RAID a podobný v tomhle případě nepomůže. Ono se to mluví...fsync. Ale:
1) databáze si zpravidla sama určuje, kdy bude zapisovat na disk a kdy ne. Ani transakce nepomůžou. Pomůže jen dobrá záloha :)
2) použití fsync() výrazně zpomalí celý systém. Chci vidět, toho člověka, který to bude používat na tyto aplikace.

Nehledě na množství dat, které tam protéká. Zeptej se na wz,
tak dlouho obnovovali rozbitý raid...

Nikdy neodhadneš míru poškození souborů. Samozřejmě například INNODB má něco jako žurnál, takže (snad) pozná, co je špatně. Já osobně bych měl taky strach při tomhle množství věcí něco pokoušet. Možná by bylo lepší (pokud by se na to přišlo včas) všechny servery včas vypnout. Ušetřila by se práce s obnovou. Ale po bitvě je každý kapitán...

takhle jednoduchý to v plném pracovním vytížení zase není
pokud bych chtěl použít fsync tak musím zastavit procesy které manipulují s daty, jinak to nemá moc velký smysl.
to asi může rozkázat jenom božský Ivo (jenže tomu v tichomoří zrovna nešel satelitní telefon)
Pokud budete chtít deaktivovat některé služby určitě potřebujete povolení...

A že by aplikace při každé změně volala fsync no tomu snad nikdo nevěříme že ne? asi by moc rychlá nebyla

Mají to strašně složitý :(
Google je v podstatě takovej skynet :)
Je to nová filosofie úplně odlišná od všech ostatních
V jejich případě nezáleží na hardware, ale na síle myšlenky,
kterou museli velmi dobře zaplatit.

Úplně unikátní je sítový souborový systém, který se replikuje mezi všechny servery v síti (proto ty 10Gbit spojení)
Výsledky vyhledávání se skládají z fragmentů dat uložených v datacentru tedy cca 10000 serverů.
Když je v tom integrován gmail tak to musí být asi hodně složitý a žádné informace se neztrácejí

Mit alespon jedno datacentrum dostatecne vysoko nad rekou je samozrejme zakladni pozadavek.

Tak to asi zřejmě imbecil budu :)) Používám jak IMAP tak "nedejbůh webové rozhraní". Dále no comment.

Stejne reseni se pouziva i na GMail.

Nojo, ale tech mailu musis stihat ukladat stovky za sekundu.

Dalsi otazka je, jak je pravdepodobne, ze zadny MX server nebude dostupny, respektive co takova situace bude mit za dalsi nasledky.

Mne z toho vychazi, ze v takove situaci nebude dostupne Centrum vubec, coz je velky prusvih. Takze ma spis smysl se snazit aby ty servery byly maximalne dostupne tak jak jsou.

... a když to programátoři ze seznamu neumějí používat, tak jim to spadlo. Nesvaloval bych to na výpadek elektřiny, ups, filesystém, linux. Je to prostě tím, že ta mailová aplikace je špatně napsaná.

S ohledem na to, ze Seznam nesdeluje auditovane vysledky je duveryhodnost teto informace vcelku diskutabilni. Nicmene i tak maloktera firma je ochotna do DR reseni investovat svuj vice nez rocni zisk.
Nechapu poznamku o konkurenci, nikde jsem netvrdil, ze ti jsou na tom lepe.

Myslim ze si se senamem nemuzte v tomto ohledu nic vycitat:

; <<>> DiG 9.3.2 <<>> MX centrum.cz
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64136
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 2, ADDITIONAL: 8

;; QUESTION SECTION:
;centrum.cz. IN MX

;; ANSWER SECTION:
centrum.cz. 1347 IN MX 10 mail8.centrum.cz.
centrum.cz. 1347 IN MX 10 mail1.centrum.cz.
centrum.cz. 1347 IN MX 10 mail2.centrum.cz.
centrum.cz. 1347 IN MX 10 mail5.centrum.cz.
centrum.cz. 1347 IN MX 10 mail6.centrum.cz.
centrum.cz. 1347 IN MX 10 mail7.centrum.cz.

;; AUTHORITY SECTION:
centrum.cz. 2867 IN NS host2.netcentrum.cz.
centrum.cz. 2867 IN NS host1.netcentrum.cz.

;; ADDITIONAL SECTION:
mail1.centrum.cz. 607 IN A 213.29.7.233
mail2.centrum.cz. 2898 IN A 213.29.7.232
mail5.centrum.cz. 1398 IN A 213.29.7.229
mail6.centrum.cz. 943 IN A 213.29.7.198
mail7.centrum.cz. 2285 IN A 213.29.7.193
mail8.centrum.cz. 2898 IN A 213.29.7.184
host1.netcentrum.cz. 3455 IN A 213.29.7.239
host2.netcentrum.cz. 821 IN A 81.0.254.36


; <<>> DiG 9.3.2 <<>> MX seznam.cz
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2137
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 6

;; QUESTION SECTION:
;seznam.cz. IN MX

;; ANSWER SECTION:
seznam.cz. 268 IN MX 10 mx1.seznam.cz.
seznam.cz. 268 IN MX 20 mx2.seznam.cz.

;; AUTHORITY SECTION:
seznam.cz. 268 IN NS ms.seznam.cz.
seznam.cz. 268 IN NS ns.seznam.cz.

;; ADDITIONAL SECTION:
mx1.seznam.cz. 184 IN A 194.228.32.45
mx1.seznam.cz. 184 IN A 194.228.32.26
mx1.seznam.cz. 184 IN A 194.228.32.44
mx2.seznam.cz. 100 IN A 194.228.32.42
ms.seznam.cz. 200 IN A 194.228.3.117
ns.seznam.cz. 47 IN A 82.100.0.150
***********

Centrum ma vsechno napraskane do jednoho subnetu stejne jako Seznam => kdyz zdechne ten subnet, tak se jak jeden tak druhy vypari z inetu.

Od profiku bych ocekaval ze aspon 1/2 MX bude smerovat na jiny a samozrejme jinde fyzicky umisteny subnet. To ze vam zustane v provozu zalozni DNS je vam prd platny.

Normalni OS ma aspon dost slusnosti napsat neco do logu. Widle s radosti zdechnou bez toho, v lepsim pripade s nejakym tim dumpem pameti. Ale ze by se clovek docet aspon ktera ze aplikace to zrovna mela potrebu volat fci xyz v knihovne klm ...

Mno a za 1/2 roku se clovek docte ze M$ opravil kritickou chybu v klm.dll ktera zpusobovala pady systemu, pricemz jejich (podotykam placeny)support vesele tvrdi, ze chyba je nekde u me. (vlastni zkusenost)

U jinyho OS (a mel sem jich pod rukama uz par) se mi jeste nestalo, ze by se stroj restartnul takovym fofrem pod rukama, aniz by si na cokoli postezoval. Uplne jako kdybych ho resetoval HW. Netvrdim ze tohle widle delaj casto, ale uz se mi to stalo nekolikrat.

A to nemluvim o naprave pripadnych problemu, u tuxe v nejhorsim nastartuju z CD a konfiguraci proste opravim, ale u widli abych zase hledal nejakou silenou utilitu na editaci registru, kterej, kupodivu, je cirou nahodou, zrovna tim poskozenym souborem, ktery se pri padu nestacil/spatne ulozil.

Ja teda nevim, jake pouziva Seznam servery a o jakou diskovou kapacitu se celkove jedna, ale mozna ze by v konecnem dusledku byl ten Symmetrix od EMC i levnejsi variantou.

A co tak L2/L3 vrsta? napr STP abo VRRP protokoly ? Alebo technologia ATM ? tam mas cas regeneracie okruhu do 50 ms

asi jsem uplny imbecil - pouzivam IMAP (kdyz sedim u nektereho sveho pocitace) a webmailove rozhranni, kdyz sedimu u ciziho pocitace - zrovna vcera jsem o tom delal v praci "prednasku", jak pohodlne je to reseni o proti pop3. ale mozna je vsechno uplne jinak...

> Zajimalo by mne co se stane, kdyz spojeni mezi dvema
> lokalitami vypadne - treba na deset sekund, na minutu?

Pokud vypadne jeden propoj, tak se nic nestane, protoze i opticke propoje SAN jsou pochopitelne zdvojeny.
Pokud vypadnou oba, tak jsou dve moznosti. Bud je konfigurace active/passive (90+% pripadu, simultanni zapis na diskova pole ve dvou lokacich neni uplne dobre vyresen), tak se proste prohlasi zalozni pole za desynchronized (split) a pocka se na obnoveni spojeni aby se znovu sesynchronizovaly.
Pokud je cirou nahodou konfigurace active-active, tak uplne preruseni spojeni dostane cluster do nejhorsiho z moznych stavu - splitbrain. Pri splitbrainu bezi obe dve instance, ale nejsou synchronizovany mezi sebou. V takovem pripade se pouzije zalozni heartbeat, aby se urcilo, ktera z instanci zije a na tu se aplikace preclusteruje. Pokud ziji obe dojde k shutdownu te s nizsi prioritou.
Alespon jeden heartbeat by nemel byt prerusen, protoze se obvykle implementuje dvema nezavislymi technologiemi (napriklad pres sdilene disky a zaroven pres ethernet). Pokud by nahodou doslo k preruseni uplne vsech spojeni naridi cluster software nezavisle na sobe na obou dvou lokacich shutdown abort. Uplna outage je totiz mensi zlo nez nechat obe diskova pole aby se navzajem rozesla s tim, ze cast platnych transakci bude na jednom poli a cast na druhem. Takovy stav totiz neni na urovni infrastruktury nijak resitelny.

Pisu to tu uz potreti: Potkal (a myslim potkava casteji nez Seznam). Jenom se s nim Centrum vyporadalo lepe.

NS jsou geograficky oddelene (i kdyz jen v ramci Prahy). Ale stejne je nanic ze NS funguje, kdyz se nedostanes na IP, kterou prelozili ;-)

Stejne tak MX sice muzeme jit jinde, ale do 4 dni pocka mail u odesilatele a ulozit 4 dny prichozich mailu rozhodne neni reseni za 50 tisic :-)

Treba tu analyzu delal a vyslo mu, ze takhle je to levnejsi ;-)

V tomhle musím souhlasit, všude sice používám linux, ale je pravda že pokud se windows normálně nainstalují tak běží.
(sice pomaleji a jsou háklivé na hackery :)) ale není to záhadné
Záhadný bývá software uvnitř...

Zadny pad pod Windows neni zahadny. Zahadny je jenom pro toho, kdo tomu systemu nerozumi - coz je zrejme vas pripad.

A cendra?

Co je to "rozumny HW" ? Kernel panic sem videl naposledny kdyz sem si hral se starym strepem a krad mu HW za chodu. Zato chybovy hlasky u serveru provozovanych na widlich vidim dnes a denne. Mam v praci obe, jak tuxe tak widle. Na tucnaka se kouknu cas od casu a jediny co o nem muzu ric je "proste funguje". Nemusim resit zadny zahadny pady uprostred noci, kdy se nic nedeje, zadny 100% zatizeni CPU nicim, "samovolny" narust velikosti systemu na disku a podobne.

Jeste sem nevidel widle, ktery bych moh vzit tak jak sou na disku, zapojit je do uplne jinyho stroje aby bez sebemensiho zavahani nastartovaly. U tuxe naprosta samozrejmost. Widle se obvykle po prechodu na jinej chipset slozej nebo je treba celodeniho laborovani s rizikem, ze stejne neco nebude fungovat jak ma. Takze ve finale je efektivnejsi to nainstalovat znova.

Vim ze existujou vsemozny nastroje na spravovani widli, ale tux se da vpohode spravovat tak nejak od prirody a nemusim za spoustu $ dokupovat nastroje, ktery potrebuju abych moch pod widlema udelat totez stejne efektivne.

Já vím doufám že mě nikdo nebude bít :) nicméně to spolu
trochu souvisí a seznam asi neměl moc na výběr jak situaci řešit. Druhé centrum je príma, ale to jsou dvojnásobné investice (otázkou je jestli se to vyplatí při jednom výpadku za rok) Mirroring dat by ale měl být řešen v SW jako to má goooogle

Vsak nikdo nerikal, ze by tam meli byt proto, aby neco opravovali :) Ale proto, aby komunikovali s postizenymi uzivateli a medii...

Nojo, holt jsou to lamy, na Seznam nemaji, ten pouziva profesionalni reseni :-)))

No na všechno :)
2x IDE disky se používají v té jejich server farmě na vyhledávání prostě www.google.com search jede na IDE diskách
cca 12 datacenter spojených 10Gbit linkama rozsypaných po světě
No je tam dost šílenej systém replikace dat, kterej sem nepochopil. Pokud někdo ví sem jedno ucho, ale ta matematika je pro mě asi nezvladatelná :)

Příjde vám google amatérské? Všechno není jenom o HW

MySQL(InnoBase) používají asi na nějaké ty doprovodné služby (podrobněji to nevím jenom vím že je uváděné jako používaný software)
Vyhledávat v MySQL samozřejmě nejde... ale to ani v ORACLE, ten je totiž ještě pomalejší.

Finta je v tom dat si vhodne omezujici podminky :-) Coz je pri clusteringu na aplikacni urovni docela dobre mozne.

Jinak doporucuji podivat se na Google FS, to je o level vys nez co ma Centrum.

No, lepsi nez rikat "ty pocitace jak se tam ukladaji data" :-)

Kdyz - predpokladam - mate znalost tech reseni, povezte mi co udela takovy distribuovany RAID, kdyz mu na minutu vypadne spojeni mezi lokalitami? To mi jeste nikdo nedokazal zodpovedet.

I Centrum muze se svym systemem pokryt Vami uvedena rizika a troufam si tvrdit, ze se zlomkem jednotkovych nakladu co by s tim mel Seznam.

Navic ten problem "jednoho FS" neni o HW, ale o systemu nad nim.

Cim je lepsi investice do HW nez do lidi? I HW zastarava, takze investice do nej neni jednorazova. Maximalne je to o tom, ze investice do HW je mene rizikova, protoze clovek muze odejit, ale HW vam nevezmou. Ale to je opet zvladnutelne riziko.

Vase prirovnani je nesmysl, Centrum i Seznam se provozuji ve zhruba stejnem prostredi. A opakuji, i Centrum ma problemy zpusobene externimi selhanimi, ale evidentne se s nimi umi vyporadat lepe.

GOOGLE je sebevrah? To si nemyslim a ani nepouzivaji diskova pole pouze 2x IDE disk a rekl bych ze jim to celkem funguje :)

Každej ví jak by se to mělo udělat, ale nikdo neuvažuje
nad tím kolik to bude stát.
Nejraději mám typy ze státní správy, nebo třeba z ČEZu, kteří si vůbec neumí představit že by si na sebe museli vydělat. Miliony nerostou na stromech!

Je trochu škoda že teď každej bude koukat na TTC jako
na toho komu nic nefunguje, ale výpadek byl jenom 12 minut
a to ještě ne ve všech technologiích!

A těm se spoustama milionů ty jejich javaletí řešení padají
jako hrušky a nikoho to nepřekvapuje joo von je zase spadlej ORACLE... apod.
Nefungují www banky, pošty, apod nikoho to nedrásá, ale oni na to opravdu mají peníze a stejně jim to nechodí.
A to tam dělají samí děsně chytří lidé, kteří jako první tady budou psát o tom jak to má seznam špatně.

Tak ať to udělají lépe... koupit další zařízení to umí každej blbec.

Je to odhad, ale IMHO radove mimo neni.

Vsechno vyjmenovane.

Koukam konecne nekdo, kdo o tom neco vi :-)

Zajimalo by mne co se stane, kdyz spojeni mezi dvema lokalitami vypadne - treba na deset sekund, na minutu?

Normalni - ve smyslu typicky - uzivatel ma emaily na free serveru a nezalohuje si je.

Tak si to prectete jeste jednou. Nic nebrani mit jednu storage na jednom miste, druhou na druhem, treti na tretim. Storage = pocitac a ulozisteje tvoreno clusterem techto storagi.

Pokud se rozbije filesystem na jedne, nic se nedeje, jede se z jine.

No, cekal bych, ze u toho Seznamu bude stacit tak 500MB/s a celkova velikost pole 200TB.

Ale mne prave zajima, jak se chova RAID na ne moc spolehlive siti - podle mne v tom bude hlavni zadrhel.

Jinak ty FS jsou hezke, ale ne moc pro narocne pouziti. Neznam aktualni "state of the art", ale pred par roky nic moc. Jediny filesystem ktery vyhovuje je Google FS a ten neni verejne dostupny :-)

To je vec, rekneme architektonicko/filozoficka. Reseni co ma Seznam ma proste uzke misto v tom filesystemu (resp. redundanci az na urovni HW). A to ja vidim jako zasadni architektonicky problem bez ohledu na to, kolik jake reseni stoji. Pak se naskytne nejaka nepredvidana okolnost (jako tehle vypadek proudu, nebo muze vlivem nejake HW poruchy zblbnout HW radic, poskodit obsah disku) a opet - mate problem.

Reseni Centra je naopak co nejvic decentralizovane. Stoji na tom, ze pokud se stane nejaky velky prusvih, tak se stane izolovane a alespon jedna kopie bude funkcni.

Samozrejme ma velkou narocnost na kvalitu toho SW co zajistuje redundanci, ale pri vhodne zvolene SW architekture a postupech to neni zas tak velky problem - podarilo se nam to zvladnout.

> I middle range, ale bez pochyb i enterprise range storage
> zajistí v rozumné konfiguraci řádově nižší riziko
> poškození dat než vlastní vyvíjená aplikace, která dělá
> mirroring na aplikační úrovni.

Hm, tak proc tedy Seznam ma takove problemy a Centrum ne?
Pritom na Naganu nedavno vypadla klimatizace, takze to neni tim, ze by Centrum melo "privetivejsi" prostredi.

No, on to neni RAID. Je to vlastni SW reseni. Viz:
http://kryl.info/clanek/280-pod-poklickou-gigamailu-centra-i http://kryl.info/clanek/281-pod-poklickou-gigamailu-centra-ii

Ano. Hruby zisk CEZu byl za prvni ctvrtleti tohoto roku 15 miliard :-)

Myslis tyhle zpravu: http://www.cesnet.cz/doc/techzpravy/2004/soip4/ ?

Ale to je neco trochu jineho, to neni RAID kde je jedna kopie nekde a druha jinde, ale disk pripojeny pres sit.

A pokud to chapu dobre, tak jen pripojenim pres lokalni crossover metalicky kabele s latenci ~0.1ms znamena snizeni prenosove kapacity na polovinu.

> Ono je navic otazka, co je geograficka redundance. Mit v
> Praze dve serverovny, tomu nerikam geograficka
> redundance. A mezi Prahou a Brnem uz, bohuzel, latence
> nabehne.

Pro bezne potreby jsou dve opravdu redundatni servrovny v Praze zcela dostatecna geograficka redundance. Vzdalenost mezi Prahou a Brnem je v nasich podminkach pro ucely disaster recovery zcela zbytecna a neefektivni z mnoha duvodu.

> To je jasné, že na storage, na které má Centrum to nejde.
> Profesionální HW, které používá Seznam, ale umožňuje i
> geografický mirroring dat na HW úrovni. Je to otázka jen
> licence a dostatečně silné linky.

Vazne? Napriklad u EMC funguje rozumne HW mirroring (SRDF) pouze u nejvyssi rady diskovych poli (Symmetrix) a to jsou spolecne s licencemi za SW, switche, optiku mezitim atd. takove naklady, ze neverim ze by firma jako je Seznam byla schopna je zaplatit.

Problem je v tom, ze internetove firmy jsou dle standardniho razeni spise firmickami a to vcetne tech nejvetsich. Takovy Seznam je sice na ceskem webu gigant, ale pri zarazeni mezi bezne firmy je to firma maximalne stredni velikosti (jak poctem zamestnancu, tak obrakem i ziskem). Pokrocilejsi disaster recovery technologie jako zminovane "redundantni zrcadlo v zaloznim datacentru" jsou samozrejme technicky snadno proveditelne, ale financne extremne nakladne. A to co si snadno dovoli nejaka banka nebo treba CEZ znamena pro "giganta" jakym je Seznam pet let bez zisku. :-)
Je to neprijemny paradox, ze nejvice zavisle na sve IT infrastrukture jsou firmy, ktere si nemohou dovolit do ni prilis mnoho investovat.

Pán si asi zkusil nainstalovat nějakou linuxovou distribuci, chvilku na to čučel, v ničem se nevyznal, tak to zase smázl. A teď o tom zasvěceně všude mluví jak je linux poruchový a na prd. Mimochodem linux je jen jádro operačního systému, ty aplikace co vidíte na monitoru jsou úplně z jiného soudku (GNU/GPL). Linuxové distribuce používám už několik let a jsem naprosto spokojený.

Jeste jedna vec - soucasny prusvih je zpusobeny prave tim, "profesionalnim HW", respektive architekturou s miroringem dat na HW urovni. Pokud se vam rozsype FS a nejake soubory na nem, tak mate prusvih.

Pokud to mate mirorovane na aplikacni urovni, tak se muze FS rozsypat a soubory ztratit. Ale pokud se vam nerozsype tech FS vic a nejak fatalne (hodne poztracenych souboru), tak mate vzdycky alespon jednu kopii dobrou.

Koukam expert na architekturu Centra. Ale ja jsem vetsi :-) Samozrejme to jde.

No, jelikoz ty raidy bezi po optice, tak by asi nebyl problem si pronajmout pevnou optickou trasu mezi temi serverovnami a tahat to po ni. Akorat nevim, jak moc rychlou optiku to pole potrebuje. A hlavne co by se delo v pripade (i kratkodobeho) vypadku te trasy.

Ono je fajn zes to delal a RAID po siti samozrejme jde, ale tady se bavime o radove jinych datovych tocich. AFS je pro tohle nevhodne a Samba nezajisti redundanci.

No je to trošku zvláštní, že jim to takhle umřelo. Upřímně řečeno si myslím že to asi moc nezvládli. Seznam používá FreeBSD a Debian pak hodně MySQL databázi. Otázkou je jakou verzi. Starší verze byli dost háklivé na výpadky (to ani souborový systém s žurnálem nezachrání - jaká databáze není háklivá na výpadek energie :) neznám). Chyba byla asi v tom že nedošlo k řízenému shutdownu na serverech.
Jenom se musím pochlubit že mám také server v TTC a ten vydržel, jeho uptime je stále nezměněn. Takže někdo umí a někdo ne.

Ale nezávidím to těm deseti technikům to asi muselo bejt hodně ošklivý. Tlak ze všech stran ať to funguje.
Každé kolečko se nakonec poláme i kdyby bylo sebelepší.
A že by to seznam nepřežil :) toho bych se nebál i kdyby
to nefungovalo dva, tři dni tak se stejně nic nezmění.

Normální člověk hlavně šetří s "imbecily" na závažnější chvíle:P

Asi nejsem normální člověk, ale úplnej imbecil. IMAP totiž používám a k POP3 bych se nevrátil. Když vy nedokážete / nepotřebujete využít výhody IMAPu, ještě to neznamená, že kdokoliv jiný je imbecil. Říká vám něco lokální cachování?

Vůbec nechápu, proč to způsobilo nějaký problém. Normální člověk si snad maily pravidelně stahuje (POP3) k sobě na svoje PC/server. Používat IMAP nebo nedejbůh snad webové rozhraní může snad jen úplnej imbecil. Za pár posledních let měli nějaký výpadek všichni freemailoví operátoři, na nemožnost ztráty dat u nich snad nikdo nevěří. Jak říkám, normální člověk má svoje maily u sebe a pravidelně si je zálohuje (na další PC, případně vypalování - to je snad přístupné naprosto pro každého)

Nevím jak ostatní, ale já nevím nic o tom že by Seznam měl servery jěště nikde jinde, takže se výpadek týkal jak neplatících tak i platících zákazníků. No to že jim trošku popadaly na partišny na low-end strojích kde běží freemail je něco jiného.

Ale v dnešní době snad není velký problém (pro firmu velikosti Seznamu) si udělat v záložním datacentru redundantní zrcadlo placených služeb, pro případ těhle výpadků. Pro ISP s autonomním systémem by to měla být hračka...

Ona ta UPS nic nehlasi, je tam generator, takze ma teoreticky vydrzet libovolne dlouho - dokud jezdi cisterny s naftou :-)

Geograficka redundance je pekna vec, ale obavam se, ze ten jejich RAID jim pres WAN asi nepobezi :-) Nehlede na to, ze WAN ma castejsi vypadky, vetsi zpozdeni atp., takze je to dost narocne udelat.

Doporucuju vymenit tvyho dodavatele diskovejch poli. I tchajwansky mrchy maj dneska baterky, co bez problemu zvladnou flush cache na disky.

To že UPSka nevydrží tolik kolik nahlásí se prostě stane. Nestává se to denně, ale takové případy jsou. Spíš bych se zamyslel nad tím, jak má profesionální firma, jakou se Seznam snaží být, vyřešenou redundanci technologií. Pokud mám 450 serverů, všechny v jednom datacentru, na jedné lince do Netu s jedním přívodem elektriky, ...

2 xpman: To jste opravdu myslel vážně? Není Vám moc horko?

S LInuxem to nema nic spolecnyho. Si myslite ze tam maj vobicejnou pecku s 2 hadrama? Co takle diskovy pole s 2GB cache? A gdyz UPS odrizne bez varovani eletriku neni cache a celej fs de tam gde je tma a smrad.

Tak to je dobre, jeste ze mate Windows XP, jen tak jsou Vase data v dokonalem bezpeci. Opet se ukazuje, jak nebezpecnym hazardem je pouzivat Linux, obzvalste na serverech! Budiz to ponaucenim pro nas pro vsechny!

no hlavně že ušetřili na software :-)

Maji tam nejakou distribuci GNU/Linux, takze za svuj hazard zaplatili.

Může mi někdo vysvětlit jak se mohly poškodit databáze a filesystémy? I v této naprosto nepředvídatelné situaci kdy nejde elektrika mi jede server na UPS a když dojde baterka tak se server vypne ne? A i kdybych server za provozu vytáhnul ze zásovku tak se mu poškodí filesystém? Tuším že Windows XP tam asi nemají, ale mě se tohle na NTFS nikdy nestalo! Co tam tedy mají? Win95 s FAT16???