High Availability Deployment Options
Only available in Sonatype Nexus Repository Pro. Interested in a free trial? Start here.
NEW IN 3.50.0
The High Availability (HA) architecture described in this section replaces our legacy High Availability Clustering (HA-C) solution.
What is High Availability?
High Availability (HA) refers to increased uptime accomplished by deploying a cluster of redundant Nexus Repository instances in active/active mode (i.e., both actively running simultaneously) within a single cloud region or on-premises data center. This allows you to maintain Nexus Repository availability even if an instance becomes unavailable.
Use Cases
HA is designed to protect against the following scenarios:
- An Availability Zone (AZ) outage within a single region
- A virtual machine/bare metal/EC2 instance failure
- A Nexus Repository instance failure
As such, HA is an appropriate solution for mission-critical Nexus Repository deployments that require continuous operations or uptime for an extended period and can help such instances scale for load.
It also provides the following necessary functionality to highly scalable Nexus Repository deployments that must meet varying loads:
- 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
Note that HA requires additional infrastructure and maintenance overhead. Deploying HA without a strong need or use case may not yield your desired return on investment.
Choosing High Availability
HA is an advanced feature that requires careful consideration. Consider the following points before deploying to an HA environment:
- 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). 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.
Search Feature Differences
The Search feature implemented for HA differs from the Search currently used in a non-HA environment. HA Search has the following requirements:
- At least one search criterion is required when searching through the UI
- At least one additional search criterion is required beyond format when searching through the UI
- Each search criteria must be at least three characters long
- Leading wildcard search is not supported; however, you may use a trailing wildcard (i.e., prefix search)
- For keyword search, enclose your criteria in quotation marks to search an exact phrase; otherwise, search criteria will be split by any commas, spaces, dashes, or forward slashes used
- All keyword searches automatically append a wildcard (*) at the end of each criterion
Example Invalid Search Patterns
The following search patterns are some that may work in non-HA environments but will not work in an HA environment
| Invalid Pattern | Reasoning |
|---|---|
| "*" | Less than three characters long; leading wildcard not supported |
| "he*" | Less than three characters long |
| "he*@_" | User criteria ("@_") contains only an underscore |
| "he*@/" | User criteria ("@/") contains only a forward slash |
| "he*@*" | User criteria ("@*") contains only a wildcard |
| "hel*/1.*" | The version criteria (1.*) contains only two characters |
Logging
Container-based cloud deployments use statefulsets to dynamically provision a volume per pod. This is done through dynamic provisioning of EBS for AWS or Azure Disk for Azure.
For both container and non-container-based on-premises as well as for non-container-based cloud deployments, each Nexus Repository instance runs on a single VM/bare metal machine and will write logs to the local disk.
In all cases, the correct node will respond to support zip generation requests and store the generated zip in the blob store.
The Log Viewer is not available when using an HA deployment options.
Blob Storage
Enabling HA will disable the ability to create default blob stores and repositories. If you are already using the default blob store on your instance, you will need to follow the instructions in Migrating to Shared Blob Storage to change your default blob store's path to connect to a shared location.
Related Help Topics
System Requirements
- Each Sonatype Nexus Repository instance must meet our Sonatype Nexus Repository System Requirements.
- You must also meet all System Requirements for High Availability Deployments, including using shared blob storage (see Migrating to Shared Blob Storage if necessary).
Migrating from HA-C or a Resilient Deployment
Detailed instructions for migration are captured in Migrating to an HA Deployment from a Legacy HA-C or a Resilient Deployment.
Upgrading Nexus Repository in an HA Environment
Upgrading Sonatype Nexus Repository in an HA environment does require downtime. Upgrade is not possible without downtime. Full details on upgrading in an HA environment are available in Upgrading Nexus Repository in an HA Environment.
Downgrading from HA to a Single Instance
Detailed instructions for downgrading are captured in Moving from a High Availability Deployment to a Single Instance