Рекомендации по платформе приложений для критически важных рабочих нагрузок в Azure
Azure предоставляет множество вычислительных служб для размещения высокодоступных приложений. Службы отличаются возможностями и сложностью. Рекомендуется выбирать службы на основе:
- Нефункциональный требования к надежности, доступности, производительности и безопасности.
- Факторы принятия решений, такие как масштабируемость, стоимость, операбельность и сложность.
Выбор платформы размещения приложений является критически важным решением, которое влияет на все другие области проектирования. Например, устаревшее или частное программное обеспечение разработки может не выполняться в службах PaaS или контейнерных приложениях. Это ограничение влияет на выбор вычислительной платформы.
Критически важное приложение может использовать несколько вычислительных служб для поддержки нескольких составных рабочих нагрузок и микрослужб, каждый из которых имеет определенные требования.
Эта область проектирования предоставляет рекомендации, связанные с выбором вычислительных ресурсов, проектированием и параметрами конфигурации. Мы также рекомендуем ознакомиться с деревом принятия решений вычислений.
Внимание
Эта статья является частью серии критически важных рабочих нагрузок Azure Well-Architected Framework. Если вы не знакомы с этой серией, рекомендуется начать работу с критически важной рабочей нагрузкой?
Глобальное распределение ресурсов платформы
Типичный шаблон для критически важной рабочей нагрузки включает глобальные ресурсы и региональные ресурсы.
Службы Azure, которые не ограничены определенным регионом Azure, развертываются или настраиваются как глобальные ресурсы. Некоторые варианты использования включают распределение трафика в нескольких регионах, хранение постоянного состояния для всего приложения и кэширование глобальных статических данных. Если необходимо разместить архитектуру единиц масштабирования и глобальное распределение, рассмотрите, как ресурсы оптимально распределяются или реплицируются по регионам Azure.
Другие ресурсы развертываются в регионе. Эти ресурсы, которые развертываются в рамках метки развертывания, обычно соответствуют единице масштабирования. Однако регион может иметь несколько меток, и метка может иметь несколько единиц. Надежность региональных ресурсов имеет решающее значение, так как они отвечают за выполнение основной рабочей нагрузки.
На следующем рисунке показан высокоуровневый дизайн. Пользователь обращается к приложению через центральную глобальную точку входа, которая затем перенаправляет запросы на соответствующую метку регионального развертывания:
Для методологии проектирования, критической для миссии, требуется развертывание в нескольких регионах. Эта модель обеспечивает отказоустойчивость региона, чтобы приложение оставалось доступным даже при переходе всего региона. При разработке приложения с несколькими регионами рассмотрите различные стратегии развертывания, такие как активный и активный и пассивный, а также требования к приложениям, так как для каждого подхода существуют значительные компромиссы. Для критически важных рабочих нагрузок настоятельно рекомендуется использовать активную и активную модель.
Не каждая рабочая нагрузка поддерживает или требует одновременного выполнения нескольких регионов. Чтобы определить оптимальное решение по проектированию, следует взвесить конкретные требования к приложению в отношении компромиссов. Для некоторых сценариев приложений, имеющих более низкие целевые показатели надежности, активные или пассивные или сегментирование могут быть подходящими альтернативами.
Зоны доступности могут предоставлять высокодоступные региональные развертывания в разных центрах обработки данных в пределах региона. Почти все службы Azure доступны в зональной конфигурации, где служба делегируется определенной зоне или конфигурации, избыточной по зонам, где платформа автоматически гарантирует, что служба распространяется по зонам и может выдержать сбой зоны. Эти конфигурации обеспечивают отказоустойчивость до уровня центра обработки данных.
Рекомендации по проектированию
Региональные и зональные возможности. Не все службы и возможности доступны в каждом регионе Azure. Это может повлиять на нужные регионы. Кроме того, зоны доступности недоступны в каждом регионе.
Региональные пары. Регионы Azure группируются в региональные пары , состоящие из двух регионов в одном географическом регионе. Некоторые службы Azure используют парные регионы для обеспечения непрерывности бизнес-процессов и обеспечения уровня защиты от потери данных. Например, геоизбыточное хранилище Azure (GRS) автоматически реплицирует данные в дополнительный парный регион, гарантируя, что данные устойчивы, если основной регион не может восстановиться. Если сбой влияет на несколько регионов Azure, по крайней мере один регион в каждой паре имеет приоритет для восстановления.
Согласованность данных. Для обеспечения согласованности рекомендуется использовать глобально распределенное хранилище данных, метку региональной архитектуры и частично активное или активное развертывание. В частичном развертывании некоторые компоненты активны во всех регионах, а другие находятся централизованно в основном регионе.
Безопасное развертывание. Платформа безопасного развертывания Azure (SDP) гарантирует, что все изменения кода и конфигурации (плановое обслуживание) на платформе Azure проходят поэтапное развертывание. Работоспособность анализируется для снижения состояния во время выпуска. После успешного завершения канарной и пилотной фазы обновления платформы сериализуются между региональными парами, поэтому только один регион в каждой паре обновляется в определенное время.
Емкость платформы. Как и любой поставщик облачных служб, Azure имеет конечные ресурсы. Недоступность может быть результатом ограничений емкости в регионах. При возникновении регионального сбоя наблюдается увеличение спроса на ресурсы, так как рабочая нагрузка пытается восстановиться в парном регионе. Сбой может создать проблему емкости, где предложение временно не соответствует спросу.
Рекомендации по проектированию
Разверните решение по крайней мере в двух регионах Azure, чтобы защититься от региональных сбоев. Разверните его в регионах с возможностями и характеристиками, которыми требуется рабочая нагрузка. Возможности должны соответствовать целевым показателям производительности и доступности при выполнении требований к месту размещения и хранения данных.
Например, некоторые требования к соответствию данным могут ограничивать количество доступных регионов и потенциально принудительно создавать компромиссы. В таких случаях настоятельно рекомендуется добавить дополнительные инвестиции в операционные оболочки для прогнозирования, обнаружения и реагирования на ошибки. Предположим, что вы ограничены географией с двумя регионами, и только один из этих регионов поддерживает зоны доступности (модель центра обработки данных 3 + 1). Создайте шаблон дополнительного развертывания с помощью изоляции домена сбоя, чтобы обе регионы могли быть развернуты в активной конфигурации, и убедитесь, что основной регион содержит несколько меток развертывания.
Если подходящие регионы Azure не предоставляют все необходимые возможности, подготовьтесь к компрометации согласованности региональных меток развертывания для определения приоритетов географического распределения и максимальной надежности. Если подходит только один регион Azure, разверните несколько меток развертывания (региональные единицы масштабирования) в выбранном регионе, чтобы снизить риск, и использовать зоны доступности для обеспечения отказоустойчивости на уровне центра обработки данных. Однако такой значительный компромисс в географическом распределении резко ограничивает достижимую составную SLO и общую надежность.
Внимание
Для сценариев, предназначенных для SLO, превышающего или равный 99,99%, рекомендуется как минимум три региона развертывания. Вычислите составной SLO для всех потоков пользователей. Убедитесь, что эти целевые объекты соответствуют целевым объектам бизнеса.
В сценариях с высокомасштабируемыми приложениями, имеющими значительные объемы трафика, можно разработать решение для масштабирования в нескольких регионах, чтобы перейти к потенциальным ограничениям емкости в одном регионе. Дополнительные метки регионального развертывания могут достичь более высокого составного SLO. Дополнительные сведения см. в статье о реализации целевых объектов с несколькими агрегатами.
Определите и проверьте цели точки восстановления (RPO) и цели времени восстановления (RTO).
В пределах одного географического региона приоритеты используют региональные пары, чтобы воспользоваться сериализованными развертываниями SDP для планового обслуживания и региональной приоритетности для незапланированного обслуживания.
Географически колоируйте ресурсы Azure с пользователями, чтобы свести к минимуму задержку сети и максимально повысить производительность.
- Вы также можете использовать такие решения, как сеть доставки содержимого (CDN) или пограничный кэширование, чтобы обеспечить оптимальную задержку сети для распределенных баз пользователей. Дополнительные сведения см. в статье "Глобальная маршрутизация трафика", службы доставки приложений и кэширование и доставка статического содержимого.
При выборе регионов развертывания выравнивайте текущую доступность служб с помощью стратегий разработки продуктов. Некоторые службы могут быть не сразу доступны в каждом регионе.
Контейнеризация
Контейнер включает код приложения и связанные файлы конфигурации, библиотеки и зависимости, необходимые приложению. Контейнеризация предоставляет уровень абстракции для кода приложения и его зависимостей и создает разделение от базовой платформы размещения. Один пакет программного обеспечения очень переносим и может работать согласованно на различных платформах инфраструктуры и поставщиках облачных служб. Разработчикам не нужно перезаписывать код и развертывать приложения быстрее и надежнее.
Внимание
Рекомендуется использовать контейнеры для критически важных пакетов приложений. Они улучшают использование инфраструктуры, так как можно разместить несколько контейнеров в одной виртуализированной инфраструктуре. Кроме того, так как все программное обеспечение входит в контейнер, вы можете перемещать приложение по различным операционным системам независимо от версий среды выполнения или библиотеки. Управление также проще с контейнерами, чем с традиционным виртуализированным размещением.
Критически важные приложения должны быстро масштабироваться, чтобы избежать узких мест производительности. Так как образы контейнеров предварительно созданы, можно ограничить запуск только во время загрузки приложения, что обеспечивает быструю масштабируемость.
Рекомендации по проектированию
Мониторинг. Службам мониторинга может быть трудно получить доступ к приложениям, которые находятся в контейнерах. Обычно требуется стороннее программное обеспечение для сбора и хранения индикаторов состояния контейнера, таких как использование ЦП или ОЗУ.
Безопасность. Ядро ОС платформы размещения используется для нескольких контейнеров, создавая одну точку атаки. Однако риск доступа к виртуальной машине ограничен, так как контейнеры изолированы от базовой операционной системы.
Состояние. Хотя данные можно хранить в файловой системе запущенного контейнера, данные не будут сохраняться при повторном создании контейнера. Вместо этого сохраняйте данные путем подключения внешнего хранилища или использования внешней базы данных.
Рекомендации по проектированию
Контейнеризируйте все компоненты приложения. Используйте образы контейнеров в качестве основной модели для пакетов развертывания приложений.
По возможности определите приоритет среды выполнения контейнеров на основе Linux. Образы являются более легкими, и новые функции для узлов и контейнеров Linux часто выпускаются.
Сделайте контейнеры неизменяемыми и заменяемыми с короткими жизненными циклами.
Не забудьте собрать все соответствующие журналы и метрики из контейнера, узла контейнера и базового кластера. Отправьте собранные журналы и метрики в единый приемник данных для дальнейшей обработки и анализа.
Храните образы контейнеров в Реестр контейнеров Azure. Используйте георепликацию для репликации образов контейнеров во всех регионах. Включите Microsoft Defender для реестров контейнеров, чтобы обеспечить сканирование уязвимостей для образов контейнеров. Убедитесь, что доступ к реестру управляется идентификатором Microsoft Entra.
Размещение контейнеров и оркестрация
Несколько платформ приложений Azure могут эффективно размещать контейнеры. Существуют преимущества и недостатки, связанные с каждой из этих платформ. Сравните параметры в контексте бизнес-требований. Однако всегда оптимизируйте надежность, масштабируемость и производительность. Дополнительные сведения см. в следующих статьях:
Внимание
Служба Azure Kubernetes (AKS) и приложения контейнеров Azure должны быть одними из первых вариантов управления контейнерами в зависимости от ваших требований. Хотя служба приложение Azure не является оркестратором, так как платформа контейнеров с низким уровнем трения, она по-прежнему является возможной альтернативой AKS.
Рекомендации и рекомендации по проектированию Служба Azure Kubernetes
AKS, управляемая служба Kubernetes, позволяет быстро подготовить кластер, не требуя сложных действий администрирования кластера и предлагает набор функций, включающий расширенные возможности сети и удостоверений. Полный набор рекомендаций см. в обзоре Azure Well-Architected Framework — AKS.
Внимание
Существует несколько базовых решений конфигурации, которые нельзя изменить без повторного развертывания кластера AKS. Примеры включают выбор между общедоступными и частными кластерами AKS, включением политики сети Azure, интеграцией Microsoft Entra и использованием управляемых удостоверений для AKS вместо субъектов-служб.
Надежность
AKS управляет собственным уровнем управления Kubernetes. Если уровень управления недоступен, рабочая нагрузка испытывает простой. Воспользуйтесь преимуществами функций надежности, предлагаемых AKS:
Развертывание кластеров AKS в разных регионах Azure в виде единицы масштабирования для повышения надежности и доступности. Используйте зоны доступности для максимальной устойчивости в регионе Azure путем распространения плоскости управления AKS и узлов агента в физически отдельных центрах обработки данных. Однако если задержка совместного размещения является проблемой, вы можете выполнить развертывание AKS в пределах одной зоны или использовать группы размещения близкого взаимодействия, чтобы свести к минимуму задержку интернода.
Используйте соглашение об уровне обслуживания akS для рабочих кластеров, чтобы максимально повысить доступность конечных точек API Kubernetes.
Масштабируемость
Учитывайте ограничения масштабирования AKS, такие как количество узлов, пулов узлов на кластер и кластеры на подписку.
Если ограничения масштабирования являются ограничением, воспользуйтесь стратегией единиц масштабирования и разверните больше единиц с кластерами.
Включите автомасштабирование кластера, чтобы автоматически настроить число узлов агента в соответствии с ограничениями ресурсов.
Используйте средство автомасштабирования горизонтального модуля pod для настройки количества модулей pod в развертывании на основе использования ЦП или других метрик.
Для сценариев с высоким масштабом и ускорением рекомендуется использовать виртуальные узлы для расширенного и быстрого масштабирования.
Определите запросы и ограничения ресурсов pod в манифестах развертывания приложений. Если вы этого не сделали, могут возникнуть проблемы с производительностью.
Изоляция
Поддерживайте границы между инфраструктурой, используемой рабочей нагрузкой и системными средствами. Общий доступ к инфраструктуре может привести к высокой загрузке ресурсов и шумным сценариям соседей.
Используйте отдельные пулы узлов для служб системной и рабочей нагрузки. Пулы выделенных узлов для компонентов рабочей нагрузки должны основываться на требованиях к специализированным ресурсам инфраструктуры, таким как виртуальные машины GPU с высокой памятью. Как правило, чтобы сократить ненужные затраты на управление, избежать развертывания большого количества пулов узлов.
Используйте ограничения и терпимые методы для предоставления выделенных узлов и ограничения ресурсоемких приложений.
Оцените соответствие приложений и требования к борьбе с сходством и настройте соответствующее совместное размещение контейнеров на узлах.
Безопасность
По умолчанию vanilla Kubernetes требует значительной конфигурации, чтобы обеспечить подходящий уровень безопасности для критически важных сценариев. AKS решает различные риски безопасности вне поля. Функции включают частные кластеры, аудит и вход в Log Analytics, защищенные образы узлов и управляемые удостоверения.
Примените руководство по настройке, предоставленное в базовой конфигурации AKS.
Используйте функции AKS для обработки удостоверений кластера и управления доступом, чтобы сократить операционные издержки и применить согласованное управление доступом.
Используйте управляемые удостоверения вместо субъектов-служб, чтобы избежать управления и смены учетных данных. Управляемые удостоверения можно добавить на уровне кластера. На уровне pod можно использовать управляемые удостоверения с помощью Идентификация рабочей нагрузки Microsoft Entra.
Используйте интеграцию Microsoft Entra для централизованного управления учетными записями и паролей, управления доступом к приложениям и расширенной защиты идентификации. Используйте RBAC Kubernetes с идентификатором Microsoft Entra id для наименьших привилегий и свести к минимуму предоставление прав администратора для защиты доступа к конфигурации и секретам. Кроме того, ограничьте доступ к файлу конфигурации кластера Kubernetes с помощью управления доступом на основе ролей Azure. Ограничить доступ к действиям, которые могут выполнять контейнеры, предоставить наименьшее количество разрешений и избежать эскалации корневых привилегий.
Обновления
Кластеры и узлы должны регулярно обновляться. AKS поддерживает версии Kubernetes в соответствии с циклом выпуска собственных Kubernetes.
Подпишитесь на общедоступные заметки о стратегии и выпуске AKS на GitHub, чтобы оставаться в курсе предстоящих изменений, улучшений и, что самое главное, выпуски и отмены версий Kubernetes.
Примените рекомендации, приведенные в контрольном списке AKS, чтобы обеспечить соответствие рекомендациям.
Помните о различных методах, поддерживаемых AKS для обновления узлов и (или) кластеров. Эти методы могут быть вручную или автоматизированы. Вы можете использовать плановое обслуживание для определения периодов обслуживания для этих операций. Новые образы выпускаются еженедельно. AKS также поддерживает каналы автоматического обновления для автоматического обновления кластеров AKS до более новых версий Kubernetes и (или) более новых образов узлов при их доступности.
Сеть
Оцените сетевые подключаемые модули, которые лучше всего соответствуют вашему варианту использования. Определите, требуется ли детализированное управление трафиком между модулями pod. поддержка Azure s kubenet, Azure CNI и принести собственный CNI для конкретных вариантов использования.
Определите приоритет использования Azure CNI после оценки требований к сети и размера кластера. Azure CNI позволяет использовать политики сети Azure или Calico для управления трафиком в кластере.
Наблюдение
Средства мониторинга должны иметь возможность записывать журналы и метрики из запущенных модулей pod. Вы также должны собирать сведения из API метрик Kubernetes, чтобы отслеживать работоспособность выполняемых ресурсов и рабочих нагрузок.
Используйте Azure Monitor и Application Insights для сбора метрик, журналов и диагностика из ресурсов AKS для устранения неполадок.
Включите и просмотрите журналы ресурсов Kubernetes.
Настройте метрики Prometheus в Azure Monitor. Аналитика контейнеров в Мониторе обеспечивает подключение, обеспечивает возможности мониторинга вне поля и обеспечивает более расширенные возможности с помощью встроенной поддержки Prometheus.
Система управления
Используйте политики для согласованного применения централизованных гарантий к кластерам AKS. Применение назначений политик в области подписки или более поздней версии для обеспечения согласованности между командами разработчиков.
Управление функциями, которыми предоставляются модули pod, и выполнение которой противоречит политике, с помощью Политика Azure. Этот доступ определяется с помощью встроенных политик, предоставляемых надстройкой Политика Azure для AKS.
Создайте согласованные базовые показатели надежности и безопасности для конфигураций кластера AKS и pod с помощью Политика Azure.
Используйте надстройку Политика Azure для AKS для управления функциями pod, такими как привилегии корня, и запретить модули pod, которые не соответствуют политике.
Примечание.
При развертывании в целевой зоне Azure политики Azure помогают обеспечить согласованность надежности и безопасности в рамках реализации целевой зоны.
Критически важные эталонные реализации предоставляют набор базовых политик для обеспечения рекомендуемой надежности и конфигураций безопасности.
Рекомендации и рекомендации для службы приложение Azure
Для сценариев рабочих нагрузок на основе веб-сайтов и API Служба приложений может быть возможной альтернативой AKS. Она предоставляет платформу контейнеров с низким уровнем трения без сложности Kubernetes. Полный набор рекомендаций см. в статье "Рекомендации по надежности" для Служба приложений и эффективности работы для Служба приложений.
Надежность
Оцените использование портов TCP и SNAT. TCP-подключения используются для всех исходящих подключений. Порты SNAT используются для исходящих подключений к общедоступным IP-адресам. Исчерпание портов SNAT — это распространенный сценарий сбоя. Эту проблему следует прогнозировать путем нагрузочного тестирования при использовании Диагностика Azure для мониторинга портов. Если возникают ошибки SNAT, необходимо выполнить масштабирование между несколькими или большими рабочими ролей или реализовать методики написания кода для сохранения и повторного использования портов SNAT. Примеры методов написания кода, которые можно использовать, включают пул подключений и отложенную загрузку ресурсов.
Исчерпание TCP-порта — это еще один сценарий сбоя. Происходит, когда сумма исходящих подключений из заданной рабочей роли превышает емкость. Количество доступных TCP-портов зависит от размера рабочей роли. Рекомендации см. в разделе "Порты TCP и SNAT".
Масштабируемость
Планируйте будущие требования к масштабируемости и рост приложений, чтобы можно было применить соответствующие рекомендации с самого начала. Таким образом, вы можете избежать технической задолженности по мере роста решения.
Включите автомасштабирование, чтобы обеспечить доступность достаточных ресурсов для запросов на обслуживание. Оцените масштабирование на приложение для размещения с высокой плотностью на Служба приложений.
Помните, что Служба приложений имеет по умолчанию обратимое ограничение экземпляров на план Служба приложений.
Применение правил автомасштабирования. План Служба приложений масштабируется, если выполняется любое правило в профиле, но только масштабируется, если выполняются все правила в профиле. Используйте сочетание правил горизонтального масштабирования и масштабирования, чтобы обеспечить автоматическое масштабирование как для горизонтального масштабирования, так и для масштабирования. Изучите поведение нескольких правил масштабирования в одном профиле.
Помните, что вы можете включить масштабирование для каждого приложения на уровне плана Служба приложений, чтобы позволить приложению масштабироваться независимо от плана Служба приложений, на котором он размещен. Приложения выделяются для доступных узлов с помощью оптимального подхода к равномерному распределению. Хотя даже распределение не гарантируется, платформа гарантирует, что два экземпляра одного приложения не размещаются в одном экземпляре.
Наблюдение
Отслеживайте поведение приложения и получайте доступ к соответствующим журналам и метрикам, чтобы убедиться, что приложение работает должным образом.
Журнал диагностики можно использовать для приема журналов уровня приложения и платформы в Log Analytics, служба хранилища Azure или стороннего средства с помощью Центры событий Azure.
Мониторинг производительности приложений с помощью Application Insights предоставляет подробные сведения о производительности приложений.
Критически важные приложения должны иметь возможность самовосстановляться, если возникают сбои. Включение автоматического лечения для автоматического перезапуска неработоспособных рабочих ролей.
Необходимо использовать соответствующие проверки работоспособности для оценки всех критически важных подчиненных зависимостей, что помогает обеспечить общую работоспособность. Настоятельно рекомендуется включить проверку работоспособности для выявления неинтервных работников.
Развертывание
Чтобы обойти ограничение по умолчанию экземпляров на план Служба приложений, разверните Служба приложений планы в нескольких единицах масштабирования в одном регионе. Разверните планы Служба приложений в конфигурации зоны доступности, чтобы обеспечить распределение рабочих узлов между зонами в пределах региона. Рассмотрите возможность открытия запроса в службу поддержки, чтобы увеличить максимальное число рабочих ролей, чтобы увеличить число экземпляров, необходимое для обслуживания нормальной пиковой нагрузки.
Реестр контейнеров
Реестры контейнеров размещают образы, развернутые в средах выполнения контейнеров, таких как AKS. Необходимо тщательно настроить реестры контейнеров для критически важных рабочих нагрузок. Сбой не должен вызывать задержки при извлечении изображений, особенно во время операций масштабирования. Следующие рекомендации и рекомендации сосредоточены на Реестр контейнеров Azure и рассматривают компромиссы, связанные с централизованными и федеративными моделями развертывания.
Рекомендации по проектированию
Формат: Рассмотрите возможность использования реестра контейнеров, который использует предоставленный Docker формат и стандарты для операций отправки и извлечения. Эти решения совместимы и в основном взаимозаменяемы.
Модель развертывания. Реестр контейнеров можно развернуть как централизованную службу, которая используется несколькими приложениями в организации. Кроме того, его можно развернуть как выделенный компонент для конкретной рабочей нагрузки приложения.
Общедоступные реестры. Образы контейнеров хранятся в Docker Hub или других общедоступных реестрах, которые существуют за пределами Azure и определенной виртуальной сети. Это не обязательно проблема, но это может привести к различным проблемам, связанным с доступностью службы, регулированием и кражей данных. Для некоторых сценариев приложений необходимо реплицировать общедоступные образы контейнеров в частном реестре контейнеров, чтобы ограничить исходящий трафик, повысить доступность или избежать потенциального регулирования.
Рекомендации по проектированию
Используйте экземпляры реестра контейнеров, предназначенные для рабочей нагрузки приложения. Избегайте создания зависимости от централизованной службы, если требования к доступности и надежности организации полностью не соответствуют приложению.
В рекомендуемом шаблоне основной архитектуры реестры контейнеров — это глобальные ресурсы, которые являются длительными. Рекомендуется использовать один глобальный реестр контейнеров для каждой среды. Например, используйте глобальный рабочий реестр.
Убедитесь, что соглашение об уровне обслуживания для общедоступного реестра соответствует вашим целям надежности и безопасности. Обратите особое внимание на ограничения регулирования для вариантов использования, зависящих от Docker Hub.
Приоритет Реестр контейнеров Azure размещения образов контейнеров.
Рекомендации и рекомендации по проектированию Реестр контейнеров Azure
Эта собственная служба предоставляет ряд функций, включая георепликацию, проверку подлинности Microsoft Entra, автоматическое создание контейнеров и исправление с помощью задач реестра контейнеров.
Надежность
Настройте георепликацию для всех регионов развертывания, чтобы удалить региональные зависимости и оптимизировать задержку. Реестр контейнеров поддерживает высокий уровень доступности с помощью георепликации в нескольких настроенных регионах, обеспечивая устойчивость к региональным сбоям. Если регион становится недоступным, другие регионы продолжают обслуживать запросы изображений. Когда регион вернулся в сеть, реестр контейнеров восстанавливает и реплицирует изменения в него. Эта возможность также обеспечивает совместное размещение реестра в каждом настроенном регионе, уменьшая задержку сети и затраты на передачу данных между регионами.
В регионах Azure, которые обеспечивают поддержку зоны доступности, уровень реестра контейнеров класса Premium поддерживает избыточность зон, чтобы обеспечить защиту от зонального сбоя. Уровень "Премиум" также поддерживает частные конечные точки , чтобы предотвратить несанкционированный доступ к реестру, что может привести к проблемам надежности.
Образы узлов, близкие к потребляющим вычислительным ресурсам, в одном регионе Azure.
Блокировка изображений
Изображения могут быть удалены в результате, например, ошибки вручную. Реестр контейнеров поддерживает блокировку версии образа или репозитория для предотвращения изменений или удаления. При изменении версии образа, развернутой ранее, развертывания с одинаковыми версиями могут предоставлять различные результаты до и после изменения.
Если вы хотите защитить экземпляр реестра контейнеров от удаления, используйте блокировки ресурсов.
Помеченные изображения
Образы реестра контейнеров, помеченные по умолчанию, изменяются, что означает, что один и тот же тег можно использовать для нескольких образов, отправленных в реестр. В рабочих сценариях это может привести к непредсказуемому поведению, которое может повлиять на время простоя приложения.
Управление удостоверениями и доступом
Используйте встроенную проверку подлинности Microsoft Entra для отправки и извлечения изображений вместо использования ключей доступа. Для повышения безопасности полностью отключите использование ключа доступа администратора.
Бессерверные вычисления
Бессерверные вычисления предоставляют ресурсы по запросу и устраняют необходимость управления инфраструктурой. Поставщик облачных служб автоматически подготавливает, масштабирует и управляет ресурсами, необходимыми для запуска развернутого кода приложения. Azure предоставляет несколько бессерверных вычислительных платформ:
Функции Azure. При использовании Функции Azure логика приложения реализуется в виде отдельных блоков кода или функций, которые выполняются в ответ на события, такие как HTTP-запрос или сообщение очереди. Каждая функция масштабируется по мере необходимости для удовлетворения спроса.
Azure Logic Apps. Logic Apps лучше всего подходит для создания и запуска автоматизированных рабочих процессов, которые интегрируют различные приложения, источники данных, службы и системы. Как и Функции Azure, Logic Apps использует встроенные триггеры для обработки на основе событий. Однако вместо развертывания кода приложения можно создавать приложения логики с помощью графического пользовательского интерфейса, поддерживающего блоки кода, такие как условные и циклы.
Служба управления Azure API. Вы можете использовать Управление API для публикации, преобразования, обслуживания и мониторинга API расширенной безопасности с помощью уровня потребления.
Power Apps и Power Automate. Эти средства предоставляют возможности разработки с низким кодом или без кода с простой логикой рабочего процесса и интеграцией, которые можно настроить с помощью подключений в пользовательском интерфейсе.
Для критически важных приложений бессерверные технологии обеспечивают упрощенную разработку и операции, которые могут быть ценными для простых бизнес-вариантов использования. Однако эта простота обеспечивает гибкость с точки зрения масштабируемости, надежности и производительности, и это недоступно для большинства критически важных сценариев приложений.
В следующих разделах приведены рекомендации по проектированию и рекомендации по использованию Функции Azure и Logic Apps в качестве альтернативных платформ для некритических сценариев рабочих процессов.
Рекомендации и рекомендации по проектированию Функции Azure
Критически важные рабочие нагрузки имеют критически важные и некритичные системные потоки. Функции Azure — это жизнеспособный выбор потоков, которые не имеют одинаковых жестких бизнес-требований, что и критически важные системные потоки. Он хорошо подходит для потоков, управляемых событиями, которые имеют короткие процессы, так как функции выполняют различные операции, которые выполняются как можно быстрее.
Выберите вариант размещения Функции Azure, соответствующий уровню надежности приложения. Рекомендуется использовать план Premium, так как он позволяет настроить размер вычислительного экземпляра. Выделенный план является наименее бессерверным вариантом. Он обеспечивает автомасштабирование, но эти операции масштабирования медленнее, чем другие планы. Рекомендуется использовать план Premium для повышения надежности и производительности.
Существуют некоторые аспекты безопасности. При использовании триггера HTTP для предоставления внешней конечной точки используйте брандмауэр веб-приложения (WAF), чтобы обеспечить уровень защиты конечной точки HTTP от распространенных внешних векторов атак.
Мы рекомендуем использовать частные конечные точки для ограничения доступа к частным виртуальным сетям. Они также могут снизить риски кражи данных, такие как сценарии вредоносных администраторов.
Необходимо использовать средства сканирования кода в Функции Azure коде и интегрировать эти средства с конвейерами CI/CD.
Рекомендации и рекомендации по проектированию для Azure Logic Apps
Как и Функции Azure, Logic Apps использует встроенные триггеры для обработки на основе событий. Однако вместо развертывания кода приложения можно создавать приложения логики с помощью графического пользовательского интерфейса, который поддерживает такие блоки, как условные, циклы и другие конструкции.
Доступны несколько режимов развертывания. Мы рекомендуем стандартный режим, чтобы обеспечить развертывание с одним клиентом и устранить шумные сценарии соседей. В этом режиме используется контейнерная среда выполнения Logic Apps с одним клиентом, основанная на Функции Azure. В этом режиме приложение логики может иметь несколько рабочих процессов с отслеживанием состояния и без отслеживания состояния. Следует учитывать ограничения конфигурации.
Ограниченные миграции через IaaS
Многие приложения, имеющие локальные развертывания, используют технологии виртуализации и избыточное оборудование для обеспечения критически важных уровней надежности. Модернизация часто препятствует ограничениям бизнеса, которые препятствуют полному выравниванию с шаблоном архитектуры на основе облака (North Star), который рекомендуется для критически важных рабочих нагрузок. Поэтому многие приложения используют поэтапный подход с первоначальными облачными развертываниями с помощью виртуализации и Azure Виртуальные машины в качестве основной модели размещения приложений. Использование инфраструктуры как службы (IaaS) может потребоваться в определенных сценариях:
- Доступные службы PaaS не обеспечивают необходимую производительность или уровень управления.
- Для рабочей нагрузки требуется доступ к операционной системе, определенные драйверы или конфигурации сети и системы.
- Рабочая нагрузка не поддерживает выполнение в контейнерах.
- Поддержка сторонних рабочих нагрузок отсутствует.
В этом разделе рассматриваются лучшие способы использования Виртуальные машины и связанных служб для повышения надежности платформы приложений. В ней рассматриваются ключевые аспекты методологии проектирования, которая преобразует сценарии миграции на основе облака и IaaS.
Рекомендации по проектированию
Операционные затраты на использование виртуальных машин IaaS значительно выше, чем затраты на использование служб PaaS из-за требований к управлению виртуальными машинами и операционными системами. Управление виртуальными машинами требует частого развертывания пакетов программного обеспечения и обновлений.
Azure предоставляет возможности для повышения доступности виртуальных машин:
- Зоны доступности помогают достичь еще более высокого уровня надежности, распределяя виртуальные машины в физически разделенных центрах обработки данных в пределах региона.
- Масштабируемые наборы виртуальных машин Azure предоставляют функции автоматического масштабирования числа виртуальных машин в группе. Они также предоставляют возможности для мониторинга работоспособности экземпляров и автоматического восстановления неработоспособных экземпляров.
- Масштабируемые наборы с гибкой оркестрацией могут помочь защититься от сбоев сети, диска и питания, автоматически распределяя виртуальные машины между доменами сбоя.
Рекомендации по проектированию
Внимание
Используйте службы и контейнеры PaaS, если это возможно, чтобы снизить операционную сложность и затраты. Используйте виртуальные машины IaaS только при необходимости.
Размер SKU виртуальной машины правильного размера , чтобы обеспечить эффективное использование ресурсов.
Разверните три или более виртуальных машин в зонах доступности для обеспечения отказоустойчивости на уровне центра обработки данных.
- Если вы развертываете коммерческое программное обеспечение вне полки, обратитесь к поставщику программного обеспечения и проверьте его достаточно, прежде чем развертывать программное обеспечение в рабочей среде.
Для рабочих нагрузок, которые нельзя развернуть в зонах доступности, используйте гибкие масштабируемые наборы виртуальных машин, содержащие три или более виртуальных машин. Дополнительные сведения о настройке правильного количества доменов сбоя см. в разделе "Управление доменами сбоя" в масштабируемых наборах.
Приоритет использования Масштабируемые наборы виртуальных машин для избыточности и избыточности зон. Эта точка особенно важна для рабочих нагрузок с различными нагрузками. Например, если число активных пользователей или запросов в секунду является различной нагрузкой.
Не обращаться к отдельным виртуальным машинам напрямую. Используйте подсистемы балансировки нагрузки перед ними, когда это возможно.
Чтобы защититься от региональных сбоев, разверните виртуальные машины приложений в нескольких регионах Azure.
- Сведения о том, как оптимально направлять трафик между активными регионами развертывания, см. в области проектирования сети и подключения.
Для рабочих нагрузок, которые не поддерживают многорегионные и активные развертывания, рассмотрите возможность реализации активных и пассивных развертываний с помощью виртуальных машин с горячим или теплым резервным режимом для региональной отработки отказа.
Используйте стандартные образы из Azure Marketplace, а не пользовательские образы, которые необходимо сохранить.
Реализуйте автоматизированные процессы для развертывания и развертывания изменений на виртуальных машинах, избегая вмешательства вручную. Дополнительные сведения см. в рекомендациях по работе с IaaS в области проектирования операционных процедур.
Реализуйте эксперименты хаоса, чтобы внедрить ошибки приложений в компоненты виртуальных машин и наблюдать за устранением ошибок. Дополнительные сведения см. в разделе "Непрерывная проверка и тестирование".
Мониторинг виртуальных машин и обеспечение приема журналов диагностики и метрик в единый приемник данных.
Реализуйте методики безопасности для сценариев критически важных приложений, если это применимо, и рекомендации по безопасности для рабочих нагрузок IaaS в Azure.
Следующий шаг
Ознакомьтесь с рекомендациями по платформе данных.