Table of contents Implement Redundancy, High Availability (HA), and Failover for Aternity on-premise You can implement high availability and redundancy in two key areas of the Aternity on-premise deployment: the Aternity Database Server and the Aternity Aggregation Server. Implement redundancy via failover in Aternity Aggregation Server Redundancy with Failovers Aternity supports two levels of redundancy with Aggregation Servers: You can deploy more than one Aggregation Server and use a third party load balancer to front the cluster. If one server in the cluster fails, the other servers can continue to operate without any downtime. You can also set up a parallel load balancer as a failover for disaster recovery, or if you only have a single Aggregation Server, you can set up a parallel one as a failover. You perform the standard installation of an Aggregation Server, without any extra configuration on the server itself. Then you can configure the Aternity Agents on the devices to switch to a different Aggregation Server if one fails. Tip If 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. Configure the LB with persistent (sticky) sessions to ensure the Agent maintains its connection with the same server. Failover for Aternity Agents sending to the Aggregation Server Database Server Redundancy with Failover Aternity supports creating a redundant clone of the 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 Database Server To implement a cloned 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. Contact Aternity customer service team before implementing connection strings with any RAC elements or other advanced features. Parent topic Plan your Deployment Strategy for Aternity on-premise 9.0.2 / 9.0.3Related tasksSecure your Aternity on-premise DeploymentRestore Aternity Database from a Backup / Disaster Recovery (DR)Related referenceChoose the Sizing and Hardware Requirements of your Aternity on-premise Deployment 9.0.2 or 9.0.3Choose the Network Topology Layout for Aternity on-premise 9.0.2 / 9.0.3Choose your Backup Strategy for Aternity on-premise SavePDF Selected topic Selected topic and subtopics All content Related Links
Implement Redundancy, High Availability (HA), and Failover for Aternity on-premise You can implement high availability and redundancy in two key areas of the Aternity on-premise deployment: the Aternity Database Server and the Aternity Aggregation Server. Implement redundancy via failover in Aternity Aggregation Server Redundancy with Failovers Aternity supports two levels of redundancy with Aggregation Servers: You can deploy more than one Aggregation Server and use a third party load balancer to front the cluster. If one server in the cluster fails, the other servers can continue to operate without any downtime. You can also set up a parallel load balancer as a failover for disaster recovery, or if you only have a single Aggregation Server, you can set up a parallel one as a failover. You perform the standard installation of an Aggregation Server, without any extra configuration on the server itself. Then you can configure the Aternity Agents on the devices to switch to a different Aggregation Server if one fails. Tip If 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. Configure the LB with persistent (sticky) sessions to ensure the Agent maintains its connection with the same server. Failover for Aternity Agents sending to the Aggregation Server Database Server Redundancy with Failover Aternity supports creating a redundant clone of the 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 Database Server To implement a cloned 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. Contact Aternity customer service team before implementing connection strings with any RAC elements or other advanced features. Parent topic Plan your Deployment Strategy for Aternity on-premise 9.0.2 / 9.0.3Related tasksSecure your Aternity on-premise DeploymentRestore Aternity Database from a Backup / Disaster Recovery (DR)Related referenceChoose the Sizing and Hardware Requirements of your Aternity on-premise Deployment 9.0.2 or 9.0.3Choose the Network Topology Layout for Aternity on-premise 9.0.2 / 9.0.3Choose your Backup Strategy for Aternity on-premise
Implement Redundancy, High Availability (HA), and Failover for Aternity on-premise You can implement high availability and redundancy in two key areas of the Aternity on-premise deployment: the Aternity Database Server and the Aternity Aggregation Server. Implement redundancy via failover in Aternity Aggregation Server Redundancy with Failovers Aternity supports two levels of redundancy with Aggregation Servers: You can deploy more than one Aggregation Server and use a third party load balancer to front the cluster. If one server in the cluster fails, the other servers can continue to operate without any downtime. You can also set up a parallel load balancer as a failover for disaster recovery, or if you only have a single Aggregation Server, you can set up a parallel one as a failover. You perform the standard installation of an Aggregation Server, without any extra configuration on the server itself. Then you can configure the Aternity Agents on the devices to switch to a different Aggregation Server if one fails. Tip If 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. Configure the LB with persistent (sticky) sessions to ensure the Agent maintains its connection with the same server. Failover for Aternity Agents sending to the Aggregation Server Database Server Redundancy with Failover Aternity supports creating a redundant clone of the 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 Database Server To implement a cloned 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. Contact Aternity customer service team before implementing connection strings with any RAC elements or other advanced features. Parent topic Plan your Deployment Strategy for Aternity on-premise 9.0.2 / 9.0.3Related tasksSecure your Aternity on-premise DeploymentRestore Aternity Database from a Backup / Disaster Recovery (DR)Related referenceChoose the Sizing and Hardware Requirements of your Aternity on-premise Deployment 9.0.2 or 9.0.3Choose the Network Topology Layout for Aternity on-premise 9.0.2 / 9.0.3Choose your Backup Strategy for Aternity on-premise