KNOWLEDGE CENTRE / SERVERS / INFRASTRUCTURE

Server Redundancy: Power, Storage and Networking

Reliable server infrastructure is built around reducing single points of failure where the workload justifies the additional complexity and cost.

Redundancy means designing a system so that the failure of one component does not necessarily stop the service. The right level of redundancy depends on how important the workload is.

Practical example: NAS, DAS or SAN?

25-user storage example
25-user storage exampleFor shared office files, NAS is often the natural architecture to evaluate first. RequirementShared filesDASOne-host focusNASFile services over LANSANShared block storage For shared office files, NAS is often the natural architecture to evaluate first.

For shared office files, NAS is often the natural architecture to evaluate first.

Scenario: A 25-user office needs shared departmental files, central backup storage and controlled user access.

A NAS is a natural candidate because it provides file services over the existing network. A directly attached enclosure would tie the storage more closely to one host. A SAN would make more sense where servers require shared block storage, for example in a more complex virtualisation environment.

Decision: For this example, start by evaluating NAS capacity, drive type, network speed, snapshots and backup replication. Do not deploy SAN architecture merely because it sounds more enterprise.

Common mistakes and selection checklist

Common mistakes

  • Choosing NAS, DAS or SAN because one architecture sounds more enterprise rather than because it fits the workload.
  • Sizing storage only by terabytes and ignoring IOPS, throughput, network speed, snapshots and backup.
  • Using one storage system as both primary data and the only backup copy.

What happens if you get it wrong?

Users can experience slow file access or applications can be constrained by the wrong storage path. More importantly, a storage failure or data-loss event can affect both production data and the supposed recovery copy.

Selection checklist

  • Decide whether applications need file storage, block storage or storage attached to one host.
  • Estimate current usable capacity and realistic growth.
  • Identify performance, network and concurrency requirements.
  • Check drive type, RAID options, snapshots and expansion.
  • Design backup and off-system recovery independently.

Power redundancy

Servers may support multiple power supplies. When combined with appropriate electrical circuits and power distribution, this can reduce the impact of a single power component or circuit failure.

Storage redundancy

RAID can provide protection against certain drive failures. The RAID level should be selected according to the workload and recovery requirements.

Network redundancy

Multiple network interfaces or network paths can provide alternative connectivity where the network architecture supports it.

Redundancy is not backup

Redundancy helps keep a system operating through certain failures. Backup provides a way to recover data or systems after events such as deletion, corruption or other data loss.

Do not add redundancy blindly

Redundant components introduce additional cost and configuration requirements. The design should focus on the failures that would have the greatest operational impact.

Start with the failure you are trying to survive.

Then design the redundancy around that failure rather than simply adding duplicate components.

How to use this information

Confirm the exact product specification, supported configuration and compatibility before ordering. Platform generation, firmware, licences and optional components can change what a product supports.