cloudxy 新一代弹性云计算平台
openkk
12年前
CLOUDXY立足于实现虚拟子网（以太网）的弹性云计算平台 该项目主要包含有两个子项目：
- HLFS - 虚拟机分布式镜像存储 (类似于亚马逊EBS，首先发布出来）
- ECMS - 虚拟环境管理系统
背景介绍
HLFS的使用场景是为弹性云平台提供虚拟磁盘（类似amazon的EBS）提供后台存储服务。它需要满足高可用性、高性能、能随机读写、快速故障恢复、数据快照、回滚等特性。
实现简述
hadoop dfs 可被看做一个可靠的、随时可扩展的“磁盘”；但美中不足的是其不能随机写，只能追加写入，因此还不能直接作为我们的镜像存储系统。那么我们需要借助log structrue filesystem的理念，使用追加方式在hdfs上实现随机读写的要求。
特性描述
- 用户态文件系统 —— 和标准的内核态posix接口文件系统不同，HLFS实现于用户态，以lib形式嵌入客户端。 不必完全实现posix接口规范 ，按需实现pread\pwrite等主要语意即可。
- 支持随机读写 —— 文件要能支持随机读写（按照offset定位位置）。
- 支持超大文件存储 —— 单个文件需可支持上T数据存储（这里文件对应的是虚拟机的磁盘大小）。
- 仅支持单文件 —— 在我们应用场景中每个虚拟磁盘对应一个HLFS实例，因此最简化的设计就是只需要支持一个文件（对应虚拟机里一个磁盘）。
- 面向客户端一致性 （client - orient ）—— 虚拟机磁盘同一时刻只能被挂载到一个虚拟机镜像中，因此只需要对其挂载的虚拟机客户保证数据一致
- 支持快照、支持回滚 —— 文件可随时进行现场快照、可按需进行回滚（对于host服务的虚拟机，快照回滚是防止网站被入侵或者误操作造成数据污染、损坏的最有效手段）
- 支持多数据多副本 —— 数据存储多份，保证数据安全性和就近访问优化（hadoop dfs为我们实现这点）
- 集群系统可动态扩容 —— 存储节点（PC服务器）可动态添加到集群中，而不影响集群正常服务（hadoop dfs为我们实现这点）
- 集群系统可透明故障切换 —— 存储节点出现故障，不影响服务，对用户透明（hadoop dfs为我们实现这点）
概要设计
HLFS 的磁盘数据格式与一般文件系统（FFS—fast filesystem）无多大差异，都是借助于indirect block 、inode 、directory 等结构。 所不同之处在于LFS会将磁盘（我们这里是hdfs的存储池）分割成有序的segment 进行管理，当前活跃的segment只有一个（也就是我们日志的逻辑尾的segment）。 这些segment 逻辑上头尾相连组成一个线性log，任何的文件更新（数据块、indirect block 、inode等等）都会以追加方式写入到log尾部——显然这么做的好处是保证了磁头的顺序移动，提高了吞吐；而带来的麻烦是需要回收前期写入的旧数据 （修改过的），否则磁盘迟早会写满。综上所述我们设计的最基本思路是 —— 利用hadoop dfs为我们提供可靠的、分布式的存储介质；然后在其上实现LFS。
下面就关键设计技术点做概要设计。
HLFS LOG 创建和检索
LOG 是我们数据持久化的一个基本写入单位,对于写透需求来说，实际上每次写入动作都会产生一个新的LOG，而每次的LOG大小不尽相同。
LOG的内容显然必须包含被写入的数据块，还需要包含对应的元数据（索引块等）信息，以及元数据的元信息（inode)，这样才能完成对一个信息的索引。
LOG创建
任何文件或者目录的修改LFS都需要向log中写入如下几部分信息，而且要求严格“按照顺序写入（in-order semantics）”—— 其目的是为了崩溃时能尽可能恢复数据一致性。
- 任何修改或者新数据块 （数据块是数据实际操作的最小粒度；可配置；大小为8196字节或者更大）
- Indirect block 更新 （也叫做meta-data block ，是inode中的2/3/4级索引块数据）
- Inode 更新 （每个inode对应一个文件，如果只支持单一文件，则只用一个inode)
- Inode map 更新 ( 单一文件则只有一个映射项）
