OpenStack 使用 ceph的正确方式

 

 上面左边是个人我的微信，如需进一步沟通，请加微信。  右边是个人公众号“Openstack私有云”，若有兴趣，请关注。

    使用ceph做为存储的openstack，看到一篇很是很是有价值的文章，这篇文章整理了openstack结合ceph的最佳方式，包括了一些openstack使用ceph后的参数优化，以及SSD OSD磁盘的使用方式建议，一些pool池的使用建议，解答了至关一部分的疑惑。感谢原做者的付出和分享，也感谢“zphj1987”翻译和整理了这篇文章！下面是正文：

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

使用 show_image_direct_url and the Glance v2 API

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

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

2. 克隆中没有修改的部分仍是由原始卷提供。这很重要，由于很容易命中相同的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：

[libvirt] images_type = <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将一块儿工做，只有在写入完成时才会报告

• 写入主OSD

• 复制到可用的副本OSD

• 只是写入全部的osd journal才会acknowledged

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

你能够经过修改nova-compute 配置文件的下面选项开启writeback caching

[libvirt] images_type = rbd ... disk_cachemodes="network=writeback"

你应该这样去作

为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层次结构：

ID WEIGHT  TYPE NAME         UP/DOWN REWEIGHT PRIMARY-AFFINITY - -1 4.85994 root default -2 1.61998     host elk 0 0.53999         osd.0          up  1.00000          1.00000 1 0.53999         osd.1          up  1.00000          1.00000 2 0.53999         osd.2          up  1.00000          1.00000 -3 1.61998     host moose 3 0.53999         osd.3          up  1.00000          1.00000 4 0.53999         osd.4          up  1.00000          1.00000 5 0.53999         osd.5          up  1.00000          1.00000 -4 1.61998     host reindeer 6 0.53999         osd.6          up  1.00000          1.00000 7 0.53999         osd.7          up  1.00000          1.00000 8 0.53999         osd.8          up  1.00000          1.00000 -5 4.85994 root highperf -6 1.61998     host elk-ssd 9 0.53999         osd.9          up  1.00000          1.00000 10 0.53999         osd.10         up  1.00000          1.00000 11 0.53999         osd.11         up  1.00000          1.00000 -7 1.61998     host moose-ssd 12 0.53999         osd.12         up  1.00000          1.00000 13 0.53999         osd.13         up  1.00000          1.00000 14 0.53999         osd.14         up  1.00000          1.00000 -8 1.61998     host reindeer-ssd 15 0.53999         osd.15         up  1.00000          1.00000 16 0.53999         osd.16         up  1.00000          1.00000 17 0.53999         osd.17         up  1.00000          1.00000

在上面的示例中，OSDs 0-8分配到默认根，而OSDs 9-17（咱们的SSD）属于根highperf。 咱们如今能够建立两个单独的CRUSH rule：

rule replicated_ruleset {    ruleset 0    type replicated    min_size 1    max_size 10    step take default    step chooseleaf firstn 0 type host    step emit } rule highperf_ruleset {    ruleset 1    type replicated    min_size 1    max_size 10    step take highperf    step chooseleaf firstn 0 type host    step emit }

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

为存储池池指定all-flash rule

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

ceph osd pool set <name> crush_ruleset <number>

…其中是池的名称，是您的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 data pools (.rgw.buckets and friends) - 若是您须要在Swift存储上进行低延迟读取和写入

• Glance image pools (glance, images)

• Cinder backup pools (cinder-backup) - 一般是这是最后一个转换为 all-flash 的池。

配置一些具备低延迟本地存储的非Ceph计算主机

如今，毫无疑问，有一些应用场景，Ceph不会产生你所须要的延迟。 也许任何基于网络的存储都没法知足。 这只是存储和网络技术最近发展的直接结果。

就在几年前，对块设备的单扇区非缓存写入的平均延迟大约为毫秒或1000微秒（μs）。 相比之下，在承载512字节（1扇区）有效载荷的TCP分组上引发的延迟大约为50μs，这使得100μs的往返行程。 总而言之，从网络写入设备（而不是本地写入）所产生的额外延迟约为10％。

在过渡期间，对于相同价格的器件的单扇区写入自己约为100μs，顶级的，一些价格仍是合理的设备降低到约40μs。 相比之下，网络延迟并无改变那么多 - 从千兆以太网到10 GbE降低约20％。

所以，即便经过网络访问单个未复制的SSD设备，如今的延迟将为40 + 80 = 120μs，而本地仅为40μs。 这不是10％的开销了，这是一个惊人的三倍

使用Ceph，这变得更糟。 Ceph屡次写入数据，首先到主OSD，而后（并行）写入全部副本。 所以，与40μs的单扇区写操做相比，咱们如今至少有两次写操做的延迟，再加上两次网络往返，即40×2 + 80×2 =240μs，是本地写延迟的6倍

好消息是，大多数应用程序不关心这种延迟开销，由于它们延迟不是关键的。 坏消息是，有些很是在乎。

因此，你应该放弃Ceph由于这样吗？ 不。 可是请考虑添加一些未使用libvirt / images_type = rbd配置的计算节点，而是使用本地磁盘映像。 将这些主机进行主机聚合，并将它们映射到指定的flavor。 建议您的用户，他们选择这种flavor来跑低延迟的应用程序。

引用

本篇英文原文

https://www.hastexo.com/resources/hints-and-kinks/dos-donts-ceph-openstack/index.html