Руководство по базовым показателям операций для Azure Red Hat OpenShift

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

Рекомендации по проектированию

Примите во внимание следующие факторы.

• Ознакомьтесь с матрицей ответственности Azure Red Hat OpenShift , чтобы понять, как обязанности по кластерам распределяются между корпорацией Майкрософт, Red Hat и клиентами.
• Помните об ограничениях виртуальных машин Azure и поддерживаемых регионах. Убедитесь, что имеется емкость для развертывания ресурсов.
• Помните о возможностях логически изолировать рабочие нагрузки в кластере и физически в отдельных кластерах.
• Помните о возможностях передавать Kubernetes данные о работоспособности рабочих нагрузок.
• Помните о различных размерах виртуальных машин и о последствиях использования одной из них.
• Помните о способах мониторинга и ведения журнала Azure Red Hat OpenShift, чтобы получить представление о работоспособности ресурсов и предвидеть потенциальные проблемы. Как кластер, так и приложения, работающие на вершине, могут создавать множество событий. Используйте оповещения, чтобы различать записи журнала для исторических целей и записи, требующие немедленного действия.
• Помните о важных обновлениях и обновлениях системы. Критические обновления исправлений автоматически применяются к кластерам инженерами по обеспечению надежности сайта (SRE) Azure Red Hat OpenShift. Клиенты, которые хотят установить обновления исправлений заранее, могут это сделать.
• Учитывайте ограничения ресурсов кластера и отдельных рабочих нагрузок.
• Помните о различиях между горизонтальным автомасштабированием pod и автомасштабированием кластера.
• Просмотрите жизненный цикл поддержки и изучите политику поддержки версий. Azure Red Hat OpenShift поддерживает только текущие и предыдущие общедоступные дополнительные выпуски платформы контейнеров Red Hat OpenShift. Запросы на поддержку требуют, чтобы кластер был в поддерживаемой версии.
• Ознакомьтесь с требованиями к конфигурации кластера для поддержки кластера.
• Просмотрите сетевые подключения между пространствами имен для защиты трафика в кластере с помощью политики сети.

Рекомендации по проектированию

• Azure Red Hat OpenShift обладает богатой экосистемой операторов и должна использоваться для эффективного и точного выполнения и автоматизации операционных действий.
• Добавьте пробы работоспособности в модули pod для мониторинга работоспособности приложений. Убедитесь, что модули pod содержат livenessProbe и readinessProbe. Используйте пробы запуска, чтобы определить точку запуска приложения.
• Используйте размеры виртуальных машин, достаточно большие, чтобы содержать несколько экземпляров контейнеров, чтобы получить преимущества повышенной плотности, но не настолько большой, чтобы кластер не смог справиться с рабочей нагрузкой неработоспособных узлов.
• Регулировать функции кластера с помощью подключаемых модулей допуска, которые обычно используются для применения политики безопасности, ограничений ресурсов или требований к конфигурации.
• Используйте запросы и ограничения pod для управления вычислительными ресурсами в кластере. Запросы и ограничения pod информируют планировщик Kubernetes, который назначает вычислительные ресурсы модулем pod. Ограничение потребления ресурсов в проекте с помощью диапазонов ограничений.
• Оптимизируйте значения запросов ЦП и памяти, а также увеличьте эффективность ресурсов кластера с помощью средства вертикального автомасштабирования pod.
• Веб-консоль OpenShift содержит все метрики на уровне узла. Создайте процесс мониторинга с помощью встроенной интеграции Prometheus или Container Insights.
  • Prometheus предварительно установлен и настроен для работы с кластерами Azure Red Hat OpenShift 4.x.
  • Аналитику контейнеров можно включить, подключив кластер к Kubernetes с поддержкой Azure Arc.
  • При ведении журнала OpenShift развертываются агрегаторы журналов, компоненты хранения и визуализации.
