WSFC2016 VM弹性与存储容错

很高兴今天给大家介绍微软2016群集的VM弹性和存储容错技术,在老王看来,WSFC 2016里面针对于群集运作,VM弹性是一项很重要的改变,和滚动升级一样,是一种颠覆式的思维。

简单来说,在大家的认知里,群集就是应该当检测到节点不可用之后,快速进行failover,把应用继续转移到其它节点上运行,对吧,相信大家都认同这一点。

2012R2里面默认相同子网和跨子网都是每隔一秒全网检测一次,五次检测失效,即判定该节点不可用,RCM开始根据群集数据库内容,故障转移角色到其它节点运作,检测时间和检测失败次数操作,可以改,如果您的环境存在网络不稳定的情况,严格的监测会导致节点频繁故障转移,您也改成松散一些的1秒检测一次,20次检测失败,再执行故障转移

但是这个阀值不易修改太久,原因,一个是因为这个值是针对整个群集级别,如果群集上面有很多应用则所有应用都将受到这个影响,其二是如果检测次数时间过长,会导致宕机时间很久才被发现,因此2012R2及之前,微软建议,最长设置为20次检测失败就故障转移,不建议超过这个数值

但归根到底,我们修改监测阀值,还是为了解决网络不稳定的问题,以及用户特定的需求,例如,如果客户网络不稳定,检测会存在瞬时中断,而且也没办法更改,那么就可以把监测阀值设置宽松一些,如果客户环境网络很稳定,需要很严格的检测来保证SLA,也可以把检测阀值设置严格一些。

这是2012R2时代的解决方案,到了2016,微软认为,真正的故障转移情况已经并不多见,反而是瞬时故障的情况更常见,例如节点短暂无法进行网络通信,或短暂无法和存储连接,之后又立刻恢复了,因此微软重新设计了群集中VM故障转移策略,能够让一定时间内的节点瞬时故障,不必再触发节点虚拟机的故障转移。

在WSFC 2016中,VM弹性功能默认被启用,在2016 TP1中这项功能默认被禁用,随后的版本都默认启用,运行Get-Cluster |fl * 可以看到和VM弹性相关的配置

参数说明

ResiliencyLevel : IsolateOnSpecialHeartbeat或1,AlwaysIsolate或2,默认为AlwaysIsolate,即在发生节点瞬时中断后,在一段时间内可以允许虚拟机在线或暂停状态,IsolateOnSpecialHeartbeat即当检测到瞬时中断后,立刻置节点为失败状态,执行failover

之前我们说过2016里面重构了VM故障转移策略

到底是怎么重构的呢

在WSFC 2016里面,假设你发生了瞬时中断,例如

  1. 网络短暂不稳定,节点无法和其它节点通讯
  2. 群集服务崩溃,无法与其他节点连接
  3. 管理员误操作

当发生例如这种瞬时中断,群集现在新增了三个属性

  1. 隔离:针对于群集节点,在规定时间内,群集节点发生瞬时中断后,状态会被标记为隔离,该成员不会再是合格的群集成员,但上面托管的虚拟机,在一定时间内依然可以正常运行
  2. 未监视:针对于群集管理器中看虚拟机状态,如果当节点发生瞬时中断,变成隔离状态后,在群集里面看虚拟机,虚拟机会是未监视状态

如果虚拟机存储在SMB3/SOFS路径下,节点隔离状态后虚拟机可以使用Online状态运行,因为SMB可独立运行,如果虚拟机存储在FC/FCoE/iSCSI/ShareSAS等块存储构成的CSV路径下,那么虚拟机会被置为暂停状态,因为节点被隔离后,不是合格的群集成员,也将失去CSV的访问资格,如果节点恢复正常,虚拟机会从暂停状态中恢复正常运行,如果节点的瞬时中断一段时间内未恢复,虚拟机将会被failover到其它节点运作。

3. 检疫持续:我们会设定一个时间,在这个时间内,节点如果发生瞬时中断后又恢复了,虚拟机不会被迁移,只是继续运行,但如果节点在一小时内,被隔离达到一定次数,多次发生瞬时中断,则我们判定该节点当前不正常,该节点可能会导致应用不稳定,因此我们会把该节点置为检疫状态,置为检疫状态的节点,在一段时间内该节点将处于检疫状态,上面所有的虚拟机会被实时迁移走,直到我们分析判断该节点恢复正常后,再重新加入群集。

ResiliencyPeriod:配置节点在隔离状态下运作的时间,默认为240秒,即240秒内的瞬时中断,可以被接受,不需要发生故障转移,如果超过240秒仍未恢复,则按照群集检测走,执行故障转移操作。

#配置隔离状态时间

(Get-Cluster).ResiliencyDefaultPeriod = 60

#关闭隔离状态功能

