Vlákno názorů k článku Odpovědi na nejčastější dotazy k našemu odchodu z předraženého cloudu od Josef Marianek - Jde taky o to na co mate lidi,...
-
Josef MarianekBronzový podporovatelJde taky o to na co mate lidi, HW potrebuje peci spravcu, na SW staci vyvojari.
-
BuldrZlatý podporovatelJak se spravuje tisíce kusů serverů, switchů, diskových polí si komentovat nedovolím, protože to je mimo můj obor a prakticky o tom nic nevím. Údržbu zázemí (rozvodná síť, požární zabezpečení, záložní zdroje, …) si umím představit více než dobře. Nepřísluší mi diskutovat o něčem, čemu nerozumím a neznám realitu praxe.
Rozumím myšlence, ale přesto formulace působí nešťastně. Přece jen se mi příčí nechat vývojáře SW spravovat i servery např.: Exchange, ADDS, DB … tedy dělit práci mezi lidi s různými znalostmi a to budete dělat tak jako tak, bez ohledu jestli máte HW pod vlastní střechou, v datovém centru, nebo u poskytovatele cloudu.
V malém měřítku si také raději zaplatíte schopného správce (firmu), který se vám o to postará, protože není vždy oboustranně efektivní platit schopného člověka na plný úvazek. Drahé a kousal by se třeba nudou. Stejně tak si můžete zaplatit jednorázovou, nebo paušální službu lidí, kteří se fyzicky o ten HW postarají v případě problémů.
Nabídky „s neskutečnými výhodami“ přejít do cloudu pro malé firmy, nereálně nízkými náklady, přicházejí neustále a když si to spočítám, vždy se dopočítám, dostávám se k trojnásobku. Jednou za 5-6 let koupím potřebný počet fyzických serverů (psal jsem v malém, tak se nesmějte), náklady na správu, licence, úpravy mi zůstanou tak jako tak a nic dalšího kromě energií a připojení neplatím, protože zázemí už mám vybudované. Z cloudu se podle mého názoru stalo módní slovy a při těch nabídkách to budí dojem, že firma, která není v cloudu patří do historie a neexistuje. Nějak mi přijde, že Cloud se bere jako všespásné řešení, přitom to není pravda.
4. 1. 2024, 12:50 editováno autorem komentáře
-
kdykoliv necháš dělat někoho, kdo to neumí, koleduješ si o problém.
Nedávno nám v jednom datacentru v asii vyhořely primární UPS, pár zahořelých vedení, nic velkého, ale spustila se tím velká kaskáda problémů, která vedla k odstávce celého DC. A tady se ukázala slabina vlastního HW, obejít tisíce serverů dělalo těch pár lokálních adminů skoro dva týdny. V cloudu tohle jsme schopní naškálovat v podstatě hned.
Znáš to asi sám, jak musíš něco udělat fyzicky, tak se to strašně blbě škáluje a automatizuje, ale zase máš čas u toho přemýšlet a kontrolovat se.
Na druhou stranu to špatné škálování a automatizování má své výhody, pokud udělám botu, chvilku trvá než jí fyzicky udělám všude a je čas si toho všimnout a zachránit to. Pokud při správně cloudu udělám botu, velkou botu, mám minimum času na záchranu a důsledky jsou fatální.
-
BuldrZlatý podporovatel
Bez důkladné a pečlivé kontroly nikdy nezjistíš, s jakými následky se potýkáš v případě závažné poruchy silových rozvodů. Nakonec ty skříně musíš otevřít a podívat se dovnitř.
-
BuldrZlatý podporovatel
To netuším, protože nemám sebemenší představu, jak to měli vyřešené, nevíme ani co hořelo. Psal baterie což je stejná informace, jako škrtnul sirkou a ona možná propálila koberec a zhasla, nebo podpálila celý barák. I když tak nějak nepřímo říká, že tam toho bylo více, protože odstavit celé DC bez důvodu? To asi ne, i když se třeba přímo netýká provozovaných serverů. Třeba v drátech lítalo deformované napětí, že to vymlátilo půl serverovny, nebo jen praskla signalizační pojistka vypínače uvnitř skříně, která sice nemá přímý vliv, ale vyměnit se musí. Nevím a domýšlet, nebo si představovat scénáře nebudu, proto mohu poskytnout pouze obecnou odpověď a ta nebude k ničemu, respektive na Tvou otázku neodpoví. Vlastně psal, že hořelo v Asii a v určitých oblastech se hodně používají asynchronní motory i pro menší ventilátory, tedy pokud jsem se trefil do oblasti a použití, tak bych šel asi ihned po kontrole jištění po asynchronních motorech, který bytostně nesnáší i krátkodobé podpětí. Ne všude používají stejné postupy a řešení, jako v našich končinách.
Těžko se odpovídá – zabývám se elektrikou, přirozeně mi projelo hlavou x scénářů s elektrikou. Třeba za prolézáním stoji přepečlivý japonský přístup, indický fištrón, či cokoliv jiného.
-
"protože odstavit celé DC bez důvodu"
Typnul bych ze to okourilo kabelaz, ktera to asi podle popisu prezila, ale izolace byla nejspis narusena. No a ty privodni kabely se za provozu moc vymenovat nedaji, specielne kdyz nevis, jestli druha vetev pripadne zvysenou zatez prezije, nebo shori uplne.
Ale presne stejnej problem bys mel v cmoudu, pokud by museli odstavit cely DC.
-
ale stejně to musíš opravit a vyřešit, samozřejmě DR lokalita je, přeplo se během pár minut a provoz se přesměroval, proto se to mohlo řešit týdny a v klidu.
Vtipné je, že vlastně v tomhle prostředí (pobřeží Indického oceánu - Srí lanka, Větnam, Thajsko, Kambodža atd.) není záchrana ani cloud, protože těch DC tam je strašně málo, konektivita mezi nimi je žalostná, ceny vysoké a při výpadku nějakého AZ jsi často stejně out, ten provoz z jiné lokality má úzké hrdlo a ucpe se. Tady není ani cloud řešením.
-
malý požár způsobil zapnutí požárního systému v celém sále, ten způsobil masivní podtlak, spousta serverů a aktivních prvků to neunesla a přestaly reagovat (plotnové disky to nemají rádi), odpadly i věci jako vzdálená správa, musel se každý server obejít, vypnout zapnout, zkontrolovat, vyměnit porouchané disky.
Všechny ty automatizace a monitoring systémy fungují dobře, pokud vypadne jen něco málo, když se ale sesype celá lokalita, bez ruční práce se neobejdeš, zprvu totiž nemáš vůbec informace, co vlastně nefunguje a co se stalo.
-
BuldrZlatý podporovatel
Už z původního popisu jsem tak nějak čekal poškození v bateriové místnosti a problém s rozvody, ale nečekal bych, že dojde k aktivaci hasícího systému i v dalších prostorách a už vůbec ne, že aktivace hasícího systému zničí disky. To jsem netušil, řekl bych spíš poškozené/zničené 10-15k rpm fany, které v těch serverech jsou, ale disky ne.
-
ano, ano, bateriová místnost a zahořelo pár kabelů, bohužel zrovna hned u detektoru kouře, takže vesda nestačila zareagovat včasným varováním a rovnou se spustil alarm na "požár velkého rozsahu", obsluha spustila první úroveň ochrany, budova se evakuovala, uzavřela, klimatizace se vypnula a prostory se začaly plnit inertním plynem (inergen), právě vč. sálu. Tenhle proces ale dočasně způsobil vysoký podklad v sále.
Klasický plotnový disk má propustnou membránu a není hermeticky uzavřený, výrazně změna okolního tlaku může způsobit jeho různé poruchy a nouzové odstavení (to už teď znám na vlastní kůži). Část disků stačilo odpojit a připojit (hard restart serveru nestačil), část ale zůstala nefunkčních a vyměnily se. Heliové disky (zpravidla 8TB+) to přežily bez problémů, kvůli heliu musejí být velice pečlivě uzavřeny.
-
"Opravdu šlo o podtlak? Ne"
Tak jako tak si nedovedu predstavit, jak bys vygenerovat takovy rozdil tlaku, aby si toho cokoli vubec vsimlo. Na to bys totiz musel mit velice tezka vrata na vstupech, hermiticke uzavery, a predevsim velice vykone kompresory. Rozhodne na to nestaci vypusteni plynu ... plynove haseni je navic vylozene navrzeno tak, aby nic neposkodilo.
-
ne, šlo o podtlak.
Před vpuštěním plynu (myslím, že tam mají argonit) se vypne klimatizace. Nejprve se vypnulo nasávání na vstupu a vhánění vzduchu a až posléze se vypíná odsávání. Tady nejspíš nastal problém, časová prodleva byla asi příliš velká a klimatizace vytvořila podtlak ještě dříve než se tam začal vhánět plyn. Pokud necháš zapnutou klimatizaci a vženeš tam hasící plyn, klimatizace ti ho zase velice rychle odventiluje.
Problém je, že hodně těch věcí se "testuje" pouze teoreticky, ty nové HDD jsou očividně dost náchylné na vnější tlak, to dřív nebývalo, provozovali jsme dříve HDD vyloženě v podtlaku (to byla velikost ještě v stovkách MB). Nebo kdo kdy v DC testoval end-to-end celý proces řešení požárů? Vidím, že se zkouší agregátory, zkouší se jednotlivé části samostatně, ale že by někdo udělal tenhle proces se zapnutými servery v provozu? To jsem ještě nikdy nezažil, vždy ty testy jsou určitým způsobem umělé a zpřizpůsobené, tady nám během okamžiku lehlo několik stovek serverů, přitom DC TIER 3 (teda marketingově 3.5).
Věnuji se primárně tomu, co se v DC provozuje a nikoliv samotným DC, neznám přesně veškeré detaily.
-
Ono je to cele jeste trochu slozitejsi, ten plyn je v tlakovych nadobach = hodne stlaceny. Takze kdyz ho vypustite do datacentra, tak dojde k jeho expanzi a tim prudkemu ochlazeni celeho prostoru a tim zase zpetne k poklesu tlaku, protoze logicky chladnejsi plyn ma pri stejnem objemu mistnosti nizsi tlak. Takze tam dochazi k razovym vlnam. Pripadne muze dojit dokonce k namraze.
Navic ty disky typicky odchazely kvuli vibracim, proto se datacentra predelavala na tzv. tiche trysky. Protoze ty klasicke pro prumysl maji ostre hrany a ten plyn pri tak vysokem tlaku generuje obrovsky hluk na nizkych frekvencich a dokaze rozvibrovat cele racky a hlavicky pak narazi do ploten. I to uvidite v nabidkach, kdyz se datacentrum chce pochvalit, ze uz pro haseni maji tiche trysky.
Ten plyn musi byt vyfouknut behem 10s aby ucinkoval, takze se v trubkach uz pohybuje nadzvukuvou rychlosti.
-
pokles tlaku kvůli ochlazení je také jedna z hypotéz, kterou tam kluci řeší, ale je to daleko, nemám tam přímý přístup a řeším jen provoz toho HW v pronajatém DC a nikoliv DC samotné.
Tiché trysky snad mají dneska už všude, bez toho to je taková malé zemětřesení.
Ano, těch vysokotlakých lahví tam je celý sklad, jedna dávka výjde asi na 100k EUR a celé se to plynem naplňuje hodně rychle. Ano, tlak se mohl měnit ve vlnách, máme informaci pouze s jednoho barometru a nikoliv nějakou tlakovou mapu v jednotlivých uličkách.
Informace o vypadnutí disků kvůli podtlaku mám od lokálních adminů, kteří servery fyzicky obcházeli a řešili.
-
Filip JirsákStříbrný podporovatelNebo kdo kdy v DC testoval end-to-end celý proces řešení požárů?
Před dvěma roky to testovalo OVH ;-) -
Filip JirsákStříbrný podporovatel
Kdyby vám dali vědět dopředu, mohl byste se připravit a nebyl by to dostatečně věrohodný test :-) Ale pokud vím, ještě pořád nikdo nedělá monkey testing na datová centra, že by každý týden zkusili něco náhodně v datacentru podpálit a sledovali by, co se stane…
-
Kdezto v Google cloudu jsou data v suchu a bezpeci. Oh wait..
https://www.datacenterdynamics.com/en/news/water-leak-at-paris-global-switch-data-center-causes-fire-leads-to-outages-at-google/ -
Jo jasne. Mam zkusenosti ze vyvojari obvykle nerozumi moc sitim a ani tomu jak vystavit vyssi funkcni prvky proti nespolehlivosti infrastruktury. Naproti tomu docela dobre se vedou embedaci a neni treba je az tolik usmernovat. Idealni je proste mezoborova spoluprace s asistenci architektu.
Infrastrukturu postavenou developery jsem takhle do funkcniho udrzovatelne stavu dostaval po kouskach 5 let. Nejhorsi jsou ty diskuse kdy devel si mysli ze si zvoli treba libovolnou ip adresu v libovolne siti a UDP paket vzdy musi pres internet dojit. Idealne do par ms. Nebo ze bude admin na deployment studovat zdrojak aby vedel kde co nastavit. Pripadne ze prenaset data nesifrovane je preci normalni :-/
-
A presne toto je nesmysl, ktery vyvraci prave mimo jine tenhle clanecek.
HW zadnou spravu nepotrebuje, tech clovekohodin je naproste minimum a mozna kdyz je toho HW za 600k dolaru, tak to stoji za hovor, ale to uz je opravdu velka hromada HW.
Ten HW musi nekdo nainstalovat a zprovoznit. To je vse. Kdyz strelim ze za 600k to bude rekneme 60ks zeleza, tak to obnasi mozna sakumprask 200 clovekohodin prace. Jednou za 5 let. Radove vic casu bude trvat na tom zprovoznit SW. A ten se musi zprovoznit a udrzovat i na tom cmoudu ze?
"na SW staci vyvojari."
Jiste, a pak to vypada tak, ze vsichni vsude maji roota, a pod rootem i vsechno bezi. Videl sem, a ne jednou.
