archiva-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthieu Godlewski <Matthieu.Godlew...@reuters.com>
Subject RE: Which maven repository manager for high availability ?
Date Thu, 18 Oct 2007 12:24:00 GMT
> The chosen solution should fulfill our high availability requirement.
> The available documentation on this point is pretty poor for Archiva:
>
> http://docs.codehaus.org/display/MAVENUSER/High+Availability+Archiva
>
> (Confluence is down atm so I can't check, but,) What do you want to
know?
>
> Past confirming that Archiva has the features you need and is stable,
> most of the work I've done with making it highly available has been
> hardware and network related.

I've got pretty poor knowledge about high availability systems so I was
wondering how this should be handled, if J2EE containers could play a
role and if there is good practices to share/replicate datas (artifacts,
metadatas, indexes, user preferences, ...?).

> As an example configuration, we have two servers running Archiva
> (actually, Maestro,) with a virtual IP device in front.  Everyone uses
> a single url that goes to the VIP, which monitors port 8080 on the
> servers to see which one is available.  Right now it's done as
> failover to a hot standby, but we eventually want it load balanced,
> and will add more repository servers as necessary.  

How do you handle repositories storage with this solution?
It's not a real issue when considering cached repository but what about
internal release (use in distributionManagement) and private
repositories?

Sharing a same NFS doesn't seem a good way because it adds a possible
"point of failure" (unless setting up a high available nfs server
http://www.howtoforge.com/high_availability_nfs_drbd_heartbeat).

Not sure that rsyncing repositories partition frequently is a better
one.

Setting every archiva instance to mirror others isn't safe either,
especially in a failover context (once artifacts are deployed in first
archiva instance, they're never replicated to others until the first
fail and it will be to late).

> We've also switched to MySQL for the user database, to take advantage
of  > its replication and admin features.

I think we will follow your advice.

> The Artifactory docs seem to be talking about having multiple
> distributed servers.   That should also work fine with Archiva, you
> could configure them to proxy requests in some hierarchy.
> 
> In my case, all the project infrastructure is collocated, so
> distributed doesn't make sense, but it might for you.

We're in the same case now but if we succeed, this could evolve in a
multilocated structure.

Cheers,


Matthieu

This email was sent to you by Reuters, the global news and information company. 
To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, 
except where the sender specifically states them to be the views of Reuters Limited.

Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the
ultimate parent company.
Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary
Wharf, London E14 5EP, United Kingdom
Registered No: 3296375
Registered in England and Wales



Mime
View raw message