Skip to main content

Resiliency and High Availability

Note

Only available in Sonatype Nexus Repository Pro. Interested in a free trial? Start here.

Note

A Helm Chart (GitHub, ArtifactHub) is available for our on-premises, AWS, and Azure resiliency and high availability deployment options. Be sure to read the deployment instructions in the associated README file before using the chart.

Note

Already have a Nexus Repository instance and want to migrate to a resilient architecture? See our migration documentation.

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 providestasks 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.

Note

Note that our content replication feature is not appropriate for disaster recovery and is not included in our library of patterns.

Pattern Name

Description

Use Cases

Limitations

Examples*

Active-Active

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:

  • Maximum uptime; protects against the following scenarios

    • Availability Zone (AZ) outage within a single region

    • A virtual machine/bare metal/EC2 instance failure

    • A Nexus Repository instance failure

  • Manually scale repository instances

  • Auto scale instances in AWS/Azure

  • Deploy in Kubernetes to facilitate scaling instances up and down without having to shut down Nexus Repository

  • Does not support rolling upgrades

  • Containerized and cloud HA deployments require using several advanced technologies (e.g., Kubernetes, cloud technologies) outside the Sonatype Suite's scope. You should ensure that you have in-house expertise in these technologies before attempting an HA deployment.

  • HA requires additional infrastructure and maintenance overhead (See Sonatype Nexus Repository High Availability Performance Data (AWS, Azure)). Deploying HA without a strong need or use case may not yield your desired return on investment.

  • Sonatype Nexus Repository High Availability deployments should be fully deployed and tested in a development environment before attempting to deploy in production. Improper deployment in a production environment can result in critical data loss.

Single Node with Backup

Single active node with a cold backup that can be used to recover from a data loss.

  • Reduce data loss

  • Manual backup

  • More downtime on recovery vs. other patterns

  • Less availability than other patterns

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.

  • Achieve automatic failover

  • Reduce downtime

  • Reduce data loss

  • More downtime on recovery vs. other patterns

  • Less availability than other patterns

* 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?

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 uptimeby 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.