基于 Ceph 对象存储构建实践

一、存储发展

数据存储是人类永恒的话题和不断探索的主题

• 绳结记事

  原始社会，文字未发明之前 ，人们所使用的一种记事方法，在绳子上打结记事。

• 穿孔卡

  穿孔卡片是始于 20 世纪的主要存储方法，也是最早的机械化信息存储形式，进入 20 世纪 60 年代后，逐渐被其他存储手段取代。目前穿孔卡片已经极少使用，除非用于读出当年存储的历史数据。

• 磁鼓存储器

  20 世纪 50 年代，磁鼓作为内存储器应用于 IBM 650。在后续的 IBM 360/91 和 DEC PDP-11 中，磁鼓也用作交换区存储和页面存储。磁鼓的代表性产品是 IBM 2301 固定头磁鼓存储器。磁鼓是利用铝鼓筒表面涂覆的磁性材料来存储数据的。鼓筒旋转速度很高，因此存取速度快。它采用饱和磁记录，从固定式磁头发展到浮动式磁头，从采用磁胶发展到采用电镀的连续磁介质。这些都为后来的磁盘存储器打下了基础。

  磁鼓最大的缺点是存储容量太小。一个大圆柱体只有表面一层用于存储，而磁盘的两面都可用来存储，显然利用率要高得多。因此，当磁盘出现后，磁鼓就被淘汰了。

• 磁带

  磁带是从 1951 年起被作为数据存储设备使用的，磁带是所有存储媒体中单位存储成本最低、容量最大、标准化程度最高的常用存储介质之一。从 20 世纪 70 年代后期到 80 年代出现了小型的盒式磁带，长度为 90 分钟的磁带每一面可以记录大约 660KB 的数据。

• 软盘

  软盘发明于 1969 年，直径是 8 英寸，单面容量 80KB。4 年后，5.25 英寸、容量为 320KB 的软盘诞生了。软盘的发展趋势是盘片直径越来越小，而容量却越来越大，可靠性也越来越高。图 2-10 是三种典型的软盘，其中 a 为不同外观尺寸的软盘，b 中 3.5 英寸软盘的容量为 1.44MB，曾经作为主要的移动存储介质被广泛使用。到了 20 世纪 90 年代后期，出现了容量为 250MB 的 3.5 英寸软盘产品，但由于兼容性、可靠性、成本等原因，并未被广泛使用，如今已难寻踪迹。

• 光盘

  早期光盘主要用于电影行业，第一张光盘于 1987 年进入市场， 直径为 30cm，每一面可以记录 60 分钟的音视频。

• 硬盘存储器

  第一款硬盘驱动器是 IBM Model 350 Disk File， 于 1956 年制造，包含了 50 张 24 英寸的盘片，总容量不到 5MB，机械硬盘发展至今，单盘容量已经超过 16T 了 。

二、存储的三种方式

2.1 块存储

2.1.1 DAS

直接附加存储（Directed Attached Storage，DAS） 作为一种最简单的外接存储方式，通过数据线直接连接在各种服务器或客户端扩展接口上。它本身是硬件的堆叠，不带有任何存储操作系统，因而也不能独立于服务器对外提供存储服务。DAS 常见的形式是外置磁盘阵列，通常的配置就是 RAID 控制器 + 一堆磁盘。DAS 方便安装、成本较低的特性使其特别适合于对存储容量要求不高、服务器数量较少的中小型数据中心。

2.1.2 SAN

存储区域网络（Storage Area Network，简称 SAN），SAN 默认指 FC-SAN，SAN 存储有两种结构：

1. FC-SAN

   典型的 SAN 利用光纤通道（Fiber Channel，FC）技术连接节点，并使用光纤通道交换机（FC Switch）提供网络交换。不同于通用的数据网络，存储区域网络中的数据传输基于 FC 协议栈。在 FC 协议栈之上运行的 SCSI 协议提供存储访问服务。与之相对的 iSCSI 存储协议，则提供了一种低成本的替代方式，即将 SCSI 协议运行于 TCP/IP 协议栈之上。为了区别这两种存储区域网络，前者通常称为 FC-SAN，后者称为 IP-SAN。

2. IP-SAN

   由于 FC-SAN 的高成本，人们就开始考虑构建基于以太网技术的存储网络，使得的 iSCSI 可以实现在 IP 网络上运行 SCSI 协议。但是在 SAN 中，传输的指令是 SCSI 的读写指令，不是 IP 数据包。iSCSI（互联网小型计算机系统接口）是一种在 TCP/IP 上进行数据块传输的标准。它是由 Cisco 和 IBM 两家发起的，并且得到了各大存储厂商的大力支持。iSCSI 可以实现在 IP 网络上运行 SCSI 协议，使其能够在诸如高速千兆以太网上进行快速的数据存取备份操作。为了与之前基于光纤技术的 FC-SAN 区分开来，这种技术被称为 IP-SAN。

优点

• 高性能，集中化的管理，稳定性和安全性得到保障

缺点

• 成本昂贵，磁盘阵列的兼容性限制了设备选择空间及资源共享

2.2 NAS 存储

Network Attached Storage 网络附加存储，采用 NFS 或 CIFS 协议访问数据，以文件为传输协议，通过 TCP/IP 实现网络化存储，可扩展性好、价格便宜、用户易管理，如目前在集群计算中应用较多的 NFS 文件系统。

优点

• 造价成本低，有一个服务器，装上网络文件存储软件，就可以提供给其他服务器挂载访问。
• 文件级的数据共享

