通过

将 WebSphere 应用程序迁移到 Azure 虚拟机

  • 项目

本指南介绍了将现有 WebSphere 应用服务器 (WAS) 传统应用程序迁移到 Azure 虚拟机上运行时应注意的事项。 有关 Azure 市场中可用的 WAS 传统解决方案的概述，请参阅在 Azure 上运行 IBM WebSphere 系列产品的解决方案有哪些？

预迁移

若要确保迁移成功，请在开始之前完成以下各节中所述的评估和清点步骤。

定义“迁移完成”的含义

本指南和相应的 Azure 市场产品/服务是加快将 WAS 传统工作负荷迁移到 Azure 的起点。 定义迁移工作的范围很重要。 例如，你是否要严格按要求从现有的基础结构“直接迁移”到 Azure 虚拟机？ 如果答案为是，则在迁移过程中，你可能想要尝试使用一些“迁移加改进”措施。

考虑到本指南中详述的必要更改，最好是尽可能进行单纯的“直接迁移”。 定义“迁移完成”的含义，这样就可以知道自己何时到达了该里程碑。 当“迁移完成”时，可以按照创建虚拟硬盘的快照中的说明为虚拟机创建快照。 在验证你可以从快照成功还原后，你可以进行改进，而不必担心丢失迄今为止取得的迁移进度。

确保目标是迁移工作的适当目标

成功将 WAS 应用程序迁移到 Azure 的第一步是选择最合适的迁移目标。

WAS 传统工作负荷在 Azure 虚拟机上运行良好。 虚拟机 (VM) 目标是最简单的选择，因为它与本地部署最为相似。 虚拟机的管理和部署体验与本地体验很相似。

另一种方法是将 WAS 传统工作负荷转换为应用程序容器，从而迁移到容器。 可以在 Azure Kubernetes 服务 (AKS) 和 Azure Red Hat OpenShift 上运行容器目标。 这种便利性的代价是经济成本。

一般来说，与容器相比，基于 VM 的解决方案的每分钟成本更高。 虽然基于容器的解决方案运行成本较低，但必须堆应用程序加以限制，使其符合容器业务流程平台的要求。

如果最大程度地减少更改是迁移工作最重要的因素，请考虑基于 VM 的迁移。 在这种情况下，请参阅将 WebSphere 应用程序迁移到 Azure 虚拟机。

如果能忍受将应用程序转换为在容器中运行以降低运行时成本，则可以考虑基于 AKS 或 Azure Red Hat OpenShift 的迁移。

对于基于 AKS 的迁移，可以开始使用免费层。 获得免费的群集管理，只为消耗的虚拟机、相关存储和网络资源付费。 在这种情况下，请参阅将 WebSphere 应用程序迁移到 Azure Kubernetes 服务。

对于基于 Azure Red Hat OpenShift 的迁移，除了计算和基础设施成本外，应用程序节点还需要支付 OpenShift 许可证组件的其他费用。 该费用是根据应用节点数量和实例类型计费的。 使用按需定价或预留实例，以满足工作负荷和业务需求。 在这种情况下，请参阅将 WebSphere 应用程序迁移到 Azure Red Hat OpenShift。

Azure Red Hat OpenShift 文档中的操作指南涵盖了与迁移相关的某些方面。 有关操作指南的完整列表，请参阅 Azure Red Hat OpenShift 文档。

确定预生成的 Azure 市场产品/服务是否是良好起点

IBM 与 Microsoft 合作，为 Azure 市场提供了一套 Azure 解决方案模板，为迁移到 Azure 提供了一个坚实的起点。 有关产品/服务列表，请参阅在 Microsoft Azure 上运行 WebSphere 系统产品和 Liberty，然后选择与现有部署最匹配的产品。 可以在概述文章在 Azure 上运行 IBM WebSphere 系列产品的解决方案有哪些？中查看产品/服务列表。

如果任何现有产品/服务都不是良好起点，则必须使用 Azure 虚拟机资源手动重现部署。 可以在教程：在 Azure 虚拟机上手动安装 WebSphere Application Server Network Deployment 传统版中找到逐步指导。 有关详细信息，请参阅什么是 IaaS？

确定 WAS 传统版是否兼容

现有的 WAS 传统版本必须与 IaaS 产品/服务的版本兼容。 可以在 Azure VM 上的 IBM WebSphere 应用服务器单实例和 Azure VM 上的 IBM WebSphere 应用服务器群集的概述页面找到版本信息。 如果现有的 WAS 传统版与该版本不兼容，则必须使用 Azure IaaS 资源手动重现部署。 有关详细信息，请参阅什么是 IaaS？

清点服务器容量

记录当前生产服务器的硬件（内存、CPU、磁盘），以及平均和峰值请求计数和资源利用率。 此信息必须告知所选 VM 大小。 有关详细信息，请参阅云服务的大小。

清点所有机密

在出现“配置即服务”技术（如 Azure Key Vault）之前，没有有关“机密”的明确定义的概念。 你只能使用一组不同的配置设置，这些设置可以有效地充当我们现在所称的“机密”。 在应用服务器（如 WAS）中，这些机密位于许多不同的配置文件和配置存储中。 检查生产服务器上的所有属性和配置文件中是否有机密和密码。 还可以在应用程序中查找包含密码或凭据的配置文件。 WAS 将配置数据存储在多个文档中，并以目录层层递进的方式排列。 大多数配置文档都包含 XML 内容。 有关详细信息，请参阅配置文档和 Azure Key Vault 基本概念。

清点所有证书

记录用于公共 SSL 终结点的所有证书。 可以通过运行以下命令来查看生产服务器上的所有证书：

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

更多信息，请参阅 IBM 文档 SSL 中的证书管理。

验证支持的 Java 版本是否正常运行

在 Azure 虚拟机上使用 WAS 需要特定版本的 Java，因此需要确认应用程序可以使用该支持的版本正确运行。

IBM Java 8 随 WAS9 分发一起提供。 建议使用 IBM 提供的 Java JRE。 有关详细信息，请参阅 WebSphere 应用服务器传统版 V9 中的 Java SE 8。

如果要切换到不同的 Java SDK，请遵循 IBM 文档在 WebSphere 应用服务器中切换 Java SDK。

清点 JNDI 资源

清点所有 JNDI 资源。 例如，数据库等数据源可能具有关联的 JNDI 名称，该名称允许 JPA 正确地将 EntityManager 的实例绑定到特定数据库。 有关 JNDI 资源和数据库的详细信息，请参阅 IBM 文档中的 WebSphere 数据源。 其他 JNDI 相关资源（如 JMS 消息代理）可能需要迁移或重新配置。 有关 JMS 配置的详细信息，请参阅使用 JMS 资源。

检查配置文件配置

WAS 中的主要配置单元是配置文件。 因此，resources.xml 文件包含了大量的配置，进行迁移时必须仔细考虑这些配置。 此文件包含对存储在子目录中的更多 XML 文件的引用。 IBM 建议通常使用 IBM 控制台来配置 WAS 的可管理对象和服务，并允许 WAS 维护 profiles/profile-name 文件夹。 有关详细信息，请参阅在分布式和 IBM i 操作系统上管理配置文件。

在应用程序中

检查 deployment.xml 文件和/或 WEB-INF/web.xml 文件。

确定是否使用了会话复制

如果应用程序依赖于会话复制，则可以进行以下选择：

  • 对于 HTTP 会话，可以根据会话管理级别使用内存或数据库来收集会话数据。
  • 对于分布式会话，可以使用数据库会话持久化将会话保存在数据库中。
  • 对于 动态缓存，可以通过内存到内存复制或数据库来管理会话数据。
  • 重构应用程序，使用数据库进行会话管理。
  • 重构应用程序，将 Azure Redis 服务的会话外部化。 有关详细信息，请参阅 Azure Cache for Redis。

对于所有这些选项，最后是掌握 WAS 如何执行 HTTP 会话状态复制。 有关详细信息，请参阅 IBM 文档中的管理会话 Bean。

记录数据源

如果应用程序使用任何数据库，则需捕获以下信息：

  • 数据源名称是什么？
  • 连接池配置是什么？
  • 在哪里可以找到 JDBC 驱动程序 JAR 文件？

有关 WAS 中 JDBC 驱动程序的详细信息，请参阅在 WebSphere Application Server 中使用 JDBC 驱动程序。

确定是否已自定义 WAS

确定进行了以下哪些自定义，并捕获已完成的操作。

  • 是否更改了启动脚本？ 此类脚本包括 wsadmin、AdminControl、AdminConfig、AdminApp 和 AdminTask。
  • 是否有任何特定参数传递到 JVM？
  • 是否存在添加到服务器 classpath 中的 JAR？
  • 是否使用了 OS 级设施（如 systemd）来使 WAS 组件在服务器重启后自动启动？

需要根据这些问题的答案来考虑迁移问题。

确定是否需要连接到本地

如果应用程序需要访问任何本地服务，则需预配 Azure 的某个连接服务。 有关详细信息，请参阅将本地网络连接到 Azure。 或者，你需要重构应用程序，以便使用本地资源公开的公开可用的 API。

确定 Java 消息服务 (JMS) 队列或主题是否正在使用中

如果应用程序正在使用 JMS 队列或主题，则需要将它们迁移到外部托管的 JMS 服务器上。 使用 JMS 的一种策略是使用 Azure 服务总线和高级消息队列协议。 有关详细信息，请参阅将 Java Message Service 1.1 与 Azure 服务总线标准和 AMQP 1.0 配合使用。

如果配置了 JMS 持久存储，则必须捕获其配置并在迁移后应用。

如果使用的是 IBM MQ，则可以将该软件迁移到 Azure 虚拟机并按原样使用。

Microsoft 有一个将 IBM MQ 与逻辑应用程序集成的解决方案。 有关详细信息，请参阅从 Azure 逻辑应用中的工作流连接到 IBM MQ 服务器。

确定是否使用自己的自定义创建的共享 Java EE 库

如果使用共享 Java EE 库功能，则可使用两个选项：

  • 重构应用程序代码以删除库上的所有依赖项，并改将功能直接合并到应用程序中。
  • 将库添加到服务器 classpath。

确定是否使用了 OSGi 捆绑

如果使用的是添加到 WAS 的 OSGi 捆绑程序，则需要将相应的 JAR 文件直接添加到 Web 应用程序中。

确定应用程序是否包含特定于 OS 的代码

如果应用程序包含的代码有主机 OS 的依赖项，则需重构该代码，删除那些依赖项。 例如，如果应用程序在 Windows 上运行，则可能需要将文件系统路径中的 / 或 \ 替换为 File.Separator 或 Paths.get。

确定是否正在使用 IBM 集成总线

如果应用程序使用 IBM 集成总线，则需要捕获 IBM 集成总线的配置方式。 有关详细信息，请参阅 IBM 集成总线文档。

确定应用程序是否由多个 WAR 组成

如果应用程序由多个 WAR 组成，则应将这些 WAR 中的每一个都视为单独的应用程序，并通过本指南了解这其中的每个应用程序。

确定应用程序是否打包为 EAR

如果应用程序被打包为一个 EAR 文件，请务必检查 application.xml、ibm-application-bnd.xmi 和 ibm-application-ext.xmi 文件，并捕获它们的配置。 有关详细信息，请参阅在 WebSphere 上生成企业存档 (EAR) 包。

确定在生产服务器上运行的所有外部进程和守护程序

如果在应用程序服务器外运行任何进程（如监视守护程序），则需消除它们或将它们迁移到其他位置。

确定是否使用以及如何使用文件系统

在持久性、启动和关闭方面，VM 文件系统与本地文件系统的操作方式相同。 尽管如此，仍然必须了解文件系统需求，确保 VM 有足够的存储大小和性能。

只读静态内容

如果应用程序当前提供静态内容，则需为其提供一个备用位置。 可能需要考虑将静态内容移到 Azure Blob 存储，并添加 Azure CDN，方便用户在全球范围内快速下载。 有关详细信息，请参阅 Azure 存储中的静态网站托管和快速入门：将 Azure 存储帐户与 Azure CDN 集成。

动态发布的静态内容

如果应用程序允许那些通过应用程序上传/生成但在创建后不可变的静态内容，则可将上述 Azure Blob 存储和 Azure CDN 与 Azure 函数配合使用，以便处理上传和 CDN 刷新操作。 我们提供了一个示例实现，用于通过 Azure Functions 进行静态内容的上传和 CDN 预加载操作。

确定网络拓扑

当前的 Azure 市场产品/服务集是迁移的起点。 如果产品/服务没有涵盖需要迁移的体系结构的各个方面，则需要捕获现有部署的网络拓扑。 然后，即使在使用解决方案模板之一建立基本产品/服务之后，也仍需要在 Azure 中重现该网络拓扑。

网络拓扑是一个非常广泛的主题，但以下参考可为迁移工作提供某些指导：

考虑 JCA 适配器和资源适配器的使用情况

如果现有应用程序使用 JCA 适配器或其他资源适配器连接到其他企业系统，请确保将这些项目的配置应用到在 Azure 虚拟机中运行的 WAS。 有关详细信息，请参阅 IBM 文档中的关系资源适配器和 JCA。

用于身份验证和授权的帐户

大多数应用程序都有某种身份验证和授权。 如果使用 OpenID 进行身份验证，则可以使用 Microsoft Entra ID 配置 OpenID Connect 身份验证。 有关详细信息，请参阅使用 Microsoft Entra ID 进行 OpenID Connect 身份验证。

确定是否使用了 WAS 群集分析

最可能的情况是，你已将应用程序部署到多个 WAS 服务器上，以实现高可用性。 可以直接将这些群集从本地安装迁移到 Azure 虚拟机中运行的 WAS。 有关详细信息，请参阅 IBM 文档中的 WebSphere 应用服务器网络部署。

用于满足负载均衡要求的帐户

负载均衡是将 WAS 群集迁移到 Azure 的重要组成部分。 最简单的解决方案是使用 Azure 市场产品/服务中为 IBM WebSphere 应用服务器提供的对 Azure 应用程序网关或 IBM HTTP 服务器的内置支持。

要查看摘要了解 Azure 应用程序网关的功能与其他 Azure 负载均衡解决方案的比较情况，请参阅负载均衡选项。

确定是否使用了 Java EE 应用程序客户端功能

如果应用程序使用 Java EE 应用程序客户端功能，则在迁移到 Azure 虚拟机后，它应继续工作，没有更改。 有关详细信息，请参阅 Using Java EE Client Application Modules（使用 Java EE 客户端应用程序模块）。

迁移

选择 Azure 虚拟机产品/服务上的 WAS 传统版

以下套餐适用于基于 Azure 虚拟机的 WAS。

在部署产品/服务期间，系统会要求您为 WAS 节点选择虚拟机大小。 在选择 VM 大小时，请务必考虑有关大小调整的所有方面（内存、处理器、磁盘）。 有关详细信息，请参阅云服务（经典）的大小。

  • Azure VM 上的 IBM WebSphere 应用服务器单实例

    此产品/服务可自动执行大多数模板步骤，以便在 Azure 虚拟机上预配单个 WebSphere 实例。 它通过 WAS 管理控制台来创建应用服务器配置文件。

  • Azure VM 上的 WebSphere 应用服务器群集

    此产品/服务可自动执行在 Azure VM 上配置 WebSphere 群集的大部分模板步骤。 它可在 Azure VM 上创建带有 WAS 管理控制台的部署管理器，并在单独的 Azure VM 上创建所需数量的节点代理。

预配套餐

在选择从哪个产品开始后，按照在 Azure 虚拟机上部署 WebSphere 应用服务器（传统）集群中的说明为该产品进行预配。

迁移配置文件

在预配产品/服务后，就可以检查配置文件配置。 有关详细信息，请参阅 IBM 文档中的配置文件概念。

连接数据库

在迁移配置文件后，可以按照 IBM 文档配置 WebSphere 应用程序服务数据源中的说明来连接数据库。

考虑密钥存储

必须考虑应用程序所用的任何 SSL 密钥存储的迁移。 有关详细信息，请参阅 IBM 文档中的 SSL 的密钥存储配置。

连接 JMS 源

在连接数据库后，可以按照 IBM 文档在 IBM WebSphere 应用程序服务中设置 JMS中的说明来配置 JMS。

用于身份验证和授权的帐户

大多数应用程序都有某种身份验证和授权。 如果使用 OpenID 进行身份验证，则可以使用 Microsoft Entra ID 配置 OpenID Connect 身份验证。 有关详细信息，请参阅使用 Microsoft Entra ID 进行 OpenID Connect 身份验证。

考虑日志记录

可以按照 IBM 文档使用 Elastic Stack 分析 WebSphere 应用服务器日志中的说明来配置 Elastic Stack。 Azure 为 Elastic 提供了支持。 有关详细信息，请参阅什么是 Elastic 与 Azure 的集成？可以结合这两个资源中的知识，为 VM 上的 WAS 实现 Azure 优化的日志记录解决方案。

迁移应用程序

用于将开发团队的应用程序部署到测试、过渡和生产服务器的技术因情况的不同而差异很大。 在某些情况下，高度演化的 CI/CD 平台会将应用程序部署到 WebSphere 应用服务器上。 在其他情况下，该过程可能需要更多的手动操作。 使用 Azure 虚拟机将 WAS 传统版应用程序迁移到云的一个好处是，现有流程可以继续工作。

你必须配置产品/服务预配的网络安全组，以允许从 CI/CD 管道或手动部署系统进行访问。 有关详细信息，请参阅网络安全组。

测试

必须配置针对应用程序的任何容器内测试，以便访问在 Azure 中运行的新服务器。 如果涉及 CI/CD，则必须确保所需的网络安全规则允许你的测试访问已部署到 Azure 的应用程序。 有关详细信息，请参阅网络安全组。

迁移后

实现在预迁移步骤中定义的迁移目标后，请执行某些端到端验收测试，验证一切是否按预期工作。 有关迁移后一些潜在增强功能的指导，请参阅以下建议：