Windows Server 2016存储复制浅谈

Posted 2020-10-16

存储复制是Windows Server 2016中新增的一项功能，它是Windows Server上面原生自带的块级别复制技术，可以实现分区对分区，单机对单机，延伸群集，跨群集复制等灾备场景的复制，帮助组织更好的提高业务连续性，存储复制技术实现为非对称存储无关性，在单机对单机，以及群集架构中，各节点可分别连接各自存储。

存储复制技术的主要技术特点

1. 使用SMB 3.1.1通讯协议

2. 支持同步复制与非同步复制

3. 复制时会需要日志磁盘与数据磁盘，数据先写入日志磁盘，再Commit数据磁盘

4. 每次复制的最小单位为Block

5. 存储无相关性，节点底层可以是任何存储结构

6. 支持固定式磁盘，最新版本的Server 2016数据中心版，已经支持精简置备磁盘

7. 复制过程存在主备关系，主复制分区可读写，备复制分区不可读写，暂未支持备只读模式
   

8. 使用数据包签名，AES-128-GCM全数据加密等安全技术，存储复制过程使用Kerberos AES256进行节点间的所有身份验证

事实上，存储复制其实是工作在Windows Storage Stack ，Partition Manager之上，Volume Manager之下的一个磁盘过滤器驱动程序，我们都知道，分区是指存储设备上连续的存储区域，卷是指扇区的逻辑集合，一个卷的内部扇区可能来一个分区，或多个分区，或不同的磁盘，而存储复制在分区到卷之间于又插入了一层逻辑，再公开给卷，对于上层的卷和application来说，是不知道底层做了这件事的，您依然可以使用VSS技术，卷级别的Bitlocker 技术

下图可以进一步看到存储的工作过程，可以看到，存储复制在两个节点的Partition Manager之上，Volume Manager之下完成

通过这样的架构，我们就可以看出，存储复制和其它Windows上面的复制技术的不同

1. 它是基于块的复制，它插入在分区之上卷之下的区域，所以不知道文件的概念，不知道它们被使用，也不会像DFS一样，会care文件是不是在被使用

2. 它只关心写入IO，可以被用于CSVFS，NTFS和ReFS

3. 它不是基于检查点，而是连续复制，所以变化的增量往往远低于基于快照的产品

4. 它在分区层上运行，因此可以复制由Windows Server或备份软件创建的所有VSS快照

老王点评：

存储复制技术，可以说是一项广大ITpro一直期待的技术，之前版本的Windows Server中一直没有什么很好的复制技术可以被用于虚拟化，私有云的场景，DFS只能复制关闭的文件，所以很多场景并不能使用它，新的存储复制技术可以说是一大亮点，一个很典型的场景，如果一个企业要实现一套高可用群集架构，这套架构可能是异地的，但是又没有钱实现设备级别的存储复制，只好使用第三方的产品实现存储复制，公开给群集，例如Starwind或者Datakeeper等产品，主机级别实现软件虚拟的存储复制，公开给群集，现在有了存储复制技术，我们直接使用微软原生自带的就可以实现经济实惠的穷人版的存储复制，存储复制技术的两点还在于，它的平台无关性，硬件无关性，存储技术实现为OS层面的一个技术，只要你有Windows Server 2016数据中心版，就可以使用这项技术，那么这就好玩啦，可以是在我们本地机房里面玩，私有云里面玩，公有云里面玩，混合云场景玩，只要有OS可以，还不好说？硬件无关性，存储复制并没有对节点底层存储做限制，可以是本地SCSI/SATA，ISCSI，Share SAS ，SAN，对于单机对单机，以及群集场景，您还可以一方使用ISCSI，一方使用SAN，只要保证数据磁盘大小，日志磁盘大小一致即可

存储复制技术的四种使用场景

单机分区对分区 

可以实现针对于单机Server上面分区对分区级别的复制，复制协议使用SMB，实际应用场景不多，可使用磁盘镜像，存储空间等技术替代

单机对单机

