Implantar o IBM Maximo Application Suite no Azure

Este artigo descreve a implantação do MAS (IBM Maximo Application Suite) em Azure. O MAS é executado no Red Hat OpenShift. Red Hat OpenShift no Azure (ARO) é a plataforma preferencial do OpenShift se atender aos seus requisitos operacionais, de segurança e de rede. Use o Red Hat OpenShift autogerenciado no Azure somente quando precisar de controle que o ARO não fornece, como padrões de implantação desconectados específicos ou personalização no nível do cluster.

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

Arquitetura

O diagrama a seguir ilustra uma implantação de MAS baseada em ARO em Azure.

Carrege um arquivo Visio desta arquitetura.

Você pode implantar a carga de trabalho como uma implantação interna ou externa, dependendo de seus requisitos. Este artigo não prescreve um modelo de implantação de ARO público ou privado. Escolha a arquitetura de plano de controle, entrada e saída com base na arquitetura da zona de destino Azure, incluindo sua topologia de rede, modelo de conectividade, controles de segurança, requisitos de acesso operacional, requisitos de conformidade e padrões de acesso do usuário mas.

Quando a IBM dá suporte a bancos de dados externos para os aplicativos MAS que você implanta, tente externalizar esses bancos de dados para reduzir o estado dentro do cluster do OpenShift e desacoplar o gerenciamento de banco de dados do gerenciamento de cluster.

Workflow

Do ponto de vista da infraestrutura, essa arquitetura fornece os seguintes recursos:

• Um serviço gerenciado Red Hat OpenShift no Azure para implantar cargas de trabalho altamente disponíveis em zonas de disponibilidade
• Um cluster do OpenShift integrado com Azure rede e armazenamento
• Arquivos do Azure Premium e Arquivos do Azure Standard para requisitos de armazenamento mas com suporte
• Instância Gerenciada de SQL do Azure ou IBM Db2 Warehouse baseado em contêiner
• DNS do Azure para gerenciamento de DNS (Sistema de Nomes de Domínio) do OpenShift e seus contêineres
• Microsoft Entra ID para autenticação única (SSO) no MAS

Componentes

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

• Máquinas Virtuais do Azure é uma IaaS (infraestrutura como serviço) que implanta recursos de computação sob demanda e escalonáveis. Use Máquinas Virtuais em vez de ARO para implantar o Red Hat OpenShift autogerenciado no Azure.

  Opcionalmente, use Azure VMs linux como jump boxes para instalação de MAS e administração do OpenShift. Se você tiver conectividade de rede privada em seu ambiente de Azure, poderá executar a administração de um computador protegido existente.

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

• Azure Load Balancer fornece conectividade com o cluster. Load Balancer é um serviço de balanceamento de carga de camada 4 de alto desempenho e de baixa latência para todos os protocolos UDP (Protocolo de Datagrama de Usuário) e TCP (Protocolo de Controle de Transmissão) de entrada e saída. Load Balancer pode lidar com milhões de solicitações por segundo, garantindo que sua solução esteja altamente disponível. Load Balancer é com redundância de zona, garantindo alta disponibilidade entre zonas de disponibilidade.

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

• Arquivos do Azure fornece compartilhamentos de arquivos totalmente gerenciados na nuvem que podem ser acessados por meio dos protocolos SMB (Bloco de Mensagens do Servidor) e NFS (Sistema de Arquivos de Rede). Use Arquivos do Azure para hospedar os dados com estado para os bancos de dados e sistemas dentro do cluster.

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

• Azure Bastion é um serviço totalmente gerenciado que fornece rdp (protocolo de área de trabalho remota) e acesso de shell seguro (SSH) a VMs sem qualquer exposição por meio de endereços IP públicos. Opcionalmente, use Azure Bastion e uma sub-rede para acesso de segurança aprimorada a qualquer um dos nós de trabalho ou computadores de jump box opcionais.

• Instância Gerenciada de SQL fornece serviços de dados externos ao MAS quando a IBM dá suporte a SQL Server para os aplicativos que você implanta. Você também pode escolher outro banco de dados, como Oracle Exadata ou IBM Db2 Warehouse. não há suporte para Banco de Dados SQL do Azure.

• O Twilio SendGrid envia emails do MAS para seus consumidores. Se sua implantação de MAS precisar de um serviço de email para cenários de notificação e expedição da força de trabalho, opcionalmente incorpore um serviço de email, como o Twilio SendGrid, em seu design.

Alternativas

Normalmente, os serviços a seguir não são necessários, mas são alternativas eficazes:

• Azure NetApp Files como um substituto para Arquivos do Azure. Azure NetApp Files dá suporte a cargas de trabalho que precisam de alta disponibilidade e alto desempenho.
• O Banco de Dados Oracle no Azure se houver suporte e você preferir.
• OpenShift Data Foundation se você quiser usar o Db2 Warehouse no OpenShift Data Foundation.

Detalhes do cenário

O IBM Maximo Application Suite é uma plataforma de gerenciamento de ativos corporativos com manutenção de ativos baseada em IA. O MAS se concentra na resiliência operacional e na confiabilidade. O pacote consiste na plataforma de aplicativos mas core e nos aplicativos a seguir e soluções específicas do setor que são criadas na plataforma.

• Maximo Manage. Reduz o tempo de inatividade e os custos usando o gerenciamento de ativos para melhorar o desempenho operacional.
• Maximo Monitor. Usa a IoT (Internet das Coisas) para monitoramento avançado de ativos remotos habilitados para IA em escala.
• Maximo Health. Gerencia a integridade do ativo usando dados de IoT de sensores, dados de ativos e histórico de manutenção.
• Inspeção visual maximo. Treina modelos de machine learning para usar a inspeção visual para análise visual de problemas emergentes.
• Maximo Predict. Prevê falhas futuras usando machine learning e análise de dados.
• Maximo Collaborate. Dá suporte a técnicos com orientação baseada em IA de uma base de dados de conhecimento de manutenção de equipamentos e fornece acesso remoto a especialistas.
• Maximo Health, Safety and Environment (HSE). Conecta processos de segurança, conformidade ambiental e controle de trabalho a ativos, locais e ordens de trabalho.
• Infraestrutura Civil Maximo. Integra atividades de inspeção, acompanhamento de defeitos e manutenção para ajudar a melhorar a vida útil dos ativos, manter sistemas críticos operacionais e reduzir os custos totais de propriedade da infraestrutura civil.
• Maximo Real Estate and Facilities. Gerencia portfólios imobiliários e ativos de instalação com gerenciamento de espaço, reservas, projetos de capital, avaliação de condição de instalação, gerenciamento de concessão, operações e manutenção.

Possíveis casos de uso

Muitos setores e setores usam soluções de MAS, como as seguintes áreas:

• Energia e serviços
• Óleo e gás
• Produção
• Viagens, automóveis e transporte
• Setor público

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

Recomendações

Este artigo é escrito para implantações de MAS 9.x com suporte no Azure. Microsoft trabalhou com a equipe do IBM MAS e outros parceiros para garantir que essa solução esteja configurada para ser executada de forma ideal e fornecer a melhor experiência em Azure. Esta documentação, arquitetura e diretrizes seguem as práticas recomendadas, conforme descrito no Microsoft Azure Well-Architected Framework. Entre em contato com sua equipe de conta ibm para obter perguntas específicas do produto e suporte além desta documentação.

Use este artigo para diretrizes de arquitetura quando você tiver suporte da IBM e de um parceiro para instalação. Azure também oferece um caminho de instalação para MAS que dá suporte a trazer sua própria licença. Para obter informações adicionais, consulte IBM Maximo Application Suite (traga sua própria licença (BYOL)).

Instale uma versão de MAS com suporte que a IBM lista como compatível com a versão do OpenShift e os aplicativos MAS selecionados. Para novas implantações de Azure, use o ARO como a plataforma preferencial do OpenShift, a menos que você exija um cluster autogerenciado.

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

