Zgjidhni disponueshmërinë në zona dhe rajone

Filloni nga veprimi i përdoruesit

Disponueshmëria e lartë (HA) synon ta mbajë shërbimin të përdorshëm pavarësisht dështimeve të komponentëve. Përcaktoni përdorshmërinë para se të zgjidhni arkitekturën. Një faqe rezervimesh që ngarkohet ndërsa të gjitha kërkesat për rezervim dështojnë nuk përbën një shërbim të disponueshëm rezervimesh.

Vendosni një objektiv të nivelit të shërbimit (SLO) për veprimin e rëndësishëm. Përcaktoni cilat kërkesa numërohen, çfarë do të thotë sukses dhe periudhën e matjes. Një SLA e shërbimit cloud përshkruan angazhimin e atij ofruesi. Ajo nuk vërteton disponueshmërinë e matur të aplikacionit tuaj.

Si ilustrim, disponueshmëria 99,9% e bazuar në kohë lejon 43,2 minuta padisponueshmëri në një muaj 30-ditor. Një SLO i bazuar në kërkesa ka emërues tjetër. Asnjëra matje nuk tregon sa të dhëna mund të humbni ose nuk garanton një kohëzgjatje maksimale për një ndërprerje të vetme.

Kuptoni kufijtë e dështimit

Një AWS Availability Zone (AZ) është një vendndodhje e izoluar infrastrukture brenda një Region-i. Një Region përmban disa AZ. Një projektim multi-region shpërndan komponentët e ngarkesës së punës nëpër Region-e. Ofruesit e tjerë kanë kufijtë dhe sjelljen e tyre të shërbimeve; shqyrtoni shërbimin e zgjedhur.

Këto janë mundësi projektimi, jo garanci disponueshmërie. Një etiketë nuk provon se çdo komponent i kërkuar përdor kufirin e synuar.

Gjurmoni rrugën e plotë të kërkesës

Merrni një shërbim imagjinar rezervimesh. Kopjet web ekzekutohen në dy AZ. Të dyja përdorin një bazë të dhënash dhe një gateway dalës në AZ A. Gateway nevojitet për të thirrur ofruesin e pagesave.

Nëse AZ A dështon, kopja web në AZ B mund të mbetet në gjendje të mirë, ndërsa rezervimi ende dështon. Ekipi duhet të vlerësojë bazën e të dhënave, rrugën e rrjetit, ofruesin e identitetit, varësinë e pagesave dhe drejtimin e trafikut. Shqyrtoni mënyrën reale të funksionimit të bazës së menaxhuar të të dhënave: replikimi, kalimi në burimet rezervë dhe sjellja e kopjeve për lexim ndryshojnë sipas produktit dhe konfigurimit.

Kontrolloni edhe kapacitetin. Burimet që mbijetojnë duhet të përballojnë ngarkesën e kërkuar. Një projektim që mbështetet te krijimi i kapacitetit gjatë një incidenti varet nga kuotat, burimet e disponueshme dhe veprimet e shtresës së kontrollit.

Kryeni një ushtrim të kontrolluar me kufi të përcaktuar, kushte ndalimi dhe person përgjegjës. Verifikoni një rezervim të plotë, përfshirë rakordimin e pagesave. Regjistroni kërkesat e dështuara dhe kohën për të rikthyer funksionimin e dobishëm.

Vendosni nëse një Region tjetër e zgjidh problemin

Funksionimi multi-region shton transferimin e të dhënave, burime të dyfishta, koordinim vendosjesh dhe punë funksionimi. Active/passive mban një mjedis gati për të marrë trafik. Active/active shërben trafik në më shumë se një mjedis. Gatishmëria dhe sjellja e kërkuar e të dhënave ndryshojnë.

Për shërbimin e rezervimeve, shkrimet e njëkohshme ngrenë një pyetje: a mund ta shesin dy Region-e të njëjtën ulëse? Përcaktoni cili sistem ka vendimin përfundimtar për një rezervim dhe sjelljen gjatë ndërprerjes së replikimit. «Replikoni bazën e të dhënave» nuk është përgjigje e plotë.

Kontrolloni vendndodhjet e lejuara të të dhënave, çelësat e enkriptimit, certifikatat, DNS, sekretet dhe shërbimet e jashtme. Një ndërprerje e shërbimit të përbashkët të identitetit ose një publikim i gabuar mund të prekë disa Region-e. Më shumë vendndodhje nuk heqin çdo shkak të përbashkët.

Lidheni disponueshmërinë me rikuperimin

HA trajton dështime të përcaktuara gjatë funksionimit. Rikuperimi nga fatkeqësitë rikthen një shërbim të përdorshëm dhe të dhënat e tij pas një ngjarjeje ndërprerëse. Një shërbim multi-region ende kërkon një plan rikuperimi për fshirjen ose dëmtimin e të dhënave.

Dokumentoni skenarët e zgjedhur të dështimit dhe ata që biznesi i pranon. Mbajini testet dhe përkufizimet e infrastrukturës në përputhje ndërsa aplikacioni ndryshon. Vazhdoni me RTO, RPO dhe rikuperimin nga fatkeqësitë.