Internet Info, s.r.o. Lupa Měšec Podnikatel Root Zdroják DigiZone Slunečnice Vitalia TopDrive KupDnes Navrcholu NovýTarif Dobrý web Weblogy Woko Jagg Computer.cz SK: MojeLinky

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

bigboban
bigboban (neregistrovaný)
11. 7. 2006 8:19 Nový

Spadlá DB a filesystém?

celé vlákno
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???
mirek
mirek (neregistrovaný)
11. 7. 2006 8:29 Nový

Re: Spadlá DB a filesystém?

celé vlákno
Maji tam nejakou distribuci GNU/Linux, takze za svuj hazard zaplatili.
LIbb
LIbb (neregistrovaný)
11. 7. 2006 8:35 Nový

Re: Spadlá DB a filesystém?

celé vlákno
no hlavně že ušetřili na software :-)
uživatel si přál zůstat v anonymitě
11. 7. 2006 8:51 Nový

Re: Spadlá DB a filesystém?

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

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

Re: Spadlá DB a filesystém?

celé vlákno
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.
uživatel si přál zůstat v anonymitě
11. 7. 2006 22:05 Nový

Re: Spadlá DB a filesystém?

celé vlákno
Heh .. a to jste vzal kde? :) NTFS nezurnaluje data samotna.. ale pouze metadata.... cili je to tak na pul
Tomas Crhonek aura:100
11. 7. 2006 22:22 Nový

Re: Spadlá DB a filesystém?

celé vlákno
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).
M jako Molitan
M jako Molitan (neregistrovaný)
12. 7. 2006 20:12 Nový

Re: Spadlá DB a filesystém?

celé vlákno
Kazdopadne poznamka, ze NTFS je zurnalovaci byla trochu zbytecna, vzhledem k tomu, ze i v puvodnim prispevku ten clovek psal, ze NTFS je zurnalovaci.
uživatel si přál zůstat v anonymitě
10. 8. 2006 9:53 Nový

Re: Spadlá DB a filesystém?

celé vlákno
hazard? hazard je mít na serveru windows :P
Newkiller
Newkiller (neregistrovaný)
10. 8. 2006 9:56 Nový

Re: Spadlá DB a filesystém?

celé vlákno
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
Tomas Crhonek aura:100
11. 7. 2006 8:42 Nový

Re: Spadlá DB a filesystém?

celé vlákno
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.
xpman
xpman (neregistrovaný)
11. 7. 2006 8:50 Nový

Re: Spadlá DB a filesystém?

celé vlákno
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!
PiPe.cz
PiPe.cz (neregistrovaný)
11. 7. 2006 9:03 Nový

Re: Spadlá DB a filesystém?

celé vlákno
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.
Anonym
Anonym (neregistrovaný)
11. 7. 2006 9:09 Nový

Re: Spadlá DB a filesystém?

celé vlákno
Doporucuju vymenit tvyho dodavatele diskovejch poli. I tchajwansky mrchy maj dneska baterky, co bez problemu zvladnou flush cache na disky.
Pavel Janoušek
11. 7. 2006 14:23 Nový

Re: Spadlá DB a filesystém?

celé vlákno
Paklize jim to ty disky jeste dovoli, vidte?:-)
jouda
jouda (neregistrovaný)
11. 7. 2006 9:03 Nový

Re: Spadlá DB a filesystém?

celé vlákno
2 xpman: To jste opravdu myslel vážně? Není Vám moc horko?
Vonka
Vonka (neregistrovaný)
11. 7. 2006 10:30 Nový

Re: Spadlá DB a filesystém?

celé vlákno
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ý.
uživatel si přál zůstat v anonymitě
11. 7. 2006 12:46 Nový

Re: Spadlá DB a filesystém?

celé vlákno
na rozumnem hw je pri standardni distro a dobre administrovanych windows (to MALOKDO umi, stejne jako rozumne administrovat *nix) je porad vetsi podil kernel panicku nez BSOD - to je proste fakt
J
J (neregistrovaný)
11. 7. 2006 13:11 Nový

Re: Spadlá DB a filesystém?

celé vlákno
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.
stroural
stroural (neregistrovaný)
11. 7. 2006 13:24 Nový

Re: Spadlá DB a filesystém?

celé vlákno
Zadny pad pod Windows neni zahadny. Zahadny je jenom pro toho, kdo tomu systemu nerozumi - coz je zrejme vas pripad.
Jan Forman
Jan Forman (neregistrovaný)
11. 7. 2006 13:31 Nový

Re: Spadlá DB a filesystém?

celé vlákno
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ř...
J
J (neregistrovaný)
11. 7. 2006 13:55 Nový

Re: Spadlá DB a filesystém?

celé vlákno
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.
uživatel si přál zůstat v anonymitě
11. 7. 2006 13:58 Nový

Re: Spadlá DB a filesystém?

