[Practice] Ceph distributed create high performance and high reliability storage system based block

Block storage system

Distributed Storage has excellent performance, you can carry a lot of failure, can be easily extended, so we use Ceph build high-performance, highly reliable block storage system and use it to support public cloud cloud hosting and cloud hosting, cloud hard drive service.

Due to the use of distributed block storage system, avoiding the process of copying the mirror, so the time to create a cloud host can be shortened to less than 10 seconds, and rapid thermal cloud host can migrate to facilitate the operation and maintenance personnel on the physical server hardware and software maintain.

For the most intuitive user experience from cloud block storage system hard disk service, now our cloud hard drive is characterized by:

• Each support 6000 IOPS the cloud and the maximum hard disk 170 MB / s throughput, 95% in 4K random write operation delay is less than 2ms.
• All data are three copies, strong consistency, durability of up to 10 9.
• Create, delete, mount, unload all second-level operations.
• Real-time snapshot.
• Cloud provides two types of hard disks, and the performance displacement type.

Hardware and software configurations

After several rounds of selection and testing, and stepped on numerous pits after we chose our software and appropriate hardware.

software

hardware

• From disk to SATA SSD, in order to improve and reduce IOPS Latency.
• SSD from consumer to enterprise-class SSD, in order to improve reliability.
• From RAID HBA card to card, in order to improve and reduce IOPS Latency.

 

The minimum deployment architecture

As adjust demand to upgrade hardware and software, we are constantly in evolution deployment architecture, and strive to achieve the best balance of cost, performance and reliability.

Deployment minimum size of 12 nodes, there are three on each node SSD. There are two Gigabit ports and one gigabit ports, virtual machine network and storage network using Gigabit port on a node, the management network Gigabit port. Each cluster node has three Ceph Monitor.

Easy expansion

Benefits of cloud computing is a highly scalable, cloud computing as the underlying architecture, also we need to have a quick Scale-out capacity. In the deployment architecture block storage system can be extended in units of 12 sets of nodes.

 

OpenStack transformation

Native OpenStack does not support unified storage, cloud hosting services Nova, mirroring service Glance, hard disk back-end storage cloud service Cinder vary, causing serious internal friction. We put three back-end services to unify, efficient management, to solve the virtual machine creation and long-time mirroring storms and other issues, but also allows the virtual machine just drift.

Virgin OpenStack

改造后的OpenStack

 使用原生的OpenStack创建虚拟机需要1~3分钟，而使用改造后的OpenStack仅需要不到10秒钟时间。这是因为nova-compute不再需要通过HTTP下载整个镜像，虚拟机可以通过直接读取Ceph中的镜像数据进行启动。

我们还增加两个OpenStack没有的功能: QoS 和 共享云硬盘。云计算的另外一个好处是租户资源隔离，所以必备QoS。共享云硬盘可以挂载给多台云主机，适用于数据处理的场景。

我们还使用了OpenStack的multi-backend功能，支持多种云硬盘类型，现在我们的云硬盘类型有性能型、容量型，可以满足数据库和大文件应用。

 

高性能

存储系统主要的性能指标是IOPS和Latency。我们对于IOPS的优化已经达到了硬件的瓶颈，除非更换更快的固态硬盘或者闪存卡，或者是改变整个架构。我们对于Latency的优化也快接近完成，可以达到企业级存储的水平。

 

复杂的I/O栈

整个块存储系统有着长长的I/O栈，每个I/O请求要穿过很多线程和队列。

 

优化操作系统

优化操作系统的参数可以充分利用硬件的性能。

• CPU
  • 关闭CPU节能模式
  • 使用Cgroup绑定Ceph OSD进程到固定的CPU Cores上
• Memory
  • 关闭NUMA
  • 设置vm.swappiness=0
• Block
  • 设置SSD的调度算法为deadline
• FileSystem
  • 设置挂载参数”noatime nobarrier”

优化Qemu

Qemu作为块存储系统的直接消费者，也有很多值得优化的地方。

• Throttle: 平滑的I/O QoS算法
• RBD: 支持discard和flush
• Burst: 支持突发请求
• Virt-scsi: 支持多队列

优化Ceph

我们对于Ceph的优化是重头戏，有很多问题也是时间长、规模上去之后才暴露出来的。

 

高可靠性