(Get-Cluster).ResiliencyDefaultPeriod =0

#配置单个虚拟机级别隔离状态时间(即未监视状态时间)

(Get-ClusterGroup“stat”).ResiliencyPeriod =  60

QuarantineThreshold:节点进入检疫状态前的隔离次数,默认为3,即节点一小时内被置为3次隔离状态后,则节点进入检疫状态,所有虚拟机会被实时迁移走

#配置进入检疫状态前的隔离次数

(Get-Cluster).QuarantineThreshold =<value>

QuarantineDuration:节点处在检疫状态下的时间,默认为7200秒,在这段时间,节点将不承载应用,所有虚拟机被实时迁移走,管理员可以排查频繁导致瞬时终端的问题,如果修复好了后可以手动让节点提前恢复,或等到7200秒自动恢复。

#配置检疫状态时间

(Get-Cluster).QuarantineDuration = <value>

这项技术说太多可能会觉得枯燥,下面我们实际来看一下案例

当前环境里面四台虚拟机,其中RODC运作在SOFS路径,其它三台虚拟机运作在通过ISCSI提供的CSV路径下,我设置节点隔离状态时间为60秒,检疫状态时间为600秒,这里老王只是为了测试快点看到结果,真实环境下建议根据实际时间评估,多长时间内可以算作瞬时中断,频繁发生瞬时中断我需要多长时间进行排查问题节点。

WSFC 2016中要实现VM弹性的功能要求

  1. 群集功能级别为9
  2. 虚拟机配置级别升级至少6x以上

在老王的实验中,我将模拟一个群集服务短暂崩溃的场景,模拟群集服务强制停止后,观察群集的反应

当前群集四台虚拟机都承载在HV01

我们通过强制停止节点上面的clussvc进程来模拟群集服务崩溃

Stop-process -name clussvc -Force

可以看到,群集服务崩溃后,节点会被置为隔离状态

所有虚拟机在群集里面看会是未被监视状态,这只是个群集管理器中看到的临时状态

但其实在Hyper-V可以看到,实质上,存放在SOFS的RODC在60秒内会持续运行,运行在CSV上的其他虚拟机,虽然显示 正在运行-关键,这个中文显示是错的,英文上面显示为Paused-Critical,实质上它们是因为节点被隔离,失去到CSV的资格,而被置为暂停状态。

如果60秒内,节点又恢复正常了,瞬时中断恢复,网络恢复正常,服务不再崩溃,管理员恢复了误操作,则节点重新加入回到正常状态,已被暂停的虚拟机会重新开始运行,本例中我们强制终止clussvc进程后,稍后会自动启动起来

如果60秒内,瞬时中断,或是群集服务崩溃,或是网络临时中断,或是管理员误操作,没有得到修复,则节点会被置为Down状态,所有被置为未被监视状态的虚拟机会被迁移到其它活着的节点上,迁移过程是快速迁移,针对暂停的虚拟机会置为关机状态再迁移走。

下面我们模拟1小时内3次隔离的情况发生,即同一节点三小时内发生瞬时中断

可以看到,在节点的地方查看发现已经从红隔离变成了绿隔离,但其实这个绿色的已隔离和上面红色的已隔离已经不是同一个意思,一个是Isolate,一个是Quarantine,进入绿隔离状态其实应该是我们说的检疫状态,即根据我们定义的算法,群集已经可以判断这个节点不正常了,它生病了,不应该再继续承载虚拟机,因此上面所有的虚拟机都会被实时迁移至其它节点,并在QuarantineDuration时间内,节点都将处于检疫状态,这时候管理员可以对节点进行错误诊断,确认频繁发生瞬时中断,是否意味着有真实的问题存在需要处理,

如果600秒时间到了,则群集认为您已经解决了该问题,自动解除检疫状态,放节点正常加入群集,如果您不想等待这个时间,或者您在已经提前解决了频繁瞬时中断的问题,那么您也可以运行命令 Start-ClusterNode -CQ 执行ClearQuarantine操作,把节点手动恢复正常

相信通过以上实验大家对于VM弹性功能已经有了一定了解了

有了这项技术后,我们可以让群集保持以前的样子,根据检测信号完成快速的故障转移,也可以根据通过VM弹性技术,设置在一定瞬时中断时间内,接受短暂的中断又恢复,不需要立刻执行故障转移,可以分别把主机在瞬时中断下做隔离处理,甚至进一步检疫处理,相对来说更加正规一些,也比原来我们调整检测信号的方式来的效果更好,因此如果大家环境中有瞬时中断的情况,不妨了解使用下这项功能。

如果不想要VM弹性功能,还想恢复以前基于信号检测直接做故障转移的运作方式

