Implementación de IBM Maximo Application Suite en Azure

En este artículo se describe la implementación de IBM Maximo Application Suite (MAS) en Azure. MAS se ejecuta en Red Hat OpenShift. Red Hat OpenShift en Azure (ARO) es la plataforma de OpenShift preferida si cumple los requisitos operativos, de seguridad y de red. Use Red Hat OpenShift autoadministrado en Azure solo cuando necesite controlar que ARO no proporciona, como patrones de implementación desconectados específicos o personalización de nivel de clúster.

En este artículo no se detalla cómo instalar MAS. Para obtener más información sobre la instalación, consulte Instalación de Maximo Application Suite.

Arquitectura

En el diagrama siguiente se muestra una implementación de MAS basada en ARO en Azure.

Descargue un archivo Visio de esta arquitectura.

Puede implementar la carga de trabajo como una implementación interna o externa, en función de sus requisitos. En este artículo no se prescribe un modelo de implementación de ARO público o privado. Elija el plano de control, la arquitectura de entrada y salida en función de la arquitectura de la zona de aterrizaje de Azure, incluida su topología de red, el modelo de conectividad, los controles de seguridad, los requisitos de acceso operativo, los requisitos de cumplimiento y los patrones de acceso de usuario de MAS.

Cuando IBM admite bases de datos externas para las aplicaciones MAS que implemente, intente externalizar esas bases de datos para reducir el estado dentro del clúster de OpenShift y desacoplar la administración de bases de datos de la administración de clústeres.

Flujo de trabajo

Desde una perspectiva de la infraestructura, esta arquitectura proporciona las siguientes funcionalidades:

• Un servicio administrado Red Hat OpenShift en Azure para implementar cargas de trabajo de alta disponibilidad en zonas de disponibilidad
• Un clúster de OpenShift integrado con redes y almacenamiento de Azure
• Azure Files Premium y Azure Files Estándar para los requisitos de almacenamiento de MAS admitidos
• Azure SQL Managed Instance o IBM Db2 Warehouse basado en contenedores
• Azure DNS para la administración del sistema de nombres de dominio (DNS) de OpenShift y sus contenedores
• Microsoft Entra ID para el inicio de sesión único (SSO) en MAS

Componentes

• Red Hat OpenShift en Azure (ARO) es la plataforma de OpenShift preferida para MAS en Azure. ARO reduce la responsabilidad operativa de ejecutar OpenShift, en comparación con un clúster autoadministrado en máquinas virtuales (VM) de Azure.

• Azure Virtual Machines es una infraestructura como servicio (IaaS) que implementa recursos informáticos a petición y escalables. Use Virtual Machines en lugar de ARO para implementar Red Hat OpenShift autoadministrado en Azure.

  Opcionalmente, use Azure máquinas virtuales Linux como jump boxes para la instalación de MAS y la administración de OpenShift. Si tiene conectividad de red privada en el entorno de Azure, puede realizar la administración desde una máquina protegida existente.

• Red Hat Enterprise Linux CoreOS proporciona la imagen del sistema operativo para los nodos de OpenShift.

• Azure Load Balancer proporciona conectividad al clúster. Load Balancer es un servicio de equilibrio de carga de nivel 4 de alto rendimiento y ultra bajo rendimiento para todos los protocolos de datagramas de usuario entrantes y salientes (UDP) y protocolos de control de transmisión (TCP). Load Balancer puede controlar millones de solicitudes por segundo, a la vez que garantiza que la solución es de alta disponibilidad. Load Balancer es con redundancia de zona, lo que garantiza una alta disponibilidad en todas las zonas de disponibilidad.

• Azure Virtual Network es el bloque de creación fundamental para las redes privadas en Azure. Use Virtual Network para la comunicación entre nodos y servicios Azure y para la conectividad híbrida.

• Azure Files proporciona recursos compartidos de archivos totalmente administrados en la nube a los que se puede acceder a través de los protocolos bloque de mensajes del servidor (SMB) y del sistema de archivos de red (NFS). Use Azure Files para hospedar los datos con estado de las bases de datos y los sistemas dentro del clúster.

• Azure DNS administra la resolución DNS para los contenedores dentro y fuera de la solución. Azure DNS admite todos los registros DNS comunes y proporciona alta disponibilidad.

• Azure Bastion es un servicio totalmente administrado que proporciona acceso de protocolo de escritorio remoto (RDP) y de shell seguro (SSH) a las máquinas virtuales sin exposición a través de direcciones IP públicas. Opcionalmente, use Azure Bastion y una subred para el acceso de seguridad mejorada a cualquiera de los nodos de trabajo o a las máquinas de jump box opcionales.

• SQL Managed Instance proporciona servicios de datos externos a MAS cuando IBM admite SQL Server para las aplicaciones que implemente. También puede elegir otra base de datos, como Oracle Exadata o IBM Db2 Warehouse. no se admite Azure SQL Database.

• Twilio SendGrid envía correos electrónicos de MAS a sus consumidores. Si la implementación de MAS necesita un servicio de correo electrónico para escenarios de envío de notificaciones y empleados, puede incorporar un servicio de correo electrónico como Twilio SendGrid en su diseño.

Alternativas

Normalmente, los siguientes servicios no son necesarios, pero son alternativas eficaces:

• Azure NetApp Files como reemplazo de Azure Files. Azure NetApp Files admite cargas de trabajo que necesitan alta disponibilidad y alto rendimiento.
• Oracle Database en Azure si se admite y lo prefiere.
• OpenShift Data Foundation si desea usar Db2 Warehouse en OpenShift Data Foundation.

Detalles del escenario

IBM Maximo Application Suite es una plataforma de administración de activos empresariales con mantenimiento de activos basado en IA. MAS se centra en la resistencia operativa y la confiabilidad. El conjunto consta de la plataforma de aplicaciones principales de MAS y las siguientes aplicaciones y soluciones específicas del sector que se basan en la plataforma.

• Maximo Manage. Reduce el tiempo de inactividad y los costos mediante la administración de recursos para mejorar el rendimiento operativo.
• Maximo Monitor. Usa Internet de las cosas (IoT) para la supervisión avanzada con tecnología de inteligencia artificial de recursos remotos a escala.
• Maximo Health. Administra el estado de los recursos mediante el uso de datos de IoT de sensores, datos de recursos e historial de mantenimiento.
• Inspección visual máxima. Entrena modelos de aprendizaje automático para usar la inspección visual para el análisis visual de problemas emergentes.
• Maximo Predict. Predice errores futuros mediante el aprendizaje automático y el análisis de datos.
• Maximo Collaborate. Admite técnicos con instrucciones basadas en inteligencia artificial de una base de conocimiento de datos de mantenimiento de equipos y proporciona acceso remoto a expertos.
• Maximo Health, Safety and Environment (HSE). Conecta los procesos de seguridad, cumplimiento del entorno y control del trabajo a recursos, ubicaciones y pedidos de trabajo.
• Maximo Civil Infrastructure. Integra las actividades de inspección, seguimiento de defectos y mantenimiento para ayudar a mejorar la vida de los activos, mantener los sistemas críticos operativos y reducir los costos totales de propiedad de la infraestructura civil.
• Maximo Real Estate e Instalaciones. Administra carteras inmobiliarias y activos de instalaciones con gestión de espacios, reservas, proyectos de capital, evaluación de condiciones de instalación, administración de arrendamientos, operaciones y mantenimiento.

Posibles casos de uso

Muchos sectores y sectores usan soluciones MAS, como las siguientes:

• Energía y servicios públicos
• Petróleo y gas
• Fabricación
• Viajes, automoción y transporte
• Sector público

Para obtener más información sobre los casos de uso de MAS, consulte IBM Maximo Application Suite en el sitio web de IBM.

Recomendaciones

Este artículo está escrito para implementaciones de MAS 9.x compatibles actualmente en Azure. Microsoft trabajó con el equipo de IBM MAS y otros asociados para asegurarse de que esta solución está configurada para ejecutarse de forma óptima y proporcionar la mejor experiencia en Azure. Esta documentación, arquitectura e instrucciones siguen los procedimientos recomendados como se describe en Microsoft Azure Well-Architected Framework. Póngase en contacto con el equipo de la cuenta de IBM para obtener preguntas específicas del producto y soporte técnico más allá de esta documentación.

Use este artículo para obtener instrucciones de arquitectura cuando tenga soporte técnico de IBM y un asociado para la instalación. Azure también ofrece una ruta de instalación para MAS que admite la incorporación de su propia licencia. Para obtener más información, consulte IBM Maximo Application Suite (traiga su propia licencia (BYOL)).

Instale una versión de MAS compatible que IBM enumera como compatible con la versión de OpenShift seleccionada y las aplicaciones MAS. En el caso de las nuevas implementaciones de Azure, use ARO como plataforma de OpenShift preferida a menos que necesite un clúster autoadministrado.

La compatibilidad de soporte técnico de OpenShift depende de tres límites de compatibilidad superpuestos: compatibilidad de IBM MAS, compatibilidad con el ciclo de vida de Red Hat OpenShift y disponibilidad de la versión de ARO. El uso de una versión de OpenShift que IBM no muestra en los informes de compatibilidad de productos de software (SPCR) o que están fuera de la compatibilidad con Red Hat o ARO puede dejar que la implementación de MAS no sea compatible.

