weed-fs使用簡介

時間 2020-02-04

標籤 weed 使用簡介简体版

原文原文鏈接

weed-fs，全名Seaweed-fs，是一種用golang實現的簡單且高可用的分佈式文件系統。該系統的目標有二：html

- 存儲billions of files
- serve the files fastnode

weed-fs起初是爲了搞一個基於Fackbook的Haystack論文的實現，Haystack旨在優化Fackbook內部圖片存儲和獲取。後在這個基礎上，weed-fs做者又增長了若干feature，造成了目前的weed-fs。linux

這裏並不打算深刻分析weed-fs源碼，僅僅是從黑盒角度介紹weed-fs的使用，發掘weed-fs的功能、長處和不足。git

1、weed-fs集羣簡介github

weed-fs集羣的拓撲(Topology)由DataCenter、Rack(機架)、Machine(或叫Node)組成。最第一版本的weed-fs應該能夠通過配置文件來描述整個集羣的拓撲結構，配置文件採用xml格式，官方給出的樣例以下：golang

<Configuration>
<Topology>
    <DataCenter name="dc1">
      <Rack name="rack1">
        <Ip>192.168.1.1</Ip>
      </Rack>
    </DataCenter>
    <DataCenter name="dc2">
      <Rack name="rack1">
        <Ip>192.168.1.2</Ip>
      </Rack>
      <Rack name="rack2">
        <Ip>192.168.1.3</Ip>
        <Ip>192.168.1.4</Ip>
      </Rack>
    </DataCenter>
</Topology>
</Configuration>web

但目前的版本中，該配置文件在help說明中被置爲「Deprecating!」了：redis

$weed master -help
…
-conf="/etc/weedfs/weedfs.conf": Deprecating! xml configuration file
…json

0.70版本的weed-fs在Master中維護集羣拓撲，master會根據master與master、volume與master的鏈接狀況實時合成拓撲結構了。bootstrap

weed-fs自身能夠在兩種模式下運行，一種是Master，另一種則是Volume。集羣的維護以及強一致性的保證由master們保證，master間經過raft協議實現強一致性。Volume是實際管理和存儲數據的運行實例。數據的可靠性則能夠經過weed-fs提供的 replication機制保證。

weed-fs提供了若干種replication策略(rack – 機架，一個邏輯上的概念)：

000 no replication, just one copy
001 replicate once on the same rack
010 replicate once on a different rack in the same data center
100 replicate once on a different data center
200 replicate twice on two other different data center
110 replicate once on a different rack, and once on a different data center

選擇數據更可靠的策略，則會帶來一些性能上的代價，這始終是一個權衡的問題。

更多的細節以及Scaling、數據遷移等方面，下面將逐一說明。

2、weed-fs集羣的啓動

爲了實驗方便，咱們定義了一個weed-fs集羣拓撲：

三個master:
    master1 – localhost:9333
    master2 – localhost:9334
    master3 – localhost:9335

replication策略：100(即在另一個不一樣的datacenter中複製一份)

三個volume:
         volume1 – localhost:8081 dc1
    volume2 – localhost:8082 dc1
    volume3 – localhost:8083 dc2

集羣啓動首先啓動master們，啓動順序: master一、master二、master3：

master1:

$ weed -v=3 master -port=9333 -mdir=./m1 -peers=localhost:9333,localhost:9334,localhost:9335 -defaultReplication=100
I0820 14:37:17 07606 file_util.go:20] Folder ./m1 Permission: -rwxrwxr-x
I0820 14:37:17 07606 topology.go:86] Using default configurations.
I0820 14:37:17 07606 master_server.go:59] Volume Size Limit is 30000 MB
I0820 14:37:17 07606 master.go:69] Start Seaweed Master 0.70 beta at 0.0.0.0:9333
I0820 14:37:17 07606 raft_server.go:50] Starting RaftServer with IP:localhost:9333:
I0820 14:37:17 07606 raft_server.go:74] Joining cluster: localhost:9333,localhost:9334,localhost:9335
I0820 14:37:17 07606 raft_server.go:134] Attempting to connect to:http://localhost:9334/cluster/join
I0820 14:37:17 07606 raft_server.go:139] Post returned error: Posthttp://localhost:9334/cluster/join: dial tcp 127.0.0.1:9334: connection refused
I0820 14:37:17 07606 raft_server.go:134] Attempting to connect to:http://localhost:9335/cluster/join
I0820 14:37:17 07606 raft_server.go:139] Post returned error: Posthttp://localhost:9335/cluster/join: dial tcp 127.0.0.1:9335: connection refused
I0820 14:37:17 07606 raft_server.go:78] No existing server found. Starting as leader in the new cluster.
I0820 14:37:17 07606 master_server.go:93] [ localhost:9333 ] I am the leader!

I0820 14:37:52 07606 raft_server_handlers.go:16] Processing incoming join. Current Leader localhost:9333 Self localhost:9333 Peers map[]
I0820 14:37:52 07606 raft_server_handlers.go:20] Command:{"name":"localhost:9334","connectionString":"http://localhost:9334"}
I0820 14:37:52 07606 raft_server_handlers.go:27] join command from Name localhost:9334 Connection http://localhost:9334

I0820 14:38:02 07606 raft_server_handlers.go:16] Processing incoming join. Current Leader localhost:9333 Self localhost:9333 Peers map[localhost:9334:0xc20800f730]
I0820 14:38:02 07606 raft_server_handlers.go:20] Command:{"name":"localhost:9335","connectionString":"http://localhost:9335"}
I0820 14:38:02 07606 raft_server_handlers.go:27] join command from Name localhost:9335 Connection http://localhost:9335

master2:

