High Availability Archiva

• http://en.wikipedia.org/wiki/High_availability^{Image Removed}

General considerations running multiple instances (cluster)

...

Option 1: master-slave-strategy (not really a cluster)

• one primary server, one secondary server
• the fs of the primary server is replicated/synchronized to the secondary server every n minutes (e. g. using rsync)
• in case the primary server goes down, developers need to modify their settings.xml to direct to the secondary server

advantage: easy to set up
drawback: no transpararent fail-over, no load-balancing

...

How can upgrades be handled to minimize downtime?
no general solution. it depends on 2 factors:

• release changes
• customization

Example architectures

Example configuration

...

Example architecture: two Archiva-Servers + httpd-balancer

• two Archiva-servers (tomcat) running with identical config
• both servers connect to the same mysql-database; the mysql-database may itself be clustered
• both servers share the fs for the managed repos; this fs is RAID5-based and therefore higly resistant to crash
• important is to ensure that only one of those instances do write-operations (to the fs and db)
• single httpd-server configured to do read-operations for both-servers (load-balancing and fail-over), but write-operations only to one defined server

Benefits:

• distributed HA-architecture (2 Archiva-servers, mysql-cluster, RAID5)
• both Archiva-instances are always in the same state - no replication necessary
• load-balancing allows for maximum performance
• no concurrency issues because only one server does write operations at a time

What are write-operations
usually triggered by deploy-goals
the release-plugin might also do some write operation

...