一、weed-fs集群簡介
weed-fs集群的拓撲(Topology)由DataCenter、Rack(機架)、Machine(或叫Node)組成。最初版本的weed-fs應該可以通 過配置文件來描述整個集群的拓撲結構，配置文件采用xml格式，官方給出的樣例如下：
<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>
但目前的版本中，該配置文件在help說明中被置為“Deprecating!”了：
$weed master -help
…
-conf="/etc/weedfs/weedfs.conf": Deprecating! xml configuration file
…
0.70版本的weed-fs在Master中維護集群拓撲，master會根據master與master、volume與master的連接 情況實時合成拓撲結構了。
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、數據遷移等方面，下面將逐一說明。
二、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們，啟動順序: master1、master2、master3：
master1: $ weed -v=3 master -port=9333 -mdir=./m1 -peers=localhost:9333,localhost:9334,localhost:9335 -defaultReplication=100
master2: $ weed -v=3 master -port=9334 -mdir=./m2 -peers=localhost:9333,localhost:9334,localhost:9335 -defaultReplication=100
master3: $ weed -v=3 master -port=9335 -mdir=./m3 -peers=localhost:9333,localhost:9334,localhost:9335 -defaultReplication=100
master1啟動后，發現其他兩個peer master尚未啟動，於是將自己選為leader。master2、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文件。
三、基本操作：存儲、獲取和刪除文件
創建一個hello.txt文件，內容為"hello weed-fs!"，用於我們測試weed-fs的基本操作。weed-fs提供了HTTP REST API接口，我們可以很方便的使用其基本功能(這里客戶端使用curl)。
1、存儲
我們來將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也是一樣的（后續在做數據遷移時，這點極其重要）。
2、獲取
前面提到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了這個問題。
3、刪除
通過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，真的變小了。
四、一致性（consistency）
在分布式系統中，“一致性”是永恆的難題。weed-fs支持replication，其多副本的數據一致性需要保證。
weed-fs理論上采用了是一種“強一致性”的策略，即：
存儲文件時，當多個副本都存儲成功后，才會返回成功；任何一個副本存儲失敗，此次存儲操作則返回失敗。
刪除文件時，當所有副本都刪除成功后，才返回成功；任何一個副本刪除失敗，則此次刪除操作返回失敗。
我們來驗證一下weed-fs是否做到了以上兩點：
1、存儲的一致性保證
我們先將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認為此次操作無法繼續進行，返回失敗。這點符合存儲一致性的要求。
2、刪除的一致性保證
恢復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將被逐個逐漸占滿，期待后續的解決方案吧。
五、目錄支持
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
1、存儲
$curl -F "filename=@hello.txt" "http://localhost:8888/foo/"
{"name":"hello.txt","size":39}
2、獲取
$ curl http://localhost:8888/foo/hello.txt
hello weed-fs!
3、查詢目錄文件列表
$ curl "http://localhost:8888/foo/?pretty=y"
{
"Directory": "/foo/",
"Files": [
{
"name": "hello.txt",
"fid": "6,067281a126"
}
],
"Subdirectories": null
}
4、刪除
$ curl -X DELETE http://localhost:8888/foo/hello.txt
{"error":""}
再嘗試獲取hello.txt：
$curl http://localhost:8888/foo/hello.txt
返回空。hello.txt已被刪除。
5、多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顯然也要做好集群。
六、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的存儲卷。
七、伸縮(Scaling)
對於分布式系統來說，Scaling是不得不考慮的問題，也是極為常見的操作。
1、伸（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都可以隨意增減，這里就不再重復贅述了。
2、縮(scale down)
master的縮是極其簡單的，只需將相應節點shutdown即可；如果master是leader，則其他master會檢測到leader shutdown，並自動重新選出新leader。不過在leader選舉的過程中，整個集群的服務將短暫停止，直到leader選出。
filer在standalone模式下，談伸縮是毫無意義的；對於distributed模式下，filter節點和master節點縮的方法 一致，shutdown即可。
唯一的麻煩就是volume節點，因為數據存儲在volume節點下，我們不能簡單的停掉volume，我們需要考慮在不同 replication策略下是否可以做數據遷移，如何做數據遷移。這就是下一節我們要詳細描述的。
八、數據遷移
下面我們就來探討一下weed-fs的volume數據遷移問題。
1、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即可。
2、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上的數據也生效了。
3、100復制策略下的數據遷移
測試環境稍作變化：
master:
$ weed -v=3 master -port=9333 -mdir=./m1 -defaultReplication=100
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=dc2
和之前一樣，我們上傳三份文件：
$ 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”策略的情形。
其他策略的分析方式也是如此，這里就不長篇大論了。
九、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相對於其他分布式文件系統的優點。
十、其它
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。
十一、小結
weed-fs為想尋找開源分布式文件系統的朋友們提供了一個新選擇。尤其是在存儲大量小圖片時，weed-fs自身就是基於haystack這一優化圖 片存儲的論文的。另外weed-fs使用起來的確十分簡單，分分鍾就可以建立起一個分布式系統，部署容易，幾乎不需要什么配置。但weed-fs目前最大 的問題似乎是沒有重量級的使用案例，自身也還有不少不足，但希望通過這篇文章能讓更多人認識weed-fs，並使用weed-fs，幫助改善weed-fs吧。