$ weed -v=3 master -port=9334 -mdir=./m2 -peers=localhost:9333,localhost:9334,localhost:9335 -defaultReplication=100
I0820 14:37:52 07616 file_util.go:20] Folder ./m2 Permission: -rwxrwxr-x
I0820 14:37:52 07616 topology.go:86] Using default configurations.
I0820 14:37:52 07616 master_server.go:59] Volume Size Limit is 30000 MB
I0820 14:37:52 07616 master.go:69] Start Seaweed Master 0.70 beta at 0.0.0.0:9334
I0820 14:37:52 07616 raft_server.go:50] Starting RaftServer with IP:localhost:9334:
I0820 14:37:52 07616 raft_server.go:74] Joining cluster: localhost:9333,localhost:9334,localhost:9335
I0820 14:37:52 07616 raft_server.go:134] Attempting to connect to:http://localhost:9333/cluster/join
I0820 14:37:52 07616 raft_server.go:179] Post returned status: 200

master3:

$ weed -v=3 master -port=9335 -mdir=./m3 -peers=localhost:9333,localhost:9334,localhost:9335 -defaultReplication=100
I0820 14:38:02 07626 file_util.go:20] Folder ./m3 Permission: -rwxrwxr-x
I0820 14:38:02 07626 topology.go:86] Using default configurations.
I0820 14:38:02 07626 master_server.go:59] Volume Size Limit is 30000 MB
I0820 14:38:02 07626 master.go:69] Start Seaweed Master 0.70 beta at 0.0.0.0:9335
I0820 14:38:02 07626 raft_server.go:50] Starting RaftServer with IP:localhost:9335:
I0820 14:38:02 07626 raft_server.go:74] Joining cluster: localhost:9333,localhost:9334,localhost:9335
I0820 14:38:02 07626 raft_server.go:134] Attempting to connect to:http://localhost:9333/cluster/join
I0820 14:38:03 07626 raft_server.go:179] Post returned status: 200

master1啓動後，發現其餘兩個peer master還沒有啓動，因而將本身選爲leader。master二、master3啓動後，加入到以master1爲leader的 master集羣。

接下來咱們來啓動volume servers：

volume1:

$ weed -v=3 volume -port=8081 -dir=./v1 -mserver=localhost:9333 -dataCenter=dc1
I0820 14:44:29 07642 file_util.go:20] Folder ./v1 Permission: -rwxrwxr-x
I0820 14:44:29 07642 store.go:225] Store started on dir: ./v1 with 0 volumes max 7
I0820 14:44:29 07642 volume.go:136] Start Seaweed volume server 0.70 beta at 0.0.0.0:8081
I0820 14:44:29 07642 volume_server.go:70] Volume server bootstraps with master localhost:9333
I0820 14:44:29 07642 list_masters.go:18] list masters result :{"IsLeader":true,"Leader":"localhost:9333","Peers":["localhost:9334","localhost:9335"]}
I0820 14:44:29 07642 store.go:65] current master nodes is nodes:[localhost:9334 localhost:9335 localhost:9333 localhost:9333], lastNode:3

volume server的啓動大體相同，volume2和volume3的輸出日誌這裏就不詳細列出了。

volume2:

$weed -v=3 volume -port=8082 -dir=./v2 -mserver=localhost:9334 -dataCenter=dc1

volume3:

$weed -v=3 volume -port=8083 -dir=./v3 -mserver=localhost:9335 -dataCenter=dc2

三個volume server啓動後，咱們在leader master(9333)上能看到以下日誌：

I0820 14:44:29 07606 node.go:208] topo adds child dc1
I0820 14:44:29 07606 node.go:208] topo:dc1 adds child DefaultRack
I0820 14:44:29 07606 node.go:208] topo:dc1:DefaultRack adds child 127.0.0.1:8081
I0820 14:47:09 07606 node.go:208] topo:dc1:DefaultRack adds child 127.0.0.1:8082
I0820 14:47:21 07606 node.go:208] topo adds child dc2
I0820 14:47:21 07606 node.go:208] topo:dc2 adds child DefaultRack
I0820 14:47:21 07606 node.go:208] topo:dc2:DefaultRack adds child 127.0.0.1:8083

至此，整個weed-fs集羣已經啓動了。初始啓動後的master會在-mdir下創建一些目錄和文件：

$ ls m1
conf log snapshot

但volume在-dir下沒有作任何操做，volume server會在第一次寫入數據時創建相應的.idx文件和.dat文件。

3、基本操做：存儲、獲取和刪除文件

建立一個hello.txt文件，內容爲"hello weed-fs!"，用於咱們測試weed-fs的基本操做。weed-fs提供了HTTP REST API接口，咱們能夠很方便的使用其基本功能(這裏客戶端使用curl)。

一、存儲

咱們來將hello.txt文件存儲在weed-fs文件系統中，咱們經過master提供的submit API接口來完成這一操做：

$ curl -F file=@hello.txt http://localhost:9333/submit
{"fid":"6,01fc4a422c","fileName":"hello.txt","fileUrl":"127.0.0.1:8082/6,01fc4a422c","size":39}

咱們看到master給咱們返回了一行json數據，其中:

fid是一個逗號分隔的字符串，按照repository中文檔的說明，這個字符串應該由volume id, key uint64和cookie code構成。其中逗號前面的6就是volume id, 01fc4a422c則是key和cookie組成的串。fid是文件hello.txt在集羣中的惟一ID。後續查看、獲取以及刪除該文件數據都須要使用這個fid。

fileUrl是該文件在weed-fs中的一個訪問地址(非惟一哦)，這裏是127.0.0.1:8082/6,01fc4a422c，能夠看出weed-fs在volume server2上存儲了一份hello.txt的數據。

