• 欢迎访问举个栗子网站
  • 小说APP下载 xsz.tw 不带广告的小说站

Windows Server 2016存储复制浅谈(转)

电脑 举个栗子 2年前 (2017-12-18) 678次浏览 0个评论 扫描二维码

存储复制是 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 技术

2017-11-28_090216.png

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

2017-11-28_091729.png

通过这样的架构,我们就可以看出,存储复制和其它 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/SATAISCSI,Share SAS ,SAN,对于单机对单机,以及群集场景,您还可以一方使用ISCSI,一方使用 SAN,只要保证数据磁盘大小,日志磁盘大小一致即可

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

单机分区对分区 

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

blob.png

单机对单机

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

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

blob.png

延伸群集

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

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

blob.png

跨群集复制

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

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

blob.png

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

模式 工作过程
同步

零数据丢失

RPO

Windows Server 2016 存储复制浅谈(转) 1.应用程序写入数据
2.写入日志磁盘并将日志复制到远程站点
3.远程站点写入日志
4.远程站点返回写入结果
5.复制引擎回应写入完成,应用程序 IO 结束

t&t1:稍后将日志刷新至数据磁盘


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

模式 脚步
异步

近零数据丢失

(取决于多种因素)

RPO

Windows Server 2016 存储复制浅谈(转) 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. 存储复制是Windows Server 2016 数据中心版才有的功能
  2. 复制节点需安装File Server角色,以及存储副本功能
  3. Active Directory 域环境,提供复制过程各节点的 Kerberos 验证
  4. 复制节点至少需要两个磁盘,一个数据磁盘,一个日志磁盘
  5. 数据磁盘和日志磁盘的格式必须为 GPT,不支持 MBR 格式磁盘
  6. 两个数据磁盘大小与分区大小必须相同,最大 10TB
  7. 两个日志磁盘大小与分区大小必须相同,最少 8GB
  8. 存储复制使用 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 磁盘用于日志磁盘

2017-11-28_115230.png

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

16Server1

2017-11-28_115553.png

16Server2

2017-11-28_115954.png

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

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

在其中一台执行即可

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

2017-11-28_120633.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-11-28_134237.png

产生测试报告

md C:\SRtest

Test-SRTopology

-SourceComputerName 16server1    #来源计算机

-SourceVolumeName S:   #来源数据磁盘

-SourceLogVolumeName R:  #来源日志磁盘

-DestinationComputerName 16server2   #目标计算机

-DestinationVolumeName S:  #目标数据磁盘

-DestinationLogVolumeName R: #目标日志磁盘

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

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

2017-11-28_140839.png

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

需求测试

2017-11-28_141540.png

初始同步性能测试

2017-11-28_141553.png

复制写入 IO 延迟

2017-11-28_141608.png

通过此测试我们可以看出,当前环境是否满足存储复制基本需求,性能是否达到预期,如果没有达到,应该如何做出调整,需要注意,此测试一定要在数据磁盘有 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

2017-11-28_143035.png

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

2017-11-28_143411.png

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

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

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

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

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

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

Dismount-SRDestination -Name RG2 -Computername 16server2

监视存储复制状况

命令查看

Get-SRPartnership

显示复制方向

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

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

2017-11-28_145635.png

Get-SRgroup

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

2017-11-28_145741.png

(Get-SRGroup).Replicas

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

2017-11-28_150806.png

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

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

2017-11-28_151028.png

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

Storage Replica Partition I/O Statistics

Storage Replica Statistics

2017-11-28_151349.png

2017-11-28_151544.png

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

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

Sync-SRGroup -Name RG01 -Force

2017-11-28_154552.png

反向复制命令

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

2017-11-28_155036.png

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

2017-11-28_160113.png

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

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

Get-SRPartnership | Remove-SRPartnership -Force

2017-11-28_160358.png

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

16server1

2017-11-28_160515.png

16server2

2017-11-28_160625.png

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

16server1

2017-11-28_160715.png

16server2

2017-11-28_160726.png

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

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

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

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

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

存储复制日常管理操作

管理授权

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

Grant-SRDelegation -UserName oa\mikewang

2017-11-28_161538.png

限制存储复制网卡

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

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

2017-11-28_162745.png

2017-11-28_164247.png

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

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

2017-11-28_164507.png

各节点刷新 SMB 多通道连接

2017-11-28_164645.png

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

2017-11-28_164734.png

限制存储复制带宽使用

创建 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


举个栗子 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明原文链接:Windows Server 2016 存储复制浅谈(转)
喜欢 (0)
举个栗子
关于作者:
建筑工地上施工员,闲暇时弄个博客打发时间,
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址