# Client rack awareness **URL:** \ **Category:** General Discussion\ **Created:** [April 4, 2019, 12:50am UTC](https://discuss.aerospike.com/t/client-rack-awareness/6110 "2019-04-04T00:50:16Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![sameer.pradhan](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/sameer.pradhan/32/916_2.png) [@sameer.pradhan](https://discuss.aerospike.com/u/sameer.pradhan)\ **Post date:** [April 4, 2019, 12:50am UTC](https://discuss.aerospike.com/t/client-rack-awareness/6110/1 "2019-04-04T00:50:16Z")
As per this thread, > [@Rack aware-ness in the client (AER-5957)](https://discuss.aerospike.com/t/rack-aware-ness-in-the-client-aer-5957/1656): > > The rack awareness feature seems great. Are the client libraries aware of it? Is there a way to specify in the client which node group to go to? For example, if I am running on two ec2 availability zones and I have them set up as separate rack groups, can I tell the client api to prefer going to a node on the same availability zone/cluster group? rack-awareness is supported in Java Client. Where can I find documentation regarding how to use the feature? In particular, how does a client specify which rack id it prefers to connect? Secondly, with client rack-awareness, does the client read data from masters as well as replicas in the specified rack? To clarify the question, consider an example of 2 racks and replication factor of 2, each rack will have masters for half the data and replicas for the other half of the data. My understanding is that normally only the masters are read from, and replicas are used only for rebalance when its master goes down. i.e. replicas are never read from. If client rack-awareness implies that a client always reads all data from the same rack, does that mean it reads from the masters as well as replicas? Thanks. ---
**Author:** ![Albot](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/albot/32/2076_2.png) [@Albot](https://discuss.aerospike.com/u/Albot)\ **Post date:** [April 4, 2019, 3:55am UTC](https://discuss.aerospike.com/t/client-rack-awareness/6110/2 "2019-04-04T03:55:18Z")
You need to define the client rack id manually. When your app comes up in rack X it needs to define that in the clientpolicy before connecting to Aerospike `myClientPolicy.rackId=`. [https://www.aerospike.com/apidocs/java/com/aerospike/client/policy/ClientPolicy.html#rackAware](https://www.aerospike.com/apidocs/java/com/aerospike/client/policy/ClientPolicy.html#rackAware)[https://www.aerospike.com/apidocs/java/com/aerospike/client/policy/ClientPolicy.html#rackId](https://www.aerospike.com/apidocs/java/com/aerospike/client/policy/ClientPolicy.html#rackId) With these optimizations you can tell the client to prefer to only read from the local rack. It won’t have to consult both master/replica unless you define it that way. So if you have two racks, you will be reading from the same rack 100% of the time with this feature but reading only the replica 50% of the time in theory. Additionally, even without rack awareness its possible to tell Aerospike to consult replica’s for reads. See [https://www.aerospike.com/docs/guide/policies.html#replica](https://www.aerospike.com/docs/guide/policies.html#replica) ---
**Author:** ![sameer.pradhan](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/sameer.pradhan/32/916_2.png) [@sameer.pradhan](https://discuss.aerospike.com/u/sameer.pradhan)\ **Post date:** [April 11, 2019, 9:54pm UTC](https://discuss.aerospike.com/t/client-rack-awareness/6110/3 "2019-04-11T21:54:15Z")
Thank you @Albot Once a client has been setup for rack awareness, how would I test/verify that it performed the operation against the same rack? ---
**Author:** ![Albot](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/albot/32/2076_2.png) [@Albot](https://discuss.aerospike.com/u/Albot)\ **Post date:** [April 11, 2019, 10:53pm UTC](https://discuss.aerospike.com/t/client-rack-awareness/6110/4 "2019-04-11T22:53:06Z")
I’m not sure if there is any way to find this, outside of monitoring the network. If you’re paying for cross-AZ traffic like in AWS, you could find this data pretty easily. Someone else in the forum might know a good way though… ---
**Author:** ![kporter](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/kporter/32/515_2.png) [@kporter](https://discuss.aerospike.com/u/kporter)\ **Post date:** [April 16, 2019, 1:22am UTC](https://discuss.aerospike.com/t/client-rack-awareness/6110/5 "2019-04-16T01:22:42Z")
Shouldn’t be too hard. Set up two racks with replication factor 2. Write 100K records to the cluster and then read with a preferred rack. Assuming no ongoing migrations, all of the reads should then occur on the same rack. ---
**Author:** ![sameer.pradhan](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/sameer.pradhan/32/916_2.png) [@sameer.pradhan](https://discuss.aerospike.com/u/sameer.pradhan)\ **Post date:** [April 16, 2019, 2:30am UTC](https://discuss.aerospike.com/t/client-rack-awareness/6110/6 "2019-04-16T02:30:32Z")
@kporter thanks for your response. > Assuming no ongoing migrations, all of the reads should then occur on the same rack. That is my question. How I can tell if all the reads did occur on the same rack? ---
**Author:** ![kporter](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/kporter/32/515_2.png) [@kporter](https://discuss.aerospike.com/u/kporter)\ **Post date:** [April 16, 2019, 2:52am UTC](https://discuss.aerospike.com/t/client-rack-awareness/6110/7 "2019-04-16T02:52:32Z")
Check [https://www.aerospike.com/docs/reference/metrics/#client\_read\_success](https://www.aerospike.com/docs/reference/metrics/#client_read_success). ---
**Author:** ![sameer.pradhan](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/sameer.pradhan/32/916_2.png) [@sameer.pradhan](https://discuss.aerospike.com/u/sameer.pradhan)\ **Post date:** [April 23, 2019, 12:31am UTC](https://discuss.aerospike.com/t/client-rack-awareness/6110/8 "2019-04-23T00:31:10Z")
Thanks @Albot and @kporter for your help.