Подготовка зоны приземления для миграции

2025-05-14

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

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

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

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

Замечание

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

Установка гибридного подключения

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

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

Дополнительные сведения о технических рекомендациях по конкретным сценариям см. в следующих руководствах.

Замечание

Дополнительные рекомендации также см. в конкретной документации поставщика.

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

Подготовка идентификационных данных

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

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

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

Вы также должны просмотреть базовые показатели удостоверений на этапе управления, чтобы определить, нужно ли вносить изменения в идентификатор Microsoft Entra.

Расширение контроллеров домена Active Directory

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

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

Общие шаблоны архитектуры для развертывания этих ресурсов см. в статье "Развертывание доменных служб Active Directory ( AD DS) в виртуальной сети Azure.

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

Microsoft Entra Connect

Многие организации уже имеют Microsoft Entra Connect для заполнения служб Microsoft 365, таких как Exchange Online. Если у вашей организации нет Microsoft Entra Connect, возможно, потребуется установить его и настроить после развертывания целевой площадки, чтобы реплицировать учётные записи.

Включение гибридного DNS

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

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

Пользовательское разрешение DNS

Если вы используете Active Directory для сопоставителя DNS или развертываете стороннее решение, необходимо развернуть виртуальные машины. Эти виртуальные машины можно использовать в качестве DNS-серверов, если контроллеры домена развертываются в подписке идентификации и сетевом узле. В противном случае необходимо развернуть и настроить виртуальные машины для размещения этих служб.

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

Вы также можете использовать Azure DNS Private Resolver, но эта служба не развертывается в рамках развертывания вашей целевой зоны приземления Azure.

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

Брандмауэр Azure DNS-прокси

Брандмауэр Azure можно настроить как DNS-прокси. Брандмауэр Azure может получать трафик и пересылать его в резолвер Azure или на ваши DNS-серверы. Эта конфигурация позволяет выполнять поиск из локальной среды в Azure, но их нельзя условно перенаправить на локальные DNS-серверы.

Если требуется гибридное разрешение DNS, можно настроить прокси-сервер DNS брандмауэра Azure для пересылки трафика на пользовательские DNS-серверы, например контроллеры домена.

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

Настройка настраиваемых DNS-серверов виртуальной сети

После завершения предыдущих действий можно настроить DNS-серверы для виртуальных сетей Azure на пользовательские серверы, которые вы используете.

Для получения дополнительной информации см. параметры DNS Брандмауэра Azure.

Настройка брандмауэра центра

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

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

Если вы используете сторонний NVA в качестве брандмауэра, ознакомьтесь с руководством поставщика и нашим общим руководством по обеспечению высокой доступности NVAs.

Развертывание стандартных наборов правил

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

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

Маршрутизация

Azure обеспечивает маршрутизацию для следующих сценариев без дополнительной конфигурации:

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

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

Маршрутизация между периферийными узлами

Для области проектирования сети многие организации используют топологию сети с концентраторами.

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

Если вы хотите разрешить исходящий трафик через Интернет, можно также назначить другой маршрут для частного IP-пространства брандмауэру, например 10.0.0.0/8. Эта конфигурация не переопределяет более конкретные маршруты. Но вы можете использовать его как простой маршрут, чтобы межспицевой трафик можно было правильно маршрутизировать.

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

Маршрутизация из подсети шлюза

Если вы используете виртуальные сети для концентратора, необходимо спланировать обработку проверки трафика, поступающих из шлюзов.

Если вы планируете проверить трафик, вам потребуется две конфигурации:

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

Дополнительные сведения о пользовательских и определяемых Azure маршрутах см. в статье "Маршрутизация трафика виртуальной сети Azure".

Если вы планируете проверить трафик к частным конечным точкам, включите соответствующую политику маршрутизации сети в подсети, где размещаются частные конечные точки. Дополнительные сведения см. в разделе "Управление политиками сети для частных конечных точек".

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

Настройка мониторинга и управления

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

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

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

Подготовка площадки для миграции суверенных рабочих нагрузок

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

Эти возможности можно включить, развернув суверенную зону высадки. Архитектура суверенной целевой зоны соответствует рекомендуемой схеме целевой зоны Azure .

Портфель политики Microsoft Cloud for Sovereignty

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

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

Включение управления подписками

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

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

Подготовка к Microsoft Defender для облака

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

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

Рассмотрим эти дополнительные ресурсы для подготовки к миграции: