ESXi/ESX hosts with visibility to RDM LUNs being used by MSCS nodes with RDMs may take a long time to start or during LUN rescan

ESXi/ESX hosts with visibility to RDM LUNs being used by MSCS nodes with RDMs may take a long time to start or during LUN rescan (1016106)

Symptoms

• ESXi/ESX 4.x and ESXi 5.x hosts take a long time to start. This time depends on the number of RDMs that are attached to the ESXi/ESX host.
  
  Note: In a system with 10 RDMs used in an MSCS cluster with two nodes, a restart of the ESXi/ESX host with the secondary node takes approximately 30 minutes. In a system with less RDMs, the restart time is less. For example, if only three RDMs are used, the restart time is approximately 10 minutes.
  
• ESXi intermittently shows an error message on the Summary Tab and vSphere Client may not be able to start:
  
  Cannot synchronize host hostname. Operation Timed out.
  
• The logging screen shows the start waiting after this message:
  
  Loading module multiextent.
  
• The cluster is running virtual machines participating in an MSCS using shared RDMs and SCSI Reservations across hosts, and a virtual machine on another host is the active cluster node holding a SCSI Reservation.
  
• Delay occurs at these steps:
  
  
  • Starting path claiming and SCSI device discovery
    
    In the vmkernel.log file of the restarting ESXi host (to check the log file depending on the version of ESXi, see the note below), you see entries similar to:
    
    vmkernel: 0:00:01:57.828 cpu0:4096)WARNING: ScsiCore: 1353: Power-on Reset occurred on naa.6006016045502500176a24d34fbbdf11
vmkernel: 0:00:01:57.830 cpu0:4096)VMNIX: VmkDev: 2122: Added SCSI device vml0:3:0 (naa.6006016045502500166a24d34fbbdf11)
vmkernel: 0:00:02:37.842 cpu3:4099)ScsiDeviceIO: 1672: Command 0x1a to device"naa.6006016045502500176a24d34fbbdf11" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0
    
  • Mounting the partition of the RDM LUNs
    
    In the vmkernel.log file of the restarting ESXi/ESX host, you see entries similar to:
    
    vmkernel: 0:00:08:58.811 cpu2:4098)WARNING: ScsiCore: 1353: Power-on Reset occurred on naa.600601604550250083489d914fbbdf11
vmkernel: 0:00:08:58.814 cpu0:4096)VMNIX: VmkDev: 2122: Added SCSI device vml0:9:0 (naa.600601604550250082489d914fbbdf11)
vmkernel: 0:00:09:38.855 cpu2:4098)ScsiDeviceIO: 1672: Command 0x1a to device"naa.600601604550250083489d914fbbdf11" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.
vmkernel: 0:00:09:38.855 cpu1:4111)ScsiDeviceIO: 4494: Could not detect setting of QErr for device naa.600601604550250083489d914fbbdf11. Error Failure.
vmkernel: 0:00:10:08.945 cpu1:4111)WARNING: Partition: 801: Partition table read from device naa.600601604550250083489d914fbbdf11 failed: I/O error
vmkernel: 0:00:10:08.945 cpu1:4111)ScsiDevice: 2200: Successfully registered device "naa.600601604550250083489d914fbbdf11" from plugin "NMP" of type 0

vmkernel: 47:02:52:19.382 cpu17:9624)WARNING: NMP: nmp_IsSupportedPResvCommand: Unsupported Persistent Reservation Command,service action 0 type 4
vmkernel: 47:02:52:19.383 cpu17:9624)WARNING: NMP: nmp_IsSupportedPResvCommand: Unsupported Persistent Reservation Command,service action 0 type 4
vmkernel: 47:02:52:19.383 cpu23:9621)WARNING: NMP: nmp_IsSupportedPResvCommand: Unsupported Persistent Reservation Command,service action 0 type 4
vmkernel: 47:02:52:19.383 cpu17:9624)WARNING: NMP: nmp_IsSupportedPResvCommand: Unsupported Persistent Reservation Command,service action 0 type 4
vmkernel: 47:02:52:19.383 cpu12:4108)WARNING: NMP: nmpUpdatePResvStateSuccess: Parameter List Length 54310000 for service action 0 is beyondthe supported value 18
vmkernel: 47:02:52:19.383 cpu12:4108)WARNING: NMP: nmpUpdatePResvStateSuccess: Parameter List Length 54310000 for service action 0 is beyondthe supported value 18
vmkernel: 47:02:52:19.383 cpu3:5733)WARNING: NMP: nmpUpdatePResvStateSuccess: Parameter List Length 54310000 for service action 0 is beyondthe supported value 18
vmkernel: 47:02:52:19.384 cpu12:9738)WARNING: NMP: nmpUpdatePResvStateSuccess: Parameter List Length 54310000 for service action 0 is beyondthe supported value 18
vmkernel: 47:02:52:21.383 cpu23:9621)WARNING: NMP: nmp_IsSupportedPResvCommand: Unsupported Persistent Reservation Command,service action 0 type 4
    
• If you configure the setting on an existing VMFS LUN, you may see these entries in the vmkernel.log file:
  
  cpu4:10169)WARNING: Partition: 1273: Device "naa.XXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxx" with a VMFS partition is marked perennially reserved. This is not supported and may lead to data loss.cpu4:10169)WARNING: Partition: 1273: Device "naa.XXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxx" with a VMFS partition is marked perennially reserved. This is not supported and may lead to data loss.cpu4:10169)WARNING: Partition: 1273: Device "naa.XXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxx" with a VMFS partition is marked perennially reserved. This is not supported and may lead to data loss.

Note: For more information on the location of the vmkernel.log file for different versions of ESX/ESXi, see Location of log files for VMware products (1021806).

Purpose

This article describes a specific issue. If you experience all the symptoms, consult these sections.

If you are experiencing only some of the symptoms, search the Knowledge Base for your symptoms or see:

• vSphere ESX/ESXi 4.x stops during start up at the step: multiextent loaded successfully (2003424)
• ESX machines hosting passive MSCS nodes report reservation conflicts during storage operations (1009287)

Resolution

ESXi/ESX 4.x

This issue is resolved in the VMware ESXi/ESX 4.1 patch released on 2011-07-28. For more information, see:

• ESXi 4.1: VMware ESXi 4.1 Patch ESXi410-201107401-BG: Updates Firmware (2000609)
• ESX 4.1: VMware ESX 4.1 Patch ESX410-201107401-BG: Updates VMkernel, VMX, CIM (2000604)

In addition to installing the patch, modify this advanced configuration option on the affected ESXi/ESX hosts to speed up the start process:

• ESXi/ESX 4.1: Change the advanced option Scsi.CRTimeoutDuringBoot to 1.
• ESXi/ESX 4.0: Change the advanced option Scsi.UWConflictRetries to 80.

For more information on changing advanced configuration options, see Configuring advanced options for ESXi/ESX (1038578).

On ESXi/ESX 4.1, if the rescan times are still extended, the best option to resolve the issue is to upgrade the host to ESXi 5.0, which includes both of the fixes above (that is, the Patch released on 2011-07-28 and changing the advanced option Scsi.CRTimeoutDuringBoot to 1).

Before configuring the perennially-reserved setting on an existing LUN, you can verify that the LUN is mounted as a VMFS LUN. To view the existing settings, run the command:

esxcfg-scsidevs -m|grep naa.XXXXXXXXXXXXXXXXXXX




The issue Cannot synchronize host hostname. Operation Timed out is fixed in ESXi 5.0 and we recommend upgrading to ESXi 5.0 or later.

ESXi 5.0

ESXi 5.0 uses a different technique to determine if Raw Device Mapped (RDM) LUNs are used for MSCS cluster devices, by introducing a configuration flag to mark each device as perennially reserved that is participating in an MSCS cluster. During the start of an ESXi host, the storage mid-layer attempts to discover all devices presented to an ESXi host during the device claiming phase. However, MSCS LUNs that have a permanent SCSI reservation cause the start process to lengthen as the ESXi host cannot interrogate the LUN due to the persistent SCSI reservation placed on a device by an active MSCS Node hosted on another ESXi host.