存储需要高可靠性，保证数据可用并且数据不丢失。因为我们的架构中没有使用UPS和NVRAM，所以写请求的数据都是落到三块硬盘之后才返回，这样最大限度地保证了用户的数据安全。

如何计算持久性

持久性是数据丢失的概率，可以用于度量一个存储系统的可靠性，俗称 “多少个9”。数据的放置(DataPlacement)决定了数据持久性，而Ceph的CRUSH MAP又决定了数据的放置，因此CRUSH MAP的设置决定了数据持久性。但是，即时我们知道需要修改CRUSH MAP的设置，但是我们应该怎么修改CRUSH MAP的设置呢，我们该如何计算数据持久性呢？

我们需要一个计算模型和计算公式，通过以下资料，我们可以构建一个计算模型和计算公式。

• Reliability model
• 《CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data》
• 《Copysets: Reducing the Frequency of Data Loss in Cloud Storage》
• 《Ceph的CRUSH数据分布算法介绍》

最终的计算公式是： P = func(N, R, S, AFR)

• P: 丢失所有副本的概率
• N: 整个Ceph Pool中OSD的数量
• R: 副本数
• S: 在一个Bucket中OSD的个数
• AFR: 磁盘的年平均故障率

这个计算模型是怎么样得到计算公式的呢？下面是4个步骤。

1. 先计算硬盘发生故障的概率。
2. 定义哪种情况下丢失数据不能恢复。
3. 计算任意R个OSD发生故障的概率。
4. 计算Ceph丢失PG的概率。

硬盘发生故障的概率是符合泊松分布的：

• fit =   failures in time = 1/MTTF ~= 1/MTBF = AFR/(24*365)
• 事件概率 Pn(λ,t) = (λt)n e-λt / n!

Ceph的每个PG是有R份副本的，存放在R个OSD上，当存有这个PG的R个OSD都发生故障时，数据是不可访问的，当这R个OSD都损坏时，数据是不可恢复的。

计算一年内任意R个OSD发生相关故障概率的方法是：

1. 计算一年内有OSD发生故障的概率。
2. 在Recovery时间内，(R-1)个OSD发生故障的概率。
3. 以上概率相乘，就是一年内任意R个OSD发生相关故障概率，假设是 Pr。
4. N个OSD中，任意R个OSD的组合数是C(R, N)。

因为这任意R个OSD不一定存有同一个PG的副本，所以这任意R个OSD发生故障并不会导致数据不可恢复，也就是不一定会导致数据丢失。

假设每个PG对应一组OSD(有R个OSD， 称之为Copy Set)，有可能多个PG对应同一组OSD。假设有M个不同的Copy Set， M是一个非常重要的数字。

我们再来对Copy Set进行精确的定义：Copy Set上至少有一个PG的所有副本，当这个Copy Set损坏时，这个PG的所有副本也会丢失，这个PG上的所有数据就不可恢复。所以Ceph丢失数据的事件就是Ceph丢失PG， Ceph丢失PG就是有一个Copy Set发生损坏，一个Copy Set丢失的概率就是 P = Pr * M / C(R, N) 。

持久性公式就是个量化工具，它可以指明努力的方向。我们先小试牛刀，算一下默认情况下的持久性是多少？

假设我们有3个机架，每个机架上有8台节点，每个几点上有3块硬盘，每个硬盘做一个OSD，则一共有72个OSD。

默认的crush map设置如下所示

通过持久性公式，我们得到下面的数据。

默认情况下，持久性有8个9，已经比一般的RAID5、RAID10要高，和RAID6差不多，但是还不能满足公有云的要求，因为公有云的规模很大，故障事件的数学期望也会很大，这就逼着我们尽量提高持久性。

提高持久性的方法有很多，比如增加副本数，使用Erase Code等。不过这些方法都有弊端，增加副本数势必会扩大成本；使用Erase Code会导致Latency提高，不适合于块存储服务。在成本和Latency的制约下，还有什么办法可以提高持久性呢？

前面我们已经得到一个量化公式 P = Pr * M / C(R, N)， 我们从量化公式入手，去提高持久性(也就是降低P)。要想降低P， 就得降低Pr、M，或者是提高C(R, N)。因为C(R, N)已经确定，我们只能降低Pr和M。

 

降低恢复时间

从Pr的定义可以知道Pr与恢复时间有关，恢复时间越短，Pr的值越低。那么恢复时间跟什么有关系呢？

