中斷鏡像關(guān)系是否會導(dǎo)致宕機？——寧夏銀行宕機始末

冬瓜頭

最近寧夏銀行宕機事件，引發(fā)種種猜測，謠傳不斷。原文報道不再多說，其中一句話耐人尋味，意思是“在中斷數(shù)據(jù)錄像之后即發(fā)生宕機”，帶有明顯的暗示色彩，解讀這句話可以初步得出其所“暗示”的兩個結(jié)論，第一個就是本次宕機的導(dǎo)火索是中斷了數(shù)據(jù)錄像，第二個就是提供數(shù)據(jù)錄像的廠商很有可能就是飛康，當然，第二個結(jié)論已經(jīng)是事實了。但是第一個結(jié)論，有待考證。如果一個系統(tǒng)已經(jīng)出現(xiàn)了問題，而不可逆轉(zhuǎn)的話，此時所做的任何動作，都有可能成為該系統(tǒng)最終宕機的理由，而如果不做這些動作，系統(tǒng)依然可能還會最終宕機，所以，報道里的這句話是模棱兩可的。

但是不同的人，不同的位置和角色，就會產(chǎn)生偏見了，最終偏向?qū)ψ约河欣�的那一�?cè)。這里有三個角度。首先對于用戶而言，這一災(zāi)難是巨大的，相關(guān)方面這時除了吸取教訓(xùn)，更重要的恐怕是對于責任的認定。如果有一種解釋能淡化運維和操作相關(guān)的責任，不失為一種好的危機應(yīng)對；對于飛康的競爭者們，當然是“希望”問題出在飛康身上，飛康一定是希望問題不出在自己身上。
根據(jù)有關(guān)寧夏銀行之前的相關(guān)報道，寧夏銀行的核心系統(tǒng)包括CDP在內(nèi)，已穩(wěn)定運行數(shù)年。在這其間，還曾經(jīng)于2010年進行過成功的復(fù)雜條件災(zāi)備真實切換的演練并取得成功，這一事件當時被眾多媒體和同行現(xiàn)場報道和觀摩。那么，在數(shù)據(jù)庫崩潰之前，到底系統(tǒng)已經(jīng)出現(xiàn)了什么征兆和問題，在那天，除了關(guān)閉“錄像”，用戶對于數(shù)據(jù)庫和主機還進行了哪些操作，在報告里卻不得而知。

這里拋開這些人的因素，只談技術(shù)。

中斷數(shù)據(jù)錄像這個動作到底是否會導(dǎo)致系統(tǒng)宕機，有多大幾率？要回答這個問題，就得先搞清楚這些CDP方案是怎么執(zhí)行數(shù)據(jù)錄像，詳細機制在《大話存儲2》16章有詳細描述，這里只是簡單總結(jié)一下。首先生產(chǎn)數(shù)據(jù)先被鏡像一份到一個獨立的存儲系統(tǒng)里，當達到同步收斂之后，生產(chǎn)卷和鏡像卷的IO實時同步。基于這份鏡像卷，CDP系統(tǒng)在其上實現(xiàn)數(shù)據(jù)持續(xù)捕獲劑元數(shù)據(jù)記錄，最后采用基準鏡像+增量的方式實現(xiàn)任意時間點回滾。

這里所使用的IO同步鏡像工具一般為LVM，也就是Linux和UNIX普遍使用的存儲空間批發(fā)+零售的卷管理系統(tǒng)，Logical Volume Manager。其前提是應(yīng)用的數(shù)據(jù)是部署在LV塊設(shè)備上的，如果是部署在/dev/sda這種底層塊設(shè)備上，就不能使用LVM作鏡像了。正因如此，飛康在Windows下提供單獨的Disksafe鏡像和快照管理工具，因為WIndows下幾乎沒有應(yīng)用使用系統(tǒng)自帶的動態(tài)磁盤方案（Windows下的“LVM”）。

不管是LVM，還是Disksafe，其底層都需要在IO路徑上插入filter driver，當然這是個Windows下的名詞，Linux下更直白，不叫filter，叫hook，Windows不能隨便讓你hook來hook去，它的驅(qū)動框架都是定死的，你只要填空就行了，Linux則非常靈活，但是風險自負。Windows下不少時候的IO性能比發(fā)行版Linux是要強很多的，當然如果自己定制化了內(nèi)核IO路徑就另當別論了。在Linux下，LVM底層使用的是device mapper這個名正言順的鉤子驅(qū)動，當然這個鉤子是經(jīng)過千錘百煉的，穩(wěn)定性應(yīng)該不成問題，但是不排除其依然有bug，只是幾率微乎其微。你也可以插入你自己的鉤子驅(qū)動，但是你自己的鉤子就得風險自負，內(nèi)核態(tài)里出了問題系統(tǒng)多半宕機，所以一般商用產(chǎn)品，能用內(nèi)核自帶的就用，這樣一來節(jié)省開發(fā)，二來名正言順，三來出了問題也可以撇清關(guān)系。

LVM鏡像一般都是同步模式的，也沒有地方可供更改為異步，這就要求鏡像卷縮在的系統(tǒng)性能足夠強以至于不會拖慢生產(chǎn)系統(tǒng)，此外采用同步復(fù)制也可以保證不丟失數(shù)據(jù)，只要數(shù)據(jù)是一致的。
而且，根據(jù)飛康CDP的實施手冊要求，LVM CDP 只建議配置成寫入目標模式（ write target ）, 主機只向CDP寫入I/O, 但平時并不讀取。只有在需要恢復(fù)或驗證某時間點數(shù)據(jù)時，才會將錄像點磁盤mount 到驗證機上。所以CDP 的故障或錯誤是不會反向影響到主機的數(shù)據(jù)的�，F(xiàn)在，我們再來看下一步，如果要中斷數(shù)據(jù)錄像，就得在主機上進行針對LVM鏡像卷的配置，將鏡像切開，這一步必然需要通知底層驅(qū)動，驅(qū)動此時會斷開對鏡像卷的數(shù)據(jù)IO。這一步在低IO壓力下，正常來講沒有問題，但是在高IO壓力下，對IO路徑任意一處做影響IO路徑的更改，就很有可能導(dǎo)致系統(tǒng)卡死，因為牽扯到路徑變更，勢必導(dǎo)致對資源的鎖操作，以及瞬間暫停IO，此時上層的IO仍然會不斷壓入隊列，最終會導(dǎo)致queue full，內(nèi)核遲遲不返回結(jié)果給應(yīng)用，響應(yīng)時間的增加，又會導(dǎo)致前端操作員不斷刷新重試，又會導(dǎo)致大量新IO請求，最后系統(tǒng)越來越慢，內(nèi)存耗費暴增，不得不借助swap暫存，最后swap如果要滿了的話，那就真的沒有可用內(nèi)存了，最后就是僵死態(tài)，這屬于連鎖反應(yīng)。這種現(xiàn)象在Linux x86 服務(wù)器上是有所耳聞的，但是后來的內(nèi)核版本會自動殺進程來保證新資源被分配來確保系統(tǒng)尚在運行，此時已經(jīng)算是抽風了。AIX則不會，swap滿則卡死。

再說回來，為何要中斷數(shù)據(jù)錄像？恐怕那時候系統(tǒng)已經(jīng)非常慢了，導(dǎo)致必須人為介入處理。但為什么慢？

7月初，很多業(yè)務(wù)都處于半年結(jié)算期，業(yè)務(wù)壓力暴增，從另外一些報道，系統(tǒng)在徹底中斷之前，有一些業(yè)務(wù)已經(jīng)中斷了。網(wǎng)上還有一些數(shù)據(jù)庫專家的猜測，這個多年沒有維保的Informix 系統(tǒng)踩到了那幾個老版本Informix 上已知的“地雷”，中招的現(xiàn)象就是系統(tǒng)很慢，類似假死。但可怕的是數(shù)據(jù)庫一旦重啟，將系統(tǒng)崩潰。可能也正是由于此，才會人為介入，此時該系統(tǒng)已經(jīng)是茍延殘喘，動底層驅(qū)動，很有可能是壓垮駱駝的最后一根稻草。但是這點必須根據(jù)現(xiàn)場經(jīng)驗和系統(tǒng)log日志才能夠具體判斷，如果中斷錄像之后沒多久立即宕機，那么這個動作可以被判斷為是最終那根稻草，如果沒有立即宕機，那么這個動作或許本來對系統(tǒng)是沒產(chǎn)生決定性影響的。另外，宕機類型也得搞清楚，是立即重啟了，還是僵死態(tài)比如尚能ping通，這兩個是很不一樣的，如果是立即重啟，則該動作導(dǎo)致的可能性就非常大了，如果是僵死，也不足以判斷是否該動作產(chǎn)生決定性影響。

所以綜上來看，該系統(tǒng)過于老舊，而新業(yè)務(wù)猛增的IO壓力，是根因，中斷錄像可能是導(dǎo)火索，也可能根本沒起決定性作用。這次事件至少給人一個教訓(xùn)，洪水是很快的，等到噴涌直下的時候再去筑堤壩是來不及的。技術(shù)上可以有些改善，當然，也要付出更多成本，比如可以利用交換機上的端口鏡像功能或者封裝之后的接口比如SANtap Service，這樣就可以與主機徹底撇清關(guān)系了。

