{
  "id": "rack-zone-awareness",
  "title": "Rack-zone awareness in Redis Enterprise Software",
  "url": "https://redis.io/docs/latest/operate/rs/7.8/clusters/configure/rack-zone-awareness/",
  "summary": "Rack-zone awareness ensures high availability in the event of a rack or zone failure.",
  "content": "Rack-zone awareness helps ensure high availability in the event of a rack or zone failure.\n\nWhen you enable rack-zone awareness in a Redis Enterprise Software cluster, you assign\na [rack-zone ID](#rack-zone-id-rules) to each node. This ID is used to map the node to a\nphysical rack or logical zone. The cluster can then ensure that master shards, corresponding replica shards, and associated endpoints are placed on [nodes in different racks or zones](#node-layout-guidelines).\n\nIn the event of a rack or zone failure, the replicas and endpoints in the remaining racks and zones are promoted. This ensures high availability when a rack or zone fails.\n\nThere is no limitation on the number of racks and zones per cluster. Each\nnode can belong to a different rack or multiple nodes can belong to the\nsame rack.\n\nRack-zone awareness affects various cluster, node, and database actions, such as node rebalancing, node removal, node replacement, shard and endpoint migration, and database failover.\n\n## Rack-zone ID rules\n\nThe rack-zone ID must comply with the following rules:\n\n- Maximum length of 63 characters.\n- Characters consist of letters, digits, and hyphens ('-'). Underscores ('_') are also accepted as of Redis Enterprise Software 6.4.2-61.\n- ID starts with a letter and ends with a letter or a digit.\n\n\nRack-zone IDs are **case-insensitive** (uppercase and lowercase letter are treated as the same).\n\n\n## Node layout guidelines\n\nAvoid placing the majority of nodes in one availability zone.\n\nIf a Redis Enterprise Software cluster consists of three nodes (the recommended minimum), follow these guidelines:\n\n- For high availability, the three nodes must be distributed across three *distinct* racks or zones.\n\n- When using availability zones, all three zones should exist within the same *region* to avoid potential latency issues.\n\n## Set up rack-zone awareness\n\nTo enable rack-zone awareness, you need to configure it for the\ncluster, nodes, and [databases](#enable-database-rack-zone-awareness).\n\n\n- After rack-zone awareness is enabled for a cluster, it cannot be turned off.\n\n- After a rack ID is assigned to a node, it cannot be changed.\n\n\n### New cluster\n\nYou can set up rack-zone awareness for the cluster and its nodes during [cluster creation]():\n\n1. In the **Cluster** screen's **Configuration** section, enable **Rack zone awareness**.\n\n1. Select **Next** to continue to the **Node** configuration screen.\n\n1. Enter a **Rack-zone ID** for the current node.\n\n1. Finish [cluster setup]().\n\n1. For every [node you add to the cluster](), assign a different **Rack-zone ID**.\n\n### Existing cluster\n\nIf you did not configure rack-zone awareness during cluster creation, you can configure rack-zone awareness for existing clusters using the [REST API]():\n\n1. For each node in the cluster, assign a different rack-zone ID using the REST API to [update the node]():\n\n    ```sh\n    PUT /v1/nodes/\u003cnode-ID\u003e\n    { \"rack_id\": \"rack-zone-ID\" }\n    ```\n\n1. [Update the cluster policy]() to enable rack-zone awareness:\n\n    ```sh\n    PUT /v1/cluster/policy\n    { \"rack_aware\": true }\n    ```\n\n## Enable database rack-zone awareness\n\nBefore you can enable rack-zone awareness for a database, you must configure rack-zone awareness for the cluster and its nodes. For more information, see [set up rack-zone awareness](#set-up-rack-zone-awareness).\n\n\u003c!--\nTo enable rack-zone awareness for a database using the Cluster Manager UI:\n\n1. From **databases**, [create a new database]() or edit an existing database's **configuration**.\n\n1. Expand the **High availability \u0026 durability** section.\n\n1. Enable [**Replication**]().\n\n1. Select **Rack-zone awareness**.\n\n    \n\n1. **Create** or **Save** your database.\n\n1. [Rearrange database shards](#rearrange-database-shards) to optimize an existing database for rack-zone awareness.\n\n    \nIf you enabled rack-zone awareness during database creation, you can ignore this step.\n    \n--\u003e\n\nTo enable rack-zone awareness for a database, use a [REST API request]():\n\n```sh\nPUT /v1/bdbs/\u003cdatabase-ID\u003e\n{ \"rack_aware\": true }\n```\n\n### Rearrange database shards\n\nAfter you enable rack-zone awareness for an existing database, you should generate an optimized shard placement blueprint using the [REST API]() and use it to rearrange the shards in different racks or zones.\n\n1. [Generate an optimized shard placement blueprint]():\n\n    1. Send the following `GET` request:\n\n        ```sh\n        GET /v1/bdbs/\u003cdatabase-ID\u003e/actions/optimize_shards_placement\n        ```\n\n    1. Copy the `cluster-state-id` from the response headers.\n\n    1. Copy the JSON response body, which represents the new shard placement blueprint.\n\n1. [Rearrange the database shards]() according to the new shard placement blueprint:\n\n    1. In the request headers, include the \u003cnobr\u003e`cluster-state-id`\u003c/nobr\u003e from the `optimize_shards_placement` response.\n\n    1. Add the following JSON in the request body and replace \u003cnobr\u003e`\u003cshard placement blueprint\u003e`\u003c/nobr\u003e with the new blueprint:\n\n        ```sh\n        {\n          \"shards_blueprint\": \u003cshard placement blueprint\u003e\n        }\n        ```\n\n    1. Send the following `PUT` request to rearrange the shards:\n\n        ```sh\n        PUT /v1/bdbs/\u003cdatabase-ID\u003e\n        ```\n\n## Shard placement without rack-zone awareness\n\nEven if a database has rack-zone awareness turned off, the cluster still ensures that master and replica shards are placed on distinct nodes.\n",
  "tags": ["docs","operate","rs","kubernetes"],
  "last_updated": "2026-04-01T08:10:08-05:00"
}