Vlákno názorů k článku Casablanca INT druhý den v potížích: po zatopení serverů obnovuje data [AKTUALIZOVÁNO] od Sten - Podle čeho byste to předpokládal? Na webu ani...

Podle čeho byste to předpokládal? Na webu ani ve smlouvě nic takového neuvádějí.

A co kdyz to zacnou tahat vsichni najednou?

nechcete to chápat tak to nechápete. to 1+1=3 je vyjádření že mezi jednou lokalitou a jednou kopií je propastnej rozdíl v dostupnosti ne že to je tři. Porovnejte pravděpodobnost ztráty dat na dběžném disku a ztráty dat na RAID-1. Tj chápejte kontext, prostě nemít žádnou redundanci je naprostej hazar mezi 3-4 kopiemi už není takovej rozdíl jak mezi jednou a dvěma!

Ad lokality, vy tady čtete něco co nikdo nenapsal neprovozujeme cloud jako je BBO nad dvěma fyzickými lokalitami. Tj to co píšete je nesmysl, zálohování není mnoho je to cca 400mb/s kontinuelně IN/OUT tj 800mbit/s per datacentrum. Žádná replikace POLE tam neprobíhá, když už replikují se db/kód a to se bavíme o jednotkách Mb. Jak psal michal udělat distribuovatejnej např iSCSI volume je netriviálni záležitost.

Ad DDoS míří proti dostupnosti služby nikoliv proti ztrátě dat. Tj mluvíte do 100% dostupnosti služby kterou tady ovšem operujete pouze vy (nikdo ani já to netvrdí). Řeč byla o bezpečnosti dat, kde je růst spolehlivosti méně ekonomicky náročnější.

Geograficky systémem více izolovaných nod provozujeme službu coby subdodavatel pro jednu velmi velmi neoblíbenou firmu co podojila stát o pěkných pár miliard, a při 4 bodech se za x let nestalo že i přes DDoS by to nesplnilo parametr 99,9996 dostupnosti.

A ad dostupnost vůbec jsem tady nesledoval smlouvy (nejsem zákazníkem BBO) ale my zákazníkům "nic negarantujeme" pouze je nastaveno 99,9996 garantována dostupnost a v případ nesplnění smluvní pokuta , víc nejde zaplatit žádným SLA víc jde zajistit pouze tím že si těch nod/systémů pro svůj systém nasekáte víc (2,3,4). Tj je to dostupnost apliakce jako celek ne jednotlivých subsystémů. Žádné peníze ani SLA nezajistí totiž ani náznakem vyšší dostupnost s porovnáním se skutečně důslednou analýzou rizik a aplikace.

Problém proč lidi slyší na ty "rádoby cloud" virtualizace jsou jednoduché, uprava apliakce aby běžela třeba z pěti bodů není triviální zvlášt když řada aplikací je buď PHP/MYsql nebo dotnet2/MSSQL. A pak nahrajete na jednom bodu data a oni nejsou okamžitě na jiném. Musí se udělat interní push mechanismus kde soubor nahrajete php do /tmp a nikam ho nepřesouváte ale rovnou cpete do que mechanismu co ho rozdistribuuje (tj taková pseudocdn prostě tam přes api narvete soubor a ono to vrátí že je to OK). to samé cookies, autorizace, ssl, post - jakmile to lidi vidí často na aplikaci ani nesáhnout a chtěj ten "cloud" kde vše zázrakem jede samo a 100% dostupně - jak to dopadá řešíme celej večer tady v diskuzi.

A zcela mimo možnosti j když dotyčným řeknete ať si přes api forkují nody dynamicky, to většinou uplně zabije jejich snahy upravovat aplikaci.

1+1=3? V kontextu keců tady kolem těch garantovaných 100% to působí komicky. Sčítat se učí už na základní škole, ze dvou serverů tři prostě neudělám, i když ten druhý bude u protinožců.

