Failover Clustering and Network Load Balancing Team Blog
Hi Cluster Fans,
As you may already know, the requirements for having a supported cluster have been significantly simplified since the release of Windows Server 2008. There is no longer a need to have every component in the configuration listed in the Windows Server catalog as any commodity hardware should now support clustering. However it is required that every component receives a Windows Server 2008 (R2) logo and the entire solution passes the built-in “Validate a Configuration” (“Validate”) suite of tests.
Validate (Step by Step Guide) can be run at any time once the Failover Clustering feature has been installed, including before the cluster has been deployed, during cluster creation and while the cluster is running. In fact, additional tests are executed once the cluster is in use which check that best practices are being followed for the highly-available workloads. However, according to the Microsoft Support Policy for Failover Clusters, the “Validate test should also be run whenever a major component of the cluster is changed or updated. The following are examples…Adding a node to the cluster; Upgrading or replacing the storage hardware; Upgrading the firmware or the driver for host bus adapters (HBAs); Updating the multipathing software or the DSM; Changing or updating any network adapter…” So how can you minimize the impact of Validating a cluster while it is in production?
When the “Validate a Configuration” wizard is launched it offers the choice to run all tests or a subset of tests. With this granularity it is possible to select all the tests which do not impact the cluster and skip those which can impact high-availability for a group. In fact almost all of the tests can be run while the cluster is online, without impacting anything running on the cluster, other than a slight performance hit due to processing the tests themselves. There are five categories of tests:
Across these dozens of tests, only a few of them will impact running cluster workloads and these are all within the storage category, so skipping this entire category is an easy way to avoid disruptive tests. Listing All Disks and Potential Cluster Disks will not impact anything. Validating Disk Access Latency, File System, Microsoft MPIO-based disks, and SCSI device Vital Product Data (VPD) can impact the disk’s performance as tests are performed against the disk which is in use, however they will cause no downtime unless the disk latency becomes so slow that it triggers an alert. Several tests will actually trigger failovers and move the disks and groups to different cluster nodes which will cause downtime, and these include Validating Disk Arbitration, Disk Failover, Multiple Arbitration, SCSI-3 Persistent Reservation, and Simultaneous Failover. So if you want to test a majority of the functionality of your cluster without impacting availability, exclude these tests.
Failover Clustering does come with a built-in safeguard to prevent accidental downtime when running the storage tests in Validate. If the cluster has any online groups when Validate is initiated, and the storage tests remain selected, it will prompt the user for confirmation whether they want to run all the tests (and cause downtime), or to skip testing the disks of any online groups to avoid downtime. If the entire storage category was excluded from being tested, then this prompt is not displayed. This will enable cluster validation with no downtime, but of course it is not complete as some of the tests have been skipped, yet according to the Microsoft Support Policy “the proposed solution must pass the full Validate test.” So what happens if you need to test your storage, yet all of your disks are being used by running workloads? Or how do you test that your Windows Server 2003 storage will work after a migration without actually impacting your production 2003 cluster.
This can be done by simply creating a new cluster disk from the same storage array, exposing it to all nodes and running all tests against just that disk. This gives you the benefits of running Validate against that type of disk to ensure that it will work while not risking any downtime to production workloads. This can be done by running Validate, selecting all the tests, but keeping any running services or applications online.
Now you can feel confident that your disks should work on your new cluster! It is still important to note that the support policy technically requires the entire configuration to be tested (including all disks), so if you have a storage-related issue and have not run Validate against all disks you may be asked to do so. Nevertheless this is still a great approach to Validating your cluster after a configuration change or migration with minimal impact.
Thanks,Symon PerrimanTechnical EvangelistPrivate Cloud TechnologiesMicrosoft
I have a question about creating another disk array, is there any size limitations or suggestions about other disk?
I am about to upgrade firmware, drivers etc on a 2 node failover cluster running Windows 2008 enterprise.
I was going to upgrade the passive node first then failover and upgrade the other node. I will be upgrading a lot of stuff
Dell Firmware and Drivers
Emulex Firmware and Drivers
Do I need to stop the cluster service on the passive node before? I guess will have to use your procesdure to run a complete validtion test after if I do not want down time.
Our problem with running validation against production CSVs is that out of the last 3 times we have run cluster validation tests we have lost partitions twice on random CSVs. This resulted in Premier calls to use DiskProbe2 tool to do low level partition table editing to bring the data back. Very scary. We installed KB2531907 on all hyper-v cluster nodes and still lost a CSV partition when running validation tests again. We have had long-running support calls with both Microsoft and HP and neither can tell us why this is happening. They also both struggle to explain why the validation test complains about a persistent reservation on the witness disk but yet we can change the ownership of the witness disk without problem. We have run the clear-clusterdiskreservation command but are very wary of running validation again due to possibility of CSV partition loss.