WSFC2016 延伸群集

延伸群集是Windows Server 2016存儲復制的主要應用場景，通過把存儲復制與WSFC的結合，實現跨站點群集存儲的復制，幫助企業更好的實現較低RTO RPO的跨站點災難恢復，確保當站點發生故障轉移時不會因為存儲而導致轉移失敗。

事實上微軟并不是首先提出延伸群集這個概念的，早在前些年VMare VSAN，IBM SVC就已經提出了這個概念，對于延伸群集這個概念每個廠商都有各自的實踐理解

以VSAN延伸群集為例，對于VSAN來說，延伸群集是超融合存儲節點的一種擴展，將原有的機房內機架，擴展到同城多園區，或異地的群集架構，實現VSAN延伸群集后，VSAN上面的虛擬機存儲會被存放兩份，每個組件都對應存儲到一個主站點，一個輔助站點，主站點和輔助站點都可以存放數據，每份數據都會有兩份，每份數據都可以確保有一個副本被復制到其它站點，同時虛擬機對于存儲的讀取經過優化，延伸群集架構中，每個虛擬機會從本地站點100%讀取存儲，和DRS結合，故障轉移后由DRS切換至合適站點。

VSAN延伸群集架構的特點

1.  節省存儲成本，延伸群集可完全由本地VSAN存儲實現

2.  虛擬機會與各站點綁定，確保正常情況下虛擬機都運行在應該運行的站點

3.  結合見證組件實現自動故障切換，如果虛擬機所在站點宕機，可以在另外站點重新啟動

4.  由超融合功能本身實現，不需要借助其它軟件

5.  實現雙活，并非一個站點主，另外一個站點完全不可用，兩個站點都可以正常存儲虛擬機，虛擬機會被復制到對方站點

6.  每份組件至多只會有一份副本，不可以復制到多個站點

7.  會占用總資源的百分之50，留作災難恢復，這部分計算資源和存儲資源需要預留，否則災難發生虛擬機沒辦法完全啟動。

微軟的延伸群集和VSAN，IBM SVC提出的概念有所不同，事實上微軟的延伸群集并非是群集本身，或者是超融合軟件，存儲虛擬化軟件來實現，而是將系統上面的存儲復制功能與群集功能相結合，在實現高可用的基礎上，再實現災難恢復，兩者相結合達到業務連續性

我們都知道，微軟群集本身支持多站點部署，在之前老王和大家也專門提到過，微軟多站點群集部署需要考慮的網絡，仲裁，存儲，在存儲里面老王又和大家講到了存儲復制的重要性，傳統情況下群集時兩個節點連到一個共享存儲，但是在多站點的情況下，你需要實現兩個站點都有存儲，因為如果存儲在一個站點，如果發現站點級別災難，即便另外一個站點可以接管，但是由于沒有存儲，同樣群集沒辦法運轉，因此多站點群集的重要一條就在于實現存儲的復制，存儲復制在以前通常是設備實現，或者第三方軟件，例如Starwind，SIOS，Symantec VVR等產品

微軟在Windows Server 2016實現了基于塊級別的存儲復制，操作系統只需要添加功能就可以實現

對于微軟延伸群集來說，它把存儲復制和群集做了結合，架構上使用非對稱存儲架構，即站點1連接站點1的共享存儲，站點2連接站點2的共享存儲，兩邊的存儲大小一致，符合存儲復制要求，就可以實現延伸群集

配置微軟延伸群集可以在群集管理器圖形界面完成，它會把兩邊站點符合要求的磁盤進行存儲復制配置，支持在同一個群集里面部署多套復制組以實現多主雙活，當其中一個站點發生故障時，延伸群集將自動實現故障轉移，將對方站點的復制組存儲全部提升為主，然后群集應用在對方站點聯機上線，由于是使用故障轉移群集，因此微軟延伸群集具備最低RTO，發生故障后，將會由群集自動化完成故障轉移，不需要人為干預，如果使用同步復制架構，則使用零RPO丟失，如果使用異步復制架構，則有可能產生數據丟失

微軟延伸群集和微軟Hyper-V復制的主要區別在于

1.  延伸群集是自動化故障轉移，Hyper-V復制需手動

2.  延伸群集只能恢復到最近時間點，Hyper-V可以恢復到多個可選時間點

微軟延伸群集架構特點

1. 目前仍需使用非對稱架構，即兩邊站點分別連接共享存儲，不能使用本地磁盤，SDS架構，maybe以后的版本會改變

2.  使用兩組非對稱共享存儲，底層可以是SAS JBOD（可與存儲空間配合使用，支持SDD HDD混合架構）、 SAN、Share VHDX 或 iSCSI ，需要支持永久保留

3.  每個復制組，需要有源和目的數據磁盤，日志磁盤

4.  完全windows server實現，不需要借助其他軟件

5.  是存儲復制技術和群集技術的配合，可以做到自動化故障轉移和存儲切換

6.  在延伸群集架構中來源數據磁盤必須是CSV或者傳統文件服務器群集角色才可以復制

7.  可以建立多個復制組，以實現多主雙活

8.  存儲復制技術會占用群集總資源的百分之50，留作災難恢復，這部分計算資源和存儲資源需要預留，否則災難發生沒辦法完全啟動。

9.  主要用于文件服務器負載和虛擬化負載

10. 支持計劃內 計劃外故障轉移 存儲切換

11. 可以配合群集站點感知技術，群集放置技術，實現優先本地站點故障轉移，讀取優化等

通過對比我們可以看出，兩種類型的延伸群集各有千秋，但歸根到底都是為了實現跨站點群集 存儲的高度可用，因此我們可以暫且給延伸群集一個初步定義，在實現跨站點群集的基礎上，利用設備復制技術，或超融合技術，或復制技術，實現了存儲的高度可用，確保站點發生故障時，不會因為存儲而影響災難恢復。

延伸群集存儲處理的幾大類別

1.  設備復制：以EMC，Netapp，華為為代表

2.  第三方軟件復制，以Symantec，SIOS，Vision，Starwind為代表

3.  超融合或存儲虛擬化復制：VSAN，IBM SVC

4.  服務器操作系統原生復制：微軟延伸群集

微軟延伸群集的配置需求

1. Active Directory域環境，提供復制過程各節點的Kerberos驗證

2.  各Site節點分別連接各自Site存儲，確保每個Site存儲不對另外Site可見

3.  每個Site復制節點至少需要兩個磁盤，一個數據磁盤，一個日志磁盤

4.  數據磁盤和日志磁盤的格式必須為GPT，不支持MBR格式磁盤

5.  兩個數據磁盤大小與分區大小必須相同，最大 10TB

6.  兩個日志磁盤大小與分區大小必須相同，最少 8GB

7.  來源數據磁盤需配置為CSV或群集角色

8. 存儲復制使用445端口（SMB - 復制傳輸協議），5895端口（WSManHTTP - WMI / CIM / PowerShell的管理協議），5445端口（iWARP SMB - 僅在使用iWARP RDMA網絡時需要）

微軟延伸群集的規劃建議

1. 考慮RTO / RPO 以及成本，如果是關鍵應用，可以使用延伸群集同步復制架構，可以確保最低的RTO，以及零數據丟失RPO，但隨之而來需要更高要求的帶寬，而且同步復制建議兩個站點延遲不超過5ms，或者距離不超過30km，因此同步復制延伸群集適用于同城不同園區，高帶寬低延遲的網絡，可以最高程度確保應用可用。  如果群集應用并非很關鍵，可以接受短暫時間的數據丟失，那么您可以考慮異步復制的延伸群集架構，最新的windows server 2016已經支持異步復制延伸群集，在之前的版本只支持同步復制，使用異步復制延伸群集架構的好處是對于帶寬要求并不高，可以接受延遲，距離也可以更遠，跨地域，或者跨國，缺點是如果故障忽然發生，可能數據沒有來得及復制到輔助站點，導致數據丟失，因此工程師需結合實際企業情況選擇合適的架構，是應該使用同步復制延伸群集，還是異步復制延伸群集，還是hyper-v復制，ASR，或其它產品。

2.  建議為日志磁盤使用SSD，或NVME SSD，存儲復制首先寫入數據至日志磁盤，良好的日志磁盤性能可以幫助提高寫入效率

3.  建議規劃較大的日志空間，較大的日志允許從較大的中斷中恢復速度更快，但會消耗空間成本。

4.  同步復制延伸群集準備可靠高速的網絡帶寬，建議1Gbps起步，最好10Gbps，網卡支援RDMA更好，同步復制場景，如果帶寬不足，將延遲應用程序的寫入請求時間

