WebSphere Application Server 常見問題及解答：叢集

CloudSpace發表於2008-07-11
WebAPPServer
1. 規劃叢集方案時應考慮哪些因素？

答：
在規劃高可用的叢集方案時，我們建議按以下因素規劃和評估：

1. 分析需求：
  • 是否需要持續運轉？ 大多數使用者不需要持續運轉，硬軟體升級可以離線完成；
  • 運轉時需要哪種可用性？
  • 故障恢復時對效能有什麼要求？例如，一個node/server故障時，效能可能會受到影響；
2. 分析成本：
  • 如果系統不可用，損失是多少？
  • 您準備向可用性投入多少？
3. 評估配置管理的複雜性：系統越複雜，越需要更高的技術人員技能和配置管理成本。

4. 考慮整個系統裡各元件的可用性：通常，整體可用性由系統中最弱的點決定。

5. 分析故障恢復時間：主要是故障探測時間和恢復時間。對於不同的技術，故障恢復的時間也是不同的。

6. 分析故障恢復的關鍵點：這直接關係到工作量和成本。

7. 理解程式設計模型：這關係到故障恢復對客戶端和其他元件是否是透明的。如果部分元件不是透明的，必要時需要新增額外的處理。

8. 考慮故障影響範圍：一些系統可能有一些特別的約束。故障發生時，可能有其他的系統受到影響。
 
2. 在異構平臺上建立 WAS V6.1 叢集，避免使用絕對路徑。

答：
在異構平臺上建立 WebSphere Application Server V6.1 叢集，最主要的問題是異構作業系統的目錄格式不同，產品的預設安裝目錄也不同。為了避免因目錄和目錄格式的不相同所帶來的影響，在資源配置和應用部署中，應當避免使用絕對路徑，而採用通用的節點作用域 WebSphere 變數來替代，然後根據每個節點的實際情況來對該變數賦值。
 
3. 在設計和開發執行於 WAS 叢集環境的應用程式時需要考慮哪些方面？

答：
在面向叢集環境的應用程式中，需要考慮的方面主要包括檔案同步，會話管理和動態快取等。
  • 檔案同步
    如果應用程式使用了儲存於檔案系統的資料，那麼應當保證它們在每個叢集伺服器中的一致。一個可行的解決方案是使用共享的檔案系統或共享的資料庫，然而這種方法會導致一個新的單點故障和效能的瓶頸，並且可能會增加程式設計和配置工作的複雜性。另外一種方法是使用WAS所支援的細粒度檔案更新，您可以在叢集範圍內擁有更靈活的應用程式檔案，並避免引入新的單點故障。
    關於細粒度檔案更新的更多內容，請參見WAS V6.1資訊中心： http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp
  • 會話管理
    會話管理是 Web 應用程式的一個重要的考慮事項。WAS為叢集環境下的應用程式提供了實時一致的會話資料共享機制，提供包括基於記憶體拷貝的共享和基於資料庫的共享方式。從應用程式設計的開發的角度，您應該考慮進行物件序列化和反序列化，以便將其放入會話中並在叢集範圍內進行共享。您可以使用自已定義的類將物件封裝到會話中，然後執行驗證。會話的複製是一個開銷比較大的過程。因此，為了保證效能，您需要儘量降低會話物件的大小，從而提高複製時的效率。
  • 動態快取
    您可以通過使用WAS提供的動態快取和資料複製服務來實現叢集範圍內應用程式資料的共享，這將顯著地提高應用程式的效能。

關於動態快取的更多內容，可參見WAS V6.1資訊中心： http://publib.boulder.ibm.com/in ... n_dynamiccache.html

4. 在叢集環境中，我應該使用資料庫持久化的方式還是使用記憶體到記憶體複製的方式來進行會話故障轉移？
答：
資料庫持久化和記憶體到記憶體複製之間的效能差異並不大。這是因為 95% 的複製或持久化會話開銷是在會話物件的序列化/反序列化中產生的——不論會話儲存在哪裡，這種開銷都必定會產生。  決定選擇哪種技術將部分基於這兩種技術之間的差異：
  • 通過使用資料庫，您實際上持久化了資料（儲存到磁碟中），這樣高可用性的資料庫伺服器就可以在級聯故障中倖免於難，而記憶體複製的方式無法達到此目的。
  • 對於兩個相同的單元/域，高可用性的資料庫完全可以確保兩個域之間的會話故障轉移，而對於記憶體到記憶體複製，兩個單元只能有一個通用複製器；因此，它就變為單點故障（Single Point Of Failure，SPOF）。
因此，對於必須進行交叉單元會話故障轉移的配置，只能選擇高可用性資料庫來消除 SPOF。請注意，此時跨單元共享會話是得到支援的，但不建議這樣做，因為在單元間共享狀態將使得在兩個單元中獨立升級元件（應用程式和 WAS）異常困難。  另外，利用記憶體到記憶體複製，您可以儲存的會話資訊的數量受應用伺服器的 JVM 堆大小的限制。即使在 WebSphere Application Server V6.01 中支援 64 位的 JVM，最大應用伺服器堆大小也大大小於資料庫伺服器（用作會話儲存）上可用的磁碟空間數量。因此，儘管在許多組織中，使用記憶體到記憶體複製對避免系統管理員和資料庫管理員之間的角色和職責衝突更有利，但資料庫持久化仍是最佳選擇。 
 
 有關會話、狀態複製的更多資源，請參閱 developerWorks 中國站點的文章《Java 理論與實踐：Web 層的狀態複製》。
 
