Часто задаваемые вопросы (FAQ) о посадочной зоне Azure

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

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

Что такое акселератор портала зоны приземления Azure?

Акселератор портала зоны посадки Azure — это опыт развертывания, основанный на портале Azure. Он развертывает строго определенную реализацию на основе эталонной архитектуры целевой зоны Azure.

Какие являются рекомендуемые ускорители и внедрения для целевых зон Azure?

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

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

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

Что такое эталонная архитектура зоны высадки Azure?

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

На что сопоставляется посадочная зона в Azure в контексте архитектуры посадочной зоны Azure?

С точки зрения концепции landing zone в Azure, целевые зоны являются отдельными подписками Azure.

Что означает управление, управляемое политикой, и как это работает?

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

Управление на основе политик означает использование политики Azure, чтобы сократить время, необходимое для распространенных и повторяющихся операционных задач в клиенте Azure. Используйте множество эффектов политики Azure, таких как Append, Deny, DeployIfNotExists и Modify, чтобы предотвращать несоответствие требованиям, ограничивая создание или обновление несоответствующих ресурсов (как определено в определении политики), либо развертывая ресурсы или изменяя параметры в запросе на создание или обновление ресурса, чтобы обеспечить их соответствие. Некоторые эффекты, такие как AuditDisabled, и AuditIfNotExists, не предотвращают или не принимают меры; они только проверяют и сообщают о несоответствии.

Ниже приведены некоторые примеры управления на основе политик:

• Deny Эффект: Запрещает создание или обновление подсетей без ассоциации с группами безопасности сети.

• DeployIfNotExists Результат: Создается новая подписка (landing zone) и помещается в группу управления в развертывании Azure landing zone. Политика Azure гарантирует, что Microsoft Defender для облака (прежнее название — Центр безопасности Azure) включен в подписке. Он также настраивает параметры диагностики для журнала действий для отправки журналов в рабочую область Log Analytics в подписке "Управление".

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

Что делать, если мы не можем или еще не готовы использовать политики DeployIfNotExists (DINE)?

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

Ознакомьтесь с руководством по внедрению политик, ориентированных на политические рамки

Следует ли использовать политику Azure для развертывания рабочих нагрузок?

Короче говоря, нет. Используйте политику Azure для управления, контроля и соблюдения соответствия ваших рабочих нагрузок и зон размещения. Он не предназначен для развертывания полноценнных рабочих нагрузок и другого инструментария. Используйте портал Azure или предложения по внедрению инфраструктуры как кода (шаблоны ARM, Bicep, Terraform) для развертывания и управления вашей рабочей нагрузкой, чтобы достичь необходимой автономии.

Что такое посадочные зоны Cloud Adoption Framework для Terraform (aztfmod)?

Проект с открытым исходным кодом для целевых зон Cloud Adoption Framework (OSS) (также известный как aztfmod) — это проект, управляемый сообществом, который находится и поддерживается за пределами основной команды Azure по целевым зонам и организации Azure GitHub. Если ваша организация решит использовать этот проект ОСЗ (открытое программное обеспечение), следует учитывать доступную поддержку, так как она зависит от усилий сообщества через GitHub.

Что, если у нас уже есть ресурсы в целевых зонах, и позже мы применим определение политики Azure, которое включает их в область охвата?

Ознакомьтесь со следующими разделами документации:

• Переход существующих сред Azure в эталонную архитектуру целевой зоны Azure — раздел "Политика"
• Быстрый старт: Создание назначения политики для выявления несоответствующих ресурсов — раздел "Определение несоответствующих ресурсов"

Нужна ли выделенная или отдельная целевая зона ИИ?

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

Как обрабатывать зоны приземления для рабочих нагрузок dev/test/production в архитектуре зон приземления Azure?

Дополнительные сведения см. в статье "Управление средами разработки приложений в целевых зонах Azure".

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

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

Селектор региона на вкладке "Расположение развертывания" также используется для выбора региона Azure, в котором должны храниться ресурсы, относящиеся к конкретному региону, например, рабочая область Log Analytics, если это необходимо.

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

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

Как включить больше регионов Azure при использовании архитектуры базовой площадки Azure?

Сведения о том, как добавить новые регионы в целевую зону или как переместить ресурсы целевой зоны в другой регион, см. в разделе "Регионы целевой зоны".

Следует ли создавать новую подписку Azure каждый раз или повторно использовать подписки Azure?

Что такое повторное использование подписки?

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

Почему следует повторно использовать подписки?

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

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

• У вас есть Enterprise Agreement (EA), и вы планируете создать более 5000 подписок на одну учетную запись владельца EA (учетная запись для выставления счетов), включая удаленные подписки.
• У вас есть клиентское соглашение Майкрософт (MCA) или MPA партнера Майкрософт и планируется иметь более 5000 активных подписок. Дополнительные сведения об ограничениях подписки см. в статье "Учетные записи и области выставления счетов" на портале Azure.
• Вы являетесь клиентом с оплатой по мере использования.
• Вы используете спонсорство Microsoft Azure.
• Вы обычно создаете:
  1. Эфемерные лабораторные среды или песочницы
  2. Демонстрационные среды для проверки концепции (POCs) или минимальных жизнеспособных продуктов (MVP), включая независимых поставщиков программного обеспечения (ISV) для демонстрации и пробного доступа клиента
  3. Учебные среды, такие как среды обучения MSPs/учебные среды тренеров

Как повторно использовать подписки?

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

Очистка старой подписки

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

• Удалите группы ресурсов и содержащиеся ресурсы.
• Удалите назначения ролей, включая назначения ролей управления привилегированными удостоверениями (PIM), на уровне подписки.
• Удалите определения пользовательского управления доступом на основе ролей (RBAC) в области подписки.
• Удалите определения политик, инициативы, назначения и исключения на уровне подписки.
• Удалите развертывания в области подписки.
• Удалите теги в области подписки.
• Удалите все блокировки ресурсов в области подписки.
• Удалите все бюджеты Microsoft Cost Management в области подписки.
• Сбросьте Microsoft Defender для облака на бесплатные уровни, если организационные требования не предписывают использование платных уровней для этих журналов. Обычно эти требования применяются с помощью политики Azure.
• Удалите журналы активности подписки (настройки диагностики) пересылки в рабочие области Log Analytics, Центры событий, учетные записи хранения или другие поддерживаемые направления, если только требования организации не требуют переадресации этих журналов во время активной подписки.
• Удалите все делегирования Azure Lighthouse в области подписки.
• Удалите все скрытые ресурсы из подписки.

Переназначение подписки

После очищения подписки можно переназначить её. Ниже приведены некоторые распространенные действия, которые могут потребоваться выполнить в процессе переназначения:

• Добавьте новые теги и задайте значения для них в подписке.
• Добавьте новые назначения ролей или назначения привилегированных ролей управления удостоверениями (PIM) в области подписки для новых владельцев. Как правило, эти назначения будут выполняться в группах Microsoft Entra вместо отдельных пользователей.
• Поместите подписку в нужную группу управления на основе требований к управлению.
• Создайте новые бюджеты управления затратами Майкрософт и задайте для новых владельцев оповещения при достижении пороговых значений.
• Задайте для Microsoft Defender для облака нужные уровни. Этот параметр следует применить с помощью политики Azure после его размещения в правильной группе управления.
• Настройте параметры диагностики журналов действий подписки для пересылки в рабочие области Log Analytics, центры событий, учетные записи хранения или другие поддерживаемые целевые назначения. Этот параметр следует применить с помощью политики Azure после его размещения в правильной группе управления.

Что такое суверенная зона посадки и как она связана с архитектурой посадочной зоны Azure?

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

Дополнительные сведения о суверенной зоне посадки см. в разделе "Суверенная зона посадки (SLZ)".