How do private switches work in a server cluster?
Physical systems are more popular than virtualization as they are easily manageable, especially when it comes to restoring procedures and backup. However, one advantage of virtualization over physical systems is its high availability.
Regardless of how many physical hosts are running your virtual network, it will always be available due to hardware redundancies, which is what server clustering offers its users. This type of server configuration reduces downtime and outages and increases availability by allowing other servers to take over when an outage occurs. With that said, let’s discuss some terms like virtualization, failover clustering, Hyper-V virtual switches, and other related terms.
What is a Server Cluster?
Server clusters are a collection of servers operating simultaneously and sharing a single IP address. Clustered server setups are generally used for file, message, print, and database networks, but can also be used for supercomputing and crunching big numbers. Clusters improve data security and sustain the consistency of the cluster configuration over time.
In a clustered server environment, each server owns and manages its own devices and has a copy of the operating system used to run other servers in the cluster. There are different types of server clusters classified based on how the node is connected to the device responsible for storing configuration data. The different types of server clusters are single node cluster, majority node set cluster, and single quorum cluster.
Read more about server cluster configuration.
Hyper-V Failover Cluster
A failover cluster is a collection of groups of related Hyper-V servers, also known as nodes, that can be designed appropriately to interact such that one node can take on the load (VMs, services, and processes) when one node fails.
Examples of failover clusters are Microsoft SQL Server, Microsoft Exchange Server and Hyper-V, and other clustered services that run on Microsoft Windows. However, a system administrator can manually test a planned failover by moving from one node to another, or a failover cluster service can do it automatically in the event of an unplanned calamity (unplanned failover).
The Hyper-V failover clustering provides excellent scalability. When you are ready to add another server, a system wizard will make it simple to add it to the cluster on the fly without any complex reconfigurations or downtime. To prevent single points of failure and maintain high availability, all the components in the network must be redundant.
Hyper-V Virtual Switch
Hyper-V Virtual Switch is virtual software and operates within the active memory of a Hyper-V host, performing the functionality of Ethernet frame switching. To communicate with other computers on the physical network, it uses a single or collection of physical network adapters, which serve as uplinks to a physical switch. However, Hyper-V supplies virtual network adapters to its virtual machines to enable direct communication with the virtual switch. Types of Hyper-V virtual switches are internal, external, and private switches.
Private Switches
A Hyper-V private switch is a virtual switch that only allows communication between virtual adapters connected to virtual machines within a data center environment. Aside from the private switch, there are other operation modes for the Hyper-V virtual switch: the internal virtual switch and the external virtual switch. A private switch is a virtual switch that isolates the virtual machines completely, with no network switching between the virtual machines and the Hyper-V host.
How do Private Switches Work on Server Cluster?
To better understand how private switches work on a server cluster, it is essential to know that the private switch is not a clustered role. This means that the private switch is aware of the cluster, but the cluster is unaware of the virtual switches.
In this case, whenever you try to move a virtual machine from one cluster node to another cluster node, the private switch will carry out a “pre-flight” check. One of the “pre-flight” checks involves searching for a virtual switch on the destination host that shares the same name as each virtual switch to which the migrating virtual machine connects.
However, private switches won’t migrate the virtual machine if the target host doesn’t have a virtual switch with a similar name. The option to employ “resource pools” of virtual switches is available with Hyper-V versions 2012 and later; in this instance, the name of the resource pool will be tried to match instead of the switch’s name, but the name-matching rule still holds.
A clustered virtual machine connected to an internal or private virtual switch cannot be Live Migrated with the 2012 version. Even if the target host shares the same name switch, it can’t be connected, and the pre-flight check will be unsuccessful. There could be a brief service interruption when a clustered virtual machine is live migrated. Hence, you must unregister the MAC address(es) of the virtual machine(s) from the source virtual switch (and consequently from its attached physical switch) and re-register them at the destination.
A similar de-registration and registration process will occur if you use dynamic MAC addresses. In this case, the MACs may be returned to the source host’s pool and replaced with new MACs on the destination host. In-flight TCP communication should proceed without a significant hitch as long as all of the above occurs inside the typical TCP timeout window.
This will result in the loss of UDP and all other non-error-correcting traffic, such as ICMP and IGMP operations like PING. The time it takes for the MAC modifications to spread throughout the network will determine how quickly the private switch performs the de-registration and registration.
It is essential to know that private virtual switches do not surpass an external virtual switch in terms of performance. This is because the virtual switch is perceptive enough to send packets from one virtual adapter to the MAC address of another virtual adapter on the same virtual switch without using the physical network. On the other hand, if layer three traffic must go through an external router, traffic may leave the host before returning.
Conclusion
One of the reasons why you should use private virtual switches on your server cluster is its isolation features. You can be guaranteed that no traffic that travels on a private switch will ever leave the host. However, you can partially isolate your guests by putting a virtual machine with routing capabilities on the isolation network(s) and an external switch.
At ServerMania, we provide server cluster hosting that guarantees high performance for your business and a wide range of fully customizable dedicated, cloud, hybrid, IP Transit services, and colocation to help boost your hosting performance at all levels.
Contact us today for more information or a free consultation.
About the author
