The goal of fail-over is to allow work that would normally be done by one server to be done by another server should the regular one fail.
For example, Server A responds to all requests unless it has a hardware failure, or someone trips over its network cable, or the data center it is located in burns to the ground. And if Server A cannot respond to requests, then Server B can take over.
Manually triggering a failover can also allow you to safely perform maintenance on the primary servers without interupting your service.
To implement fail-over you typically need to have your data replicated across multiple machines. You could do this via rsync+cron for files/directories. And via something like MySQL replication for databases.
One way to trigger the fail-over is to change the IP address your domain points to. IP address changes can happen within a few minutes of a DNS server update, though there are situation where clients may use old DNS records for longer
There are some services like our https://pingability.com that can detect a failure and automatically update the DNS for you.
Except in rare cases (eg a very custom deployment), we directly control our network equipment. Which helps us ensure your setup will keep working reliably and without interuption.
Load Balancing is different from failover, though elements of both may be used together. It is possible in some cases to 'scale vertically', by simply moving to more capable hardware such as quicker disks, a faster CPU or a fatter network pipe. But that may only be a temporary solution.
One simple way to distribute load is to split services into layers. e.g. running a web service on one server and a database service on another. This simple but important step helps set the stage for managing those services independantly. For example deciding which necessary files are on the web servers, while necessary database data is on the database server.
Load balancing becomes a factor if you need to spread each layer of services out to more than one machine for performance, higher demand. Or a need to guarantee a higher level of service avilability than a single machine could offer.
Another way to distribute requests is to have a single virtual IP (VIP) that all clients use. And for the computer on that 'virtual' IP to forward the request to the real servers. eg with haproxy.
Load balancing software ranges from setting up web servers to share work across backend servers, eg apache mod_proxy_balancer, nginx. Or using dedicated proxy software like haproxy, up to more specialised software that handles just that distribution layer.
We can help setup file system replication or other storage solutions. And we can with database replication.
We also provide integrated external monitoring from https://pingability.com that can perform failover tasks.
If you want to implement simple failover, the secondary server could be in a separate data center. e.g. have your primary server in Dallas and the failover server be in London. We provide servers globally so you can have more options.
One issue with fail-over is when switching back to the primary server. Say your main server fails. You switch over to the backup server. Your customers use that server. The files and database on that server are updated.. When the main server comes back those changes would need to be reflected on the main server. e.g. by syncing data back to the primary. Setting up bi-directional replication can simplify this. We can aid with the setup and management of a cluster so you dont have to to insure that will work the way you expect.
We usually recommend load balancing be implemented on dedicated hardware. On our shared hosts a busy service might see contention or performance issues which can lead to unexpected behaviour with the load balancing.
We offer dedicated servers which are ideal for high demand services.
If you have multiple dedicated servers in one data center then we can also help setup load balancing with advanced solutions like LVS (see http://www.linuxvirtualserver.org/) or pacemaker+corosync as described at http://www.clusterlabs.org. There are newer solutions that use containers as well (eg docker/kubernetes)
We can also implement dedicated private network options that lets your servers communicate more securely, and without the traffic needing to go over the public internet.
An older (but still sometimes useful) technique is IP failover. This is where a 'heartbeat' process runs on your servers. And in the event one server fails to see the heartbeat of the other side, it takes over a shared IP address. i.e. tries to make that IP route to itself. Then requstes to that ip will hit the backup server instead.
Often IP takeover is implemented when two servers are very closely connected, or on the same switch.
RimuHosting does allow IP takeover, just please do let us know if you implement this so we can configure our network monitoring appropriately.
We have had a few people ask about clustered or shared file systems. Ideally you would have a simple shared file system that any server could write to, that was highly redundant, available 100% of the time, and distributed safely across underlying hardware.
In the real world to do this you need a clustered file system. That can can co-ordinate safe disk access from different sources. There are many good solutions but they do take a bit more work to setup and validate. And may also need specific monitoring and software that uinderstands how to talk to such a setup.
Depending on your requirements this sort of solution can range anywhere from a few small servers to larger cabinet sized deployments. We can help set you up with a solution that fits your budget.
LaunchtimeVPS : Server hosting service. A Rimu Hosting Ltd business. RimuHosting services include:
© RimuHosting Ltd 2002-2025. Rimuhosting, Launchtime and the Rimuhosting logo are RimuHosting™ trademarks.
launchtimevps.com