Что делать после переноса виртуальных машин в облако

В Интернете доступно бесчисленное множество справочных материалов (в том числе многие из тех, что я написал сам), которые призваны помочь вам в процессе переноса виртуальных машин в общедоступные облака, такие как AWS или Microsoft Azure. Однако не так часто встречаются ресурсы, предназначенные для того, чтобы помочь вам выполнить все задачи после миграции, которые необходимо выполнить. В таком случае я хотел бы воспользоваться возможностью, чтобы рассказать о некоторых вещах, которые вам могут понадобиться после переноса виртуальных машин в облако.

Прежде чем я начну

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

Тест RDP

Самое первое, что я рекомендую сделать после того, как вы мигрировали виртуальную машину в облако, — это убедиться, что вы можете подключиться к виртуальной машине по протоколу RDP (или использовать SSH, если виртуальная машина работает под управлением Linux).

Конечно, существуют инструменты управления, которые позволяют управлять виртуальными машинами, не прибегая к использованию RDP. Например, вы можете использовать веб-консоль для управления приложением виртуальной машины или центр администрирования Windows для управления конфигурацией виртуальной машины. Тем не менее, важно иметь возможность напрямую подключаться к консоли виртуальной машины, если вам нужно выполнить ремонт или техническое обслуживание, которые невозможно выполнить с помощью более традиционных инструментов управления.

Программное обеспечение безопасности

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

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

Проверьте часовой пояс

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

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

Тестовое разрешение имен DNS

Еще одна вещь, которую я рекомендую сделать после переноса виртуальной машины в общедоступное облако, — убедиться, что разрешение DNS-имен по-прежнему работает должным образом.

Когда вы перемещаете виртуальную машину в облако, эта виртуальная машина будет подключена к другой подсети, чем раньше. По крайней мере, это означает, что IP-адрес виртуальной машины изменится. Если виртуальная машина настроена на использование DHCP, велика вероятность того, что DHCP-сервер также заставит виртуальную машину использовать другой DNS-сервер для запросов на разрешение имен. Это не проблема, если виртуальной машине нужно выполнять только DNS-запросы Интернета. Однако это проблема, если виртуальная машина должна иметь возможность разрешать имена в вашей собственной сети.

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

Следующее, что мне нравится делать, это пинговать IP-адрес в моей собственной сети. Таким образом, я могу убедиться, что облачная виртуальная машина имеет действительный путь связи с ресурсами в моей сети. Предполагая, что этот ping успешен, я повторяю ping-тест, но на этот раз я использую полное доменное имя ресурса вместо его IP-адреса. Это подтверждает, что разрешение имен DNS работает для моей частной сети.

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

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

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