5.  實際場景建議最少四節點實現延伸群集，配合站點感知技術實現應用正常本地站點轉移，災難發生時轉移至輔助站點

延伸群集可以整合的其它微軟技術

部署：Nano Server，SCVMM

管理：PS，WMI，群集管理器，Honolulu，SCOM，OMS，Azure Stack，Azure ASR，DPM

整合：Hyper-V，SOFS，SMB Multichannel，SMB Direct，重復資料刪除，ReFS，NTFS

微軟延伸群集和WSFC 2016其它功能整合的思考

有了延伸群集的功能后，工程師們可以更好的思考多站點群集的設計

例如配合站點感知，存儲站點感知功能，讓同站點內始終優先在同站點內做故障轉移

配合站點心跳檢測功能，調整跨站點故障轉移檢測參數

配合VM彈性技術，存儲彈性技術實現瞬斷處理

配合云仲裁技術實現延伸群集見證

微軟延伸群集實作

環境介紹

本次實驗模擬兩個站點的架構，北京站點和天津站點，兩個節點各一臺server，一臺ISCSI，各節點分別連接各自站點存儲，實現基于CSV的延伸群集，群集再承載Hyper-V高可用虛擬機角色，正常情況存儲和虛擬機在主站點運作，主站點發生災難轉移至輔助站點

AD&北京ISCSI

Lan：10.0.0.2 255.0.0.0

ISCSI：30.0.0.2 255.0.0.0

16Server1

MGMT: 10.0.0.3 255.0.0.0 DNS 10.0.0.2

ISCSI：30.0.0.3 255.0.0.0

Heart：18.0.0.3 255.0.0.0

天津AD&ISCSI

Lan:10.0.0.100

ISCSI.30.0.0.100

16Server2

MGMT: 10.0.0.4 255.0.0.0 DNS 10.0.0.100

ISCSI：30.0.0.4 255.0.0.0

Heart：18.0.0.4 255.0.0.0

當前各節點已經分別連接到各站點ISCSI存儲，分別格式化為GPT，NTFS磁盤，10GB數據磁盤，8GB日志磁盤

16server1

16server2

為各節點安裝故障轉移群集功能，存儲復制功能，文件服務器角色功能可選

同樣實現延伸群集之前，建議先針對于環境進行測試，測試過程使用Test-SRTopology命令完成測試，該命令在完成按照存儲副本功能后即可使用，測試過程將評估現有環境是否符合存儲復制要求，將檢查磁盤大小，分區大小是否一致，帶寬是否符合要求，日志大小是否符合，復制IOPS，初始復制性能等，最終將根據評估結果，出示html報表

執行Test-SRTopology命令需為磁盤產生IO才有效果，這里老王使用Diskspd命令產生一個IO測試

Diskspd下載地址：https://gallery.technet.microsoft.com/DiskSpd-a-robust-storage-6cd2f223 

Diskspd.exe -c1m –d300 -W5 -C5 -b8k -t2 -o2 -r –w25 –h s:\test.dat

產生測試報告

Test-SRTopology 

-SourceComputerName 16server1    #來源計算機

-SourceVolumeName S:   #來源數據磁盤

-SourceLogVolumeName R:  #來源日志磁盤

-DestinationComputerName 16server2   #目標計算機

-DestinationVolumeName S:  #目標數據磁盤

-DestinationLogVolumeName R: #目標日志磁盤

-DurationInMinutes 1  #指定測試時間，生產環境建議10-30分鐘

-ResultPath C:\SRTest  #報告生成路徑

等待測試完成，打開報告路徑即可看到html格式的存儲復制測試報告，該報告會展示當前環境是否滿足存儲復制基本需求，性能是否達到預期，如果沒有達到，應該如何做出調整，需要注意，此測試一定要在數據磁盤有IO產生時才有意義，否則不會得到測試數據。

測試完成后我們就可以實施延伸群集了

實施思路如下

1. 創建群集

2. 添加群集磁盤

3. 添加來源數據磁盤為CSV或群集角色磁盤

4. 執行群集磁盤復制向導（延伸群集向導）

5. 選擇目標數據磁盤，日志磁盤

6. 選擇來源日志磁盤

7. 選擇同步模式

