WSFC時間分區場景實作

  上篇文章提到了WSFC群集出現時間分區時，使用磁盤見證和共享見證處理的方式會不一樣，老王實作了一下，看國內目前還沒這方面的博客，心血來潮決定把這篇番外博客寫出

  首先我們先來看出現時間分區時共享見證的處理，所謂時間分區即是說，當你修改一個節點的資源狀態時，另外一個節點不在線，然后修改的節點又宕機，另外一個節點上線時同步面臨的群集數據庫同步問題

我們假設這樣一個場景

時間節點1：節點1和節點2同時存活，節點1上面添加DTC群集角色，群集數據庫自動同步至節點2

時間節點2：節點1宕機，節點2查找群集數據庫上線群集1承載DTC角色

時間節點3：節點2添加SOFS角色

時間節點4：節點2宕機

時間節點5：節點1上線 

當實際出現了這種場景的時候，你會發現共享見證下節點1無論如何也沒辦法進行正常的工作

打開事件管理器 - 系統，你會看到 Event ID 1561的錯誤，內容提示已經很清楚，由于該節點不具備群集數據庫最新版本，因此無法啟動，無法形成群集

這正是老王上篇文章提到的，當你使用共享見證作的情況下，出現時間分區時，共享見證是沒辦法處理的，因為共享見證里面沒有存群集數據庫

然后這時你在節點1打開群集管理器，你會發現無論如何也連接不上CNO，你試圖ping群集CNO VCO域名可以ping通，但是當你訪問他們，使用VCO名稱，會發現連接不上

  這時候只有等節點2修復完成，當節點2加入群集后，節點1可以和節點2同步最新的群集數據庫之后，節點1群集管理器才可以正常打開，可以重新加入群集工作。

  即使這時你的節點1可以打開，也千萬不要執行強制仲裁，因為一旦執行了強制仲裁會覆蓋paxos標簽，提升節點1的paxos標簽為最新，共享見證又只承認擁有最新paxos的一方，導致的結果就是讓群集以為節點1的群集數據庫才是最新的，然后這時候如果節點2修復打開了，之前修改的內容也將完全丟失，因為節點2要以節點1的群集數據庫為準了，因此共享見證情況下出現時間分區了，只有等權威節點修復完成上線，或通過恢復群集權威數據庫方式

我們再來看下同樣的時間分區場景在磁盤見證下的效果

時間節點1：節點1和節點2同時存活，節點1上面添加DTC群集角色，群集數據庫自動同步至節點2

時間節點2：節點1宕機，節點2查找群集數據庫上線群集1承載DTC角色

時間節點3：節點2添加SOFS角色

時間節點4：節點2宕機

時間節點5：節點1上線 

節點1不在線情況下節點2新增SOFS角色

節點2宕機，節點1上線

節點1可以同步使用SOFS角色信息，并正常提供群集應用服務

   同樣的情況下，節點2在節點1不在的情況下，新增了SOFS角色，之后節點2宕機，節點1上線，可以看到，節點1依然是可以正常啟動的，群集管理器也可以正常打開，群集應用也可以正常對外提供服務

  為什么會是這樣呢，因為群集磁盤會存著最新的群集數據庫，當我們使用磁盤見證的時候，當新增或刪除了群集資源，除了會把狀態同步到節點本身的群集數據庫注冊表，也會同步一份到見證磁盤中，當出現時間分區時，會發生的只是節點1聯系到見證磁盤，與見證磁盤同步到最新的群集數據庫，然后正常啟動服務。

  因此，大家可以看出，共享見證在一些場景下還是會有問題，老王建議能使用磁盤見證盡量一定要用磁盤見證

  2016新推出的Cloud blob見證我還沒有試過時間分區的場景，不知道是類似共享見證的效果，還是磁盤見證的效果，關鍵在于里面會不會有最新的群集數據庫，后續有時間我會去驗證一下，也歡迎大家去驗證下然后告訴我答案