[Pulp-list] pulp HA

[Pier, Bryce]

On Feb 6, 2013, at 9:58 AM, Randy Barlow <rbarlow at redhat.com> wrote:

> On Tue, 5 Feb 2013, Steven Roberts wrote:
>> I'm thinking active-standy wouldn't be too bad to do now.  use the
>> Mongo replication features I have heard about and do an rsync of
>> the /var/lib/pulp dirs.
> 
> I wanted to throw in a note here about Mongo's replication features. It
> has a really nice automatic replication system where the various Mongo
> nodes that are part of the replica set will vote on which one of them in
> the master. The nice thing is that they are able to automatically handle
> the scenario where the master disappears by revoting among the remaining
> nodes to decide a new master. They will only do so if a majority of the
> nodes are still able to be reached, otherwise they enter a read only
> mode.
> 
> Because of this replication system, it is often recommended to install
> Mongo servers in odd numbers. If you'd prefer to stay lighter on
> resources, they also have a very thin system called an arbiter that
> could be installed on a small system that only participates in voting.
> With that, you could have two Pulp servers instead of the more typical
> three.
> 
> For the /var/lib/pulp folders, an rsync setup could probably get the job
> done. Alternatively, you might be able to use a shared filesystem, or
> possible disk replication to accomplish something similar. I'm not sure
> how much testing we've done with those sort of setups, so we'd love to
> hear about it if you gain some experience in this area.

My solution was to put /var/lib/pulp on an NFS volume, publish the repos via http, and then mount the NFS volume on other VMs that act as kickstart/build web servers to distribute the repos. It took a bit of work to get the links on the other web servers right but once that was figured out, I put it into the puppet configuration for our build servers and let puppet maintain them. At some point in the future I may use our NetApps to replicate the NFS volume to other data centers so that the repo traffic stays local to each data center.

--
Bryce T. Pier
bryce.pier at capella.edu