在我们管理虚拟化场景或群集应用场景时，可能经常会经常碰见一个需求，即依赖性顺序，开发人员可能会需要保证一系列联合工作虚拟机或群集应用的启动顺序，确保最底层需要的资源启动后，再按照顺序陆续启动其它资源。
针对于依赖性启动的需求，如果是在没有群集的单机Hyper-V场景下，我们可以通过设置虚拟机的自动启动属性来解决此问题，例如，一套sharepoint环境，有DC,DB,AP,WEB，我们可以依次设置各虚拟机自动启动的延迟时间，0,30,50,80。这样做了之后，在单机情况下，当宿主机重新启动，可以按照延迟顺序逐步启动虚拟机以达到依赖性启动的需求，但这项设置仅限单机使用，当我们将虚拟机移动至其它节点，则自动启动延迟设置失效，需要每次重新设置
虚拟机迁移至其它节点后设置失效
WSFC2012时代优化了群集优先级功能，我们在2012时代，通过群集优先级也可以完成控制群集应用的依赖性启动，针对于群集优先级老王在日常管理操作篇博客做了详细介绍，大家感兴趣可以去看，在群集中点击VM或其它群集角色，可以看到更改启动优先级的选项，设置之后，群集角色会按照高中低顺序启动，针对于不自动启动，则在故障转移后需要管理员手动启动。
优先级设置在节点冷启动，移动至最佳节点，故障转移，维护模式下都会生效，优先级设置帮助确定好迁移或启动顺序，群集依据放置规则执行操作，优先级设置是群集级别，不会因为群集角色迁移到其它节点而失效，不仅可以针对虚拟机设置，也可以针对需要联合工作的群集角色设置
本场景中，我们设置四个虚拟机的优先级别，分别为，高，中，低，低。
直接关闭HV02，可以看到虚拟机已经被迁移至HV01
直接看cluster log可以看到优先级处理过程
通过查看clusterlog我们可以看出，优先级设置是生效的，当故障转移时，会按照我们给定的优先级顺序，进行联机处理虚拟机虚拟机，这在一些场景下是有作用的。
但是也有它所做不到的地方，例如，当我们的依赖关系达到四层的时候，像我们这种DC,DB,AP,WEB的场景下，就只好设置WEB和AP都为低，这样两个应用就会随机起来，而不能完全满足我们对于依赖性启动的需求。
而且在2012时代开始，如果我们对于虚拟机设置为低优先级还是有一定风险的，例如，如果我们发生故障转移，高优先级的虚拟机如果因为没有资源而无法被放置启动，是会关机回收低优先级虚拟机资源的，如果您的环境资源很足够，当然不会发生这种问题，但如果服务器资源有限就需要注意了。
还有一点，根据老王的观察，优先级启动这个功能很好，它在帮助我们编排群集资源的处理顺序方面很好，可以帮助我们很好的解决启动风暴的问题，可以在资源有限的情况下确保高优先级的资源始终优先启动，这项功能它可以工作的很好，但是对于依赖性启动，老王认为优先级设置还有待提升，其一是只有三层依赖关系可以设置，其二是依赖性启动处理的不够明显，大家看clusterlog就能看出，各个虚拟机的联机处理时间挨着很近，即是说可能会发生一种情况，DC可能没完全启动起来，只是虚拟机资源联机了，但是系统没完全启动起来，SQL就开始联机启动了，这样依赖性启动意义也就不大了，因为优先级设置没办法控制依赖性启动的间隔，例如没办法控制高优先级启动多长时间后，再启动中优先级。
优先级设置这项功能，在老王看来，属于群集的一种附属功能，它是在维持群集可用性的情况下的一种策略设置，只是负责确定一个顺序，但是当计划内，计划外移动转移发生时，它做的只是快速确定顺序，然后群集快速按照它确定好的顺序进行放置处理群集资源。
在WSFC2016时代，针对于群集资源管理，推出了顺序组的功能，简单来说，我们现在可以自己定义群集虚拟机或群集角色之间的依赖关系了，想创建多少层依赖关系，就创建多少层，每层依赖关系对应的是一个个的顺序组，每个顺序组里面可以有多个虚拟机或群集应用，当我们创建依赖关系，是基于顺序组的级别去创建依赖关系，一项重要的改变是，当我们使用新的顺序组功能时，每个顺序组启动后，默认会等待20秒的时候，当一个依赖顺序组启动后，等待20秒再启动下一个顺序组，这个等待时间可以更改，此功能为群集级别，不论虚拟机迁移到其它任何节点都会生效，因此我们可以说，这是项真正的依赖性启动处理解决方案。
整理下思路，我们现在有了顺序组功能，我们可以手动去创建顺序组，每个组里面可以包括多个虚拟机或群集角色。构建完成顺序组后，我们可以在群集上手动创建依赖关系，指定一层一层的顺序组依赖关系，最终，应该当我们要启动最底层依赖关系的一台虚拟机，会检测到上一个依赖顺序组虚拟机还没启动，上层虚拟机要启动又需要最上层顺序组，结果所有虚拟机按照顺序启动，每一层虚拟机启动后，默认都会等待20秒再启动下一层顺序组中虚拟机，该时间可控。
VM顺序组配置相关Powershell命令
创建管理顺序组
New-ClusterGroupSet: 创建一个顺序组
Get-ClusterGroupSet: 获取当前顺序组
Set-ClusterGroupSet: 配置顺序组设置
Remove-ClusterGroupSet: 删除一个顺序组
Add-ClusterGroupToSet: 添加VM或其它群集角色至顺序
Remove-ClusterGroupFromSet: 从顺序组中删除VM或其它群集角色
配置顺序组内依赖关系
Add-ClusterGroupDependency: 添加顺序组内虚拟机的依赖关系
Get-ClusterGroupDependency: 获取顺序组内虚拟机的依赖关系
Remove-ClusterGroupDependency: 删除顺序组内虚拟机的依赖关系
配置顺序组间依赖关系
Add-ClusterGroupSetDependency: 添加跨顺序组之间的依赖关系
Get-ClusterGroupSetDependency: 获取跨顺序组之间的依赖关系
Remove-ClusterGroupSetDependency: 删除跨顺序组之间的依赖关系
#创建顺序组
$Cluster = "pecluster.oa.com"
New-ClusterGroupSet -CimSession $Cluster -Name "DC"
New-ClusterGroupSet -CimSession $Cluster -Name "SharepointDB"
New-ClusterGroupSet -CimSession $Cluster -Name "SharepointApp"
New-ClusterGroupSet -CimSession $Cluster -Name "SharepointWeb"
可以看到老王之前说过的20秒等待时间，即当前顺序组启动20秒后，再启动其它顺序组，例如，如果您知道，某些顺序组启动时间会很长，例如SharepointDB虚拟机，那么您就可以单独设置它的等待时间长一些，例如我们手动设置为30秒，即依赖于SharepointDB的顺序组，需要等待30秒，SharepointDB启动后，再启动下一层。
其它参数介绍
StartupDelayTrigger 定义了当开始依赖关系处理时，对于顺序组的处理方式
Online ：不进行等待时间，只要资源状态变为联机就启动下个顺序组
Delay：默认设置，等待StartupDeplay设置的时间到了才启动下个顺序组
StartupCount 定义开始处理依赖关系之前，顺序组内必须已经经过延迟上线的角色数量
只有组内所有角色都经过延迟上线后才处理后面（默认）
0 只要组中大部分角色都上线就处理后面顺序组
N 用户自行定义顺序组中启动多少角色可以处理后面顺序组
IsGlobal ：有趣的参数，假设您构建了很多个顺序组，您的群集里面有DHCP,Fileserver，DC虚拟机等基础架构角色，那么您可以把它们顺序组设置为IsGlobal=1，这样设置之后，依赖关系将always always 第一联机IsGlobal=1的顺序组，再处理其它的，适用于群集里面多个基础架构服务，其它顺序组都对它们有所依赖的场景。
#示例：Set-ClusterGroupSet -name ServerInfra -IsGlobal 1
当前我们创建完了顺序组，群集知道你有这样一个规划了，但是顺序组里面没有资源，现在是空的，我们需要把对应的虚拟机或其它群集角色添加进去
#添加虚拟机至顺序组
#DC
Add-ClusterGroupToSet -CimSession $Cluster -Name DC -Group "DC"
#SharepointDB
Add-ClusterGroupToSet -CimSession $Cluster -Name SharepointDB -Group "SPDB"
#SharepointApp
Add-ClusterGroupToSet -CimSession $Cluster -Name SharepointApp -Group "SPAP"
#SharepointWeb
Add-ClusterGroupToSet -CimSession $Cluster -Name SharepointWeb -Group "SPWEB"
这里的Name是顺序组的名称，后面Group是虚拟机名称，如果是其它群集角色则也添加群集角色名称，这里每一个顺序组中可以添加多个虚拟机或群集角色，老王这里只添加一台作为测试，如果您在一个顺序组中添加了多台虚拟机或群集角色，那么您还可以配置顺序组内的依赖关系。
#查看顺序组，可以看到顺序组中各成员
OK，三步走，创建顺序组，添加各顺序组成员，接下来该创建顺序组之间依赖关系了
#创建顺序组之间依赖关系
Add-ClusterGroupSetDependency -CimSession $Cluster -Name SharepointWeb -Provider SharepointApp
Add-ClusterGroupSetDependency -CimSession $Cluster -Name SharepointApp -Provider SharepointDB
Add-ClusterGroupSetDependency -CimSession $Cluster -Name SharepointDB -Provider DC
#获取群集内顺序组之间依赖关系
根据老王的测试，发现顺序组依赖功能仅在群集节点冷启动下生效，即是说，只有在节点关机开机时，我们创建的这套依赖关系才会生效。本例中，我们将虚拟机全部关机，然后启动SharepointWEB，看看会不会根据依赖关系自动把其它虚拟机都启动起来
关闭所有虚拟机
启动SPWEB
可以看到，已经按照我们构建的依赖关系进行逐步唤醒各个依赖顺序组，并唤醒各个顺序组中虚拟机，每唤醒一个依赖顺序组后，都会按照该顺序组设定的开机等待时间，等待时间到了才会继续唤醒下个顺序组。
确保所有依赖关系顺序组都已经启动完成，最终SPWEB才会启动
查看clusterlog可以看到顺序组依赖工作过程
设置顺序组及依赖关系，群集DM记录信息进入群集数据库，并通过GUM同步至所有节点
群集通过RCM操作处理顺序组依赖启动功能
通过以上实验相信大家可以看出顺序组依赖关系这项功能是怎么回事了，可以说这是一项真正解决群集应用依赖启动问题的功能，我们自己构建顺序组及依赖关系，虚拟机关机再开机时，RCM遵照我们的构建进行操作处理，实质上，RCM处理依赖关系，首先看的是顺序组，我们实现这样一套自己构建的东西后，实际群集操作的依赖关系是按照顺序组为单位进行操作，然后幕后顺序组再对应到虚拟机或群集角色，我们完成虚拟机到顺序组的映射，顺序组到依赖关系的映射，最后使本来不具备依赖关系功能的虚拟机应用上依赖关系功能
总结下顺序组依赖功能的利与弊
- 群集级别功能，单台配置，全群集生效，配置信息记录至群集数据库同步至全群集节点及仲裁磁盘
- 不仅可以应用于虚拟机，还可以应用于其他群集角色
- 可以任意构建依赖关系模型，支持跨顺序组之间构建依赖关系，也支持顺序组内构建依赖关系，可以手动调整顺序组延迟启动时间，依赖延迟操作，较为灵活，适用于真正有依赖启动需求的场景
- 缺点，只能是节点冷启动，或虚拟机关机开机时依赖关系才会生效，手动移动至最佳节点，维护模式不会生效，希望以后维护模式，手动移动至最佳节点也可以用上就厉害了，这样如果跨站点迁移的话，当我们迁移Web，就会也把DB,AP也一起迁移过去
2016里面除了针对于群集的顺序组，还有个针对于虚拟机的管理组功能，老王特定把这两个功能拿到一起来讲，怕大家给它们两个弄混
首先，两者最大的一个区别，顺序组是2016群集的功能，VM管理组是2016Hyper-V的功能，顺序组主要为了解决资源启动时的依赖关系问题，VM管理组主要是解决虚拟机批量管理的问题。
简单来讲，VM管理组，是我们在Hyper-V 2016上面创建出来的一个逻辑的组，它的主要作用
- 同一个VM管理组内虚拟机可以一起进行Hyper-V复制
- VM管理组支持嵌套管理组进行管理操作
- Hyper-V 2016中使用Shared Drive的虚拟机支持Hyper-V复制，但需要依赖于VM管理组功能
#创建VM管理组
New-VMGroup -Name "DC" -GroupType VMCollectionType
New-VMGroup -Name "SPDB" -GroupType VMCollectionType
New-VMGroup -Name "SPWEB" -GroupType VMCollectionType
New-VMGroup -Name "SPAP" -GroupType VMCollectionType
#添加虚拟机进入VM管理组 ，可以添加多个虚拟机进入同一个管理组，()后面逗号隔开继续输入即可
Add-VMGroupMember -Name "DC" -VM (Get-VM "DC")
Add-VMGroupMember -Name "SPDB" -VM (Get-VM "SPDB")
Add-VMGroupMember -Name "SPAP" -VM (Get-VM "SPAP")
Add-VMGroupMember -Name "SPWEB" -VM (Get-VM "SPWEB")
#获取VM管理组中虚拟机
(Get-VMGroup -Name "SPDB").VMMembers
#获取宿主机所有虚拟机的管理组信息
Get-VM | FT Name, Groups
同一个VM管理组中可以有多个虚拟机，同一个虚拟机可以属于多个管理组
由于Hyper-V复制不允许群集内，只允许单机对单机，单机对群集，或群集对群集，所以老王暂时把HV02退出群集节点，勾选允许作为复制副本，群集开启hyper-v replica boker角色，允许作为复制副本
#基于组级别创建VM复制关系
Enable-VMReplication -VM (Get-VMGroup SPDB).VMMembers -ReplicaServerName HV02 -ReplicaServerPort 80 -AuthenticationType Kerberos -CompressionEnabled 1 -ReplicationFrequencySec 30 -AutoResynchronizeEnabled 1
#查看复制状态
VM管理组除了VMCollectionType这种组类型，还有一种ManagementCollectionType组类型，当我们如果需要嵌套管理组资源则需要创建这种VM管理组类型
#创建VM管理组ManagementCollectionType类型
#嵌套添加VM管理组至新类型管理组中
Add-VMGroupMember -VMgroup (Get-VMGroup "MGroup") -VMGroupMember (Get-VMGroup "DC"),(Get-VMGroup "SPDB"),(Get-VMGroup "SPAP"),(Get-VMGroup "SPWEB")
#获取嵌套VM管理组架构
#尝试针对于嵌套VM管理组启动复制，发现不成功，也在意料之内，Hyper-V复制应该是只支直接组内就是虚拟机的类型，否则获取不到VM参数即不成功。
至此，老王为大家简单介绍了下VM管理组功能，这是一项Hyper-V 2016的功能，只不过都是和组相关，特地拿出来说下，可以看到VM管理组的功能，主要定位于Hyper-V层面，可以针对于组级别进行复制操作，可以进行嵌套组管理，目前看来功能还不是很多，老王看来目前为止，主要的意义在于，针对于组级别做Hyper-V复制，可以解决原来share vhdx虚拟机不能复制的问题，期待日后更多Hyper-V的管理操作也可以通过这种管理组的方式批量操作，这项功能英文叫VM Group，老王将它翻译为VM管理组，因为老王这项功能更侧重与管理，如果单说组过于抽象，也和顺序组功能区别开，本篇文章就到这里，希望看到的朋友都会有收获，后续几篇还将继续微软WSFC 2016管理操作方面的新功能进行讲解，一切都是刚刚开始