8. 選擇同步初始化步驟

創建群集SRcluster，配置群集仲裁為文件共享仲裁，或云仲裁，或獨立復制外的仲裁磁盤

剛創建完成群集，打開磁盤會發現一塊磁盤也沒有，因為我們既沒有開啟S2D，也沒有使用共享磁盤，所以默認情況下這里為空

如果我們需要配置延伸群集需要額外輸入一條命令，讓可以群集讀取所有非對稱共享磁盤

Get-ClusterAvailableDisk -All | Add-ClusterDisk

輸入完成后，這時所有磁盤都可以在群集看到，由于我們是非對稱磁盤的架構，有兩塊磁盤應該始終會處于未連接狀態，因為并不是所有磁盤都對所有節點可見

添加來源數據磁盤為CSV，或為來源數據磁盤分配傳統高可用文件服務器角色

在已添加的群集共享卷處，右鍵點擊復制 - 啟用

開始執行延伸群集配置向導，選擇目標數據磁盤

選擇來源日志磁盤

選擇目標日志磁盤

選擇初始同步操作，指定是合并或是由來源端覆蓋目的端

配置復制模式，同步復制或異步復制 ，關于同步復制和異步復制區別可以查看老王第一篇存儲復制博客

配置一致性組，選擇優化排序性能，或啟用寫入順序，如果您計劃部署SQL FCI On CSV by StorageReplica 或其它對寫入順序有要求的群集應用 ，則您務必需要選擇啟用寫入順序

OK，We Done it！到這里延伸群集就配置完成了，跑完向導之后，我們可以在群集中看到存儲的變化

先前不可用的磁盤變成了SR組，復制角色也有了顯示，來源站點日志磁盤被自動提升為CSV

在磁盤信息的下方可以看到多了存儲一欄，在里面可以看到當前存儲復制的復制狀態

經過初始化復制后，正常情況下復制狀態應該會一直是連續復制

測試計劃內故障轉移，存儲復制和群集融合后可以說非常智能，方便多了，舉個例子，當前如果我們通過兩臺節點實現存儲復制，上面跑CSV提供服務，如果我們知道要做維護了，可以直接把源數據磁盤和日志磁盤移動到目的磁盤，再把節點置為維護模式，這時就可以針對源站點進行維護操作

點擊來源端數據磁盤 日志磁盤，選擇移動至16server2

移動后即可看到，當前存儲復制已經完成了計劃內維護反轉，16server2變成源，16server1變成目標，如果16server1上面還承載了其它角色，移走就可以做維護了

雖然這里我們也可以在16server1上面的CSV看到存儲內容，但是請注意，這時16server1看CSV，是通過CSV重定向協調 而看到的16server2提供的內容，因為我們已經把存儲復制移動至16server2，所以16server1源主節點也就無法訪問到存儲，這時如果還有應用運行在16server1，將是以CSV重定向的方式運作，效能會很低，因此如果執行了存儲復制反轉的操作后，建議盡快將16server1上面的角色移走，做完維護再回來聯機角色

當前我們得到了CSV之后，就可以在它上面運行群集負載，推薦使用Hyper-V，SQL 2014及以后版本，或直接使用傳統高可用文件服務器，這里官網并未說明支持SOFS，只是說道支持傳統高可用文件服務器，老王猜想可能是由于存儲復制的切換，導致SOFS沒辦法完成透明故障轉移，因此暫未完全支持，maybe以后會做改變。

總結來看微軟延伸群集無非是兩種架構 

1. 超融合，存儲復制節點本身再運行Hyper-V或SQL ，實現計算高可用和存儲災難恢復

2. 融合，  存儲復制節點本身提供文件服務器UNC路徑，供前端使用
   

本例我們嘗試在群集中安裝一臺虛擬機，運行在數據磁盤CSV，切記，這時在單一復制組中只有來源端數據磁盤可以被使用，其它磁盤不可以使用

我們先來模擬一個存儲故障，當前數據磁盤CSV運行在16server1，虛擬機也運行在這里，我們模擬一個存儲災難，直接在16server1連接的ISCSI server上面禁用ISCSI

可以看到，群集可以感知到存儲復制主節點 脫機無法連接存儲，立刻自動切換存儲至16server2為主節點，始終確保有一側的存儲可讀寫

對于虛擬機而言，由于 2016的VM存儲彈×××，所以對于虛擬機來說存儲的失聯，并不會導致虛擬機崩潰，而是會把虛擬機IO凍結，置為暫停狀態，在一定時間內如果存儲恢復，重新釋放IO。

如果關閉VM存儲彈×××，再次嘗試，會和之前2012R2時一樣，虛擬機檢測到存儲失聯，由于使用了CSV卷，所以虛擬機還會在16server1上面繼續運行，但是會使用CSV重定向，訪問到16server2的存儲，因為16server1已經失去了到存儲的連接。

通過這個實驗我們就可以把存儲復制技術，VM存儲彈性技術，CSV技術，虛擬化技術串起來進行理解

1. 延伸群集可以感應到存儲故障而故障轉移，當其中一個Site節點和存儲失聯，會自動切換主站點存儲轉移到輔助站點讀寫

2. 2016默認情況下開啟VM彈×××，其本意是為了確保當存儲出現瞬斷，不要影響業務，凍結IO，恢復立刻釋放。

3. 如果您的VM到存儲沒有瞬斷的情況，那么您可以關掉到VM彈×××，當VM檢測到本地存儲失聯，CSV會發揮作用，重定向IO至其它擁有存儲訪問資格節點，但注意，此時虛擬機性能會感覺到明顯的下降，最好將虛擬機移動至當前存儲組活著的站點上

4. VM存儲彈×××主要為了處理瞬斷問題，但是如果長時間未恢復，也會延長宕機時間，因此建議如果沒有瞬斷場景，關閉VM存儲彈×××，讓虛擬機以CSV重定向運行，或移到轉移后存儲組主站點。
   

接下來我們再模擬整個站點發生災難，主站點計算和存儲資源都不用，停止ISCSI服務器，關閉主節點

可以看到，首先存儲被自動轉移至16server2提供讀寫

虛擬機也被自動轉換至16server2提供服務

這正是延伸群集的魅力所在，實現了計算和存儲資源的雙災備，可以容許存儲和計算機出錯，而不影響業務，當站點級別發生災難，上面存儲復制的主存儲會首先自動轉移至輔助節點提供服務，承載的SQL，虛擬機，文件服務器資源隨后也會故障轉移聯機上線。

當主站點恢復后，當前并不會自動執行存儲復制反轉，復制組的主節點將仍然由之前的輔助節點負責，如果希望回復在界面上手動移動CSV卷即可

主站點恢復后，存儲組仍然在16server2作為主站點

選擇手動移動群集共享卷，反轉復制回16server1

這時虛擬機并不會自動移動回主站點，而是會以CSV重定向的方式繼續運行在16server2，需手動移動回16server1，如果配合了站點感知和存儲站點感知功能，可以實現CSV感應到站點回來了，移動回自身站點，虛擬機過1分鐘，感覺到自己和CSV不再一個站點了，也會自動follow CSV移動回去站點，實現虛擬機資源和站點綁定，始終運行在應該運行的站點，永遠避免CSV跨站點重定向問題。

需要注意的三點

1. 默認情況下站點故障虛擬機并不會立即故障轉移，因為2016的VM彈×××，它以為短暫的瞬斷不需要故障轉移，所以一段時間內不會故障轉移，該功能默認被開啟，如果你發現虛擬機未發現轉移，而是出于未被監視狀態，直接手動移走即可，或關閉VM彈×××，關于VM彈×××介紹，請參考老王文章 https://blog.51cto.com/wzde2012/1963604

2. 對于站點故障，虛擬機資源通常情況下，會在另外一個站點從新開機，除非是來得及正常關機，可以從保存中釋放，或實時遷移，否則如果是直接斷電，只會是在另外一個站點重新開機。

3. 延伸群集非透明故障轉移，當站點級別故障轉移時會有10-30秒的延遲，視網絡質量而定，因為需要先轉移存儲，再轉移角色。

4. 實施延伸群集時需要綜合考慮WSFC2016新功能，以判斷轉移結果是否符合預期
   

通過上述兩個實驗，我們可以看出，延伸群集能夠處理三個級別的災難

