Provide a single point of contact for a large-scale system consisting of many virtual machines so that they are viewed as one giant VM from outside
Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.
As Known As
When a system becomes big, you need multiple VMs to support the workload. For ease of use reasons, external users don’t want to manage multiple connections to each of the virtual machines. Who wants to remember a list of IP or DNS names for a service? Also, you just cannot expect your users to pick up the least-busy VMs for balanced workloads across your cluster of VMs. And to scale your application when your overall workload increases, you want a seamless way adding new capacities without notifying others.
Finally, if you offer a public service, you don’t want to allocate a public IP address for each of your VMs. These days, public IPs are scarce resources and may cost you money.
To solve these problems, you want to designate a VM as the façade of your cluster of VMs. From an external perspective, users or applications can see only one giant virtual machine providing service.
The façade VM gets allocated a well-known IP address and registered with DNS servers. If it’s a publicly available service, the façade VM gets one public IP address.
Behind the façade VM, each other VM is assigned a private IP address and made known to the façade VM. When a request comes in, the façade VM can quickly process it and forward it to backend VMs for further processing, as shown in Figure 1.
Figure 1 Façade VM and backend VMs
As you can see from Figure 1, two participants are involved:
- Façade VM: its IP and service ports are well known to everyone;
- Backend VM (worker VM): these play different roles with data feeds from the façade VM upfront. There could be many instances. All are hidden from external view.
The criteria that decide which backend VM server to forward to include:
- The functionality. The backend servers can be divided with different roles to serve specific requests. The service can be identified with a port number for fast processing. Ideally they should be uniform for easy development and management.
- The workload. For the VMs with the same roles, the façade VM can send a request to a least-busy VM. It can be simply based on the total number of requests, not necessarily the real VM workload you can find from the hypervisor hosting it. Most of time, this approach should be good enough.
For load balancing, the façade VM can delegate the traffic routing work to existing high performance load balancer appliances in data centers while still maintaining the management responsibilities.
The façade VM should monitor the health of the backend VMs. When any of them dies, the façade VM should remove it and add a new VM.
Usethe façade VM to:
- Group VMs together like a single giant VM;
- Simplify user experience of VM clusters;
- Achieve better availability of your application;
- Balance workloads to different VMs running in the backend;
- Scale your application seamlessly by adding more backend VMs;
- Save public IP addresses.
While it’s a good idea to have a single point of contact, it’s also a risk as it could be a single point of failure. For mission critical applications, you will want to have a hot standby backup for the façade VM. At a minimum, you need an auto restart for the façade VM.
For public services, it would be hard for developers and system administrators to directly access–for example, using SSH–the backend VMs. The related ports are mostly not open for security reasons. Even if they are open, you cannot connect to a particular backend server because there is no one-on-one mapping from public IPs to the private IPs of the VM of your interest. In that case, you most likely have to use VPN so that you can “see” private the IP addresses of all backend VMs.
Most cloud service providers offer load balancing features so that you can design the façade VM easily without affecting performance. Amazon EC2, for example, offers load balancing features.
Not all load balancing mechanisms are the same. Terremark vCloudExpress, for example, provides a unique feature in which you can map each port of a public IP address to a group of virtual machines. This allows maximum use of a public IP address.
VM Pool: you can get VMs from VM pool during peak hours and return them during off peak hours.
Stateless VM: you can leverage this for the backend servers.