Общие вопросы об Azure Site Recovery

Служба Site Recovery помогает реализовать стратегии непрерывности бизнес-процессов и аварийного восстановления (BCDR), автоматизируя процессы репликации виртуальных машин Azure между регионами, локальных виртуальных машин и физических серверов в Azure, а также локальных виртуальных машин в дополнительный центр обработки данных и осуществляя управление ими. Подробнее.

Нет, Azure Site Recovery не поддерживает рабочие нагрузки Docker, работающие на виртуальных машинах. Чтобы защитить такие виртуальные машины с помощью Site Recovery, исключите из них диски с установленным Docker.

При работе с Site Recovery предпринимаются различные меры, чтобы обеспечить целостность данных. Между всеми службами устанавливается безопасное соединение с помощью протокола HTTPS. Это гарантирует, что любые вредоносные или внешние сущности не смогут незаконно изменить данные. Другая мера заключается в использовании контрольных сумм. Передача данных между исходным и целевым расположениями осуществляется с вычислением контрольных сумм между ними. Это обеспечивает целостность передаваемых данных.

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

Да, Site Recovery поддерживает как выделенную, так и общую модели инфраструктуры.

Нет. Клиент остается анонимным. Клиентам не требуется доступ к порталу Site Recovery. Только администратор поставщика служб взаимодействует с порталом.

При репликации между сайтами, принадлежащими поставщику служб, данные приложения никогда не передаются в Azure. Данные шифруются при передаче (HTTPS) и реплицируются непосредственно между сайтами поставщика услуг.

При репликации в Azure данные приложения передаются в службу хранилища Azure, а не в службу Site Recovery. Данные шифруются в процессе передачи и остаются зашифрованными в Azure.

Нет. Azure выставляет счета только поставщику службы. Поставщики служб отвечают за создание специальных счетов для своих клиентов.

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

Да.

Поддерживаются развертывания на основе Azure Pack, системы облачной платформы и System Center 2012 и более поздних версий. Узнайте больше об интеграции Azure Pack и Site Recovery.

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

Ознакомьтесь со сведениями о расценках на Site Recovery.

Вы можете использовать калькулятор цен для оценки затрат при использовании Site Recovery.

Для получения подробной оценки затрат запустите средство планировщика развертывания для VMware или Hyper-V и проанализируйте отчет об оценке стоимости.

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

Да. В течение первого 31-дневного периода использования Azure Site Recovery плата за каждый защищенный экземпляр не взимается. Например, если в течение последних 6 месяцев вы пользовались защитой для 10-ти экземпляров и подключаете 11-й экземпляр к Azure Site Recovery, за начальный период работы (31 день) нового экземпляра плата не взимается. Но первые 10 экземпляров вы будете оплачивать по обычным тарифам на Azure Site Recovery, так как защита для них применяется уже боле 31 дня.

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

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

Нет, служба Site Recovery не перехватывает реплицируемые данные и не получает сведения о компонентах, запущенных на ваших виртуальных машинах или физических серверах. Обмен данными репликации осуществляется между локальными узлами Hyper-V, низкоуровневыми оболочками VMware или физическими серверами и хранилищем Azure или дополнительным сайтом. Служба Site Recovery не обладает способностью перехватывать эти данные. В службу Site Recovery передаются только метаданные, необходимые для управления репликацией и отработкой отказа.

Site Recovery имеет сертификаты ISO 27001:2013, 27018, HIPAA, DPA и сейчас проходит проверки на соответствие SOC2 и FedRAMP JAB.

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

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

Да, протокол TLS 1.2 по умолчанию принудительно применяется для взаимодействий между службами Azure и Azure Site Recovery.

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

Обмен данными между микрослужбами Azure Site Recovery выполняется по протоколу TLS 1.2. Site Recovery всегда использует поставщики безопасности, настроенные в системе (ОС), и последнюю доступную версию протокола TLS. Вам достаточно явным образом включить TLS 1.2 в реестре, и тогда Site Recovery будет использовать только TLS 1.2 для взаимодействия со службами.

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

• Учетные записи хранения на основе Resource Manager (категория “Стандартный”):
  • Участник
  • участник данных BLOB-объектов хранилища;
• Учетные записи хранения на основе Resource Manager (категория "Премиум"):
  • Участник
  • владелец данных BLOB-объектов хранилища;
• Классические учетные записи хранения:
  • Участник классической учетной записи хранения
  • Роль службы оператора ключей классических учетных записей хранения

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

• Виртуальные машины Azure. Служба Site Recovery может реплицировать любую нагрузку, выполняющуюся на поддерживаемой виртуальной машине Azure.
• Виртуальные машины Hyper-V. Служба Site Recovery позволяет защитить любую рабочую нагрузку, выполняющуюся на виртуальной машине Hyper-V.
• Физические серверы. Служба Site Recovery позволяет защитить физические серверы под управлением Windows или Linux.
• Виртуальные машины VMware. Служба Site Recovery позволяет защитить любую рабочую нагрузку, выполняющуюся на виртуальной машине VMware.

Службу Site Recovery можно использовать для защиты большинства рабочих нагрузок, запущенных на поддерживаемой виртуальной машине или физическом сервере. Служба Site Recovery также поддерживает репликацию уровня приложения, позволяя восстанавливать приложения до программируемого состояния. Она интегрируется с приложениями Майкрософт, включая SharePoint, Exchange, Dynamics, SQL Server и Active Directory, а также тесно взаимодействует с решениями ведущих производителей, в том числе Oracle, SAP, IBM и Red Hat. Подробнее о защите рабочей нагрузки.

Да. Используя службу Site Recovery для управления репликацией и отработкой отказа в офисах филиалов, вы получаете объединенные возможности управления и представление для всех рабочих нагрузок офисов филиалов в центральном расположении. Таким образом, можно легко выполнить отработку отказа и управлять аварийным восстановлением для всех филиалов, не выходя из главного офиса.

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

Да, Site Recovery поддерживает аварийное восстановление локальных виртуальных машин VMware. Ознакомьтесь с часто задаваемыми вопросами об аварийном восстановлении виртуальных машин VMware.

Да, Site Recovery поддерживает аварийное восстановление локальных виртуальных машин Hyper-V. Ознакомьтесь с часто задаваемыми вопросами об аварийном восстановлении виртуальных машин Hyper-V.

Да, Site Recovery поддерживает аварийное восстановление локальных физических серверов под управлением Windows и Linux в Azure или на вторичный сайт. Узнайте больше о требованиях к аварийному восстановлению в Azure и на вторичный сайт. Обратите внимание, что физические серверы после отработки отказа будут работать в качестве виртуальных машин в Azure. Сейчас восстановление размещения из Azure на локальный физический сервер не поддерживается. Восстановление размещения можно выполнить только на виртуальную машину VMware.

Нет, Azure Site Recovery не поддерживает перемещение хранилища Служб восстановления с размещенными в нем защищенными виртуальными машинами.

Azure Site Recovery реплицирует данные в учетную запись хранения Azure или на управляемый диск через общедоступную конечную точку. Однако репликация также можно выполняться через VPN типа "сеть —сеть". VPN-подключение типа "сеть —сеть" позволяет организациям подключать существующие сети к Azure или сети Azure друг к другу. VPN типа "сеть —сеть" использует туннелирование IPSec через Интернет с применением существующего локального пограничного сетевого оборудования и сетевых устройств в Azure — собственных функций, таких как шлюз виртуальной частной сети Azure (VPN), или сторонних решений, например Check Point CloudGaurd или Palo Alto NextGen Firewall.

• Частное подключение через общедоступный Интернет к Microsoft Edge
• Хранилища служб восстановления, настроенные для обеспечения безопасности с использованием частных конечных точек
• Репликация через подключение частной виртуальной сети клиента
• Простой переход в будущее состояние
• Отсутствие соглашения об уровне обслуживания и потенциально более высокая задержка
• Требуется доступное локальное VPN-устройство