Configuring the device to be perennially reserved is local to each ESXi host, and must be performed on every ESXi 5.0 host that has visibility to each device participating in an MSCS cluster. This improves the start time for all ESXi hosts that have visibility to the device(s).

There is no support to apply this setting using vSphere host profiles. ESXi 5.0 hosts deployed using vSphere Auto Deploy cannot take advantage of this feature.

Note: The advanced option Scsi.CRTimeoutDuringBoot is no longer valid on ESXi 5.0.

Upgrading to ESXi 5.0

To upgrade to ESXi 5.0:

For each host having visibility to MSCS RDM LUNs:

1. All virtual machines in the cluster must be powered off.
2. Prior to upgrading, unmount all MSCS RDMs from the host:
   1. Determine which RDM LUNs are part of an MSCS cluster.
   2. From the vSphere Client, select a virtual machine that has a mapping to the MSCS cluster RDM devices.
   3. Edit your virtual machine settings and navigate to your Mapped RAW LUNs.
   4. Select Manage Paths to display the device properties of each Mapped RAW LUN and its device identifier (that is, the naa ID).
   5. Take note of each naa ID found this way, which is a globally unique identifier for your RDMs.
   6. Mask all paths to all MSCS RDMs devices from the host. For more information, see Masking a LUN from ESX and ESXi using the MASK_PATH plug-in (1009449).
   7. Unpresent all MSCS RDMs devices from this host at the storage array.
      
3. Upgrade the host to ESXi 5.0. For more information, see Methods of upgrading to ESXi 5.0 (2004501).
4. Following restart, use the esxcli command on that host to mark each RDM device as perennially reserved:
   
   esxcli storage core device setconfig -d naa.id --perennially-reserved=true
   
   Note: This works even if the LUNs are not currently presented to the host.
   
5. Re-present the MSCS RDM devices to the host and rescan.
6. Confirm that the correct devices are marked as perennially reserved by running this command on the host:
   
   esxcli storage core device list |less

Note: Restarting hosts should not have issues with MSCS devices.

Already upgraded ESXi 5.1/5.5 hosts

To mark the MSCS LUNs as perennially reserved on an already upgraded ESXi 5.1/5.5 host, set the perennially reserved flag in Host Profiles. For more information, see the vSphere MSCS Setup Checklist section in the vSphere Documentation Center in these guides:

• vSphere 5.1 Resource Management Guide
• vSphere 5.5 Resource Management Guide

Hosts hosting MSCS nodes with RDM LUNs, use the esxcli command to mark the device as perennially reserved

esxcli storage core device setconfig -d naa.id --perennially-reserved=true

Note: Stateless ESXi hosts being configured with Auto Deploy will only apply the perennially reserved flag before boot delays while running ESXi 5.1 P04, ESXi 5.5 P04, or later. On these builds the perennially reserved flag is set by a new native plugin that Host Profiles uses before the storage mid-layer attempts to discover all devices presented to an ESXi host during the device claiming phase. In previous builds the perennially reserved flag was set by Host Profiles after the ESXi host tries to claim all the devices which causes the delay.

Already upgraded ESXi 5.0 hosts

To mark the MSCS LUNs as perennially reserved on an already upgraded ESXi 5.0 host, run the esxcli command from Already upgraded ESXi 5.1/5.5 hosts section of this article and all subsequent rescans/starts at normal speed. 

1. Determine which RDM LUNs are part of an MSCS cluster.
2. From the vSphere Client, select a virtual machine that has a mapping to the MSCS cluster RDM devices.
3. Edit your virtual machine settings and navigate to your Mapped RAW LUNs.
4. Select Manage Paths to display the device properties of the Mapped RAW LUN and the device identifier (that is, the naa ID).
5. Take note of the naa ID, which is a globally unique identifier for your shared device.
6. Use the esxcli command to mark the device as perennially reserved:
   
   esxcli storage core device setconfig -d naa.id --perennially-reserved=true
   
