Implantar 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 do OpenShift. Ele não entra em detalhes sobre como instalar o MAS. Para saber mais sobre o processo de instalação, consulte Como instalar o Maximo Application Suite no OperatorHub.

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

A carga de trabalho pode ser implantada internamente ou externamente, dependendo de seus requisitos.

Workflow

Do ponto de vista da infraestrutura, essa arquitetura fornece o seguinte:

• Uma plataforma de hospedagem de contêiner para implantar cargas de trabalho altamente disponíveis entre zonas de disponibilidade
• Uma implantação privatizada de nós de trabalho e controle integrados ao armazenamento
• Arquivos Premium do Azure e arquivos padrão para armazenamento (o 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 DNS do OpenShift e seus contêineres
• Microsoft Entra ID para logon único (SSO) no MAS

Componentes

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

• 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, 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 a sua solução esteja altamente disponível. O Azure Load Balancer tem redundância de 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 que hospedam os dados com 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.

• 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 acessar com segurança qualquer um dos nós de trabalho ou computadores JumpBox opcionais. O Azure Bastion é um serviço totalmente gerenciado que fornece acesso seguro e contínuo de RDP e SSH a VMs sem exposição por meio de endereços IP públicos.

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

• Twilio Send Grid (opcional) para enviar emails do MAS para seus consumidores.

• Máquinas virtuais Linux no Azure (opcional) para fornecer um jump box para instalação do OpenShift. Você também pode usar essa VM para se conectar e gerenciar o cluster do 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 de um computador existente.

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. O NetApp Files dá suporte a qualquer tipo de carga de trabalho com alta disponibilidade e alto desempenho.
• Oracle Database 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 MAS (Maximo Application Suite) da IBM, também conhecido como Maximo, é 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 em uma plataforma de aplicativo principal, MAS e aplicativos e soluções específicas do setor na parte superior da plataforma. Cada aplicativo fornece um benefício específico:

• Gerenciar. Reduza o tempo de inatividade e os custos usando o gerenciamento de ativos para melhorar o desempenho operacional.
• Monitorar. Use a IoT para monitoramento avançado de ativos remotos alimentados por IA em escala.
• Integridade. Gerencie a integridade do ativo usando dados de IoT de sensores, dados de ativos e histórico de manutenção.
• Inspeção visual. Treine modelos de machine learning para usar a inspeção visual para análise visual de problemas emergentes.
• Prever. Prever falhas futuras usando machine learning e análise de dados.
• Auxiliar. Ajude os técnicos fornecendo orientação baseada em IA para uma base de dados de conhecimento de manutenção de equipamentos e fornecendo-lhes acesso remoto a especialistas.
• Safety. Coletar e analisar dados de sensores, fornecer dados contextuais e derivar análises significativas.
• Civil. Integre 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.

Esses aplicativos e o 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 esteja configurada para ser executada de forma ideal 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 da IBM para obter perguntas específicas do produto. O Azure Marketplace oferece uma instalação alternativa para MAS que dá suporte à sua própria licença. Para obter informações adicionais, consulte IBM Maximo Application Suite (traga sua própria licença (BYOL)).

Possíveis casos de uso

Muitos setores e setores usam as soluções no MAS, como:

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

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

Recomendações

É recomendável 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 com suporte, pois as versões com suporte 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 o 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 as diretrizes, a arquitetura e o guia de início rápido forneç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 sua implantação, você precisa responder às seguintes perguntas sobre design:

• Quais aplicativos MAS você precisa?
• Quais dependências seus aplicativos têm?
• Qual versão do OpenShift é necessária?
• Qual método de instalação do OpenShift você deve usar?
• Quais bancos de dados são necessários?
• Qual número e tamanhos de VMs você precisa?
• Os usuários se conectarão de redes externas?

Maximo Application Suite

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

Examine os aplicativos MAS necessários para seu cenário de negócios completo e examine os requisitos de cada um dos aplicativos. Para obter mais informações, consulte requisitos do sistema 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 VMs 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 na Oracle Cloud Infrastructure usando a interconexão, mas essa não é uma configuração testada. Para obter mais informações sobre interconexão, consulte Saiba mais sobre como interconectar o Oracle Cloud com o Microsoft Azure. Atualmente, não há suporte para o Banco de Dados SQL do Azure, a Instância Gerenciada de SQL do Azure e o Azure Cosmos DB.

O MAS e alguns de seus aplicativos têm dependências no MongoDB e no 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, BAS, usam bancos de dados que não podem ser externalizados, mas que exigem que o armazenamento persistente seja fornecido para o cluster Do OpenShift.

Para serviços baseados em estado executados dentro do cluster do 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 adequadamente, especialmente ao executar Kafka ou MongoDB dentro do OpenShift.

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

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

OpenShift

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

• IPI (infraestrutura provisionada do instalador). Esse método usa um instalador para implantar e configurar o ambiente do OpenShift no Azure. A IPI é o método mais comum para implantação no Azure e você deve usar a IPI, a menos que seus requisitos de segurança sejam muito estritos para fazer isso.

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

É recomendável usar a IPI sempre que possível, pois reduz significativamente a quantidade de trabalho necessária para concluir a instalação do OpenShift.

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

• Seleção de região. É recomendável usar uma região com zonas de disponibilidade. Durante a implantação, o OpenShift tenta criar nós automaticamente entre zonas com base na configuração no arquivo de configuração, install-config.yaml. Por padrão, o OpenShift equilibra as 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 poderá continuar funcionando com nós em outras zonas que podem assumir o trabalho.

• Backup & recuperação. Você pode usar as instruções para o Red Hat OpenShift no Azure para backup e recuperação. Para obter mais informações, consulte Criar um Backup de Aplicativo de cluster do Red Hat OpenShift 4 do Azure. 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 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 gapped no ar

Em alguns casos, como para conformidade regulatória, você pode exigir uma instalação de MAS com gapped no ar no Azure. O ar gapped 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 de instalação em tempo de execução para a instalação do MAS ou do OpenShift.

Não recomendamos que você faça uma instalação com gapped a ar, 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 proteger contra vulnerabilidades de segurança e gerenciar um firewall podem se tornar muito demoradas.

Para obter mais informações sobre instalações com gapped a ar, 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 diretrizes semelhantes.

Dimensionamento de seu ambiente

Para todas as cargas de trabalho (exceto inspeção visual), recomendamos usar as VMs da série Ds mais recentes como nós de trabalho. Exemplos são Dsv3, Dasv4, Dsv4 ,Dasv5 ouDsv5 . É recomendável usar as versões mais recentes, quando possível, porque elas fornecem melhor desempenho. Use apenas VMs que tenham armazenamento Premium.

A Inspeção Visual Maximo requer nós de GPU para executar seu aprendizado de máquina. A solução usa CUDA e dá suporte apenas a 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 os computadores GPU, recomendamos começar com o menor nó e escalar verticalmente à medida que seus requisitos aumentam.

Para todos os outros computadores, recomendamos configurar VMs entre zonas de disponibilidade para dar 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 nós de Standard_D8s_v4.

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

O núcleo mas requer 13 vCPUs para uma instalação base 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, Gerenciar para 10 usuários requer outras 2 vCPUs. Recomendamos que você examine os requisitos do sistema IBM Maximo Application Suite para obter uma boa estimativa de dimensionamento.

Tente manter os tipos de VMs semelhantes uns aos outros para fornecer proximidade com cada uma das zonas de disponibilidade entre nós de trabalho e 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 um jump box para usar a interface de linha de comando do OpenShift (oc) ou 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 CNI (interface de rede de contêiner) padrão do SDN (rede definida por software) do OpenShift. Para obter mais informações sobre o CNI do OpenShift padrão, consulte o Operador de Rede de Cluster na Plataforma de Contêiner do OpenShift. Você deve dimensionar sua rede para o número de nós de trabalho e controle do OpenShift necessários e também para quaisquer outros requisitos, como bancos de dados e contas de armazenamento.

Para uma instalação de produção de MAS padrão, recomendamos uma rede virtual com o espaço de endereço que um prefixo de roteamento entre domínios sem classe (CIDR) de /24 fornece. A rede virtual tem três ou quatro sub-redes (para Bastion). Para o 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 deve ter um prefixo de /27. Se você estiver implantando o Azure Bastion, que é opcional, precisará de uma sub-rede chamada AzureBastionSubnet com um prefixo de /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 adequadamente. 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

Vários componentes do 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ê implantá-lo usando 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 no Azure, pois ele fornece um repositório externalizado, backups, dimensionamento e muito mais. No momento, o Azure não dá suporte ao uso de APIs do MongoDB com o Azure Cosmos DB.

Se você implantar serviços de IoT, será necessário também fornecer um ponto de extremidade kafka. A orientação padrão é usar Strimzi para implantar o Kafka dentro do cluster do 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ê deverá considerar o uso do Kafka do Confluent no Azure. Atualmente, os Hubs de Eventos do Azure com pontos de extremidade kafka não são suportados.

O MAS vem repleto de muitos bancos de dados dentro de seus pods, e esses bancos de dados retêm seus estados no sistema de arquivos fornecido para MAS. É recomendável usar um mecanismo de armazenamento com redundância de zona (ZRS) para manter 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 de taxa de transferência mais baixas e RWO (ReadWriteOnce). Standard é um ótimo ajuste para partes do aplicativo que não gravam com frequência no armazenamento e exigem um único volume persistente (por exemplo, armazenamento de nível único ibm).

• Premium. Fornece compartilhamentos NFS (Sistema de Arquivos de Rede) 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 in Manage.

Certifique-se de desabilitar 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 a conectividade privada com seus compartilhamentos.

Por padrão, o Db2 Warehouse é implantado na parte superior do OpenShift Data Foundation (anteriormente conhecido como Armazenamento de Contêiner do OpenShift). Por motivos de custo, desempenho, dimensionamento e confiabilidade, recomendamos o uso de Arquivos Premium do Azure com NFS em vez do OpenShift Data Foundation.

Não use o Blob do Azure com drivers CSI, pois ele não dá suporte a links rígidos, 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​, um conjunto de princípios orientadores que você pode usar para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira 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 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.

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

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

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

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

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

Se você precisar de acesso às suas VMs por algum motivo, poderá se conectar por meio de sua conectividade híbrida ou por meio do console de administração do OpenShift. Se você tiver uma implantação online ou não quiser confiar na conectividade, também poderá acessar suas VMs por meio do Azure Bastion (o 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 SSE (criptografia do lado do servidor) do Armazenamento em Disco do Azure protege seus dados. Ela também ajuda você a cumprir os compromissos organizacionais de segurança e conformidade. Com os discos gerenciados do Azure, a SSE criptografa os dados inativos ao persisti-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 atualmente dá suporte ao uso da SAML (Security Assertion Markup Language) por meio do Microsoft Entra ID. Para fazer isso funcionar, você precisa de um aplicativo empresarial no Microsoft Entra ID e de permissão para modificar o aplicativo ou da assistência de um administrador global que possa fazer as alterações necessárias.

O guia de início rápido no GitHub tem um tutorial sobre como configurar o SAML com o MAS. Para obter mais informações, consulte Habilitar a autenticação SAML no Microsoft Entra ID.

Antes de configurar a autenticação baseada em SAML, recomendamos que você examine a configuração da IBM e a configuração do Azure. Para obter informações sobre SAML com MAS, consulte SAML na documentação do MAS. Para obter informações sobre SAML com o Azure, consulte Início Rápido: Habilitar o logon único para um aplicativoempresarial.

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

Proteger a infraestrutura

Controle o acesso aos recursos do Azure que você implanta. Todas as assinaturas do Azure têm uma relação de confiança com um locatário do Microsoft Entra. Use o controle de acesso baseado em função para conceder as permissões corretas para recursos do Azure a usuários na sua organização. Conceda o acesso atribuindo funções do Azure a usuários ou grupos em um determinado escopo. O escopo pode ser uma assinatura, 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 o log de atividades do Azure Monitor.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

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 Microsoft 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.

Você pode examinar uma estimativa de exemplo usando nossa calculadora de custos. As configurações variam e você deve verificar sua configuração com sua equipe de dimensionamento da IBM antes de finalizar sua implantação.

Confiabilidade

O OpenShift tem funcionalidades internas para autorrecuperação, dimensionamento e resiliência para garantir que o OpenShift e o MAS funcionem com êxito. O OpenShift e o MAS foram projetados para partes que falham e se recuperam. Um requisito fundamental para a autorrecuperação funcionar é que haja nós de trabalho suficientes. Para se recuperar de uma falha de zona em uma região do Azure, o controle e os nós 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, 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 scripts de exemplo para configurar a automação completa de ponta a ponta.

Implantar este cenário

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

• Acesso a uma Assinatura do Azure com permissão de Leitor
• Registro do aplicativo ou nome do principal do serviço que tem permissões de Contribuinte e Administrador de acesso do usuário para a assinatura
• Domínio ou subdomínio delegado para uma zona DNS do Azure
• Efetuar pull do segredo do Red Hat para implantar o OpenShift
• Chave de direito mas
• Arquivo de licença MAS (criado após a instalação do MAS)
• Dimensionamento de cluster recomendado pela IBM
• Rede virtual existente ou uma nova rede virtual criada pela IPI, dependendo de seus requisitos
• Requisitos de alta disponibilidade e recuperação de desastre 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 de implantação

É melhor implantar cargas de trabalho usando iac (infraestrutura como código) em vez de implantar cargas de trabalho manualmente, pois 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.

Antes de criar seu ambiente, examine o guia de início rápido para desenvolver uma compreensão dos 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 ativos do guia para acessar um mecanismo de nível de produção para implantação.

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

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

• David Baumgarten | Arquiteto sênior de soluções de nuvem
• Roeland Nieuwenhuis | Arquiteto principal de soluções de nuvem

Outro colaborador:

• Gary Moore | Programador/escritor

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

Próximas etapas

Para obter ajuda com a introdução, consulte os seguintes recursos:

• Instalando o OpenShift no Azure
• Guia de Início Rápido: Maximo Application Suite no Azure
• Guia do OpenShift UPI
• Requisitos para Maximo
• IBM Maximo Application Suite (BYOL)

Para saber mais sobre as tecnologias em destaque, confira 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 do Red Hat

Recursos relacionados

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