Implementar a Suite de Aplicações IBM Maximo no Azure

Este artigo descreve a implementação do IBM Maximo Application Suite (MAS) no Azure. O MAS funciona com Red Hat OpenShift. Azure Red Hat OpenShift (ARO) é a plataforma OpenShift preferida se satisfazer os seus requisitos operacionais, de segurança e de rede. Use o Red Hat OpenShift autogerido no Azure apenas quando precisar de controlo que o ARO não oferece, como padrões de implementação desconectados específicos ou personalização ao nível do cluster.

Este artigo não entra em detalhes sobre como instalar MAS. Para mais informações sobre instalação, consulte Instalação do Maximo Application Suite.

Arquitetura

O diagrama seguinte ilustra uma implementação MAS baseada em ARO no Azure.

Descarregue um ficheiro Visio desta arquitetura.

Pode implementar a carga de trabalho como uma implementação interna ou externa, dependendo das suas necessidades. Este artigo não prescreve um modelo de implementação ARO público ou privado. Escolha o plano de controlo, a arquitetura de entrada e saída com base na arquitetura da sua zona de aterragem Azure, incluindo a sua topologia de rede, modelo de conectividade, controlos de segurança, requisitos de acesso operacional, requisitos de conformidade e padrões de acesso dos utilizadores MAS.

Quando a IBM suporta bases de dados externas para as aplicações MAS que implementa, tente externalizar essas bases de dados para reduzir o estado dentro do cluster OpenShift e desacoplar a gestão de bases de dados da gestão do cluster.

Workflow

Do ponto de vista da infraestrutura, esta arquitetura oferece as seguintes capacidades:

• Um serviço gerido Azure Red Hat OpenShift para implementar cargas de trabalho altamente disponíveis em zonas de disponibilidade
• Um cluster OpenShift integrado com redes e armazenamento Azure
• Ficheiros do Azure Premium e Ficheiros do Azure Standard para requisitos de armazenamento MAS suportados
• Azure SQL Managed Instance ou IBM Db2 Warehouse baseado em contentores
• DNS do Azure para gestão do Sistema de Nomes de Domínio (DNS) do OpenShift e dos seus contentores
• Microsoft Entra ID para login único (SSO) no MAS

Componentes

• Azure Red Hat OpenShift (ARO) é a plataforma OpenShift preferida para MAS no Azure. O ARO reduz a sua responsabilidade operacional pela execução do OpenShift, comparado com um cluster autogerido em máquinas virtuais (VMs) do Azure.

• Máquinas Virtuais do Azure é uma infraestrutura como serviço (IaaS) que implementa recursos computacionais escaláveis e sob demanda. Use Máquinas Virtuais em vez de ARO para implementar o Red Hat OpenShift autogerido no Azure.

  Opcionalmente, use VMs Linux do Azure como jump boxes para instalação de MAS e administração do OpenShift. Se tiver conectividade de rede privada ao seu ambiente Azure, pode realizar a administração a partir de uma máquina segura existente.

• Red Hat Enterprise Linux O CoreOS fornece a imagem do sistema operativo para nós OpenShift.

• O Balanceador de Carga do Azure fornece conectividade ao cluster. Balanceador de Carga é um serviço de balanceamento de carga de camada 4 de alto desempenho e latência ultra baixa para todos os protocolos User Datagram Protocol (UDP) e Transmission Control Protocol (TCP) de entrada e saída. O Balanceador de Carga consegue lidar com milhões de pedidos por segundo, garantindo que a sua solução está altamente disponível. Balanceador de Carga é redundante por zona, garantindo alta disponibilidade em todas as zonas.

• Rede Virtual do Azure é o bloco fundamental para redes privadas em Azure. Use a Rede Virtual para comunicação entre nós e serviços Azure, e para conectividade híbrida.

• O Ficheiros do Azure fornece partilhas de ficheiros totalmente geridas na cloud, acessíveis através dos protocolos Server Message Block (SMB) e Network File System (NFS). Use o Ficheiros do Azure para alojar os dados com estado das bases de dados e sistemas dentro do cluster.

• O DNS do Azure gere a resolução DNS para os contentores dentro e fora da solução. O DNS do Azure suporta todos os registos DNS comuns e oferece alta disponibilidade.

• O Azure Bastion é um serviço totalmente gerido que fornece acesso ao protocolo de desktop remoto (RDP) e secure shell (SSH) às VMs sem qualquer exposição através de endereços IP públicos. Opcionalmente, use o Azure Bastion e uma sub-rede para acesso de segurança reforçada a qualquer um dos nós worker ou máquinas opcionais de jump box.

