Resiliency and High Availability
What is Resiliency?
Choosing the appropriate resiliency options to meet your needs should be your primary goal when designing your Nexus Repository architecture. Resiliency refers to the ability to recover from disruptions to critical processes and supporting technology systems. Disruptions may include any of the following:
- failure of a single service (the repository node, the external relational database, or the artifact storage)
- a data center outage for the production environment
- an availability zone outage in the case of cloud services
The scope of interruption you are planning to mitigate will determine which architecture you will need to achieve the level of resiliency required.
Backup and Restoration
As you review backup strategies, there are two important terms to remember:
- Recovery Point Objective - the amount of data loss that is acceptable if a restore becomes necessary
- Recovery Time Objective - the length of time required to restore the service
Your backup plan will need to balance the cost of maintenance with the risk of potential data loss and disruptions to the service. Setting requirements for fast recovery with the least risk will increase infrastructure complexity and maintenance cost for achieving those results. You will also need to regularly test the recovery process to ensure that the process is successful and to provide training for process owners. Regardless of implementation size, make sure to document your plan and to keep it up to date with any infrastructure changes.
You can configure your architecture to schedule database exports or use third-party tooling to transfer and back up files from one location to another.
For OrientDB or H2, Nexus Repository provides tasks to create database snapshots and relocate them to a target disk. Other directories in your local instance (or instances) should also be copied and rebuilt on a backup disk (see Prepare a Backup).
You will need to back up blob storage outside of the repository service.
See Backup and Restore (for H2 and OrientDB) and Backup and Restore in Amazon Web Services for further information.
Library of Patterns
The matrix below lists various deployment patterns that you might use depending on the level of resiliency you wish to achieve.
| Pattern Name | Description | Use Cases | Limitations | Examples* |
|---|---|---|---|---|
Active-Active NEW IN 3.50 | Cluster of redundant active Nexus Repository instances within a single cloud region or on-premises data center. | HA is designed to protect against the following scenarios:
|
| |
| Single Node with Backup | Single active node with a cold backup that can be used to recover from a data loss. |
|
| |
| Single Node with Dynamic Failover | Single active node in one availability zone. Should a node or availability zone fail, Kubernetes automatically spins up a second node in either the same or a second availability zone. |
|
|
* We will continue to update this section with more examples as we validate them.
High Availability (HA)
What High Availability Deployment Options are Currently Supported? NEW IN 3.50
Our current HA deployment options for deployments using a PostgreSQL database accomplish increased uptime by deploying a cluster of redundant Nexus Repository instances (i.e., nodes) in active/active mode (i.e., both actively running the same kind of application simultaneously) within a single cloud region or on-premises data center. This allows you to maintain Nexus Repository availability even if a node becomes unavailable.
What is Legacy High Availability Clustering?
High Availability Clustering (HA-C) was a Nexus Repository feature implemented only in OrientDB that was meant to improve uptime by having a cluster of redundant Nexus Repository instances (i.e., nodes) within a single data center. We have replaced HA-C with a newer HA option for deployments using PostgreSQL databases.