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