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那麼複雜，也不須要精通跨站點的羣集調優策略，它很簡單，但也能實現很好的效果，只要正確掌握操做方法，發現故障及時手動故障轉移，就能夠將宕機時間儘可能降到最低，也許你值得擁有。