Shulou(Shulou.com)06/02 Report--

When we manage a virtualization scenario or a clustered application scenario, we may often encounter a requirement, that is, the dependency order, and the developer may need to ensure the startup sequence of a series of joint working virtual machines or clustered applications. Ensure that the lowest required resources are started, and then start other resources in sequence.

For the need for dependent startup, if it is a stand-alone Hyper-V scenario without clusters, we can solve this problem by setting the automatic startup properties of virtual machines. For example, in a sharepoint environment with DC,DB,AP,WEB, we can set the delay time for automatic startup of each virtual machine in turn. After doing this, when the host restarts in the stand-alone case, the virtual machine can be started step by step according to the delay order to meet the requirement of dependent startup, but this setting is limited to stand-alone use only. When we move the virtual machine to another node, the automatic startup delay setting is invalid and needs to be reset each time.

The setting becomes invalid after the virtual machine is migrated to another node

The cluster priority function has been optimized in the WSFC2012 era. In the 2012 era, we can also control the dependent startup of cluster applications through the cluster priority. Lao Wang has made a detailed introduction to the cluster priority in his daily management operation blog. If you are interested, you can see it. Click VM or other cluster roles in the cluster, you can see the option to change the startup priority after setting it. The cluster role starts in high, middle and low order, and if it does not start automatically, the administrator will need to start it manually after a failover.

The priority setting takes effect when the node is cold started, moved to the best node, failover, and maintenance mode. The priority setting helps determine the migration or startup order, and the cluster performs operations according to placement rules. The priority setting is at the cluster level and will not be invalidated because the cluster role is migrated to other nodes. It can be set not only for virtual machines, but also for cluster roles that need to work jointly.

In this scenario, we set the priority of four virtual machines as high, medium, low, and low.

If you close HV02 directly, you can see that the virtual machine has been migrated to HV01

If you look at cluster log directly, you can see the priority processing process.

By looking at the clusterlog, we can see that the priority setting is in effect, and when we fail over, the virtual machines are processed online in the order of priority we have given, which is useful in some scenarios.

But there are also places that it can't do, for example, when our dependency reaches four layers, in our DC,DB,AP,WEB scenario, we have to set both WEB and AP to low, so that the two applications will be random and can not fully meet our need for dependency startup.

Moreover, at the beginning of 2012, there is still a certain risk if we set the virtual machine to a low priority. For example, if we fail over, if the high-priority virtual machine cannot be placed and started because there are no resources, it will shut down and recycle the low-priority virtual machine resources. If your environment resources are sufficient, of course this problem will not occur, but if the server resources are limited, you need to pay attention.

In addition, according to Lao Wang's observation, priority startup is a very good function. It helps us to arrange the processing order of cluster resources, and can help us solve the problem of starting storms. It can ensure that high-priority resources always start first when resources are limited. This function works well, but for dependent startup, Lao Wang believes that the priority setting needs to be improved. One is that there are only three layers of dependencies that can be set, and the other is that the dependency startup processing is not obvious enough. If you look at clusterlog, you can see that the online processing time of each virtual machine is very close, that is to say, a situation may occur. DC may not be fully started, but the virtual machine resources are online, but the system is not fully started, and SQL starts to start online, so dependency startup is of little significance. Because the priority setting does not control the interval of dependency startup, for example, there is no way to control how long it takes to start with a high priority and then the priority in the startup.

In Lao Wang's view, priority setting is a subsidiary function of the cluster. it is a policy setting while maintaining the availability of the cluster, and it is only responsible for determining an order, but when an unplanned mobile transfer occurs, all it does is quickly determine the order, and then the cluster quickly places and processes the cluster resources in the order determined by it.

In the WSFC2016 era, we introduced the function of sequential groups for cluster resource management. To put it simply, we can now define the dependencies between cluster virtual machines or cluster roles. We can create as many layers of dependencies as we want. Each layer of dependencies corresponds to sequential groups. There can be multiple virtual machines or cluster applications in each sequential group. When we create dependencies, we can create dependencies. It is based on the level of the sequence group to create the dependency. An important change is that when we use the new sequence group function, after each sequence group starts, it will wait 20 seconds by default, when a dependent sequence group starts. Wait 20 seconds before starting the next sequence group, this waiting time can be changed, this function is at the cluster level, no matter the virtual machine is migrated to any other node will take effect. So we can say that this is a real dependency startup processing solution.

To sort things out, we now have the sequential group feature, and we can manually create sequential groups, each of which can include multiple virtual machine or cluster roles. After the sequence group is built, we can manually create dependencies on the cluster and specify one layer of sequential group dependencies. Finally, when we want to start a virtual machine with the lowest dependency, we will detect that the last dependent sequence group virtual machine has not been started, and the upper virtual machine needs the top sequence group to start. As a result, all virtual machines start sequentially, and after each layer virtual machine starts. By default, you will wait 20 seconds before starting the virtual machine in the next sequence group, which is controllable.

VM sequential group configuration related Powershell commands

Create a management sequence group

New-ClusterGroupSet: create a sequential group

Get-ClusterGroupSet: gets the current sequence group

Set-ClusterGroupSet: configuring sequence group settin

Remove-ClusterGroupSet: delete a sequence group

Add-ClusterGroupToSet: add VM or other cluster roles to order

Remove-ClusterGroupFromSet: removes VM or other cluster roles from a sequence group

Configure sequential intra-group dependencies

Add-ClusterGroupDependency: add dependencies of virtual machines in a sequential group

Get-ClusterGroupDependency: gets the dependencies of virtual machines in a sequential group

Remove-ClusterGroupDependency: removes the dependency of virtual machines in a sequential group

Configure sequential intergroup dependencies

Add-ClusterGroupSetDependency: add dependencies across sequential groups

Get-ClusterGroupSetDependency: getting dependencies across sequential groups

Remove-ClusterGroupSetDependency: removes dependencies across sequential groups

# create a sequence group

$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"

You can see the 20-second wait time mentioned by Lao Wang, that is, after the current sequence group starts for 20 seconds, you can start other sequence groups. For example, if you know that some sequence groups will take a long time to start, such as the SharepointDB virtual machine, you can set its wait time separately. For example, we manually set it to 30 seconds, that is, the sequence group that depends on SharepointDB needs to wait for 30 seconds. After SharepointDB starts, you can start the next layer.

Introduction of other parameters

StartupDelayTrigger defines how sequential groups are handled when dependency processing begins

Online: no wait time, start the next sequence group as soon as the resource status becomes online

Delay: default setting. Wait for the time to set StartupDeplay before starting the next sequence group.

StartupCount defines the number of roles in a sequential group that must have been delayed before starting to deal with dependencies

Only all characters in the group will be processed later after the delayed launch (default)

0 as long as most of the characters in the group are online, deal with the subsequent sequential groups.

N users define how many roles can be started in the sequence group to handle the subsequent sequence group.

IsGlobal: interesting parameter. Suppose you build many sequential groups, and you have infrastructure roles such as DHCP,Fileserver,DC virtual machines in your cluster, then you can set them to IsGlobal=1. After this setting, dependencies will always always the sequential groups of the first online IsGlobal=1, and then deal with other scenarios that are suitable for multiple infrastructure services in the cluster, and other sequential groups depend on them.

# example: Set-ClusterGroupSet-name ServerInfra-IsGlobal 1

Now that we have created the sequence group, the cluster knows that you have such a plan, but there are no resources in the sequence group. It is empty now. We need to add the corresponding virtual machine or other cluster roles to it.

# add a virtual machine to a sequence group

# 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"

Here, Name is the name of the sequence group, followed by the virtual machine name, and if it is other cluster roles, cluster role names are also added. Here, multiple virtual machines or cluster roles can be added to each sequence group. Lao Wang only adds one as a test. If you add multiple virtual machines or cluster roles to a sequence group, you can also configure the dependencies within the sequence group.

# looking at the sequence group, you can see the members of the sequence group

OK, three steps, create order groups, add members of each sequence group, and then create dependencies between order groups

# create dependencies between sequential groups

Add-ClusterGroupSetDependency-CimSession $Cluster-Name SharepointWeb-Provider SharepointApp

Add-ClusterGroupSetDependency-CimSession $Cluster-Name SharepointApp-Provider SharepointDB

Add-ClusterGroupSetDependency-CimSession $Cluster-Name SharepointDB-Provider DC

# obtain dependencies between sequential groups within a cluster

According to Lao Wang's test, it is found that the sequential group dependency function takes effect only when the cluster node is cold started, that is, the dependency we created will only take effect when the node is turned on. In this example, we shut down all the virtual machines, and then start SharepointWEB to see if we can automatically start the other virtual machines based on the dependency.

Shut down all virtual machines

Start SPWEB

You can see that each dependency order group has been gradually awakened according to the dependency relationship we have built, and the virtual machines in each sequence group have been awakened. After awakening each dependent sequence group, the boot waiting time set by the sequence group will be followed. The waiting time will not continue to wake up the next sequence group until the waiting time is up.

Ensure that all dependency order groups have been started before SPWEB is finally started

If you look at clusterlog, you can see that sequential groups depend on the work process.

Set sequence groups and dependencies. Cluster DM records information into the cluster database and synchronizes to all nodes through GUM.

The cluster handles the order group dependent startup function through RCM operations

