Экспорт (0) Печать
Развернуть все
Развернуть Свернуть

Техническое руководство по непрерывности бизнес-процессов для Azure

Обновлено: Июнь 2014 г.

Последнее обновление: Май 2014 г.

Дата первой публикации: Март 2012 г.

Авторы: Патрик Уиклайн (Patrick Wickline), Джейсон Рот (Jason Roth)

Соавторы и рецензенты: Луис Карлос Варгас Херринг (Luis Carlos Vargas Herring), Дрю Мак-Даниел (Drew McDaniel), Дейвид Магар (David Magar), Ганеш Сринивасан (Ganesh Srinivasan), Милан Гада (Milan Gada), Нир Машковски (Nir Mashkowski), Харш Миттал (Harsh Mittal), Саша Носов (Sasha Nosov), Сельцин Туркаршан (Selcin Turkarslan), Кепас Лин (Cephas Lin), Шерил Мак-Гуаэр (Cheryl McGuire), Билл Матерс (Bill Mathers), Манди Олингер (Mandi Ohlinger), Сидни Хига (Sidney Higa), Майкл Грин (Michael Green), Хайди Стин (Heidi Steen), Метт Уинклер (Matt Winkler), Шейн Бурджес (Shayne Burgess), Ларри Франкс (Larry Franks), Бред Севертсон (Brad Severtson), Явор Георгиев (Yavor Georgiev), Гленн Гейли (Glenn Gailey), Тим Амман (Tim Ammann), Рупперт Кох (Ruppert Koch), Сет Манхейм (Seth Manheim), Абинав Гупта (Abhinav Gupta), Стив Даниельсон (Steve Danielson), Кори Сандерс (Corey Sanders), Джон Дойчер (John Deutscher)

Для обеспечения высокого уровня доступности и аварийного восстановления (DR) требуются знания в двух областях: 1) доскональное техническое понимание возможностей облачной платформы; 2) умение правильно создать архитектуру распределенной службы. Этот документ охватывает первую тему — возможности и ограничения платформы Azure с учетом непрерывности бизнес-процессов. В нем также упоминаются шаблоны архитектуры и разработки, но это не является основной темой документа. Читателю следует изучить материалы из раздела «Дополнительные ресурсы» и найти в них указания по разработке.

Информация разбита на следующие разделы:

  • 1. Восстановление после локальных сбоев . Физическое оборудование (например, диски, серверы и сетевые устройства) может отказать, а ресурсы во время пиковых нагрузок могут быть исчерпаны. В этом разделе описываются возможности, предоставляемые Azure для поддержания высокого уровня доступности в данных условиях.

  • 2. Восстановление от потери региона Azure. Отказы в значительном объеме редки, но возможны. Из-за сетевых сбоев или физических повреждений (в результате стихийных бедствий) могут оказаться изолированными целые регионы. В этом разделе объясняется, как использовать возможности Azure для создания приложений, охватывающих различные географические регионы.

  • 3. Восстановление из локальной системы в Azure. Облако значительно изменяет экономику восстановления при аварии, благодаря чему у организаций появляется возможность использовать Azure в целях создания второго местоположения для восстановления. Это обойдется в малую долю стоимости создания и обслуживания запасного центра обработки данных. В этом разделе объясняются возможности, предоставляемые Azure для расширения локального центра обработки данных в облако.

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

  • 5. Дополнительные ресурсы. Прочие важные ресурсы, касающиеся доступности и восстановления после сбоев в Azure.

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

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

  • Каждый экземпляр роли выполняется на собственной виртуальной машине (ВМ) и взаимодействует со своим КФ через гостевого агента (ГА). ГА собирает метрики ресурсов и узлов, включая использование ВМ, состояние, журналы, использование ресурсов, исключения и условия сбоя. КФ отправляет ГА запросы с настраиваемыми интервалами и перезагружает ВМ, если ГА не отвечает.

  • В случае аппаратного сбоя соответствующий КФ перемещает все экземпляры роли, которых это касается, на новый узел оборудования и реконфигурирует сеть для направления трафика туда.

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

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

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

  • Чтобы быть идемпотентной, длительная операция должна производить один и тот же эффект вне зависимости от количества выполнений, даже если она прервана в ходе выполнения.

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

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

Изначальное количество экземпляров, в которых выполняется та или иная роль, определяется ее конфигурацией. Администраторы должны изначально конфигурировать каждую из ролей для выполнения в двух и более экземплярах на основании ожидаемой нагрузки. Но экземпляры роли легко масштабировать в сторону увеличения и уменьшения при смене шаблонов использования. Это действие можно производить на портале Azure, в Windows PowerShell, в API управления службами или с помощью сторонних средств. КФ автоматически провизионирует все новые экземпляры и вставляет их в подсистему балансировки нагрузки для данной роли.

На основе автомасштабирования Azure (предварительная версия) можно поручить Azure автоматически масштабировать роли в зависимости от нагрузки. Автомасштабирование можно также программно встроить и настроить для облачной службы с помощью платформы наподобие блока автомасштабирования приложения (WASABi).

КФ использует два типа секций: домены обновления и домены отказоустойчивости.

  • Домены обновления используются для обновления экземпляров роли службы в группах. Azure развертывает экземпляры службы в нескольких доменах обновления. Для обновления на месте КФ останавливает все экземпляры в одном домене обновления, обновляет их и затем перезапускает, а уже затем переходит к новому домену обновления. Такой подход позволяет предотвратить недоступность всей службы в процессе обновления.

  • Домен отказоустойчивости определяет потенциальные точки сбоев оборудования или сети. Для любой роли более чем с одним экземпляром КФ обеспечивает, что экземпляры будут распределены по разным доменам отказоустойчивости, чтобы изолированные сбои оборудования не вредили работе службы. Риск серверных и кластерных сбоев в Azure управляется доменами отказоустойчивости.

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

Весь входящий трафик к веб-роли проходит через подсистему балансировки нагрузки без сохранения состояния, которая распределяет клиентские запросы между экземплярами роли. Отдельные экземпляры роли не имеют общих IP-адресов и не адресуются напрямую из Интернета. Для веб-ролей не сохраняются состояния, чтобы любой клиентский запрос можно было перенаправить любому экземпляру роли. Каждые 15 секунд вызывается событие StatusCheck. Его можно использовать для отображения того, готова ли роль к получению трафика, или она занята и должна быть исключена из ротации в подсистеме балансировки нагрузки.

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

В отличие от экземпляров роли PaaS данные, хранимые на дисках виртуальной машины, постоянны даже при перемещении виртуальной машины. Виртуальные машины Azure используют диски на ВМ, существующие в виде BLOB-объектов в хранилище Azure. Благодаря характеристикам доступности хранилища Azure данные, хранимые на дисках виртуальной машины, также легко доступны. Обратите внимание, что диск D: является исключением из этого правила. Диск D: по сути является физическим хранилищем на сервере, где размещена ВМ, и его данные при утилизации ВМ теряются. Диск D: предназначен только для временного хранения.

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

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

Если трафик ВМ должен быть распределен между ними, необходимо сгруппировать ВМ в облачной службе и сбалансировать нагрузку для конкретной конечной точки TCP или определяемой пользователем процедуры. Дополнительные сведения см. в разделе Виртуальные машины с балансировкой нагрузки. Если ВМ получают входные данные из другого источника (например, механизма очередей), подсистема балансировки нагрузки не требуется. Подсистема балансировки нагрузки определяет, следует ли отправлять трафик узлу, с помощью базовой проверки исправности. Также можно создать собственные пробы для реализации специфичных для приложения метрик исправности, которые будут определять, должна ли ВМ получать трафик.

Хранилище Azure — это базовая служба долговременного хранения данных для Azure, которая обеспечивает хранение BLOB-объектов, таблиц, очередей и дисковых хранилищ ВМ. В нем используется сочетание репликации и управления ресурсами для обеспечения высокого уровня доступности в одном центре обработки данных. Соглашение об уровне обслуживания в части доступности хранилища Azure гарантирует, что как минимум в 99,9 % случаев правильно отформатированные запросы на добавление, обновление, чтение и удаление данных будут успешно и правильно обработаны и что учетные записи хранения будут иметь возможность подключения к интернет-шлюзу.

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

