乾貨丨DolphinDB集羣如何擴展節點和存儲

1. 概述

當系統準備上線前，咱們會評估和規劃硬件平臺的容量，而且儘量的留出餘量。但是現實每每是不能預料的，隨着業務的擴張，系統的數據容量和計算能力都會變得不堪重負，咱們就不得不面對一個問題：如何爲現有系統增長數據容量和計算能力？

因爲DolphinDB的節點是集計算和存儲於一體的，因此要增長計算能力和數據容量對DolphinDB的集羣來說就是一件事 : 增長節點。固然，DolphinDB也支持對原有的節點單獨增長存儲。

2. 擴展機制

DolphinDB的集羣是由控制節點(Controller)，代理節點(Agent)，數據節點(Data Node)三個角色組成:

• Controller負責管理集羣元數據，提供Web集羣管理工具;
• Agent部署在每一臺物理機上，負責本機節點的啓動和中止；
• Data Node是計算和數據節點。

DolphinDB擴展節點須要修改節點配置文件，經過集羣Controller重啓來載入新的節點配置，若新節點部署在一臺新的物理機上，那麼須要部署一個新的Agent服務來負責新物理機上的節點啓停。當新的節點啓動後，節點的計算能力會即時歸入集羣的計算資源來統籌；新增的節點默認會將[Home Dir]/[Data Node Alias]/storage做爲數據存儲區域，

注意此處 [Home Dir] 本例中經過在啓動命令中增長 -home data，意思就是[Home Dir]指向可執行文件同級目錄下的/data/目錄，因此舉例node3的數據存儲默認目錄就是 /data/node3/storage。

當新節點啓動後，該目錄會被自動建立並初始化用於存儲集羣的分佈式數據。

若僅對存儲空間進行擴展，只須要修改節點配置文件，爲指定節點volumes屬性增長路徑。

3. 方法

擴展節點須要作的工做，首先要讓Controller知道須要新增的機器IP和Data Node，這份工做主要是由配置文件來實現，DolphinDB提供如下幾個配置文件分別來配置集羣信息

• [Controller] controller.cfg: 負責定義控制節點的相關配置，好比IP端口，控制節點鏈接數上限等
• [Controller] cluster.cfg: 負責集羣內每個節點的個性化配置，好比node3的volumes屬性等
• [Controller] cluster.nodes: 定義集羣內部的節點和代理清單，控制節點會經過這個文件來獲取集羣的節點信息
• [Agent] agent.cfg: 定義代理節點相關屬性，好比代理節點IP和端口，所屬集羣控制節點等信息，和代理節點程序一塊兒部署在各臺物理機上

而後在新增長的物理機上部署Agent來負責啓停本機器的Data Node，而剩下的詳細配置工做和節點的啓停均可以在Web集羣管理界面上方便的完成。

而擴展存儲空間的工做，由於volumes屬性支持用逗號分隔指定多個存儲目錄，因此在原有的volumes屬性後面追加存儲目錄便可。

4. 擴展節點

4.1 環境說明

由於具體的操做是在一個已有的集羣上作擴容操做，因此這裏先了解一下原集羣的配置狀況。原有服務器4臺，操做系統均爲ubuntu 16.04，部署了 DolphinDB 0.7 版本

172.18.0.10 : controller
172.18.0.11 : datanode1
172.18.0.12 : datanode2
172.18.0.13 : datanode3

具體的配置以下：

controller.cfg

localSite=172.18.0.10:8990:ctl8990

cluster.nodes

localSite,mode
172.18.0.11:8701:agent1,agent
172.18.0.12:8701:agent2,agent
172.18.0.13:8701:agent3,agent
172.18.0.11:8801:node1,datanode
172.18.0.12:8802:node2,datanode
172.18.0.13:8803:node3,datanode

啓動Controller腳本

nohup ./dolphindb -console 0 -mode controller -script dolphindb.dos -config config/controller.cfg -logFile log/controller.log -nodesFile config/cluster.nodes &

啓動Agent腳本

./dolphindb -mode agent -home data -script dolphindb.dos -config config/agent.cfg -logFile log/agent.log

爲了在擴展工做完成以後能夠驗證效果，咱們在集羣內建立一個分佈式數據庫，並寫入初始數據

data = table(1..1000 as id,rand(`A`B`C,1000) as name)
//分區時預留了1000的餘量，預備後續寫入測試用
db = database("dfs://scaleout_test_db",RANGE,cutPoints(1..2000,10))
tb = db.createPartitionedTable(data,"scaleoutTB",`id)
tb.append!(data)

執行完後經過集羣web界面 dfs explorer觀察生成的數據分佈狀況

在後續完成節點和存儲的擴展以後，咱們會用一樣的方式追加數據，來驗證新節點和存儲是否已經啓用。

須要瞭解集羣初始化配置能夠參考  多物理機上部署集羣教程

4.2 擴展目標

本次擴容目標是爲了增長計算和存儲能力，增長了一臺新的服務器，將之加入原有的集羣做爲一個新的節點。

新增的物理機IP

172.18.0.14

新增的節點信息

172.18.0.14:8804:datanode4

4.3 擴展步驟
4.3.1 在新機器上部署和配置Agent

拷貝原機器上的Agent部署包到新機器，並修改agent.cfg

#指定Agent自己的ip和端口
localSite=172.18.0.14:8701:agent4
#告訴Agent本集羣的controller位置
controllerSite=172.18.0.10:8990:ctl8990
mode=agent

4.3.2 配置controller

修改節點清單配置cluster.nodes,配置新增長的Data Node和Agent

localSite,mode
172.18.0.14:8704:agent4,agent
172.18.0.14:8804:node4,datanode

4.3.3 重啓集羣

• 訪問集羣web管理界面，關閉全部的節點。

http://172.18.0.10:8990

• 關閉Controller，在172.18.0.10機器上執行

pkill dolphindb

• 等待半分鐘以後(等待端口釋放，可能根據操做系統這個時間有不一樣)，從新再啓動Controller
• 回到web管理界面，能夠看到已經新增了一個agent4而且是已啓動狀態，在web界面上啓動全部節點

到此咱們已經完成了新節點的增長。

4.4 驗證

下面咱們經過向集羣寫入一些數據來驗證node4是否已經在集羣中啓用。

tb = database("dfs://scaleout_test_db").loadTable("scaleoutTB")
tb.append!(table(1001..1500 as id,rand(`A`B`C,500) as name))

觀察dfs explorer，能夠看到數據已經分佈到新的 node4 節點上。

5. 擴展存儲

因爲node3所在服務器自己的磁盤空間不足，現擴展了一塊磁盤，路徑爲/dev/disk2，將這塊磁盤歸入node3的存儲。

5.1 步驟

DolphinDB的節點存儲能夠經過配置文件中的volumes屬性來配置，上述案例中沒有配置，那麼默認的存儲路徑[HomeDir]/[Data Node Alias]/Storage, 在本例中即 data/node3/storage 目錄下

若從默認路徑增長磁盤，那麼在設置volumes屬性時，必需要將原默認路徑顯式設置，不然會致使默認路徑下元數據丟失

默認狀況的volumes屬性內容以下，若是沒有這一行，須要手工加上

cluster.cfg

node3.volumes=data/node3/storage

修改配置文件後，在controller上執行loadClusterNodesConfigs()使得Controller從新載入節點配置，若是上述步驟在集羣管理web界面上完成，這個重載過程會自動完成，無需手工執行。 配置完成後無需重啓controller，只要在web界面上重啓node3節點便可使新配置生效。

若是但願node3暫不重啓，可是新的存儲立刻生效，能夠在node3上執行addVolumes("/dev/disk2/node3")函數動態添加volumes，此函數的效果並不會持久化，重啓後會被新配置覆蓋。

5.2 驗證

配置完成後，經過下面的語句向集羣寫入新數據，查看數據是否被寫入新的磁盤

tb = database("dfs://scaleout_test_db").loadTable("scaleoutTB")
tb.append!(table(1501..2000 as id,rand(`A`B`C,500) as name))

到磁盤下觀察數據已被寫入

6 常見問題

• 在驗證節點的數據寫入分佈狀況時 , 從dfs explorer裏常常會發現site信息有時候會發生變化，好比原來保存在node3的數據遷移到其餘節點了?

這個問題涉及到DolphinDB的Recovery 機制: DolphinDB的集羣支持數據自動Recovery機制，當偵測到集羣內部分節點長時間沒有心跳時(斷定宕機)，將會從其餘副本中自動恢復數據而且保持整個集羣的副本數穩定, 這也是當某個節點長時間未啓動，系統後臺會發生數據遷移的緣由。須要注意的是，這個數據穩定的前提是宕掉的節點數少於系統設置的數據副本數。這個機制涉及到的配置項及默認值以下

controller.cfg

//集羣內每一個數據副本數，默認2
dfsReplicationFactor=2
//副本安全策略，0 多個副本容許存在一個節點 1 多個副本必須分存到不一樣節點,默認0
dfsReplicaReliabilityLevel=1
//節點心跳中止多久開啓Recovery,默認不啓用，單位ms
dfsRecoveryWaitTime=30000

這3個參數對於系統的數據穩定性很是重要

dfsRecoveryWaitTime控制recovery的啓動，默認不設置即關閉recovery功能。這個等待時間的設置主要是爲了不一些計劃內的停機維護致使沒必要要的recovery，須要用戶根據運維的實際狀況來設置。

從穩定性上來說，副本數越多數據越不容易因意外丟失，可是副本數過多也會致使系統保存數據時性能低下，因此dfsReplicationFactor的值不建議低於2，可是具體設置多高須要用戶根據總體集羣的節點數、數據穩定性需求、系統寫入性能需求來綜合考慮。

dfsReplicaReliabilityLevel這個設置在生產環境下建議設置爲1，0只建議做爲學習或者測試環境下使用。