标签 Google 下的文章

weed-fs使用简介

weed-fs,全名Seaweed-fs,是一种用golang实现的简单且高可用的分布式文件系统。该系统的目标有二:

- 存储billions of files
- serve the files fast

weed-fs起初是为了搞一个基于Fackbook的Haystack论文的实现,Haystack旨在优化Fackbook内部图片存储和获取。后在这个基 础上,weed-fs作者又增加了若干feature,形成了目前的weed-fs。

这里并不打算深入分析weed-fs源码,仅仅是从黑盒角度介绍weed-fs的使用,发掘weed-fs的功能、长处和不足。

一、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
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:  Post http://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:  Post http://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。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吧。

理解Go 1.5 vendor

Go 1.5中(目前最新版本go1.5beta3)加入了一个experimental feature: vendor/。这个feature不是Go 1.5的正式功能,但却是Go Authors们在解决Go被外界诟病的包依赖管理的道路上的一次重要尝试。目前关于Go vendor机制的资料有限,主要的包括如下几个:

1、Russ Cox在Golang-dev group上的一个名 为"proposal: external packages" topic上的reply。
2、Go 1.5beta版发布后Russ Cox根据上面topic整理的一个doc
3、medium.com上一篇名为“Go 1.5 vendor/ experiment"的文章。

但由于Go 1.5稳定版还未发布(最新消息是2015.8月中旬发布),因此估计真正采用vendor的repo尚没有。但既然是Go官方解决方案,后续从 expreimental变成official的可能性就很大(Russ的初步计划:如果试验顺利,1.6版本默认 GO15VENDOREXPERIMENT="1";1.7中将去掉GO15VENDOREXPERIMENT环境变量)。因此对于Gophers们,搞 清楚vendor还是很必要的。本文就和大家一起来理解下vendor这个新feature。

一、vendor由来

Go第三方包依赖和管理的问题由来已久,民间知名的解决方案就有godepgb等。这次Go team在推出vendor前已经在Golang-dev group上做了长时间的调研,最终Russ Cox在Keith Rarick的proposal的基础上做了改良,形成了Go 1.5中的vendor。

Russ Cox基于前期调研的结果,给出了vendor机制的群众意见基础:
    – 不rewrite gopath
    – go tool来解决
    – go get兼容
    – 可reproduce building process

并给出了vendor机制的"4行"诠释:

If there is a source directory d/vendor, then, when compiling a source file within the subtree rooted at d, import "p" is interpreted as import "d/vendor/p" if that exists.

When there are multiple possible resolutions,the most specific (longest) path wins.

The short form must always be used: no import path can  contain “/vendor/” explicitly.

Import comments are ignored in vendored packages.

这四行诠释在group中引起了强烈的讨论,短小精悍的背后是理解上的不小差异。我们下面逐一举例理解。

二、vendor基本样例

Russ Cox诠释中的第一条是vendor机制的基础。粗犷的理解就是如果有如下这样的目录结构:

d/
   vendor/
          p/
           p.go
   mypkg/
          main.go

如果mypkg/main.go中有"import p",那么这个p就会被go工具解析为"d/vendor/p",而不是$GOPATH/src/p。

现在我们就来复现这个例子,我们在go15-vendor-examples/src/basic下建立如上目录结构(其中go15-vendor-examples为GOPATH路径):

$ls -R
d/

./d:
mypkg/    vendor/

./d/mypkg:
main.go

./d/vendor:
p/

./d/vendor/p:
p.go

其中main.go代码如下:

//main.go
package main

import "p"

func main() {
    p.P()
}

p.go代码如下:

//p.go
package p

import "fmt"

func P() {
    fmt.Println("P in d/vendor/p")
}

在未开启vendor时,我们编译d/mypkg/main.go会得到如下错误结果:

$ go build main.go
main.go:3:8: cannot find package "p" in any of:
    /Users/tony/.bin/go15beta3/src/p (from $GOROOT)
    /Users/tony/OpenSource/github.com/experiments/go15-vendor-examples/src/p (from $GOPATH)

错误原因很显然:go编译器无法找到package p,d/vendor下的p此时无效。

这时开启vendor:export GO15VENDOREXPERIMENT=1,我们再来编译执行一次:
$go run main.go
P in d/vendor/p

开启了vendor机制的go tool在d/vendor下找到了package p。

也就是说拥有了vendor后,你的project依赖的第三方包统统放在vendor/下就好了。这样go get时会将第三方包同时download下来,使得你的project无论被下载到那里都可以无需依赖目标环境而编译通过(reproduce the building process)。

三、嵌套vendor

那么问题来了!如果vendor中的第三方包中也包含了vendor目录,go tool是如何choose第三方包的呢?我们来看看下面目录结构(go15-vendor-examples/src/embeded):

d/
   vendor/
          p/
            p.go
          q/
            q.go
            vendor/
               p/
                 p.go
   mypkg/
          main.go

embeded目录下出现了嵌套vendor结构:main.go依赖的q包本身还有一个vendor目录,该vendor目录下有一个p包,这样我们就有了两个p包。到底go工具会选择哪个p包呢?显然为了验证一些结论,我们源文件也要变化一下:

d/vendor/p/p.go的代码不变。

//d/vendor/q/q.go
package q

import (
    "fmt"
    "p"
)

func Q() {
    fmt.Println("Q in d/vendor/q")
    p.P()
}

//d/vendor/q/vendor/p/p.go
package p

import "fmt"

func P() {
    fmt.Println("P in d/vendor/q/vendor/p")
}

//mypkg/main.go
package main

import (
    "p"
    "q"
)

func main() {
    p.P()
    fmt.Println("")
    q.Q()
}

目录和代码编排完毕,我们就来到了见证奇迹的时刻了!我们执行一下main.go:

$go run main.go
P in d/vendor/p

Q in d/vendor/q
P in d/vendor/q/vendor/p

可以看出main.go中最终引用的是d/vendor/p,而q.Q()中调用的p.P()则是d/vendor/q/vendor/p包的实现。go tool到底是如何在嵌套vendor情况下选择包的呢?我们回到Russ Cox关于vendor诠释内容的第二条:

   When there are multiple possible resolutions,the most specific (longest) path wins.

这句话很简略,但却引来的巨大争论。"longest path wins"让人迷惑不解。如果仅仅从字面含义来看,上面main.go的执行结果更应该是:

P in d/vendor/q/vendor/p

Q in d/vendor/q
P in d/vendor/q/vendor/p

d/vendor/q/vendor/p可比d/vendor/p路径更long,但go tool显然并未这么做。它到底是怎么做的呢?talk is cheap, show you the code。我们粗略翻看一下go tool的实现代码:

在$GOROOT/src/cmd/go/pkg.go中有一个方法vendoredImportPath,这个方法在go tool中广泛被使用

// vendoredImportPath returns the expansion of path when it appears in parent.
// If parent is x/y/z, then path might expand to x/y/z/vendor/path, x/y/vendor/path,
// x/vendor/path, vendor/path, or else stay x/y/z if none of those exist.
// vendoredImportPath returns the expanded path or, if no expansion is found, the original.
// If no expansion is found, vendoredImportPath also returns a list of vendor directories
// it searched along the way, to help prepare a useful error message should path turn
// out not to exist.
func vendoredImportPath(parent *Package, path string) (found string, searched []string)

这个方法的doc讲述的很清楚,这个方法返回所有可能的vendor path,以parentpath为x/y/z为例:

x/y/z作为parentpath输入后,返回的vendorpath包括:
   
x/y/z/vendor/path
x/y/vendor/path
x/vendor/path
vendor/path

这么说还不是很直观,我们结合我们的embeded vendor的例子来说明一下,为什么结果是像上面那样!go tool是如何resolve p包的!我们模仿go tool对main.go代码进行编译(此时vendor已经开启)。

根据go程序的package init顺序,go tool首先编译p包。如何找到p包呢?此时的编译对象是d/mypkg/main.go,于是乎parent = d/mypkg,经过vendordImportPath处理,可能的vendor路径为:

d/mypkg/vendor
d/vendor

但只有d/vendor/下存在p包,于是go tool将p包resolve为d/vendor/p,于是下面的p.P()就会输出:
P in d/vendor/p

接下来初始化q包。与p类似,go tool对main.go代码进行编译,此时的编译对象是d/mypkg/main.go,于是乎parent = d/mypkg,经过vendordImportPath处理,可能的vendor路径为:

d/mypkg/vendor
d/vendor

但只有d/vendor/下存在q包,于是乎go tool将q包resolve为d/vendor/q,由于q包自身还依赖p包,于是go tool继续对q中依赖的p包进行选择,此时go tool的编译对象变为了d/vendor/q/q.go,parent = d/vendor/q,于是经过vendordImportPath处理,可能的vendor路径为:

d/vendor/q/vendor
d/vendor/vendor
d/vendor

存在p包的路径包括:

d/vendor/q/vendor/p
d/vendor/p

此时按照Russ Cox的诠释2:choose longest,于是go tool选择了d/vendor/q/vendor/p,于是q.Q()中的p.P()输出的内容就是:
"
P in d/vendor/q/vendor/p"

如果目录结构足够复杂,这个resolve过程也是蛮繁琐的,但按照这个思路依然是可以分析出正确的包的。

另外vendoredImportPath传入的parent x/y/z并不是一个绝对路径,而是一个相对于$GOPATH/src的路径。

BTW,上述测试样例代码在这里可以下载到。

四、第三和第四条

最难理解的第二条已经pass了,剩下两条就比较好理解了。

The short form must always be used: no import path can  contain “/vendor/” explicitly.

这条就是说,你在源码中不用理会vendor这个路径的存在,该怎么import包就怎么import,不要出现import "d/vendor/p"的情况。vendor是由go tool隐式处理的。

Import comments are ignored in vendored packages.

go 1.4引入了canonical imports机制,如:

package pdf // import "rsc.io/pdf"

如果你引用的pdf不是来自rsc.io/pdf,那么编译器会报错。但由于vendor机制的存在,go tool不会校验vendor中package的import path是否与canonical import路径是否一致了。

五、问题

根据小节三中的分析,对于vendor中包的resolving过程类似是一个recursive(递归)过程。

main.go中的p使用d/vendor/p;而q.go中的p使用的是d/vendor/q/vendor/p,这样就会存在一个问题:一个工程中存 在着两个版本的p包,这也许不会带来问题,也许也会是问题的根源,但目前来看从go tool的视角来看似乎没有更好的办法。Russ Cox期望大家良好设计工程布局,作为lib的包不携带vendor更佳。

这样一个project内的所有vendor都集中在顶层vendor里面。就像下面这样:

d/
    vendor/   
            q/
            p/
            … …
    mypkg1
            main.go
    mypkg2
            main.go
    … …

另外Go vendor不支持第三方包的版本管理,没有类似godep的Godeps.json这样的存储包元信息的文件。不过目前已经有第三方的vendor specs放在了github上,之前Go team的Brad Fizpatrick也在Golang-dev上征集过类似的方案,不知未来vendor是否会支持。

六、vendor vs. internal

在golang-dev有人提到:有了vendor,internal似乎没用了。这显然是混淆了internal和vendor所要解决的问题。

internal故名思议:内部包,不是对所有源文件都可见的。vendor是存储和管理外部依赖包,更类似于external,里面的包都是copy自 外部的,工程内所有源文件均可import vendor中的包。另外internal在1.4版本中已经加入到go核心,是不可能轻易去除的,虽然到目前为止我们还没能亲自体会到internal 包的作用。

在《Go 1.5中值得关注的几个变化》一文中我提到过go 1.5 beta1似乎“不支持”internal,beta3发布后,我又试了试看beta3是否支持internal包。

结果是beta3中,build依旧不报错。但go list -json会提示错误:
"DepsErrors": [
        {
            "ImportStack": [
                "otherpkg",
                "mypkg/internal/foo"
            ],
            "Pos": "",
            "Err": "use of internal package not allowed"
        }
    ]

难道真的要到最终go 1.5版本才会让internal包发挥作用?

使用core-vagrant方式安装CoreOS

CoreOS是一种专门为运行类docker容器而生的linux发行版。与其他通用linux发行版(ubuntudebianredhat)相 比,它具有体型最小,消耗最小,支持滚动更新等特点。除此之外CoreOS内置的分布式系统服务组件也给开发者和运维者组建分布式集群、部署分布式服务应 用带来了极大便利。

CoreOS与知名容器Docker脚前脚后诞生,到目前为止已经较为成熟,国外主流云平台提供商如Amazon EC2Google Compute EngineMicrosoft AzureDigtial Ocean等均提供了CoreOS image,通过这些服务,你可以一键建立一个CoreOS实例,这似乎也是CoreOS官方推荐的主流install方式(最Easy)。

