Partilhar via

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

Para garantir uma migração bem-sucedida, antes de começar, conclua as etapas de avaliação e inventário descritas nas seções a seguir.

Definir o que quer dizer com "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 âmbito do seu esforço de migração. Por exemplo, está a fazer uma migração estritamente "lift-and-shift" da sua infraestrutura existente para Máquinas Virtuais do Microsoft Azure? Em caso afirmativo, poderá sentir-se tentado a fazer alguma migração "lift-and-improve" à medida que migra.

Contudo, é melhor manter-se o mais próximo possível de uma migração "lift-and-shift" pura, tendo em conta as mudanças necessárias conforme detalhado neste guia. Defina o que quer dizer com "migração concluída" para ficar ciente do momento em que atingiu este marco. Quando tiver atingido a "migração concluída", pode tirar um instantâneo das suas 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 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 é o destino apropriado para o 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 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 Kubernetes do Azure (AKS) e no Azure Red Hat OpenShift. A contrapartida 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êineres.

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 o nível Gratuito. 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 de 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 aspetos 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 estabeleceram 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, em seguida, escolha o 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, consulte O que é IaaS?

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

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

Fazer o inventário da capacidade do servidor

Documente o hardware (memória, CPU, disco) dos servidores de produção atuais, bem como as contagens médias e máximas de pedidos e utilização de recursos. Estas informações têm de influenciar a escolha do tamanho das VMs. Para obter mais informações, veja Tamanhos para Serviços Cloud.

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, tínhamos um conjunto díspar de definições de configuração que, efetivamente, funcionavam como aquilo a que hoje chamamos "segredos". Com servidores de aplicativos como o WAS, esses segredos estão em muitos arquivos de configuração e armazenamentos de configuração diferentes. Procure segredos e palavras-passe nas propriedades e nos ficheiros de configuração do servidor ou servidores de produção. Também poderá encontrar ficheiros de configuração com palavras-passe ou credenciais dentro da aplicação. 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 utilizados para os pontos finais SSL públicos. Pode ver todos os certificados no servidor ou servidores de produção com o comando seguinte:

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

Para obter mais informações, consulte o IBM document Certificate management in SSL

Verificar se a versão de Java suportada 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 suportada.

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 desejar alternar para um Java SDK diferente, siga o documento IBM Switching the Java SDK in WebSphere Application Server.

Inventariar recursos do JNDI

Inventariar todos os recursos do JNDI. Por exemplo, as origens de dados como as bases de dados podem ter associado um nome do JNDI que permite que o JPA vincule corretamente instâncias de EntityManager a uma base de dados específica. Para obter mais informações sobre recursos e bancos de dados JNDI, consulte WebSphere Data Sources na documentação da IBM. Outros recursos não relacionados com o JNDI, como os mediadores de mensagens do 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 grande variedade 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 mais informações, consulte Gerenciando perfis em sistemas operacionais distribuídos e IBM i.

Na aplicação

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

Determinar se é utilizada a replicação de sessões

Se seu aplicativo depende da replicação de sessão, você tem 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 de sessão.
  • Para sessões distribuídas, você pode salvar sessões em um banco de dados usando a persistência da sessão do banco de dados.
  • Para 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.
  • Refatorize a sua aplicação para utilizar uma base de dados para a gestão de sessões.
  • Refatorize a sua aplicação para externalizar a sessão para o Serviço de Redis do Azure. Para obter mais informações, veja Azure Cache for Redis (Cache do Azure para Redis).

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

Documentar origens de dados

Se a sua aplicação utilizar bases de dados, terá de recolher as seguintes informações:

  • Qual é o nome da origem de dados?
  • Qual é a configuração do conjunto de ligações?
  • Onde posso obter o ficheiro JAR do controlador JDBC?

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

Determinar se o WAS foi personalizado

Determine quais das seguintes personalizações foram feitas e capture as que o foram.

  • Os scripts de arranque foram alterados? Esses scripts incluem wsadmin, AdminControl, AdminConfig, AdminApp e AdminTask.
  • São transmitidos parâmetros específicos para a JVM?
  • Foram adicionados JARs ao classpath do servidor?
  • Os recursos no nível do sistema operacional foram systemd 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 é necessária uma ligação ao local

Se a sua aplicação precisar de aceder a um dos seus serviços no local, tem de aprovisionar um dos serviços de conectividade do Azure. Para obter mais informações, veja Ligar uma rede no local ao Azure. Em alternativa, tem de refatorizar a aplicação para utilizar as APIs publicamente disponíveis que os seus recursos no local expõem.

Determinar se os Tópicos ou Filas do Java Message Service (JMS) estão a ser utilizados

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 Java Message Service 1.1 com o Azure Service Bus Standard e AMQP 1.0.

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

Se estiver usando o IBM MQ, você poderá migrar esse software para 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-se a um servidor IBM MQ a partir de um fluxo de trabalho no Azure Logic Apps.

Determinar se está a utilizar bibliotecas Shared Java EE criadas e personalizadas por si.

Se utilizar a funcionalidade de biblioteca Shared Java EE, tem duas opções:

  • Refatorizar o código da aplicação para remover todas as dependências nas bibliotecas e, ao invés, incorporar a funcionalidade diretamente na aplicação.
  • Adicionar as bibliotecas ao classpath do servidor.

Determinar se os conjuntos OSGi são utilizados

Se você usou pacotes OSGi adicionados ao WAS, você precisa adicionar os arquivos JAR equivalentes diretamente ao seu aplicativo web.

Determinar se a aplicação contem código de SO específico

Se seu aplicativo contiver qualquer código com dependências no sistema operacional 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 por File.Separator ou Paths.get se seu aplicativo estiver sendo executado 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 a sua aplicação é composta por vários WARs

Se a sua aplicação for composta por vários WARs, deve tratar cada um desses WARs como aplicações separadas e seguir este guia para cada qual individualmente.

Determinar se a sua aplicação está empacotada como 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 Building the enterprise archive (EAR) package on WebSphere.

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

Se tiver processos em execução fora do servidor de aplicações, como daemons de monitorização, terá de eliminar ou migrá-los para outro local.

Determinar se e como é que o sistema de ficheiros é utilizado

Os sistemas de ficheiros de VMs funcionam da mesma forma que os sistemas de ficheiros no local no que diz respeito a persistência, arranque e encerramento. Contudo, é importante ter noção das necessidades do seu sistema de ficheiros e garantir que o tamanho de armazenamento e o desempenho das VMs é adequado.

Conteúdo estático só de leitura

Se a sua aplicação servir conteúdo estático atualmente, precisa de uma localização alternativa para o mesmo. Pode considerar mover o conteúdo estático para o Armazenamento de Blobs do Azure e adicionar a CDN do Azure para obter transferências super-rápidas a nível global. Para obter mais informações, consulte Hospedagem de site estático no Armazenamento do Azure e Guia de início rápido: integrar uma conta de armazenamento do Azure com a CDN do Azure.

Conteúdo estático publicado dinamicamente

Se a sua aplicação permitir conteúdo estático carregado/produzido pela mesma, mas que é imutável após a criação, pode utilizar o Armazenamento de Blobs do Azure e a CDN do Azure conforme descrito acima, com uma função das Funções do Azure que lide com os carregamentos e as atualizações da CDN. Disponibilizamos uma implementação de exemplo que pode utilizar, em Uploading and CDN-preloading static content with Azure Functions (Carregamento e pré-carregamento da CDN de conteúdo estático com as Funções do Azure).

Determinar a topologia de rede

O conjunto atual de ofertas do Azure Marketplace é um ponto de partida para a sua migração. Se a oferta não abranger aspetos da sua arquitetura que você precisa migrar, você precisará capturar a topologia de rede de sua implantação existente. Em seguida, você precisa reproduzir essa topologia de rede no Azure, mesmo depois de apresentar 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 mais informações, consulte WebSphere Application Server Data Sources.
  • As origens das mensagens também são servidores separados. Para obter mais informações, 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: Clustering 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 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 OpenID para autenticação, poderá configurar a autenticação OpenID connect 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 da sua instalação local para o WAS em execução nas Máquinas Virtuais do Azure. Para obter mais informações, 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 a funcionalidade da aplicação cliente Java EE está a ser utilizada

Se a sua aplicação estiver a utilizar a funcionalidade da aplicação cliente Java EE, deverá continuar a funcionar de forma inalterada após a migração para Máquinas Virtuais do Azure. Para obter mais informações, veja Using Java EE Client Application Modules (Utilizar os módulos da aplicação cliente Java EE).

Migração

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

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

Durante a implantação de uma oferta, você é solicitado a escolher o tamanho da máquina virtual para seus nós do WAS. Quando escolher o tamanho das VMs, é importante considerar todos os aspetos do tamanho (memória, processador, disco, etc.). 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

    Esta 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

    Esta 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 números necessários de agentes de nó em VMs do Azure separadas.

Aprovisionar a oferta

Depois de selecionar 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 mais informações, consulte Conceitos de perfil na documentação da IBM.

Ligar as bases 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 KeyStores

Tem de ter em conta a migração de todos os KeyStores SSL utilizados pela sua aplicação. Para obter mais informações, consulte Configurações de armazenamento de chaves para SSL na documentação da IBM.

Ligar as origens do 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 do IBM.

Conta para autenticação e autorização

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

Considerar o registo

É 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 do Azure para o WAS em VMs.

Migrando seus aplicativos

As técnicas utilizadas para implementar aplicações da equipa de desenvolvimento em servidores de teste e de produção variam muito de caso para caso. Em alguns casos, há uma plataforma CI/CD altamente evoluída que resulta na implementação dos aplicativos no WebSphere Application Server. Noutros 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 a funcionar.

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

Testar

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 de 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, consulte Grupos de segurança de rede.

Pós-migração

Após alcançar os objetivos de migração que definiu no passo de pré-migração, realize alguns testes de aceitação ponto a ponto para verificar se tudo está a funcionar conforme o esperado. Para obter orientações sobre alguns possíveis aprimoramentos pós-migração, consulte as seguintes recomendações: