Implementar o IBM Maximo Application Suite no Azure

IBM Maximo Application Suite (MAS) 8.x é executado no OpenShift e é benéfico familiarizar-se com o OpenShift e os padrões sugeridos para instalação no Azure. Para obter mais informações, consulte Preparando-se para instalar no Azure. Essa arquitetura ilustra um cluster OpenShift. Ele não entra em detalhes sobre como instalar o MAS. Para saber mais sobre o processo de instalação, consulte Instalando o Maximo Application Suite do OperatorHub.

Arquitetura

Transfira um ficheiro do Visio desta arquitetura.

A carga de trabalho pode ser implantada interna ou externamente, dependendo de suas necessidades.

Fluxo de Trabalho

Do ponto de vista da infraestrutura, esta arquitetura proporciona o seguinte:

• Uma plataforma de hospedagem de contêiner para implantar cargas de trabalho altamente disponíveis em zonas de disponibilidade
• Uma implantação privatizada de nós de trabalho e controle integrados ao armazenamento
• Arquivos premium e padrão do Azure Files para armazenamento (OpenShift Data Foundation não é necessário)
• SQL Server em VMs do Azure ou IBM Db2 Warehouse baseado em contêiner
• DNS do Azure para gerenciamento de DNS do OpenShift e seus contêineres
• ID do Microsoft Entra para logon único (SSO) no MAS

Componentes

• Máquinas Virtuais do Azure para hospedar a plataforma OpenShift e executar os contêineres do Maximo. Máquinas Virtuais é uma oferta de infraestrutura como serviço (IaaS). Você pode usar máquinas virtuais para implantar recursos de computação escaláveis sob demanda.

• Red Hat Enterprise Linux CoreOS para fornecer uma imagem de VM personalizada para o OpenShift.

• Azure Load Balancers para fornecer conectividade ao cluster. O Azure Load Balancer é um serviço de balanceamento de carga de camada 4 de alto desempenho e latência ultrabaixa (entrada e saída) para todos os protocolos UDP e TCP. Ele foi criado para lidar com milhões de solicitações por segundo, garantindo que sua solução esteja altamente disponível. O Azure Load Balancer é redundante por zona, garantindo alta disponibilidade nas Zonas de Disponibilidade.

• Rede Virtual para comunicação entre nós, serviços do Azure e necessidades de conectividade híbrida. A Rede Virtual é o bloco de construção fundamental para redes privadas no Azure.

• Arquivos do Azure para hospedar os dados com monitoração de estado para os bancos de dados e sistemas dentro do cluster. Os Arquivos do Azure fornecem compartilhamentos de arquivos totalmente gerenciados na nuvem que podem ser acessados por meio dos protocolos SMB e NFS (Network File System).

• DNS do Azure para gerenciar a resolução de DNS para os contêineres dentro e fora da solução. O DNS do Azure dá suporte a todos os registros DNS comuns e fornece alta disponibilidade.

• Azure Bastion (opcional) e uma sub-rede para acesso de segurança aprimorada a qualquer um dos nós de trabalho ou máquinas JumpBox opcionais. O Azure Bastion é um serviço totalmente gerenciado que fornece acesso RDP e SSH de segurança aprimorada contínuo a VMs sem qualquer exposição por meio de endereços IP públicos.

• SQL Server em Máquinas Virtuais do Azure (opcional) para fornecer serviços de dados ao MAS. O banco de dados também pode ser outro, como Oracle Exadata ou IBM Db2 Warehouse. O Banco de Dados SQL do Azure e a Instância Gerenciada SQL do Azure não são suportados no momento.

• Twilio Send Grid (opcional) para enviar e-mails do MAS para seus consumidores.

• Máquinas virtuais Linux no Azure (opcional) para fornecer uma caixa de salto para a instalação do OpenShift. Você também pode usar essa VM para conectar e gerenciar o cluster OpenShift porque ele contém o arquivo de configuração do Kubernetes após a instalação. Se você tiver conectividade de rede em seu ambiente do Azure, poderá executar a instalação a partir de uma máquina existente.

