"Megsült tárolók miatt hasalt el az Azure"

Microsoft, Windows

"Masszív, egy napot is meghaladó leállást okozott egy vihar a Microsoft Azure szolgáltatásában. A vállalat most publikálta az ok-okozatot feltáró post mortem jelentését. [...] Az igazi problémát a hűtőrendszer leállása okozta, amely a védelem ellenére túláramot kapott és lekapcsolt. Erre az esetre felkészülve az adatközpont rendelkezik bizonyos hőpufferrel, vagyis bizonyos ideig tudta tartani a biztonságos működési hőmérsékletet, ez lehetőséget biztosít, hogy bizonyos hőmérsékleti küszöbértéket meghaladva a rendszer rendezett leállást tudjon eszközölni. Ebben az esetben azonban a puffer annyira gyorsan fogyott el, hogy nem volt idő a leállást végrehajtani. Ennek következtében "jelentős számú" tárolószerver károsodott, kis számú hálózati egységgel és tápegységgel együtt. A Microsoft beszámolója szerint a helyszíni üzemeltető csapat több lépést is tett a károk megakadályozására, például a teljes adatközpontot generátorra állították át."

A teljes cikk itt olvasható.

( trey | 2018. 09. 11., k – 18:50 )

Elolvasva a jelentést, ezek azok a hibák, amik miatt felhőbe migrálnék, remélve, hogy ott ilyenek az üzemeltetésre jutó "végtelen" pénz miatt nem jönnek elő soha.

Erre tessék.

--
trey @ gépház

Magyarul nem volt vele tervezve. Még mérnöknek sem kell lenni ahhoz, hogy az "előfordulható maximális terhelés + ráhagyás"-ra méretezünk.

A puffer (jelentsen ez bármit is) ha gyorsabban fogyott mint tervezték, akkor alul tervezték.

A rendszernek még azelőtt le kellett volna állnia rendben, mielőtt megfő minden.

--
trey @ gépház

Rájöttem, hogy mi lehetett a puffer:

Van egy bazi nagy hűtőjük, amiben jégtömböket tartanak. A klíma leállása esetén kinyitják a hűtő ajtaját, és a jégtömbök olvadása biztosítja a hőelvonást. A baj abból származott, hogy a hűtőt XT-kkel telerakott szerverszobára méretezték, és amikor ezeket kicserélték modernebb gépekre, akkor elfelejtették a hűtőt „upgrade”-elni. Így aztán nem csoda, hogy gyorsabban emelkedett a hőmérséklet, mint azt 35 évvel ezelőtt kiszámolták.

Van az a szint, amire nem lehet sehogy sem felkészülni, és ez még csak nem is a pénzen múlik.
Be kell látni, hogy a digitálisan tárolt adat -mint egyébként úgy általában MINDEN adat, analóg is- veszélyben van, bármikor elveszhet örökre.
Mint az ókorban, amikor leégett az alexandriai könyvtár, és az emberiség akkori össztudása majdnem teljesen, örökre elveszett. Sosem tudjuk meg, mit tudtak az akkori emberek, amiket mi már nem tudunk - függetlenül attól, hogy csomó mindent meg már jobban tudunk.

--
robyboy

Azért álljunk meg, kit érdekel, hogy megsült-e tároló? Majd vesznek másikat, aprópénz. A lényeg, hogy zéró adat veszett el.

Az egész dilemma arról szólt, hogy vagy azonnal átállnak egy távoli replikára, de az aszinkron replikáció miatt az minimális adatvesztéssel jár, vagy inkább állnak szolgáltatások egy napig, de egyetlen bit sem veszik el. Utóbbit választották.

És usereknél pedig megint előjött, hogy akkor drága-e a DR. Aki rendesen megcsinálta (és kifizette...) a georedunanciát, annak nem volt kiesése a saját szolgáltatásában, hiába a US south-on ment a rendszere, simán átállt másik datacenterre és ment tovább.

"Azért álljunk meg, kit érdekel, hogy megsült-e tároló? Majd vesznek másikat, aprópénz. A lényeg, hogy zéró adat veszett el."

Valamilyen szinten kiállít egy bizonyítványt tervezésről. Értem én, hogy te most más szemmel nézed, de ne kelljen már tapsikolni azért, hogy az adatok megmaradtak.

--
trey @ gépház