设置VM弹性值如下,则回到从前,需要注意,在2016TP2之后的版本,这项功能默认被启用,因此当发生网络中断,服务崩溃如果发现应用没快速故障转移,不要惊慌,那么是因为群集自动开启了VM弹性功能,不想要它,直接这样disable掉即可

关闭VM弹性后,再次强制停止clussvc进程,发现节点直接进入故障状态,执行故障转移

以上为VM弹性功能,可以帮助我们解决节点级别的网络,系统,误操作等瞬时故障,除了计算级别可以有这种弹性功能,2016还在虚拟机存储中也添加了这项技术,主要针对于虚拟机访问VHDX,在2012R2中,如果虚拟机忽然访问不到VHDX,虚拟机肯定会崩溃无法使用,当存储再次可用,我们可能也需要重新打开虚拟机。

在WSFC 2016中群集虚拟机可以和存储实现更好的容错功能,非常的神奇,我们可以设置一个允许中断时间,在这段时间内,如果群集虚拟机到存储之间发生了瞬时故障,无法访问VHDX了,可以把虚拟机置为暂停关键状态,虚拟机将被冻结,状态得到保存,所有虚拟机的IO也都会被冻结

当VHDX恢复访问后,虚拟机从暂停状态回到正常运行,状态释放,所有IO得到正常运转,通过这样内置的存储容错功能,可以帮助我们在存储短暂连接失效的时候提供一种很好的方案,当存储再次可用时,虚拟机自动load io,对于用户来说,停机时间得到改善。

当前除了RODC虚拟机,其它虚拟机都是直接连接到的CSV,我们直接在ISCSI上面禁用掉16群集用的数据磁盘,这样CSV也就是失败,节点到存储失败,VHDX也再也不可读取

可以看到虚拟机又被置为正在运行-关键,但其实这个状态应该是Paused-Critical

那么这个冻结虚拟机IO的时间是有限的,默认是30分钟,不可以太长,不可以是无限期的,在一段时间内,如果虚拟机仍然无法连接到VHDX,则VM将会关闭,下次启动将是冷启动

30分钟之内如果虚拟机恢复到存储的连接,则继续运作,虚拟机被置为正在运行,继续保留之前的工作状态,所有操作和IO正常运转,如果这个到存储的故障很短,那么对于用户来说是感受不到的,一旦存储连接上后,虚拟机会很快恢复运转,SOFS虚拟机最快,其次是CSV虚拟机,开挂的ShareVHDX虚拟机会直接执行实时迁移。

#配置虚拟机存储容错,HV级别配置虚拟机

开启虚拟机容错功能

Set-VM -AutomaticCriticalErrorAction  <None | Pause>

默认为Pause,即存储无法连接时暂停,改成None则回到以前状态,如果要修改需关闭虚拟机!

配置虚拟机存储无法连接等待时间 默认30分钟

Set-VM –AutomaticCriticalErrorActionTimeout <value in minutes>

针对于ShareVhdx虚拟机在Hyper-V 2016会每隔十分钟轮询一次,存储是否可用,如果不可用则自动实时迁移到其它节点上。

VM存储容错功能,仅支持基于CSV的VHD,VHDX检测,或sharevhdx,sofs

不支持为群集化的本地VHD VHDX

不支持使用直通磁盘,或USB存储的虚拟机

以上,老王为大家介绍了VM弹性和存储容错的功能,关注这项技术很久了,一直很想把这项技术介绍给国内的朋友,这次终于写好了,希望能够为看到的朋友带来收获,如果您的环境中存在节点,网络,存储的瞬时故障,现在您可以通过2016中的VM弹性技术进行控制,尤其是针对于存储的神奇容错功能。

时间: 2024-08-27 13:10:28

WSFC2016 VM弹性与存储容错的相关文章

WSFC2016 VM顺序组与管理组

在我们管理虚拟化场景或群集应用场景时,可能经常会经常碰见一个需求,即依赖性顺序,开发人员可能会需要保证一系列联合工作虚拟机或群集应用的启动顺序,确保最底层需要的资源启动后,再按照顺序陆续启动其它资源. 针对于依赖性启动的需求,如果是在没有群集的单机Hyper-V场景下,我们可以通过设置虚拟机的自动启动属性来解决此问题,例如,一套sharepoint环境,有DC,DB,AP,WEB,我们可以依次设置各虚拟机自动启动的延迟时间,0,30,50,80.这样做了之后,在单机情况下,当宿主机重新启动,可以

WSFC2016 VM负载均衡

在2012时代中,智能放置功能得到了更新,当我们执行手动移动至最佳节点,故障转移,维护模式时,默认如果没有任何设置,例如首选所有者,可能所有者,反相关性等,群集先会根据内存智能放置功能,尽可能帮我们选择当前承载群集应用少的,可用内存多的节点上进行放置. 但是这只是项群集增强性的功能,只能说是作为一个最基本的放置策略来使用,帮我们选择相对轻松的节点,但是群集主要关注的点还是强调故障转移,维护后让应用尽可能快速的上线,它只是在放置初始根据群集应用数量和内存做下基本的判断,随后应用会被快速联机上线.