7. To verify that the device is perennially reserved, run this command:
   
   esxcli storage core device list -d naa.id
   
   In the output of the esxcli command, search for the entry Is Perennially Reserved: true. This shows that the device is marked as perennially reserved.
   
8. Repeat the procedure for each Mapped RAW LUN that is participating in the MSCS cluster.

Note: The configuration is permanently stored with the ESXi host and persists across restarts. To remove the perennially reserved flag, run this command:

esxcli storage core device setconfig -d naa.id --perennially-reserved=false

PowerCLI 5.0

To mark the MSCS LUNs as perennially reserved using the PowerCLI, esxcli functionality is available directly through the PowerCLI. Retrieve an esxcli instance and invoke any of its methods. For more information, see the VMware vSphere PowerCLI Blog.

To retrieve an esxcli instance, run this command:

Connect-VIServer -Server xxx.xxx.xxx.xxx -User xxxxx -Pass xxxxx


To set the esxcli instance, run this command:

$myesxcli= get-esxcli -VMHost ESXhost


To list the devices, run this command:

$myesxcli.storage.core.device.list()
To determine the PowerCLI parameters, run this command:

$myesxcli.storage.core.device.setconfig
TypeNameOfValue : VMware.VimAutomation.ViCore.Util10Ps.EsxCliExtensionMethod
OverloadDefinitions : {void setconfig(boolean detached, string device, boolean perenniallyreserved)}
MemberType : CodeMethod
Value : void setconfig(boolean detached, string device, boolean perenniallyreserved)
Name : setconfig
IsInstance : True

To list details by device naa ID, run this command:

$myesxcli.storage.core.device.list("naa.50060160c46036df50060160c46036df")
AttachedFilters :
DevfsPath : /vmfs/devices/disks/naa.50060160c46036df50060160c46036df
Device : naa.50060160c46036df50060160c46036df
IsPerenniallyReserved : false
IsPseudo : true

To set the device as perennially reserved, run this command:

$myesxcli.storage.core.device.setconfig($false, "naa.50060160c46036df50060160c46036df", $true)

To verify the parameter updates, run this command:

$myesxcli.storage.core.device.list("naa.50060160c46036df50060160c46036df")
AttachedFilters :
DevfsPath : /vmfs/devices/disks/naa.50060160c46036df50060160c46036df
Device : naa.50060160c46036df50060160c46036df
IsPerenniallyReserved : true
IsPseudo : true

To remove the perennially reserved flag, run this command:

$myesxcli.storage.core.device.setconfig($false, "naa.50060160c46036df50060160c46036df", $false)

ESXi 6.0 Hosts

For all ESXi 6.0 hosts, the command line, vSphere Client, and PowerCLI methods of setting the MCSC cluster RDMs to perennially reserved as covered in the three prior sections of this article are effective. 

Additional Information

For more information, see Obtaining LUN pathing information for ESX or ESXi hosts (1003973) and Using Tech Support Mode in ESXi 4.1 and ESXi 5.x (1017910).

Note: The PowerCLI and esxcli commands are case sensitive. If the naa.id is specified in uppercase letters when issuing the command, a new device is added on the ESXi host.

The resolution steps in this article are also known to resolve storage devices reporting NMP errors similar to:

 

WARNING: NMP: nmp_DeviceRetryCommand:133:Device "naa.600601604ec0360065efeed9d265e411": awaiting fast path state update for failover with I/O blocked. No prior reservation exists on the device.

For more information see:

Repeated characters when typing in remote console Fix

Repeated characters when typing in remote console (196)

Details

When typing into a remote console, you see unintended repeated keystrokes.

Solution

If you are using a wide-area or low-bandwidth connection, the time delay over the network may be long enough to cause the virtual machine to start auto-repeat.

To reduce these effects, increase the time threshold necessary for auto-repeat in the remote console.

1. Power off the virtual machine.
2. Add a line, similar to this, at the end of your virtual machine's configuration (.vmx) file:
   
   keyboard.typematicMinDelay = "2000000"
   The delay is specified in micro-seconds, so the line in the example above increases the repeat time to 2 seconds. This should ensure that you never get auto-repeat unless you intend it.
   
