Atsparumas gedimams proaktyviai perkelia darbo krūvius į sveikas sistemas, kol vartotojai nepastebi problemų, o sistemos gedimų atveju iš naujo paleidžiamos sistemos reaktyviai atkuria paslaugas po netikėtų gedimų. Abu metodai siekia palaikyti prieinamumą, tačiau iš esmės skiriasi laiku, architektūros sudėtingumu ir poveikiu vartotojams.
Proaktyvi architektūra, kuri automatiškai nukreipia srautą į atsargines sistemas, kai pagrindiniai komponentai rodo gedimo požymius.
Reaktyvus atkūrimo mechanizmas, kuris aptinka nepavykusius procesus ir automatiškai juos paleidžia iš naujo, kad atkurtų paslaugos funkcionalumą.
| Funkcija | Atsparumas gedimams | Sistemos gedimas paleidžiamas iš naujo |
|---|---|---|
| Pirminis požiūris | Proaktyvus perteklius ir srauto perkėlimas | Reaktyvus aptikimas ir proceso atgaivinimas |
| Naudotojo poveikis | Dažnai sklandžiai, be matomų pertraukų | Paprastai sukelia trumpalaikį paslaugos nepasiekiamumą |
| Infrastruktūros kaina | Didesnis dėl pasikartojančių atsarginių išteklių | Mažesnis, nes nereikia nenaudojamų atsarginių sistemų |
| Aptikimo metodas | Nuolatinis sveikatos stebėjimas ir ribos | Proceso nutraukimas arba širdies nepakankamumas |
| Atsigavimo laikas | Milisekundės į sekundes | Nuo sekundžių iki minučių, priklausomai nuo paleidimo |
| Sudėtingumas | Aukštas – reikalingas orkestravimas ir būsenos sinchronizavimas | Vidutinis – iš pradžių lengviau įgyvendinti |
| Geriausiai tinka | Svarbios naudotojams skirtos paslaugos ir duomenų bazės | Vidiniai įrankiai, paketiniai darbai, darbuotojai be pilietybės |
Atsparumas gedimams sukuria dubliavimą sistemos projekte nuo pat pradžių, traktuojant gedimą kaip laukiamą įvykį, o ne išimtį. Toks mąstymas perkelia inžinerijos dėmesį į sklandų degradavimą ir geografinį pasiskirstymą. Priešingai, gedimų atveju paleidimas iš naujo daro prielaidą, kad atskiri procesai gali ir suges, todėl sistemai tereikia patikimų mechanizmų, kad jie greitai vėl veiktų.
Avarinio perkrovimo klasterių priežiūra reikalauja nuolatinio dėmesio duomenų nuoseklumui, smegenų skaidymo prevencijai ir avarinio perkrovimo testavimui, kuriuos daugelis komandų nepakankamai įvertina. Avarinio paleidimo iš naujo mechanizmai yra paprastesni konfigūruoti, tačiau gali užmaskuoti esminį nestabilumą – komandos kartais sukaupia techninių skolų, kai dažnas paleidimas iš naujo tampa normalizuotas, o ne tiriamas.
Dvigubos infrastruktūros naudojimas apsaugai nuo gedimų padvigubina arba patrigubina skaičiavimo išlaidas, nors debesies taškinės instancijos ir automatinis mastelio keitimas gali tai sumažinti. Avarinis paleidimas iš naujo sumažina išteklių sąnaudas, nes nėra laisvų atsarginių kopijų, tačiau paslėptos prastovų išlaidos atkūrimo metu gali viršyti infrastruktūros taupymą pajamoms svarbioms programoms.
Perkrovimas geriausiai veikia, kai ištisi duomenų centrai ar regionai tampa nepasiekiami, nes srautas gali būti nukreipiamas per geografiškai išsklaidytus mazgus. Avariniai paleidimai iš naujo efektyviai susidoroja su izoliuotais procesų gedimais, tačiau sunkiai susidoroja su kaskadiniais gedimais, kai vienu metu sugenda keli komponentai – tokiais atvejais paprasti paleidimo iš naujo ciklai dažnai pablogina problemą.
Abu metodai generuoja skirtingus telemetrijos modelius. Hibų valdymo sistemos generuoja įspėjimus apie sumažėjusį pajėgumą ir pasislinkusius srauto modelius, kuriuos reikia interpretuoti. Avarijų atveju paleidimo iš naujo sistemos užtvindo žurnalus paleidimo iš naujo įvykiais, kurie gali trukdyti analizuoti gedimų priežastis, nebent jie būtų kruopščiai struktūrizuoti naudojant išėjimo kodus ir gedimų kategorijas.
Atsparumas gedimams daro sistemas visiškai atsparias prastovoms.
Net ir gerai suprojektuotos gedimų prevencijos sistemos patiria trumpus sutrikimus neplanuotų gedimų metu, o netinkamai sukonfigūruotos sistemos būklės patikros gali sukelti priešlaikinius gedimus, kurie sukuria sutrikimus, o ne jų užkerta kelią. Pačių gedimų prevencijos mechanizmų sudėtingumas tampa galimų gedimų šaltiniu.
Avarinis paleidimas iš naujo skirtas tik prastai suprojektuotoms programoms.
Net ir kruopščiausiai parašyta programinė įranga gamyboje susiduria su kraštutiniais atvejais – atminties nutekėjimais priklausomybėse, branduolio klaidomis ar aparatinės įrangos gedimais, kurių negali numatyti joks programos kodas. Avarinis paleidimas iš naujo tarnauja kaip pragmatiškas saugos tinklas visoje pramonėje, o ne tik tvarstis nuo blogo kodo.
Turite rinktis tik tarp avarinio ir paleidimo iš naujo po gedimo.
Didelio masto gamybos sistemos paprastai naudoja abu: apkrovos balansavimo sistemos gedimų šalinimą ir duomenų bazės pakopų perteklių, o gedimų atveju paleidimas iš naujo apdoroja atskiras kiekvieno mazgo procesų klaidas. Šie mechanizmai vienas kitą papildo, o ne pakeičia.
Automatinis perjungimas visada įvyksta greičiau nei rankinis įsikišimas.
Nors automatinis gedimų perjungimas gali perkelti srautą per kelias sekundes, aptikimo ir sprendimų logika kartais sukelia vėlavimus arba klaidingus teigiamus rezultatus. Sudėtingais gedimų atvejais patyrę operatoriai, atliekantys tyčinį rankinį gedimų perjungimą, gali pasiekti patikimesnių rezultatų nei automatinės sistemos, reaguojančios į dviprasmiškus signalus.
Avarinis paleidimas iš naujo panaikina poreikį analizuoti pagrindinę priežastį.
Automatinio paleidimo iš naujo patogumas dažnai verčia komandas nepakankamai dėmesio skirti gedimų priežasčių supratimui. Organizacijos, kurios patenka į šį modelį, kaupia nestabilumo skolą – dažnas paleidimas iš naujo padidina delsos dispersiją, švaisto skaičiavimo ciklus ir galiausiai sukelia kaskadinius gedimus, kai paleidimo iš naujo dažnis viršija sistemos pajėgumą.
Rinkitės atsparumą gedimams klientų aptarnavimo paslaugoms, kur net ir kelios sekundės prastovų turi verslo pasekmių, priimdami tam reikalingas infrastruktūros investicijas. Rinkitės gedimų sukeltą paleidimą iš naujo, kai pakanka greito būsenos neturinčių arba vidinių darbo krūvių atkūrimo, tačiau atidžiai stebėkite paleidimo iš naujo dažnumą, kad pastebėtumėte sistemines problemas, kol jos neiškilo.
„Kafka“ ir „Flink“ sudaro paskirstytą srautinio apdorojimo ekosistemą realaus laiko duomenų srautams, o apdorojimas atmintyje pagreitina analizę, nes duomenys saugomi tik RAM atmintyje – kiekvienas iš jų tenkina iš esmės skirtingus architektūrinius greičio, mastelio ir tvarumo poreikius.
„Netflix“ vidinė mašininio mokymosi platforma siūlo glaudžiai integruotus, didelio masto įrankius, skirtus transliacijų suasmeninimui, o nepriklausomi mašininio mokymosi įrankiai suteikia mažesnėms komandoms lankstumo ir kontrolės. Pasirinkimas priklauso nuo masto, pritaikymo poreikių ir esamų investicijų į infrastruktūrą.
Adaptyvi infrastruktūra dinamiškai prisitaiko prie kintančių darbo krūvių, naudodama automatizavimą ir mastelio keitimą realiuoju laiku, o statinės infrastruktūros projektavimas remiasi fiksuotais, iš anksto sukonfigūruotais ištekliais. Pasirinkimas priklauso nuo darbo krūvio kintamumo, biudžeto nuspėjamumo ir veikimo brandos jūsų debesijos aplinkoje.
Apkrovos balansavimas mašininio mokymosi sistemose valdo GPU reikalaujančius išvadų ir mokymo darbo krūvius specializuotoje įrangoje, o paprastas API užklausų apdorojimas paskirsto nedidelį HTTP srautą bendrosios paskirties serveriuose. Jie labai skiriasi sudėtingumu, išteklių poreikiu ir maršruto parinkimo išmanumu.
Ši palyginimo analizė nagrinėja „Amazon Web Services“ ir „Google Cloud“, vertindama jų paslaugų pasiūlą, kainodaros modelius, pasaulinę infrastruktūrą, našumą, kūrėjų patirtį ir optimalius naudojimo atvejus, padėdama organizacijoms pasirinkti debesų platformą, geriausiai atitinkančią jų techninius ir verslo poreikius.
