WebSphere 反向投資者: 高可用性（重申）與持續可用性

簡介： 高可用性和持續可用性通常作為同義詞使用，但兩者實際上是有所不同的，雖然提供其中一種或這兩種服務級別的基礎架構通常均依賴於多個冗餘的 IBM WebSphere 應用伺服器網路部署（IBM WebSphere Application Server Network Deployment）單元。 本文來自於 IBM WebSphere Developer Technical Journal 中文版。

在每一篇專欄文章中，“WebSphere® 反向投資者” 均會回答問題、提供指導或者討論有關使用 WebSphere 產品的基礎專題，通常還會給出與主流觀點相反但卻已被證實的建議。

再次重申

雖然我從未發現有關高可用性或災難恢復的問題出現短缺，但 上一期 WebSphere 反向投資者（處理 WebSphere Application Server 管理高可用性選項）提示最近這些問題的數量似乎有所增加。因此，在這裡我將繼續高可用性這一主題，另外會新增一些有關如何獲得高可用性（HA）和持續可用性（CA）的想法。但在我們開始討論這些話題以前，先讓我們確保大家對以下兩個術語達成共識：

• 高可用性：基礎架構（或在其上執行的應用程式）不可以承受一次超過幾秒鐘或幾分鐘的計劃外中斷，但這樣做可能並不會對企業的業務產生嚴重的影響。此外，偶爾終止應用程式幾個小時以進行有計劃的維護是可以接受的。
• 連續可用性：基礎架構（或在其上執行的應用程式）根本不可以中斷。基本上，無論計劃外的還是計劃內的中斷都沒有任何中斷補償。這種可用性級別通常被稱為 “五個 9” 或 99.999% 可用性，即可以理解為每年計劃內和計劃外的中斷總共剛剛超過 5 分鐘。

要補充說明的是，很多情況下有些人將聲稱他們 “只” 需要 “四個 9”（99.99%）的可用性或一個類似的數字，以為這樣的可用性會被歸類為 HA，實際上在一年的期間內 99.99% 和 99.999% 可用性之間並沒有任何有意義的區別。如果您進行一下數學計算，您將發現 99.99% 可用性的情況下每年仍然需要總共剛剛超過 5 小時的中斷；換個方式說，您不可能再容忍計劃外中斷超過 99.999% 可用性的情況，同樣您也不可能進行計劃內中斷的補償。

在這裡我不再描述執行 WebSphere Application Server Network Deployment 時的具體操作過程，因為這些在 這本書 和 這篇文章 中已經進行了記錄。閱讀完其中一篇或這兩篇參考資料後，明顯就會了解通過認真管理好的過程和詳細的計劃，單個 Network Deployment 單元也可以提供 HA。而且，雙單元會稍微增加管理工作（因為您需要管理兩個單元），藉助這些優勢，無論是 HA 或 CA 環境，從操作的角度看其管理的複雜性都將大為簡化。

硬體隔離

有兩個（或更多個）單元時無需單獨的硬體 — 您可以藉助 共存 功能在同一硬體上執行多個單元 — 這可以更好地將硬體充分用於每一個單元。這是因為，如果每個單元都有單獨的硬體，就會在單元之間提供完整的硬體和網路隔離。如果一個單元內的伺服器、伺服器框架、路由或其他裝置變得無法操作，硬體的隔離會確保這種情況不會影響到其他單元。這樣，具有故障裝置的單元會被離線，而生產將由剩餘的單元提供服務。對故障裝置的任何修復工作都不會影響其他單元，而且一旦修復完成，即可獨立進行測試而不影響生產。多個單元（其中每個單元都有單獨的硬體）還可以提供一種方法進行硬體升級。這是因為當伺服器或伺服器框架交換出時，可以將一個單元旋轉出生產而通過其他單元來處理負載，從而進行記憶體和 CPU 升級。同修復的情況一樣，一旦升級完成，即可進行軟硬體合併測試，如果升級過程中出現某些問題並導致硬體故障，也不會給任何使用者帶來負面影響。

