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

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

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

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

Pokud je řeč o žurnálovacích filesystémech, které se lépe zotavují z poruch, tak těch je i v linuxu dostatek (ext3, reiserfs, xfs, jfs ... narozdíl od Windows, které mimo NTFS nic neznají).

Ale zásadní rozdíl asi bude v tom, že na kolegových Windows XP se neprovádí takové množství simultánních diskových operací, jako na serverech seznamu. U běžných desktopových aplikací se 90% času disk ani nehne. Mně se v mém linuxu za posledních 5 let také žadný soubor neztratil, a to kvůli odcházejícím zdrojům nemám o pořádné výpadky nouzi. Ale to se prostě nedá srovnávat.

Mno NTFS je také žurnálovací.

A třeba takový XFS je velmí dobrý FS, ale UPS potřebuje jaksi z principu návrhu (má to v RAM a na disk sáhne až když je potřeba).

Ale tady jde o něco jiného. Srovnávat domácí desktop s jedním diskem, který se 95% provozu PC nudí s fileserverem s velkým diskovým polem, které je neustále v provozu a má velký cache, prostě nelze.

Heh .. a to jste vzal kde? :) NTFS nezurnaluje data samotna.. ale pouze metadata.... cili je to tak na pul

Jedinej systém, pokud je mi známo, který žurnáluje i data je ext3 (při nastavení journal_data, defaultně taky dělá jen metadata).

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

hazard? hazard je mít na serveru windows :P

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

Podle prosáknuvších informací tam mají linux a někde freebsd.

Ale to je celkem jedno. Každý FS se může poškodit. I ten váš NTFS. A pokud ta UPS zareagovala stylem, "mám ještě deset minut" a pak se kvůli přetížení prostě vypla, tak to není chyba OS, nebo FS, ale prostě té UPS.

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!

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.

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

Paklize jim to ty disky jeste dovoli, vidte?:-)

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

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

na rozumnem hw je pri standardni distro a dobre administrovanych windows (to MALOKDO umi, stejne jako rozumne administrovat *nix) je porad vetsi podil kernel panicku nez BSOD - to je proste fakt

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.

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

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

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.

podobnou situaci vam nasimuluji skutecne na naprosto kazdem OS

podobnou situaci vam nasimuluji u uplne kazde podpory - pravdu u vetsiny ne-widle (viz idiotska terminologie) systemu ani zadna neni

ja rozumim proc neumite na takovou otazku odpovedet - zkuste si vy-mns-novat :-) napr. WHQL

skutecne neni treba k windows dokupovat zadne nastroje-nektere vam praci ulehci ale to je duvod existence SW a HW nakonec obecne ze?

tedy-mylite se

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.

Jo, server má běžet. Ale třeba běžná situace: "nainstaluju desktop na svém silném PC, odladím, nakonfiguruju, vezmu HDD a šoupnu do PC sekretářce vše připravené a odladěné, takže neprudím dlouho u jejího PC" s Woknama prostě provést nejde, kdežto s Linuxem ano a levou zadní. Nezajímá jestli sekretářka bude užívat Linux, nebo jestli si myslíte, že ne (mám několik takových PC, která pracují docela úspěšně ke spokojenosti sekretářek).

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.

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

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

Mno pokud jde o neplacenou službu, tak je to více méně jedno. Předpokládám že data a služby platících zákazníků mají ochráněná lépe.

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

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.

Seznam psal, že měl zisk 300 milionů Kč. To je víc než obrat jeho nejbližší konkurence :-).

Nějaký další argument?

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

A Centra?

A cendra?

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.

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

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.

Pokud vim, tak se diskutuje Seznam, nikoliv TTC :-)

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

Vzdy jsou reseni. Je to jen otazka nakladu.

Na posouzeni, zda je lepsi v tomhle pripade mit velke homogenni systemy (ala Seznam) nebo rozprostene (ala Centrum), mame proklate malo informaci.

Naivko:-)

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.

