Ceph在同程的实践

同程有很多不同的职能部门，存在大量的非结构化数据，所谓的非结构化数据是指数据结构不规则或不完整，没有预定义的数据模型，不方便用数据库二维逻辑表来表现的数据，包括所有格式的办公文档、文本、图片、XML、HTML、各类报表……...



1.  Ceph使用背景

同程有很多不同的职能部门，存在大量的非结构化数据。所谓的非结构化数据是指数据结构不规则或不完整，没有预定义的数据模型，不方便用数据库二维逻辑表来表现的数据，包括所有格式的办公文档、文本、图片、XML、HTML、各类报表、音频/视频信息等等。在未引入分布式存储之前，同程使用的是传统的单机文件系统存储，非结构化数据都存入本地磁盘，存在诸多缺点：

• 单点故障
• 扩容困难
• 无法实现数据的高可靠，也无法实现访问的高可用
• 数据达到一定规模时，面临庞大的元数据管理，给存储系统带来很大的开销，造成性能瓶颈
• 使用本地存储的有状态应用无法实现迁移
• 和OS绑定，如果文件系统存在bug，则整个系统不可用

目前非结构化数据的主流存放方案是对象存储，相比传统的单机文件存储，具有如下优点：

• REST风格的接口和扁平的数据组织结构
• 海量数据、水平扩展、性能和容量同步按需升级
• 多租户、细粒度控制安全
• 使用存储资源池，有效分配存储资源按需使用

同程的私有云环境，也需要高可靠的云盘服务并且能够弹性伸缩，这个要使用分布式块存储。

综上，在调研了诸多的开源分布式存储之后，选用Ceph作为解决方案，理由如下：

• Ceph架构先进，去中心化设计，社区活跃
• 支持对象、块、文件系统存储，大有统一存储的趋势
• OpenStack深度集成是OpenStack默认的存储后端

2.  Ceph在同程的使用

      根据同程的业务需求，使用Ceph的不同功能模块，主要如下：

1）RGW应用于非结构化数据存储

目前存储的数据类型主要有各种办公文档、报表、音、视频，小部分的图片存储以及各种应用的APP包等，实现了存储资源的统一管理和分配。RGW实现了AWS S3和Swift兼容的接口，因此可以直接使用AWS S3 SDK进行访问。

同程RGW的配置比较简单，多个RGW实例通过Nginx进行负载均衡，Nginx使用Keepalived保持高可用。Ngnix端主要做了如下工作：

• Web的CSS、JS文件一般比较小，存储时通过lua实现了多个静态资源的压缩合并存储功能。
• 为加快get速度启用了cache功能，但是Nginx的缓存没有更新功能，通过lua实现了缓存的自动清理。

2）块存储应用于私有云平台建设

将Ceph统一作为Nova、Glance、Cinder的存储后端，不再使用独立的存储：

统一存储避免了OpenStack创建虚拟机时的Image复制，利用RBD的Snapshot功能，基本可以实现Nova instance的秒级创建；RBD的Snapshot有效的减少了Cinder Volume，Nova Instance的备份创建时间和空间占用。

目前Ceph底层没有实现Qos功能，通过QEMU Qos实现卷的Iops和带宽限制，架构如下：3）CephFS应用于服务器间共享数据

原本线下使用NAS，现在可以通过CephFS Kernel Client和FUSE实现POSIX接口访问数据。CephFS的整体架构如下：CephFS目前并不稳定，尤其是目录分片功能。为规避该问题，线下CephFS使用Ceph-FUSE客户端，严格控制目录文件数量和容量并且禁止目录分片以保持稳定性（Kernel CephFS客户端模块没有配额功能），MDS服务使用active-standby模式。目前同程的CephFS用户不多，后续会考虑和OpenStack Manila对接。

3.  Ceph使用的痛点Ceph在使用的过程中，遇到了不少痛点，也踩过很多坑，主要的经验分享如下：

1) Ceph存在日志盘，数据先写到日志盘，再同步到OSD数据盘，再加上三副本强一致性的模型，如果单纯使用HDD盘，性能将会很糟糕，因此同程遵从官方文档建议使用SSD+HDD混搭的模式，在性能和成本之间取得平衡。基本配置是每OSD节点挂载10块普通4T SATA接口硬盘，使用10Gbps网卡，假设每块普通SATA硬盘的带宽为100MB/s，因此只有使用万兆网卡才能发挥全部10块数据硬盘的带宽，并且可以大大缩短OSD之间复制数据的时间；2块SSD盘作为日志盘，每块SSD日志盘对应5块OSD数据盘，由于OSD日志盘倾向于顺序写，因此选用带宽为400-500MB/s的SSD。单节点配置如下表所示：2）对象存储，由于RGW架构本身的设计单bucket无法存放无限文件。默认情况下单个bucket的index全部存储在一个shard文件中，随着单bucket存储的object数量增加，整个shard文件也会不断增加。如果不加限制会导致shard文件体积过大，将会引发各种问题，主要如下：

• 对buckets.index pool 进行scrub或者deep scrub时，如果此时shard的体积过大，会极大消耗底层存储设备的性能，造成io请求超时
• 当坏盘或者OSD down重新up时，恢复一个大体积的shard文件将严重影响正常io资源，造成client io超时

针对该问题，主要做了如下几个方面优化：

• 合理设置bucket shard数量，使用多个shard文件存储bucket元数据，避免单个shard文件过大
• buckets.index  pool 使用SSD，加快恢复速度
• 启用bucket的配额功能，控制shard文件尺寸

3）Ceph在L版本之前并没有提供管理的dashboard，但是提供了丰富的api，用于Ceph管理。基于此实现了统一的管理平台，通过Ceph RGW的admin api和bucket api实现了对象存储的管理；使用Cinder api和Nova api实现了卷的管理。

4）Ceph监控是重点，集群异常时必须给出告警并通知相关人员，虽然官方没有提供统一的监控工具，但是通过Zabbix可以有效的实现Ceph监控，主要关注如下几个指标：

• Ceph OSD是否异常，因为OSD down之后再次up，将触发Ceph的peering和对象修复过程，在此期间Client io将hang住
• Ceph monitor进程数是否正常，以3个monitor节点为例，如果超过1个monitor挂掉，集群将不可用
• Io request是否耗时过长，Ceph是强一致性，如果某个io耗时过长，可能是某一个OSD的响应变慢，此时该OSD的硬盘可能存在问题
• Ceph容量及负载，这个将影响是否进行集群扩容和切走应用

4.  未来工作

如果把Ceph比作金矿，同程目前已在开采的路上。但是开采量还比较有限，Ceph存在很多亮点，比如Ceph在硬件上就存在多种配置，容量型和性能型，可以根据不同的性能要求进行灵活配置；常用的存储接口Ceph基本上也都支持(目前不支持ISCSI)。同程的存储需求需要进一步挖掘，让Ceph得到更多应用，同时提供更加稳定可靠的存储服务，是今后努力的方向。

    关注 同程研发中心