CoreOS当然支持其他方式的安装,比如支持虚拟机安装(vagrant+virtualbox)、PXE(preboot execute environment)安装以及iso install to 物理disk方式。如果仅仅是做一些实验,虚拟机安装是最简单也是最安全的方式。不过由于CoreOS的官方下载站在大陆无法直接访问(大陆程序员们好悲 催啊),因此这一最简单的虚拟机安装CoreOS的过程也就不那么简单了。

通过core-vagrant安装的直接结果是CoreOS被安装到一个VirtualBox虚拟机中,之后我们利用Vagrant命令来进行 CoreOS虚拟机的启停。CoreOS以及Vagrant都在持续演进,尤其是CoreOS目前在active dev中,版本号变化很快,这也是CoreOS滚动升级的必然结果。因此在安装操作演示前,我们有必要明确一下这个安装过程使用的软件版本:

    物理机OS:
        Ubuntu 12.04 3.8.0-42-generic x86_64
    VirtualBox:
        Oracle VM VirtualBox Manager 4.2.10
    Vagrant:
        Vagrant 1.7.3

    CoreOS:
        stable 717.3.0

    coreos-vagrant source:
        commit b9ed7e2182ff08b72419ab3e89f4a5652bc75082

一、原理

如果没有Wall,CoreOS的coreos-vagrant安装将非常简单:

1、git clone https://github.com/coreos/coreos-vagrant
2、编辑配置文件
3、vagrant up
4、vagrant ssh

但是现在有了Wall,步骤3:vagrant up会报错:无法连接到http://stable.release.core-os.net/amd64-usr/717.3.0/xx这个url,导致安装失败。

我大致分析了一下vagrant up的执行过程:

1、设置配置默认值

    $num_instances = 1
    $instance_name_prefix = "core"
    $update_channel = "alpha"
    $image_version = "current"
    $enable_serial_logging = false
    $share_home = false
    $vm_gui = false
    $vm_memory = 1024
    $vm_cpus = 1
    $shared_folders = {}
    $forwarded_ports = {}

2、判断是否存在config.rb这个配置,如果有,则加载。
3、设置config.vm.url,并获取对应的json文件:

{
  "name": "coreos-stable",
  "description": "CoreOS stable",
  "versions": [{
    "version": "717.3.0",
    "providers": [{
      "name": "virtualbox",
      "url": "http://stable.release.core-os.net/amd64-usr/717.3.0/coreos_production_vagrant.box",
      "checksum_type": "sha256",
      "checksum": "99dcd74c7cae8b1d90f108f8819f92b17bfbd34f4f141325bd0400fe4def55b6"
    }]
  }]
}

4、根据config.vm.provider(是virtualbox还是vmvare等)来决定采用哪种虚拟机创建逻辑。

这里我们看到,整个过程只需要从core-os.net下载两个文件:coreos_production_vagrant.boxcoreos_production_vagrant.json。如果我们提前将这两个文件下载到本地,并放在一个临时的http server下,修改Vagrantfile和coreos_production_vagrant.json这两个文件,就应该可以通过coreos-vagrant安装了。

二、coreos-vagrant安装single instance CoreOS

好了,根据上述原理,我们首先要下载coreos_production_vagrant.boxcoreos_production_vagrant.json这两个文件,根据我们的channel和版本选择,两个文件的下载地址分别为:

 http://stable.release.core-os.net/amd64-usr/717.3.0/coreos_production_vagrant.box
 http://stable.release.core-os.net/amd64-usr/717.3.0/coreos_production_vagrant.json

接下来就是不管你用什么梯子,只要把这两个文件下载到本地,并放到一个目录下就好了。

我们需要修改一下coreos_production_vagrant.json,将其中的url改为:
   
    "url": "http://localhost:8080/coreos_production_vagrant.box"

我们要将这两个文件放到一个local file server中,后续供core-vagrant访问。最简单的方法就是使用:

    python -m SimpleHTTPServer 8080

当然使用Go实现一个简单的http file server也是非常简单的:

//fileserver.go
package main

import "net/http"
import "log"

func main() {
    log.Fatal(http.ListenAndServe(":8080", http.FileServer(http.Dir("./"))))
}

接下来我们就可以按照正常步骤,下载coreos-vagrant并up了:

$git clone https://github.com/coreos/coreos-vagrant

修改Vagrantfile:

