Implementación de IBM Maximo Application Suite en Azure

IBM Maximo Application Suite (MAS) 8.x y las ejecuciones en OpenShift, y es beneficioso familiarizarse con OpenShift y los patrones sugeridos para la instalación en Azure. Para más información, consulte Preparación de la instalación en Azure. Esta arquitectura ilustra un clúster de OpenShift. No se detalla cómo instalar MAS. Para obtener más información sobre el proceso de instalación, consulte Instalación de Maximo Application Suite.

Architecture

Descargue un archivo Visio de esta arquitectura.

La carga de trabajo se puede implementar interna o externamente, en función de sus requisitos.

Flujo de trabajo

Desde la perspectiva de la infraestructura, esta arquitectura proporciona lo siguiente:

• Una plataforma de hospedaje de contenedores para implementar cargas de trabajo de alta disponibilidad en zonas de disponibilidad
• Implementación privada de nodos de trabajo y control que se integran con el almacenamiento
• Azure Files premium y archivos estándar para el almacenamiento (no se requiere OpenShift Data Foundation)
• SQL Server en máquinas virtuales de Azure o ibm Db2 Warehouse basada en contenedores
• Azure DNS para la administración de DNS de OpenShift y sus contenedores
• Microsoft Entra ID para el inicio de sesión único (SSO) en MAS

Componentes

• Azure Virtual Machines para hospedar la plataforma OpenShift y ejecutar los contenedores Maximo. Las máquinas virtuales son una oferta de Infraestructura como servicio (IaaS). Puede usar máquinas virtuales para implementar recursos informáticos escalables a petición.

• Red Hat Enterprise Linux CoreOS para proporcionar una imagen de máquina virtual personalizada para OpenShift.

• Azure Load Balancer para proporcionar conectividad al clúster. Azure Load Balancer proporciona un servicio de equilibrio de carga de capa 4 con latencia muy baja y alto rendimiento (entrante y saliente) para todos los protocolos UDP y TCP. Se diseñó para administrar millones de solicitudes por segundo, a la vez que garantiza que la solución tiene una alta disponibilidad. Azure Load Balancer tiene redundancia de zona, lo que garantiza una alta disponibilidad en las instancias de Availability Zones.

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

• Azure Files hospeda los datos de estado de las bases de datos y los sistemas dentro del clúster. Azure Files proporciona recursos compartidos de archivos completamente administrados en la nube que son accesibles a través de los protocolos SMB y Network File System (NFS)

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

• Azure Bastion (opcional) y una subred para acceder de forma segura a cualquiera de los nodos de trabajo o a las máquinas JumpBox opcionales. Azure Bastion es un servicio totalmente administrado que proporciona acceso RDP y SSH con seguridad mejorada y sin problemas a las máquinas virtuales sin ninguna exposición mediante direcciones IP públicas.

• SQL Server en Azure Virtual Machines (opcional) para proporcionar servicios de datos a MAS. La base de datos también puede ser otra, como Oracle Exadata o IBM Db2 Warehouse. Azure SQL Base de datos y Azure SQL Managed Instance no se admiten ahora mismo.

• Twilio Send Grid (opcional) para enviar correos electrónicos desde MAS a los consumidores.

• Máquinas virtuales Linux en Azure (opcional) para proporcionar una caja de salto para la instalación de OpenShift. También puede usar esta máquina virtual para conectarse y administrar el clúster de OpenShift porque contiene el archivo de configuración de Kubernetes después de la instalación. Si tiene conectividad de red en el entorno de Azure, puede realizar la instalación desde una máquina existente.

Alternativas

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

• Azure NetApp Files como reemplazo de Azure Files. Azure NetApp Files admite cualquier tipo de carga de trabajo con alta disponibilidad y alto rendimiento.
• Oracle Database en Azure si prefiere que SQL Server o Db2 Warehouse.
• OpenShift Data Foundation si desea usar Db2 Warehouse en OpenShift Data Foundation.

Detalles del escenario

Maximo Application Suite (MAS) de IBM, también conocido como Maximo, 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 de aplicaciones consta de una plataforma de aplicaciones principal, MAS y aplicaciones y soluciones específicas del sector sobre la plataforma. Cada aplicación proporciona una ventaja específica:

• Administración. Reduce el tiempo de interoperabilidad y los costos mediante la administración de recursos para mejorar el rendimiento operativo.
• Supervisión. Use IoT para la supervisión avanzada con tecnología de inteligencia artificial de recursos remotos a escala.
• Estado. Administre el estado de los recursos mediante el uso de datos de IoT de sensores, datos de recursos e historial de mantenimiento.
• Inspección visual. Entrene modelos de Modelo de Machine Learning para usar la inspección visual para el análisis visual de problemas emergentes.
• Predict. Predice errores futuros mediante el aprendizaje automático y el análisis de datos.
• Assist. Ayude a los técnicos con una guía impulsada por la IA a una base de conocimientos de datos de mantenimiento de equipos y dándoles acceso remoto a los expertos.
• Safety. Recopile y analice datos de sensores, proporcione datos contextuales y derive análisis significativos.
• Civil. Integre las actividades de inspección, seguimiento de defectos y mantenimiento para ayudar a mejorar la vida útil de los activos, mantener los sistemas críticos operativos y reducir los costos totales de propiedad de la infraestructura civil.

Estas aplicaciones y MAS 8.x y versiones posteriores se prueban para su uso en Azure. Microsoft y el equipo de IBM Maximo se asociaron para asegurarse de que esta solución está configurada para ejecutarse de forma óptima en Azure. En este artículo se proporciona un diseño para ejecutar MAS 8.x y versiones posteriores de Azure para los clientes que tienen soporte técnico de IBM y un asociado para su instalación. Póngase en contacto con su equipo de IBM para obtener preguntas específicas del producto. Azure Marketplace ofrece una instalación alternativa 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)). En esta guía se detalla cómo instalar Maximo manualmente.

Posibles casos de uso

Muchas industrias y sectores utilizan las soluciones de MAS, como:

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

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

Recomendaciones

Se recomienda instalar la versión estable más reciente de MAS porque proporciona las mejores opciones de integración con Azure. Preste mucha atención a las versiones de OpenShift que son compatibles, porque estas varían según la versión específica de MAS.

El uso de versiones principales anteriores o posteriores de OpenShift puede dar lugar a la caída del soporte técnico oficial para MAS. Antes de crear su propia implementación, se recomienda leer exhaustivamente la instalación en Azure y planeación de la documentación de Azure para comprender cómo funciona la implementación y la configuración. Conocer los detalles de instalación acelera la creación de los requisitos de diseño para la implementación.

Microsoft trabaja con IBM y otros asociados para asegurarse de que la documentación, la arquitectura y las instrucciones proporcionan la mejor experiencia en Azure. 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 soporte técnico más allá de esta documentación.

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

• ¿Qué aplicaciones mas necesita?
• ¿Qué dependencias tienen las aplicaciones?
• ¿Qué versión de OpenShift se necesita?
• ¿Qué método de instalación de OpenShift debe usar?
• ¿Qué bases de datos son necesarias?
• ¿Qué número y tamaños de máquinas virtuales necesita?
• ¿Se conectarán los usuarios desde redes externas?

Maximo Application Suite

Microsoft ha probado las versiones 8.7 y posteriores de MAS en Azure. Nuestra recomendación es usar la versión más reciente de MAS, que actualmente es la versión 9.0. Si está en versiones anteriores de Maximo Application Suite, se recomienda actualizar para beneficiarse de una mejor integración con Azure.

Revise las aplicaciones mas que necesita para su escenario empresarial completo y revise los requisitos de cada una de las aplicaciones. Para obtener más información, consulte Requisitos del sistema IBM Maximo Application Suite. Cada una de las aplicaciones puede necesitar bases de datos independientes. Hemos probado y admitido las siguientes bases de datos en Azure:

• SQL Server en máquinas virtuales de Azure versión 2019 con Windows o Linux
• IBM Db2 Warehouse on Cloud Pak for Data 5

También puede optar por ejecutar Oracle Exadata en una máquina virtual o en Oracle Cloud Infrastructure mediante la interconexión, pero esto no es una configuración probada. Para más información sobre la interconexión, consulte Interconexión de Oracle Cloud con Microsoft Azure. Actualmente, Azure SQL Database, Azure SQL Managed Instance y Azure Cosmos DB no son compatibles.

MAS y algunas de sus aplicaciones tienen dependencias en MongoDB y Kafka. Decida cómo implementar estas soluciones en función de las consideraciones de rendimiento y operaciones. Los valores predeterminados son implementar MongoDB Community Edition y Strimzi Kafka dentro de los clústeres. Algunos de los requisitos previos de MAS, por ejemplo BAS, usan bases de datos que no se pueden externalizar, pero que 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, es necesario realizar copias de seguridad de datos con frecuencia y mover las copias de seguridad a otra región. Diseñe y planee una estrategia de recuperación en caso de desastre y decida en consecuencia, especialmente al ejecutar Kafka o MongoDB dentro de OpenShift.

En el caso de los servicios que conservan el estado, use las ofertas externas de la plataforma como servicio (PaaS) de Azure cuando sea posible. Esto mejora la compatibilidad durante una interrupción.

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

OpenShift

Antes de instalar OpenShift, debe determinar qué método va a usar:

• Infraestructura aprovisionada (IPI) del instalador. Este método usa un instalador para implementar y configurar el entorno de OpenShift en Azure. IPI es el método más común para la implementación en Azure y debe usar IPI a menos que los requisitos de seguridad sean demasiado estrictos para hacerlo.

• 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 no satisface sus necesidades. Un caso de uso común para la UPI es el de una instalación privada, aislada. Elija UPI cuando no tenga acceso saliente a Internet al compilar el entorno.

Se recomienda usar IPI siempre que sea posible, ya que reduce significativamente la cantidad de trabajo necesario para completar la instalación de OpenShift.

Al instalar OpenShift, debe resolver las consideraciones siguientes:

• Selección de región. Se recomienda usar una región con zonas de disponibilidad. Durante la implementación, OpenShift intenta crear automáticamente nodos entre zonas en función de la configuración del archivo de configuración, install-config.yaml. De forma predeterminada, OpenShift equilibra las cargas de trabajo en todos los nodos disponibles y en las zonas de disponibilidad. Si hay una interrupción en una zona, la solución puede seguir funcionando gracias a los nodos en otras zonas que puedan asumir el trabajo.

• Copia de seguridad y recuperación. Puede usar las instrucciones para Red Hat OpenShift en Azure para realizar copias de seguridad y recuperación. Para más información, consulte Creación de una copia de seguridad de aplicaciones del clúster de Red Hat OpenShift en Azure 4. 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 ellos e Internet para redirigir el tráfico al clúster adecuado cuando se produzca una interrupción de una región. En esta situación, también debe migrar los estados de las aplicaciones y los volúmenes persistentes.

Instalaciones aisladas

En algunos casos, como por ejemplo para el cumplimiento de la normativa, es posible que se requiera una instalación aislada de MAS en Azure. Aislada significa que no hay acceso a Internet ni de entrada ni de salida. Sin conexión a Internet, la instalación no puede recuperar las dependencias de instalación en tiempo de ejecución para la instalación de MAS o OpenShift.

No se recomienda realizar una instalación con disponibilidad aislada a menos que sea un requisito de seguridad. Un aislamiento agrega una complejidad significativa a las operaciones de la solución. Las actividades como la instalación de software, la creación de reflejo de contenedores, la actualización de un reflejo para protegerse frente a vulnerabilidades de seguridad y la administración de un firewall pueden llevar mucho tiempo.

Para obtener más información sobre las instalaciones con aislamiento, consulte la siguiente documentación de OpenShift:

• Creación de reflejo de imágenes para una instalación desconectada
• Instalación de un clúster privado en Azure

Después de instalar OpenShift, consulte la documentación de MAS para obtener instrucciones similares.

Dimensionamiento del tamaño del entorno

Para todas las cargas de trabajo (excepto la inspección visual), se recomienda usar las máquinas virtuales de la serie Ds más recientes como nodos de trabajo. Algunos ejemplos son Dsv3, Dasv4, Dsv4, Dasv5 o Dsv5. Se recomienda usar las versiones más recientes, siempre que sea posible, ya que proporcionan un mejor rendimiento. Use solo máquinas virtuales que tengan almacenamiento premium.

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. Los tipos recomendados de máquinas virtuales son NCv3 y NCasT4_v3. Si necesita entrenar mediante YOLOv3, necesitará GPU basadas en Ampere. Use NVadsA10 v5 o NC A100 v4 para tareas de entrenamiento más grandes.

En el caso de las máquinas GPU, se recomienda comenzar con el nodo más pequeño y escalar verticalmente a medida que aumentan los requisitos.

Para todas las demás máquinas, se recomienda configurar máquinas virtuales entre zonas de disponibilidad para admitir la alta disponibilidad. Configure los nodos de la siguiente manera:

• Nodos de control. Un mínimo de una máquina virtual por zona de disponibilidad dentro de la región seleccionada. Se recomienda un recuento de vCPU de al menos 4. Nuestra referencia utiliza 3 nodos Standard_D8s_v4.

• Nodos de trabajo. Un mínimo de dos máquinas por zona de disponibilidad dentro de la región seleccionada. Se recomienda un número de vCPU de al menos 8. Nuestra referencia utiliza 6 nodos Standard_D8s_v4.

El núcleo MAS requiere 13 vCPU para una instalación base de tamaño estándar. El dimensionamiento de tamaño de los nodos de trabajo varía en función de las aplicaciones mas que implementa la configuración y la carga en el entorno. Por ejemplo, Administrar para 10 usuarios requiere otras 2 vCPU. Se recomienda revisar los requisitos del sistema IBM Maximo Application Suite para obtener una buena estimación del tamaño.

Intente mantener los tipos de máquinas virtuales similares entre sí para proporcionar proximidad con cada una de las zonas de disponibilidad entre los nodos de trabajo y de control. Es decir, si usa una máquina virtual v4 para los nodos de control, use también una máquina virtual v4 para los nodos de trabajo.

Si necesita un jump box para usar la interfaz de línea de comandos (oc) de OpenShift o para instalar MAS, implemente una VM que ejecute Red Hat Enterprise Linux versión 8.4.

Red

Con OpenShift, usamos el proveedor predeterminado de interfaz de red de contenedor (CNI) de las redes definidas por software (SDN) de OpenShift. Para obtener más información sobre el CNI de OpenShift predeterminado, consulte Descripción de las redes en OpenShift Container Platform. Debe ajustar el tamaño de la red para el número de nodos de trabajo y control de OpenShift que necesite, así como para cualquier otro requisito, como bases de datos y cuentas de almacenamiento.

Para una instalación de producción de MAS estándar, se recomienda una red virtual con el espacio de direcciones que proporciona un prefijo de enrutamiento entre dominios sin clase (CIDR) de /24. La red virtual tiene tres o cuatro subredes (para Azure Bastion). En el caso de OpenShift, la subred de los nodos trabajadores tiene un prefijo CIDR de /25, y los nodos de control tienen un prefijo de /27 Una subred para puntos de conexión y un servidor de base de datos externo opcional debe tener un prefijo de /27. Si va a implementar Azure Bastion, que es opcional, necesita una subred denominada AzureBastionSubnet con un prefijo de /26. Para más información sobre los requisitos de Azure Bastion, consulte Arquitectura.

Si tiene pocas direcciones IP, puede implementar una configuración de alta disponibilidad con un prefijo mínimo de /27 para la subred de nodos de control y /27 para la subred de nodos de trabajo.

Si desea usar una CNI diferente, cambie el tamaño de 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

Varios componentes de MAS usan MongoDB como almacén de metadatos. La guía predeterminada es implementar MongoDB Community Edition dentro del clúster. Si la implementa mediante 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, ya que proporciona un almacén externo, copias de seguridad, escalado, etc. Azure no admite actualmente el uso de las 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. Durante una recuperación ante desastres, es probable que se pierdan datos dentro de Strimzi. Si la pérdida de datos dentro de Kafka es inaceptable, debe considerar la posibilidad de usar Confluent Kafka en Azure. Actualmente, Azure Event Hubs con puntos de conexión Kafka no se admiten.

MAS viene empaquetado con muchas bases de datos dentro de sus pods, y esas bases de datos conservan sus estados en el sistema de archivos que se proporciona para MAS. Se recomienda usar un mecanismo de almacenamiento con redundancia de zona (ZRS) para conservar los estados fuera de los clústeres para poder absorber errores de zona. Nuestro patrón recomendado es usar Azure File Storage con las siguientes configuraciones:

• Estándar. Proporciona recursos compartidos de bloque de mensajes de servidor (SMB) para reducir el rendimiento y las cargas de trabajo ReadWriteOnce (RWO). Standard es una excelente opción para partes de la aplicación que no escriben en el almacenamiento a menudo y requieren un único volumen persistente (por ejemplo, almacenamiento de un solo nivel de IBM).

• Premium. Proporciona recursos compartidos del sistema de archivos de red (NFS) para un mayor rendimiento y cargas de trabajo ReadWriteMany (RWX). Los volúmenes como estos se usan en todo el clúster para las cargas de trabajo RWX, como el Db2 Warehouse en Cloud Pak for Data o Postgres en administración.

Asegúrese de deshabilitar las directivas para aplicar la transferencia segura en el Azure Blob Storage o excluir las cuentas de dichas directivas. Azure Premium Files con NFS requiere que se deshabilite la transferencia segura. Asegúrese de usar un punto de conexión privado para garantizar la conectividad privada con los recursos compartidos.

De manera predeterminada, Db2 Warehouse se implementa sobre OpenShift Data Foundation (anteriormente conocido como OpenShift Container Storage). Por motivos de costo, rendimiento, escalado y confiabilidad, se recomienda usar Azure Premium Files con NFS en lugar de OpenShift Data Foundation.

No use Azure Blob Storage con controladores CSI, ya que no admite vínculos duros, que son necesarios. Algunos pods no pueden funcionar sin enlaces duros.

Consideraciones

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

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar 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.

Azure ofrece MAS mediante los modelos de infraestructura como servicio (IaaS) y PaaS. Microsoft crea protecciones de seguridad en el servicio en los niveles siguientes:

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

Evalúe cuidadosamente los servicios y las tecnologías que seleccione para las áreas anteriores al hipervisor, como la versión revisada más reciente de OpenShift para una versión principal. Asegúrese de proporcionar los controles de seguridad adecuados para la arquitectura. Es responsable de aplicar revisiones y mantener la seguridad de los sistemas IaaS. Microsoft asume ese rol para los servicios PaaS.

Utilice grupos de seguridad de red para filtrar el tráfico de red hacia y desde los recursos en la red virtual. Con estos grupos, puede definir reglas que concedan o denieguen el acceso a los servicios de MAS. Algunos ejemplos son:

• 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 tener acceso a MAS y al clúster de OpenShift

Si necesita acceso a las máquinas virtuales por algún motivo, 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, también puede acceder a las máquinas virtuales a través de Azure Bastion (opcional). Por motivos de seguridad, no debe exponer máquinas virtuales a una red o a Internet sin configurar grupos de seguridad de red para controlar el acceso a ellas.

El cifrado del lado servidor (SSE) de Azure Disk Storage protege los datos. También le ayuda a satisfacer los compromisos de seguridad y cumplimiento de la organización. Con discos administrados de Azure, 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

Actualmente, MAS admite el inicio de sesión único (SSO) con el Lenguaje de Marcado para Confirmaciones de Seguridad (SAML) en Microsoft Entra ID. Este método de autenticación requiere una aplicación empresarial dentro de Microsoft Entra ID y permisos para modificar la aplicación. Para obtener más información, consulte Integración de SSO de Microsoft Entra con Maximo Application Suite.

Antes de configurar la autenticación basada en SAML, se recomienda pasar por la configuración de IBM y la configuración de Azure. Para obtener información sobre SAML con MAS, consulte SAML en la documentación de MAS. Para obtener información sobre SAML con Azure, consulte Inicio rápido: Habilitación del inicio de sesión único para una aplicación empresarial.

También debe configurar Open Authorization (OAuth) para OpenShift. Para obtener más información, consulte Introducción a la autenticación y autorización en la documentación de OpenShift.

Protección de la infraestructura

Controle el acceso a los recursos de Azure que implemente. Cada suscripción de Azure tiene una relación de confianza con un inquilino de Microsoft Entra. Use el control de acceso basado en roles (RBAC) de Azure para conceder a los usuarios de la organización los permisos adecuados en los recursos de Azure. Para conceder el acceso, asigne los roles de Azure a usuarios o grupos en un ámbito determinado. El ámbito puede ser una suscripción, un grupo de recursos o incluso un solo recurso. Asegúrese de auditar todos los cambios en la infraestructura. Para más información sobre la auditoría, consulte Registro de actividad de Azure Monitor.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