• O SQL Managed Instance fornece serviços de dados externos ao MAS quando a IBM suporta o SQL Server para as aplicações que implementa. Também pode escolher outra base de dados, como Oracle Exadata ou IBM Db2 Warehouse. Base de Dados SQL do Azure não é suportado.

• A Twilio SendGrid envia emails de MAS aos seus consumidores. Se a sua implementação MAS precisar de um serviço de email para cenários de notificação e despacho de força de trabalho, incorpore opcionalmente um serviço de email como o Twilio SendGrid no seu design.

Alternativas

Os seguintes serviços normalmente não são necessários, mas são alternativas eficazes:

• Azure NetApp Files como substituto do Ficheiros do Azure. O Azure NetApp Files suporta cargas de trabalho que necessitam de alta disponibilidade e alto desempenho.
• Oracle Database no Azure se for suportado e preferir.
• OpenShift Data Foundation se você quiser usar o Db2 Warehouse no OpenShift Data Foundation.

Detalhes do cenário

A IBM Maximo Application Suite é uma plataforma de gestão de ativos empresariais com manutenção de ativos baseada em IA. O MAS concentra-se na resiliência operacional e na confiabilidade. O conjunto consiste na plataforma principal de aplicações MAS e nas seguintes aplicações e soluções específicas da indústria que são construídas sobre a plataforma.

• Maximo Manage. Reduz o tempo de inatividade e os custos utilizando a gestão de ativos para melhorar o desempenho operacional.
• Maximo Monitor. Utiliza a Internet das Coisas (IoT) para monitorização avançada de ativos remotos em larga escala, impulsionada por IA.
• Maximo Health. Gerir a saúde dos ativos utilizando dados IoT provenientes de sensores, dados de ativos e histórico de manutenção.
• Maximo Visual Inspection. Treina modelos de aprendizagem automática para usar inspeção visual para análise visual de questões emergentes.
• Maximo Predict. Prevê falhas futuras utilizando aprendizagem automática e análise de dados.
• Maximo Collaborate. Apoia os técnicos com orientação baseada em IA a partir de uma base de conhecimento de dados de manutenção de equipamentos e fornece acesso remoto a especialistas.
• Maximo Saúde, Segurança e Ambiente (HSE). Liga processos de segurança, conformidade ambiental e controlo do trabalho a ativos, localizações e ordens de trabalho.
• Maximo Infraestruturas Civis. Integra inspeção, rastreio de defeitos e atividades de manutenção para ajudar a melhorar a vida útil dos ativos, manter os sistemas críticos a funcionar e reduzir os custos totais de propriedade da infraestrutura civil.
• Maximo Real Estate and Facilities. Gerir portfólios imobiliários e ativos de instalações com gestão de espaços, reservas, projetos de capital, avaliação do estado das instalações, gestão de contratos de arrendamento, operações e manutenção.

Potenciais casos de utilização

Muitas indústrias e setores utilizam soluções MAS, como as seguintes áreas:

• Setor energético e serviços públicos
• Petróleo e gás
• Fabricação
• Viagens, automóveis e transportes
• Setor público

Para mais informações sobre casos de uso do MAS, consulte o IBM Maximo Application Suite no site da IBM.

Recomendações

Este artigo foi escrito para implementações MAS 9.x suportadas atualmente no Azure. A Microsoft trabalhou com a equipa IBM MAS e outros parceiros para garantir que esta solução está configurada para funcionar de forma ótima e proporcionar a melhor experiência no Azure. Esta documentação, arquitetura e orientação seguem as melhores práticas conforme delineadas no Quadro Microsoft Azure Well-Architected. Contacte a sua equipa de contas IBM para questões específicas de produto e suporte para além desta documentação.

Use este artigo para orientação de arquitetura quando tiver apoio da IBM e de um parceiro para a instalação. O Azure também oferece um caminho de instalação para MAS que suporta trazer a sua própria licença. Para obter mais informações, consulte IBM Maximo Application Suite (bring your own license (BYOL))).

Instale uma versão MAS suportada que a IBM liste como compatível com a sua versão OpenShift selecionada e com as aplicações MAS. Para novas implementações do Azure, use o ARO como plataforma OpenShift preferida, a menos que precise de um cluster autogerido.

A compatibilidade do suporte OpenShift depende de três limites sobrepostos de suporte: compatibilidade IBM MAS, suporte ao ciclo de vida Red Hat OpenShift e disponibilidade de versões ARO. Usar uma versão do OpenShift que a IBM não lista nos Relatórios de Compatibilidade de Produtos de Software (SPCR) ou que esteja fora do suporte Red Hat ou ARO pode deixar a implementação do seu MAS sem suporte.

