OpenStack经常使用Ceph的正确形式

经常使用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私有云