celé vlákno
podobnou situaci vam nasimuluji skutecne na naprosto kazdem OS

podobnou situaci vam nasimuluji u uplne kazde podpory - pravdu u vetsiny ne-widle (viz idiotska terminologie) systemu ani zadna neni
uživatel si přál zůstat v anonymitě
11. 7. 2006 13:32 Nový

Re: Spadlá DB a filesystém?

celé vlákno
ja rozumim proc neumite na takovou otazku odpovedet - zkuste si vy-mns-novat :-) napr. WHQL

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

tedy-mylite se
jarda
jarda (neregistrovaný)
12. 7. 2006 8:24 Nový

Re: Spadlá DB a filesystém?

celé vlákno
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.
uživatel si přál zůstat v anonymitě
13. 7. 2006 23:06 Nový

Re: Spadlá DB a filesystém?

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

Re: Spadlá DB a filesystém?

celé vlákno
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.
msk
msk (neregistrovaný)
21. 7. 2006 11:29 Nový

Re: Spadlá DB a filesystém?

celé vlákno
Mily ziak strednej/zakladnej skoly. Kolko kernel panic-v si videl osobne na kolkych strojoch nasadenych na kriticke aplikacie?
Frodik
Frodik (neregistrovaný)
11. 7. 2006 9:07 Nový

Redundance

celé vlákno
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, ...
Tomas Crhonek aura:100
11. 7. 2006 9:14 Nový

Re: Redundance

celé vlákno
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.
Frodik
Frodik (neregistrovaný)
11. 7. 2006 9:25 Nový

Re: Redundance

celé vlákno
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
Dusan (neregistrovaný)
11. 7. 2006 10:43 Nový

Re: Redundance

celé vlákno
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.
uživatel si přál zůstat v anonymitě
11. 7. 2006 10:56 Nový

Re: Redundance

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

Nějaký další argument?
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 11:06 Nový

Re: Redundance

celé vlákno
Ano. Hruby zisk CEZu byl za prvni ctvrtleti tohoto roku 15 miliard :-)
uživatel si přál zůstat v anonymitě
11. 7. 2006 11:08 Nový

Re: Redundance

celé vlákno
A Centra?
xyz
xyz (neregistrovaný)
11. 7. 2006 13:17 Nový

Re: Redundance

celé vlákno
A cendra?
Dusan
Dusan (neregistrovaný)
11. 7. 2006 14:08 Nový

Re: Redundance

celé vlákno
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.
czDa5id
czDa5id (neregistrovaný)
11. 7. 2006 16:22 Nový

Re: Redundance

celé vlákno
Pokud máš na mysli hospodářské výsledky, stačí se kouknout do Seznamu evidovaných listin na www.justice.cz
Jan Forman
Jan Forman (neregistrovaný)
11. 7. 2006 12:19 Nový

Re: Redundance

celé vlákno
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.
Michal Krsek aura:57
11. 7. 2006 12:22 Nový

Re: Redundance

celé vlákno
Pokud vim, tak se diskutuje Seznam, nikoliv TTC :-)
Jan Forman
Jan Forman (neregistrovaný)
11. 7. 2006 13:01 Nový

Re: Redundance

celé vlákno
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 Krsek aura:57
11. 7. 2006 13:14 Nový

Re: Redundance

celé vlákno
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.
Pavel Janoušek
11. 7. 2006 14:25 Nový

Re: Redundance

celé vlákno
Naivko:-)
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 9:16 Nový

Re: Redundance

celé vlákno
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.
Michal Krsek aura:57
11. 7. 2006 9:33 Nový

Re: Redundance

celé vlákno
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
Michal Kára (neregistrovaný)
11. 7. 2006 9:59 Nový

Re: Redundance

celé vlákno
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.
Michal Krsek aura:57
11. 7. 2006 10:16 Nový

Re: Redundance

celé vlákno
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
Dusan (neregistrovaný)
11. 7. 2006 10:49 Nový

Re: Redundance

celé vlákno
> 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.
Pavel Janoušek
11. 7. 2006 14:27 Nový

Re: Redundance

celé vlákno
A pak se objevi trocha vody a vyplachne par mestaku a je z toho tisicileta voda...:-)
Dusan
Dusan (neregistrovaný)
11. 7. 2006 14:40 Nový

Re: Redundance

celé vlákno
Mit alespon jedno datacentrum dostatecne vysoko nad rekou je samozrejme zakladni pozadavek.
Pavel Janoušek
11. 7. 2006 14:47 Nový

Re: Redundance

celé vlákno
Vy jste ale rizikovy analytik... copak povoden je jedine riziko? A to muzeme stale zustat pouze u tech zivelnych a nikoli teroristickych/zaskodnickych...:-)
Dusan
Dusan (neregistrovaný)
11. 7. 2006 18:35 Nový

Re: Redundance

celé vlákno
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.
Pavel Janoušek
11. 7. 2006 21:23 Nový

