High Availability Archiva
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
...