DB2管理：超級可用性
之前為大家介紹了DB2開發經驗小結，本文主要為大家介紹DB2管理之超級可用性。
超級可用性的定義
我至今還清楚地記得最近的一次由一名大型公司的高級 IT 專家和幾名 DB2 DBA 及系統程序員參加的工作會議。會議的討論主題是戰略可用性，即，長期戰略和規劃，它與公司核心業務應用程序的服務交付緊密相關。我們請這位專家為我們解釋開發戰略可用性計劃需要圍繞的目標。他的回答是：
“永不宕機，永不丟失任何東西”
這寥寥幾個字與商業理論家 Jim Collins(Built to Last and Good to Great的作者)稱為 BHAG(Big Hairy Audacious Goal，發音為“bee-hag”)的思想不謀而合。BHAG 倡導大膽的前瞻性思維。(我的一位朋友曾這樣反向解釋過 BHAG 式思維：“如果目標定得低，所獲得的成就也就如此。”)
讓我們來剖析一下這個可用性目標
永不宕機
首先，很有必要理解“永不宕機”的含義(即我對它的理解以及前面提及的那位IT專家對其含義的定義)。它不是指以某段時間內消逝時間的百分比所表示的數據庫或應用服務器的正常運行時間。不要曲解我的意思，設定和爭取最佳正常運行時間的目標(比如，99.9%的可用性)很有用，尤其是對于負責應用程序基礎架構的那些人(即系統管理員)而言更是如此。然而，從業務角度考慮，更重要的可用性度量手段是故障客戶交互數(FCI)。這是一個重要的區分指標。請考慮如下的兩個場景：
場景 1：公司 A 的 IT 部門經理正興高采烈地慶祝工作成績：過去1個月內可用性指標達到了99.95%。不料，負責客戶 B 的客戶關系經理忽然通知 IT 部門說公司 B 不大滿意，原因是上星期發到公司A進行處理的事務中竟有很大一部分都沒有被妥善執行。這是怎么回事呢?實際上這不是很難理解。有可能是處理公司 B 請求的某個基礎架構組件(比如應用服務器)一時出了故障;當然，這對于有數百個服務器的系統而言還不足以傷及可用性指標，但卻足以招致公司 B 的抱怨之聲。另一種可能性是由公司 A 負責系統的團隊沒有注意到的某個應用的程序邏輯錯誤恰好影響到公司 B 發來的事務處理。
場景 2：一星期之后，公司 A 的一名 DB2 DBA Julie 遇到了棘手的事情——Linux 服務器上的一個 DB2 實例受到了宕機的影響。這個DB2 實例是 HADR(High Availability Disaster Recovery)配置的一部分(HADR 是我在“DB2 Disaster Recovery, Part 2”中所描述的一個 DB2 for LUW 特性)。受影響的這個實例在20秒后再度處理請求，但從達到本月的可用性目標而論，這20秒沒有任何幫助。負責客戶 B 的關系經理恰巧路過，Julie 本準備好了要應對這場免不了的口舌之爭。但沒想到關系經理卻稱贊她杰出的工作表現：公司 B 的事務沒有出任何故障(事務超時值是30秒)。
因此，“永不宕機”真正的含義是“無 FCI”，而不是“無服務器宕機時間”。這無疑是件好事：允許存在某些不足以引起 FCI 的短暫的服務器宕機。這就意味著為了將DB2 for LUW維護應用于維護窗口之外而發起的 HADR 故障轉移這樣的動作與“永不宕機”的可用性目標沒有任何矛盾(DB2 for z/OS 數據共享也允許應用程序維護應用于維護窗口之外，正如在參考資料部分列出的我的“DB2 Disaster Recovery”DB2 DBA 專欄中所描述的那樣)。
不太好的消息是：高級 IT 專家并沒有界定是“由于本地故障而引起的永不宕機”，他只說了“永不宕機”。這就表示 IT 部門不能對因災難(洪水、火災、地震、龍卷風)致使整個數據中心癱瘓后所需進行的應用程序服務恢復袖手旁觀。
現在，已經有很多很棒的技術，可用來顯著減少當主站點發生災難時讓應用程序系統在備用站點恢復運行所需的時間，其中最棒的要數基于磁盤陣列的數據復制。而且還有一些編程實踐(比如，頻繁提交)和 DB2 參數設置(比如檢查點頻率)可以使用，但是在數據中心范圍的故障發生之后恢復系統而同時又要讓用戶感覺不到任何宕機時間，即使是做到天衣無縫，這個目標看上去也很難實現。
想想看：在主站點發生災難的30分鐘內讓應用程序在備用站點就緒對 IT 部門來說，已經很不容易了，但30 分鐘根本算不上是“永不宕機”。怎么辦?如何能讓系統恢復時間壓縮到最可能短的數值?您不妨換個角度想想，解決方案就會很明顯。
永不恢復
很明顯：要想最大限度地加快災難恢復，就是不恢復。最快的恢復就是不恢復。這怎么可能呢?一方面，請不要想著所謂的“系統恢復”，與之相反，要開始轉而想想“應用程序服務恢復”。我推崇的策略是：在站點 A 和 B 運行應用程序的一個完整實例(包括數據庫)，業務流量在這兩個站點間分割。如果站點 A 無效，不要試圖在站點 B 恢復應用程序系統A，相反，而是要將定向到站點 A 的作業路由到站點 B。
很簡單，對吧?我知道實現上述方案絕非輕而易舉。成功的前提是要讓這兩個完整但卻地理位置各異的應用程序數據庫的實例相互同步(或者近似同步)。我本人很鐘愛基于磁盤陣列的數據復制，但那(至少，只其本身)并不是一種很好的數據庫同步策略。在這種情況下，基于硬件的復制的主要問題在于遠端站點的目標磁盤卷在被用于復制時不能被遠端站點的服務器使用。換言之，在站點 B，既有用于應用程序的“活動”數據庫卷，也有復制在站點A所做的數據庫更改所需的卷——基于磁盤陣列的復制并不能導致在站點 A 所做的更改能夠反應到站點 B 的“活動”數據庫卷。如果站點 A 失陷，可以人為地讓站點 B 的目標復制卷可被站點 B 所用，但為了實用的目的，只有當站點A 的 DB2 實例要在站點 B 恢復的時候，這些卷才可用。而這并不是我們所想要的，因為我們的目標是為受站點 A 失陷影響的客戶機恢復應用程序服務，而同時又無需在站點 B 執行 DB2 恢復操作。
所以，如果出于數據庫同步的考慮而把基于磁盤陣列的復制置于考慮之外(即便該技術對于復制某些非數據庫文件十分有效)，那么我們應該考慮使用什么技術呢?我的選擇是基于軟件的復制方案。這些工具(來自多個供應商，包括 IBM)中最為復雜的部分是 與 DB2 事務日志管理器的接口以便識別在站點 A 的數據庫更改并將這些更改傳遞到站點 B(復制過程的“捕獲”塊)。在站點 B，復制軟件產品的“應用”塊將會使用 DB2 SQL 接口來在站點 B 的數據庫反應對站點 A 的數據庫所做的更改(在將站點 B 的數據庫更改傳遞到站點 A 的相反過程中，所發生的事情是同樣的)。
這個本來很有效的方案中也有不如人意之處：在站點 A 和 B 間發生的雙向的數據庫更改復制在本質上是異步的，因為基于軟件的數據復制工具要等待一個 DB2 COMMIT 以便在將相關的數據庫更改傳遞到遠端站點之前在一個站點先流動。這意味著應用程序數據庫的兩個實例將不會精確同步。實際上，它們只會近似同步，在一個站點提交數據庫更改和將更改應用到另一個站點之間有輕微的延遲(可能只有少數幾秒)。
但，這已經相當不錯了，不是么?在發生數據中心級別的故障時能獲得如此超級迅速的服務恢復，而且只有幾秒鐘的數據更改丟失?還有什么更高的希求呢?但除了“永不宕機”之外，還有另一個高要求，即“永不丟失任何東西”。
目標更加嚴格
當我提到的這個 IT 專家給出了“永不宕機，永不丟失任何東西”的目標時，我笑著對他說：“您的意思是說永不丟失任何提交了的數據庫更改，是吧?故障發生時正在進行中的與事務相關的數據庫更改則會丟失，對吧?”專家笑著回答我說：“不是。我的意思是我們永不丟失任何東西，即使是只完成一部分的事務。”
同屋的這些人不禁說到(或想到)：“這不可能。”但我們決定還是試著去相信有這個可能。若真的能找到這樣一個解決方案——它能讓用戶在即使故障發生時事務尚在執行中的情況下也覺察不到系統故障——又該如何呢?這樣的一種解決方案該是何模樣呢?
我腦海中不禁浮現了這樣的答案：將所有事務的輸入(“輸入”指的是所請求的應用程序服務、參數值，比如帳號或訂單號等等)都發送到兩個站點，但在站點 A 只“播放”與路由到站點 A 的用戶相關的那些輸入(對于路由到站點 B 的那些用戶將會在站點 B 進行同樣的處理)。
現在，就是問題的技巧所在。不好!發生了一個重大的故障事件，站點 A 失效。一旦確認了站點失效(我希望是在數秒之內)，就會啟動站點 B 接管通常路由到站點 A 的流量的過程。該過程將實行如下目標：
1. 所有流向站點 B 的事務都(指的是所有的事務，因為站點 A 離線了)暫時懸起。
2. 提交到站點 A 而沒有在站點 B 應用的數據庫更改都應用到站點 B(還記得前面提到過，由于 DB2 事務日志驅動的數據復制工具的異步特性，這兩個數據庫將會相互有些不同步)。為何如此呢?這是因為數據復制工具都會具有其自己的日志文件，而這些文件可以通過基于磁盤陣列的復制而在備用站點同步復制(雖然這只在兩個站點間使用光纖連接的距離在20至30英里內才可行)。理想情況下，在站點 B 安裝的復制工具可以讀取在站點 A 安裝的工具的日志文件副本(一旦人為讓相關卷對站點 B 的服務器可用)并使用那些信息來消除站點 A 和站點 B 應用程序數據庫實例間的時間間隙。[嘿，復制工具提供商，這可能是您的一個市場商機!]
3. 現在，處理當站點 A 離線時還尚在處理中的那些事務。我的想法是每個在站點 A 處理的事務都會在事務執行開始時被分配給一個惟一的標識符。如果這個標識符是一個基于事務輸入(正如前面所述，這些輸入發送到兩個站點)的哈希值，那么只要兩個站點使用相同的哈希算法，站點 B 的每個事務都會具有標識符，根本無需復制。當某個事務在站點 A 完成執行時，就會給此事務設一個“完成”指示，而這個完成/未完成文件也會同步復制(很可能是通過基于陣列的復制)到站點 B。在站點 B，路由到站點 A 的事務的那些標識符會與由站點 A 復制過來的“完成/未完成”值相比較。如果在站點 A 接收到的事務還沒有在站點 A 完成，相關的事務輸入(該輸入還是要發送到兩個站點)就會在站點 B“播放”，而結果則會發送回提交用戶(或提交應用程序過程)。
4. 釋放懸起的事務(參見步驟 1)以便執行，恢復正常的處理。
很容易，是不是?開個玩笑。我知道這個方案相當復雜，而且可能還需要一定的用戶編程才能讓其工作。但是我相信，這種“永不丟失任何東西”的解決方案(以及“永不宕機”的特性)是可以設計出來并實現的(實際上，類似的計劃就構成了這個專家的永不宕機/永不丟失任何東西的解決方案的基礎)。諸位盡可以大膽前行。超級可用性是可以實現的。
最后說一句：請不要試圖逃避您公司與 IT 相關的 BHAG。如果貴公司還沒有這類東西，就請奮力爭取。不管何種情況，都請您務必參與其中。它們會讓您發揮出自己的最大潛能，努力創造自己的一片天地，相信您的明天一定會是非常輝煌的。
【編輯推薦】
