要“癲癇”，還是要“腦裂”？
——“IT生存法則”之雙活數據中心

“老王，你們醫院的雙活數據中心方案定了嗎？”

“還沒呢，已經聽好幾個廠家介紹方案了，有點暈，不知選哪個好，你有什么建議？”

“也談不上什么建議，就是提醒你下，上雙活方案，一定要防范好‘腦裂’的風險！”

“‘腦裂’？那不是治‘癲癇’病的后遺癥嗎？‘雙活’也會有后遺癥？”

“可不是，前一段某金融部門還專門發文提醒上‘雙活’后的‘腦裂’問題呢！”

“是嗎？那我們得好好評估一下，最終方案一定要考慮這方面的風險！”

是啊，是要搞搞清清楚下面這幾個問題，再做抉擇：

第一個問題是：為什么要上“雙活”？

隨著信息技術越來越成為驅動業務拓展的動力，對IT應用系統的連續性提出更高的要求，君不見SLA（服務水平協議）都在比小數點后有幾個9嗎？恨不得直接寫100%呢。可做為基礎架構的IT系統，終歸是機器設備，總會在生命周期中出現各類故障，對于網絡設備可以通過雙機冗余模式解決，對于應用服務器可以通過負載均衡方案解決，但對于數據庫服務器及其存儲設備，則一直采用傳統的冷備模式，既當主設備出故障時，冷啟動備機應急，顯然這種解決方案，其故障恢復時間無法降到秒級，最好的也在分鐘級，當需要保證7×24不間斷提供服務時，這里就成為了瓶頸。

正是在這種局面下，諸多存儲設備廠商，借鑒數據庫廠商的HA（高可用性）解決方案，提出并開發了“雙活”模式，理想的“雙活”解決方案，由于雙機互為主、備，并實時同步數據，因此只需毫秒級的延遲，即可在一方出故障時，接管對數據的存取，保證業務的連續性。

第二個問題是：“雙活”有什么利弊？

正所謂成也蕭何，敗也蕭何。由于IT系統的復雜性，環境、線路、設備、系統，甚至是線纜都可能是故障源，采取“雙活”后，如何破解數據的“CAP”難題就成為該模式能否有效的關鍵！也就是說數據的一致性（Consistency）、可用性（Availability）、分區容忍性（Partition Tolerance）三者只能同時選擇實現二個，其中，一致性追求RPO為零，可用性追求RTO為零，分區容忍性追求多存儲復本且在不同存儲載體上，截止目前，由于相關理論尚且沒有被證偽，要找到三者兼顧的解決方案還不現實。

“雙活”的目的，本來是解決可用性（注：隨時可用）的問題的，順便實現分區容忍性，這就帶來了數據的一致性無法保證的問題，既所謂的“腦裂”問題，如果發生的話，將造成數據的不可用，進而影響業務的連續性，雖然其發生概率較小，但一旦發生則是致命的。

這也是為什么大家上“雙活”模式時，非常慎重的原因！

第三個問題是：如何應對“腦裂”風險？

“腦裂”有風險，“雙活”又要上，既然沒有完美的技術，那就選擇能根據場景變換組合的解決方案。比如上述三者的分類組合，如CP、CA、AP等組合都能實現的方案。

這就需要進行場景變換實測，看該解決方案是否支持“同步復制”和“異步復制”，是否支持同步成功以“同步命令發出”或“同步結果完成”為信號的雙模式。

還有，是否有“仲裁服務器”和“多路徑軟件”用來對“腦裂”現象強行干預。

最為重要是，是否有手工模式，以便在“仲裁”失效或“各方”失聯的情況下，通過傳統的手工模式（注：類似冷備模式）恢復服務。

——IT語錄：魚與熊掌不可兼得，舍魚而取熊掌者也！

“老婆，問一個嚴肅的個人問題？”

“什么嚴肅問題？不會是你犯嚴重錯誤了吧？”

“別瞎猜！是這樣，假如你得了‘癲癇’，如果做手術，可以治好，但卻有后遺癥！你是做呢？還是不做?”

“那要看是什么后遺癥了！”

“比如‘腦裂’？就是腦子中總有兩小人打駕，一個往左，一個往右，不知聽哪個的好。”

“那不成精神分裂了嗎？”

“到沒那么嚴重，慢慢適應，最終選一個小人的指令就行了？”

“這還行，如果用‘精神分裂’換‘癲癇’，那還不如不換呢！”

……

想想也是，任何方案都不是十全十美的，要有利的一面，一定會帶來不利的一面，關鍵是最在乎什么？以及如何取舍？只要控制住風險，并將不利影響減少到最小，就是可以接受的，要不怎么會有那么多的人愿意做治‘癲癇’的手術呢？

明天就要上會討論確定是否上“雙活”方案了，經與老婆調侃幾句，王主任心靜了許多，似乎有些小小釋然。

下期預告：他們為什么要“磨洋工”？