Учетная запись хранения, созданная после 7 июня 2012 г., может содержать до 200 ТБ данных (вместо прежних 100 ТБ). Если необходимо дополнительное место, приложения должны быть спроектированы с учетом поддержки нескольких учетных записей хранения.

Диск виртуальной машины (ВМ) хранится как страничный BLOB-объект в хранилище Azure, что дает ему ту же надежность и те же свойства масштабируемости, какими обладает хранилище BLOB-объектов. В результате этого данные на диске виртуальной машины становятся постоянными даже после сбоя сервера, на котором выполняется ВМ, и перезапуска ее на другом сервере.

База данных SQL Microsoft Azure обеспечивает работу базы данных в качестве службы, благодаря которой приложения могут быстро провизионировать, вставлять данные в реляционные базы данных и выполнять запросы. Такая служба поддерживает многие известные функции SQL Server, не сталкиваясь с проблемами, которые связаны с оборудованием, настройкой конфигурации, применением обновлений и обеспечением гибкости.

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

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

Для каждой базы данных в момент создания настраивается верхний предел размера. Доступный в настоящий момент максимальный размер — 150 ГБ. Если база данных достигает верхнего предела по размеру, то все последующие команды INSERT и UPDATE будут отклоняться (запрос и удаление данных по-прежнему возможны).

Внутри базы данных База данных SQL Microsoft Azure использует фабрику для управления ресурсами. Однако вместо контроллера фабрики для обнаружения сбоев используется кольцевая топология. Каждая реплика в кластере имеет двух соседей и может определить, не произошло ли их отключение. Если реплика отключается, ее соседи активируют агент реконфигурации (RA) для воссоздания ее на другой машине. Предусмотрено регулирование ресурсов в ядре для обеспечения того, чтобы логический сервер не использовал слишком много ресурсов на машине и не выходил за пределы ее физических возможностей.

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

При установке SQL Server 2012 в виртуальных машинах Azure (IaaS) используются традиционные функции доступности SQL Server, такие как группы доступности AlwaysOn и зеркальное отображение базы данных. Обратите внимание, что рабочие характеристики ВМ, хранилища и сети Azure отличаются от локальной, невиртуализированной ИТ-инфраструктуры. Для успешной реализации HADR-решения для SQL Server в Azure необходимо понимать эти различия и разработать решение в соответствии с ними.

При реализации решения высокой доступности в Azure группа доступности Azure позволяет разместить узлы высокой доступности в отдельных неисправных доменах и доменах обновления. Чтобы все прояснить, группа доступности — это понятие Azure. Дополнительные сведения см. в разделе Управление доступностью виртуальных машин. Этой рекомендации следует придерживаться, чтобы обеспечить действительно высокую доступность, если вы используете группы доступности AlwaysOn, зеркальное отображение базы данных или другие методы. В противном случае вам может казаться, что у вашей системы высокий уровень доступности, но на самом деле узлы могут выйти из строя одновременно, поскольку они размещены в одном домене в центре обработки данных Azure. Эту рекомендацию нельзя применить к доставке журналов в качестве компонента аварийного восстановления, поскольку для этого необходимо, чтобы серверы работали в разных центрах обработки данных Azure (в разных регионах). Эти расположения по определению являются отдельными доменами отказоустойчивости.

Чтобы разместить ВМ Azure в одной группе доступности, их необходимо развернуть в одной облачной службе. Только узлы в одной облачной службе могут входить в одну группу доступности. Кроме того, ВМ должны находиться в одной и той же VNet, чтобы они могли поддерживать свои IP даже после восстановления службы, избегая тем самым затрат времени на обновления DNS.

Вы можете реализовать решение высокого уровня доступности для баз данных SQL Server в Azure с помощью групп доступности AlwaysOn или зеркального отображения базы данных.

На следующей диаграмме показана архитектура групп доступности AlwaysOn, выполняемых на виртуальных машинах Azure. Эта диаграмма взята из подробной статьи по данной теме — Высокий уровень доступности и аварийное восстановление для SQL Server в виртуальных машинах Azure.

На следующей диаграмме показано, как использовать зеркальное отображение базы данных в виртуальных машинах Azure. Она также взята из подробной статьи Высокий уровень доступности и аварийное восстановление для SQL Server в виртуальных машинах Azure.