這一存儲操做引起了物理volume的建立，咱們能夠看到volume server的-dir下發生了變化，多了不少.idx和.dat文件：

$ ls v1 v2 v3
v1:
3.dat 3.idx 4.dat 4.idx 5.dat 5.idx

v2:
1.dat 1.idx 2.dat 2.idx 6.dat 6.idx

v3:
1.dat 1.idx 2.dat 2.idx 3.dat 3.idx 4.dat 4.idx 5.dat 5.idx 6.dat 6.idx

而且這個建立過程是在master leader的控制之下的：

I0820 15:06:02 07606 volume_growth.go:204] Created Volume 3 on topo:dc1:DefaultRack:127.0.0.1:8081
I0820 15:06:02 07606 volume_growth.go:204] Created Volume 3 on topo:dc2:DefaultRack:127.0.0.1:8083

咱們從文件的size能夠看出，hello.txt文件被存儲在了v2和v3下的id爲6的卷(6.dat和6.idx)中：

v2:
-rw-r–r– 1 tonybai tonybai 104 8月20 15:06 6.dat
-rw-r–r– 1 tonybai tonybai 16 8月20 15:06 6.idx

v3:
-rw-r–r– 1 tonybai tonybai 104 8月20 15:06 6.dat
-rw-r–r– 1 tonybai tonybai 16 8月20 15:06 6.idx

v2和v3中的6.dat是如出一轍的，6.idx也是同樣的（後續在作數據遷移時，這點極其重要）。

二、獲取

前面提到master給咱們返回了一個fid:6,01fc4a422c以及fileUrl":"127.0.0.1:8082/6,01fc4a422c"。

經過這個fileUrl，咱們能夠獲取到hello.txt的數據：

$ curl http://127.0.0.1:8082/6,01fc4a422c
hello weed-fs!

根據咱們的replication策略，hello.txt應該還存儲在v3下，咱們換成8083這個volume，應該也能夠獲得 hello.txt數據：

$ curl http://127.0.0.1:8083/6,01fc4a422c
hello weed-fs!

若是咱們經過volume1 (8081)查，應該得不到數據：

$ curl http://127.0.0.1:8081/6,01fc4a422c
<a href="http://127.0.0.1:8082/6,01fc4a422c">Moved Permanently</a>.

這裏彷佛是重定向了。咱們給curl加上重定向處理選項再試一次：

$ curl -L http://127.0.0.1:8081/6,01fc4a422c
hello weed-fs!

竟然也能獲得相應數據，從volume1的日誌來看，volume1也能獲取到hello.txt的正確地址，並將返回重定向請求，這樣curl 就能從正確的machine上獲取數據了。

若是咱們經過master來獲取hello.txt數據，會是什麼結果呢？

$ curl -L http://127.0.0.1:9335/6,01fc4a422c
hello weed-fs!

一樣master返回重定向地址，curl從volume節點獲取到正確數據。咱們看看master是如何返回重定向地址的？

$ curl http://127.0.0.1:9335/6,01fc4a422c
<a href="http://127.0.0.1:8082/6,01fc4a422c">Moved Permanently</a>.
$ curl http://127.0.0.1:9335/6,01fc4a422c
<a href="http://127.0.0.1:8083/6,01fc4a422c">Moved Permanently</a>.

能夠看到master會自動均衡負載，輪詢式的返回8082和8083。0.70版本之前，經過非leader master是沒法獲得正確結果的，只能經過leader master獲得，0.70版本fix了這個問題。

三、刪除

經過fileUrl地址直接刪除hello.txt：

$ curl -X DELETE http://127.0.0.1:8082/6,01fc4a422c
{"size":39}

操做成功後，咱們再來get一下hello.txt:

$ curl -i http://127.0.0.1:8082/6,01fc4a422c
HTTP/1.1 404 Not Found
Date: Thu, 20 Aug 2015 08:13:28 GMT
Content-Length: 0
Content-Type: text/plain; charset=utf-8

$ curl -i -L http://127.0.0.1:9335/6,01fc4a422c
HTTP/1.1 301 Moved Permanently
Content-Length: 69
Content-Type: text/html; charset=utf-8
Date: Thu, 20 Aug 2015 08:13:56 GMT
Location: http://127.0.0.1:8082/6,01fc4a422c

HTTP/1.1 404 Not Found
Date: Thu, 20 Aug 2015 08:13:56 GMT
Content-Length: 0
Content-Type: text/plain; charset=utf-8

能夠看出，不管是直接經過volume仍是間接經過master都沒法獲取到hello.txt了，hello.txt被成功刪除了。

不過刪除hello.txt後，volume server下的數據文件的size卻並無隨之減少，別擔憂，這就是weed-fs的處理方法，這些數據刪除後遺留下來的空洞須要手工清除（對數據文件進行手工緊縮）：

$ curl "http://localhost:9335/vol/vacuum"
{"Topology":{"DataCenters":[{"Free":8,"Id":"dc1","Max":14,"Racks":[{"DataNodes":[{"Free":4,"Max":7,"PublicUrl":"127.0.0.1:8081","Url":"127.0.0.1:8081","Volumes":3},{"Free":4,"Max":7,"PublicUrl":"127.0.0.1:8082","Url":"127.0.0.1:8082","Volumes":3}],」Free」:8,」Id」:」DefaultRack」,」Max」:14}]},{「Free」:1,」Id」:」dc2″,」Max」:7,」Racks」:[{"DataNodes":[{"Free":1,"Max":7,"PublicUrl":"127.0.0.1:8083","Url":"127.0.0.1:8083","Volumes":6}],」Free」:1,」Id」:」DefaultRack」,」Max」:7}]}],」Free」:9,」Max」:21,」layouts」:[{"collection":"","replication":"100","ttl":"","writables":[1,2,3,4,5,6]}]},"Version":"0.70 beta"}

緊縮後，你再查看v1, v2, v3下的文件size，真的變小了。

4、一致性（consistency）

在分佈式系統中，「一致性」是永恆的難題。weed-fs支持replication，其多副本的數據一致性須要保證。

weed-fs理論上採用了是一種「強一致性」的策略，即：

存儲文件時，當多個副本都存儲成功後，纔會返回成功；任何一個副本存儲失敗，這次存儲操做則返回失敗。
刪除文件時，當全部副本都刪除成功後，才返回成功；任何一個副本刪除失敗，則這次刪除操做返回失敗。

咱們來驗證一下weed-fs是否作到了以上兩點：

一、存儲的一致性保證

咱們先將volume3停掉(即dc2)，這樣在replication 策略爲100時，向weed-fs存儲hello.txt時會發生以下結果：

$ curl -F file=@hello.txt http://localhost:9333/submit
{"error":"Cannot grow volume group! Not enough data node found!"}

master根據100策略，須要在dc2選擇一個volume存儲hello.txt的副本，但dc2全部machine都down掉了，所以沒有存儲空間，因而master認爲這次操做沒法繼續進行，返回失敗。這點符合存儲一致性的要求。

二、刪除的一致性保證

恢復dc2，將hello.txt存入：

$ curl -F file=@hello.txt http://localhost:9333/submit
{"fid":"6,04dce94a72","fileName":"hello.txt","fileUrl":"127.0.0.1:8082/6,04dce94a72","size":39}

再次停掉dc2，以後嘗試刪除hello.txt（經過master刪除)：

$ curl -L -X DELETE http://127.0.0.1:9333/6,04dce94a72
{"error":"Deletion Failed."}

雖然返回的是delete failed，但從8082上的日誌來看，彷佛8082已經將hello.txt刪除了：

I0820 17:32:20 07653 volume_server_handlers_write.go:53] deleting Cookie:3706276466, Id:4, Size:0, DataSize:0, Name: , Mime:

咱們再從8082獲取一下hello.txt：

$ curl http://127.0.0.1:8082/6,04dce94a72

結果是什麼也沒有返回。

從8082日誌來看：

I0820 17:33:24 07653 volume_server_handlers_read.go:53] read error: File Entry Not Found. Needle 70 Memory 0 /6,04dce94a72

hello.txt的確被刪除了！

這時將dc2(8083)從新啓動！咱們嘗試從8083獲取hello.txt：

$ curl http://127.0.0.1:8083/6,04dce94a72
hello weed-fs!

8083上的hello.txt依舊存在，能夠被讀取。

再試試經過master來獲取hello.txt：

$ curl -L http://127.0.0.1:9333/6,04dce94a72
$ curl -L http://127.0.0.1:9333/6,04dce94a72
hello weed-fs!

結果是有時能返回hello.txt內容，有時不行。顯然這是與master的自動負載均衡有關，返回8082這個重定向地址，則curl沒法得到結果；但若返回8083這個重定向地址，咱們就能夠獲得hello.txt的內容。

這樣來看，目前weed-fs的刪除操做還沒法保證強一致性。weed-fs github.com上已有若干issues(#172，#179，#182)是關於這個問題的。在大數據量(TB、PB級別)的狀況下，這種不一致性最大的問題是致使storage leak，即空間被佔用而沒法回收，volume將被逐個逐漸佔滿，期待後續的解決方案吧。

5、目錄支持

weed-fs還支持像傳統文件系統那樣，將文件放在目錄下管理，並經過文件路徑對文件進行存儲、獲取和刪除操做。weed-fs對目錄的支持是經過另一個server實現的：filer server。也就是說若是想擁有對目錄的支持，則必須啓動一個(或若干個) filer server，而且全部的操做都要經過filer server進行。

$ weed filer -port=8888 -dir=./f1 -master=localhost:9333 -defaultReplicaPlacement=100
I0820 22:09:40 08238 file_util.go:20] Folder ./f1 Permission: -rwxrwxr-x
I0820 22:09:40 08238 filer.go:88] Start Seaweed Filer 0.70 beta at port 8888

一、存儲

$curl -F "filename=@hello.txt" "http://localhost:8888/foo/"
{"name":"hello.txt","size":39}

二、獲取

$ curl http://localhost:8888/foo/hello.txt
hello weed-fs!

三、查詢目錄文件列表

$ curl "http://localhost:8888/foo/?pretty=y"
{
"Directory": "/foo/",
"Files": [
    {
      "name": "hello.txt",
      "fid": "6,067281a126"
    }
],
"Subdirectories": null
}

四、刪除

$ curl -X DELETE http://localhost:8888/foo/hello.txt
{"error":""}

再嘗試獲取hello.txt：

$curl http://localhost:8888/foo/hello.txt
返回空。hello.txt已被刪除。

五、多filer server

weed filer server是單點，咱們再來啓動一個filer server。

$ weed filer -port=8889 -dir=./f2 -master=localhost:9333 -defaultReplicaPlacement=100
I0821 13:47:52 08973 file_util.go:20] Folder ./f2 Permission: -rwxrwxr-x
I0821 13:47:52 08973 filer.go:88] Start Seaweed Filer 0.70 beta at port 8889

兩個filer節點間是否有協調呢？咱們來測試一下：咱們從8888存儲一個文件，而後從8889獲取這個文件：

$ curl -F "filename=@hello.txt" "http://localhost:8888/foo/"
{"name":"hello.txt","size":39}
$ curl http://localhost:8888/foo/hello.txt
hello weed-fs!
$ curl http://localhost:8889/foo/hello.txt
空

從測試結果來看，兩者各自獨立工做，並無任何聯繫，也就是說沒有共享「文件full path」到"fid"的索引關係。默認狀況下 filer server都是工做在standalone模式下的。

weed-fs官方給出了filer的集羣方案，即便用redis或Cassandra做爲後端，在多個filer節點間共享「文件full path」到"fid"的索引關係。

咱們啓動一個redis-server(2.8.21)，監聽在默認的6379端口。用下面命令重啓兩個filer server節點：

$ weed filer -port=8888 -dir=./f1 -master=localhost:9333 -defaultReplicaPlacement=100 -redis.server=localhost:6379
$ weed filer -port=8889 -dir=./f2 -master=localhost:9333 -defaultReplicaPlacement=100 -redis.server=localhost:6379

重複一下上面的測試步驟：
$ curl -F "filename=@hello.txt" "http://localhost:8888/foo/"
{"name":"hello.txt","size":39}

$ curl http://localhost:8889/foo/hello.txt
hello weed-fs!

能夠看到從8888存儲的文件，能夠被從8889獲取到。

咱們刪除這個文件：
$ curl -X DELETE http://localhost:8889/foo/hello.txt
{"error":"Invalid fileId "}

提示error，但實際上文件已經被刪除了！這塊多是個小bug(#183)。

雖然filer是集羣了，但其後端的redis依舊是單點，若是考慮高可靠性，redis顯然也要作好集羣。

6、Collection

Collection，顧名思義是「集合」，在weed-fs中，它指的是物理volume的集合。前面咱們在存儲文件時並無指定 collection，所以weed-fs採用默認collection(空)。若是咱們指定集合，結果會是什麼樣子呢？

$ curl -F file=@hello.txt "http://localhost:9333/submit?collection=picture"
{"fid":"7,0c4f5dc90f","fileName":"hello.txt","fileUrl":"127.0.0.1:8083/7,0c4f5dc90f","size":39}

$ ls v1 v2 v3
v1:
3.dat 3.idx 4.dat 4.idx 5.dat 5.idx picture_7.dat picture_7.idx
v2:
1.dat 1.idx 2.dat 2.idx 6.dat 6.idx
v3:
1.dat 1.idx 2.dat 2.idx 3.dat 3.idx 4.dat 4.idx 5.dat 5.idx 6.dat 6.idx picture_7.dat picture_7.idx

能夠看出volume server在本身的-dir下面創建了一個collection名字爲prefix的idx和dat文件，上述例子中hello.txt被分配到 8081和8083兩個volume server上，所以這兩個volume server各自創建了picture_7.dat和picture_7.idx。以picture爲前綴的idx和dat文件只是用來存放存儲在 collection=picture的文件數據，其餘數據要麼存儲在默認collection中，要麼存儲在其餘名字的collection 中。

collection就比如爲Windows下位驅動器存儲捲起名。好比C:叫"系統盤"，D叫「程序盤」，E叫「數據盤」。這裏各個 volume server下的picture_7.dat和picture_7.idx被起名爲picture卷。若是還有video collection，那麼它可能由各個volume server下的video_8.dat和video_8.idx。

不過因爲默認狀況下，weed volume的默認-max="7"，所以在實驗環境下每一個volume server最多在-dir下創建7個物理卷(七對.idx和.dat)。若是此時我還想創建video卷會怎麼樣呢？

$ curl -F file=@hello.txt "http://localhost:9333/submit?collection=video"
{"error":"Cannot grow volume group! Not enough data node found!"}

volume server們返回失敗結果，提示沒法再擴展volume了。這時你須要重啓各個volume server，將-max值改大，好比100。

好比：$weed -v=3 volume -port=8083 -dir=./v3 -mserver=localhost:9335 -dataCenter=dc2 -max=100

重啓後，咱們再來創建video collection:

$ curl -F file=@hello.txt "http://localhost:9333/submit?collection=video"
{"fid":"11,0ee98ca54d","fileName":"hello.txt","fileUrl":"127.0.0.1:8083/11,0ee98ca54d","size":39}

$ ls v1 v2 v3
v1:
3.dat 4.dat 5.dat picture_7.dat video_10.dat video_11.dat video_12.dat video_13.dat video_9.dat
3.idx 4.idx 5.idx picture_7.idx video_10.idx video_11.idx video_12.idx video_13.idx video_9.idx

v2:
1.dat 1.idx 2.dat 2.idx 6.dat 6.idx video_8.dat video_8.idx

v3:
1.dat 2.dat 3.dat 4.dat 5.dat 6.dat picture_7.dat video_10.dat video_11.dat video_12.dat video_13.dat video_8.dat video_9.dat
1.idx 2.idx 3.idx 4.idx 5.idx 6.idx picture_7.idx video_10.idx video_11.idx video_12.idx video_13.idx video_8.idx video_9.idx

能夠看到每一個datacenter的volume server一次分配了6個volume做爲video collection的存儲卷。

7、伸縮(Scaling)

對於分佈式系統來講，Scaling是不得不考慮的問題，也是極爲常見的操做。

一、伸（scale up)

weed-fs對「伸"的支持是很好的，咱們分角色說。

【master】
master間採用的是raft協議，增長一個master，對於集羣來講是最最基本的操做：

