deploying.html.md.erb

---
breadcrumb: VMware RabbitMQ for Tanzu Application Service Documentation
title: Deploying the VMware RabbitMQ for Tanzu Application Service Pre-Provisioned Service
owner: London Services
---

## <a id="default"></a>Default Deployment

Deploying <%= vars.product_full %> through <%= vars.ops_manager %> deploys a
RabbitMQ cluster of **3 nodes** by default.
The deployment includes a single load balancer `haproxy` which spreads connections
on all of the default ports, for all of the shipped plugins across all of the machines within the cluster.
The deployment occurs in a single availability zone (AZ).

The default configuration is for testing purposes only and VMware recommends that
customers have a minimum of **3 RabbitMQ nodes** and **2 HAProxy nodes**

The diagram below shows the default <%= vars.product_short %> pre-provisioned deployment.

<%= image_tag("images/deployment_default.png",
:alt => "The default pre-provisioned deployment shows
Tanzu Application Service and an app within it. The app communnicates to the HAProxy, which communicates to three RabbitMQ nodes. The HAProxy and RabbitMQ nodes are within
VMware RabbitMQ for Tanzu Application Service, which is within availability zone 1.") %>

### <a id="default-consider"></a>Considerations for the Default Deployment

* Provides high availability for the RabbitMQ cluster
* Queues must be configured to be high availability as they are placed on one node by default
* Customers should decide which partition behavior is best suited to their use case. For two nodes 'automatic' is preferred.
* HAProxy is a single point of failure (SPOF)
* The entire deployment is in a single AZ, which does not protect against external failures from failures in hardware, networking, etc.

## <a id="recommended"></a>Recommended Deployment

VMware recommends that <%= vars.product_short %> is deployed across at least two AZs.
Scale RabbitMQ server nodes to an odd number that is greater than or equal to three.

Only use replication of queues where required as it can have a big impact on system performance.

The HAProxy job instance count should also be increased to match the number of AZs to ensure there is a HAProxy located in each AZ.
This removes the HAProxy SPOF and provides further redundancy.

The diagram below shows the recommended <%= vars.product_short %> pre-provisioned deployment.
It shows that when you use this configuration, if a single HAProxy and single RabbitMQ node fail,
your cluster can remain online and apps remain connected.

<%= image_tag("images/deployment_recommended.png",
:alt => "An app is inside 'Tanzu Application Service'. It tries to communicate
to the failed HAProxy and to a functioning HA Proxy. The HA proxy
tries to communicate with the failed RabbitMQ node before communicating
with a functioning RabbitMQ node. These components are inside the VMware RabbitMQ for Tanzu Application Service
service, within Availability Zone 1 and Availability Zone 2.") %>

### <a id="upgrade-from-single-az"></a>Upgrading to the Recommended Deployment from a Single AZ Deployment

It is **not** possible to upgrade to this setup from the default deployment across a single AZ.

This is because the AZ setup cannot be changed after the tile has been deployed for the first time.
This is to protect against data loss when moving jobs between AZs.

### <a id="upgrade-from-multi-az"></a>Upgrading to the Recommended Deployment from a Multi AZ Deployment

If you have deployed the tile across two AZs, but with a single HAProxy instance,
you can migrate to this setup by deploying an additional HAProxy instance through <%= vars.ops_manager %>.
New or re-bound apps to the <%= vars.product_short %> service instance see the IPs of both HAProxies immediately.
Existing bound apps will continue to work, but only using the previously deployed HAProxy IP Address. They can be re-bound as required at your discretion.

### <a id="recommended-consider"></a>Considerations for the Recommended Deployment

* Requires IaaS configuration for AZs ahead of deploying the <%= vars.product_short %> tile
* Application developers are handed the IPs of each deployed HAProxy in their environment variables
* Queues must be configured to be high availability as they are placed on one node by default
* Customers should decide on which partition behavior is best suited to their use case. For three or more nodes 'pause_minority' is preferred.

## <a id="advanced"></a>Advanced Deployment

This deployment builds upon the above recommended deployment and so follows the same upgrade paths.
This allows you to replace the use of HAProxy with your own external load balancer.
You might choose to do this to remove any knowledge of the topology of the <%= vars.product_short %> setup from app developers.

The diagram below shows an advanced <%= vars.product_short %> pre-provisioned deployment.

<%= image_tag("images/deployment_advanced.png",
:alt => "Tanzu Application Service has an existing bound app and a re-bound app.
The existing bound app goes through the same sequence as the diagram in the recommended
deployment. It communicates with the working RabbitMQ node through the HAProxy.
The re-bound app communicates with the customer's load balancer, which then communicates
directly to the working RabbitMQ Node.") %>

**Advantages:**

* App developers do not need to handle multiple IPs for the HAProxy jobs in their apps

**Disadvantages:**

* The load balancer needs to be configured with the IPs of the RabbitMQ Nodes.
These are only be known after the deployment is finished.
 The IPs should remain the same during subsequent deployments but there is a risk they might change.


### <a id="upgrade-from-recommended"></a>Upgrading to the Advanced from the Recommended Deployment

It is possible to first deploy with multiple HAProxy jobs, as per the recommended deployment, and later use your own external load balancer.

This can be achieved without downtime to your apps. Follow these steps to do so:

1. Configure your external load balancer to point to the RabbitMQ Node IPs.
2. Configure the DNS name or IP address for the external load balancer (ELB) on the <%= vars.product_short %> tile in <%= vars.ops_manager %>.
3. Deploy the changes. Any new <%= vars.product_short %> service instances **or** any re-bound connections
will use the DNS name or IP address of the ELB in their `VCAP_SERVICES`.
Any existing service instances continue to use the HAProxy IP addresses in their `VCAP_SERVICES`
6. Phase the re-binding of existing apps to update their environment variables.
7. After all apps are updated, reduce the instance count of the `HAProxy` job in <%= vars.ops_manager %> to 0.
9. Deploy the changes.

This approach works as any existing bound apps have their `VCAP_SERVICES` information cached in Cloud Controller and are only updated by a re-bind request.

### <a id="downgrade-to-recommended"></a>Downgrading from the Advanced Deployment to the Recommended Deployment

If you are currently using an external load balancer, then you can move back to using HAProxies instead.

You can achieve this by following the above steps in reverse order and re-instating the HAProxy jobs.

## <a id="resource-requirements"></a>Resource Requirements

The following table shows the default resource and IP requirements for installing the tile:
<table border="1" class="nice">
	<tr>
		<th>Product</th>
		<th>Resource</th>
		<th>Instances</th>
		<th>Core</th>
		<th>Ram</th>
		<th>Ephemeral</th>
		<th>Persistent</th>
		<th>Static IP</th>
		<th>Dynamic IP</th>
	</tr>
	<tr>
		<td>RabbitMQ</td>
		<td>RabbitMQ node</td>
		<td>3</td>
		<td>2</td>
		<td>8192</td>
		<td>16384</td>
		<td>30720</td>
		<td>1</td>
		<td>0</td>
	</tr>
	<tr>
		<td>RabbitMQ</td>
		<td>HAProxy for RabbitMQ</td>
		<td>1</td>
		<td>1</td>
		<td>2048</td>
		<td>4096</td>
		<td>0</td>
		<td>1</td>
		<td>0</td>
	</tr>
	<tr>
		<td>RabbitMQ</td>
		<td><%= vars.product_short %> service broker</td>
		<td>1</td>
		<td>1</td>
		<td>2048</td>
		<td>4096</td>
		<td>0</td>
		<td>1</td>
		<td>0</td>
	</tr>
	<tr>
		<td>RabbitMQ</td>
		<td>Broker Registrar</td>
		<td>1</td>
		<td>1</td>
		<td>1024</td>
		<td>2048</td>
		<td>0</td>
		<td>0</td>
		<td>1</td>
	</tr>
	<tr>
		<td>RabbitMQ</td>
		<td>Broker Deregistrar</td>
		<td>1</td>
		<td>1</td>
		<td>1024</td>
		<td>2048</td>
		<td>0</td>
		<td>0</td>
		<td>1</td>
	</tr>
	<tr>
		<td>RabbitMQ</td>
		<td>Smoke Tests</td>
		<td>1</td>
		<td>1</td>
		<td>1024</td>
		<td>2048</td>
		<td>0</td>
		<td>0</td>
		<td>1</td>
	</tr>
	<tr>
		<td>RabbitMQ</td>
		<td>RabbitMQ on-demand broker</td>
		<td>1</td>
		<td>1</td>
		<td>1024</td>
		<td>8192</td>
		<td>1024</td>
		<td>0</td>
		<td>1</td>
	</tr>
	<tr>
		<td>RabbitMQ</td>
		<td>Register On-Demand Service Broker</td>
		<td>1</td>
		<td>1</td>
		<td>1024</td>
		<td>2048</td>
		<td>0</td>
		<td>0</td>
		<td>1</td>
	</tr>
	<tr>
		<td>RabbitMQ</td>
		<td>Deregister On-Demand Service Broker</td>
		<td>1</td>
		<td>1</td>
		<td>1024</td>
		<td>2048</td>
		<td>0</td>
		<td>0</td>
		<td>1</td>
	</tr>
	<tr>
		<td>RabbitMQ</td>
		<td>Delete All Service Instances</td>
		<td>1</td>
		<td>1</td>
		<td>1024</td>
		<td>2048</td>
		<td>0</td>
		<td>0</td>
		<td>1</td>
	</tr>
	<tr>
		<td>RabbitMQ</td>
		<td>Upgrade All Service Instances</td>
		<td>1</td>
		<td>1</td>
		<td>1024</td>
		<td>2048</td>
		<td>0</td>
		<td>0</td>
		<td>1</td>
	</tr>
	<tr>
		<td>RabbitMQ</td>
		<td>Recreate All Service Instances</td>
		<td>1</td>
		<td>1</td>
		<td>1024</td>
		<td>2048</td>
		<td>0</td>
		<td>0</td>
		<td>1</td>
	</tr>
</table>

#### Notes:
* The number of `RabbitMQ Node` can be increased if required.