缺点

• 读写速率低

2.3 对象存储

块存储读写快、不利于数据共享，文件存储数据共享方便、但是读写慢，能否弄一个读写快而且可以共享数据的存储，于是对象存储就诞生了。块存储和文件存储是我们比较熟悉的两种主流的存储类型，而对象存储（Object-based Storage）是一种新的网络存储架构。

2.3.1 3 个核心概念

1、对象

对象是对象存储中的最小单元，比如照片就是一个对象，对象由元数据信息 (MataData，包含 Length，lastModify 等），用户数据 (Data)，用户自定义的数据信息（拍摄者、拍摄设备等）和文件名（Key）组成。

2、存储桶

作为存放对象的容器

3、用户

对象存储的使用者，存储桶的拥有者，每个用户使用 AccessKeyId 和 SecretAccessKey 对称加密的方法来验证某个请求的发送者身份。

2.3 对象存储适合存什么

用来存海量非结构化数据的，对象存储将数据以对象的方式存储，而不是以传统的文件和数据块的形式存储，每个对象都要存储数据、元数据和一个唯一的标识符。

• 图片
• 视频
• 音频
• 文档
• 代码 js/html

缺点

• 应用代码需要改动，无法修改对象，需要一次性完整写入

优点

• 无限扩容

三、基于 Ceph 的对象存储构建实践

3.1 什么是 Ceph

加州大学 Santa Cruz 分校的 Sage Weil(DreamHost 的联合创始人) 博士论文设计的新一代自由软件分布式文件系统。软件定义存储 (Software Defined Storage, SDS)，统一的存储解决方案，提供了三种存储方式：块存储、文件存储、对象存储。Ceph 的架构如下：

3.2 Ceph 组件

• Ceph Monitor(监视器，简称 Mon)

  Mon 通过保存一份集群状态映射来的维护整个集群的健康状态。它分别为每个组件维护映射信息。所有集群节点都向 Mon 节点汇报状态信息。

• RADOS

  (Reliable Autonomix Distributed Object Store)，是存储集群的基础。在 Ceph 中所有的数据都是以对象的形式存储，RADOS 就负责存这些数据，不考虑它们的类型。

• Ceph 对象存储设备 OSD

  Ceph 分布式对象存储系统的对象存储守护进程。它负责把对象存储到本地文件系统，并使之通过网络可访问。

• RADOS 网关 (RGW)

  提供了兼容 Amazon S3 和 OpenStack 对象存储 API(Swift) 的 restful API 接口。支持多租户和 OpenStack Keystone 身份验证。

• MDS(Ceph 元数据服务器)

  为 CephFS 跟踪文件层次结构和存储元数据。

• librados

  librados 库为 PHP，Ruby，Java，Python，C 和 C++ 这些编程语言提供了方便地访问 RADOS 接口的方式。

• RBD(RADOS 块设备)

  Ceph 块设备，原名是 RADOS 块设备，提供可靠的分布式和高性能块存储磁盘给客户端，将块数据以顺序条带化的形式分散存储在的多个 OSD 上，支持自动精简配置、动态调整大小、完整和增量快照、写实复制克隆等企业级特性，而且 RBD 服务已经被封装成了基于 librados 的一个原生接口。

• CephFS(Ceph Filesystem)

  Ceph 文件系统提供了一个使用 Ceph 存储集群存储用户数据的与 POSIX 兼容的文件系统。和 RBD、RGW 一样，基于 librados 封装了原生接口。

3.3 Ceph 的特点

• 高性能

  摒弃了传统的集中式存储元数据寻址的方案，采用 CRUSH 算法，数据分布均衡，并行度高

• 高可用性

  数据强一致性，多种故障场景自愈

• 高扩展性

  去中心化、灵活扩展

• 特性丰富

  支持三种存储接口：块存储、对象存储、文件存储

  支持多种语言（Python、C++、Java、PHP、Ruby 等）驱动，自定义接口

3.4 基于 Ceph 的对象存储实践

客户端通过 4，7 层负载均衡，基于 HTTP 协议，将请求转发至对象存储网关（Rados GateWay）, 对象存储网关通过 Sockets 与集群通信，至此，完成了整个数据的传输。

3.5 用户认证

1. 应用在发送请求前，使用用户私有秘钥（secret key）、请求内容等，采用与 RGW 网关约定好的算法计算出数字签名 后，将数字签名以及用户访问秘钥 access_key 封装在请求中发送给 RGW 网关
2. RGW 网关接受到请求后，使用用户访问秘钥作为索引送 RADOS 集群中读取用户信息，并从用户信息中获取到用户私有秘钥。
3. 使用用户私有秘钥、请求内容等，采用与应用约定好的算法计算数字签名。
4. 判断 RGW 生成的数字签名和请求的签名是否匹配，如果匹配，则认为请求是真实的，用户认证通过，如果匹配返回 S3 error: 403 (SignatureDoesNotMatch)

3.6 对象存储 IO 路径分析

应用通过 http 协议将请求发送至对象存储网关，网关收到 I/O 请求后，从 http 语义中解析出 S3 或 Swift 数据并进行一系列检查，检查通过后，根据不同 API 操作请求执行不同的数据处理逻辑，通过 librados 接口从 RADOS Cluster 中 GET 或者 PUT 数据，完成整个 I/O 过程。

本文转载自公众号宜信技术学院（ID：CE_TECH）。

原文链接：

https://mp.weixin.qq.com/s/oukM46o5j7gy9bL9nI8u3A