从 OpenStack 的角度看块存储的世界

块存储，简单来说就是提供了块设备存储的接口。用户需要把块存储卷附加到虚拟机或者裸机上以与其交互。这些卷都是持久的：它们可以从运行实例上被解除或者重新附加而数据保持完整不变。

本文重点介绍块存储服务。我们对目前主流的块存储服务提供商和开源的块存储软件做了一个简要分析，希望能给从事块存储开发的工程师对于块存储一个全局的认识。

下面会先介绍常见的单机块设备工具，以建立对块存储的初步印象。

单机块存储

首先，一个硬盘是一个块设备。内核检测到硬盘后，在 /dev/ 下会看到 /dev/sda/。为了用一个硬盘来得到不同的分区来做不同的事，我们使用 fdisk 工具得到 /dev/sda1、/dev/sda2 等。这种方式通过直接写入分区表来规定和切分硬盘，是最死板的分区方式。

1. LVM & Device-mapper

LVM 是一种逻辑卷管理器。通过 LVM 来对硬盘创建逻辑卷组和得到逻辑卷，要比 fdisk 方式更加弹性。如果你目前对 LVM 用途还不熟悉或者不大清楚，可参考以下链接：

• 通用线程：学习 Linux LVM，第 1 部分
• 通用线程：学习 Linux LVM，第 2 部分

LVM 基于 Device-mapper 用户程序实现。Device-mapper 是一种支持逻辑卷管理的通用设备映射机制，为存储资源管理的块设备驱动提供了一个高度模块化的内核架构。以下链接对 Device-mapper 架构进行了极好的说明：

• Linux 内核中的 Device Mapper 机制

2. SAN & iSCSI

在接触了单机下的逻辑卷管理后，你需要了解 SAN ，目前主流的企业级存储方式。

大部分 SAN 使用 SCSI 协议在服务器和存储设备之间传输和沟通，通过在 SCSI 之上建立不同镜像层，可以实现存储网络的连接。常见的有 iSCSI ， FCP ， Fibre Channel over Ethernet 等。

SAN 通常需要在专用存储设备中建立，而 iSCSI 是基于 TCP/IP 的 SCSI 映射，通过 iSCSI 协议和 Linux iSCSI 项目，我们可以在常见的 PC 机上建立 SAN 存储。

对于如何建立在 PC 机上的 SAN，可以参考：

• iSCSI 建立

不过，这篇文章提到的 iSCSI target 管理方式不太方便，通常我们会用 targetcli 管理 target。targetcli 可以直接建立和管理不同 backstone 类型的逻辑卷和不同的 export 方式，如建立 ramdisk 并且通过 iSCSI export，非常方便。操作方式见 targetcli screencast Part 2 of 3: ISCSI – YouTube 。

以上都是我们经常接触的单机块存储。接下来是本文主要分享的内容：公共云技术服务提供的块存储服务，开源的块存储框架，以及 OpenStack 目前对块存储的定义和支持情况。

分布式块存储

在面对极具弹性的存储需求和性能要求下，单机或者独立的 SAN 越来越不能满足企业的需要。如同数据库系统一样，块存储在 scale up 的瓶颈下也面临着 scale out 的需要。我们可以用以下几个特点来描述分布式块存储系统的概念：

1. 分布式块存储可以为任何物理机或者虚拟机提供持久化的块存储设备
2. 分布式块存储系统管理块设备的创建、删除和 attach/detach
3. 分布式块存储支持强大的快照功能，快照可以用来恢复或者创建新的块设备
4. 分布式存储系统能够提供不同 IO 性能要求的块设备

3.1 Amazon EBS

Amazon 作为领先的 IaaS 服务商，其 API 目前是 IaaS 的事实标准。Amazon EC2 目前在大多数方面远超其他 IaaS 服务商。Amazon EC2 的产品介绍是快速了解Amazon EC2 的捷径。

EBS 是 Amazon 提供的块存储服务。通过 EBS，用户可以随时增删迁移 volume 和快照操作。

Amazon EC2 实例可以将根设备数据存储在 Amazon EBS 或者本地实例存储上。使用 Amazon EBS 时，根设备中的数据将独立于实例的生命周期保留下来，使得在停止实例后仍可以重新启动使用，与笔记本电脑关机并在再次需要时重新启动相似。另一方面，本地实例存储仅在实例的生命周期内保留。这是启动实例的一种经济方式，因为数据没有存储到根设备中。

Amazon EBS 提供两种类型的卷，即标准卷和预配置 IOPS 卷。它们的性能特点和价格不同，可以根据应用程序的要求和预算定制所需的存储性能。

