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