noteПримечание
Заметьте, что в обеих архитектурах необходим контроллер домена. При зеркальном отображении базы данных можно обойтись и без контроллера домена, используя сертификаты сервера.

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

Служба управления доступом (ACS) 2.0 создает резервные копии всех пространств имен один раз в сутки в безопасном местоположении на альтернативной площадке. Если оперативный персонал ACS обнаружит невосстановимую потерю данных в одном из региональных центров обработки данных ACS, служба попытается восстановить подписки клиентов, восстановив данные из последней резервной копии. В связи с частотой резервного копирования возможна потеря данных за последние 24 часа. Дополнительные сведения см. в Служба управления доступом (аварийное восстановление).

Чтобы снизить риск временного сбоя работы шины обслуживания Azure Service Bus, рассмотрите возможность создания надежной очереди на стороне клиента. В ней временно используется альтернативный локальный механизм хранилища для хранения сообщений, которые не могут быть добавлены в очередь Service Bus. Приложение может решать, как обрабатывать временно хранимые сообщения после возобновления работы службы. Дополнительные сведения см. в разделе Защита приложений Service Bus от перебоев в работе Service Bus. Дополнительные сведения см. в Service Bus (аварийное восстановление).

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

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

 

Служба/область Контрольный список

Вычисление (PaaS)

  • Настройте как минимум два экземпляра для каждой роли.

  • Сохраняйте состояние в надежном хранилище, а не в экземплярах роли.

  • Правильно обрабатывайте событие StatusCheck.

  • По возможности включайте связанные изменения в транзакции.

  • Убедитесь, что задачи рабочей роли идемпотентные и перезапускаемые.

  • Продолжайте вызывать операции, пока они не будут выполнены успешно.

  • Рассмотрите возможность применения стратегий автомасштабирования.

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

  • Не используйте диск D: для постоянного хранилища.

  • Группируйте машины на уровне службы в группу доступности.

  • Настройте балансировку нагрузки и необязательные пробы.

Хранилище

  • Используйте несколько учетных записей хранения, когда данные или пропускная способность превышают квоты.

база данных SQL

  • Реализуйте политику повторов для обработки временных ошибок.

  • Используйте секционирование/сегментирование как стратегию горизонтального масштабирования.

SQL Server 2012 на виртуальных машинах (IaaS)

  • Следуйте приведенным выше рекомендациям для виртуальных машин.

  • Используйте свойства высокого уровня доступности SQL Server, например AlwaysOn.

Служба управления доступом (доступность)

  • Дополнительные шаги применительно к локальным сбоям не требуются.

Service Bus (доступность)

  • Рассмотрите создание надежной очереди на стороне клиента в качестве резервной копии.

Мобильные службы (доступность)

  • Регулярно создавайте резервные копии для служб База данных SQL Azure, связанных с мобильными службами.

  • Создавайте резервные копии скриптов мобильных служб.

HDInsight (доступность)

  • Дополнительные шаги применительно к локальным сбоям не требуются.

Azure разделена физически и логически на единицы, называемые регионами. Регион состоит из одного или более центров обработки данных, находящихся рядом. На момент подготовки к этой публикации в Azure насчитывалось восемь регионов (4 в Северной Америке, 2 в Азии и 2 в Европе).

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

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

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

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

