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

中斷數(shù)據(jù)錄像這個動作到底是否會導(dǎo)致系統(tǒng)宕機，有多大幾率？要回答這個問題，就得先搞清楚這些CDP方案是怎么執(zhí)行數(shù)據(jù)錄像，詳細(xì)機制在《大話存儲2》16章有詳細(xì)描述，這里只是簡單總結(jié)一下。首先生產(chǎn)數(shù)據(jù)先被鏡像一份到一個獨立的存儲系統(tǒng)里，當(dāng)達(dá)到同步收斂之后，生產(chǎn)卷和鏡像卷的IO實時同步?；谶@份鏡像卷，CDP系統(tǒng)在其上實現(xiàn)數(shù)據(jù)持續(xù)捕獲劑元數(shù)據(jù)記錄，最后采用基準(zhǔn)鏡像+增量的方式實現(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，當(dāng)然這是個Windows下的名詞，Linux下更直白，不叫filter，叫hook，Windows不能隨便讓你hook來hook去，它的驅(qū)動框架都是定死的，你只要填空就行了，Linux則非常靈活，但是風(fēng)險自負(fù)。Windows下不少時候的IO性能比發(fā)行版Linux是要強很多的，當(dāng)然如果自己定制化了內(nèi)核IO路徑就另當(dāng)別論了。在Linux下，LVM底層使用的是device mapper這個名正言順的鉤子驅(qū)動，當(dāng)然這個鉤子是經(jīng)過千錘百煉的，穩(wěn)定性應(yīng)該不成問題，但是不排除其依然有bug，只是幾率微乎其微。你也可以插入你自己的鉤子驅(qū)動，但是你自己的鉤子就得風(fēng)險自負(fù)，內(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 只建議配置成寫入目標(biāo)模式（ write target ）, 主機只向CDP寫入I/O, 但平時并不讀取。只有在需要恢復(fù)或驗證某時間點數(shù)據(jù)時，才會將錄像點磁盤mount 到驗證機上。所以CDP 的故障或錯誤是不會反向影響到主機的數(shù)據(jù)的?，F(xiàn)在，我們再來看下一步，如果要中斷數(shù)據(jù)錄像，就得在主機上進(jìn)行針對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)核版本會自動殺進(jìn)程來保證新資源被分配來確保系統(tǒng)尚在運行，此時已經(jīng)算是抽風(fē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ù)上可以有些改善，當(dāng)然，也要付出更多成本，比如可以利用交換機上的端口鏡像功能或者封裝之后的接口比如SANtap Service，這樣就可以與主機徹底撇清關(guān)系了。

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

donggua