Storage Space Direct(简称S2D)是微软在Windows Server 2016数据中心版集成的第三代软件定义存储技术,S2D技术能够将工业标准X86服务器的本地磁盘汇总构建出具备高可用、高性能和易扩展的软件定义存储架构。S2D的优势在于和自家产品如Hyper-V/WAC/SCVMM/SCOM整合较好,适用于那些已经广泛使用微软企业级产品的用户,微软不仅有成熟企业级产品,也有成熟的OEM生态圈,微软不仅在今年发布了Windows Server 2019,同时还宣布了WSSD产品的路线图。随着Windows Server 2019功能的不断优化与增强,S2D的性能与可靠性已经得到企业用户认可,相信会有部分已经在使用2016版本S2D用户会选择将原有环境升级至最新版本,故本文老王将为大家介绍如何在不停机的情况下将2016环境的S2D滚动升级2019


本文老王将不会过多介绍S2D相关概念原理,我们将主要专注于S2D滚动升级的过程思考

本文老王以S2D融合架构为例主要讲解,对于超融合场景会进行简单提示

由于目前网络上面还没有相关文章,老王会将S2D滚动升级细节全部呈现,以供日后国内用户升级时参考


滚动升级之前老王曾经写过一篇Hyper-V 2012滚动升级2016的文章,滚动升级的概念能够得以实现,即在同一个群集内完成不停机的升级,前提条件有二,一 群集支持混合模式,二 虚拟化软件支持向下兼容。来到S2D同样是这个道理,只不过不是2012到2016,而是2016到2019支持滚动升级,由于2012存储空间与2016S2D架构不同,所以2012存储空间升级到2016S2D时只有在2012节点重装2016,然后升级存储池,因此当中一定会产生宕机时间,但是2016到2019就不同了,由于2016和2019采用的是相同的S2D架构,因此我们可以在升级过程中,实现数据同时在2016节点与2019节点撒下,意味着当我们重做了一台2016节点装成2019时,这个节点可以直接加入现有存储池的容错,不会对业务产生任何可用性影响。

2018-10-23_214058.png

理解了前提条件之后,继续往后看,众所周知,S2D是基于微软WSFC群集实现的架构,而一旦一个WSFC群集变成了S2D群集之后,每个机器除了作为普通群集节点,还会承担S2D数据写入故障域的角色,S2D将各个群集节点本地磁盘汇总起来,在群集里面形成一个虚拟机的盘柜,当数据写入时,S2D会把数据切分成一个个1GB的extent,按照虚拟磁盘容错规则进行写入,如果是镜像,则确保extent两个副本始终写入在两个不同节点,以此类推,不允许因为单个节点故障影响虚拟磁盘可用。


这样我们就需要额外考虑一些问题,不能当成单独的群集滚动升级对待,例如,当我们暂停或删除一个节点时,对于S2D产生的影响,节点恢复后应该执行那些操作,带着这些疑问我们走进环境开始实战


环境介绍,当前有一套三节点S2D2016群集,已经开启了S2D,已经创建一个镜像容错的虚拟磁盘正在使用

2018-10-22_180033.png

我们将通过不停机滚动升级的方式最终将三个节点都升级为2019,关于验证不停机的方法,老王采用实时写入脚本进行验证,脚本如下

for /L %i in (1,1,30000) do fsutil File createnew %i 1024 

这段脚本的意思是每隔一秒钟对S2D卷写入一个1KB的文件,写入30000次,如果写入在升级过程中没有中断,可以持续写入,则说明滚动升级没有对写入造成任何影响,脚本可以在一个节点一直跑到最后,直到最后这个节点要升级时,切换到其它节点继续跑。

2018-10-22_180131.png

在执行S2D滚动升级之前,首先要做的一个步骤是检查,检查四样东西


1.虚拟磁盘是否健康

2018-10-22_181546.png

2.是否有未完成的存储作业

2018-10-22_181533.png

3.检查磁盘操作状态,是否存在Needs Rebalance提示,如果有请执行Optimize-Storagepool操作

2018-10-23_182608.png

4.是否存在CAU或VMM等自动更新任务,如有,请针对群集节点全部关闭,以防止影响手动操作群集升级过程。


确保环境已就绪,我们就要开始执行S2D滚动升级第一个操作,暂停节点,对于一般的群集节点而言,暂停节点意味着按照放置规则排出角色到其它节点,对于S2D意义又多了一点,首先,正常情况下,数据会在三个节点之间随机找到两个节点进行镜像写入,假设一个群集节点宕机,那么对于虚拟磁盘来说会变成降级状态,因为在该节点上面的extent副本将不可用,意味着一些数据块可能此时会是没有第二个副本可用的,暂停节点后数据再次写入,extent将不会再次撒在暂停节点,当节点恢复后,暂停期间其它节点写入的增量数据会自动同步到暂停节点。如果是超融合场景下,此步骤虚拟机中也将一起被排出到其它节点。

2018-10-22_180229.png

暂停节点时S2D将执行刷新和提交数据,因此务必要记得执行暂停节点操作,当节点被置为暂停状态后,下一个操作是将节点从S2D群集中删除,我们仅执行逐出操作,这意味着仅在群集中删除该节点,但并不删除已经在群集池中注册的物理磁盘,即便节点被逐出群集,但节点的本地磁盘依然会被记录在群集池中,只是被标记为丢失状态,即便是节点重做系统后,只要磁盘还插在节点上,那么就可以重新与群集池中的磁盘关联。

2018-10-22_182258.png


2018-10-22_184442.png

逐出之后,对节点进行脱域,干净重装2019操作系统,机器名可以和原来一样,也可以重新命名,此过程略

2018-10-22_182536.png

当节点被暂停逐出后,可以看到虚拟磁盘此时的操作状态为降级,这是因为丢失了一个故障域节点,但并不影响对磁盘的写入,可通过写入脚本看出,对于一个故障域的虚拟磁盘来说,此时群集不能再有节点宕机,否则磁盘将不可访问,如果是三路镜像,有两个故障域,则可以再允许宕机一个节点。

2018-10-23_093107.png

在虚拟化环境中执行此操作的朋友可能会遇到一个BUG,即2019节点新做好了之后怎么也加入不到群集里面,根本原因是error 1809的问题,此节点已加入启用存储空间直通的群集,但未在当前版本上进行验证,此节点将被隔离

详见KB  https://support.microsoft.com/en-us/help/4464776/software-defined-data-center-and-software-defined-networking


2018-10-22_210113.png

WSSD是微软的一个全新计划,微软和DELL/Dataon/HPE等厂商合作,推出合作解决方案,厂商提供设备,经过微软认证后即可在上面出色的运行微软最新的SDDC技术,S2D/SDN/WAC等等,但是有的客户可能就是虚拟化环境,或者没有买WSSD认证设备,那就会遇见这个问题,经过研究得知是2019节点加入S2D群集时会经过一个判断,检查注册表的一个键值,如果已存在则可以运行加入S2D群集

位置在HKEY_LOCAL_MECHINE\SYSTEM\CurrentControlSet\Services\ClusSvc\Parameters下面,管理员需要在S2D群集里面每个节点键入该键值,DWORD类型,名称S2D,数值为1,针对于2019节点,需事先建Parameters项,再新建键值即可规避此问题

2018-10-23_103751.png

处理完成后2019节点即可正常加入S2D2016群集

2018-10-22_202854.png

当2019节点加入到群集后,我们可以通过注册表观察到当前群集已经进入了混合模式,如下位置的MixedMode数值为1,代表群集当前处于混合模式,如果全部升级为2019,群集FunctionalLevel升级后,则数值为0

2018-10-22_215008.png

通过获取群集详细信息可以看到,群集当前功能级别为9,代表着群集当前是Windows Server 2016的群集功能级别,如果群集节点全部升级到2019后,提升群集FunctionalLevel后,群集功能级别将升级为10。

2018-10-22_214807.png

节点正常加入群集后,先前由于重做系统而在群集池中失联的磁盘,重新联系上变为正常状态

2018-10-23_220458.png