Ve skutečnosti jen další marketingový kec, kterými se zákazníkům vymývá mozek :-) Už se nedivím fakt ničemu. Apropos, jaké že máte kapacity mezi těmi dvěmi lokalitami? A jde o vyhrazené trasy pro potřeby replikace, nebo to honíte po stejných linkách, jako běžnou konektivitu, co se při nějakém DDoSu dají dobře a lacino ucpat? Ono se to pak nabaluje.

pochopitelně, systém má asi 6GB ten se zálohuje zvlášť sice to o 30 minut zdrží obnovu ale zase se to dá verifikovat injectem konfigurace . rozbalíte to automatizovaně vnutíte tomu jinou IP oveříte funkčnost backimportujete data a nepotřebujete nějakou Chaos Monkey .

A hlavně když máte "vlastní řešení" tak vám záleží na tom kolik do toho zákazník sype peněz tak se udělají dvě menší vpsky ve dvou lokalitách (upraví se app aby běžela ze dvou míst buď master slave replikací db nebo se proste ta aplikace upraví, odstraní se server side autorizace aby v případě výpadku nevypadla session a zůstal přihlášenej). A dvě lokality byli problém snad jen v roce 2007 ale brno-praha to řeší elegantně. Poste 1+1=3 přínos dvou datacenter je hyperbolický nikoliv jen lineární.

U záloh v PDS máme funkcni context protector tj pro jeden backup existuje klíč té zálohy (každá vps, každej hosting, každej systém, každá db) má jinej UUID takže ulozistě zajistí, že dnešní záloha bude 99% jinde (v jiném disku jiná noda) než včerejší.

takže pokud zálohujete denně, tak při 30 dnech záloh máte 99,999999999999% (je to 12 devítek) šanci že když nedostanete poslední, tak dostanete předposlední (je jinde) nebo předpředposlední(je jinde než ta předchozí a jinde než ta předtím) tj data nebudou starší než 48 hodin. Samozřejme dva dny jsou nahovno takže šance že dostanete tu poslední je mnohem nižší někde okolo 99,99999% ale můžete ji zvednout počtem kopií kolik si platíte třeba na 10.

a pak je to o nutnosti rychlosti jestli 1x denně full, a hodinove inkrementaci nebo zvolit např pro databázi repliku která je ONLINE a offsite backup pouze pro případ pádu té db softwaerově (pro mysql nic překvapivého)

To ale asi není řeč o snapshotech VMFS filesystému, že? :-)

Pokud očekávám geografické oddělení a dostupnost i při destrukci jedné serverovny, tak se budu ptát, jak to mají vyřešené. To není o nějakém projevu nedůvěry. Jestli nakupujete jen podle toho, co Vám promítnou v televizi, tak upřímnou soustrast :-)

Stačí se po detailních informacích pídit a nespokojit se jen s tím, co se píše na webu a v marketingových papírech, případně řekne obchodník.

jeden nas zakaznik co prisel pri povodnich o dost penez naz doted nuti jednou za cas "na zavolani" obnovit pred nim data v jim dodanem prostoru a sleduje ze jsou ze zaloh tj povoli nam komunikaci pouze do zaloh (dame mu id blobu v zalohach a on je stahne aby se presvedcil ze to netahame z produkcnich masin) a my to musime poskladat.

tj nechapu proc si nekdo proste nenechal jednou za ctvrt roku ty zalohy zpristupnit aby si je poslal. v nasem distribuovanem ulozisti (na zalohy) ma kazdej klient moznost bezplatne vytahat si pres http rozhrani kolik chce zaloh (okamzite) a overit si ze v zaloze je co tam je. obcas to nekdo udela casto sleduji jen velikost te zalohy ale jsou puntickari co to udelaji - a my jsme za to radi, kontrola je dulezita.

Jiste jiste ... pujdu vybagrovat tu pripojku, pripadne si necham rozebrat celou serverovnu, aby se presvedcil, ze to co pisou je ve skutecnosti pravda ... a pak zavolam tomu bagristovi, aby to prekop ... a ja se moh presvedcit o tom, ze to vazne pobezi ....

