基於外部ZooKeeper的GlusterFS做爲分佈式文件系統的徹底分佈式HBase集羣安裝指南

時間 2019-11-07

標籤基於外部 zookeeper glusterfs 做爲分佈式文件系統徹底 hbase 集羣安裝指南欄目 Zookeeper 简体版

原文原文鏈接

(WJW)基於外部ZooKeeper的GlusterFS做爲分佈式文件系統的徹底分佈式HBase集羣安裝指南

[X] 前提條件

服務器列表:

192.168.1.84 hbase84 #hbase-masterhtml

192.168.1.85 hbase85 #hbase-regionserver,zookeeperjava

192.168.1.86 hbase86 #hbase-regionserver,zookeepernode

192.168.1.87 hbase87 #hbase-regionserver,zookeeperlinux

建議安裝Sun的JDK1.7版本! 安裝完畢並配置java環境變量,在/etc/profile末尾添加以下代碼:
export JAVA_HOME=/usr/java/default
export PATH=$JAVA_HOME/bin:$PATH
保存退出便可,而後執行source /etc/profile生效.在命令行執行java -version 以下表明JAVA安裝成功.數據庫

須要配置各個節點的免密碼登陸!
首先在本身機器上使用ssh-keygen -t rsa
會要求輸入密碼(必須爲空),回車幾回,而後會在HOME目錄下生成.ssh文件夾,
裏面有私鑰和公鑰,公鑰爲id_rsa.pub,(如今你須要將你的公鑰拷貝到服務器上,若是你的系統有ssh-copy-id命令,拷貝會很簡單:$ ssh-copy-id 用戶名@服務器名)
不然,你須要手動將你的私鑰拷貝的服務器上的~/.ssh/authorized_keys文件中!apache

集羣的時鐘要保證基本的一致.稍有不一致是能夠容忍的,可是很大的不一致會形成奇怪的行爲. 運行 NTP 或者其餘什麼東西來同步你的時間.
若是你查詢的時候或者是遇到奇怪的故障,能夠檢查一下系統時間是否正確!數組

echo "server 192.168.0.2" >> /etc/ntp.conf  
chkconfig ntpd on  
service ntpd restart  
ntpq -p

ulimit和nproc

HBase是數據庫,會在同一時間使用不少的文件句柄.大多數linux系統使用的默認值1024是不能知足的,修改/etc/security/limits.conf文件爲:緩存

*               soft    nproc   16384
      *               hard    nproc   16384  
      *               soft    nofile  65536  
      *               hard    nofile  65536

ZooKeeper

先把ZooKeeper安裝在hbase85,hbase86,hbase873個節點上
啓動hbase85,hbase86,hbase87上的ZooKeeper!

/opt/app/zookeeper/bin/zkServer.sh startbash

HBase還須要一個正在運行的分佈式文件系統:HDFS,或者GlusterFS

本指南使用GlusterFS做爲分佈式文件系統!
每一個節點的掛載目錄爲:/mnt/gfs_v3/hbase
GlusterFS是Scale-Out存儲解決方案Gluster的核心,它是一個開源的分佈式文件系統,具備強大的橫向擴展能力,經過擴展可以支持數PB存儲容量和處理數千客戶端.
GlusterFS藉助TCP/IP或InfiniBand RDMA網絡將物理分佈的存儲資源彙集在一塊兒,使用單一全局命名空間來管理數據.
GlusterFS基於可堆疊的用戶空間設計,可爲各類不一樣的數據負載提供優異的性能.服務器

[X] 修改 192.168.1.84,192.168.1.85,192.168.1.86,192.168.1.87 的`etc/hosts`文件,在文件最後添加:

192.168.1.84 hbase84
192.168.1.85 hbase85
192.168.1.86 hbase86
192.168.1.87 hbase87

[X] 拷貝`hbase-0.98.8-hadoop2-bin.tar.gz`到各個hbase84的`/opt`目錄下,而後執行:

cd /opt
tar zxvf ./hbase-0.98.8-hadoop2-bin.tar.gz
mv hbase-0.98.8-hadoop2  /opt/hbase

[X] 源碼編譯安裝Hadoop的native庫:

#YUM安裝依賴庫
yum install autoconfautomake libtool cmake zlib-devel
yum install ncurses-devel
yum install openssl-devel
yum install gcc*

下載並安裝配置:protobuf
cd /tmp
wget http://protobuf.googlecode.com/files/protobuf-2.5.0.tar.gz
tar -zxvf protobuf-2.5.0.tar.gz
cd protobuf-2.5.0
./configure
make
make install 
ldconfig
rm -rf /tmp/protobuf-2.5.0/

#下載並配置:findbugs
http://sourceforge.net/projects/findbugs/files/findbugs/2.0.2/findbugs-2.0.2.tar.gz/download
解壓:tar -zxvf ./findbugs-2.0.2.tar.gz
配置環境變量FINDBUGS_HOME: export FINDBUGS_HOME=/path to your extract directory  #例如: export FINDBUGS_HOME=/opt/findbugs-2.0.2

#Build native libraries using maven
編輯`hadoop-common-project/hadoop-auth/pom.xml`文件,添加上
    <dependency>
       <groupId>org.mortbay.jetty</groupId>
      <artifactId>jetty-util</artifactId>
      <scope>test</scope>
    </dependency>
編輯`hadoop-common-project/hadoop-auth/pom.xml`文件,在<artifactId>maven-site-plugin</artifactId>後添加一行:<version>3.3</version>
編輯`pom.xml`文件,把<artifactId>maven-site-plugin</artifactId>後面的:<version>3.0</version>改爲:<version>3.3</version>

mvn package -Pdist,native,docs -DskipTests -Dtar
生成好的文件是:/opt/hadoop-2.2.0-src/hadoop-dist/target/hadoop-2.2.0.tar.gz

把hadoop-2.2.0.tar.gz裏的lib/native目錄下的文件複製到hbase的lib/native目錄下,而後執行:

cd /opt/hbase/lib/native
ln -fs libhadoop.so.1.0.0 libhadoop.so
ln -fs libhdfs.so.0.0.0 libhdfs.so

[X] 修改`/opt/hbase/conf/hbase-env.sh`文件,在文件最後添加:

export JAVA_HOME=/usr/java/default
export PATH=$JAVA_HOME/bin:$PATH

export HBASE_PID_DIR=/var/hbase/pids
export JAVA_LIBRARY_PATH=${HBASE_HOME}/lib/native
export HBASE_MANAGES_ZK=false
export HBASE_HEAPSIZE=3000

[X] 修改`/opt/hbase/conf/hbase-site.xml`文件,改爲:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
  <property>
    <name>hbase.cluster.distributed</name>
    <value>true</value>
  </property>
  <property>
    <name>hbase.master.port</name>
    <value>60000</value>
  </property>

  <property>
    <name>hbase.rootdir</name>
    <value>file:///mnt/gfs_v3/hbase</value>
    <!-- <value>hdfs://m1:9000/hbase</value>  -->
  </property>
  
  <property>
    <name>hbase.zookeeper.quorum</name>
    <value>192.168.1.85,192.168.1.86,192.168.1.87</value>
  </property>
  <property>
    <name>hbase.zookeeper.property.clientPort</name>
    <value>2181</value>
  </property>
  <property>
    <name>zookeeper.znode.parent</name>
    <value>/hbase</value>
  </property>
  
  
  <!-- 優化參數  -->
  <property>
    <name>hbase.regionserver.handler.count</name>
    <value>50</value>
  </property>
  <property>
    <name>hbase.hregion.max.filesize</name>
    <value>268435456</value>
  </property>
  
</configuration>

[X] 修改`/opt/hbase/conf/regionservers文件`,配置HBase集羣中的從結點Region Server,以下所示:

hbase85
hbase86
hbase87

[X] 爲腳本文件添加可執行權限

chmod -R +x /opt/hbase/bin/*
chmod -R +x /opt/hbase/conf/*.sh

[X] 啓動hbase集羣

[1] 把配置好的hbase複製到其餘節點:

執行以下操做便可

ssh hbase84
ssh hbase85
ssh hbase86
ssh hbase87
scp -r /opt/hbase/ root@hbase85:/opt/
scp -r /opt/hbase/ root@hbase86:/opt/
scp -r /opt/hbase/ root@hbase87:/opt/

[2] 在hbase84節點上執行:

/opt/hbase/bin/start-hbase.sh

[X] 中止hbase集羣

在hbase84節點上執行:

/opt/hbase/bin/stop-hbase.sh

[X] 附錄:

腳本使用小結:

開啓集羣,start-hbase.sh
關閉集羣,stop-hbase.sh
開啓/關閉全部的regionserver、zookeeper, hbase-daemons.sh start/stop regionserver/zookeeper
開啓/關閉單個regionserver、zookeeper, hbase-daemon.sh start/stop regionserver/zookeeper
開啓/關閉master, hbase-daemon.sh start/stop master, 是否成爲active master取決於當前是否有active master
rolling-restart.sh 能夠用來挨個滾動重啓
graceful_stop.sh move服務器上的全部region後,再stop/restart該服務器,能夠用來進行版本的熱升級

幾個細節:

hbase-daemon.sh start master 與 hbase-daemon.sh start master --backup,這2個命令的做用同樣的,是否成爲backup或active是由master的內部邏輯來控制的
stop-hbase.sh 不會調用hbase-daemons.sh stop regionserver 來關閉regionserver, 可是會調用hbase-daemons.sh stop zookeeper/master-backup來關閉zk和backup master,關閉regionserver實際調用的是hbaseAdmin的shutdown接口
經過$HBASE_HOME/bin/hbase stop master關閉的是整個集羣而非單個master,只關閉單個master的話使用$HBASE_HOME/bin/hbase-daemon.sh stop master
$HBASE_HOME/bin/hbase stop regionserver/zookeeper 不能這麼調,調了也會出錯,也沒有路徑會調用這個命令,可是能夠經過$HBASE_HOME/bin/hbase start regionserver/zookeeper 來啓動rs或者zk,hbase-daemon.sh調用的就是這個命令

HTable一些基本概念

Row key

行主鍵, HBase不支持條件查詢和Order by等查詢,讀取記錄只能按Row key(及其range)或全表掃描,所以Row key須要根據業務來設計以利用其存儲排序特性(Table按Row key字典序排序如1,10,100,11,2)提升性能.

避免使用遞增的數字或時間作爲rowkey.

若是rowkey是整型,用二進制的方式比用string來存儲更節約空間

合理的控制rowkey的長度,儘量短,由於rowkey的數據也會存在每一個Cell中.

若是須要將表預分裂爲多個region是,最好自定義分裂的規則.

Column Family(列族)

在表建立時聲明,每一個Column Family爲一個存儲單元.在上例中設計了一個HBase表blog,該表有兩個列族:article和author.

列簇儘可能少,最好不超過3個.由於每一個列簇是存在一個獨立的HFile裏的,flush和compaction操做都是針對一個Region進行的,當一個列簇的數據不少須要flush的時候,其它列簇即便數據不多也須要flush,這樣就產生的大量沒必要要的io操做.

在多列簇的狀況下,注意各列簇數據的數量級要一致.若是兩個列簇的數量級相差太大,會使數量級少的列簇的數據掃描效率低下.

將常常查詢和不常常查詢的數據放到不一樣的列簇.

由於列簇和列的名字會存在HBase的每一個Cell中,因此他們的名字應該儘量的短.好比,用f:q代替mycolumnfamily:mycolumnqualifier

Column(列)

HBase的每一個列都屬於一個列族,以列族名爲前綴,如列article:title和article:content屬於article列族,author:name和author:nickname屬於author列族.

Column不用建立表時定義便可以動態新增,同一Column Family的Columns會羣聚在一個存儲單元上,並依Column key排序,所以設計時應將具備相同I/O特性的Column設計在一個Column Family上以提升性能.同時這裏須要注意的是:這個列是能夠增長和刪除的,這和咱們的傳統數據庫很大的區別.因此他適合非結構化數據.

Timestamp

HBase經過row和column肯定一份數據,這份數據的值可能有多個版本,不一樣版本的值按照時間倒序排序,即最新的數據排在最前面,查詢時默認返回最新版本.如上例中row key=1的author:nickname值有兩個版本,分別爲1317180070811對應的"一葉渡江"和1317180718830對應的"yedu"(對應到實際業務能夠理解爲在某時刻修改了nickname爲yedu,但舊值仍然存在).Timestamp默認爲系統當前時間(精確到毫秒),也能夠在寫入數據時指定該值.

Value

每一個值經過4個鍵惟一索引,tableName+RowKey+ColumnKey+Timestamp=>value,例如上例中{tableName='blog',RowKey='1',ColumnName='author:nickname',Timestamp=' 1317180718830'}索引到的惟一值是"yedu".

存儲類型

TableName 是字符串
RowKey和ColumnName是二進制值(Java 類型 byte[])
Timestamp是一個 64 位整數(Java 類型 long) value是一個字節數組(Java類型 byte[]).

HBase配置優化

zookeeper.session.timeout

默認值:3分鐘(180000ms)

說明:RegionServer與Zookeeper間的鏈接超時時間.當超時時間到後,ReigonServer會被Zookeeper從RS集羣清單中移除,HMaster收到移除通知後,會對這臺server負責的regions從新balance,讓其餘存活的RegionServer接管.

調優:這個timeout決定了RegionServer是否可以及時的failover.設置成1分鐘或更低,能夠減小因等待超時而被延長的failover時間. 不過須要注意的是,對於一些Online應用,RegionServer從宕機到恢復時間自己就很短的(網絡閃斷,crash等故障,運維可快速介入),若是調低timeout時間,反而會得不償失.由於當ReigonServer被正式從RS集羣中移除時,HMaster就開始作balance了(讓其餘RS根據故障機器記錄的WAL日誌進行恢復).當故障的RS在人工介入恢復後,這個balance動做是毫無心義的,反而會使負載不均勻,給RS帶來更多負擔.特別是那些固定分配regions的場景.

hbase.regionserver.handler.count

默認值:10

說明:RegionServer的請求處理IO線程數.

調優: 這個參數的調優與內存息息相關. 較少的IO線程,適用於處理單次請求內存消耗較高的Big PUT場景(大容量單次PUT或設置了較大cache的scan,均屬於Big PUT)或ReigonServer的內存比較緊張的場景. 較多的IO線程,適用於單次請求內存消耗低,TPS要求很是高的場景.設置該值的時候,以監控內存爲主要參考. 這裏須要注意的是若是server的region數量不多,大量的請求都落在一個region上,因快速充滿memstore觸發flush致使的讀寫鎖會影響全局TPS,不是IO線程數越高越好. 壓測時,開啓Enabling RPC-level logging,
能夠同時監控每次請求的內存消耗和GC的情況,最後經過屢次壓測結果來合理調節IO線程數. 這裏是一個案例?Hadoop and HBase Optimization for Read Intensive Search Applications,做者在SSD的機器上設置IO線程數爲100,僅供參考.

hbase.hregion.max.filesize

默認值:256M

說明:在當前ReigonServer上單個Reigon的最大存儲空間,單個Region超過該值時,這個Region會被自動split成更小的region.

調優: 小region對split和compaction友好,由於拆分region或compact小region裏的storefile速度很快,內存佔用低.缺點是split和compaction會很頻繁.特別是數量較多的小region不停地split, compaction,會致使集羣響應時間波動很大,region數量太多不只給管理上帶來麻煩,甚至會引起一些Hbase的bug.通常512如下的都算小region.
大region,則不太適合常常split和compaction,由於作一次compact和split會產生較長時間的停頓,對應用的讀寫性能衝擊很是大.此外,大region意味着較大的storefile,compaction時對內存也是一個挑戰. 固然,大region也有其用武之地.若是你的應用場景中,某個時間點的訪問量較低,那麼在此時作compact和split,既能順利完成split和compaction,又能保證絕大多數時間平穩的讀寫性能.
既然split和compaction如此影響性能,有沒有辦法去掉? compaction是沒法避免的,split卻是能夠從自動調整爲手動. 只要經過將這個參數值調大到某個很難達到的值,好比100G,就能夠間接禁用自動split(RegionServer不會對未到達100G的region作split). 再配合RegionSplitter這個工具,在須要split時,手動split. 手動split在靈活性和穩定性上比起自動split要高不少,相反,管理成本增長很少,比較推薦online實時系統使用. 內存方面,小region在設置memstore的大小值上比較靈活,大region則過大太小都不行,過大會致使flush時app的IO wait增高,太小則因store file過多影響讀性能.

hbase.regionserver.global.memstore.upperLimit/lowerLimit

默認值:0.4/0.35

upperlimit說明:hbase.hregion.memstore.flush.size 這個參數的做用是當單個Region內全部的memstore大小總和超過指定值時,flush該region的全部memstore.RegionServer的flush是經過將請求添加一個隊列,模擬生產消費模式來異步處理的.那這裏就有一個問題,當隊列來不及消費,產生大量積壓請求時,可能會致使內存陡增,最壞的狀況是觸發OOM. 這個參數的做用是防止內存佔用過大,當ReigonServer內全部region的memstores所佔用內存總和達到heap的40%時,HBase會強制block全部的更新並flush這些region以釋放全部memstore佔用的內存.

lowerLimit說明: 同upperLimit,只不過lowerLimit在全部region的memstores所佔用內存達到Heap的35%時,不flush全部的memstore.它會找一個memstore內存佔用最大的region,作個別flush,此時寫更新仍是會被block.lowerLimit算是一個在全部region強制flush致使性能下降前的補救措施.在日誌中,表現爲 "** Flush thread woke up with memory above low water."

調優:這是一個Heap內存保護參數,默認值已經能適用大多數場景. 參數調整會影響讀寫,若是寫的壓力大致使常常超過這個閥值,則調小讀緩存hfile.block.cache.size增大該閥值,或者Heap餘量較多時,不修改讀緩存大小. 若是在高壓狀況下,也沒超過這個閥值,那麼建議你適當調小這個閥值再作壓測,確保觸發次數不要太多,而後還有較多Heap餘量的時候,調大hfile.block.cache.size提升讀性能. 還有一種可能性是?hbase.hregion.memstore.flush.size保持不變,但RS維護了過多的region,要知道 region數量直接影響佔用內存的大小.

hfile.block.cache.size

默認值:0.2

說明:storefile的讀緩存佔用Heap的大小百分比,0.2表示20%.該值直接影響數據讀的性能.

調優:固然是越大越好,若是寫比讀少不少,開到0.4-0.5也沒問題.若是讀寫較均衡,0.3左右.若是寫比讀多,果斷默認吧.設置這個值的時候,你同時要參考?hbase.regionserver.global.memstore.upperLimit?,該值是memstore佔heap的最大百分比,兩個參數一個影響讀,一個影響寫.若是兩值加起來超過80-90%,會有OOM的風險,謹慎設置.

hbase.hstore.blockingStoreFiles

默認值:7

說明:在flush時,當一個region中的Store(Coulmn Family)內有超過7個storefile時,則block全部的寫請求進行compaction,以減小storefile數量.

調優:block寫請求會嚴重影響當前regionServer的響應時間,但過多的storefile也會影響讀性能.從實際應用來看,爲了獲取較平滑的響應時間,可將值設爲無限大.若是能容忍響應時間出現較大的波峯波谷,那麼默認或根據自身場景調整便可.

hbase.hregion.memstore.block.multiplier

默認值:2

說明:當一個region裏的memstore佔用內存大小超過hbase.hregion.memstore.flush.size兩倍的大小時,block該region的全部請求,進行flush,釋放內存. 雖然咱們設置了region所佔用的memstores總內存大小,好比64M,但想象一下,在最後63.9M的時候,我Put了一個200M的數據,此時memstore的大小會瞬間暴漲到超過預期的hbase.hregion.memstore.flush.size的幾倍.這個參數的做用是當memstore的大小增至超過hbase.hregion.memstore.flush.size 2倍時,block全部請求,遏制風險進一步擴大.

調優: 這個參數的默認值仍是比較靠譜的.若是你預估你的正常應用場景(不包括異常)不會出現突發寫或寫的量可控,那麼保持默認值便可.若是正常狀況下,你的寫請求量就會常常暴長到正常的幾倍,那麼你應該調大這個倍數並調整其餘參數值,好比hfile.block.cache.size和hbase.regionserver.global.memstore.upperLimit/lowerLimit,以預留更多內存,防止HBase server OOM.