A mai digitális világban az adatokhoz való megszakítás nélküli hozzáférés elvárása már nem luxus, hanem szükségszerűség.Függetlenül attól, hogy egy kritikus alkalmazást hajt végre, multimédiás tartalmat nyújt a globális közönségnek, vagy egyszerűen csak személyes fájlokat készít biztonsági mentésre, a felhőalapú tárolás megbízhatósága közvetlenül befolyásolja a termelékenységtől a bizalomig. A legtöbb felhőszolgáltató esetében a megbízhatóságot az üzemidő százalékos arányai – 99,9%, 99,99% vagy akár Mindazonáltal ezeknek a polírozott szolgáltatási szintű megállapodásoknak (SLA-k) mögött egy éles valóság van: igaz. Az a képesség, hogy bármikor, bárhol, váratlan késések vagy megszakítások nélkül hozzáférhessen az adataidhoz, elkerülhetetlen marad. Még a legerősebb központosított felhők is érzékenyek arra, amit megpróbálnak enyhíteni: a kudarc. five nines continuous performance A megbízhatóság nem valami, amit remélsz - ez valami, amit tervezel. A régión belüli megszakításoktól kezdve a rosszul konfigurált hálózati útvonalakig újra és újra láttuk, hogy a központosított infrastruktúra, függetlenül attól, hogy mennyire megerősödött, nem menekülhet meg a saját szerkezeti korlátaitól. A régión belüli megszakításoktól kezdve a rosszul konfigurált hálózati útvonalakig újra és újra láttuk, hogy a központosított infrastruktúra, függetlenül attól, hogy mennyire megerősödött, nem menekülhet meg a saját szerkezeti korlátaitól. Ez a blog feltárja, hogy a Sia decentralizált architektúrája miért egyedülállóan képes leküzdeni ezeket a korlátozásokat. Az elkövetkező szakaszokban összehasonlítjuk ezt a tervezést a hagyományos tárolási modellekkel, lebontjuk a valós hibaforgatókönyveket, és bemutatjuk, hogy a decentralizáció nemcsak biztonságosabb, hanem megbízhatóbb. Teljesítmény az ellenálláson keresztül Mert a felhőalapú tárolás jövőjében a megbízhatóság nem valami, amit remélsz – ez valami, amit tervezel. A központosított felhők törékeny alapjai Annak ellenére, hogy a hagyományos felhő tárolási platformok „öt kilenc” üzemidőt ígérnek, többször is bebizonyították, hogy a központosított infrastruktúra milyen törékeny lehet a környezeti szélsőségek, az emberi hiba vagy a belső hibák miatt.Annak ellenére, hogy az AWS, a Google Cloud és a Microsoft Azure, a valós esettanulmányok egy másik történetet mesélnek el - egy olyan, ahol több millió felhasználó elveszítheti a hozzáférést egy pillanat alatt, és az egész vállalkozást egyetlen hiba miatt leállítják. Talán a legdrámaibb példák a felhő törékenység megtalálható adatközpontok tüzek – incidensek, amelyek azonnal letilthatják az egész zónák a felhő szolgáltatások. Augusztusban 2022, egy elektromos robbanás a Google Council Bluffs adatközpont sérült három dolgozót, és megzavarta az alapvető szolgáltatások, mint a Keresés és Térkép. Egy évvel később Párizsban a Google Cloud európai-nyugati 9-es zónájának több klaszteres meghibásodása a víz behatolásával kezdődött – maga a hűtőrendszer meghibásodása következtében, amely elárasztotta az akkumulátortermet és tüzet gyújtott. Ezek az incidensek visszhangozzák a 2021-es strasbourgi OVHcloud-tüzet, amely teljesen elpusztította az SBG2 adatközpontot, és részben károsította másokat ugyanabban a campusban. Many customers had no disaster recovery plans in place, and entire websites were lost without backups. A tűzön túl a hőhullámok váratlan, de egyre növekvő veszélyt jelentenek.2022 júliusában a 40 °C (104 °F) feletti londoni rekordhőmérséklet a Google és az Oracle adatközpontokat is offline állapotba hozta a hűtőrendszer meghibásodása miatt.A Google-nak proaktívan le kellett zárnia felhőjének egyes részeit, hogy megakadályozza a hardverkárosodást – ami lenyűgöző elismerés, hogy egyedül az időjárás veszélyeztetheti a szolgáltatás elérhetőségét. Azonban nem minden megszakítás születik fizikai katasztrófából – néhány a digitális katasztrófák várakozására. 2024 februárjában a Google Cloud újabb megszakítást szenvedett el, amikor egy regionális metadata-tárhely meghibásodása közel három órán át eltávolította az USA-nyugati régiót. Hasonlóképpen a CrowdStrike 2024 júliusi rutinfrissítése a Microsoft Windows rendszerek széles körű összeomlását váltotta ki, ami több ezer törölt járatot és hatalmas termelékenységi veszteséget okozott az iparágakban. Amikor egy olyan tartalomszolgáltató hálózat (CDN) mint a Fastly 2021-ben hibás konfigurációt tapasztalt, globális zavarokat okozott, és másodpercek alatt befolyásolta a Reddit-t, a Spotify-t és a főbb hírportálokat. Folyamatos teljesítmény a design által Ahol a központosított felhőszolgáltatók egyre nagyobb erődítményeket építenek a kudarcok elleni védelem érdekében, a Sia teljesen elutasítja a erőd modellt. Ahelyett, hogy mindent egy régió vagy létesítmény ellenálló képességére fogadna, a Sia globálisan, több tucat függetlenül működő csomóponton keresztül osztja el adatait, matematikával – nem marketinggel – garantálja a megbízhatóságot. Az elbocsátás, amely Az elbocsátást gyakran úgy tekintik, mint egy biztonsági intézkedést – a kudarc elleni védelem egyik módját. De a Sia-nál ez sokkal több. Alapértelmezés szerint a Sia minden fájlt 30 titkosított részre oszt törlési kódolással. Csak 10 részre van szükség a fájl teljes újjáépítéséhez. Ez azt jelenti, hogy a hálózat nemcsak a megszakításokat, hanem az egyes hostok változó teljesítményét is elviselheti – mindezt zökkenőmentes hozzáférés mellett. Az elbocsátás nem visszaesés – ez a folyamatos teljesítmény alapja. Ezzel szemben a hagyományos felhők a teljes fájl-replikációra támaszkodnak néhány régióban.Ha egy régió nem működik, a hozzáférés lelassul vagy leáll – és az extra tárhely nem jelenti a jobb sebességet. A Sia modellje valós időben alkalmazkodik.A visszanyerési útvonalak dinamikusan változnak a fogadó rendelkezésre állásától és a hálózati körülményektől függően – nincsenek hibaelhárítások, nincsenek szűk keresztmetszetek, nincsenek leállási ablakok. És bár a központosított felhők belsőleg is használhatják a törlési kódolást, infrastruktúrájukat még mindig egyetlen szolgáltató üzemelteti. A Sia hostjei ezzel szemben önállóan működnek – gyakran különböző magánszemélyek vagy vállalkozások.A Sia használata olyan, mint az adatok alapértelmezett felosztása 30 különböző felhőre. Ellenállás megszakítás nélkül A legtöbb felhőalapú környezetben, amikor valami megszakad, a teljesítmény szenved. Még a meghibásodási rendszereknél is, a megszakítások gyakran csökkenő sebességhez, akadálymentes hozzáféréshez vagy teljes leálláshoz vezetnek, miközben az infrastruktúra megpróbál helyreállni. Az építészet másképp működik. Amikor az adataid egy részét tároló host offline állapotba kerül – akár meghibásodás, karbantartás vagy instabilitás miatt – a fájlok továbbra is teljes mértékben elérhetők maradnak. Nincs betöltési pörgető, nincs szinkronizálási késedelem, nincs figyelmeztetés. Eközben a háttérben a bérlő szoftver elkezdi önállóan helyreállítani a teljes redundanciát azáltal, hogy új szeleteket tölt fel az egészséges házigazdáknak. A Sia nem csak felépül a kudarcokból - működik rajta keresztül. Ahelyett, hogy reagálnánk a kudarcra, miután ez megtörténik, a Sia úgy kezeli a churn-t, mint egy várható viselkedést - egy olyan viselkedést, amelyet a hálózat graciálisan kezelt. Ez a rugalmasság modellje, amely nem csak elkerüli a megszakításokat - aktívan védi a felhasználókat attól, hogy észrevegyék őket. Nincs egyetlen kudarcpont A központosított felhőplatformok sérülékenyek a kaszkadáló meghibásodásokra, mert a központosított vezérlésre támaszkodnak.A rosszul konfigurált útválasztó, a hibás szoftver telepítés vagy az egyetlen létesítményben fellépő áramellátási probléma régiókra terjedhet – ezáltal több millióan támaszkodnak a szolgáltatásokra. A Sia architektúrája a tervezés révén kiküszöböli ezt a kockázatot. Nincs főcsomó. Nincs központi régió. Nincs olyan kiváltságos hatóság, amely véletlenül kikapcsolhatja a rendszert. Ehelyett az adatait több tucat független host szerte a világon – mindegyik csak titkosított részecskéket tárol. Ha egy host meghibásodik, a rendszer továbbra is fut. Ha tíz host meghibásodik, akkor továbbra is fut. Nincs szükség „meghibásodásra”, mert nincs egyedi út, amellyel elkezdeni. Nincs régió. Nincs master csomópont. Nincs bottleneck. Csak megállíthatatlan hozzáférés. A központi függőség hiánya nemcsak a hiba toleranciát növeli, hanem Nem vársz arra, hogy egy régió visszatérjen az internetre.Nem egy túlterhelt átjáró vagy egy emberi rendszergazda-helyreállítási szolgáltatás blokkolja Önt.Az adatokat bárhonnan húzza, ahol a leggyorsabb - folyamatosan. prevents performance blackouts Megbízhatóságot tervezni, nem csak remélni Amikor a „felhő megbízhatóságáról” beszélünk, gyakran ígéretet kapunk – egy olyan SLA-t, amelyet pénzügyi szankciók, ragyogó üzemidő-százalékok és márka hírnév támogatnak.De ahogy láttuk, még a legnagyobb felhőszolgáltatók sem tudnak elmenekülni a központosítással járó törékenységtől. A Sia alapvetően más megközelítést alkalmaz. ahelyett, hogy feltételezné az infrastruktúrát, és felkészülne a katasztrófára, amikor nem, a Sia feltételezi, hogy a kudarc elkerülhetetlen - és olyan rendszert épít, amely mindenképpen működik. Nincs kiváltságos szerver, nincs regionális függőség, nincs beszállítói zár. Csak önjavító, decentralizált infrastruktúra, amely az adatokat hozzáférhetővé teszi, mert egyetlen szereplő sem rendelkezik azzal a hatalommal, hogy hozzáférhetetlenné tegye. Folyamatos teljesítmény Ez több, mint technikai előny. Ez megváltoztatja azt, ahogyan a digitális ellenálló képességre gondolunk. Ahelyett, hogy magasabb falakat és mélyebb csapokat építenénk, a Sia szétszórja védelmét. Megosztja a bizalmat. És ezzel újradefiniálja, hogy milyen lehet a megbízható felhő tárolás egy olyan világban, ahol a leállás már nem elfogadható. Mivel a szervezetek egyre növekvő leállásokkal, növekvő költségekkel és szigorúbb megfelelési követelményekkel szembesülnek, a decentralizáció több mint megvalósítható – ez jobb. Még akkor is, ha a dolgok rosszul mennek, itt az ideje, hogy abbahagyjuk a bizalom köré tervezést, és elkezdjük a bizonyosság köré tervezni. Csak munka A Sia-val a folyamatos teljesítmény nem cél, hanem garancia. Források Data Center Knowledge. (2022, augusztus 9). Adatközpont tűz — Google szenved ‘elektromos incidens’, 3 sérült. Data Center Knowledge. https://www.datacenterknowledge.com/hyperscalers/data-center-fire-google-suffers-electric-incident-3-sérült Claburn, T. (2023, április 26). A Google Cloud áthalad Európában vízszivárgás, tűz közepette. https://www.theregister.com/2023/04/26/google_cloud_outage/ Sverdlik, Y. (2021, március 9). A tűz elpusztította az OVH Strasbourg adatközpontját (SBG2). Adatközpont ismerete. https://www.datacenterknowledge.com/uptime/fire-has-destroyed-ovh-s-strasbourg-datacenter-sbg2 Bloomberg News. (2022, július 20). Google, Oracle adatközpontok ütött offline a londoni hő. Data Center Tudás. https://www.datacenterknowledge.com/cooling/google-oracle-data-centers-knocked-offline-by-london-heat Millward, W. (2024, december 5). A 10 legnagyobb felhőmegszakítások 2024. CRN. https://www.crn.com/news/cloud/2024/the-10-biggest-cloud-outages-of-2024 Barrett, B. (2021, június 8). Hogyan egy homályos cég vette le a nagy darab az interneten. WIRED. https://www.wired.com/story/fastly-cdn-internet-outages-2021/

This story contains new, firsthand information uncovered by the writer.

Ez a hanganyag a történet eredeti nyelvén készült!

Túl hosszú; Olvasni

Make resilience your competitive advantage

A Sia újradefiniálja a felhő megbízhatóságát a tervezésen alapuló folyamatos teljesítménygel

About Author

HOZZÁSZÓLÁSOK

HANG TAGOK

EZT A CIKKET BEMUTATTA

Related Stories

How Emoji Credibility Indicators Add Context to HackerNoon Stories

THE LAST DAY OF NEW YORK

From Desk to HackerNoon: Your Ultimate Guide on How to Publish a Story

On OpenAI Failed Board Coup of Sam Altman & the Danger of Leaving AI Fate in the Hands of a Few

How Emoji Credibility Indicators Add Context to HackerNoon Stories

THE LAST DAY OF NEW YORK

From Desk to HackerNoon: Your Ultimate Guide on How to Publish a Story

On OpenAI Failed Board Coup of Sam Altman & the Danger of Leaving AI Fate in the Hands of a Few

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps