Implement Redundancy, High Availability, and Failover for Aternity 10

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 (DR).

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.

    Activate the Aternity ETL Server to constantly update the Aternity Vertica Database Servers with the latest data from the Oracle Database Server.

  • 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 Aternity Agents 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 Aternity Agent 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.

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 maintaining extra Aternity Vertica Database Servers for high availability.

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.

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. K-safety=2 indicates availability when two nodes fail.

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 K-safety=2, you must triple the storage of each node, and so on.

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.

Another example, if your sizing requires two nodes with 300GB each, to add K-safety=2, you must first add one extra node (to have a minimum of three nodes), then split the total storage equally (600GB total divided by three is 200GB each), then triple the storage in each node (K-safety=2), resulting in 600GB 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). 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