Наш партнер Riverbed предлагает подробные рекомендации по работе с Azure Site Recovery. Изучите их руководство по решению.

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

• Azure Site Recovery реплицирует данные в службу хранилища Azure через общедоступную конечную точку. Чтобы использовать ExpressRoute для репликации в Site Recovery, необходимо настроить пиринг Майкрософт или применить существующий общедоступный пиринг (не рекомендуется для новых каналов).
• Пиринг Майкрософт является рекомендуемым доменом маршрутизации для репликации.
• Репликация через частный пиринг не поддерживается.
• Ели вы защищаете виртуальные машины VMware или физические компьютеры, убедитесь, что соблюдаются все требования к сети для сервера конфигурации. Для оркестрации репликации в Site Recovery требуется возможность подключения сервера конфигурации к определенным URL-адресам. Для такого подключения невозможно использовать ExpressRoute.
• После отработки отказа виртуальных машин в виртуальную сеть Azure доступ к можно получать с помощью частного пиринга, настроенного в виртуальной сети Azure.

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

• Hyper-V. Виртуальные машины Hyper-V можно реплицировать каждые 30 секунд (неприменимо к хранилищу ценовой категории "Премиум") или пять минут.
• Виртуальные машины Azure, виртуальные машины VMware и физические серверы. Здесь частота репликации не имеет значения. Репликация является непрерывной.

Расширенная репликация и цепочка репликации не поддерживаются. Запросите эту функцию на форуме отзывов и предложений.

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

Эта возможность поддерживается при репликации виртуальных машин VMware и Hyper-V в Azure с помощью портала Azure.

Динамические диски поддерживаются при репликации виртуальных машин Hyper-V, а также при репликации виртуальных машин VMware и физических компьютеров в Azure. Диск операционной системы должен представлять собой базовый диск.

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

• Планирование ресурсов для репликации виртуальных машин VMware и физических серверов
• Запуск планировщика ресурсов Hyper-V для Site Recovery

Да. Azure Site Recovery для операционной системы Linux поддерживает настраиваемые сценарии для согласования приложений. Пользовательский сценарий с параметрами pre и post будет использоваться агентом мобильности Azure Site Recovery во время согласования приложений. Ниже приведен порядок действий для его реализации.

1. Войдите в систему на компьютере в качестве привилегированного пользователя.

2. Перейдите в каталог установки агента мобильности Azure Site Recovery. По умолчанию используется /usr/local/ASR.
   # cd /usr/local/ASR

3. Перейдите в подкаталог VX/scripts.
   # cd VX/scripts

