У сервиса выездного обслуживания есть резервный регион. Приложение там запускается, база реплицируется, проверка доступности зелёная. Но при переключении диспетчер не может открыть фотографии неисправности: файлы остались на основной площадке. Вход нового сотрудника тоже не работает — служба авторизации зависит от неё же. Серверы переехали, работа компании — пока нет.
Такой сценарий полезнее обсуждения количества регионов. Он заставляет определить, что именно должно продолжить работать после потери площадки и какие зависимости понадобятся для этого. Второй комплект приложения защищает лишь ту часть процесса, которую действительно удалось сделать самостоятельной.
От какой аварии покупаем защиту
Несколько серверов внутри одного региона помогают пережить отказ отдельного узла. Размещение в разных зонах доступности расширяет эту защиту, но не устраняет региональные зависимости. Multi-Region нужен для другого масштаба события: когда основная площадка недоступна целиком либо продолжать работу в ней небезопасно.
Сначала стоит описать необходимый результат. Диспетчеры должны назначать исполнителей, сотрудники — видеть задания и прикладывать документы. Историческую аналитику, возможно, допустимо восстановить позже. Для этих процессов согласуют предельное время восстановления и допустимую потерю последних изменений — RTO и RPO. Это цели, которые ещё предстоит подтвердить проверкой, а не свойства, возникающие после оплаты второй площадки.
Близость к пользователям — отдельный аргумент. Она может оправдать региональное размещение, даже когда аварийного переключения нет. Но быстрый локальный экран ничего не говорит о том, сможет ли человек продолжить работу после отказа источника данных.
Два работающих региона не обязательно принимают любые записи
При active-passive основную работу выполняет один регион. Второй может быть полностью готов к приёму нагрузки, работать с уменьшенной мощностью или требовать запуска дополнительных компонентов. Во всех случаях нужно честно учитывать время до готовности, включая получение ресурсов и загрузку данных.
При active-active оба региона обслуживают пользователей уже в обычном режиме. Однако это не означает, что любой из них вправе одновременно менять любую запись. Компания может закрепить клиентов за регионами или оставить единый путь записи, распределив чтение. Правила владения данными важнее самого названия схемы.
Для нашей службы разница проявится при назначении мастера. Если два региона независимо считают одно время свободным, оба могут подтвердить выезд. Способ разрешения такого конфликта нельзя отложить до аварии. Нужно либо заранее предотвращать противоречивые назначения, либо определить допустимое поведение продукта при потере связи.
Самая неприятная потеря — уже подтверждённое изменение
Асинхронная репликация допускает промежуток между записью в основном регионе и появлением её на резервной стороне. При аварии там может не оказаться последних изменений, которые приложение уже подтвердило пользователю. Среднее небольшое отставание не доказывает, что под перегрузкой промежуток останется таким же.
Синхронное подтверждение через несколько площадок даёт другие гарантии в пределах выбранной технологии и конфигурации. За них приходится платить задержкой и зависимостью записи от доступности нужных участников. Формула «сделаем одновременно быстро, всегда доступно и без конфликтов» здесь не является проектом. Эти компромиссы подробно разобраны в руководстве AWS по данным между регионами.
После переключения придётся сверить незавершённые назначения, загруженные файлы и ответы партнёров. Исчезновение записи из восстановленной базы не отменяет выезда, который уже принял исполнитель. Повторять такие действия вслепую опасно; нужны устойчивые идентификаторы и способ проверить фактическое состояние операции.
Кто разрешает запись после переключения
Сетевой разрыв не всегда означает, что прежний регион выключился. Он может продолжать обслуживать часть клиентов, пока резервная сторона считает его потерянным. Для системы с одним владельцем записи необходим механизм, не допускающий двух одновременно действующих владельцев: например, контролируемое лидерство и проверка полномочий на запись средствами выбранной платформы.
Перевод адреса в DNS сам по себе эту задачу не решает. Часть клиентов сохранит старое соединение или ещё будет пользоваться прежним адресом. Поэтому маршрутизация и разрешение изменять данные должны быть согласованы, а не просто запущены рядом.
Отдельно определяют право объявить переключение. Автоматика может выполнять процедуру, но критерии её запуска, допустимая потеря данных и порядок действий при неоднозначной аварии должны быть утверждены заранее. Иначе компания впервые обсуждает эти решения, когда диспетчеры уже принимают заявки по телефону.
Проверяем весь рабочий маршрут
Нужны не только приложение и база. Файлы, очереди, ключи, сертификаты, вход сотрудников и доступ к партнёрским API должны работать с резервной стороны. Средства управления переключением тоже не должны требовать исправности основной площадки. Именно такой разбор предлагает проверка региональных зависимостей AWS.
В проверке службы обслуживания это означает пройти путь обычного сотрудника: войти, открыть существующее задание, назначить новое, приложить файл и получить подтверждение исполнителя. Тест только страницы входа оставит большинство важных вопросов без ответа.
Затем потребуется нагрузка, соответствующая аварийному режиму. Если оба региона обычно заняты своей работой, оставшийся должен выдержать согласованный объём после потери соседа. Расчёт на мгновенное увеличение мощности нужно проверить вместе с квотами, временем запуска и пределами зависимостей.
Вернуться назад — отдельная операция
После восстановления старой площадки на ней уже могут быть устаревшие данные. Возвращать туда трафик только потому, что серверы снова отвечают, нельзя. Сначала устанавливают актуальный источник, восстанавливают направление репликации, сверяют незавершённые действия и лишь затем выполняют обратный переход. Иногда разумнее временно оставить новый основной регион, чем торопиться ради привычной схемы.
В стоимость Multi-Region стоит включать эти упражнения, сопровождение конфигураций и проверку каждого существенного изменения. Для небольшого процесса с приемлемым длительным простоем восстановление из защищённых копий может оказаться достаточным. Для критичного — резерв стоит принимать по результатам полного переключения и возврата, а не по наличию зелёных серверов.
Подготовку людей, критериев переключения и испытаний описывает руководство по операционной готовности Multi-Region.