Michale, RAID bezici pres MAN jsem konfiguroval uz pred deseti lety. Dneska, kdy je GE za hubicku (coz jiste potvrdi se kripajicimi zuby vsichni poskytovatele metro kapacit), je to komoditni zalezitost.

Ano, bal bych se jet treba iSCSI/FCIP Praha - Ostrava (otestovano, nepouzitelne kvuli latenci), nicmene treba pouziti AFS bych fakt nevidel jako problem ...

Podotykam, ze pres hloupou sambu mam propojene filesystemy v Praze a Ostrave (MPLS) a fakt to neni problem.

Ono uz je sitovani trosku dal, nez si poskytovatele obsahu mysli. Jenze poradni sitari jsou pro ne moc drazi :-)

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.

Michale, co je radove jiny datovy tok? Ja to zkousel na datovych tocich tesne pod gigabit :-) Bohuzel dostupnost desitky v Ostrave zhatila pripadne testy na vyssi kapacite.

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.

Testy jsem delal (respektive jsem pomahal kolegovi Dolezalovi) na HW RAIDu - nekde na webu CESNETu je technicka zprava.

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

A pak se objevi trocha vody a vyplachne par mestaku a je z toho tisicileta voda...:-)

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

Vy jste ale rizikovy analytik... copak povoden je jedine riziko? A to muzeme stale zustat pouze u tech zivelnych a nikoli teroristickych/zaskodnickych...:-)

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.

Jste si tim jist? V Cernobylu si to take mysleli....:-) (a to my ty elektrarny mame od Praglu nepomerne blize) A co treba protrzena vltavska kaskada? Je hezke, ze vas stroj bude v suchu na pahorku, bohuzel to je tak vse, protoze dopravovat energii nebude jak (ropu Vam nikdo neda), elektrina bude vypnuta, majitel budovy dostane prikazem, ze z duvodu bezpecnosti bude odpojen veskery privod plynu, vody, elektriny... - nejak rychle jste zapomnel na zpusob a krizove rizeni pri povodni v roce 2002 - a infrastruktura okolo bude down... takze i kdybyste ten server pohanel na slapacim kole bude Vam to vite k cemu... 15, 20, 50 km to je fuk, tohle neni geograficka zaloha...

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

Teorie hezka... ta statni cisterna se na misto dopravi jak? Po vode neschudne (trosky a neprostupny bordel okolo, jehoz odklizeni aspon pro plavebni drahu prevysi zasobu nafty v agregatoru), vrtulniky vytizene (tolik jich neni), mame dalsi moznost? Navic to, co jste jmenoval nejsou komercni (o nichz se zde bavime) bussiness, ale statni zajem... patrne to bylo i pri prazske povodni - jediny kdo dostal naftu byly mobilni operatori a to ti ostatni az pote, co se prislo na to, ze Eurotel neni schopen zajistit to, co ma smluvne se statem dohodnuto (o tom, ze by z toho nekdo vyvodil zavery, odpovednost, sankce atd. mi neni nic znamo - jak typicke v nasem Kocourkove)... jenze to uz mezi tim proteklo hodne vody (casu) a zbytecne...

Navic s dvojcaty srovnavate nesrovnatelne - lidske zdroje, ktere minite tim chaosem nebyly zasazene/znicene, jsou plne operativni - jsou geograficky po celem svete, takze do zniceni Zeme se nic nedeje... jde jen o to datacentrum a tedy techniku

.

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

Krome nebezpeci pozaru a elmag. zareni (oboji resitelne), cemu jinemu to vadi?:-)

Letadlum? :)

Vy jste slysel o zivelne pohrome na strategicke zasoby zeme nebo vojensky vyznamnem miste?

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.

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.

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.

Michale, abych mohl posoudit nasazeni te veci do RAIDu, musim vedet, jaka je realna prenosova kapacita. Nemam k dispozici v DWDM krabicich FC sloty, takze iSCSI/FCIP je jedna z mala moznosti to delat na HW urovni. A pokud mi L1 uroven dava nesmyslne vysledky, nebudu se poustet do testovani L2/L3.

