We are pleased to announce the general availability of VMware Tanzu RabbitMQ, a new enterprise version of the popular open source message broker enhanced by VMware’s RabbitMQ engineering experts. You can download it from Tanzu Network today.
Inter-node data compression and multisite schema replication
Consistent releases and predetermined upgrade stages
24x7 support backed by the software engineers that are building RabbitMQ, who have experience with a wide range of enterprise deployments
Why did VMware create its own optimized RabbitMQ? After all, the open source version is wildly popular, with more than 1 billion downloads to date. It is because we saw that when RabbitMQ is used successfully in the enterprise, common patterns emerge, patterns that could be codified in an enhanced RabbitMQ distribution. Enterprises do not just need validated, tested components; they also require consistent releases and easy access to always-available, extended support. Enterprises that use RabbitMQ, meanwhile, need clusters that are secure, highly resilient, and observable. And when enterprises run hundreds or even thousands of these clusters, ease of scale and upgrading becomes very important.
With that in mind, let us take a look at how Tanzu RabbitMQ simplifies enterprise deployments.
Single release artifact, up and running in minutes
Tanzu RabbitMQ ships as a container image that works the same on all flavors of infrastructure. It can be run locally for development or testing with Docker, on any certified Kubernetes installation (including VMware Tanzu Kubernetes editions) with the official RabbitMQ Kubernetes Cluster Operator, and even directly on VMware vSphere 7, which supports containerized workloads out of the box. Regardless of where you run it, Tanzu RabbitMQ is optimized for enterprise needs: inter-node data compression to save on bandwidth costs, multisite schema replication for near-instant failover, and the best selection of runtime components, all curated and integrated by RabbitMQ engineers.
Tanzu RabbitMQ makes it easy to architect resilient, loosely coupled, data-safe systems. Application developers can connect distributed applications using a variety of protocols and formats without having to worry about interoperability, reliability, or scalability.
Watch a demonstration to see how easy it is to provision a new, production-ready RabbitMQ cluster spanning multiple availability zones in minutes.
Tanzu RabbitMQ 1.0.0 release notes include a written guide on how to get started.
New enterprise features
The open source RabbitMQ is a good way to get started with the technology. But for demanding enterprise environments, customers told us they wanted more capabilities out of the box. Here is a rundown of our favorite Tanzu RabbitMQ features.
Inter-node data compression
All data traffic between nodes in a cluster is now compressed by default. This can result in significant cost saving for clusters spanning multiple availability zones, something we commonly see in resilient, production RabbitMQ clusters.
In a test in our own labs, with inter-node data compression enabled, given a message payload of 8kB, and a rate of 11,575 messages per second, when the message replication factor is set to 3, all nodes in the cluster transfer approximately 16 MB/s (or 128Mbps):
Data transfer with inter-node compression enabled
Without compression, the combined nodes data transfer is 195 MB/s (or 1.5Gbps):
Data transfer without compression
To see how much Tanzu RabbitMQ can reduce the bandwidth bill for your messaging workload, use our monthly cost savings calculator.
The Tanzu RabbitMQ cost savings calculator can be customized with your own parameters
In the example above, given a quorum queue with three replicas, with each replica running in a different availability zone, and a rate of a billion messages per day at an average message size of 8kB, Tanzu RabbitMQ will reduce the inter-zone network traffic cost in Google Cloud by $5,484 and in AWS and Azure by as much as $10,967 in a single month. This calculation is based on public pricing as specified in VM-VM egress pricing within Google Cloud, data transfer within the same AWS region, and VNET peering within the same region for Azure.
Read the official documentation on Tanzu RabbitMQ inter-node data compression.
Multisite schema replication
One Tanzu RabbitMQ deployment can replicate the schema (users, virtual hosts, exchanges, queues, bindings, and policies) of another. This enables service continuity via a hot standby that runs in a different site, be it another region or continent. The hot standby has the entire schema from the primary deployment, and it’s able to take over from the primary deployment with minimal impact on clients—they need only reconnect to the hot standby.
When extra redundancy is required, multiple downstream deployments can be configured to replicate the schema of a single upstream deployment. The downstream deployments can be placed on different continents as the schema replication is an asynchronous and highly efficient process.
Read the official documentation on Tanzu RabbitMQ multisite schema replication.
Production-ready by default
Out of the box, Tanzu RabbitMQ implements the memory-to-disk ratio production-safe default setting, as noted in the official Production Checklist. For example, if a node is configured with 16GB of memory, the disk free limit is set to 16GB. The free edition of RabbitMQ uses a 50MB limit, which works well for development but is not a production-safe value.
Another Tanzu RabbitMQ production-ready feature is the improved handling of crash dumps. In the rare instance of a node crash, we limit how much crash-related data is written to disk. In the open source edition of RabbitMQ, nodes will write the entire contents of memory used to disk. This is known to prolong node unavailability and use up all available disk space, which results in nodes being unable to start.
Last but not least, the runtime version and configuration, as well as cryptographic libraries, conform to recommendations by VMware’s RabbitMQ engineers for enterprise deployments. TLS v1.0 and v1.1 are disabled as they are no longer considered safe by the Internet Engineering Task Force and as such, would not be PCI-compliant.
I’m a Tanzu RabbitMQ for VMs customer: What should I expect?
Tanzu RabbitMQ differs from Tanzu RabbitMQ for VMs in a few key ways:
Includes commercial extensions (e.g., inter-node data compression and multisite schema replication)
Distributed as a container image and runnable on any container runtime, including all certified Kubernetes distributions
These features will not be ported to Tanzu RabbitMQ for VMs.
Get your copy, and get started today
Learn more about new Tanzu RabbitMQ features via short, how-to videos, on our official Tanzu RabbitMQ page. There you can also find out what to expect in terms of upcoming releases and lifecycle policy, review frequently asked questions, and use our aforementioned cost savings calculator.