You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Matthew Tordoff <ma...@markit.com> on 2008/11/14 11:54:44 UTC
Highly Available Artifactory
Hi all,
I have recently been doing some investigation into making Artifactory
Highly Available, and to be honest am having difficulty in finding an
acceptable solution. To date the only solution I have found is having a
'cluster' of 2 Artifactory repositories which are load balanced. Each
repository is then made to use the other as a proxy, so if a request for
an artifact fails it searches in the repository of the other node.
The problems I see with this approach are as follows:
1) There will be situations where losing one node will leave you with an
incomplete set of artifacts. This will be when an artifact has been
deployed to node X, and not yet requested from node Y - thus pulling it
into it's local cache.
2) The second problem, similar to the first, is after a SNAPSHOT of
artifact X has been deployed to node 1, and later requested from node 2,
an updated version of that SNAPSHOT is then deployed to node 1. When a
further request of that SNAPSHOT is made, the result of the request will
be unknown - you could get one of the two different versions of the
SNAPSHOT.
3) The security settings need to be maintained manually across the two
nodes (potentially 3/4 if you include DR as well - and for our internal
20-30 different areas within the repository this is a huge overhead.)
I have heard mumblings about the use of MySQL and it's replication
abilities, however, have not seen any documented way to make use of
these.
If anyone has any further information on this topic then it would be
greatly appreciated.
Kind Regards,
Matt Tordoff
P.S. If there is no solution for Artifactory, is there a solution for
any other product e.g. Archiva?
The content of this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient and may not be disclosed, copied or distributed. If you received this email in error, please contact the sender immediately by return e-mail or by telephoning +44 20 7260 2000, delete it and do not disclose its contents to any person. You should take full responsibility for checking this email for viruses. Markit reserves the right to monitor all e-mail communications through its network.
Markit and its affiliated companies make no warranty as to the accuracy or completeness of any information contained in this message and hereby exclude any liability of any kind for the information contained herein. Any opinions expressed in this message are those of the author and do not necessarily reflect the opinions of Markit.
For full details about Markit, its offerings and legal terms and conditions, please see Markit's website at http://www.markit.com <http://www.markit.com/> .
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Highly Available Artifactory
Posted by Nick Stolwijk <ni...@gmail.com>.
I know Artifactory is built upon Jackrabbit. Maybe you can cluster the
underlying Jackrabbit instance? Take a look at clustering,
http://wiki.apache.org/jackrabbit/Clustering.
Hth,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Fri, Nov 14, 2008 at 11:54 AM, Matthew Tordoff
<ma...@markit.com> wrote:
> Hi all,
>
> I have recently been doing some investigation into making Artifactory
> Highly Available, and to be honest am having difficulty in finding an
> acceptable solution. To date the only solution I have found is having a
> 'cluster' of 2 Artifactory repositories which are load balanced. Each
> repository is then made to use the other as a proxy, so if a request for
> an artifact fails it searches in the repository of the other node.
>
> The problems I see with this approach are as follows:
>
> 1) There will be situations where losing one node will leave you with an
> incomplete set of artifacts. This will be when an artifact has been
> deployed to node X, and not yet requested from node Y - thus pulling it
> into it's local cache.
>
> 2) The second problem, similar to the first, is after a SNAPSHOT of
> artifact X has been deployed to node 1, and later requested from node 2,
> an updated version of that SNAPSHOT is then deployed to node 1. When a
> further request of that SNAPSHOT is made, the result of the request will
> be unknown - you could get one of the two different versions of the
> SNAPSHOT.
>
> 3) The security settings need to be maintained manually across the two
> nodes (potentially 3/4 if you include DR as well - and for our internal
> 20-30 different areas within the repository this is a huge overhead.)
>
> I have heard mumblings about the use of MySQL and it's replication
> abilities, however, have not seen any documented way to make use of
> these.
>
> If anyone has any further information on this topic then it would be
> greatly appreciated.
>
> Kind Regards,
>
> Matt Tordoff
>
> P.S. If there is no solution for Artifactory, is there a solution for
> any other product e.g. Archiva?
>
>
>
> The content of this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient and may not be disclosed, copied or distributed. If you received this email in error, please contact the sender immediately by return e-mail or by telephoning +44 20 7260 2000, delete it and do not disclose its contents to any person. You should take full responsibility for checking this email for viruses. Markit reserves the right to monitor all e-mail communications through its network.
> Markit and its affiliated companies make no warranty as to the accuracy or completeness of any information contained in this message and hereby exclude any liability of any kind for the information contained herein. Any opinions expressed in this message are those of the author and do not necessarily reflect the opinions of Markit.
> For full details about Markit, its offerings and legal terms and conditions, please see Markit's website at http://www.markit.com <http://www.markit.com/> .
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Highly Available Artifactory
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Nexus has a few users that are sharing the storage between separate
Nexus instances directly via some shared backend like a SAN. Since Nexus
uses just a regular m2 repo layout for storage, the options for
clustering them are much greater and simpler.
-----Original Message-----
From: Matthew Tordoff [mailto:matthew.tordoff@markit.com]
Sent: Friday, November 14, 2008 5:55 AM
To: Maven Users List
Subject: Highly Available Artifactory
Hi all,
I have recently been doing some investigation into making Artifactory
Highly Available, and to be honest am having difficulty in finding an
acceptable solution. To date the only solution I have found is having a
'cluster' of 2 Artifactory repositories which are load balanced. Each
repository is then made to use the other as a proxy, so if a request for
an artifact fails it searches in the repository of the other node.
The problems I see with this approach are as follows:
1) There will be situations where losing one node will leave you with an
incomplete set of artifacts. This will be when an artifact has been
deployed to node X, and not yet requested from node Y - thus pulling it
into it's local cache.
2) The second problem, similar to the first, is after a SNAPSHOT of
artifact X has been deployed to node 1, and later requested from node 2,
an updated version of that SNAPSHOT is then deployed to node 1. When a
further request of that SNAPSHOT is made, the result of the request will
be unknown - you could get one of the two different versions of the
SNAPSHOT.
3) The security settings need to be maintained manually across the two
nodes (potentially 3/4 if you include DR as well - and for our internal
20-30 different areas within the repository this is a huge overhead.)
I have heard mumblings about the use of MySQL and it's replication
abilities, however, have not seen any documented way to make use of
these.
If anyone has any further information on this topic then it would be
greatly appreciated.
Kind Regards,
Matt Tordoff
P.S. If there is no solution for Artifactory, is there a solution for
any other product e.g. Archiva?
The content of this e-mail is confidential and may be privileged. It may
be read, copied and used only by the intended recipient and may not be
disclosed, copied or distributed. If you received this email in error,
please contact the sender immediately by return e-mail or by telephoning
+44 20 7260 2000, delete it and do not disclose its contents to any
person. You should take full responsibility for checking this email for
viruses. Markit reserves the right to monitor all e-mail communications
through its network.
Markit and its affiliated companies make no warranty as to the accuracy
or completeness of any information contained in this message and hereby
exclude any liability of any kind for the information contained herein.
Any opinions expressed in this message are those of the author and do
not necessarily reflect the opinions of Markit.
For full details about Markit, its offerings and legal terms and
conditions, please see Markit's website at http://www.markit.com
<http://www.markit.com/> .
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org