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