Re: Redundance

celé vlákno
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
Dusan (neregistrovaný)
12. 7. 2006 9:32 Nový

Re: Redundance

celé vlákno
> 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.
Pavel Janoušek
12. 7. 2006 9:42 Nový

Re: Redundance

celé vlákno
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

.
Béďa Rozumbrada
Béďa Rozumbrada (neregistrovaný)
11. 7. 2006 16:04 Nový

Re: Redundance

celé vlákno
A když jí budeš mít na kopci, tak ti zase do ní budou mlátit blesky :-))))))))
Pavel Janoušek
11. 7. 2006 16:12 Nový

Re: Redundance

celé vlákno
Krome nebezpeci pozaru a elmag. zareni (oboji resitelne), cemu jinemu to vadi?:-)
John_
John_ (neregistrovaný)
11. 7. 2006 17:23 Nový

Re: Redundance

celé vlákno
Letadlum? :)
Pavel Janoušek
11. 7. 2006 17:26 Nový

Re: Redundance

celé vlákno
Vy jste slysel o zivelne pohrome na strategicke zasoby zeme nebo vojensky vyznamnem miste?
Tomas
Tomas (neregistrovaný)
14. 7. 2006 19:13 Nový

Re: Redundance

celé vlákno
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.
Mard
Mard (neregistrovaný)
15. 7. 2006 18:28 Nový

Re: Redundance

celé vlákno
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.
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 10:56 Nový

Re: Redundance

celé vlákno
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.
Michal Krsek aura:57
11. 7. 2006 11:13 Nový

Re: Redundance

celé vlákno
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 Krsek aura:57
11. 7. 2006 11:14 Nový

Re: Redundance

celé vlákno
s/chytry system/chytry souborovy system/
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 11:34 Nový

Re: Redundance

celé vlákno
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 :-)
Michal Krsek aura:57
11. 7. 2006 11:52 Nový

Re: Redundance

celé vlákno
500MB/s = 4 Gb/s ... To mi prijde prilis.

Co je to "ne moc spolehliva sit"? Vypadky infrastruktury? Ztraty paketu? Velky rozptyl? :-)
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 12:11 Nový

Re: Redundance

celé vlákno
Je to odhad, ale IMHO radove mimo neni.

Vsechno vyjmenovane.
Mr.StY
Mr.StY (neregistrovaný)
11. 7. 2006 13:52 Nový

Re: Redundance

celé vlákno
A co tak L2/L3 vrsta? napr STP abo VRRP protokoly ? Alebo technologia ATM ? tam mas cas regeneracie okruhu do 50 ms
Pavel Janoušek
11. 7. 2006 14:29 Nový

Re: Redundance

celé vlákno
Ja mel za to, ze GFS vcetne implementace a specifikace koupil RedHat... ale mozna jsem mel mlhu...:-)
deda.jabko
deda.jabko (neregistrovaný)
11. 7. 2006 15:22 Nový

Re: Redundance

celé vlákno
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
František Ryšánek (neregistrovaný)
11. 7. 2006 16:04 Nový

Re: Redundance

celé vlákno
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.
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 17:13 Nový

Re: Redundance

celé vlákno
Zhruba tak. Jinak udajne pouzivaji tri kopie.
Martin Kalenda
11. 7. 2006 12:51 Nový

Re: Redundance

celé vlákno
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.
Pavel Janoušek
11. 7. 2006 14:30 Nový

Re: Redundance

celé vlákno
No hlavne vime, ze jedou uplne na doraz, kdyz nejsou schopny zalohovat adress booky s poukazem na vytizeni...:-) - kolik by ty AD asi prispely?
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 17:11 Nový

Re: Redundance

celé vlákno
To me taky dostalo :-)
uživatel si přál zůstat v anonymitě
11. 7. 2006 9:51 Nový

Re: Redundance

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

Takže to co používá Seznam , a čemu vy říkáte "RAID" jim přes WAN poběží.
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 10:06 Nový

Re: Redundance

celé vlákno
Koukam expert na architekturu Centra. Ale ja jsem vetsi :-) Samozrejme to jde.
uživatel si přál zůstat v anonymitě
11. 7. 2006 10:58 Nový

Re: Redundance

celé vlákno
Můžete uvést výrobce toho RAIDu nebo raději ne? :-)
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 11:10 Nový

Re: Redundance

celé vlákno
uživatel si přál zůstat v anonymitě
11. 7. 2006 11:22 Nový

Re: Rundance

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

Když uvážím, že OS i file system bude stejný jako na Seznamu, pak teoretická dostupnost řešení je na Centru řádově horší.
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 11:36 Nový

Re: Rundance

celé vlákno
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.
uživatel si přál zůstat v anonymitě
11. 7. 2006 11:53 Nový

Re: Rundance

celé vlákno
No však to píšu. Na koleně řešený clustering, který jinak vyvíjí desítky programátorů po několik let.