• Автоматизируйте процесс доставки приложений с помощью методик DevOps и решений CI/CD, таких как Pipelines/GitOps, предоставляемых платформой контейнеров OpenShift.
• Определите ClusterAutoScaler и MachineAutoScaler для масштабирования компьютеров, когда в кластере заканчивается количество ресурсов для поддержки дополнительных развертываний.
• Развертывание проверок работоспособности компьютера для автоматического восстановления поврежденных компьютеров в пуле компьютеров.
• Масштабируйте модули pod в соответствии с потребностями с помощью средства горизонтального автомасштабирования pod.
• Используйте систему оповещений для предоставления уведомлений, когда требуются прямые действия: оповещения метрик Аналитики контейнеров или встроенный пользовательский интерфейс оповещений.

Непрерывность бизнес-процессов и аварийное восстановление (BCDR)

Вашей организации необходимо разработать подходящие возможности azure Red Hat OpenShift на уровне платформы в соответствии с конкретными требованиями. Эти службы приложений имеют требования, связанные с целевым временем восстановления (RTO) и целевой точкой восстановления (RPO). Существует несколько рекомендаций, которые следует учитывать при аварийном восстановлении. Первым шагом является определение соглашения об уровне обслуживания (SLA) для вашей инфраструктуры и вашего приложения. Сведения об уровне обслуживания для Azure Red Hat OpenShift. Информацию о вычислении времени работы за месяц см. в разделе Сведения о соглашении об уровне обслуживания.

Рекомендации по проектированию для BCDR

Примите во внимание следующие факторы.

• Кластер Azure Red Hat OpenShift должен использовать несколько наборов компьютеров, чтобы обеспечить минимальный уровень доступности приложения.
• Задайте ограничения и запросы объектов pod. Установка этих ограничений позволяет Kubernetes:
  • Эффективно назначьте ресурсы ЦП и памяти модулям pod.
  • добиться повышенной плотности контейнеров на узле.
  • Повышение надежности за счет снижения затрат благодаря более эффективному использованию оборудования.
• Распределите узлы по всем доступным зонам для повышения доступности.
  • Выберите регион с поддержкой зон доступности.
  • Чтобы максимально полно использовать преимущество зон, их также должны поддерживать зависимости служб. Если зависимая служба не поддерживает зоны, сбой зоны может привести к сбою этой службы. Просмотрите типы дисков, используемые при распространении рабочей нагрузки между зонами.
  • Для повышения доступности, превышающей Зоны доступности, запустите несколько кластеров в разных парных регионах. Если ресурс Azure поддерживает геоизбыточность, укажите расположение, где будет находится дополнительный регион избыточной службы.
• Обеспечьте согласованное создание резервных копий для приложений и данных.
  • Службу без отслеживания состояния можно эффективно реплицировать.
  • Если необходимо сохранить состояние в кластере, регулярно создавайте резервные копии данных в парном регионе.
• Обновление и обслуживание кластеров.
  • Всегда поддерживайте кластер в актуальном состоянии. Проверьте наличие обновлений кластера.
  • Не забывайте о процессе выпуска и устаревания.
  • Управление обновлениями с помощью расписаний.
  • Ознакомьтесь с необходимостью в обновлении возможного развертывания для критически важных рабочих нагрузок.
• Для сетевого подключения в случае отработки отказа:
  • Если вам нужно распределить трафик между регионами, рекомендуется использовать Azure Front Door.
• Для плановой и незапланированной отработки отказа:
  • При настройке каждой службы Azure выберите компоненты, поддерживающие аварийное восстановление. Например, если выбран Реестр контейнеров Azure, включите его для георепликации. Если регион отключается, вы по-прежнему можете получить образы из реплицированного региона.
• Поддерживайте возможности разработки DevOps для достижения целей уровня обслуживания.

Рекомендации по проектированию для BCDR

Ниже приведены рекомендации по проектированию:

