Изаберите решење за доступност у више зона и региона

Почните од корисничке операције

Висока доступност, односно HA, тежи да сервис остане употребљив упркос отказима компоненти. Дефинишите употребљивост пре избора архитектуре. Страница за резервације која се учитава док сви захтеви за резервацију отказују није доступан сервис за резервације.

Поставите циљ нивоа сервиса, односно SLO, за важну операцију. Дефинишите који захтеви се рачунају, шта значи успех и период мерења. SLA cloud сервиса описује обавезу тог добављача. Не доказује измерену доступност ваше апликације.

На пример, временски мерена доступност од 99,9 % дозвољава 43,2 минута недоступности у месецу од 30 дана. SLO заснован на захтевима има другачији именилац. Ниједна мера не говори колико података можете да изгубите нити гарантује најдуже трајање појединачног прекида.

Разумите границе отказа

AWS Availability Zone, односно AZ, изолована је инфраструктурна локација унутар региона (Region). Регион садржи више AZ зона. Дизајн у више региона распоређује компоненте радног система у различите регионе. Други добављачи имају сопствене границе и понашање сервиса; испитајте изабрани сервис.

Ово су могућности дизајна, а не гаранције доступности. Ознака не доказује да свака потребна компонента користи намеравану границу.

Пратите целу путању захтева

Размотримо измишљен сервис за резервације. Веб-реплике раде у две AZ зоне. Обе користе једну базу и један излазни мрежни пролаз у зони AZ A. Пролаз је потребан за позивање добављача плаћања.

Ако AZ A откаже, веб-реплика у зони AZ B може да остане исправна док резервација и даље не успева. Тим мора да процени базу, мрежну путању, добављача идентитета, зависност од плаћања и усмеравање. Испитајте стварни режим управљане базе: репликација, прелазак на резервну инстанцу и понашање компоненти за читање разликују се према производу и конфигурацији.

Проверите и капацитет. Преостали ресурси морају да поднесу потребно оптерећење. Дизајн који се ослања на стварање капацитета током инцидента зависи од квота, доступних ресурса и операција управљачког слоја.

Спроведите контролисану вежбу са дефинисаном границом, условима заустављања и одговорном особом. Проверите потпуну резервацију, укључујући усаглашавање плаћања. Забележите неуспеле захтеве и време до опоравка употребљивог рада.

Одлучите да ли други регион решава проблем

Рад у више региона додаје пренос података, дуплиране ресурсе, координацију постављања и оперативни рад. Active/passive држи једно окружење спремно да преузме саобраћај. Active/active обрађује саобраћај у више окружења. Потребна спремност и понашање података разликују се.

За сервис резервација истовремени уписи отварају питање: могу ли два региона да продају исто седиште? Дефинишите ко има право да потврди резервацију и како систем ради током прекинуте репликације. „Реплицирајте базу” није потпун одговор.

Проверите дозвољене локације података, кључеве за шифровање, сертификате, DNS, тајне и спољне сервисе. Отказ заједничког сервиса идентитета или лоша верзија могу да погоде више региона. Више локација не уклања сваки заједнички узрок.

Повежите доступност са опоравком

HA обрађује одређене отказе током рада. Опоравак од катастрофе обнавља употребљив сервис и његове податке после догађаја који прекида рад. Сервис у више региона и даље захтева план опоравка за брисање или оштећење података.

Документујте изабране сценарије отказа и оне које пословање прихвата. Усклађујте тестове и дефиниције инфраструктуре док се апликација мења. Наставите са RTO, RPO и опоравком од катастрофе.