获取存储作业可以看到,首先,2019节点加入到S2D群集后,S2D先执行Repair作业,此作业目的是将节点不在期间,各虚拟磁盘的增量数据进行重新同步,此操作证明S2D支持跨2016/2019节点撒下数据,此操作不会影响磁盘的正常写入,但从节点暂停退出后到此修复过程,磁盘性能将有所下降。

2018-10-22_181407.png

你也可能会看到Optimize作业操作,这里解释下为什么升级过程要留意它,以及为什么开始之前要进行检查,在S2D运作过程中随着数据的大量写入删除,可能在某一个时间节点,一个物理磁盘的利用率已经达到了百分之90 ,而其它物理磁盘只有百分之60,这样就有可能出现单个物理硬盘被写爆,导致影响写入操作,甚至虚拟磁盘脱机,因此,建议在滚动升级过程中,每做完一个节点就留意下各个磁盘的使用状况或者群集管理器中的虚拟磁盘状态,是否出现Needs Rebalance,如果有,立即执行Optimize-Storagepool ,除此之外当新加入节点至S2D群集时,每隔一段时间大概30分钟,会自动执行Optimize-Storagepool操作,等不及的话也可以直接手动执行。


Repair作业是为了同步节点暂停时其它节点更新的数据,Optimize作业是为了平衡节点添加后各节点物理磁盘使用情况,两者不要混淆

2018-10-22_215057.png

由于每做一个节点时虚拟磁盘会降级,重做完成后节点需要重新同步数据,平衡负载,因此请务必每次仅执行一个节点的升级操作,如果在一个节点加入群集后还未执行完毕Repair和Optimize作业就执行下一个节点,将会产生宕机的风险。


确认第一个节点执行完毕Repair和Optimize作业,虚拟磁盘操作状态恢复为OK就可以开始做下一个节点

2018-10-22_181546.png

暂停节点 - 逐出节点 - 节点退域 - 重做系统 - 修改注册表 - 加入群集 - 等待Repair作业和Optimize作业执行 - 检查群集虚拟磁盘状态 

第二个节点按照相同步骤执行,所谓滚动升级,意思就是我们每次只重装故障域允许的节点,确保重装之后,虚拟磁盘仅为降级,不会影响读写,节点重做完成加入群集后 虚拟磁盘又恢复为完整,再重做下一台,始终通过补上的方式阻止磁盘失去读写。操作步骤并不难,关键是要理解每一步背后所发生的事情,以及每一个操作执行后应该关注的内容。

按照这样的滚动思维做到最后一个节点时,最后一个节点执行完所有步骤,检查群集虚拟磁盘状态为OK,即代表所有节点已经不停机滚动升级至2019,但目前群集功能级别仍然是Windows Server 2016,升级群集功能级别后群集功能级别将为10,享受WSFC2019所有新功能,此操作不可逆

2018-10-23_131536.png

检查注册表位置可以发现MixedMode已经取消为0键值

2018-10-23_132013.png

除此之外,如果检查存储池可以看到,目前存储池的版本还是Windows Server 2016 

2018-10-23_124809.png

执行命令 Get-StoragePool -FriendlyName "PoolName" | Update-StoragePool 升级存储池为最新版本,此操作不可逆。

2018-10-23_131856.png

群集功能级别与存储池升级后,可以发现2019的新功能,和WAC集成实现的性能历史记录,通过在S2D创建一个10GB的磁盘以存放历史数据,此功能为S2D2019专有

2018-10-23_131934.png

最后如果是超融合架构,还需要升级虚拟机配置,此操作需关闭虚拟机才可以升级,需单独规划时间进行操作。

需要注意,升级群集功能级别,升级存储池,升级虚拟机配置,这三个操作都不可逆,一旦敲下命令就没有后悔药可以吃,如果举棋不定,可以在混合模式期间进行观察回退,升级群集功能级别之后就不能回退了。


升级过程最主要的是要理解执行每个操作步骤对S2D群集会发生的事情,做到思路清晰,心里有数,操作步骤并不繁琐,按部就班完成各节点升级,每一个步骤都不可以跳跃,每个节点升级完成都应该谨慎检查再下一个节点,按照顺序操作我们就能实现不停机的S2D滚动升级,最终完成操作系统升级,群集功能级别升级,存储池升级,虚拟机升级。

2018-10-24_122009.png