Для балансировки трафика между регионами необходимо использовать решение по управлению трафиком. Azure предоставляет диспетчер трафика Azure (теперь в CTP). Также можно воспользоваться службами сторонних производителей, предоставляющими схожие возможности по управлению трафиком.

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

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

  • Теплая замена («активный/пассивный»). Вторичная размещенная служба создается в альтернативном регионе, и для гарантии минимальной производительности развертываются роли, однако роли при этом не получают рабочего трафика. Этот подход применим для приложений, не спроектированных для распределения трафика по регионам.

  • Горячая замена («активный/активный»). Приложение разработано для получения рабочей нагрузки в разных регионах. Облачные службы в каждом регионе можно настроить для более высокой нагрузки, чем требуется для целей DR. Кроме того, облачные службы можно горизонтально масштабировать при необходимости в момент аварии и отказа. Этот подход требует значительных вложений в разработку приложения, но имеет значительные преимущества, включая малое и гарантированное время восстановления, непрерывное тестирование всех аварийных местоположений и эффективное использование ресурсов.

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

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

  • Используйте API копирования BLOB-объектов для копирования дисков ВМ. Для создания ВМ во многих регионах необходимо скопировать диск ВМ в альтернативный регион. Поскольку диски ВМ — это просто BLOB-объекты, это можно выполнить средствами стандартного API копирования BLOB-объектов.

  • Отделите диск с данными от диска с ОС. Важным аспектом ВМ IaaS является то, что нельзя изменить диск с ОС без повторного создания ВМ. Это не становится источником проблем, если стратегия аварийного восстановления состоит в повторном развертывании после аварии. Однако могут возникать трудности, если для резервирования нагрузки используется подход с «теплой заменой». Чтобы реализовать его правильно, требуемый диск с ОС необходимо развернуть и в первичном и во вторичном местоположении, а данные приложения должны храниться на отдельном диске. По возможности используйте стандартную конфигурацию ОС, которая может быть предоставлена в обоих местоположениях. После отработки отказа следует присоединить диск с данными к существующим ВМ IaaS во вторичном DC. Используйте API CopyBlob для копирования моментальных снимков дисков с данными на удаленный сайт.

  • Потенциальные проблемы согласованности после отработки отказа средствами георепликации с несколькими дисками ВМ: Диски ВМ реализованы как BLOB-объекты хранилища Azure и имеют те же характеристики георепликации (см. ниже). Диски ВМ гарантированно находятся в согласованном при сбое состоянии после отработки отказа средствами георепликации, однако нет гарантий согласованности между дисками, поскольку георепликация асинхронна и диски реплицируются независимо друг от друга. Это может вызвать проблемы в некоторых случаях (например, в случае чередования дисков). Для восстановления согласованности после отработки отказа средствами георепликации в этих случаях может потребоваться дополнительная работа. Для обеспечения правильного резервного копирования следует использовать средство резервного копирования, такое как Data Protection Manager, для создания резервной копии и восстановления данных приложения.

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

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

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

Дополнительные сведения о GRS и о предварительном выпуске RA-GRS см. в статье Параметры избыточности хранилища Microsoft Azure и служба Read Access Geo Redundant Storage.

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

 

Первичный Вторичный

Северо-Центральный регион США

Южно-Центральный регион США

Южно-Центральный регион США

Северо-Центральный регион США

Восток США

Запад США

Запад США

Восток США

Северная Европа

Западная Европа

Западная Европа

Северная Европа

Юго-Восточная Азия

Восточная Азия

Восточная Азия

Юго-Восточная Азия

Восточный Китай

Северный Китай

Северный Китай

Восточный Китай

Юг Бразилии

Южно-Центральный регион США

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

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

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

  • Как уже говорилось в разделе, посвященном дискам ВМ, нет гарантий согласованности данных между различными дисками ВМ после отработки отказа. Для обеспечения правильного резервного копирования следует использовать средство резервного копирования, такое как Data Protection Manager, для создания резервной копии и восстановления данных приложения.

Восстановление служб Azure База данных SQL Azure может быть выполнено путем экспорта базы данных в BLOB-объект хранилища Azure с использованием службы импорта или экспорта служб Azure База данных SQL Azure. Это достигается следующими способами.

  • Экспорт в BLOB-объект с использованием учетной записи хранения в другом центре обработки данных

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

  • Импорт в локальный экземпляр SQL Server на вашей собственной площадке.

Подробные сведения по реализации см. в статье MSDN Непрерывность бизнеса в базе данных SQL Azure.

Есть два варианта восстановления базы данных SQL Server, выполняемой в IaaS, в альтернативном центре обработки данных Azure: зеркальное отображение базы данных или создание резервной копии с последующим восстановлением посредством BLOB-объектов хранилища. Следует учитывать, что в настоящее время группы доступности SQL Server 2012 не поддерживаются для работы в разных центрах обработки данных Azure, поскольку виртуальные сети между центрами обработки данных в Azure на сегодняшний день не поддерживаются, а домен Active Directory не может включать в себя несколько центров обработки данных Azure.

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

Другим вариантом является использование стандартных процедур резервного копирования и восстановления в Azure с помощью BLOB-объектов хранилища.

