Izvēlieties pieejamību zonās un reģionos

Sāciet ar lietotāja darbību

Augsta pieejamība (HA) cenšas saglabāt pakalpojumu lietojamu, neskatoties uz komponentu kļūmēm. Definējiet lietojamību pirms arhitektūras izvēles. Rezervēšanas lapa, kas ielādējas, kamēr visi rezervēšanas pieprasījumi neizdodas, nav pieejams rezervēšanas pakalpojums.

Būtiskajai darbībai nosakiet pakalpojuma līmeņa mērķi (SLO). Definējiet, kuri pieprasījumi tiek skaitīti, ko nozīmē panākums un kāds ir mērījuma periods. Mākoņpakalpojuma SLA apraksta konkrētā sniedzēja saistības. Tas nepierāda jūsu lietotnes izmērīto pieejamību.

Ilustrācijai: 99,9 % pieejamība pēc laika pieļauj 43,2 minūtes nepieejamības 30 dienu mēnesī. Uz pieprasījumiem balstītam SLO ir cits saucējs. Neviens mērījums nenosaka pieļaujamo datu zudumu un negarantē maksimālu atsevišķa pārtraukuma ilgumu.

Izprotiet kļūmju robežas

AWS pieejamības zona (AZ) ir izolēta infrastruktūras atrašanās vieta reģionā. Reģions satur vairākas AZ. Vairāku reģionu risinājums sadala darba slodzes komponentus starp reģioniem. Citiem sniedzējiem ir savas robežas un pakalpojumu darbība; pārbaudiet izvēlēto pakalpojumu.

Tās ir projektēšanas iespējas, nevis pieejamības garantijas. Apzīmējums nepierāda, ka katrs nepieciešamais komponents izmanto paredzēto robežu.

Izsekojiet visu pieprasījuma ceļu

Aplūkojiet izdomātu rezervēšanas pakalpojumu. Tīmekļa replikas darbojas divās AZ. Abas izmanto vienu datubāzi un vienu izejošo vārteju AZ A. Vārteja ir vajadzīga maksājumu sniedzēja izsaukšanai.

Ja AZ A nedarbojas, tīmekļa replika AZ B var palikt darbspējīga, bet rezervēšana joprojām neizdodas. Komandai jānovērtē datubāze, tīkla ceļš, identitātes nodrošinātājs, maksājumu atkarība un maršrutēšana. Pārbaudiet faktisko pārvaldītās datubāzes režīmu: replikācija, pārslēgšanās un lasošo komponentu darbība atšķiras pēc produkta un konfigurācijas.

Pārbaudiet arī jaudu. Atlikušajiem resursiem jāapstrādā vajadzīgā slodze. Risinājums, kas paļaujas uz jaudas izveidi incidenta laikā, ir atkarīgs no kvotām, pieejamiem resursiem un vadības plaknes darbībām.

Veiciet kontrolētas mācības ar noteiktu robežu, apstāšanās nosacījumiem un atbildīgo. Pārbaudiet pilnu rezervēšanu, tostarp maksājumu saskaņošanu. Reģistrējiet neveiksmīgos pieprasījumus un laiku līdz noderīgas darbības atjaunošanai.

Izlemiet, vai cits reģions risina problēmu

Darbība vairākos reģionos pievieno datu pārsūtīšanu, dublētus resursus, izvietošanas koordinēšanu un ekspluatācijas darbu. Aktīvs/pasīvs režīms tur vienu vidi gatavu pārņemt datplūsmu. Aktīvs/aktīvs režīms apkalpo datplūsmu vairākās vidēs. Vajadzīgā gatavība un datu darbība atšķiras.

Rezervēšanas pakalpojumā vienlaicīga rakstīšana rada jautājumu: vai divi reģioni var pārdot vienu un to pašu vietu? Nosakiet, kurš ir tiesīgs apstiprināt rezervāciju un kā rīkoties pārtrauktas replikācijas laikā. „Replicēt datubāzi“ nav pilna atbilde.

Pārbaudiet atļautās datu atrašanās vietas, šifrēšanas atslēgas, sertifikātus, DNS, slepenos datus un ārējos pakalpojumus. Kopīga identitātes kļūme vai slikts laidiens var ietekmēt vairākus reģionus. Vairāk atrašanās vietu nenovērš katru kopīgo cēloni.

Saistiet pieejamību ar atjaunošanu

HA risina noteiktas kļūmes ekspluatācijas laikā. Atjaunošana pēc katastrofas atjauno lietojamu pakalpojumu un tā datus pēc traucējoša notikuma. Arī vairāku reģionu pakalpojumam vajag atjaunošanas plānu dzēšanas vai datu bojājumu gadījumam.

Dokumentējiet izvēlētos kļūmju scenārijus un tos, kuru risku bizness pieņem. Mainoties lietotnei, saglabājiet testu un infrastruktūras definīciju saskaņu. Turpiniet ar RTO, RPO un atjaunošanu pēc katastrofas.