Tech Support

100% white labeled, US based 24/7 phone support for web hosts and web designers.

How we achieved high uptime in VPS hosting using oVirt high availability configuration

How we achieved high uptime in VPS hosting using oVirt high availability configuration

On Oct 10, Google Drive and Google Docs went down for 3 hours. Google services has been synonymous with high uptime, and a lot of people even used (and still use) Google.com to check if their laptop connection is up. So, predictably, the internet had a meltdown over it. 

high uptime vps ovirt Google Down

No Google! What now?

A reaction like this is a far cry from how things were just 5 years back. People didn’t mind an online service being unavailable for a few mins, or even a couple of hours. That’s not the case any more. Downtimes are rare, and internet users expect 100% uptime for every website they access.

See how our WHMCS oVirt plugin helps you!

To meet this demand, website owners now insist on high uptime from their hosting providers. This is especially true for premium hosting services such as VPS hosting and Cloud hosting.

In a recent post, we covered how we used oVirt to implement a competitive VPS hosting solution. Today we’ll go a bit further into how we achieved 99.9% uptime by configuring oVirt for high availability.

How high availability works in oVirt

The oVirt system is centrally managed by a server called oVirt engine. The oVirt engine keeps tabs on each server in the hosting system. If a server (say Node 01) becomes unreachable, all VPS running in that server would be transferred to other servers in the system. Users of those VPS would notice a small break in services, but everything would be back online in a couple of minutes.

This works because operating system and application information of all VPS are stored in a shared storage space accessible by all servers. As you can see in the image, “Node 01”, “Node 02” and “Node 03” access the same “Shared storage”. So, VMs in “Node 01” can work equally well in “Node 02” or “Node 03” as long as the “Shared storage” is accessible from those servers.

Architecture to enable high uptime in VPS hosting

When the host “Node 01” fails, the VMs in “Node 01” is automatically migrated to “Node 02” and “Node 03”.

For high availability to work in oVirt, there were a few pre-conditions to be met. This includes a highly available shared storage device, power management on all servers, and surplus resources on all servers to accommodate VMs from other servers. Let’s take a look at them one by one.

[ Looking for custom plugins to manage your portals? Contact us to get tailor-made plugins to serve your business purposes. ]

Configuring shared storage

A shared storage is at the core of a highly available system. Unlike traditional dedicated servers, VPS in a highly available cluster store their operating system and applications in an external, high-speed storage device that sits outside the servers.

So, even if a VPS’s host server goes down, the storage device remains online. It is then just a matter of starting the VPS in another host server to bring the services back online.

In the cloud system we implemented, one of the shared storage devices we used was a RAID 10 array. All servers in the VPS system had access to this storage device. This made it possible for all VPS using that shared device to run off any host server in the cloud.

We chose a high-speed, redundant storage device such as RAID 10 array for this purpose because high availability would work only if the storage device remains online at all times.

[ You don’t have to lose your sleep to keep your customers happy. Get the best tech support specialists to care for your customers 24/7. ]

Configuring power management on hosts

As mentioned earlier, oVirt is centrally managed by a server called oVirt engine. It is the oVirt engine’s job to detect if a server has gone down, and initiate a VPS transfer.

Now, consider a scenario where the network cable between oVirt engine and a cloud server is cut, but the cloud server is still connected to the shared storage device. The oVirt engine would think that the server is offline and create clones of VMs in that server on other cloud servers. This will essentially corrupt the data of all the VMs hosted on that cloud server.

To avoid this situation, oVirt REQUIRES that power management be accessible on all cloud servers for high availability to function. When oVirt detects a cloud server to be offline, first it’ll try to shutdown the server by turning off the power. ONLY IF the power shutdown is a success, will it attempt to put the VMs on another server.

So, before we enabled high availability in VMs, we configured power management for all servers in the cloud. It is done by navigating to “System” –> “Data Centers” –> “Clusters” –> “Hosts” –> “Edit”. The power management fields were filled in as shown here:

oVirt VPS hosting host power management

oVirt host power management

 

Planning surplus resources to accommodate fail-over VMs

Let’s say there are 25 VMs in a cloud server called “Node 01”. These VMs would be allocated CPU and Memory resources that are carved from “Node 01’s” CPU and Memory capability. Now, let’s say the 25 VMs are allocated 50 GB of memory and 30 CPU cores in total. Then, for high availability to work, the rest of the servers in the cloud system should have a SURPLUS capability of 50 GB RAM and CPU cycles equaling 30 CPU cores.

For example, in the cloud system we implemented, we started off with 3 cloud servers which had 32 core CPUs and 64 GB RAM memory. The maximum resource that we could allocate on one server was 45 GB memory and 25 CPUs (with a bit of overselling). This allocation policy left ample space for VMs from one failed server to be evenly distributed over the other two.

[ Looking for the WHMCS plugin to manage your oVirt interface? Get our WHMCS plugin for oVirt management here. ]

Enabling high availability

Once the shared storage, power management and surplus resource planning was completed in the oVirt system, the VPSs were then ready to be enabled with “High Availability” fail-overs.

To do this, we enabled the “Highly Available” option under “System” –> “Data Centers” –> “Clusters” –> “VMs” –> “Edit” –> “High Availability”. Based on the hosting plan, the priority of fail-overs were selected in that interface. In case of a server failure, a VM marked as “High” priority would be started first, thereby minimizing downtime.

High uptime in VPS using oVirt high availability configuration

oVirt VPS high availability configuration

 

High availability is a core feature in any VPS hosting solution. Here we’ve covered how high availability was implemented for a VPS hosting system using oVirt. Bobcares helps web hosts, VPS providers and cloud providers deliver industry standard VPS services through custom configuration and preventive maintenance of virtualized systems.

 


ENSURE ZERO DOWNTIME SERVICES

Guaranteed 100% uptime for your servers & 24/7 support for your customers!

GET IN TOUCH WITH THE 'BEST IN INDUSTRY' SUPPORT

ovirt

Submit a Comment

Your email address will not be published. Required fields are marked *

Bobcares
BUSY WITH TECH SUPPORT ALL DAY? We help web hosts and other web solution providers save time and focus on growth.
Here's how we helped a web host reduce support engagement time from 3 hours to 30 mins per day:
SEE CASE STUDY

Privacy Preference Center

    Necessary

    Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

    PHPSESSID - Preserves user session state across page requests.

    gdpr[consent_types] - Used to store user consents.

    gdpr[allowed_cookies] - Used to store user allowed cookies.

    PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
    PHPSESSID
    WHMCSpKDlPzh2chML

    Statistics

    Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

    _ga - Preserves user session state across page requests.

    _gat - Used by Google Analytics to throttle request rate

    _gid - Registers a unique ID that is used to generate statistical data on how you use the website.

    smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

    _ga, _gat, _gid
    _ga, _gat, _gid
    smartlookCookie

    Marketing

    Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

    IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

    test_cookie - Used to check if the user's browser supports cookies.

    1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

    NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

    DV - Google ad personalisation

    IDE, test_cookie, 1P_JAR, NID, DV, NID
    IDE, test_cookie
    1P_JAR, NID, DV
    NID