Implement Redundancy and High Availability for Aternity 11

You can implement high availability and redundancy to enable restoring from backups of the Aternity Oracle Database Server, the Aternity Vertica Database Server and the Aternity Aggregation Servers.

Tip

See also details of backing up your Aternity deployment and restoring from backups.

Implement Redundancy on a Separate Standby Site (Hot Recovery)

You can create an entire standby data center site which is ready to spring into action if your main site becomes unavailable, also known as hot recovery.

Hot recovery by implementing a standby site

To deploy a standby site for hot recovery, you must:

  • Use a tool to backup the Oracle Database Server constantly (live) to a clone server which remains in a state of read-only.

  • The monitored devices should report to either the main site's load balancer for Aggregation Servers, or to a parallel load balancer on the standby site for disaster recovery. Configure the Agent for End User Devicess on the devices to the main site, until it fails, and then route to the secondary site if needed.

    Tip

    If your sizing requires that you deploy more than one dedicated Aternity Aggregation Server, you must deploy a third party load balancer (LB). Then configure the Agent for End User Devices of all devices to point to the LB's virtual IP address (learn more). Configure the LB with persistent (sticky) sessions to ensure the Agent maintains its connection with the same server. Aternity also supports sticky sessions also when the LB implements stickiness via cookies.

Learn more about disaster recovery process.

Implement Redundancy for Aternity on a Single Site

You can implement redundancy on one site by keeping a backup of your Aternity Oracle Database Server and Aternity Vertica Database Server, as well as maintaining extra Aternity Vertica Database Servers for high availability (cluster).

Implement redundancy for failover recovery in Aternity

You can deploy more than one Aggregation Server and use a third party load balancer to front the cluster. If one server fails, the other servers can continue to operate without any downtime.

Learn more about backing up Aternity Vertica Database Server.

Oracle Database Server Redundancy

Aternity supports creating a redundant clone of the Oracle Database Server using Oracle Data Guard, which streams all database updates to the clone server to ensure its content remains the same as the main server.

Clone the Aternity Oracle Database Server

To implement a cloned Oracle Database Server, you must enable Oracle's archive log for hot backups.

Tip

If you have your own custom queries and reports which you want to run directly on the Aternity database, use the clone.

If you have Oracle RAC (Real Application Clusters) deployed, configure the connection string of Aternity's database service to use only a one single instance in the cluster. You can configure the failover option to use another server if required.

Therefore Aternity does NOT support RAC's load balancing and high availability features. We recommend you contact Customer Services to discuss your overall DR / high availability architecture.

Aternity Vertica Database Server Redundancy and High Availability

Prepare for high availability by first determining the level of failure tolerance you need with your Vertica Database Server. If one Vertica Database Server node fails, do you want to maintain availability? If two nodes fail, do you still want to maintain availability? The level of failure tolerance is a value known as K-safety (or K-safe).

K-safety=1 indicates you maintain availability when one node fails.

If your sizing requires less than three nodes for the Vertica Database Server, you must deploy at least three nodes, to maintain availability when one of them fails (K-safety=1). You can split the total storage amongst all the nodes.

For K-safety=1, you must also double the hard disk storage in each node.

For example, if your sizing requires one node with 300GB storage, to add K-safety=1, you must first add two more nodes (to have a minimum of three nodes), then split the storage equally between all three (100GB each), then double the storage in each node (K-safety=1), resulting in 200GB each.

If your sizing requires three nodes or more, you can maintain high availability by either adding more nodes or by increasing the hard disk storage of all existing nodes (or both). Learn more.

If you have a cluster of Vertica databases, Vertica recommends not to deploy firewalls on the individual servers within the cluster (learn more). All nodes should be behind a firewall, but if you must use a firewall between nodes, ensure the required ports are open on each node. For a complete list of ports within a cluster, see the ports list (learn more).

Adding high availability depends on fault tolerance and sizing

Since the Aternity Dashboard Server connects to only one Vertica Database Server, if that server fails, it cannot connect to any servers in the cluster. Therefore you should connect the Dashboard Server to a load balancer to ensure high availability.

Install a Vertica cluster for performance and high availability

Learn more about backing up Aternity Vertica Database Server.