Antes de criar sua implantação, examine a visão geral do IBM Maximo Application Suite, planejando instalar no Microsoft Azure e a documentação dos Relatórios de Compatibilidade de Produtos de Software (SPCR) para entender os requisitos atuais de implantação e configuração.

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

• Quais aplicativos MAS você precisa?
• Quais dependências seus aplicativos têm?
• Qual versão do OpenShift o IBM dá suporte para sua versão e aplicativos mas?
• A ARO atende aos seus requisitos ou você precisa do Red Hat OpenShift autogerenciado no Azure?
• De quais bancos de dados você precisa?
• Qual número e tamanhos de VMs você precisa?
• Os usuários precisam se conectar de redes externas?

Maximo Application Suite

Use uma versão mas 9.x com suporte atual e valide as versões, bancos de dados e dependências do OpenShift com suporte no IBM SPCR antes de finalizar a arquitetura. Se você estiver em uma versão anterior do Maximo Application Suite, examine o status do ciclo de vida da IBM e planeje uma atualização para uma versão mas 9.x com suporte.

Examine os aplicativos MAS necessários para seu cenário de negócios completo e examine os requisitos para cada um dos aplicativos. Para obter mais informações, consulte requisitos do sistema IBM Maximo Application Suite.

Cada aplicativo MAS pode precisar de um banco de dados separado. Tente externalizar bancos de dados se a IBM der suporte a um banco de dados externo para o aplicativo, pois essa abordagem reduz a quantidade de estado que você deve operar dentro do OpenShift. Microsoft e IBM testaram e dão suporte aos seguintes bancos de dados para MAS em Azure:

• Instância Gerenciada de SQL
• IBM Db2 Warehouse no Cloud Pak para Dados 5

não há suporte para Banco de Dados SQL do Azure e Azure Cosmos DB.

Você também pode optar por executar o Oracle Exadata na Oracle Cloud Infrastructure ou em uma VM usando uma interconexão. Essa configuração não é testada oficialmente, mas é supostamente bem-sucedida. Para obter mais informações sobre interconexão, consulte Interconnecting Oracle Cloud com Microsoft Azure.

O MAS e alguns de seus aplicativos dependem do MongoDB e do Kafka. Use as implantações padrão do Ibm no cluster MongoDB Community Edition e strimzi Kafka quando elas se ajustarem aos seus requisitos de suporte, backup e recuperação. Essa escolha é apropriada quando Kafka e MongoDB são dependências de MAS internas e sua solução não as usa fora do MAS.

Tente usar serviços gerenciados externos, como o MongoDB Atlas em Azure ou Confluent Cloud no Azure, quando precisar de operações de backup, dimensionamento ou recuperação de desastre mais fortes. Alguns pré-requisitos de MAS, como o BAS (Behavior Analytics Services), usam bancos de dados que não podem ser externalizados, mas exigem que o armazenamento persistente seja fornecido para o cluster OpenShift.

Para serviços baseados em estado executados dentro do cluster do OpenShift, faça backup regular dos dados e mova os backups para outra região. Projete, planeje e decida sobre uma estratégia de recuperação para desastres, especialmente quando você executa o Kafka ou o MongoDB no OpenShift. Para serviços que retêm o estado, use ofertas de PaaS (plataforma como serviço) de Azure externa, se possível, para melhorar a capacidade de suporte durante uma interrupção.

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

Red Hat OpenShift no Azure

Use o ARO como a plataforma openshift preferencial para MAS em Azure. O ARO fornece um serviço openshift gerenciado em Azure, o que reduz sua carga operacional para instalar, aplicar patch e operar a plataforma OpenShift. Você ainda possui o MAS e sua configuração de aplicativo, planejamento de capacidade de trabalho, integração de rede, integração de identidade, opções de armazenamento, proteção de dados e recuperação de desastre.

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

• Compatibilidade de versão. Selecione uma versão do OpenShift que o IBM lista como compatível com sua versão mas e aplicativos MAS selecionados. Confirme se a mesma versão do OpenShift está disponível e tem suporte do ARO em sua região de Azure de destino. Quando possível, selecione uma versão do OpenShift com numeração uniforme para implantações de MAS de produção, pois essas versões são versões de SUPORTE de Atualização Estendida (EUS ).

  Valide cruzadamente se a IBM dá suporte à versão do OpenShift selecionada para todos os aplicativos e dependências de MAS selecionados. Se um componente MAS listar uma versão mais recente do OpenShift com numeração ímpar como um requisito no IBM SPCR, valide o conjunto de componentes completo em relação ao IBM SPCR, ao suporte ao ciclo de vida do Red Hat e à disponibilidade da versão do ARO antes de escolher a versão do cluster.

• Caminho de implantação. Use um cluster ARO existente quando você tiver Azure controles operacionais, rede, identidade, armazenamento e zona de destino pré-existentes. Use o caminho de instalação do IBM Azure Marketplace quando quiser que a automação fornecida pela IBM crie ou reutilize a infraestrutura do OpenShift com suporte. Use o Red Hat OpenShift autogerenciado no Azure somente quando o ARO não atender às suas necessidades.

• Seleção de região. Use uma região que tenha zonas de disponibilidade , se possível. Configure nós de trabalho do ARO entre zonas quando a região de destino der suporte a esse padrão. Para o OpenShift autogerenciado, configure o arquivo de instalação, install-config.yaml, para que o OpenShift coloque nós entre zonas. Se houver uma interrupção em uma zona, sua solução poderá continuar funcionando fazendo com que nós em outras zonas assumam o trabalho.

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

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

OpenShift autogerenciado

Use o Red Hat OpenShift autogerenciado no Azure se o ARO não atender aos requisitos de controle, isolamento ou implantação desconectado. Para implantações autogerenciadas, escolha entre os seguintes métodos de instalação:

• IPI (infraestrutura provisionada do instalador). Esse método usa um instalador para implantar e configurar o ambiente do OpenShift no Azure. Use a IPI quando atender aos requisitos de segurança e rede.

• Infraestrutura provisionada pelo usuário (UPI). Esse método permite que você tenha controle refinado sobre sua implantação. A UPI exige mais etapas e considerações para configurar seu ambiente. Use o UPI se a IPI ou a ARO não atenderem às suas necessidades. Uma instalação privada ou desconectada é um caso de uso comum para UPI.

Instalação com gapped no ar

Alguns casos, como a conformidade regulatória, podem exigir uma instalação de MAS com gapped no ar em Azure. A gapped no ar significa que não há acesso à Internet de entrada ou de saída. Sem uma conexão com a Internet, sua instalação não pode recuperar as dependências para a instalação do MAS ou do OpenShift em runtime.

Use uma instalação com gapped a ar somente se for um requisito de segurança. Uma lacuna de ar adiciona complexidade significativa às operações de solução. Atividades como instalar software, espelhar contêineres, atualizar espelhos para proteger contra vulnerabilidades de segurança ou gerenciar firewalls podem consumir esforço operacional significativo.

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

• Espelhamento de imagens para uma instalação desconectada usando oc-mirror
• Instalando um cluster privado em Azure

Após uma instalação do OpenShift com gapped no ar, você pode continuar com a documentação de MAS para obter diretrizes sobre ambientes desconectados.

Dimensionamento de nó e ambiente

Para todas as cargas de trabalho, exceto a Inspeção Visual maximo, comece com famílias de VM da série Ds ou Das de geração atual, como Dsv6, que estão disponíveis como nós de trabalho na região escolhida. Escolha tamanhos de VM que dão suporte ao armazenamento premium e atendam aos requisitos de CPU, memória e armazenamento para os aplicativos MAS implantados.

Maximo Visual Inspection requer nós de GPU para realizar seu aprendizado de máquina. A solução usa CUDA e dá suporte apenas a GPUs NVIDIA. Para a ARO, escolha um tamanho de VM de GPU NVIDIA na lista de suporte atual do nó de trabalho do ARO e confirme se a IBM dá suporte a ela para as versões mas e OpenShift. Para o OpenShift autogerenciado, escolha um tamanho de VM de GPU NVIDIA compatível com IBM e Red Hat.

Para nós de trabalho de GPU, comece com o menor nó e aumente conforme seus requisitos aumentarem.

Para a ARO e o OpenShift autogerenciado, use as mesmas diretrizes de dimensionamento de carga de trabalho mas para nós de trabalho. Configure nós de trabalho entre zonas de disponibilidade para dar suporte à alta disponibilidade. Para o OpenShift autogerenciado, configure também o plano de controle entre zonas de disponibilidade. Use o seguinte ponto de partida:

• Nós de controle. Para a ARO, o plano de controle é gerenciado como parte do serviço. Para o OpenShift autogerenciado, use um mínimo de uma VM por zona de disponibilidade dentro da região selecionada.

• Nós trabalhadores. Use um mínimo de dois computadores por zona de disponibilidade na região selecionada. Dimensionar nós de trabalho com base nas diretrizes da IBM, aplicativos MAS selecionados e carga esperada.

O núcleo do MAS exige 13 vCPUs para uma instalação básica de tamanho padrão. O dimensionamento dos nós de trabalho varia de acordo com quais aplicativos MAS sua configuração implanta e a carga em seu ambiente. Por exemplo, o Maximo Manage para 10 usuários requer outras 2 vCPUs. Trate esses valores como pontos iniciais e valide o dimensionamento em relação aos requisitos atuais do sistema IBM Maximo Application Suite para sua versão mas 9.x, aplicativos selecionados e uso esperado.

Para o OpenShift autogerenciado, tente manter os tipos de VM semelhantes uns aos outros para fornecer proximidade com cada uma das zonas de disponibilidade entre nós de trabalho e controle. Para a ARO, alinhe os pools de nós de trabalho aos mesmos requisitos de carga de trabalho mas e Azure capacidade regional.

Se você precisar de um jump box para usar a interface de linha de comando do OpenShift oc ou instalar o MAS, implante uma VM linux com suporte que atenda aos requisitos administrativos e de segurança da sua organização.

Configuração de rede

Para a ARO, use a configuração de rede padrão do OpenShift implantada pelo ARO, a menos que IBM, Red Hat e sua equipe de rede validem outra opção. Planeje a rede virtual e as sub-redes separadas para nós do plano de controle ARO, nós de trabalho, dependências de serviço Azure, pontos de extremidade privados, bancos de dados e conectividade híbrida. Dimensione as sub-redes do nó para o número de nós de trabalho do OpenShift necessários, incluindo capacidade de atualização e expansão futura.

Para o OpenShift autogerenciado, inclua também os requisitos de infraestrutura criada por inicialização e instalador. Mantenha o acesso administrativo à API do OpenShift e aos nós limitados a caminhos de rede aprovados, como conectividade híbrida, hosts de salto protegidos ou outros controles necessários à sua organização. Se você restringir a saída do cluster, planeje as dependências de saída necessárias para o OpenShift, instalação de MAS, pulls de imagem de contêiner, atualizações, monitoramento e serviços externos.

Para uma instalação de produção de MAS padrão no ARO, não comece com uma rede virtual bem lotada. Reserve um espaço de endereço maior, como um prefixo CIDR (roteamento de Inter-Domain sem classe) de /16 quando a zona de destino permitir e alocar sub-redes dedicadas. Use pelo menos um tamanho de planejamento /24 para a sub-rede do plano de controle ARO e pelo menos um tamanho de planejamento /24 para a sub-rede do nó de trabalho. Adicione uma sub-rede /27 ou maior para pontos de extremidade privados e serviços de banco de dados externos. Se você implantar Azure Bastion opcionalmente, adicione uma sub-rede chamada AzureBastionSubnet com um prefixo de /26. Para obter mais informações sobre Azure Bastion requisitos, consulte Arquitetura.

Se você usar o OpenShift autogerenciado e tiver poucos endereços IP, poderá criar uma configuração altamente disponível restrita com um prefixo mínimo de /27 para a sub-rede do nó de controle e /27 para a sub-rede do nó de trabalho. Não use esse dimensionamento restrito como ponto de partida para uma implantação de produção de ARO. Não subespasize as sub-redes de rede virtual ou de nó. A readressão de uma implantação do OpenShift após a instalação é disruptiva e pode exigir reimplantação.

Se você quiser usar uma CNI (Interface de Rede de Contêiner) diferente, dimensione suas redes adequadamente. O MAS com alguns aplicativos padrão implanta mais de 800 pods, o que provavelmente exige um prefixo CIDR de /21 ou maior.

Específicos do banco de dados

Alguns componentes mas usam o MongoDB como um repositório de metadados. A orientação padrão é implantar o MongoDB Community Edition dentro do cluster. Se você usar esse método, verifique se você tem um procedimento adequado para fazer backup e restaurar o banco de dados. Considere usar o Atlas do MongoDB em Azure para fornecer um repositório externo, backups e dimensionamento. Azure atualmente não dá suporte ao uso de APIs do MongoDB com Azure Cosmos DB.

Se você implantar serviços de IoT, também deverá fornecer um ponto de extremidade kafka. A orientação padrão é usar Strimzi para implantar o Kafka dentro do cluster OpenShift, mas os dados dentro do Strimzi provavelmente serão perdidos durante a recuperação de desastre. Se a perda de dados no Kafka for inaceitável, considere usar o Confluent Kafka no Azure. Atualmente, não há suporte para Hubs de Eventos do Azure com pontos de extremidade kafka.

O MAS inclui vários bancos de dados em seus pods e esses bancos de dados retêm seus estados no sistema de arquivos fornecido para MAS. Para absorver falhas de zona, use um mecanismo de ZRS (armazenamento com redundância de zona) para manter os estados fora de seus clusters. O padrão recomendado é usar Azure Armazenamento de Arquivos com as seguintes configurações:

• A Standard fornece compartilhamentos SMB para cargas de trabalho de taxa de transferência e RWO (ReadWriteOnce). Use o Standard para partes do aplicativo que não gravam no armazenamento com frequência e exigem um único volume persistente, como o armazenamento de nível único da IBM.

• O Premium fornece compartilhamentos NFS para cargas de trabalho de taxa de transferência mais alta e RWX (ReadWriteMany). 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 Postgres no Maximo Manage.

Arquivos do Azure NFS dá suporte à criptografia em trânsito. Se o cliente MAS OpenShift não puder usar a criptografia NFS, você poderá isentar a conta de políticas de imposição de transferência segura. Para obter mais informações, consulte NFS Azure compartilhamentos de arquivos: Criptografia. Use um ponto de extremidade privado para fornecer conectividade privada aos seus compartilhamentos.

Se você implantar o Db2 Warehouse por meio do Cloud Pak for Data, use o OpenShift Data Foundation. Para obter um exemplo do OpenShift Data Foundation que usa classes de armazenamento CephFS (Sistema de Arquivos Ceph) e RADOS Block Device (Ceph RBD) para diferentes tipos de dados do Db2 Warehouse, consulte Criando a instância Db2 usando o console cloud Pak for Data.

Não use Armazenamento de Blobs do Azure com drivers CSI (Interface de Armazenamento de Contêiner), pois ele não dá suporte a links rígidos, que alguns pods precisam executar.

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.

Confiabilidade

O OpenShift tem funcionalidades internas para autorrecuperação, dimensionamento e resiliência. O OpenShift e o MAS esperam que os componentes falhem e se recuperem. Um requisito fundamental para a autorrecuperação é que o cluster tenha nós de trabalho suficientes. Para se recuperar de uma falha de zona em uma região Azure, os nós de controle e de trabalho devem ser equilibrados entre zonas de disponibilidade.

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

Para ajudar a evitar erros humanos, implante o MAS usando o máximo de automação possível. Use a documentação de instalação atual da IBM e a automação com suporte para sua versão de MAS selecionada, a plataforma OpenShift e o caminho de implantaçã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 com eficiência 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 proteger todos os dados que são movidos para dentro e para fora da arquitetura.

Usando implantações de ARO, você se beneficia do modelo de responsabilidade compartilhada do ARO. Red Hat OpenShift no Azure é projetado em conjunto, operado e suportado por Microsoft e Red Hat, que patch, atualização e monitore a plataforma OpenShift gerenciada em seu nome. Você permanece responsável por implantações em cima do ARO. Essa responsabilidade inclui mas e sua configuração de aplicativo, integração de identidade, controles de rede, planejamento de capacidade de trabalho, opções de armazenamento, backup e recuperação de desastre, segredos, proteção de dados e requisitos de conformidade. Para obter mais informações, consulte Introdução à política de suporte Red Hat OpenShift no Azure e Red Hat OpenShift no Azure 4.0.

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

• Datacenter físico
• Rede física
• Host físico
• Hipervisor

Use uma versão do OpenShift compatível com a plataforma OpenShift e que a IBM dê suporte para sua versão e aplicativos mas. Quando possível, use uma versão de suporte de longo prazo com suporte. Se você usar o OpenShift autogerenciado, será responsável por aplicar patch e manter a plataforma OpenShift e as VMs subjacentes. Se você usar o ARO, Microsoft manipulará a aplicação de patch e o gerenciamento.

Use os grupos de segurança de rede para filtrar o tráfego de rede para e de recursos em uma rede virtual. Usando esses grupos, você pode definir regras que concedem ou negam acesso aos serviços de MAS, como:

• Permitindo o acesso SSH aos nós do OpenShift para solução de problemas.
• Bloquear o acesso a todas as outras partes do cluster.
• Controlando quais locais podem acessar o MAS e o cluster do OpenShift.

Para acessar suas VMs, você pode se conectar por meio da conectividade híbrida ou por meio do console de administração do OpenShift. Se você tiver uma implantação online ou não quiser depender da conectividade híbrida, poderá acessar suas VMs por meio de Azure Bastion. Por motivos de segurança, não exponha as VMs a uma rede ou à Internet sem configurar grupos de segurança de rede para controlar o acesso.

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

Autenticação

O MAS dá suporte ao SSO com SAML (Security Assertion Markup Language). Para usar Microsoft Entra ID como provedor de identidade SAML, crie um aplicativo empresarial no Microsoft Entra ID e configure o MAS como o provedor de serviços. Para obter mais informações, consulte Integração do SSO do Microsoft Entra com o Maximo Application Suite.

Antes de configurar a autenticação baseada em SAML, examine a configuração da IBM e a configuração do Azure. Para obter informações sobre SAML com MAS, consulte Configurando a autenticação SAML. Para obter informações sobre o SAML com Azure, consulte Quickstart: Habilitar o logon único para um aplicativo empresarial.

Você também deve configurar o OAuth para acesso administrativo do OpenShift. Para ARO, consulte Configurar Microsoft Entra autenticação para um cluster Red Hat OpenShift no Azure. Para o OpenShift autogerenciado, consulte Configurando provedores de identidade na Plataforma de Contêiner do OpenShift 4.21.

Acesso a recursos e auditoria

Controlar o acesso aos recursos de Azure que você implanta. Cada assinatura do Azure tem uma relação de confiança com um locatário Microsoft Entra. Use o Azure RBAC (controle de acesso baseado em função do Azure) para conceder as permissões corretas para recursos do Azure a usuários em sua organização. Conceda acesso atribuindo Azure funções a usuários ou grupos em um determinado escopo, como uma assinatura, um grupo de recursos ou um único recurso. Audite todas as alterações na infraestrutura. Para obter mais informações sobre auditoria, consulte Azure Monitor log de atividades.

Otimização de custo

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

Uma implantação de MAS padrão em Azure inclui os seguintes drivers de custo primário:

