Hyper-V群集對群集復制

大部分人可能只知道Hyper-V復制是2012新引入的虛擬機復制功能，但卻不知道其實Hyper-V復制支持非常靈活的架構，如單機對單機，單機對群集，群集對單機，群集對群集，那么Hyper-V復制和群集扯上關系到底是怎么回事呢

在WSFC 2012開始，WSFC新增加了一個Hyper-V副本代理角色，如下圖所示

老王認為這個角色應該叫做群集對外復制代理比較合適，不然很容易讓人誤會是群集內部的復制，可以理解為微軟將hyper-v復制與WSFC的整合實現為一個群集對外復制協調引擎，當我們配置這個角色時會輸入一個名稱，這個名稱就作為復制代理角色的客戶端訪問點，不論此群集作為來源端或者目的端，在復制向導填寫名稱時都會填寫復制代理名稱，而非單個節點，復制代理會自動協調群集內參與虛擬機復制節點，當一個外面的復制請求丟到群集，復制代理引擎接到請求會自動協調出來一個節點參與復制，當被挑選參與復制的節點宕機，則虛擬機將被故障轉移到群集內其它節點繼續復制，利用WSFC故障轉移和復制引擎機制確保不會因為單個主機宕機而影響虛擬機復制

總結群集對外復制代理功能如下

1. 作為群集統一的對外代理，對外提供統一的復制名稱

2. 挑選協調群集內主機參與復制，感知故障轉移，告知外面復制請求流量最終應到達主機。

3. 確保群集內添加節點時不會對正在進行的復制產生影響

4. Broker角色將復制配置寫入群集數據庫并觸發通知，每個節點上的虛擬機管理服務都會得到復制配置，并且每個節點都會使用復制設置的最新副本

5. 支持副本虛擬機在群集內實時遷移，當副本虛擬機被遷移到其它節點，復制流量自動重新路由，不需要人工干預。

2012R2，Hyper-V復制還引入了重磅新功能，擴展復制，更進一步的貼近實際應用，利用這個功能我們可以實現 群集-群集-群集，群集-單機-單機，單機-單機-群集，群集-單機-群集等更加靈活的場景。

站在跨站點，跨群集的角度來看Hyper-V復制

首先，Hyper-V復制對比存儲復制，WSFC來說，最大的一個優勢就是架構靈活，可以不受架構的限制，不受存儲的限制，支持足夠多的場景，但是，如果不和群集整合，單獨Hyper-V單機對單機復制的話，也有一個最大的弊病，即計劃內維護需要宕機，經過老王和好友張俊森的實際測驗，發現在一個計劃內維護的場景下，如果要維護宿主機，竟然要把虛擬機關機才可以進行Hyper-V復制計劃內故障轉移，這個是單機場景下的不足，但是如果可以搭建群集則不會有這個問題，通過復制代理引擎會自動挑選參與復制的節點，那怕其中一個節點宕機，或者計劃內要維護關機，復制代理引擎也會立刻挑選其它主機來參與復制，從可用性的角度來講，利用復制代理能在外面Hyper-V復制機制里面再加上一層復制代理雙保險，通過協調群集內復制節點，確保只要群集活著就始終有能參與復制的節點。

除此之外Hyper-V復制還有以下優點，支持多個還原點，不需要使用其它備份工具，直接通過Hyper-V窗口就能夠回滾到不同的時間節點，支持應用程序一致性感知，支持證書驗證 SSL 443加密，支持固定端口發布到其它網絡對接復制，支持Azure云端整合復制。

缺點來說，除了單機對單機的維護問題，還有通過和好友張俊森討論認為Hyper-V復制的復制間隔還是過長，兩方復制30秒 5分鐘 15分鐘，擴展復制5分鐘 15分鐘，對于一些核心關鍵的業務可能會希望更短的復制間隔時間，以減少數據的丟失。

實際環境中使用Hyper-V復制的建議，如果是單機對單機的場景下，老王不建議跑重要業務，一般的業務可以由Hyper-V復制負責，降低成本，計劃內維護關閉虛擬機需在維護窗口時間完成，如果環境允許的話，處于可用性的考慮，老王建議至少組建一個群集對單機的場景，這樣就可以放心的跑一些業務，虛擬機正常情況下在群集內一個節點運作，由群集再將虛擬機異步復制到單機，以防止群集崩潰，一旦群集內單個節點宕機，復制代理協調另外一個節點自動參與復制，一旦群集崩潰，手動在單機節點故障轉移虛擬機。

WSFC對比Hyper-V復制來說最大的優勢就是自動故障轉移，Hyper-V復制不論是單機對單機，群集對單機，群集對群集，假設其中一方突然宕機，管理員都需要手動完成故障轉移，跨站點的情況下可能更會延遲宕機時間，如果是搭建了WSFC，在跨站點的情況下，只要合理設計好網絡，存儲，仲裁，DNS延遲，放置策略，應用重試等群集配置，應用可以很快的自動故障轉移。不論是Hyper-V復制還是WSFC，如果設計跨站點的可用性方案，都需要考慮到網絡和存儲，Hyper-V復制對于存儲沒有要求，可以是共享存儲也可以是本機存儲，需要注意的是網絡延遲，不同的復制頻率對網絡帶寬的質量要求也就越高，如果真的考慮跨站點應用Hyper-V復制，可能也需要搭建專線。

WSFC目前跨站點可用性方案有兩種模型 

1. WSFC 2016+自帶存儲復制，構建成延伸群集

2. WSFC 2008R2/2012R2/2016+第三方存儲復制/設備復制

從目前的架構上面來講，WSFC的跨站點還是要考慮到存儲的問題，原因是目前S2D不能跨站點分布存儲數據，只能做到跨機架級別，因此需要考慮存儲的可用性，不論是那種方案，WSFC跨站點的話對于網絡質量也是要求很高。

Hyper-V復制與WSFC兩種方案，Hyper-V復制更加廉價，沒有存儲限制，異步復制，架構靈活，但需要和群集整合來實現更高的可用性，故障轉移恢復時間較長，需手動進行計劃外故障轉移，WSFC可以做到自動的故障轉移，但是對于管理員技術有所要求，要求管理員必須熟悉精通跨站點群集的網絡，存儲，仲裁，DNS延遲，放置策略，應用重試等概念設計，兩種方案均對網絡要求較高，想要做跨站點高可用應該想到這一點，實際決定采納方案時，還應該結合管理人員對hyper-v復制和WSFC的熟悉程度決定。

跨站點還是跨群集

WSFC從2008開始支持群集多子網，真正推進了跨站點群集的場景，支持調整跨子網心跳檢測閥值，2008R2引入HostRecordTTL機制降低跨站點故障轉移時DNS復制延遲，引入RegisterAllProvidersIP屬性讓支持的應用可以進行多子網的快速重試，支持調整跨網絡群集檢測通信加密屬性。2012R2新增動態仲裁，反相關性，增強優先級設置以便于跨站點故障轉移時的可用性策略。2016時代對于跨站點新增了不少新功能，站點感知，存儲站點感知，群集組站點感知，首選站點，跨站點心跳檢測閥值，通過配置能夠實現應用默認本地站點轉移，本地站點全部宕機跨站點故障轉移，虛擬機followCSV，CSV轉移到其它站點則虛擬機也跟隨轉移，通過配置群集組站點感知實現多個群集組始終在不同站點運行。通過站點屬性配置50/50情況獲勝，通過站點屬性配置本地子網跨子網外的閥值規則。一切都源于2016引入了故障域的概念，管理員可以手動定義Site，Rack，Chassis等故障域屬性，隨后應用會感知到故障域定義以進行故障轉移或策略應用，例如前面介紹的幾個新功能都是圍繞著故障域定義的Site屬性來應用設計跨站點故障轉移的策略，故障轉移層面S2D實現效果最好，例如檢測到rack故障域定義 可以將extent撒到不同rack

WSFC 2016的故障域，站點感知等策略，在設計2016群集架構時是必不可少要思考的地方，合理的規劃可以幫助減少很多的宕機時間，到了WSFC 2019，所有的2016新功能得到延續，并且新增了ClusterSet新功能。

ClusterSet和Hyper-V復制代理有點像，但也不全像

說他倆像是因為它倆都有一個共同的效果，不把雞蛋放在一個籃子里，不全部押寶單個群集

ClusterSet前面已經單獨寫文章和大家聊過，簡單來說它就是一種基于統一的命名空間路徑運行虛擬機，以及管理群集調度成員群集的機制，讓多個群集形成一個大的Set，所有群集虛擬機都在同一個大命名空間下面流動，虛擬機可以跨群集/跨可用性集進行實時遷移，故障轉移，目的主要有四，擴展單個群集虛擬化或S2D邊界，實現虛擬機跨群集跨可用性集流動，便于群集生命周期管理，兼容不同存儲架構群集。

ClusterSet完全是一個WSFC新引入的機制，這項技術的缺點就是太耗費資源，要構建管理群集，成員群集，管理員也需要理解2019SOFS的概念，并且目前階段配置也完全只能用Powershell，技術難度較大，因此更加適用于準備構建大型數據中心，私有云，混合云的企業用戶

Hyper-V復制代理這項技術相對來說更容易理解，沒有ClusterSet那么復雜，但是它的缺點就是，一旦其中一方全部崩潰，整個復制關系要計劃外故障轉移時，只能通過手動故障轉移，ClusterSet則可以自動化完成。

ClusterSet與Hyper-V復制有一個共同的好處就是都不需要Care群集的跨站點配置，設想一下，ClusterSet的話 北京一個管理群集，天津一個成員群集，張家口一個成員群集，每一個群集都是本地站點，就不需要考慮跨站點的網絡，存儲，仲裁，站點策略等概念。Hyper-V復制也是一個道理，如果北京群集復制到天津群集，兩邊群集也都是本地站點，因此這種跨群集的解決方案，還有存儲復制的跨群集復制，都不需要關注單群集跨站點時所涉及到的概念，稍微省心一點

但是缺點就是Hyper-V復制代理，存儲復制，跨群集故障轉移時都需要手動執行，如果不跨群集的話那就考慮單群集跨站點的方案，結合存儲復制，可以達到最高的可用性，但需要管理員熟悉跨站點的群集策略，實際應用的時候大家可以結合自己的場景多多思考，到底有沒有必要跨群集，還是跨站點，采用那項技術最為適合。

實驗環境

本文最后老王將為大家實作群集對群集Hyper-V復制的場景，北京站點12node1，12node2，天津站點12node3，12node4，分別連接各自站點的共享存儲，我將在兩個群集之間建立復制代理對復制代理的Hyper-V復制關系，并且逐個宕機宿主機驗證理論。

北京群集

天津群集

北京群集添加Hyper-V副本代理群集角色

輸入客戶端訪問點名稱，之后不論此群集作為Hyper-V復制來源端或目的端都會通過此名稱統一對外復制，一個小技巧，如果希望限定復制時使用的網絡，可以在這里選擇其中群集網絡類型1的網絡子網作為客戶端訪問點IP，隨后在對面各群集節點或單機添加復制代理客戶端訪問點的FQDN名稱，NetBIOS名稱進入hosts文件，因為復制代理的名稱僅在復制時使用，并不對外，所以可以通過hosts文件限定網絡

配置天津站點復制代理

當前北京站點存在一臺虛擬機，虛擬機存儲位于北京站點CSV

右鍵點擊虛擬機，啟用復制

進入復制配置向導，輸入天津站點群集對外復制代理名稱

分別配置兩邊群集Hyper-V復制代理配置，存儲位置可以是SOFS或CSV路徑

其它配置視實際情況而定

點擊群集虛擬機，右鍵，查看復制運行狀況，可以整體檢視Hyper-V復制運作，如果有擴展復制也會在這里顯示，可以看到當前北京站點復制代理，天津站點復制代理分別挑選的復制主機

虛擬機不停機實時遷移到北京站點12node2，此時移走12node1上面其它角色即可不停機維護12node1

再次檢視復制運行狀況，發現復制主機已經自動挑選為12node2

直接宕機12node2，復制引擎感知故障轉移，重新協調由12node1進行復制

宕機12node1 北京站點群集全部關閉，天津站點此時虛擬機處于關閉狀態，需手動進行故障轉移

右鍵點擊虛擬機 - 復制 - 故障轉移

選擇要使用的恢復點

虛擬機跨群集復制啟動成功。

此時如果天津站點12node4崩潰，虛擬機和復制代理角色會故障轉移到12node3，只要仲裁設計合理 ，虛擬機可以存活至最后一個節點

隨后各節點陸續恢復，在天津站點群集上右鍵點擊虛擬機 - 復制 - 反向復制，將數據反向同步回北京站點。

Hyper-V跨群集復制，不像ClusterSet那么復雜，也不需要精通跨站點的群集調優策略，它很簡單，但也能實現很好的效果，只要正確掌握操作方法，發現故障及時手動故障轉移，就可以將宕機時間盡量降到最低，也許你值得擁有。