The Chef Indexer is comprised of a RabbitMQ message queue, chef-expander, which pulls messages from the queue and formats them, and chef-solr, a thin wrapper around Solr.
RabbitMQ provides a queuing service which stores requests for updates to the search index. This allows the API server to handle load spikes while maintaining an even load on Solr.
We recommend you read RabbitMQ's administration guide before deploying it into production.
Configuring Chef's RabbitMQ-Specific Settings
Configuring RabbitMQ for Chef
Chef requires you to configure a user and vhost in RabbitMQ. Normally, this configuration will be handled for you by either post-install scripts in Chef packages, or in the rabbitmq_chef recipe included in the bootstrap install. You only need to run these commands if you are doing a fully manual installation or have destroyed your RabbitMQ configuration somehow.
To configure RabbitMQ for Chef using the default vhost "/chef", user "chef", and password "testing". (You may need to do this as "rabbitmq" user or whatever user rabbitmq runs as):
To verify that your configuration is correct:
As of Chef 0.10, you can configure Chef to use RabbitMQ persistence. This means that RabbitMQ will store queued messages on disk, allowing them to be recovered if RabbitMQ should fail (but not if the disk on the box running RabbitMQ fails). To enable persistence, make sure you are running RabbitMQ 2.2 or higher. Then set
Chef Expander fetches messages from RabbitMQ, processes them into the correct format to be loaded into Solr and loads them into Solr.
Running Chef Expander
Chef Expander is designed for clustered operation, though small installations will only need one worker process. To run Chef Expander with one worker process, run
Workers are single threaded and therefore cannot use more than 100% of a single CPU. If you find that your queues are getting backlogged (see Operation and Troubleshooting, below), increase the number of workers.
Chef Expander Operation and Troubleshooting
Chef Expander includes
If you suspect that a worker process is stuck, as long as you are using clustered operation, you can simply kill the worker process and it will be restarted by the master process.
Chef Expander uses 1024 queues (called vnodes in some places) to allow you to scale the number of Chef Expander workers to meet the needs of your infrastructure. When objects are saved in the API server, they are added to queues based on their database IDs. These queues can be assigned to different Chef Expander workers to distribute the load of processing the index updates.
Redundancy and Scaling Options with Chef Indexer
The point of setting the queue name is to switch between messages going from 1 producer to N consumers or messages going from 1 producer to (1 of N) consumers. When multiple consumers share the same queue name, you'll have the 1->(1 of N) behavior; with multiple consumers with distinct queue names, you'll get the 1-> N behavior.
The use cases these address in Chef are: