1.Ursa
云硬盘对IaaS云计算平台有至关重要的作用，几乎已成为必备组件，如亚马逊的EBS(Elastic Block Store)、阿里云的盘古、OpenStack中的Cinder等。云硬盘可为云计算平台带来许多优良特性，如更高的数据可靠性和可用性、灵活的数据快照功能、更好的虚拟机动态迁移支持、更短的主机故障恢复时间等等。随着万兆以太网逐渐普及，云硬盘的各项优势得到加强和凸显，其必要性变得十分强烈。
云硬盘的底层通常是分布式块存储系统，目前开源领域有一些此类项目，如Ceph RBD、Sheepdog。另外MooseFS和GlusterFS虽然叫做文件系统，但由于其特性与块存储系统接近，也能用于支持云硬盘。我们在测评中发现，这些开源项目均存在一些问题，使得它们都难以直接应用在大规模的生产系统当中。例如Ceph RBD的效率较低（CPU使用过高）；Sheepdog在压力测试中出现了数据丢失的现象；MooseFS的POSIX语义支持、基于FUSE的架构、不完全开源的2.0版本等问题给它自身带来了许多的局限性；GlusterFS与Ceph同属红帽收购的开源存储系统，主要用于scale-out文件存储场景，在云计算领域使用不多。此外，这些存储系统都难以充发挥用万兆网卡和SSD的性能潜力，难以在未来承担重任。
由于以上原因，美团云研发了全新的分布式块存储系统Ursa，通过简单稳固的系统架构、高效的代码实现以及对各种非典型场景的仔细考虑，实现了高可靠、高可用、高性能、低开销、可扩展、易运维、易维护等等目标。Ursa的名字源于DotA中的熊战士，他具有极高的攻击速度、攻击力和生命值，分别隐喻存储系统中的IOPS、吞吐率和稳定性。
分布式块存储相关项目与技术
2.1 Ceph
（主要参考：https:///blog/ceph_infra/）
Ceph项目起源于其创始人Sage Weil在加州大学Santa Cruz分校攻读博士期间的研究课题。项目的起始时间为2004年。在2006年的OSDI学术会议上，Sage发表了关于Ceph的论文，并提供了项目的下载链接，由此开始广为人知。2010年Ceph客户端部分代码正式进入Linux kernel 2.6.34。
Ceph同时提供对象、块和文件这三个层次的分布式存储服务，其中只有块层存储与我们相关。由于块存储在IaaS云计算系统中占有重要地位，Ceph在近些年的关注度得到显著提高。许多云计算系统实例基于Ceph提供块存储服务，如UnitedStack、Mirantis OpenStack等。
Ceph性能测试
测试版本：0.81
操作系统：CentOS 6.x
测试工具：fio
服务器配置：
CPU: Intel Xeon E5-2650v2 @ 2.6GHz
RAM: 96GB
NIC: 10 GbE
HDD: 6 NL SAS, 7200 RPM
RAID Controller: Dell H710p (LSI 2208 with 1GB NVRAM)
服务器数量：4，其中一个为兼职客户端
注意：由于客户端位于一个存储服务器上，所以有1/4的吞吐率不经过网卡。
测试结果如下：
读IOPS：16 407（此时客户端CPU占用率超过500%，5台服务器CPU总使用率接近500%）
写IOPS：941
顺序读吞吐率：218 859 KB/s
顺序写吞吐率：67 242 KB/s
顺序读延迟：1.6ms (664 IOPS)
顺序写延迟：4.4ms (225 IOPS)
网络ping值：0.1324ms
本地硬盘顺序读写延迟：0.03332ms (29 126 IOPS)
从测试来看，Ceph的读吞吐率正常，然而写吞吐率不足读的1/3，性能偏低；读写延迟比显著大于网络延迟与磁盘I/O延迟之和；CPU占用率过高。
2.2 Sheepdog
（主要参考：/blog/static/12033201221594937257/）
Sheepdog是由日本NTT实验室的Morita Kazutaka专为虚拟化平台创立的分布式块存储开源项目, 于2009年开源[1]。从2011年9月开始, 一些淘宝的工程师加入了Sheepdog项目，以及相关开源项目比如Corosync、Accord的开发。Sheepdog主要由两部分组成：集群管理和存储服务，其中集群管理目前使用Corosync或者Zookper来完成，存储服务是全新实现的。
Sheepdog采用无中心节点的全对称架构，基于一致性哈希实现从ObjectID到存储节点的定位：每个节点划分成多个虚拟节点，虚拟节点和ObjectID一样，采用64位整数唯一标识，每个虚拟节点负责一段包含节点ID在内的ObjectID区间。DataObject副本存在ObjectID对应的虚拟节点，及在后续的几个节点上。Sheepdog无单点故障问题，存储容量和性能均可线性扩展，新增节点通过简单配置即可加入集群，并且Sheepdog自动实现负载均衡，节点故障时可自动发现并进行副本修复，还直接支持QEMU/KVM。
Sheepdog的服务进程既承担数据服务的职责，同时也是客户端（QEMU）访问数据的gateway。QEMU的Sheepdog driver将对volume的请求转换成为对object的请求，然后通过UNIX domain socket或者TCP socket连接一个Sheepdog服务进程，并将访问请求发给该进程来完成后续步骤。Sheepdog的服务进程还可以开启数据缓存功能，以减少网络I/O。Sheepdog的I/O路径是“clientgatewayobject manager(s)”，读操作可以在任意副本完成，更新操作并行的发往所有副本， 当所有副本都更新成功之后，gateway才告诉客户端更新操作成功。
Sheepdog的数据可靠性问题
我们对Sheepdog开展了可靠性、可用性测试。在测试中有共3台服务器，每台配有6个机械硬盘，配置好Sheepdog之后，每台服务器启动10个VM，每个VM内无限循环运行fio分别执行小块随机读、写和大块顺序读、写的测试。
在执行压力测试一周后，对集群中的全部数据进行一致性检测（collie cluster check），发现有些数据块副本与另外2个不一致（“fixed replica ...”），有些数据块的3个各不相同（“no majority of ...”）：
复制代码代码如下:
[root@node3-10gtest ~]# collie cluster check
fix vdi test1-3
99.9 % [=================================================================>] 50 GB / 50 GB
fixed replica 3e563000000fca
99.9 % [=================================================================>] 50 GB / 50 GB
fixed replica 3e563000000fec
100.0 % [================================================================>] 50 GB / 50 GB
fixed replica 3e5630000026f5
100.0 % [================================================================>] 50 GB / 50 GB
fixed replica 3e563000002da6
100.0 % [================================================================>] 50 GB / 50 GB
fixed replica 3e563000001e8c
100.0 % [================================================================>] 50 GB / 50 GB
fixed replica 3e563000001530
...
fix vdi test2-9
50.9 % [=================================> ] 25 GB / 50 GB
no majority of d781e300000123
51.0 % [===================================> ] 26 GB / 50 GB
no majority of d781e300000159
51.2 % [===================================> ] 26 GB / 50 GB
no majority of d781e30000018a
53.2 % [====================================> ] 27 GB / 50 GB
…
2.3 MooseFS
（主要参考：/blog/static/12033201251791139592/）
MooseFS是容错的分布式文件系统，通过FUSE支持标准POSIX文件系统接口。 MooseFS的架构类似于GFS，由四个部分组成：
管理服务器Master：类似于GFS的Master，主要有两个功能：(1）存储文件和目录元数据，文件元数据包括文件大小、属性、对应的Chunk等；(2）管理集群成员关系和Chunk元数据信息，包括Chunk存储、版本、Lease等。
元数据备份服务器Metalogger Server：根据元数据文件和log实时备份Master元数据。
存储服务器Chunk Server：负责存储Chunk，提供Chunk读写能力。Chunk文件默认为64MB大小。
客户端Client：以FUSE方式挂到本地文件系统，实现标准文件系统接口。
MooseFS本地不会缓存Chunk信息， 每次读写操作都会访问Master， Master的压力较大。此外MooseFS写操作流程较长且开销较高。MooseFS支持快照，但是以整个Chunk为单位进行CoW(Copy-on-Write)，可能造成响应时间恶化，补救办法是以牺牲系统规模为代价，降低Chunk大小。
MooseFS基于FUSE提供POSIX语义支持，已有应用可以不经修改直接迁移到MooseFS之上，这给应用带来极大的便利。然而FUSE也带来了一些负面作用，比如POSIX语义对于块存储来说并不需要，FUSE会带来额外开销等等。
2.4 GFS/HDFS
（主要参考：/archives/119）
HDFS基本可以认为是GFS的一个简化开源实现，二者因此有很多相似之处。首先，GFS和HDFS都采用单一主控机+多台工作机的模式，由一台主控机(Master)存储系统全部元数据，并实现数据的分布、复制、备份决策，主控机还实现了元数据的checkpoint和操作日志记录及回放功能。工作机存储数据，并根据主控机的指令进行数据存储、数据迁移和数据计算等。其次，GFS和HDFS都通过数据分块和复制（多副本，一般是3）来提供更高的可靠性和更高的性能。当其中一个副本不可用时，系统都提供副本自动复制功能。同时，针对数据读多于写的特点，读服务被分配到多个副本所在机器，提供了系统的整体性能。最后，GFS和HDFS都提供了一个树结构的文件系统，实现了类似与Linux下的文件复制、改名、移动、创建、删除操作以及简单的权限管理等。
然而，GFS和HDFS在关键点的设计上差异很大，HDFS为了规避GFS的复杂度进行了很多简化。例如HDFS不支持并发追加和集群快照，早期HDFS的NameNode（即Master）没原生HA功能。总之，HDFS基本可以认为是GFS的简化版，由于时间及应用场景等各方面的原因对GFS的功能做了一定的简化，大大降低了复杂度。
2.5 HLFS
（主要参考：/blog/static/120332012226104116710/）
HLFS（HDFS Log-structured F