WSFC2016 延伸群集

Posted 2020-10-17

延伸群集是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，同步复制场景，如果带宽不足，将延迟应用程序的写入请求时间

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，各节点分别连接各自站点存储，群集承载SOFS角色，给前端使用，正常情况在主站点，主站点发生灾难转移至辅助站点

 

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弹性功能介绍，请参考老王文章 http://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.可以和更多微软应用整合

在微软的整套企业级应用生态圈中，除了存储复制，还有很多其它的复制产品，存储对比它们到底有什么不同和配合点

Hyper-V复制与存储复制的不同

Hyper-V在标准版中也支持，而存储复制仅支持数据中心版

Hyper-V复制使用80或443端口，存储复制使用SMB 445

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实例的存储复制保护

DFSR FRS与存储复制的不同

DFSR只支持复制关闭的文件，存储复制无此限制

DFSR和AD站点集成 使用站点拓扑，存储复制不和AD站点集成

DFSR是分布式的，各个节点都可以读取，存储复制备站点暂时不可以读取

DFSR主要用于复制关闭的文件，信息工作者文件，存储复制主要用于hyper-v，文件服务器，SQL，私有云场景

存储复制技术本身只是项灾难恢复技术，帮助我们不借助硬件设备原生实现存储的灾难恢复，配合群集技术可以实现延伸群集，帮助我们确保站点灾难恢复的完整性，但是存储复制技术并不是备份技术，您仍需要对来源数据磁盘进行磁盘进行备份，以防止数据误删，需要注意的是存储复制仅支持对来源端可读写的一方进行备份，如果需要从备节点备份，需要先执行反向复制才可以。

以上为本篇延伸群集的内容，希望可以为感兴趣的朋友带来收获！