Čekat pět dní na obnovu dat to je neuvěřitelný, nedokážu pochopit, že takhle vychvalovaný a robustní řešení může mít tak zásadní nedostatek. Když bych měl vlastní server, kterej budu zálohovat, tak obnovu dat provedu v řádu hodin. Můžou vychvalovat stoprocentní dostupnost, neomezený výpočetní výkon a nevim co všecko ještě, ale tenhle nedostatek to úplně přebíjí.
A kam ho budete zálohovat, aby i ta záloha přežila takovou vodu? (Primární záloha na diskovém poli ji nepřežila.) A kolik vás takové zálohování bude stát? :-)
Obnovování z pásek není moc rychlé. Na druhou stranu, taky mohli rovnou říct, že to bude několik dní trvat, aby zákazníci mohli nahodit alespoň nouzový web a mail server.
Nevim jak vy, ale lidi v mem okoli si alespon "kriticka" data zalohuji na externi disky - a to se bavime o desktopech. Pokud se budeme bavit o serverch ... sekundarni pole v jine mistnosti, ze ktereho navic mohu primo spustit provoz. Snapy (!!!KONZISTENTNI!!!) to dela (dle konfigurace) klidne kazdou minutu, ale je to zbytecny, nastaveno je 15. Jinak je to CDP, takze nekonzistetni data lze vysat z libovolnyho casovyho okamziku. A pokud se bavime o cene, tak se pohybujem lehce v M.
Tohle HP nebo Casablanca neumi ani za (minimalne) desitky mega???
Podotykam, ze provoz ze zalohy mam i na vlastni kuzi overeny, spusteni trvalo cca 10 minut, a to proto, ze sem si radsi vsechno kontroloval 5x, protoze sem to delal poprve. Zadny problem, o vikendu sem jednoduse povypinal servery, prekopiroval aktualni data a vratil provoz na puvodni pole (zalozni je ponekud pomalejsi). Ale nebyl by problem mit dve zcela totozna pole. Dokonce neni zadny problem pouzivat obe pole zaroven ... rozlozit na ne zatez, a v pripade vypadku jen prevest docasne kompletni provoz na jedno.
Jestli jste si nevšimnul, tak problémem není absence dat jako takových, ale rychlost, jakou obnova probíhá. A asi jste si také nevšimnul, že se zde nebavíme o dvou serverech. Provozovat větší cluster s geografickou redundancí taková sranda také už není, jak se rádoby-odborníkům se dvěma servery na stole zdá :-)
nemáte pravdu, píšou o 100TB to jest bratru 40kkč měsíčně při tom kdyby to byl denně 1/5 flow (tj 20TB denně) (tj že by aktuální zálohy delali každou hodinu a např ty starší by mazali po 48 hodinách tak že by nechali vždy jen jednu ze dne tj by bylo např 24 záloh (inkrementů) po dobu 2-3 dnů (kvůli víkendu) a např 28 záloh po dnech.
Mj měl jsem za to že zálohovali pro sebe právě pro případ jako je tento aby data dokázala vrátit, diletantství některých zákazníků co svěřili zálohu jen case nepotřebuej komentář měli jsme několik větších objednávek (5k měsíčně víc) na virtuály a všichni svorně tvrdili že čekají až jim casa vydá data. a to to byli lidi s 50Gb dat tj 20-100kč měsíčně za backup
Obnovit data z disku jednoho serveru bude časově asi jinak náročné, než obnova nám neznámého a zřejmě asi ne zrovna malého počtu disků v té virtualizační platformě. Když těch serverů budete mít pětset, asi to taky nebudete mít zprovozněné vše za pár hodin. Je neuvěřitelné, jak dalece lidé nedokážou používat hlavu a myslet :-)
Já to beru ze svýho pohledu zákazníka. Pro mě je obnovení mýho jednoho serveru rychlovka v porovnání s tim jak dlouho musim čekat než se dočkam obnovy u Big Blue One. Čekal bych, že takhle vychvalovaná technologie to bude umět o dost rychleji. Takže když budou mít dvakrát víc zákazníků a dvakrát víc dat, tak místo 5 dní budu čekat 10 dní? A to že tisíc serverů bych obnovoval pomaleji to mě nijak neuklidní, protože já mam jenom jeden server a ten obnovim v řádu hodin a nemusim na to čekat 5 dní ani 10 dní.
Každá technologie má své výhody i nevýhody. Lidé rádi vnímají jen ty výhody, ale často zapomínají na nevýhody a rizika, které to může přinést. Samotná volba mezi vlastním fyzickým serverem a serverem virtuálním je čistě na zákazníkovi. Práce s velkým objemem dat nějaký čas prostě zabere a je dost naivní myslet si něco jiného.
Že musim měnit olej, dofukovat kola takové informace bych čekal v návodu v obsluze, nikoliv v marketingových materiálech. Ale to, že budu čekat pět dní na výměnu prasklé žárovky u předního světla (a nebo 10 dní pokud si auto v daném roce místo 10.000 lidí koupilo 20.000 lidí), to už je důležitá informace, která by měla být v marketingových materiálech, protože podstatně ovlivňuje moje rozhodnutí při výběru nového auta.
Oni do marketingových materiálů fakt nenapíšou, že kvůli žárovce musíte do servisu, jelikož její výměna je složitá operace, kterou amatér bez potřebného speciálního vybavení sám nezvládne a rozebere se kvůli tomu půl auta :-) Ano, i taková auta na trhu jsou a do marketingových materiálů to nenapíšou.
Účelem marketingového materiálu je produkt vychválit, ne upozorňovat na problémy. Spousta lidí to očividně má problém pochopit :-)
Zákazník podepsal a platí garanci 100% dostupnosti služby za jakékoliv situace - včetně živelné pohromy? To asi ne, co? Ano, jeho aplikace neběží, ale ve smlouvě je jasně upozorněn, že existují nějaké situace, kdy něco takového nastat může. Jestli si to pořádně při podpisu nepřečetl, tak je pitomec :-)
Pokud se bavime o tom blbovi o post vejs, tak vyplaveni z vodovodu neni zivelna pohroma ani ve snu. Dokonce ani vyplaveni od deste deravou strechou neni zivelna pohroma a zadna pojistovna na to v tomto rezimu plneni neposkytne.
Ostatne, kazda normalni domacnost se pojistuje prave na vyplaveni ... sousedu, prave vodou z vodovodu. Tudiz kazdy i hodne podprumerne inteligentni ovcan predpoklada, ze se to stat muze (a taky se to celkem bezne deje).
Takze si dovolim tvrdit, ze na toto se 100% garance vztahuje (leda by jeste mohli tvrdit, ze slo o ohalseny vypadek ...). Jeste zajimavejsi to pak bude s temi, kterym znicili jejich HW ... specielne v ripade, ze k jeho zniceni doslo uz ve chvili, kdy se o vode vedelo ... a bylo zapricineno tim, ze to nechali pod proudem.
To kdo a kde pustil nejakou vodu je uplne jedno. Jedine co je dulezite pro posouzeni jestli podle tech vop za to casa zodpovida, je jakym zpusobem ma zajistene ,aby technicka zavada nekde v objektu kam sve zarizeni umistila nenarusila chod toho zarizeni. A to nema nebo ma spatna opatreni. Proste - kde bude zarizeni provozovat, je jeji rozhodnuti a pokud se objekt rozhodla sdilet s jinymi subjekty, pak ho sdili i s riziky s tim spojenymi. Je to jako bydlet v panelaku, nebo rd. Kdo jde do panelaku, musi pocitat s tim, ze dum sdili s dalsimi obyvateli a jejich chyby a nehody proste budou ovlivnovat i bydleni jeho samotneho.
Presne ... kdo bydli pod strechou, pocita s tim, ze strecha muze protekat, kdo bydli niz, pocita s tim, ze jej lide nad nim mohou vytopit. Ti lide proti tomu budou pojisteni, ale pokud ma dotycny doma neco, na cem voda zpusobi skody za desitky ci stovky mega ... tak to pujde za nim, protoze to nema nalezite zajisteno.
1200TB distribuovaného uložiště nás stálo asi 2,8M investičně, dál 900 tisíc na vývoji provozne je to měsíčně asi za 160 tisíc korun za hw a asi 35 interně za rozvoj a udržbu. Pokud by to nepoložilo poskytovatele tak to těch 800gb/s dá. Bohužel se předpokládá geolokace takže to dá 40 protože by to nedali uplinky žádného z dc.
takže problém bude že se replikovalo z pole na pole a ne virtuál pro virtuálu. to by aspoň mohli dát img zákazníkům ať si to pustí jinde - jenže to by byla smrt.
Musí teď jednat chladnokrevně když data pustí ven a neprovedou zdlouhavou replikaci tak přijdou o většinu zákazníků - takto bude výpadek a po výpadku to pojede to už bude fuk jestli to pojede od casa nebo jinde. A na to sází. JIné vysvětlení nemám, my máme totální kolaps firmy vyřešen tak, že prostě 100% dat jsme schopni zákazníkům vydat do 5ti minut (začít jistě to nekde stáhnout naráz) říci sorry padl na 5 Dc z šesti co používáme meteorit (nebo 3 meteority a dva boeingy podle chuti) a my nemáme jedinej server. Data máte k dispozici OKAMZITE tady, přejeme hodne štěstí u konkurence.
ťuk ťuk, snad se to nikdy nestane.
Přečtěte si prosím nač o reagujete smrt 5/6 serveru je fuč 87% výpočetního výkonu.
Pro tyto situace skutečně nemáme plnou 1:1 redundanci, nedí důvod máme jeden záložní asi na 13-17 serverů (bere se to tak že těch top serverů je méně protože záloha by měla dokázat poskytnout stejný né-li větší výkon) Tj bez problému ustojíme ztrátu tak 7-10 racků tj do 200 serverů.
Jenže něco je to technicky ustát a něco je obratem zaplatit za 200 serverů 18-25M korun a pak doufat že to pojišťovna zaplatí.
Plán B je ovšem mít DATA a SYSTEMY i systém a kdyby se stalo (ťuk ťuk) tak prostě nakoupíte ty systémové zdroje jinde a vyjde vás to levněji než se na to zajišťovat hardwarem. U Amazonu a v MS máte 200 serverů naklikáno za dvě a půl hodiny. Stát vás to bude pár set dolarů za hodinu a to na ty dva dny dáte. Nelhledě na to že v čechách vám rád ledaskdo pomůže ať hw nebo vám nakliká vps které budou sice výrazně pomalejší než ty produkční ale pořád je to lepší než když to stojí.
Takže kdyby bylo fakt začně se čistit zálohování třeba do S3/Glacieru nebo se prostě zastaví zálohování a nasypou se data na ty cpu boxy pro zálohování a pustí se to na tom.
Pokud resim skutecne vysokou dostupnost a 87% vykonu mam na jednom miste, tak je asi neco spatne :-) Ekonomickym aspektum rozumim. Vy se rozhodujete o tom, ze mate jeden zalozni server na buhvikolik produkcnich. Ale k podobnym kompromisum dochazi vsude kolem nas :-)
Amazon se jako priklad pouziva casto, ale i ten vypadky postihly. A bud zakaznici o data prisli uplne, nebo cekali nekolik dni, nez je budou mit zpet. Ale to bud nevite, nebo to nevnimate. Lide si spojili pojem cloud s tim, ze jejich data jsou automaticky na nekolika mistech. Jenze to je moznost, kterou cloudova reseni nabizi - nikoliv automaticka vlastnost. A to je dost podstatny rozdil :-)
Read it again - píšu že kdyby na 5 míst ze 6 it (geolokace, byť třeba praha - praha) spadne meteorit (tj na 5 míst současně) tak to prostě nejde dělat. Stejně tak o těch serverech, 1/13-15 je počet volných prázdných serverů kde NIC není čekají na smrt jiného. Raději to budu stavět na SM než na IBM a budu mít poměr 1/13 než s IBM 1/35.
Na 100% redundanci to nejde nadesignovat vždy existuje pravděpodobnost a hypotetická šance že se něco pokazí. Proto jsem psal že exitová strategie koupit výkon jinde (tj mít data tak backup systému a konfigurace) je ekonomicky opodstatněná (jinak by muselo být poměr serverů třeba 1/4 - 1/2)