4. Создайте сценарий оболочки Bash с именем customscript.sh и разрешениями на выполнение для привилегированного пользователя.
   а. Сценарий должен поддерживать параметры командной строки --pre и --post (обратите внимание на двойные тире).
   b. При вызове сценария с параметром pre он должен заморозить операции ввода-вывода приложения, а при вызове с параметром post — разморозить их.
   c. Пример шаблона:
   

   # cat customscript.sh
   

    #!/bin/bash

    if [ $# -ne 1 ]; then
        echo "Usage: $0 [--pre | --post]"
        exit 1
    elif [ "$1" == "--pre" ]; then
        echo "Freezing app IO"
        exit 0
    elif [ "$1" == "--post" ]; then
        echo "Thawed app IO"
        exit 0
    fi

5. Добавьте команды замораживания и размораживания операций ввода-вывода к этапам pre и post для приложений, которым требуется согласование. Вы можете добавить еще один сценарий, который будет их определять, и вызвать его из customscript.sh с параметрами pre и post.

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

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

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

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

Site Recovery создает отказоустойчивую точку восстановления каждые 5 минут.

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

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

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

Site Recovery может создать точку восстановления, согласованную с приложением, с минимальной частотой в 1 час.

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

Site Recovery создает отказоустойчивую точку восстановления каждые 5 минут. Вы не можете изменить эту частоту. За последние 2 часа вам доступны 24 точки восстановления с согласованностью на уровне сбоя и 2 точки восстановления с согласованностью на уровне приложений. Со временем Site Recovery урезает все точки восстановления старше 2 часов, сохраняя из них только 1 точку восстановления в час за период не более 24 часов.

На следующем снимке экрана показан пример. На снимке экрана:

• За последние 2 часа существуют точки восстановления с интервалом в 5 минут.

• За период ранее этих 2-х часов Site Recovery сохраняет только 1 точку восстановления в час.

  

Самая старая точка восстановления, которую можно использовать, имеет давность 15 дней на управляемом диске или 3 дня на неуправляемом диске.

Нет. В этом случае Site Recovery будет хранить все предыдущие точки восстановления. В зависимости от периода хранения точек восстановления Site Recovery заменяет самую старую точку только при создании новых. Из-за проблемы Site Recovery не может создавать новые точки восстановления. Пока не появятся новые точки восстановления, все старые точки останутся на месте даже после окончания периода хранения.

Перейдите в раздел Хранилище Site Recovery>Инфраструктура Site Recovery>Политики репликации. Выберите политику, которую требуется изменить, и сохраните изменения. Изменения будут применяться и к существующим репликациям.

Первая сгенерированная точка восстановления имеет полную копию. Все последующие точки восстановления имеют разностные изменения.

Да, при увеличении срока хранения с 1 до 3 дней Site Recovery будет хранить точки восстановления дополнительные 2 дня. С увеличением периода хранения с 1 дня до 3 дней увеличится и плата за хранилище, так как потребуется хранить еще 12 точек восстановления. Например, одна точка восстановления может иметь разностные изменения в 10 ГБ при стоимости за гигабайт в 0,16 долл. США в месяц. Дополнительная плата составит $1,60 × 12 в месяц.

Доступ к виртуальным машинам Azure можно получить через безопасное подключение к Интернету, подключение VPN типа "сеть — сеть" или с помощью Azure ExpressRoute. Для подключения потребуется выполнить несколько подготовительных действий. Подробнее.

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

Можно активировать незапланированную отработку отказа на дополнительном сайте. Для отработки отказа службе Site Recovery не требуется подключение на основном сайте.

Отработка отказа не выполняется автоматически. Чтобы активировать ее, необходимо щелкнуть в соответствующем месте на портале или воспользоваться Site Recovery PowerShell . Восстановление размещения — простое действие, которое выполняется на портале Site Recovery.

Чтобы автоматизировать выполнение этих процедур, можно использовать локальное решение Orchestrator или Operations Manager для обнаружения сбоя виртуальной машины, а затем активировать отработку отказа, используя пакет SDK.

• Дополнительные сведения о планах восстановления см. здесь.
• Узнайте больше об отработке отказа.
• Узнайте больше о восстановлении размещения виртуальных машин VMware и физических серверов.

Да. Вы можете выполнить восстановление на другой узел из Azure.

• Для виртуальных машин VMware
• Для виртуальных машин Hyper-V

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

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

Да. Рабочие процессы службы Site Recovery можно автоматизировать с помощью интерфейса REST API, PowerShell или пакета SDK для Azure. Ниже перечислены сценарии развертывания Site Recovery с помощью PowerShell, которые поддерживаются в настоящее время.

• Репликация виртуальных машин Hyper-V из облаков VMM в Azure с помощью PowerShell (модель Resource Manager)
• Репликация виртуальных машин Hyper-V (без VMM) в Azure с помощью PowerShell (модель Resource Manager)
• Репликация из VMware в Azure с помощью PowerShell для Resource Manager

Узнайте больше о новых обновлениях и накопительных пакетах.

Дальнейшие действия

• Ознакомьтесь со статьей Обзор Site Recovery