Separate network interfaces for inter-node communication and update/search requests?

["MOIS Martin (MORPHO)" <ma...@morpho.com>]

Hello,

is it possible to separate the network interface for inter-node communication from the network interface for update/search requests? If so I could put two network cards in each machine and route the index and search traffic over the first interface and the traffic for the inter-node communication (sending documents to replicas) over the second interface.

Best Regards,
Martin Mois
#
" This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system."
#

Re: Separate network interfaces for inter-node communication and update/search requests?

[Anirudha Jadhav <an...@nyu.edu>]

Modern network interfaces are pretty capable. I would doubt this
optimization would yield any performance improvements.
I would love to see some test results which prove me wrong.

is performance the primary reason for this? or do you have any other
reasons.

-Ani

On Thu, Jun 11, 2015 at 9:04 AM, Shawn Heisey <ap...@elyograg.org> wrote:

> On 6/11/2015 6:47 AM, MOIS Martin (MORPHO) wrote:
> > is it possible to separate the network interface for inter-node
> communication from the network interface for update/search requests? If so
> I could put two network cards in each machine and route the index and
> search traffic over the first interface and the traffic for the inter-node
> communication (sending documents to replicas) over the second interface.
>
> Assuming you are using SolrCloud, you would do this by using the name or
> IP address of the internal communication interface on the "host"
> parameter in your solr.xml file (or -Dhost=foo on the startup
> commandline).  This will cause each node to register itself with
> zookeeper using that interface.
>
> Note that what I've said above probably will not work with a cloud-aware
> client like CloudSolrClient/CloudSolrServer in SolrJ, because that
> client will obtain the server/port for each node from zookeeper and try
> to contact each one directly.  The necessary routing probably will not
> be in place.
>
> If it's not SolrCloud, then the shards parameter that you are using for
> distributed search would need internal names/addresses.
>
> The other interface, for queries and updates, would be the one with the
> default gateway.
>
> Thanks,
> Shawn
>
>


-- 
Anirudha P. Jadhav

Re: Separate network interfaces for inter-node communication and update/search requests?

[Shawn Heisey <ap...@elyograg.org>]

On 6/11/2015 6:47 AM, MOIS Martin (MORPHO) wrote:
> is it possible to separate the network interface for inter-node communication from the network interface for update/search requests? If so I could put two network cards in each machine and route the index and search traffic over the first interface and the traffic for the inter-node communication (sending documents to replicas) over the second interface.

Assuming you are using SolrCloud, you would do this by using the name or
IP address of the internal communication interface on the "host"
parameter in your solr.xml file (or -Dhost=foo on the startup
commandline).  This will cause each node to register itself with
zookeeper using that interface.

Note that what I've said above probably will not work with a cloud-aware
client like CloudSolrClient/CloudSolrServer in SolrJ, because that
client will obtain the server/port for each node from zookeeper and try
to contact each one directly.  The necessary routing probably will not
be in place.

If it's not SolrCloud, then the shards parameter that you are using for
distributed search would need internal names/addresses.

The other interface, for queries and updates, would be the one with the
default gateway.

Thanks,
Shawn