Redundancy and Abstraction in HA Architectures

iSCSI SAN Storage Software / Features / StarWind’s Active-Active HA storage architecture / Redundancy and Abstraction in HA Architectures

Differentiating Between Redundancy and Abstraction in High Availability Architectures

When designing high availability architecture, it is important to understand the difference between redundancy in the environment and abstraction. Both of these terms can be used to describe physical and virtual design considerations that, if properly implemented, can be used to deliver a more effective and more resilient operating environment for your information technology solutions.

Designing for redundancy simply means that there is failover or, at a minimum, a “backup plan” that can be implemented in the event of any software, hardware, or network failure. Understanding of this redundancy can be built into your software solution – i.e. attempt to connect to Server A and, if that fails, redirect to Server B (as StarWind HA Active-Active does) – or it can be managed at the environment level by an administrator who understands the redundant components within the architecture. For this latter approach, the system administrator may configure the system to direct network traffic to a backup router or network switch or an optional Microsoft Exchange high availability environment, should the primary option fail.


The term “abstraction”, however, implies that multiple components in the architecture actually look and appear the same to consumers of the components – whether that be a high availability storage subsystem that actually stores data across multiple hard drives that appear as a single unit or whether that be a high availability cluster of web servers, each of which is reached via the same web URL in the web browser.

High availability virtualization solutions such as a Hyper-V high availability environment allow organizations today to provide even more redundancy and abstraction at the software server layer of the architecture by allowing multiple virtual servers to be exposed in the architecture – some or all of which may actually be residing on the same underlying physical hardware. Such an environment can be said to be fully abstracted because the physical hardware layer is completely abstracted out to the clients of these virtual servers.

On the other hand, while a virtualized environment such as this offers obvious redundancy at the system software layer (through the individual virtual machines), all of these VMs are dependent on the single hardware environment that they are running on. If not properly designed, this single piece of hardware and its associated storage and network connectivity can bring the entire high availability software environment down to a hardware failure. Many small organizations have only recently begun to plan for and deploy high availability architecture (such as those based on Windows high availability technologies) and, as part of that process, they have begun to rely heavily on high availability virtualization techniques and low-cost hardware environments.

In such a scenario, any organization whose stated goal is the deployment of a high availability server farm or a high availability disaster recovery solution must pay careful attention to the entire infrastructure’s redundancy and levels of abstraction to ensure that the system remains operable in the event of component or subsystem failures.