利用 WebSphere Extended Deployment 實現應用程式的無縫線上更新

CloudSpace發表於2009-04-09
Web

前言

WebSphere Extended Deployment 產品對 WebSphere Application Server 網路部署版（以下簡稱 WAS ND）和其他中介軟體平臺進行了擴充套件。它主要著眼於對服務質量的保證、效能的提高以及彈性和可管理性等方面。WebSphere Extended Deployment V6.1（以下簡稱 WebSphere XD ）版本有 3 個產品包。2008 年 4 月，每個產品包被獨立成一個產品： Operations Optimization 產品包的新名稱為：WebSphere Virtual Enterprise（以下稱為 WVE）；Data Grid 產品包的新名稱為：WebSphere eXtreme Scale；Compute Grid 產品包的名稱為：WebSphere Compute Grid。

WebSphere Virtual Enterprise 產品通過在應用程式級別實現虛擬化，能夠讓企業的應用更好地實現 Service Level Agreement（SLA）。SLA 是網路服務供應商跟客戶之間的協議，客戶通常用可度量、可證明的方式指定網路服務供應商提供的服務。WVE 的一個重要特性就是對應用程式的版本管理功能。WVE 使得企業可以在 WAS ND 的一個單元中管理同一應用程式的多個版本。您可以方便地通過管理控制檯上的版本控制中心釋出新版本，在釋出期間不會中斷使用者的繼續使用，即實現無縫線上更新；而且如果發現新發布的新版本存在錯誤，也能夠方便地回退到之前的某個穩定版本。

在閱讀本文之前，如果您瞭解 WebSphere Application Server Network Deployment V6.1 及 WebSphere Extended Deployment V6.1 概述 的功能，那麼將會很有幫助。


WAS ND 中的應用程式更新功能

WAS ND 產品本身具有可以對應用程式進行更新的功能。下面我們為您介紹如何使用 WAS ND 中的應用程式更新功能。

在WAS ND V6.1 中，管理員可以對應用程式的整個程式包、單個模組、單個檔案等進行更新。如果一個應用程式安裝在叢集上，當應用程式的檔案或配置被更新後，點選管理控制檯上的“啟用更新”（Rollout Update）按鈕，那些被更新的檔案或配置將會被依次安裝到叢集中的各個成員伺服器上。“啟用更新”會在各個叢集的成員伺服器上依次完成下面的步驟：

  1. 儲存更新後的應用程式的配置。
  2. 停止一個節點上的所有成員伺服器。
  3. 通過同步配置更新該節點上的應用程式。
  4. 重啟該節點上被停止的成員伺服器。
  5. 在叢集所在的其他節點上重複步驟 2 到 4。

由於每個節點上的成員伺服器有停止-啟動的操作，因此，那些正在進行中的 HTTP 和JMS 事務有可能丟失。另外，Web Server Plug-in 只有在檢測到一個成員伺服器停止服務後（如響應超時）才會選擇向叢集中其他成員伺服器傳送請求。這時，必須通過額外的努力縮減對客戶請求產生的影響。文章 WebSphere Application Server V6 的系統管理，第 5 部分 中講到了如何使用一種通用的模式來儘量解決這個問題：

  1. 建立冗餘應用程式目標，以進行工作負載管理和保證持續可用性。
  2. 從某些目標子集將請求路由到別處。
  3. 當所有工作已從該目標子集轉移後，更新部署在其上的應用程式。
  4. 使已更新的目標子集重新聯機。
  5. 將工作路由回已更新的子集。
  6. 對於剩餘的應用程式目標重複以上步驟。

本節向您講述了WAS ND 中的應用程式更新功能。接下來我們看 WebSphere XD 是怎樣實現應用程式版本的無縫更新的。

WebSphere XD 版本管理的應用場景

WebSphere XD 中的版本控制中心具有如下的功能：

  • 線上無縫版本更新
  • 回退到舊版本
  • 部分測試人員使用“驗證”模式對即將上線的新版本線上進行最後的測試。

下面我們對這些功能進行一一介紹。

線上無縫版本更新

WebSphere XD 可以對應用程式進行線上的無縫版本更新，用一個新的版本取代當前的活動版本。新版本可以是對當前版本的簡單修改，也可以包含比較複雜的修改，只要新版本是向後相容的，那麼更新時當前訪問應用程式的客戶將不會受到影響。

更新應用程式時有 3 個配置選項：

1.轉出策略。

在進行版本轉出時，將一個版本替換為另一個版本，WebSphere XD 在替換過程中不會中斷當前正在執行的應用程式。這點是通過下列步驟實現的：先停止當前應用程式請求，然後將新請求重新傳遞給其他伺服器或者對請求進行臨時排隊，直到新版本可以使用為止。