这种场景有一定的使用意义，可以帮助两个相同地域或不同地域的节点，在没有群集的情况下实现基于块级别的存储复制

单机对单机复制的技术特点：需手动故障转移，需使用Powershell创建维护，存储无关性，支援同步复制或非同步复制，后面老王会介绍两者区别

延伸群集

延伸群集即是指，实现了存储双活的群集，避免了存储在单一站点，站点宕机存储失联的问题，之前老王在多站点与灾难恢复篇曾经提到这点，在之前我们仅能用第三方软件或设备实现群集存储的复制，现在原生自带存储复制和WSFC完美融合，实现高可用+灾难恢复。

延伸群集的技术特点：GUI图形界面管理 ，仅支持同步复制(确保群集数据一致性)，存储无关性，全自动故障转移

跨群集复制

实现为两座不同的Cluster之间进行复制，这种场景在国内应该并不多见，老王能想到的是场景，大概可能主要是一套灾备群集，maybe有一套很重要的群集系统，需要对群集本身和群集数据都进行灾备，于是就原模原样又搭建了一套群集，平时不对外，数据实时复制到存储，一旦主群集坏掉或数据丢失，灾备群集立刻启动。

跨群集复制的技术特点：需手动故障转移，支援同步或非同步复制，存储无关性

存储复制同步复制工作过程

模式	图	工作过程
同步 零数据丢失 RPO		1.应用程序写入数据 2.写入日志磁盘并将日志复制到远程站点 3.远程站点写入日志 4.远程站点返回写入结果 5.复制引擎回应写入完成，应用程序IO结束 t＆t1：稍后将日志刷新至数据磁盘

存储复制异步复制工作过程

模式	图	脚步
异步 近零数据丢失 （取决于多种因素） RPO		1.应用程序写入数据 2.数据写入日志磁盘 3.复制引擎回应写入完成，应用程序IO结束 4.复制日志到远程站点 5.远程站点写入日志 6.远程站点返回写入完成确认信息 t＆t1：稍后将日志磁盘数据刷新至数据磁盘

同步复制与非同步复制适用场景

同步复制适用场景

1. 关键性业务应用

2. 短距离节点(网络延迟<5ms, 或距离<30km)

3. 专用的网络链路，高带宽，1GB起步，建议10GB以上实现同步复制。

对于同步复制而言，一个应用程序的写入请求，会等待日志复制到对方节点，返回写入成功后，IO才会结束，因此对于应用程序的写入会略微感到一点延迟，所以对于网络要求会很高，如果网络带宽足够高，延迟不高，那么就不会感觉到写入延迟，利用同步复制可以使您的业务应用获得崩溃一致性，发生故障时应用转移到其他站点继续运行，数据不会丢失。

异步复制适用场景

1. 非关键性应用，可以接受数据出现丢失的可能性

2. 跨城市/跨国家的部署场景

3. 网络带宽有限，没有专用网络链路

在异步复制场景中，应用程序的写入请求会被复制引擎捕获，写入到本地日志磁盘后就立即向应用程序确认写入完成，此模式对于应用程序而言，性能并无消耗，稍后复制引擎会再把数据复制到远程站点，但此过程已经不在应用程序IO路径中，应用程序IO已经结束，所以远程站点的响应性和距离并不重要，但如果源站点忽然宕机，并且数据的副本仍未复制到远程站点，则存在数据丢失的风险。

存储复制可以整合的其它微软技术

部署：Nano Server , SCVMM

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

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

存储复制技术部署需求

1. 复制节点需安装File Server角色，以及存储副本功能

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

3. 复制节点至少需要两个磁盘，一个数据磁盘，一个日志磁盘

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

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

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

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

存储复制规划建议

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

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

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

在老王看来存储复制的主要应用场景为单机对单机，延伸群集，跨群集复制这三种，老王将分别为大家进行实作讲解

本文我们将实作单机对单机的复制

实验场景介绍

AD

Lan：10.0.0.2 255.0.0.0

16Server1

MGMT: 10.0.0.3 255.0.0.0 DNS 10.0.0.2

SMB01：60.0.0.3 255.0.0.0

SMB02：70.0.0.3 255.0.0.0

16Server2

MGMT: 10.0.0.4 255.0.0.0 DNS 10.0.0.2

SMB01：60.0.0.4 255.0.0.0

SMB02：70.0.0.4 255.0.0.0

当前两个节点上面各通过vmware workstation新增了一块20GB磁盘用于数据磁盘，一块15GB磁盘用于日志磁盘

分别联机为GPT磁盘，格式化卷为NTFS

16Server1

16Server2

两个复制已经已经加入到域，可以正常利用Kerberos验证

为各节点安装安装File Server角色，以及存储副本功能

在其中一台执行即可

Invoke-Command -Computername 16server1,16server2 -ScriptBlock{Install-WindowsFeature -Name Storage-Replica,FS-FileServer -IncludeManagementTools -restart}

在实际实现存储功能之前，建议先针对于环境进行测试，测试过程使用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

产生测试报告

md C:\SRtest

Test-SRTopology 

-SourceComputerName 16server1    #来源计算机

-SourceVolumeName S:   #来源数据磁盘

-SourceLogVolumeName R:  #来源日志磁盘

-DestinationComputerName 16server2   #目标计算机

-DestinationVolumeName S:  #目标数据磁盘

-DestinationLogVolumeName R: #目标日志磁盘

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

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

等待一分钟后测试完成，打开报告路径即可看到html格式的存储复制测试报告

需求测试

初始同步性能测试

复制写入IO延迟

通过此测试我们可以看出，当前环境是否满足存储复制基本需求，性能是否达到预期，如果没有达到，应该如何做出调整，需要注意，此测试一定要在数据磁盘有IO产生时才有意义，否则不会得到测试数据。

测试完成后，我们就可以开始配置创建存储复制，配置存储复制的命令和测试的命令差不多，只不过是多了一个存储组的参数，由来源存储组，复制到目标存储组，存储复制组的概念和Azure ASR的概念相通

New-SRPartnership 

-SourceComputerName 16server1 

-SourceRGName RG01

-SourceVolumeName S: 

-SourceLogVolumeName R:

-DestinationComputerName 16server2 

-DestinationRGName RG02

-DestinationVolumeName S: 

-DestinationLogVolumeName R:

-ReplicationMode Asynchronous  #设置同步模式为异步，默认为同步

-Seeded True                                 #合并来源端与目的端数据磁盘的数据，默认为false，即来源端始终覆盖目的端

-LogSizeInBytes 12GB                   #设置Log文件大小

-Verbose

打开16server2可以看到数据磁盘S，成为备磁盘，不再可用，正如我们前面说过的这样，目前存储复制只能是主备架构，主可以读写，目标备不可读写。

最新版本的Windows Server 2016  1709版本新增了测试存储副本的功能，可以帮助我们测试数据有没有得到正常的复制

首先在主数据磁盘产生数据

要使用存储副本的测试故障转移功能，您需要有一个未使用的NTFS或ReFS格式的卷，挂载到目标节点，且目前没有参与存储复制，测试过程可以暂时挂载复制存储的快照以用于测试或备份目的

#挂载当前备复制节点16server2的数据磁盘至K盘

Mount-SRDestination -Name RG2 -Computername 16server2 -TemporaryPath K:\

#移除测试故障转移快照并放弃更改

Dismount-SRDestination -Name RG2 -Computername 16server2

监视存储复制状况

命令查看

Get-SRPartnership

显示复制方向

来源服务器 -> 目标服务器

来源复制组 ->目的复制组

Get-SRgroup

显示复制组信息，其中主要关注Replication Status，该属性为Relicating说明正在复制，InitialBlockCopy说明还在初始复制，如果出现error字样说明当前出现无法执行复制

(Get-SRGroup).Replicas

显示同一复制组内各分区复制状态，每一个复制组可以复制两个以上的分区，通过此命令可以显示所有分区的复制状态

