What is server redundancy?
Redundancy is often seen as a negative term, but in when it comes to IT – and infrastructure in particular – it’s a very important consideration.
IT-wise, redundancy is the “duplication of critical components or functions of a system with the intention of increasing reliability of the system, usually in the form of a backup or fail-safe, or to improve actual system performance, such as in the case of GNSS receivers, or multi-threaded computer processing,” according to Wikipedia.
If you have production servers in your organization, having redundant servers is a must. A redundant server is deployed for backup, load balancing, or maintenance reasons.
Server redundancy is instigated in an enterprise IT environment where server availability is really necessary. A redundant server uses the same compute capacity and storage as well as having the same applications running and the same configuration.
A redundant server stays offline and is not used as a live server until it is needed. That said, it is powered up and has network connectivity so it can spring into action when required.
When failure, downtime or excessive traffic happens to a live production server, the redundant server can be deployed to either take the place of the production server or share its traffic load to minimize problems.
However, it can double both the cost of having a server and its running costs. Importantly, you will also need space for two servers.
Why is it important?
When faced with a disaster, the difference between an organization that survives and one that fails, is down to the effectiveness of their DR strategy – not just in theory but in implementation.
As such, redundant servers should be an essential part of wider DR plans. After all, access to your server and the data on it will be critical in the aftermath of a disaster.
Issues such as a hardware failure, network problems or application faults could cause your primary servers to stop functioning correctly. This can leave users unable to access services, which poses a real barrier to productivity.
Server redundancy helps business by protecting critical data by ensuring it exists in more than just one place. This means that the business can recover data if something happens to a live server.
For applications where data integrity and access are vital, redundant servers are very important.
What are the business benefits?
Redundant servers offer assurance to businesses as they have a cost-effective backup for accessing critical data if disaster strikes and a live server goes offline.
If a server goes down, a backup server can take up the slack enabling maximum uptime until the failed server is fixed.
They also feature real-time system monitoring which scans for possible failure, this means your business always knows about the health of their servers.
However, the benefits need to be balanced with the level of risk and the substantial costs associated with it.
Types of redundant server
Redundant servers can take many forms.
Redundant domain, front end, and validation servers: These are used for load-balancing to ensure users can always access a service. For example, a secondary Windows Active Directory server validates user access to the domain if the primary AD server goes down or is busy.
Replicated servers: A replicated backup server can be paired with a production server. Any change to the production server is replicated to a backup server using software-based or hardware-based tools. In the event of a server failure, the replicated server can be brought into service.
Disaster recovery servers: These are semi-hot spares that can have backup files quickly restored and restart processing, should disaster strike.
How to create server redundancy
In order to create server redundancy in your infrastructure, you need two servers housing identical data – a primary server and a secondary server.
A failover monitoring server checks the primary servers for any problems. Should a problem be detected, it will automatically update DNS records so that network traffic is diverted to a secondary server.
Once the primary server is working properly again, traffic will be rerouted back to the primary server. If the handover and hand back are successful, users should not notice any difference to the service.
What is IP failover?
IP failover is a popular technique for server redundancy. Servers run a ‘heartbeat’ process and in the event of one server failing to see the ‘heartbeat’ of the other server, it takes over the IP address of the failing server.
IP takeover is implemented when two servers are connected on the same switch and are running on the same subnet.
What else should be redundant?
In addition to a redundant server, your infrastructure should make sure it has other parts of it that can be duplicated in case of emergencies and to ensure maximum uptime.
Backups: Backups can be deployed to ensure data held locally is also stored elsewhere (on the cloud, or another data center in a distant location). This allows you to quickly restore data in the event of a disaster.
Disk drives: Hot spares should be available so that if a disk drive in a primary server fails, another drive can immediately replace it. Using a RAID array should ensure that a server can keep running when there is a single disk failure.
Power supplies: Redundant power supplies should be deployed on critical servers so that if the main power supply fails, it can continue to run.
Internet connectivity: If your server needs to have a connection to the internet at all times, having a line from a different telecoms company is important. If one line fails (e.g. if a workman severs a cable), traffic can shift onto an undamaged line.
Learn more about how to customize a CenturyLink private cloud for your organization.
This blog is provided for informational purposes only and may require additional research and substantiation by the end user. In addition, the information is provided “as is” without any warranty or condition of any kind, either express or implied. Use of this information is at the end user’s own risk. CenturyLink does not warrant that the information will meet the end user’s requirements or that the implementation or usage of this information will result in the desired outcome of the end user.