Is Puppetlabs planning some easy solution for this ? The real problem I see is that you can't separate the Puppet CA from the Puppet Master. So even that you can have multiple puppet masters, the CA must run in one of them. So if that server goes down your multiple puppet master setup is screwed as well.
I would love to see a Puppet CA high availability solution out of the box. On Tuesday, April 30, 2013 6:43:08 AM UTC-7, R.I. Pienaar wrote: > > > > ----- Original Message ----- > > From: "jcbollinger" <john.bollin...@stjude.org> > > To: puppet...@googlegroups.com <javascript:> > > Sent: Tuesday, April 30, 2013 2:39:52 PM > > Subject: [Puppet Users] Re: High Availability of Puppet server for > separate geographical location > > > > > > > > On Monday, April 29, 2013 8:55:39 AM UTC-5, shyam sundar Keshari wrote: > > > > > > Hi Team, > > > > > > I have to configure puppet server in Primary-Secondary mode for 2 > > > distributed location . > > > > > > Site A is already running 1 Puppet server .Now I need to configure > > > another puppet secondary server at site B ,so that > > > > > > all client at location B ,only connect to that server .And site A > > > puppet client only connect to site A . > > > > > > But mine requirement is of that suppose site A server goes down then > > > Site B server handle all client request and > > > > > > same if Site B server down then server A handles all . > > > > > > Kindly guide me to implement this scenario . > > > > > > > > For the most part, this is outside Puppet's scope. You need to stand up > > some kind appliance or service in front of your Puppet servers to > monitor > > when one goes down, so as to redirect traffic to the other when needed. > > That cannot be part of Puppet, else it would go down with Puppet if ever > > Puppet went down. > > > > With an external failover system in place, there would still be a few > > things to arrange on the Puppet side. In order for site B to properly > > serve site A's nodes, it must have > > > > - site A's SSL certificate, or at least a certificate that site A's > > nodes will trust; > > - ENC and/or node declarations for site A's nodes, matching those on > > site A; > > - modules (and standalone classes, if any) matching those on site A; > > - external data (if applicable) appropriate for site A's nodes; and > > - stored configs for site A, if applicable. > > SRV goes a long way towards solving some of this, it is possible to share > a CA between masters too which solves some of that. Gets a lot harder > when > you involve PuppetDB. > > http://docs.puppetlabs.com/guides/scaling_multiple_masters.html > > > > > > I see two reasonably good approaches here: > > > > 1. the site A and B masters are maintained as a mirrored pair. This > has > > the effect that from Puppet's perspective, physical sites A and B are > > meaningless partitions of a single large, federated site. A shared, > > central certificate authority would be required (and that would need > to be > > the site A master if you want to avoid issuing new certificates to > all the > > site A nodes). > > 2. A mirror of site A's master is maintained as a hot spare at site > B, > > and vice versa. Each spare could run on the same (possibly virtual) > > hardware as the local master (but on a different port), or it could > run on > > different hardware and merely be geographically colocated. This > would > > maintain a logical distinction between sites A and B, and would be > overall > > easier to set up and maintain. > > > > If you consider option 2, however, you should soon realize that in that > > case you don't get any particular advantage from putting the spare > masters > > on the same machine as the local site's main master. Indeed, it might > be > > easier to set them up as ordinary nodes (for the site in which they are > > actually located), and even to let the local site's masters have > > responsibility for maintaining the spares' puppet master config, each as > a > > mirror of the other site's master. > > > > > > John > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "Puppet Users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to puppet-users...@googlegroups.com <javascript:>. > > To post to this group, send email to > > puppet...@googlegroups.com<javascript:>. > > > Visit this group at http://groups.google.com/group/puppet-users?hl=en. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
