# TCP load-balancer with client nodes

**URL:** <https://discuss.elastic.co/t/tcp-load-balancer-with-client-nodes/86043>\
**Category:** Elasticsearch\
**Created:** [May 17, 2017, 5:01am UTC](https://discuss.elastic.co/t/tcp-load-balancer-with-client-nodes/86043 "2017-05-17T05:01:50Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Utkarsh\_Pyne](https://avatars.discourse-cdn.com/v4/letter/u/a587f6/32.png) [@Utkarsh\_Pyne](https://discuss.elastic.co/u/Utkarsh_Pyne)\
**Post date:** [May 17, 2017, 5:01am UTC](https://discuss.elastic.co/t/tcp-load-balancer-with-client-nodes/86043/1 "2017-05-17T05:01:50Z")

</div>

We are separating our cluster into data and client nodes and plan to have client nodes behind a TCP load balancer so that applications can connect to the cluster via TransportClient. We have multiple applications, each with multiple hosts, persisting data at different rate into the same cluster.

Is it a good approach to route requests via TCP load balancer or can there be any concerns?

---

<div class="post-metadata">

**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\
**Post date:** [May 17, 2017, 5:32am UTC](https://discuss.elastic.co/t/tcp-load-balancer-with-client-nodes/86043/2 "2017-05-17T05:32:09Z")

</div>

Just a note. We are moving to the REST Client which means that Transport layer will be deprecated for a client usage in the future.  
You should start to consider load balancing the REST layer instead.

Is it a good approach? Yes. I don't see anything bad with that.

---

<div class="post-metadata">

**Author:** ![ivank](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ivank/32/7595_2.png) [@ivank](https://discuss.elastic.co/u/ivank)\
**Post date:** [May 17, 2017, 4:36pm UTC](https://discuss.elastic.co/t/tcp-load-balancer-with-client-nodes/86043/3 "2017-05-17T16:36:55Z")

</div>

What will be with performance?

- JSON-serialized data has greater size in bytes than binary serialized data
- More time is needed to [de]serialize to JSON then to binary

And it is strange that Elasticsearch 5.x has no NodeClient. We used it to send data directly to shards instead of sending to each node in round robin manner

---

<div class="post-metadata">

**Author:** ![Utkarsh\_Pyne](https://avatars.discourse-cdn.com/v4/letter/u/a587f6/32.png) [@Utkarsh\_Pyne](https://discuss.elastic.co/u/Utkarsh_Pyne)\
**Post date:** [May 17, 2017, 7:23pm UTC](https://discuss.elastic.co/t/tcp-load-balancer-with-client-nodes/86043/4 "2017-05-17T19:23:38Z")

</div>

@dadoonet I searched about TCP load-balancing more and found this - Transport client makes 14 connections to a host and it's possible that the load-balancer may not map all the 14 connections to the same host behind the load-balancer but I guess the transport client assumes that it will be connected to the same host with 14 connections, please correct me if I'm wrong?

---

<div class="post-metadata">

**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\
**Post date:** [May 17, 2017, 9:18pm UTC](https://discuss.elastic.co/t/tcp-load-balancer-with-client-nodes/86043/5 "2017-05-17T21:18:04Z")

</div>

> [@ivank](#):
>
> And it is strange that Elasticsearch 5.x has no NodeClient.

You can still do something similar with: [Connecting a Client to a Coordinating Only Node | Java Transport Client (deprecated) [7.17] | Elastic](https://www.elastic.co/guide/en/elasticsearch/client/java-api/current/client-connected-to-client-node.html)

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [June 14, 2017, 9:18pm UTC](https://discuss.elastic.co/t/tcp-load-balancer-with-client-nodes/86043/6 "2017-06-14T21:18:04Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