微软WSFC全方位解析

Windows Server Failover Clustering是微软重要的Windows Server功能,它为微软众多企业级平台提供底层高可用机制,掌握WSFC的概念原理,功能使用,故障排错将对管理员运维有很大帮助,本系列文章将从WSFC的概念介绍,功能使用,故障排错,性能优化,WSFC 2016新功能解析等多个层面来为大家介绍WSFC,一层层揭开它的神秘面纱,让更多朋友知道它,使用它 WSFC概念与管理操作知识补遗21篇: 浅谈群集与分布式基础知识 http://blog.51cto.

WSFC2016 工作组部署模型

今天老王来和大家聊聊WSFC 2016里面的工作组部署模型,正如老王刚开始在WSFC 2016系列开篇所讲,对于WSFC 2016 我们会从维护管理,排错优化,部署迁移几个点分别讲起,基本上我们对于WSFC 2016维护管理的新功能已经讲的差不多,优化和部署还有几篇未完 在讲到工作组部署模型之前呢,我们首先来看看历史问题,为什么要有工作组部署模型 早起在2003时代,如果我们要建立一个群集,每个群集都需要使用一个CSA(Cluster Service Account),即一个域账号,用于支持群集

Windows Azure Virtual Machine (24) 使用高级存储和DS系列VM

<Windows Azure Platform 系列文章目录> 本文介绍的是国内由世纪互联运维的Azure China 熟悉Azure平台的读者都了解,Azure VM每一块Disk的IOPS为500.我们以D系列的VM为例,IOPS信息如下: 虚拟机类型 CPU RAM 临时磁盘 外挂磁盘数 IOPS D1 1 3.5GB 50GB 2 2 * 500 D2 2 7GB 100GB 4 4 * 500 D3 4 14GB 200GB 8 8 * 500 D4 8 28GB 400GB 16

WSFC2016 On Azure

本篇文章,老王将为大家介绍WSFC在Azure上面跑的一些执行操作,以及操作过程中需要注意的地方 之所以要写这篇文章有几个原因 1.为大家破除群集能否在公有云平台跑的迷思 2.为大家带来群集在公有云平台跑的思考 3.为大家介绍WSFC 2016 借助于Azure实现的云S2D,云仲裁 首先,WSFC群集能不能在公有云平台跑呢,答案是可以的,理论上来说,只要可以满足建立群集的要求,我们可以在私有云,公有云,混合云任何一个平台上面部署群集 思考一下,当我们建置一个群集时有哪些最基本的先决条件要准备

WSFC2016 跨站点运行状况检测

之前在WSFC基础知识奠基篇曾经为大家介绍过微软WSFC故障转移的过程,我们来重温一下 1.按照要求部署配置群集节点,确保群集服务器利用了冗余技术消除了服务器,网络,存储的单一故障点 2.保证群集内所有节点都可以访问到共享存储 3.群集应用将应用数据写入到群集共享存储 4.管理员新增节点1服务器上面功能角色,新增完成后节点1服务器群集数据库记录新增的角色功能以及相关联的信息,稍后会把信息同步至其它节点2,及群集仲裁磁盘 5.群集节点之间按照预定的心跳检测频率进行全网握手检测 6.节点1出现故障服

WSFC2016 延伸群集

延伸群集是Windows Server 2016存储复制的主要应用场景,通过把存储复制与WSFC的结合,实现跨站点群集存储的复制,帮助企业更好的实现较低RTO RPO的跨站点灾难恢复,确保当站点发生故障转移时不会因为存储而导致转移失败. 事实上微软并不是首先提出延伸群集这个概念的,早在前些年VMare VSAN,IBM SVC就已经提出了这个概念,对于延伸群集这个概念每个厂商都有各自的实践理解 以VSAN延伸群集为例,对于VSAN来说,延伸群集是超融合存储节点的一种扩展,将原有的机房内机架,扩展

6分钟彻底掌握存储和备份区别

摘要:如果不是专业的技术专家,很难搞清楚存储和备份这两者之间区别,特别是云的出现,这两个概念往往容易混在一起,本文将从专业角度详细对比存储和备份两者之间的区别和发展趋势. 一直以来,存储和备份是两个相近的概念,但是又有很大区别的.如果不是专业的技术专家,是比较难搞清楚这两者之间区别,特别是云的出现,这两个概念往往容易混在一起看.本文从几个方面快速对比下存储和备份这两个概念的区别和发展,以及演变趋势. 1. 备份是不能独立数据容器存在,永远构建于存储之上 存储是数据保存容器的统称,比如软盘,光盘,