Развертывание IBM Maximo Application Suite в Azure

IBM Maximo Application Suite (MAS) 8.x выполняется в OpenShift, и полезно ознакомиться с OpenShift и предлагаемыми шаблонами для установки в Azure. Дополнительные сведения см. в статье "Подготовка к установке в Azure". Эта архитектура иллюстрирует кластер OpenShift. Он не подробно описывает, как установить MAS. Дополнительные сведения о процессе установки см. в разделе "Установка Maximo Application Suite" из OperatorHub.

Архитектура

Скачайте файл Visio для этой архитектуры.

Рабочая нагрузка может быть развернута внутри или вне системы в зависимости от ваших требований.

Рабочий процесс

С точки зрения инфраструктуры эта архитектура обеспечивает следующие возможности:

• Платформа размещения контейнеров для развертывания высокодоступных рабочих нагрузок в зонах доступности
• Приватизированное развертывание рабочих и контрольных узлов, интегрированных с хранилищем
• Файлы Azure уровня "Премиум" и стандартные файлы для хранилища (Не требуется OpenShift Data Foundation)
• SQL Server на виртуальных машинах Azure или хранилище IBM Db2 на основе контейнеров
• Azure DNS для управления DNS OpenShift и его контейнерами
• Идентификатор Microsoft Entra для единого входа в MAS

Компоненты

• Azure Виртуальные машины для размещения платформы OpenShift и запуска контейнеров Maximo. Виртуальные машины — это предложение инфраструктуры как услуга (IaaS). Виртуальные машины можно использовать для развертывания масштабируемых вычислительных ресурсов, предоставляемых по запросу.

• Red Hat Enterprise Linux CoreOS для предоставления пользовательского образа виртуальной машины для OpenShift.

• Azure Load Balancers для обеспечения подключения к кластеру. Azure Load Balancer — высокопроизводительная служба балансировки нагрузки на уровне 4 со сверхнизкой задержкой (входящей и исходящей) для всех протоколов UDP и TCP. Она разработана для обработки миллионов запросов в секунду, обеспечивая высокую доступность решения. Служба Azure Load Balancer является избыточной между зонами, обеспечивая высокий уровень доступности для разных зон доступности.

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

• Файлы Azure размещения данных с отслеживанием состояния для баз данных и систем в кластере. Файлы Azure предоставляет полностью управляемые общие папки в облаке, доступные через протоколы S МБ и NFS.

• Azure DNS для управления разрешением DNS для контейнеров внутри и за пределами решения. Azure DNS поддерживает все общие записи DNS и обеспечивает высокий уровень доступности.

• Бастион Azure (необязательно) и подсеть для безопасного доступа к любым рабочим узлам или необязательным компьютерам JumpBox. Бастион Azure — это полностью управляемая служба, которая обеспечивает безопасный и простой доступ к виртуальным машинам по протоколу RDP и SSH без какого-либо воздействия через общедоступные IP-адреса.

• SQL Server в Azure Виртуальные машины (необязательно) SQL Server в Azure Виртуальные машины (виртуальных машинах) для предоставления служб данных MAS. База данных также может быть другой, например Oracle Exadata или IBM Db2 Warehouse. База данных SQL Azure и Управляемый экземпляр SQL Azure сейчас не поддерживаются.

• Twilio Send Grid (необязательно) для отправки сообщений электронной почты из MAS потребителям.

• Виртуальные машины Linux в Azure (необязательно) предоставляют окно перехода для установки OpenShift. Вы также можете использовать эту виртуальную машину для подключения к кластеру OpenShift и управления им, так как он содержит файл конфигурации Kubernetes после установки. Если у вас есть сетевое подключение к среде Azure, можно выполнить установку с существующего компьютера.

Альтернативные варианты

Обычно не нужны следующие службы, но они являются эффективными альтернативами:

• Azure NetApp Files в качестве замены Файлы Azure. NetApp Files поддерживает любую рабочую нагрузку с высоким уровнем доступности и высокой производительностью.
• База данных Oracle в Azure , если вы предпочитаете использовать хранилище SQL Server или Db2.
• OpenShift Data Foundation , если вы хотите использовать хранилище Db2 в OpenShift Data Foundation.

Подробности сценария

IBM Maximo Application Suite (MAS), также известный как Maximo, является платформой управления корпоративными активами с обслуживанием активов на основе ИИ. MAS фокусируется на устойчивости и надежности операционной деятельности. Набор состоит из основной платформы приложений, MAS и приложений и отраслевых решений на основе платформы. Каждое приложение предоставляет определенное преимущество:

• Управление. Сокращение времени простоя и затрат с помощью управления ресурсами для повышения производительности операций.
• Мониторинг. Используйте IoT для расширенного мониторинга удаленных ресурсов на основе искусственного интеллекта в большом масштабе.
• Работоспособность. Управление работоспособностью активов с помощью данных Интернета вещей с помощью датчиков, данных активов и журнала обслуживания.
• Визуальная проверка. Обучение моделей машинного обучения для использования визуальной проверки для визуального анализа возникающих проблем.
• Прогнозирование. Прогнозирование будущих сбоев с помощью машинного обучения и аналитики данных.
• Помощь. Помощь техническим специалистам путем предоставления ими руководства база знаний данных обслуживания оборудования и предоставления им удаленного доступа к экспертам.
• Сейф сти. Сбор и анализ данных с датчиков, предоставление контекстных данных и получение значимых аналитических данных.
• Гражданский. Интегрируйте действия по проверке, отслеживанию дефектов и обслуживанию, помогающие улучшить жизнь активов, сохранить критически важные системы и снизить общую стоимость владения гражданской инфраструктурой.

Эти приложения и MAS 8.X тестируются для использования в Azure. Корпорация Майкрософт и команда IBM Maximo сотрудничают, чтобы обеспечить оптимальную работу этого решения в Azure. В этой статье описано, как запустить MAS 8.x в Azure для клиентов с поддержкой IBM и партнера по установке. Обратитесь к группе IBM по вопросам, связанным с продуктами. Azure Marketplace предлагает альтернативную установку для MAS, которая поддерживает создание собственной лицензии. Дополнительные сведения см. в статье IBM Maximo Application Suite (BYOL).

Потенциальные варианты использования

Многие отрасли и секторы используют решения в MAS, такие как:

• Энергетика и инженерное обеспечение
• Нефть и газ
• Производство
• Путешествия, автомобили и транспорт
• Государственный сектор

Дополнительные сведения об вариантах использования MAS на веб-сайте IBM Maximo Application Suite.

Рекомендации

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

Использование более ранних или более поздних основных версий OpenShift может привести к падению официальной поддержки MAS. Перед созданием собственного развертывания рекомендуется использовать краткое руководство по развертыванию MAS, чтобы понять, как работает развертывание и конфигурация. Зная, как это делается, ускоряет создание требований к проектированию для реализации. Дополнительные сведения см . в кратком руководстве. Максимо Application Suite в Azure.

Мы тесно сотрудничаем с IBM и другими партнерами, чтобы гарантировать, что рекомендации, архитектура и краткое руководство помогут вам лучше всего работать в Azure. Они следуют рекомендациям, описанным в Microsoft Azure Well-Architected Framework. Обратитесь к группе учетной записи IBM, чтобы получить поддержку за пределами этой документации.

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

• Какие приложения MAS вам нужны?
• Какие зависимости имеют приложения?
• Какая версия OpenShift требуется?
• Какой метод установки OpenShift следует использовать?
• Какие базы данных необходимы?
• Какое количество и размеры виртуальных машин требуется?
• Будут ли пользователи подключаться из внешних сетей?

Maximo Application Suite

Корпорация Майкрософт проверила MAS версии 8.5 и более поздних версий в Azure. Мы рекомендуем использовать последнюю версию MAS, которая является версией 8.7.

Просмотрите приложения MAS, необходимые для полного бизнес-сценария, а затем просмотрите требования для каждого из приложений. Дополнительные сведения см. в статье о требованиях к системе IBM Maximo Application Suite. Каждому из приложений может потребоваться отдельная база данных. Мы проверили и поддержали следующие базы данных в Azure:

• SQL Server на виртуальных машинах Azure версии 2019 с помощью Windows или Linux
• Хранилище IBM Db2 в Cloud Pak для данных 3.5

Вы также можете запустить Oracle Exadata на виртуальной машине или в Oracle Cloud Infrastructure с помощью взаимодействия, но это не проверенная конфигурация. Дополнительные сведения о соединении см. в статье о подключении Oracle Cloud с Microsoft Azure. В настоящее время База данных SQL Azure, Управляемый экземпляр SQL Azure и Azure Cosmos DB не поддерживаются.

MAS и некоторые из его приложений имеют зависимости от MongoDB и Kafka. Определите, как развернуть эти решения на основе соображений производительности и операций. По умолчанию необходимо развернуть MongoDB Community Edition и Strimzi Kafka в кластерах. Некоторые из предварительных требований MAS, например BAS, используют базы данных, которые не могут быть внешние, но которые требуют постоянного хранения для кластера OpenShift.

Для служб на основе состояния, работающих внутри кластера OpenShift, часто выполняется резервное копирование данных и перемещение резервных копий в другой регион. Проектируйте и планируйте стратегию восстановления в случае аварии и решите соответствующим образом, особенно при запуске Kafka или MongoDB в OpenShift.

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

Для некоторых служб могут потребоваться другие инструменты и службы IBM, такие как IBM Watson Машинное обучение и IBM App Подключение. Вы можете развернуть все средства и службы в одном кластере OpenShift.

OpenShift

Перед установкой OpenShift необходимо определить, какой метод вы будете использовать:

• Подготовленная инфраструктура установщика (IPI). Этот метод использует установщик для развертывания и настройки среды OpenShift в Azure. IPI — это наиболее распространенный метод развертывания в Azure, и следует использовать IPI, если требования к безопасности не слишком строги для этого.

• Подготовленная пользователем инфраструктура (UPI) Этот метод позволяет точно контролировать развертывание. UPI требует дополнительных шагов и рекомендаций по созданию среды. Используйте UPI, если IPI не соответствует вашим потребностям. Распространенный вариант использования UPI предназначен для частной установки с использованием воздуха. Выберите UPI, если при создании среды нет исходящего доступа к Интернету.

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

При установке OpenShift необходимо устранить следующие аспекты:

• Выбор региона. Рекомендуется использовать регион с зонами доступности. Во время развертывания OpenShift автоматически пытается создать узлы между зонами на основе конфигурации в файле конфигурации, install-config.yaml. По умолчанию OpenShift балансирует рабочие нагрузки на всех доступных узлах и в зонах доступности. Если в зоне произошел сбой, решение может продолжать работу, имея узлы в других зонах, которые могут взять на себя работу.

• Резервное копирование и восстановление. Инструкции для Azure Red Hat OpenShift можно использовать для резервного копирования и восстановления. Дополнительные сведения см. в статье "Создание резервного копирования приложений azure Red Hat OpenShift 4". Если этот метод используется для резервного копирования и восстановления, необходимо предоставить другой метод аварийного восстановления для базы данных.

• Отработка отказа. Рассмотрите возможность развертывания OpenShift в двух регионах и использования Red Hat Advanced Cluster Management. Если решение имеет общедоступные конечные точки, вы можете разместить Диспетчер трафика Azure между ними и Интернетом, чтобы перенаправить трафик в соответствующий кластер при сбое региона. В такой ситуации необходимо также перенести состояния приложений и постоянные тома.

Установки с отводом воздуха

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

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

Дополнительные сведения о установках с воздушным доступом см. в следующей документации по OpenShift:

• Зеркальные изображения для отключенной установки
• Установка частного кластера в Azure

После установки OpenShift ознакомьтесь с документацией MAS по аналогичным рекомендациям.

Определение размера среды

Для всех рабочих нагрузок (кроме визуальной проверки) рекомендуется использовать последние виртуальные машины серии Ds в качестве рабочих узлов. Примерами являются Dsv3, Dasv4, Dsv4, Dasv5 или Dsv5. По возможности рекомендуется использовать последние версии, так как они обеспечивают более высокую производительность. Используйте только виртуальные машины с хранилищем класса Premium.