Alternativas

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

• Arquivos NetApp do Azure como um substituto para Arquivos do Azure. Os Arquivos NetApp do Azure dão suporte a qualquer tipo de carga de trabalho com alta disponibilidade e alto desempenho.
• Banco de Dados Oracle no Azure, se preferir isso ao SQL Server ou ao Db2 Warehouse.
• OpenShift Data Foundation se você quiser usar o Db2 Warehouse no OpenShift Data Foundation.

Detalhes do cenário

O Maximo Application Suite (MAS) da IBM, também conhecido como Maximo, é uma plataforma de gerenciamento de ativos corporativos com manutenção de ativos baseada em IA. O MAS concentra-se na resiliência operacional e na confiabilidade. O pacote consiste em uma plataforma de aplicativos principal, MAS, e aplicativos e soluções específicas do setor sobre a plataforma. Cada aplicação proporciona um benefício específico:

• Gerir. Reduza o tempo de inatividade e os custos usando o gerenciamento de ativos para melhorar o desempenho operacional.
• Monitorizar. Use IoT para monitoramento avançado alimentado por IA de ativos remotos em escala.
• Estado de Funcionamento. Gerencie a integridade dos ativos usando dados da IoT de sensores, dados de ativos e histórico de manutenção.
• Inspeção visual Treine modelos de aprendizado de máquina para usar inspeção visual para análise visual de problemas emergentes.
• Prever. Preveja falhas futuras usando aprendizado de máquina e análise de dados.
• Assista. Ajude os técnicos fornecendo orientação baseada em IA para uma base de conhecimento de dados de manutenção de equipamentos e dando-lhes acesso remoto a especialistas.
• Segurança. Colete e analise dados de sensores, forneça dados contextuais e derive análises significativas.
• Civil. Integre atividades de inspeção, rastreamento de defeitos e manutenção para ajudar a melhorar a vida útil dos ativos, manter os sistemas críticos operando e reduzir os custos totais de propriedade da infraestrutura civil.

Estas aplicações e MAS 8.x são testados para uso no Azure. A Microsoft e a equipe do IBM Maximo fizeram uma parceria para garantir que essa solução seja configurada para ser executada de forma otimizada no Azure. Este artigo fornece um design para executar o MAS 8.x no Azure para clientes que têm suporte da IBM e de um parceiro para instalação. Entre em contato com sua equipe IBM para perguntas específicas do produto. O Azure Marketplace oferece uma instalação alternativa para o 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))).

Potenciais casos de utilização

Muitas indústrias e setores utilizam as soluções em MAS, tais como:

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

Encontre mais informações sobre casos de uso para MAS no site da IBM em IBM Maximo Application Suite.

Recomendações

Recomendamos instalar a versão estável mais recente do MAS porque ela fornece as melhores opções de integração com o Azure. Preste muita atenção às versões do OpenShift que são suportadas, porque as versões suportadas variam com a versão específica do MAS.

O uso de versões principais anteriores ou posteriores do OpenShift pode resultar na queda do suporte oficial para MAS. Antes de criar sua própria implantação, recomendamos usar o guia de início rápido para implantar o MAS, para que você entenda como a implantação e a configuração funcionam. Saber como isso é feito acelera a criação dos requisitos de design para sua implementação. Para obter mais informações, consulte Guia de início rápido: Maximo Application Suite no Azure.

Trabalhamos em estreita colaboração com a IBM e outros parceiros para garantir que a orientação, a arquitetura e o guia de início rápido ofereçam a melhor experiência no Azure. Eles seguem as práticas recomendadas, conforme descrito no Microsoft Azure Well-Architected Framework. Entre em contato com sua equipe de conta IBM para obter suporte além desta documentação.

Antes de prosseguir com a implantação, você precisa responder às seguintes perguntas sobre design:

• Quais aplicativos MAS você precisa?
• Que dependências têm as suas aplicações?
• Que versão do OpenShift é necessária?
• Qual método de instalação do OpenShift você deve usar?
• Que bases de dados são necessárias?
• De que número e tamanhos de VMs você precisa?
• Os usuários se conectarão a partir de redes externas?

Pacote de aplicativos Maximo

A Microsoft testou as versões 8.5 e posteriores do MAS no Azure. Nossa recomendação é usar a versão mais recente do MAS, que é a versão 8.7.

Analise os aplicativos MAS necessários para seu cenário de negócios completo e, em seguida, revise os requisitos para cada um dos aplicativos. Para obter mais informações, consulte Requisitos de sistema do IBM Maximo Application Suite. Cada um dos aplicativos pode precisar de bancos de dados separados. Testamos e damos suporte aos seguintes bancos de dados no Azure:

• SQL Server em Máquinas Virtuais do Azure versão 2019 usando Windows ou Linux
• IBM Db2 Warehouse no Cloud Pak para Dados 3.5

Você também pode optar por executar o Oracle Exadata em uma VM ou no Oracle Cloud Infrastructure usando interconexão, mas essa não é uma configuração testada. Para obter mais informações sobre interconexão, consulte Interconectando o Oracle Cloud com o Microsoft Azure. Atualmente, o Banco de Dados SQL do Azure, a Instância Gerenciada do SQL do Azure e o Azure Cosmos DB não são suportados.

O MAS e algumas de suas aplicações têm dependências do MongoDB e Kafka. Decida como implantar essas soluções com base em considerações de desempenho e operações. Os padrões são implantar o MongoDB Community Edition e o Strimzi Kafka dentro dos clusters. Alguns dos pré-requisitos do MAS, por exemplo o BAS, usam bancos de dados que não podem ser externalizados, mas que exigem armazenamento persistente para ser fornecido ao cluster OpenShift.

Para serviços baseados em estado que são executados dentro do cluster OpenShift, é necessário fazer backup de dados com frequência e mover os backups para outra região. Projete e planeje uma estratégia de recuperação em caso de desastre e decida de acordo, especialmente ao executar Kafka ou MongoDB dentro do OpenShift.

Para serviços que mantêm o estado, use ofertas externas da plataforma Azure como serviço (PaaS) quando possível. Isso melhora a capacidade de suporte durante uma interrupção.

Alguns dos serviços podem exigir outras ferramentas e serviços IBM, como IBM Watson Machine Learning e IBM App Connect. Você pode implantar todas as ferramentas e serviços no mesmo cluster OpenShift.

OpenShift

Antes de instalar o OpenShift, você precisa determinar qual método será usado:

• Infraestrutura provisionada do instalador (IPI). Esse método usa um instalador para implantar e configurar o ambiente OpenShift no Azure. O IPI é o método mais comum para implantar no Azure, e você deve usar o IPI, a menos que seus requisitos de segurança sejam muito rigorosos para fazê-lo.

• Infraestrutura provisionada pelo usuário (UPI). Esse método permite um controle refinado sobre sua implantação. A UPI requer mais etapas e considerações para criar seu ambiente. Use o UPI se o IPI não atender às suas necessidades. Um caso de uso comum para UPI é para instalação privada com ar comprimido. Escolha UPI quando não tiver acesso de saída à Internet ao criar o ambiente.

Recomendamos o uso do IPI sempre que possível, porque reduz significativamente a quantidade de trabalho necessário para concluir a instalação do OpenShift.

Ao instalar o OpenShift, você deve resolver as seguintes considerações:

• Seleção de região. Recomendamos o uso de uma região com zonas de disponibilidade. Durante a implantação, o OpenShift tenta criar automaticamente nós entre zonas com base na configuração no arquivo de configuração, install-config.yaml. Por padrão, o OpenShift equilibra cargas de trabalho em todos os nós disponíveis e nas zonas de disponibilidade. Se houver uma interrupção em uma zona, sua solução pode continuar funcionando com nós em outras zonas que podem assumir o trabalho.

