通过

将 WebSphere 应用程序迁移到 Azure Red Hat OpenShift

  • 项目

本指南介绍了将现有 WebSphere 应用服务器 (WAS) 工作负荷迁移到在 Azure Red Hat OpenShift 上运行的 IBM WebSphere Liberty 或 Open Liberty 时应注意的事项。

预迁移

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

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

成功将 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 市场产品/服务是否是良好起点

在确定 Azure Red Hat OpenShift 是合适的部署目标后，必须接受 IBM WebSphere Liberty 操作程序或 Open Liberty 操作程序（操作程序）是在 Kubernetes 上运行 Liberty 的唯一方法。 接受此事实后，必须确定预生成的 Azure 市场产品/服务是否是一个很好的起点。 以下是关于预生成的 Azure 市场产品/服务需要考虑的一些事项：

  • IBM 和 Microsoft 创建了此产品/服务，让你可以在 Azure Red Hat OpenShift 上快速预配 Liberty。 下面的内容将详细解释这一概念。
  • 概括而言，产品/服务会自动执行以下步骤。
    • 如果需要，可使用现有的应用程序映像。
    • 如果需要，请预配 Azure Red Hat OpenShift 群集。
    • 在 Azure Red Hat OpenShift 上安装和配置 IBM WebSphere Liberty 操作程序或 Open Liberty 操作程序。
    • 使用操作员运行整个操作。 操作程序会在 Azure Red Hat OpenShift 中部署和管理容器化的 Liberty 应用程序。 可以在 IBM WebSphere Liberty 操作程序和 Open Liberty 操作程序中找到参考文档。

如果不使用预生成 Azure 市场产品/服务，则必须了解如何直接使用操作员。 掌握操作员超出了本文的范围。 有关操作程序的完整文档，请参阅 IBM WebSphere Liberty 操作程序和 Open Liberty 操作程序。

现在，你已经了解了在 Azure Red Hat OpenShift 上处理 Liberty 的各种方法，能够更好地选择是使用预生成的 Azure 市场产品/服务，还是直接使用操作程序自行处理。

确定 Liberty 版本是否兼容

需要使用 Open Liberty 操作程序或 WebSphere Liberty 操作程序在基于 Kubernetes 的群集上部署和管理应用程序。 确保现有的 Liberty 版本是操作程序支持的版本之一。 Open Liberty 的各个版本在 GitHub OpenLiberty/open-liberty 中维护。 IBM 维护各个版本的 IBM WebSphere Application Server Liberty。 有关详细信息，请参阅 WebSphere Application Server Liberty。

预生成的 Azure 市场产品/服务允许从公共注册表中选择应用程序映像，从而隐式支持所有的版本。

确定是否需要许可证

对于 IBM WebSphere Liberty，必须接受与应用程序容器中的 IBM 程序版本相对应的许可协议中的条款。 有关适用于此 IBM 计划的许可协议，请参阅查看 WebSphere Liberty 操作程序的许可信息。 有关详细信息，请参阅在 Microsoft Azure 上运行 WebSphere Liberty。

如果产品版本不是默认的 IBM WebSphere 应用服务器（基础版），则 .spec.license.edition value 必须指定产品版本。 其他可用值是 IBM WebSphere Application Server Liberty Core 和 IBM WebSphere Application Server Network Deployment。 预生成的 Azure 市场产品/服务允许你选择支持的产品版本。

使用 IBM 迁移工具开列差异清单

要将应用程序迁移到 WebSphere Application Server Liberty 或 Open Liberty，则需要制定迁移计划、分析应用程序并更新源代码。 IBM 提供了迁移工具，可帮助识别当前环境与新 Liberty 环境中技术之间的任何差异，如 Java EE 7 或 Java EE 8，以及 Java SE 8 或 Java SE 11。 有关详细信息，请参阅将应用程序迁移到 Liberty。

清点服务器容量

记录当前生产服务器的硬件（内存、CPU、磁盘）、平均值和峰值请求计数，以及资源利用率。 无论选择哪种迁移路径，都需要这些信息。 例如，这些信息有助于指导选择节点中 VM 的大小、容器使用的内存量以及容器需要多少 CPU 份额。

要利用未使用的容量并节省大量成本，可以在 Azure Red Hat OpenShift 中使用 Azure 现成虚拟机。 要了解如何使用，请参阅 在 Azure Red Hat OpenShift 集群中使用 Azure 现成虚拟机。

清点所有机密

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

在获得了可靠的机密清单后，请查阅有关机密的操作人员文档。 有关详细信息，请参阅以下文章：

清点所有证书

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

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

在获得可靠的证书清单后，就可以按照以下文章对它们进行配置：

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

使用 Liberty 需要特定版本的 Java，因此需要确认应用程序是否可以使用该支持版本正确运行。

WebSphere Application Server Liberty 的运行时对 Java 运行时环境 (JRE) 的最低级别有特定要求。 有关详细信息，请参阅功能的 Java 版本依赖关系。

Open Liberty 需要使用 Java SE 运行时。 它可以通过 Java 运行时环境 (JRE) 或 Java SE 开发工具包 (JDK) 分发来运行。 有关详细信息，请参阅支持的 Java SE 版本。

清点 JNDI 资源

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

如果使用预生成 Azure 市场产品/服务，则可以在部署时自定义的 JNDI 资源集仅限于产品/服务支持的内容。 对于 Azure Kubernetes 服务 （AKS）上的 WebSphere Liberty，可以在默认的 Java 命名和目录接口 （JNDI） 命名空间中提供对象。 有关详细信息，请参阅在 Liberty 功能中使用 JNDI 默认命名空间进行开发。 有关 Open Liberty，请参阅 Java 命名和目录接口。

检查配置文件配置

WAS 中的主要配置单元是配置文件。 因此，resources.xml 文件包含了大量的配置，进行迁移时必须仔细考虑这些配置。 此文件包括对存储在子目录中的其他 XML 文件的引用。 有关详细信息，请参阅在分布式和 IBM i 操作系统上管理配置文件。

在应用程序中

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

需要在 Azure Red Hat OpenShift 运行的容器映像中捕获这些自定义设置。 在使用预生成的 Azure 市场产品/服务时，最好通过创建自定义容器映像并将其置于公共注册表中，然后在部署时指向该注册表来处理此类自定义。

如果使用的是 WebSphere 应用服务器网络部署单元，则每个群集成员都在一个传统 WAS 安装中运行。 Liberty 是 WebSphere 应用服务器的轻量级配置文件。 它是 WAS 的一个灵活的动态配置文件，可使 WAS 服务器只部署所需的自定义功能，而无需部署大量可用的 JEE 组件。

确定是否使用了会话复制

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

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

对于所有这些选项，最后是掌握 Liberty 如何执行 HTTP 会话状态复制。 以下文档有助于了解如何在 Liberty 中管理 HTTP 会话：

记录数据源

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

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

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

JDBC 配置是 Liberty 的核心服务器配置。 有关详细信息，请参阅 JDBC 驱动程序。

预生成的 Azure 市场产品/服务对数据库的支持有限。 可以在应用程序映像中处理配置，并在部署产品/服务时使用该映像。

确定是否已自定义 WAS

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

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

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

需要在 Azure Red Hat OpenShift 运行的容器映像中捕获这些自定义设置。 在使用预生成的 Azure 市场产品/服务时，最好通过创建自定义容器映像并将其置于公共注册表中，然后在部署时指向该注册表来处理此类自定义。

确定是否需要连接到本地

如果应用程序需要访问任何本地服务，则需预配 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。

可以使用从 Java EE 应用程序访问第三方 API 中所述的相同技术来处理这些库。

确定是否使用了 OSGi 捆绑

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

可以在提供给预生成 Azure 市场产品/服务的映像中包含捆绑包。 有关详细信息，请参阅为 OSGi 应用程序配置库。

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

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