Максимо Visual Inspection требует, чтобы узлы GPU выполняли машинное обучение. Решение использует CUDA и поддерживает только GPU NVIDIA. Рекомендуемые типы виртуальных машин — NCv3 и NCasT4_v3. Если вам нужно обучиться с помощью YOLOv3, вам потребуются графические процессоры на основе Ampere. Используйте NVadsA10 v5 или NC A100 версии 4 для более крупных задач обучения.

Для компьютеров GPU рекомендуется начинать с наименьшего узла и увеличивать масштаб по мере увеличения требований.

Для всех остальных компьютеров рекомендуется настроить виртуальные машины в зонах доступности для обеспечения высокой доступности. Настройте узлы следующим образом:

• Управление узлами. Не менее одной виртуальной машины на каждую зону доступности в выбранном регионе. Мы рекомендовали количество виртуальных ЦП по крайней мере 4. В нашем справочнике используются 3x Standard_D8s_v4 узлов.

• Рабочие узлы. Не менее двух компьютеров на каждую зону доступности в выбранном регионе. Мы рекомендуем по крайней мере 8 виртуальных ЦП. В нашем справочнике используется 6x Standard_D8s_v4 узлов.

Для базовой установки уровня "Стандартный" требуется 13 виртуальных ЦП. Размер рабочих узлов зависит от того, какие приложения MAS развертывают конфигурацию и нагрузку на среду. Например, для управления для 10 пользователей требуется еще 2 виртуальных ЦП. Мы рекомендуем ознакомиться с требованиями к системе IBM Maximo Application Suite, чтобы получить хорошую оценку размера.

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

Если вам нужен флажок перехода для использования интерфейса командной строки OpenShift (oc) или установки MAS, разверните виртуальную машину под управлением Red Hat Enterprise Linux версии 8.4.

Network

С помощью OpenShift мы используем поставщик сетевого интерфейса контейнера по умолчанию (CNI) программно-определяемой сети OpenShift (SDN). Дополнительные сведения о CNI openShift по умолчанию см. в разделе "Оператор сети кластера" в платформе контейнеров OpenShift. Необходимо размер сети для количества необходимых рабочих узлов и элементов управления OpenShift, а также для любых других требований, таких как базы данных и учетные записи хранения.

Для стандартной производственной установки MAS рекомендуется использовать виртуальную сеть с адресным пространством, которое предоставляет префикс CIDR /24. Виртуальная сеть имеет три или четыре подсети (для Бастиона). Для OpenShift подсеть для рабочих узлов имеет префикс CIDR /25, а узлы управления имеют префикс /27. Подсеть для конечных точек и необязательный внешний сервер базы данных должен иметь префикс /27. Если вы развертываете Бастион Azure, который является необязательным, вам нужна подсеть с именем AzureBastionSubnet с префиксом /26. Дополнительные сведения о требованиях к Бастиону Azure см. в статье "Архитектура".

Если у вас нет IP-адресов, можно реализовать конфигурацию с высоким уровнем доступности с минимальным префиксом /27 для подсети узлов управления и /27 для подсети рабочих узлов.

Если вы хотите использовать другую CNI, задайте размер сетей соответствующим образом. MAS с некоторыми стандартными приложениями развертывает более 800 модулей pod, которые, скорее всего, требуют префикса CIDR /21 или большего размера.

Особенности базы данных

Различные компоненты MAS используют MongoDB в качестве хранилища метаданных. Руководство по умолчанию — развертывание MongoDB Community Edition в кластере. Если вы развертываете его с помощью этого метода, убедитесь, что у вас есть правильная процедура резервного копирования и восстановления базы данных. Рассмотрите возможность использования MongoDB Atlas в Azure, так как она предоставляет внешнее хранилище, резервные копии, масштабирование и многое другое. В настоящее время Azure не поддерживает использование API MongoDB с Azure Cosmos DB.

