README.md 4.1 KB
Newer Older
G
gongweibao 已提交
1 2 3 4 5 6 7
# Desgin doc: FileManager
## Objetive
在本文档中,我们设计说明了用户上传、下载、管理自己在PaddlePaddle Cloud上的文件所涉及到的模块和流程
<image src=./src/filemanager.png width=600>

## Module
### Client
G
gongweibao 已提交
8
Client是用户操作的命令行程序,支持的命令如下
G
gongweibao 已提交
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

- ls
 
```bash
ls
```

- cp

```bash
cp 
```

- sync

```bash
sync
```

- mv

```bash
mv
```


### Ingress
- 在kubernets中运行
- 做Http转发
- 注意配置session保持


### FileServer
G
gongweibao 已提交
42 43 44 45 46 47
功能说明:  
- gorpc写的HttpServer  
- 响应外部的REST API的请求  
- 在kubernets中运行  

REST API说明:
G
gongweibao 已提交
48 49 50 51 52 53 54 55 56 57 58 59 60 61 62

- file

```
GET /file: Get attribue of files
POST /file: Touch a file 
DELETE /file: Delete a File
```

- chunk
 
```
GET /file/chunk: Get a chunk info 
POST /file/chunk: Update a chunk
```
G
gongweibao 已提交
63 64 65 66 67 68 69 70 71 72 73
为什么有chunk的抽象:  
用户文件可能是比较大的,上传到Cloud或者下载到本地的时间可能比较长,而且在传输的过程中也可能出现网络不稳定的情况。为了应对以上的问题,我们提出了chunk的概念。chunk由所在的文件偏移、数据、数据长度及校验值组成。数据内容的上传和下载都是都过chunk的操作来实现的。由于chunk比较小(默认256K),完成一个传输动作的transaction的时间也比较短,不容易出错。

```
type Chunk struct {
	filePos int64
	checkSum uint32
	len     uint32
	data    []byte
}
```  
G
gongweibao 已提交
74 75 76 77 78 79 80 81 82 83 84

- dir

```
GET /dir: List all files in a directory
POST /dir: Touch a directory
DELETE /dir: Delete a directory
```


## 流程
G
gongweibao 已提交
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116
### 关于文件权限
- 每一个用户在Cloud注册后可以申请分配用户空间,系统默认会在CephFS上分配一个固定大小(比如初始10G)的、有所有权限的volume,对用户而言就是自己的`home`目录。用户彼此之间的数据是隔离的、无法访问的。用户的空间大小第一期也不允许扩大。
- 公共数据集合放到一个单独的volume下,对所有外部用户只读。由于其被读取的可能比较频繁,需要提高其备份数,防止成为热点文件。

### 关于认证
> 通信各方都需要有各自的身份证。一个公司可以自签名一个CA身份证,并 且用它来给每个雇员以及每个程序签署身份证。这样,只要每台电脑上都预先安 装好公司自己的CA身份证,就可以用这个身份证验证每个雇员和程序的身份了。 这是目前很多公司的常用做法  

身份的认证来自于用户或者程序是否有crt标识身份,以及是否有可信的CA确认这个身份证是否有效。我们这里描述的crt涉及到两个部分,一个是Client端程序访问FileServer的crt,不妨称之为Client crt;另外一个是FileServer访问CephFS的crt,不妨称之为CephFS crt。

- Client和FileServer相互认证的办法   
`cloud.paddlepaddle.org`需要有自己的CA,FileServer和注册用户也要为其生成各自的私钥(key)、crt。这样用户把CA、自己的key和crt下载到本地后,Client程序可以用之和FileServer可以做相互的认证

- CephFS验证FileServer的身份的两种方法
	- 第一种:每一个用户都有自己单独的访问CephFS crt。
	用户访问其空间时,由FileServer读取它然后才可以在CephFS上完成操作。
	- 第二种:CephFS crt只有一个,也就是admin crt,拥有所有volume的读写权限。  
	FileServer从Client crt提取Client的身份(username),限制其可以操作的volume。 我们选择这种。

### 关于cp
cp的关键在于需要Client端对比src和dst的文件chunks的checkSum是否保持一致,不一致的由Client Get或者Post完成。藉由上述的方法完成断点的数据传输。  

优化的方法:  

- dst文件不存在时,可以没有Get的过程,只有Post。
- 文件的chunks信息可以做cache,不用每次启动传输都去读和计算。这个由于比较复杂,第一期暂时不做。

tricky:

- 可以用[Fallocate](https://golang.org/pkg/syscall/#Fallocate)让dst和src文件保持相同的大小。这样,chunk就可以写固定的偏移上。

## 参考文档
- [Do you see tls?](https://github.com/k8sp/tls/blob/master/README.md)