Vlákno názorů k článku Výpadek TTC ochromil 200 tisíc e-mailových schránek Seznamu od Frodik - To že UPSka nevydrží tolik kolik nahlásí se...
-
Frodik (neregistrovaný)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, ...
-
Frodik (neregistrovaný)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... -
Dusan (neregistrovaný)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. -
Jan Forman (neregistrovaný)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. -
Jan Forman (neregistrovaný)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 -
Michal Kára (neregistrovaný)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 :-) -
Michal Kára (neregistrovaný)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.
-
Dusan (neregistrovaný)> 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. -
Dusan (neregistrovaný)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... -
Dusan (neregistrovaný)> 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
. -
Michal Kára (neregistrovaný)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 :-)
-
Michal Kára (neregistrovaný)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 :-) -
deda.jabko (neregistrovaný)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 -
František Ryšánek (neregistrovaný)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. -
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. -
Michal Kára (neregistrovaný)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 -
Michal Kára (neregistrovaný)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. -
anonymní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. -
Michal Kára (neregistrovaný)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. -
anonymní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 :-) -
Michal Kára (neregistrovaný)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. -
Michal Kára (neregistrovaný)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".
-
Michal Kára (neregistrovaný)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. -
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 :-)
-
J (neregistrovaný)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.
-
Michal Kára (neregistrovaný)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. -
Michal Kára (neregistrovaný)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. -
Ale Michale, takove distribucni systemy prece neoperuji nad jednou bazi (RAID) a kopie jednotky informace jsou rozprostreny v topologii nekolikrat... - takze vypadek nevadi, pracuje se s lokalni (byt zastaralou) kopii a casem se to synchronizuje... vicefazovy (alespon dvou) commit znate... princip je stejny (a tedy zhola odlisny od RAIDu)... mam za to, ze GFS i AFS pracuji timto stylem...
-
nechci se zastavat cetnra ale to co povidate je cista masaz techto dodavatelu. Programator centra muze byt sebevetsi prase ale nezavisly audit toho ze na tom druhem konci republiky je identicka kopie toho co tady proveri jestli to opravdu funguje.
Samozrejme by mel probiha nejaky monitoring ale rikat ze kdyz nekdo upravi smtp server ze veskere prichozi veci rovnou kopiruje zurnalogem s daty na server 1000 km daleko aby vedel ze je ma treba posledni 4 hodiny kopirovany na 3 stroje poslednich 24 na dva stroje a poslednich 48 hodin na jednom stroji (jedno zaloznim tj ve dvou kopiich) je proste vzdy levnejsi nez nejake hw reseni. -
To vis, kazde reseni ma nejake mouchy. Napriklad v kauze "tolik videa ceskym Internetem jeste neteklo" se nevyznamenal jiny portal :-) Pripadne konfigurace MX a NS zaznamu netcentra je, ehm ... projevem l*******y hodne velke urovne. Vsechny adresy v jednom bloku a jeste v ASu, ktery neni vlastni ... ehm ... Naklad na redundanci je ehm ... Kolik ... Padesat tisic na server a pet tisic mesicne na hosting. Setrit se musi, at to stoji, co to stoji.
-
Dusan (neregistrovaný)> 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. -
Dusan (neregistrovaný)> 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. -
František Ryšánek (neregistrovaný)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... -
Dusan (neregistrovaný)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. -
Michal Kára (neregistrovaný)> 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. -
Dusan (neregistrovaný)> 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. -
Michal Kára (neregistrovaný)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. -
František Ryšánek (neregistrovaný)> 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. -
Reverse (neregistrovaný)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.
-
anonymníUPS-ka, která vydrží 10 minut má prostě staré baterky (anebo si nějaký trouba nepřečetl, jakou má kapacitu).
Ovšem lepší UPS-ky umějí samy při klesání výkonu řádně odstavit počítač. Napište raději, jaké šunky používali, aby si je ostatní pro jistotu už nekupovali.
P.S.
Vůbec nejlepší je z článku věta, že ani ředitel ani tisková mluvčí nebyli hned k zastižení. Prosím Vás, znáte někdo firmu, kde ředitel a tisková mluvčí vůbec něčemu trochu složitějšímu rozumí? Jeden nebyl schopen ani dostudovat a druhá je pro změnu určitě vystudovaná žurnalistka. -
anonymníTTC ma dimenzovane UPS na ~10minut - alespon to lze vycist z materialu (pripadove studie) publikovane na webu APC... - puvodni design capacity 30minut, a planovali snizeni na 1/3; po tom co se tam nastehoval Cendra se svym ansablem a svym pristupem k napajeni obecne bych se nedivil, kdyby jim to cele pretizil (ono to stehovani probihalo dosti zbrkle, takze ani jeho vlastni zakaznici nevedeli, ze jim servery ze Zelivskeho mizi do Malesic)...
ČLÁNKY DO MAILU