軟體隔離

在有多個單元的情況下，通過將一個單元旋轉出生產這一功能，能夠將維護軟體（例如，修訂包、補丁等）應用於作業系統、基礎架構中介軟體或應用程式本身。一旦升級完成，即可進行軟硬體合併測試，如果升級過程中出現某些問題，也不會給任何使用者帶來負面影響。

很明顯，如果應用程式升級需要對共享資料庫架構進行相應地更改，這種情況會變得更加複雜。當對這種型別的升級使用多個單元時，需要考慮其他資料庫更新策略，因為在生產中執行的單元將不會識別新的資料庫架構。

對於資料庫更新，如果嘗試更新一個仍在處理應用程式資料請求的單個資料庫伺服器，其引入的操作複雜性類似於試圖使用單個單元來滿足 HA 或 CA 服務級別要求且同時應用硬體或軟體維護。這就是為什麼其他的管理工作（應該與執行兩次 — 且每個單元各一次 — 相同的管理指令碼一樣簡單）應該是造成簡化操作過程這一結果的明顯折中。

防止災難性中斷的保險

對於生產環境中所有管理操作編寫指令碼是提供可重複過程的基礎，這對於維護 HA 或 CA 環境是必要的，其更改可引起錯誤或其他災難性結果。疲勞系統管理員的無意按鍵可能會導致檔案系統中的檔案被刪除、整個應用程式被解除安裝或記憶體升級燒壞內部硬體。在執行高可用性站點時，您必須假設某一天單元內會發生一起災難性事件。這就是獨立單元的無價之處。如果單元中的變更沒有按計劃進行 — 該單元應該已經在預生產環境中進行了排練 — 則在對單元和問題的來源採取糾正措施時，其他單元可以繼續服務生產。

與管理單獨的單元和付出的額外努力有關，遇到這種使用磁碟複製來維護第二個單元（或站點）映象的客戶端的情況並不常見。如果您正在使用或仔細考慮這種方法，則要認真考慮在錯誤的情況下會發生什麼（如同上面所描述的那樣），以及使錯誤從您的生產單元（使之不再使用）自動複製到備用單元的影響。這並不是說我反對使用像磁碟複製那樣的自動機制來從一個環境到另一個環境傳播變更或資料 — 這項技術非常有用 — 而是要確保您在應用變更以前擁有檔案系統備份或環境 “快照” 以便您在有問題的情況下有一個恢復點。我認為多次執行指令碼是最簡單的方法，因為它不僅可以維護一致的環境並且不需要付出過多的努力，但您可以決定帶有備份的磁碟複製這種方法對您的環境更有效。重要的是，如果您依靠自動機制，為了以防萬一，您需要確保有恢復計劃可以終止在整個基礎架構內傳播問題。請記住磁碟複製通常是用於 建立與主站點事務性一致的災難修復站點 的唯一可行的途徑。因此，如果您既需要災難恢復又需要這裡描述的持續可用性，一個好的方法就是在一個資料中心中有兩個單元，每一個都使用指令碼管理，其中單元的內容（配置、日誌、資料等）可複製到一個遠端資料中心。

越多越好？

還有一個有關執行多個單元的問題，即兩個單元足夠了嗎？提及這個的原因是 “規則 3”。基本上，如果您有其中任何兩個（單元、服務、路由等），並且其中一個從服務（無論是進行維護還是破壞的結果）中被刪除，則剩下的單個單元或元件現在就是單一故障點。此外，現在您是在一半的容量下執行。您需要仔細考慮需要多少冗餘級別來滿足企業的操作需求，或許需要為您的基礎架構購買三個（或更多個）級別。顯然對您可以獲得的冗餘數量會有限制；除了財務上的限制，還有面臨的實際問題，即您不能擁有所有級別，您將把它放置到哪裡？

http://www.ibm.com/developerworks/cn/websphere/techjournal/1004_webcon/1004_webcon.html

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