• Custos do cluster ARO, incluindo nós de trabalho e quaisquer encargos de plano de controle ou cluster faturáveis
• Pools de nós de trabalho dimensionados para o MAS Core e os aplicativos MAS que você implanta
• Nós de trabalho opcionais de GPU para Inspeção Visual maximo
• Serviços de banco de dados, como Instância Gerenciada de SQL, Db2 Warehouse ou outro banco de dados com suporte da IBM
• Contas de armazenamento ou serviços de armazenamento gerenciado para volumes persistentes, backups e artefatos de instalação
• Zonas DNS, balanceamento de carga, pontos de extremidade privados e uma instância opcional de Azure Bastion

Para o ARO e o OpenShift autogerenciado, uma implantação de MAS padrão normalmente usa a mesma linha de base de dimensionamento de nó de trabalho. Use o inventário a seguir como ponto de partida para estimativa de custo:

• Seis VMs de trabalho.
• Três VMs de trabalho para o Db2 Warehouse. Você pode substituir Instância Gerenciada de SQL 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ó de trabalho da GPU de Inspeção Visual maximo, se você planeja executar a Inspeção Visual Maximo dentro do MAS.

O custo do plano de controle difere por modelo de implantação. Para implantações autogerenciadas do OpenShift que usam IPI ou UPI, inclua também três VMs de controle. Para a ARO, contabilize o plano de controle gerenciado e quaisquer encargos de cluster específicos do ARO em vez de adicionar VMs de controle gerenciado pelo cliente.

Você pode examinar uma estimativa de exemplo usando a calculadora de custos. As configurações variam, portanto, verifique sua configuração com sua equipe de dimensionamento da IBM antes de finalizar sua implantação.

Implantar este cenário

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

• Acesso a uma assinatura Azure com a permissão Leitor
• Um nome de entidade de serviço ou registro de aplicativo que tenha permissões de Administrador de Acesso de Usuário e Colaborador para a assinatura
• Um domínio ou subdomínio delegado para uma zona de DNS do Azure
• Um cluster ARO com suporte ou as permissões e os pré-requisitos para criar um
• Um segredo de pull do Red Hat se o caminho de implantação criar ou gerenciar a infraestrutura do OpenShift
• Uma chave de direito mas
• Um arquivo de licença MAS que você cria após a instalação do MAS
• Dimensionamento de cluster recomendado pela IBM
• Uma rede virtual existente ou uma nova rede virtual que atenda aos requisitos de ARO e MAS
• Requisitos de alta disponibilidade e recuperação de desastre para sua implantação específica
• Detalhes de configuração do caminho de implantação selecionado, como detalhes do cluster ARO ou parâmetros de instalação do OpenShift autogerenciado

Antes de criar seu ambiente, examine o IBM Planning para instalar Microsoft Azure documentação para entender os parâmetros de design. Para obter as diretrizes atuais de instalação do Azure, consulte Maximo Application Suite em Microsoft Azure visão geral. Valide seu processo de implantação na documentação atual da IBM e na matriz de suporte para sua versão de MAS.

Considerações de implantação

Implante cargas de trabalho usando iac (infraestrutura como código) em vez de manualmente. A implantação manual pode resultar em configuração incorreta. Cargas de trabalho baseadas em contêiner podem ser sensíveis à configuração incorreta, o que pode reduzir a produtividade.

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

Colaboradores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Principais autores:

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

Para ver perfis de LinkedIn não públicos, entre em LinkedIn.

Próximas etapas

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

• Red Hat OpenShift no Azure
• Visão geral do Maximo Application Suite no Microsoft Azure
• Planejando a instalação no Microsoft Azure
• Instalando o OpenShift no Azure
• Guia do OpenShift UPI
• Requisitos para Maximo
• Relatórios de compatibilidade do produto ibm software
• IBM Maximo Application Suite (BYOL)

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

• Vantagem do IBM Passport
• Introduction para DNS do Azure
• Introduction para Azure NetApp Files
• Introdução ao Red Hat OpenShift no Azure
• Portal do Cliente do Red Hat

Recursos relacionados

• Azure compartilhamento empresarial de arquivos em nuvem
• Implante um aplicativo Java com a plataforma de aplicações empresariais JBoss (EAP) em um cluster ARO