Server Redundancy Made Easy & Affordable: Failover Clustering for Hyper-V 2012 [50:42]
Learn how to create and maintain a failover cluster in Windows Server® 2012 R2. Join Bill Hersh, D&H Solutions Coordinator, as he walks through the process of setting up a failover cluster in Windows Server® 2012 R2. Previously an expensive, high-end, and complex solution, clustering has been simplified to the point where it can be just as valuable in SMB as in enterprise solutions. Just as importantly, it is now simple to create and maintain a server cluster, so the effort required is minimal to add this level of fault-tolerance and redundancy to your client offerings. When will you be addressing failover cloud-storage, and options? What backend storage were you using? Or did you just use internal (local) storage for this demonstration? Can the failover cluster be separated geographically, to protect against physicals disasters (fire, flood, etc.)? How can they be networked reliably (how big of a pipe is needed)? What is the minimum hardware requirements for failover? Can you get this done with two servers? Is a NETGEAR ReadyNAS® supported? How can I figure out the bandwidth requirements of a Line of Business program if I want to separate the nodes of a failover cluster geographically? A SMB CPA office, using Lacerte, Quickbooks, etc; how can I figure out the bandwidth pipes needed? Do both physical servers need full Windows Server® licenses? You said in the webcast that if you don't have three servers and one fails you lose some failover functionality. Can you explain this in more detail? What are the major differences between Windows Server® 2012 R2 and Standard? Do the systems have to be exactly alike to be clustered? Why would any customer want to spend the money on two (or more) servers for one workload? Can I cluster older versions of Windows Server®? Is clustering only useful for virtualized environments? Is there a difference between Clustering and Load Balancing? Feel free to contact the Solutions Lab team at: solutionslab@dandh.com or contact Solutions Lab team members individually at their contact information below: whersh@dandh.com mallison@dandh.com tschubert@dandh.com
We expect to be doing videos on failover storage and other associated redundancy options in the next month or so. They will likely be recorded as video shorts, so please remember to check back, as they will not be broadcast.
For this demonstration, we're using a Netgear ReadyNAS® RN2120 1U rack-mount unit. We recommend using external storage with a clustered environment, since internal storage on a failed node would become inaccessible.
Yes, you can build a cluster out of servers at geographically disparate locations. We recommend that you plan to use high-speed connections for this practice, as the nodes need to stay in sync and line latency between distant nodes can lead to a breakdown in the cluster's effectiveness.
Minimum hardware requirements for failover are two identical servers and a file share on some third network location.
Not only supported, but in use on the demonstration systems.
You'll be able to see this by checking network traffic on a similar stand-alone system. If you have these applications currently running on a system, track the network traffic experienced by that server, then plan on connections to remote servers that will support slightly higher traffic than this to account for including the cluster communications, as well.
Yes, all physical servers in a cluster require full server licenses.
The nodes of a cluster stay in constant communication in order to maintain their identical profiles and to keep up with what each other are currently doing. They need to do this in order to be able to pick up the workload from a failed node with no lost data and no downtime. If you only have two servers, you need a file share somewhere on the network that serves as a consistency check, charged with maintaining record of everything that the nodes do. This share, called a "witness", is required to reach a "quorum", which is needed to complete the cluster.
Far too many to list here. The most complete list that I've found is at http://technet.microsoft.com/en-us/library/dn250019.aspx.
Yes, all nodes of a cluster need to be identical, both software and hardware.
Redundancy, resilience, and uptime. Don't assume that a customer won't spend the money for this, if they really need for their application to be up 24/7/365.
Yes, but the process is much more complex, and managing the cluster is far more difficult.
No, there are a number of cluster-ready applications available that can be installed as the main workload on a cluster. We simply recommend using virtualization and clustering because it offers the most flexibility for most customers.
Clustering means you run a system on several machines or nodes. Today's video was about one specific feature of a cluster; Failover. Another feature available to users who implement a cluster is Load Balancing. Load balancing is a method for distributing workloads across multiple computers so that more work can be completed in the same amount of time. In general, users get served faster with this method as well.Bill Hersh, Solutions Coordinator
800.877.1200, Extension 7626Matt Allison, Solutions Specialist
800.877.1200, Extension 7974Trevor Schubert, Solutions Specialist
800.877.1200, Extension 7976