Antes de compilar la implementación, revise la información general de IBM Maximo Application Suite, Planeación de la instalación en Microsoft Azure e Informes de compatibilidad de productos de software (SPCR) para comprender los requisitos de implementación y configuración actuales.

Antes de continuar con la implementación, responda las siguientes preguntas sobre el diseño:

• ¿Qué aplicaciones MAS necesita?
• ¿Qué dependencias tienen las aplicaciones?
• ¿Qué versión de OpenShift admite IBM para la versión y las aplicaciones mas?
• ¿ARO cumple sus requisitos o necesita Red Hat OpenShift autoadministrado en Azure?
• ¿Qué bases de datos necesita?
• ¿Qué número y tamaños de máquinas virtuales necesita?
• ¿Los usuarios necesitan conectarse desde redes externas?

Maximo Application Suite

Use una versión de MAS 9.x compatible actualmente y valide las versiones, bases de datos y dependencias compatibles de OpenShift en IBM SPCR antes de finalizar la arquitectura. Si está en una versión anterior de Maximo Application Suite, revise su estado del ciclo de vida de IBM y planee una actualización a una versión compatible de MAS 9.x.

Revise las aplicaciones mas que necesita para su escenario empresarial completo y, a continuación, revise los requisitos de cada una de las aplicaciones. Para obtener más información, consulte Requisitos del sistema IBM Maximo Application Suite.

Cada aplicación MAS puede necesitar una base de datos independiente. Intente externalizar bases de datos si IBM admite una base de datos externa para la aplicación, ya que ese enfoque reduce la cantidad de estado que debe operar dentro de OpenShift. Microsoft e IBM probaron y admiten las siguientes bases de datos para MAS en Azure:

• SQL Managed Instance
• IBM Db2 Warehouse on Cloud Pak for Data 5

no se admiten Azure SQL Database ni Azure Cosmos DB.

También puede optar por ejecutar Oracle Exadata en Oracle Cloud Infrastructure o en una máquina virtual mediante una interconexión. Esta configuración no se prueba oficialmente, pero se informa que es correcta. Para obtener más información sobre la interconexión, consulte Interconnecting Oracle Cloud with Microsoft Azure.

MAS y algunas de sus aplicaciones dependen de MongoDB y Kafka. Use las implementaciones predeterminadas de MongoDB Community Edition y Strimzi Kafka predeterminadas de IBM cuando se ajusten a los requisitos de soporte técnico, copia de seguridad y recuperación. Esta opción es adecuada cuando Kafka y MongoDB son dependencias internas de MAS y la solución no las usa fuera de MAS.

Intente usar servicios administrados externos, como MongoDB Atlas en Azure o Confluent Cloud en Azure, cuando necesite operaciones de copia de seguridad, escalado o recuperación ante desastres más sólidas. Algunos requisitos previos de MAS, como Behavior Analytics Services (BAS), usan bases de datos que no se pueden externalizar, pero requieren que se proporcione almacenamiento persistente al clúster de OpenShift.

En el caso de los servicios basados en estado que se ejecutan dentro del clúster de OpenShift, realice copias de seguridad periódicamente de los datos y mueva las copias de seguridad a otra región. Diseñe, planee y decida una estrategia de recuperación para desastres, especialmente cuando se ejecuta Kafka o MongoDB dentro de OpenShift. En el caso de los servicios que conservan el estado, use ofertas de Azure plataforma como servicio (PaaS) externas si es posible para mejorar la compatibilidad durante una interrupción.

Algunos servicios pueden requerir otras herramientas y servicios de IBM, como IBM Watson Machine Learning e IBM App Connect. Puede implementar todas estas herramientas y servicios en el mismo clúster de OpenShift.

Red Hat OpenShift en Azure

Use ARO como plataforma de OpenShift preferida para MAS en Azure. ARO proporciona un servicio openShift administrado en Azure, lo que reduce la carga operativa para instalar, aplicar revisiones y operar la plataforma OpenShift. Todavía posee MAS y su configuración de aplicaciones, planeamiento de la capacidad de trabajo, integración de red, integración de identidades, opciones de almacenamiento, protección de datos y recuperación ante desastres.

Antes de implementar MAS en ARO, tenga en cuenta las siguientes recomendaciones:

