Проектирование географически распределенной архитектуры данных
Последний аспект архитектуры приложения, который следует продумать, — это уровень хранилища данных. Необходимо сделать так, чтобы после сбоя в масштабе всего региона данные оставались доступны для чтения и записи с сохранением всей функциональности.
На портале отслеживания поставок мы решили использовать Azure Front Door для отправки всех запросов в Служба приложений в регионе "Восточная часть США". Если регион "Восточная часть США" завершается ошибкой, Front Door обнаруживает сбой и отправляет запросы на дублирование компонентов Служба приложений в регионе "Западная часть США". В изначальной архитектуре с одним регионом реляционные данные хранились в базе данных SQL Azure, а частично структурированные — в Cosmos DB. Теперь мы хотим понять, как мы можем убедиться, что обе базы данных остаются доступными, если регион "Восточная часть США" завершается ошибкой.
Здесь мы узнаем, как реплика te данные между регионами и как обеспечить быструю отработку отказа при необходимости.
База данных SQL Azure
Чтобы создать реализацию базы данных SQL Azure в нескольких регионах для хранения реляционных данных, можно использовать один из следующих способов:
- Активная георепликация
- группы автоматической отработки отказа.
Активная георепликация
Служба "База данных SQL Azure" может автоматически реплицировать базу данных и все ее изменения в другую базу данных с помощью функции активной георепликации. Копия базы данных, доступная для записи, размещается только на основном логическом сервере. Можно создать до четырех логических серверов, на которых будут размещаться копии базы данных только для чтения.
Для портала отслеживания поставок создайте базу данных-получатель в регионе "Западная часть США" и настройте гео-реплика из региона "Восточная часть США". При возникновении регионального сбоя Front Door перенаправляет запросы пользователей на Служба приложений в регионе "Западная часть США". Служба приложений и Функции Azure могут получить доступ к реляционным данным, так как копия уже реплика в регионе "Западная часть США".
Переключение происходит автоматически, но помните, что база данных-получатель в западной части США доступна только для чтения. Если пользователь попытается изменить данные, например создать отправление, может произойти ошибка. Мы можем вручную инициировать отработку отказа на западную часть США, как только мы заметим проблему в портал Azure. Чтобы автоматизировать этот процесс, разработчики могут написать код, который вызывает метод failover из REST API базы данных SQL Azure.
Примечание.
Управляемые экземпляры базы данных SQL Azure не поддерживают активную георепликацию. Они предназначены для упрощения переноса данных с локального сервера SQL Server без снижения уровня безопасности. Если вы используете управляемый экземпляр, рассмотрите возможность использования групп отработки отказа.
группы автоматической отработки отказа.
Группа автоматической отработки отказа — это группа баз данных, в которой данные автоматически реплицируются с сервера-источника на один или несколько серверов-получателей. Такая схема похожа на активную георепликацию, и в ней применяется тот же метод репликации данных. Однако можно автоматизировать реакцию на сбой, определив политику.
На портале доставки мы создадим базу данных-получатель в регионе "Западная часть США". Затем мы добавим политику, которая выполняет отработку отказа первичной реплика базы данных на западную часть США, если катастрофический сбой происходит в регионе "Восточная часть США". При этом реплика в западной части США автоматически становится базой данных-источником, доступной для записи, с сохранением всей функциональности.
Группу автоматической отработки отказа рекомендуется использовать, если требуется автоматизировать отработку отказа доступной для записи базы данных без написания пользовательского кода для ее активации. Кроме того, используйте группы автоматической отработки отказа, если база данных выполняется в управляемом экземпляре База данных SQL Azure.
Важно!
Как активная георепликация, так и группы автоматической отработки отказа предполагают асинхронную репликацию. Когда к первичной реплике применяется изменение, клиенту отправляется подтверждение. После этого транзакция считается завершенной, и выполняется репликация. В случае сбоя может оказаться, что последние изменения, внесенные в базу данных-источник, еще не были реплицированы во вторичную реплику. Учтите, что после аварии последние изменения в базе данных могут быть утеряны.
Azure Cosmos DB
Наша конфигурация менее сложна с Azure Cosmos DB, так как она разработана как многорегиональная облачная система базы данных. Cosmos DB — это многомодельная база данных, позволяющая хранить реляционные, частично структурированные и другие формы данных. Даже если Cosmos DB выполняется в одном регионе, для повышения уровня доступности данные реплицируются в несколько экземпляров в разных доменах сбоя.
При создании учетной записи Cosmos DB в нескольких регионах можно выбрать один из указанных ниже режимов.
Учетные записи для нескольких регионов с несколькими регионами записи.
В этом режиме все копии базы данных всегда записываются. В случае сбоя в регионе отработка отказа не требуется.
Учетные записи для нескольких регионов с одним регионом записи.
В этом режиме записываемые базы данных находятся только в основном регионе. Данные, реплицируемые в дополнительные регионы, доступны только для чтения. В случае сбоя основного региона изменения по умолчанию отключены. Однако можно включить автоматический переход на другой ресурс, чтобы служба Cosmos DB автоматически выполняла отработку отказа для основной доступной для записи копии базы данных в другой регион.
Важно!
В Cosmos DB репликация данных осуществляется синхронно. При применении изменения транзакция не считается завершенной до тех пор, пока не будет реплицирована в кворум реплик. После этого клиенту отправляется подтверждение. При возникновении сбоя последние изменения не теряются, так как репликация уже произошла.