Option 1 - Manual High Availability Deployment
Only available in Sonatype Nexus Repository Pro. Interested in a free trial? Start here.
Warning
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 may result in critical data loss.
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
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
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).
If you require your clients to access more than one Docker Repository, you must use an external load balancer (e.g., NGINX) as a reverse proxy instead of the provided ingress for Docker YAML.
Before proceeding, you must have adjusted the max_connections.
Limitations
Upgrading with zero downtime (rolling upgrades) is only available from release 3.71.0 forward; 3.72.0 is the first version to which you can upgrade without shutting down all active nodes. See our HA upgrade documentation for details.
We do not recommend deploying HA clusters across regions due to the large number of database interactions is involved in HA.
In the absence of a distributed solution for logging, local disks are required to persist the log files that are needed for support zip creation.
Database
To set up a Sonatype Nexus Repository cluster manually, you must configure each Sonatype Nexus Repository instance following our documentation for Configuring Nexus Repository Pro for PostgreSQL.
Blob Storage
When first launching Nexus Repository with HA enabled, the default repositories and blobstore are not created. Administrators will need to create blob stores in a shared location.
For existing deployments, use the Migrating to Shared Blob Storage to change your blob store's path to connect to a shared location.
Enable HA Property
Beyond the instructions linked above, you must also modify the $data-dir/ sonatype-work/nexus3/etc/nexus.properties in each instance to include the following line:
nexus.datastore.clustered.enabled = true
Note
If you accidentally start in the wrong mode, you will need to shut down any started instances, set the flag above on each instance, and then restart each instance.
License Store for On-Premises and Cloud
As outlined in the documentation for Configuring Nexus Repository Pro for PostgreSQL, you should specify the license file via the nexus.licenseFile in $data-dir/sonatype-work/nexus3/etc/nexus.properties by adding the following line, replacing the placeholders with the appropriate path to point to your valid Pro license:
nexus.licenseFile=/path/to/your/sonatype-license.lic
Log Store
You will find Sonatype Nexus Repository logs on each instance in the data directory (i.e., $data-dir/sonatype-work/nexus3/logs/).
Each Sonatype Nexus Repository instance will write logs to the local disk. The correct instance will respond to support zip generation requests and store the generated zip in the blob store.