• Backup e recuperação. Você pode usar as instruções do Azure Red Hat OpenShift para backup e recuperação. Para obter mais informações, consulte Criar um backup de aplicativo de cluster do Azure Red Hat OpenShift 4. Se você usar esse método para backup e recuperação, deverá fornecer outro método de recuperação de desastres para o banco de dados.

• Ativação pós-falha. Considere implantar o OpenShift em duas regiões e usar o Red Hat Advanced Cluster Management. Se sua solução tiver pontos de extremidade públicos, você poderá colocar o Gerenciador de Tráfego do Azure entre eles e a Internet para redirecionar o tráfego para o cluster apropriado quando houver uma interrupção de uma região. Nessa situação, você também deve migrar os estados e volumes persistentes de seus aplicativos.

Instalações com ar comprimido

Em alguns casos, como para conformidade regulamentar, você pode exigir uma instalação air-gapped do MAS no Azure. Air gapped significa que não há acesso à Internet de entrada ou saída. Sem uma conexão com a Internet, sua instalação não pode recuperar as dependências de instalação em tempo de execução para a instalação do MAS ou OpenShift.

Não recomendamos que você faça uma instalação com ar comprimido, a menos que isso seja um requisito de segurança. Uma lacuna de ar adiciona complexidade significativa às operações da sua solução. Atividades como instalar software, espelhar contêineres, atualizar um espelho para proteção contra vulnerabilidades de segurança e gerenciar um firewall podem se tornar muito demoradas.

Para obter mais informações sobre instalações com ar comprimido, consulte a seguinte documentação do OpenShift:

• Espelhamento de imagens para uma instalação desconectada
• Instalando um cluster privado no Azure

Depois de instalar o OpenShift, consulte a documentação do MAS para obter orientações semelhantes.

Dimensionando seu ambiente

Para todas as cargas de trabalho (exceto inspeção visual), recomendamos o uso das VMs mais recentes da série Ds como nós de trabalho. Exemplos são o Dsv3, Dasv4, Dsv4, Dasv5 ou Dsv5. Recomendamos o uso das versões mais recentes, quando possível, porque proporcionam um melhor desempenho. Use apenas VMs que tenham armazenamento premium.

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. Os tipos recomendados de VMs são NCv3 e NCasT4_v3. Se você precisar treinar usando YOLOv3, precisará de GPUs baseadas em Ampere. Use o NVadsA10 v5 ou NC A100 v4 para tarefas de treinamento maiores.

Para as máquinas GPU, recomendamos começar com o menor nó e aumentar a escala à medida que suas necessidades aumentam.

Para todas as outras máquinas, recomendamos configurar VMs em zonas de disponibilidade para oferecer suporte à alta disponibilidade. Configure os nós da seguinte maneira:

• Nós de controle. Um mínimo de uma VM por zona de disponibilidade dentro da região selecionada. Recomendamos uma contagem de vCPU de pelo menos 4. Nossa referência usa 3x Standard_D8s_v4 nós.

• Nós de trabalho. Um mínimo de duas máquinas por zona de disponibilidade dentro da região selecionada. Recomendamos uma contagem de vCPU de pelo menos 8. Nossa referência usa 6x Standard_D8s_v4 nós.

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, Gerenciar para 10 usuários requer mais 2 vCPUs. Recomendamos que você revise os requisitos de sistema do IBM Maximo Application Suite para obter uma boa estimativa de dimensionamento.

Tente manter os tipos de VMs semelhantes entre si para fornecer proximidade com cada uma das zonas de disponibilidade entre nós de trabalho e de controle. Ou seja, se você usar uma VM v4 para seus nós de controle, use também uma VM v4 para seus nós de trabalho.

Se você precisar de uma caixa de salto para usar a interface de linha de comando (oc) do OpenShift ou para instalar o MAS, implante uma VM que esteja executando o Red Hat Enterprise Linux versão 8.4.

Rede

Com o OpenShift, usamos o provedor de interface de rede de contêiner padrão (CNI) da rede definida por software (SDN) do OpenShift. Para obter mais informações sobre o OpenShift CNI padrão, consulte Operador de rede de cluster na plataforma de contêiner OpenShift. Você deve dimensionar sua rede para o número de nós de controle e trabalho OpenShift que você precisa, e também para quaisquer outros requisitos, como bancos de dados e contas de armazenamento.

Para uma instalação de produção MAS padrão, recomendamos uma rede virtual com o espaço de endereço que um prefixo CIDR (roteamento entre domínios sem classe) de /24 fornece. A rede virtual tem três ou quatro sub-redes (para o Azure Bastion). Para OpenShift, a sub-rede para os nós de trabalho tem um prefixo CIDR de /25 e os nós de controle têm um prefixo de /27. Uma sub-rede para pontos de extremidade e um servidor de banco de dados externo opcional devem ter um prefixo /27. Se você estiver implantando o Azure Bastion, que é opcional, precisará de uma sub-rede chamada AzureBastionSubnet com um prefixo /26. Para obter mais informações sobre os requisitos do Azure Bastion, consulte Arquitetura.

Se você tiver poucos endereços IP, poderá implementar uma configuração altamente disponível com um prefixo mínimo de /27 para a sub-rede de nós de controle e /27 para a sub-rede de nós de trabalho.

Se você quiser usar uma CNI diferente, dimensione suas redes de acordo. O MAS, com alguns aplicativos padrão, implanta mais de 800 pods, que provavelmente exigem um prefixo CIDR de /21 ou maior.

Especificidades da base de dados

Vários componentes do MAS usam o MongoDB como um armazenamento de metadados. A orientação padrão é implantar o MongoDB Community Edition dentro do cluster. Se você implantá-lo usando esse método, certifique-se de ter um procedimento adequado para fazer backup e restaurar o banco de dados. Considere usar o MongoDB Atlas no Azure, pois ele fornece um armazenamento externalizado, backups, dimensionamento e muito mais. Atualmente, o Azure não oferece suporte ao uso de APIs do MongoDB com o Azure Cosmos DB.

Se você implantar serviços de IoT, também precisará fornecer um ponto de extremidade Kafka. A orientação padrão é usar o Strimzi para implantar o Kafka dentro do cluster OpenShift. Durante uma recuperação de desastre, os dados dentro do Strimzi provavelmente serão perdidos. Se a perda de dados no Kafka for inaceitável, você deve considerar o uso do Confluent Kafka no Azure. Atualmente, os Hubs de Eventos do Azure com pontos de extremidade Kafka não são suportados.

O MAS vem embalado com muitos bancos de dados dentro de seus pods, e esses bancos de dados mantêm seus estados no sistema de arquivos fornecido para o MAS. Recomendamos o uso de um mecanismo de armazenamento com redundância de zona (ZRS) para reter os estados fora de seus clusters para poder absorver falhas de zona. Nosso padrão recomendado é usar o Armazenamento de Arquivos do Azure com as seguintes configurações:

• Standard. Fornece compartilhamentos SMB (Server Message Block) para cargas de trabalho ReadWriteOnce (RWO) e taxa de transferência mais baixas. O padrão é uma ótima opção para partes do aplicativo que não gravam no armazenamento com frequência e exigem um único volume persistente (por exemplo, armazenamento de nível único IBM).

• Premium. Fornece compartilhamentos NFS (Network File System) para cargas de trabalho de taxa de transferência e ReadWriteMany (RWX) mais altas. Volumes como esses são usados em todo o cluster para cargas de trabalho RWX, como o Db2 Warehouse no Cloud Pak for Data ou o Postgres no Manage.

Certifique-se de desabilitar as políticas para impor a transferência segura no Armazenamento de Blobs do Azure ou isentar as contas dessas políticas. Os Arquivos Premium do Azure com NFS exigem que a transferência segura seja desabilitada. Certifique-se de usar um ponto de extremidade privado para garantir conectividade privada para seus compartilhamentos.

Por padrão, o DB2 Warehouse é implantado sobre o OpenShift Data Foundation (anteriormente conhecido como OpenShift Container Storage). Por motivos de custo, desempenho, dimensionamento e confiabilidade, recomendamos o uso do Azure Premium Files com NFS em vez do OpenShift Data Foundation.

Não use o Armazenamento de Blobs do Azure com drivers CSI, porque ele não oferece suporte a links físicos, que são necessários. Alguns pods não podem ser executados sem links rígidos.

Considerações

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

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar 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.

O Azure fornece MAS usando os modelos de infraestrutura como serviço (IaaS) e PaaS. A Microsoft cria proteções de segurança no serviço nos seguintes níveis:

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

Avalie cuidadosamente os serviços e tecnologias selecionados para as áreas acima do hipervisor, como a versão corrigida mais recente do OpenShift para uma versão principal. Certifique-se de fornecer os controles de segurança adequados para sua arquitetura. Você é responsável por corrigir e manter a segurança dos sistemas IaaS. A Microsoft assume esse papel para os serviços PaaS.

Use grupos de segurança de rede para filtrar o tráfego de rede de e para recursos em sua rede virtual. Com esses grupos, você pode definir regras que concedem ou negam acesso aos seus serviços do MAS. Exemplos incluem:

• Permitir acesso SSH aos nós OpenShift para solução de problemas
• Bloquear o acesso a todas as outras partes do cluster
• Controle quais locais podem ter acesso ao MAS e ao cluster OpenShift

Se precisar de acesso às suas VMs por algum motivo, pode ligar-se através da sua conectividade híbrida ou através da consola de administração OpenShift. Se você tiver uma implantação online ou não quiser depender da conectividade, também poderá acessar suas VMs por meio do Azure Bastion (que é opcional). Por motivos de segurança, você não deve expor VMs a uma rede ou à Internet sem configurar grupos de segurança de rede para controlar o acesso a elas.

A criptografia do lado do servidor (SSE) do Armazenamento em Disco do Azure protege seus dados. Também ajuda a cumprir os compromissos organizacionais de segurança e conformidade. Com os discos gerenciados do Azure, o SSE criptografa os dados em repouso ao mantê-los na nuvem. Esse comportamento se aplica por padrão ao sistema operacional e aos discos de dados. O OpenShift usa SSE por padrão.

Autenticação

Atualmente, o MAS oferece suporte ao logon único (SSO) com SAML (Security Assertion Markup Language) no Microsoft Entra ID. Esse método de autenticação requer um aplicativo corporativo dentro do Microsoft Entra ID e permissões para modificar o aplicativo. Para obter mais informações, consulte Integração do Microsoft Entra SSO com o Maximo Application Suite.

Antes de configurar a autenticação baseada em SAML, recomendamos que você passe pela configuração IBM e pela configuração do Azure. Para obter informações sobre SAML com MAS, consulte SAML na documentação para MAS. Para obter informações sobre SAML com Azure, consulte Guia de início rápido: habilitar logon único para um aplicativo corporativo.

Você também deve configurar Open Authorization (OAuth) para OpenShift. Para obter mais informações, consulte Visão geral da autenticação e autorização na documentação do OpenShift.

Proteja a sua infraestrutura

Controle o acesso aos recursos do Azure que implementa. Cada assinatura do Azure tem uma relação de confiança com um locatário do Microsoft Entra. Use o RBAC (controle de acesso baseado em função) do Azure para conceder aos usuários em sua organização as permissões corretas para recursos do Azure. Conceda acesso ao atribuir funções do Azure a utilizadores ou grupos num determinado âmbito. O âmbito pode ser uma subscrição, um grupo de recursos ou um único recurso. Certifique-se de auditar todas as alterações na infraestrutura. Para obter mais informações sobre auditoria, consulte Log de atividades do Azure Monitor.

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.

Uma implantação padrão do MAS consiste nos seguintes componentes:

• 3 VMs de controle
• 6 VMs de trabalho
• 3 VMs de trabalho para o Db2 Warehouse
  • Você pode substituir o SQL Server em VMs do Azure em algumas configurações, em vez de usar o DB2 Warehouse.
• 2 contas de Armazenamento do Azure
• 2 zonas DNS
• 2 Balanceadores de carga
• Azure Bastion
• 1 VM de inspeção visual
  • Isso não é necessário, a menos que você esteja planejando executar a Inspeção Visual dentro do MAS.

Pode rever um exemplo de estimativa utilizando a nossa calculadora de custos. As configurações variam e você deve verificar sua configuração com sua equipe de dimensionamento IBM antes de finalizar sua implementação.

Fiabilidade

O OpenShift tem recursos integrados para autorrecuperação, dimensionamento e resiliência para garantir que o OpenShift e o MAS funcionem com sucesso. OpenShift e MAS foram projetados para peças que falham e se recuperam. Um requisito fundamental para que a autorrecuperação funcione é que haja nós de trabalho suficientes. Para se recuperar de uma falha de zona em uma região do Azure, seus nós de controle e de trabalho devem ser balanceados entre zonas de disponibilidade.

MAS e OpenShift usam armazenamento para persistir o estado fora do cluster Kubernetes. Para garantir que as dependências de armazenamento continuem a funcionar durante uma falha, você deve usar o armazenamento com redundância de zona sempre que possível. Esse tipo de armazenamento permanece disponível quando uma zona falha.

Como o erro humano é comum, você deve implantar o MAS usando o máximo de automação possível. Em nosso guia de início rápido, fornecemos alguns exemplos de scripts para configurar a automação completa de ponta a ponta.

Implementar este cenário

Antes de começar, recomendamos que você revise os requisitos de sistema do IBM Maximo Application Suite. Certifique-se de ter os seguintes recursos disponíveis antes de iniciar a implantação:

• Acesso a uma Subscrição do Azure com permissão de Leitor
• Registro do aplicativo ou nome da entidade de serviço que tenha permissões de Colaborador e Administrador de Acesso de Usuário para a assinatura
• Domínio ou subdomínio delegado a uma zona DNS do Azure
• Extraia segredo da Red Hat para implantar o OpenShift
• Chave de direito do MAS
• Arquivo de licença do MAS (criado após a instalação do MAS)
• Dimensionamento de cluster recomendado pela IBM
• Rede virtual existente ou uma nova rede virtual criada pelo IPI, dependendo das suas necessidades
• Requisitos de alta disponibilidade e recuperação de desastres para sua implantação específica
• Arquivo de configuração, install-config.yaml, para o instalador

Para obter um guia passo a passo para instalar o OpenShift e o MAS no Azure, incluindo como lidar com os pré-requisitos, consulte nosso guia de início rápido no GitHub.

Considerações sobre implementação

É melhor implantar cargas de trabalho usando infraestrutura como código (IaC) em vez de implantar manualmente cargas de trabalho, porque a implantação manual pode resultar em configuração incorreta. As cargas de trabalho baseadas em contêiner podem ser sensíveis a configurações incorretas, o que pode reduzir a produtividade.

Antes de criar seu ambiente, revise o guia de início rápido para entender os parâmetros de design. O guia de início rápido não se destina a uma implantação pronta para produção, mas você pode usar os recursos do guia para chegar a um mecanismo de nível de produção para implantação.

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

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

• David Baumgarten - Brasil | Arquiteto de Soluções Cloud Sênior
• Roeland Nieuwenhuis - Brasil | Arquiteto Principal de Soluções na Nuvem

Outros contribuidores:

• Gary Moore - Brasil | Programador/Redator

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

Para obter ajuda com os primeiros passos, consulte os seguintes recursos:

• Instalando o OpenShift no Azure
• Guia de início rápido: Maximo Application Suite no Azure
• Guia UPI OpenShift
• Requisitos para o Maximo
• 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 ao Azure NetApp Files
• Introdução ao Red Hat no Azure
• Portal do cliente Red Hat

Recursos relacionados

• Compartilhamento de arquivos na nuvem corporativa do Azure
• Introdução à manutenção preditiva na manufatura
• Implementar um aplicativo Java com a plataforma de aplicação empresarial (EAP) JBoss em um cluster ARO