我们需要增加更多的OSD用于数据恢复，以便减少恢复时间。目前host bucket不能增加更多的OSD，这是因为主机的网络带宽限制和硬盘插槽限制。解决办法是从CRUSH MAP入手，增加一种虚拟的Bucket: osd-domain， 不再使用host bucket。

通过使用osd-domain bucket，我们把持久性提高了10倍，现在持久性有9个9。

 

减少Coepy Set个数

如何减少Copy Set的个数呢？Copy Sets是和PG的映射有关的，我们从CRUSH MAP的规则和条件入手，减少Copy Set的个数。解决办法增加虚拟的Bucket: replica-domain， 不再使用rack bucket。每个PG必须在一个replica-domain上，PG不能跨replica-domain，这样可以显著减少Copy Set的个数。

通过使用replica-domain，现在的持久性有10个9，持久性比默认的crush map设置提高了100倍。

 

自动化运维

Ceph的运维比较费心，稍有差池，整个云平台都会受到影响，因此我们觉得运维的目标是可用性：

减少不必要的数据迁移，进而减少slow requests，保证SLA。

部署

我们整个云平台都是使用Puppet部署的，因此我们使用了Puppet去部署Ceph。一般Ceph的安装是分阶段的：

1. 安装好Ceph Monitor集群。
2. 格式化Disk，使用文件系统的UUID去注册OSD， 得到OSD ID。
3. 根据OSD ID去创建数据目录，挂载Disk到数据目录上。
4. 初始化CRUSH MAP。

Puppet只需要完成前三步，第四步一般根据具体情况用脚本去执行。因为OSD ID是在执行过程中得到的，而Puppet是编译后执行，这是一个悲伤的故事，所以puppet-ceph模块必须设计成retry的。

相比eNovance和Stackforge的puppet-ceph模块，我们的puppet-ceph模块的优点是：

• 更短的部署时间
• 支持Ceph所有的参数
• 支持多种硬盘类型
• 使用WWN-ID替代盘符。

 

维护

升级Ceph的过程很简单，三条命令就可以搞定：

1. ceph osd set noout    #避免在异常情况下不可控
2. ceph osd down x        #提前mark down， 减少slow request
3. service ceph restart osd.x

更换硬件或者升级内核时需要对机器进行重启，步骤也很简单:

1. 把这台机器上的虚拟机迁移到其他机器上
2. ceph osd set noout
3. ceph osd down x    #把这个机器上的OSD都设置为down状态
4. service ceph stop osd.x
5. 重启机器

扩展集群的时候需要非常小心，因为它会触发数据迁移：

1. 设置crush map
2. 设置recovery options
3. 在凌晨12点触发数据迁移
4. 观察数据迁移的速度，观察每个机器上网口的带宽，避免跑满
5. 观察slow requests的数量

你总会碰到硬盘损坏的时候，替换硬盘时需要非常小心，你要小心的设置crush map，你要保证要替换硬盘过程中replica-domain的weight的值是不变的，这样才能保证不必须要的数据迁移。

 

监控

Ceph own Calamari looks good, but not practical, and it's deployment package is not perfect, there are some on CentOS BUG, ​​we can only continue to use the original tool.

• Collection: Use diamond, adding new colloctor, for collecting more detailed data.
• Save: Use graphite, set up collection and preservation precision accuracy.
• Display: Use grafana, pick a dozen tools, we found or grafana pretty easy to use.
• 报警：zabbix agent && ceph health

According to our Ceph software architecture is divided into a number of layers for each throttle OSD, the following is a throttle model:

With the throttle model, we can monitor each throttle, we added a new collector on the diamond for the throttle to monitor and redefine the metric name.

Finally, we can get monitoring data for each of the OSD each throttle. But usually only concern IOPS, throughput, OSD Journal delay, delay a read request, capacity utilization and the like.

accident

On the cloud platform line has been almost a year, we meet the size of the accident are:

• SSD GC problems can cause read and write requests Latency is very large, it had risen to several hundred milliseconds.
• Network failure will cause the Monitor OSD set down state.
• Ceph Bug, OSD process will lead to direct collapse out.
• XFS Bug, OSD process will lead to cluster all direct collapse out.
• SSD damage.
• Ceph PG inconsistent。
• Ceph data recovery when run over the network bandwidth.

Overall, Ceph is very stable and reliable.

Excerpt from: http:? //Way4ever.com/ p = 2989