This is an automated email from the ASF dual-hosted git repository. ishan pushed a commit to branch jira/SOLR15694 in repository https://gitbox.apache.org/repos/asf/solr.git
commit e4e24dce8aa7540a1d1e0287ddac071ac468317d Author: Ishan Chattopadhyaya <[email protected]> AuthorDate: Fri Dec 17 14:15:01 2021 +0530 SOLR-15694: Ref guide changes --- solr/solr-ref-guide/src/node-roles.adoc | 65 +++++++++++++++++++++++++ solr/solr-ref-guide/src/solrcloud-clusters.adoc | 4 ++ 2 files changed, 69 insertions(+) diff --git a/solr/solr-ref-guide/src/node-roles.adoc b/solr/solr-ref-guide/src/node-roles.adoc new file mode 100644 index 0000000..f3e5969 --- /dev/null +++ b/solr/solr-ref-guide/src/node-roles.adoc @@ -0,0 +1,65 @@ += Node Roles +// Licensed to the Apache Software Foundation (ASF) under one +// or more contributor license agreements. See the NOTICE file +// distributed with this work for additional information +// regarding copyright ownership. The ASF licenses this file +// to you under the Apache License, Version 2.0 (the +// "License"); you may not use this file except in compliance +// with the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, +// software distributed under the License is distributed on an +// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +// KIND, either express or implied. See the License for the +// specific language governing permissions and limitations +// under the License. + +A node in Solr is usually capable of performing various types of operations, e.g. hosting replicas, performing indexing and querying on them, collection management tasks etc. However, if someone wants to setup a cluster where these functionalities are isolated to certain dedicated nodes, then this can be achieved leveraging the concept of node roles. + +== Definitions + +=== Node role + +A role is a designation of a node that indicates that the node may perform a certain functionality that is governed by the role. + +=== Mode +Every role has a list of modes under which a node can be. It can be simple (e.g. `["on", "off"]`) or more granular (e.g. `["allowed", "preferred", "disallowed"]`). + +== Roles + +In order to specify role(s) for a node, one needs to start a Solr node with the following parameter. + +.Startup Parameter +[cols="1,2,1,1"] +|=== +|Parameter |Value |Required? | Default + +|solr.node.roles +|Comma separated list of roles (in the format: <role>:<mode>) for this node. +Examples: "data:on,overseer:allowed" or "overseer:preferred" +|No +|data:on,overseer:allowed +|=== + +[TIP] +==== +If a node has been started with no `solr.node.roles` parameter, it will be assumed to have the data role turned on and overseer role allowed on it. If you've never needed roles before, you likely won't need to change anything in your startup parameters to accomodate the functionality associated with these roles. +==== + + +=== `data` role +A node with this role (in mode "on") can host shards and replicas for collections. + +=== `overseer` role +A node with this role can perform duties of an overseer node (unless mode is `disallowed`). When one or more nodes have the overseer role in `preferred` mode, the overseer leader will be elected from one of these nodes. In case no node is designated as a preferred overseer or no such node is live, the overseer leader will be elected from one of the nodes that have the overseer role in `allowed` mode. If all nodes that are designated with overseer role (allowed or preferred) are down, the [...] + +== A typical scenario of roles usage + +A common situation arises when the nodes in a cluster is under heavy querying or indexing load, and under such circumstances the overseer leader node is unable to perform collection management duties efficiently. It might be reasonable to have dedicated nodes to act as the overseer. Such an effect can be achieved as follows: + +* Most nodes, say 10 of them, in the cluster start with `-Dsolr.node.roles=data:on,overseer:allowed` (or with no parameter, since the default value for `solr.node.roles` is the same). +* One or more nodes can start with `-Dsolr.node.roles=overseer:preferred` (or `-Dsolr.node.roles=overseer:preferred,data:off`) + +In this arrangement, such dedicated nodes can have lesser resources than other data nodes (since these are stateless nodes) and yet the cluster will behave optimally. In case the dedicated overseer nodes go down for some reason, the overseer leader will be elected from one of the data nodes (since they have overseer in "allowed" mode), and once one of the dedicated overseer nodes are back up, it will assume the overseer leadership again. \ No newline at end of file diff --git a/solr/solr-ref-guide/src/solrcloud-clusters.adoc b/solr/solr-ref-guide/src/solrcloud-clusters.adoc index 83b3fde..03723f5 100644 --- a/solr/solr-ref-guide/src/solrcloud-clusters.adoc +++ b/solr/solr-ref-guide/src/solrcloud-clusters.adoc @@ -3,6 +3,7 @@ solrcloud-recoveries-and-write-tolerance, \ solrcloud-distributed-requests, \ aliases, \ + node-roles, \ cluster-node-management, \ shard-management, \ replica-management, \ @@ -47,6 +48,9 @@ ZooKeeper is a critical component of SolrCloud, used to manage shard and replica | <<solrcloud-recoveries-and-write-tolerance.adoc#,SolrCloud Recoveries and Write Tolerance>>: Recovery in a SolrCloud cluster. | <<solrcloud-distributed-requests.adoc#,SolrCloud Distributed Requests>>: Query routing in a SolrCloud cluster. | <<aliases.adoc#,Aliases>>: Alternative names for collections. +2+^h| Cluster Management +| <<node-roles.adoc#,Node Roles>>: Functional roles for nodes for multi-tiered clusters. +| 2+^h| Collections API |<<cluster-node-management.adoc#,Cluster and Node Management>>: Cluster management commands of the Collections API. | <<shard-management.adoc#,Shard Management>>: Shard management commands of the Collections API.
