Поделиться через

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

  • Статья

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

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

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

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

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

Во время развертывания целевой зоны Azure можно развернуть подписку Подключение ivity с помощью концентратора виртуальной сети и сетевых шлюзов, таких как 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 в области сети удостоверений, развернутой вами. После развертывания виртуальных машин необходимо выполнить обычный процесс повышения уровня контроллера домена, чтобы добавить их в домен. Этот процесс может включать создание дополнительных сайтов для поддержки топологии реплика tion.

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

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

Microsoft Entra Connect

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения см. в разделе Брандмауэр Azure параметров DNS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Портфель политик безопасности Microsoft Cloud для суверенитета

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

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

Включение вендинг по подписке

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

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

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

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

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

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

Следующие шаги

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