This documentation describes the a9s RabbitMQ service. a9s RabbitMQ enables on-demand provisioning of VM-based, dedicated RabbitMQ servers and clusters. Developers can create instances of a RabbitMQ server or cluster using Apps Manager or the Cloud Foundry Command Line interface (cf CLI) and bind these instances to an app. Depending on your service plan, a service instance may be associated with a single, dedicated VM or a set of VMs consisting of multiple VMs containing a RabbitMQ cluster.
When you run the cf CLI
create-service rabbitmq command, BOSH creates
dedicated VMs for this service instance. This provides protection from bad neighbors.
RabbitMQ service instance provisioning, including VM orchestration, is entirely automated. This enables service instances to be highly isolated and shielded by infrastructure virtualization mechanisms.
Due to the on-demand provisioning on VMs, only existing service instances allocate infrastructure resources. These resources are released when service instances are destroyed. Using on-demand, provisioning the number of service instances is not limited by design.
Distributed across multiple infrastructure availability zones, clustered data service plans enable short failover times and are resilient against failures of individual infrastructure hosts or entire availability zones.
a9s RabbitMQ includes the following key features:
|On-demand service instance provisioning||a9s RabbitMQ deploys RabbitMQ instances automatically. Developers can provision a single-VM RabbitMQ server or a multi-VM RabbitMQ replica set using one command.|
|Service instance isolation||Each RabbitMQ server runs on a dedicated VM to ensure bad-neighborhood protection and align with enterprise security requirements.
a9s RabbitMQ uses Cloud Foundry application security groups (ASGs) to prevent network connections from unauthorized apps.
|High availability||a9s RabbitMQ ensures high availability using RabbitMQ replication.
The Consul-based internal DNS system ensures that the bound application always connects to a working node.
|Smoke tests||A post-deployment, smoke-test errand runs basic tests against your installation to ensure that it is configured properly.|
|Service instance capacity upgrade||By updating your service plan, you can upgrade the RAM, CPU, and storage capacity for your RabbitMQ instances.|
|Logging and monitoring||Each RabbitMQ service instance provides log messages and RabbitMQ-specific metrics to one or more
|Deployment updater||An updater errand updates the stemcell and all provisioned a9s RabbitMQ service instances to their latest version.|
|Backup Manager||The Backup Manager does regular backups of your instances, and offers endpoints to backup instantly and restore backups.|
|Service Guard||The Service Guard creates Cloud Foundry security groups for your service instance VMs.
When the IP address of a service instance changes, the guard updates the security group. The Service Guard also restarts the application instances bound to the affected service instance. The instances of one application are restarted one by one to avoid downtime.
Specification of a9s RabbitMQ service plans:
(number of nodes)
|Number of vCPUs||2||2||2||2||2||2|
|RAM||0.5 GB||2 GB||4 GB||2 GB||4 GB||4 GB|
|Disk *||3 GB||4 GB||6 GB||4 GB||6 GB||20 GB|
|Connections||No direct limit. Max File 64000|
For example, one backing service instance of size m is high available (consists of 3 nodes), has 2 vCPUs, 4 GB RAM, 6 GB disk, no connection limit but maximum 64000 files and logging component.
* Total virtual disk size. You cannot use the whole disk for your data. For more information, refer Disk Alerts.
Any questions left?
Except where otherwise noted, content on this site is licensed under the MindSphere Development License Agreement.