• Compatibilidad de versiones. Seleccione una versión de OpenShift que IBM enumera como compatible con la versión de MAS y las aplicaciones MAS seleccionadas. Confirme que la misma versión de OpenShift está disponible y compatible con ARO en la región de Azure de destino. Cuando sea posible, seleccione una versión de OpenShift uniforme para las implementaciones de MAS de producción, ya que estas versiones son versiones de soporte extendido de actualización (EUS).

  Valide cruzadamente que IBM admite la versión de OpenShift seleccionada para todas las aplicaciones y dependencias de MAS seleccionadas. Si un componente MAS muestra una versión de OpenShift con un número impar más reciente como requisito en IBM SPCR, valide el conjunto de componentes completo en IBM SPCR, compatibilidad con el ciclo de vida de Red Hat y disponibilidad de la versión de ARO antes de elegir la versión del clúster.

• Ruta de acceso de implementación. Use un clúster de ARO existente cuando haya existente Azure zona de aterrizaje, redes, identidad, almacenamiento y controles operativos. Use la ruta de instalación de IBM Azure Marketplace cuando desee que la automatización proporcionada por IBM cree o reutilice la infraestructura de OpenShift compatible. Use Red Hat OpenShift autoadministrado en Azure solo cuando ARO no cumpla sus requisitos.

• Selección de región. Use una región que tenga zonas de disponibilidad si es posible. Configure nodos de trabajo de ARO entre zonas cuando la región de destino admita ese patrón. Para OpenShift autoadministrado, configure el archivo de instalación install-config.yaml, por lo que OpenShift coloca nodos entre zonas. Si hay una interrupción en una zona, la solución puede seguir funcionando si los nodos de otras zonas toman el trabajo.

• Copia de seguridad y recuperación. Puede usar las instrucciones de copia de seguridad y recuperación de Red Hat OpenShift en Azure. Para obtener más información, consulte Create an Red Hat OpenShift en Azure 4 cluster Application Backup. Si usa este método para la copia de seguridad y la recuperación, debe proporcionar otro método de recuperación ante desastres para la base de datos.

• Conmutación por error. Considere la posibilidad de implementar OpenShift en dos regiones y usar la administración avanzada de clústeres de Red Hat. Si la solución tiene puntos de conexión públicos, puede colocar Azure Traffic Manager entre los puntos de conexión e Internet para redirigir el tráfico al clúster adecuado en una interrupción regional. En esa situación, también debe migrar los estados de las aplicaciones y los volúmenes persistentes.

OpenShift autoadministrado

Use Red Hat OpenShift autoadministrado en Azure si ARO no cumple los requisitos de implementación, aislamiento o control. Para las implementaciones autoadministrados, elija entre los métodos de instalación siguientes:

• Infraestructura aprovisionada (IPI) del instalador. Este método usa un instalador para implementar y configurar el entorno de OpenShift en Azure. Use IPI cuando cumpla los requisitos de seguridad y redes.

• Infraestructura aprovisionada por el usuario (UPI). Este método permite un control específico sobre la implementación. UPI requiere más pasos y consideraciones para crear el entorno. Use UPI si IPI o ARO no satisfacen sus necesidades. Una instalación privada o desconectada es un caso de uso común para UPI.

Instalación con disponibilidad de aire

Algunos casos, como el cumplimiento normativo, podrían requerir una instalación de MAS en Azure. Con acceso directo a internet significa que no hay acceso entrante o saliente a Internet. Sin una conexión a Internet, la instalación no puede recuperar las dependencias para la instalación de MAS o OpenShift en tiempo de ejecución.

Use una instalación con disponibilidad por aire solo si es un requisito de seguridad. Una brecha aérea agrega una complejidad significativa a las operaciones de solución. Las actividades como la instalación de software, los contenedores de creación de reflejos, la actualización de reflejos para protegerse frente a vulnerabilidades de seguridad o la administración de firewalls pueden consumir un esfuerzo operativo significativo.

Para obtener más información sobre las instalaciones con disponibilidad de aire, consulte la siguiente documentación de Red Hat OpenShift para instalaciones desconectadas y clústeres privados en Azure:

• Creación de reflejo de imágenes para una instalación desconectada mediante oc-mirror
• Instalar un clúster privado en Azure

Después de instalar OpenShift con aire, puede continuar con la documentación de MAS para obtener instrucciones sobre entornos desconectados.

Ajuste de tamaño de nodo y entorno

Para todas las cargas de trabajo excepto Maximo Visual Inspection, comience con las familias de máquinas virtuales de la serie Ds o Das de generación actual, como Dsv6, que están disponibles como nodos de trabajo en la región elegida. Elija tamaños de máquina virtual que admitan Premium Storage y cumplan los requisitos de CPU, memoria y almacenamiento para las aplicaciones mas que implemente.

Maximo Visual Inspection requiere nodos GPU para realizar su aprendizaje automático. La solución usa CUDA y solo es compatible con las GPU NVIDIA. Para ARO, elija un tamaño de máquina virtual de GPU nvidia en la lista actual de compatibilidad con nodos de trabajo de ARO y confirme que IBM lo admite para las versiones mas y OpenShift. Para OpenShift autoadministrado, elija un tamaño de máquina virtual de GPU nvidia compatible con IBM y Red Hat.

En el caso de los nodos de trabajo de GPU, comience con el nodo más pequeño y escale verticalmente a medida que aumenten los requisitos.

Para ARO y OpenShift autoadministrado, use la misma guía de ajuste de tamaño de la carga de trabajo de MAS para los nodos de trabajo. Configure nodos de trabajo entre zonas de disponibilidad para admitir la alta disponibilidad. Para OpenShift autoadministrado, configure también el plano de control entre zonas de disponibilidad. Use el siguiente punto de partida:

• Nodos de control. Para ARO, el plano de control se administra como parte del servicio. Para OpenShift autoadministrado, use un mínimo de una máquina virtual por zona de disponibilidad dentro de la región seleccionada.

• Nodos de trabajo. Use un mínimo de dos máquinas por zona de disponibilidad dentro de la región seleccionada. Ajustar el tamaño de los nodos de trabajo en función de las instrucciones de IBM, las aplicaciones MAS seleccionadas y la carga esperada.

El núcleo MAS requiere 13 vCPU para una instalación base de tamaño estándar. El dimensionamiento de los nodos de trabajo varía en función de las aplicaciones MAS que implementa tu configuración y la carga sobre tu entorno. Por ejemplo, Maximo Manage para 10 usuarios requiere otras 2 vCPU. Trate estos valores como puntos de partida y valide el ajuste de tamaño con respecto a los requisitos actuales del sistema ibm Maximo Application Suite para la versión de MAS 9.x, las aplicaciones seleccionadas y el uso esperado.

Para OpenShift autoadministrado, intente mantener los tipos de máquina virtual similares entre sí para proporcionar proximidad con cada una de las zonas de disponibilidad entre nodos de trabajo y control. Para ARO, alinee los grupos de nodos de trabajo con los mismos requisitos de carga de trabajo de MAS y Azure capacidad regional.

Si necesita un jump box para usar la interfaz de la línea de comandos de OpenShift oc o para instalar MAS, implemente una máquina virtual Linux compatible que cumpla los requisitos administrativos y de seguridad de su organización.

Configuración de red

Para ARO, use la configuración de red predeterminada de OpenShift que ARO implementa a menos que IBM, Red Hat y el equipo de redes validen otra opción. Planee la red virtual y subredes independientes para nodos del plano de control de ARO, nodos de trabajo, Azure dependencias de servicio, puntos de conexión privados, bases de datos y conectividad híbrida. Tamaño de las subredes de nodo para el número de nodos de trabajo de OpenShift que necesita, incluida la capacidad de actualización y el escalado horizontal futuro.

Para OpenShift autoadministrado, también incluye los requisitos de infraestructura creados por el instalador y el arranque. Mantenga el acceso administrativo a la API de OpenShift y a los nodos limitados a las rutas de acceso de red aprobadas, como la conectividad híbrida, los hosts de salto protegidos u otros controles que requiere su organización. Si restringe la salida del clúster, planee las dependencias de salida necesarias para OpenShift, instalación de MAS, extracción de imágenes de contenedor, actualizaciones, supervisión y servicios externos.

Para una instalación estándar de producción de MAS en ARO, no empiece con una red virtual estrechamente empaquetada. Reserve un espacio de direcciones mayor, como un prefijo de enrutamiento de Inter-Domain sin clases (CIDR) de /16 cuando la zona de aterrizaje la permita y asigne subredes dedicadas. Use al menos un tamaño de planeamiento /24 para la subred del plano de control de ARO y al menos un tamaño de planeamiento /24 para la subred del nodo de trabajo. Agregue una subred /27 o superior para puntos de conexión privados y servicios de base de datos externos. Si opcionalmente implementa Azure Bastion, agregue una subred denominada AzureBastionSubnet con un prefijo de /26. Para obtener más información sobre los requisitos de Azure Bastion, consulte Arquitectura.

Si usa OpenShift autoadministrado y está corto en direcciones IP, puede diseñar una configuración de alta disponibilidad restringida con un prefijo mínimo de /27 para la subred del nodo de control y /27 para la subred del nodo de trabajo. No use este ajuste de tamaño restringido como punto de partida para una implementación de producción de ARO. No etiquete la red virtual ni las subredes de nodo. Readdressing an OpenShift deployment after installation is disrupt and might require redeployment.

Si desea usar una interfaz de red de contenedor diferente (CNI), dimensione las redes en consecuencia. MAS con algunas aplicaciones estándar implementa más de 800 pods, lo que probablemente requiera un prefijo CIDR de /21 o mayor.

Detalles de la base de datos

Algunos componentes de MAS usan MongoDB como almacén de metadatos. La guía predeterminada es implementar MongoDB Community Edition dentro del clúster. Si usa ese método, asegúrese de que tiene un procedimiento adecuado para realizar copias de seguridad y restaurar la base de datos. Considere la posibilidad de usar MongoDB Atlas en Azure para proporcionar un almacén externo, copias de seguridad y escalado. Azure no admite actualmente el uso de api de MongoDB con Azure Cosmos DB.

Si implementa servicios de IoT, también debe proporcionar un punto de conexión de Kafka. La guía predeterminada es usar Strimzi para implementar Kafka dentro del clúster de OpenShift, pero es probable que se pierdan datos dentro de Strimzi durante la recuperación ante desastres. Si la pérdida de datos en Kafka es inaceptable, considere la posibilidad de usar Confluent Kafka en Azure. Actualmente, Azure Event Hubs no se admiten con puntos de conexión de Kafka.

MAS incluye varias bases de datos en sus pods y esas bases de datos conservan sus estados en el sistema de archivos proporcionado para MAS. Para absorber errores de zona, use un mecanismo de almacenamiento con redundancia de zona (ZRS) para conservar los estados fuera de los clústeres. El patrón recomendado es usar Azure File Storage con las siguientes configuraciones:

• Standard proporciona recursos compartidos SMB para cargas de trabajo readWriteOnce (RWO) de menor rendimiento. Use Standard para partes de la aplicación que no escriben en el almacenamiento a menudo y requieran un único volumen persistente, como el almacenamiento de un solo nivel de IBM.

• Premium proporciona recursos compartidos NFS para cargas de trabajo readWriteMany (RWX) de mayor rendimiento. Los volúmenes como estos se usan en todo el clúster para cargas de trabajo RWX, como Db2 Warehouse in Cloud Pak for Data o Postgres en Maximo Manage.

Azure Files NFS admite el cifrado en tránsito. Si el cliente de MAS OpenShift no puede usar el cifrado NFS, puede excluir la cuenta de las directivas de cumplimiento de transferencia segura. Para obtener más información, consulte NFS Azure recursos compartidos de archivos: Cifrado. Use un punto de conexión privado para proporcionar conectividad privada a los recursos compartidos.

Si implementa Db2 Warehouse a través de Cloud Pak for Data, use OpenShift Data Foundation. Para ver un ejemplo de OpenShift Data Foundation que usa ceph File System (CephFS) y clases de almacenamiento de dispositivo de bloqueo RADOS (Ceph RBD) para diferentes tipos de datos de db2 Warehouse, consulte Creación de la instancia de Db2 mediante la consola de Cloud Pak for Data.

No use Azure Blob Storage con controladores de interfaz de almacenamiento de contenedores (CSI), ya que no admite vínculos duros, que algunos pods requieren para ejecutarse.

Consideraciones

Estas consideraciones implementan los pilares del marco de Azure Well-Architected, que es un conjunto de principios rectores que puede usar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Microsoft Azure Well-Architected Framework.

Confiabilidad

OpenShift tiene funcionalidades integradas para la recuperación automática, el escalado y la resistencia. OpenShift y MAS esperan que los componentes produzcan errores y se recuperen. Un requisito clave para la recuperación automática es que el clúster tiene suficientes nodos de trabajo. Para recuperarse de un error de zona dentro de una región de Azure, los nodos de control y los nodos de trabajo deben equilibrarse entre zonas de disponibilidad.

MAS y OpenShift usan almacenamiento para conservar el estado fuera del clúster de Kubernetes. Para asegurarse que las dependencias de almacenamiento sigan funcionando durante un error, utilice el almacenamiento con redundancia de zona siempre que sea posible. El almacenamiento con redundancia de zona permanece disponible cuando se produce un error en una sola zona.

Para ayudar a evitar errores humanos, implemente MAS mediante la mayor automatización posible. Use la documentación de instalación de IBM actual y la automatización admitida para la versión de MAS seleccionada, la plataforma OpenShift y la ruta de implementación.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el uso indebido de sus valiosos datos y sistemas. Para obtener más información, vea Lista de comprobación para la revisión de diseño de seguridad.

Mantener el acceso y la visibilidad en el ciclo de vida de mantenimiento de los recursos puede ser una de las mayores oportunidades de su organización para operar de forma eficaz y mantener el tiempo de actividad. Para mejorar la posición de seguridad de su entorno, es importante usar la autenticación segura y mantener actualizadas las soluciones. Use el cifrado para ayudar a proteger todos los datos que se mueven dentro y fuera de la arquitectura.