Дополнительные сведения см. в разделе Высокий уровень доступности и аварийное восстановление для SQL Server в виртуальных машинах Azure.

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

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

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

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

Как и ACS, Service Bus использует уникальное пространство имен, которое не может быть разнесено на несколько регионов Azure. Таким образом, первым требованием является настройка необходимых пространств имен Service Bus в альтернативном регионе. Однако есть и некоторые соображения относительно надежности сообщений в очереди. Существует несколько стратегий репликации сообщений между регионами Azure. Подробности этих стратегий репликации и других стратегий аварийного восстановления см. в разделе Защита приложений Service Bus от перебоев в работе Service Bus. Информацию о других вопросах доступности см. в разделе Service Bus (доступность)

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

Во вторичном регионе Azure создайте резервную мобильную службу для своего приложения. Восстановите службы База данных SQL Azure также и в альтернативном регионе. Затем с помощью средств командной строки Azure переместите мобильную службу в альтернативный регион. После этого настройте мобильную службу для использования восстановленной базы данных. Дополнительные сведения об этом процессе см. в разделе Восстановление мобильной службы в случае аварии. Информацию о других вопросах доступности см. в разделе Мобильные службы (доступность)

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

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

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

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

 

Служба/область Контрольный список

Вычисление (PaaS)

  • Создайте межрегиональную стратегию аварийного восстановления.

  • Оцените компромиссы резервирования ресурсов в альтернативных регионах.

  • Используйте средства маршрутизации трафика, такие как диспетчер трафика Azure (CTP).

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

  • Скопируйте ресурсы диска ВМ с BLOB-объектом в альтернативный центр обработки данных.

  • Регулярно создавайте резервные копии диска ВМ или содержимого диска.

Хранилище

  • Не отключайте георепликацию ресурсов хранилища.

  • Определите альтернативный регион для георепликации в случае отработки отказа.

  • Создайте пользовательские стратегии резервного копирования для управляемых пользователем стратегий отработки отказа.

База данных SQL (аварийное восстановление)

  • Экспортируйте База данных SQL Azure в хранилище BLOB-объектов.

  • Создайте план аварийного восстановления на основе рассмотренных соображений, касающихся хранилища.

SQL Server на виртуальных машинах (аварийное восстановление)

  • Используйте межрегиональное зеркальное отображение базы данных.

  • В качестве альтернативы можно использовать резервное копирование в хранилище BLOB-объектов и восстановление из него.

Служба управления доступом (аварийное восстановление)

  • Настройте пространство имен ACS в альтернативном регионе.

  • Используйте службу управления ACS 2.0 для создания пользовательских решений резервного копирования.

Service Bus (аварийное восстановление)

  • Настройте пространство имен Service Bus в альтернативном регионе.

  • Рассмотрите возможность использования пользовательских стратегий репликации для сообщений между регионами.

Веб-сайты (аварийное восстановление)

  • Поддерживайте резервные копии веб-сайта за пределами первичного региона.

  • Если сбой частичный, попытайтесь получить текущий сайт через FTP.

  • Запланируйте развертывание веб-сайта в новый или существующий веб-сайт в альтернативном регионе.

  • Запланируйте изменения в конфигурации как для приложения, так и для записей DNS CNAME.

Мобильные службы (аварийное восстановление)

  • Создайте резервную мобильную службу в альтернативном регионе.

  • Управляйте резервными копиями связанной База данных SQL Azure для восстановления при отработке отказа.

  • С помощью средств командной строки Azure переместите мобильную службу.

HDInsight (аварийное восстановление)

  • Создайте новый кластер Hadoop в регионе с реплицированными данными.

Служба отчетов SQL Reporting (аварийное восстановление)

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

  • Поддерживайте отдельный план для репликации назначения в этот регион.

Службы носителей (аварийное восстановление)

  • Создайте учетную запись служб носителей в альтернативном регионе.

  • Закодируйте одно и то же содержимое в обоих регионах для поддержки отработки отказа для потоковой передачи.

  • В случае сбоя отправляйте задания кодирования в альтернативный регион.

Виртуальная сеть (аварийное восстановление)

  • С помощью экспортированных параметров виртуальной сети повторно создайте ее в другом регионе.

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

  • Сеть: виртуальная частная сеть позволяет безопасным образом расширить локальную сеть в облако.

  • Вычисления: пользователи, использующие Hyper-V локально, могут перенести существующие ВМ в Azure.

  • Хранилище: StorSimple расширяет файловую систему за счет хранилища Azure. Служба резервного копирования Azure позволяет создавать резервные копии файлов и служб База данных SQL Azure в хранилище Azure

  • Репликация баз данных: группы доступности SQL 2012 обеспечивают высокий уровень доступности и возможность восстановления при аварии для локальных данных.

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

Пользователи, использующие Hyper-V локально, могут перенести существующие ВМ в Azure и поставщики служб, работающие в Windows Server 2012, без изменений в ВМ и без преобразования форматов ВМ. Дополнительные сведения см. в статье Управление дисками и образами.

Существует несколько вариантов использования Azure как резервного узла для локальных данных.

StorSimple безопасным и прозрачным образом интегрирует облачное хранилище для использования локальными приложениями и предлагает единое устройство, предоставляющее высокопроизводительное многоуровневое локальное и облачное хранилище, архивирование в реальном времени, защиту данных в облаке и аварийное восстановление. Дополнительные сведения см. в статье StorSimple, интегрированное в облако хранилище, — что и зачем.

Резервные службы Azure позволяют создавать облачные резервные копии с помощью знакомых средств резервного копирования в Windows Server 2012, Windows Server 2012 Essentials и System Center 2012 Data Protection Manager. Эти средства предоставляют рабочий процесс для управления резервным копированием, независимый от расположения хранилища резервных копий — на локальном диске или в хранилище Azure. После резервного копирования данных в облако авторизованные пользователи могут легко восстановить их на любой сервер.

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

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

Группы доступности AlwaysOn можно использовать в гибридной ИТ-среде, где реплики баз данных существуют как локально, так и в облаке. Это показано на следующей диаграмме, взятой из подробной статьи — Высокий уровень доступности и аварийное восстановление для SQL Server в виртуальных машинах Azure.

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

Доставку журналов можно использовать для синхронизации локальной базы данных с базой данных, размещенной на SQL Server в среде виртуальной машины Azure.

Наконец, можно создавать резервные копии локальных баз данных напрямую в хранилище BLOB-объектов Azure.

Дополнительные сведения см. в разделах Высокий уровень доступности и аварийное восстановление для SQL Server в виртуальных машинах Azure и Резервное копирование и восстановление для SQL Server в виртуальных машинах Azure.

 

Служба/область Контрольный список

Сеть

  • Используйте виртуальную сеть для безопасного подключения локальной сети к облаку.

Среда выполнения приложений

  • Перемещайте ВМ между Hyper-V и Azure.

Хранилище

  • Воспользуйтесь преимуществами служб StorSimple для использования облачного хранилища.

  • Используйте резервные службы Azure.

База данных

  • Рассмотрите возможность использования SQL Server на ВМ Azure в качестве резерва.

  • Настройте группы доступности AlwaysOn.

  • Настройте зеркальное отображение базы данных на основе сертификатов.

  • Используйте доставку журналов.

  • Резервное копирование локальной базы данных в хранилище BLOB-объектов Azure.

Этот сценарий посвящен восстановлению данных, поврежденных или случайно удаленных из-за ошибок приложения или оператора.

Необходимо отметить следующее. Хотя хранилище Azure обеспечивает эластичность доступа к данным с помощью автоматизированных реплик, это не позволяет предотвратить повреждение данных кодом приложения (или разработчиками, пользователями) в результате случайного или непреднамеренного удаления, обновления и т. д. Для поддержания достоверности данных в условиях возможной ошибки приложения или пользователя требуются более совершенные методы, такие как копирование данных в местоположение вторичного хранилища и ведение журнала аудита. Разработчикам может быть полезна возможность создания моментального снимка, позволяющая создавать предназначенные только для чтения моментальные снимки содержимого BLOB-объекта на определенный момент времени. Они могут служить основой решения по повышению достоверности данных BLOB-объектов.

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

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

