Setting cluster advanced features including HA DRS and EVC_PowerCLI Cookbook-QQ阅读中文科幻网

书名：PowerCLI Cookbook
作者名：Philip Sellers
本章字数：1700字
更新时间：2025-04-04 21:05:24

Setting cluster advanced features, including HA, DRS, and EVC

The previous recipe mentioned the advanced features of vSphere clusters. In this recipe, you will configure those advanced features since it is more common to reconfigure these settings than to initially set these settings.

The cluster settings you are going to be working with are HA, DRS, and Enhanced vMotion Compatibility (EVC) settings. In the vSphere Client, these settings are exposed in the Edit Cluster Settings option.

Creating a cluster is a one-time event, but as you deploy vSphere, you might not be ready to automate vMotions or Storage vMotions with DRS in your cluster from the beginning.

However, over a period of time, your comfort level with these automation technologies begins to increase and you would want to put the cluster on autopilot and change the automation level to be fully automated. You will cover how to do this and how to set up other common settings from PowerCLI.

PowerCLI is useful for these settings because it allows you to repeat the same cmdlet against multiple clusters in large environments, or to change your configuration and change it back easily for smaller environments. However, even cluster-wide settings are just the beginning of what you can configure faster in PowerCLI than in the GUI.

DRS rules are a great example of something that is faster to configure from PowerCLI than in the GUI. Since you can use the Get-VM cmdlet to quickly return an object with multiple VMs matching a search string, you can pass this into a new rule instead of searching and clicking multiple times on the GUI.

You can also see that one vSphere advanced clustering feature is missing from this recipe: Fault Tolerance (FT). The reason it is missing from this configuration recipe is that the only requirements for Fault Tolerance to work were already configured in the ESXi configuration from Chapter 1, Configuring the Basic Settings of an ESXi Host with PowerCLI. For FT, you need to set a vmkernel port with an IP address and enable this for FT logging. There is no additional configuration required.

Getting ready

To begin, you will need to open a PowerCLI window and log into a vCenter server.

In this recipe, you will configure the availability and resource balancing features of a cluster. All of these features are managed at a cluster level, so you will utilize the Get-Cluster cmdlet to specify which cluster you want to be working with.

Reconfiguring the cluster settings is a common requirement for the existing clusters. You will explore simple cmdlets to enable and disable HA or DRS on a cluster, you will take a look at how to configure the additional settings used for the restart order with HA and how workloads are balanced with DRS.

However, DRS doesn't stop at simply balancing workloads. DRS rules expand beyond simply spreading the load evenly across the hosts in a cluster. DRS rules can dictate which VMs should coreside on the same host and which VMs should never reside on the same host. The latter is particularly helpful when you have multiple, identical app servers fronted by a load balancer. To have redundancy, you need to make sure that a hardware failure can't take down both VMs at once. You will also examine how to create simple DRS rules for keeping VMs together and keeping VMs separated.

For HA, Admission Control is a feature that reserves resources, so that a cluster can withstand losing one or more hosts without negatively impacting the performance. This setting can be enabled or disabled, and you can also adjust the number of hosts' failures that the cluster can accommodate. The cluster reserves resources so that if the specified numbers of hosts fail, the VM workloads still run without being resource constrained. These settings prevent users from powering on virtual machines if the resource conditions are not met.

Note

If you are running vCloud Director, DRS is required and must not be disabled.

Since HA is primarily concerned with recovering failed virtual machines, there are two additional settings that you can set: Isolation Response and Restart Priority. Isolation Response sets the reactive behavior that the host should take if it becomes isolated from the rest of the cluster. You can set this to either power off the VMs or to do nothing. The Restart Priority setting sets the default priority for VMs in the cluster if they fail. This can be set per VM, so at the cluster level you are setting the default. Ideally, your most critical VMs are manually set to a higher level, other critical VMs to medium, and management systems and noncritical systems to low. It's also important to note that if Admission Control doesn't have resources to restart any more VM's, the lowest priority VMs would be left powered off.

How to do it…

In order to set up the advanced features of a cluster, including HA, DRS, and EVC, that is, to configure the availability and resource balancing features of a cluster, perform the following steps:

