Переход от классического к модернизации аварийного восстановления VMware
В этой статье содержатся сведения об архитектуре, необходимой инфраструктуре и часто задаваемых вопросы о перемещении реплика виртуальных машин VMware или физического компьютера из классическойв модернизируемую архитектуру защиты. Благодаря этой возможности миграции можно успешно перенести реплицированные элементы с сервера конфигурации на устройство репликации Azure Site Recovery. Эта миграция управляется интеллектуальным механизмом реплика tion, что гарантирует, что полное начальное реплика не выполняется повторно для некритических реплика элементов и передается только разностные данные.
Примечание.
Планы восстановления не будут перенесены и их потребуется создать повторно в модернизированном хранилище Служб восстановления.
Архитектура
Компоненты, участвующие в миграции реплика элементов VMware или физического компьютера, приведены в следующей таблице:
| Компонент | Требование |
|---|---|
| Реплицированные элементы в классическом хранилище Служб восстановления | Один или несколько реплицированных элементов, защищенных с помощью классической архитектуры и работоспособного сервера конфигурации. Элемент реплика должен находиться в некритичном состоянии и должен быть реплика из локальной среды в Azure с агентом мобильности, работающим в версии 9.50 или более поздней. |
| Сервер конфигурации, используемый реплицированными элементами | Сервер конфигурации, используемый реплика элементами, должен находиться в некритичном состоянии, а его компоненты должны быть обновлены до последней версии (9.50 или более поздней). |
| Хранилище Служб восстановления с обновленным интерфейсом | Хранилище Служб восстановления с обновленным интерфейсом. |
| Работоспособные устройства репликации Azure Site Recovery | Некритичное устройство репликации Azure Site Recovery, которое может обнаруживать локальные компьютеры. При этом все его компоненты обновлены до последней версии (9.50 или более поздней). Точные требуемые версии приведены ниже. Сервер обработки: 9.50 Прокси-сервер: 1.35.8419.34591 Агент служб восстановления: 2.0.9249.0 Служба репликации: 1.35.8433.24227 |
Требуемая инфраструктура
Для успешного перемещения реплицированного элемента убедитесь в следующем:
- Хранилище Служб восстановления использует обновленный интерфейс.
Примечание.
Все созданные новые хранилища Служб восстановления по умолчанию будут иметь обновленный интерфейс. Вы не можете переключиться на классический интерфейс, так как его нерекомендуция уже объявлена.
- Служба Azure Site Recovery реплика (модуль), которая успешно зарегистрирована в хранилище, и все его компоненты находятся в некритичном состоянии.
- Устройство должно быть версии 9.50 или более поздней. Подробное описание версии см. здесь.
- Для успешного обнаружения в локальной среде в устройство добавлены сведения о сервере vCenter или узле vSphere, на котором размещены существующие реплицированные компьютеры.
Предварительные требования
Подготовка инфраструктуры
Прежде чем переходить от классической архитектуры к модернизированной, убедитесь в следующем:
- Создайте хранилище служб восстановления и убедитесь, что интерфейс не был переключен на классический
- Разверните устройства репликации Azure Site Recovery.
- Добавьте в устройство сведения о vCenter Server локального компьютера, чтобы оно успешно выполняло обнаружение.
Подготовка классического хранилища служб восстановления
Убедитесь, что для реплика указанных элементов, которые вы планируете переместить:
- Элемент реплика — это реплика виртуальной машины VMware или физического компьютера с помощью сервера конфигурации.
- Репликация не происходит с неуправляемой учетной записью хранения, а вместо управляемого диска.
- Репликация происходит из локальной среды в Azure, а элемент реплика не находится в отработке отказа или в состоянии отработки отказа.
- Элемент реплика не реплика данные из Azure в локальную среду.
- Начальное реплика не выполняется и уже завершено.
- Элемент реплика не отображается в состоянии resynchronization.
- Версия сервера конфигурации — 9.50 или более поздняя, и ее работоспособность находится в некритичном состоянии.
- Сервер конфигурации имеет пульс, соответствующий работоспособному состоянию.
- На исходном компьютере установлен агент службы "Мобильность" версии 9.50 или более поздней.
- Поддерживаются хранилища служб восстановления с поддержкой MSI.
- Поддерживаются хранилища служб восстановления с включенными частными конечными точками.
- Работоспособность реплика заданного элемента находится в некритичном состоянии или ее точки восстановления создаются успешно.
Подготовка модернизированного хранилища служб восстановления
Для модернизации конфигурации архитектуры убедитесь, что:
- Хранилище Служб восстановления, используемое для настройки модернизированной архитектуры, находится в том же географическом расположении, что и классическое хранилище.
- Устройство репликации Azure Site Recovery развертывается в локальной среде с версией 9.50 или более поздней.
- Устройство успешно зарегистрировано в хранилище.
- (модуль) и все его компоненты находятся в некритичном состоянии, и (модуль) имеет здоровое сердцебиение.
- Версия vCenter Server поддерживается модернизированной архитектурой.
- Сведения о vCenter Server исходного компьютера добавлены на устройство.
- Версия дистрибутива Linux поддерживается модернизированной архитектурой. Подробнее.
- Версия Windows Server поддерживается модернизированной архитектурой. Подробнее.
Вычисление общего времени перемещения
Общее время, необходимое для перемещения любого реплицированного элемента из классического хранилища в модернизированное, зависит от состояния репликации элемента и размера диска.
| State | Время миграции в модернизированное хранилище |
|---|---|
| Состояние защиты реплицированного элемента — работоспособна, а последняя точка восстановления создана менее 50 минут назад | Миграция завершена в 1–2 часа |
| Состояние защиты реплицированного элемента — неработоспособна, а последняя точка восстановления создана более 50 минут назад | Время миграции может отличаться и зависит от размера диска |
Если состояние защиты компьютеров не работает, используйте следующую формулу, чтобы вычислить точное время для компьютеров:
Время миграции = 1 час + 45 секунд/ГиБ
| Конфигурация компьютера | Время миграции |
|---|---|
| Один компьютер с двумя дисками размером 256 ГиБ | ~ 4 часа 15 мин [Оба диска переносятся параллельно] |
| 10 компьютеров с двумя дисками каждый, оба размера 256 ГиБ | ~ 4 часа 15 мин [Все виртуальные машины и их диски переносятся параллельно] |
| Один компьютер с четырьмя дисками, все размером 512 ГиБ | ~ 7 часов 30 мин [Оба диска переносятся параллельно] |
| 10 компьютеров с четырьмя дисками, все размером 512 ГиБ | ~ 7 часов 30 мин [Все виртуальные машины и их диски переносятся параллельно] |
Та же формула используется для вычисления времени миграции и отображается на портале.
Как определить необходимую инфраструктуру
При переносе компьютеров из классической в модернизируемую архитектуру необходимо убедиться, что требуемая инфраструктура уже зарегистрирована в модернизированном хранилище служб восстановления. Сведения о размерах и емкости устройства репликации помогут определить необходимую инфраструктуру.
Как правило, необходимо настроить то же количество устройств репликации, что и количество серверов обработки в классическом хранилище Служб восстановления. Если в классическом хранилище был один сервер конфигурации и четыре сервера обработки, необходимо настроить четыре устройства репликации в модернизированном хранилище Служб восстановления.
Цены
Плата за лицензию на Site Recovery в классическом хранилище будет взиматься по-прежнему вплоть до завершения периода хранения всех точек восстановления. После очистки всех точек восстановления в классическом хранилище также будет остановлено вычисление цен. После завершения периода хранения всех точек восстановления реплицированный элемент будет автоматически удален с помощью очищающей операции репликации, активируемой системой.
Site Recovery начнет взимать плату за лицензию на реплицированные элементы в модернизированном хранилище, только после создания первой точки восстановления и очистки старого хранилища. Если в классическом хранилище есть какое-либо количество дней пробного использования, эти сведения будут переданы в модернизированное хранилище. Вычисление цен начнется в модернизированном хранилище только после завершения этого пробного периода.
Примечание.
В каждый момент времени цены будут вычисляться только для одного хранилища: классического или модернизированного.
Вопросы и ответы
Зачем переносить компьютеры в модернизированную архитектуру?
Важно отметить, что классическая архитектура аварийного восстановления будет прекращена, поэтому пользователи должны переключиться на последнюю и обновленную версию. В следующей таблице представлено сравнение двух архитектур, которые помогут вам выбрать правильный вариант для защиты компьютеров в случае аварии.
| Классическая архитектура | Модернизация архитектуры [Новая] |
|---|---|
| Для обнаружения локальных данных требуется несколько настроек. | Централизованное обнаружение локального центра обработки данных с помощью службы обнаружения. |
| Необходимо выполнить множество шагов для начального подключения. | Упрощенный интерфейс подключения, предусматривающий автоматизацию создания артефактов и введение значений по умолчанию для сокращения количества необходимых входных данных. |
| Использует скачанный вручную файл для получения контекста облака. | Внедрен ключ репликации для получения контекста облака при настройке устройства. |
| Обширное количество шагов, необходимых для простого процесса репликации. | Упрощенный интерфейс включения репликации, уменьшающий количество необходимых входных данных и переопределяющий каждую колонку. |
| Сервер конфигурации по-прежнему представляет собой локальную инфраструктуру с обширным процессом настройки для различных компонентов. | Устройство улучшено за счет преобразования всех компонентов в размещенные микрослужбы Azure. Это упрощает масштабирование, мониторинг и устранение неполадок для устройства. |
| Потребность в сервере обработки с поддержкой горизонтального увеличения масштаба и главном целевом сервере в Azure для компьютеров Linux создает препятствия. | Устранена необходимость обслуживания отдельного сервера обработки и главного целевого сервера. |
| Используется статическая парольная фраза для проверки подлинности, что препятствует выполнению бизнес-требований клиента к периодической смене паролей. | Внедрена проверка подлинности на основе сертификатов, которая более безопасна и устраняет проблемы безопасности клиента. |
| Обновление до обновленной версии должно выполняться вручную и является затруднительным процессом. | Внедрены автоматические обновления для компонентов устройства и службы "Мобильность". |
| Сервер конфигурации не имеет высокой доступности и может столкнуться с риском сворачивания. | Реализован высокий уровень доступности устройства для обеспечения устойчивости. |
| Корневые учетные данные должны регулярно обновляться, чтобы обеспечить возможность обновления без ошибок. | Устранено требование относительно обслуживания корневых учетных данные компьютера для выполнения автоматических обновлений. |
| Для поддержания подключения серверу конфигурации должен быть назначен статический IP-адрес. | Внедрено подключение на основе полного доменного имени между устройством и локальными компьютерами. |
| Следует использовать только ту виртуальную сеть, в которой включено подключение VPN типа "сеть — сеть" или Express Route. | Устранена необходимость обслуживания VPN типа "сеть — сеть" или Express Route для обратной репликации. |
| Кроме того, необходимо настроить стороннее средство MySQL. | Удалена зависимость от любых сторонних средств. |
Какие компьютеры следует перенести в модернизированную архитектуру?
Все виртуальные машины VMware или физические компьютеры, которые реплика с помощью сервера конфигурации, должны быть перенесены в модернизируемую архитектуру.
Где следует создать модернизированное хранилище Служб восстановления?
Модернизированное хранилище служб восстановления должно находиться в том же регионе и клиенте, что и классическое хранилище. Оно может принадлежать к любой подписке или группе ресурсов.
Продолжится ли репликация во время миграции?
Нет, во время миграции репликация будет прервана на какое-то время. В течение этого времени последняя созданная точка восстановления в классическом хранилище Служб восстановления будет доступна для отработки отказа. После завершения миграции в хранилище обновленных служб восстановления создается новая точка восстановления.
Когда операция миграции будет помечена как завершенная?
Операция миграции будет помечена как завершенная только после успешного создания первой точки восстановления в модернизированном хранилище Служб восстановления.
Какие операции можно выполнить из классического хранилища Служб восстановления после миграции?
После миграции можно выполнить отработку отказа из классического хранилища. Операция отработки отказа будет доступна в классическом хранилище до истечения срока действия точек восстановления.
Например, если срок хранения для реплика элемента составляет 72 часа (три дня), после успешной миграции будет доступна после последней точки восстановления в классическом хранилище. После указанного времени Azure Site Recovery автоматически активирует операцию очистки реплика на реплика элементе и выполняет очистку всех связанных хранилищ и элементов, вызывающих выставление счетов.
Что делать, если во время выполнения операции миграции на компьютере возникнет аварийная ситуация?
Любой реплика добавленный элемент, проходящий миграцию, по-прежнему может поддерживать операцию отработки отказа через классическое хранилище служб восстановления до окончания срока хранения конечной точки восстановления. При попытке выполнить операцию отработки отказа она будет иметь приоритет над операцией миграции, а задание миграции прервано. Чтобы убедиться, что реплика перенесенный элемент, необходимо снова активировать операцию миграции позже.
Примечание.
Свойства в колонке "Вычисления и сеть" реплицированных элементов можно обновить во время миграции. Однако изменения могут не реплицироваться в модернизированное хранилище Служб восстановления.
Сколько компьютеров можно перенести за раз из классического хранилища в модернизированное?
С помощью портала за раз можно выполнить миграцию до 10 компьютеров.
Следует ли повторно создавать виртуальные сети, учетные записи хранения и политику репликации для использования в новом хранилище?
Нет, в модернизированном хранилище будут по умолчанию использоваться те же ресурсы, которые использовались ранее. Вы всегда можете изменить их из колонки вычислений и сети реплика элемента. Необходимо убедиться, что ресурсы по-прежнему имеют требуемый доступ.
Как будут перемещаться политики репликации в модернизированное хранилище?
При условии Site Recovery создаст политики реплика tion в модернизируемом хранилище с той же конфигурацией, что и в классическом хранилище. Таким образом, перед перемещением реплика измененного элемента связанная политика создается в модернизируемом хранилище. Рекомендуется избегать внесения изменений в конфигурацию политик реплика tion в классическом хранилище после активации миграции, так как эти изменения не будут отражены в модернизированном хранилище. Перед началом процесса миграции рекомендуется внести эти изменения.
Имя политики репликации, созданной в модернизированном хранилище, будет изменено. Он префиксируется с именем группы ресурсов и именем хранилища обновленных хранилищ служб восстановления. Таким образом, если имя политики было "политикой реплика tion по умолчанию" в классическом хранилище, то в модернизированном хранилище это имя политики, учитывая, что имя default replication policy contoso-modern-vault_contoso-rgхранилища — contoso-modern-vault, а группа ресурсов хранилища — contoso-rg.
Можно ли изменить политику репликации во время миграции или после нее в классическом хранилище?
Если реплика политики репликации уже создана в модернизированном хранилище, изменения политики в классическом хранилище не будут распространяться в модернизированное хранилище.
Таким образом, если есть 10 реплика элементов, которые реплика с помощью политики, и вы решили переместить 5 из них в модернизированный интерфейс, то перед началом миграции создается копия политики. Теперь перед выполнением миграции оставшихся пяти элементов, если какие-либо изменения внесены в политику в классическом хранилище, политика из модернизированного хранилища не будет обновлена. Эти изменения конфигурации также необходимо внести в модернизируемом хранилище.
Как перенести реплицированные элементы, которые присутствуют в группе репликации, известной также как группа согласованности с несколькими виртуальными машинами?
Все реплика элементы, которые являются частью группы реплика tion, переносятся вместе. Вы можете выбрать все из них, выбрав группу реплика tion или пропустить их все. Если процесс миграции завершается сбоем для некоторых компьютеров в группе реплика tion, но выполняется откат к классическому интерфейсу для неудавшихся реплика элементов, и процесс миграции можно активировать снова для этих элементов.
Можно ли перенести классическую настройку с общедоступной конечной точкой в модернизацию установки с помощью частной конечной точки?
Нет, можно переместить только классическую настройку аварийного восстановления с общедоступной конечной точкой в модернизированную настройку общедоступной конечной точки. Обратите внимание, что миграция частной конечной точки в частную конечную точку не поддерживается, но миграция частной конечной точки в частную конечную точку поддерживается.
Следующие шаги
Инструкции по переходу с классического на модернизированное аварийное восстановление VMware