Skip to main content
We are excited to be a part of AWS re:Invent 2024. Visit us at booth #1844 in Las Vegas.More info
Loading

Rack awareness

Overview​

This page describes the rack awareness feature available in Aerospike Database Enterprise Edition.

Aerospike data distribution ensures that the master and replicas partitions of each namespace are kept on separate cluster nodes. This means that if fewer nodes than the namespace replication-factor go down, all of the namespace data partitions are available for reads and writes.

A higher degree of resilience is available with the rack awareness feature which can help avoid possible data unavailability when a physical rack fails in a bare-metal deployment, or an Availability Zone (AZ) fails in a cloud deployment.

note

Starting with Database 7.2, the active rack feature dynamically designates a particular rack-id to hold all master partition copies. For instructions on how to enable active rack, see Designate an active rack.

Rack awareness master and replica distribution​

In a rack aware-configured namespace, the replicas are distributed to different hardware failure groups. For example, if the replication-factor is 2 (RF2), the master copy of a partition and its replica are stored in two separate racks, defined by their rack-id.

note

In non-uniform balance, rack awareness only affects the distribution of replica partitions across the cluster nodes.

With uniform-balance set to true, the addition of rack awareness affects the master partitions as well.

Rack awareness also provides a mechanism for database clients to read from the servers in the closest rack or zone on a preferential basis. This can result in lower latency, increased stability, and significantly reduced traffic charges by limiting cross-availability-zone traffic.

Replication factor and number of racks​

  • If the RF is less than or equal to the number of racks, replication factor number of racks are ensured to have one replica for a given partition.

  • If the RF is greater than the number of racks, all racks will have a copy of the partition's data, and some racks will have additional replicas for a given partition.

  • If a single node goes down, the cluster is temporarily imbalanced until the node is restored. This imbalance does not cause service interruptions; the cluster continues uninterrupted. Once the node restarts, the cluster automatically rebalances.

    • Assuming you start with same size racks, masters will still be evenly distributed. As result, the replica balance won't be evenly distributed.

For details on how to configure rack awareness, see Rack-aware.