码迷,mamicode.com
首页 > 其他好文 > 详细

WSFC2016 延伸群集

时间:2017-12-12 23:52:52      阅读:1034      评论:0      收藏:0      [点我收藏+]

标签:微软延伸群集   微软存储复制   wsfc2016   vm存储弹性   

延伸群集是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,私有云场景


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


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

WSFC2016 延伸群集

标签:微软延伸群集   微软存储复制   wsfc2016   vm存储弹性   

原文地址:http://blog.51cto.com/wzde2012/2049922

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!