最后，利用此事件打擊對手其實并不是明智之舉，大家都是做容災(zāi)的，難道用了其他家的就不會出這種問題？如果能拿出針對IO方面的更好設(shè)計和技術(shù)，倒是值得討論，如果只是煽風點火，其實最后都是砸自己的腳。

muslin529

冬瓜兄威武

鍋鐵做

回復(fù) 1# 冬瓜頭

大家好，

我的觀點是這樣的：
首先要弄清飛康用的是哪個產(chǎn)品，這個很重要，如果NSS，而CDP僅僅作為輔助，這個故障出現(xiàn)的幾率很��；
（但如果甲方說了:既然問題出了，必須站出來個背鍋的，否則第二年預(yù)算下來你就可以滾了，我想作為廠商則沒什么脾氣，對嗎？所以這里面事情也許能寫出一本書出來）

而此時，我僅僅想在技術(shù)發(fā)表下看法：

其次，如果飛康用的是IPstor+CDP就難說了，因為在應(yīng)用主機安裝一個Agent拆分IO給CDP有很大的隱患，隨之主機業(yè)務(wù)并非越高，Agent越是要向主機請求更多的性能來拆分IO至CDP設(shè)備，所以，這是一個潛在的放大效應(yīng)，當某些組件出現(xiàn)瓶頸（如：CDP存儲響應(yīng)，應(yīng)用主機CPU負載,鏈路等等），那會導(dǎo)致很多問題出來，即使停機也在所難免。

最后我想說，這句話我個人非常認同
“最后，利用此事件打擊對手其實并不是明智之舉，大家都是做容災(zāi)的，難道用了其他家的就不會出這種問題？如果能拿出針對IO方面的更好設(shè)計和技術(shù)，倒是值得討論，如果只是煽風點火，其實最后都是砸自己的腳。”    

很早之前，很多網(wǎng)友就因為CDP引發(fā)了無數(shù)的口水戰(zhàn)與不理解，我想說的是，CDP的技術(shù)原理也許大同小異，但是每個廠商CDP所運用的場景是不同的，因為某次事故而槍斃所有的CDP廠商，產(chǎn)品，方案，這并不是一個技術(shù)人員的職業(yè)操守，請往下看我的詮釋：

對CDP有諸多分歧，我想很多時候是因為不同技術(shù)領(lǐng)域的代溝，很多人還停留在利用CDP做容災(zāi)的階段，沒錯，還有很多廠商致力于CDP容災(zāi)，尤其是國內(nèi)廠商。
但是：類似EMC Recoverpoint，上海愛數(shù)的CDP等等，并不是寄托于CDP容災(zāi)的，我自己認為。
他們?nèi)轂?zāi)的手段是存儲陣列之間的實時鏡像-Synchronous Mirroring；也就說，在同城的兩個中心，各放置若干套EMC VPLEX引擎，或者愛數(shù)的什么虛擬化網(wǎng)關(guān)，讓兩個數(shù)據(jù)中心存儲陣列之間永遠保持兩份相同的數(shù)據(jù)副本，待其中一個數(shù)據(jù)中心陣列或者整個數(shù)據(jù)中心毀掉，那第二個數(shù)據(jù)中心會即時接管業(yè)務(wù)。這已然成為了一套最高級別的高可用解決方案。
那回到之前，那EMC和上海愛數(shù)還要擴展CDP方案做什么？替用戶多消化下預(yù)算？
坦白的說Synchronous Mirroring，也有一個很小的弊端，那就是為了履行即時接管的職責，兩個數(shù)據(jù)中心的數(shù)據(jù)副本永遠會保持一致，包括運維人員不小心刪掉了一些數(shù)據(jù)在HOST上面，包括病毒蠕蟲**，網(wǎng)絡(luò)入侵或者軟件bug，這時候CDP就能夠非常精細的回滾數(shù)據(jù)之上一個時間點，上一天，上一個小時，甚至“秒”，CDP能夠提供一個較短的RTO，并且縮小RPO，尤其是TRUE CDP技術(shù)。

在上面例子能夠看出，不是每個廠商都是依靠CDP做容災(zāi)的，也許僅僅是輔助，對于邏輯錯誤的輔助；因為對于單個NODE或單個數(shù)據(jù)中心已然有Sync Mirroring，如果還不放心區(qū)域故障，還可以擴展為遠程容災(zāi)至另一個城市/國家，利用EMC Geo或者上海愛數(shù)的遠程復(fù)制（這就是兩地三中心），而CDP僅僅是對用戶的一種高度負責及節(jié)省備份產(chǎn)品的投入。

如果，因為一個技術(shù)人員自身學(xué)藝不精，就草草的對某些事情下定論，到頭來可悲的卻是自己。

再次重申，以上是我個人的看法，根據(jù)我的經(jīng)驗，閱歷，不為任何廠商漂白或粉飾什么，我只為我自己代言。


基于人道主義，我倒是期盼這件事情不會對飛康帶來多大影響，因為這幾個Q飛康的業(yè)績已經(jīng)令人堪憂了。

hxsaj

都是存儲大拿，牛逼。

mike1979

AIX里swap滿了也會殺進程，errpt里有時會有記錄。但這些其實都沒啥用，你殺死一些進程釋放的資源根本無濟于事。

飛康CDP功能強大，但是缺陷也很明顯。LVM鏡像要求兩個分支存儲的性能相當。而飛康CDP上還要周期性做快照，那么飛康CDP的存儲性能應(yīng)該比另一個分支存儲更強些才是�？蓪嶋H中大都是1臺高端存儲+1臺飛康CDP，完全顛倒了。

回過去說為什么系統(tǒng)慢？有可能是informix bug，但也可能是飛康CDP拖累了。寧夏銀行用的是DMX800+飛康CDP，這就是我說的性能顛倒。LVM鏡像是同步寫，寫性能取決于性能差的分支存儲。

飛康CDP號稱能做備份和容災(zāi)，同時生產(chǎn)系統(tǒng)中它也要插一腳�？蓡栴}是備份和容災(zāi)是IT系統(tǒng)的最后防線，要是都用飛康CDP，就是把雞蛋放在同一個籃子里了。最壞情況下就是都不能用。

比較奇怪的是，就算把飛康CDP關(guān)掉，那么在DMX800上還有一份完整數(shù)據(jù)，這份數(shù)據(jù)應(yīng)該是可用的。哪怕系統(tǒng)宕掉重起，也應(yīng)該能把數(shù)據(jù)庫拉起來。出現(xiàn)公告中說的“數(shù)據(jù)庫損壞”很奇怪。

冬瓜頭

3樓黑的太明顯了。

鍋鐵做

回復(fù) 6# 冬瓜頭

首先，黑與不黑取決您的心態(tài)，心態(tài)不正做什么都是變質(zhì)的對嗎？可我只能保證自己的心態(tài)在寫這些時候是正常的。

其次，看東西不能只看喜歡的部分，正如我所擔心的，我在倒數(shù)第二句寫了：
"再次重申，以上是我個人的看法，根據(jù)我的經(jīng)驗，閱歷，不為任何廠商漂白或粉飾什么，我只為我自己代言"
--------而--之所以追加這個沒有意義的回復(fù)，完全是因為之前拜讀過某個網(wǎng)友送的一本書，正是閣下的 -存儲2.

最后，不是每個廠商的CDP技術(shù)都是鏡像數(shù)據(jù)至另一個存儲的，也許僅僅是捕捉變化的IO，到頭來僅僅需要個日志空間，最終需要依賴源數(shù)據(jù)才能恢復(fù)，所以，即使寫書里了，這段話并非通用在所有廠商：

“首先生產(chǎn)數(shù)據(jù)先被鏡像一份到一個獨立的存儲系統(tǒng)里，當達到同步收斂之后，生產(chǎn)卷和鏡像卷的IO實時同步”

勿回，
晚安！

   

mike1979

鍋鐵做 發(fā)表于 2014-08-08 22:31
最后，不是每個廠商的CDP技術(shù)都是鏡像數(shù)據(jù)至另一個存儲的，也許僅僅是捕捉變化的IO，到頭來僅僅需要個日志空間，最終需要依賴源數(shù)據(jù)才能恢復(fù)，所以，即使寫書里了，這段話并非通用在所有廠商：

“首先生產(chǎn)數(shù)據(jù)先被鏡像一份到一個獨立的存儲系統(tǒng)里，當達到同步收斂之后，生產(chǎn)卷和鏡像卷的IO實時同步”

你跟他說的根本不是一回事。你自己也說依賴源數(shù)據(jù)才能恢復(fù)，你這個源數(shù)據(jù)只能在CDP上吧？他說的就是CDP上的源數(shù)據(jù)是怎么來的。之于你說的日志空間，那是同步后在CDP上做快照。

冬瓜頭

越來越有意思了，我還是少說話，以免又被版主給封號一年。

pingfan2

mike1979 發(fā)表于 2014-08-08 22:37
你跟他說的根本不是一回事。你自己也說依賴源數(shù)據(jù)才能恢復(fù)，你這個源數(shù)據(jù)只能在CDP上吧？他說的就是CDP上 ...

同意！