Восстановление после прерывания работы служб во всем регионе

Статья
03/21/2023

Azure физически и логически разделяется на единицы, называемые регионами. Регион состоит из одного или нескольких центров обработки данных, расположенных в непосредственной близости друг от друга. Многие регионы и службы также поддерживают зоны доступности, которые можно использовать для обеспечения дополнительной устойчивости к сбоям в отдельном центре обработки данных. Мы рекомендуем использовать регионы с зонами доступности, чтобы вы могли улучшить доступность решения.

В редких случаях объекты во всей зоне доступности или регионе могут стать недоступными, например из-за сбоев сети. Или объекты могут быть полностью потеряны, например, из-за стихийного бедствия. Azure позволяет создавать приложения, которые распределены по зонам и регионам. Такое распределение помогает минимизировать вероятность того, что сбой в одной зоне или регионе повлияет на другие зоны или регионы.

Облачные службы

Управление ресурсами

Вы можете распределить вычислительные операции по регионам, создав отдельную облачную службу в каждом целевом регионе и опубликовав пакет развертывания в каждой из служб. Однако распределение трафика между облачными службами в разных регионах должно быть реализовано разработчиком приложения или службой управления трафиком.

Определение необходимого количества запасных экземпляров роли, которые нужно предварительно развертывать для аварийного восстановления, — это важный аспект планирования ресурсов. Наличие полномасштабной дополнительной развернутой службы гарантирует, что при необходимости ресурсы уже будут доступны, однако стоимость при этом увеличится вдвое. Распространенный подход — развернуть небольшую дополнительную службу, достаточную для запуска критически важных служб. Это целесообразно для создания резервной мощности и тестирования конфигурации дополнительной среды.

Примечание

Квота подписки не гарантирует наличие ресурсов. Квота — просто кредитный лимит. Чтобы обеспечить достаточное количество ресурсов, в модели службы нужно задать необходимое количество ролей, при этом роли должны быть развернуты.

Балансировка нагрузки

Чтобы распределить нагрузку по трафику между регионами, требуется решение по управлению трафиком. Azure предоставляет диспетчер трафика Azure. Кроме того, вы можете воспользоваться сторонними службами, которые предоставляют аналогичные возможности по управлению трафиком.

Стратегии

Существует множество альтернативных стратегий для реализации распределенных вычислительных ресурсов в разных регионах. Они должны быть приспособлены к конкретным бизнес-требованиям и обстоятельствам применения приложения. В сущности, подходы можно разделить на следующие категории.

Повторное развертывание после аварии — этот подход предусматривает повторное развертывание приложения с нуля в случае аварии. Это подходит для некритических приложений, для которых не требуется гарантированное время восстановления.
Warm Spare (активный и пассивный): в альтернативном регионе создается вторичная размещенная служба, а роли развертываются для обеспечения минимальной емкости; однако роли не получают рабочий трафик. Этот подход можно использовать для приложений, которые не предназначены для распределения трафика по регионам.
Горячая замена (активная/активная). Приложение предназначено для получения рабочей нагрузки в нескольких регионах. Кроме того, облачные службы могут масштабироваться по мере необходимости во время аварии и отработки отказа. Кроме того, в случае необходимости облачные службы можно развернуть при аварии и отработке отказа. включая малое и гарантированное время восстановления, непрерывное тестирование всех расположений для восстановления и эффективное использование ресурсов.

Полное описание распределенной архитектуры выходит за рамки данного документа. Дополнительные сведения см. в статье Аварийное восстановление и высокий уровень доступности для приложений Azure.

Виртуальные машины

Восстановление виртуальных машин IaaS ("инфраструктура как услуга") во многом подобно восстановлению вычислений приложений PaaS ("платформа как услуга"). Однако между ними есть важные различия, потому что виртуальная машина IaaS включает в себя как саму виртуальную машину, так и диск виртуальной машины.

Использование службы архивации Azure для создания согласованных межрегиональных резервных копий приложения. службы архивации Azure пользователи могут создавать согласованные резервные копии приложения с нескольких дисков виртуальных машин и поддерживать репликацию резервных копий по регионам. Для этого при создании хранилища резервных копий для него нужно выбрать георепликацию. Репликацию хранилища резервных копий необходимо настроить во время создания. Ее нельзя настроить позже. В случае потери региона корпорация Майкрософт делает резервные копии доступными для пользователей. Благодаря этому пользователи могут восстановить данные в любой из своих настроенных точек восстановления.
Разделение диска данных и диска операционной системы. Важным аспектом использования виртуальных машин IaaS является то, что нельзя изменить диск операционной системы без повторного создания виртуальной машины. Это не проблема, если стратегия восстановления заключается в повторном развертывании после аварии. Тем не менее это может стать проблемой, если вы используете подход "теплой замены" для резервной мощности. Чтобы правильно реализовать этот подход, и в основном, и в дополнительном расположениях должен быть развернут правильный диск операционной системы, а данные приложений должны храниться на отдельном диске. По возможности используйте стандартную конфигурацию операционной системы, которая может быть предоставлена в обоих расположениях. После отработки отказа следует подключить диск данных к имеющимся виртуальным машинам IaaS на дополнительном контроллере домена. Используйте AzCopy для копирования моментальных снимков дисков с данными на удаленный сайт.
Помните о потенциальных проблемах согласованности после географической отработки отказа нескольких дисков виртуальных машин. Диски виртуальных машин реализуются в виде больших двоичных объектов службы хранилища Azure и имеют одинаковые характеристики георепликации. Если служба архивации Azure не используется, нет гарантий согласованности между дисками, так как георепликация выполняется асинхронно и диски реплицируются независимо друг от друга. При сбое отдельные диски виртуальных машин гарантированно будут в состоянии отказоустойчивости после географической отработки отказа, но они не будут согласованы между собой. В некоторых случаях (например, в случае чередования дисков) это может вызвать проблемы.
Используйте azure Site Recovery для репликации приложений между регионами. При использовании Azure Site Recovery клиентам не нужно беспокоиться о разделении дисков данных от дисков операционной системы или о потенциальных проблемах согласованности. Azure Site Recovery реплицирует рабочие нагрузки, выполняемые на физических и виртуальных машинах, из первичного сайта (локального или в Azure) в дополнительное расположение (в Azure). При возникновении сбоя на первичном сайте клиента можно активировать отработку отказа, чтобы быстро вернуть клиента в рабочее состояние. После восстановления основного расположения клиенты могут восстановить размещение. Они могут легко реплицироваться с помощью точек восстановления с моментальными снимками, согласованными с приложениями. Эти моментальные снимки записывают данные о дисках, все данные в памяти и все внутрипроцессные транзакции. Azure Site Recovery позволяет клиентам поддерживать целевые значения времени восстановления (RTO) и целевые точки восстановления (RPO) в пределах организации. Клиенты также могут легко выполнять отработки аварийного восстановления, не затрагивая приложения в рабочей среде. Используя планы восстановления, клиенты могут последовательно выполнять отработку отказа и восстановление многоуровневых приложений, работающих на нескольких виртуальных машинах. Они могут группировать компьютеры в рамках плана восстановления и при необходимости добавлять скрипты и действия, выполняемые вручную. Планы восстановления можно интегрировать с служба автоматизации Azure модулями Runbook.

Память

Восстановление с использованием геоизбыточного хранилища дискового пространства больших двоичных объектов, таблиц, очередей и виртуальных машин

В Azure все большие двоичные объекты, таблицы, очереди и диски виртуальных машин по умолчанию являются геореплицируемыми. Это называется геоизбыточным хранилищем (GRS). GRS реплицирует данные хранилища в сопряженный центр обработки данных, расположенный в сотнях миль друг от друга в пределах определенного географического региона. Хранилище GRS обеспечивает дополнительный уровень надежности на случай серьезной аварии в центре обработки данных. Корпорация Майкрософт контролирует отработку отказа. Она происходит только в случае серьезной аварии, при которой восстановить исходное основное расположение в разумные сроки невозможно. В некоторых случаях на это может уйти несколько дней. Данные обычно реплицируются несколько минут, хотя интервал синхронизации еще не регламентирован соглашением об уровне обслуживания.

При выполнении географической отработки отказа способ доступа к учетной записи не изменится (URL-адрес и ключ учетной записи не изменятся). Однако после отработки отказа учетная запись хранения будет находиться в другом регионе. Это может повлиять на приложения, которые должны находиться в одном регионе с учетной записью хранения. Даже если используются службы и приложения, для которых необязательно, чтобы учетная запись хранения находилась в том же центре обработки данных, задержки связи между центрами обработки данных и расходы, связанные с пропускной способностью, могут послужить вескими причинами для временного перемещения трафика в регион отработки отказа. Это может повлиять на общую стратегию аварийного восстановления.

Помимо автоматической отработки отказа, предоставляемой в GRS, в Azure появилась служба, которая предоставляет доступ для чтения копии данных в расположении дополнительного хранилища. Это называется геоизбыточным хранилищем с доступом на чтение (RA-GRS).

Дополнительные сведения о хранилище GRS и RA-GRS см. в статье Репликация службы хранилища Azure.

Сопоставления регионов георепликации

Важно знать, в какой регион выполняется георепликация, чтобы понимать, где развертывать другие экземпляры данных, которые должны находиться в одном регионе с хранилищем данных. Дополнительные сведения см. в статье Парные регионы Azure.

Расходы, связанные с георепликацией

Георепликация включена в текущую стоимость службы хранилища Azure. Это называется геоизбыточным хранилищем (GRS). Если вы не хотите, чтобы данные геореплицировались, можно отключить георепликацию для учетной записи. Это называется локально избыточное хранилище (LRS) и оплачивается по сниженной цене по сравнению с GRS.

Как определить, что произошла географическая отработка отказа

При географической отработке отказа сведения о ней публикуются на панели мониторинга работоспособности служб Azure. Однако приложения могут автоматически определять это, наблюдая за географическим регионом своей учетной записи хранения. Это можно использовать для запуска других операций восстановления, например активации вычислительных ресурсов в географическом регионе, в который перемещено их хранилище. Для этого можно отправить запрос из API управления службами с помощью процедуры получения свойств учетной записи хранения. Необходимы следующие свойства:

<GeoPrimaryRegion>primary-region</GeoPrimaryRegion>
<StatusOfPrimary>[Available|Unavailable]</StatusOfPrimary>
<LastGeoFailoverTime>DateTime</LastGeoFailoverTime>
<GeoSecondaryRegion>secondary-region</GeoSecondaryRegion>
<StatusOfSecondary>[Available|Unavailable]</StatusOfSecondary>

База данных

База данных SQL

База данных SQL Azure предоставляет два типа восстановления данных: геовосстановление и активная георепликация.

Геовосстановление

Геовосстановление также доступно для баз данных уровней "Базовый", "Стандартный" и "Премиум". Она используется по умолчанию, когда база данных недоступна из-за происшествия в регионе, где она размещена. Как и для функции восстановления до точки во времени, при геовосстановлении используются резервные копии базы данных из геоизбыточного хранилища Azure. Восстановление выполняется на основе резервной копии из удаленного хранилища, что позволяет защитить базу данных от сбоев в основном регионе. См. дополнительные сведения о восстановлении базы данных SQL Azure или отработке отказа на базу данных-получатель.

Активная георепликация

Активная георепликация доступна для всех уровней баз данных. Она рассчитана на приложения, которые предъявляют более высокие требования к восстановлению по сравнению с теми, которые может обеспечить обычное геовосстановление. С использованием активной георепликации можно создать до четырех вторичных баз данных в режиме чтения на серверах в разных регионах. Отработку отказа можно выполнить на любую из баз данных-получателей. Кроме того, активную георепликацию можно применять при обновлении приложений и их перемещении, а также при балансировке нагрузки для рабочих нагрузок только для чтения. Дополнительные сведения см. в статье Настройка активной георепликации для Базы данных SQL Azure и запуск отработки отказа. Дополнительные сведения о разработке и реализации приложений и их обновлении без простоев см. в статьях Разработка глобально доступных служб с помощью Базы данных SQL Azure и Управление последовательными обновлениями для облачных приложений с помощью активной георепликации Базы данных SQL.

