Развертывание агента служба хранилища Azure Mover
Служба mover служба хранилища Azure использует агенты для выполнения заданий миграции, настроенных в службе. Агент — это устройство миграции на основе виртуальных машин, которое выполняется на узле виртуализации. В идеале узел виртуализации находится как можно ближе к исходному хранилищу для переноса. Mover хранилища может поддерживать несколько агентов.
Поскольку агент по сути является устройством миграции, вы взаимодействуете с ним с помощью локальной административной оболочки агента. Оболочка ограничивает операции, которые можно выполнять на этом компьютере, хотя конфигурация сети и задачи устранения неполадок доступны.
Использование агента в миграции осуществляется через Azure. Поддерживаются Azure PowerShell и CLI, а графическое взаимодействие доступно в портал Azure. Агент доступен как образ диска, совместимый с новыми виртуальными машинами Windows Hyper-V или VMware.
В этой статье описаны действия, необходимые для успешного развертывания виртуальной машины агента Mover хранилища.
Необходимые компоненты
- Приведенные ниже конечные точки Mover хранилища должны иметь доступ к трафику https
mcr.microsoft.com<region>.agentgateway.prd.azsm.azure.comevhns-sm-ur-prd-<region>.servicebus.windows.net
- Узел Windows Hyper-V или VMware, на котором выполняется виртуальная машина агента.
Дополнительные сведения о требованиях к ресурсам агента см. в разделе "Рекомендуемые ресурсы вычислений и памяти".
Примечание.
В настоящее время Windows Hyper-V и VMware являются единственными поддерживаемыми средами виртуализации для виртуальной машины агента. Другие среды виртуализации не протестированы и не поддерживаются.
Определение необходимых ресурсов для виртуальной машины
Как и каждая виртуальная машина, агент требует доступных вычислительных ресурсов, памяти, сети и дискового пространства на узле. Хотя общий размер данных может повлиять на время, необходимое для завершения миграции, обычно это количество файлов и папок, которые определяют требования к ресурсам.
Сетевые ресурсы
Агенту требуется неограниченное подключение к Интернету.
Хотя ни один параметр конфигурации сети не работает для каждой среды, простейшая конфигурация включает развертывание внешнего виртуального коммутатора. Тип внешнего коммутатора подключен к физическому адаптеру и позволяет операционной системе узла совместно использовать подключение ко всем виртуальным машинам. Этот коммутатор позволяет обмен данными между физической сетью, операционной системой управления и виртуальными адаптерами на виртуальных машинах. Этот подход может быть приемлемым для тестовой среды, но, скорее всего, недостаточно для рабочего сервера.
После создания коммутатора убедитесь, что виртуальные машины управления и агента находятся на одном коммутаторе. В брандмауэре связи глобальной сети должен быть открыт исходящий TCP-порт 443. Помните, что прерывания подключения должны ожидаться при изменении конфигураций сети.
Вы можете получить справку по созданию виртуального коммутатора для виртуальных машин Hyper-V в документации по Windows Server . Ознакомьтесь с веб-сайтом поддержки VMware, чтобы получить подробные рекомендации по созданию виртуального коммутатора для виртуальных машин, размещенных на VMware.
Рекомендуемые ресурсы вычислений и памяти
| Масштаб миграции* | Память (ОЗУ) | Число ядер виртуального процессора (в 2 ГГц мин.) |
|---|---|---|
| 1 миллион элементов | 8 ГиБ | 4 виртуальных ядра |
| 10 миллионов элементов | 8 ГиБ | 4 виртуальных ядра |
| 30 миллионов элементов | 12 ГиБ | 6 виртуальных ядер |
| 50 миллионов элементов | 16 ГиБ | 8 виртуальных ядер |
| 100 миллионов элементов | 16 ГиБ | 8 виртуальных ядер |
Количество элементов ссылается на общее количество файлов и папок в источнике.
Внимание
Хотя виртуальные машины агента ниже минимальных спецификаций могут работать для миграции, они могут не работать оптимально и не поддерживаются.
В статье целевых показателей производительности содержатся результаты теста из разных исходных пространств имен и ресурсов виртуальной машины.
Емкость локального хранилища
Как минимум, образ агента должен иметь 20 ГиБ локального хранилища. Требуемый объем может увеличиться, если во время миграции кэшируются большое количество небольших файлов.
Скачивание образа виртуальной машины агента
Образы виртуальных машин агента размещаются в Центре загрузки Майкрософт в виде ZIP-файла. Скачайте файл https://aka.ms/StorageMover/agent и извлеките образ виртуального жесткого диска агента на узел виртуализации.
Создание виртуальной машины агента
Ниже описан процесс создания виртуальной машины с помощью Microsoft Hyper-V. Ознакомьтесь с веб-сайтом поддержки VMware, чтобы получить подробные рекомендации по созданию виртуальной машины на основе VMware.
Создайте виртуальную машину для размещения агента. Откройте диспетчер Hyper-V. В области "Действия" выберите "Создать" и "Виртуальная машина", чтобы запустить мастер создания виртуальной машины.
В области "Указание имени" и "Расположение" укажите значения полей "Имя и расположение" виртуальной машины агента. Если это возможно, расположение должно соответствовать папке, в которой хранится виртуальный жесткий диск. Выберите Далее.
В области "Указание поколения" выберите параметр "Поколение 1".
Внимание
Поддерживаются только виртуальные машины поколения 1 . Этот образ Linux не будет загружаться как виртуальная машина поколения 2 .
Если вы еще не сделали этого, определите объем памяти, необходимой для виртуальной машины. Введите этот объем в области "Назначение памяти ", отметив, что необходимо ввести значение в MiB. 1 ГиБ = 1024 МиБ. Использование функции динамической памяти хорошо.
В области "Настройка сети" выберите раскрывающийся список "Подключение". В списке выберите виртуальный коммутатор, который предоставляет агенту подключение к Интернету и нажмите кнопку "Далее". Дополнительные сведения см. в документации по виртуальным сетям Hyper-V.
В области "Подключение виртуального жесткого диска" выберите параметр "Использовать существующий виртуальный жесткий диск". В поле "Расположение" выберите "Обзор" и перейдите к VHD-файлу, который был извлечен на предыдущих шагах. Выберите Далее.
В области "Сводка" нажмите кнопку "Готово", чтобы создать виртуальную машину агента.
После успешного создания нового агента он появится в области Виртуальные машины в диспетчере Hyper-V.
Изменение пароля по умолчанию
Агент поставляется с учетной записью пользователя по умолчанию и паролем. Подключитесь к только что созданному агенту и измените пароль по умолчанию сразу после развертывания и запуска агента.
На компьютере в той же подсети, что и агент, выполните команду SSH:
ssh <AgentIpAddress> -l admin
Внимание
Недавно развернутый агент Перемещения хранилища имеет пароль по умолчанию: локальный пользователь:
пароль администратора по умолчанию: администратор
Вам будет предложено сразу же изменить пароль по умолчанию после первого подключения к только что развернутному агенту. Запишите новый пароль, процесс восстановления не выполняется. Потеря пароля блокирует вас из административной оболочки. Для управления облаком этот пароль локального администратора не требуется. Если агент был зарегистрирован ранее, его можно использовать для заданий миграции. Агенты являются одноразовыми. Они содержат мало значения за пределами текущего задания миграции, которое они выполняют. Вы всегда можете развернуть новый агент и использовать его для выполнения следующего задания миграции.
Регулирование пропускной способности
Прежде чем развертывать его в сети, рассмотрите объем пропускной способности нового компьютера. Агент mover служба хранилища Azure взаимодействует с исходной папкой с помощью локальной сети и служба хранилища Azure службы по каналу WAN. В обоих случаях агент предназначен для полного использования пропускной способности сети по умолчанию. Однако теперь можно задать расписания управления пропускной способностью для агентов Mover хранилища.
Кроме того, можно создать локальную виртуальную сеть с подключением к Интернету и настроить параметры качества обслуживания (QoS). Этот подход позволяет предоставлять агент через виртуальную сеть и локально настраивать неавтономизованный сетевой прокси-сервер на агенте при необходимости.
Отмена эксплуатации агента
Если вам больше не нужен определенный агент перемещения хранилища, его можно выходить из эксплуатации. Вывод из эксплуатации — это двухэтапный процесс:
- Отмена регистрации агента из ресурса перемещения хранилища.
- Остановите виртуальную машину агента на узле виртуализации и удалите ее.
Отмена эксплуатации агента начинается с отмены регистрации агента. Существует три варианта запуска процесса отмены регистрации:
Вы можете отменить регистрацию агента с помощью административной оболочки виртуальной машины агента. Агент должен быть подключен к службе и отображаться как локально, так и через портал Azure и Azure PowerShell или Azure CLI.
На компьютере в той же подсети, что и агент, выполните команду SSH:
ssh <AgentIpAddress> -l admin
Внимание
Недавно развернутый агент Перемещения хранилища имеет пароль по умолчанию: локальный пользователь:
пароль администратора по умолчанию: администратор
Вам будет предложено сразу же изменить пароль по умолчанию после первого подключения к только что развернутному агенту. Запишите новый пароль, процесс восстановления не выполняется. Потеря пароля блокирует вас из административной оболочки. Для управления облаком этот пароль локального администратора не требуется. Если агент был зарегистрирован ранее, его можно использовать для заданий миграции. Агенты являются одноразовыми. Они содержат мало значения за пределами текущего задания миграции, которое они выполняют. Вы всегда можете развернуть новый агент и использовать его для выполнения следующего задания миграции.
1) System configuration
2) Network configuration
3) Service and job status
4) Unregister
5) Collect support bundle
6) Restart agent
7) Disk Cleanup
8) Exit
xdmsh> 4
Выберите вариант 4) Отмена регистрации. Появится сообщение с предложением подтвердить операцию.
Предупреждение
Отмена регистрации останавливает выполнение задания миграции на агенте и окончательно удаляет агент из пула доступных агентов миграции. Повторная регистрация ранее зарегистрированной виртуальной машины агента не поддерживается. Если вам нужен новый агент, необходимо зарегистрировать новую ранее незарегистрированную виртуальную машину агента. Не используйте ранее незарегистрированную виртуальную машину агента.
Во время процесса отмены регистрации происходит несколько действий:
Агент удаляется из ресурса перемещения хранилища. Агент больше не отображается на вкладке "Зарегистрированные агенты" на портале или выбрать его для новых заданий миграции.
Агент также удаляется из службы Azure ARC. Это удаление удаляет гибридный вычислительный ресурс типа Server — Azure Arc, который представлял агент со службой Azure ARC в той же группе ресурсов, что и ресурс перемещения хранилища.
Отмена регистрации удаляет управляемое удостоверение агента из идентификатора Microsoft Entra. Связанный субъект-служба автоматически удаляется, отменяя разрешения, которые этот агент может иметь в других ресурсах Azure. Если вы проверяете назначения ролей управления доступом на основе ролей (RBAC), например контейнер целевого хранилища, для агента ранее были разрешения, вы больше не найдете субъект-службу агента, так как он был удален. Само назначение по-прежнему отображается как "Неизвестный субъект-служба", но это назначение больше не подключается к удостоверению и никогда не может быть повторно подключено. Это просто признак того, что назначение роли использовалось здесь, субъекта-службы, который больше не существует.
Это поведение является стандартным и не зависит от служба хранилища Azure Mover. Вы можете наблюдать такое же поведение, если удалить другой субъект-службу из идентификатора Microsoft Entra ID, а затем проверить прежнее назначение роли.
Предупреждение
Отмена регистрации автономного агента поддерживается, но ресурс Azure ARC агента не удаляется автоматически. Вместо этого необходимо вручную удалить ресурс после отмены регистрации автономного агента. Жизненный цикл управляемого удостоверения агента привязан к этому ресурсу. Удаление удаляет управляемое удостоверение и субъект-службу, как описано ранее.
Вы можете проверить, завершен ли процесс отмены регистрации, когда агент исчезнет из портал Azure и Azure PowerShell или Azure CLI. Кроме того, необходимо убедиться, что гибридный вычислительный ресурс типа Server — Azure Arc удален из группы ресурсов.
Вы также можете использовать административную оболочку агента для проверки того, что агент не зарегистрирован. Чтобы проверить отмену регистрации, перейдите к любому подменю, а затем вернитесь в меню верхнего уровня. Если отмена регистрации выполнена успешно, вы увидите, что параметр меню переключился из отмены регистрации на register. Как упоминалось ранее, повторная регистрация не поддерживается.
Вы можете остановить виртуальную машину агента на узле виртуализации после завершения отмены регистрации. Рекомендуется удалить образ виртуальной машины агента, так как он был ранее зарегистрирован, сохраняет некоторое состояние и не должен использоваться повторно. Если вам нужен новый агент, разверните новую виртуальную машину с новым образом агента, никогда не зарегистрировано.
Следующие шаги
После развертывания агента запустите его и измените пароль по умолчанию локальной учетной записи: