最近寧夏銀行宕機事件，引發種種猜測，謠傳不斷。原文報道不再多說，其中一句話耐人尋味，意思是“在中斷數據錄像之后即發生宕機”，帶有明顯的暗示色彩，解讀這句話可以初步得出其所“暗示”的兩個結論，第一個就是本次宕機的導火索是中斷了數據錄像，第二個就是提供數據錄像的廠商很有可能就是飛康，當然，第二個結論已經是事實了。但是第一個結論，有待考證。如果一個系統已經出現了問題，而不可逆轉的話，此時所做的任何動作，都有可能成為該系統最終宕機的理由，而如果不做這些動作，系統依然可能還會最終宕機，所以，報道里的這句話是模棱兩可的。
但是不同的人，不同的位置和角色，就會產生偏見了，最終偏向對自己有利的那一側。這里有三個角度。首先對于用戶而言，這一災難是巨大的，相關方面這時除了吸取教訓，更重要的恐怕是對于責任的認定。如果有一種解釋能淡化運維和操作相關的責任，不失為一種好的危機應對;對于飛康的競爭者們，當然是“希望”問題出在飛康身上，飛康一定是希望問題不出在自己身上。
根據有關寧夏銀行之前的相關報道，寧夏銀行的核心系統包括CDP在內，已穩定運行數年。在這其間，還曾經于2010年進行過成功的復雜條件災備真實切換的演練并取得成功，這一事件當時被眾多媒體和同行現場報道和觀摩。那么，在數據庫崩潰之前，到底系統已經出現了什么征兆和問題，在那天，除了關閉“錄像”，用戶對于數據庫和主機還進行了哪些操作，在報告里卻不得而知。
這里拋開這些人的因素，只談技術。
中斷數據錄像這個動作到底是否會導致系統宕機，有多大幾率？要回答這個問題，就得先搞清楚這些CDP方案是怎么執行數據錄像，詳細機制在《大話存儲2》16章有詳細描述，這里只是簡單總結一下。首先生產數據先被鏡像一份到一個獨立的存儲系統里，當達到同步收斂之后，生產卷和鏡像卷的IO實時同步。基于這份鏡像卷，CDP系統在其上實現數據持續捕獲劑元數據記錄，最后采用基準鏡像+增量的方式實現任意時間點回滾。
這里所使用的IO同步鏡像工具一般為LVM，也就是Linux和UNIX普遍使用的存儲空間批發+零售的卷管理系統，Logical Volume Manager。其前提是應用的數據是部署在LV塊設備上的，如果是部署在/dev/sda這種底層塊設備上，就不能使用LVM作鏡像了。正因如此，飛康在Windows下提供單獨的Disksafe鏡像和快照管理工具，因為WIndows下幾乎沒有應用使用系統自帶的動態磁盤方案(Windows下的“LVM”)。
不管是LVM，還是Disksafe，其底層都需要在IO路徑上插入filter driver，當然這是個Windows下的名詞，Linux下更直白，不叫filter，叫hook，Windows不能隨便讓你hook來hook去，它的驅動框架都是定死的，你只要填空就行了，Linux則非常靈活，但是風險自負。Windows下不少時候的IO性能比發行版Linux是要強很多的，當然如果自己定制化了內核IO路徑就另當別論了。在Linux下，LVM底層使用的是device mapper這個名正言順的鉤子驅動，當然這個鉤子是經過千錘百煉的，穩定性應該不成問題，但是不排除其依然有bug，只是幾率微乎其微。你也可以插入你自己的鉤子驅動，但是你自己的鉤子就得風險自負，內核態里出了問題系統多半宕機，所以一般商用產品，能用內核自帶的就用，這樣一來節省開發，二來名正言順，三來出了問題也可以撇清關系。
LVM鏡像一般都是同步模式的，也沒有地方可供更改為異步，這就要求鏡像卷縮在的系統性能足夠強以至于不會拖慢生產系統，此外采用同步復制也可以保證不丟失數據，只要數據是一致的。
而且，根據飛康CDP的實施手冊要求，LVM CDP 只建議配置成寫入目標模式( write target ), 主機只向CDP寫入I/O, 但平時并不讀取。只有在需要恢復或驗證某時間點數據時，才會將錄像點磁盤mount 到驗證機上。所以CDP 的故障或錯誤是不會反向影響到主機的數據的?，F在，我們再來看下一步，如果要中斷數據錄像，就得在主機上進行針對LVM鏡像卷的配置，將鏡像切開，這一步必然需要通知底層驅動，驅動此時會斷開對鏡像卷的數據IO。這一步在低IO壓力下，正常來講沒有問題，但是在高IO壓力下，對IO路徑任意一處做影響IO路徑的更改，就很有可能導致系統卡死，因為牽扯到路徑變更，勢必導致對資源的鎖操作，以及瞬間暫停IO，此時上層的IO仍然會不斷壓入隊列，最終會導致queue full，內核遲遲不返回結果給應用，響應時間的增加，又會導致前端操作員不斷刷新重試，又會導致大量新IO請求，最后系統越來越慢，內存耗費暴增，不得不借助swap暫存，最后swap如果要滿了的話，那就真的沒有可用內存了，最后就是僵死態，這屬于連鎖反應。這種現象在Linux x86 服務器上是有所耳聞的，但是后來的內核版本會自動殺進程來保證新資源被分配來確保系統尚在運行，此時已經算是抽風了。AIX則不會，swap滿則卡死。
再說回來，為何要中斷數據錄像？恐怕那時候系統已經非常慢了，導致必須人為介入處理。但為什么慢？
7月初，很多業務都處于半年結算期，業務壓力暴增，從另外一些報道，系統在徹底中斷之前，有一些業務已經中斷了。網上還有一些數據庫專家的猜測，這個多年沒有維保的Informix 系統踩到了那幾個老版本Informix 上已知的“地雷”，中招的現象就是系統很慢，類似假死。但可怕的是數據庫一旦重啟，將系統崩潰?？赡芤舱怯捎诖?，才會人為介入，此時該系統已經是茍延殘喘，動底層驅動，很有可能是壓垮駱駝的最后一根稻草。但是這點必須根據現場經驗和系統log日志才能夠具體判斷，如果中斷錄像之后沒多久立即宕機，那么這個動作可以被判斷為是最終那根稻草，如果沒有立即宕機，那么這個動作或許本來對系統是沒產生決定性影響的。另外，宕機類型也得搞清楚，是立即重啟了，還是僵死態比如尚能ping通，這兩個是很不一樣的，如果是立即重啟，則該動作導致的可能性就非常大了，如果是僵死，也不足以判斷是否該動作產生決定性影響。
所以綜上來看，該系統過于老舊，而新業務猛增的IO壓力，是根因，中斷錄像可能是導火索，也可能根本沒起決定性作用。這次事件至少給人一個教訓，洪水是很快的，等到噴涌直下的時候再去筑堤壩是來不及的。技術上可以有些改善，當然，也要付出更多成本，比如可以利用交換機上的端口鏡像功能或者封裝之后的接口比如SANtap Service，這樣就可以與主機徹底撇清關系了。
最后，利用此事件打擊對手其實并不是明智之舉，大家都是做容災的，難道用了其他家的就不會出這種問題？如果能拿出針對IO方面的更好設計和技術，倒是值得討論，如果只是煽風點火，其實最后都是砸自己的腳。
