Migrar aplicativos WebSphere para Máquinas Virtuais do Azure

  • Artigo

Este guia descreve o que você deve estar ciente quando deseja migrar um aplicativo tradicional existente do WebSphere Application Server (WAS) para ser executado em Máquinas Virtuais do Azure. Para obter uma visão geral das soluções tradicionais do WAS disponíveis no Azure Marketplace, consulte O que são soluções para executar a família de produtos IBM WebSphere no Azure?

Pré-migração

Antes de tudo, para garantir uma migração bem-sucedida, conclua as etapas de avaliação e de inventário descritas nas seções a seguir.

Defina o que você quer dizer por "migração concluída"

Este guia e as ofertas correspondentes do Azure Marketplace são um ponto de partida para acelerar a migração de suas cargas de trabalho tradicionais do WAS para o Azure. É importante definir o escopo do seu esforço de migração. Por exemplo, você está fazendo um "lift and shift" rigoroso de sua infraestrutura existente para Máquinas Virtuais do Azure? Nesse caso, pode estar tentado a fazer um "lift and improve" ao migrar.

É melhor se ater ao "lift and shift" puro na medida do possível, fazendo as alterações necessárias detalhadas neste guia. Defina o que você quer dizer por "migração concluída" para saber quando chegou a essa etapa. Quando a "migração estiver concluída", você poderá tirar um instantâneo de suas Máquinas Virtuais, conforme descrito em Criar um instantâneo de um disco rígido virtual. Depois de verificar se é possível restaurar com êxito a partir do snapshot, você pode fazer as melhorias sem medo de perder o progresso da migração alcançado até agora.

Certifique-se de que o destino seja o destino apropriado para seu esforço de migração

A primeira etapa em uma migração bem-sucedida de um aplicativo WAS para o Azure é selecionar o destino de migração mais apropriado.

O WAS tradicional funciona bem nas Máquinas Virtuais do Azure. O destino da máquina virtual (VM) é a escolha mais fácil, porque se assemelha mais a uma implantação local. A experiência administrativa e de implantação para máquinas virtuais é análoga à que você tem localmente.

Outra opção é migrar para contêineres convertendo a carga de trabalho tradicional do WAS em contêineres de aplicativo. Você pode executar o destino do contêiner no Serviço de Kubernetes do Azure (AKS) e no Azure Red Hat OpenShift. O trade-off para essa facilidade é o custo econômico.

De um modo geral, o custo por minuto para uma solução baseada em VM é maior em comparação com contêineres. Embora uma solução baseada em contêiner custe menos para ser executada, você deve restringir seu aplicativo para se adequar aos requisitos da plataforma de orquestração de contêiner.

Se minimizar as alterações for o fator mais importante para seu esforço de migração, considere uma migração baseada em VM. Nesse caso, consulte Migrar aplicativos WebSphere para Máquinas Virtuais do Azure.

Se você puder tolerar a conversão de seu aplicativo para execução em contêineres para reduzir o custo de tempo de execução, considere uma migração baseada em AKS ou no Azure Red Hat OpenShift.

Para migração baseada em AKS, você pode começar a usar a camada Gratuita. Obtenha gerenciamento de cluster gratuito e pague apenas pelas máquinas virtuais, armazenamento associado e recursos de rede consumidos. Nesse caso, consulte Migrar aplicativos WebSphere para o Serviço Kubernetes do Azure.

Para a migração baseada no Azure Red Hat OpenShift, além dos custos de computação e infraestrutura, os nós de aplicativo têm outro custo para o componente de licença do OpenShift. Esse custo é cobrado com base no número de nós do aplicativo e no tipo de instância. Use preços sob demanda ou instâncias reservadas, o que melhor atender às necessidades de sua carga de trabalho e negócios. Nesse caso, consulte Migrar aplicativos WebSphere para o Azure Red Hat OpenShift.

Os guias de instruções na documentação do Azure Red Hat OpenShift abrangem alguns aspectos relevantes para a migração. Para obter a lista completa de guias de instruções, consulte a documentação do Azure Red Hat OpenShift.

Determine se as ofertas pré-criadas do Azure Marketplace são um bom ponto de partida

A IBM e a Microsoft fizeram uma parceria para trazer um conjunto de modelos de solução do Azure para o Azure Marketplace para fornecer um ponto de partida sólido para a migração para o Azure. Para obter a lista de ofertas, consulte Executar a família de produtos WebSphere e o Liberty no Microsoft Azure e escolha a que mais se aproxima da sua implementação existente. Você pode ver a lista de ofertas no artigo de visão geral O que são soluções para executar a família de produtos IBM WebSphere no Azure?

Se nenhuma das ofertas existentes for um bom ponto de partida, você precisará reproduzir a implantação manualmente usando os recursos da Máquina Virtual do Azure. É possível encontrar a orientação passo a passo em Tutorial: Instalar manualmente o IBM WebSphere Application Server Network Deployment tradicional em Máquinas Virtuais do Azure. Para obter mais informações, confira O que é IaaS?

Determinar se a versão tradicional do WAS é compatível

Sua versão tradicional do WAS existente deve ser compatível com a versão nas ofertas de IaaS. É possível localizar as informações de versão na página de visão geral do IBM WebSphere Application Server Single Instance na VM do Azure e do IBM WebSphere Application Server Cluster nas VMs do Azure. Se sua versão tradicional do WAS existente não for compatível com essa versão, você precisará reproduzir a implantação manualmente usando os recursos de IaaS do Azure. Para obter mais informações, confira O que é IaaS?

Inventariar a capacidade do servidor

Documente o hardware (memória, CPU, disco) dos servidores de produção atuais, assim como as contagens de solicitações média e de pico e a utilização de recursos. Essas informações devem orientar a escolha do tamanho da VM. Para saber mais, veja Tamanhos dos Serviços de Nuvem.

Inventariar todos os segredos

Antes do advento das tecnologias de "configuração como serviço", como o Azure Key Vault, não havia um conceito bem definido de "segredos". Em vez disso, você tinha um conjunto distinto de definições de configuração que funcionavam efetivamente como aquilo que agora chamamos de "segredos". Com servidores de aplicativos como o WAS, esses segredos estão em muitos arquivos de configuração e armazenamentos de configuração diferentes. Verifique todas as propriedades e os arquivos de configuração nos servidores de produção em busca de segredos e senhas. Arquivos de configuração que contenham senhas ou credenciais também podem ser encontrados dentro de seu aplicativo. O WAS armazena dados de configuração em vários documentos em uma hierarquia em cascata de diretórios. A maioria dos documentos de configuração tem conteúdo XML. Para obter mais informações, consulte Documentos de configuração e conceitos básicos do Cofre de Chaves do Azure.

Inventariar todos os certificados

Documente todos os certificados usados para pontos de extremidade SSL públicos. Você pode exibir todos os certificados nos servidores de produção executando o seguinte comando:

keytool -list -v -keystore <path to keystore>

Para obter informações adicionais, consulte o documento IBM Certificate management in SSL

Validar se a versão Java com suporte funciona corretamente

Usar o WAS em Máquinas Virtuais do Azure requer uma versão específica do Java, portanto, você precisa confirmar se seu aplicativo é executado corretamente usando essa versão com suporte.

O IBM Java 8 vem com a distribuição WAS9. Recomendamos o uso do Java JRE fornecido pela IBM. Para obter informações adicionais, consulte Java SE 8 no WebSphere Application Server V9 tradicional.

Se desejar alternar para um Java SDK diferente, siga o documento IBM Switching the Java SDK in WebSphere Application Server.

Inventariar recursos de JNDI

