Ⅰ 思科交换机3560如何清空DHCP地址池缓存
clear ip dhcp binding *
Ⅱ ceph：rados浅析
在传统分布式存储架构中，存储节点往往仅作为被动查询对象来使用，随着存储规模的增加，数据一致性的管理会出现很多问题。
而新型的存储架构倾向于将基本的块分配决策和安全保证等操作交给存储节点来做，然后通过提倡客户端和存储节点直接交互来简化数据布局并减小io瓶颈。
RADOS就是这样一个可用于PB级规模数据存储集群的可伸缩的、可靠的对象存储服务。它包含两类节点：存储节点、管理节点。它通过利用存储设备的智能性，将诸如一致性数据访问、冗余存储、错误检测、错误恢复分布到包含了上千存储节点的集群中，而不是仅仅依靠少数管理节点来处理。
RADOS中的存储节点被称为OSD(object storage device)，它可以仅由很普通的组件来构成，只需要包含CPU、网卡、本地缓存和一个磁盘或者RAID，并将传统的块存储方式替换成面向对象的存储。
在PB级的存储规模下，存储系统一定是动态的：系统会随着新设备的部署和旧设备的淘汰而增长或收缩，系统内的设备会持续地崩溃和恢复，大量的数据被创建或者删除。RADOS通过 cluster map来实现这些，cluster map会被复制到集群中的所有部分（存储节点、控制节点，甚至是客户端），并且通过怠惰地传播小增量更新而更新。cluster map中存储了整个集群的数据的分布以及成员。
通过在每个存储节点存储完整的cluster map，存储设备可以表现的半自动化，通过peer-to-peer的方式（比如定义协议）来进行数据备份、更新，错误检测、数据迁移等等操作。这无疑减轻了占少数的monitor cluster（管理节点组成的集群）的负担。
一个RADOS系统包含大量的OSDs 和 很少的用于管理OSD集群成员的monitors。OSD的组成如简介所说。而monitor是一些独立的进程，以及少量的本地存储，monitor之间通过一致性算法保证数据的一致性。
存储节点集群通过monitor集群操作cluster map来实现成员的管理。cluster map 描述了哪些OSD被包含进存储集群以及所有数据在存储集群中的分布。
cluster map不仅存储在monitor节点，它被复制到集群中的每一个存储节点，以及和集群交互的client。
当因为一些原因，比如设备崩溃、数据迁移等，cluster map的内容需要改变时，cluster map的版本号被增加，map的版本号可以使通信的双方确认自己的map是否是最新的，版本旧的一方会先将map更新成对方的map，然后才会进行后续操作。
首先，如下图，总体说下RADOS的存储层次，RADOS中基本的存储单位是对象，一般为2MB或4MB，当一个文件要存入RADOS时，首先会被切分成大小固定的对象（最后一个对象大小可能不同），然后将对象分配到一个PG（Placement Group）中，然后PG会复制几份，伪随机地派给不同的存储节点。当新的存储节点被加入集群，会在已有数据中随机抽取一部分数据迁移到新节点。这种概率平衡的分布方式可以保证设备在潜在的高负载下正常工作。更重要的是，数据的分布过程仅需要做几次随机映射，不需要大型的集中式分配表。
对于每个层次的详细说明：
2.Object—— RADOS的基本存储单元。Object与上面提到的file的区别是，object的最大size由RADOS限定（通常为2MB或4MB），以便实现底层存储的组织管理。因此，当上层应用向RADOS存入size很大的file时，需要将file切分成统一大小的一系列object（最后一个的大小可以不同）进行存储。
各层次之间的映射关系：
前面的介绍中已经提到，由若干个monitor共同负责整个RADOS集群中所有OSD状态的发现与记录，并且共同形成cluster map的master版本，然后扩散至全体OSD以及client。OSD使用cluster map进行数据的维护，而client使用cluster map进行数据的寻址。
monitor并不主动轮询各个OSD的当前状态。相反，OSD需要向monitor上报状态信息。常见的上报有两种情况：一是新的OSD被加入集群，二是某个OSD发现自身或者其他OSD发生异常。在收到这些上报信息后，monitor将更新cluster map信息并加以扩散。其细节将在下文中加以介绍。
Cluster map的实际内容包括：
（1） Epoch，即版本号。cluster map的epoch是一个单调递增序列。epoch越大，则cluster map版本越新。因此，持有不同版本cluster map的OSD或client可以简单地通过比较epoch决定应该遵从谁手中的版本。而monitor手中必定有epoch最大、版本最新的cluster map。当任意两方在通信时发现彼此epoch值不同时，将默认先将cluster map同步至高版本一方的状态，再进行后续操作。
（2）各个OSD的网络地址。
（3）各个OSD的状态。OSD状态的描述分为两个维度：up或者down（表明OSD是否正常工作），in或者out（表明OSD是否在至少一个PG中）。因此，对于任意一个OSD，共有四种可能的状态：
（4）CRUSH算法配置参数。表明了Ceph集群的物理层级关系（cluster hierarchy），位置映射规则（placement rules）。
根据cluster map的定义可以看出，其版本变化通常只会由（3）和（4）两项信息的变化触发。而这两者相比，（3）发生变化的概率更高一些。这可以通过下面对OSD工作状态变化过程的介绍加以反映。
一个新的OSD上线后，首先根据配置信息与monitor通信。Monitor将其加入cluster map，并设置为up且out状态，再将最新版本的cluster map发给这个新OSD。
收到monitor发来的cluster map之后，这个新OSD计算出自己所承载的PG（为简化讨论，此处我们假定这个新的OSD开始只承载一个PG），以及和自己承载同一个PG的其他OSD。然后，新OSD将与这些OSD取得联系。如果这个PG目前处于降级状态（即承载该PG的OSD个数少于正常值，如正常应该是3个，此时只有2个或1个。这种情况通常是OSD故障所致），则其他OSD将把这个PG内的所有对象和元数据复制给新OSD。数据复制完成后，新OSD被置为up且in状态。而cluster map内容也将据此更新。这事实上是一个自动化的failure recovery过程。当然，即便没有新的OSD加入，降级的PG也将计算出其他OSD实现failure recovery。
如果该PG目前一切正常，则这个新OSD将替换掉现有OSD中的一个（PG内将重新选出Primary OSD），并承担其数据。在数据复制完成后，新OSD被置为up且in状态，而被替换的OSD将退出该PG（但状态通常仍然为up且in，因为还要承载其他PG）。而cluster map内容也将据此更新。这事实上是一个自动化的数据re-balancing过程。
如果一个OSD发现和自己共同承载一个PG的另一个OSD无法联通，则会将这一情况上报monitor。此外，如果一个OSD deamon发现自身工作状态异常，也将把异常情况主动上报给monitor。在上述情况下，monitor将把出现问题的OSD的状态设为down且in。如果超过某一预订时间期限，该OSD仍然无法恢复正常，则其状态将被设置为down且out。反之，如果该OSD能够恢复正常，则其状态会恢复为up且in。在上述这些状态变化发生之后，monitor都将更新cluster map并进行扩散。这事实上是自动化的failure detection过程。
对于一个RADOS集群而言，即便由数千个甚至更多OSD组成，cluster map的数据结构大小也并不惊人。同时，cluster map的状态更新并不会频繁发生。即便如此，Ceph依然对cluster map信息的扩散机制进行了优化，以便减轻相关计算和通信压力：
基于上述机制，Ceph避免了由于cluster map版本更新而引起的广播风暴。这虽然是一种异步且lazy的机制，但根据论文中的结论，对于一个由n个OSD组成的Ceph集群，任何一次版本更新能够在O(log(n))时间复杂度内扩散到集群中的任何一个OSD上。
一个可能被问到的问题是：既然这是一种异步和lazy的扩散机制，则在版本扩散过程中，系统必定出现各个OSD看到的cluster map不一致的情况，这是否会导致问题？答案是：不会。事实上，如果一个client和它要访问的PG内部的各个OSD看到的cluster map状态一致，则访问操作就可以正确进行。而如果这个client或者PG中的某个OSD和其他几方的cluster map不一致，则根据Ceph的机制设计，这几方将首先同步cluster map至最新状态，并进行必要的数据re-balancing操作，然后即可继续正常访问。
Ⅲ 如何获取ceph的缓存池中对象的大小和偏移
连续容器如:Vector，内部是预先分配一段连续缓存来保存对象，所分配内存可以保存对象的个数为容量，而已保存的对象个数为长度。
当程序调用push时候，如果容量不够了，Vector自动重新分配一段缓存，大小是原来的2倍，然后把原来的内容拷贝到新缓存中，最后释放原来的缓存。出现这种情况是很费时间的！所以Vector内部的指针的地址是可能变得的！
list 是每次添加对象的时候动态分配内存，所以没有容量的概念！
Ⅳ 星际争霸2老是提示我缓存池不足啊！！！求解决方法！！
听我的4G内存就弄512缓存优化一下系统就用你的鲁大师还有垃圾病毒这些都是基本的就算不玩游戏也得经常弄我就不多说了
不要把缓存弄得过多普通的民用硬盘的速度怎么可能比得上内存条？这绝对是在开国际玩笑，天方夜谈
之后一定要重启绝对
保证你的每个盘符下至少有15%的剩余空间实在不行就保证C盘和游戏盘也行C盘东西不能多多了你再好电脑也得卡
我的渣配置玩都不卡
Ⅳ ceph分布式存储-常见 PG 故障处理
创建一个新集群后，PG 的状态一直处于 active ， active + remapped 或 active + degraded 状态， 而无法达到 active + clean 状态 ，那很可能是你的配置有问题。
你可能需要检查下集群中有关 Pool 、 PG 和 CRUSH 的配置项，做以适当的调整。
一般来说，你的集群中需要多于 1 个 OSD，并且存储池的 size 要大于 1 副本。
有时候，我们需要搭建一个单节点的 Ceph 实验环境。此时，在开始创建 monitor 和 OSD 之前，你需要把 Ceph 配置文件中的 osd crush chooseleaf type 选项从默认值 1 （表示 host 或 node ）修改为 0 （表示 osd ）。这样做是告诉 Ceph 允许把数据的不同副本分布到同一 host 的 OSDs 上。
如果你已经启动了 2 个 OSD，它们都处于 up 和 in 的状态，但 PG 仍未达到 active + clean 状态，那可能是给 osd pool default size 设置了一个大于 2 的值。
如果你想要在 active + degraded 状态（ 2 副本）操作你的集群，可以设置 osd pool default min size 为 2 ，这样你就可以对处于 active + degraded 的对象写入数据。然后你还可以把 osd pool default size 的值改为 2 ，这样集群就可以达到 active + clean 状态了。
另外，修改参数 osd pool default size/min_size 后，只会对后面新建的 pool 起作用。如果想修改已存在的 pool 的 size/min_size ，可用下面的命令：
注意： 你可以在运行时修改参数值。如果是在 Ceph 配置文件中进行的修改，你可能需要重启集群。
如果你设置了 osd pool default size 的值为 1 ，那你就仅有对象的单份拷贝。OSD 依赖于其他 OSD 告诉自己应该保存哪些对象。如果第一个 OSD 持有对象的拷贝，并且没有第二份拷贝，那么也就没有第二个 OSD 去告诉第一个 OSD 它应该保管那份拷贝。对于每一个映射到第一个 OSD 上的 PG （参考 ceph pg mp 的输出），你可以强制第一个 OSD 关注它应该保存的 PGs ：
PG 达不到 clean 状态的另一个可能的原因就是集群的 CRUSH Map 有错误，导致 PG 不能映射到正确的地方。
有失败发生后，PG 会进入“degraded”（降级）或“peering”（连接建立中）状态，这种情况时有发生。通常这些状态意味着正常的失败恢复正在进行。然而，如果一个 PG 长时间处于这些状态中的某个，就意味着有更大的问题。因此 monitor 在 PG 卡 （ stuck ） 在非最优状态时会告警。我们具体检查：
你可以用下列命令显式地列出卡住的 PGs：
卡在 stale 状态的 PG 通过重启 ceph-osd 进程通常可以修复；卡在 inactive 状态的 PG 通常是互联问题（参见 PG 挂了 —— 互联失败 ）；卡在 unclean 状态的 PG 通常是由于某些原因阻止了恢复的完成，像未找到的对象（参见 未找到的对象 ）。
在某些情况下， ceph-osd 互联 进程会遇到问题，阻值 PG 达到活跃、可用的状态。例如， ceph health 也许显示：
可以查询到 PG 为何被标记为 down ：
recovery_state 段告诉我们互联过程因 ceph-osd 进程挂了而被阻塞，本例是 osd.1 挂了，启动这个进程应该就可以恢复。
或者，如果 osd.1 发生了灾难性的失败（如硬盘损坏），我们可以告诉集群它丢失（ lost ）了，让集群尽力完成副本拷贝。
重要： 集群不能保证其它数据副本是一致且最新的，就会很危险！
让 Ceph 无论如何都继续：
恢复将继续进行。
某几种失败相组合，可能导致 Ceph 抱怨有找不到（ unfound ）的对象：
这意味着存储集群知道一些对象（或者存在对象的较新副本）存在，却没有找到它们的副本。下例展示了这种情况是如何发生的，一个 PG 的数据存储在 ceph-osd 1 和 2 上：
这时， 1 知道这些对象存在，但是活着的 ceph-osd 都没有这些副本。这种情况下，读写这些对象的 IO 就会被阻塞，集群只能指望 down 掉的节点尽早恢复。这样处理是假设比直接给用户返回一个 IO 错误要好一些。
首先，你应该确认哪些对象找不到了：
如果在一次查询里列出的对象太多， more 这个字段将为 true ，你就可以查询更多。
其次，你可以找出哪些 OSD 上探测到、或可能包含数据：
本例中，集群知道 osd.1 可能有数据，但它挂了（ down ）。所有可能的状态有：
有时候集群要花一些时间来查询可能的位置。
还有一种可能性，对象存在于其它位置却未被列出。例如，集群里的一个 ceph-osd 停止且被剔出集群，然后集群完全恢复了；后来一系列的失败导致了未找到的对象，它也不会觉得早已死亡的 ceph-osd 上仍可能包含这些对象。（这种情况几乎不太可能发生）。
如果所有可能的位置都查询过了但仍有对象丢失，那就得放弃丢失的对象了。这仍可能是罕见的失败组合导致的，集群在写操作恢复后，未能得知写入是否已执行。以下命令把未找到的（ unfound ）对象标记为丢失（ lost ）。
上述最后一个参数告诉集群应如何处理丢失的对象。
拥有 PG 拷贝的 OSD 可能会全部失败，这种情况下，那一部分的对象存储不可用， monitor 也就不会收到那些 PG 的状态更新了。为检测这种情况，monitor 会把任何主 OSD 失败的 PG 标记为 stale （不新鲜），例如：
可以找出哪些 PG 是 stale 状态，和存储这些归置组的最新 OSD ，命令如下：
如果想使 PG 2.5 重新上线，例如，上面的输出告诉我们它最后由 osd.0 和 osd.2 管理，重启这些 ceph-osd 将恢复之（可以假定还有其它的很多 PG 也会进行恢复 ）。
如果你的集群有很多节点，但只有其中几个接收数据， 检查 下存储池里的 PG 数量。因为 PG 是映射到多个 OSD 的，较少的 PG 将不能均衡地分布于整个集群。试着创建个新存储池，设置 PG 数量是 OSD 数量的若干倍。更详细的信息可以参考 Ceph 官方文档 —— Placement Groups 。
如果你的集群已启动，但一些 OSD 没起来，导致不能写入数据，确认下运行的 OSD 数量满足 PG 要求的最低 OSD 数。如果不能满足， Ceph 就不会允许你写入数据，因为 Ceph 不能保证复制能如愿进行。这个最低 OSD 个数是由参数 osd pool default min size 限定的。
如果收到 active + clean + inconsistent 这样的状态，很可能是由于在对 PG 做擦洗（ scrubbing ）时发生了错误。如果是由于磁盘错误导致的不一致，请检查磁盘，如果磁盘有损坏，可能需要将这个磁盘对应的 OSD 踢出集群，然后进行更换。生产环境中遇到过不一致的问题，就是由于磁盘坏道导致的。
当集群中出现 PG 不一致的问题时，执行 ceph -s 命令会出现下面的信息：
1、查找处于 inconsistent 状态的问题 PG ：
这个有问题的 PG 分布在 osd.1 、 osd.2 和 osd.0 上，其中 osd.1 是主 OSD。
2、去主 OSD（ osd.1 ）的日志中查找不一致的具体对象 。
从日志中可以知道，是 rbd_data.1349f035c101d9.0000000000000001 这个对象的属性 _ 丢失了，所以在 scrub 的过程中产生了 error 。
3、执行 ceph pg repair 命令修复问题 PG 。
4、检查 Ceph 集群是否恢复到 HEALTH_OK 状态。
osd.1 的日志里也提示修复成功：
如果经过前面的步骤，Ceph 仍没有达到 HEALTH_OK 状态，可以尝试用下面这种方式进行修复。
1、停掉不一致的 object 所属的 osd 。
2、刷新该 osd 的日志。
3、将不一致的 object 移除。
4、重新启动该 osd 。
5、重新执行修复命令。
6、检查 Ceph 集群是否恢复到 HEALTH_OK 状态。
有时候，我们在 ceph -s 的输出中可以看到如下的告警信息：
这是因为集群 OSD 数量较少，测试过程中建立了多个存储池，每个存储池都要建立一些 PGs 。而目前 Ceph 配置的默认值是每 OSD 上最多有 300 个 PGs 。在测试环境中，为了快速解决这个问题，可以调大集群的关于此选项的告警阀值。方法如下：
在 monitor 节点的 ceph.conf 配置文件中添加:
然后重启 monitor 进程。
或者直接用 tell 命令在运行时更改参数的值而不用重启服务：
而另一种情况， too few PGs per OSD （16 < min 20） 这样的告警信息则往往出现在集群刚刚建立起来，除了默认的 rbd 存储池，还没建立自己的存储池，再加上 OSD 个数较多，就会出现这个提示信息。这通常不是什么问题，也无需修改配置项，在建立了自己的存储池后，这个告警信息就会消失。
Ⅵ ceph（第一步） 基础架构
ceph 是什么？
ceph 是一种开源存储软件。底层实现了对象存储，并以此为基础对外提供对象存储接口、块存储接口、文渣迹穗件级存储接口。
ceph 结构包含两个部分：
ceph 版本：Nautilus
官网的一张架构图：
对于这张图，一开始没有看懂它想表达什么，后来明白了。如下图：
相关名词解释：
ceph 组件分为两部分：
此部分介绍构成 ceph 集群的基础组件。
其中包含 OSD、Manager、MDS、Monitor。
此部分介绍 ceph 对外提供各种功能的组件。
其中包含：Block Device、Object Storage、Filesystem。
前面两个部分主要介绍了 ceph 的一些组件及对外提供的功能。
这部分主要介绍 ceph 的存储逻辑。
首先，在对象存储中，一切都是扁平化的，并且存储的最小单元为对象（obj）。存储 obj 如下图：
ceph 在对象存储的基础上提供了更加高级的思想。
当对象数量达到了百万级以上，原生的对象存储在索引对象时消耗的性能非常大。ceph 因此引入了 placement group （pg）的概念。一个 pg 就是一组对象的集合。如下图：
obj 和 pg 之间的映射由 ceph client 计算得出。
讨论 pg 时，不得不提的另外一个名词：pgp。
pgp 决定了 pg 和 osd 之间的映射关系。一般将 pgp_num 设置成和 pg_num 一样大小。
这里还有一个名词需要提一下，在 ceph 中会经常见到 crush 算法。简单来说，crush 算法就是指 ceph 中数据如何存储、读取的过程。如卜
由于 ceph 集群面对许多的独立项目，因此 ceph 还引入了 ceph pool 的概念用于划分不同的项目。
ceph pool 是对 ceph 对象的逻辑划分，并不是物理划分。
pg 和 ceph pool 的区别：
像大多数集群软件一样，ceph 也提供了缓存的概念。称之为 Cache Tier（缓存层，在具体使用时有时会称之为缓存池）。
缓存池对用户来说是透明的，因此不会改变用户的原有使用逻辑。以下缓存池的介绍，均为底层逻辑。
在没有缓存池时，ceph client 直接指向存储池。
在添加缓存池后，ceph client 指向缓存池，缓存池再指向存储池。
官方原话：
When pg_num is increased for any pool, every PG of this pool splits into half, but they all remain mapped to their parent OSD.
Until this time, Ceph does not start rebalancing. Now, when you increase the pgp_num value for the same pool, PGs start to migrate from the parent to some other OSD, and cluster rebalancing starts. This is how PGP plays an important role.
By Karan Singh
个人翻译：
当州旦一个池增加 pg 数量时，这个池中的所有 pg 都会变化。但是原 pg 的实际物理存储位置不会改变。
当一个池增加 pgp 的数量时，pg 的实际物理存储位置会发生改变。
首先，截至目前，没有具体查到资料证明以下观点。（基于一致性hash的猜想）
图中出现了一个新词： vosd ，这个是指虚拟 osd。它的数量等于 pgp 的数量，而 pgp 一般又等于 pg。
pgp 的数量就是 vosd 的数量。
引入 pg 可以实现 pool 概念，以及优化碎片管理（这一点十分不确定）。
引入 pgp（vosd），是为了在增加 osd 时可以让数据更加均衡的分布。
如猜想图：
当我们增加池的 pg 数量时，不会改变 vosd，因此原 pg 与 vosd 之间的映射未变，原 pg 的实际物理位置也不会发生变化。只是会影响同一个池中 obj 的分布。
当我们增加池的 pgp 数量时，相当于改变了 vosd，通过 hash 计算出的部分 pg 与 vosd 之间的映射就要发生改变，从而导致 pg 的实际物理位置发生改变。
与一致性hash不同的地方：
一般情况下，一致性hash只有一层虚拟化层，并且虚拟化层是根据物理硬件而变化的。但是ceph却是一种反着来的意思。
当 ceph 增加一个 osd 时，pg 的物理位置也会发生改变。
在该猜想下：
当增加 osd 时，并不会增加 vosd 的数量，原部分 vosd 会映射到新的 osd 上，因此产生一种部分 pg 的实际物理位置发生变化的情况。
创建池时，会分配固定的 pg，以及设置与 pg 一样大小的 pgp。
注意，一般 pg 数量都设置为 2 的次方。
严格意义上，我们无论为池分配多少个 pg 都没有问题。但有时候 pg num 配置小了会报错，配置大了也会报错。这不是因为这么配置不对，是因为有其它的参数在限制我们随意配置 pg num。
比如：
osd 有两个配置，当每个 osd 的 pg num 过少（默认30）时会告警，当每个 osd 的 pg num 过多（默认300）也会告警。
所以，想要入门使用 ceph，还是需要了解许多基础知识才可以。否则，各种意外。
https://docs.ceph.com/docs/master/architecture/
https://ceph.com/pgcalc/
Ⅶ Ceph 分层缓存--Tiering Cache
原文来自Ceph官方文档： CACHE TIERING
部分摘抄自Ceph中国社区翻译文档： 分级缓存
分层缓存为ceph客户端中的某些存放在存储层的数据提供更好的IO性能。分级缓存需创建一个由高速而昂贵存储设备（如 SSD ）组成的存储池、作为缓存层，以及一个相对低速/廉价设备组成的后端存储池（或纠删码编码的）、作为经济存储层。Ceph 的对象处理器决定往哪里存储对象，分级代理决定何时把缓存内的对象刷回后端存储层；所以缓存层和后端存储层对 Ceph 客户端来孙禅孝说是完全透明的。
缓存代理层管理着数据在缓存层和存储层之间的自动迁移。但是, 管理员也可以通过配置来干预迁移规则， 下面是对两个主要场景的介绍:
Writeback Mode： 当管理员将缓存层配置成回写模式, Ceph客户端将数据写入缓存层，并接收返回的ACK。同时，写入缓存层的数据迁移到存储层， 然后从缓存层刷掉。 直观的看， 缓存层在存储层之前。 当Ceph客户端需要存在于存储层的数据时， 缓存层代理会把这些数据迁移到缓存层，然后再发往 Ceph 客户端。因此，Ceph 客户端将与缓存层进行 I/O 操作，直到数据不再被读写。此模式对于易变数据来说较理想（如照片/视频编辑、事务数据等）。
Read-proxy Mode： 这个模式将使用一些已经存在于缓存层的数据，但是，如果数据不在缓存层，请求将被代理转发到底层。这个模式对于从回写模式过渡到禁用缓存非常有用的， 因为它润需负载一直工作到缓存干涸，不再向缓存添加任何数据。
如果负载过多，分层缓存会降低性能。用户在使用以下特性时需要极其谨慎。
Workload dependent : 缓存是否能提升性能，高度依赖于负载能力。因为将数据移入或移除缓存会导致额外的开销，它只在对数据集的访问有大的偏离时有影响。例如, 众多的请求访问小数量的objects，这时，你的缓存池需要非常大，才能在处理所有请求时，避免数据过渡。
Difficult to benchmark : 用户使用评测性能时，大部分的关于分层缓存bechmarks测试结果，将会是一个糟糕的结果。其中部分原因是很少的bechmarks倾斜于一组小的对象集合的请求 ， 这会使缓存经过很长时间后才能“活跃起来”，并且这种“活跃起来”会导致高昂的开销。
Usually slower : 对于并没有友好使用分级缓存的工作负载，性能普遍低于一个没使用分级缓存的普通rados池。
librados object enumeration : 对于librados级别的枚举对象API并不能连贯存在在这种情况中（The librados-level object enumeration API is not meant to be coherent in the presence of the case）。 如果你的应用直接使用则稿rados，并且依赖于枚举对象，分级缓存不能向期待的那样工作. (对于RGW, RBD, or CephFS，没有这个问题)
Complexity : 在使用RADOS集群时，使用分级缓存意味着大量的额外器械和复杂性。这会增加你遇到未知的BUG（可能其他人未遇到过）的可能性， 并且使你的部署拥有更大的风险。
RGW time-skewed : 如果RGW工作中遇到的大部分操作是朝向最近写入的数据，一个简单的分级缓存可以工作得很好。
下面的配置使用分层缓存效果不佳。
RBD with replicated cache and erasure-coded base : 这是一个普遍的需求, 但是通常不能很好工作。即使合理的倾斜工作负载，仍然会遇到一些对于冷门object的写操作的情况，并且由于纠删袭仿码类型的池还不支持轻微的读写操作，为了适应一些小的写入操作（通常4kb），整个object块（通常4MB）必须被全部迁移到缓存 。只有少数用户成功的应用了这种部署方式，并且这种部署方案只能为他们工作是因为他们的数据是极其“冷门”的（例如备份），并且他们对于性能并不敏感。
RBD with replicated cache and base : 在使用备份类型为基础层时比以纠删码为基础层时，RBD的表现更为良好， 但是它在工作负载中仍然依赖于大量的倾斜，并且很难验证。用户需要对他们的工作负载有更好的理解， 并且需要仔细调整分层缓存参数。
为了建立分层缓存，你必须拥有两个存储池。一个作为后端存储，一个作为缓存。
建立一个后端存储池包含两种场景：
标准存储 : 在这种场景中，这个池在Ceph存储集群中存储一个对象的多个副本。
纠删码: 在这种场景中，存储池用纠删码高效地存储数据，性能稍有损失。
在标准存储场景中，你可以用 CRUSH 规则集来标识失败域（如 osd 、主机、机箱、机架、排等）。当规则集所涉及的所有驱动器规格、速度（转速和吞吐量）和类型相同时， OSD 守护进程运行得最优。创建规则集的详情见 CRUSH 图 。创建好规则集后，再创建后端存储池。
在纠删码编码情景中，创建存储池时指定好参数就会自动生成合适的规则集，详情见 创建存储池 。
在后续例子中，我们把cold-storage当作后端存储池。