Boze takovyho kretena potkat ....

Zase předpoklady a nějaká očekávání. Když kupuji jakoukoliv službu, tak si přece ověřím, co si tedy platím, jaké to má parametry a na co mám nárok a nestavím to na nějakých pocitech a doměnkách. Pokud budu chtít robusní službu, kterou nepoloží ani výpadek v jedné lokalitě, budu ji takto poptávat. A ne se pak divit, že něco funguje jinak. To je veřejný projev vlastní blbosti :-)

Samo, bavime se o distribuci technologii tak, aby vypadek jedne lokality nesejmul cely provoz ...

Znam trebas firmy, kde to maji alespon ve 2 ruznych mistnostech na 2 ruznych vetvich rozvodu elektriky. Samo, pokud CEZ odpoji celou ctvrt, tak holt smula, ale to je vzdy o pomeru vynalozenych nakladu vs pripadny skody. Pak znam par firem, ktere proste maji zalozni reseni nekde na pobocce => kdyz chcipne cetrala, tak zajisti alespon nouzovy provoz, byt trebas s omezenym vykonem. A to nejsou zadni giganti, jsou to pidifirmy.

V tomhle pripade bych predpokladal minimalne dve ruzne budovy v ruznych castech mesta. Predpokladam, ze se prsi tim, ze maji 2+ privodu elektriny ... ale na 100% si dovolim tvrdit, ze do baraku vedou stejnou trubkou => pokud bagrista hrabne ... je po privodu.

Dvě (nebo možná i víc) pole to má, ale obě jsou ve stejné serverovně. Tady už jde o obnovu záloh nejspíš z pásek.

vsak prave za to jim zakaznici platili, ale casablanca se zjevne rozhodla, ze bude lepsi, kdyz si ty penize necha na neco jineho, ze to je pro jeji klienty zbytecny prepych :-)

Technologicky je primy spusteni z backupu naprosta trivka ... samo je to otazka vykonu, ale v tomhle pripade bych ocekaval, ze budou mit dve stejna pole (a samo prislusnej dalsi HW), ktery se zrcadlej ... => centralne se to jen shodi, presmeruje a zase nahodi => operace na ... hodinu (nez vse znova nastartuje)?

Navic vmware - pokud by to bylo komplet virtualizovany - toto umi udelat i za pochodu => nikdo z venku si ani nevsimne, ze se neco podelalo.

Navic to neni zadna kosmicky draha technologie, protoze i pro malou firmu je dneska proste uz problem obnovovat TB dat, proste proto, ze to trva.

hromadna je jim jedno, jedine spatne na hromadne je ze poskozeni slozi sily a tudiz daji dohromady presvedcivou argumentaci a podklady.

Vyse skody je stejne smluvni, budou pekne solit ale asi to nebude tak tragicke protoze pojistka pokryje tu skutecnou skodu a na jejich libovuli je zda vam rozdil daji nebo vas nechaji dohanet.

Sam jsem prekvapen kdo je za tuhle legraci zodpovednej. Nicmene ta pole to me fakt prekvapuje ze to neumi jednotlive provisioning pointy tj obnovit to nekam jinam. HP od toho asi da taky ruce pryc prece jenom to asi vsechna technologie umi (hp i vmware) a zbytek je pouze o rozhodnuti ze to bude takto.

hromadne oni nechteji, nejsou hlupaci

Prosíme ty klienty, jichž se situace týká, aby kontaktovali svého obchodníka, a chci je osobně ubezpečit, že jsme připraveni řešit jejich dočasnou ztrátu dat a způsobené provozní problémy vždy individuálně s co nejlepším přístupem

ten kdo ma skodu za par set tisic tak si tezko najme jeste dobreho pravnika na jednani o skode a s tema velkyma uz se nejak dohodnou :-)

Žaloba na Casablancu? Případně hromadná žaloba? Má to šanci?

V podmínkách nejspíše neručí tradičně za nic, ale přesto...