《分布式块存储系统Ursa的设计与实现.docx》由会员分享，可在线阅读，更多相关《分布式块存储系统Ursa的设计与实现.docx（14页珍藏版）》请在三一办公上搜索。
1、分布式块存储系统Ursa的设计与实现引言云硬盘对IaaS云计算平台有至关重要的作用，几乎已成为必备组件，如亚马逊的 EBS(Elastic Block Store)、阿里云的盘古、OpenStack 中的 Cinder 等。云硬盘可 为云计算平台带来许多优良特性，如更高的数据可靠性和可用性、灵活的数据快照 功能、更好的虚拟机动态迁移支持、更短的主机故障恢复时间等等。随着万兆以太 网逐渐普及，云硬盘的各项优势得到加强和凸显，其必要性变得十分强烈。云硬盘的底层通常是分布式块存储系统，目前开源领域有一些此类项目，如Ceph RBD、Sheepdog。另外MooseFS和GlusterFS虽然叫做文件
2、系统，但由于其特 性与块存储系统接近，也能用于支持云硬盘。我们在测评中发现，这些开源项目均 存在一些问题使得它们都难以直接应用在大规模的生产系统当中。例如Ceph RBD 的效率较低(CPU使用过高)；Sheepdog在压力测试中出现了数据丢失的现象； MooseFS的POSIX语义支持、基于FUSE的架构、不完全开源的2.0版本等问题 给它自身带来了许多的局限性GlusterFS与Ceph同属红帽收购的开源存储系统， 主要用于scale-out文件存储场景，在云计算领域使用不多。此外，这些存储系统 都难以充发挥用万兆网卡和SSD的性能潜力，难以在未来承担重任。由于以上原因，美团云研发了全新的
3、分布式块存储系统Ursa，通过简单稳固的系统 架构、高效的代码实现以及对各种非典型场景的仔细考虑，实现了高可靠、高可用、 高性能、低开销、可扩展、易运维、易维护等等目标。Ursa的名字源于DotA中的 熊战士，他具有极高的攻击速度、攻击力和生命值，分别隐喻存储系统中的IOPS、 吞吐率和稳定性。分布式块存储相关项目与技术2.1 Ceph（主要参考：Ceph项目起源于其创始人Sage Weil在加州大学Santa Cruz分校攻读博士期间 的研究课题。项目的起始时间为2004年。在2006年的OSDI学术会议上，Sage 发表了关于Ceph的论文，并提供了项目的下载链接，由此开始广为人知。201
4、0 年Ceph客户端部分代码正式进入Linux kernel 2.6.34OCeph同时提供对象、块和文件这三个层次的分布式存储服务，其中只有块层存储 与我们相关。由于块存储在IaaS云计算系统中占有重要地位，Ceph在近些年的关 注度得到显著提高。许多云计算系统实例基于Ceph提供块存储服务，如 UnitedStack、MirantisOpenStack 等。Ceph性能测试 测试版本：0.81 操作系统：CentOS 6.x 测试工具：fio 服务器配置：o CPU: Intel Xeon E5-2650v2 2.6GHzo RAM: 96GBo NIC: 10 GbEo HDD: 6 N
5、L SAS, 7200 RPMo RAID Controller: Dell H710p (LSI 2208 with 1GB NVRAM) 服务器数量：4，其中一个为兼职客户端注意：由于客户端位于一个存储服务器上，所以有1/4的吞吐率不经过网卡。测试结果如下： 读IOPS : 16 407(此时客户端CPU占用率超过500%，5台服务器CPU总使用率接近500%) 写 IOPS : 9411顺序读吞吐率：218 859 KB/s |顺序写吞吐率：67 242 KB/s 顺序读延迟：1.6ms (664 IOPS) 顺序写延迟：4.4ms (225 IOPS) 网络 ping 值：0.1324
6、ms 本地硬盘顺序读写延迟：0.03332ms (29 126 IOPS)从测试来看，Ceph的读吞吐率正常，然而写吞吐率不足读的1/3，性能偏低；读 写延迟比显著大于网络延迟与磁盘I/O延迟之和；CPU占用率过高。2.2 Sheepdog(主要参考：Sheepdog是由日本NTT实验室的Morita Kazutaka专为虚拟化平台创立的分布 式块存储开源项目，于2009年开源1。从2011年9月开始，一些淘宝的工程师加 入了 Sheepdog项目，以及相关开源项目比如Corosync、Accord的开发。Sheepdog主要由两部分组成：集群管理和存储服务，其中集群管理目前使用 Corosy
7、nc或者Zookper来完成，存储服务是全新实现的。Sheepdog采用无中心节点的全对称架构，基于一致性哈希实现从ObjectID到存 储节点的定位：每个节点划分成多个虚拟节点，虚拟节点和ObjectID 一样，采用 64位整数唯一标识，每个虚拟节点负责一段包含节点ID在内的ObjectID区间。 DataObject副本存在ObjectID对应的虚拟节点，及在后续的几个节点上。Sheepdog无单点故障问题，存储容量和性能均可线性扩展，新增节点通过简单配 置即可加入集群，并且Sheepdog自动实现负载均衡，节点故障时可自动发现并进 行副本修复，还直接支持QEMU/KVM。Sheepdog
8、的服务进程既承担数据服务的职责，同时也是客户端(QEMU)访问数 据的gateway。QEMU的Sheepdog driver将对volum e的请求转换成为对object 的请求，然后通过 UNIX domain socket 或者 TCP socket 连接一个 Sheepdog 服 务进程，并将访问请求发给该进程来完成后续步骤。Sheepdog的服务进程还可以 开启数据缓存功能，以减少网络I/O。Sheepdog的I/O路径是“clientgatewayobject manager，读操作可以在任意副本完成，更 新操作并行的发往所有副本，当所有副本都更新成功之后，gateway才告诉客户
9、 端更新操作成功。Sheepdog的数据可靠性问题我们对Sheepdog开展了可靠性、可用性测试。在测试中有共3台服务器，每台配 有6个机械硬盘，配置好Sheepdog之后，每台服务器启动10个VM，每个VM 内无限循环运行fio分别执行小块随机读、写和大块|1顺序读、写的测试。:劄目Z好虞53田SdD工仞茉欧布团SzPsooiai。翁哆爰朝本XISOd我当毋不3SPd R 哆爰朝本培夕好团甜最者SdesooH（/乙 6S6EH6匕我乙 10 乙 0 乙 l/D!*K/6o|q/ujo）9r6o|qwAj59d:dnu:呆第王）9909 / as LZ as 09 / as 92 as 09
10、/ as 92 as 09 / as 92 =% 乙. 8l00000l8LP jo AtjoCeui ou=% 2 , T9 69T000009T8AP JO AtjoCeui ou=% 0 T9 2T000009T8AP JO AtjoCeui ou=% 6,09 6-乙 TPA XTJ . 09T00000999 EOTxdea pexyjas09 / S3 09 =% CTOCH。护1。9圣 EOTTdea pexyjas09 / S3 09 =% 000T 9买乙000009G迎 EOTxdea pexTjas09 / S3 09 =% 000T GI9乙。9 0迎 EOTxdea
11、pexTjas09 / S3 09 =% CTOCH Q习。9圣 EOTTdea pexyjas09 / S3 09 =% 666 eoj000000999 EOTxdea pexTj aS09 / S3 09 =% 666 E-T4S94 TPA 叫。aesnxo 977700 # 439460T-epou4Ooa：（J。Aiuofem ou ）回昌 团谄净谕 扁身（ ewdaj pox!,，）涎一业乙仍皆与更僵谄净谕扁身他绥（P叫。 jeisnp ei|OD） 0肾ffil，港一寄谕虞手团申瘴事EX 与国一襄踪H巧9昭丑 管理服务器Master :类似于GFS的Master，主要有两个功能
12、：(1)存储文件和目录元数据，文件元数据 包括文件大小、属性、对应的Chunk等；(2)管理集群成员关系和Chunk元数据信息，包括Chunk存储、 版本、Lease等。 元数据备份服务器Metalogger Server :根据元数据文件和log实时备份Master元数据。 存储服务器Chunk Server :负责存储Chunk，提供Chunk读写能力。Chunk文件默认为64MB大小。 客户端Client :以FUSE方式挂到本地文件系统，实现标准文件系统接口。MooseFS本地不会缓存Chunk信息，每次读写操作都会访问Master， Master 的压力较大。此外MooseFS写操作
13、流程较长且开销较高。MooseFS支持快照，但 是以整个Chunk为单位进行CoW(Copy-on-Write)，可能造成响应时间恶化，补 救办法是以牺牲系统规模为代价，降低Chunk大小。MooseFS基于FUSE提供POSIX语义支持，已有应用可以不经修改直接迁移到 MooseFS之上，这给应用带来极大的便利。然而FUSE也带来了一些负面作用，比 如POSIX语义对于块存储来说并不需要，FUSE会带来额外开销等等。(主要参考：HDFS基本可以认为是GFS的一个简化开源实现二者因此有很多相似之处。首先， GFS和HDFS都采用单一主控机+多台工作机的模式，由一台主控机(Master)存储 系
14、统全部元数据，并实现数据的分布、复制、备份决策，主控机还实现了元数据的 checkpoint和操作日志记录及回放功能。工作机存储数据，并根据主控机的指令进 行数据存储、数据迁移和数据计算等。其次，GFS和HDFS都通过数据分块和复制 (多副本，一般是3)来提供更高的可靠性和更高的性能。当其中一个副本不可用 时，系统都提供副本自动复制功能。同时，针对数据读多于写的特点，读服务被分 配到多个副本所在机器，提供了系统的整体性能。最后，GFS和HDFS都提供了一 个树结构的文件系统，实现了类似与Linux下的文件复制、改名、移动、创建、删 除操作以及简单的权限管理等。然而，GFS和HDFS在关键点的设
15、计上差异很大，HDFS为了规避GFS的复杂度进 行了很多简化。例如HDFS不支持并发追加和集群快照早期HDFS的NameNode (即Master)没原生HA功能。总之，HDFS基本可以认为是GFS的简化版，由 于时间及应用场景等各方面的原因对GFS的功能做了一定的简化，大大降低了复杂 度。2.5 HLFS(主要参考：HLFS( HDFS Log-structured File System)是一个开源分布式块存储系统，其最 大特色是结合了 LFS和HDFS。HDFS提供了可靠、随时可扩展的文件服务，而HLFS 通过Log-structured技术弥补了 HDFS不能随机更新的缺憾。在HLFS
16、中，虚拟 磁盘对应一个文件，文件长度能够超过TB级别，客户端支持Linux和Xen，其中 Linux基于NBD实现，Xen基于blktap2实现，客户端通过类POSIX接口 libHLFS 与服务端通讯。HLFS主要特性包括多副本、动态扩容、故障透明处理和快照。HLFS性能较低。首先，非原地更新必然导致数据块在物理上非连续存放，因此读 I/O比较随机，顺序读性能下降。其次，虽然从单个文件角度看来，写I/O是|1|顺序 的，但是在HDFS的Chunk Server服务了多个HLFS文件，因此从它的角度来看， I/O仍然是随机的。第三，写延迟问题，HDFS面向大文件设计，小文件写延时不 够优化。第
17、四，垃圾回收的影响，垃圾回收需要读取和写入大量数据，对正常写操 作造成较大影响。此外，按照目前实现，相同段上的垃圾回收和读写请求不能并发， 垃圾回收算法对正常操作的干扰较大。2.6 iSCSI. FCoE. AoE. NBDiSCSI、FCoE、AoE、NBD等都是用来支持通过网络访问块设备的协议，它们都采 用C/S架构，无法直接支持分布式块存储系统。Ursa的设计与实现分布式块存储系统给虚拟机提供的是虚拟硬盘服务，因而有如下设计目标： 大文件存储：虚拟硬盘实际通常GB级别以上，小于1GB是罕见情况需要支持随机读写访问，不需支持追加写，需要支持resize 通常情况下，文件由一个进程独占读写访
18、问；数据块可被共享只读访问 高可靠，高可用：任意两个服务器同时出现故障不影响数据的可靠性和可用性 能发挥出新型硬件的性能优势，如万兆网络、SSD 由于应用需求未知，同时需要优化吞吐率和IOPS 高效率：降低资源消耗，就降低了成本除了上述源于虚拟硬盘的直接需求意外，分布式块存储还需要支持下列功能： 快照：可给一个文件在不同时刻建立多个独立的快照 克隆：可将一个文件或快照在逻辑上复制成独立的多份 精简配置（thin-provisioning）:只有存储数据的部分才真正占用空间3.1系统架构分布式存储系统总体架构可以分为有maste（元数据服务器；和无master两大类。有master架构在技术上较
19、为简单清晰，但存在单点失效以及潜在的性能瓶颈问题； 无master架构可以消除单点失效和性能瓶颈问题，然而在技术上却较为复杂，并 且在数据布局方面具有较多局限性。块存储系统对master的压力不大同时master 的单点故障问题可采用一些现有成熟技术解决，因而美团EBS的总体架构使用有 master的类型。这一架构与GFS、HDFS、MooseFS等系统的架构属于同一类型。如图1所示，美团EBS系统包括M、S和C三个部分，分别代表Master、Chunk Server和Client。Master中记录的元数据包括3种：（1）关于volume的信息，如 类型、大小、创建时间、包含哪些数据chun
20、k等等；（2）关于chunk的信息，如大 小、创建时间、所在位置等；（3）关于Chunk Server的信息，如IP地址、端口、数 据存储量、I/O负载、空间剩余量等。这3种信息当中，关于volume的信息是持 久化保存的，其余两种均为暂存信息，通过Chunk Server上报。在元数据中，关于volume的信息非常重要，必须持久化保存；关于chunk的信息 和Chunk Server的信息是时变的，并且是由Chunk Server上报的，因而没必要 持久化保存。根据这样的分析，我们将关于volume的信息保存在MySQL当中， 其他元数据保存在Redis当中，余下的集群管理功能由Manage
21、r完成。Master = Manager + MySQL + Redis，其中MySQL使用双机主从配置，Redis使用官方 提供的标准cluster功能。3.2 CAP取舍C、A、P 分别代表 Consistency. Availability 和 Partition-tolerance。分布式系 统很难同时在这三个方面做到很高的保障，通常要在仔细分析应用需求的基础之上 对CAP做出取舍。块存储系统主要用于提供云硬盘服务，每块云硬盘通常只会挂载到1台VM之上， 不存在多机器并发读写的情况，因而其典型应用场景对一致性的需求较低。针对这 一特性，我们可以在设计上舍C而取AP。对于多机并行访问云硬
22、盘的使用模式，若数据是只读的则无需额外处理；若数据有 写有读，甚至是多写多读，则需要在上层引入分布式锁，来确保数据一致性和完整 性。这种使用模式在SAN领域并不少见，其典型应用场景是多机同时挂载一个网 络硬盘，并通过集群文件系统（而不是常见的单机文件系统）来协调访问存储空间。集群文件系统内部会使用分布式锁来确保数据操作的正确性，所以我们舍C的设计 决策不会影响多机并行访问的使用模式。3.3并发模型并发（不是并行！）模型的选择和设计无法作为实现细节隐藏在局部，它会影响到 程序代码的各个部分，从底层到上层。基本的并发模型只有这样几种：事件驱动、 多线程、多进程以及较为小众的多协程。事件驱动模型是一
23、种更接近硬件工作模式的并发模型，具有更高的执行效率，是高 性能网络服务的普遍选择。为能充分发挥万兆网络和SSD的性能潜力，我们必须利 用多核心并行服务，因而需要选用多线程或者多进程模型。由于多进程模型更加简 单，进程天然是故障传播的屏障，这两方面都十分有利于提高软件的健壮性；并且 我们也很容易对业务进行横向拆分，做到互相没有依赖，也不需要交互，所以我们 选择了多进程模型，与事件驱动一起构成混合模型。协程在现实中的应用并不多，很多语言/开发生态甚至不支持协程，然而协程在一些 特定领域其实具有更好的适用性。比如，QEMU/KVM在磁盘I/O方面的并发执行 完全是由协程负责的，即便某些block d
24、river只提供了事件驱动的接口（如Ceph RBD），QEMU/KVM也会自动把它们转化封装成多协程模式。实践表明，在并发 I/O领域，多协程模型可以同时在性能和易用性方面取得非常好的效果，所以我们 做了跟QEMU/KVM类似的选择在底层将事件驱动模型转换成了多协程模型， 最终形成了 多进程+多协程+事件驱动”的混合并发模型。3.4存储结构如图所示，Ursa中的存储结构与GFS/HDFS相似，存储卷由64MB （可配置）大 小的chunk组成。Ursa系统中的数据复制、故障检测与修复均在chunk层次进行。 系统中，每3个（可配置）chunk组成一组，互为备份。每2个chunk组构成一 个s
25、tripe组，实现条带化交错读写，提高单客户端III贿读写性能。Ursa在I/O栈 上层添加Cache模块，可将最常用的数据缓存在客户端本地的SSD介质当中，当 访问命中缓存时可大大提高性能。3.5写入策略最常见的写入策略有两种：(1)客户端直接写多个副本到各个Chunk Server,如图 (a)所示，Sheepdog采用此种办法；(2)客户端写第一个副本，并将写请求依次传 递下去，如图(b)所示。这两种方法各有利弊：前者通常具有较小的写入延迟，但吞 吐率最高只能达到网络带宽的1/3 ；后者的吞吐率可以达到100%网络带宽，却具 有较高的写入延迟。RepliesRepl teal w/ IW
26、RITE REPUCATEClient RcplicaiClientReplica?WHITERcpIicaZ ClientRcplical (primary)WHITER.cplica3Replies?RcplieaS(b)由于Ursa可能用于支持各种类型的应用，必须同时面向吞吐率和带宽进行优化， 所以我们设计采用了一种分叉式的写入策略：如图(c)所示，客户端使用 WRITE_REPLICATE请求求将数据写到第一个副本，称为primary，然后由primary 负责将数据分别写到其他副本。这样Ursa可以在吞吐率和延迟两方面取得较好的 均衡。为确保数据可靠性，写操作会等所有副本的写操作都完
27、成之后才能返回。3.6无状态服务Chunk Server内部几乎不保存状态通常情况下各个请求之间是完全独立执行的， 并且重启Chunk Server不会影响后续请求的执行。这样的Chunk Server不但具 有更高的鲁棒性，而且具有更高的扩展性。许多其他网络服务、协议的设计都遵循 了无状态的原则。3.7模块如下图所示，Ursa中的I/O功能模块的组织采用decorator模式，即所有模块都 实现了 IStore抽象接口其中负责直接与Chunk Server通信的模块属于decorator 模式中的concrete component，其余模块均为concrete decorator。所有的
28、decorator都保存数量不等的指向其他模块的指针（IStore指针）。在运行时，Ursa的I/O栈层次结构的对象图如下所示。3.8产品界面美团云账户余探厚牙，退出W云晰,E1瞿例 快甄0汗世 U/4i性能实测如下图所示测试环境由万兆以太网、1台Client和3台Chunk Server组成,chunk 文件存在tmpfs上，即所有写操作不落盘，写到内存为止。选择tmpfs主要是为了 避免硬盘的I/O速度的局限性，以便测试Ursa在极限情况下的表现。测试环境的网络延迟如下:七讷O0J4L t-imc=0,152 time=0.169 time=0.O3L time=0.117 time=0.
29、169(USmsIDSmsIDS在上述环境中，用fio分别测试了读写操作的吞吐率、IOPS以及I/O延迟，测试参 数与结果如下：从测试结果可以看出：(1). Ursa在吞吐率测试中可以轻易接近网卡理论带宽;(2) . Ursa的IOPS性能可以达到SSD的水准；(3) . Ursa的读延迟接近ping值，写操作需要写3个副本，延迟比读高68%。作为对比，我们在测试Ceph的过程中监测到服务端CPU占用情况如下:21282 root2017771 root2019448 root2018580 root2020392 root200 809m 80m0 802m 80m0 839m 79m0 8
30、24m 82m0 798m 77m11m S 37.4 0.110m S 27.8 0.110m S 27.1 0.110m S 26.5 0.110m S 13.9 0.16:38.88 ceph-osd 4:54.46 ceph-osd 6:42.14 c叩h-osd 5:52.29 ceph-osd4:02.15 ceph-osd1237% 4101 读IOPS此时机器上5个存储服务进程ceph-osd共占用123.7%的CPU资源提供了 4 101 的读IOPS服务；而Ursa的服务进程只消耗了 43%的CPU资源，提供了 61 340 读IOPS服务，运行效率比Ceph高43倍。在客
31、户端方面，Ceph消耗了 500%+ 的CPU资源，得到了 16 407读IOPS ；而Ursa只消耗了 96%的CPU资源，得到了 61 340读IOPS，运行效率比Ceph高21倍。总结与展望Ursa从零开始动手开发到内部上线只经历了 9个月的时间，虽然基本功能、性能都 已达到预期，但仍有许多需要进一步开发的地方。一个重要的方向是对SSD的支持。 虽然将HDD简单替换为SSD，不修改Ursa的任何代码、配置就可以运行，并取 得性能上的显著改善，然而SSD在性能、成本、寿命等方面与HDD差异巨大，Ursa 必须做出针对性的优化才能使SSD扬长避短。另一个重要方向是对大量VM同时启 动的更好的支持。如果同时有上百台相同的VM从Ursa启动(即系统盘放在Ursa 上)，会在短时间内有大量读请求访问相同的数据集(启动文件)，形成局部热点， 此时相关的Chunk Server服务能力会出现不足，导致启动变慢。由于各个VM所 需的启动数据基本相同，我们可以采用一传十，十传百”的方式组织一个应用层 组播树overlay网络来进行数据分发，这样可以从容应对热点数据访问问题。随着 一步步的完善，相信Ursa将在云平台的运营当中起到越来越重要的作用。