Pokud PC s SCSI disky říkáte storage, tak OK :-D
Michal Krsek aura:57
11. 7. 2006 12:10 Nový

Re: Rundance

celé vlákno
Jak jste prisel na ty SCSI disky? :-)
uživatel si přál zůstat v anonymitě
11. 7. 2006 12:16 Nový

Re: Rundance

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


Tak co v tom Centru tedy používáte za diskové storage?
Michal Krsek aura:57
11. 7. 2006 12:18 Nový

Re: Rundance

celé vlákno
ja nevim, co tam ONI pouzivaji :-)
uživatel si přál zůstat v anonymitě
11. 7. 2006 22:41 Nový

Re: Rundance

celé vlákno
Podle toho jak se nikdo nehrne do odpovědi tak nepoužívají žádný storage. Nebo je to Centrumáci jinak?
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 12:46 Nový

Re: Rundance

celé vlákno
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" :-)
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 10:14 Nový

Re: Redundance

celé vlákno
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.
uživatel si přál zůstat v anonymitě
11. 7. 2006 10:51 Nový

Re: Redundance

celé vlákno
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
Michal Kára (neregistrovaný)
11. 7. 2006 11:25 Nový

Re: Redundance

celé vlákno
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.
uživatel si přál zůstat v anonymitě
11. 7. 2006 11:48 Nový

Re: Redundance

celé vlákno
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
Michal Kára (neregistrovaný)
11. 7. 2006 12:32 Nový

Re: Redundance

celé vlákno
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 Krsek aura:57
11. 7. 2006 13:19 Nový

Re: Redundance

celé vlákno
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 :-)
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 13:31 Nový

Re: Redundance

celé vlákno
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 ;-)
Michal Krsek aura:57
11. 7. 2006 13:46 Nový

Re: Redundance

celé vlákno
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
Michal Kára (neregistrovaný)
11. 7. 2006 14:09 Nový

Re: Redundance

celé vlákno
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.
Pavel Janoušek
11. 7. 2006 14:40 Nový

Re: Redundance

celé vlákno
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)
Michal Krsek aura:57
11. 7. 2006 15:15 Nový

Re: Redundance

celé vlákno
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
J (neregistrovaný)
11. 7. 2006 14:07 Nový

Re: Redundance

celé vlákno
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.
Michal Krsek aura:57
11. 7. 2006 15:07 Nový

Re: Redundance

celé vlákno
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.
J
J (neregistrovaný)
11. 7. 2006 16:05 Nový

Re: Redundance

celé vlákno
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.
Michal Krsek aura:57
11. 7. 2006 17:23 Nový

Re: Redundance

celé vlákno
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).
uživatel si přál zůstat v anonymitě
11. 7. 2006 17:11 Nový

Re: Redundance

celé vlákno
A co Atlas ?
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 18:39 Nový

Re: Redundance

celé vlákno
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.
uživatel si přál zůstat v anonymitě
11. 7. 2006 22:44 Nový

Centrum je levnější na úkor rizika

celé vlákno
Ano, řešení Centra je zřejmě VÝRAZNĚ levnější za cenu rizika a to zejména zanesení chyb do složitější aplikace, nebezpečí odchodu těch několika málo lidí, kteří tomu rozumí atd.

Určitě je to solidní řešení, za daných nákladů možná i jediné rozumné a realizovatelé.
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 23:46 Nový

Re: Centrum je levnější na úkor rizika

celé vlákno
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.
Robert Urbanik
Robert Urbanik (neregistrovaný)
16. 7. 2006 23:48 Nový

Re: Redundance

celé vlákno
Ale Michale,

ze jsi to s tou svoji sestrou nemyslel vazne ;-)
Michal Krsek aura:57
17. 7. 2006 15:26 Nový

Re: Redundance

celé vlákno
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 :-)
Pavel Janoušek
11. 7. 2006 14:36 Nový

Re: Redundance

celé vlákno
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...
Martin Kalenda
11. 7. 2006 12:58 Nový

Re: Redundance

celé vlákno
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.
uživatel si přál zůstat v anonymitě
11. 7. 2006 22:53 Nový

Re: Redundance

celé vlákno
Levnější je do doby než toho jednoho levného programátora, který nedělá chyby, nepřejede auto. Pak se teprve ukáže jak drahé to bylo.

Jsou firmy, které si můžou dovolit kupovat levné věci a jsou firmy, které si to dovolit nemůžou. Co preferovali v Centru je asi jasné.
Michal Krsek aura:57
11. 7. 2006 10:57 Nový

Re: Redundance

celé vlákno
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.
uživatel si přál zůstat v anonymitě
11. 7. 2006 11:00 Nový

Re: Redundance

celé vlákno
Marketing musí být i kdyby na administrátory nebylo!
Dusan
Dusan (neregistrovaný)
11. 7. 2006 10:47 Nový

Re: Redundance

celé vlákno
> 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.
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 11:39 Nový

Re: Redundance

celé vlákno
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?
Dusan
Dusan (neregistrovaný)
11. 7. 2006 13:33 Nový

Re: Redundance

celé vlákno
> 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
František Ryšánek (neregistrovaný)
11. 7. 2006 16:58 Nový

Re: Redundance

celé vlákno
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
Dusan (neregistrovaný)
11. 7. 2006 18:51 Nový

Re: Redundance

celé vlákno
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
Michal Kára (neregistrovaný)
11. 7. 2006 22:29 Nový

Re: Redundance

celé vlákno
> 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
Dusan (neregistrovaný)
12. 7. 2006 9:19 Nový

Re: Redundance

celé vlákno
> 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
Michal Kára (neregistrovaný)
12. 7. 2006 9:42 Nový

Re: Redundance

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

Souhlas.
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 18:57 Nový

Re: Redundance

celé vlákno
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
František Ryšánek (neregistrovaný)
11. 7. 2006 20:24 Nový

Re: Redundance

celé vlákno
> 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.
uživatel si přál zůstat v anonymitě
11. 7. 2006 22:46 Nový

Re: Redundance

celé vlákno
Vy jste tvurce emailu Centra, je to tak? Nepřijde vám hloupé z této pozice napadat někoho z toho, že je obchodník s HW a je tedy dle vás zaujatý?
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 23:38 Nový

Re: Redundance

celé vlákno
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.
Pavel Janoušek
12. 7. 2006 8:36 Nový

Re: Redundance

celé vlákno
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).
johnny
johnny (neregistrovaný)
11. 7. 2006 13:54 Nový

Re: Redundance

celé vlákno
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.
Reverse
Reverse (neregistrovaný)
12. 7. 2006 10:53 Nový

Re: Redundance

celé vlákno
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.
Dusan
Dusan (neregistrovaný)
12. 7. 2006 11:01 Nový

Re: Redundance

celé vlákno
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.
Reverse
Reverse (neregistrovaný)
12. 7. 2006 13:58 Nový

Re: Redundance

celé vlákno
No, nevim jesli tohle je zrovna low end :o). Rekl bych, ze spise stredni trida. Lowendy si predstavuji trochu jinak :o).
Dusan
Dusan (neregistrovaný)
12. 7. 2006 15:37 Nový

Re: Redundance

celé vlákno
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.
uživatel si přál zůstat v anonymitě
11. 7. 2006 12:28 Nový

Re: Redundance

celé vlákno
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.
Bok
Bok (neregistrovaný)
11. 7. 2006 12:55 Nový

Re: Redundance

celé vlákno
Vsak nikdo nerikal, ze by tam meli byt proto, aby neco opravovali :) Ale proto, aby komunikovali s postizenymi uzivateli a medii...
uživatel si přál zůstat v anonymitě
11. 7. 2006 16:00 Nový

Re: Redundance

celé vlákno
No to nejsou "lepsi" upsky na home pouziti.. to je uplne jina trida UPS. Chtel bych videt jak od jedne takove UPS tahnes kabely k tisici strojum aby si s ni kazdy mohl hezky povidat v jakem je stavu. Evidentne o tom jak se telehousy stavej vubec nic nevis.
Pavel Janoušek
11. 7. 2006 17:21 Nový

Re: Redundance

celé vlákno
SNMP?:-r
uživatel si přál zůstat v anonymitě
11. 7. 2006 21:21 Nový

Re: Redundance

celé vlákno
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)...
Pavel Janoušek
11. 7. 2006 14:24 Nový

Re: Redundance

celé vlákno
??? 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...
xoxo
xoxo (neregistrovaný)
11. 7. 2006 9:32 Nový

data na serverech

celé vlákno
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)
Ritchie
Ritchie (neregistrovaný)
11. 7. 2006 9:47 Nový

Re: data na serverech

celé vlákno
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í?
heh
heh (neregistrovaný)
11. 7. 2006 9:47 Nový

Re: data na serverech

celé vlákno
Normální člověk hlavně šetří s "imbecily" na závažnější chvíle:P
stroural
stroural (neregistrovaný)
11. 7. 2006 11:38 Nový

Re: data na serverech

celé vlákno
Normalni - ve smyslu typicky - uzivatel ma emaily na free serveru a nezalohuje si je.
HK Maly aura:61
12. 7. 2006 8:17 Nový

Re: data na serverech

celé vlákno
Normalni ve smyslu typicky uzivatel sice nemusi byt imbecil, ale rozumi "tem pocitacum" tak spatne jako by byl.
deda.jabko
deda.jabko (neregistrovaný)
11. 7. 2006 13:42 Nový

Re: data na serverech

celé vlákno
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...
Michal Krsek aura:57
11. 7. 2006 14:00 Nový

Re: data na serverech

