<p>As of now (2022) Sonatype Nexus3 only supports high availability through what they call &quot;cloud resilient single-node deployment&quot;, which translates to a 1-replica k8s deployment. In this scenario it is Kubernetes that provides resiliency as it will replicate the pod in case of issues with the pod, the k8s cluster node, or the entire availability zone/datacenter.</p>
<p>There's no support for active/active redundant instances of Nexus3, even in the Pro version. Currently Nexus is in version 3.41. They say in their websie, thought, that they have plans to implement clustering HA (active/active).</p>
<p>Smart proxying is not a feature of Nexus3 and the link for &quot;Component fabric&quot; is broken. I assume they removed this feature.</p>
<p>Also they say in their website that HA requires a paid version (Nexus Pro and not Nexus OSS) but I think that this is inaccurate, since as long as it's k8s that is providing the resiliency, it works for both OSS and Pro versions.</p>

CC BY-SA 4.0
2022-09-01T14:06:31.200Z
2022-09-01T14:06:31.200Z
Lascou
<p>Sonatype's Nexus 3 Pro <a href="https://www.sonatype.com/high-availability" rel="noreferrer">supports High Availability</a> through a couple of mechanisms that are collectively known as Component Fabric:</p>

<ul>
<li>Peer-to-peer Repository Managers means there is no one master, also known as a single point of failure.  Packages are replicated between the nodes to ensure they are eventually consistent.</li>
<li>Storage Backends mean you can use high durability storage such as S3.</li>
<li>Dynamic Nodes enable auto-scaling support to increase capacity when demand is high and decrease it when demand is low to reduce costs.</li>
</ul>

<p>It's not really in Sonatype's interests to support HA for the community project as it would cannibalize some of the enterprise customers from their paid product.</p>

CC BY-SA 3.0
2017-04-10T07:58:58.543Z
Thanks, we are using Nexus pro licensed indeed, but we are stuck on v 2.x for the foreseeable future unfortunately.
ᴳᵁᴵᴰᴼ
CC BY-SA 3.0
2017-04-10T21:26:29.737Z
@ᴳᵁᴵᴰᴼ unfortunate indeed, any chance of setting up Nexus 3 as a mirror of Nexus 2?
Richard Slater
CC BY-SA 3.0
2017-12-15T12:05:01.330Z
Is  High Availability - Clustering (HA-C) in Nexus Repository Manager OSS as well ?
Nitul
CC BY-SA 4.0
2018-05-25T15:50:25.450Z
Doesn't [deploying Nexus on Kubernetes](https://github.com/travelaudience/kubernetes-nexus) essentially enable high availability, or am I getting this wrong?
lostsoul29
CC BY-SA 4.0
2019-11-12T10:30:20.167Z
@lostsoul29 It depends on the storage you are using. If you use k8s in AWS your EBS volumes will end up in a Availability Zone X. If this all your nodes in that instance die, you won't be able to mount the volume. So no HA here…
Pascal Hofmann
CC BY-SA 3.0
2017-04-09T11:56:06.690Z
2017-04-10T08:45:29.910Z
2017-04-10T08:45:29.910Z
Richard Slater
<p>Load balancing Nexus is currently not supported by Sonatype, except by putting a Nexus instance in front of two with <a href="https://help.sonatype.com/repomanager2/smart-proxy" rel="nofollow noreferrer">smart-proxying</a> enabled or via a <a href="https://help.sonatype.com/repomanager3/high-availability---introduction" rel="nofollow noreferrer">newer feature</a>. </p>

<p>Still, I gave it a shot, by sharing the filesystem with GlusterFS for the <code>/storage</code>, and trying to <a href="https://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html" rel="nofollow noreferrer">enable stickyness in the Apache Load Balancer config</a> and in Nexus config for the UI.</p>

<p>With the UI I am failing miserably, as it seems the Nexus container does not honor the properties for setting the cookie value; using the following configuration at the moment:</p>

<p>For the storage it seems to work, by limiting to <code>GET</code> and <code>HEAD</code> requests only, still have to try opening to <code>POST</code>s. I was also unsure about the possible collateral effects of scheduled jobs, so all were disabled in the "secondary" node.</p>

<p>Has anybody achieved some level of trustworthy configuration for load-balancing nexus? The UI is not actually important to be load-balanced, I would be happy enough with the storage.</p>

CC BY-SA 3.0
2017-03-06T10:56:41.257Z
Is the goal to achieve load balancing or high availability ?
Tensibai
CC BY-SA 3.0
2017-03-06T13:12:25.883Z
@Tensibai both eventually
ᴳᵁᴵᴰᴼ
CC BY-SA 3.0
2017-03-06T15:38:00.440Z
Old, but maybe still [relevant blog post](http://www.sonatype.org/nexus/2015/07/10/high-availability-ha-and-continuous-integration-ci-with-nexus-oss/)
Tensibai
<load-balance><nexus><apache-httpd><n3dr>
Load balancing Nexus artifact repository
ᴳᵁᴵᴰᴼ
# Load balancing Nexus artifact repository

(Asked by: username_0 on 2017-03-06)

Load balancing Nexus is currently not supported by Sonatype, except by putting a Nexus instance in front of two with [smart-proxying](https://help.sonatype.com/repomanager2/smart-proxy) enabled or via a [newer feature](https://help.sonatype.com/repomanager3/high-availability---introduction).

Still, I gave it a shot, by sharing the filesystem with GlusterFS for the `/storage`, and trying to [enable stickyness in the Apache Load Balancer config](https://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html) and in Nexus config for the UI.

With the UI I am failing miserably, as it seems the Nexus container does not honor the properties for setting the cookie value; using the following configuration at the moment:

For the storage it seems to work, by limiting to `GET` and `HEAD` requests only, still have to try opening to `POST`s. I was also unsure about the possible collateral effects of scheduled jobs, so all were disabled in the "secondary" node.

Has anybody achieved some level of trustworthy configuration for load-balancing nexus? The UI is not actually important to be load-balanced, I would be happy enough with the storage.

**Tags:** load-balance, nexus, apache-httpd, n3dr

> **Comments:**
> **username_1**: Is the goal to achieve load balancing or high availability ?  
> **username_0**: @username_1 both eventually  
> **username_1**: Old, but maybe still [relevant blog post](http://www.sonatype.org/nexus/2015/07/10/high-availability-ha-and-continuous-integration-ci-with-nexus-oss/)  

---

## 2 answers

### Answer by username_3 on 2017-04-09. Score: 8 | Accepted answer

Sonatype's Nexus 3 Pro [supports High Availability](https://www.sonatype.com/high-availability) through a couple of mechanisms that are collectively known as Component Fabric:

* Peer-to-peer Repository Managers means there is no one master, also known as a single point of failure. Packages are replicated between the nodes to ensure they are eventually consistent.
* Storage Backends mean you can use high durability storage such as S3.
* Dynamic Nodes enable auto-scaling support to increase capacity when demand is high and decrease it when demand is low to reduce costs.

It's not really in Sonatype's interests to support HA for the community project as it would cannibalize some of the enterprise customers from their paid product.

> **Comments:**
> **username_0**: Thanks, we are using Nexus pro licensed indeed, but we are stuck on v 2.x for the foreseeable future unfortunately.  
> **username_3**: @username_0 unfortunate indeed, any chance of setting up Nexus 3 as a mirror of Nexus 2?  
> **username_4**: Is  High Availability - Clustering (HA-C) in Nexus Repository Manager OSS as well ?  
> **username_5**: Doesn't [deploying Nexus on Kubernetes](https://github.com/travelaudience/kubernetes-nexus) essentially enable high availability, or am I getting this wrong?  
> **username_6**: @username_5 It depends on the storage you are using. If you use k8s in AWS your EBS volumes will end up in a Availability Zone X. If this all your nodes in that instance die, you won't be able to mount the volume. So no HA here…  

---

### Answer by username_2 on 2022-09-01. Score: 0

As of now (2022) Sonatype Nexus3 only supports high availability through what they call "cloud resilient single-node deployment", which translates to a 1-replica k8s deployment. In this scenario it is Kubernetes that provides resiliency as it will replicate the pod in case of issues with the pod, the k8s cluster node, or the entire availability zone/datacenter.

There's no support for active/active redundant instances of Nexus3, even in the Pro version. Currently Nexus is in version 3.41. They say in their websie, thought, that they have plans to implement clustering HA (active/active).

Smart proxying is not a feature of Nexus3 and the link for "Component fabric" is broken. I assume they removed this feature.

Also they say in their website that HA requires a paid version (Nexus Pro and not Nexus OSS) but I think that this is inaccurate, since as long as it's k8s that is providing the resiliency, it works for both OSS and Pro versions.


---

