再次重申
雖然我從未發現有關高可用性或災難恢復的問題出現短缺，但 上一期 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 服務級別幾乎是不可能的。簡單地說，WebSphere Application Server 管理控制台中的 “指向並單擊” 不是一個可重復的進程，至少不足夠重復以可靠地滿足這些服務級別。我甚至知道有些用戶為了確保為所有管理操作編寫腳本而沒有安裝管理控制台。我並不建議您也到不安裝管理控制台的程度，但我建議您開始使用 命令幫助 或 IBM Rational Automation Framework for WebSphere 以便為可重復的生產管理建立所需的腳本庫。
對於生產環境中所有管理操作編寫腳本是提供可重復過程的基礎，這對於維護 HA 或 CA 環境是必要的，其更改可引起錯誤或其他災難性結果。疲勞系統管理員的無意按鍵可能會導致文件系統中的文件被刪除、整個應用程序被卸載或內存升級燒壞內部硬件。在運行高可用性站點時，您必須假設某一天單元內會發生一起災難性事件。這就是獨立單元的無價之處。如果單元中的變更沒有按計劃進行 — 該單元應該已經在預生產環境中進行了排練 — 則在對單元和問題的來源采取糾正措施時，其他單元可以繼續服務生產。
與管理單獨的單元和付出的額外努力有關，遇到這種使用磁盤復制來維護第二個單元（或站點）鏡像的客戶端的情況並不常見。如果您正在使用或仔細考慮這種方法，則要認真考慮在錯誤的情況下會發生什麼（如同上面所描述的那樣），以及使錯誤從您的生產單元（使之不再使用）自動復制到備用單元的影響。這並不是說我反對使用像磁盤復制那樣的自動機制來從一個環境到另一個環境傳播變更或數據 — 這項技術非常有用 — 而是要確保您在應用變更以前擁有文件系統備份或環境 “快照” 以便您在有問題的情況下有一個恢復點。我認為多次運行腳本是最簡單的方法，因為它不僅可以維護一致的環境並且不需要付出過多的努力，但您可以決定帶有備份的磁盤復制這種方法對您的環境更有效。重要的是，如果您依靠自動機制，為了以防萬一，您需要確保有恢復計劃可以終止在整個基礎架構內傳播問題。請記住磁盤復制通常是用於 創建與主站點事務性一致的災難修復站點 的唯一可行的途徑。因此，如果您既需要災難恢復又需要這裡描述的持續可用性，一個好的方法就是在一個數據中心中有兩個單元，每一個都使用腳本管理，其中單元的內容（配置、日志、數據等）可復制到一個遠程數據中心。
越多越好？
還有一個有關運行多個單元的問題，即兩個單元足夠了嗎？提及這個的原因是 “規則 3”。基本上，如果您有其中任何兩個（單元、服務、路由等），並且其中一個從服務（無論是進行維護還是破壞的結果）中被刪除，則剩下的單個單元或組件現在就是單一故障點。此外，現在您是在一半的容量下運行。您需要仔細考慮需要多少冗余級別來滿足企業的操作需求，或許需要為您的基礎架構購買三個（或更多個）級別。顯然對您可以獲得的冗余數量會有限制；除了財務上的限制，還有面臨的實際問題，即您不能擁有所有級別，您將把它放置到哪裡？