Faça um inventário de todos os recursos de JNDI. Por exemplo, fontes de dados como bancos de dados podem ter um nome JNDI associado que permite que o JPA associe corretamente instâncias de EntityManager a um banco de dados específico. Para obter mais informações sobre recursos e bancos de dados JNDI, consulte WebSphere Data Sources na documentação da IBM. Outros recursos relacionados a JNDI, como agentes de mensagens JMS, podem exigir migração ou reconfiguração. Para obter mais informações sobre a configuração do JMS, consulte Usando recursos do JMS.

Inspecione a configuração do seu perfil

A principal unidade de configuração no WAS é o perfil. Como tal, o arquivo resources.xml contém uma riqueza de configurações que você deve considerar cuidadosamente para a migração. O arquivo inclui referências a mais arquivos XML armazenados em subdiretórios. A IBM aconselha que você normalmente deve usar o IBM Console para configurar os objetos e serviços gerenciáveis do WAS e permitir que o WAS mantenha a pasta profiles/profile-name . Para obter informações adicionais, consulte Gerenciando perfis em sistemas operacionais distribuídos e IBM i.

Dentro de seu aplicativo

Inspecione o arquivo deployment.xml e/ou o arquivo WEB-INF/web.xml .

Determinar se a replicação de sessão é usada

Se seu aplicativo depender da replicação de sessão, você terá as seguintes opções:

  • Para sessões HTTP, de acordo com o nível de gerenciamento de sessão, você pode usar memória ou um banco de dados para coletar dados da sessão.
  • Para sessões distribuídas, você pode salvar sessões em um banco de dados usando a persistência de sessão de banco de dados.
  • Para o cache dinâmico, você pode gerenciar dados de sessão na replicação de memória para memória ou em um banco de dados.
  • Refatore seu aplicativo para usar um banco de dados para gerenciamento de sessão.
  • Refatore seu aplicativo para externalizar a sessão para o serviço Redis do Azure. Para obter mais informações, consulte Azure Cache for Redis.

Para todas essas opções, é uma boa ideia dominar como o WAS faz a replicação de estado de sessão HTTP. Para obter informações adicionais, consulte Administrando beans de sessão na documentação da IBM.

Documentar fontes de dados

Se seu aplicativo usar algum banco de dados, você precisará capturar as informações a seguir:

  • Qual é o nome da fonte de dados?
  • Qual é a configuração do pool de conexões?
  • Onde posso encontrar o arquivo JAR do driver JDBC?

Para obter informações adicionais sobre drivers JDBC no WAS, consulte Usando drivers JDBC com o WebSphere Application Server.

Determinar se o WAS foi personalizado

Determine quais das personalizações a seguir foram feitas e capture o que foi feito.

  • Os scripts de inicialização foram alterados? Esses scripts incluem wsadmin, AdminControl, AdminConfig, AdminApp e AdminTask.
  • Parâmetros específicos foram passados para a JVM?
  • JARs foram adicionados ao classpath do servidor?
  • Os recursos de nível de sistema operacional, como systemd os que foram usados para fazer com que os componentes do WAS sejam iniciados automaticamente após a reinicialização do servidor?

Você precisa levar em conta as considerações de migração, dependendo das respostas a essas perguntas.

Determinar se uma conexão com o local é necessária

Se seu aplicativo precisar acessar qualquer um dos seus serviços locais, você precisará provisionar um dos serviços de conectividade do Azure. Para obter mais informações, confira Escolher uma solução para conectar uma rede local ao Azure. Como alternativa, você precisará refatorar seu aplicativo para usar APIs disponíveis publicamente que seus recursos locais expõem.

Determinar se as Filas ou os Tópicos do JMS (Java Message Service) estão em uso

Se seu aplicativo estiver usando Filas ou Tópicos JMS, você precisará migrá-los para um servidor JMS hospedado externamente. Uma estratégia para aqueles que usam JMS é usar o Barramento de Serviço do Azure e o Protocolo Avançado de Enfileiramento de Mensagens. Para obter mais informações, consulte Usar o JMS com o Barramento de Serviço do Azure e o AMQP 1.0.

Se você configurou repositórios persistentes JMS, deverá capturar sua configuração e aplicá-la após a migração.

Se você estiver usando o IBM MQ, poderá migrar esse software para as Máquinas Virtuais do Azure e usá-lo como está.

A Microsoft tem uma solução para integrar o IBM MQ com Aplicativos Lógicos. Para obter mais informações, consulte Conectar a um servidor IBM MQ de um fluxo de trabalho nos Aplicativos Lógicos do Azure.

Determinar se você está usando suas próprias bibliotecas Java EE compartilhadas personalizadas criadas

Se você estiver usando o recurso de biblioteca Java EE compartilhada, terá duas opções:

  • Refatore o código do aplicativo para remover todas as dependências em suas bibliotecas e incorporar a funcionalidade diretamente ao seu aplicativo.
  • Adicione as bibliotecas ao classpath do servidor.

Determinar se pacotes OSGi são usados

Se você usou pacotes OSGi adicionados ao WAS, precisará adicionar os arquivos JAR equivalentes diretamente ao seu aplicativo Web.

Determinar se o aplicativo contém código específico do sistema operacional

Se seu aplicativo contiver qualquer código com dependências do sistema operacional do host, você precisará refatorá-lo para remover essas dependências. Por exemplo, talvez seja necessário substituir qualquer uso de / ou \ em caminhos do sistema de arquivos com File.Separator ou Paths.get.

Determine se o IBM Integration Bus está em uso

Se seu aplicativo estiver usando o IBM Integration Bus, será necessário capturar como o IBM Integration Bus está configurado. Para obter informações adicionais, consulte a documentação do IBM Integration Bus.

Determinar se seu aplicativo é composto por vários WARs

Se seu aplicativo for composto por vários WARs, você deverá tratar cada um desses WARs como aplicativos separados e consultar este guia para cada um deles.

Determinar se seu aplicativo está empacotado como um EAR

Se seu aplicativo for empacotado como um arquivo EAR, certifique-se de examinar os arquivos application.xml, ibm-application-bnd.xmi e ibm-application-ext.xmi e capturar suas configurações. Para obter mais informações, consulte Compilando o pacote EAR (Enterprise Archive) no WebSphere.

Identificar todos os processos e daemons externos em execução nos servidores de produção

Se você tiver processos em execução fora do servidor de aplicativos, como daemons de monitoramento, precisará eliminá-los ou migrá-los para outro lugar.

Determinar se e como o sistema de arquivos é usado

Os sistemas de arquivos de VMs funcionam da mesma forma que os sistemas de arquivos locais em relação à persistência, inicialização e ao desligamento. Mesmo assim, é importante estar ciente das necessidades do seu sistema de arquivos e garantir que as VMs tenham o tamanho e o desempenho de armazenamento adequados.

Conteúdo estático somente leitura

Se seu aplicativo estiver servindo conteúdo estático no momento, você precisará de um local alternativo para ele. Talvez você queira considerar a movimentação de conteúdo estático para o Armazenamento de Blobs do Azure e a adição da CDN do Azure para downloads extremamente rápidos, globalmente. Para obter mais informações, confira Hospedagem de site estático no Armazenamento do Microsoft Azure e Início rápido: Integrar uma conta de armazenamento do Azure à CDN do Azure. Você também pode implantar diretamente o conteúdo estático em um aplicativo no plano Azure Spring Apps Enterprise. Para mais informações, veja Implantar arquivos estáticos da web.

Conteúdo estático publicado dinamicamente

Se o aplicativo permitir conteúdo estático que é carregado/produzido pelo aplicativo, mas não puder ser alterado após sua criação, você poderá usar o Armazenamento de Blobs do Azure e a CDN do Azure, conforme descrito acima, com uma Função do Azure para lidar com uploads e atualização de CDN. Fornecemos uma implementação de exemplo para seu uso em Carregar conteúdo estático e fazer o pré-carregamento desse conteúdo pela CDN com o Azure Functions. Você também pode implantar diretamente o conteúdo estático em um aplicativo no plano Azure Spring Apps Enterprise. Para mais informações, veja Implantar arquivos estáticos da web.

Determinar a topologia de rede

O conjunto atual de ofertas do Azure Marketplace é um ponto de partida para sua migração. Se a oferta não cobrir aspectos da arquitetura que você precisa migrar, você precisará capturar a topologia de rede da implantação existente. Em seguida, você precisa reproduzir essa topologia de rede no Azure, mesmo depois de manter a oferta básica com um dos modelos de solução.

A topologia de rede é um tópico amplo, mas as referências a seguir podem dar alguma direção aos seus esforços de migração:

  • A referência a seguir enumera os tópicos de alto nível relevantes para a migração da topologia de rede para o Azure: topologias do WebSphere Application Server Network Deployment.
  • Como as fontes de dados são servidores separados em um sistema WAS, você deve considerá-las como parte da análise de topologia de rede. Para obter informações adicionais, consulte WebSphere Application Server Data Sources.
  • As fontes de mensagens também são servidores separados. Para obter informações adicionais, consulte Topologias de rede: interoperando usando o provedor de mensagens do WebSphere MQ.
  • O balanceamento de carga é um requisito fundamental. A referência a seguir abrange o lado WAS do balanceamento de carga: cluster com balanceamento de carga do WebSphere Application Server Network Deployment.

Conta para o uso de adaptadores JCA e adaptadores de recursos

Se seu aplicativo existente usa adaptadores JCA ou outros adaptadores de recursos para se conectar a outros sistemas corporativos, certifique-se de aplicar a configuração desses artefatos ao WAS em execução nas Máquinas Virtuais do Azure. Para obter informações adicionais, consulte Adaptadores de recursos relacionais e JCA na documentação da IBM.

Conta para autenticação e autorização

A maioria dos aplicativos tem algum tipo de autenticação e autorização. Se você usar o OpenID para autenticação, poderá configurar a autenticação de conexão OpenID com o Microsoft Entra ID. Para obter mais informações, consulte Autenticação do OpenID Connect com o Microsoft Entra ID.

Determinar se o clustering do WAS é usado

Muito provavelmente, você implantou seu aplicativo em vários servidores WAS para obter alta disponibilidade. Você pode migrar esses clusters diretamente de sua instalação local para o WAS em execução nas Máquinas Virtuais do Azure. Para obter informações adicionais, consulte WebSphere Application Server Network Deployment na documentação da IBM.

Conta para requisitos de balanceamento de carga

O balanceamento de carga é uma parte essencial da migração do cluster do WAS para o Azure. A solução mais fácil é usar o suporte interno para o Azure Application Gateway ou IBM HTTP Server fornecido na oferta do Azure Marketplace para IBM WebSphere Application Server Cluster.

Para obter um resumo dos recursos do Gateway de Aplicativo do Azure em comparação com outras soluções de balanceamento de carga do Azure, consulte Opções de balanceamento de carga.

Determinar se o recurso Cliente do aplicativo Java EE é usado

Se seu aplicativo usar o recurso Cliente do aplicativo Java EE, ele deverá continuar a funcionar sem alterações após a migração para as Máquinas Virtuais do Azure. Para saber mais, consulte Usando módulos do aplicativo cliente Java EE.

Migração

Selecione uma oferta do WAS tradicional nas Máquinas Virtuais do Azure

As ofertas a seguir estão disponíveis para o WAS em Máquinas Virtuais do Azure.

Durante a implantação de uma oferta, você será solicitado a escolher o tamanho da máquina virtual para seus nós WAS. É importante considerar todos os aspectos do dimensionamento (memória, processador, disco) ao escolher o tamanho da VM. Para obter mais informações, consulte Tamanhos para serviços de nuvem (clássico).

  • Instância única do IBM WebSphere Application Server na VM do Azure

    Essa oferta automatiza a maioria das etapas clichês para provisionar uma única instância do WebSphere em uma Máquina Virtual do Azure. Ele cria um perfil de servidor de aplicativos com o console de administração do WAS.

  • IBM WebSphere Application Server Cluster em VMs do Azure

    Essa oferta automatiza a maioria das etapas clichês para provisionar um cluster do WebSphere em VMs do Azure. Ele cria um gerenciador de implantação com o console de administração do WAS em uma VM do Azure e o número necessário de agentes de nó em VMs separadas do Azure.

Provisionar a oferta

Depois de selecionar com qual oferta começar, provisione essa oferta seguindo as instruções em Implementar o WebSphere Application Server (tradicional) Cluster em Máquinas Virtuais do Azure.

Migrar os perfis

Depois de provisionar a oferta, você pode examinar a configuração do perfil. Para obter informações adicionais, consulte Conceitos de perfil na documentação da IBM.

Conectar os bancos de dados

Depois de migrar os perfis, é possível conectar os bancos de dados seguindo as instruções em Configurando a Fonte de Dados do WebSphere Application Server na documentação da IBM.

Considerar os repositórios de chaves

Você deve considerar a migração de todos os repositórios de chaves SSL usados pelo seu aplicativo. Para obter informações adicionais, consulte Configurações de armazenamento de chaves para SSL na documentação da IBM.

Conectar as fontes JMS

Depois de conectar os bancos de dados, é possível configurar o JMS seguindo as instruções em Configurando o JMS no IBM WebSphere Application Server na documentação da IBM.

Conta para autenticação e autorização

A maioria dos aplicativos tem algum tipo de autenticação e autorização. Se você usar o OpenID para autenticação, poderá configurar a autenticação de conexão OpenID com o Microsoft Entra ID. Para obter mais informações, consulte Autenticação do OpenID Connect com o Microsoft Entra ID.

Considerar o registro em log

É possível configurar o Elastic Stack seguindo as instruções em Analisando logs do WebSphere Application Server com o Elastic Stack na documentação da IBM. O Azure fornece suporte para o Elastic. Para obter mais informações, consulte O que é a integração elástica com o Azure? Você pode combinar o conhecimento nesses dois recursos para obter uma solução de log otimizada para o Azure para WAS em VMs.

Migrando seus aplicativos

As técnicas usadas para implantar aplicativos da equipe de desenvolvimento em servidores de teste, de preparo e de produção variam muito conforme o caso. Em alguns casos, há uma plataforma CI/CD altamente evoluída que resulta na implementação dos aplicativos no WebSphere Application Server. Em outros casos, o processo pode ser mais manual. Um benefício de usar as Máquinas Virtuais do Azure para migrar aplicativos tradicionais do WAS para a nuvem é que seus processos existentes continuam funcionando.

Você precisa configurar o Grupo de Segurança de Rede que a oferta provisiona para permitir o acesso do pipeline de CI/CD ou do sistema de implantação manual. Para obter mais informações, confira Grupos de segurança de rede.

Testando

Você deve configurar quaisquer testes no contêiner em aplicativos para acessar os novos servidores em execução no Azure. Assim como acontece com as preocupações com o CI/CD, você deve garantir que as regras de segurança de rede necessárias permitam que seus testes acessem os aplicativos implantados no Azure. Para obter mais informações, confira Grupos de segurança de rede.

Pós-migração

Depois de atingir as metas de migração que você definiu na etapa de pré-migração, execute um teste de aceitação de ponta a ponta para verificar se tudo funciona conforme o esperado. Para obter orientação sobre alguns possíveis aprimoramentos pós-migração, consulte as seguintes recomendações: