Pasirinkite prieinamumą tarp zonų ir regionų

Pradėkite nuo naudotojo operacijos

Aukštas prieinamumas (HA) siekia išlaikyti paslaugą tinkamą naudoti nepaisant komponentų gedimų. Apibrėžkite tinkamumą naudoti prieš pasirinkdami architektūrą. Įkeliamas rezervavimo puslapis, kuriame visos rezervavimo užklausos nepavyksta, nėra prieinama rezervavimo paslauga.

Svarbiai operacijai nustatykite paslaugos lygio tikslą (SLO). Apibrėžkite, kurios užklausos skaičiuojamos, ką reiškia sėkmė ir koks matavimo laikotarpis. Debesijos paslaugos SLA aprašo to teikėjo įsipareigojimą. Jis neįrodo išmatuoto jūsų programos prieinamumo.

Pavyzdžiui, 99,9 % laiku grindžiamas prieinamumas leidžia 43,2 minutės neprieinamumo per 30 dienų mėnesį. Užklausomis grindžiamo SLO vardiklis kitoks. Nė vienas matas nenusako, kiek duomenų galite prarasti, ir negarantuoja didžiausios atskiro sutrikimo trukmės.

Supraskite gedimų ribas

AWS Availability Zone (AZ) yra izoliuota infrastruktūros vieta regione. Regioną sudaro kelios AZ. Kelių regionų sprendimas paskirsto darbo krūvio komponentus tarp regionų. Kiti teikėjai turi savo ribas ir paslaugų veikimą; išnagrinėkite pasirinktą paslaugą.

Tai projektavimo galimybės, o ne prieinamumo garantijos. Pavadinimas neįrodo, kad kiekvienas būtinas komponentas naudoja numatytą ribą.

Atsekite visą užklausos kelią

Apsvarstykite išgalvotą rezervavimo paslaugą. Žiniatinklio replikos veikia dviejose AZ. Abi naudoja vieną duomenų bazę ir vieną išeinančio srauto šliuzą zonoje AZ A. Šliuzas būtinas norint kreiptis į mokėjimų teikėją.

Jei AZ A sugenda, žiniatinklio replika zonoje AZ B gali likti veiksni, nors rezervavimas vis tiek neveikia. Komanda turi įvertinti duomenų bazę, tinklo kelią, tapatybės teikėją, mokėjimų priklausomybę ir maršruto parinkimą. Išnagrinėkite tikrąjį valdomos duomenų bazės režimą: replikavimas, persijungimas po gedimo ir skaitymo veikimas priklauso nuo produkto bei konfigūracijos.

Taip pat patikrinkite pajėgumą. Likę ištekliai turi apdoroti reikiamą apkrovą. Sprendimas, kuris remiasi pajėgumo sukūrimu incidento metu, priklauso nuo kvotų, prieinamų išteklių ir valdymo plokštumos operacijų.

Atlikite kontroliuojamą pratimą su apibrėžta riba, sustabdymo sąlygomis ir atsakingu asmeniu. Patikrinkite visą rezervavimą, įskaitant mokėjimo duomenų suderinimą. Užrašykite nepavykusias užklausas ir naudingo veikimo atkūrimo laiką.

Nuspręskite, ar kitas regionas sprendžia problemą

Eksploatavimas keliuose regionuose prideda duomenų perdavimo, dubliuotų išteklių, diegimo koordinavimo ir eksploatavimo darbo. Active/passive režimas laiko vieną aplinką parengtą priimti srautą. Active/active režimas aptarnauja srautą daugiau nei vienoje aplinkoje. Reikiamas pasirengimas ir duomenų veikimas skiriasi.

Rezervavimo paslaugai vienalaikiai įrašymai kelia klausimą: ar du regionai gali parduoti tą pačią vietą? Apibrėžkite, kas priima galutinį rezervavimo sprendimą ir kaip sistema veikia nutrūkus replikavimui. „Replikuoti duomenų bazę“ nėra išsamus atsakymas.

Patikrinkite leidžiamas duomenų vietas, šifravimo raktus, sertifikatus, DNS, paslaptis ir išorines paslaugas. Bendras tapatybių sutrikimas ar bloga versija gali paveikti kelis regionus. Daugiau vietų nepašalina visų bendrų priežasčių.

Susiekite prieinamumą su atkūrimu

HA skirtas apibrėžtiems gedimams eksploatavimo metu. Atkūrimas po katastrofos atkuria tinkamą naudoti paslaugą ir jos duomenis po trikdančio įvykio. Keliuose regionuose veikiančiai paslaugai vis tiek reikia atkūrimo plano po ištrynimo ar duomenų sugadinimo.

Dokumentuokite pasirinktus gedimų scenarijus ir tuos, kurių riziką verslas priima. Keičiantis programai, derinkite testus ir infrastruktūros apibrėžimus. Toliau skaitykite apie RTO, RPO ir atkūrimą po katastrofos.