延伸群集是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产生时才有意义,否则不会得到测试数据。
测试完成后我们就可以实施延伸群集了
实施思路如下
创建群集
添加群集磁盘
添加来源数据磁盘为CSV或群集角色磁盘
执行群集磁盘复制向导(延伸群集向导)
选择目标数据磁盘,日志磁盘
选择来源日志磁盘
选择同步模式
选择同步初始化步骤
创建群集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以后会做改变。
总结来看微软延伸群集无非是两种架构
超融合,存储复制节点本身再运行Hyper-V或SQL ,实现计算高可用和存储灾难恢复
融合, 存储复制节点本身提供文件服务器UNC路径,供前端使用
本例我们尝试在群集中安装一台虚拟机,运行在数据磁盘CSV,切记,这时在单一复制组中只有来源端数据磁盘可以被使用,其它磁盘不可以使用
我们先来模拟一个存储故障,当前数据磁盘CSV运行在16server1,虚拟机也运行在这里,我们模拟一个存储灾难,直接在16server1连接的ISCSI server上面禁用ISCSI
可以看到,群集可以感知到存储复制主节点 脱机无法连接存储,立刻自动切换存储至16server2为主节点,始终确保有一侧的存储可读写
对于虚拟机而言,由于 2016的VM存储弹×××,所以对于虚拟机来说存储的失联,并不会导致虚拟机崩溃,而是会把虚拟机IO冻结,置为暂停状态,在一定时间内如果存储恢复,重新释放IO。
如果关闭VM存储弹×××,再次尝试,会和之前2012R2时一样,虚拟机检测到存储失联,由于使用了CSV卷,所以虚拟机还会在16server1上面继续运行,但是会使用CSV重定向,访问到16server2的存储,因为16server1已经失去了到存储的连接。
通过这个实验我们就可以把存储复制技术,VM存储弹性技术,CSV技术,虚拟化技术串起来进行理解
延伸群集可以感应到存储故障而故障转移,当其中一个Site节点和存储失联,会自动切换主站点存储转移到辅助站点读写
2016默认情况下开启VM弹×××,其本意是为了确保当存储出现瞬断,不要影响业务,冻结IO,恢复立刻释放。
如果您的VM到存储没有瞬断的情况,那么您可以关掉到VM弹×××,当VM检测到本地存储失联,CSV会发挥作用,重定向IO至其它拥有存储访问资格节点,但注意,此时虚拟机性能会感觉到明显的下降,最好将虚拟机移动至当前存储组活着的站点上
VM存储弹×××主要为了处理瞬断问题,但是如果长时间未恢复,也会延长宕机时间,因此建议如果没有瞬断场景,关闭VM存储弹×××,让虚拟机以CSV重定向运行,或移到转移后存储组主站点。
接下来我们再模拟整个站点发生灾难,主站点计算和存储资源都不用,停止ISCSI服务器,关闭主节点
可以看到,首先存储被自动转移至16server2提供读写
虚拟机也被自动转换至16server2提供服务
这正是延伸群集的魅力所在,实现了计算和存储资源的双灾备,可以容许存储和计算机出错,而不影响业务,当站点级别发生灾难,上面存储复制的主存储会首先自动转移至辅助节点提供服务,承载的SQL,虚拟机,文件服务器资源随后也会故障转移联机上线。
当主站点恢复后,当前并不会自动执行存储复制反转,复制组的主节点将仍然由之前的辅助节点负责,如果希望回复在界面上手动移动CSV卷即可
主站点恢复后,存储组仍然在16server2作为主站点
选择手动移动群集共享卷,反转复制回16server1
这时虚拟机并不会自动移动回主站点,而是会以CSV重定向的方式继续运行在16server2,需手动移动回16server1,如果配合了站点感知和存储站点感知功能,可以实现CSV感应到站点回来了,移动回自身站点,虚拟机过1分钟,感觉到自己和CSV不再一个站点了,也会自动follow CSV移动回去站点,实现虚拟机资源和站点绑定,始终运行在应该运行的站点,永远避免CSV跨站点重定向问题。
需要注意的三点
默认情况下站点故障虚拟机并不会立即故障转移,因为2016的VM弹×××,它以为短暂的瞬断不需要故障转移,所以一段时间内不会故障转移,该功能默认被开启,如果你发现虚拟机未发现转移,而是出于未被监视状态,直接手动移走即可,或关闭VM弹×××,关于VM弹×××介绍,请参考老王文章 https://blog.51cto.com/wzde2012/1963604
对于站点故障,虚拟机资源通常情况下,会在另外一个站点从新开机,除非是来得及正常关机,可以从保存中释放,或实时迁移,否则如果是直接断电,只会是在另外一个站点重新开机。
延伸群集非透明故障转移,当站点级别故障转移时会有10-30秒的延迟,视网络质量而定,因为需要先转移存储,再转移角色。
实施延伸群集时需要综合考虑WSFC2016新功能,以判断转移结果是否符合预期
通过上述两个实验,我们可以看出,延伸群集能够处理三个级别的灾难
1.可以感应存储故障:选择面对VM存储弹性,或CSV重定向,假设虚拟机资源正在运行,忽然失去到存储的连接,2016中默认情况下会进入冻结状态,冻结虚拟机所有IO,等待存储恢复,再把IO释放,这种设计是为了避免存储瞬断问题,如果您的环境没有存储瞬断,那么该功能并不适合,因为冻结期间,一切IO都不能进行,相反,如果针对于虚拟机关闭了VM存储弹性,则虚拟机会直接进入CSV重定向状态,虽然这时候IO都需要东西向转发,虽然慢但是仍然可以进行IO,具体需要根据实际场景做选择。仅Hyper-V资源会面对这种VM存储弹性和CSV重定向的问题,对于SQL和文件服务器负载则不会遇见此问题,它们会直接进行故障转移或重新导向。
2.可以感应节点故障:如果单个节点宕机,会自动将该节点承载的主存储副本转移,承载的角色或虚拟机转移
3.可以感应站点故障:如果整个站点宕机,会自动将该站点承载的主存储副本转移,承载的角色或虚拟机转移
优化建议
考虑网络因素,参考老王灾难恢复博客中提到的关于多站点群集网络方面内容
结合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,私有云场景
存储复制技术本身只是项灾难恢复技术,帮助我们不借助硬件设备原生实现存储的灾难恢复,配合群集技术可以实现延伸群集,帮助我们确保站点灾难恢复的完整性,但是存储复制技术并不是备份技术,您仍需要对来源数据磁盘进行磁盘进行备份,以防止数据误删,需要注意的是存储复制仅支持对来源端可读写的一方进行备份,如果需要从备节点备份,需要先执行反向复制才可以。
以上为本篇延伸群集的内容,希望可以为感兴趣的朋友带来收获!
转载于:https://blog.51cto.com/wzde2012/2049922