延伸群集是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

2017-12-11_125536.png


2017-12-11_125718.png


16server2

2017-12-11_130006.png


2017-12-11_130020.png


为各节点安装故障转移群集功能,存储复制功能,文件服务器角色功能可选


2017-12-11_130736.png

 


同样实现延伸群集之前,建议先针对于环境进行测试,测试过程使用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

2017-12-11_134537.png


产生测试报告



Test-SRTopology 

-SourceComputerName 16server1    #来源计算机

-SourceVolumeName S:   #来源数据磁盘

-SourceLogVolumeName R:  #来源日志磁盘

-DestinationComputerName 16server2   #目标计算机

-DestinationVolumeName S:  #目标数据磁盘

-DestinationLogVolumeName R: #目标日志磁盘

-DurationInMinutes 1  #指定测试时间,生产环境建议10-30分钟

-ResultPath C:\SRTest  #报告生成路径


2017-12-11_135617.png


等待测试完成,打开报告路径即可看到html格式的存储复制测试报告,该报告会展示当前环境是否满足存储复制基本需求,性能是否达到预期,如果没有达到,应该如何做出调整,需要注意,此测试一定要在数据磁盘有IO产生时才有意义,否则不会得到测试数据。


2017-12-11_135844.png


测试完成后我们就可以实施延伸群集了


实施思路如下


  1. 创建群集

  2. 添加群集磁盘

  3. 添加来源数据磁盘为CSV或群集角色磁盘

  4. 执行群集磁盘复制向导(延伸群集向导)

  5. 选择目标数据磁盘,日志磁盘

  6. 选择来源日志磁盘

  7. 选择同步模式

  8. 选择同步初始化步骤


创建群集SRcluster,配置群集仲裁为文件共享仲裁,或云仲裁,或独立复制外的仲裁磁盘

2017-12-11_152227.png

刚创建完成群集,打开磁盘会发现一块磁盘也没有,因为我们既没有开启S2D,也没有使用共享磁盘,所以默认情况下这里为空

2017-12-11_152924.png

如果我们需要配置延伸群集需要额外输入一条命令,让可以群集读取所有非对称共享磁盘

Get-ClusterAvailableDisk -All | Add-ClusterDisk

2017-12-11_152846.png


输入完成后,这时所有磁盘都可以在群集看到,由于我们是非对称磁盘的架构,有两块磁盘应该始终会处于未连接状态,因为并不是所有磁盘都对所有节点可见

2017-12-11_153119.png

添加来源数据磁盘为CSV,或为来源数据磁盘分配传统高可用文件服务器角色

2017-12-11_153239.png

在已添加的群集共享卷处,右键点击复制 - 启用

2017-12-11_153355.png

开始执行延伸群集配置向导,选择目标数据磁盘

2017-12-11_153455.png


选择来源日志磁盘

2017-12-11_153636.png

选择目标日志磁盘

2017-12-11_154000.png

选择初始同步操作,指定是合并或是由来源端覆盖目的端

2017-12-11_154019.png

配置复制模式,同步复制或异步复制 ,关于同步复制和异步复制区别可以查看老王第一篇存储复制博客

2017-12-11_154031.png

配置一致性组,选择优化排序性能,或启用写入顺序,如果您计划部署SQL FCI On CSV by StorageReplica 或其它对写入顺序有要求的群集应用 ,则您务必需要选择启用写入顺序

2017-12-11_160028.png


OK,We Done it!到这里延伸群集就配置完成了,跑完向导之后,我们可以在群集中看到存储的变化


先前不可用的磁盘变成了SR组,复制角色也有了显示,来源站点日志磁盘被自动提升为CSV

2017-12-11_161146.png

在磁盘信息的下方可以看到多了存储一栏,在里面可以看到当前存储复制的复制状态

2017-12-11_161328.png

经过初始化复制后,正常情况下复制状态应该会一直是连续复制

2017-12-11_161757.png


