Chapter 10. Creating Collectives

A Collective is a set of ActiveMQ topics and queues used to group request traffic. In small installations you should use a single Collective. The installation we have done in this book uses the default collective name mcollective for all configurations.

You may want to create multiple collectives for the following reasons:

  1. Collectives can be used to limit traffic in large clusters or between sites.
  2. Collectives can be used to group nodes together for restricting client access.

Deciding When to Create More

There are a few reasons why you may want to implement multiple collectives in your network:

  1. You have more than a thousand servers.
  2. You have multiple locations with high latency between them.
  3. You have multiple locations and you’d like to reduce the network traffic between them.
  4. You want to allow local admins control of their own hosts, while allowing a global team to administer all hosts.

Following are a few reasons you don’t want to implement multiple collectives:

  1. You want fault tolerance in your middleware setup.

    Sub-Collectives do not intrinsically provide fault tolerance. That can be created by using a Network of Brokers or Master/Slave setup, as documented in ActiveMQ Clusters. Collectives are most effective at limiting traffic when placed on brokers localized to each site.

  2. You want to implement barriers for authorization control.

    While you can restrict clients to specific collectives to limit server access, this isn’t a granular authorization mechanism. We suggest using the facilities documented in Authorization.

  3. You have different Puppet domains.

    While Puppet and MCollective play nice together, their domains don’t need to overlap. You can use a single MCollective for many Puppet domains or vice versa.

If you feel that you require distinct collectives according to the list above, let’s go over how to create them.

Collectives != Clustering

One thing to understand up front is that Collectives are different from ActiveMQ Clusters.

A Collective is a set of ActiveMQ topics and queues used to isolate network traffic. An ActiveMQ Cluster provides fault tolerance for a set of topics and queues. It’s quite possible to run hundreds of Collectives on a single ActiveMQ broker, which would provide zero fault tolerance. Likewise, you could use dozens of ActiveMQ brokers to provide extensive fault tolerance and high performance for a single Collective.

Most environments use something in between, such as:

  1. A Master/Slave pair of brokers which support all Collectives for single-site redundancy
  2. A network of brokers with one ActiveMQ broker in each location which hosts all Collectives at that site
  3. A network of brokers with multiple ActiveMQ brokers in each location
  4. A combination of the three above

We provide some examples of ActiveMQ cluster configuration in ActiveMQ Clusters. For now, it is only important to realize that these are distinct. The Collective is a message path configured on top of network of brokers.

Note

If you are familiar with the OSI model for networking, it is not entirely accurate but easiest to think of Clustering as Layer 4, and Collectives as Layer 6. This reflects how the Collective is an application specific path used in the collection.

(We’ll just quietly ignore that this metaphor breaks down when using multiple Collectives on different servers, as that means multiple Layer 4 connections.)

Configuration Traffic

The following configuration parameters define the collectives a client is attached to:

client.cfg.  

collectives = mcollective,asia,europe,usa
main_collective = mcollective

On any given server you want to only put it in the relevant, local collectives:

server.cfg.  

collectives = mcollective,asia
main_collective = mcollective

You can query the servers to learn which collectives they are part of. You can write the collective structure out to a DOT abstract graph to be read with Graphviz, ZGRViewer, and various conversion utilities.

$ mco inventory --list-collectives
   Collective                     Nodes
   ==========                     =====
   asia                           4
   europe                         7
   usa                            3
   mcollective                    14
                     Total nodes: 14

$ mco inventory --collective-graph all_sites.dot
Retrieving collective info....
Graph of 14 nodes has been written to all_sites.dot

You can query a given server to learn which collectives it is part of.

$ mco rpc rpcutil collective_info -I heliotrope

heliotrope
   All Collectives: ["mcollective","asia"]
   Main Collective: mcollective

When submitting commands you can define a target for any request you send out, thus limiting the request to the smaller collective. If you don’t define a target, the request will be sent to the collective identified in the main_collective parameter of your client.cfg file.

$ mco ping --target asia
...only the asia nodes respond

Localizing Traffic

The middleware will only send traffic where it knows that someone is listening. This is due to how the topic subscription mechanism works. If only five machines have the puppet plugin loaded (and are thus subscribed to the collective.puppet.agent topic), only those five machines will receive requests sent out from the puppet client plugin.