Through the above experiments, I believe you can see what is going on with the function of sequential group dependencies. It can be said that this is a function that really solves the problem of cluster application dependency startup. We build sequential groups and dependencies ourselves. When the virtual machine is powered off and rebooted, RCM operates in accordance with our construction. In essence, RCM deals with dependencies, first of all looking at sequential groups. After we implement such a set of things we build, the dependencies of the actual cluster operations are operated in units of sequential groups, and then the behind-the-scenes sequential groups correspond to virtual machines or cluster roles. We complete the mapping of virtual machines to sequential groups, the mapping of sequential groups to dependencies, and finally the dependency function of virtual machines that do not have the dependency function.

Summarize the advantages and disadvantages of sequential group dependence function

Cluster level function, single configuration, full cluster effective, configuration information recorded to cluster database synchronized to full cluster node and quorum disk

Can be applied not only to virtual machines, but also to other cluster roles

You can build a dependency model at will, support building dependencies across sequential groups, and also support building dependencies within sequential groups. You can manually adjust the delayed start time of sequential groups and rely on delayed operations, which is more flexible and suitable for scenarios with real dependent startup requirements.

The disadvantage is that the dependency relationship will only take effect when the node is cold started, or when the virtual machine is turned on. If you manually move to the best node, the maintenance mode will not take effect. I hope that in the future, you can also use the maintenance mode and manually move to the best node. In this way, if you migrate across sites, when we migrate Web, we will also migrate DB,AP.

In 2016, in addition to the sequential group for clusters, there is also a management group function for virtual machines. Lao Wang specifically put these two functions together for fear that everyone would confuse the two of them.

First of all, the biggest difference between the two is that the sequential group is the function of the 2016 cluster, the VM management group is the function of 2016Hyper-V, the sequential group is mainly to solve the dependency problem when resources are started, and the VM management group is mainly to solve the problem of batch management of virtual machines.

To put it simply, the VM Management Group is a logical group that we created on Hyper-V 2016, and its main role

Virtual machines in the same VM management group can perform Hyper-V replication together.

VM management groups support nested management groups for management operations

Virtual machines using Shared Drive in Hyper-V 2016 support Hyper-V replication, but rely on VM management group functionality

# create a VM management group

New-VMGroup-Name "DC"-GroupType VMCollectionType

New-VMGroup-Name "SPDB"-GroupType VMCollectionType

New-VMGroup-Name "SPWEB"-GroupType VMCollectionType

New-VMGroup-Name "SPAP"-GroupType VMCollectionType

# add virtual machines to the VM management group. You can add multiple virtual machines to the same management group, and () continue to enter them separated by commas

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")

# obtain virtual machines in VM management group

(Get-VMGroup-Name "SPDB") .VMMembers

# obtain the management group information of all virtual machines of the host

Get-VM | FT Name, Groups

There can be multiple virtual machines in the same VM management group, and the same virtual machine can belong to multiple management groups.

Since Hyper-V replication is not allowed within the cluster, only stand-to-stand, stand-alone-to-cluster, or cluster-to-cluster is allowed, Lao Wang temporarily exits HV02 from the cluster node, check allow to be a replica, and the cluster opens the hyper-v replica boker role and allows to be a replica

# create VM replication relationship based on group level

Enable-VMReplication-VM (Get-VMGroup SPDB). VMMembers-ReplicaServerName HV02-ReplicaServerPort 80-AuthenticationType Kerberos-CompressionEnabled 1-ReplicationFrequencySec 30-AutoResynchronizeEnabled 1

# View replication status

VM management group in addition to the VMCollectionType group type, there is also a ManagementCollectionType group type, when we need to nest management group resources, we need to create this VM management group type

# create VM management group ManagementCollectionType type

# nested add VM management group to the new type management group

Add-VMGroupMember-VMgroup (Get-VMGroup "MGroup")-VMGroupMember (Get-VMGroup "DC"), (Get-VMGroup "SPDB"), (Get-VMGroup "SPAP"), (Get-VMGroup "SPWEB")

# get nested VM management group architecture

# an attempt was made to start replication for a nested VM management group. It is also expected that Hyper-V replication should only support the type of virtual machine in the group, otherwise it will not succeed if the VM parameter is not obtained.

At this point, Lao Wang gave you a brief introduction to the VM management group function, which is a function of Hyper-V 2016, but it is all related to the group. Specifically, you can see that the function of the VM management group is mainly located at the Hyper-V level. It can be replicated at the group level and nested group management can be carried out. At present, it seems that there are not many functions. According to Lao Wang, the main significance so far is Hyper-V replication at the group level can solve the problem that the original share vhdx virtual machine cannot be replicated. It is expected that more Hyper-V management operations can also be operated in batches through this management group in the future. This function is called VM Group in English. Lao Wang translated it into a VM management group, because Lao Wang places more emphasis on management. If the group is too abstract and different from the sequential group function, this article ends here. Friends who hope to see will be rewarded. In the following articles, we will continue to explain the new features of Microsoft WSFC 2016 management operation. Everything is just the beginning.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.