• Кластеры Azure Red Hat OpenShift подготавливаются с тремя узлами уровня управления и тремя или более рабочими узлами. Убедитесь, что кластер создан в регионе, поддерживающем Зоны доступности, чтобы узлы были распределены по зонам.
• Для обеспечения высокого уровня доступности разверните эти узлы в разных Зоны доступности. Так как для каждой зоны доступности требуются разные наборы компьютеров, создайте по крайней мере три набора компьютеров.
• Не выполняйте дополнительные рабочие нагрузки на узлах уровня управления. Хотя их можно запланировать на узлах уровня управления, это приведет к дополнительным проблемам использования ресурсов и стабильности, которые могут повлиять на весь кластер.
• Создание наборов компьютеров инфраструктуры для хранения компонентов инфраструктуры. Примените определенные метки Kubernetes к этим компьютерам, а затем обновите компоненты инфраструктуры, чтобы они выполнялись только на этих компьютерах.
• По возможности удалите состояние службы из контейнеров. Вместо этого используйте платформу как услугу (PaaS) Azure, которая поддерживает репликацию в нескольких регионах.
• В развертываниях должны указываться требования к ресурсам pod. Тогда планировщик может надлежащим образом запланировать объект pod. Если планирование объектов pod не выполняется, надежность значительно снижается.
• Настройте несколько реплик в развертывании, чтобы обрабатывать перебои в работе, например сбои оборудования. Для запланированных мероприятий, таких как обновление и модернизация, бюджет неработоспособности может обеспечить необходимое количество реплик pod для обработки ожидаемой нагрузки приложения.
• Используйте ограничения топологии pod для автоматического планирования модулей pod на узлах кластера.
• Приложения могут использовать хранилище для своих данных и при необходимости должны обеспечить доступность в разных регионах:
  • Использование хранилища RWX со встроенным классом хранения Файлы Azure.
  • Использование драйверов CSI для подготовки хранилища.
• Создайте резервную копию приложения и запланируйте восстановление:
  • Включите постоянные тома в резервную копию.
• Оценка ограничений ресурсов pod. Выполните тестирование и определите базовые показатели. Начните с одинаковых значений для запросов и ограничений. Затем постепенно корректируйте эти значения, пока не установите порог, способный привести к нестабильной работе кластера. Ограничения pod можно указать в манифестах развертывания. Средство вертикального автомасштабирования pod оптимизирует значения запросов ЦП и памяти и может повысить эффективность ресурсов кластера.
  • Встроенные функции могут обрабатывать сбои и сбои в архитектуре служб. Эти конфигурации помогают упростить разработку и автоматизацию развертывания. Когда организация определяет стандарт для SLA, RTO и RPO, она может использовать службы, встроенные в Kubernetes и Azure, для достижения бизнес-целей.
• Для развертывания новых выпусков приложения рассмотрите стратегии сине-зеленого цвета или канареечного цвета.
• Задайте бюджеты приоритета и прерывания pod, чтобы ограничить количество реплик pod, которые кластер может принимать для операций обслуживания, тем самым обеспечивая доступность.
• Применение квот ресурсов в пространствах имен служб. Квота ресурсов для пространства имен обеспечит правильную настройку запросов и ограничений pod в развертывании.
  • Установка квот ресурсов на уровне кластера может вызвать проблемы при развертывании партнерских служб, у которых нет соответствующих запросов и ограничений.
• Храните образы контейнеров в Реестр контейнеров Azure и геореплицируйте реестр в каждый регион.
• Используйте несколько регионов и расположений пиринга для подключения Azure ExpressRoute. Если возникает сбой, затрагивающий расположение поставщика пиринга или регион Azure, избыточная архитектура гибридной сети помогает обеспечить непрерывное подключение между различными местоположениями.
• Соединяйте регионы с помощью глобального пиринга между виртуальными сетями. Если кластеры должны взаимодействовать друг с другом, обе виртуальных сети можно соединить с помощью пиринга между виртуальными сетями. Эта технология соединяет виртуальные сети друг с другом, обеспечивая высокую пропускную способность в магистральной сети Майкрософт, даже в разных географических регионах.
• Используйте разделенный протокол любой рассылки на основе TCP Azure Front Door, чтобы быстро подключить пользователей к ближайшей точке присутствия Front Door POP. Ниже приведены дополнительные функции Azure Front Door.
  • завершение сеанса TLS;
  • Личный домен
  • Брандмауэр веб-приложения
  • Переопределение URL-адресов
  • Сходство сеансов

Дальнейшие действия

Ознакомьтесь с рекомендациями по проектированию для автоматизации платформы и DevOps в целевых зонах Azure.