有兩種轉出策略可供選擇：分組更新策略和原子更新策略。

  • 分組更新策略。將目標叢集上的成員分為多個組，然後一組一組地替換這些成員上的版本。分組更新是最典型的選項，對於大型叢集很有用。當新版本在分組更新期間變為可用時，所有請求都將定向至該新版本。
  • 原子更新策略。在叢集的一半成員上，使用原子更新將一個版本一次性地替換為另一個版本。此更新策略將使用一致的應用程式版本來處理所有使用者請求。由於使用一致的版本來處理所有使用者請求，因此叢集將以一半成員伺服器的容量執行。如果叢集很大，那麼考慮使用分組更新將您的轉出劃分為較小的組。另外，原子方式還可以與單個伺服器部署目標配合使用。在單個伺服器部署目標中，對叢集的另一半成員執行的操作將被忽略。

分組更新策略模式適合於叢集，並對由分組大小給定的叢集成員數目執行併發替換，使得同一組內的 server 上的應用同時被更新到新版本並被啟用。原子更新策略同時適合於叢集單個伺服器，它保證在同一個時刻更新半數的 server，被更新的版本先處在未啟用狀態，並在隨需應變路由器（ODR）的幫助下保證客戶請求在更新應用版本的時候不丟失。

2.復位策略。

復位策略將管理如何從記憶體中卸裝舊版本以及如何裝入新版本。復位策略將與轉出策略一起工作。在進行版本轉出時，每個伺服器上的新版本都將被啟動，有兩種啟動策略：軟復位或者硬復位。執行軟復位時，停止舊版本的應用程式，並啟動新版本的應用程式。在執行這些操作的期間，伺服器保持執行。執行硬復位時，停止正在執行舊版本應用程式的伺服器，然後使用新版本替代舊版本來重新啟動該伺服器。軟復位通常適合於大多數應用程式。而對於依賴於由底層作業系統裝入的工件（例如，本機庫）的版本來說，則需要進行硬復位。

3.消耗時間間隔。

消耗時間間隔是一個時間量，由使用者指定。當 WebSphere XD 準備更新一個伺服器上的應用時，首先不再轉發新請求過來，等待一定時間，然後再開始執行復位策略操作（新舊版本更替），這個等待的時間就是消耗時間間隔。在此時間間隔內，與伺服器具有會話親緣關係的請求仍會路由到該伺服器，其他請求將不會被轉發過來。此時間間隔內允許有一段時間，以便完成現有 HTTP 會話和進行任何自動驅動的應用程式清除工作。消耗時間間隔的存在避免了那些正在進行中的 HTTP 和 JMS 事務的丟失。

版本更新時的這 3 個配置選項保證了更新的漸進性及無間斷性。

回退到舊版本

如果一個應用程式的版本（如：版本2）被更新後在執行中發現存在問題，那麼管理員可以很容易地回退到以前的一個穩定執行的版本（如：版本1）。回退的步驟和更新的步驟是一樣的，只是回退時是用舊版本取代新版本。

版本驗證

使用應用程式版本驗證功能可以在生產環境中安裝和測試一個新版本，同時執行應用程式的當前版本。例如：一個應用程式的版本 1.0 已被安裝，啟用，並在一個動態叢集上執行著。版本 2.0 是候選版本，等待驗證，被安裝到同一個部署目標-動態叢集上，處於未啟用狀態。當驗證版本 2.0 時，驗證動作會複製當前叢集，成為一個新的動態叢集，並把版本 2.0 對映到這個新的動態叢集上。複製出來的叢集使用既存的叢集成員作為新的伺服器模板來複製出新的叢集的成員伺服器。

在開始驗證前，必須為版本 2.0 定義唯一的路由規則。路由規則使得不同版本的應用同時存在成為可能，它規定客戶的請求仍然被路由到原來的動態叢集上，而那些用於驗證版本 2.0 的 HTTP 請求將被路由到複製出來的動態叢集上，不影響版本 1.0 的工作。

對應用程式進行線上無縫更新時需要注意 WVE 版本相容的標準。如果不符合相容標準，可能不會達到無縫更新。下面是版本相容的標準：

  • 應用程式介面或語義：如果對現有介面進行更改，其中包括修改或除去現有介面，那麼將破壞應用程式的現有使用者。類似，假如介面先前允許引數為 NULL，但所作更改要求該引數不為 NULL，那麼對介面的語義行為進行更改時，也會破壞現有使用者。如果所作更改會影響現有客戶機，那麼視這些更改不能向後相容，因此，不能通過無縫升級予以解決。如果對現有客戶機的影響不會造成任何問題，那麼可以使用 WAS 轉出更新。
  • HTTP 會話狀態：如果 HTTP 會話狀態是持久或複製的，那麼諸如對會話新增資料型別或更改儲存在會話中的資料型別這樣的應用程式更改也意味著所作更改不相容。當前版本可能無法使用先前版本建立的會話狀態。
  • 資料庫：諸如對錶新增欄位或更改資料型別這樣的應用程式更改也意味著所作更改不相容。

下面我們將通過例項場景來向您說明線上版本更新的具體過程。

版本更新例項

我們使用示例應用程式 xddemo.war 的兩個版本來演示。xddemo.war 裡面包含兩個簡單的 jsp：page1.jsp 和 page2.jsp。從 page1.jsp 提交一個表單給 page2.jsp，兩個 page 裡面都含有版本標誌資訊。程式碼如下：

清單 1. page1.jsp V1.0



This is version 1.0!
Input User Name :

清單 2. page2.jsp V1.0



This is version 1.0!


User Name is :

各 jsp 的版本 V2.0 與 V1.0 的差別僅在於第三行程式碼，V2.0 為 ：

This is version 2.0!

建立一個動態叢集 DC1，其中包含兩個伺服器例項。將動態叢集 DC1 置成手工模式，如圖 1。啟動所有 Server 例項（圖 2）。


圖 1：動態叢集列表


圖 2：Server 例項列表

首先安裝第一個應用程式版本。在管理控制檯上點選應用程式->企業應用程式->安裝，選定應用程式，指定上下文根為 /xddemo。點選下一步。

在安裝新的應用程式頁面，注意填寫應用程式版本，如下圖：


圖 3：選擇安裝選項

在步驟 2 將應用程式對映到動態叢集 DC1。安裝完成後，啟動應用程式，通過 ODR 訪問 /xddemo/page1.jsp，驗證 page1.jsp， page2.jsp 都顯示版本 1.0，如圖 4、5 所示。


圖 4：page1.jsp V1.0


圖 5：page2.jsp V1.0

下面開啟一個新的瀏覽器頁面，訪問 /xddemo/page1.jsp，輸入 User Name: NewUser，如圖 6。不要關閉此瀏覽器，記住此時頁面顯示版本 V1.0。


圖 6：版本更新前的 page1.jsp

下面我們安裝版本 2。版本 2 的安裝與版本 1 的安裝是一樣的，指定相同的上下文根：/xddemo，對映到相同的動態叢集 DC1，只是在上圖 3 填寫的版本號為 V2.0。安裝完成後，在應用程式->版本控制中心點選xddemo_war 應用程式，可以看到版本V1.0 處於活動狀態，而版本 V2.0 處於不活動狀態。


圖 7：管理版本-1

選中 V2.0 版本，點選“轉出”按鈕，進入如圖 8 所示的版本轉出配置介面。


圖 8：版本轉出配置

在本例中我們使用預設的配置選項，讀者可以嘗試使用其他選項。轉出策略選擇分組策略，組大小為 1，即每次更新一組 Server，也就是一個 Server。復位策略選擇軟復位，即在一個 Server 上更新了版本後，只重啟應用程式，而不是重啟 Server。因為程式非常簡單，沒有事務處理，這裡消耗時間間隔選擇 3 秒，即在 Server 上停止接受新請求但繼續處理正在執行中的現有 HTTP 會話和一些清除工作的時間為 3 秒。

配置好轉出策略後點選確定。應用程式開始更新。在此期間可開啟新的瀏覽器頁面訪問page1.jsp/page2.jsp，應用程式仍能訪問，在開始階段可能顯示版本 V1.0 的頁面，在後來階段會顯示版本 V2.0 的頁面。這是因為，首先更新的是第一組 Server，第二組 Server 仍執行版本 V1.0 應用程式；第一組 Server 更新成功後，開始執行版本 V2.0，第二組Server再開始更新。

更新成功後，開啟一個新的瀏覽器，訪問應用程式，/xddemo/page1.jsp 顯示如圖 9 所示的 V2.0 頁面，點選 Next，顯示如圖 10 所示的 V2.0 頁面。


圖 9：page1.jsp V2.0


圖 10：page2.jsp V2.0

下面回到版本更新前開啟的如上圖 6 所示的那個瀏覽器，page1.jsp 顯示的是版本 V1.0 的頁面，點選 Next，可以看到，page2.jsp 顯示的已是版本 V2.0 的頁面，如圖 11 所示。


圖 11：版本更新後的 page2.jsp

更新完成後在版本控制中心可以看到 V1.0 變成不活動狀態，而 V2.0 變成活動狀態，如圖 12。


圖 12：管理版本-2

這樣就完成了一個簡單的版本更新（V1.0 到 V2.0）的過程。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-586922/，如需轉載，請註明出處，否則將追究法律責任。

相關文章