标准卷可为要求有适度或突发式 I/O 的应用程序提供存储。这些卷平均可以提供大约 100 IOPS，最多可突增至数百 IOPS。标准卷也非常适合用作引导卷，其突发能力可提供快速的实例启动时间（通常十几秒）。

预配置 IOPS 卷旨在为数据库等 I/O 密集型随机读写工作负载提供可预计的高性能。创建一个卷时，利用预置 IOPS 为卷确定 IOPS 速率，随之 Amazon EBS 在该卷的生命周期内提供该速率。Amazon EBS 目前支持每预配置 IOPS 卷最多 4000 个 IOPS。您可以将多个条带式卷组合在一起，为应用程序提供每个 Amazon EC2 数千 IOPS 的能力。

EBS 可以在卷连接和使用期间实时拍摄快照。不过，快照只能捕获已写入 Amazon EBS 卷的数据，不包含应用程序或操作系统已在本地缓存的数据。如果需要确保能为实例连接的卷获得一致的快照，需要先彻底地断开卷连接，再发出快照命令，然后重新连接卷。

EBS 快照目前可以跨 regions 增量备份，意味着 EBS 快照时间会大大缩短，从另一面增加了 EBS 使用的安全性。

总的来说，Amazon EBS 是目前 IaaS 服务商最引入注目的服务之一，目前的 OpenStack、CloudStack 等其他开源框架都无法提供 Amazon EBS 的弹性和强大的服务。了解和使用 Amazon EBS 是学习 IaaS 块存储的最好手段。

3.2 阿里云存储

阿里云是国内的公共云计算服务商。阿里云磁盘目前仅支持在创建云主机的时候绑定云磁盘或者在升级云主机的进行云磁盘扩容，这从根本上就是传统的虚拟主机的特点而不是所谓的“云磁盘”。

从目前的阿里云磁盘的限制：

1. 无法快速创建或删除 volume，在进行扩容时需要升级云主机才能达到，而升级云主机只有在下月云主机套餐到期时才能生效（中国移动套餐的模式）
2. 一个云主机最多只能绑定 3 个云磁盘

从阿里云磁盘目前的使用分析，以下是我对阿里云磁盘实现的推测：

1. 阿里云主机是跟磁盘绑定的，这意味着阿里云的云磁盘是 local volume（因此性能还是挺可观的）。用户需要扩容、减少都需要下个月更说明了这点，整个主机在扩容时去调度合适的有足够存储空间的 host，然后进行扩容。
2. 阿里云磁盘是分布式块存储系统，但是由于其 QoS 无法保证和其他资源调度原因，无法提供足够的块存储支持。

从演讲回顾：阿里云存储技术的演进，以及云服务用例最佳实践中了解到阿里云是基于自家的“盘古”系统，那么从实际使用来说，远没达到一般的分布式块存储系统的要求。

4.1 Ceph

Ceph 是开源实现的 PB 级分布式文件系统，其分布式对象存储机制为上层提供了文件接口、块存储接口和对象存储接口。 Inktank 是 Ceph 的主要支持商，也是目前 Ceph 开源社区的主要力量。

Ceph 目前是 OpenStack 的开源块存储实现系统（即 Cinder 项目的 backend driver 之一），其实现分为三个部分: OSD，Monitor，MDS。OSD 是底层对象存储系统，Monitor 是集群管理系统，MDS 是用来支持 POSIX 文件接口的 Metadata Server。从 Ceph 的原始论文《 Ceph: Reliable, Scalable, and High-Performance Distributed Storage 》来看，Ceph 专注于扩展性，高可用性和容错性。Ceph 放弃了传统的 Metadata 查表方式（HDFS）而改用算法（CRUSH）去定位具体的 block。

利用 Ceph 提供的 RULES 可以弹性地制订存储策略和 Pool 选择，Monitor 作为集群管理系统掌握了全部的 Cluster Map，Client 在没有 Map 的情况下需要先向 Monitor 请求得到，然后通过 Object id 计算相应的 OSD Server。

Ceph 的文档可以参考以下链接：

• Ceph：一个 Linux PB 级分布式文件系统
• 分布式文件系统 Ceph 调研 1 – RADOS
• Ceph Architecture
• Ceph 的现状
• ceph 的 CRUSH 数据分布算法介绍
• Ceph INTERNAL DEVELOPER DOCUMENTATION

Ceph 支持传统的 POSIX 文件接口，因此需要额外的 MDS（Meatadata Server）支持文件元信息（Ceph 的块存储和对象存储支持不需要 MDS 服务）。Ceph 将 Data 和 Metadata 分离到两个服务上，跟传统的分布式系统如 Lustre 相比可以大大增强扩展性。在小文件读写上，Ceph 读写文件会有 [RTT*2]，在每次 open 时，会先去 Metadata Server 查询一次，然后再去 Object Server。除了 Open 操作外，Ceph 在 Delete 上也有问题，它需要到 Metadata Server 擦除对应的 Metadata，是 n(2) 复杂度。Ceph 在 Metadata 上并非只有坏处，通过 Metadata Server，像目录列表等目录操作为非常快速，远超 GlusterFS 等其他分布式文件系统的目录或文件元操作。

如果要用 Ceph 作为块存储项目，有几个问题需要考虑：

1. Ceph 在读写上不太稳定（有 btrfs 的原因）。目前 Ceph 官方推荐 XFS 作为底层文件系统
2. Ceph 的扩展性较难，如果需要介入 Ceph，需要较长时间
3. Ceph 的部署不够简易并且集群不够稳定

4.2 Sheepdog

Sheepdog 是另一个分布式块存储系统实现。与 Ceph 相比，它的最大优势就是代码短小好维护，hack 的成本很小。Sheepdog 也有很多 Ceph 不支持的特性，比如说 Multi-Disk, Cluster-wide Snapshot 等。

Sheepdog 主要有两部分，一个是集群管理，另一个是存储服务。集群管理目前使用 Corosync 或者 Zookper 来完成，其存储服务的特点是在 client 和存储 host 有 Cache 的实现可以大大减小数据流量。

目前 Sheepdog 只在 QEMU 端提供 Drive，而缺少 library 支持，这是 Sheepdog 目前最主要的问题。但是社区已经有相关的 Blueprint 在讨论这个问题。

了解 Sheepdog 的一些相关资料：

• Sheepdog Overview
• Sheepdog 淘宝核心系统团队
• Sheepdog wiki ：Sheepdog 的一系列 Wiki 如同它的代码一样简短出色

目前 Taobao 是 Sheepdog 主要用户和社区贡献者。

5. Cinder

OpenStack 是目前流行的 IaaS 框架，提供了与 AWS 类似的服务并且兼容其 API。OpenStack Nova 是计算服务，Swift 是对象存储服务，Quantum 是网络服务，Glance 是镜像服务，Cinder 是块存储服务，Keystone 是身份认证服务，Horizon 是 Dashboard，另外还有 Heat、Oslo、Ceilometer、Ironic 等等项目。

OpenStack 的存储主要分为三大类：

• 对象存储服务，Swift
• 块设备存储服务，主要是提供给虚拟机作为“硬盘”的存储。这里又分为两块：
  • 本地块存储
  • 分布式块存储，Cinder
• 数据库服务，目前是一个正在孵化的项目 Trove，前身是 Rackspace 开源出来的 RedDwarf，对应 AWS 里面的 RDC。

Cinder 是 OpenStack 中提供类似于 EBS 块存储服务的 API 框架。它并没有实现对块设备的管理和实际服务，而是为后端不同的存储结构提供了统一的接口，不同的块设备服务厂商在 Cinder 中实现其驱动支持以与 OpenStack 进行整合。后端的存储可以是 DAS，NAS，SAN，对象存储或者分布式文件系统。也就是说，Cinder 的块存储数据完整性、可用性保障是由后端存储提供的。在 CinderSupportMatrix 中可以看到众多存储厂商如 NetAPP、IBM、SolidFire、EMC 和众多开源块存储系统对 Cinder 的支持。

从上图我们也可以看到，Cinder 只是提供了一层抽象，然后通过其后段支持的 driver 实现来发出命令来得到回应。关于块存储的分配信息以及选项配置等会被保存到 OpenStack 统一的 DB 中。

总结

目前分布式块存储的实现仍然是由 Amazon EBS 领衔，其卓越稳定的读写性能、强大的增量快照和跨区域块设备迁移，以及令人惊叹的 QoS 控制都是目前开源或者其他商业实现无法比拟的。

不过 Amazon EBS 始终不是公司私有存储的一部分，作为企业 IT 成本的重要部分，块存储正在发生改变。EMC 在一个月前发布了其 ViPR 平台，并开放了其接口，试图接纳其他厂商和开源实现。Nexenta 在颠覆传统的的存储专有硬件，在其上软件实现原来只有专有 SDN 的能力，让企业客户完全摆脱存储与厂商的绑定。Inktank 极力融合 OpenStack 并推动 Ceph 在 OpenStack 社区的影响力。这些都说明了，无论是目前的存储厂商还是开源社区都在极力推动整个分布式块存储的发展，存储专有设备的局限性正在进一步弱化了原有企业的存储架构。

在分布式块存储和 OpenStack 之间，我们可以打造更巩固的纽带，将块存储在企业私有云平台上做更好的集成和运维。

作者简介

王豪迈，UnitedStack 工程师。本文根据作者的博客文章《块存储的世界（入门级）》修改而成。