关于存储复制的日志，可以通过事件查看器看到，设计为两个通道，Admin与Operational

位于应用程序和服务日志 - Windows - StorageReplica

存储复制性能计数器，如果有SCOM 可以使用SCOM收集性能计数器指针，或编写MP包进行监视，也可整合OMS，到云端展示。

Storage Replica Partition I/O Statistics 

Storage Replica Statistics

在单机对单机，或跨群集复制时，不支持自动化的故障转移，因此一旦节点宕机，需要手动切换复制，手动切换复制，其实就所谓的反向复制，我们重新切换，由可用的一方为主节点，提供读写功能。

刷新主节点复制组日志至数据磁盘，防止数据丢失

Sync-SRGroup -Name RG01 -Force

反向复制命令

Set-SRPartnership -NewSourceComputerName 16server2 -SourceRGName RG2 -DestinationComputerName 16server1 -DestinationRGName RG1 

执行反向复制完成后，当前数据在16server2可读写，可以看到我们之前复制过来的数据

这里有一点需要和大家说明，很多外国的博客都没提到这点，对于单机对单机复制，反向复制切换仅在计划内维护有效，例如，当前server1，server2存活，计划内我们知道server1要维护，可以利用反向复制把server1的复制切换到server2提供读写服务，然后维护server1，但是一旦server1忽然宕机，这时候在server2再次执行这条命令是不会成功的，根据老王的了解，在单机对单机的情况下，这种场景，只有删除存储复制组，这时磁盘会分别释放给两个节点，两个节点都能读写，这时候例如server1宕机，我在server2上面删除复制关系，释放出磁盘，给应用读写，等server1可用时再重建复制关系，只有这样做了，并不是很完美，期望以后可以更智能一些，server1忽然宕机，server2运行一条命令能够直接接管

#删除存储复制关系，其中一个节点执行即可

Get-SRPartnership | Remove-SRPartnership -Force

#删除复制组，需在各节点执行

16server1

16server2

磁盘分别释放给各节点，每个节点的磁盘都可以看到数据

16server1

16server2

如果是两个节点的情况下，忽然宕机，大家可以遵循这样的步骤去恢复

时间节点1：主服务器宕机

时间节点2：备服务器删除复制关系，复制组

时间节点3：备服务器提供读写

时间节点4：主服务器恢复，备服务器重新创建复制关系至主服务器

存储复制日常管理操作

管理授权

默认情况下存储复制服务器本地管理员具备管理存储复制权限，可以通过委派普通用户，而不需要本地管理员权限

Grant-SRDelegation -UserName oa\mikewang

限制存储复制网卡

默认情况下存储复制会尽可能使用所有可用通信的网卡进行存储复制，我们可以指定使用指定网卡完成存储复制流量

Get-NetAdapter 获取各节点网卡index信息

创建存储复制网络限制策略

Set-SRNetworkConstraint -SourceComputerName 16server1 -SourceRGName RG01 -SourceNWInterface 11,13 -DestinationComputerName 16server2 -DestinationNWInterface 10,12 -DestinationRGName RG02

各节点刷新SMB多通道连接

各节点获取SMB多通道-存储复制专用链路

限制存储复制带宽使用

创建SMB带宽限制

Set-SmbBandwidthLimit  -Category StorageReplication -BytesPerSecond  50MB

查看SMB带宽限制

Get-SmbBandwidthLimit -Category StorageReplication

删除SMB带宽限制

Remove-SmbBandwidthLimit -Category StorageReplication

删除复制后无法再次配置复制

删除所有孤立的Storage Replica分区数据库并重新装入所有分区（单机一招爽）

Clear-SRMetadata -AllPartitions 

删除所有孤立的Storage Replica日志数据

Clear-SRMetadata -AllLogs 

删除所有孤立的故障转移群集配置数据

Clear-SRMetadata -AllConfiguration （群集一招爽）

删除单个复制组元数据

Clear-SRMetadata -Name RG01 -Logs -Partition