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教程