使用ceph作为存储的openstack，看到一篇非常非常有价值的文章，这篇文章整理了openstack结合ceph的最佳方式，包括了一些openstack使用ceph后的参数优化，以及SSD OSD磁盘的使用方式建议，一些pool池的使用建议，解答了相当一部分的疑惑。

Ceph和OpenStack是一个非常有用和非常受欢迎的组合。 不过，部署Ceph / OpenStack经常会有一些容易避免的缺点 - 我们将帮助你解决它们。

使用 show_image_direct_url and the Glance v2 API

使用ceph的RBD（RADOS Block Device）,你可以创建克隆,你可以将克隆理解为可写的快照（快照通常是只读的）。克隆只会为相对于父快照变化的部分创建对象，这意味着：

可以节省空间。这是显而易见的，但是这并不能很有说服力，毕竟存储是分布式系统当中最便宜的部分

克隆中没有修改的部分还是由原始卷提供。这很重要，因为很容易命中相同的RADOS 对象，相同的osd，不论是用的哪个克隆。而且这意味着，这些对象是从OSD的页面缓存进行响应，换句话说，是RAM提供。RAM比任何存储访问方式速度都快，所以从内存当中提供大量的读取是很好的。正因为这样，从克隆的卷提供数据读取，要比相同数据全拷贝的情况下速度要快一些

Cinder（当从image创建一个卷）和Nova(从ceph提供临时磁盘)都能够使用ceph的后端的RBD image的克隆，并且是自动的，但这个只有在glance-api.conf中设置了show_image_direct_url=true 才会使用，并且配置使用 Glance v2 API进行连接Glance。

设置 libvirt/images_type = rbd on Nova compute nodes

在NOVA中（使用libvirt的KVM计算驱动），有几个存储临时镜像的配置，不从Cinder卷启动的情况。你可以设置 nova?compute.conf 的[libvirt]当中的images_type：

默认的类型是磁盘，这意味着你启动一个新的vm的时候，将会发生下面的事：

nova-compute在你的虚拟机管理节点上链接到Glance API,查找所需要的image，下载这个image到你的计算节点，默认在/var/lib/nova/instances/_base路径下

然后会创建一个qcow2文件，使用下载的这个image做它的backing file

这个过程在计算节点上会占用大量的空间，并且会一旦这个镜像没有提前在计算节点上下载好，就会需要等很久才能启动虚拟机，这也使得这样的vm不可能实时的迁移到另外一台主机而不产生宕机时间

将images_types设置为rbd后意味着disk是存储在rbd的后端的，是原始镜像的克隆，并且是立即创建的，没有延时启动，没有浪费空间，可以获得所有克隆的好处，参考文档

在Nova计算节点上启用RBD缓存

librbd是支持Qemu / KVM RBD存储驱动程序的ceph的库，可以使用虚拟化主机的RAM进行磁盘的缓存。你应该使用这个。

是的，它是一个可以安全使用的缓存。 一方面，virtio-blk与Qemu RBD 驱动程序的组合将正确地实现磁盘刷新。 也就是说，当虚拟机中的应用程序显示“我现在想在磁盘上存储此数据”时，virtio-blk，Qemu和Ceph将一起工作，只有在写入完成时才会报告

此外，Ceph RBD具有一个智能保护：即使它被配置为write-back缓存，它也将拒绝这样做（这意味着它将 write-through模式操作），直到它接收到用户的第一次flush请求。 因此，如果你运行一个永远不会这样做的虚拟机，因为它被错误配置或者它的客户操作系统很老的，那么RBD将固执地拒绝缓存任何写入。 相应的RBD选项称为 rbd cache writethrough until flush，它默认为true，你不应该禁用它。

你可以通过修改nova-compute 配置文件的下面选项开启writeback caching

disk_cachemodes=

你应该这样去做

为images, volumes, and ephemeral disks使用单独的池

现在你已经在Glance开启了enabled show_image_direct_url=true，配置Cinder and nova-compute与Glance交互 的时候使用 v2 API, 配置 nova-compute使用 libvirt/images_type=rbd，所有的VMs和volumes都使用rbd克隆，克隆可以跨存储进行，意味着你可以创建RBD image(已经快照)在一个存储池，然后它的克隆在另外一个存储池

你应该这样做，有几个原因：

单独的池意味着您可以分别控制对这些池的访问。 这只是一个标准的缓解危险方法：如果您的nova-compute节点被攻破，并且攻击者可以损坏或删除临时磁盘，那么这是坏的 - 但如果他们也可能损坏您的Glance图像那将会更糟。

单独池也意味着您可以有不同的池设置，例如size或pg_num的设置。

最重要的是，单独的池可以使用单独的crush_ruleset设置。 下面我们会做介绍

通常有三个不同的池：一个用于Glance图像（通常命名为glance或图像），一个用于Cinder卷（cinder或卷），一个用于VM（nova-compute或vms）。

不需要使用SSD作为你的Ceph OSD journal

在这篇文章的建议中，这一个可能是最令人感觉到奇怪和不认可的。 当然，传统的情况下都会认为，你应该总是把你的OSD journal在更快的设备上，并且你应该以1：4到1：6的比例部署ssd和普通磁盘，对吧？

让我们来看看。 假设你是按1：6的配比方法，你的SATA转盘能够以100 MB/s的速度写。 6个OSD，每个OSD使用企业SSD分区上的分区作为。进一步假设SSD能够以500MB/s写入。

恭喜你，在那种情况下，你刚刚使你的SSD成为瓶颈。虽然你的OSDs聚合带宽支持600 MB / s，你的SSD限制你大约83％的性能。

在这种情况下，你实际上可以用1：4的比例，但使你的聚合带宽只快了一点点，SSD的没有很大的优势

现在，当然，考虑另一种选择：如果你把你的journal放在OSD相同的设备上，那么你只能有效地使用一半的驱动器的标称带宽，平均来说，因为你写两次到同一设备。 所以这意味着没有SSD，你的有效单个osd带宽只有大约50 MB/s，所以你从6个驱动器中得到的总带宽更像是300 MB/s，对此，500MB/ s仍然是一个实质性的改进。

所以你需要将自己的配比匹配到上面的计算当中，并对价格和性能进行自己的评估。 只是不要认为SSD journal将是万灵药，也许使用ssd算是一个好主意，关键在于比较

使用all-flash OSDs

有一件事要注意，你的SSD journal不会提高读。 那么，怎样利用SSD的提高读取呢？

使用ssd做OSD。 也就是说，不是OSD journal，而是具有文件存储和journal的OSD。 这样的ssd的OSD不仅仅是写入速度快，而且读取也会快。

将 all-flash OSDs 放入独立的CRUSH root

假设你不是在全闪存硬件上运行，而是运行一个经济高效的混合集群，其中一些OSD是普通的，而其他是SSD（或NVMe设备或其他），你显然需要单独处理这些OSD。 最简单和容易的方法就是，除了正常配置的默认根之外再创建一个单独的CRUSH根。

例如，您可以按如下所示设置CRUSH层次结构：

-14.85994root

在上面的示例中，OSDs 0-8分配到默认根，而OSDs 9-17（我们的SSD）属于根highperf。 我们现在可以创建两个单独的CRUSH rule：

默认crush rule 是replicated_ruleset，从默认根选择OSD，而step take highperf在highperf_ruleset当中意味着它只会选择在highperf根的OSD。

为存储池池指定all-flash rule

将单个池分配给新的CRUSH crule（并因此分配给不同的OSD集），使用一个命令：

…其中是池的名称，是您的CRUSH RULE的ID。 你可以在线执行此操作，而客户端正在访问其数据 - 当然会有很多remapped和backfill，因此您的整体性能会受到一些影响。

现在，假设你的环境普通存储比SSD存储更多。 因此，您将需要为all-flash OSD选择单独的池。 这里有一些池可以先迁移到 all-flash。 您可以将以下列表解释为优先级列表：在向群集添加更多SSD容量时，可以逐个将池移动到全闪存存储。

Nova ephemeral RBD池（vms，nova-compute）

radosgw bucket indexes .rgw.buckets.index and friends） - 如果你使用radosgw替换你OpenStack Swift

Cinder volume pools (cinder, volumes)

radosgw> 来源： Openstack私有云