WSFC2016 故障域站点感知

很高兴和大家介绍另外一项WSFC2016的酷炫技术,即故障域功能

与之类似的技术有CloudStack,Openastack等

以CloudStack为例,在ClusterStack中,针对于资源架构,我们可以手动来定义架构模型,从最上层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.新增跨站点心跳检测参数

作为微软本地端产品首次尝试引入故障域属性,老王认为微软做的已经还可以,期望未来可以不断完善,在老王看来,故障域其实可以更上一个级别,例如我们可以在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

针对于站点感知或应用多主首选站点感知,建议配置应用的故障回复属性,这样当检测到首选站点,或本地站点可用时,会回到原来站点运行

时间: 09-09

WSFC2016 故障域站点感知的相关文章

WSFC2016 站点感知与健康服务

之前老王曾经写过一篇文章简单探讨过WSFC 2016的故障域以及站点感知功能,但是随着继续深入的应用和使用,老王发现站点感知这个概念在WSFC 2016体系里面贯穿到了很多功能,因此决定再写一篇,主要与大家探讨在ReallyWorld中应该如何思考站点感知,故障域,以及WSFC 2016健康服务功能 # 1. 初谈WSFC 2016故障域 故障域通常来说,只有当我们作为交付SLA,或享用SLA的时候会听到这个概念,例如,当我们购买了某云厂商的云服务,它们会保证很多个9,但前提是我们要把云服务里面

lduan server 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),即一个域账号,用于支持群集

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来说,延伸群集是超融合存储节点的一种扩展,将原有的机房内机架,扩展

学习总结-Active Directory 域服务管理06-站点和复制

站点和复制 一.应用场景 1.1)添加多台域控制器后,域管理员对domain分区读和写的权限,对用户做变更操作的结果会不一致,"复制"的机制能够同步域控制器之间的domain分区数据 1.2)多个分支机构的情况下,每个分支机构都有域控制器,让分支机构的用户优先找分支机构的域控制器,"站点"是一种高速的链接网络,根据子网来划分 二.组件 kcc,复制链接优化 三.配置 以子网划分站点,不同站点间的域控制器处在不同的位置,如DC04的是192.168.32.0网段,属于

Win Server 2008 R2主域控灾难恢复

好久没写东西了,前几天遇到一个企业,因为主域控在没有任何保护的情况下,裸奔后感染病毒,直接垮掉了(无语),且无法恢复.希望能够对其进行完整功能的灾难恢复,今天就跟大家分享一下恢复的过程. 整个过程不难,但是大家在做这种操作的时候,思路一定要清晰,且操作的时候一定要仔细. 具体思路步骤:(可能不完善,欢迎大家补充) 1. 彻底检查主域控SRVDC01状态,这里主要包括是否彻底无法启动 or 只是功能故障 2. 如果主域控还能勉强单机登录的话,备份一切可以备份的有用文件资料或者应用配置,如CA证书服

java 跨域

跨域请求,顾名思义,就是一个站点中的资源去访问另外一个不同域名站点上的资源. 资源可以是一个请求,或一个操作或一个数据流等 出于安全的考虑,如果你要从www.a.com通过Ajax来请求另外一个网站www.b.com的内容,浏览器是不允许你这样做的(不理解这里的安全是指什么?想想如果没有这个限制的话,黑客可以做些什么).那什么样的情况下算是跨域?域名不同那当然算是跨域了,例如a.com向b.com发送请求,这当然就是跨域了,不允许的.不过子域名不同(例如sub.a.com向www.a.com 发