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弹×××介绍，请参考老王文章 http://www.javashuo.com/article/p-cgnvnjui-ee.html

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，私有云场景

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

以上为本篇延伸群集的内容，但愿能够为感兴趣的朋友带来收获！