celé vlákno
Ja jsem imbecil jen napul. Pouzivam sice IMAP na svych pocitacich, nicmene na tech cizich pouzivam dusledne konzoloveho klienta :-)
rogue
rogue (neregistrovaný)
11. 7. 2006 14:17 Nový

Re: data na serverech

celé vlákno
Tak to asi zřejmě imbecil budu :)) Používám jak IMAP tak "nedejbůh webové rozhraní". Dále no comment.
Jan Forman
Jan Forman (neregistrovaný)
11. 7. 2006 9:49 Nový

Seznam vždycky tam najdu co neznám

celé vlákno
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í.
uživatel si přál zůstat v anonymitě
11. 7. 2006 10:53 Nový

Re: Seznam vždycky tam najdu co neznám

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

Ps. No vidíte jak jste šikovný. A to máte jen o 449 serverů méně než Seznam a jak to hezky zvládáte :)
Jan Forman
Jan Forman (neregistrovaný)
11. 7. 2006 12:26 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
GOOGLE je sebevrah? To si nemyslim a ani nepouzivaji diskova pole pouze 2x IDE disk a rekl bych ze jim to celkem funguje :)
uživatel si přál zůstat v anonymitě
11. 7. 2006 12:30 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
A na co tam takovou konnfiguraci používají? Kde k tomu najít další informace?
Jan Forman
Jan Forman (neregistrovaný)
11. 7. 2006 12:47 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
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ší.
uživatel si přál zůstat v anonymitě
11. 7. 2006 13:52 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
Takže to používají na data, která mohou snadno nahradit :-). Když jeden počítač umře, mají dalších deset. Když umře všech deset tak to znova naindexují z Internetu. To je trochu jiná situace.
Jan Forman
Jan Forman (neregistrovaný)
11. 7. 2006 14:55 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
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í
Pavel Janoušek
11. 7. 2006 17:22 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
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.
Jan Forman
Jan Forman (neregistrovaný)
11. 7. 2006 18:19 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
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?)
Pavel Janoušek
12. 7. 2006 8:38 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
Nebyl jsem ten, co tvrdil, ze vsechny servery maji kompleni replikaci dat...:-r
Libor Nováček aura:100
13. 7. 2006 18:32 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
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í.
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 12:47 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
Nojo, holt jsou to lamy, na Seznam nemaji, ten pouziva profesionalni reseni :-)))
uživatel si přál zůstat v anonymitě
11. 7. 2006 13:57 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
Fulltext je něco dost jiného než email, že? ;-)
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 14:10 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
Stejne reseni se pouziva i na GMail.
uživatel si přál zůstat v anonymitě
11. 7. 2006 22:48 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
Kde se o tom píše? Máte nějaký odkaz?
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 23:35 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
uživatel si přál zůstat v anonymitě
12. 7. 2006 0:02 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
Tak a teď si srovnejmě kolik lidí pracuje na GFS a kolik na aplikaci Centra a popřemýšlejte o tom jak by vadalo srovnání rizik, které podstupuje Google a která Centrum.
Michal Kára
Michal Kára (neregistrovaný)
12. 7. 2006 8:08 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
Nevim, proc s tim srovnavate aplikaci Centra, ta je o mnoho jednodussi, nez GFS - odpovida moznostem Centra.
Michal Kára
Michal Kára (neregistrovaný)
12. 7. 2006 8:11 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
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.
mormegil aura:88
11. 7. 2006 16:31 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno

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

uživatel si přál zůstat v anonymitě
11. 7. 2006 16:44 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
To jsou požadavky prakticky pouze na čtení. To přeci nemůžete srovnávat.
Pavel Janoušek
11. 7. 2006 17:23 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
Par tisic konkurentnich modifikacnich operaci nebo pouze read-only? Mozna byste se divil, jak rychle dochazi MySQL dech pri opravdove praci nad SQL bazi...
Jan Forman
Jan Forman (neregistrovaný)
11. 7. 2006 18:51 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
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í...
uživatel si přál zůstat v anonymitě
11. 7. 2006 21:54 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
No a ja mam uplne opacne zkusenosti. Trochu slozitejsi dotaz, nedejboze subselect a mysql je otresne pomale.
HK Maly aura:61
12. 7. 2006 8:22 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
A mate oba stejnou verzi ? Typicky subselecty budou IMHO dost zaviset na verzi MySQL, protoze MySQL se jeste porad vyviji.
J
J (neregistrovaný)
12. 7. 2006 12:28 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
Pokud vim, subselecty jsou pouzitelne az v 5.x verzi a ta je jeste v hodne bourlive se vyvyjejicim stadiu.
Jan Forman
Jan Forman (neregistrovaný)
12. 7. 2006 22:55 Nový

Re: Seznam vždycky tam najdu co neznám

celé vlákno
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
Mikuláš Patočkla
Mikuláš Patočkla (neregistrovaný)
11. 7. 2006 14:08 Nový

Databáze mají transakce, filesystém má fsync()