Tapsikolni nem kell, de amibe itt bele lehet kötni az a leállás. Nem tudták hozni a vállalt rendelkezésre állást, de az adatbiztonság valóban nem sérült.

Más részről ahhoz pedig, hogy az adatközpontokban hogyan esnek-kelnek a hardware elemek, úgy gondolom, neked mint felhasználónak nem sok közöd van. Nem is tudom talán Facebook vagy Google adatparkról olvastam, hogy óránként(!) mennek tönkre diszkek pusztán a mennyiségből kifolyólag. Nem is cserélik őket egyesével, mert a szükséges redundanciához nincs ennyire szükség. Ha már beszart legalább 100 db, akkor cserélik egyben, oszt ennyi.

Igen, kiállít. Mindig van némi esély üzemzavarra, akár emberi, akár technikai hiba miatt is. S, ilyen szituációban elfogadhatóan vizsgáznak.

A különbség az, hogy ha egy ilyen krahh beüt, akkor azok az okoskodó cégek, akik jellemzően 0 vagy 100% rendelkezésre állással tudnak csak üzemelni, na azok ilyenkor teljes adat és hardver megsemmisülést élnek meg. A nímand cégüket megszüntetik jogutód nélkül, az ügyfeleik kenhetik a hajukra. Majd egy hét múlva a lenyúlt előfizetési díjakból indítanak egy hasonló nímand céget, amí egészen addig 100%-os rendelkezésre állással üzemel, míg ködbe nem megy megint.

Van az a cégméret vagy jogi, technikai helyzet, amikor megéri saját szervereket üzemeltetni. Kisebb cégeknél, ahogy csak a szerver megvételének árával számolnak és az üzemeltetés és a redundancia meg eszükbe sem jut, na ott szokott menni a nagy mellényű okoskodás, hogy a felhő a bolondoknak való. Közben meg csak szerencselovagok. De mindenkinek elfogy egyszer a szerencséje.

Egyébként eddig a hírekből úgy tűnik nekem, hogy valamivel jobban megy ez az amazonnak. Legalábbis náluk sok egymásutáni áramszünet és több államot érintő szükségállapotot okozó hurrikán kapcsán volt anno probléma. Persze náluk meg máskor meg az egyik alkalmazottjuk emberi hibája okozott necces helyzetet.

Összekevered az üzemzavart az alulméretezéssel.

Pontosan abból adódott itt a leállás, hogy elkövették azt a hibát, amit mondjuk egy amatőr által tákolt sufninál el lehet. Telezsúfoltak egy helyiséget annyi szerverrel, hogy az üzemzavar felléptekor nem volt elég idejük a szakszerű leállításra. Ez semmivel sem különb, mint ha fogok egy helyiséget, telerakom faszig, teszek rá egy darab klímát, aztán ha az megdöglik, akkor megfő minden.

--
trey @ gépház

Tökéletesen összefoglaltad.

Megspékelve azzal, hogy a monitorozó rendszer is odaveszett mielőtt riasztást tudott volna küldeni ("A legcifrább, hogy a VSTS státuszoldala, amelyen követni lehetett a szolgáltatás minőségét, nem tudott frissülni, mivel az ehhez szükséges adatok és az állapotfrissítéshez szükséges eszközök az érintett adatközpontban futottak."; ilyen jellegű problémák már korábban is voltak emlékeim szerint) Ilyen helyen nincs egy szolgáltatás-függőségi gráf?

Engem meglep, hogy most szembesülnek ilyen kérdésekkel/problémákkal: "Given all of the above, I still need to address the question of when I would fail over to another region if there is data loss. I fundamentally do not want to decide for customers whether or not to accept data loss. I’ve had customers tell me they would take data loss to get a large team productive again quickly, and other customers have told me they do not want any data loss and would wait on recovery for however long that took."

Érdemes elolvasni a "Service startup issue:" részt is (https://azure.microsoft.com/en-us/status/history/).

Sok szempontból tanulságos eset. Kíváncsi lennék, hogy a versenytársaknál mi mozdul meg ennek hatására, hányan csapnak a homlokukra.

Lehetne azt is nezni, hogy ha jol ertem UTC 8:42-kor volt villamcsapas ami okozta a klima hibajat is (bar arrol nem irnak hogy azonnal-e) majd 9:29-kor kezdtek leallni a gepek tulmelegedes miatt.
Ezt nezve mondjuk negyed ora utan jutottak el addig hogy klima megallt es jo esellyel fel fognak melegedni a gepek akkor volt szuk fel orajuk merlegelni amennyi ido alatt azert aszinkron replika hianyzo reszet at lehetett volna masolni masik site-ra ha ugy dontenek hogy ne legyen adatvesztes (mikozben elesbe leallitjak az iras muveleteket vagy teljesen es replikalas szinkronba hozasara fokuszalnak).
Persze ha ugy van tervezve az asszinkron replika tobb oras vagy nagyobb lemaradast is jelenthet naluk vagy a klima megallas joval kesobb tortent es valojaban nem volt 10 perc se klima megallas es tulmelegedes miatti gepek leallasa kozott (ami azert tenyleg nagyon keves puffert jelenthet) akkor nemigen volt erre se idejuk/lehetoseguk.

640KiloByte és utólag megcáfolta Vili, hogy ő nem is mondott ilyet. Amúgy meg volt az oka, hogy miért annyi, mert többet csak trükközéssel kezelt a DOS meg a 8086 ( pontosabban a 8088) (tudom, 1 megát kezelt, de le voltak foglalva egyes tartományok mindenféle okosságokra)

A kérdés nem ilyen egyszerű. Nem mindegy, hogy szalmabálákat akarsz megvédeni, vagy egy rohadt érzékeny áramkör kupacot.

De elvileg különböző védelmi technikák kombinálásával igenis meggátolható a kósza elektronok pusztítása. Csak pénz, és elszántság kérdése.

Szerintem most lefog írni pármillió dollárt a közösből a vezetőség, hogy pótolja az "á ide úgyse fog beütni soha a büdös életbe" miatt kispórolt megoldásokat.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Magát az adatot azért nagy balf.szság elveszteni 2018ban. Számtalan eszköz és módszer van rá. Az hogy a szolgáltatásom csökkentett módba vagy offline megy, egy dolog, ha emberi időben vissza tudok állni.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Az összeset elvesziteni balf.szság. De katasztrófa előtti utolsó 3 percnyi adatot elvesziteni már nem az, sőt igen nehéz biztositani, hogy ne történjen meg. (szinkron replika egy másik kontinensre technikailag megoldható, gyakorlatban viszont használhatatlan lassúvá tenné az éles rendszert)

Az adatmentés egyetlen működő módszere, ha az adatok folyamatosan másolva vannak. A másolás közben is történhet katasztrófa, de ettől most tekintsünk el.
Nincs olyan média, ami évtizedek múlva is működőképes és olvasható lesz. Még mindig a szalagos mentés a legtartósabb ideális tárolási körülmények között, de ott is lehet gond a szalagos egység megléte.

Kinek milyen évből datálódik a meglévő, legkorábbi digitális adata?

Az én Dédanyámról van egy fotó a családi archívumban, papír, 1905-ből. Most 113 éves. Hol lesz ez a kép 113 év múlva, ha ma beszkennelem?

--
robyboy

Rám pl rám tört pár éve ez a mi lesz a régi (analóg) cuccokkal gondolat és nekiálltam digitalizálni, de mint a gép. Régi családi diák, fényképek, VHS videók, magnókazetták (amin gyermekkori felvételek, már nem élő rokonok hangjai voltak) és elkezdtem kijavítgatni őket, szakadt "karcos" fotókat kiretusálgattam, videókat újraszíneztem, hangokról sercegést leszedtem.

Amúgy a digitális adat túlélése nagyban függ attól hogy hogyan kezeled. Nekem pl megvannak még az eredeti age of 2 mentéseim is amik egy 300Mhz-es celeronon születtek W98 alatt még általános iskolás koromban, középiskolás MSN beszélgetéseim logjai, suliba készült beadandók, illetve a "füzeteim" :) Jártak winyóról winyóra, aztán CD-re, DVD-re, külső winyóra, most meg épp felhőben (a winyók mellett).

Ma már ott tartok hogy megszabadultam az optikától, minden külső winyókon és felhőben van. Plusz erősen gondolkodom egy NAS-on csak még nem tudom hogy megépítem-e magamnak vagy veszek egyet.

