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

但是不同的人，不同的位置和角色，就會(huì)產(chǎn)生偏見(jiàn)了，最終偏向?qū)ψ约河欣哪且粋?cè)。這里有三個(gè)角度。首先對(duì)于用戶而言，這一災(zāi)難是巨大的，相關(guān)方面這時(shí)除了吸取教訓(xùn)，更重要的恐怕是對(duì)于責(zé)任的認(rèn)定。如果有一種解釋能淡化運(yùn)維和操作相關(guān)的責(zé)任，不失為一種好的危機(jī)應(yīng)對(duì);對(duì)于飛康的競(jìng)爭(zhēng)者們，當(dāng)然是“希望”問(wèn)題出在飛康身上，飛康一定是希望問(wèn)題不出在自己身上。

根據(jù)有關(guān)寧夏銀行之前的相關(guān)報(bào)道，寧夏銀行的核心系統(tǒng)包括CDP在內(nèi)，已穩(wěn)定運(yùn)行數(shù)年。在這其間，還曾經(jīng)于2010年進(jìn)行過(guò)成功的復(fù)雜條件災(zāi)備真實(shí)切換的演練并取得成功，這一事件當(dāng)時(shí)被眾多媒體和同行現(xiàn)場(chǎng)報(bào)道和觀摩。那么，在數(shù)據(jù)庫(kù)崩潰之前，到底系統(tǒng)已經(jīng)出現(xiàn)了什么征兆和問(wèn)題，在那天，除了關(guān)閉“錄像”，用戶對(duì)于數(shù)據(jù)庫(kù)和主機(jī)還進(jìn)行了哪些操作，在報(bào)告里卻不得而知。

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

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

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

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

LVM鏡像一般都是同步模式的，也沒(méi)有地方可供更改為異步，這就要求鏡像卷縮在的系統(tǒng)性能足夠強(qiáng)以至于不會(huì)拖慢生產(chǎn)系統(tǒng)，此外采用同步復(fù)制也可以保證不丟失數(shù)據(jù)，只要數(shù)據(jù)是一致的。

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

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

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

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

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