5. 什麼是單元（Cell）？什麼是節點（Node）？Node、Profile 與 Server 之間的關係是什麼？

答：

單元：
單元是整個分散式網路中一個或多個節點的邏輯分組。單元是一個配置概念，是管理員將節點間邏輯關聯起來的實現方法。管理員根據具體的業務環境，制定對其整體系統整合環境有意義的條件來定義和組織構成單元的節點。就一般情況來說，可以將單元看作是最大的作用域。

在 IBM WAS ND 產品中，管理配置資料都儲存在 XML 檔案中。單元保留了它每個節點中每臺伺服器的主配置檔案。同時每個節點和伺服器也有其自己的本地配置檔案。如果伺服器已經屬於單元，則對於本地節點或伺服器配置檔案的更改都是臨時的，通過在本地提交更改生效時，本地更改覆蓋單元配置，但是當執行單元配置文件同步到節點的操作時，在單元級別上對主控伺服器和主節點配置檔案所作的更改將會替換對該節點所作的任何臨時更改。

節點：

節點是受管伺服器（Server）的邏輯分組。節點通常與具有唯一 IP 主機地址的邏輯或物理計算機系統對應，節點不能跨多臺計算機。節點分為受管節點與非受管節點。

關於 Node、Profile 與 Server:

這三個概念比較容易混淆，我們拿出來對比說明：Node=Profile。Node 是管理上使用的概念，Profile 是實際的概要檔案，它們代表同一事物。Server 就是所謂的 Application Server Instance , 這是我們實際要佈署 Application 的地方。在IBM WAS ND 產品中受管節點的 Node Agent 目的就是讓 Deployment Manager Server 可以透過 Node Agent 來管 Node (Profile) 中的 Application Server Instance，一個 Node (Profile) 中可以有多個 Application Server Instance。


如果是非 ND 版本 , 則屬於 Single Server 版本，那麼一個 Node (Profile) 中只能有一個 Application Server Instance，如果你希望在一臺機器上有多個 Application Server Instance，那就只能透過建立多個 Profile (Node) 來達成，但這些 Node (Porfile) 彼此獨立沒有管理上的關係 (RelationShip)，只要使用的 TCP/IP Port 不要衝突即可。  有關分散式網路環境中相關概念的更多資源，請參閱 developerWorks 中國站點的文章《IBM WAS ND 分散式網路環境的理解與叢集的實現》。
 
6.我可以在多個資料中心上執行 WebSphere Application Server 單元嗎？

答：
是的。但也許這樣做是不明智的。

首先，讓我們看一下最明顯的問題：資料中心之間的網速和可靠性。在許多情況下，WAN 的效能和可靠性不如 LAN，雖然有些環境下 WAN 非常可靠而且能提供 LAN 頻寬；在這種情況下，對於應用程式（例如 WebSphere Application Server）來說，WAN 與 LAN 是一樣的。所以簡單的回答是：當然，請繼續這樣做，如果您有一個又快又可靠的 WAN。然而，一個更重要的問題被忽視了：為什麼有多個資料中心呢？通常，您這樣做是為了提高可靠性，因此如果一個資料中心全部失敗或丟失（換句話說，一個真正的“災難”），則您想讓其餘的資料中心能處理工作而不會有很大問題。考慮到這一點，人們需要為時間不短的資料中心停機作好計劃，因此，這種狀態下的可靠性將會變得非常重要。另外，這種情況下的故障轉移要正確測試可能非常困難，因為這是在“正常的”WebSphere Application Server 故障轉移（處於元件級（伺服器、Web、EJB 等），而非資料中心級）範圍外。

在這種情況下，特別是當客戶機位於一個資料中心而伺服器位於另一個資料中心時，WLM 端點會發生什麼情況呢？EJB WLM 或 HTTP 伺服器外掛 WLM 都會出現這種情況，這取決於部署和網路體系結構，雖然這兩種 WLM 實現都會還原（通過超時），但這是需要考慮（和可能避免）的另一種情況。

WebSphere Application Server Network Deployment 部署管理器是一個單點失敗。因此，如果您失去執行部署管理器的資料中心，也就失去了管理單元的能力，直到仍然存在的資料中心啟動備份部署管理器為止。雖然這種問題能夠解決，但它仍然是在故障中需要處理的另一個問題。

如果您選擇分發 HTTP 會話物件，而且您使用資料庫來實現此目的，則如果該資料庫位於現在沒有執行的資料中心，會話資訊會出現什麼情況呢？

雖然的確可以構建（和測試）交叉中央叢集解決方案（如果您非常謹慎地運用），但也始終存在丟失某些東西的風險，這在真正面臨災難時會出現。這是因為還存在一些我在這裡沒提到（和我沒有考慮過）的問題，它們致使我再次建議跨多個資料中心執行 WebSphere Application Server 單元。正如我經常提到的，災難不是您在工作中想要經歷的事情。  

本答案，來自IBM WebSphere 開發者技術期刊中的來自 Tom Alcott 的評論:欲言又止的 WebSphere Application Server 的相關問題，第 2 部分

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

相關文章