> 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