Changes to any existing cluster will utilize the Set-Cluster cmdlet. The Set-Cluster cmdlet has the same features as the New-Cluster cmdlet you used in the previous recipe. With Set-Cluster, you will specify a cluster using the -Cluster parameter and then you can make any configuration changes to the cluster you want. Let's start with a quick cmdlet to disable HA:
```
Set-Cluster -Cluster "BigCluster" -HAEnable $false
```
Change $false to $true and the cmdlet turns on the feature. Simple!
```
Set-Cluster -Cluster "BigCluster" -HAEnable $true
```
Next, you might want to change the Admission Control and Failover Level settings for HA on the cluster. Again, you turn to the Set-Cluster cmdlet to make these setting changes. The -HAAdmissionControlEnabled parameter controls whether Admission Control is turned on. The -HAFailoverLevel parameter is set to a number from 1 to 4 specifying how many host failures you want the cluster to be able to survive. You will set our example to survive one host failure:
```
Set-Cluster -Cluster "BigCluster" -HAadmissionControlEnabled $true -HAFailoverLevel 1
```
Next, you can set the Isolation Response and Restart Priority settings for the cluster, again using the Set-Cluster cmdlet. First, you use -HAIsolationResponse to set the behavior if the host becomes isolated. Next, you use -HARestartPriority to set the default priority to restart VMs in the cluster:
```
Set-Cluster -Cluster "BigCluster" -HAIsolationResponse PowerOff -HaRestartPriority Medium
```
It is also important to note that all of these settings can be combined in a single Set-Cluster cmdlet.
It is also common to change the DRS mode on a cluster. To do this, you again use the Set-Cluster cmdlet, but you will use the -DrsAutomationLevel parameter to set the mode:
```
Set-Cluster -Cluster "BigCluster" -DrsAutomationLevel Manual -Confirm:$false
```
More commonly, you might want to set the DRS mode to fully automated:
```
Set-Cluster -Cluster "BigCluster" -DrsAutomationLevel FullyAutomated -Confirm:$false
```
Next, in this example, you will make sure that our domain controllers are not both running on the same ESXi node by defining a DRS rule. First, you need to retrieve a list of the domain controller VM's with the Get-VM cmdlet. The New-DrsRule cmdlet allows you to create a KeepTogether or a Separate rule. The syntax is very simple. You need to specify a name for our rule, a cluster, whether or not this is a KeepTogether rule, and finally, which VMs are passed by a variable:
```
$domaincontrollers = Get-VM -Name "DC*"

New-DrsRule -Name "Separate DCs" -Cluster "BigCluster" -Enabled $true -KeepTogether $false -VM $domaincontrollers
```
Reporting the EVC mode setting is very straightforward from PowerCLI. To begin, you must retrieve the cluster object and the EVC mode setting as a parameter of this object:
```
Get-Cluster "BigCluster" | Select Name, EVCMode
```
Changing the EVC mode setting is pretty simple using the Set-Cluster cmdlet, but it requires PowerCLI 5.5 R2. The earlier versions of PowerCLI do not include the -EVCMode parameter with the Set-Cluster cmdlet. You simply need to specify the key of the mode you want to enable. A chart of the keys is included in the How it works… section:
```
Set-Cluster -Cluster "Primary" -EVCMode 'intel-penryn'
```

How it works…

All of these settings are cluster-level settings and so most of them are set using the Set-Cluster cmdlet. Set-Cluster, like New-Cluster in the previous recipe, has a number of parameters specific to vSphere clusters. Many of the parameters are simple Boolean inputs, either $true or $false. Others have defined the input where you might need to use the Get-Help Set-Cluster cmdlet in order to investigate the exact input expected for the setting you desire.

Again, where does PowerCLI buy you the biggest benefits for cluster configuration? Anytime you've got more than one cluster, and you want to make sure that you have uniform settings across the clusters. If you want to make sure that your HA, DRS, and EVC settings are the same for several hosts, you simply use a Get-Cluster cmdlet. Search for all of the clusters in your datacenter or for specific clusters in the datacenter, and then pipe that directly into a Set-Cluster cmdlet with your desired settings. This is much faster and helps you to eliminate human error by picking the wrong setting in the GUI while changing clusters one at a time.

One of the parameters, -EVCmode, specifically needs enumerated input settings. The following tables show the available EVC mode keys that can be set from the New-Cluster and Set-Cluster cmdlets:

There's more…

While you talked about KeepTogether and Separate DRS rules, there are other types of DRS rules and those are VM to Host rules. While PowerCLI doesn't provide cmdlets to handle DRS Affinity Group assignments, this is one of the best use cases for PowerCLI and one that I use in my managed environments. Users who have implemented a VMware Metro Storage Cluster might need to routinely manage and assign VMs to Affinity Groups to make sure that VMs are running in a particular physical location. This is an advanced use case, but you should definitely read the blog post and code from Niklas Åkerlund linked in the See also section.