Vysledky toho testu bych neinterpretoval tak, jako Ty. Problem neni pouze latence, ale take jeji rozptyl (jitter). Na tom metalickem kabelu zadny rozptyl mit nebudes, ale v te MPLS siti urcite nejaky bude.

Pokud se tyce ciste kopie dat, na to mi dneska staci NTFS/DFS ci jinych chytry system, pripadne replikace databazi :-)

s/chytry system/chytry souborovy system/

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

500MB/s = 4 Gb/s ... To mi prijde prilis.

Co je to "ne moc spolehliva sit"? Vypadky infrastruktury? Ztraty paketu? Velky rozptyl? :-)

Je to odhad, ale IMHO radove mimo neni.

Vsechno vyjmenovane.

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

Ja mel za to, ze GFS vcetne implementace a specifikace koupil RedHat... ale mozna jsem mel mlhu...:-)

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_Sy stem

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.

Zhruba tak. Jinak udajne pouzivaji tri kopie.

Nevim ja jsem pro aplikacni mirror reseni. U takto rozsahlych projektu se musi zalohovat na aplikacni urovni nikoliv na fyzicke. Napriklad zalohovat maily tak ze se bude raidovat mez prahou a ostravou je naproste blaznovstvi. To uz je lepsi mit pustener rsync i kdyz i ten je k prdu.

Proste se nabori pop3/webmailovej/imap frontend a ten vytvari zurnal akci a ty se pekne "jak linka dovoli" provadi i na tom vzdalenem systemu. To muze byt nejaka low-end supermicro case s 12xSATA disky (tj nekolik terra dat).

Hlavne tu nikdo moc nediskutuje ze Seznamu takze vime prd co se stalo 500 serveru je 500 serveru.

No hlavne vime, ze jedou uplne na doraz, kdyz nejsou schopny zalohovat adress booky s poukazem na vytizeni...:-) - kolik by ty AD asi prispely?

To me taky dostalo :-)

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.

Takže to co používá Seznam , a čemu vy říkáte "RAID" jim přes WAN poběží.

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

Můžete uvést výrobce toho RAIDu nebo raději ne? :-)

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

A co jsem psal? Storage to neumí a celé je to na koleně udělané v Centru.

Když uvážím, že OS i file system bude stejný jako na Seznamu, pak teoretická dostupnost řešení je na Centru řádově horší.

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 však to píšu. Na koleně řešený clustering, který jinak vyvíjí desítky programátorů po několik let.

Pokud PC s SCSI disky říkáte storage, tak OK :-D

Jak jste prisel na ty SCSI disky? :-)

Podle toho jak je to celé "navržené" a podle toho, že namísto odpovědi co je to za storage jsem se dočkal odpovědi, že storage je celé PC :-)))


Tak co v tom Centru tedy používáte za diskové storage?

ja nevim, co tam ONI pouzivaji :-)

Podle toho jak se nikdo nehrne do odpovědi tak nepoužívají žádný storage. Nebo je to Centrumáci jinak?

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

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.

To je teorie bez znalosti konkrétních řešení a bez praxe s ním. Pro Centrum je vývoj vlastního mirroringu na aplikační úrovni lepší, jelikož je výrazně levnější než profesionální řešení :-)

Cenu, kterou za to platíte je, že poškození systému může být způsobem chybou software, typicky pokud se na jeho vývoji podílí jen několik málo lidí. Je to tak ve vašem případě? nemýlim se?

K tomu všemu takovým designem aplikace zvyšujete její složitost a tím i pravděpodobnost chyby a následné ztraty dat.

"Průšvih" , jak píšete, není způsobem "profesionálním hardware", ale tím, že celá infrastruktura nepočítala s tím, že by k výpadku el. produ mohlo vůbec dojít.

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.

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.

