Editar

Partilhar via


AIX UNIX local para migração do Azure Linux

Azure NetApp Files
Azure Site Recovery
Azure SQL Database
Azure Virtual Machines
Azure Virtual Network

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 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 replicação geográfica e grupos de 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 estende uma rede local aos serviços de nuvem da Microsoft por meio de uma conexão privada, facilitada por um provedor de conectividade. 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 que distribui o tráfego entre regiões do Azure, com alta disponibilidade e capacidade de resposta rápida.

  • O Balanceador de Carga do Azure dá suporte à alta disponibilidade distribuindo o tráfego de rede de entrada entre VMs de 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).

  • O Azure Web Application Firewall é um serviço WAF nativo da nuvem que protege aplicativos Web contra ataques mal-intencionados e vulnerabilidades comuns da Web.

  • O Serviço de Aplicativo do Azure é um serviço de hospedagem na Web totalmente gerenciado para implantar rápida e facilmente aplicativos Web corporativos para qualquer plataforma em uma infraestrutura de nuvem escalável e confiável.

  • As Máquinas Virtuais do Azure são um dos vários serviços do Azure que fornecem recursos de computação escalonáveis e sob demanda. Com as VMs do Azure, você obtém a flexibilidade da virtualização sem precisar comprar e manter hardware físico.

    • Os discos gerenciados do SSD do Azure são volumes de armazenamento em nível de bloco para VMs do Azure.
    • As placas de interface de rede virtual (NICs) do Azure permitem que as VMs do Azure se comuniquem com recursos da Internet, do Azure e locais. Você pode adicionar várias NICs virtuais a uma VM do Azure, para que as VMs filhas possam ter seus próprios dispositivos de interface de rede dedicados e endereços IP.
  • A Rede Virtual do Azure é o bloco de construção fundamental para as redes privadas do Azure. A Rede Virtual permite que muitos tipos de recursos do Azure, como VMs, se comuniquem com segurança entre si, com a Internet e com redes locais. A Rede Virtual oferece benefícios de infraestrutura do Azure, como escalabilidade, disponibilidade e isolamento.

  • O armazenamento de Arquivos do Azure oferece 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.

  • 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 estável do mecanismo de banco de dados do SQL Server, com a mais alta disponibilidade. O Banco de dados SQL lida com funções de gerenciamento de banco de dados, como atualizações, aplicação de patches, backups e monitoramento, sem o envolvimento do usuário.

  • O Azure NetApp Files oferece compartilhamentos de arquivos do Azure de nível empresarial com tecnologia NetApp. Os Arquivos NetApp do Azure facilitam para as empresas a migração e a execução de aplicativos complexos baseados em arquivos sem alterações de código.

  • O Azure Site Recovery é um serviço de DR nativo do Azure. 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.

  • O Microsoft Entra ID é o serviço de gerenciamento de acesso e identidade empresarial baseado em nuvem da Microsoft. O início de sessão único e a autenticação multifator do Microsoft Entra ajudam os utilizadores a iniciar sessão e a aceder a recursos, ao mesmo tempo que protegem contra ataques de cibersegurança.

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

As seguintes considerações, baseadas no Microsoft Azure Well-Architected Framework, aplicam-se a esta solução:

Disponibilidade

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

Operações

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

Eficiência de desempenho

  • 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, unidades de estado sólido (SSDs) premium, SSDs padrão e unidades de disco rígido padrão (HDDs). 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.

Escalabilidade

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

Segurança

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.

Contribuidores

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

Autor principal:

Próximos passos