$ diff Vagrantfile Vagrantfile.bak
14,15c14,15
< $update_channel = "stable"
< $image_version = "717.3.0"

> $update_channel = "alpha"
> $image_version = "current"
55c55
<   config.vm.box_url = "http://localhost:8080/coreos_production_vagrant.json"

>   config.vm.box_url = "http://%s.release.core-os.net/amd64-usr/%s/coreos_production_vagrant.json" % [$update_channel, $image_version]

将user-data.sample改名为user-data,并编辑user-data,在etcd2下面增加一行:

      etcd2:
    name: core-01

将units:下面对于etcd2的注释去掉,以enable etcd2服务。(将etcd服务注释掉)

万事俱备,只需vagrant up。

$ vagrant up
Bringing machine 'core-01' up with 'virtualbox' provider…
==> core-01: Box 'coreos-stable' could not be found. Attempting to find and install…
    core-01: Box Provider: virtualbox
    core-01: Box Version: 717.3.0
==> core-01: Loading metadata for box 'http://localhost:8080/coreos_production_vagrant.json'
    core-01: URL: http://localhost:8080/coreos_production_vagrant.json
==> core-01: Adding box 'coreos-stable' (v717.3.0) for provider: virtualbox
    core-01: Downloading: http://localhost:8080/coreos_production_vagrant.box
    core-01: Calculating and comparing box checksum…
==> core-01: Successfully added box 'coreos-stable' (v717.3.0) for 'virtualbox'!
==> core-01: Importing base box 'coreos-stable'…
==> core-01: Matching MAC address for NAT networking…
==> core-01: Checking if box 'coreos-stable' is up to date…
==> core-01: Setting the name of the VM: coreos-vagrant_core-01_1437121834188_89503
==> core-01: Clearing any previously set network interfaces…
==> core-01: Preparing network interfaces based on configuration…
    core-01: Adapter 1: nat
    core-01: Adapter 2: hostonly
==> core-01: Forwarding ports…
    core-01: 22 => 2222 (adapter 1)
==> core-01: Running 'pre-boot' VM customizations…
==> core-01: Booting VM…
==> core-01: Waiting for machine to boot. This may take a few minutes…
    core-01: SSH address: 127.0.0.1:2222
    core-01: SSH username: core
    core-01: SSH auth method: private key
    core-01: Warning: Connection timeout. Retrying…
==> core-01: Machine booted and ready!
==> core-01: Setting hostname…
==> core-01: Configuring and enabling network interfaces…
==> core-01: Running provisioner: file…
==> core-01: Running provisioner: shell…
    core-01: Running: inline script

登入你的coreos实例:
$ vagrant ssh
CoreOS stable (717.3.0)
core@core-01 ~ $

在vagrant up时,你可能会遇到如下两个错误:

错误1:

Progress state: VBOX_E_FILE_ERROR
VBoxManage: error: Could not open the medium storage unit '/home1/tonybai/.vagrant.d/boxes/coreos-stable/717.3.0/virtualbox/coreos_production_vagrant_image.vmdk'.
VBoxManage: error: VMDK: inconsistent references to grain directory in '/home1/tonybai/.vagrant.d/boxes/coreos-stable/717.3.0/virtualbox/coreos_production_vagrant_image.vmdk'  (VERR_VD_VMDK_INVALID_HEADER).

这个问题的原因很可能是你的Virtualbox版本不对,比如版本太低,与coreos_production_vagrant.box格式不兼容。可尝试安装一下高版本virtualbox来解决。

错误2:

core-01: SSH address: 127.0.0.1:2222
core-01: SSH username: core
core-01: SSH auth method: private key
core-01: Warning: Connection timeout. Retrying…
core-01: Warning: Connection timeout. Retrying…
core-01: Warning: Connection timeout. Retrying…

coreos虚拟机创建后,似乎一直无法连接上。在coreos的github issue中,有人遇到了这个问题,目前给出的原因是因为cpu的支持虚拟化技术的vt开关没有打开,需要在bios中将其开启。这主要在安装64bit box时才会发生。

到这里,我们已经完成了一个single instance coreos虚拟机的安装。vagrant halt可以帮助你将启动的coreos虚拟机停下来。

$ vagrant halt
==> core-01: Attempting graceful shutdown of VM…

三、  CoreOS cluster

上面虽然成功的安装了coreos,然并卵。在实际应用中,CoreOS多以Cluster形式呈现,也就是说我们要启动多个CoreOS实例。