Antes de construir a sua implementação, consulte a visão geral da IBM Maximo Application Suite, o planeamento de instalação no Microsoft Azure e a documentação dos Relatórios de Compatibilidade de Produtos de Software (SPCR) para compreender os requisitos atuais de implementação e configuração.

Antes de prosseguir com a implantação, responda às seguintes perguntas sobre seu design:

• Quais aplicativos MAS você precisa?
• Que dependências têm as suas aplicações?
• Qual é a versão do OpenShift que a IBM suporta para a sua versão MAS e aplicações?
• O ARO cumpre os seus requisitos ou precisa de um Red Hat OpenShift autogerido no Azure?
• Que bases de dados precisas?
• De que número e tamanhos de VMs você precisa?
• Os utilizadores precisam de se ligar a partir de redes externas?

Pacote de aplicativos Maximo

Use uma versão MAS 9.x suportada atualmente e valide as versões, bases de dados e dependências do OpenShift suportadas no IBM SPCR antes de finalizar a arquitetura. Se estiver numa versão anterior do Maximo Application Suite, reveja o estado do ciclo de vida da IBM e planeie uma atualização para uma versão MAS 9.x suportada.

Revise as candidaturas MAS necessárias para o seu cenário empresarial completo e depois reveja os requisitos para cada uma das candidaturas. Para obter mais informações, consulte Requisitos de sistema do IBM Maximo Application Suite.

Cada aplicação MAS pode precisar de uma base de dados separada. Tente externalizar bases de dados se a IBM suportar uma base de dados externa para a aplicação, porque essa abordagem reduz a quantidade de estado que tem de operar dentro do OpenShift. A Microsoft e a IBM testaram e suportam as seguintes bases de dados para MAS no Azure:

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

Base de Dados SQL do Azure e Azure Cosmos DB não são suportados.

Também pode optar por correr Oracle Exadata na Oracle Cloud Infrastructure ou numa VM usando uma interligação. Esta configuração não foi oficialmente testada, mas alegadamente é bem-sucedida. Para mais informações sobre interligação, consulte Interconnecting Oracle Cloud com Microsoft Azure.

O MAS e algumas das suas aplicações dependem do MongoDB e do Kafka. Use as implementações padrão da IBM no cluster MongoDB Community Edition e Strimzi Kafka quando se adequarem aos seus requisitos de suporte, backup e recuperação. Esta escolha é apropriada quando Kafka e MongoDB são dependências internas de MAS e a tua solução não os usa fora de MAS.

Tente usar serviços geridos externos, como o MongoDB Atlas no Azure ou o Confluent Cloud no Azure, quando precisar de backups, escalabilidade ou operações de recuperação de desastres mais fortes. Alguns pré-requisitos do MAS, como os Behavior Analytics Services (BAS), utilizam bases de dados que não podem ser externalizadas mas que exigem armazenamento persistente fornecido ao cluster OpenShift.

Para serviços baseados em estados que correm dentro do cluster OpenShift, faça backup regular dos dados e mova os backups para outra região. Desenhar, planear e decidir uma estratégia de recuperação para desastres, especialmente quando executa Kafka ou MongoDB dentro do OpenShift. Para serviços que mantêm o estado, use ofertas externas da plataforma Azure como serviço (PaaS) se possível para melhorar o suporte durante uma interrupção.

Alguns serviços podem necessitar de outras ferramentas e serviços da IBM, como o IBM Watson Machine Learning e o IBM App Connect. Podes implementar todas estas ferramentas e serviços no mesmo cluster OpenShift.

Azure Red Hat OpenShift

Use o ARO como a plataforma OpenShift preferida para MAS no Azure. O ARO fornece um serviço OpenShift gerido no Azure, que reduz o seu encargo operacional de instalar, aplicar patches e operar a plataforma OpenShift. Continua a ser dono do MAS e da sua configuração de aplicações, planeamento da capacidade de trabalhador, integração de rede, integração de identidade, escolhas de armazenamento, proteção de dados e recuperação de desastres.

Antes de implementar MAS no ARO, considere as seguintes recomendações:

• Compatibilidade de versões. Selecione uma versão OpenShift que a IBM liste como suportada para a sua versão MAS e para as aplicações MAS selecionadas. Confirme se a mesma versão do OpenShift está disponível e suportada pelo ARO na sua região Azure de destino. Sempre que possível, selecione uma versão OpenShift com número par para implantações MAS de produção, pois estas versões são versões de Suporte de Atualização Estendida (EUS ).

  Valide cruzadamente que a IBM suporta a versão OpenShift selecionada para todas as aplicações MAS e dependências selecionadas. Se um componente MAS listar uma versão OpenShift ímpar mais recente como requisito no IBM SPCR, valide o conjunto completo de componentes com o IBM SPCR, suporte ao ciclo de vida do Red Hat e disponibilidade de versões ARO antes de escolher a versão do cluster.

• Caminho de implantação. Use um cluster ARO existente quando tiver zona de aterragem Azure pré-existente, redes, identidade, armazenamento e controlos operacionais. Use o caminho de instalação do IBM Azure Marketplace quando quiser automação fornecida pela IBM para criar ou reutilizar a infraestrutura OpenShift suportada. Use o Red Hat OpenShift autogerido no Azure apenas quando o ARO não cumprir os seus requisitos.

• Seleção de região. Use uma região que tenha zonas de disponibilidade , se possível. Configure nós trabalhadores ARO entre zonas quando a região alvo suportar esse padrão. Para OpenShift autogerido, configura o ficheiro de instalação, install-config.yaml, para que o OpenShift coloque os nós entre zonas. Se houver uma falha numa zona, a sua solução pode continuar a funcionar fazendo com que nós noutras zonas assumam o trabalho.

• Backup e recuperação. Pode usar as instruções de backup e recuperação do Azure Red Hat OpenShift. Para mais informações, consulte Criar um Azure Red Hat OpenShift 4 cluster Application Backup. Se usar este método para backup e recuperação, terá de fornecer outro método de recuperação de desastres para a base de dados.

• Failover. Considere implantar o OpenShift em duas regiões e usar o Red Hat Advanced Cluster Management. Se a sua solução tiver endpoints públicos, pode colocar o Gestor de Tráfego do Azure entre os endpoints e a internet para redirecionar o tráfego para o cluster apropriado numa interrupção regional. Nessa situação, também deve migrar os estados e volumes persistentes das suas aplicações.

OpenShift autogerido

Use o Red Hat OpenShift autogerido no Azure se o ARO não cumprir os seus requisitos de controlo, isolamento ou implementação desconectada. Para implementações autogeridas, escolha entre os seguintes métodos de instalação:

• Infraestrutura provisionada do instalador (IPI). Este método utiliza um instalador para implementar e configurar o ambiente OpenShift no Azure. Use IPI quando cumpra os seus requisitos de segurança e redes.

• Infraestrutura provisionada pelo usuário (UPI). Este método permite-lhe um controlo detalhado sobre a sua implementação. O UPI requer mais etapas e considerações para criar o seu ambiente. Usa UPI se o IPI ou o ARO não corresponderem às tuas necessidades. Uma instalação privada ou desligada é um caso de uso comum para UPI.

Instalação com distância de ar

Alguns casos, como a conformidade regulatória, podem exigir uma instalação aérea do MAS no Azure. Air-gap significa que não há acesso à internet de entrada ou saída. Sem uma ligação à internet, a sua instalação não consegue recuperar as dependências da instalação MAS ou OpenShift em tempo de execução.

Use uma instalação isolada apenas se for um requisito de segurança. Um air gap acrescenta complexidade significativa às operações de solução. Atividades como instalar software, espelhar containers, atualizar espelhos para proteger contra vulnerabilidades de segurança ou gerir firewalls podem consumir um esforço operacional significativo.

Para mais informações sobre instalações air-gapped instalações, consulte a seguinte documentação do Red Hat OpenShift para instalações desconectadas e clusters privados no Azure:

• Espelhar imagens para uma instalação desconectada usando oc-mirror
• Instalação de um cluster privado na Azure

Após uma instalação OpenShift sem reservas, pode continuar com a documentação do MAS para obter orientações sobre ambientes desconectados.

Dimensionamento de nós e ambiente

Para todas as cargas de trabalho exceto a Maximo Visual Inspection, comece pelas famílias de VMs da série Ds ou Das da geração atual, como o Dsv6, que estão disponíveis como nós worker na região escolhida. Escolha tamanhos de VM que suportem armazenamento premium e cumpram os requisitos de CPU, memória e armazenamento das aplicações MAS que implementa.

O Maximo Visual Inspection requer nós de GPU para executar seu aprendizado de máquina. A solução usa CUDA e suporta apenas GPUs NVIDIA. Para o ARO, escolha o tamanho de uma VM GPU Nvidia da lista atual de suporte a nós de trabalho ARO e depois confirme que a IBM a suporta para as suas versões MAS e OpenShift. Para OpenShift autogerido, escolha um tamanho de GPU VM da Nvidia suportado pela IBM e Red Hat.

Para nós de trabalho da GPU, começa pelo nó mais pequeno e aumenta à medida que os requisitos aumentam.

Para ARO e OpenShift autogerido, use as mesmas orientações de dimensionamento da carga de trabalho MAS para nós trabalhadores. Configure nós de trabalho entre as zonas de disponibilidade para suportar alta disponibilidade. Para OpenShift autogerido, configure também o plano de controlo entre as zonas de disponibilidade. Use o seguinte ponto de partida:

• Nós de controlo. Para o ARO, o plano de controlo é gerido como parte do serviço. Para OpenShift autogerido, utilize no mínimo uma VM por zona de disponibilidade dentro da região selecionada.

• Nós trabalhadores. Use pelo menos duas máquinas por zona de disponibilidade dentro da região selecionada. Dimensione os nós trabalhadores com base nas orientações IBM, aplicações MAS selecionadas e carga esperada.

O núcleo do MAS requer 13 vCPUs para uma instalação base de tamanho padrão. O dimensionamento para os nós de trabalho varia de acordo com os aplicativos MAS que sua configuração implanta e a carga em seu ambiente. Por exemplo, o Maximo Manage para 10 utilizadores requer mais 2 vCPUs. Trate estes valores como pontos de partida e valide o dimensionamento com base nos requisitos atuais do sistema IBM Maximo Application Suite para a sua versão MAS 9.x, aplicações selecionadas e uso esperado.

Para OpenShift autogerido, tente manter os tipos de VM semelhantes entre si para garantir proximidade com cada uma das zonas de disponibilidade entre os nós trabalhador e de controlo. Para ARO, alinhe os pools de nós worker com os mesmos requisitos de carga de trabalho MAS e capacidade regional do Azure.

Se precisar de uma jump box para usar a interface de linha de comandos do OpenShift oc ou para instalar o MAS, implemente uma VM Linux suportada que cumpra os requisitos administrativos e de segurança da sua organização.

Configuração de rede

Para o ARO, use a configuração de rede OpenShift por defeito que o ARO implementa, a menos que a IBM, a Red Hat e a sua equipa de redes validem outra opção. Planeie a rede virtual e sub-redes separadas para nós de plano de controlo ARO, nós de trabalho, dependências de serviços Azure, endpoints privados, bases de dados e conectividade híbrida. Dimensione as subredes de nós para o número de nós trabalhadores do OpenShift que precisa, incluindo capacidade de atualização e escalabilidade futura.

Para OpenShift autogerido, inclua também requisitos de bootstrap e infraestrutura criada pelo instalador. Mantenha o acesso administrativo à API e aos nós OpenShift limitado a caminhos de rede aprovados, como conectividade híbrida, hosts de salto seguros ou outros controlos que a sua organização necessite. Se restringires a saída do cluster, planeia as dependências de saída necessárias para OpenShift, instalação MAS, pulls de imagens de contentores, atualizações, monitorização e serviços externos.

Para uma instalação de produção MAS padrão em ARO, não comece com uma rede virtual muito compacta. Reserve um espaço de endereçamento maior, como um prefixo Classless Inter-Domain Routing (CIDR) de /16 quando a sua zona de aterragem o permitir, e aloque sub-redes dedicadas. Use pelo menos um tamanho de planeamento /24 para a sub-rede do plano de controlo ARO e pelo menos um tamanho de planeamento /24 para a sub-rede do nó trabalhador. Adicione uma sub-rede /27 ou maior para endpoints privados e serviços externos de base de dados. Se opcionalmente implementares o Azure Bastion, adiciona uma sub-rede chamada AzureBastionSubnet com o prefixo /26. Para mais informações sobre os requisitos do Azure Bastion, consulte Arquitetura.

Se usar OpenShift autogerido e tiver falta de endereços IP, pode desenhar uma configuração altamente disponível e limitada com um prefixo mínimo de /27 para a sub-rede do nó de controlo e /27 para a sub-rede do nó trabalhador. Não uses este dimensionamento restrito como ponto de partida para uma implementação em produção ARO. Não subdimensione a rede virtual ou as sub-redes de nós. Reenderear uma implementação OpenShift após a instalação é disruptivo e pode exigir uma nova implementação.

Se quiseres usar uma Interface de Rede de Contentores (CNI) diferente, dimensiona as tuas redes em conformidade. O MAS, com algumas aplicações padrão, implementa mais de 800 pods, que provavelmente requerem um prefixo CIDR de /21 ou maior.

Especificidades da base de dados

Alguns componentes MAS utilizam o MongoDB como armazenamento de metadados. A orientação padrão é implementar o MongoDB Community Edition dentro do cluster. Se usar esse método, certifique-se de que tem um procedimento adequado para fazer backup e restaurar a base de dados. Considere usar o MongoDB Atlas no Azure para fornecer um armazenamento externalizado, backups e escalabilidade. O Azure atualmente não suporta o uso de APIs do MongoDB com o Azure Cosmos DB.

Se implementa serviços IoT, deve também fornecer um endpoint Kafka. A orientação padrão é usar o Strimzi para implementar o Kafka dentro do cluster OpenShift, mas é provável que os dados dentro do Strimzi se percam durante a recuperação de desastres. Se a perda de dados dentro do Kafka for inaceitável, considere usar o Confluent Kafka no Azure. Atualmente, o Hubs de Eventos do Azure não é suportado com endpoints Kafka.

O MAS inclui várias bases de dados nos seus pods, e essas bases de dados mantêm os seus estados no sistema de ficheiros fornecido para o MAS. Para absorver falhas de zona, utilize um mecanismo de armazenamento redundante por zonas (ZRS) para manter os estados fora dos seus clusters. O padrão recomendado é usar o Azure File Storage com as seguintes configurações:

• A Standard fornece partilhas SMB para cargas de trabalho de menor débito e ReadWriteOnce (RWO). Use Standard para partes da aplicação que não escrevem frequentemente em armazenamento e que requerem um único volume persistente, como o armazenamento de nível único da IBM.

• A Premium fornece shares NFS para maiores cargas de trabalho de rendimento e ReadWriteMany (RWX). Volumes como estes são usados em todo o cluster para cargas de trabalho do RWX, como o Db2 Warehouse no Cloud Pak for Data ou o Postgres no Maximo Manage.

O Ficheiros do Azure NFS suporta encriptação durante o trânsito. Se o cliente MAS OpenShift não conseguir usar encriptação NFS, pode isentar a conta das políticas de aplicação segura de transferências. Para mais informações, consulte NFS Azure file shares: Encryption. Use um endpoint privado para fornecer conectividade privada às suas partilhas.

Se implementares o Db2 Warehouse através do Cloud Pak for Data, usa o OpenShift Data Foundation. Para um exemplo da OpenShift Data Foundation que utiliza classes de armazenamento Ceph File System (CephFS) e RADOS Block Device (Ceph RBD) para diferentes tipos de dados do Db2 Warehouse, veja Criar a instância Db2 usando a consola Cloud Pak for Data.

Não uses o Armazenamento de Blobs do Azure com drivers Container Storage Interface (CSI), porque não suporta ligações fixas, que alguns pods exigem para correr.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que pode usar para melhorar a qualidade de uma carga de trabalho. Para mais informações, consulte Microsoft Azure Well-Architected Framework.

Fiabilidade

O OpenShift tem capacidades integradas para auto-cura, escalabilidade e resiliência. O OpenShift e o MAS esperam que os componentes falhem e recuperem. Um requisito fundamental para a auto-recuperação é que o cluster tenha nós trabalhadores suficientes. Para recuperar de uma falha de zona numa região Azure, os seus nós de controlo e de trabalho devem estar equilibrados entre zonas de disponibilidade.

O MAS e o OpenShift utilizam armazenamento para persistir o estado fora do cluster Kubernetes. Para garantir que as dependências de armazenamento continuem a funcionar durante uma falha, use o armazenamento com redundância de zona sempre que possível. O armazenamento redundante por zona permanece disponível quando uma única zona falha.

Para ajudar a prevenir erros humanos, implemente o MAS utilizando o máximo de automação possível. Use a documentação de instalação atual da IBM e a automação suportada para a sua versão MAS selecionada, plataforma OpenShift e caminho de implementação.

Segurança

A segurança fornece garantias contra ataques deliberados e o uso indevido de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação para revisão de design de segurança.

Manter o acesso e a visibilidade do ciclo de vida de manutenção de seus ativos pode ser uma das maiores oportunidades da sua organização para operar de forma eficiente e manter o tempo de atividade. Para melhorar a postura de segurança do seu ambiente, é importante usar a autenticação segura e manter suas soluções atualizadas. Use a criptografia para ajudar a proteger todos os dados que entram e saem da sua arquitetura.

Ao utilizar implementações ARO, beneficia do modelo de responsabilidade partilhada ARO. O Azure Red Hat OpenShift é concebido, operado e suportado em conjunto pela Microsoft e Red Hat, que atualizam, atualizam e monitorizam a plataforma OpenShift gerida em seu nome. Continua responsável pelas implantações além do ARO. Esta responsabilidade inclui a configuração do MAS e da sua aplicação, integração de identidade, controlos de rede, planeamento da capacidade dos trabalhadores, escolhas de armazenamento, backup e recuperação de desastres, segredos, proteção de dados e requisitos de conformidade. Para mais informações, consulte Introdução ao Azure Red Hat OpenShift e política de suporte ao Azure Red Hat OpenShift 4.0.

A Microsoft integra proteções de segurança na plataforma Azure nos seguintes níveis:

• Datacenter físico
• Rede física
• Anfitrião físico
• Hipervisor

Use uma versão OpenShift que a sua plataforma OpenShift suporte e que a IBM suporte para a sua versão MAS e aplicações. Sempre que possível, utilize uma versão de suporte suportada a longo prazo. Se usar OpenShift autogerido, é responsável por corrigir e manter a plataforma OpenShift e as VMs subjacentes. Se usares o ARO, a Microsoft trata das correções e gestão.

Use grupos de segurança de rede para filtrar o tráfego de rede de e para os recursos da sua rede virtual. Ao utilizar estes grupos, pode definir regras que concedem ou negam o acesso aos seus serviços MAS, tais como:

• Permitir acesso SSH aos nós OpenShift para resolução de problemas.
• A bloquear o acesso a todas as outras partes do cluster.
• Controlar quais as localizações que podem aceder ao MAS e ao cluster OpenShift.

Para aceder às suas VMs, pode ligar-se através de conectividade híbrida ou através da consola de administração OpenShift. Se tiver uma implementação online ou não quiser depender da conectividade híbrida, pode aceder às suas VMs através do Azure Bastion. Por razões de segurança, não exponha VMs a uma rede ou à internet sem configurar grupos de segurança de rede para controlar o acesso.

A encriptação do lado do servidor (SSE) do Armazenamento de Discos do Azure protege os seus dados e ajuda-o a cumprir os compromissos organizacionais de segurança e conformidade. Com discos geridos do Azure, o SSE encripta os dados em repouso quando os mantém na cloud. Esse comportamento se aplica por padrão ao sistema operacional e aos discos de dados. O OpenShift usa SSE por padrão.

Autenticação

O MAS suporta SSO com Security Assertion Markup Language (SAML). Para usar o Microsoft Entra ID como fornecedor de identidade SAML, crie uma aplicação empresarial no Microsoft Entra ID e configure o MAS como fornecedor de serviços. Para mais informações, consulte a integração SSO do Microsoft Entra com a Maximo Application Suite.

Antes de configurar a autenticação baseada em SAML, reveja tanto a configuração IBM como a configuração do Azure. Para informações sobre SAML com MAS, consulte Configurar a autenticação SAML. Para informações sobre SAML com Azure, veja Quickstart: Habilitar single log-on para uma aplicação empresarial.

Deves também configurar o OAuth para acesso administrativo ao OpenShift. Para ARO, consulte Configurar autenticação Microsoft Entra para um cluster Azure Red Hat OpenShift. Para OpenShift autogerido, veja Configurar fornecedores de identidade na OpenShift Container Platform 4.21.

Acesso a recursos e auditoria

Controla o acesso aos recursos do Azure que implementas. Cada subscrição Azure tem uma relação trust com um inquilino Microsoft Entra. Utilize o controlo de acesso baseado em funções do Azure (RBAC do Azure) para conceder aos utilizadores na sua organização as permissões adequadas aos recursos do Azure. Conceda acesso atribuindo funções no Azure a utilizadores ou grupos num determinado âmbito, como uma subscrição, grupo de recursos ou recurso único. Auditar todas as alterações à infraestrutura. Para mais informações sobre auditoria, consulte Azure Monitor registo de atividade.

Otimização de custos

A Otimização de Custos concentra-se em formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de projeto para Otimização de custos.

Uma implementação MAS padrão no Azure inclui os seguintes principais fatores de custo:

• Custos de cluster ARO, incluindo nós de trabalho e quaisquer encargos faturáveis de plano de controlo ou cluster
• Pools de nós worker dimensionados para o MAS Core e as aplicações MAS que implementas
• Nós opcionais de GPU worker para Inspeção Visual Maximo
• Serviços de base de dados, como SQL Managed Instance, Db2 Warehouse ou outra base de dados suportada pela IBM
• Contas de armazenamento ou serviços de armazenamento geridos para volumes persistentes, backups e artefactos de instalação
• Zonas DNS, balanceamento de carga, endpoints privados e uma instância opcional do Azure Bastion

Para ARO e OpenShift autogerido, uma implementação MAS padrão utiliza tipicamente a mesma linha base de dimensionamento de nó de trabalho. Use o seguinte inventário como ponto de partida para a estimativa de custos:

• Seis VMs de trabalhadores.
• Três VMs de trabalhadores para o Db2 Warehouse. Podes substituir o SQL Managed Instance em algumas configurações em vez de usar o Db2 Warehouse.
• Duas contas Armazenamento do Azure.
• Duas zonas DNS.
• Dois balanceadores de carga.
• Azure Bastion.
• Um nó trabalhador da GPU Maximo Visual Inspection, se planeias executar o Maximo Visual Inspection dentro do MAS.

O custo do plano de controlo varia consoante o modelo de implantação. Para implementações OpenShift autogeridas que utilizam IPI ou UPI, incluam também três VMs de controlo. Para o ARO, tem em conta o plano de controlo gerido e quaisquer encargos específicos do cluster ARO em vez de adicionar VMs de controlo geridas pelo cliente.

Pode rever um orçamento de exemplo usando a calculadora de custos. As configurações variam, por isso verifica a tua configuração com a tua equipa de dimensionamento IBM antes de finalizares a implementação.

Implementar este cenário

Antes de começar, reveja os requisitos do sistema IBM Maximo Application Suite e o IBM SPCR para a sua versão MAS e aplicações. Tenha os seguintes recursos disponíveis antes de iniciar a implantação:

• Acesso a uma subscrição do Azure com permissão do Leitor
• Um nome principal de registo de aplicação ou serviço que tenha permissões de Contribuidor e Administrador de Acesso ao Utilizador para a subscrição
• Um domínio ou subdomínio delegado a uma zona DNS do Azure
• Um cluster ARO suportado ou as permissões e pré-requisitos para criar um
• Um segredo de pull da Red Hat se o seu caminho de implementação cria ou gere infraestrutura OpenShift
• Uma chave de direito MAS
• Um ficheiro de licença MAS que cria após a instalação do MAS
• Dimensionamento de cluster recomendado pela IBM
• Uma rede virtual existente ou uma nova rede virtual que cumpra os requisitos ARO e MAS
• Requisitos de alta disponibilidade e recuperação de desastres para sua implantação específica
• Detalhes de configuração para o caminho de implementação selecionado, como detalhes do cluster ARO ou parâmetros de instalação OpenShift autogeridos

Antes de construir o seu ambiente, consulte a documentação IBM Planeando instalar no Microsoft Azure para compreender os parâmetros de design. Para orientações atuais sobre a instalação do Azure, consulte a visão geral do Maximo Application Suite no Microsoft Azure. Valide o seu processo de implementação com a documentação atual da IBM e a matriz de suporte para a sua versão MAS.

Considerações sobre implementação

Implementar cargas de trabalho usando infraestrutura como código (IaC) em vez de manualmente. A implementação manual pode resultar em má configuração. As cargas de trabalho baseadas em contêiner podem ser sensíveis a configurações incorretas, o que pode reduzir a produtividade.

A IBM oferece serviços especializados para ajudá-lo com a instalação. Entre em contato com sua equipe IBM para obter suporte.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Principais autores:

• David Baumgarten | Arquiteto-Chefe
• Roeland Nieuwenhuis | Arquiteto Chefe

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Próximos passos

Para obter ajuda para começar, consulte os seguintes recursos:

• Azure Red Hat OpenShift
• Resumo do Maximo Application Suite no Microsoft Azure
• A planear instalar no Microsoft Azure
• A instalar o OpenShift no Azure
• Guia UPI OpenShift
• Requisitos para o Maximo
• Relatórios de Compatibilidade de Produtos de Software IBM
• IBM Maximo Application Suite (BYOL)

Para saber mais sobre as tecnologias em destaque, consulte os seguintes recursos:

• Vantagem do IBM Passport
• Introdução ao DNS do Azure
• Introdução à Azure NetApp Files
• Introdução ao Azure Red Hat OpenShift
• Portal do cliente Red Hat

Recursos relacionados

• Partilha de ficheiros na cloud empresarial Azure
• Implementar uma aplicação Java com a plataforma de aplicações empresariais (EAP) JBoss num cluster ARO