You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Ween Jiann (Jira)" <ji...@apache.org> on 2019/09/26 03:45:00 UTC
[jira] [Comment Edited] (SOLR-13788) Resolve multiple IPs from
specified zookeeper URL
[ https://issues.apache.org/jira/browse/SOLR-13788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938236#comment-16938236 ]
Ween Jiann edited comment on SOLR-13788 at 9/26/19 3:44 AM:
------------------------------------------------------------
I'm trying to modify the helm chart for solr such that it works for kubernetes (k8s) deployment correctly. There needs to be a particular change in the way solr resolves zookeepers hostname in order for this to happen.
Let me explain...
The standard way to configure solr is by listing all the zookeeper hostname/IP in either:
* {{solr.in.sh}} or {{solr.in.cmd}}
* {{zoo.cfg}}
* {{-z param}}
For example: ZK_HOST="zk1:2181,zk2:2181,zk3:2181".
However, when it comes to cloud deployment, in particular on k8s using helm chart, this is not an ideal situation as the user is required to modify zk_host each time they scale the number of zookeeper up/down.
For example (scale down): ZK_HOST="zk1:2181,zk2:2181".
For example (scale up): ZK_HOST="zk1:2181,zk2:2181,zk3:2181,zk4:2181".
And this cannot be done automatically using in helm. In k8s, this parameter should remain static, meaning that it should not be changed after deployment of the chart.
For example (k8s): ZK_HOST="zk-headless:2181".
What a chart can do is to create a service with a DNS name such as zk-headless that contains all the IP of the zookeeper, and as zookeeper scales, the number of IP resolved from zk-headless changes. I'm asking if there could be an improvement that allows solr to resolve multiple zookeeper IPs from a single name.
I will also raise this question on the user's list.
was (Author: lwj5):
I'm trying to modify the helm chart for solr such that it works for kubernetes (k8s) deployment properly. There needs to be a particular change in the way solr resolves zookeepers hostname in order for this to happen.
Let me explain...
The standard way to configure solr is by listing all the zookeeper hostname/IP in either:
* {{solr.in.sh}} or {{solr.in.cmd}}
* {{zoo.cfg}}
* {{-z param}}
For example: ZK_HOST="zk1:2181,zk2:2181,zk3:2181".
However, when it comes to cloud deployment, in particular on k8s using helm chart, this is not an ideal situation as the user is required to modify zk_host each time they scale the number of zookeeper up/down.
For example (scale down): ZK_HOST="zk1:2181,zk2:2181".
For example (scale up): ZK_HOST="zk1:2181,zk2:2181,zk3:2181,zk4:2181".
And this cannot be done automatically using in helm. In k8s, this parameter should remain static, meaning that it should not be changed after deployment of the chart.
For example (k8s): ZK_HOST="zk-headless:2181".
What a chart can do is to create a service with a DNS name such as zk-headless that contains all the IP of the zookeeper, and as zookeeper scales, the number of IP resolved from zk-headless changes. I'm asking if there could be an improvement that allows solr to resolve multiple zookeeper IPs from a single name.
I will also raise this question on the user's list.
> Resolve multiple IPs from specified zookeeper URL
> -------------------------------------------------
>
> Key: SOLR-13788
> URL: https://issues.apache.org/jira/browse/SOLR-13788
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 8.1.1
> Reporter: Ween Jiann
> Priority: Minor
> Labels: features
>
> Use DNS lookup to get the IPs of the servers listed in ZK_HOST or -z param. This would help cloud deployment as DNS is often used to group services together.
> [https://lucene.apache.org/solr/guide/8_1/setting-up-an-external-zookeeper-ensemble.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org