És a legdurvább az hogy szelektálva és megfelelő formátumba téve nem is foglalnak annyira drasztikusan sok helyet, pl 4TB-nyi videót nemrégiben konvertáltam át HEVC-be és 1TB-ra mentek össze érzékelhető minőségromlás nélkül. Igaz a kiinduló formátumok elég nagy szórásban voltak, volt ott pl mpeg2 avi, xvid, quicktime mov meg éppen az aktuális általam használt szoftver kedvenc kimenete. Most egységes x265 :)

Aztán majd jön egy jó kis napkitörés nekem meg ment a levesbe x munkaórám ahol az x nagyon sok :D

Haha, szép. :) Nekem házi NAS -om van (rpi3 openmediavaulttal, nextclouddal). Maga az adat három helyen forog (2 laptop és a nas), és most tervezek automatizált, titkosított offsite backupot (valszeg s3 lesz mert arra találtam számomra is érthetően kezelhető toolt).

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

+1 vagy eredeti formátumban és mellé az eredeti szoftvert.
Ezért van az Internet Archive-ban JavaScriptre fordított MAME/MESS, hogy ha van 1980-ból egy fájlod, amit egy akkori mondjuk amigán csináltál, be tudd bootolni az "eredeti" rendszert, el tudd rajta indítani a progit és be tudd tölteni a fájlt.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

https://cloud.google.com/docs/geography-and-regions

"Zones should be considered a single failure domain within a region. In order to deploy fault-tolerant applications with high availability, you should deploy your applications across multiple zones in a region to help protect against unexpected failures."

"To protect against the loss of an entire region due to natural disaster, you should have a disaster recovery plan and know how to bring up your application in the unlikely event that your primary region is lost."

A felhő azért jó, mert tisztában lehetsz vele, hogy mi az a failure domain, meg a rendelkezésre állás, és nagyon könnyen tudod tologatni az erőforrásokat ide-oda, sőt ezt teljesen automatizálni is lehet (pl. geo-redudant storage, egyszer feltöltöd és ő majd szépen replikálja neked mindenhova).

( x-daemon | 2018. 09. 11., k – 22:35 )

lehet hogy sok eve mar kerdeztem es lehet hogy akkor volt is ra valasz, de mivel azota jott ki ujabb mssql ujbol felteszem a kerdest.
valaki tudja hogy lehet-e olyan replikaciot csinalni mssql-el mint mysql-el, hogy megmondom milyen nevu adatbazisokat replikaljon, es replikalni fogja az osszes tranzakciot, akkor is ha az egy tabla letrehozo vagy modosito tranzakcio? tehat ha a replikacio elinditasa utan letrehozok egy adatbazist, tablakat es adatokat, onnantol a replikalt adatbazis - adott kesleltetessel - megfelel az eredetinek?
koszi!

--
neked aztan fura humorod van...

( lajos22 | 2018. 09. 12., sze – 08:09 )

Felületesen átfutva, csak annyi nem jutott el, hogy a hűtőrendszer leállásától számítva mennyi idő telt el a megdöglésig. Nincs konkrét érték, hogy mennyi hő keletkezett, azaz hány fokban sültek meg a cuccok.

--
openSUSE 42.2 x86_64

Komoly rendszerek ma már automatikusan megkezdik az emergency shutdown procedúrát, ha az érték elér egy küszöbszintet. Ezt értelmes helyen jóval a kritikus hőmérséklet alá lövik be és sok helyen a gyártó nem is engedi módosítani a gyári értékeket. Pl. van olyan gyártó, amelyik méri az intake, exhaust értékeket, nem is lehet állítani. Önvédelemből.

Nem is értem, hogy ha ez be volt állítva, akkor milyen döntést kellett meghozni. Ez automatikus.

Persze, van, ahol ki lehet kapcsolni és majd "eldöntjük, hogy mi legyen, ha szar van, leállítjuk manuálisan" stb.

Na, ha ez volt, akkor ez pedig emberi hiba.

--
trey @ gépház

Most néztem meg egy rendszerem. Tápegységnél (PSU) 95 celsius fok a critical shutdown temp.

https://flic.kr/p/29UnBKE

De pl. egy kontrollernél már csak 60.

Nekem ez az egész magyarázat szaglik. Vagyis már akkor el kellett volna kezdődnie a leállításnak minden rendszernél, amikor 50-60 fok volt a hőmérséklet.

