Hello, ----- "Patrick" <kc7...@gmail.com> a écrit : | On Jun 5, 2010, at 2:31 PM, Chuck wrote: | | > I am currently worried about scalability as the number of modules | and | > clients on my puppet server increases. I am planning on locating | at | > least one puppet server in each of the 4 data centers. | | I've found that very bad things
Why ? I know some people here do it, with some real success. Having your master near your clients is, to me, a good thing. Use a central master to configure satellite ones. The only problem is about SSL chaining that can drive you crazy :p | > I am not finding any information on what to expect and to design | into | > my infrastructure as it matures so I don't run into any unexpected | > surprises. It sounds like some people are using puppet in large | > environments and I would like to know what the issues that have | been | > run into and if there is a way to design the environment to avoid | > these issues. I have been reading through the puppet mailing | lists, | > wiki, and documentation which has gotten me to my current use of | > apache/passenger. | | I'm not exactly sure what you want, but here's some general scaling | advice: | | If you are using storeconfigs, take a look at | http://www.masterzen.fr/2009/03/18/omg-storedconfigs-killed-my-database/ | | You probably want to use the "splay" option. Normally it won't help | much, but it will help make sure that the puppet clients don't all get | "in sync" and all try to connect to the server at once. | | I've heard that using RubyEE or JRuby can help reduce the amount of | ram you need. There's a queue daemon now, you should take a look at this -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
