5.4 Pivotal RabbitMQ

• vCloud Director and the vCloud API include a framework for integration of extensions services that a vCloud API client can access as though they were native services. In addition to service-specific objects or operations they provide, extension services can implement new operations for existing API objects.

• vCloud messages provide the capability to connect vCloud Director with external systems by posting notifications or blocking task messages to AMQP-based enterprise messaging brokers.

Both options rely on an AMQP message broker, which must be installed. The AMQP service must be configured in vCloud Director. VMware recommends Pivotal RabbitMQ as the AMQP broker.

vCloud Director AMQP service (the publisher) sends messages to AMQP exchange which then routes them to specific queues based on a routing key. The external systems (the consumers) connect to queues and listen to the messages. See VCD-nclient VMware Fling¹ for a quick introduction to the feature.

$C:\Users\Tomas Fojta\Documents\VMware Files\vCloud Director\vCloud Architecture Toolkit\3.0\vCAT 3.0 Documentation Center\Architecting a vCloud\images\3a Architecting a VMware vCloud.2.132.1.jpg$

The following are RabbitMQ design considerations:

• vCloud Director cells retry delivering messages to the AMQP broker until the configured timeout period is reached.

• vCloud System Administrator is informed by email when the connection to the AMQP server is lost.

• RabbitMQ broker can be clustered for high availability. All definitions (exchanges, bindings, users, and so on) are mirrored across the entire cluster. You can either use load-balanced RabbitMQ nodes (configure AMQP service in vCloud Director with the virtual IP of the load balancer), or each vCloud cell can have RabbitMQ service installed (point AMQP service to the localhost address).

Clustered RabbitMQ does not handle network partitions well. Therefore, deployment of nodes across sites is not recommended. Split-brain scenario causes some messages not to be delivered properly. Monitoring for cluster state is essential. Take care when RabbitMQ nodes are powered off and on. The last clustered node that shuts down must be powered on first, otherwise the cluster is not started.

• By default, queues reside only on the node where they were declared. For high availability, they must be mirrored across nodes with one master and multiple slaves—this is enabled through a policy. The messages published to the queue are replicated to all slaves. Consumers are connected to the master regardless of which node they attach to, with slaves dropping messages that have been acknowledged at the master.

• The consumer subscribes to the same queue through all RabbitMQ brokers or by using a load-balanced broker and is able to retrieve messages in case of a node failure.

• While VMware still offers download of VMware vFabric® RabbitMQ, the Pivotal Web site offers the latest version. Pivotal provides RabbitMQ support as well.

• RabbitMQ scales up to thousands of messages per second, which is much more than vCloud Director is able to publish. Therefore, there is no need to load balance RabbitMQ nodes for performance reasons.

• RabbitMQ can use SSL both for communication with vCloud Director and the consumers. Enable this when such communication goes over unsecured networks.

• In some rare cases, tenants might need to access organization-specific vCloud messages to connect their own orchestration tools. While this scenario is more likely to be used in dedicated cloud environments, it is possible to accommodate such a request with the RabbitMQ Shovel plug-in. The provider deploys the tenant’s own instance of RabbitMQ and the provider RabbitMQ proxies a subset of vCloud messages to the tenant instance.

• The Shovel plug-in can be also used for aggregation of messages from multiple vCloud Director instances into one RabbitMQ receiver. This might be useful in multi-region set-up where the federation portal consumes messages from a central aggregated RabbitMQ instance.

An example of a highly available RabbitMQ design is shown in the following figure. RabbitMQ is co-installed with vCloud Director on each cell virtual machine in a clustered configuration and queue mirroring is enabled. The AMQP Service in vCloud Director points the AMQP host to a localhost URL. The consumer (for example vRealize Orchestrator) establishes a subscription with each node. No load balancer is needed.

For environments with a larger number of cells and where RabbitMQ consumers cannot establish multiple subscriptions (for example vCloud Availability for vCloud Director), VMware recommends using dedicated load-balanced RabbitMQ nodes.