Compartilhar via

Migrar aplicativos WebSphere para Máquinas Virtuais do Azure

  • Artigo

Este guia descreve as informações das quais você deve estar ciente quando deseja migrar um aplicativo WebSphere Application Server (WAS) tradicional existente 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 Quais são as 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 do Azure Marketplace correspondentes 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 tiver atingido a "migração concluída", você poderá tirar um instantâneo das máquinas virtuais, conforme descrito em Criar um instantâneo de um disco rígido virtual. Depois de verificar que é possível restaurar com êxito com base no seu instantâneo, você pode fazer as melhorias sem medo de perder o progresso da migração feito até agora.

Verifique se o destino é o adequado para o 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 adequado.

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

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

De 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êineres.

Se minimizar as mudanças é o fator mais importante para o esforço de migração, considere uma migração baseada em VM. Nesse caso, confira Migrar aplicativos do WebSphere para Máquinas Virtuais do Azure.

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

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

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

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

Determinar se as ofertas predefinidas do Azure Marketplace são um bom ponto de partida

A IBM e a Microsoft fizeram parceria para trazer um conjunto de modelos de solução do Azure para o Azure Marketplace e 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, em seguida, escolha aquela que mais se aproxima da implementação existente. Você pode ver a lista de ofertas no artigo de visão geral Quais são as soluções para executar a família de produtos IBM WebSphere no Azure?

Se nenhuma das ofertas existentes for um bom ponto de partida, será necessário reproduzir a implantação manualmente usando recursos de Máquina Virtual do Azure. Você pode encontrar as diretrizes passo a passo no 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 do WAS tradicional é compatível

Sua versão existente do WAS tradicional deve ser compatível com a versão nas ofertas de IaaS. Você pode encontrar 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 em VMs do Azure. Se a versão existente do WAS tradicional não for compatível com essa versão, você terá que 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 repositórios 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 Azure Key Vault.

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 mais informações, consulte o documento da IBM Gerenciamento de certificados em 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 o 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 mais informações, consulte Java SE 8 no WebSphere Application Server V9 tradicional.

Se quiser alternar para um SDK Java diferente, siga o documento da IBM Alternando o SDK Java no 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 os recursos e bancos de dados de JNDI, consulte Fontes de dados do WebSphere 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.

Inspecionar a configuração de perfil

A principal unidade de configuração no WAS é o perfil. Portanto, o arquivo resources.xml contém uma infinidade de configurações que você precisa considerar cuidadosamente para a migração. O arquivo inclui referências a mais arquivos XML que são 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 mais informações, 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 o 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ões, você pode usar a 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 saber como o WAS faz a replicação de estado de sessão HTTP. Para obter mais informações, 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 saber mais 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, 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, consulte 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 do JMS, você precisa migrá-los para um servidor do JMS hospedado externamente. Uma estratégia para pessoas que usam JMS é usar o Barramento de Serviço do Azure e o Advanced Message Queuing Protocol. Para obter mais informações, confira Usar o Java Message Service 1.1 com o padrão de Barramento de Serviço do Azure e o AMQP 1.0.

Se os armazenamentos persistentes JMS tiverem sido configurados, você deverá capturar a configuração deles 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 no estado em que se encontra.

A Microsoft tem uma solução para integrar o IBM MQ com os 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, precisa 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 se o aplicativo estiver em execução no Windows.

Determinar se o IBM Integration Bus está em uso

Se seu aplicativo estiver usando o IBM Integration Bus, você precisará capturar como o IBM Integration Bus está configurado. Para obter mais informações, 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 estiver empacotado como um arquivo EAR, examine os arquivos application.xml, ibm-application-bnd.xmi e ibm-application-ext.xmi e capture as configurações deles. Para obter mais informações, consulte Construindo o pacote de arquivo corporativo (EAR) 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 migraçã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.

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.

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 abranger aspectos de sua arquitetura que você precisa migrar, capture a topologia de rede de sua 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.

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

Considerar o uso de adaptadores JCA e adaptadores de recursos

Se seu aplicativo existente usar adaptadores JCA ou outros adaptadores de recursos para se conectar a outros sistemas empresariais, aplique a configuração desses artefatos ao WAS em execução em Máquinas Virtuais do Azure. Para obter mais informações, 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 do OpenID com o Microsoft Entra ID. Para mais informações, confira Autenticação do OpenID Connect com o Microsoft Entra ID.

Determinar se o clustering do WAS é ou não usado

É provável que você tenha implantado seu aplicativo em vários WAS para conseguir alta disponibilidade. Você pode migrar esses clusters diretamente da instalação local para o WAS em execução em Máquinas Virtuais do Azure. Para obter mais informações, consulte Implantação de rede do WebSphere Application Server 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 Gateway de Aplicativo do Azure ou o IBM HTTP Server fornecido na oferta do Azure Marketplace para o IBM WebSphere Application Server Cluster.

Para obter um resumo das funcionalidades do Gateway de Aplicativo do Azure em comparação com outras soluções de balanceamento de carga do Azure, confira 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

Selecionar uma oferta do WAS tradicional em 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ê deverá escolher o tamanho da máquina virtual para seus nós do 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 dos 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.

  • Cluster do IBM WebSphere Application Server 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 Implantar o cluster do WebSphere Application Server (tradicional) em Máquinas Virtuais do Azure.

Migrar os perfis

Depois de provisionar a oferta, você pode examinar a configuração do perfil. Para obter mais informações, confira 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 mais informações, 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 do OpenID com o Microsoft Entra ID. Para mais informações, confira 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 Elastic. Para obter mais informações, consulte O que é a integração do Elastic com o Azure? Você pode combinar o conhecimento nesses dois recursos para obter uma solução de log otimizada para 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 de CI/CD altamente evoluída que faz com que os aplicativos sejam implantados no WebSphere Application Server. Em outros casos, o processo pode ser mais manual. Um dos benefícios de usar as Máquinas Virtuais do Azure para migrar aplicativos WAS tradicional para a nuvem é que os processos existentes continuarão a funcionar.

Você precisa configurar o grupo de segurança de rede provisionado pela oferta para permitir o acesso do pipeline de CI/CD ou do sistema de implantação manual. Para saber mais, confira Grupos de segurança de rede.

Testando

Configure os testes no contêiner em relação a 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 saber mais, 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 encontrar diretrizes sobre alguns possíveis aprimoramentos pós-migração, confira as seguintes recomendações: