Introduction to Blue/Green Deployments with Hazelcast IMDG

This is the first blog post for Hazelcast IMDG’s Blue/Green Deployments feature, which is the most recent member of the Enterprise edition. 

“Blue/Green deployment” refers to a software technique used to reduce or even eliminate system downtime and the associated business risk by deploying two mirrored production environments referred to as “Blue” and “Green”. 

In Hazelcast IMDG 3.12, we released a new Hazelcast Enterprise feature for Blue/Green deployments. It provides a client failover mechanism that allows for client connections to be rerouted to a different cluster without requiring a client network configuration update or client restart. This feature can be used to manually redirect client traffic in order to perform maintenance or software updates, as well as automatically redirect client traffic to a different cluster during a disaster recovery scenario. Respectively, Blue/Green Deployments and Automatic Disaster Recovery are the main two usages of this feature.

Blue/Green Deployments

This capability provides Hazelcast IMDG application users with a seamless experience, by eliminating downtime with an always-ready standby cluster. In this model, one of the clusters provides production services to clients while the other cluster can be upgraded with the new application code.

Hazelcast IMDG offers the flexibility to migrate all clients of a cluster, subsets of clients, or select groups of clients using label filtering and black/white lists which are configured using the Management Center of Hazelcast IMDG. Using the Cluster Client Filtering screen, you can configure your IMDG clients so they can automatically connect to another cluster when blacklisted from a currently connected cluster, including subsets using client labels to the black or white list.

Automatic Disaster Recovery

This is a special form of the Blue/Green Deployments feature. It allows your applications to switch automatically to another cluster when the target production cluster becomes unavailable.

Please note that there is no limit in terms of the number of clusters that can be used as Green both in “Blue/Green Deployments” and “Automatic Disaster Recovery” capabilities.

Features worth mentioning

Configurable Client Behavior After the Disconnection

Client behavior after disconnection is set using a `reconnect-mode` configuration within the client.

• ON: The client changes the cluster and blocks invocations
• ASYNC: The client changes the cluster in the background and issues a `HazelcastClientOfflineException` to the logs, to alert that the client has been disconnected from its primary cluster.
• OFF: The client does not change the cluster; it shuts down immediately.

Prioritize Clusters When Clients Try to Connect

More than one cluster can be listed in the client configuration for fail-over. The order of the clusters that the client will try to connect is decided by order of the cluster declarations provided in the client configuration.

Supports CNAME

CNAME re-routing is a useful approach to take for blue/green switching of clusters where the listing of different cluster addresses in client configuration is not practical. Use `CNAME DNS` entries and change the resolved hostname, then force disconnects of clients from the currently connected cluster via the Management Center.

Closing Words

This was the initial blog post for our Blue/Green Deployments feature. In the second post of this series, I will go through top scenarios where you can benefit from the Blue/Green Deployments. If you would like to learn more now, you can download my white paper:

• Blue/Green Deployments & Auto Disaster Recovery Failover Scenarios

Documentation:

• Hazelcast IMDG
• Management Center

Free Training:

• https://training.hazelcast.com

Join the Discussion:

• Google Group: https://groups.google.com/forum/#!forum/hazelcast
• Stack Overflow: http://stackoverflow.com/questions/tagged/hazelcast
• Gitter: https://gitter.im/hazelcast/hazelcast