Hazelcast Management Center v4.2021.04 Release

I’m pleased to announce Management Center v4.2021.04 has been released as of today! Let’s see what this new release brings.

Before we start, please note that the following features require you to have an enterprise license. You can request a free enterprise trial license here.

Configuration Check Improvements

Management Center has a very useful feature where it receives the effective configuration from all members of a cluster and checks for various issues. There are two broad categories of issues that it checks:

1. Equality checks make sure parts of the configuration that should be the same for all members of a cluster are configured the same
2. Semantic checks detect when a configuration is syntactically valid but semantically wrong

In the earlier versions of Management Center, we only reported when there’s a problem. With this release, you can now see all the checks that are performed, either as a success or failure on the user interface. We have also added equality checks for the WAN replication configuration with this release. Give it a try to see the list of all the checks performed.

High Availability Support for Client Filtering

For many of our users, Management Center acts as the central component for managing Hazelcast clusters, which means that Management Center needs to be available all the time. The usual way to achieve this is to run multiple instances of Management Center and front them with a load balancer. Unfortunately, this doesn’t work out of the box as each Management Center has its own local persistent storage which is not shared between these instances. This approach usually is not a big problem as long as you make sure each Management Center has the same configuration by applying the same configuration to each individual Management Center instance. However, our client filtering feature doesn’t fit into this picture nicely.

When you configure a client filtering list on the Management Center and deploy it to a cluster, Management Center continuously polls the cluster to make sure all members apply the correct filtering rules. It’s all good until another Management Center is started which connects to the same cluster. The second Management Center wants to enforce the rules from its own local persistent storage to the cluster upon connecting to it, which is of course empty at that point. What happens is both Management Centers try to apply their rules, and the cluster fluctuates between the two sets of rules until you configure the second Management Center to have the same rules as the first one.

With this version of Management Center, we fix this problem by using the target cluster as the shared storage for the client filtering lists so that whenever a new Management Center connects to the cluster, it copies the existing list into its own local persistent storage so that both Management Center instances have the same info, and the target cluster doesn’t fluctuate its rules.

One could wonder why we don’t treat client filtering lists the same as the rest of the configuration and let our users make sure they’re the same on different Management Center instances. The answer is most of the configuration data of Management Center is not very dynamic and can be configured easily before Management Center starts but client filtering lists are a more operational concern that are usually updated/deployed during regular operation of the cluster.

We have also updated our documentation with more information about how to run Management Center in a high availability setup. Make sure to read it before using Management Center in such a setup as it details some important caveats that you should be careful about.

Cluster Health Check API

Management Center exposes a REST API (called the Clustered REST API) which you can use to get information about all the monitored clusters. With this release, we add another endpoint under “/rest/health” that can be used to get an overview of the health of all your clusters. We have also extended one of our existing endpoints to provide the same information for a specific cluster (under the “/rest/clusters/{cluster name}” endpoint). Don’t forget to enable the clustered REST API first. You can read more about the endpoint in our documentation.