测试计划内故障转移,存储复制和群集融合后可以说非常智能,方便多了,举个例子,当前如果我们通过两台节点实现存储复制,上面跑CSV提供服务,如果我们知道要做维护了,可以直接把源数据磁盘和日志磁盘移动到目的磁盘,再把节点置为维护模式,这时就可以针对源站点进行维护操作


点击来源端数据磁盘 日志磁盘,选择移动至16server2

2017-12-11_161940.png

移动后即可看到,当前存储复制已经完成了计划内维护反转,16server2变成源,16server1变成目标,如果16server1上面还承载了其它角色,移走就可以做维护了

2017-12-11_162008.png

虽然这里我们也可以在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,切记,这时在单一复制组中只有来源端数据磁盘可以被使用,其它磁盘不可以使用

2017-12-12_091901.png


2017-12-12_092013.png


我们先来模拟一个存储故障,当前数据磁盘CSV运行在16server1,虚拟机也运行在这里,我们模拟一个存储灾难,直接在16server1连接的ISCSI server上面禁用ISCSI

2017-12-12_092126.png

可以看到,群集可以感知到存储复制主节点 脱机无法连接存储,立刻自动切换存储至16server2为主节点,始终确保有一侧的存储可读写

2017-12-12_092303.png

对于虚拟机而言,由于 2016的VM存储弹×××,所以对于虚拟机来说存储的失联,并不会导致虚拟机崩溃,而是会把虚拟机IO冻结,置为暂停状态,在一定时间内如果存储恢复,重新释放IO。

2017-12-12_092519.png



2017-12-12_092538.png


如果关闭VM存储弹×××,再次尝试,会和之前2012R2时一样,虚拟机检测到存储失联,由于使用了CSV卷,所以虚拟机还会在16server1上面继续运行,但是会使用CSV重定向,访问到16server2的存储,因为16server1已经失去了到存储的连接。


2017-12-12_100519.png


2017-12-12_101735.png


通过这个实验我们就可以把存储复制技术,VM存储弹性技术,CSV技术,虚拟化技术串起来进行理解


  1. 延伸群集可以感应到存储故障而故障转移,当其中一个Site节点和存储失联,会自动切换主站点存储转移到辅助站点读写

  2. 2016默认情况下开启VM弹×××,其本意是为了确保当存储出现瞬断,不要影响业务,冻结IO,恢复立刻释放。

  3. 如果您的VM到存储没有瞬断的情况,那么您可以关掉到VM弹×××,当VM检测到本地存储失联,CSV会发挥作用,重定向IO至其它拥有存储访问资格节点,但注意,此时虚拟机性能会感觉到明显的下降,最好将虚拟机移动至当前存储组活着的站点上

  4. VM存储弹×××主要为了处理瞬断问题,但是如果长时间未恢复,也会延长宕机时间,因此建议如果没有瞬断场景,关闭VM存储弹×××,让虚拟机以CSV重定向运行,或移到转移后存储组主站点。


接下来我们再模拟整个站点发生灾难,主站点计算和存储资源都不用,停止ISCSI服务器,关闭主节点


可以看到,首先存储被自动转移至16server2提供读写

2017-12-12_140604.png

虚拟机也被自动转换至16server2提供服务

2017-12-12_191128.png

这正是延伸群集的魅力所在,实现了计算和存储资源的双灾备,可以容许存储和计算机出错,而不影响业务,当站点级别发生灾难,上面存储复制的主存储会首先自动转移至辅助节点提供服务,承载的SQL,虚拟机,文件服务器资源随后也会故障转移联机上线。


当主站点恢复后,当前并不会自动执行存储复制反转,复制组的主节点将仍然由之前的辅助节点负责,如果希望回复在界面上手动移动CSV卷即可


主站点恢复后,存储组仍然在16server2作为主站点

2017-12-12_190058.png

选择手动移动群集共享卷,反转复制回16server1

2017-12-12_190203.png


2017-12-12_190323.png

这时虚拟机并不会自动移动回主站点,而是会以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.可以和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,私有云场景


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


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