При развертывании служб Интернета вещей необходимо также предоставить конечную точку Kafka. Руководство по умолчанию — использовать Strimzi для развертывания Kafka в кластере OpenShift. Во время аварийного восстановления данные внутри Strimzi, скорее всего, будут потеряны. Если потеря данных в Kafka неприемлема, следует рассмотреть возможность использования Confluent Kafka в Azure. В настоящее время Центры событий Azure с конечными точками Kafka не поддерживаются.

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

• Стандартный. Предоставляет общие папки блока сообщений сервера (S МБ) для более низкой пропускной способности и рабочих нагрузок ReadWriteOnce (RWO). Стандарт — это отлично подходит для частей приложения, которые часто не записываются в хранилище и требуют одного постоянного тома (например, одноуровневого хранилища IBM).

• Премиум. Предоставляет общие ресурсы сетевой файловой системы (NFS) для более высокой пропускной способности и рабочих нагрузок ReadWriteMany (RWX). Такие тома используются во всем кластере для рабочих нагрузок RWX, таких как хранилище Db2 в Cloud Pak для данных или Postgres в управлении.

Не забудьте отключить политики для принудительной безопасной передачи на Хранилище BLOB-объектов Azure или исключить учетные записи из таких политик. Для файлов Уровня "Премиум" Azure с NFS требуется отключить безопасную передачу. Не забудьте использовать частную конечную точку , чтобы гарантировать частное подключение к общим папкам.

По умолчанию хранилище Db2 развертывается поверх OpenShift Data Foundation (ранее известное как OpenShift Container служба хранилища). По соображениям затрат, производительности, масштабирования и надежности мы рекомендуем использовать файлы Azure Premium с NFS вместо OpenShift Data Foundation.

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

Рекомендации

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая представляет собой набор руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".

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

Azure предоставляет MAS с помощью моделей инфраструктуры как услуги (IaaS) и PaaS. Корпорация Майкрософт создает защиту безопасности в службе на следующих уровнях:

• Физический центр обработки данных
• Физическая сеть
• Физический узел
• Низкоуровневая оболочка

Тщательно оцените службы и технологии, которые вы выбираете для областей над гипервизором, например последнюю исправленную версию OpenShift для основного выпуска. Обязательно предоставьте правильные элементы управления безопасностью для архитектуры. Вы несете ответственность за исправление и поддержание безопасности систем IaaS. Корпорация Майкрософт принимает роль для служб PaaS.

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

• Разрешение доступа SSH к узлам OpenShift для устранения неполадок
• Блокировать доступ ко всем остальным частям кластера
• Управление доступом к MAS и кластеру OpenShift

Если вам нужен доступ к виртуальным машинам по какой-то причине, вы можете подключиться через гибридное подключение или с помощью консоли администрирования OpenShift. Если у вас есть сетевое развертывание или вы не хотите полагаться на подключение, вы также можете получить доступ к виртуальным машинам через Бастион Azure (необязательно). По соображениям безопасности не следует предоставлять виртуальные машины сети или Интернету без настройки групп безопасности сети для управления доступом к ним.

Шифрование на стороне сервера (SSE) диска Azure служба хранилища защищает данные. Он также помогает выполнять обязательства организации по обеспечению безопасности и соответствия требованиям. С помощью управляемых дисков Azure служба SSE шифрует неактивных данных при сохранении данных в облаке. Это поведение применяется по умолчанию как к дискам ОС, так и к дискам данных. По умолчанию OpenShift использует SSE.

Проверка подлинности

MAS в настоящее время поддерживает использование языка разметки утверждений безопасности (SAML) с помощью идентификатора Microsoft Entra. Чтобы сделать эту работу, требуется корпоративное приложение в идентификаторе Microsoft Entra и разрешение на изменение приложения или помощь глобального администратора, который может внести необходимые изменения.

Краткое руководство по GitHub содержит руководство по настройке SAML с помощью MAS. Дополнительные сведения см. в разделе "Включение проверки подлинности SAML для идентификатора Microsoft Entra".