Mediante el uso de implementaciones de ARO, se beneficia del modelo de responsabilidad compartida de ARO. Red Hat OpenShift en Azure está diseñado conjuntamente, operado y compatible con Microsoft y Red Hat, que revisan, actualizan y supervisan la plataforma administrada de OpenShift en su nombre. Sigue siendo responsable de las implementaciones sobre ARO. Esta responsabilidad incluye MAS y su configuración de aplicaciones, integración de identidades, controles de red, planeamiento de la capacidad de trabajo, opciones de almacenamiento, copia de seguridad y recuperación ante desastres, secretos, protección de datos y requisitos de cumplimiento. Para obtener más información, consulte Introducción a la directiva de soporte técnico de Red Hat OpenShift en Azure y Red Hat OpenShift en Azure 4.0.

Microsoft crea protecciones de seguridad en la plataforma Azure en los siguientes niveles:

• Centro de datos físico
• Red física
• Host físico
• Hipervisor

Use una versión de OpenShift compatible con la plataforma de OpenShift y que IBM admita para su versión y aplicaciones mas. Cuando sea posible, use una versión de soporte técnico a largo plazo compatible. Si usa OpenShift autoadministrado, es responsable de aplicar revisiones y mantener la plataforma OpenShift y las máquinas virtuales subyacentes. Si usa ARO, Microsoft controla la aplicación de revisiones y la administración.

Utilice grupos de seguridad de red para filtrar el tráfico de red hacia y desde los recursos en la red virtual. Mediante el uso de estos grupos, puede definir reglas que concedan o denieguen el acceso a los servicios mas, como:

• Permitir el acceso SSH a los nodos de OpenShift para solucionar problemas.
• Bloquear el acceso a todas las demás partes del clúster.
• Controlar qué ubicaciones pueden acceder a MAS y al clúster de OpenShift.

Para acceder a las máquinas virtuales, puede conectarse a través de la conectividad híbrida o a través de la consola de administración de OpenShift. Si tiene una implementación en línea o no quiere confiar en la conectividad híbrida, puede acceder a las máquinas virtuales a través de Azure Bastion. Por motivos de seguridad, no exponga máquinas virtuales a una red ni a Internet sin configurar grupos de seguridad de red para controlar el acceso.

El cifrado del lado servidor (SSE) de Azure Disk Storage protege los datos y le ayuda a cumplir los compromisos de seguridad y cumplimiento de la organización. Con Azure discos administrados, SSE cifra los datos en reposo al conservarlos en la nube. Este comportamiento se aplica de forma predeterminada a los discos de datos y del sistema operativo. OpenShift usa SSE de forma predeterminada.

Autenticación

MAS admite SSO con lenguaje de marcado de aserción de seguridad (SAML). Para usar Microsoft Entra ID como proveedor de identidades de SAML, cree una aplicación empresarial en Microsoft Entra ID y configure MAS como proveedor de servicios. Para obtener más información, consulte la integración de SSO de Microsoft Entra con Maximo Application Suite.

Antes de configurar la autenticación basada en SAML, revise la configuración de IBM y la configuración de Azure. Para obtener información sobre SAML con MAS, consulte Configuración de la autenticación SAML. Para obtener información sobre SAML con Azure, consulte Quickstart: Habilitación del inicio de sesión único para una aplicación empresarial.

También debe configurar OAuth para el acceso administrativo de OpenShift. Para ARO, consulte Configuración de la autenticación de Microsoft Entra para un clúster de Red Hat OpenShift en Azure. Para OpenShift autoadministrado, consulte Configuración de proveedores de identidades en OpenShift Container Platform 4.21.

Acceso y auditoría de recursos

Controle el acceso a los recursos de Azure que implemente. Cada suscripción de Azure tiene una relación de confianza con una entidad de Microsoft Entra. Use el control de acceso basado en rol de Azure (Azure RBAC) para otorgar a los usuarios de la organización los permisos correctos para los recursos de Azure. Conceda acceso mediante la asignación de roles de Azure a usuarios o grupos en un ámbito determinado, como una suscripción, un grupo de recursos o un único recurso. Audite todos los cambios en la infraestructura. Para obtener más información sobre la auditoría, consulte Azure Monitor registro de actividad.

Optimización de costos

La optimización de costos se centra en formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costes.

Una implementación mas estándar en Azure incluye los siguientes controladores de costos principales:

• Costos de clúster de ARO, incluidos los nodos de trabajo y los cargos facturables del plano de control o del clúster
• Grupos de nodos de trabajo de tamaño para MAS Core y las aplicaciones mas que se implementan
• Nodos de trabajo de GPU opcionales para Maximo Visual Inspection
• Servicios de base de datos, como SQL Managed Instance, Db2 Warehouse u otra base de datos compatible con IBM
• Cuentas de almacenamiento o servicios de almacenamiento administrados para volúmenes persistentes, copias de seguridad e artefactos de instalación
• Zonas DNS, equilibrio de carga, puntos de conexión privados y una instancia opcional de Azure Bastion

