第三讲，Ceph内部构件
大家好！今天小编继续给大家介绍Ceph存储系统第三讲《Ceph内部构件》。可能大家都觉得一直讲原理会难免有点枯燥，但是大家别心急，先了解Ceph的基础原理再论操作会更容易明白，首先我们要弄懂他为什么能无限扩展，为什么能实现高可用，到底他是以一种什么形式存储数据，然后会介绍如何部署Ceph。因为小编是以自己操作经验和书本理论结合，然后一字一句手打，如有错误之处欢迎留言一起探讨。
对象
对于Ceph存储来说，他是以对象形式存储，一个对象通常包含绑定在一起的数据和元数据，并且用一个全局唯一的标识符标识。这个唯一的标识符确保在整个存储集群中没有其他对象使用相同的对象ID，从而保证对象唯一性。
基于文件的存储中，文件大小是有限制的；与此不同的是，对象的大小则是可以随着大小可变的元数据而变得很大。在一个对象中，数据存储为丰富的元数据，他们存储上下文和数据的实际内容等信息；备注：元数据是关于数据的数据，具体如下图
对象可以存储在本地，也可以存放在地理上分开的线性地址空间中，也就是说，在一个连续的存储空间中。这种存储机制帮助对象在整个集群中唯一地标识自己，任何应用程序都可以基于对象ID通过调用RESTful API从对象中获取数据。这个URL可以以同样的方式工作在Internet上，一个对象ID作为一个唯一的指针指向对象。这些对象都以复制的方式存储在基于对象的存储设备OSD中，因此提供高可用性。这个也是Ceph能不受限制地扩展容量的基础。
CRUSH
CRUSH算法（Controlled Replication Under Scalable Hashing），他是Ceph的智能数据分发机制，他是整个Ceph数据存储机制的核心。与传统系统依赖于存储和管理一个核心元数据不同的是，Ceph使用CRUSH算法来准确计算数据应该被写入哪里或从哪里读取。
在这里小编在哆嗦地解释一下元数据吧，在传统文件存储系统机制，每一次有数据更新到存储系统中时，元数据是最先更新，更新内容是数据将会存放在哪里，在这之后才是实际数据存储，读取数据也一样，先从元数据告诉你需要读取的数据在哪里，各位可以理解为一个路由表或索引表，同时元数据也是文件系统的单点故障之一，一旦元数据表损坏，你将失去所有数据。
而CRUSH改变了这个传统文件系统机制，所以Ceph可以说是数据存储和管理的一种革命。
CRUSH是按需计算元数据，而不是存储元数据，从而消除传统的元数据存储方法中的所有限制。CRUSH机制以这样一种方式工作：元数据计算的负载是分布式的并且只在需要时执行。
他不依赖系统，Ceph给客户端提供了足够的灵活性来按需执行元数据计算，客户端使用自己的系统资源来执行CRUSH查找，从而取消中心查找。
CRUSH查找
对于Ceph集群的一次读写操作，客户端首先联系Ceph的monitor并获取一个集群map副本，集群map帮助客户端获取Ceph集群的状态和配置信息，使用对象和池名/ID将数据转换为对象，然后将对象和PG（Placement Groups）数一起77经过散列来生成其在Ceph池中最终存放的那一个PG，然后前面计算好的PG经过CRUSH查找来确定存储或获取数据所需的主OSD位置，计算完准确的OSD ID后，客户端直接联系这个OSD来存储数据。所有这些计算都是在客户端来执行，所以他不会影响整个集群的性能。
一旦数据被写入主OSD，主OSD所在节点将执行CRUSH查找操作并计算辅助PG和OSD的位置来实现数据复制，进而实现高可用性。
CRUSH还能设计层级结构化，CRUSH设备列表通常包括磁盘，节点，机架，房间，数据中心等等，这些组件称为故障域（CRUSH bucket），根据基础设施，CRUSH跨故障域来传播数据及副本，因而即使一些组件出错，数据也是安全的，同时保证高可用性。
建议：在搭建Ceph前需要设计好架构，小编之前吃过一次亏，在搭建好再设计架构，当然也是可以，只不过会产生数据再平衡的情况，数据再平衡就会对生产环境带来性能上的影响，而且会视乎你设计的架构复杂度而决定所需时长，小编一共30TB磁盘，3个主机重新设计架构花两天时间再平衡。当然架构的设计不是必须的，只是小编我有点强迫症。
PG
PG是一个逻辑概念，这个小编一开始也没有很好理解。小编理解PG就是管理对象的容器，这个会更抽象一些，各位千万不要把日常使用的windows的文件管理系统习惯带进Ceph，不然你会很难理解，小编一开始学也是花了不少时间让自己想法纠正过来。言归正传
当Ceph集群接收到数据存储的请求时，它被分散到各个PG中，然而，CRUSH首先将数据分解成一组对象，然后根据对象名称、复制级别和系统中总的PG数目等信息执行散列操作，再将结果生成PG ID。PG是一组对象的逻辑集合，通过复制他到不同的OSD上来提供存储系统的可靠性。根据Ceph池的复制级别，每个PG的数据会被复制并分发到Ceph集群的多个OSD上。没有PG，在跟踪数以百万计的对象复制和传播是相当困难的，没有PG管理消耗计算资源是噩梦。与独立的管理每一个对象不同的是，Ceph只管理包含大量对象的PG。每个PG需要一定的系统资源CPU和内存，增加集群PG的数量能够降低每个OSD的负载，但应该以规范方式进行增加，建议每个OSD上放置50-100个PG。Ceph官方给出的规范计算公式如下：
PG总数=（OSD总数×100）/最大副本数
结果必须舍入最接近2的N次幂的值；例如计算得出120就取128,得出180就取256，诸如此类；
理论上PG是可以再次调整，但小编实操过程发现调整只能增加PG数量，不能减少，也就是原来是128，可以增加到256，但原来是256的不能降为128.而且变更PG也同样造成数据再平衡，顺便提一下，再平衡其实就是平衡PG。PGs也有最大值限制，系统会根据OSD目前总数会有一个最大值限制。小编翻查过Ceph书籍并没有明确说明最大值的计算方式，但小编尝试设置一个很大的值之后，系统会告诉我PGs超过了OSD总数×250，他会根据目前的OSD数量和副本数量计算出你总的限制。
Ceph池
Ceph池可以简单理解为逻辑分区，逻辑分区在传统文件系统已经存在，池也不是一个新概念。Ceph中每个池都包含一定数量的PG，进而实现把一定数量的对象映射到集群内部不同OSD上。池可以通过创建需要的副本数来保障数据的高可用性。一个池可以以复制或者纠删码方式创建，但不能同时使用这两种方式。在创建池的时候，可以指定副本数，默认是2，当然可以1或＞2，池的副本数是非常灵活的，是可以改变它。但书籍上并没有具体说明改变的方法，小编在实际环境中是以移动方式去改变副本数。如果各位有更好的方式希望能够分享一下。
Ceph数据管理
Ceph集群内的数据管理涉及目前为止，我们已经讨论过的所有组件。这些组件之间的协作给了Ceph提供可靠和健壮的存储系统能力。数据管理始于客户端向Ceph池中写数据，一旦客户端准备写数据到Ceph池中，数据首先写入到基于池副本数的主OSD中。主OSD再复制相同数据到第二OSD和第三OSD中，并等待他们确认写入完成，只要第二OSD和第三OSD完成数据写入，他们就会发送一个应答信号给主OSD，最后主OSD再返回一个应答信号给客户端，以确认完成整个写入操作。
关于Ceph内部构件先介绍到这里，感谢大家阅读！
通过这三讲，大家应该已经对Ceph有了初步的了解，也基本明白Ceph的操作原理；后续将继续为大家介绍实操《如何部署Ceph存储系统》，敬请关注下一期。具有Ceph功能的系统市面上有几个，有收费有免费，也有技术性收费，小编只能介绍目前自己所用的系统，并将以实际工作经验与遇到的问题点再与书本理论结合精简地给大家介绍，希望大家多点赞，谢谢！
- 发表于:
- 原文链接：https://kuaibao.qq.com/s/20191016A0CIV700?refer=cp_1026
- 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号（企鹅号）传播渠道之一，根据《腾讯内容开放平台服务协议》转载发布内容。
- 如有侵权，请联系 cloudcommunity@tencent.com 删除。
相关快讯
扫码
添加站长 进交流群
领取专属 10元无门槛券
私享最新 技术干货
腾讯云开发者
