Názory k článku
Amazonu selhává cloud, řada stránek se nenačítá

Snad to na post mortem nebude. Len na anamnezu.

Dejte si svy data do cmoudu, je to daleko spolehlivejsi a bezpecnejsi nez na vlastnim zeleze .... no fakt, nekecam, prece za ty prachy to musej umet lip nez nejakej blbej mistni admin ...

Co bys čekal od j…
I tak je ale trochu blbé že ta jednotlivost toho s sebou vezme opravdu hodně.

služby, které chci ab běžely prostě umístím do více lokalit, tady u Amazonu umřela jedna služba v jedné lokalitě a jde vidět, jak všichni počítají s výpadky...

Amazon a další ač občas nějaký výpadek mají, není to o nic častěji než výpadek jednotlivých DC.... Buď s tím služba počítá nebo nikoliv.

Vypatlancu rádoby architektů je hromada. Něco tak jednoduchého a základního jako rozložení na více lokalit - Amazon dává celkem v tomhle adminum volnou ruku, se mine u většiny adminu, kteří nemají ve vousech zapleteny nudle ale svůj diplom. Protože tyto praktické věci se prostě neuci. Ty si clovek musí dostudovat bokem. Je jedno jestli cmoud nebo necmoud reseni.
Na druhou stranu, většinou zákazníkům dávám sežrat že si nepriplati z geografické zálohy. Samozrejmne v případě výpadku a následného zvedání a prekonfigurace na více lokalit se platí víc než u počátečního setupu nebo plánovaném rozšíření. Ono obnovit třeba pole po záplavě nebo po bombovych útocích jiz nemusí být úplně dobře mozne.

Zatím se jako nejlepší jeví uložit data v jednom čmoudu (levnější ukládání), přechroupávat ve druhým (levnější výpočty) a vizualizovat ve třetím (nejlepší knihovny pro weby). Pak výpadek jednoho poskytovatele nic nerozbije, pokud ovšem zrovna má výpadek jiný...

Tim myslite ztrojnasobit sanci na vypadek? :-O

Vite, my vime, ze tady to oko, na kterem visi cely vytah, se muze rozlomit a zpusobit havarii. Ale tak co, dame tri ta oka za se sebe (kazde od jineho vyrobce), ono to potom vypada tak frikulinsky ;)

hm, pěkná teorie.

Amazon nabízí k storage linku až 40 Gb/s, mezi Amazonem a Google data tečou prakticky 1Gb/s a ještě mě obě strany to nechají pěkně zaplatit. Už při několika PB dat to stoupá do astronomických časů a částek.

Tj, statisticky za posledni rok padly vsechny vetsi cmoudy minimalne jednou prakticky totalne nahubu.

Prakticky provoz na vlastnim zeleze v pripade vypadku znamena nekde splasit nahradni zelezo (hodina) a nekde ho spustit (dalsi) ... jednou za ... 10let ... mozna.

Narozdil od vypadku cmoudu, kde to znamena cekat a doufat ...

Prakticky vlastní železo znamená mít live kopii v jiném datacentru (protože třeba výpadek proudu). Spustit službu na nové mašině totiž jde, ale bez dat. A tohle je především o datech.

Důležitá cloudová služba musí s výpadkem počítat a bežet distribuovaně úplně stejně jako lokální.

To jiste, proto bezne data mizej ... naposled se tu propiral nejakej gitlab ... nebo co treba takovej 100% garantovanej geografickej cluster, kterej sejme kybl vody ...

Kdyz mam data na svym zeleze, tak mam pochopitelne na dalsim svym zeleze i zalohu tech dat (kterou musim mit tak jako tak, pokud se teda s tema datama v cmoudu nechci rozloucit navzdy). A samozrejme, pokud provozuju neco tak zasadniho ze to nesmi padnou ani na minutu, tak budu mit ne 2x, ale 3x vlastni zelezo, a rozhodne ne ve dvou datacentrech v praglu, kde pak padne nahubu rozvodna na chodove a s ni i obe ty datacentra.

Pricemz to v zadnym pripade nebudu provozovat v cmoudu, protoze ten mi bezvypadkovej provoz zajistit neumi, jak je videt dnes a jak se ukazalo uz mockrat.

Máš pravdu pokud ale tím "totálně na hubu" myslíš, že jim odpadla jedna celá lokalita. Jedeme v Amozonu i Google globální projekty na 4+ lokality a všechny výpadky byly do pár minut než se přesměroval provoz na jinou.

No to nevím, kde to vlastní železo máš, jen dojet do DC je často ta hodina, železo sice splašíš třeba cestou nebo ve skladu v DC, ale zajistit el. přípojku do racku, instalace a nahrání dat je otázka minimálně hodin, prakticky to jsou celé dny.

Jak u vlastního železa, tak i u cloudu platí, že pokud chci omezit výpadky, musím mít více lokalit, thaťs all.

" výpadky byly do pár minut"

Tj, treba tomu guuglu to naposled trvalo bezmala 7 tejdnu ... mam to i tipnuty. Z pohledu uzivatelu to bylo nejmin nekolik dnu. A da se doslova rict, ze "internet se posral", prave predevsim kvuli tardum, ktery ani to podelany dns neumej provozovat svoje.

"No to nevím, kde to vlastní železo máš, jen dojet do DC je často ta hodina, železo sice splašíš třeba cestou nebo ve skladu v DC, ale zajistit el. přípojku do racku, instalace a nahrání dat je otázka minimálně hodin, prakticky to jsou celé dny."

Ajaj, další vtipálek. Je rozdíl mezi typem zálohy.
1) Rozložení provozu - část odbavuje jedno DC, část druhý a data se průběžně synchronizují. Pokud jedno klekne, jde provoz na záložní a z pohledu zákazníka se jenom prodlouží doba načítání.
2) Horká záloha - ještě jedna sada železa, který se průběžně krmí daty, ale neinteraguje s klienty. V případě výpadku se dá přepnout do několika sekund.
3) Vlažná záloha. Stroje běží, ale nedodávají data zákazníkům a je potřeba je napřed "nakrmit" daty. To je třeba pokud použiješ jako záskok testovací infrastrukturu a přepnutí trvá pár hodin.
4) Studená záloha. Někde je ready železo, který se nabootuje, updatuje se systém, přetahují se data,...
5) Migrace do jinýho DC, kam musíš dotáhnout železo, zapojit, ...

A ono třeba pokud máš verzi 1) ve třech městech, každý na 50% standardní kapacity a na zbylé kapacitě jede testování, tak výpadek jednoho uzlu nepoznáš. Ale každý si musí spočítat, jestli je levnější den výpadku a ztráta dat, nebo něco takovýho a co se mu vyplatí...

jestli mf nehostuje na amazonu a druha vlna to neodstrelila

one is none - prostě je reálněj fakt že řada firem neumí napsat spolehlivé řešení i když jim dává browser před RR opravdu hodně šancí a nebo mají svoji aplikaci a neumí si napsat routing policy. a když to umí tak to zase nezaplatí. Kdyby to měli alespoň jako cold zálohu a mininstance pro sync funkcionality takt o pak nafouknou a jedou jinde. kdo chce kam