Шаблоны Multi-AZ для сервисов с состоянием

Сервисы с состоянием — базы данных, кэши и файловые системы — сложнее всего сделать высокодоступными, поскольку они хранят данные, которые должны пережить сбои. Если база данных в одной AZ выходит из строя, всё приложение теряет хранилище данных. Ответ AWS — это развёртывания Multi-AZ, в которых сервис поддерживает синхронную или почти синхронную реплику во второй зоне доступности, способную быстро принять нагрузку при отказе основной.

RDS Multi-AZ поддерживает синхронную резервную реплику в другой AZ. Каждая запись в основной экземпляр синхронно реплицируется до подтверждения успешного выполнения — это означает отсутствие потери данных (RPO=0), но немного увеличивает задержку записи. При отказе основного экземпляра RDS автоматически обновляет конечную точку DNS, чтобы направить её на резервный экземпляр, в течение 60–120 секунд. Приложению достаточно повторно подключиться к той же конечной точке — изменения кода не требуются.

Amazon Aurora развивает Multi-AZ благодаря общему распределённому уровню хранения, который автоматически реплицирует данные в шесть копий в трёх AZ. Экземпляры Aurora не хранят состояние — они выполняют чтение и запись в это общее хранилище. Когда основной экземпляр Aurora, выполняющий записи, выходит из строя, реплика для чтения в другой AZ повышается до роли экземпляра для записи менее чем за 30 секунд. Это быстрее, чем переключение RDS Multi-AZ при отказе, а данные всегда согласованы между AZ без явной репликации на резервный экземпляр.

ElastiCache for Redis поддерживает Multi-AZ с помощью групп репликации. Основной узел принимает записи и асинхронно реплицирует их на реплики для чтения в других AZ. Когда основной узел выходит из строя, ElastiCache автоматически повышает одну из реплик до роли основного узла. В режиме кластера Redis с включённым режимом кластера данные распределяются между несколькими группами узлов, в каждой из которых есть собственный основной узел и реплики в разных AZ. Это обеспечивает одновременно высокую доступность и горизонтальное масштабирование.

Amazon Elastic File System (EFS) изначально поддерживает Multi-AZ: это региональная служба, которая избыточно хранит данные в нескольких AZ одного региона. Вы создаёте точки монтирования в подсети каждой AZ, а экземпляры EC2 в любой AZ могут подключать файловую систему через локальную точку монтирования. Ручная настройка Multi-AZ не требуется. EFS предоставляет общее файловое хранилище POSIX, к которому несколько экземпляров в разных AZ получают одновременный доступ.

Elastic Load Balancers сами поддерживают Multi-AZ: ALB и NLB разворачивают узлы балансировщика в каждой указанной вами AZ. При включённой балансировке нагрузки между зонами (по умолчанию для ALB) каждый узел балансировщика равномерно распределяет трафик между всеми зарегистрированными целями во всех AZ, а не только в своей AZ. Благодаря этому, даже если все экземпляры в одной AZ выйдут из строя, балансировщик продолжит обслуживать трафик через экземпляры в остальных AZ.

Распространённая ошибка — развернуть один NAT Gateway в одной AZ, тогда как частные подсети в других AZ направляют трафик через него. Если эта AZ выйдет из строя, все частные экземпляры потеряют доступ к интернету. Правильный шаблон Multi-AZ — развернуть по одному NAT Gateway в каждой AZ и настроить таблицу частной маршрутизации каждой AZ так, чтобы маршрут 0.0.0.0/0 проходил через собственный NAT Gateway этой AZ. Это устраняет NAT Gateway как единую точку отказа между AZ и снижает расходы на передачу данных между AZ.

DynamoDB — это полностью управляемая служба, которая автоматически реплицирует данные в трёх AZ одного региона, поэтому настраивать Multi-AZ вручную не требуется. Перед возвратом успешного результата каждая запись надёжно сохраняется во всех трёх AZ. DynamoDB фактически обеспечивает отказоустойчивость на уровне AZ сразу после создания. Поэтому DynamoDB часто рекомендуют выбирать в качестве базы данных, когда в экзаменационном вопросе подчёркивается высокая доступность при минимальных эксплуатационных затратах.

Во время переключения RDS Multi-AZ приложения, поддерживающие постоянные подключения к базе данных, могут столкнуться со сбоями при изменении конечной точки. RDS Proxy располагается между приложением и RDS и поддерживает пул подключений к базе данных. Во время переключения RDS Proxy автоматически перенаправляет подключения к новому основному экземпляру, сокращая влияние переключения с 60–120 секунд до менее 30 секунд для приложений, использующих конечную точку прокси. RDS Proxy также помогает при работе с функциями Lambda, которые создают множество краткоживущих подключений.

Понимание режимов репликации крайне важно при выборе шаблонов Multi-AZ. Синхронная репликация (RDS Multi-AZ, EFS) обеспечивает RPO=0, поскольку каждая запись подтверждается в обеих AZ до возврата успешного результата. Компромисс заключается в немного большей задержке записи. Асинхронная репликация (реплики ElastiCache Redis, реплики RDS для чтения) обеспечивает меньшую задержку записи, но допускает небольшое отставание репликации — это означает, что часть данных может быть потеряна, если основной экземпляр выйдет из строя до завершения репликации.

Следует регулярно тестировать переключение Multi-AZ, чтобы проверять обоснованность предположений о RTO. Для RDS можно запустить переключение с помощью параметра консоли Перезагрузка с переключением или CLI. Отслеживайте в CloudWatch метрику FailedSQLServerAgentJobsCount и журналы приложения, чтобы убедиться, что оно успешно переподключается. Документируйте фактическую продолжительность переключения: она может отличаться от указанной в документации AWS в зависимости от класса экземпляра и рабочей нагрузки.

Проверьте своё понимание концепций AWS Solutions Architect (SAA-C03), рассмотренных в этом уроке.

В этом уроке вы узнали, что RDS Multi-AZ использует синхронную репликацию с автоматическим переключением DNS, Aurora использует общий уровень хранения в трёх AZ для более быстрого переключения, а EFS и DynamoDB изначально поддерживают Multi-AZ без ручной настройки. Разворачивайте по одному NAT Gateway в каждой AZ, чтобы избежать единых точек отказа между AZ. Далее мы рассмотрим шаблоны active-active и active-passive в нескольких регионах.