SIOS SANless clusters High-availability Machine Learning monitoring
What happens in a SQL Server disaster? Here’s your chance to be part of the action.
This webinar guides you through a few simulated disasters of SQL Server. Walk away from this webinar with a DR plan and a checklist to ensure your business operations run as expected in the event of an outage.
Windows Server has a new UserVoice page: http://windowsserver.uservoice.com/forums/295047-general-feedback with subsections:
This is where YOU get to provide Microsoft with your feedback directly.
Reproduced with permission from https://clusteringformeremortals.com/2015/05/12/microsoft-wants-your-input-on-the-next-version-of-windows-server/
Before we get started with all the great new cluster quorum types in Windows Server 2012 R2, we should take a moment and understand what it does and how we got to where we are today. Rob Hindman describes quorum best in his blog post…
“The quorum configuration in a failover cluster determines the number of failures that the cluster can sustain while still remaining online.”
Prior to Windows Server 2003, there was only one quorum type, Disk Only. Now there are different cluster quorum types. Disk Only is still available today, but is not recommended as the quorum disk is a single point of failure. In Windows Server 2003 Microsoft introduce the Majority Node Set (MNS) quorum. This was an improvement as it eliminated the disk only quorum as a single point of failure in the cluster. However, it did have its limitations. As implied in its name, Majority Node Set must have a majority of nodes to form a quorum and stay online. So, this quorum model is not ideal for a two node cluster where the failure of one node would only leave one node remaining. One out of two is not a majority, so the remaining node would go offline.
Microsoft introduced a hotfix that allowed for the creation of a File Share Witness (FSW) on Windows Server 2003 SP1 and 2003 R2 clusters. Essentially the FSW is a simple file share on another server that is given a vote in a MNS cluster. The driving force behind this innovation was Exchange Server 2007 Continuous Cluster Replication (CCR), which allowed for clustering without shared storage. Of course, without shared storage a Disk Only Quorum was not an option. Effective MNS clusters would require three or more cluster nodes. Hence, the introduction of the FSW to support two node Exchange CCR clusters.
Windows Server 2008 saw the introduction of a new witness type, Disk Witness. Unlike the old Disk Only quorum type, the Disk Witness allows the users to configure a small partition on a shared disk that acts as a vote in the cluster, similar to that of the FSW. However, the Disk Witness is preferable to the FSW. This is because it keeps a copy of the cluster database and eliminates the possibility of “partition in time”. If you’d like to read more about partition in time, I suggest you read the File Share Witness vs. Disk Witness for local clusters.
Windows Server 2012 continued to improve upon quorum options. It is my belief that many of these new features were driven by two forces: Hyper-V and SQL Server AlwaysOn Availability Groups. With Hyper-V, we began to see clusters that contained many more nodes than we have typically seen in the past. In a majority node set, as soon as you lose a majority of your votes, the remaining nodes go offline. For example, if you have a Hyper-V cluster with seven nodes, and you were to lose four of those nodes, the remaining nodes would go offline, even though there are three nodes remaining. This might not be exactly what you want to happen. So in Windows Server 2012, Microsoft introduced Dynamic Quorum.
Dynamic Quorum does what its name implies. It adjusts the quorum dynamically. So in the scenario described about, assuming I didn’t lose all four servers at the same time, as servers in the cluster went offline, the number of votes in the quorum would adjust dynamically. When node one went offline, I would then in theory have a six node cluster. When node two went offline, I would then have a five node cluster, and so on. In reality, if I continued to lose cluster nodes one by one, I could go all the way down to a two node cluster and still remain online. And, if I had configured a witness (Disk or File Share) I could actually go all the way down to a single node and still remain online.
Read more about cluster quorum types at….
Reproduced with permission from https://clusteringformeremortals.com/2014/04/29/understanding-the-windows-server-failover-cluster-quorum-in-windows-server-2012-r2/
With the launch of Windows Server 2008 R2 and the interest in DataKeeper replication solutions for Hyper-V, I have been pretty busy – which is a good thing! Recently, I have been speaking with some Microsoft Gold Partners who are busy installing Hyper-V at their customer locations and looking at some of the disaster recovery options, including multi-site Hyper-V clusters with SteelEye DataKeeper Cluster Edition. Many of the questions are the same each time and the demonstration is always the same. I figured it may be beneficial to produce a video that talks specifically about one of the questions – the difference between Live Migration and Quick Migration and when to use one vs. the other. This video that demonstrates Live Migration and Quick Migration while discussing some of the things to consider may be of interest to you.
With the release of Windows Server 2008 R2, one of the enhancements was improving the performance of dynamic VHD files. Prior to R2, writes to dynamically expanding VHD files could be 3x slower than writes to a fixed size VHD file due to limited meta data caching. Overall, Microsoft is claiming the performance of dynamic VHD files vs. fixed size VHD files is almost identical.Pass-through disks are another option when configuring a Hyper-V VM. According to my results, the performance of a pass-through disk is marginally better than that of VHD files. However, if you use pass-through disks you lose all of the benefits of VHD files such as portability, snap-shotting and thin provisioning. Considering these trade-offs, using pass-through disks should really only be considered if you require a disk that is greater than 2 TB in size or if your application is I/O bound and you really could benefit from another .1 ms shaved off your average response time.
I figured rather than taking Microsoft’s word for it, I would put these different disk types to the test for myself. I set up a Hyper-V Windows Server 2008 R2 virtual machine running on top of Windows Server 2008 R2. For my Hypervisor, I used Dell PowerEdge 1950 server attached to a Dell AX150 SAN and carved off three 10 GB LUNs for use in my test. In Hyper-V Manager, I added three new disks, one pass-through, one dynamic VHD and one fixed-size VHD. I then used IOMeter to test the performance of the disks. The test parameters and raw data can be found in this CSV file.
The charts below summarize my results. As you can see, on the extremes (Maximum/Minimum), the pass-through disk wins in most cases. However, on average, there is almost no difference between the performances of the three different disk types.
The benefit of thin provisioning, meaning building a VHD file or multiple VHD files with a combined size that is greater than the available disk space, and the portability of VHD files make dynamically expanding VHD files the obvious choice for most Windows Server 2008 R2 virtual machines.
In summary, I’d strongly consider the use of dynamically expanding VHD files for your next Hyper-V deployment on Windows Server 2008 R2.
Reproduced with permission from https://clusteringformeremortals.com/2009/09/25/hyper-v-pass-through-disk-performance-vs-fixed-size-vhd-files-and-dynamic-vhd-files-in-windows-server-2008-r2/