3. Power on the virtual machine.

To make the changes using the vSphere Client:

• Power off the virtual machine
• Right click virtual machine select Edit Settings
• Click Options > General > Configuration Parameters
• Click Add Row
• Under Name enter keyboard.typematicMinDelay In the Value field 2000000
• Click OK
• Power on the virtual machine 

http://www.purepowershellguy.com/

http://www.purepowershellguy.com/

Step-by-Step Configure DHCP Failover with 2012 R2

LINK

In Part 1, I provided with walk through of how to install DHCP and configure scope on your newly installed DHCP server. In this post, we are going to setup failover between two servers. I am assuming that two DHCP servers are installed and a scope is configure already.
So let’s go ahead and configure failover for given scope:

In the resulting dialog, you can either select all scopes that exist or select scopes you want to provide failover for:

On next page, you need to provide partner server. This is the server where scope information will be replicated to:

After selecting partner server, you need to configure failover relationship parameters (you can read more detailed description on TechNet article: http://technet.microsoft.com/en-us/library/dn338985.aspx):

• Relationship name is descriptive and can be anything that helps you identify the relationship
• Maximum client lead time defines how much time extension a partner server can provide to a client, based on time known by partner server
• Mode allows you to choose between hot standby mode and load balance mode. In hot standby mode only one server services DHCP requests from clients. Load balance mode allows both servers in partnership to serve DHCP clients
• If you select load balance mode, you can define how each server will serve DHCP clients by defining percentage per server
• State switchover interval controls how long standby server waits after losing communication with primary server before assuming active state and servicing DHCP clients. In load balance mode it may not be important factor as both servers can serve clients based on defined percentage of scope IP addresses. In Hot standby mode, it will be important to select, or the standby server will never switchover automatically
• To secure communications between DHCP partner servers, you have an option to enable message authentication between servers. If enabled, you must specify shared secret.

After configuring failover mode and parameters, you are provided with summary page:

When you click finish, you will see progress dialog, informing you of status of failover configuration steps:

If all steps are successful, you now have a working DHCP failover pair, with no clustering required! Cheers!

New Features ofWindows Server 2012 Failover Clustering

Windows IT Pro

John Marlin

Aug 22, 2012

Prepare for easier management, increased scalability, and more flexibility

In “Troubleshooting Windows Server 2008 R2 Failover Clusters,” I discussed troubleshooting failover clusters—specifically, the locations and tips for where you can go to get the data you need in order to troubleshoot a problem. The Microsoft Program Management Team looked at quite a few of the top problems and worked to improve them in Windows Server 2012 Failover Clustering. So this month, I’ll talk about the new features and functionality of Server 2012 Failover Clustering. The new changes for failover clustering offer easier management, increased scalability, and more flexibility.
 

Scalability Limits

One of the first things to talk about is scalability limits. With Server 2012 clustering, you now have a maximum limit of 64 nodes per cluster. If you’re running as a Hyper-V cluster with highly available virtual machines (VMs), the limit has increased to 4,000 VMs per cluster and 1,024 VMs per node. With these increased limits, Server Manager has been bolstered with the ability to discover and provide remote management capabilities. When you’ve configured a cluster, it will show all nodes, including the name of the cluster and any VMs on the cluster. In Server Manager, you would see where the remote management can be accomplished, as Figure 1 shows. With this capability, you can enable additional roles/features remotely.

Figure 1: Configuring remote management

A New Level of AD Integration

When you’re creating a cluster, you’ll experience a new level of detection about where the cluster creates an object in Active Directory (AD). When allowing the cluster to create the object, it will detect the organizational unit (OU) where the nodes reside and create the object in the same OU. It will still use the logged-on user account to create the Cluster Name Object (CNO), so this account needs to have Read and Create permissions on this OU. If you want to bypass this detection, or place it in a separate OU, you can specify that during the creation. For example, if I want to place the cluster name in an OU called Cluster, during creation I would input the data that Figure 2 shows.

Figure 2: Placing the cluster name in an OU called Cluster 

If you’re doing it through PowerShell, the command would be

New-Cluster “CN=WIN2012-CLUSTER,OU=Cluster,DC=Contoso,DC=com” –Node WIN2012-Node1,WIN2012-Node2,WIN2012-Node3,WIN2012-Node4

Quorum Configuration

The quorum configuration has been simplified, and a new dynamic quorum model is available—now the default when you’re creating a cluster. You can also manually remove nodes from participating in the voting. When you go through the Configure Cluster Quorum Wizard, you’re provided with three options:

·         Use typical settings (recommended)—The cluster determines quorum management options and, if necessary, selects the quorum witness.

·         Add or change the quorum witness—You can select the quorum witness; the cluster determines quorum management options.

·         Advanced quorum configuration and witness selection—You determine the quorum management options and the quorum witness.

When you choose the typical settings, the wizard will select the quorum type as dynamic. With a dynamic quorum, the number of votes changes depending on the number of participating nodes. The way it works is that, to keep a cluster up, you must have a quorum or consensus of votes. Each node that participates in a cluster is a vote. If you have also chosen to have a witness disk or share, that’s an additional vote. To keep the cluster going, more than half of the votes must continue to run. You can use the math equation of (total votes +1)/2. I have nine total nodes in a cluster without a witness disk. So, using the math equation above, it would be (9+1)/2 or 5 total votes to keep the cluster up.
 

So, for example, consider what occurs with a Server 2008 R2 cluster and a Server 2012 cluster. In a Server 2008 R2 cluster, using the same nine nodes in the cluster, this means that I have nine total votes and will need five votes (nodes) to remain going to keep the cluster up. If there are only four nodes up, the cluster service will terminate because there aren’t enough remaining votes. The administrator would need to take manual actions to force the cluster to start and get back to production. In a new Server 2012 failover cluster, when a node goes down, the number of votes needed to remain up also dynamically goes down. With my nine nodes (votes), if one node (vote) goes down, the total vote count becomes eight. If another two nodes go down, the vote count becomes six. The Server 2012 cluster will continue running and stay in production without intervention needed. Dynamic Quorum is the default and recommended quorum configuration for Server 2012 clusters.

Figure 3: Changing the quorum configuration
 

To change the quorum witness configuration, you can right-click the name of the cluster in the far left pane, choose More Actions, and select Configure Cluster Quorum Settings as Figure 3 shows. The wizard will let you set a disk witness, set a file share witness, or leave it as dynamic. If you choose the advanced settings, one of the first settings you’ll determine is what nodes actually have a vote in the cluster, as Figure 4 shows. All nodes participate with a vote to achieve quorum. If you de-select a node, it won’t have a vote. Using the earlier example of nine nodes, for Server 2008 R2 clusters, you have only eight voting members, so a witness disk or share would need to be added. In both Server 2008 R2 and Server 2012 clusters, this non-voting node doesn’t have a vote; if it’s the only node left, the cluster service will stop and manual intervention will be necessary.

Figure 4: Determining which cluster nodes have a vote 

When going through the Configure Cluster Quorum Wizard, the next screen shows the option where you can select or de-select the dynamic quorum option, as Figure 5 shows. As you can see from it, the default action is selected and is also recommended. If you want to change the quorum configuration to add a witness disk or share, the next screen in the wizard, Select Quorum Witness, is where you can choose the witness disk or share to use.

Figure 5: The Configure Quorum Management page 

Cluster Validation

There are some new cluster-validation enhancements. One of the big benefits is that storage tests will run significantly faster. The storage tests measure things such as which node can see the drives, determine failovers individually and as groups to all nodes, check to see if the drive can be yanked away from each node from the other nodes, and so on. In Server 2008 R2 failover clusters, if you had a large number of disks, the storage tests took a lot of time to complete. With Server 2012 cluster validation, the tests have been streamlined in their execution and in the speed they take to complete. A new option for the storage tests is that you can target specific LUNs to run the tests against, as you see in Figure 6. If you want to test a single LUN or a specific set of LUNs, just select the ones you want. There are also new tests for Cluster Shared Volumes (CSV) as well as for Hyper-V and the VMs. These tests check to see if your networking is configured with the recommended settings to ensure that network connectivity can be made between machines, quick/live migrations are set up to work, the same network switches are created on all nodes, and so on.

Figure 6: Reviewing your storage status 

Cluster Virtual Machine Monitoring

When you’re running highly available VMs with the Hyper-V role in a cluster, you can take advantage of a new feature called Virtual Machine Monitoring. With this new monitoring, you can actually have Failover Clustering monitor specific services within the VM and react if there is a problem with a service. For example, if you’re running a VM that provides print services, you can monitor the Print Spooler service. To set this up, you can:

1.    Right-click the VM in Failover Clustering.

2.    Choose More Actions.

3.    Choose Configure Monitoring.

4.    Choose the service or services that you would like to monitor.

If you want to set this up with PowerShell, the command would be

Add-ClusterVMMonitoredItem –VirtualMachine “VM Name” –Service Spooler

Failover Clustering will then “monitor” the VM and service through periodic health checks. If it determines that the monitored service is unhealthy, it will consider it to be in a critical state. It will first log the following event on the host. For example:
 

Event ID: 1250

Source: FailoverClustering

Description: Cluster Resource “Virtual Machine Name” in clustered role “Virtual Machine Name” has received a critical state notification. For a virtual machine this indicates that an application or service inside the virtual machine is in an unhealthy state. Verify the functionality of the service or application being monitored within the virtual machine.

It will then restart the VM (forced shutdown, but graceful) on the host that it’s currently running on. If it fails again, it will move it to another node to start. Virtual Machine Monitoring gives you a finer granularity of the kind of monitoring you want to have for your VMs. It also brings the added benefit of additional health-checking, as well as availability. Without Virtual Machine Monitoring, if a particular service has a problem, it would continue in that state and user intervention would be required to get it back up.
 

Cluster Aware Updating

Cluster Aware Updating (CAU) is new to Server 2012 Failover Clustering. This feature automates software updating (security patches) while maintaining availability. With CAU, you have the following actions available:

·         Apply updates to this cluster

·         Preview updates to this cluster

·         Create or modify the Updating Run Profile

·         Generate a report on past Updating Runs

·         Configure cluster self-updating options

·         Analyze cluster updating readiness

CAU will work in conjunction with your existing Windows Update Agent (WUA) and Windows Server Update Services (WSUS) infrastructures to apply important Microsoft updates. When CAU begins to update, it will go through the following steps:

1.    Put each node of the cluster into node maintenance mode.

2.    Move the clustered roles off the node. In the case of highly available VMs, it will perform a live migration of the VMs.

3.    Install updates and any dependent updates.

4.    Perform a reboot of the node, if necessary.

5.    Bring the node out of maintenance mode.

6.    Restore the clustered roles on the node.

7.    Move to update the next node.

You can start CAU from Server Manager, Failover Cluster Manager, or a remote machine. The recommendations and considerations for setting this up are as follows:

·         Don’t configure the nodes for automatic updating either from Windows Update or a WSUS server.

·         All cluster nodes should be uniformly configured to use the same update source (WSUS server, Windows Update, or Microsoft Update).

·         If you update using Microsoft System Center Configuration Manager 2007 and Microsoft System Center Virtual Machine Manager 2008, exclude cluster nodes from all required or automatic updates.

·         If you use internal software distribution servers (e.g., WSUS servers) to contain and deploy the updates, ensure that those servers correctly identify the approved updates for the cluster nodes.

·         Review any preferred owner settings for clustered roles. Configure these settings so that when the software-update process is complete, the clustered roles will be distributed across the cluster nodes.

Alternative Connections

In the previous versions, the only way you could connect to a share is with the Client Access Point (the network name in the group) because the shares were scoped to only this name. More information about this behavior is explained in the blog post “ File Share ‘Scoping’ in Windows Server 2008 Failover Clusters.” This limited the way administrators had clients connect to shares because there was only one option to connect. This was a big problem with administrators because, in some cases, it made server consolidations more difficult and time consuming because additional steps needed to be taken into consideration—which, in turn, led to longer downtimes to perform the consolidations. Because of this, Server 2012 Failover Clustering now gives you the ability to connect to shares via the virtual network name, the virtual IP address, or a CNAME that is created in DNS. One caveat is that when using CNAMEs, there is an additional configuration needed for the name. For example, suppose you had a file share with the clustered network name TXFILESERVER and you wanted to set up a CNAME of TEXAS in DNS to connect. Through PowerShell, you would execute
 

Get-ClusterResource “TXFILESERVER” | Set-ClusterParameter Aliases TEXAS

 When this is done, you must take the name offline and put it back online before it will take effect and answer the connection.

You need to consider the repercussions of connecting via the IP address or alias. When connecting via these methods, Kerberos won’t be the authentication method used because it will drop to using NTLM security. So, although connecting via these alternative methods does bring flexibility, the security trade-off for NTLM authentication must be taken into consideration.
 

CSV Updates

CSV has been updated with the following list of capabilities. These features provide for easier setups, broader workloads, and enhanced security and performance in a wider variety of deployments, as well as greater availability.

·         Storage capabilities for Scale-Out File Servers (more on this later), not just highly available VMs

·         A new CSV Proxy File System (CSVFS) to provide a single, consistent filename space

·         Support for BitLocker drive encryption

·         Direct I/O for file data access, enhancing VM creation and copy performance

·         Removal of external authentication dependencies when a domain controller (DC) might not be available

·         Integration with the new Server Message Block (SMB) 3.0 to provide for file servers, Hyper-V VMs, and applications such as SQL Server

·         Use of SMB Multichannel and SMB Direct to allow CSV traffic to stream across multiple networks, and use of network adapters that support Remote Direct Memory Access (RDMA)

·         Ability to scan and correct volumes with zero offline time as NTFS identifies, logs, and repairs issues without affecting the availability of CSV drives

Scale-Out File Servers

Scale-Out File Servers can host continuously available and scalable storage, by using the SMB 3.0 protocol, and utilizes CSV for the storage. Benefits of Scale-Out File Servers include the following:

·         Provides for active-active file shares in which all nodes accept and serve SMB client requests. This functionality provides for transparent failover to other cluster nodes during planned maintenance and unplanned failures.

·         Increases the total bandwidth of all file server nodes. There is no longer the bandwidth concern of all network client connections going to a single node; instead, a Scale-Out File Server gives you the ability to transparently move a client connection to another node to continue servicing that client without any network disruption. The limit to a Scale-Out File Server at this time is eight nodes.

·         CSV takes the improved Chkdsk times a step further by eliminating the offline phase. With CSVFS, you can run Chkdsk without affecting applications.

·         Another new CSV feature is CSV Cache, which can improve performance in some scenarios such as Virtual Desktop Infrastructure (VDI). CSV Cache allows you to allocate system memory (RAM) as a write-through cache. This provides caching of read-only unbuffered I/O that isn’t cached by the Windows Cache Manager. CSV Cache boosts the performance of read requests with write-through for no caching of write requests.

·         Eases management tasks. Is no longer necessary to create multiple clustered file servers where multiple disks and placement strategies are needed.

Scale-Out File Servers are ideal for SQL Server and Hyper-V configurations. The design behind Scale-Out File Servers is for applications that keep files open for long periods of time, as do most data operations. A SQL Server database or a Hyper-V VM .vhd file performs a lot of data operations (changes to the file itself), but doesn't perform a lot of actual metadata updates. It shouldn’t be used as a user data share where the workload has a high number of NTFS metadata updates. With NTFS, metadata updates are operations such as opening/closing files, creating new files, renaming existing files, deleting files, and so on, that make changes to the file system of the drive.
 

Always Improving

There are further enhancements, but I just don’t have the space to list them all. Our Microsoft Program Management Team has worked hard and listened to users about features they've been wanting from failover clusters, and the team has delivered. We've also taken some of the top issues seen in previous versions and made them into positives with the new version.