To je fakt jen čirá teorie bez znalosti enterprise nebo aspoň middle range storage od IBM, Symmetrix apod.

Seznam to evidentně nepoužívá v konfiguraci, která byla odolná vůči výpadku el. proudu, zničení serverovny atd. Budeli chtít, je to otázka pouze investice do technologie a ne do lidí.

Investice do lidí (vlastní vývoj) je dost riziková sama o sobě. Kolik vás to v Centru psalo? Kolik testovalo? Kolik testovacích scénařů jste měli?

Je dost na zamyšlenou, když na práci 1-3 programátorů stojí terabajty uživatelských dat.

S technologií, kterou používáte, je odvolávat se na to cizí neštěstí docela zábavné. Je to jako smích rogalisty, který se uprostřed přeletu atlantického oceánu dozví, že někde havaroval Concord :-)

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.

Neni to spis Michale tak, ze Centrum jeste takovy vypadek nepotkal? :-)

Konfigurace MX a NS zaznamu netcentra je takova, ze by to moje sestra zvladla lepe a kdejaky picicmunda to ma lepe. V kazdem pripade to nesvedci o tom, ze by si vubec kdy nekdo v Centru delal skutecnou analyzu rizik :-)

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

Ulozit 4 dny prichozich mailu do obycejne SMTP fronty je reseni za 50K. Nebo Ti postou prijdou za 4 dny vic nez 2 tera majlu? Pokud jo, tak se omlouvam a misto 50K rikam, ze to reseni je za 150K :-)

Pokud tu analyzu nekdo delal, pak mu muselo byt jasne, ze tohle neni disaster recovery reseni. Ale urcite je o 150K levnejsi.

A co se tyce rozdilu mezi tim, kdy DNS funguje a kdy ne, s ohledem na SMTP protokol, tak jen doufam, ze jsi tu analyzu nedelal Ty :-) Protoze pak se muze Centrum dockat i jinych "prekvapeni".

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.

Situace, ze zadny MX server nebude aktualne dostupny pro poslani posty "dale" (= blize k cili) je by-desing resena na urovni SMTP... v cem mate problem? (krome toho, ze na nektera ustanoveni relevantnich RFC Centrum.Cz (neni osamoceno:-() do dnes kasle)

Nemusim Nemusiiiim ... Kdyz mi nebezi primarni system, zalozni muze mit nizsi kapacitu a nevim jak centrumacky mailer, ale sendmail i postfix maji hezkou odpoved "450".

A jeste jeden drobny podotek. Pokud mas nekde postu za posledni 4 dny, muzes si jeji prutok regulovat z toho serveru, kde je ulozena. Pokud je na 100.000 serverech v Internetu, moznosti regulace nejsou ani zdaleka tak prijemne.

Nevim, co znamena "nebude centrum dostupne vubec". Mozna totez, co se stalo, kdyz "Internetem tolik videa jeste neteklo" (zle jazyky tvrdi, ze Centrum melo nakoupeno 200 Mb/s konektivity a myslelo, ze mu to bude bohate stacit pro vsechny sluzby - kolik je na tom pravdy?). Pochopitelne take centrum neresi, ze se muze stat cosi s propagaci adres, ktere pouzivate. Zkratka koukate na to ocima, ktere nevidi dal nez na RJ-45, kterym Vas GTSka zasobuje paketama :-)

Ale chapu, ze tech 150 koliku na nejaky backu mailserver je pro Centrum velky problem. Stejne tak pak korun na hosting DNS treba na Slovensku :-)

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.

Ja jsem nikde netvrdil, ze to ma Seznam vyreseno lepe :-)

Zalozni DNS _JE_ potreba. Pokud existuje DNS zaznam a cilovy MTA neni dostupny, ponecha si odesilanou postu odesilaci MTA (po definovanou dobu).

Pokud nebezi DNS (respektive pokud odesilaci MTA nedostane validni odpoved na MX dotaz), odesilaci MTA postu vrati hned jako nedorucitelnou.