Partilhar via

AIX UNIX local para migração do Azure Linux

Azure NetApp Files
Azure Site Recovery
Base de Dados SQL do Azure
Máquinas Virtuais do Microsoft Azure
Rede Virtual do Azure

Esta solução descreve uma migração de uma plataforma Unix IBM AIX para o Red Hat Enterprise Linux (RHEL) no Azure. O exemplo do mundo real foi um aplicativo de Saúde e Serviços Humanos para um grande cliente. O baixo tempo de transação e a latência eram requisitos importantes para os sistemas herdados e do Azure. Uma funcionalidade importante é armazenar informações do cliente em um banco de dados que se vincula a um armazenamento de arquivos de rede contendo imagens gráficas relacionadas. O Azure atende a essa necessidade com os Arquivos NetApp do Azure.

Arquitetura

O diagrama a seguir mostra a arquitetura do sistema herdado AIX local pré-migração:

Diagrama que mostra a arquitetura do sistema AIX pré-migração.

Transfira um ficheiro do Visio desta arquitetura.

  • Os dispositivos de rede fornecem uma extensa camada de roteamento de rede e balanceamento de carga (A).

  • A camada de apresentação (B) usa três máquinas web front-end Java em sua própria sub-rede, que segmenta o tráfego de rede por firewalls.

  • Os firewalls (C) fornecem limites de rede entre todos os níveis e subsistemas participantes. Embora os firewalls sejam eficazes, também representam um fardo administrativo.

  • O sistema fornece solicitações de usuário para a camada de aplicativo (D), que tem três servidores de aplicativos Web.

  • A camada de aplicativo chama o banco de dados DB2 e o NAS (Network Attached Storage, armazenamento conectado à rede):

    • O banco de dados (E) é DB2 no AIX. Três servidores DB2 são configurados em um cluster de alta disponibilidade/recuperação de desastres (HA/DR).

    • O aplicativo armazena objetos binários como imagens e PDFs para clientes e usuários em um subsistema NAS (F).

  • Os servidores de gerenciamento e administração e os servidores MQ (G) estão em sua própria sub-rede, segmentados por firewalls.

  • Os serviços de gerenciamento de identidade (H) do Lightweight Directory Access Protocol (LDAP) estão em sua própria sub-rede, segmentados por firewalls.

O diagrama a seguir mostra a arquitetura do sistema de pós-migração do Azure RHEL:

Diagrama que mostra a arquitetura do Azure pós-migração.

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de dados

  1. Tráfego para as rotas do sistema Azure através do Azure ExpressRoute e do Azure Traffic Manager:

    • O ExpressRoute fornece uma conexão privada segura e confiável com redes virtuais do Azure. O ExpressRoute se conecta ao Azure com baixa latência, alta confiabilidade e velocidade e larguras de banda de até 100 Gbps.
    • O Gerenciador de Tráfego distribui o tráfego de aplicativos voltado para o público entre as regiões do Azure.

  2. Uma camada de gerenciamento de rede fornece segurança de ponto final, roteamento e serviços de balanceamento de carga. Essa camada usa o Azure Load Balancer e o Azure Web Application Firewall.

  3. O Serviço de Aplicativo do Azure serve como a camada de apresentação. O Serviço de Aplicativo é uma camada de plataforma como serviço (PaaS) para aplicativos .NET ou Java. Você pode configurar o Serviço de Aplicativo para disponibilidade e escalabilidade dentro e entre regiões do Azure.

  4. A solução encapsula cada camada de aplicativo em sua própria rede virtual, segmentada com grupos de segurança de rede.

  5. Os conjuntos de disponibilidade e o Armazenamento compartilhado do Azure fornecem HA e escalabilidade para máquinas virtuais (VMs) no nível da camada de aplicativo. Os servidores de cluster de aplicativos compartilham o estado da transação e aumentam a escala das VMs conforme necessário.

  6. O aplicativo usa uma conexão de ponto de extremidade privada para armazenar e acessar dados no Banco de Dados SQL do Azure. O Banco de dados SQL é executado em uma configuração de continuidade de negócios, que fornece grupos de replicação geográfica e failover automático para BCDR automático e entre geografias.

  7. Os Arquivos NetApp do Azure fornecem um NAS compartilhado, com acesso rápido a dados binários e replicação para a região secundária.

  8. A região secundária fornece ao BCDR os seguintes componentes:

    • O Azure Site Recovery faz backup de imagens de VM para failover de DR em uma configuração ativo-passivo. O Site Recovery cria réplicas de imagens de VM consistentes na região secundária e mantém as imagens de VM sincronizadas.
    • A configuração de continuidade de negócios do Banco de dados SQL mantém as transações do banco de dados consistentes. O Banco de dados SQL provisiona bancos de dados de réplica e os mantém sincronizados com a replicação de dados síncrona ou assíncrona.

O sistema também contém os seguintes componentes:

  • Uma ou mais VMs na rede virtual de gerenciamento fornecem funcionalidade de gerenciamento e administração.

  • O Barramento de Serviço do Azure implementa a infraestrutura da Série MQ e fornece serviços de fila de mensagens para os aplicativos. Para obter mais informações sobre como migrar da MQ Series para o Azure Service Bus, consulte Migrar do ActiveMQ para o Azure Service Bus.

  • O Microsoft Entra ID fornece gerenciamento de identidade e acesso para todas as entidades do Azure e identidades migradas dos serviços LDAP herdados.

Componentes

  • O Azure ExpressRoute é um serviço que estende uma rede local para os serviços de nuvem da Microsoft por meio de uma conexão privada facilitada por um provedor de conectividade. Nessa arquitetura, o ExpressRoute fornece uma conexão privada segura e confiável com o sistema Azure, com baixa latência e alta velocidade e largura de banda.

  • O Azure Traffic Manager é um balanceador de carga de tráfego baseado em DNS (sistema de nomes de domínio) que distribui o tráfego entre as regiões do Azure. Nessa arquitetura, o Gerenciador de Tráfego distribui o tráfego de aplicativos voltado para o público entre regiões do Azure com alta disponibilidade e capacidade de resposta rápida.

  • O Azure Load Balancer dá suporte à alta disponibilidade distribuindo o tráfego de rede de entrada entre VMs back-end de acordo com regras de balanceamento de carga e testes de integridade configurados. O Load Balancer opera na camada 4 do modelo OSI (Open Systems Interconnection). Nessa arquitetura, o Balanceador de Carga funciona com o Azure Web Application Firewall para fornecer a camada de gerenciamento de rede que substitui os dispositivos de rede herdados.

  • O Firewall de Aplicativo Web do Azure é um serviço nativo da nuvem que protege aplicativos Web contra ataques mal-intencionados e vulnerabilidades. Nessa arquitetura, ele fornece segurança e proteção de endpoint e substitui os vários firewalls que segmentam o tráfego de rede no sistema AIX herdado.

  • O Serviço de Aplicativo do Azure é um serviço de hospedagem Web totalmente gerenciado para implantar aplicativos Web corporativos para qualquer plataforma em uma infraestrutura de nuvem escalável e confiável. Nessa arquitetura, o Serviço de Aplicativo atua como a camada de apresentação. Ele substitui as máquinas web front-end Java e fornece recursos PAAS para aplicativos .NET ou Java.

  • As Máquinas Virtuais do Azure são um serviço que fornece recursos de computação escaláveis sob demanda. As Máquinas Virtuais fornecem a flexibilidade da virtualização sem ter que comprar e manter hardware físico. Nessa arquitetura, o serviço hospeda os servidores de camada de aplicativo em conjuntos de disponibilidade que têm armazenamento compartilhado.

  • A Rede Virtual do Azure é a base para as redes privadas do Azure. A Rede Virtual fornece benefícios de infraestrutura do Azure, como escalabilidade, disponibilidade e isolamento. Nessa arquitetura, a Rede Virtual permite que os recursos do Azure, como VMs, se comuniquem com segurança entre si, com a Internet e com redes locais.

  • Os Arquivos do Azure fornecem compartilhamentos de arquivos totalmente gerenciados na nuvem que podem ser acessados por meio do protocolo SMB (Server Message Block) padrão do setor. As implantações de Windows, Linux e macOS locais e na nuvem podem montar compartilhamentos de arquivos do Azure simultaneamente. Nessa arquitetura, o Azure Files fornece recursos de armazenamento de arquivos compartilhados como parte da estratégia geral de armazenamento para o aplicativo migrado.

  • O Banco de Dados SQL do Azure é um PaaS de banco de dados totalmente gerenciado que sempre é executado no sistema operacional mais recente e na versão mais estável do mecanismo de banco de dados do SQL Server para fornecer a mais alta disponibilidade. Nessa arquitetura, o Banco de dados SQL lida com funções de gerenciamento de banco de dados, como atualizações, patches, backups e monitoramento, sem o envolvimento do usuário.

  • O Azure NetApp Files fornece compartilhamentos de arquivos do Azure de nível empresarial com tecnologia NetApp. Essa arquitetura usa os Arquivos NetApp do Azure para ajudar as empresas a migrar e executar facilmente aplicativos complexos baseados em arquivos sem alterações de código.

  • O Azure Site Recovery é um serviço de DR nativo do Azure. Nessa arquitetura, o Site Recovery implanta processos de replicação, failover e recuperação para ajudar a manter os aplicativos em execução durante interrupções planejadas e não planejadas.

  • O Barramento de Serviço do Azure é um serviço de mensagens na nuvem confiável com integração híbrida simples. Nessa arquitetura, o Service Bus fornece serviços de fila de mensagens para os aplicativos.

  • O Microsoft Entra ID é um serviço de gerenciamento de acesso e identidade empresarial baseado em nuvem da Microsoft. Nessa arquitetura, o logon único e a autenticação multifator do Microsoft Entra ajudam os usuários a entrar e acessar recursos, ao mesmo tempo em que fornecem proteção contra ataques de segurança cibernética.

Alternativas

Os ambientes do Serviço de Aplicativo do Azure são apropriados para cargas de trabalho de aplicativos que exigem alta escala, isolamento e acesso seguro à rede. Esse recurso oferece ambientes totalmente isolados e dedicados para executar aplicativos do Serviço de Aplicativo com segurança em alta escala. Os ambientes do Serviço de Aplicativo podem hospedar os seguintes tipos de aplicativos:

  • Aplicativos web Linux, como no exemplo atual
  • Aplicações Web do Windows
  • Contentores do Docker
  • Aplicações móveis
  • Funções

Detalhes do cenário

Uma diferença distinta entre o sistema legado e a implementação na nuvem está no tratamento da segmentação da rede. O sistema legado segmentou redes com firewalls. Uma plataforma de nuvem como o Azure segmenta redes com redes virtuais e grupos de segurança de rede que filtram o tráfego com base em vários critérios.

Outra diferença entre os sistemas é a alta disponibilidade (HA) e os modelos de recuperação de desastres (DR). No sistema legado, o HA/DR usava principalmente backups e, até certo ponto, usava servidores redundantes no mesmo datacenter. Essa configuração fornecia DR modesta, mas quase nenhum recurso de HA. Melhorar o HA/DR foi um fator-chave para a mudança para a plataforma Azure. O Azure usa clustering, armazenamento compartilhado e Azure Site Recovery para fornecer um alto nível de HA/DR.

Potenciais casos de utilização

Os principais drivers para mover do IBM AIX local para o RHEL no Azure podem incluir os seguintes fatores:

  • Hardware atualizado e custos reduzidos. No local, os componentes de hardware herdados ficam continuamente desatualizados e sem suporte. Os componentes da nuvem estão sempre atualizados. Os custos mensais podem ser menores na nuvem.

  • Ambiente ágil de DevOps. A implantação de alterações de conformidade em um ambiente AIX local pode levar semanas. Talvez seja necessário configurar ambientes de engenharia de desempenho semelhantes muitas vezes para testar alterações. Em um ambiente de nuvem do Azure, você pode configurar ambientes de teste de aceitação do usuário (UAT) e de desenvolvimento em horas. Você pode implementar alterações por meio de um pipeline moderno e bem definido de integração contínua e entrega contínua (CI/CD) de DevOps.

  • Continuidade de negócios e recuperação de desastres (BCDR) aprimoradas. Em ambientes locais, os RTOs (Recovery Time Objetives, objetivos de tempo de recuperação) podem ser longos. No exemplo de ambiente AIX local, o RTO por meio de backups e restaurações tradicionais era de dois dias. A migração para o Azure reduziu o RTO para duas horas.

Considerações

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

Fiabilidade

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para Confiabilidade.

  • Os Arquivos NetApp do Azure podem manter o armazenamento de arquivos na região secundária atualizado com a replicação entre regiões dos Volumes de Arquivos NetApp do Azure. Este recurso do Azure fornece proteção de dados por meio da replicação de volume entre regiões. Você pode fazer failover de aplicativos críticos se houver uma interrupção em toda a região. A replicação de volumes entre regiões está atualmente em visualização.

  • Os servidores de cluster de aplicativos escalam VMs conforme necessário, o que aumenta a disponibilidade nas regiões do Azure.

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 Lista de verificação de revisão de design parade segurança .

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 Lista de verificação de revisão de projeto para Otimização de custos.

  • A migração de cargas de trabalho do AIX para o Linux no Azure pode trazer economias de custos substanciais. Você elimina a manutenção de hardware, reduz os custos das instalações e geralmente pode reduzir os custos operacionais em um fator de oito a 10. O Azure pode acomodar capacidade adicional para cargas de trabalho sazonais ou periódicas, conforme necessário, o que reduz o custo geral.

  • A migração de cargas de trabalho do AIX para o Azure também pode reduzir custos usando serviços nativos da nuvem. Exemplos incluem:

    • Usando o Serviço de Aplicativo do Azure para a camada de apresentação em vez de configurar várias VMs.
    • Segmentar cargas de trabalho com redes virtuais do Azure em vez de usar firewalls baseados em hardware.

Excelência Operacional

A Excelência Operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Lista de verificação de revisão de projeto para o Operational Excellence.

Para monitoramento e gerenciamento proativos, considere usar o Azure Monitor para monitorar cargas de trabalho AIX migradas.

Eficiência de desempenho

Eficiência de desempenho é a capacidade de sua carga de trabalho de escalar para atender às demandas colocadas pelos usuários de maneira eficiente. Para obter mais informações, consulte Lista de verificação de revisão de design para Eficiência de desempenho.

  • O Azure ExpressRoute dá suporte a alta escala para implementações que usam largura de banda significativa, seja para replicação inicial ou replicação de dados alterados em andamento.

  • O gerenciamento de infraestrutura, incluindo escalabilidade, é automatizado em bancos de dados do Azure.

  • Você pode expandir a camada de aplicativo adicionando mais instâncias de VM do servidor de aplicativos.

  • Os gargalos potenciais nessa arquitetura são os subsistemas de armazenamento e computação. Certifique-se de escolher seu armazenamento e SKUs de VM de acordo.

  • Os tipos de disco VM disponíveis são ultra discos, SSDs premium, SSDs padrão e unidades de disco rígido (HDDs) padrão. Para esta solução, é melhor usar SSDs premium ou ultra discos.

  • Para estimar o dimensionamento de VMs provenientes de um sistema AIX, lembre-se de que as CPUs AIX são cerca de 1,4 vezes mais rápidas do que a maioria das vCPUs x86. Essa diretriz pode variar de acordo com a carga de trabalho.

  • Coloque várias VMs que precisam se comunicar entre si em um grupo de posicionamento de proximidade. Localizar as VMs próximas umas das outras fornece a menor latência de comunicação.

Contribuidores

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

Autor principal:

Próximos passos