使用vagrant启动多个coreos实例很简单,只需将配置中的$num_instances从1改为n。

这里我们启用config.rb这个配置文件(将config.rb.sample改名为config.rb),并将其中的$num_instances修改为3:

# Size of the CoreOS cluster created by Vagrant
$num_instances=3

该配置文件中的数据会覆盖Vagrantfile中的默认配置。

三个instance中的etcd2要想组成集群还需要一个配置修改,那就是在etcd.io上申请一个token:

$curl https://discovery.etcd.io/new

https://discovery.etcd.io/fe81755687323aae273dc5f111eb059a

将这个token配置到user-data中的etcd2下:

  etcd2:

    #generate a new token for each unique cluster from https://discovery.etcd.io/new
    #discovery: https://discovery.etcd.io/<token>
    discovery: https://discovery.etcd.io/fe81755687323aae273dc5f111eb059a

我们再来up看看:

$ vagrant up
Bringing machine 'core-01' up with 'virtualbox' provider…
Bringing machine 'core-02' up with 'virtualbox' provider…
Bringing machine 'core-03' up with 'virtualbox' provider…
==> core-01: Checking if box 'coreos-stable' is up to date…
==> core-01: VirtualBox VM is already running.
==> core-02: Importing base box 'coreos-stable'…
==> core-02: Matching MAC address for NAT networking…
==> core-02: Checking if box 'coreos-stable' is up to date…
==> core-02: Setting the name of the VM: coreos-vagrant_core-02_1437388468647_96550
==> core-02: Fixed port collision for 22 => 2222. Now on port 2200.
==> core-02: Clearing any previously set network interfaces…
==> core-02: Preparing network interfaces based on configuration…
    core-02: Adapter 1: nat
    core-02: Adapter 2: hostonly
==> core-02: Forwarding ports…
    core-02: 22 => 2200 (adapter 1)
==> core-02: Running 'pre-boot' VM customizations…
==> core-02: Booting VM…
==> core-02: Waiting for machine to boot. This may take a few minutes…
    core-02: SSH address: 127.0.0.1:2200
    core-02: SSH username: core
    core-02: SSH auth method: private key
    core-02: Warning: Connection timeout. Retrying…
==> core-02: Machine booted and ready!
==> core-02: Setting hostname…
==> core-02: Configuring and enabling network interfaces…
==> core-02: Running provisioner: file…
==> core-02: Running provisioner: shell…
    core-02: Running: inline script
==> core-03: Importing base box 'coreos-stable'…
==> core-03: Matching MAC address for NAT networking…
==> core-03: Checking if box 'coreos-stable' is up to date…
==> core-03: Setting the name of the VM: coreos-vagrant_core-03_1437388512743_68112
==> core-03: Fixed port collision for 22 => 2222. Now on port 2201.
==> core-03: Clearing any previously set network interfaces…
==> core-03: Preparing network interfaces based on configuration…
    core-03: Adapter 1: nat
    core-03: Adapter 2: hostonly
==> core-03: Forwarding ports…
    core-03: 22 => 2201 (adapter 1)
==> core-03: Running 'pre-boot' VM customizations…
==> core-03: Booting VM…
==> core-03: Waiting for machine to boot. This may take a few minutes…
    core-03: SSH address: 127.0.0.1:2201
    core-03: SSH username: core
    core-03: SSH auth method: private key
    core-03: Warning: Connection timeout. Retrying…
==> core-03: Machine booted and ready!
==> core-03: Setting hostname…
==> core-03: Configuring and enabling network interfaces…
==> core-03: Running provisioner: file…
==> core-03: Running provisioner: shell…
    core-03: Running: inline script

$vagrant ssh core-02
CoreOS stable (717.3.0)
core@core-02 ~ $

可以看到Vagrant启动了三个coreos instance。关闭这些instance,同样用halt:

$ vagrant halt
==> core-03: Attempting graceful shutdown of VM…
==> core-02: Attempting graceful shutdown of VM…
==> core-01: Attempting graceful shutdown of VM…

四、小结

以上仅仅是CoreOS最基本的入门,虽然现在安装ok了,但CoreOS的各种服务组件的功用、配置;如何与Docker配合形成分布式服务系统;如何用Google Kubernetes管理容器集群等还需更进一步深入学习,这个后续会慢慢道来。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多