Auto-exit of Maintenance Mode

Maintenance Mode

The maintenance mode in Helix refers to a Helix cluster state where the Helix Controller will not trigger any type of rebalance. In short, if a cluster is in maintenance, the Controller will not bootstrap any new partitions. However, this does not mean that there won't be any (upward) state transitions. For example, partitions missing a top-state (e.g. MASTER/LEADER) replica will get a state transition in order to fill in the void for a top-state replica.

Maintenance Recovery Threshold

Recall that there are two cases in which a cluster may enter maintenance mode automatically:

1. There are more offline/disabled instances than ClusterConfig's MAX_OFFLINE_INSTANCES_ALLOWED.
2. There exist instances that have more partitions than ClusterConfig's MAX_PARTITIONS_PER_INSTANCE.

It is important to note that we are mainly concerned with Case 1. Case 2 is meant to be a sanity check against Helix's CRUSH-ed rebalance algorithm, and this has little to do with the original motivation behind cluster maintenance mode. So, although we will still check against Case 2 when determining whether it is safe to exit maintenance mode, we will only address Case 1 in this section.

With that said, it is not hard to imagine a cluster in production experiencing a flip-flop behavior around the exact value of ClusterConfig's MAX_OFFLINE_INSTANCES_ALLOWED field. Such behavior is undesirable and may defeat the purpose of using this feature. To mitigate it in design is to have a separate, more strict threshold for recovering out of maintenance mode. We therefore propose to add a new field, MAINTENANCE_RECOVERY_THRESHOLD. MAINTENANCE_RECOVERY_THRESHOLD will be defined by the user and hold a more conservative value than MAX_OFFLINE_INSTANCES_ALLOWED to allow for some wiggle room in deciding what value is enough to call a cluster “sufficiently recovered”. Additionally, we will also give users the flexibility to “opt-out” of the auto-exit feature by treating a MAINTENANCE_RECOVERY_THRESHOLD value of -1 as a disable signal.

In short,

• If NumOfflineDisabledInstances < NUM_OFFLINE_INSTANCES_FOR_AUTO_EXIT, exit maintenance mode
• NUM_OFFLINE_INSTANCES_FOR_AUTO_EXIT <= MAX_OFFLINE_INSTANCES_ALLOWED
• NUM_OFFLINE_INSTANCES_FOR_AUTO_EXIT < 0 or not set → Opt-out of auto-exiting of maintenance mode

Additional Fields in MaintenanceSignal

Currently, Helix stores the maintenance signal in /{CLUSTER_NAME}/CONTROLLER/MAINTENANCE. A sample maintenance signal ZNode will look like the following:

{
  "id" : "maintenance",
  "simpleFields" : {
    "REASON" : "Offline Instances count 5 greater than allowed count 4. Stop rebalance and put the cluster CLUSTER_TestClusterInMaintenanceModeWhenReachingOfflineInstancesLimit into maintenance mode.",
    "TRIGGERED_BY" : "CONTROLLER",
    "TIMESTAMP" : "12312838831***",
    // The following are sample user-defined fields from the REST call payload //
    "id" : "hulee",
    "jira" : "HELIX-123",
    "cluster" : "testCluster"
  },
  "listFields" : {
  },
  "mapFields" : {
  }
}

A simpleField will be newly added (notice the “TRIGGERED_BY” field) to denote whether the current maintenance signal has been generated automatically by the Controller. There will initially be two possible entries for this field:

• CONTROLLER
• USER

Also, the TIMESTAMP field will be added so that the value could be retrieved via REST.

In addition, we will allow addition of custom fields in simpleFields. See the example above. Users will be able to add these fields by using the REST endpoints that will be provided when enabling the maintenance mode. Note that when disabling maintenance mode, these fields will no longer be available because disabling maintenance mode will remove the maintenance signal altogether.

Recording Maintenance History

Currently, Helix maintains the controller history in the /{clusterName}/CONTROLLER/HISTORY ZNode. We plan to add a history for maintenance mode. This way, users will be able to access the history in ZooKeeper directly, or utilize the REST endpoint for viewing. The format will be in a human-readable format like the following (this is how Helix maintains the Controller leader history):

long currentTime = System.currentTimeMillis();
DateFormat df = new SimpleDateFormat("yyyy-MM-dd-HH:mm:ss");
df.setTimeZone(TimeZone.getTimeZone("UTC"));
String dateTime = df.format(new Date(currentTime));

Note that Helix only records 10 most recent changes in the HISTORY ZNode. We will follow a similar protocol for persisting maintenance mode-related history. Note that all changes around maintenance mode will be recorded (both entering and exiting of the mode).

Backward Compatibility

Old versions of Helix Controllers will not refer to the newly-added fields, in which case they will simply lack the auto-exit functionality.

Asynchronous Processing

Note that in order for a cluster to exit maintenance mode, the Controller must check against all conditions that are outlined above. That is, it needs to make sure 1) the total count of offline/disabled instances is less than the threshold and that 2) there are no instances with more partitions than the threshold. Checking against Condition 2 requires traversing all resources' states, which could be costly in clusters of large scale. From this, we potentially risk adding a significant latency to the pipeline, which is undesirable because it could cause problems regarding availability (for example, longer pipeline runs may exacerbate the rate at which ZooKeeper Event Callbacks accumulate. Helix currently deals with a large number of ZK Event Callbacks by re-booting the Controller, which could nick Helix's as well as applications' availability numbers).

For this reason, we will make the checks happen asynchronously. Additional tweak may be required to ensure that the maintenance signal is cached appropriately through each run of the pipeline to avoid the race condition.

Periodic Check on Cluster Recovery Status

Auto-exit is inherently triggered as part of Helix's rebalance pipeline; that is, if there is no rebalance triggered, there wouldn't be any auto-exits triggered either. In theory, this is a non-issue because whether a cluster goes into or recovers out of maintenance mode is determined by changes around LiveInstances, and a LiveInstance change is an event that triggers Helix's rebalance pipeline.

Regardless, there has been anecdotal reports where such events seemed to have been “swallowed” or “disappeared” - if that is true for any reason (mostly a ZK callback queue issue), one way to mitigate it is to enable periodically-triggered rebalances. Note that this is actually a feature already supported by Helix.

Why Use Auto-Exit

Helix is used to manage resources in distributed clusters; therefore, it inevitably gets to have hundreds of instances. With so many clusters and traffic to the ZooKeeper, Helix's metadata store, there are cases in which some Participants in the cluster experience transient connection failure, which may cause Helix to respond to each little change that happens to the cluster. For users of stateful systems, this may be undesirable, so they opt to set a config for entering maintenance mode automatically. Maintenance mode is a temporary mode that the cluster can enter in order to ensure that there are no bootstrapping state transitions on instances.

However, no bootstrapping state transitions could mean that some operations such as addition of resources would be halted, which causes periods of unavailability. It was the cluster operator's responsibility to determine whether the given cluster has sufficiently recovered enough to exit maintenance mode. The auto-exit feature removes such overhead.

Guide

First, we encourage all users of this feature to understand Helix's workflow below:

In order to use this feature, you'd need to set the following config parameters in your cluster's ClusterConfig.