背景
- 因负责运维某大型云计算平台，后端存储集群用的是ceph，天天跟ceph打交道，为了更好的运维平台，特此将用到的ceph知识进行下梳理。
说明
- 本文章是对所用的知识进行梳理，不是入门教程，对ceph感兴趣的童鞋们可以看ceph社区推出的《ceph分布式存储实战》一书进行学习。
Ceph的设计哲学
- 每个组件必须可扩展
- 不存在单点故障
- 解决方案必须是基于软件的
- 可摆脱专属硬件的束缚即可运行在常规硬件上
- 推崇自我管理即有自愈能力
Ceph的三大功能
- 对象存储（RADOSGW）
- 块存储（RBD）
- 文件系统存储（Ceph FS）
- 本文中会对块存储进行重点总结，其他两种方式因平台没有用到暂时忽略。
核心组件
- Cehp OSD（Object Storage Device）
- 数据存储仓库，处理数据的复制，恢复，平衡数据分布，为Ceph Monitor提供OSD心跳等信息。Ceph OSD将数据以对象的形式存储到集群中的每个节点的物理磁盘上。
- 在部署ceph集群时，对于OSD的物理部署，官网建议是每个osd所在的物理磁盘都做raid0，因其raid0的条带化与ceph的条带化最相似，可以提高ceph集群的吞吐量进而提升性能。当然你也可以不做raid，如果你的平台或业务系统对性能没有高要求的话。
- Ceph默认为双副本机制，要保证集群的active clean状态，你的集群至少要有两个osd。
- 生产环境中，大多数的平台都是三副本或三副本以上的副本机制来保证集群的高可用性及容错性。我所了解的平台里面，OpenStack大部分是三副本机制，Zstack是四副本机制。在OSD中，每个对象都有一个主副本和若干个从副本，这些副本默认情况下都是分布在不同的节点上的。
- 在Ceph运维过程中，故障率较高的就是OSD的故障，尤其是物理磁盘会经常出现损坏（当然这个看你的平台硬盘选型，如果你选用的是高性能的新盘，故障率就会很低，如果你选用的是二手盘，那故障率就另说了。）每次往集群中添加或删除osd都会引起集群的数据均衡，集群里存储的数据越多，均衡的时间就会越长，数据均衡时会降低集群的IO指标，进而影响平台里的虚机业务，因此搭建平台之初，要考虑到ceph集群性能的优化，提前进行设计部署。
- Ceph Monitor
- Ceph的监控器，主要功能是维护整个集群的健康状态，提供各种Map信息。如OSD、PG Map、MDS Map和CRUSH等
- Ceph Monitor是个轻量级的守护进程，通常情况下不需要大量的系统资源，但因其需要存储集群日志，需要足够的磁盘空间
- 一个生产环境的集群，为了高可用，一般包含多个Monitor节点。在集群中，Monitor的个数应该是奇数（为了防止发生脑裂）,推荐个数为3个，其中一个节点为Leader，三个Monitor节点，最多只能挂掉一个，挂掉两个就会对集群造成影响
- Ceph MDS
- Ceph的元数据服务器。主要保存的是Ceph文件系统的元数据,负责Ceph FS集群中文件和目录的管理，确保它们的一致性。
Ceph功能特性
- RADOSGW：功能特性基于LIBRADOS之上，提供当前流行的RESTful协议的网关，兼容S3和Swift接口
- RBD：功能特性基于LIBRADOS之上通过LIBRBD创建一个块设备，通过QEMU/KVM附加到VM上。
- Ceph FS：功能特性是基于RADOS来实现分布式的文件系统，引入了MDS，主要为兼容POSIX文件系统提供元数据。
说明：RADOS,LIBRADOS,RADOSGW这三个概念涉及到Ceph底层，笔者也没有深入研究，感兴趣的童鞋可以网上搜寻自行学习，当然首推官网文档。
安装
- 快速安装
- 想要快速体验ceph，推荐此方式。
- 虽然是快速安装，通过ceph-deploy简化了集群部署，但是安装之前的基础环境还是需要手动配置，所有想要玩ceph，还是需要有点Linux基础技能的。
- 手动安装
- 如果时间宽裕，推荐用手动安装，按照官方文档一步一步进行安装，有助于加深理解。
- 笔者没有单独去部署过ceph，用的是kolla（现在OpenStack社区主推的容器化部署方式）直接部署的ceph。
RBD块存储
- RBD块设备类似于硬盘，可以挂载到物理机或虚拟机中，挂载方式有以下两种
- Kernel模块方式，简称KRBD
- 利用QEMU模拟器通过LIBRDB方式
- Ceph块设备是一种精简置备模式，可以扩展大小切数据是以条带化的方式存储在一个集群中的多个OSD中。
- 笔者运维的平台中，用Ceph块存储RBD作为KVM虚拟化的后端存储。所以，想要运维好平台，对KVM技术的学习也是必不可少的，在这推荐《深度实践KVM》一书。
学习之路还很漫长。。。。
运维心得
- 对Ceph最放心的一点就是它保证了数据安全性，笔者这里用到的是三副本机制，基本上不用担心数据丢失的情况（除了不抗力因素，为了避免这种情况，最近正在考虑部署ceph异地容灾）
- 这里吐槽下Koall项目中部署的ceph，笔者用的版本为Pike版，ceph版本为Luminous版，Kolla中集成的ceph对bug的修复不是很及时，并且一点小小的改动，就会影响整个平台，笔记建议，如果你打算在生产环境中用kolla部署平台，可以考虑将cehp进行单独部署。
- 在平台搭建之初，对于平台的选型十分重要，结合要服务的对象和实际业务，决定你是要通用型的还是高性能型的平台，根据平台的选型来对ceph进行优化。
- 关于ceph的性能优化，网上有许多资料，这里不再进行整理。最重要的一点就是，如果你的将要搭建的平台承载的数据量很大的话，那么在网络设计和硬件选择设上一定要规划好，如果硬件和网络跟不上，那么等待你的将是漫长的等待。。。