Likewise, if all systems on a given collective are attached to certain brokers, the middleware brokers will not replicate the collective’s messages to brokers without anyone subscribed to those topics or queues. This will greatly reduce the amount of traffic traveling between the sites.

To gain this benefit, design your collectives as such:

  1. Use one collective that all hosts are subscribed to for registration and other global messages. (e.g. mcollective)
  2. Add one collective for each physical or infrastructure distinct area. For simplicity you might want to name this the country, city, airport code or any other easy to remember name.

Configure the middleware to accept the same client and server logins for the new collective names:

<authorizationEntry queue="site.>" write="clients" read="clients" admin="clients" />
<authorizationEntry topic="site.>" write="clients" read="clients" admin="clients" />
<authorizationEntry topic="site.*.agent" read="servers" admin="servers" />
<authorizationEntry queue="site.reply.>" write="servers" admin="servers" />

Configure the servers in that area as follows:

collectives = mcollective,site-name
main_collective = mcollective

Then configure the clients to have every local site available in their configuration:

collectives = mcollective,site #1,site #2,site #3
main_collective = mcollective

This configuration will allow the administrators to issue commands only to specific sites, or to all hosts based on how they target their request:

$ mco ping --target site #2
...only local site #2 nodes respond

$ mco puppet runall 10 --target mcollective
Puppet runs on every node in any site

Limiting Access

Another reason to use multiple collectives is to limited access to local admin teams at each site. To gain this benefit, design your collectives as such:

  1. Use one collective that all hosts are subscribed to for registration and other global messages. (e.g. mcollective)
  2. Add one collective for each set of servers which is managed by a distinct set of clients.
  3. Ensure that each collective has a unique group name for access.

Unfortunately the configuration changes for this grow linear with the number of different groups you have. Each group of admins requires a unique client login and unique group name. In the following example we will demonstrate a two-group system using operations and developers. Each of these can only take actions in their own collective. The main client

<authenticationUser username="ops" password="ops passwd"
  groups="ops-clients,everyone"
/>
<authenticationUser username="dev" password="dev passwd"
  groups="dev-clients,everyone"
/>

<authorizationEntry queue="dev.>"
  write="clients,dev-clients" read="clients,dev-clients" admin="clients,dev-clients"
/>
<authorizationEntry topic="dev.>"
  write="clients,dev-clients" read="clients,dev-clients" admin="clients,dev-clients"
/>
<authorizationEntry topic="dev.*.agent"
  read="servers,dev-servers" admin="servers,dev-servers"
/>
<authorizationEntry queue="dev.reply.>"
  write="servers,dev-servers" admin="servers,dev-servers"
/>

<authorizationEntry queue="ops.>"
  write="clients,ops-clients" read="clients,ops-clients" admin="clients,ops-clients"
/>
<authorizationEntry topic="ops.>"
  write="clients,ops-clients" read="clients,ops-clients" admin="clients,ops-clients"
/>
<authorizationEntry topic="ops.*.agent"
  read="servers,ops-servers" admin="servers,ops-servers"
/>
<authorizationEntry queue="ops.reply.>"
  write="servers,ops-servers" admin="servers,ops-servers"
/>

This leverages our earlier configuration such that the main client login will continue to have global access to all collectives, which each of these new logins will only be able to send messages and receive messages on their own collectives.

Configure the servers in that area in the more limited collective as follows:

collectives = mcollective,dev-servers
main_collective = mcollective

Configure the clients to have only the servers available in their configuration:

plugin.activemq.pool.1.user = dev
plugin.activemq.pool.1.password = dev password
collectives = mcollective,dev
main_collective = dev

This configuration will allow the developer administrators to issue requests only to dev systems, while the global admins (with the username and password to the client account) will continue to have access to all hosts.

$ mco ping --target dev
...only dev nodes respond -- both global and developer admins can do this

$ mco puppet runall 10 --target mcollective
Puppet runs on both operations and dev nodes -- only global admins can do this

Conclusion

The use of multiple collectives can assist with handling scale at several different levels. In most situations you don’t need more than the default collective until you are experiencing problems with scale, or you need to restrict access for certain groups (customers, dev teams, etc).

It is good to understand the features available in this chapter, but I wouldn’t recommend using multiple collectives until you need them.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.118.205.235