$weed -v=3 master -port=9336 -mdir=./m4 -peers=localhost:9333,localhost:9334,localhost:9335,localhost:9336 -defaultReplication=100
I0821 15:45:47 12398 file_util.go:20] Folder ./m4 Permission: -rwxrwxr-x
I0821 15:45:47 12398 topology.go:86] Using default configurations.
I0821 15:45:47 12398 master_server.go:59] Volume Size Limit is 30000 MB
I0821 15:45:47 12398 master.go:69] Start Seaweed Master 0.70 beta at 0.0.0.0:9336
I0821 15:45:47 12398 raft_server.go:50] Starting RaftServer with IP:localhost:9336:
I0821 15:45:47 12398 raft_server.go:74] Joining cluster: localhost:9333,localhost:9334,localhost:9335,localhost:9336
I0821 15:45:48 12398 raft_server.go:134] Attempting to connect to:http://localhost:9333/cluster/join
I0821 15:45:49 12398 raft_server.go:179] Post returned status: 200

新master節點啓動後，會經過raft協議自動加入到以9333爲leader的master集羣中。

【volume】

和master同樣，volume自己就是靠master管理的，volume server之間沒有什麼聯繫，增長一個volume server要作的就是啓動一個新的volume server就行了：

$ weed -v=3 volume -port=8084 -dir=./v4 -mserver=localhost:9335 -dataCenter=dc2
I0821 15:48:21 12412 file_util.go:20] Folder ./v4 Permission: -rwxrwxr-x
I0821 15:48:21 12412 store.go:225] Store started on dir: ./v4 with 0 volumes max 7
I0821 15:48:21 12412 volume.go:136] Start Seaweed volume server 0.70 beta at 0.0.0.0:8084
I0821 15:48:21 12412 volume_server.go:70] Volume server bootstraps with master localhost:9335
I0821 15:48:22 12412 list_masters.go:18] list masters result :
I0821 15:48:22 12412 list_masters.go:18] list masters result :{"IsLeader":true,"Leader":"localhost:9333","Peers":["localhost:9334","localhost:9335","localhost:9336"]}
I0821 15:48:22 12412 store.go:65] current master nodes is nodes:[localhost:9334 localhost:9335 localhost:9336 localhost:9333 localhost:9333], lastNode:4
I0821 15:48:22 12412 volume_server.go:82] Volume Server Connected with master at localhost:9333

新volume server節點啓動後，一樣會自動加入集羣，後續master就會自動在其上存儲數據了。

【filer】

前面已經談到了，不管是standalone模式，仍是distributed模式，filter均可以隨意增減，這裏就再也不重複贅述了。

二、縮(scale down)

master的縮是極其簡單的，只需將相應節點shutdown便可；若是master是leader，則其餘master會檢測到leader shutdown，並自動從新選出新leader。不過在leader選舉的過程當中，整個集羣的服務將短暫中止，直到leader選出。

filer在standalone模式下，談伸縮是毫無心義的；對於distributed模式下，filter節點和master節點縮的方法一致，shutdown便可。

惟一的麻煩就是volume節點，由於數據存儲在volume節點下，咱們不能簡單的停掉volume，咱們須要考慮在不一樣 replication策略下是否能夠作數據遷移，如何作數據遷移。這就是下一節咱們要詳細描述的。

8、數據遷移

下面咱們就來探討一下weed-fs的volume數據遷移問題。

一、000複製策略下的數據遷移

爲方便測試，我簡化一下實驗環境（一個master+3個volume）：

master:

$ weed -v=3 master -port=9333 -mdir=./m1 -defaultReplication=000

volume:

$ weed -v=3 volume -port=8081 -dir=./v1 -mserver=localhost:9333 -dataCenter=dc1
$ weed -v=3 volume -port=8082 -dir=./v2 -mserver=localhost:9333 -dataCenter=dc1
$ weed -v=3 volume -port=8083 -dir=./v3 -mserver=localhost:9333 -dataCenter=dc1

和以前同樣，啓動後，v1，v2，v3目錄下面是空的，卷的建立要等到第一份數據存入時。000策略就是沒有副本的策略，你存儲的文件在 weed-fs中只有一份數據。

咱們上傳一份文件：

$ curl -F filename=@hello1.txt "http://localhost:9333/submit"
{"fid":"1,01655ab58e","fileName":"hello1.txt","fileUrl":"127.0.0.1:8081/1,01655ab58e","size":40}

$ ll v1 v2 v3

v1:
-rw-r–r– 1 tonybai tonybai 104 8 21 21:31 1.dat
-rw-r–r– 1 tonybai tonybai 16 8 21 21:31 1.idx
-rw-r–r– 1 tonybai tonybai    8 8 21 21:31 4.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 21:31 4.idx
-rw-r–r– 1 tonybai tonybai    8 8 21 21:31 7.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 21:31 7.idx

v2:
-rw-r–r– 1 tonybai tonybai    8 8 21 21:31 2.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 21:31 2.idx
-rw-r–r– 1 tonybai tonybai    8 8 21 21:31 3.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 21:31 3.idx
-rw-r–r– 1 tonybai tonybai    8 8 21 21:31 6.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 21:31 6.idx

v3:
-rw-r–r– 1 tonybai tonybai 8 8 21 21:31 5.dat
-rw-r–r– 1 tonybai tonybai 0 8 21 21:31 5.idx

能夠看到hello1.txt被存儲在v1下，同時能夠看出不一樣的物理卷分別存放在不一樣節點下（因爲不須要do replication）。

在這種狀況(000)下，若是要將v1數據遷移到v2或v3中，只需將v1停掉，將v1下的文件mv到v2或v3中，重啓volume server2或volume server3便可。

二、001複製策略下的數據遷移

001複製策略是weed-fs默認的複製策略，weed-fs會爲每一個文件在同Rack下複製一個副本。咱們還利用上面的環境，不過須要停掉 weed-fs，清空目錄下的文件，重啓後使用，別忘了-defaultReplication=001。

咱們連續存儲三個文件：

$ curl -F filename=@hello1.txt "http://localhost:9333/submit"
{"fid":"2,01ea84980d","fileName":"hello1.txt","fileUrl":"127.0.0.1:8082/2,01ea84980d","size":40}

$ curl -F filename=@hello2.txt "http://localhost:9333/submit"
{"fid":"1,027883baa8","fileName":"hello2.txt","fileUrl":"127.0.0.1:8083/1,027883baa8","size":40}

$ curl -F filename=@hello3.txt "http://localhost:9333/submit"
{"fid":"6,03220f577e","fileName":"hello3.txt","fileUrl":"127.0.0.1:8081/6,03220f577e","size":40}

能夠看出三個文件分別被存儲在vol2, vol1和vol6中，咱們查看一下v1, v2, v3中的文件狀況：

$ ll v1 v2 v3
v1:
-rw-r–r– 1 tonybai tonybai 104 8 21 22:00 1.dat
-rw-r–r– 1 tonybai tonybai 16 8 21 22:00 1.idx
-rw-r–r– 1 tonybai tonybai    8 8 21 21:56 3.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 21:56 3.idx
-rw-r–r– 1 tonybai tonybai    8 8 21 21:56 4.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 21:56 4.idx
-rw-r–r– 1 tonybai tonybai 104 8 21 22:02 6.dat
-rw-r–r– 1 tonybai tonybai 16 8 21 22:02 6.idx

v2:
-rw-r–r– 1 tonybai tonybai 104 8 21 21:56 2.dat
-rw-r–r– 1 tonybai tonybai 16 8 21 21:56 2.idx
-rw-r–r– 1 tonybai tonybai 8 8 21 21:56 5.dat
-rw-r–r– 1 tonybai tonybai 0 8 21 21:56 5.idx

v3:
-rw-r–r– 1 tonybai tonybai 104 8 21 22:00 1.dat
-rw-r–r– 1 tonybai tonybai 16 8 21 22:00 1.idx
-rw-r–r– 1 tonybai tonybai 104 8 21 21:56 2.dat
-rw-r–r– 1 tonybai tonybai 16 8 21 21:56 2.idx
-rw-r–r– 1 tonybai tonybai    8 8 21 21:56 3.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 21:56 3.idx
-rw-r–r– 1 tonybai tonybai    8 8 21 21:56 4.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 21:56 4.idx
-rw-r–r– 1 tonybai tonybai    8 8 21 21:56 5.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 21:56 5.idx
-rw-r–r– 1 tonybai tonybai 104 8 21 22:02 6.dat
-rw-r–r– 1 tonybai tonybai 16 8 21 22:02 6.idx

假設咱們如今要shutdown v3，將v3數據遷移到其餘volume server，咱們有3種作法：

1) 不遷移
2) 將v3下的全部文件mv到v2或v1中
3) 將v3下的全部文件前後覆蓋到v1和v2中

咱們來逐個分析每種作法的後果：

1) 不遷移

001策略下，每份數據有兩個copy，v3中的數據其餘兩個v1+v2老是有的，所以即使不遷移，v1+v2中也會有一份數據copy。你能夠測試一下當shutdown volume3後：

$ curl -L "http://localhost:9333/2,01ea84980d"
hello weed-fs1!
$ curl -L "http://localhost:9333/1,027883baa8"
hello weed-fs2!
$ curl -L "http://localhost:9333/6,03220f577e"
hello weed-fs3!

針對每一份文件，你均可以多get幾回，都會獲得正確的結果。但此時的不足也很明顯，那就是存量數據再也不擁有另一份備份。

2) 將v3下的全部文件mv到v2或v1中

仍是根據001策略，將v3數據mv到v2或v1中，結果會是什麼呢，這裏就以v3 mv到 v1舉例：

- 對於v1和v3都有的卷id，好比1，二者的文件1.idx和1.dat是如出一轍的。這是001策略決定的。但一旦遷移後，系統中的數據就由2份變成1份了。
- 對於v1有，而v3沒有的，那天然沒必要說了。
- 對於v1沒有，而v3有的，mv過去就成爲了v1的數據。

爲此，這種作法依舊不夠完美。

3）將v3下的全部文件覆蓋到v1和v2中

結合上面的方法，只有此種遷移方式才能保證遷移後，系統中的數據不丟失，且每一個都是按照001策略所說的2份，這纔是正確的方法。

咱們來測試一下：

   – 停掉volume3；
   – 停掉volume1，將v3下的文件copy到v1下，啓動volume1
   – 停掉volume2，將v3下的文件copy到v2下，啓動volume2

$ curl "http://localhost:9333/6,03220f577e"
<a href="http://127.0.0.1:8081/6,03220f577e">Moved Permanently</a>.

$ curl "http://localhost:9333/6,03220f577e"
<a href="http://127.0.0.1:8082/6,03220f577e">Moved Permanently</a>.

能夠看到，master返回了重定向地址8081和8082，說明8083遷移到8082上的數據也生效了。

三、100複製策略下的數據遷移

測試環境稍做變化：

master:

$ weed -v=3 master -port=9333 -mdir=./m1 -defaultReplication=100

volume:

和以前同樣，咱們上傳三份文件：

$ curl -F filename=@hello1.txt "http://localhost:9333/submit"
{"fid":"4,01d937dd30","fileName":"hello1.txt","fileUrl":"127.0.0.1:8083/4,01d937dd30","size":40}

