WSFC2016 跨群集复制

   前面两篇文章中，老王和你们介绍了存储复制的功能，在单机对单机，以及延伸群集的实践，基本上你们能够看出，这是一种基于块级别的存储复制，原生内置于Windows Server 2016上面，能够帮助咱们实如今单机对单机场景下的灾备，也能够结合群集，实现存储和应用结合，当发生站点级别灾难的时候，自动转移存储和应用

   对于工程师来讲，如今架构上又多了一个新的选择，咱们能够不借助设备，不借助第三方产品，就使用微软原生的OS实现高可用+灾难恢复

  虽说延伸群集很好，可是仍有一个弊端，即不能直接使用各节点本地磁盘完成存储复制，各站点节点还必须接入本身站点的存储，两个站点需以非对称共享存储的方式来完成复制，老王猜测微软的本意，就是但愿把延伸群集这项功能用于异地站点不一样共享存储，例如北京站点各节点接入北京站点的存储，天津站点各节点接入天津站点的存储，而后呢，在两个Site之间作存储复制，以实现延伸群集的效果，即使是本地站点存储和计算节点所有崩溃，另一个站点也可使用

  不过老王猜测应该仍是群集机制的缘由，致使目前延伸群集还不能使用各节点本地磁盘，由于微软群集设计之初就是要求实现群集存储永久保留，群集数据存放共享存储，以便切换直接挂载，若是直接本地磁盘进入群集磁盘，故障切换上会有一些问题

  虽说微软2016有了S2D技术，能够实现超融合存储，可是它本质上功能和咱们讲的灾难恢复仍是有一些区别，S2D老王认为是存储+群集结合起来的一项技术，咱们在群集上面启用S2D，以后经过一个存储汇流排把各个节点的磁盘聚集在一块儿，可是注意，这里并非说各节点的本地磁盘直接就进到群集磁盘，而是在群集存储里面机箱的区域能够看到全部节点的可用磁盘，咱们开启S2D后，能够至关于咱们逻辑的构建了一个存储机柜，这个存储机柜里面的存储是来自各个节点的磁盘，接下来要怎么用呢，咱们还须要在这个逻辑的存储机柜上面划分Lun给各个节点接入，因此咱们建立存储池，虚拟磁盘，实现容错，分层，缓存，最终交付到群集上面是虚拟磁盘，虚拟磁盘就能够被认做是一个群集磁盘，可是事实上只会显示一个群集磁盘，即使这个虚拟磁盘是经过逻辑存储机柜，多个节点建立出来的。

  因此，在老王看来，S2D是借助于群集，实现了一个逻辑存储机柜，而后分配存储给群集应用使用，因此这个概念你们能够看到，和咱们的存储复制仍是有一些出入，相对来看，彷佛业界都是经过S2D这样的超融合架构来实现延伸群集

  

  直接底层S2D逻辑存储机柜的层面作好站点感知，而后分配给群集，存储在底层已经作好了容错，微软为何没有实现这种架构，老王猜测应该是优化和机制的问题

  1.当前S2D只能作到机架感知和机箱感知，不能作到站点感知，即没办法控制数据撒到不一样站点

  2.S2D对于网络性能要求过高，不适用于延伸群集场景

也maybe，过几个版本微软会针对于S2D作站点感知的优化，到时咱们就能够实现超融合延伸群集，或者灾难恢复延伸群集

就目前的状况来看，咱们只能经过灾难恢复来实现延伸群集的效果，那么不少朋友可能会问，为何延伸群集不能和S2D相结合一块儿来用

首先老王认为在微软生态环境中这是两个解决不一样场景的方案

延伸群集，是为了处理跨站点群集，存储的灾难恢复，为两个站点的存储实现复制，确保能够接受站点级别的灾难

S2D，     是为了处理存储设备昂贵，经过本地磁盘实现群集存储，经过操做系统软件实现存储设备的管理功能

若是咱们使用S2D，在同一个群集内并不会显示两套存储，仅会显示一套存储，由于S2D是在底层实现的存储容错

而延伸群集须要两套存储，以实现不一样站点的存储复制

因此根据目前这个定位来看，老王认为延伸群集不会和S2D有什么契合点，除非后面的版本有大变化

1. 废弃当前经过存储复制机制实现的延伸群集，优化S2D站点感知，实现延伸群集

2. 优化S2D站点感知，实现两种延伸群集模型

3. S2D架构开通一个click键，是否要实现延伸群集，若是是，则不经过底层容错，而提供两套存储，实现存储复制

就老王来看，我认为1和3的概率都不大，2的概率大一些，反正如今网络也不是瓶颈，若是企业有钱，固然能够选择用S2D实现延伸群集

事实上老王以为目前这个存储复制实现的延伸群集效果也挺好的，对于企业没有高级存储设备，可是又想实现跨站点的灾备，经过存储复制+群集，能够实现很低的RTO和RPO，灾难切换的时候实现彻底自动化，这更是一大优点

那么这是对于延伸群集中存储复制，S2D的一些探讨，对于Windows Server 2016的存储复制来讲，咱们还有另一种场景，跨群集复制，将存储复制扩展至群集边界外

在这种场景中，咱们就能够把S2D方案和存储复制方案相结合

前文咱们提到过，存储复制解决方案对于存储没有要求，底层能够是本地SCSI/SATA，ISCSI，Share SAS ，SAN，SDS，对于延伸群集来讲，多是须要非对称共享存储的架构，要是ISCSI，SAN，JBOD等架构，可是对于单机对单机或者群集对群集来讲，就没有这么多说法了，咱们可使用本地磁盘和SDS架构，在单机对单机的架构中，就至关因而，我给你系统OS提供一个存储，你别管我是怎么来的，只要两边大小一致符合要求就能够创建存储复制，群集对群集也基本上差很少，能够把一个群集当作一个大主机，两个群集就是两个大主机，你别管我这个群集的存储怎么来的，总之我群集有符合要求的存储，只要两个群集的存储配置都符合要求，就能够进行群集对群集的复制

这就有不少场景能够玩啦

例如：北京站点群集存储架构是ISCSI，天津站点群集存储架构是S2D，而后针对于两个群集作存储复制，一旦ISCSI主存储没法正常提供服务，马上切换至天津站的提供服务，或者北京站点采用物理机部署，天津站点采用虚拟机部署，北京站点使用私有云部署群集，而后再在公有云部署群集，本地群集和存储宕机，公有云里面的群集和存储能够启动起来

群集对群集复制的好处

1.不用额外配置站点感知，若是北京群集都在北京站点，只会是群集内故障转移

2.两个站点的存储底层架构能够不同，避免单一类型存储都出现故障

3.支持同步复制与异步复制

4.支持更复杂的架构，例如华北群集和华南群集，华北群集由北京节点和天津节点构成，华南群集由广东和深圳节点构成，各站点内部分别配置站点故障感知，北京节点坏了或者天津节点坏了可有可无，应用会漂移至同群集的相近站点，若是整个华北地区群集所有宕机，还能够再华南群集从新启动群集角色

5.帮助实现群集级别的容灾，例如若是北京群集配置出现故障，不会影响到天津群集，天津群集能够利用复制过来的存储启动群集角色

6.两个站点可使用不一样的网络架构，以实现子网的容错

群集对群集复制的坏处

1.须要手动使用命令进行故障转移，无图形化界面操做

2.故障转移时，需事先在备群集准备好群集角色，而后从新挂载上存储

3.针对于文件服务器，跨群集故障转移后需使用新名称访问

跨群集复制技术部署需求

1. 各复制节点操做系统须要是Windows Server 2016数据中心版

2. 至少有四台服务器（两个群集中各两台服务器），支持最多 2 个 64 节点群集

3. 两组共享存储， SAS JBOD、SAN、Share VHDX、S2D或 iSCSI，每一个存储组设置为仅对每一个群集可用

4. 复制节点需安装File Server角色，存储副本功能，故障转移群集功能

5. Active Directory域环境，提供复制过程各节点的Kerberos验证

6. 每一个复制群集至少须要两个磁盘，一个数据磁盘，一个日志磁盘

7. 数据磁盘和日志磁盘的格式必须为GPT，不支持MBR格式磁盘

8. 两个群集数据磁盘大小与分区大小必须相同，最大 10TB

9. 两个群集日志磁盘大小与分区大小必须相同，最少 8GB

10. 须要为各群集内须要被复制的磁盘分配CSV或文件服务器角色

11. 存储复制使用445端口（SMB - 复制传输协议），5895端口（WSManHTTP - WMI / CIM / PowerShell的管理协议），5445端口（iWARP SMB - 仅在使用iWARP RDMA网络时须要）

    
    

跨群集复制规划建议

1. 建议为日志磁盘使用SSD，或NVME SSD，存储复制首先写入数据至日志磁盘，良好的日志磁盘性能能够帮助提升写入效率

2. 建议规划较大的日志空间，较大的日志容许从较大的中断中恢复速度更快，但会消耗空间成本。

3. 为同步复制场景准备可靠高速的网络带宽，建议1Gbps起步，最好10Gbps，同步复制场景，若是带宽不足，将延迟应用程序的写入请求时间

4. 针对于跨云，跨国，或者远距离的跨群集复制，建议使用异步复制

跨群集复制能够整合的其它微软技术

部署：Nano Server , SCVMM

管理：PS，Azure ASR，WMI，Honolulu，SCOM，OMS，Azure Stack

整合：Hyper-V，Storage Spaces Direct ，Scale-Out File Server，SMB Multichannel，SMB Direct，重复资料删除，ReFS，NTFS

微软跨群集复制场景实做

本例模拟两座异地群集相互复制，北京站点两个节点，天津站点两个节点，北京站点有一台DC，也承载ISCSI服务器角色，北京站点群集使用ISCSI存储架构，天津站点两个节点，使用S2D架构，分别模拟节点宕机，站点宕机，站点恢复后反向复制。

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

 

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

天津站点

16Server3

MGMT: 10.0.0.5 255.0.0.0 DNS 10.0.0.2

S2D：30.0.0.5 255.0.0.0

Heart：19.0.0.5 255.0.0.0

 

16Server4

MGMT: 10.0.0.6 255.0.0.0 DNS 10.0.0.2

S2D：30.0.0.6 255.0.0.0

Heart：19.0.0.6 255.0.0.0

因为咱们采用群集对群集架构，所以网络上面也更加灵活，例如，心跳网络没必要都在同一个网段内，由于心跳网络是群集级别，跨群集了以后即使你在一个网段，另外的群集也不知道，管理网络也可使用不一样的子网，例如若是不作多个复制组，不作多活的话，那么天津的对外网络能够设置在一个安全的网段下，正常不对外提供服务，再经过网络策略限制存储复制流量从ISCSI卡到S2D卡，这样只须要打通两个群集的存储流量便可，天津若是有DC，则最好群集可使用天津站点DC。当灾难发生时，再把北京的网络和天津的管理网络打通，让北京用户访问天津的角色

操做流程

1.北京站点接入存储

2.北京站点建立群集

3.北京站点建立群集角色

4.天津站点接入存储

5.天津站点建立群集

6.天津站点开启S2D

7.天津站点建立群集角色

8.分配互相群集权限

9.建立存储复制

10.站点灾难恢复

北京站点接入存储

16server1

16server2

北京站点建立群集，配置群集仲裁为文件共享见证或云见证

北京站点建立文件服务器群集角色

能够看到，老王这里建立的群集角色是SOFS，这是跨群集复制和延伸群集的不一样点，延伸群集的时候微软说明负载只是CSV和传统高可用文件服务器角色，可是在跨群集复制时场景又变成了能够支持SOFS，咱们都知道SOFS主要强调的是文件服务器双活以及透明故障转移，因为在延伸群集中故障转移须要先存储切换再转移角色，所以很难实现透明故障转移，在跨群集复制时，可能因为是两个群集，因此每一个群集内部能够部署SOFS，实现群集内部的透明故障转移，至于站点故障，则没办法彻底透明

天津各节点接入本地存储，大小随意，最后咱们在群集存储空间上面会从新建立群集磁盘

16server3

16server4

拿到存储后，各节点把磁盘联机，初始化为GPT磁盘便可，不要直接对磁盘进行分区操做，咱们须要再经过S2D包上一层才能交付给群集

天津站点建立S2D群集

New-Cluster -Name TJCluster -Node 16Server3,16Server4  -StaticAddress 10.0.0.20 –NoStorage

注：执行前确保节点已符合S2D需求，生产环境建议执行群集验证

开启群集S2D功能

Enable-ClusterS2D -CacheState disabled -Autoconfig 0 -SkipEligibilityChecks

若是你是在vmware workstation上面模拟这个实验，你会发现开启S2D的过程会始终卡在这里，没办法进行下去，查看日志发现S2D一直没办法识别磁盘

可是究竟是什么缘由识别不了磁盘呢，vmware虚拟上来的磁盘是SAS总线的，也符合S2D的需求，通过一番研究后，老王找到了缘由，原来经过vmware虚拟出来的虚拟机没有Serial Number，而开启S2D会去找磁盘的这个数字，找不到，因此磁盘没办法被声明为S2D可用

经过在vmware虚拟机vmx配置文件关机添加参数便可

disk.EnableUUID="true"

添加完成后开机能够看到Serial Number已经能够正常显示

配置各节点磁盘MediaType标签

再次开启S2D，顺利经过，如今咱们能够在vmware workstation上面模拟S2D实验！

建立群集存储池

新建虚拟磁盘（存储空间），这里的虚拟磁盘交付出来就是群集磁盘，因此咱们要和北京群集的群集磁盘大小确保一致，以便实现存储复制

数据磁盘

日志磁盘

天津站点配置群集角色

在天津站点任意节点上授予到北京站点群集的权限

Grant-SRAccess -ComputerName 16server3 -Cluster BJcluster  

在北京站点任意节点上授予到天津站点群集的权限

Grant-SRAccess -ComputerName 16server1 -Cluster TJcluster  

建立群集对群集复制关系

New-SRPartnership -SourceComputerName bjcluster -SourceRGName rg01 -SourceVolumeName C:\ClusterStorage\Volume1 -SourceLogVolumeName R: -DestinationComputerName tjcluster -DestinationRGName rg02 -DestinationVolumeName C:\ClusterStorage\Volume1 -DestinationLogVolumeName R:

建立完成复制关系后，当前天津群集的数据磁盘会变成 联机(无访问权) ，到这里你们须要有这个意识，对于跨群集来讲，咱们如今把复制的边界跨越了群集，所以每一个复制组运做过程当中都会有一个群集的数据磁盘是待命状态，对于待命群集，复制组内磁盘不能被使用，若是部署多个跨群集复制组，能够实现群集应用互为待命。

当前文件服务器群集角色在北京站点提供服务，全部者节点为16server1，已经有一些数据文件

直接断电16server1，SOFS自动透明故障转移至同站点内16server2

存储复制继续在同站点16server2进行，由此你们能够看出，存储复制和Hyper-V复制同样，在群集内有一个复制协调引擎，经过群集名称和外面的群集进行复制，而后再协调内部由那个节点进行复制，一旦某个群集节点宕机，自动协调另一个节点参与复制，区别在于Hyper-V复制在群集有显式的群集角色，存储复制的群集角色是隐藏的

接下来模拟北京站点所有发生灾难，16server1,16server2所有断电，这时来到天津站点的群集能够看到，当前群集磁盘处于脱机状态，并不会自动完成跨群集的故障转移

手动强制跨群集故障转移

Set-SRPartnership -NewSourceComputerName tjcluster -SourceRGName rg02 -DestinationComputerName bjcluster -DestinationRGName rg01 -force

执行完成后当前数据在天津站点可读

打开数据磁盘CSV能够看到北京站点的数据被完整复制过来

实际测试跨服务器故障转移后，共享文件夹权限并不会被自动迁移，默认状况下会是未共享状态，自行手动共享便可，猜测是跨服务器转移磁盘的缘故，若是权限较多，你们能够尝试下配合权限迁移可否映射过来，不过事实上，对于这种跨服务器故障转移的负载，实际生产环境仍是建议以SQL文件，VHDX，VHD文件为主，发生跨群集故障转移后直接在新群集从新启动数据库或虚拟机角色。

如今咱们完成了跨群集的灾难恢复，若是采用网络分离的架构，把天津站点的访问公开给北京用户便可，正如咱们以前所说，转移后会使用新的名称进行访问

即使这时天津站点再坏掉一个节点，SOFS也能够透明故障转移至仅存的节点存活，前提是仲裁配置得当

仅剩下一个最后节点时，存储复制会处于暂停状态，等待其它节点恢复

等待一段时间后，各站点服务器陆续修复完成上线，存储复制自动恢复正常连续复制，当前主复制站点为天津站点

若是但愿此时继续由北京站点恢复为主站点，能够执行反转复制，把天津站点内容复制回北京站点，主备关系恢复

经过三篇对于Windows Server 2016存储复制功能的介绍，相信你们对于这项技术都有了了解，很高兴的一点是听闻有的朋友看了个人博客已经开始在实际环境使用了，存储复制技术是2016存储的一项主要进步，原生的块级别复制，若是节点不多，不想维护群集的话，可使用单机对单机场景实现灾难恢复，若是但愿群集得到最低的RTO/RPO，可使用延伸群集功能，得到自动化的灾难恢复，若是但愿规划更为复杂的架构，针对于不一样站点但愿使用不一样网络和存储架构，实现跨群集跨站点级别的灾难恢复，如今也能够实现，最终但愿你们看了文章后都能有本身的思考