您好,登录后才能下订单哦!
很高兴和大家介绍另外一项WSFC2016的酷炫技术,即故障域功能
与之类似的技术有CloudStack,Openastack等
以CloudStack为例,在CloudStack中,针对于资源架构,我们可以手动来定义架构模型,从最上层Region,Zone,Pod,Cluster,再到最底层的Host,通过规划这样一套架构模型,我们可以在云管理软件上面定义出云资源池底层的架构,实现既能够对于用户屏蔽技术细节,也能够让云管理软件按照架构模型运转
其中最上层,最大的架构为 Region,也就是地域了,例如,我们在使用阿里云,Azure,AWS的时候创建虚拟机,都只需要选择一个区域就好了,对应到后台就是这个概念,Region的概念是地域,不同Region,则应该意味着不同地域,如果说用户把两台虚拟机部署在两个不同的Region,那么它们同时出现故障的几率会很低
其次是Zone,CloudStack中,Zone主要是指数据中心,我们说一个Zone,就是说一个数据中心,一个数据中心里面可能有多个Pod,即机架,不同机架可能使用不同的网络架构设施,一个机架上面有可能有多个Cluster,一个Cluster上面又可能有多个Host,同一个Zone内共用一个二级存储。
定义这样的架构后,对于用户来说,用户不需要知道太多,它们只需要知道,我们要部署到离我们访问地方比较近的Region,如果我的不同虚拟机放在不同Region,会被放置在不同的,很远的地方,不会同时发生故障,这样就够了
一些云平台例如Azure,可以让用户选择不同的可用性集,对应的概念,就是这里的机架,如果选择虚拟机在不同的可用性集,意味着虚拟机会被放置在不同的Pod,微软也叫做Rack,如果部署了可用性集后Azure才可以保证SLA在99.95%
一套云管理系统,对于资源管理员来说,管理员主要关注的是持续保证租户资源的SLA,置备多种高可用方案,灾备方案,等等,这里我们主要讨论的是高可用方案,在高可用方案里面,通常在云计算业内,人们会谈到故障域
什么是故障域呢,例如,我一个节点坏了,上面虚拟机可以漂到其它节点,这时候节点是一个故障域,单个节点故障了,我们部署了群集系统,会故障转移,并不会影响SLA
默认情况下大多数云管理平台的failover级别都是Cluster内的节点级别,理想情况下,老王认为,所有已定义的Region,zone,pod,Cluster都是应该可以感知的,例如,如果群集里面一个节点坏了,我可以把虚拟机先迁移到Cluster内其它节点,如果不行,再迁移到同Pod上面其它群集,如果不行再迁移到Zone里面的不同Pod,如果不行再迁移到不同Zone,甚至最后整个Zone瘫痪,还可以转移到其它Region恢复运行,如果真的可以做到这样就太强大了,真正实现了云计算持续可用的目的
不过在现实情况下,根据老王的观察,我们软件的定义的这些Region,zone,pod,Cluster,一部分是用来看的,一部分是用来用的,假设Region,zone,pod这些东西没有和云资源故障系统达成感应,那么是不会有老王上面说的效果的,可能最多就是,我们可以集中针对同一个Pod里面的Cluster或Host进行policy设置,可以让一个Zone中心里面的所有Pod,Cluster使用相同的共享二级存储,或者通过报告集中输出下报告之类的。
实务上通常一些云计算厂商会实现Region级别,Pod级别,Cluster级别的故障域感知,例如Cluster失效,会恢复到其它Region继续运行,或是Cluster维护,由Pod上面其它Cluster暂时负责服务。
这里老王说了这么多,是希望把故障域这样的一个概念带给大家,这个概念是相通的,不光在微软WSFC 2016会有,在Cloudstack,Openstack等其它云平台管理软件中也会有,老王认为这项功能在云平台管理,或者大型数据中心,大型托管数据中心里面会很常见,是项规范管理的好功能。
这项技术把它叫做软件定义故障域也好,故障域也好,举个例子
比如我们知道,租户的虚拟机在HV01节点,Cluster01上面运行,Cluster 01在Pod01上面,Pod01在Zone01,Zone01在Region北京运行,之前是在脑子里知道,现在我们可以通过软件定义在管理系统中
如果HV01节点Host级别坏了,由于Cluster自动实现主机级别故障域,节点会转移到其它节点上面运行,注意,只要是通过可以正常进行故障转移的系统构成的cluster,那么默认物理上就已经实现为了主机故障域
如果Cluster坏了呢,那么Cluster就是一个故障域,Cluster上面会有很多台虚拟机,也会随之跟着停机,如果没有置备跨Cluster的转移机制,这里就会产生宕机时间。
如果Pod级别坏了,那么Pod就是一个故障域,Pod上面会有很多Cluster,Cluster里面又会有很多应用,所有全部停机。
如果Zone级别坏了,那么整个Zone就是一个故障域
如果Region级别坏了,那么整个Region就是一个故障域
大家可以看出,越大的级别坏了,影响到的越多,所以对于架构人员来说,如果你作为一个云提供商或者大型托管数据中心提供商,那么首先您应该针对于每个故障域级别强化可靠性,尽量做好灾难恢复机制,什么级别的故障域出现故障,需要如何恢复处理,其次,应该想办法实现用户云资源的跨故障域转移,例如当前在Cluster运作,如果Cluster坏了,能否转移到其它Pod,或其它Zone继续运行,实现后建议用户在不同的可感应故障域上面部署资源。
故障域级别,通常这种东西,是管理员心里有数,或者写在合同上面的东西,我们通过一些云平台软件或管理软件,无非就是实现故障域,在电脑界面上面可见,可出集中管理,出报表,出架构视图
但是更重要的,我们是要实现故障域的感知,确保用户选择到不同故障域的相同资源不会同时出现故障,确保故障域发生可以跨故障域感知,让用户虚拟机正常情况在同Region下面的群集节点运行,如果同Region出现故障,可以直接让虚拟机跨Region迁移继续运行,因此故障域的定义大体会有以下功能
1.实现软件层面的故障域架构,便于记录查看,便于与物理架构对应
2.实现云管理策略按照故障域架构分配策略
2.实现故障域感知,确保用户选择到不同故障域的相同资源不会同时出现故障
3.实现跨故障域感知,在发生故障时能够让资源跨不同级别故障域进行转移
4.通过故障域功能,可以提高同一故障域内,存储,网络,计算资源的粘性性能,确保同一故障域内的存储和计算资源可以很快的工作。
要实现故障域,主要工作应该分为两步,1.逻辑定义 2.具体实现
逻辑定义,即是我们先定义出来,故障域数据,先在软件层面创建出来,让后把资源加进来,这样看起来我们有了故障域了,但其实只是看着好看,如果云平台支持,可以做一些报表或策略控制
具体实现,既真正实现故障域的功能,让用户不同作用域的资源不会同时宕机,让低级别故障域不可用,用户资源还可以跨故障域迁移到更高的级别,具体实现这个步骤呢,一部分我们可以依赖于技术手段,如果技术手段不到位,我们也可以依赖于手动,或者说,人脑把
定义了故障域不是说了几个字那么简单,管理员做维护的时候,是要心里有数的,例如,不能同一时间对所有故障域做维护吧,一定要先维护好一个故障域,再维护另外一个,如果技术手段不行,不能做到跨故障域级别故障转移,那么真的一个故障域级别坏了,管理员是需要手动把用户资源弄走再到另外故障域恢复的。
所以说故障域,不光是软件上面的定义和技术实现,更多的也是要求管理员维护的时候有故障域这样的一个思路,如果用户资源在不同故障域,我应该怎么维护,不同的故障域级别坏了,我应该关注那些内容,参照什么流程恢复,如何跨故障域级别恢复,等等,软件技术层面实现之后,更多的是维护流程
Ok,上面看了很多通用性的概念,下面我们就来看下微软WSFC 2016在故障域上面交出的答卷把
在WSFC 2016中微软针对于故障域,开通了个四个级别,分别是Site,Rack,Chassis,Node,其中Node是群集安装后默认就有,站点,机架,机箱,我们可以自行创建,自行构建它们之间的嵌套级别,并且针对于每个故障域级别都可以做详细的说明,便于查看,让我很感到惊喜的是WSFC 2016中的故障域并不只是说说而已,而是真的WSFC本身就可以帮助我们实现故障域感知的功能,目前老王观察看到 Site,Rack,Chassis这三种故障域级别都有各自生效的场景
例如,同一个Site上面的Node,默认情况会在Site内执行故障转移,如果Site所有群集节点不可用,再转移至不同Site,随之又有很多Site故障域级别的粘合性优化,可以配置群集级别的首选Site,应用级别的首选Site,同一个Site虚拟机会使用同一个Site的存储,如果存储移动到其它Site,则虚拟机也跟着移动,等等,本文后面我也将主要介绍WSFC 2016 Site级别的故障域感知。
还有一种场景,即Storage Direct Spaces,这项技术相信很多关注微软技术的朋友已经测过了,类似于VSAN,可以将每个节点肚子里面存储贡献出来形成一个存储池,再基于这个存储池构建存储空间,CSV,SOFS,最终交付给应用,在SDS的场景下,当我们写入数据给SDS存储空间,数据是会被撒在不同节点的,配置了双向镜像,三向镜像,双重校验的等容错技术后,数据会被撒多份,届时在容错技术容许的情况下,可以允许指定的节点数坏掉,然后新加节点恢复,或磁盘坏掉,新加磁盘恢复,所以,默认情况下SDS就已经有了磁盘级别故障域,节点级别故障域
我们也可以把SDS技术和WSFC 2016故障域新功能结合起来,在开启SDS功能前,我们针对于节点构建Rack或Chassis级别的故障域,届时SDS执行容错时,将按照拓扑进行操作,例如会保证数据始终洒在不同Rack或不同chassis节点上面,这样即便是一个Rack或一个chassis故障,也不会影响SDS,注意,如果希望实现这项功能,建议最好在SDS开启之前就规划好故障域级别,否则SDS建好之后在规划,需要重新移除节点,再加入到故障域。
WSFC 2016故障域群集配置命令:
Get-ClusterFaultDomain:获取群集故障域架构,可以从群集级别,或任意故障域级别
Set-ClusterFaultDomain:移动资源所属故障域,配置故障域相关参数
New-ClusterFaultDomain:创建群集故障域,可以选择Site,Rack,Chassis级别的故障域
Remove-ClusterFaultDomain:删除故障域
实验示例:
#创建北京站点和上海站点
New-ClusterFaultDomain -Type Site -Name "Beijing" -Description "Primary Site"
New-ClusterFaultDomain -Type Site -Name "Shanghai" -Description "Secondary Site"
#创建北京站点数据中心Rack和上海站点数据中心Rack
New-ClusterFaultDomain -Type Rack -Name "Rack Beijing1" -Location "Fumadasha 17, Room 501"
New-ClusterFaultDomain -Type Rack -Name "Rack Shanghai1" -Location "TaiDidash 14, Room 203"
#创建北京Rack上面的两个机箱,上海Rack上面的两个机箱
New-ClusterFaultDomain -Type Chassis -Name "Chassis 01"-Location "Rack Beijing01 Ontop"
New-ClusterFaultDomain -Type Chassis -Name "Chassis 02"-Location "Rack Beijing01 Under"
New-ClusterFaultDomain -Type Chassis -Name "Chassis 03"-Location "Rack Shanghai01 Ontop"
New-ClusterFaultDomain -Type Chassis -Name "Chassis 04"-Location "Rack Shanghai01 Under"
需要注意,这里每个故障域Name都将是唯一的
#添加服务器进入机箱
Set-ClusterFaultDomain -Name "HV01" -Parent "Chassis 01"
Set-ClusterFaultDomain -Name "HV02" -Parent "Chassis 02"
Set-ClusterFaultDomain -Name "HV03" -Parent "Chassis 03"
Set-ClusterFaultDomain -Name "HV04" -Parent "Chassis 04"
#构建机箱机架站点依赖关系
Set-ClusterFaultDomain -Name "Chassis 01" -Parent "Rack Beijing1"
Set-ClusterFaultDomain -Name "Chassis 02" -Parent "Rack Beijing1"
Set-ClusterFaultDomain -Name "Chassis 03" -Parent "Rack Shanghai1"
Set-ClusterFaultDomain -Name "Chassis 04" -Parent "Rack Shanghai1"
Set-ClusterFaultDomain -Name "Rack Beijing1" -Parent "Beijing"
Set-ClusterFaultDomain -Name "Rack Shanghai1" -Parent "Shanghai"
#获取故障域拓扑
Get-ClusterFaultDomain
#获取故障域完整信息
Get-ClusterFaultDomain | ft name,type,parentname,childrennames,Location,description -autosize
还可以把,在这里大家可以看到,老王之前定义的所有故障域,以及嵌套关系,还有位置信息和说明信息,这两个也是新属性,主要用于对故障域做标注使用,便于排错或者查找,可以看到,从城市级别,到数据中心大厦级别,到屋子级别,机架级别,甚至定义到机架上面机箱的位置。您也可以在站点Location的位置输入城市+数据中心信息,Location和description信息也可以后期Set去改,这里有很多种玩法,大家可以自己去发掘,关键是准确,有意义,明了即可。
#获取单一故障域拓扑
#获取某一级别故障域拓扑
#删除故障域
如果要删除一个故障域,要求下面没有子资源,例如我们要删除Chassis 01,但是下面有HV01节点,我们就需要先移除HV01出去
#移除要被删除故障域下面资源
Set-ClusterFaultDomain -Name "HV01" -Parent ""
#删除故障域
除了可以使用Poweshell配置群集故障域,还可以导出xml进行配置,编辑完成后再导入xml
#导出故障域架构xml
Get-ClusterFaultDomain | Out-File <Path>
使用工具完成XML后,需要使用以下命令再把XML上传回去生效
$xml = Get-Content <Path> | Out-String
Set-ClusterFaultDomainXML -XML $xml
以上,老王简单为大家介绍了下WSFC2016中新增的故障域功能,以及配置办法,但是到目前为止我们只是逻辑创建出了故障域,可以看到,可以和物理对应,但是有没有生效呢,还没有,因为故障域的生效,取决于云管理平台,或WSFC能感应到什么程度
在常规设计中,故障域通常是在云平台管理系统中定义的,故障域会运作在云基础架构的整体架构上,而WSFC则是反其道而行之,在群集的级别上面定义Site,Rack,Chassis,这样不论是Site,Rack,Chassis都需要在群集的框架内运行,这也是微软的架构和其它厂商不同之处。
其中老王认为,对于故障域站点感知,WSFC做的还算不错,我们定义了站点故障域,把节点放入站点故障域下面后能够实现
站点感知:设置好了站点后,我们可以让群集节点每次故障转移或维护模式,都先在站点内进行角色转移,如果本站点无正常节点可转移,再转移至其它站点,在以前的版本中是没有这项技术的,以前版本中如果我们希望实现类似的需求,是通过设置应用的首选所有者来实现,2016则把站点感知带到群集中
存储站点感知:群集中的虚拟机,将会follow同站点内的CSV,假设CSV迁移到其它站点,一分钟后,虚拟机发现,CSV迁移到其它站点,那么虚拟机也会实时迁移过去,配置站点感知后,会确认首选站点始终直接访问存储,如果存储移动,则虚拟机也跟随移动。
群集组站点感知:我们也可以配置应用的站点感知,例如设置SQL实例1的首选站点为beijing,SQL实例2的首选站点为shanghai,这样可以实现一种多主运行应用的场景,让SQL1故障转移首先在beijing站点内,SQL2故障转移首先在shanghai站点内。
首选站点:配置了站点感知之后,我们首先要选择出首选站点,首选站点可以确保,当群集出现50/50投票时,动态仲裁始终去掉非首选站点的投票,让首选站点运作,没错,这替代LowerQuorumPriorityNodeID,在群集冷启动时,虚拟机也会优先在首选站点启动
它们的优先级顺序如下
存储站点感知>群集组站点感知>首选站点感知
除了这些信息外,站点感知功能随之增加了新的跨站点心跳检测机制,我们将在下一篇博客中进行介绍
OK,下面开始实验验证
清空所有故障域配置
实验环境
群集当前基于CSV跑了一台虚拟机,两个dtc,都运作在北京站点HV01
故障域配置如下
实现验证站点感知,在未配置首选所有者情况下,三个群集应用运作于HV01,归属于同一站点故障域beijing
手动停止节点HV01群集服务,应用自动首先迁移至同站点内HV02
打开clusterlog查看
这里我们虽然成功了,但是也有一定几率的情况下,我们达不到这样的效果,在2016中,当我们构建了站点故障域后,群集再次进行故障转移时,传统群集角色会直接在本站点内向尝试进行故障转移,而基于CSV的虚拟机则并不一定,原因是CSV是可以漂移的,可能现在CSV主控制点在HV04,但是虚拟机在HV01,这也是可以跑的
如果CSV的主控节点和虚拟机就在同一个节点,那么当节点宕机时,有可能CSV会去其它站点,假设CSV去了其它站点的节点,那么虚拟机也会跟着follow过去
如果CSV的主控节点和HV01不在一个Site,那么当HV01故障转移时,虚拟机会follow CSV所在的site,CSV在哪,虚拟机就去哪,确保虚拟机可以获得最好的性能,而忽略站点内感知的功能,因此存储感知的优先级也最高
如果虚拟机当前是开机状态,则每个一分钟会检测,我和CSV是否在同一个Site,如果不在同一个Site,我要实时迁移过去,如果虚拟机时关机状态则不会检测,但是故障转移或维护时,会先去找CSV所在站点,在群集日志中可以看到
接下来就要进入另外的一项技术,即首选站点功能,首选站点配置级别,可以是在群集级别,存储级别,群集组级别,这里我们首先要配置的就是存储级别,我们手动来规定确保CSV和站点的粘性,例如CSV01 始终follow 北京站点,CSV02始终follow上海站点
这样北京站点的虚拟机始终就找北京站点的CSV01,CSV01也始终会在北京站点,虚拟机故障转移或维护也始终会先在北京站点,因为CSV已经被固定,如果CSV出现维护操作或失败操作也可以第一时间回到北京站点,配置在同一个站点的CSV会在节点内执行负载分布
#获取CSV的群集组名称
Get-ClusterSharedVolume | Get-ClusterGroup
CSV也是群集组 Really?
#基于获取到的CSV群集组名称,配置到首选站点
(Get-ClusterGroup -name CSVClusterGroupName).PreferredSite =“beijing”
OK,现在我们就可以放心了,虚拟机会始终follow CSV,CSV也始终follow 本地站点,这样确保了虚拟机发生故障,在本地站点有可用节点,一定会先迁移到本地站点。
下面我们再配置群集级别的首选站点,配置群集级别首选站点的目的无非是发生50 50分时让群集始终确保首选站点可以获胜。
#查看群集当前节点投票与见证投票
直接禁用仲裁磁盘,模拟群集仲裁失效,50 50分成情况下,动态仲裁自动选择一个节点去掉投票数
可以看到默认情况下,群集自动去掉了上海站点的投票
我们如果手动指定首选站点,例如,我们手动指定上海为首选站点,那么当下次再发生五五分成的时候,动态仲裁将始终去掉北京站点节点的投票
ClusterLog
存储见证在的时候完整投票数
见证失效的临时投票数,随后立刻会被动态仲裁随机去掉投票
默认下动态仲裁去掉HV03投票
手动修改后去掉HV01投票
以上为首选站点在群集级别配置后的效果之一,看起来2012R2 LowerQuorumPriorityNodeID并没太大差别
#配置群集级别首选站点回到北京
(Get-Cluster).PreferredSite = Beijing
看过了存储级别的站点感知,以及首选站点替代LowerQuorumPriorityNodeID的新功能,最后我们来看下主菜,即应用程序的多主站点感知
在看应用程序多主站点感知,老王还是想为大家看下群集级别站点感知的效果,当前我们已经配置了存储站点感知,因此可以发挥出完整的效果
时间节点1
所有应用和虚拟机运行于北京站点HV01
手动停止HV01群集服务,CSV迁移同站点其它节点,所有角色迁移同站点内其它节点
再次停止HV02群集服务,失去整个Beijing站点,所有应用跨站点故障域迁移到Shanghai
至此就是故障域站点感知的效果了,对于了解故障域概念,但是不了解微软WSFC的人来说,这可能很炫,应用感知到故障域,并且优先在故障域内转移,同一站点故障域内虚拟机可以获得存储最好的性能,如果同级别站点故障域不可用,可以跨故障域转移至新故障域站点继续运行,看起来很不错,但是内行看门道,其实呢,只不过是包上来一层新的概念,我们通过原来的首选所有者技术也可以实现类似的效果,只不过通过新的方式配置,看起来更加专业些,便于故障域概念的落地。
相对于站点感知功能,老王更看重的是另一大块,即首选站点感知,首先站点感知里面包括群集级别,存储级别,群集组级别,其中老王更看重存储级别的首选站点感知,可以和站点感知功能融合,确保同站点内虚拟机始终访问同站点的存储,让CSV存储和虚拟机始终在同一个站点,同站点始终获取最好的性能,这是以前版本没有的
梳理下WSFC 2016针对于故障域新增的新功能
1.故障域定义:全新,支持站点感知,SDS感知
2.站点感知:代替首选所有者
3.首选站点感知:替代LowerQuorumPriorityNodeID
4.应用多主首选站点感知:代替首选所有者
5.CSV存储首选站点感知:存储follow站点,VMfollow存储
6.新增跨站点心跳检测参数
故障域和站点感知支持WSFC传统同域部署,工作组部署与同林多域部署
作为微软本地端产品首次尝试引入故障域属性,老王认为微软做的已经还可以,期望未来可以不断完善,在老王看来,故障域其实可以更上一个级别,例如我们可以在SCVMM的级别定义故障域,从站点,数据中心,机架,机箱,群集,Host,这样从上向下做的话也许会更好,因为现阶段从下向上定义,毕竟群集的规模受限,如果是在VMM级别,则我们不必受限于单个群集的规模,甚至可以针对站点,或机架,机箱,数据中心,配置不同的故障转移策略,网络策略,存储策略,那样就更好了,希望这项功能能够得到不断的完善,越来越多的本地端产品,或群集上层应用可以更好的和故障域协同。
最后,应用多主首选站点感知,我们可以配置在群集组的级别,配置不同的群集组选择不同的首选站点,这样不同的群集组就都会在各自的首选站点中先执行故障转移,如果首选站点无可用节点,再转移至其它站点,这样在一定程度上,可以减少跨站点转移的成本,确保每个站点的资源都得到合理的利用,不会本站点还有节点就转移到跨站点,一定程度上可以减少宕机时间,提高应用运行的时间。
#配置多主站点感知
对于devtestdtc首选站点为beijing
对于MikeWang首选站点为beijing
(Get-ClusterGroup -Name devtestdtc).PreferredSite = Beijing
(Get-ClusterGroup -Name MikeWang).PreferredSite = Beijing
对于devtest1dtc首选站点为shanghai
(Get-ClusterGroup -Name devtestdtc1).PreferredSite = Shanghai
当前devtestdtc Mikewang在HV01运行,devtestdtc1在HV04运行
停机HV01,devtestdtc Mikewang转移至北京同站点HV02
停机HV04,devtestdtc转移至上海同站点HV03
针对于站点感知或应用多主首选站点感知,建议配置应用的故障回复属性,这样当检测到首选站点,或本地站点可用时,会回到原来站点运行
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。