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. 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+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.
