上篇文章提到了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見證我還沒有試過時間分區的場景，不知道是類似共享見證的效果，還是磁盤見證的效果，關鍵在於裏面會不會有最新的羣集數據庫，後續有時間我會去驗證一下，也歡迎大家去驗證下然後告訴我答案