SQL Server в виртуальных машинах Azure

Существуют различные способы восстановления и обеспечения высокой доступности службы SQL Server 2012 (и более поздних версий), работающей в виртуальных машинах Azure. Дополнительные сведения см. в статье Высокий уровень доступности и аварийное восстановление для SQL Server на виртуальных машинах Azure.

Другие службы платформы Azure

При попытке запуска облачной службы в нескольких регионах Azure необходимо учитывать последствия каждой зависимости. В следующих разделах представлено руководство по конкретным службам для пользователей, которым нужно использовать ту же службу Azure в альтернативном центре обработки данных Azure. Это включает в себя как задачи конфигурации, так и задачи репликации данных.

Примечание

В некоторых случаях эти действия помогают устранить сбой конкретной службы, а не целое событие в центре обработки данных. Если говорить о приложении, сбой конкретной службы тоже может ограничивать работу службы и требовать временного переноса ее в альтернативный регион Azure.

Cлужебная шина

Служебная шина Azure использует уникальное пространство имен, которое не охватывает регионы Azure. Поэтому первым требованием является настройка необходимых пространств имен служебной шины в альтернативном регионе. Тем не менее нужно также учитывать факторы, касающиеся надежности сообщений в очереди. Существует несколько стратегий репликации сообщений в регионах Azure. Дополнительные сведения об этих стратегиях репликации и других стратегиях аварийного восстановления см. в статье Рекомендации по изолированию приложений от простоев и аварий служебной шины.

Служба приложений

Чтобы переместить приложение Azure службы приложений Azure, например веб-приложение или мобильное приложение, в дополнительный регион Azure, требуется резервная копия веб-сайта, доступная для публикации. Если сбой охватывает лишь часть центра обработки данных Azure, можно использовать FTP для скачивания последней резервной копии содержимого веб-сайта. После этого создайте приложение в альтернативном регионе, если вы не сделали это ранее для обеспечения резервной мощности. Опубликуйте сайт в новом регионе и внесите все необходимые изменения конфигурации. Эти изменения могут включать строки подключения к базе данных или другие параметры для конкретного региона. При необходимости добавьте SSL-сертификат сайта и измените запись DNS CNAME, чтобы имя личного домена указывало на URL-адрес повторно развернутого веб-приложения Azure.

HDInsight

Данные, связанные с HDInsight, по умолчанию сохраняются в хранилище BLOB-объектов Azure. HDInsight требует, чтобы задания MapReduce для обработки кластера Hadoop размещались в том же регионе, что и учетная запись хранения, содержащая анализируемые данные. Используя функцию георепликации, доступную для службы хранилища Azure, вы можете получить доступ к своим данным в дополнительном регионе, в который они были реплицированы, если по какой-то причине основной регион больше недоступен. Вы можете создать кластер Hadoop в том регионе, в который были реплицированы данные, и продолжить их обработку.

Служба отчетов SQL Reporting

В настоящее время для восстановления после потери региона Azure требуется наличие нескольких экземпляров службы SQL Reporting в разных регионах Azure. Эти экземпляры службы SQL Reporting должны получать доступ к одним и тем же данным, и эти данные должны иметь собственный план восстановления на случай аварии. Вы также можете создать внешние резервные копии RDL-файла для каждого отчета.

Службы мультимедиа

Для кодирования и потоковой передачи службы мультимедиа Azure используют разные способы восстановления. При региональном сбое, как правило, потоковая передача является более важной. Чтобы подготовиться к этому, вы должны иметь учетную запись служб мультимедиа в двух разных регионах Azure. Закодированное содержимое должно быть расположено в обоих регионах. Во время сбоя вы можете перенаправить потоковый трафик в альтернативный регион. Кодирование может выполняться в любом регионе Azure. Если для кодировки важно время выполнения, например во время обработки интерактивного события, вы должны быть готовы к отправке заданий в альтернативный центр обработки данных во время сбоев.

Виртуальная сеть

Файлы конфигурации обеспечивают самый быстрый способ настройки виртуальной сети в альтернативном регионе Azure. После настройки виртуальной сети в основном регионе Azure экспортируйте параметры текущей виртуальной сети в файл конфигурации сети. Если в основном регионе происходит сбой, восстановите виртуальную сеть из сохраненного файла конфигурации. Затем настройте другие облачные службы, виртуальные машины или распределенные параметры для работы с новой виртуальной сетью.
Существуют ресурсы, связанные с виртуальной сетью, которые необходимо учитывать (например, NSG, DNS, таблицы маршрутов). Метод, описанный в разделе Инфраструктура как код, является способом создания одной и той же среды каждый раз, и вы можете выполнить развертывание в новом регионе.

Контрольные списки для аварийного восстановления

Контрольный список для облачных служб

Просмотрите раздел "Облачные службы" этого документа.
Создайте межрегиональную стратегию аварийного восстановления.
Оцените преимущества и недостатки резервирования ресурсов в альтернативных регионах.
Используйте средства маршрутизации трафика, такие как диспетчер трафика Azure.

Контрольный список для виртуальных машин

Просмотрите раздел "Виртуальные машины" этого документа.
Используйте службу архивации Azure для создания согласованных резервных копий приложения по регионам.

Контрольный список для хранилища

Просмотрите раздел "Хранилище" этого документа.
Не отключайте георепликацию ресурсов хранилища.
Сведения об альтернативном регионе для георепликации в случае отработки отказа.
Создайте пользовательские стратегии архивирования для управляемых пользователем стратегий отработки отказа.

Контрольный список для Базы данных SQL

Просмотрите раздел "База данных SQL" этого документа.
При необходимости используйте геовосстановление или георепликацию .

Контрольный список для SQL Server на виртуальных машинах

Просмотрите раздел "SQL Server на виртуальных машинах" этого документа.
Используйте межрегиональные группы доступности AlwaysOn или зеркальное отображение базы данных.
Можно также использовать архивацию и восстановление в хранилище BLOB-объектов.

Контрольный список для служебной шины

Просмотрите раздел "Служебная шина" этого документа.
Настройте пространство имен служебной шины в альтернативном регионе.
Рассмотрите пользовательские стратегии репликации для сообщений между регионами.

Контрольный список для службы приложений

Просмотрите раздел "Служба приложений" этого документа.
Сохраните резервные копии сайта за пределами основного региона.
Если сбой частичный, попробуйте получить доступ к текущему сайту при помощи протокола FTP.
Спланируйте развертывание сайта на новом или существующем сайте в альтернативном регионе.
Создайте план изменений конфигурации для приложения и для записей DNS CNAME.

Контрольный список для HDInsight

Просмотрите раздел "HDInsight" этого документа.
Создайте новый кластер Hadoop в регионе с реплицированными данными.

Контрольный список для службы SQL Reporting

Просмотрите раздел "Служба SQL Reporting" этого документа.
Настройте альтернативный экземпляр службы SQL Reporting в другом регионе.
Разработайте отдельный план для репликации целевых данных в этот регион.

Контрольный список для служб мультимедиа

Просмотрите раздел "Службы мультимедиа" этого документа.
Создайте учетную запись служб мультимедиа в альтернативном регионе.
Закодируйте одинаковое содержимое в обоих регионах для поддержки отработки отказа потоковой передачи.
Отправьте задания кодирования в альтернативный регион, если работа службы нарушена.

Контрольный список для виртуальной сети

Просмотрите раздел "Виртуальная сеть" этого документа.
Используйте экспортированные параметры виртуальной сети, чтобы повторно создать ее в другом регионе.

Share via