SolrCloud 分布式集群安装部署以及管理

时间  2019-12-05
标签 solrcloud 分布式 集群 安装 部署 以及 管理 栏目 云服务 繁體版
原文   原文链接

SolrCloud 分布式集群安装部署html

SolrCloud 是基于Solr和Zookeeper的分布式搜索方案，是正在开发中的Solr4.0的核心组件之一，它的主要思想是使用Zookeeper做为集群的配置信息中心。
它有几个特点功能：
1. 集中式的配置信息
2. 自动容错
3. 近实时搜索
4. 查询时自动负载均衡java

一.环境准备工做：
1. 5台物理服务器 centos5.8 64位
2. apache-tomcat-7.0.54
3. jdk1.8.0_11
4. zookeeper-3.4.6.tar.gz
5. solr-4.8.1.zipnode

环境搭建：
1. 设置环境变量(java、zookeeper)
PS：可根据本身的服务器标准化准则自行设定；
2. 修改主机名web

solr-cloud-001
solr-cloud-002
solr-cloud-003
solr-cloud-004
solr-cloud-005
  1. 为5台服务器配置映射节点（可直接使用IP+PORT的方式）
    cat /etc/hosts
10.0.0.1   solr-cloud-001
10.0.0.2   solr-cloud-002
10.0.0.3   solr-cloud-003
10.0.0.4   solr-cloud-004
10.0.0.5   solr-cloud-005

ZooKeeper集群中具备两个关键的角色：Leader和Follower;
集群中全部的节点做为一个总体对分布式应用提供服务，集群中每一个节点之间都互相链接，
因此，在配置的ZooKeeper集群的时候，每个节点的host到IP地址的映射都要配置上集群中其它节点的映射信息。
ZooKeeper采用一种称为Leader election的选举算法。在整个集群运行过程当中，只有一个Leader，其余的都是Follower，
若是ZooKeeper集群在运行过程当中 Leader出了问题，系统会采用该算法从新选出一个Leader。
所以，各个节点之间要可以保证互相链接，必须配置上述映射。
ZooKeeper集群启动的时候，会首先选出一个Leader，在Leader election过程当中，某一个知足选举算的结点就能成为Leader;算法

若有疑问，可参考官网介绍 http://zookeeper.apache.org/doc/trunk/zookeeperOver.html#sc_designGoalsapache

二.正式solrcloud集群搭建json

zookeeper 部署vim

Zookeeper 分布式服务框架是 Apache Hadoop的一个子项目，它主要是用来解决分布式应用中常常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。centos

PS：Zookeeper集群的机器个数推荐是奇数台，半数机器挂掉，服务是能够正常提供的；tomcat

如今以10.0.0.1为例来部署zookeeper:
1. mkdir -p /apps/soft
cd /apps/soft
wget http://mirrors.hust.edu.cn/apache/zookeeper/zookeeper-3.4.6/zookeeper-3.4.6.tar.gz
tar zxvf zookeeper-3.4.6.tar.gz
mv /apps/soft/zookeeper-3.4.6 /apps/svr/zookeeper

  1. 新建zookeeper的数据存储目录和日志文件目录
    mkdir -p /apps/dat/zookeeper
    mkdir -p /apps/logs/zookeeper

  2. cd /apps/svr/zookeeper/conf
    cp -av zoo_sample.cfg zoo.cfg
    vim zoo.cfg并修改以下：

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/apps/dat/zookeeper
dataLogDir=/apps/logs/zookeeper
clientPort=2181
 #maxClientCnxns=60
 #minSessionTimeout=4000
 #maxSessionTimeout=40000
server.1=solr-cloud-001:4888:5888
server.2=solr-cloud-002:4888:5888
server.3=solr-cloud-003:4888:5888
server.4=solr-cloud-004:4888:5888
server.5=solr-cloud-005:4888:5888

PS:若是以前没有配置/etc/hosts，此处可以使用IP+PORT的方式

tickTime：这个时间是做为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每一个 tickTime 时间就会发送一个心跳。
initLimit：这个配置项是用来配置 Zookeeper 接受客户端（这里所说的客户端不是用户链接 Zookeeper 服务器的客户端，而是 Zookeeper服务器集群中链接到 Leader 的 Follower 服务器）初始化链接时最长能忍受多少个心跳时间间隔数。当已经超过 10 个心跳的时间（也就是tickTime）长度后 Zookeeper 服务器尚未收到客户端的返回信息，那么代表这个客户端链接失败。总的时间长度就是52000=10秒。
syncLimit：这个配置项标识 Leader 与 Follower 之间发送消息，请求和应答时间长度，最长不能超过多少个tickTime 的时间长度，总的时间长度就是22000=4秒
dataDir：顾名思义就是 Zookeeper 保存数据的目录，默认状况下，Zookeeper 将写数据的日志文件也保存在这个目录里。
dataLogDir： Zookeeper的日志文件位置。
server.A=B：C：D：其中 A 是一个数字，表示这个是第几号服务器；B是这个服务器的 ip 地址；C 表示的是这个服务器与集群中的 Leader服务器交换信息的端口；D 表示的是万一集群中的 Leader 服务器挂了，须要一个端口来从新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通讯的端口。若是是伪集群的配置方式，因为 B 都是同样，因此不一样的 Zookeeper 实例通讯端口号不能同样，因此要给它们分配不一样的端口号。
clientPort：这个端口就是客户端链接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。

  1. 同步至其他4台服务器;
    scp -r /apps/svr/zookeeper username@'10.0.0.2':/app/svr/
    scp -r /apps/svr/zookeeper username@'10.0.0.3':/app/svr/
    scp -r /apps/svr/zookeeper username@'10.0.0.4':/app/svr/
    scp -r /apps/svr/zookeeper username@'10.0.0.5':/app/svr/

  2. 分别在每台机器上建立myid文件存储该机器的标识码

    echo "1" >> /apps/dat/zookeeper/myid

    echo "2" >> /apps/dat/zookeeper/myid

    echo "3" >> /apps/dat/zookeeper/myid

    echo "4" >> /apps/dat/zookeeper/myid

    echo "5" >> /apps/dat/zookeeper/myid

    以此类推；

  3. 启动zookeeper； PS：注意iptables limit
    启动方式：cd /apps/svr/zookeeper/bin && ./zkServer.sh start
    启动成功后查看启动状态： ./zkServer.sh status
    如显示mode: follower or mode: Leader
    就表示启动成功；
    PS：可经过查询结果看出，5台机器中哪台被选中当了Leader，哪台选中当了follower
    另外，能够经过客户端脚本，链接到ZooKeeper集群上。对于客户端来讲，ZooKeeper是一个总体（ensemble），
    链接到ZooKeeper集群实际上感受在独享整个集群的服务，因此，你能够在任何一个节点上创建到服务集群的链接。

三.Solrcloud分布式集群搭建

  1. cd /apps/soft
    mkdir -p /apps/dat/web/working/solr/data(solr数据存储目录)
    wget archive.apache.org/dist/lucene/solr/4.8.1/solr-4.8.1.zip
    unzip solr-4.8.1.zip

  2. cp -av /apps/soft/solr-4.8.1/example/webapps/solr.war /apps/dat/web/working/solr/
    cd /apps/dat/web/working/solr && jar -xvf solr.war
    cp -av /apps/svr/solr-4.8.1/example/lib/ext/*.jar /apps/dat/web/working/solr/WEB-INF/lib/

  3. mkdir -p /apps/conf/solr/config-files
    mkdir -p /apps/conf/solr/solr-lib
    cp -av /apps/svr/solr-4.8.1/example/solr/collection1/conf/* /apps/conf/solr/config-files/
    cp -av /apps/dat/web/working/solr/WEB-INF/lib/*.jar /apps/conf/solr/solr-lib/

  4. vim /apps/dat/web/working/solr/WEB-INF/web.xml(添加solr数据存储目录)

<env-entry>   
  <env-entry-name>solr/home</env-entry-name>   
  <env-entry-value>/apps/dat/web/working/solr/data</env-entry-value>   
  <env-entry-type>java.lang.String</env-entry-type>
</env-entry>

  1. cp -av /apps/svr/solr-4.8.1/example/lib/ext/*.jar /apps/svr/tomcat/lib/
    cp -av /apps/svr/solr-4.8.1/example/resources/log4j.properties /apps/svr/tomcat/lib/
    cp -av /apps/svr/solr-4.8.1/example/solr/solr.xml /apps/svr/solr-4.8.1/example/solr/zoo.cfg /apps/dat/web/working/solr/data

  2. vim /apps/svr/tomcat/conf/server.xml 修改以下：

  3. vim /apps/svr/tomcat/bin/catalina.sh 注释掉JAVA_OPTS，而且添加以下：

JAVA_OPTS="$JAVA_OPTS  -Xmx8192m -Xms8192m -Xmn4g -Xss256k -XX:ParallelGCThreads=24 -DzkHost=solr-cloud-001:2181,solr-cloud-002:2181,solr-cloud-003:2181,solr-cloud-004:2181,solr-cloud-005:2181 -XX:+UseConcMarkSweepGC -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=8060 -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=10.0.0.1  -XX:PermSize=1024m -XX:MaxPermSize=1024m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -XX:+PrintHeapAtGC -Xloggc:/apps/logs/tomcat/gc`date +%Y%m%d%H%M%S`.log -XX:ErrorFile=\"/apps/logs/tomcat/java_error.log\""

  1. 将tomcat的目录分发至其他服务器的相应的位置；

  2. SolrCloud是经过ZooKeeper集群来保证配置文件的变动及时同步到各个节点上，因此，须要将配置文件上传到ZooKeeper集群中：执行以下操做：
    java -classpath .:/apps/conf/solr/solr-lib/* org.apache.solr.cloud.ZkCLI -cmd upconfig -zkhost 10.0.0.1:2181,10.0.0.2:2181,10.0.0.3:2181,10.0.0.4:2181,10.0.0.5:2181 -confdir /apps/conf/solr/config-files/ -confname myconf

    java -classpath .:/apps/conf/solr/solr-lib/* org.apache.solr.cloud.ZkCLI -cmd linkconfig -collection collection1 -confname myconf -zkhost 10.0.0.1:2181,10.0.0.2:2181,10.0.0.3:2181,10.0.0.4:2181,10.0.0.5:2181

  3. 分发完毕之后，咱们能够检查一下zookeeper的存储状况：
    cd /apps/svr/zookeeper/bin/
    ./zkCli.sh -server solr-cloud-001:2181

[zk: solr-cloud-001:2181(CONNECTED) 2] ls /configs/myconf
[currency.xml, mapping-FoldToASCII.txt, protwords.txt, synonyms.txt, scripts.conf, stopwords.txt, velocity, _schema_analysis_synonyms_english.json, admin-extra.html, update-script.js, _schema_analysis_stopwords_english.json, solrconfig.xml, admin-extra.menu-top.html, elevate.xml, schema.xml, clustering, spellings.txt, xslt, mapping-ISOLatin1Accent.txt, lang, admin-extra.menu-bottom.html]

  1. 启动10.0.0.1上的tomcat，这时候，SolrCloud集群中只有一个活跃的节点，并且默认生成了一个collection1实例，能够经过web界面访问http://10.0.0.1:8080/solr

  2. 启动其他4台服务器的tomcat，会在zookeeper集群中查看到当前全部的集群状态：

[zk: solr-cloud-001:2181(CONNECTED) 1] ls /live_nodes
[10.0.0.1:8080_solr, 10.0.0.2:8080_solr, 10.0.0.3:8080_solr, 10.0.0.4:8080_solr, 10.0.0.5:8080_solr]

这时，已经存在5个active的节点了，可是SolrCloud集群并无更多信息;

  1. 建立collection、Shard和replication

上面连接中的几个参数的含义，说明以下：

curl 'http://10.0.0.2:8080/solr/admin/collections?action=CREATE&name=userinfo&numShards=3&replicationFactor=1'
建立3个分片1个副本

curl 'http://10.0.0.2:8080/solr/admin/collections?action=CREATE&name=userinfo&numShards=5&replicationFactor=3&maxShardsPerNode=3'
建立5个分片3个副本

name 待建立Collection的名称
numShards 分片的数量
replicationFactor 复制副本的数量

执行上述操做若是没有异常，已经建立了一个Collection，名称为userinfo；这时，也能够查看ZooKeeper中状态：

[zk: solr-cloud-001:2181(CONNECTED) 3] ls /collections
[collection1, userinfo]

经过Web管理页面，访问http://10.0.0.1:8080/solr/#/~cloud查看SolrCloud集群的分片信息；

到此为止，咱们基于5个物理节点，配置完成了SolrCloud集群多节点的配置。

扩展内容：
solrCloud 管理
更多的solrcloude管理信息，请参考http://eksliang.iteye.com/blog/2124078

建立collection：
./zkcli.sh -cmd upconfig -zkhost 10.0.0.1:2181/solrcloud -confdir /apps/conf/solr/config-files-confname test_date
curl 'http://10.0.0.1:8080/solr/admin/collections?action=CREATE&name=test_date&numShards=1&replicationFactor=3'

修改collection的配置信息：
写入ZK：
1. sh zkcli.sh -zkhost 10.0.0.1:2181/solrcloud -cmd upconfig -confdir /apps/conf/solr/config-files -confname collection1
2. reload conf： curl 'http://10.0.0.1:8080/solr/admin/collections?action=RELOAD&name=collection1'

删除collection
curl 'http://10.0.0.1:8080/solr/admin/collections?action=DELETE&name=test'
数据目录下只保留了目录，数据已经删除了。
zk中的该collection的信息没有被删除。

split shard
curl 'http://10.0.0.1:8080/solr/admin/collections?action=SPLITSHARD&collection=name&shard=shardID'

delete inactive shard
curl 'http://10.0.0.1:8080/solr/admin/collections?action=DELETESHARD&shard1=shardID&collection=name'

给分片建立副本：
curl 'http://10.0.0.1:8080/solr/admin/collections?action=ADDREPLICA&collection=collection&shard=shard&node=solr_node_name'
例如：curl 'http://10.0.0.1:8080/solr/admin/collections?action=ADDREPLICA&collection=test_shard&shard=shard1_0&node=10.0.0.2:8080_solr'

删除副本：
curl 'http://10.0.0.1:8080/solr/admin/collections?action=DELETEREPLICA&collection=collection&shard=shard&replica=replica'
例如：curl 'http://10.0.0.1:8080/solr/admin/collections?action=DELETEREPLICA&collection=test_shard&shard=shard1_0&replica=core_node5'

Zookeeper维护的集群状态数据是存放在solr/data目录下的。
如今咱们来剖析下这样一个简单的集群构建的基本流程：
先从第一台solr服务器提及：
1. 它首先启动一个嵌入式的Zookeeper服务器，做为集群状态信息的管理者，
2. 将本身这个节点注册到/node_states/目录下
3. 同时将本身注册到/live_nodes/目录下
4. 建立/overseer_elect/leader，为后续Overseer节点的选举作准备，新建一个Overseer，
5. 更新/clusterstate.json目录下json格式的集群状态信息
6. 本机从Zookeeper中更新集群状态信息，维持与Zookeeper上的集群信息一致
7. 上传本地配置文件到Zookeeper中，供集群中其余solr节点使用
8. 启动本地的Solr服务器，
9. Solr启动完成后，Overseer会得知shard中有第一个节点进来，更新shard状态信息，并将本机所在节点设置为shard1的leader节点，并向整个集群发布最新的集群状态信息。
10.本机从Zookeeper中再次更新集群状态信息，第一台solr服务器启动完毕。

而后来看第二台solr服务器的启动过程：
1. 本机链接到集群所在的Zookeeper，
2. 将本身这个节点注册到/node_states/目录下
3. 同时将本身注册到/live_nodes/目录下
4. 本机从Zookeeper中更新集群状态信息，维持与Zookeeper上的集群信息一致
5. 从集群中保存的配置文件加载Solr所须要的配置信息
6. 启动本地solr服务器，
7. solr启动完成后，将本节点注册为集群中的shard，并将本机设置为shard2的Leader节点，
8. 本机从Zookeeper中再次更新集群状态信息，第二台solr服务器启动完毕。

这个集群如今就具有容错性了，你能够试着干掉一个Solr服务器，而后再发送查询请求。背后的实质是集群的ov erseer会监测各个shard的leader节点，若是leader节点挂了，则会启动自动的容错机制，会从同一个shard中的其余replica节点集中从新选举出一个leader节点，甚至若是overseer节点本身也挂了，一样会自动在其余节点上启用新的overseer节点，这样就确保了集群的高可用性

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程