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

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.

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.

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

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.

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.

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.

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

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_System

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

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

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

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.

Jak jste prisel na ty SCSI disky? :-)

ja nevim, co tam ONI pouzivaji :-)

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

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.

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.

Takze jsme si nerozumeli vzajemne. :-) Za svoji stranu nedorozumeni se omlouvam.

Ano je spatne mit nameservery na jednom subnetu. Bohuzel velka cast ceskych ISP to praktikuje (ale aspon maji pod kontrolou smerovani).

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.

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,

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

Ale jo. Predpokladam, ze i kdyz se ted zivi jinym byznysem, tak ji v hlave cosi zustalo z dob, kdy pracovala pro ty nejvetsi hrace na IP trhu :-)

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.

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

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?

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

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

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.

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

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

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

Souhlas.

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.

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

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.

Pokud je ale potvrzena transakce (a je putna, co ji myslime) a ve skutecnosti je pouze na jedne replice a bude znicena, tak takoveho transakciho brokera bych hnal svinskym krokem... (jeste ze u Centra nemam postu ci jakakoli (i vyznamove nezajimava) data).

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.

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.

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.

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

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.

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

SNMP?:-r

??? UPS ma pravidelne hlasit stav baterii, stav self-testu, aktualni stav baterii a dle toho ridici SW rozhoduje, zda-li server shodi nebo jede dale...

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)

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

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

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

Normalni ve smyslu typicky uzivatel sice nemusi byt imbecil, ale rozumi "tem pocitacum" tak spatne jako by byl.

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

Ja jsem imbecil jen napul. Pouzivam sice IMAP na svych pocitacich, nicmene na tech cizich pouzivam dusledne konzoloveho klienta :-)

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

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

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

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

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í

Muzete mi rici jake diskove pole je pripojeno ke kazdemu serveru? Kdyz je ten FS replikovan mezi vsechny servery?-) Co takhle si to nejprve nastudovat... Google na to ma ofic. technicky dokument, ktery je verejne pristupny.

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

Nebyl jsem ten, co tvrdil, ze vsechny servery maji kompleni replikaci dat...:-r

Trochu je to shrnuto zde http://en.wikipedia.org/wiki/Google_platform, pokud o to máte opravdu hlubší zájem a nechcete to jen takto povrchně, projděte si odkazované články nebo si zkuste takové články najít, je jich na webu docela dost a v každém se dozvíte o pár zajímavých informací více. Vždy to ale bude stav techniky, který měl Google před nějakou dobou, protože datacentra rostou jako houby po dešti a přeci jen - Google rád mluví a je rád vidět v médiích, ale to podstatné si pečlivě střeží. Neskutečná je třeba i ta vypilovanost uložení těch mnoha tun HW , např. má Google dokonce patent na takové jednoduché uložení/vedení ethernet kabelů, aby nepřekážely a přepojení/výměna zabrala co nejméně času [US pat. 6,870,095], zkrátka přemýšlí se tam na každém kroku o hodně víc než ve firmách, které jen tupě kopírují.

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

Stejne reseni se pouziva i na GMail.

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

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

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.

> U MySQL to není vůbec o verzi. MySQl by v takto rozsáhlých řešeních použil jen sebevrah.

Jako třeba Wikipedie se svými pár tisíci požadavky za sekundu? ;-)

Par tisic konkurentnich modifikacnich operaci nebo pouze read-only? Mozna byste se divil, jak rychle dochazi MySQL dech pri opravdove praci nad SQL bazi...

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

A mate oba stejnou verzi ? Typicky subselecty budou IMHO dost zaviset na verzi MySQL, protoze MySQL se jeste porad vyviji.

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

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

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

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

Při fsyncu se ostatní procesy nemusejí zastavovat.
fsync je přibližně stejně náročný jako přečtení nenacachovaného souboru, takže pokud jim server utáhne náhodné čtení souborů, když si uživatel prohlíží maily, není důvod, aby to neutáhlo náhodné zápisy do souborů, když ty maily přicházejí (navíc tomu odesílajícímu SMTP je celkem jedno, pokud dostane potvrzení až za několik sekund, takže je příjem mailů ještě méně náročný než jejich prohlížení).

Jen mě zarazilo, že když technologie chránící data proti výpadku napájení jsou vyvinuté už několik desetiletí, tak to stále není používáno a přispivatelé v tomto fóru kritizují všechny možné komponenty, které za to vůbec nemohou.

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

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.

2) Rad bych zduraznil, ze to "provozovat u sebe" je dulezite pouze z hlediska duvery. Pokud by jste mel nejakeho poskytovatele na internetu, kteremu muzete verit ze provadi lepsi "zalohovani" (spis obecne disaster recovery a disaster prevention nebo jak se tomu rika) tak je lepsi pouzivat jeho - jenze komu dneska muze clovek verit ? Jeste tak verim google ze se postara o www.google.com, ale ze mi zaruci moje maily na to bych se nespolehal.