1.可以感應存儲故障：選擇面對VM存儲彈性，或CSV重定向，假設虛擬機資源正在運行，忽然失去到存儲的連接，2016中默認情況下會進入凍結狀態，凍結虛擬機所有IO，等待存儲恢復，再把IO釋放，這種設計是為了避免存儲瞬斷問題，如果您的環境沒有存儲瞬斷，那么該功能并不適合，因為凍結期間，一切IO都不能進行，相反，如果針對于虛擬機關閉了VM存儲彈性，則虛擬機會直接進入CSV重定向狀態，雖然這時候IO都需要東西向轉發，雖然慢但是仍然可以進行IO，具體需要根據實際場景做選擇。僅Hyper-V資源會面對這種VM存儲彈性和CSV重定向的問題，對于SQL和文件服務器負載則不會遇見此問題，它們會直接進行故障轉移或重新導向。

2.可以感應節點故障：如果單個節點宕機，會自動將該節點承載的主存儲副本轉移，承載的角色或虛擬機轉移

3.可以感應站點故障：如果整個站點宕機，會自動將該站點承載的主存儲副本轉移，承載的角色或虛擬機轉移

優化建議

1. 考慮網絡因素，參考老王災難恢復博客中提到的關于多站點群集網絡方面內容

2. 結合WSFC 2016站點感知，存儲站點感知，首選站點 
   

按照微軟的建議，最佳實踐是至少部署四個節點的延伸群集，本地站點兩個節點，異地或同城站點兩個節點

#配置站點故障域感知，實現優先站點內故障轉移

New-ClusterFaultDomain -Name Beijing -Type Site -Description "Primary" -Location "Beijing Datacenter"     #創建北京站點故障域

New-ClusterFaultDomain -Name Tianjing -Type Site -Description "Secondary" -Location "Tianjing Datacenter"   #創建天津站點故障域

Set-ClusterFaultDomain -Name 16server1 -Parent Beijing    #添加北京節點進入站點故障域

Set-ClusterFaultDomain -Name 16server2 -Parent Beijing  

Set-ClusterFaultDomain -Name 16server3 -Parent Tianjing   #添加天津節點進入站點故障域

Set-ClusterFaultDomain -Name 16server4 -Parent Tianjing

#配置CSV follow Site ，應用 Follow CSV

 Get-ClusterSharedVolume | Get-ClusterGroup  #獲取CSV組名稱

（Get-ClusterGroup -name  CSVClusterGroupName）.PreferredSite =“Beijing” #配置北京站點CSV follow北京站點

（Get-ClusterGroup -name  CSVClusterGroupName）.PreferredSite =“Tianjing”#配置天津站點CSV follow添加站點

這樣優化之后我們會得到這樣效果

故障域是本站點共享存儲：存儲復制自動轉移至其它站點，如果CSV轉移過去，則虛擬機也會跟隨CSV過去，避免面對CSV重定向和VM存儲彈性

故障域是本站點單主機節點：虛擬機或群集角色自動轉移同站點其它主機

故障域是本站點共享存儲和所有節點：存儲復制自動轉移至其它站點，資源跟隨存儲自動在其它站點啟動。

存儲復制支持在單個群集中創建多個復制組，需要注意的是一個復制組至少就是4塊磁盤，兩個復制組就要準備八塊磁盤

通過部署兩個復制組，我們可以實現多個復制組雙活，例如第一個復制組的主是北京，備是天津，第二個復制組的主是天津，備是北京

這樣可以更好的把群集計算資源利用起來，對于存儲資源來說還是消耗一半的資源

如果是部署了多主雙活的復制組，建議使用站點感知和存儲站點感知功能，實現優先在本地站點轉移，資源跟隨CSV，避免CSV重定向

典型的場景 

1.實現SQL多個實例的多個復制組雙活，在一套WSFC群集上利用多個復制組來保證多個SQL實例的雙活

2.超融合架構，節點既作為hyper-v節點也作為存儲復制節點，可以處理磁盤級別，節點級別，站點故障

延伸群集排錯：

存儲復制事件日志：應用程序和服務日志 - Windows - StorageReplica - Admin

存儲復制性能計數器指針

群集管理器日志

群集事件管理器日志

ClusterLog

dumpfile

通過上述的介紹，相信大家已經看到了延伸群集的功能，它是微軟WSFC和存儲復制功能的結合，兩者在災難恢復時間可以完美融合，自動完成存儲復制切換與群集角色切換，能夠處理磁盤故障，節點故障，站點故障。

希望存儲復制未來可以優化的幾點

1.支持本地磁盤，SDS架構

2.可以實現透明故障轉移

3.優化磁盤鎖定問題

4.可以和WSFC2016 VM負載功能整合，VM負載如果可以感應到站點，就能夠讓應用在站點內進行負載均衡，遵循站點感應和存儲站點感應規則，目前群集一旦使用了存儲復制是輕易不敢使用VM負載功能的，因為VM負載均衡功能目前不能感應站點，所以有可能會把虛擬機遷移到其它站點，CSV并不會跟著遷移，所以會導致CSV跨站點重定向，如果VM均衡可以感應站點，那么延伸群集中，每個站點內部可以執行負載均衡，自動控制各節點負載均衡

5.可以支持一對多存儲復制，群集對單機擴展復制

6.可以和更多微軟應用整合

在微軟的整套企業級應用生態圈中，除了存儲復制，還有很多其它的復制產品，存儲對比它們到底有什么不同和配合點

Hyper-V復制與存儲復制的不同

Hyper-V在標準版中也支持，而存儲復制僅支持數據中心版

Hyper-V復制使用80或443端口，存儲復制使用SMB 445

Hyper-V可以支援在復制過程中選擇證書驗證或非證書

Hyper-V支持多個恢復點，在災難后可以選擇恢復

Hyper-V復制可以是虛擬機所有磁盤，存儲復制不支持復制系統磁盤

Hyper-V復制專為虛擬機設計，可以更好的處理應用程序一致性問題

Hyper-V復制計劃外需手動故障轉移，存儲復制延伸群集可以做到自動故障轉移

總結來看：hyper-v復制和存儲復制在很多點都有相似的地方，它們都是存儲無關性，都是災難恢復的功能，不同的是存儲復制更專注于保證存儲底層的高度可用，hyper-v復制則可以更好的理解上面虛擬機的VSS應用，hyper-v復制目前已經有了環境評估工具，擴展復制，ASR，復制進度視圖，相對來說在災難恢復層面來看似乎比存儲復制更為全面，存儲復制對比hyper-v最大的不同就是可以原生做到自動化的故障轉移，而hyper-v復制要實現自動化故障轉移需要借助腳本或ASR實現，使用hyper-v復制可以獲得廉價的災難恢復，但原生災難恢復時會有RTO和RPO的延遲，使用存儲復制延伸群集可以獲得最低的RTO和零RPO的丟失，代價是高帶寬低延遲的網絡。

存儲復制比hyper-v復制應用場景更多，存儲復制只要有OS就可以使用，可以在Guest Cluster，任何云平臺，任何虛擬化平臺

Exchange DAG  暫時不支持底層是存儲復制架構

SQL Always on 復制與存儲復制的區別和配合點

AlwaysOn復制不僅僅是塊級別，它更懂得SQL

可以實現副本只讀，存儲復制暫時未支持

支持八個異步副本或兩個同步副本

支持備份目標副本，存儲復制僅支持備份源副本

SQL AG需要SQL企業版授權，如果沒有授權則沒辦法實現SQL AG，這時候可以配合存儲復制，實現SQL實例的存儲復制保護

DFS FRS與存儲復制的不同

DFS復制是文件目錄級別，存儲復制是分區級別

DFS只支持復制關閉的文件，存儲復制無此限制

DFS和AD站點集成 使用站點拓撲，存儲復制不和AD站點集成

DFS是分布式的，各個節點都可以讀取，存儲復制備站點暫時不可以讀取

DFS可以提供統一對外名稱，名稱訪問與復制功能分離，存儲復制不提供統一對外名稱

DFS主要用于復制關閉的文件，信息工作者文件，存儲復制主要用于hyper-v，文件服務器，SQL，私有云場景

存儲復制技術本身只是項災難恢復技術，幫助我們不借助硬件設備原生實現存儲的災難恢復，配合群集技術可以實現延伸群集，幫助我們確保站點災難恢復的完整性，但是存儲復制技術并不是備份技術，您仍需要對來源數據磁盤進行磁盤進行備份，以防止數據誤刪，需要注意的是存儲復制僅支持對來源端可讀寫的一方進行備份，如果需要從備節點備份，需要先執行反向復制才可以。

以上為本篇延伸群集的內容，希望可以為感興趣的朋友帶來收獲！