Szerintem ki voltak kapcsolva ezek a mechanizmusok, Joe pedig elkezdte volna egyenként kézzel leállítani, amikor már látták h. baj van (gondolom mire megjött a vezetéstől a parancs, hogy leállás, már késő volt, nem hiszem, hogy ezt egy operátor vagy a helyszínen levő talpas mérnök döntötte volna el), de nem ért a végére.

--
trey @ gépház

Kérlek ne. A storage belső felügyelete pontosan tudja, hogy mikor kell leállítani a storage-ot, hogy ne legyen adatvesztés. Ne tudja már ezt jobban egy Microsoft. A te fejedben a Microsoft valami nagy tudós valami.

Az elképzelésedben a Microsoft lomha döntési mechanizmusa + kézi beavatkozás gyorsabb, mint egy belső szenzor jelet ad a torage-nak, ami leállítja saját magát.

Az operátor még a jelszót keresi a menedzsment felülethez, mikor a másik már meghozta a döntést érzelemmentesen.

--
trey @ gépház

Teljesen mindegy, hogy milyen storage-ot használnak: polcról levettet, saját maguk által tákoltat. Ha abból hiányzik az automatikus vészleállítás, akkor az egy kalap szar.

Cukrozhatják bárhogy.

Ebből is látszik, hogy egyeseknek a cloud az egy valami olyan természetfeletti hipiszupiság, hogy azonnal hasra kell esni tőle.

--
trey @ gépház

És az a mágikus SDS nem hardvere(ke)n fut végső soron?

A címből: "Megsült tárolók miatt hasalt el az Azure"

Mi sült akkor meg? A Software Defined Storage-ból a "Software"?

Nyilván nem. Hanem az alatta futó vas.

Ne essünk már hanyatt ezekről a buzzword-öktől..

--
trey @ gépház

A mondandóm lényege: ha hagyod megsülni, akkor lehet, hogy van még 2-5 perced ahhoz képest, mintha lelőné magát. Lehet, ez nekik (akkor, ott) fontosabb (mert tudja, hogy megvan máshol is az adat), mint az, hogy mekkora konténer szemetet visznek el az incidens végén.
--
https://naszta.hu

Értem én, hogy mit mondasz. A szarul összetákolt szoftverstackból el kell jusson az adat a storage cache-be, onnan a le kell íródnia a diszkekre vagy SSD-re.

Joe várja, hogy a szoftver kiizzadja magából a sync-et, csak lehet, hogy mire az leér a device-ra, addigra annak beáll a csapágya vagy kiolvad a flash chipje.

Végső soron lehet, hogy a szoftverrész jelzi, hogy kész, csak az adat sosem íródott ki a cache-ből. A cache meg elpatkolt.

Erre nem lehet bazírozni.

Itt az egyetlen jó megoldás:

A HW szenzor szól, hogy kurva meleg van. A storage elkezdi a szabályos shutdown rutint. Azaz, kiírja a cache-ben éppen meglevő adatot diszkre bármire és leállítja magát. Ez már biztosan megvan. Hogy a szoftver részben mennyi ki nem írt adat maradt, az az így járás kategória.

Egyébként, amit te írsz, az nem felelős üzemeltetés, hanem 19-re lap húzása, vagy az egész tét feltétele ruletten a pirosra vagy a feketére. Ebben az esetben _szerencsére_ bejött.

De ez hazardírozás volt.

--
trey @ gépház

( asch v | 2018. 09. 12., sze – 09:13 )

Szerintem az még rendben is lehet, hogy egy központ ilyen értelemben sérülékeny, és leállhat. De annak alapnak kellene lenni, hogy földrajzilag elosztott a rendszer, és egy központ leállása esetén a többi átveszi a szerepét. Így tényleg minek felhőzzek, a pincében lévő szerverrel is lehet ilyen rendelkezésreállást csinálni. Sőt.

Olcsó.

Aszinkron storage replikáció nem nagy szám, a HP EVA-k már 10+ éve is tudták. DR site-ra migrálás egy VMware-rel már szintén ment 10 éve szerintem.

Ezektől nem kell hasra esni. Viszont ki kell tudni fizetni a vasat, az infrát (pl. site-ok közti vonalat), a szoftverlicenceket, a szakembert és az üzemeltetőt.

Illetve a felelősség lehárítható.

--
trey @ gépház