Today I’m thrilled to announce two new add-ons for Chef Server 12: Chef Server High Availability and Chef Server Replication. These two features are among the most-frequently requested product enhancements and allow customers to geographically distribute highly-available Chef server clusters while maintaining a single view for Chef content – cookbooks, roles, environments, and data bags. These, and other add-ons, can be obtained from the Chef download site.
Chef Server High Availability
In Enterprise Chef 11 and prior, high-availability Chef server clusters could only be reliably built on bare metal, using a shared block device with a technology known as DRBD (distributed replicated block device). DRBD now ships with the base Chef Server 12 product, and today we are introducing a new add-on that will support additional deployment scenarios, such as those in the cloud.
At launch, Chef Server HA supports Amazon Web Services (AWS), because it brings the necessary infrastructure primitives to the table: a block device that can be detached and reattached to the backend Chef servers, as well as a floating (“elastic”) IP. We intend to expand our high-availability support to other popular clustering technologies, like RedHat Cluster Manager, and other clouds, whether public or private, that provide similar kinds of infrastructure primitives. The following diagram illustrates the deployment scenario of Chef Server High Availability in AWS.
There is no high-availability between regions. It is generally considered poor system design to attempt synchronous operations over high-latency links. For that, you likely want to implement Chef Server Replication.
For more information, please see the Chef Server High Availability documentation or skip directly to the section on AWS..
Chef Server Replication
If you have multiple Chef servers in multiple regions (they can be high-availability Chef servers as well), you may be faced with the problem of keeping the content in these servers consistent. That’s where our new Chef Server replication feature comes in. Using this add-on, you designate one of your Chef servers as the primary, and one or more other Chef servers as replicas. Each replica will periodically awaken and synchronize any changed content from the primary: cookbooks, roles, environments, and data bags. Replication can be configured on a per-organization basis. It is also consistent across network partitions.
A typical deployment scenario is to place the primary in one geographic region, and replicas in other geographic regions, as this diagram illustrates.
For more information on Chef Server Replication, please see Chef Server Replication documentation.
Conclusion
We’re introducing Chef high availability and replication today to meet the demands of larger enterprises that want to build highly-available, multi-region Chef server deployments. We’d be delighted if you’d try out these add-ons, and we welcome your feedback.