共用方式為

將 WebSphere 應用程式遷移至 Azure 虛擬機器

  • 發行項

本指南說明當您想要移轉現有的 WebSphere 應用程式伺服器 （WAS） 傳統應用程式以在 Azure 虛擬機器 上執行時，應該注意的事項。 如需 Azure Marketplace 中可用 WAS 傳統解決方案的概觀，請參閱 在 Azure 上執行 IBM WebSphere 系列產品有哪些解決方案？

移轉前

為確保成功移轉，在開始之前，請先完成下列各節中所述的評量和清查步驟。

定義「移轉完成」所代表的意義

本指南和對應的 Azure Marketplace 供應專案是加速將 WAS 傳統工作負載移轉至 Azure 的起點。 請務必定義移轉工作的範圍。 例如，您是否執行從現有基礎結構到 Azure 虛擬機器 的嚴格「隨即轉移」？ 若是如此，您可能會在移轉時嘗試在一些「隨即提升和改進」中工作。

最好盡可能接近純粹的「隨即轉移」，並考慮本指南中詳述的必要變更。 定義「移轉完成」所代表的意義，讓您知道何時達到此里程碑。 當您到達「移轉完成」時，可以建立 虛擬機器 的快照集，如建立虛擬硬碟的快照中所述。 確認您可以從快照集成功還原之後，您可以執行改善，而不必擔心遺失到目前為止已達成的移轉進度。

確定目標是移轉工作的適當目標

成功將 WAS 應用程式移轉至 Azure 的第一個步驟是選取最適當的移轉目標。

WAS 傳統在 Azure 虛擬機器 上運作良好。 虛擬機 （VM） 目標是最容易的選擇，因為它最類似於內部部署部署。 虛擬機器的系統管理與部署體驗類似於您內部部署的內容。

另一個選項是將WAS傳統工作負載轉換為應用程式容器，以遷移至容器。 您可以在 Azure Kubernetes Service （AKS） 和 Azure Red Hat OpenShift 上執行容器目標。 這種緩解的取捨是經濟成本。

一般而言，相較於容器，VM 型解決方案的每分鐘成本較高。 雖然容器型解決方案的執行成本較低，但您必須限制應用程式以符合容器協調流程平臺的需求。

如果最小化變更是移轉工作最重要的因素，請考慮以 VM 為基礎的移轉。 在此情況下，請參閱將 WebSphere 應用程式遷移至 Azure 虛擬機器。

如果您可以容許將應用程式轉換為在容器內執行，以降低運行時間成本，請考慮以 AKS 為基礎的或 Azure Red Hat OpenShift 型移轉。

針對 AKS 型移轉，您可以開始使用免費層。 取得免費叢集管理，並只支付取用的虛擬機、相關聯的記憶體和網路資源的費用。 在此情況下，請參閱 將 WebSphere 應用程式遷移至 Azure Kubernetes Service。

針對以 Azure Red Hat OpenShift 為基礎的移轉，除了計算和基礎結構成本之外，應用程式節點還有另一個 OpenShift 授權元件的成本。 此成本是根據應用程式節點數目和實例類型計費。 使用隨選定價或保留實例，無論哪一個最符合您的工作負載和商務需求。 在此情況下，請參閱 將 WebSphere 應用程式遷移至 Azure Red Hat OpenShift。

Azure Red Hat OpenShift 檔中的作法指南涵蓋與移轉相關的一些層面。 如需操作說明指南的完整清單，請參閱 Azure Red Hat OpenShift 檔。

判斷預先建置的 Azure Marketplace 供應專案是否為良好的起點

IBM 和Microsoft已合作，將一組 Azure 解決方案範本帶入 Azure Marketplace，以提供堅實的起點，以遷移至 Azure。 如需供應專案清單，請參閱 在 Microsoft azure 上執行 WebSphere 系列的產品和 Liberty，然後選擇最符合您現有部署的供應專案。 您可以在概觀文章 中看到供應專案清單：在 Azure 上執行 IBM WebSphere 產品系列的解決方案為何？

如果現有的供應專案都不是很好的起點，您必須使用 Azure 虛擬機資源來重現部署。 您可以在教學課程：在 Azure 虛擬機器 上手動安裝 IBM WebSphere 應用程式伺服器網路部署中的逐步指引。 如需相關資訊，請參閱何謂 IaaS？

判斷 WAS 傳統版本是否相容

您現有的 WAS 傳統版本必須與 IaaS 供應專案中的版本相容。 您可以從 Azure VM 上的 IBM WebSphere 應用程式伺服器單一實例概觀頁面，以及 Azure VM 上的 IBM WebSphere 應用程式伺服器叢集中找到版本資訊。 如果您現有的 WAS 傳統版本與該版本不相容，您必須使用 Azure IaaS 資源來重現部署。 如需相關資訊，請參閱何謂 IaaS？

清查伺服器容量

記錄目前生產伺服器的硬體（記憶體、CPU、磁碟）以及平均和尖峰要求計數和資源使用率。 此資訊必須通知 VM 大小的選擇。 如需詳細資訊，請參閱 雲端服務的大小。

清查所有秘密

在 Azure 金鑰保存庫 等「設定即服務」技術出現之前，沒有定義完善的「秘密」概念。 相反地，您所擁有的是一組完全不同的組態設定，其作用實際上等同於我們現在所謂的「秘密」。 使用 WAS 之類的應用程式伺服器時，這些秘密位於許多不同的組態檔和組態存放區中。 檢查實際執行伺服器上的所有屬性和設定檔是否有任何秘密和密碼。 您也可以在應用程式內找到包含密碼或認證的設定檔。 WAS 會將組態數據儲存在目錄的級聯階層中的數份檔中。 大部分的組態檔都有 XML 內容。 如需詳細資訊，請參閱設定檔和 Azure 金鑰保存庫 基本概念。

清查所有憑證

記載所有用於公用 SSL 端點的憑證。 您可以執行下列命令來檢視實際執行伺服器上的所有憑證：

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

如需詳細資訊，請參閱 SSL 中的 IBM 文件 憑證管理

驗證支援的 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 維護 配置檔/配置檔名稱 資料夾。 如需詳細資訊，請參閱 管理分散式和IBM i操作系統上的配置檔。

在應用程式內

檢查deployment.xml檔案和/或 WEB-INF/web.xml 檔案。

判斷是否使用會話複寫

如果您的應用程式依賴會話複寫，您有下列選項：

  • 針對 HTTP 工作階段，根據工作階段管理層級，您可以使用記憶體或資料庫來收集工作階段數據。
  • 針對 分散式會話，您可以使用資料庫會話持續性，將會話儲存在資料庫中。
  • 針對 動態快取，您可以在記憶體對記憶體複寫或資料庫中管理會話數據。
  • 重構您的應用程式以使用資料庫進行會話管理。
  • 重構您的應用程式，以將會話外部化至 Azure Redis 服務。 如需詳細資訊，請參閱 Azure Cache for Redis。

對於所有這些選項，最好掌握 WAS 如何進行 HTTP 工作階段狀態複寫。 如需詳細資訊，請參閱 IBM 檔中的管理會話豆類 。

檔數據源

如果應用程式使用任何資料庫，則必須擷取下列資訊：

  • 數據源名稱為何？
  • 連線集區設定是什麼？
  • 哪裡可以找到 JDBC 驅動程式 JAR 檔案？

如需 WAS 中 JDBC 驅動程式的詳細資訊，請參閱 搭配 WebSphere 應用程式伺服器使用 JDBC 驅動程式。

判斷 WAS 是否已自定義

判斷已進行下列哪一項自定義，並擷取已完成的工作。

  • 啟動文稿是否已變更？ 這類腳本包括 wsadmin、 AdminControl、 AdminConfig、 AdminApp 和 AdminTask。
  • 是否有任何特定參數傳遞至 JVM？
  • 是否有 JAR 新增至伺服器類別路徑？
  • 這類 systemd 操作系統層級的設施是否已用來在伺服器重新啟動後自動啟動WAS元件？

您必須考慮移轉考慮，視這些問題的解答而定。

判斷是否需要連線至內部部署環境

如果您的應用程式需要存取您的任何內部部署服務，您必須佈建其中一個 Azure 連線能力服務。 如需詳細資訊，請參閱將內部部署網路連線至 Azure。 或者，您必須重構應用程式，以使用內部部署資源所顯示的公開可用 API。

判斷 Java 訊息服務 （JMS） 佇列或主題是否正在使用中

如果您的應用程式使用 JMS 佇列或主題，您必須將它們移轉至外部裝載的 JMS 伺服器。 使用 JMS 的其中一個策略是使用 Azure 服務匯流排 和進階消息佇列通訊協定。 如需詳細資訊，請參閱搭配 Azure 服務匯流排 標準和AMQP 1.0使用Java Message Service 1.1。

如果您已設定 JMS 永續性存放區，則必須擷取其設定，並在移轉之後套用。

如果您使用 IBM MQ，您可以將此軟體移轉至 Azure 虛擬機器，並依目前使用。

Microsoft有整合 IBM MQ 與 Logic Apps 的解決方案。 如需詳細資訊，請參閱從 Azure Logic Apps 的工作流程連線至 IBM MQ 伺服器。

判斷您是否使用自己的自定義建立共用Java EE 連結庫

如果您使用共用 Java EE 連結函式庫功能，您有兩個選項：

  • 重構應用程式程式代碼以移除連結庫上的所有相依性，並改為將功能直接併入您的應用程式。
  • 將連結庫新增至伺服器類別路徑。

判斷是否使用OSGi套件組合

如果您使用新增至 WAS 的 OSGi 套件組合，則必須將相等的 JAR 檔案直接新增至 Web 應用程式。

判斷您的應用程式是否包含 OS 特定程式代碼

如果您的應用程式包含主機 OS 上具有相依性的任何程式代碼，則必須重構它以移除這些相依性。 例如，您可能需要使用 或 \ 取代檔案系統路徑File.Separator中的任何用法/，或Paths.get如果您的應用程式在 Windows 上執行。

判斷IBM Integration Bus 是否正在使用中

如果您的應用程式使用 IBM 整合總線，您必須擷取 IBM Integration Bus 的設定方式。 如需詳細資訊，請參閱 IBM 整合總線檔。

判斷應用程式是否由多個 WAR 組成

如果應用程式由多個 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 儲存體和 CDN，搭配 Azure 函式來處理上傳和 CDN 重新整理。 我們已在使用 Azure Functions 上傳和透過 CDN 預先載入靜態內容中提供範例實作供您使用。

判斷網路拓撲

目前一組 Azure Marketplace 供應專案是移轉的起點。 如果供應專案未涵蓋您需要移轉的架構層面，則需要擷取現有部署的網路拓撲。 然後，您必須在 Azure 中重現該網路拓撲，即使使用其中一個解決方案範本來建立基本供應專案也一樣。

網路拓撲是一個廣泛的主題，但下列參考可以為您的移轉工作提供一些方向：

用於 JCA 配接器和資源配接器的帳戶

如果您現有的應用程式使用 JCA 配接器或其他資源配接器連線到其他企業系統，請確定您將這些成品的設定套用至 Azure 虛擬機器 中執行的 WAS。 如需詳細資訊，請參閱 IBM 檔中的關係型資源配接器和 JCA 。

驗證和授權的帳戶

大部分的應用程式都有某種驗證和授權。 如果您使用 OpenID 進行驗證，您可以使用 Microsoft Entra ID 來設定 OpenID 連線驗證。 如需詳細資訊，請參閱 使用 Microsoft Entra ID 進行 OpenID Connect 驗證。

判斷是否使用 WAS 叢集

最有可能的是，您已在多個 WAS 伺服器上部署應用程式，以達到高可用性。 您可以將這些叢集直接從內部部署安裝移轉至在 Azure 虛擬機器 中執行的 WAS。 如需詳細資訊，請參閱 IBM 檔中的 WebSphere 應用程式伺服器網路部署 。

考慮負載平衡需求

負載平衡是將 WAS 叢集移轉至 Azure 不可或缺的一部分。 最簡單的解決方案是針對IBM WebSphere 應用程式伺服器叢集的 Azure Marketplace 供應專案中提供的 Azure 應用程式閘道 或 IBM HTTP Server 使用內建支援。

如需與其他 Azure 負載平衡解決方案相比，Azure 應用程式閘道 功能摘要，請參閱負載平衡選項。

判斷是否使用 Java EE 應用程式用戶端應用程式功能

如果您的應用程式使用 Java EE 應用程式用戶端功能，則移轉至 Azure 虛擬機器 之後，應該會繼續維持不變。 如需詳細資訊，請參閱 使用 Java EE 用戶端應用程式模組。

遷移

在 Azure 虛擬機器 供應項目上選取 WAS 傳統

下列供應專案適用於 Azure 虛擬機器 上的 WAS。

在部署供應項目期間，系統會要求您選擇WAS節點的虛擬機大小。 請務必在您選擇的 VM 大小中考慮重設大小的所有層面（記憶體、處理器、磁碟）。 如需詳細資訊，請參閱 雲端服務 （傳統）的大小。

布建供應專案

選取要開始使用的供應項目之後，請遵循在 Azure 虛擬機器 上部署 WebSphere 應用程式伺服器 （傳統） 叢集中的指示來布建該供應專案。

移轉設定檔

布建供應項目之後，您可以檢查配置檔組態。 如需詳細資訊，請參閱 IBM 檔中的 配置檔概念。

連接資料庫

移轉設定檔之後，您可以遵循 IBM 檔案中設定 WebSphere 應用程式伺服器資料來源中的指示來連線資料庫。

KeyStores 的帳戶

您必須考慮移轉應用程式所使用的任何 SSL KeyStore。 如需詳細資訊，請參閱 IBM 檔中 SSL 的金鑰存放區組態。

線上 JMS 來源

連接資料庫之後，您可以依照 IBM 檔案中的在 IBM WebSphere 應用程式伺服器中設定 JMS 的指示來設定 JMS。

驗證和授權的帳戶

大部分的應用程式都有某種驗證和授權。 如果您使用 OpenID 進行驗證，您可以使用 Microsoft Entra ID 來設定 OpenID 連線驗證。 如需詳細資訊，請參閱 使用 Microsoft Entra ID 進行 OpenID Connect 驗證。

用於記錄的帳戶

您可以遵循 IBM 檔案中使用彈性堆疊分析 WebSphere 應用程式伺服器記錄中的 指示來設定彈性堆疊 。 Azure 提供 Elastic 的支援。 如需詳細資訊，請參閱 什麼是彈性與 Azure 整合？ 您可以結合這兩個資源中的知識，以達到 VM 上 WAS 的 Azure 優化記錄解決方案。

移轉您的應用程式

用來將開發小組的應用程式部署至測試、預備和生產伺服器的技術，會因案例而異。 在某些情況下，有一個高度進化的 CI/CD 平臺，導致應用程式部署至 WebSphere 應用程式伺服器。 在其他情況下，程式可能更手動。 使用 Azure 虛擬機器 將 WAS 傳統應用程式遷移至雲端的其中一個優點是，您現有的程式會繼續運作。

您必須設定供應專案布建的網路安全組，以允許從 CI/CD 管線或手動部署系統進行存取。 如需詳細資訊，請參閱網路安全性群組。

測試

您必須針對應用程式設定任何容器內測試，才能存取在 Azure 內執行的新伺服器。 如同 CI/CD 考慮，您必須確定必要的網路安全性規則可讓您的測試存取部署至 Azure 的應用程式。 如需詳細資訊，請參閱網路安全性群組。

移轉後

在您達到您在移轉前步驟中 定義的移 轉目標之後，請執行一些端對端驗收測試，以確認一切如預期般運作。 如需某些潛在移轉后增強功能的指引，請參閱下列建議：

  • 使用 Azure 儲存體 來提供掛接至虛擬機的靜態內容。 如需詳細資訊，請參閱 在 Azure DevTest Labs 中連結或中斷鏈接實驗室虛擬機的數據磁碟。

  • 使用 Azure DevOps 將應用程式部署至已移轉的 WAS 叢集。 如需詳細資訊，請參閱 開始使用 Azure DevOps 檔。

  • 如果您已使用 Azure 應用程式閘道 部署 WAS 傳統，您可能會想要在 應用程式閘道 上執行更多設定。 如需詳細資訊，請參閱應用程式閘道設定概觀。

  • 使用進階的負載平衡服務來增強網路拓撲。 如需詳細資訊，請參閱 在 Azure 中使用負載平衡服務。

  • 使用 Azure 受控識別來管理秘密，並指派角色型存取權給 Azure 資源。 如需詳細資訊，請參閱什麼是 Azure 資源受控識別？

  • 整合 WAS Java EE 驗證和授權與 Microsoft Entra 識別碼。 如需詳細資訊，請參閱 整合 Microsoft Entra ID 與應用程式入門指南。

  • 使用 Azure Key Vault 來儲存作為「秘密」的任何資訊。 如需詳細資訊，請參閱 Azure 金鑰保存庫 基本概念。