Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье приведены ответы на часто задаваемые вопросы об архитектуре Azure посадочной зоны.
Часто задаваемые вопросы о внедрении архитектуры зоны размещения Azure см. в разделе Вопросы и ответы по реализации в масштабе корпорации.
Что такое акселератор портала целевой зоны Azure?
Акселератор посадочной зоны Azure — это система развертывания, основанная на портале Azure. Он развертывает предопределённую реализацию на основе эталонной архитектуры зоны приземления Azure.
Какие рекомендуемые ускорители и реализации для посадочных зон Azure?
Майкрософт активно разрабатывает и поддерживает платформенные акселераторы и реализации приложений в соответствии с принципами проектирования зоны высадки Azure и руководством по областям проектирования.
Ознакомьтесь с руководством Deploy Azure целевых зон чтобы узнать больше о рекомендуемых целевых зонах платформы и приложений.
Сведения о том, как настроить развертывание целевых зон Azure в соответствии с вашими потребностями, см. в статье Настройка архитектуры целевых зон Azure, чтобы соответствовать требованиям
Подсказка
Чтобы запросить дополнение к списку акселераторов и реализаций, создайте проблему GitHub в репозитории ALZ.
Что такое эталонная архитектура стартовой зоны Azure?
Эталонная архитектура зоны приземления Azure отражает решения, касающиеся масштабирования и уровня зрелости. Это основано на уроках, извлеченных из отзывов клиентов, освоивших Azure в рамках своей цифровой инфраструктуры. Эта концептуальная архитектура поможет вашей организации задать направление разработки и реализации посадочной зоны.
Какие объекты соответствуют посадочной зоне в Azure в контексте архитектуры посадочной зоны в Azure?
С точки зрения зоны приземления Azure, зоны приземления являются отдельными подписками Azure.
Что означает управление, управляемое политикой, и как это работает?
Управление на основе политик является одним из ключевых принципов архитектуры корпоративного масштаба.
Управление на основе политик означает использование Политика Azure, чтобы сократить время, необходимое для распространенных и повторяющихся операционных задач в клиенте Azure. Используйте многие эффекты Политика Azure, такие как Append, Deny, DeployIfNotExists и Modify, чтобы предотвратить несоответствие требованиям, ограничивая создание или обновление несоответствующих ресурсов (как определено в определении политики) или путем развертывания ресурсов и изменения параметров запроса на создание или обновление ресурсов для обеспечения их соответствия. Некоторые эффекты, такие как AuditDisabled, и AuditIfNotExists, не предотвращают или не принимают меры; они только проверяют и сообщают о несоответствии.
Ниже приведены некоторые примеры управления на основе политик:
DenyЭффект: Запрещает создание или обновление подсетей без ассоциации с группами безопасности сети.DeployIfNotExistsэффект: создается новая подписка в целевой зоне и помещается в группу управления в развертывании целевой зоны Azure. Политика Azure гарантирует, что в подписке включена Microsoft Defender для облака. Он также настраивает параметры диагностики для журнала действий для отправки журналов в рабочую область Log Analytics в подписке "Управление".Вместо повторения кода или выполнения действий вручную при создании новой подписки, определение политики
DeployIfNotExistsавтоматически развертывает и настраивает их для вас.
Что делать, если мы не можем или еще не готовы использовать политики DeployIfNotExists (DINE)?
У нас есть выделенная страница, которая объясняет различные этапы и параметры, посредством которых вы можете либо "отключить политики DINE", либо использовать наш трехэтапный подход для их внедрения в вашем окружении.
Ознакомьтесь с руководством по внедрению политик, ориентированных на политические рамки
Следует ли использовать Политика Azure для развертывания рабочих нагрузок?
Короче говоря, нет. Используйте Политика Azure для контроля, управления и поддержания соответствия эксплуатационных нагрузок и зон приземления. Он не предназначен для развертывания полноценнных рабочих нагрузок и другого инструментария. Используйте портал Azure или предложения по коду инфраструктуры (шаблоны ARM, Bicep, Terraform) для развертывания и управления вашей рабочей нагрузкой и для получения необходимой автономии.
Что такое структура внедрения облачных технологий: зоны высадки для Terraform (aztfmod)?
Проект Cloud Adoption Framework целевых сред открытый код (OSS) (также известный как aztfmod) — это проект, управляемый сообществом, принадлежащий и поддерживаемый вне основной команды Azure целевых сред и организации Azure GitHub. Если ваша организация решит использовать этот проект с открытым исходным кодом, следует учитывать доступную поддержку, поскольку она определяется усилиями сообщества через GitHub.
Что если у нас уже есть ресурсы в наших целевых зонах и затем мы назначим определение Политика Azure, включающее их в свою область действия?
Ознакомьтесь со следующими разделами документации:
- Переход существующих сред Azure к эталонной архитектуре целевой зоны Azure — раздел "Политика"
- Быстрый старт: Создание назначения политики для выявления несоответствующих ресурсов — раздел "Определение несоответствующих ресурсов"
Нужна ли выделенная или отдельная целевая зона ИИ?
Нет, вам не нужна отдельная целевая зона ИИ. Вместо этого можно использовать существующую архитектуру целевой зоны Azure для развертывания рабочих нагрузок ИИ. Ознакомьтесь с руководством и объяснением в AI в зонах высадки Azure.
Как обрабатывать посадочные зоны рабочей нагрузки для разработки/тестирования/производства в архитектуре посадочных зон Azure?
Дополнительные сведения см. в разделе Управляемые среды разработки приложений в целевых зонах Azure.
Почему необходимо указывать регионы Azure при развертывании эталонной архитектуры посадочной зоны Azure и для чего они используются?
При развертывании архитектуры целевой зоны Azure с помощью интерфейса портала эталонной зоны Azure выберите регион Azure для развертывания. Первая вкладка , расположение развертывания определяет, где хранятся данные развертывания. Дополнительные сведения см. в статье о развертывании клиента с помощью шаблонов ARM. Некоторые части целевой зоны развертываются глобально, но их метаданные развертывания отслеживаются в региональном хранилище метаданных. Метаданные, касающиеся развертывания, хранятся в регионе, выбранном на вкладке "Расположение развертывания ".
Селектор региона на вкладке Расположение для развертывания также используется для выбора, в каком регионе Azure должны храниться регион-специфические ресурсы, такие как рабочая область Log Analytics, если это необходимо.
При развертывании сетевой топологии на вкладке Network и подключения необходимо выбрать регион Azure для развертывания сетевых ресурсов. Этот регион может отличаться от региона, выбранного на вкладке "Расположение развертывания ".
Дополнительные сведения о регионах, используемых ресурсами целевой зоны, см. в разделе "Регионы целевой зоны".
Как активировать больше регионов Azure при использовании архитектуры целевой зоны Azure?
Сведения о том, как добавить новые регионы в целевую зону или как переместить ресурсы целевой зоны в другой регион, см. в разделе "Регионы целевой зоны".
Следует ли создавать новую подписку Azure каждый раз или повторно использовать Azure подписки?
Что такое повторное использование подписки?
Повторное использование подписки — это процесс повторной отправки существующей подписки новому владельцу. Необходимо выполнить процесс сброса подписки до известного чистого состояния, а затем назначить нового владельца.
Почему следует повторно использовать подписки?
Как правило, рекомендуется, чтобы клиенты приняли принцип проектирования демократизации подписки. Однако существуют определенные обстоятельства, когда повторное использование подписки невозможно или рекомендуется.
Подсказка
Посмотрите видео на YouTube о принципе проектирования демократизации подписок: Посадочные зоны Azure - Сколько подписок следует использовать в Azure?
При выполнении одного из следующих обстоятельств следует рассмотреть возможность повторного использования подписки.
- У вас есть Enterprise Agreement (EA), и вы планируете создать более 5000 подписок на одну учетную запись владельца EA (учетная запись для выставления счетов), включая удаленные подписки.
- У вас есть Клиентское соглашение Майкрософт (MCA) или Соглашение с партнером Майкрософт MPA и планируется иметь более 5000 активных подписок. Дополнительные сведения об ограничениях подписки см. в статье Billing accounts and scopes in the Azure portal.
- Вы являетесь клиентом с оплатой по мере использования.
- Вы используете Microsoft Azure спонсорство.
- Вы обычно создаете:
- Эфемерные лабораторные среды или песочницы
- Демонстрационные среды для проверки концепции (POCs) или минимальных жизнеспособных продуктов (MVP), включая независимых поставщиков программного обеспечения (ISV) для демонстрации и пробного доступа клиента
- Учебные среды, такие как среды обучения MSPs/учебные среды тренеров
Как повторно использовать подписки?
Если вы соответствуете одному из описанных выше сценариев или рекомендаций, вам может потребоваться повторно использовать существующие списанные или неиспользуемые подписки и переназначить их новому владельцу и назначению.
Очистка старой подписки
Сначала необходимо очистить старую подписку для повторного использования. Прежде чем он готов к повторному использованию, необходимо выполнить следующие действия в подписке:
- Удалите группы ресурсов и содержащиеся ресурсы.
- Удалите назначения ролей, включая назначения управление привилегированными пользователями (PIM), на уровне подписки.
- Удалите пользовательские определения управления доступом на основе ролей (RBAC) на уровне подписки.
- Удалите определения политик, инициативы, назначения и исключения на уровне подписки.
- Удалите развертывания в области подписки.
- Удалите теги в области подписки.
- Удалите все блокировки ресурсов в области подписки.
- Удалите все бюджеты Управление затратами Microsoft на уровне подписки.
- Сбросить планы Microsoft Defender для облака на бесплатные уровни, если только требования организации не предусматривают установку этих журналов на платные уровни. Обычно эти требования применяются через Политика Azure.
- Удаляйте журналы активности подписки (параметры диагностики) пересылки в рабочие области Log Analytics, Центры событий, учетные записи хранения или другие поддерживаемые назначения, если только требования организации не требуют пересылки этих журналов, пока подписка активна.
- Удалите делегирование в "Azure Lighthouse" на уровне подписки.
- Удалите все скрытые ресурсы из подписки.
Подсказка
Использование Get-AzResource или az resource list -o table, нацеленных на область подписки, поможет вам найти скрытые или оставшиеся ресурсы для удаления перед повторным назначением.
Переназначение подписки
После очищения подписки можно переназначить её. Ниже приведены некоторые распространенные действия, которые могут потребоваться выполнить в процессе переназначения:
- Добавьте новые теги и задайте значения для них в подписке.
- Добавьте новые назначения ролей, привилегированное управление идентификацией (PIM) назначения ролей на уровне подписки для владельцев. Как правило, эти назначения будут совершаться к группам в Microsoft Entra, вместо отдельных лиц.
- Поместите подписку в нужную группу управления на основе требований к управлению.
- Создайте новые бюджеты Управление затратами Microsoft и настройте оповещения для новых владельцев при достижении пороговых значений.
- Задайте планы Microsoft Defender для облака на нужные уровни подписки. Этот параметр следует применять с помощью Политика Azure после назначения в соответствующую группу управления.
- Настройте пересылку журналов активности подписки (параметров диагностики) в рабочие области Log Analytics, центры событий, аккаунты хранения или другие поддерживаемые назначения. Этот параметр следует применять, используя Политика Azure, после добавления в соответствующую группу управления.
Что такое суверенная целевая зона и как она связана с архитектурой целевой зоны Azure?
Зоны государственного назначения — это компонент Майкрософт Sovereign Cloud, предназначенный для клиентов государственного сектора, которым требуются расширенные средства контроля над суверенитетом. В качестве специализированной версии эталонной архитектуры целевой зоны Azure суверенная целевая зона согласуется с возможностями Azure, такими как размещение служб, управляемые клиентом ключи, Приватный канал Azure и конфиденциальные вычисления. Благодаря этому выравниванию целевая зона создает облачную архитектуру, в которой данные и рабочие нагрузки обеспечивают шифрование и защиту от угроз по умолчанию.
Замечание
Майкрософт Национальное облако ориентировано на организации с потребностями суверенитета. Вы должны тщательно обдумать, нужны ли вам возможности суверенного облака Майкрософт, и только затем рассмотреть возможность внедрения архитектуры суверенной зоны приземления.
Дополнительные сведения о суверенной зоне посадки см. в разделе "Суверенная зона посадки (SLZ)".