KFS部署配置说明及管理
原创文章转载请注明出处：http://wangwei3.iteye.com/blog/916476
基本机器配置
此配置在 scripts/machines.cfg
为服务定义的三个变量：
* node: 这个变量指定NODE应该在那个服务上被实例化运行
* rundir: 这个变量指定NODE的binaries被实例化的目录。当多个服务运行在同一个NODE时，每个服务的这个变量必须是唯一值。
* baseport: 在一个NODE，这个变量是为监听传入连接定义的唯一端口。在KFS中，进程间的通信---在meta中
server/chunkserver(s)/applications---是通过TCP sockets连接. 现在，
- 在多个服务运行在相同的NODE时，应该为每个服务的端口指定一个唯一值。
- 在服务运行在不同的NODE时，显然地，这个值是唯一的。因此，所有的服务能被配置成相同的端口。
metaserver的其他变量：
* backup_path: 这个变量用来指定metaserver的checkpoint文件(远程)备份位置。定期地，通过rsync文件同步，metaserver的chekpoint文件备份到这个远程位置。为了备份工作，这个"backup_path”应该存在，你应该使SSH无密码---来自metaserver的机器是运行远程NODO来把checkpoint文件备份。
* clusterkey: 这个字符串定义为群集的"key"。
每当一个chunkserver连接，他传递"key"值给metaserver。
只有"key"值匹配，这个chunkserver才允许被加入群。这用来防止配置不匹配。
chunkserver的其他变量：
* space: 这个变量指定chunkserver存储空间总量。空间单位是：
* 'G' 为千兆字节
* 'M' 为兆
* 'B' 为字节
例如： space: 30 G
* chunkdir: 这个变量是可选的。他能被用来提供一个目录列表让chunkserver来存储chunks。该目录列表包含一组路径时可以用空格分隔
默认配置,
- metaserver的 checkpoint/log 文件存储在
${rundir}/bin/kfscp and ${rundir}/bin/kfslog
- chunkserver的 checkpoint/log 文件存储在
${rundir}/bin/logs
- chunkserver的chunks是存储在 ${rundir}/bin/kfschunk。 This
在"chunkdir"变量已定义时这个值被覆盖。
注意：这是每个服务的checkpoint/log文件不可更改或默认位置。改变它们会有不利的影响（如，metaserver 的logs/checkpoint 文件备份，定期清理没用的checkpoint/log文件）。
安装KFS BINARIES
这个集群构建脚本主要做以下几步：
---把metaserver/chunkserver的二进制文件，脚本打包成kfspkg.tgz，然后使用scp/ssh拷贝到各个节点上并安装。
---在目标节点，这个脚本把kfspkg.tgz拷贝到/tmp目录下
---这个脚本所使用的模型是对于metaserver/chunkserver的静态链接版本来说是有效的。如果你要用动态链接的版本，上述方法不能正常使用。
需要设置LD_LIBRARY_PATH环境变量，然后指向相应的动态链接库文件。不过这种方法在目前的版本中不支持。
运行 KFS
这个脚本在所给的目标机器上读取machines.cfg文件和启动相应服务。
- 对于metaserver，metaserver二进制和脚本一样定期清理老的checkpoint/log 文件。
- 对于chunkserver，chunkserver二进制和脚本一样定期清理老的checkpoint/log 文件。
对于这两种metaserver/chunkserver，每当得到一个新的checkpoint（这也导致日志轮换出现），老的checkpoint/logs不会被删除。为了防止这些老文件的积累，定期清理已完成的脚本。
如果服务先运行在目标机器上，那么在目标机器上这个脚本没有作用。
停止 KFS
这个脚本在所给的目标机器上读取machines.cfg文件和停止相应服务。
监听KFS服务
为了监听KFS服务，你可以使用 ~/code/kfs/build/bin/KfsPing工具。这个工具能有以下用法：
kfsping -m -s 192.168.1.200 -p 20000
其中的 -m 指定要 ping 的是 metaserver ， -s 指定 server 的 IP ， -p 指定 server 的监听端口。
要检查 chunkserver1 是否启动成功，则：
kfsping -c -s 192.168.1.201 -p 30000
如果想单独关闭某个 chunkserver ，则可以在 chunkserver 中执行以下命令：
sudo scripts/kfsrun.sh -S -c -f bin/ChunkServer.prp
这样只会关闭这个 chunkserver ，而不影响其他 server.
关闭后重新启动： scripts/kfsrun.sh -s -c -f bin/ChunkServer.prp
增加新的chunkserver
添加新的chunkserver到设置，有以下步骤：
1. 添加新的chunkserver到machines.cfg文件
2. 安装KFS二进制在新机器上，也就是重启KFS BINARIES。
3. 启动chunkserever在新NODE，也就是启动kfs server
4. 该metaserver并定期重新平衡数据。如果它检测有些chunkservers过度使用（即“80％的空间被使用），数据从过度利用迁移到利用不足的节点。
WHERE DOES THE SERVER STORE THINGS
当KFS服务运行（metaserver/chunkserver），以下目录被创建：
- metaserver: kfscp, kfslog.这些目录存储，分别地通过metaserver产生checkpoints 和log文件。
- chunkserver: kfschunk, kfslog. 这些目录存储，分别地通过chunkserver产生chunk文件和logs/checkpoints。
对于任意一个服务，每一分钟checkpoint/logs一次，那些老的log/checkpoint文件不能立刻被删除。这是一个清丽过程，一个小时运行一次删除旧文件。
最后，chunkserver也有一个目录"kfschunk/lost+found"保存陈旧/损坏的chunks:
- stale chunks: These are chunks for which there is a chunk version #
mismatch: the version # of the chunk on the chunkserver is less
than what the metaserver knows is the latest version # of that
chunk.
- corrupted chunk: These are chunks for which there is a checksum
mismatch. That is, KFS chunkservers compute checksums for a data
block on 64KB boundaries; the checksums are computed at the time of
writing data to tbe chunk and the checksums are stored in the
logs/checkpoint files. On each read, the checksums are validated.
During this validation process, if there is a mismatch, then the
chunk is said to be corrupt. The corrupt chunks are moved to the
lost+found directory. The metaserver is notified of the corrupted
chunk. If the chunk is replicated, the metaserver will trigger
re-replication to recover the lost chunk.
升级
从KFS-v-0.1更新到KFS-v-0.1.1，运行安装脚本升级选项。例如，假设你已安装KFS二进制, type the following:
1. cd ~/code/kfs/scripts
2. python kfssetup.py -f machines.cfg -b ../build/bin -u
升级脚本会执行以下动作：
1. 停止存在的chunkserver/metaserver进程在已有的NODE中
2. 增加新的二进制到每个NODE还升级脚本在每个NODE。这类似于安装完成。
基本机器配置
此配置在 scripts/machines.cfg
为服务定义的三个变量：
* node: 这个变量指定NODE应该在那个服务上被实例化运行
* rundir: 这个变量指定NODE的binaries被实例化的目录。当多个服务运行在同一个NODE时，每个服务的这个变量必须是唯一值。
* baseport: 在一个NODE，这个变量是为监听传入连接定义的唯一端口。在KFS中，进程间的通信---在meta中
server/chunkserver(s)/applications---是通过TCP sockets连接. 现在，
- 在多个服务运行在相同的NODE时，应该为每个服务的端口指定一个唯一值。
- 在服务运行在不同的NODE时，显然地，这个值是唯一的。因此，所有的服务能被配置成相同的端口。
metaserver的其他变量：
* backup_path: 这个变量用来指定metaserver的checkpoint文件(远程)备份位置。定期地，通过rsync文件同步，metaserver的chekpoint文件备份到这个远程位置。为了备份工作，这个"backup_path”应该存在，你应该使SSH无密码---来自metaserver的机器是运行远程NODO来把checkpoint文件备份。
* clusterkey: 这个字符串定义为群集的"key"。
每当一个chunkserver连接，他传递"key"值给metaserver。
只有"key"值匹配，这个chunkserver才允许被加入群。这用来防止配置不匹配。
chunkserver的其他变量：
* space: 这个变量指定chunkserver存储空间总量。空间单位是：
* 'G' 为千兆字节
* 'M' 为兆
* 'B' 为字节
例如： space: 30 G
* chunkdir: 这个变量是可选的。他能被用来提供一个目录列表让chunkserver来存储chunks。该目录列表包含一组路径时可以用空格分隔
默认配置,
- metaserver的 checkpoint/log 文件存储在
${rundir}/bin/kfscp and ${rundir}/bin/kfslog
- chunkserver的 checkpoint/log 文件存储在
${rundir}/bin/logs
- chunkserver的chunks是存储在 ${rundir}/bin/kfschunk。 This
在"chunkdir"变量已定义时这个值被覆盖。
注意：这是每个服务的checkpoint/log文件不可更改或默认位置。改变它们会有不利的影响（如，metaserver 的logs/checkpoint 文件备份，定期清理没用的checkpoint/log文件）。
安装KFS BINARIES
这个集群构建脚本主要做以下几步：
---把metaserver/chunkserver的二进制文件，脚本打包成kfspkg.tgz，然后使用scp/ssh拷贝到各个节点上并安装。
---在目标节点，这个脚本把kfspkg.tgz拷贝到/tmp目录下
---这个脚本所使用的模型是对于metaserver/chunkserver的静态链接版本来说是有效的。如果你要用动态链接的版本，上述方法不能正常使用。
需要设置LD_LIBRARY_PATH环境变量，然后指向相应的动态链接库文件。不过这种方法在目前的版本中不支持。
运行 KFS
这个脚本在所给的目标机器上读取machines.cfg文件和启动相应服务。
- 对于metaserver，metaserver二进制和脚本一样定期清理老的checkpoint/log 文件。
- 对于chunkserver，chunkserver二进制和脚本一样定期清理老的checkpoint/log 文件。
对于这两种metaserver/chunkserver，每当得到一个新的checkpoint（这也导致日志轮换出现），老的checkpoint/logs不会被删除。为了防止这些老文件的积累，定期清理已完成的脚本。
如果服务先运行在目标机器上，那么在目标机器上这个脚本没有作用。
停止 KFS
这个脚本在所给的目标机器上读取machines.cfg文件和停止相应服务。
监听KFS服务
为了监听KFS服务，你可以使用 ~/code/kfs/build/bin/KfsPing工具。这个工具能有以下用法：
kfsping -m -s 192.168.1.200 -p 20000
其中的 -m 指定要 ping 的是 metaserver ， -s 指定 server 的 IP ， -p 指定 server 的监听端口。
要检查 chunkserver1 是否启动成功，则：
kfsping -c -s 192.168.1.201 -p 30000
如果想单独关闭某个 chunkserver ，则可以在 chunkserver 中执行以下命令：
sudo scripts/kfsrun.sh -S -c -f bin/ChunkServer.prp
这样只会关闭这个 chunkserver ，而不影响其他 server.
关闭后重新启动： scripts/kfsrun.sh -s -c -f bin/ChunkServer.prp
增加新的chunkserver
添加新的chunkserver到设置，有以下步骤：
1. 添加新的chunkserver到machines.cfg文件
2. 安装KFS二进制在新机器上，也就是重启KFS BINARIES。
3. 启动chunkserever在新NODE，也就是启动kfs server
4. 该metaserver并定期重新平衡数据。如果它检测有些chunkservers过度使用（即“80％的空间被使用），数据从过度利用迁移到利用不足的节点。
WHERE DOES THE SERVER STORE THINGS
当KFS服务运行（metaserver/chunkserver），以下目录被创建：
- metaserver: kfscp, kfslog.这些目录存储，分别地通过metaserver产生checkpoints 和log文件。
- chunkserver: kfschunk, kfslog. 这些目录存储，分别地通过chunkserver产生chunk文件和logs/checkpoints。
对于任意一个服务，每一分钟checkpoint/logs一次，那些老的log/checkpoint文件不能立刻被删除。这是一个清丽过程，一个小时运行一次删除旧文件。
最后，chunkserver也有一个目录"kfschunk/lost+found"保存陈旧/损坏的chunks:
- stale chunks: These are chunks for which there is a chunk version #
mismatch: the version # of the chunk on the chunkserver is less
than what the metaserver knows is the latest version # of that
chunk.
- corrupted chunk: These are chunks for which there is a checksum
mismatch. That is, KFS chunkservers compute checksums for a data
block on 64KB boundaries; the checksums are computed at the time of
writing data to tbe chunk and the checksums are stored in the
logs/checkpoint files. On each read, the checksums are validated.
During this validation process, if there is a mismatch, then the
chunk is said to be corrupt. The corrupt chunks are moved to the
lost+found directory. The metaserver is notified of the corrupted
chunk. If the chunk is replicated, the metaserver will trigger
re-replication to recover the lost chunk.
升级
从KFS-v-0.1更新到KFS-v-0.1.1，运行安装脚本升级选项。例如，假设你已安装KFS二进制, type the following:
1. cd ~/code/kfs/scripts
2. python kfssetup.py -f machines.cfg -b ../build/bin -u
升级脚本会执行以下动作：
1. 停止存在的chunkserver/metaserver进程在已有的NODE中
2. 增加新的二进制到每个NODE还升级脚本在每个NODE。这类似于安装完成。