Signed-off-by: Luke Kanies <[email protected]> --- README.queueing | 128 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 128 insertions(+), 0 deletions(-) create mode 100644 README.queueing
diff --git a/README.queueing b/README.queueing new file mode 100644 index 0000000..2876576 --- /dev/null +++ b/README.queueing @@ -0,0 +1,128 @@ +*PUPPET QUEUEING + +Puppet Queueing is a feature which is designed to take some load +off of the PuppetMaster by transferring the task of updating the +database to a separate program which is named puppetqd (Puppet +Queue Daemon). + +Currently this is only supported for "Storeconfigs" which is +documented at: + +http://reductivelabs.com/trac/puppet/wiki/UsingStoredConfiguration + +In the future this feature can be extended to any new puppet +data which involves storage in a database. + +*OPERATION + +In a nutshell: + + puppetmasterd -> stomp -> service -> stomp -> puppetqd -> database + +At the moment the only messaging protocol supported is "stomp". Although +others could be implemented, and considered by many as the +default queueing mechanism for Ruby and Rails applications. It is +distributed as a Ruby gem and is easily installed. + +(The queueing code inside Puppet has been written so that when other +interfaces and protocols are implemented they will be easy to use by +changing settings in puppet.conf). + +The "service" in the diagram above is any queueing service that supports +the Stomp API. For details refer to: + + http://xircles.codehaus.org/projects/stomp + +Both puppetmasterd and puppetqd subscribe to the same queueing service +using the stomp interface. As puppetmasterd posts data to the queue, +puppetqd receives it and stores it. The details of how to connect to +the service and the name of the queue to use are set in puppet.conf: + + <tbd this is a guess> + [main] + queue_interface = stomp + queue_default = storeconfigs + queue_connect = stomp://localhost:63632 + ... storeconfigs info like dblocation, etc. ... + [puppetmaster] + storeconfigs_use_queue = true + </tbd> + +Note: since puppetmasterd needs to recover the data being stored at a +later time, both puppetmasterd and puppetqd need to work with the same +database as defined in the STORECONFIGS setup. + +*QUEUEING SERVICES + +As mentioned previously any queueing service that supports the Stomp +protocol can be used. Which one you use depends on your needs. We have +tested with two of the most popular services - StompServer and ActiveMQ. + ++ StompServer + + http://rubyforge.org/projects/stompserver/ + +StompServer is a lightweight queueing service written in Ruby which is +suitable for testing or low volume puppet usage. Works well when both +puppetmasterd and puppetd are running on the same machine that it's running +on but we encountered some problems when using it from multiple machines. + ++ Apache ActiveMQ + + http://activemq.apache.org + +Considered by many to be the most popular message service in use today, +ActiveMQ has hundreds of features for scaling, persistence and so on. + +Although installation is fairly simple, the configuration can seem quite +intimidating, but for our use a one line change to the standard configuration +is all that is required and is explained at: + + http://activemq.apache.org/stomp.html + +Other customization of the internal workings of ActiveMQ, if any, will depend +on your needs and deployment. A quick skimming of the ActiveMQ documentation +will give you enough info to decide. + +Others + +We have looked at but not tried some other queuing services which are +compatible with the Stomp API: + ++ POE Component Message Queue ++ JBoss Messaging (with 3rd party support for Stomp) + +*SCALING + +For StoreConfigs you basically need to have the catalog for a node stored +in the database before the next time the node connects and asks for a +new catalog. + +If the puppetd on your nodes is set to check every 30 minutes, +then it would seem that there is no problem. However if you have 3000 +nodes you have a LOT of catalogs to store and it is possible you will +not get a catalog saved in time. + +Running puppetmaster, your queueing service and puppetqd on the same +machine means that they are all competing for the same CPU cycles. Bumping +up the power of the server they are running on may be enough to handle +even fairly large deployments. + +However since most queueing services (even StompServer) are designed to +deliver messages from a "queue" to whoever asks for the next message you +can split things up between machines: + + puppetmaster1 --\ /-- puppetqd1 -\ + puppetmaster2 ----> ActiveMQ ---> puppetqd2 ---> database + puppetmaster3 --/ \-- puppetqd33 -/ + \- puppetqd4-/ + +This is, of course a totally contrived example, but it gets the point +across. As long as the data gets to the database, it doesn't matter +which machines or services it goes through. + +Although for StoreConfigs absolute reliability is not a requirement as +a new catalog will be sent the next time a node connects, some amount +of persistence should some process crash may be desirable. Both ActiveMQ +and MySQL (and other databases) have these kind of features built in +which can be activated as needed. -- 1.6.1 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
