For the list of all supported Decision Insight downloads and releases, see the Downloads page.

High Availability and Disaster Recovery deployment options

Supported deployments


For both high availability (HA) and disaster recovery (DR), Active-Passive deployment is supported. In this kind of setup, a single node of the application is active. A backup node, stopped under normal conditions, is ready to be started in case of failure of the main node - either automatically using a clustering mechanism, or manually following a specific failover procedure.

With Local Disks

In this setup, deployment is typically performed using physical servers and a physical storage system directly attached to the server:

  • Internal RAID card with SAS HDD
  • DAS (Direct Attached Storage)

Disk replication

In order to offer HA capabilities, data need to be replicated from the active node to the passive node. This is usually achieved using rsync-like tools and mechanisms.

You can sync the configuration and database of the active node with the passive node on a regular basis using a cron for example. You can avoid to synchronize temporary objects by excluding files or folder with the tmp extension. Using rsync for instance you can use the following option:

--exclude *.tmp 

At any time, Axway Decision Insight can then be launched on the failover node; which will recover all states and historical data from the last checkpoint.

The same principle applies to provision a DR instance, usually on a remote location. In order to reduce load on the active node, the replication to the DR site is usually performed from the passive node.


In order to perform failover between nodes, the deployment relies on external mechanisms, typically a clustered service manager which ensures that a given service is properly running once and only once, and control which instance should be running at a given moment.

The same principle applies to failover to a DR site. It is not unusual to have an automatic failover mechanism for HA, but to rely on manual procedure for DR.

With SAN storage

In this setup, deployment is typically performed using virtualized servers using a SAN (Storage Area Network) as storage subsystem, and sometimes when using physical servers. Connection to the SAN is performed using specific networking mechanisms as:

  • Fiber Channel
  • iSCSI

When deploying over a SAN, it should be noted that Decision Insight has the same Storage (I/O and surface) requirements than a database management system, and should as such be positioned on Tier 0 or 1 of the SAN for performance reasons.

Disk replication

When using a SAN, disk replication is typically handled by the SAN itself within a single datacenter, covering as such the disk replication requirements for HA.

If multi-site SAN replication is in place, it also covers the disk replication requirements for DR. If not available and DR is required, a specific replication mechanism can be setup using the same principles than when using local disks.


With a virtualized deployment supporting HA

When the virtualization system HA mechanisms are available and deployed (for example, VMware vMotion, VMware HA, VMware FT, etc.), the HA failover typically relies on them for all hardware failures.

Depending on the capabilities of the virtualization system to perform failover over multiple sites, DR can also rely on those mechanisms or require a specific procedure (See With Local Disks > Failover).

With a virtualized deployment without HA

The failover mechanism is similar to With Local Disks > Failover.

Alternatively, a manual or automated procedure can consist in launching the virtual machine on another node instead of launching the application from within a passive virtual machine.

With a physical deployment

The failover mechanism is similar to With Local Disks > Failover.

Related Links