Ad 1) Souhlasím. A ani 100% zajištěné napájení v serverovně nic nevyřeší. Co kdyby jim třeba odešel zdroj, mainboard nebo procesor? --- stává se to (jeden mainboard odešel do roka, jeden procesor do 1/4 roku a další do roka a další do 2 let) a taky by to měli mít navržené tak, aby počítač stačilo vyměnit a uživatelova data se nelikvidovala.

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

Ehm... znate princip on-line UPS? Tedy tech pravych, ne tech, ktere se za on-line vydavaji? Pokud ano, odpovezte si na otazku, jak se muze takovato UPS "pretizit" nahodnym (kdepak se nam najednou vzal?) zvysenym odberem z vystupni vetve. A pak odpovezte na tuto otazku nam do fora, urcite by nas to zajimalo... A kupodivu i UPS maji moznost redundance veskerych komponent systemu...

Pokud generator nabehl az po temer vybiti UPS... tak je asi neco spatne v navrhu, vidte?

Jo a ty bezne "cihlicky" maji realnou kapacitni zivotnost do 3 let (v praxi spise 1,5-2) a to bez vyrazneho namahani (vypadek a vybiti na 50% kapacity tak 2-3x do roka).

A centrum lze nikoli simulovat, ale realne otestovat - nejlepe pred privitanim prvniho zakaznika a pote (diky redundanci - bavime se o profesionalech, ne?) v pravidelnych intervalech testovat "po okruzich".

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.

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?

Asi nejaka nova ficura :-)

Byvaly doby, kdy oba nameservery vracely stridave obe adresy, takze by takovyto test nemusel byt smerodatny. Nevim jak je to ted a jestli je nejak reseno, aby nameservery prestaly posilat nedostupnou IP adresu.

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

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.

Ahoj Petre,
prave jsem se "parkrat" optal tech nameserveru, a pro klienty ze siti chello a T-Systems Pragonet (pak jsem na to uz nemel naladu)to vraci nahodne vysledky.
Vcera jsem poslal dotazu jen malo (sit CESNET2) a asi mi nebyl nahodny vyber naklonen :-)

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.

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

Pokud si hraji na CDN (content delivery network) - treba jen dvoupopovou, tak by meli brat v uvahu to, odkud se klient pta.

Spis to vypada, ze na optimalizaci rezignovali a je to spis failover reseni - a failover se dela rucne v zonovem souboru :-)

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?

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

Jenze pripojovani postupne neni problem UPS, ale navaznych rozvodu. A pokud to neresi automaticky, mohli tam pritomni zamestnanci realizovat nabeh rucne.

SNMP na UPS neni v ceskych telehausech zrovna standard. Vsichni vam budou tvrdit, ze to vubec nepotrebujete, protoze proud proste nevypadne a kdyz ano, tak jedine jeden rack se samostatnym jisticem, kde to stejne neni nic platne. Dosahnete toho jedine, kdyz budete nakupovat fakt velky hosting.

Dosahnete toho jedine, kdyz budete nakupovat fakt velky hosting...
... a nebudete tlacit na cenu :-)

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.

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.

Mam to nastaveno stejne, ale stejne tak mam nastaveno, ze UPSka takovy server vzbudi az ma energii na 50% provozu (tedy cca 10-15 minut) - za tu dobu servery nabehnou do stavu, ze klidne mohou jit zase na INIT 6 a ukoncit se... a jeste pulka casu zbyde.... Ano vim, jsou servery/aplikace, ktere mohou nabihat klidne 30 a vice minut, pak je to ale o dimenzaci napajeni (a jeho zalohy) do serveru...

Nicmene v atomove elektrarne nemaji server ktery provozuje Pepa Jetel z dolni horni pripadne z nejake zapadle horske vizky (Straz nad Nisou). Timto se ZC omlouvam je to jen podvecerni rejpnuti. Takze ano tam to technici obejdou v 90% pripadu ceskych telehouse se to zakaznik dozvi po nekolika hodinach - inu kazdy sveho stesti strujce.

APC dela krasne PDU s postupnym nabehem cena pro cely rack od 800 czk/port. Me na nich spise vadi to, ze se do toho racku blbe davaji (vsechny telehouse preferuji 80tky misto 100vek).

Ten general error nebo snmp server pro zakazniky by ovsem telehouse zavest meli, prece jenom to stoji par susnu.

V cene vybaveni telehousu urcite, ale zrovna APC bych za SNMP kartu nebo alespon replikator portu pro bezne UPS docela povesil za koule...:-)

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