celé vlákno
... 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á.
Jan Forman
Jan Forman (neregistrovaný)
11. 7. 2006 15:01 Nový

Re: Databáze mají transakce, filesystém má fsync()

celé vlákno
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
Mikuláš Patočka
13. 7. 2006 19:27 Nový

Re: Databáze mají transakce, filesystém má fsync()

celé vlákno
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.
Majkls
Majkls (neregistrovaný)
11. 7. 2006 15:07 Nový

Re: Databáze mají transakce, filesystém má fsync()

celé vlákno
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...
Michal Kára
Michal Kára (neregistrovaný)
11. 7. 2006 15:58 Nový

Re: Databáze mají transakce, filesystém má fsync()

celé vlákno
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.
uživatel si přál zůstat v anonymitě
11. 7. 2006 15:21 Nový

Ponaučení

celé vlákno
1) Docela mě překvapuje, že párminutový výpadek elektřiny je schopen částečně zlikvidovat Seznam. Skoro bych v tomhle případě viděl chybu na straně Seznamu než datovýho centra - otázka reagování na napájení z UPS a možného totálního výpadku. Zásobování elektřinou nikdy ze zásady 100%ní být nemůže.

2) Tohle ještě jednou ukazuje zranitelnost řešení, které nabízejí firmy přes internet: různý 1 - 2 gigový schránky, vzdálená úschova souborů, vzdálená editace, vzdálené CRM a objednávkové systémy a nevím co ještě. Pokud prostě někdo na něčem opravdu závisí, musí si to provozovat u sebe, zálohovat, zálohovat, zálohovat. Internetový služby jsou určitě taky užitečný, ale tu spolehlivost musí brát člověk s rezervou.
HK Maly aura:61
12. 7. 2006 8:26 Nový

Re: Ponaučení

celé vlákno
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.
Mikuláš Patočka
13. 7. 2006 19:43 Nový

Re: Ponaučení

celé vlákno
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.
uživatel si přál zůstat v anonymitě
11. 7. 2006 15:51 Nový

Stejne je to cele divne

celé vlákno
Zda se, ze vsichni skutecnost lakuji na ruzovou.

Ze se prehral motorgenerator, muze se stat, nekdo nemenil filtry nebo tak neco. Ale proc po jeho vypadku spadla pretizena UPS? Vzdyt to byla ta sama UPS ktera zivila servery do startu motorgeneratoru. Tak co ji vlastne pretizilo?

Ze se radove lisi doba vypadku priznavana Cendrou od TTC je asi folklor.

A dostavame se k seznamu. Cekal jsem alepon Ivo rekne co se stalo tak, aby bylo jasne co se deje. Misto toho zase mlha.
František Ryšánek
František Ryšánek (neregistrovaný)
11. 7. 2006 17:50 Nový

Re: Stejne je to cele divne

celé vlákno
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...
Pavel Janoušek
12. 7. 2006 8:45 Nový

Re: Stejne je to cele divne

celé vlákno
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".

J
J (neregistrovaný)
12. 7. 2006 12:46 Nový

Re: Stejne je to cele divne

celé vlákno
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.
Petr Souček
Petr Souček (neregistrovaný)
11. 7. 2006 18:07 Nový

Konfigurace DNS seznamu

celé vlákno
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?
Michal Krsek aura:57
11. 7. 2006 18:47 Nový

Re: Konfigurace DNS seznamu

celé vlákno
Asi nejaka nova ficura :-)
Dan Ohnesorg aura:100
11. 7. 2006 19:47 Nový

Re: Konfigurace DNS seznamu

celé vlákno
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.
robert
robert (neregistrovaný)
11. 7. 2006 22:42 Nový

Re: Konfigurace DNS seznamu

celé vlákno
Asi pul roku stara featura. A vraci to zaznamy funkcniho providera, pripadne na stridacku vsech provideru.
Petr Souček
Petr Souček (neregistrovaný)
11. 7. 2006 23:17 Nový

Re: Konfigurace DNS seznamu

celé vlákno
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.

Michal Krsek aura:57
12. 7. 2006 9:34 Nový

Re: Konfigurace DNS seznamu

celé vlákno
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 :-)
Petr Souček
Petr Souček (neregistrovaný)
12. 7. 2006 10:54 Nový

Re: Konfigurace DNS seznamu

celé vlákno
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.
J
J (neregistrovaný)
12. 7. 2006 12:52 Nový

Re: Konfigurace DNS seznamu

celé vlákno
Nebylo by nahodou lepsi vracet obe ty IP ? On uz by si to klient nejak prebral.
Michal Krsek aura:57
12. 7. 2006 13:12 Nový

Re: Konfigurace DNS seznamu

celé vlákno
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 :-)
Petr Souček
Petr Souček (neregistrovaný)
11. 7. 2006 19:04 Nový

Pár nejasností k výpadku a zálohování

celé vlákno
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?

Jan Forman
Jan Forman (neregistrovaný)
11. 7. 2006 19:17 Nový

Re: Pár nejasností k výpadku a zálohování

celé vlákno
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ě.
Dan Ohnesorg aura:100
11. 7. 2006 19:59 Nový

Re: Pár nejasností k výpadku a zálohování

celé vlákno
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.
Michal Krsek aura:57
11. 7. 2006 20:05 Nový

Re: Pár nejasností k výpadku a zálohování

celé vlákno
Dosahnete toho jedine, kdyz budete nakupovat fakt velky hosting...
... a nebudete tlacit na cenu :-)
František Ryšánek
František Ryšánek (neregistrovaný)
11. 7. 2006 21:01 Nový

Re: Pár nejasností k výpadku a zálohování

celé vlákno
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.
Jan Forman
Jan Forman (neregistrovaný)
11. 7. 2006 21:23 Nový

Re: Pár nejasností k výpadku a zálohování

celé vlákno
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.
Pavel Janoušek
12. 7. 2006 8:53 Nový

Re: Pár nejasností k výpadku a zálohování

celé vlákno
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...
Martin Kalenda
11. 7. 2006 22:14 Nový

Re: Pár nejasností k výpadku a zálohování

celé vlákno
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.
Pavel Janoušek
12. 7. 2006 8:54 Nový

Re: Pár nejasností k výpadku a zálohování

celé vlákno
V cene vybaveni telehousu urcite, ale zrovna APC bych za SNMP kartu nebo alespon replikator portu pro bezne UPS docela povesil za koule...:-)
Petr Souček
Petr Souček (neregistrovaný)
11. 7. 2006 23:29 Nový

Re: Pár nejasností k výpadku a zálohování

celé vlákno
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
František Ryšánek
František Ryšánek (neregistrovaný)
12. 7. 2006 6:39 Nový

Re: Pár nejasností k výpadku a zálohování

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

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

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

Re: Pár nejasností k výpadku a zálohování

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

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

Nepochybuju, ze je totez mozne u profi HW do racku. Pripadne pripada v uvahu trivialni reseni pomoci stykacu pro jednotlive racky.
JA
JA (neregistrovaný)
11. 7. 2006 23:16 Nový

Re: Pár nejasností k výpadku a zálohování

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

Re: Pár nejasností k výpadku a zálohování

celé vlákno
To že bagrista překopne 22 kv kabel a nevšimne si toho je poměrně nereálné, mohlo by mu být nápadné proč má v lžíci vypálený díry :-D
Pavel Janoušek
12. 7. 2006 8:56 Nový

Re: Pár nejasností k výpadku a zálohování

celé vlákno
To me taky zaujalo... to bagroval za bourky?:-)
JA
JA (neregistrovaný)
11. 7. 2006 23:16 Nový

Re: Pár nejasností k výpadku a zálohování

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

service level agreement

celé vlákno
ad tisková zpráva

„Výše odhadovaných ztrát by mohla dosáhnout řádově jednotek až desítek milionů korun za minutu výpadku, proto je spolehlivé zálohování napájení skutečně nezbytností," vysvětluje Winzberger.

přeji příjemné placení :)
Petr
Petr (neregistrovaný)
12. 7. 2006 6:05 Nový

co tam maji

celé vlákno
zrovna ctu blue rose - firemni casopis IBM a je tu super clanek kde Ludmila Hamplova ze spolecnosti Servodata zpovida Pavla Zimu -tech reditele Seznamu.
Obsah si domyslete sami.
Nemam nic proti IBM, sami je masivne pouzivame, muj zaver je: at vymyslite cokoliv, vzdy se to vyse.e jinde. Toliko mych cca 25 let v IT.
Reverse
Reverse (neregistrovaný)
12. 7. 2006 11:03 Nový

Re: co tam maji

celé vlákno
jo, je to tady ke stazeni. Zipnute PDFko http://www-5.ibm.com/cz/bluerose/download/2_2006.zip
telco.bloguje.cz
telco.bloguje.cz (neregistrovaný)
16. 7. 2006 0:27 Nový

48 V DC

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

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

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

Tak to je rozdíl mezi telco a IT mimo jiné...
uživatel si přál zůstat v anonymitě
26. 7. 2006 0:17 Nový

c

celé vlákno
c
Brumla
Brumla (neregistrovaný)
28. 7. 2006 18:48 Nový

ZTRATA EMAILU??? Seznam.cz

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

Re: ZTRATA EMAILU??? Seznam.cz

celé vlákno
Taky jsem čekal, pak mi je obnovili, ale bez neobnovili složky, adresy, ani filtry. Takže mi všechnu pečlivě roztříděnou poštu nahrnuli do Doručené.
Novák
Novák (neregistrovaný)
12. 8. 2006 23:22 Nový

Víte něco o lumpovi rupert.upert@centrum .cz?

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

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

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

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