An Always-On HDR

mpruet's picture



An Always-On HDR

An Always-On HDR


IDS’s HDR technology is the cornerstone to every high-availability environment. If you need your data available at all times (and who doesn’t?) you must plan for unexpected outages (e.g. network, hardware or operating system failure). HDR addresses this by allowing you to have a copy of your primary server. With DRINTERVAL set to -1, you can guarantee that your primary and secondary servers are in complete synchronization. Problem solved.

But what happens if one node of your HDR pair goes down? You’re no longer operating with high-availability protection. How much more risk can you tolerate? Sure you’ve got logs saved, but clients need the data faster than a log restore.

With the release of version 11, IDS can be configured in such a way that you can have HDR always on. In other words, you can create an environment where you step back into HDR as soon as a failure causes you to step out of it. How do you do this? Use a cluster of an HDR pair plus RSS.

A Remote Standalone Secondary (or RSS) node operates very similarly to an HDR secondary except it is not in sync with the primary. It offers many advantages when used at a remote location (i.e. one with high network latency), but in our context let’s use one locally. One characteristic of an RSS server is that is can become an HDR secondary while on line! An HDR secondary in turn can become an RSS node. Now we’ve got all the pieces in place, so let’s explain the ring.

The simplest cluster has three nodes: an HDR primary, an HDR secondary, and an RSS node. Our goal is to always have HDR on. So when an event occurs that causes our HDR pair to break - one of the nodes fails - that must trigger a second event that reestablishes an HDR pair. The second event can occur manually or programmatically. Since the cluster has only three nodes, let’s consider the three failures that could occur and what to do.

Scenario 1: Primary fails

  1. Make the HDR secondary your new HDR primary
  2. Make the RSS node your new HDR secondary
  3. Fix your old primary and bring it online as an RSS node

Scenario 2: Secondary fails

  1. Make the RSS node your new HDR secondary
  2. Fix your old HDR secondary and bring it online as an RSS node

Scenario 3: RSS node fails

  1. Fix your RSS node

OR

  1. Add a new RSS node

Regardless of which node fails, we have the means of reestablishing an HDR environment. Further, since RSS technology is one-to-N, multiple RSS nodes can be added to the cluster giving you more options for each scenario.

What about scenarios when more than one failure occurs at a time? These are obviously more complex and their solutions depend on what types of failures occur. Redundant machine parts and network infrastructure, interconnected network nodes, and our high-availability “ring” will mostly likely play significant parts.

Adding an RSS to an HDR pair can give at least a second layer of high data availability, and as explained above can at best make HDR always on.