Una implementación estándar de MAS consta de los siguientes componentes:

• 3 máquinas virtuales de control
• 6 máquinas virtuales de trabajo
• 3 máquinas virtuales de trabajo para Db2 Warehouse
  • En algunas configuraciones se puede sustituir SQL Server en las VM de Azure, en lugar de utilizar Db2 Warehouse.
• 2 cuentas de Azure Storage
• 2 zonas DNS
• 2 equilibradores de carga
• Azure Bastion
• 1 máquina virtual de inspección visual
  • Esto no es necesario a menos que tenga previsto ejecutar la inspección visual dentro de MAS.

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

Confiabilidad

OpenShift tiene funcionalidades integradas para la recuperación automática, el escalado y la resistencia para asegurarse de que OpenShift y MAS funcionan correctamente. OpenShift y MAS han sido diseñados para elementos que producen errores y se recuperan. Un requisito clave para que la recuperación automática funcione es que hay suficientes nodos de trabajo. Para recuperarse de un error de zona dentro de una región de Azure, los nodos de control y de trabajo deben equilibrarse entre zonas de disponibilidad.

MAS y OpenShift usan almacenamiento para conservar el estado fuera del clúster de Kubernetes. Para asegurar que las dependencias de almacenamiento sigan funcionando durante un error, debe usar el almacenamiento con redundancia por zonas siempre que sea posible. Este tipo de almacenamiento permanece disponible cuando se produce un error en una zona.

Dado que el error humano es común, debe implementar MAS con la mayor automatización posible. En nuestra guía de inicio rápido, se proporcionan algunos scripts de ejemplo para configurar la automatización completa de un extremo a otro.

Implementación de este escenario

Antes de empezar, le recomendamos que revise los requisitos del sistema IBM Maximo Application Suite. Asegúrese de que tiene los siguientes recursos disponibles antes de iniciar la implementación:

• Acceso a una suscripción de Azure con permiso delector
• Registro de la aplicación o nombre de entidad de seguridad de servicio que tiene permisos de Colaborador y Administrador de acceso de usuario a la suscripción
• Dominio o subdominio delegado en una zona DNS de Azure
• Extraer el secreto de Red Hat para implementar OpenShift
• Clave de derecho MAS
• Archivo de licencia de MAS (creado después de la instalación de MAS)
• Dimensionamiento del clúster recomendado por IBM
• Red virtual existente o una red virtual nueva creada por IPI, según sus requisitos
• Requisitos de alta disponibilidad y recuperación ante desastres para la implementación específica
• Archivo de configuración, install-config.yaml, para el instalador

Para obtener una guía paso a paso para instalar OpenShift y MAS en Azure, incluido cómo abordar los requisitos previos, consulte nuestra guía de inicio rápido en GitHub.

Consideraciones de la implementación

Es mejor implementar las cargas de trabajo mediante el uso de la infraestructura como código (IaC) en lugar de implementar manualmente las cargas de trabajo, ya que 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.

Antes de compilar el entorno, revise la documentación de planeación de Azure proporcionada por IBM para desarrollar una comprensión de los parámetros de diseño. La guía de inicio rápido no está pensada para una implementación lista para producción, pero puede usar los recursos de la guía para llegar a un mecanismo de nivel de producción para la implementación.

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. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

• David Baumgarten | Arquitecto sénior de soluciones en la nube
• Roeland Nieuwenhuis | Arquitecto principal de soluciones en la nube

Otro colaborador:

• Gary Moore | Programador/escritor

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

Pasos siguientes

Si desea ayuda para empezar, consulte los siguientes recursos:

• Instalación de OpenShift en Azure
• Guía de inicio rápido: Maximo Application Suite en Azure
• Guía de UPI de OpenShift
• Requisitos para Maximo
• 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 en Azure
• Portal del cliente de Red Hat

Recursos relacionados

• Recurso compartido de archivos de la nube empresarial de Azure
• Implementación de una aplicación Java con JBoss Enterprise Application Platform (EAP) en un clúster de ARO