En el caso de ARO y OpenShift autoadministrado, una implementación mas estándar normalmente usa la misma línea base de ajuste de tamaño de nodo de trabajo. Use el siguiente inventario como punto de partida para la estimación de costos:

• Seis máquinas virtuales de trabajo.
• Tres máquinas virtuales de trabajo para Db2 Warehouse. Puede sustituir SQL Managed Instance en algunas configuraciones en lugar de usar Db2 Warehouse.
• Dos cuentas de Azure Storage.
• Dos zonas DNS.
• Dos equilibradores de carga.
• Azure Bastion.
• Un nodo de trabajo de GPU maximo Visual Inspection, si tiene previsto ejecutar Maximo Visual Inspection dentro de MAS.

El costo del plano de control difiere según el modelo de implementación. En el caso de las implementaciones de OpenShift autoadministradas que usan IPI o UPI, también incluyen tres máquinas virtuales de control. Para ARO, tenga en cuenta el plano de control administrado y los cargos de clúster específicos de ARO en lugar de agregar máquinas virtuales de control administradas por el cliente.

Puede revisar una estimación de ejemplo mediante la calculadora de costos. Las configuraciones varían, por lo que debe comprobar la configuración con el equipo de ajuste de tamaño de IBM antes de finalizar la implementación.

Implementación de este escenario

Antes de empezar, revise los requisitos del sistema de IBM Maximo Application Suite y IBM SPCR para la versión y las aplicaciones de MAS. Tenga los siguientes recursos disponibles antes de iniciar la implementación:

• Acceso a una suscripción de Azure con permiso lector
• Un registro de aplicación o un nombre de entidad de seguridad de servicio que tenga permisos de colaborador y administrador de acceso de usuario a la suscripción.
• Un subdominio delegado o un dominio en una zona de Azure DNS
• Un clúster de ARO compatible o los permisos y requisitos previos para crear uno
• Un secreto de extracción de Red Hat si la ruta de implementación crea o administra la infraestructura de OpenShift.
• Una clave de derecho MAS
• Un archivo de licencia de MAS que cree después de la instalación de MAS
• Dimensionamiento del clúster recomendado por IBM
• Una red virtual existente o una nueva red virtual que cumpla los requisitos de ARO y MAS
• Requisitos de alta disponibilidad y recuperación ante desastres para la implementación específica
• Detalles de configuración de la ruta de acceso de implementación seleccionada, como detalles del clúster de ARO o parámetros de instalación de OpenShift autoadministrados

Antes de compilar el entorno, revise la documentación de IBM Planning para instalar en Microsoft Azure para comprender los parámetros de diseño. Para obtener instrucciones actuales de instalación de Azure, consulte Maximo Application Suite on Microsoft Azure overview (Introducción a Maximo Application Suite en Microsoft Azure). Valide el proceso de implementación con la documentación actual de IBM y la matriz de compatibilidad para la versión de MAS.

Consideraciones de la implementación

Implemente cargas de trabajo mediante la infraestructura como código (IaC) en lugar de manualmente. La implementación manual puede dar lugar a una configuración incorrecta. Las cargas de trabajo basadas en contenedores suelen ser sensibles a los errores de configuración, lo que puede reducir la productividad.

IBM ofrece servicios especializados para ayudarle con la instalación. Póngase en contacto con su equipo de IBM para obtener soporte técnico.

Colaboradores

Microsoft mantiene este artículo. Los siguientes colaboradores escribieron este artículo.

Autores principales:

• David Baumgarten | Arquitecto jefe
• Roeland Nieuwenhuis | Arquitecto jefe

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Si desea obtener ayuda para comenzar, consulte los recursos siguientes:

• Red Hat OpenShift en Azure
• Introducción a Maximo Application Suite en Microsoft Azure
• Planeación de la instalación en Microsoft Azure
• Instalar OpenShift en Azure
• Guía de UPI de OpenShift
• Requisitos para Maximo
• Informes de compatibilidad de productos de software de IBM
• IBM Maximo Application Suite (BYOL)

Para más información sobre las tecnologías destacadas, consulte los siguientes recursos:

• IBM Passport Advantage
• Introducción a Azure DNS
• Introducción a Azure NetApp Files
• Introducción a Red Hat OpenShift en Azure
• Portal del cliente de Red Hat

Recursos relacionados

• Azure compartición de archivos empresariales en la nube
• Despliegue una aplicación Java con la plataforma de aplicaciones empresariales JBoss (EAP) en un clúster ARO