[
https://issues.apache.org/jira/browse/SOLR-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16501760#comment-16501760
]
Shawn Heisey commented on SOLR-6734:
------------------------------------
I've been thinking about how an agent might facilitate setting up a fault
tolerant SolrCloud, complete with ZK servers.
Users would start out by running a command like "bin/solr cloudbuild start" on
one node that has been installed as a service. This would start or reconfigure
the agent in a mode where it can begin communicating with other agents. Then
another command or set of commands would be run on that first node to set it up
with necessary services for the cluster.
If multicast communication can be written in Java with relatively simple code,
that would allow the agents to communicate with each other on LAN subnet and
form a SolrCloud cluster without explicit address/hostname configuration. If
somebody got really ambitious and configured multicast routing, they could even
do it on different subnets or across datacenters.
I envision using 239.89.83.0 as a default multicast address. UDP port 8983
seems fitting to use as a default. As each node is configured, with additional
"bin/solr cloudbuild" commands, it will begin sending periodic status packets
on the configured multicast group, which every node will listen to and build a
whole picture of the cluster.
Once there are at least three nodes configured, another command, perhaps
"bin/solr cloudbuild build", can be called. If the overall cluster config
passes validation, this will signal each node to write its configuration for ZK
and Solr, start (or restart) the services, and turn off cloudbuild mode. If
everything goes well, the user will have a functional fault-tolerant SolrCloud
install, without any need to worry about how to install ZK as a separate
service.
I have most of this idea mapped out in my head at a high level. It will
require fleshing out to realize as usable code.
> Standalone solr as *two* applications -- Solr and a controlling agent
> ---------------------------------------------------------------------
>
> Key: SOLR-6734
> URL: https://issues.apache.org/jira/browse/SOLR-6734
> Project: Solr
> Issue Type: Sub-task
> Reporter: Shawn Heisey
> Priority: Major
>
> In a message to the dev list outlining reasons to switch from a webapp to a
> standalone app, Mark Miller included the idea of making Solr into two
> applications, rather than just one. There would be Solr itself, and an agent
> to control Solr.
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201305.mbox/%3C807476C6-E4C3-4E7E-9F67-2BECB63990DE%40gmail.com%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