Перед настройкой проверки подлинности на основе SAML рекомендуется пройти конфигурацию IBM и конфигурацию Azure. Сведения о SAML с MAS см . в документации по SAML для MAS. Сведения о SAML в Azure см . в кратком руководстве по включению единого входа для корпоративного приложения.

Также следует настроить OAuth для OpenShift. Дополнительные сведения см. в разделе "Общие сведения о проверке подлинности и авторизации " в документации по OpenShift.

Защита инфраструктуры

Контролируйте доступ к развертываемым ресурсам Azure. Каждая подписка Azure имеет отношение доверия с клиентом Microsoft Entra. Используйте управление доступом на основе ролей Azure (Azure RBAC), чтобы предоставлять пользователям в своей организации необходимые разрешения на использование ресурсов Azure. Предоставляйте доступ, назначая пользователям или группам в определенной области роли Azure. Областью может быть подписка, группа ресурсов или отдельный ресурс. Обязательно проверяйте все изменения инфраструктуры. Дополнительные сведения об аудите см . в журнале действий Azure Monitor.

Оптимизация затрат

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

Стандартное развертывание MAS состоит из следующих компонентов:

• 3 виртуальные машины управления
• 6 рабочих виртуальных машин
• 3 рабочих виртуальных машины для хранилища Db2
  • Sql Server можно заменить на виртуальных машинах Azure в некоторых конфигурациях, а не использовать хранилище Db2.
• 2 учетные записи служба хранилища Azure
• 2 зоны DNS
• 2 подсистемы балансировки нагрузки
• Бастион Azure
• 1 виртуальная машина визуальной проверки
  • Это не обязательно, если вы не планируете запускать визуальную проверку внутри MAS.

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

Надежность

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

MAS и OpenShift используют хранилище для сохранения состояния за пределами кластера Kubernetes. Чтобы убедиться, что зависимости хранилища продолжают работать во время сбоя, следует использовать избыточное между зонами хранилище всякий раз, когда это возможно. Этот тип хранилища остается доступным при сбое зоны.

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

Развертывание этого сценария

Перед началом работы рекомендуется ознакомиться с требованиями к системе IBM Maximo Application Suite. Перед началом развертывания убедитесь, что у вас есть следующие ресурсы:

• Доступ к подписке Azure с разрешением читателя
• Регистрация приложения или имя субъекта-службы с разрешениями участника и доступа пользователей Администратор istrator для подписки
• Домен или делегированный поддомен в зону Azure DNS
• Извлечение секрета из Red Hat для развертывания OpenShift
• Ключ прав MAS
• Файл лицензии MAS (созданный после установки MAS)
• Рекомендуемый IBM размер кластера
• Существующая виртуальная сеть или новая виртуальная сеть, созданная с помощью IPI, в зависимости от ваших требований
• Требования к высокой доступности и аварийному восстановлению для конкретного развертывания
• Файл конфигурации, install-config.yaml для установщика

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

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

Лучше всего развертывать рабочие нагрузки с помощью инфраструктуры как кода (IaC), а не вручную развертывать рабочие нагрузки, так как развертывание вручную может привести к неправильной настройке. Рабочие нагрузки на основе контейнеров могут быть чувствительны к неправильной настройке, что может снизить производительность.

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

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.

Основные авторы:

• Дэвид Баумгартен | Старший архитектор облачных решений
• Roeland Nieuwenhuis | Главный архитектор облачных решений

Другие участник:

• Гэри Мур | Программист или писатель

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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

Сведения о начале работы см. в следующих ресурсах:

• Установка OpenShift в Azure
• Краткое руководство. Максимо Application Suite в Azure
• Руководство по OpenShift UPI
• Требования к Максимо
• IBM Maximo Application Suite (BYOL)

Дополнительные сведения о рекомендуемых технологиях см. в следующих ресурсах:

• Преимущество IBM Passport
• Общие сведения о Azure DNS
• Общие сведения об Azure NetApp Files
• Общие сведения о Red Hat в Azure
• Портал клиентов Red Hat

Связанные ресурсы

• Общей папке облачного облака Azure
• Введение в прогнозное обслуживание в производстве
• Развертывание приложения Java с помощью JBoss EAP в кластере ARO