在本篇文章中，老王將從實際應(yīng)用的角度來為大家講解下群集仲裁在真實情況下的呈現(xiàn)，以及出現(xiàn)不同點數(shù)的節(jié)點宕機應(yīng)該如何處理，在老王本篇文章中以及以后的文章中，我并不會去講如何去安裝一個群集，后面我們也將主要專注于群集的深入知識，概念理解，架構(gòu)設(shè)計，遷移優(yōu)化。

成都創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),長洲企業(yè)網(wǎng)站建設(shè),長洲品牌網(wǎng)站建設(shè),網(wǎng)站定制,長洲網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,長洲網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。

  本篇文章分為以下幾個場景

  場景1.兩個站點，三個節(jié)點的群集，假設(shè)北京站點兩個節(jié)點，保定站點一個節(jié)點，群集采用多數(shù)節(jié)點方式，我們將依次測試重現(xiàn)，群集壞掉1個節(jié)點會發(fā)生什么，應(yīng)該如何處理，群集壞掉兩個節(jié)點會發(fā)生什么，應(yīng)該如何處理。

  場景2.兩個站點，四個節(jié)點的群集，假設(shè)北京站點兩個節(jié)點，保定站點兩個節(jié)點，群集采用磁盤仲裁的方式，我們將依次測試重現(xiàn)，群集見證磁盤活著時候，壞掉一個節(jié)點時群集會發(fā)生什么，應(yīng)該如何處理，壞掉兩個節(jié)點時群集會發(fā)生什么，應(yīng)該如何處理，當(dāng)見證磁盤不在，會發(fā)生什么情況，應(yīng)該如何處理。

 場景1環(huán)境介紹

 北京站點

 Node1 

 管理網(wǎng)卡 10.0.0.3 網(wǎng)關(guān)10.0.0.1 DNS10.0.0.2

 存儲網(wǎng)卡 40.0.0.3 網(wǎng)關(guān)40.0.0.1

 心跳網(wǎng)卡 18.0.0.1

 Node2 

 管理網(wǎng)卡 10.0.0.4 網(wǎng)關(guān)10.0.0.1 DNS10.0.0.2

 存儲網(wǎng)卡 40.0.0.4 網(wǎng)關(guān)40.0.0.1

 心跳網(wǎng)卡 18.0.0.2

 08DC

 lan1 10.0.0.2 網(wǎng)關(guān)10.0.0.1

 網(wǎng)關(guān)服務(wù)器 

 10.0.0.1

 20.0.0.1

 30.0.0.1

 40.0.0.1

 保定站點

 管理網(wǎng)卡 20.0.0.5 網(wǎng)關(guān)20.0.0.1 DNS10.0.0.2

 存儲網(wǎng)卡 30.0.0.5 網(wǎng)關(guān)30.0.0.1

 心跳網(wǎng)卡 18.0.0.3

 此次設(shè)計上，并沒有采取一些最佳實踐，老王只是為了重現(xiàn)出這樣一個多站點的場景，把兩個站點間管理網(wǎng)卡和存儲網(wǎng)卡的網(wǎng)絡(luò)分開，在之后的實驗08DC也會承擔(dān)ISCSI Server角色，嚴格來說，網(wǎng)關(guān)服務(wù)器和存儲應(yīng)該要放在一個相對來說比較穩(wěn)定安全的地方，防止由于網(wǎng)關(guān)或存儲導(dǎo)致群集出現(xiàn)單點故障，另外

   大家看到我在心跳卡上面兩個站點的用的是同一個網(wǎng)端，這在實際企業(yè)環(huán)境里面不會這樣，通常情況下是打通一個大VLAN這樣去做，但是要注意，群集節(jié)點網(wǎng)卡，一定要至少有一塊網(wǎng)卡，不配置網(wǎng)關(guān)，因為群集在創(chuàng)建的時候會去利用啟發(fā)性算法來查找，群集默認會找沒有配置網(wǎng)關(guān)的網(wǎng)卡來作為心跳網(wǎng)卡，如果全部網(wǎng)卡都配置上網(wǎng)關(guān)，你會發(fā)現(xiàn)群集出現(xiàn)故障，因此，如果心跳網(wǎng)卡也需要跨越網(wǎng)段，可以采取在節(jié)點上面用route -p的方式，手動添加路由表進行解決

   參考 https://blogs.technet.microsoft.com/timmcmic/2009/04/26/windows-2008-multi-subnet-clusters-and-using-static-routes/ 

  另外也需要考慮跨站點DNS緩存的問題，由于環(huán)境有限，所以在這里老王只用了一臺DNS服務(wù)器，嚴格來說，應(yīng)該是各站點有自己的DNS服務(wù)器的，例如，當(dāng)前群集角色testdtc在北京站點的群集聯(lián)機地址是10.0.0.9，但是北京DNS就會記錄這個VCO是這個10網(wǎng)段的地址，然后每隔一段時間復(fù)制到保定的DNS服務(wù)器，這個復(fù)制時間就是個時間差，跨站點故障轉(zhuǎn)移時間實際也需要考慮到DNS服務(wù)器復(fù)制的緩存和客戶端的客戶端的緩存，因為在北京沒復(fù)制到保定之前，保定從北京或得到testdtc就是10網(wǎng)段的地址，就會cache下來，客戶端來請求就都返回這個地址，但是當(dāng)群集應(yīng)用轉(zhuǎn)移到保定，保定是20網(wǎng)段，因此就需要CNO重新注冊VCO的DNS記錄，然后群集資源名稱才可以正常聯(lián)機對外使用，通常這種跨子網(wǎng)的群集應(yīng)用我們會設(shè)置綁定多個IP地址，然后依賴關(guān)系設(shè)置為or，即只要其中一個IP可以活著 綁定注冊DNS就可以，群集請求DNS更新了VCO的地址，這時候VCO可以正常聯(lián)機了，但是客戶端能不能訪問了呢，還不一定，因為客戶端還有dns cache，針對于跨站點群集VCO的DNS緩存和記錄生命周期，后面老王會單獨寫一篇深入介紹多站點群集的博客，在里面會指出一些最佳實踐，其中網(wǎng)絡(luò)部分會深入講解，這里只是簡單帶過

首先可以看到節(jié)點服務(wù)器目前都是正常的狀態(tài)，以及按照預(yù)定規(guī)劃的多站點群集網(wǎng)絡(luò)架構(gòu)

我們創(chuàng)建了一個群集DTC應(yīng)用，可以看到當(dāng)前是主運行在node1節(jié)點上

直接將node1進行斷電關(guān)機，可以看到群集DTC已經(jīng)轉(zhuǎn)移至node2繼續(xù)提供服務(wù)

打開node2服務(wù)器系統(tǒng)日志可以看到關(guān)于檢測node1已經(jīng)離線了的日志

這時雖然群集還可以運作，但是已經(jīng)仲裁已經(jīng)提示警告，意思就是提醒你一下，你之前和我簽訂的仲裁協(xié)議是多數(shù)節(jié)點的3節(jié)點群集，現(xiàn)在你壞了一臺了，不能再壞了，再壞群集就要關(guān)了，真實場景下如果三節(jié)點群集壞了一個節(jié)點，應(yīng)該立刻修復(fù)節(jié)點重新上線，不然再壞一臺群集將不再對外提供服務(wù)。

這時候我們將node2也直接斷電關(guān)機，我們失去了整個北京站點，之后打開群集管理器可以看到，群集狀態(tài)已經(jīng)變成了下移，這時候?qū)嶋H上群集已經(jīng)不再對外提供服務(wù)，CNO和VCO都將無法訪問

打開事件管理器系統(tǒng)日志可以看到，群集服務(wù)因為仲裁協(xié)議違反，已經(jīng)被迫停止

針對于群集的分析，主要分為系統(tǒng)日志，群集詳細分析日志，群集驗證報告，cluster目錄日志，cluster.log日志，其中系統(tǒng)日志和詳細分析日志相對比較容易理解，建議大家可以先從這方面的日志看起，后面會有文章專門介紹群集日志分析

這時群集由于連續(xù)的節(jié)點崩潰已經(jīng)只剩下最后一個節(jié)點，這時候群集也關(guān)閉了，不再對外提供服務(wù)，但是我們也可以通過強制啟動的方式把最后一個節(jié)點的群集服務(wù)啟動起來，讓群集繼續(xù)對外提供服務(wù)，雖然一個節(jié)點能承載的負載有限，但是可以訪問一部分總比什么也訪問不到強

直接運行命令 

net stop clussvc

net start clussvc /FQ

即可，把群集服務(wù)先停止，然后強制啟動起來

   執(zhí)行完成強制啟動后可以看到群集已經(jīng)使用，但是群集有提示我們，當(dāng)前是在forcequorum狀態(tài)運行，群集配置可能會丟失

   老王猜想是因為，這是使用多數(shù)節(jié)點仲裁的原因，或者共享見證時會遇到的問題，因為這類仲裁模式，群集數(shù)據(jù)庫只存在本地節(jié)點間互相同步，假設(shè)現(xiàn)在只有Node3強制啟動了，其它節(jié)點都不在，我們修改了群集資源，然后節(jié)點3下，其它節(jié)點上，會因為時間分區(qū)的原因?qū)е聼o法啟動等類似原因

    因此建議大家強制啟動只能是作為實在沒辦法下的最后一道手段，能讓群集短暫的起死回生，但是回生之后應(yīng)該立即修復(fù)其它節(jié)點加入群集，解除ForceQuorum模式。

可以看到強制啟動之后 群集DTC服務(wù)已經(jīng)在保定站點正常啟動了起來，群集名稱對應(yīng)的IP地址現(xiàn)在是保定那邊的20網(wǎng)段

如果大家點擊一個群集角色的依賴報告可以看到類似下面的這種圖，理解依賴關(guān)系對于多站點群集應(yīng)用上線很重要，AND則代表，雖有關(guān)聯(lián)的子資源必須聯(lián)機，父資源才可以聯(lián)機，OR則代表選項中的幾個子資源有一個活著，父資源就可以啟動，例如網(wǎng)絡(luò)名稱需要綁定IP，如果10可以綁定注冊就綁定10網(wǎng)段，如果10子網(wǎng)無法綁定，那么20網(wǎng)段可以綁定注冊，網(wǎng)絡(luò)名稱也可以上線聯(lián)機。

以上我們實際看了三節(jié)點多數(shù)節(jié)點仲裁情況下，節(jié)點依次宕機時的處理

接下來我們再看第二個場景 

場景2環(huán)境介紹

 北京站點

 Node1 

 管理網(wǎng)卡 10.0.0.3 網(wǎng)關(guān)10.0.0.1 DNS10.0.0.2

 存儲網(wǎng)卡 40.0.0.3 網(wǎng)關(guān)40.0.0.1

 心跳網(wǎng)卡 18.0.0.1

 Node2 

 管理網(wǎng)卡 10.0.0.4 網(wǎng)關(guān)10.0.0.1 DNS10.0.0.2

 存儲網(wǎng)卡 40.0.0.4 網(wǎng)關(guān)40.0.0.1

 心跳網(wǎng)卡 18.0.0.2

 08DC

 lan1 10.0.0.2 網(wǎng)關(guān)10.0.0.1

 lan2 20.0.0.2 網(wǎng)關(guān)10.0.0.1

 lan3 30.0.0.2 網(wǎng)關(guān)30.0.0.1

 網(wǎng)關(guān)服務(wù)器 

 10.0.0.1

 20.0.0.1

 30.0.0.1

 40.0.0.1

 保定站點

 Node3

 管理網(wǎng)卡 20.0.0.5 網(wǎng)關(guān)20.0.0.1 DNS10.0.0.2

 存儲網(wǎng)卡 30.0.0.5 網(wǎng)關(guān)30.0.0.1

 心跳網(wǎng)卡 18.0.0.3

 Node4

 管理網(wǎng)卡 20.0.0.6 網(wǎng)關(guān)20.0.0.1 DNS10.0.0.2

 存儲網(wǎng)卡 30.0.0.6 網(wǎng)關(guān)30.0.0.1

 心跳網(wǎng)卡 18.0.0.4

可以看到群集已經(jīng)新增至四個節(jié)點，同時也已經(jīng)配置了磁盤見證

依舊部署一個群集DTC，目前托管在北京node2節(jié)點

我們直接將node2斷電，可以看到現(xiàn)在DTC群集應(yīng)用已經(jīng)自動轉(zhuǎn)移至本站點的node1服務(wù)器

接下來我們把Node1也直接斷電，模擬我們失去了整個北京站點的節(jié)點，可以看到，由于我們采用了磁盤見證，因此我們可以接受一半的節(jié)點壞掉，群集依然可以正常工作，但是提示我們了，在當(dāng)前的情況下，只要再壞掉一個節(jié)點或者群集磁盤宕機，都會導(dǎo)致群集關(guān)閉，這時應(yīng)該抓緊時間修復(fù)北京站點，盡快上線，不要讓這種情況持續(xù)太久

假設(shè)這時沒搶救好北京站點，保定站點又壞了一個節(jié)點，群集則會變成下移關(guān)閉狀態(tài)，所有群集服務(wù)也將都無法訪問

這時由于群集宕機節(jié)點數(shù)已經(jīng)違背了仲裁協(xié)議中的節(jié)點數(shù)，因此也只能使用強制啟動的方式把群集啟動起來，但是這種狀態(tài)同樣也不要持續(xù)太久，還是應(yīng)該盡快修復(fù)其它節(jié)點上線

接下來我們來模擬下腦裂的場景，即北京與保定直接發(fā)生了網(wǎng)絡(luò)分區(qū)，兩邊各自為政，實際最佳老王應(yīng)該模仿是群集四個節(jié)點先是失去了到仲裁磁盤的連接，然后變成四個節(jié)點，四個投票的情況下，中間產(chǎn)生一個分區(qū)，但是由于老王AD和ISCSI模擬在了一起，如果直接把這臺機器宕機所有節(jié)點別想正常工作了，因此老王這里臨時將群集仲裁模型改為了多數(shù)節(jié)點，即四個節(jié)點，四票的一個多數(shù)節(jié)點架構(gòu)，腦裂一觸即發(fā)的架構(gòu)，哇哈哈

這時我們模擬腦裂分區(qū)，將node3和node4直接改到另外一個網(wǎng)絡(luò)中

So it begin，可以在node2上面看到只有node1和node2活著，node3 node4形成群集，或無法形成

但是如果訪問群集名稱測試會發(fā)現(xiàn)還是不能訪問的，因為這是群集已經(jīng)沒辦法執(zhí)行仲裁，兩邊沒有一方是多數(shù)的，因此整個群集都將沒辦法正常工作，都在摸瞎胡中

這時由于域控和存儲在北京這邊，北京這邊可以正常工作，保定那邊網(wǎng)絡(luò)還未修復(fù)，因此我們強制啟動北京的群集分區(qū)，在node2上面運行強制啟動命令

可以看到只需要在node2上面運行一下強制啟動的命令之后，整個群集就都變得可用了，node1和node2在同一個分區(qū)內(nèi)，node1感覺到node2形成了權(quán)威分區(qū)于是自動又融入了群集，但這時由于我們是強制啟動的群集，群集還處于強制啟動狀態(tài)，不論任何情況下，都不要長時間讓群集處于強制啟動狀態(tài)，還是應(yīng)該盡快的去恢復(fù)網(wǎng)絡(luò)。

可以看到群集DTC現(xiàn)在已經(jīng)在北京站點正常聯(lián)機工作

當(dāng)保定站點網(wǎng)絡(luò)修復(fù)好了后，這一側(cè)的群集分區(qū)感應(yīng)到了北京的權(quán)威群集分區(qū)，就又會自動融合進去，群集現(xiàn)在又正常工作了，強制啟動狀態(tài)的警告也已經(jīng)消除

  總結(jié)一下，我們看了再多數(shù)節(jié)點仲裁模型下，群集節(jié)點在不停宕機時群集的變化處理，又看了在磁盤見證模型下，磁盤在的情況下，群集節(jié)點在不停宕機時群集的變化處理，以及磁盤見證不在，發(fā)生網(wǎng)絡(luò)分區(qū)時的變化處理

  簡單來說，在群集工作狀態(tài)中，只要不違背你與群集簽訂仲裁協(xié)議的規(guī)則，群集都是可以正常運作的，當(dāng)達到臨界值時，群集會提醒當(dāng)前已經(jīng)達到臨界值，再宕機一票，群集就要關(guān)了，這時候應(yīng)該要抓緊時間修復(fù)群集其它節(jié)點

   然后假設(shè)出現(xiàn)了連續(xù)宕機的情況下，只剩下一個節(jié)點，或者只剩下少數(shù)節(jié)點，如果想讓群集起死回生出來提供服務(wù)，可以使用強制仲裁的方式，在少數(shù)節(jié)點的情況下也可以讓群集啟動起來

  強制仲裁主要就是用于在少數(shù)節(jié)點的情況下啟動起來群集，或者在群集發(fā)生腦裂，50 50的情況下，啟動起來其中一端出來提供服務(wù)，同樣強制仲裁狀態(tài)時間不可以太長，否則會出現(xiàn)配置不同步風(fēng)險，也要盡快修復(fù)節(jié)點或網(wǎng)絡(luò)故障上線才是

  當(dāng)我們執(zhí)行強制仲裁命令之后，實際上背后群集會做兩件事，確立強制仲裁一方為權(quán)威方，提升強制仲裁分區(qū)的群集配置Paxos標記提升為最高，類似于AD里面的授權(quán)恢復(fù)，讓強制仲裁的一方為黃金權(quán)威方，群集將在權(quán)威方進行運作，其它節(jié)點的群集配置，將會與強制仲裁一端同步，不可否認強制仲裁，很多時候還是很實用的

  以上就是老王想和大家說的強制仲裁，以及仲裁處理，希望大家看過之后能有收獲，當(dāng)群集出現(xiàn)逐個節(jié)點宕機時心里有數(shù)該如何處理

  補充幾點

1.強制啟動起來，只是我們把群集救活了，但是可不可以完整的對外提供服務(wù)呢，不一定，因為假設(shè)是四個節(jié)點的群集，資源都是一致的，那強制啟動起來的節(jié)點能否承載起來四個節(jié)點的負載呢，這是個問題，如果支持不起來負載，一些群集應(yīng)用也是沒辦法聯(lián)機訪問的，因此，實際規(guī)劃時，也需要考慮到這種只剩下最后一個節(jié)點的場景，最佳是設(shè)計的時候能夠做好規(guī)劃，服務(wù)器資源足夠，當(dāng)然最好，也可以通過規(guī)劃群集應(yīng)用優(yōu)先級的方式規(guī)劃，一旦發(fā)生這種情況，那些群集應(yīng)用優(yōu)先級比較高，先讓這些應(yīng)用活起來，或者設(shè)置一個冷備機，平時不參加群集投票，一旦出現(xiàn)這種只剩下一個節(jié)點的情況下，可以再把冷備節(jié)點啟動來承載負載

 2.上面其實還有一種場景老王沒寫到，最后上張圖把，出于好奇心我在2008R2的群集上面試了下3個節(jié)點+見證磁盤的仲裁模型，結(jié)果死的很慘，可以看到，當(dāng)群集壞一個節(jié)點，就已經(jīng)告訴我當(dāng)前已經(jīng)達到了臨界值，見證磁盤失效或者再壞一個節(jié)點節(jié)點，群集就關(guān)了，這樣來看完全沒什么優(yōu)勢啊，因為我如果3個節(jié)點多數(shù)節(jié)點，我只需要考慮保證兩個節(jié)點可用就好了，這樣的話，我還要多考慮一個見證磁盤的可用，對于保持群集可用可謂一點用處沒有，唯獨能想到的可能就是這種場景下，可以避免時間分區(qū)的問題，如果最后剩下一個節(jié)點和見證磁盤，還可以把配置修改信息同步到見證磁盤，其它節(jié)點再上線也可以正常使用，到了2012時代這個就變了，不再雞肋，3節(jié)點配見證磁盤，不需要強制啟動的情況下也可以活到最后一個節(jié)點，下篇文章我們就來實際測試2012時代仲裁發(fā)生的變化！