Для База данных SQL Azure существует несколько вариантов обеспечения непрерывности бизнеса (резервное копирование, восстановление). Базы данных можно копировать с помощью функции копирования базы данных или с помощью службы импорта и экспорта приложения уровня данных. Копирование базы данных обеспечивает согласованный результат на уровне транзакций, в то время как BACPAC-файл (через службы импорта и экспорта) — нет. Оба этих варианта работают как службы на основе запросов в одном центре данных и в настоящий момент не имеют соглашения об уровне обслуживания, касающегося времени выполнения процессов.

noteПримечание
Обратите внимание, что копирование базы данных и служба импорта и экспорта создают значительную нагрузку на базу данных-источник и могут привести к конфликту данных или срабатыванию регулирования ресурсов (см. раздел «Общие ресурсы и регулирование» ниже).

Резервные копии баз данных База данных SQL Microsoft Azure на определенный момент времени создаются с помощью команды копирования базы данных SQL Azure. С помощью этой команды можно создавать транзакционно согласованные копии базы данных на том же логическом сервере баз данных или на другом сервере. В любом случае копия базы данных будет полностью работоспособной и абсолютно независимой от базы данных-источника. Каждая создаваемая копия представляет возможность восстановления состояния на определенный момент времени. Состояние базы данных можно полностью восстановить, назначив созданной копии базы данных имя базы данных-источника. Также с помощью запросов Transact-SQL из новой базы данных можно восстановить определенное подмножество данных. Более подробные сведения о базах данных SQL см. в разделе Непрерывность бизнеса в базах данных SQL Azure.

Для SQL Server в IaaS доступно два варианта: традиционное резервное копирование и доставка журналов. Традиционные резервные копии обеспечивают восстановление до определенного момента времени, но процесс восстановления длится долго. Восстановление из традиционных резервных копий требует запуска первоначальной полной резервной копии с последующим применением всех резервных копий, сделанных впоследствии. Второй вариант — настроить сеанс доставки журналов для задержки восстановления резервных копий журналов (например, на два часа). Это обеспечивает временной интервал для восстановления после ошибок, возникших в первичной реплике.

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

Для веб-сайтов Azure и мобильных служб Azure необходимо создавать резервные копии и поддерживать связанные базы данных. Для службы носителей Azure и виртуальных машин Azure требуется поддерживать связанную учетную запись хранения Azure и все ресурсы в ней. Например, для виртуальных машин необходимо создавать резервные копии дисков ВМ в хранилище BLOB-объектов Azure и управлять ими.

 

Служба/область Контрольный список

Хранилище

  • Регулярно создавайте резервные копии важных ресурсов хранилища.

  • Рассмотрите возможность использования функции моментального снимка для BLOB-объектов.

База данных

  • Создавайте резервные копии на определенный момент времени с помощью команды Database Copy.

Резервное копирование SQL Server на виртуальных машинах (IaaS)

  • Используйте традиционные технологии резервного копирования и восстановления.

  • Создайте сеанс отложенной доставки журналов

Веб-сайты

  • Создавайте резервные копии связанных баз данных, если таковые имеются, и поддерживайте их.

Мобильные услуги

  • Создавайте резервные копии связанных баз данных и поддерживайте их.

Службы Media Services

  • Создавайте резервные копии связанных ресурсов хранения и поддерживайте их.

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

  • Создавайте резервные копии дисков ВМ в хранилище BLOB-объектов и поддерживайте их.

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

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

Непрерывность бизнес-процессов в базе данных SQL Azure. Материал посвящен исключительно технологиям служб База данных SQL Azure в Azure для доступности — в первую очередь стратегиям резервного копирования и восстановления. Если в вашей облачной службе используются службы База данных SQL Azure, следует прочитать этот документ и связанные с ним ресурсы.

Высокий уровень доступности и аварийное восстановление для SQL Server в виртуальных машинах Azure. Описывает параметры доступности, доступные при использовании модели «инфраструктура как служба» (IaaS) для размещения служб Database Services. Обсуждаются группы доступности AlwaysOn, зеркальное отображение базы данных, доставка журналов, создание резервных копий и восстановление из них. Обратите внимание, что в том же разделе есть несколько учебников, в которых показано, как использовать эти технологии.

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

Резервное копирование и восстановление для SQL Server в виртуальных машинах Azure

Показ:
© 2014 Microsoft