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

 ( trey | 2018. szeptember 11., kedd - 18:49 )

"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ó.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

Ja, csak lespórolták a túlfeszvédelmet.
Mondjuk ha oda baszott be a villám, max az ima segí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.”

Nekem az jön le, hogy volt vele tervezve, de nagyobb lett az energia, ami beütött.
--
https://naszta.hu

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

Bezzeg, ha statikusra bízták volna...

Mondjuk éppen statikai tanulmányaimból rémlettek ilyenek pl. (egytámaszú, kéttámaszú) tartók méretezésénél.

--
trey @ gépház

Erre céloztam.
Matek alapján X. Hőmérséklet miegymás figyelembe vételével +20%-ba minden egyéb belefér.
És hogy tutit ne legyen gond (X+20%)+50% :))

Gépész szófordulattal:

Egy csavar nem csavar, két csavar egy csavar ...

Stb. stb.

--
trey @ gépház

"...nem volt idő a leállást végrehajtani"

Mindig előfordulhat, hogy a tervezettnél is rosszabbul alakul valami.

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.

Ja, mint Fukusimánál.

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

Hát, nem tudom, hogy láttam-e 20 éves pályafutásom alatt olyat, hogy megsültek adattárolók. Ez nem kis baklövés.

--
trey @ gépház

Mi volt a homerseklet ehhez ?
Mert volt mar 50 fokos kornyezetben belul 82 fokon uzemelo storage.
Ehhez viszonyitva 2 nap alatt 1 diszk, majd 6 honapon belul 5 masik szallt el.
Ez 1%.

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

Pedig de, csak az adatok megléte az érdekes, és pont ezt a legnehezebb is elérni. Minden más pótolható.

--
robyboy

Kiveve a kiesett idoben a penz? Azt meg ugye nem tudom, potoljak e

Kérdés, hogy sérült-e SLA, ÁSZF mit tudom én mi.

--
trey @ gépház

Tobb mint egy napos leallassal szerintem biztosan (SLA).

ne feledd, az SLA az eves celertek...

Kb 99,72%-nal tartanak most, ha mas leallas az evben nem volt.
Az SLA-t pedig altalaban ugy szoktak meghatarozni, hogy a tizedesvesszo utan hany db kilences. Itt mar 1 sincs.

a tizedesvesszo elotti is beleszamit.... a 4 kilences az 99.99% - es nem elmaradt haszonra hanem elofizetesi dijra vonatkozik a kotber... ha epp van.

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.

"Tapsikolni nem kell, de amibe itt bele lehet kötni az a leállás."

Én abba kötöttem bele, Imo kezdett terelni "de hát az adatok megmaradtak"-ba. Semmi köze ennek ahhoz, hogy épületgépészetileg ez egy jó nagy 1-es.

--
trey @ gépház

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.

Kell lennie worst case scenario-nak erre az esetre is.

Nem vagyok villanyosmérnök: lehet olyan mértékű villámcsapás, amire a jelenlegi tudásunkkal nem tudunk tökéletes védelmet biztosítani?

Szerintem erről a katonaságnál többet tudnak... :-)

Ebből a kommentből semmit sem tudtunk meg. :)

--
trey @ gépház

Úgy értettem azoknak pont a felülméretezés a műfajuk. Pénz, emberélet, nyersanyag, semmi sem számít... ;-D

Ja, így értem.

Hát, pl. egy liftkötelet sem 600 kg-ra méreteznek, ha annyi a lift max. terhelhetősége. Hanem 1600-ra. És van egy tartalék kötél (vagy kettő). Plusz fékek.

--
trey @ gépház

Oh, regi szep idok sejlenek vissza, mikor azt mondtak, X memoria mindenre eleg (X=640MB) akkor beleraktak volna (X + %20) * 2 -t es valoban jok lettek volna 2-3 evig :)

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

Látványos példa, de a digitális adatot korlátlan ideig meg lehet őrizni megfelelő eljárással, míg a papír előbb-utóbb az enyészeté lesz.

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

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

Igen, megfelelő eljárással. Úgy bármit sokkal tovább lehet megőrizni, legyen az papíron, vagy digitálisan. A probléma az, hogy amig egy papírkép elszakad, azt megragasszák, jóazúgy. De ha egy jpeg sérül meg, az úgy marad, mert nem értenek hozzá és nem is akarnak.

És formátumban!

Ezen ment a dokumentumszabvány balhé pár évvel ezelőtt.

--
trey @ gépház

+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)

Mindig van olyan időablak, ami közben keletkezett adatot nem lehet replikálni. Ez nem technológiai, hanem logikai dolog. Ha a feldolgozás ideje >0, akkor már meg is van ez az ablak.

Ezért szoktak adni többféle konzisztencia opciót. Pl. hány db replika kiírását akarod megvárni az ack-kal. Ha nem kaptad meg az ack-ot, akkor pedig vedd úgy, hogy nem lett elmentve a cuccod.

Ha meg akarod várni is lesz olyan időablak ahol elveszhet az adat. Például a replikáció során a küldés közben.

replikaciora is van ack, sot az ott kiirt adatra is. mas kerdes hogy budos lassu lesz az iras...

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

"leégett"

... felégették a gecibe.

--
GPLv3-as hozzászólás.

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).

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...

Van egy Replicate schema changes beállítás a Publication Properties alatt, ezzel át tudod vinni a séma módosítást jelentő kéréseket is.
Azt hiszem ez a default is egyben.
Szóval az MSSQL Replication ezt megoldja.

Nekem inkább az jön le, hogy a méretezés x szerverre készült, aztán még betoltak oda még y db-ot, mondván, hogy ezt még tuti elbírja. Aztán meg jött a nagy bumm. ;)

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

"ez pedig emberi hiba."
Na pont erre akartam utalni. Ha csak nem az történt, hogy leállt a hűtő és 5 perccel később már 80°C uralkodott a teremben. Bár ez is eléggé emberi hiba, mert akkor eléggé elszámolták a dolgokat.

--
openSUSE 42.2 x86_64

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

szvsz a meleg miatt laggolt az eger, ezert nehezen talaltak el a gombokat a ui-n.......

Vagy csak szeretnek döntést hozni: hány HDD/szerver ér meg egy adatvesztést. Tippre az MS úgy lehet vele, hogy lecseréli a fél adatközpontot, de adat ne vesszen el, mert az rosszabb a reputációnak. Legalábbis ebből a post mortem-ből nekem ez jön le.
--
https://naszta.hu

Hát ha egyszerre kirohad a fél gépterem, azért van ott adatvesztés, hiába a több helyre backup, vagy elosztott tárolás.

--
openSUSE 42.2 x86_64

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

Azt gondolom, hogy cloud esetében a legritkább esetben használnak olyan storage-ot (céleszközt), amilyenre te itt gondolsz.

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

+1
Pont ezt akartam irni en is, nem gondolnam hogy ilyen helyeken hagyomanyos SAN storage-ot hasznalnanak. Inkabb vmi SDS lesz az.

É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

meleg felhő?

Újabban a cloud is forró téma :D

Vihar felhő...

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

Igazából, mind a vészleállás megsülés előtt, mind az hogy legyen terv a teljes központ leállása esetére alap kellene hogy legyen. Tehát a tervező és üzemeltető mérnökök súlyosan hanyagok voltak.

De legalább nem atomerőmű, csak valami főhő :-).

...ha beindul a fűtésszezon :D