Azure Red Hat OpenShift 上的 Liberty 在 Linux x86_64 上运行。 任何特定于 OS 的代码都必须与 Linux 兼容。 要了解如何发现特定 OS 信息，请按照确定 Liberty 版本是否兼容部分中的步骤操作。

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

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

预生成 Azure 市场产品/服务不直接支持 IBM 集成总线。 要启用该功能，请按照 IBM 文档中启用 Liberty 上的 JMS 应用程序连接到服务集成总线中的说明进行操作。

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

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

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

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

预生成的Azure 市场产品/服务允许使用现有容器映像。 可以根据自己的业务需求来准备应用程序。

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

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

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

Kubernetes 会处理包含持久卷 (PV) 的文件系统。 预生成的 Azure 市场产品/不不支持挂载持久卷。 要创建 Azure 文件存储 StorageClass，请按照在 Azure Red Hat OpenShift 4 上创建 Azure 文件 StorageClass 中的说明进行操作。

只读静态内容

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

动态发布的静态内容

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

确定网络拓扑

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

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

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

如果现有应用程序使用 JCA 适配器或资源适配器连接到其他企业系统，请确保将这些项目的配置应用到在 Azure Kubernetes 服务 （AKS） 上运行的 Liberty 服务器。 有关详细信息，请参阅 JCA 配置元素概述和 Java 连接器体系结构。

确定是否使用了群集分析

操作程序可以为在 Azure Red Hat OpenShift 上运行 WAS 工作负荷的所有可能方式处理群集。

检查 EJB 群集分析

如果应用程序使用本地 Enterprise Java Bean (EJB)，则可能需要将它们迁移到集群 EJB。 有关详细信息，请参阅在 Liberty 上开发 EJB 应用程序。

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

预生成的 Azure 市场产品/服务使用 OpenShift 内置路由在公共 URL 中托管应用程序，并考虑负载均衡。 有关详细信息，请参阅 OpenShift Route 配置。

迁移

本部分中的步骤假定分析已引导你决定使用预生成 Azure 市场产品/服务。

预配套餐

要在Azure 门户中打开产品/服务，请参阅 Azure Red Hat OpenShift 上的 IBM WebSphere Liberty 和 Open Liberty。 选择“创建”，然后使用在前面步骤中收集的信息来帮助填写产品/服务字段。

考虑密钥存储

必须考虑应用程序所用的任何 SSL/TLS 密钥存储的迁移。 有关详细信息，请参阅 Configuring Keystores（配置密钥存储）。

连接 JMS 源

在连接数据库后，可以按照 IBM 文档中 JCA 配置元素概述的说明来配置 JMS。

考虑日志记录

如果不掌握日志记录，就无法进行云计算。 操作程序提供了不同的监控方法。 有关详细信息，请参阅监控 Liberty 服务器运行时环境。 掌握 Red Hat OpenShift 的日志记录和监控系统会很有帮助。 有关详细信息，请参阅了解 Red Hat OpenShift 的日志记录子系统和关于 OpenShift 容器平台监控。 可以为 Azure Red Hat OpenShift 配置 Azure Monitor 容器见解。 有关详细信息，请参阅为 Azure Red Hat OpenShift 配置 Azure Monitor 容器见解。 如果喜欢使用 Elastic Stack，Azure 为 Elastic 提供了强大的支持。 有关完整详细信息，请参阅什么是 Elastic 与 Azure 的集成？可以结合这些资源中的知识，为 Azure Red Hat OpenShift 上的 Liberty 实现 Azure 优化的日志记录解决方案。

迁移应用程序

无论是否选择在部署时提供应用程序映像，都需要通过 CI/CD 来更新应用程序。 OpenShift 文档中包含了有关如何进行此更新的示例。 有关详细信息，请参阅 OpenShift 容器平台 CI/CD 概述。

配置测试

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

迁移后

实现在预迁移步骤中定义的迁移目标后，请执行某些端到端验收测试，验证一切是否按预期工作。 以下文章提供了有关迁移后增强功能的信息：