$ curl -F filename=@hello2.txt "http://localhost:9333/submit"
{"fid":"2,025efbef14","fileName":"hello2.txt","fileUrl":"127.0.0.1:8082/2,025efbef14","size":40}

$ curl -F filename=@hello3.txt "http://localhost:9333/submit"
{"fid":"2,03be936488","fileName":"hello3.txt","fileUrl":"127.0.0.1:8082/2,03be936488","size":40}

$ ll v1 v2 v3
-rw-r–r– 1 tonybai tonybai    8 8 21 22:58 3.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 22:58 3.idx
-rw-r–r– 1 tonybai tonybai 104 8 21 22:58 4.dat
-rw-r–r– 1 tonybai tonybai   16 8 21 22:58 4.idx

v2:
-rw-r–r– 1 tonybai tonybai    8 8 21 22:58 1.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 22:58 1.idx
-rw-r–r– 1 tonybai tonybai 200 8 21 22:59 2.dat
-rw-r–r– 1 tonybai tonybai   32 8 21 22:59 2.idx
-rw-r–r– 1 tonybai tonybai    8 8 21 22:58 5.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 22:58 5.idx
-rw-r–r– 1 tonybai tonybai    8 8 21 22:58 6.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 22:58 6.idx

v3:
-rw-r–r– 1 tonybai tonybai    8 8 21 22:58 1.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 22:58 1.idx
-rw-r–r– 1 tonybai tonybai 200 8 21 22:59 2.dat
-rw-r–r– 1 tonybai tonybai   32 8 21 22:59 2.idx
-rw-r–r– 1 tonybai tonybai    8 8 21 22:58 3.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 22:58 3.idx
-rw-r–r– 1 tonybai tonybai 104 8 21 22:58 4.dat
-rw-r–r– 1 tonybai tonybai   16 8 21 22:58 4.idx
-rw-r–r– 1 tonybai tonybai    8 8 21 22:58 5.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 22:58 5.idx
-rw-r–r– 1 tonybai tonybai    8 8 21 22:58 6.dat
-rw-r–r– 1 tonybai tonybai    0 8 21 22:58 6.idx

因爲100策略是在不一樣DataCenter中各保持一份copy，所以數據的遷移不該該在數據中心間進行，而同一數據中心內的遷移又迴歸到了「000」策略的情形。

其餘策略的分析方式也是如此，這裏就不長篇大論了。

9、Benchmark

在HP ProLiant DL380 G4, Intel(R) Xeon(TM) CPU 3.60GHz 4核，6G內存的機器(非SSD硬盤)上，執行benchmark test:

$ weed benchmark -server=localhost:9333

This is SeaweedFS version 0.70 beta linux amd64

———— Writing Benchmark ———-
Concurrency Level:      16
Time taken for tests:   831.583 seconds
Complete requests:      1048576
Failed requests:        0
Total transferred:      1106794545 bytes
Requests per second:    1260.94 [#/sec]
Transfer rate:          1299.75 [Kbytes/sec]

Connection Times (ms)
min avg max std
Total: 2.2 12.5 1118.4 9.3

Percentage of the requests served within a certain time (ms)
   50%     11.4 ms
   66%     13.3 ms
   75%     14.8 ms
   80%     15.9 ms
   90%     19.2 ms
   95%     22.6 ms
   98%     27.4 ms
   99%     31.2 ms
100%    1118.4 ms

———— Randomly Reading Benchmark ———-
Concurrency Level:      16
Time taken for tests:   151.480 seconds
Complete requests:      1048576
Failed requests:        0
Total transferred:      1106791113 bytes
Requests per second:    6922.22 [#/sec]
Transfer rate:          7135.28 [Kbytes/sec]

Connection Times (ms)
min avg max std
Total: 0.1 2.2 116.7 3.9

Percentage of the requests served within a certain time (ms)
   50%      1.6 ms
   66%      2.1 ms
   75%      2.5 ms
   80%      2.8 ms
   90%      3.7 ms
   95%      4.8 ms
   98%      7.4 ms
   99%     11.1 ms
100%    116.7 ms

這個彷佛比做者在mac筆記本(SSD)上性能還要差些，固然這次咱們用的策略是100，而且這個服務器上還運行着其餘程序。但即使如此，感受weed-fs仍是有較大優化的空間的。

做者在官網上將weed-fs與其餘分佈式文件系統如Ceph，hdfs等作了簡要對比，強調了weed-fs相對於其餘分佈式文件系統的優勢。

10、其它

weed-fs使用google glog，所以全部log的級別設置以及log定向的方法均與glog一致。

weed-fs提供了backup命令，用來在同機上備份volume server上的數據。

weed-fs沒有提供官方client包，但在wiki上列出多種第三方client包（各類語言），就Go client包來看，彷佛尚未特別理想的。

weed-fs目前尚未web console，只能經過命令行進行操做。

使用weed-fs時，別忘了將open files no limit調大，不然可能會致使volume server crash。

11、小結

weed-fs爲想尋找開源分佈式文件系統的朋友們提供了一個新選擇。尤爲是在存儲大量小圖片時，weed-fs自身就是基於haystack這一優化圖片存儲的論文的。另外weed-fs使用起來的確十分簡單，分分鐘就能夠創建起一個分佈式系統，部署容易，幾乎不須要什麼配置。但weed-fs目前最大的問題彷佛是沒有重量級的使用案例，自身也還有很多不足，但但願經過這篇文章能讓更多人認識weed-fs，並使用weed-fs，幫助改善weed-fs吧。

一，架構設計

1，架構拓撲

DataCenter至關於數據中心

Rack至關於機櫃

DataNode至關於服務器

測試topo以下（注意因爲副本設置緣由110，1個數據中心至少要有2個rack）: