Load balancing Nexus artifact repository

Load balancing Nexus is currently not supported by Sonatype, except by putting a Nexus instance in front of two with smart-proxying enabled or via a newer feature.

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

Sonatype's Nexus 3 Pro supports 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.

StackExchange DevOps Q#366, answer score: 8