使用ceph作為存儲的openstack，看到一篇非常非常有價值的文章，這篇文章整理了openstack結(jié)合ceph的最佳方式，包括了一些openstack使用ceph后的參數(shù)優(yōu)化，以及SSD OSD磁盤的使用方式建議，一些pool池的使用建議，解答了相當一部分的疑惑。

Ceph和OpenStack是一個非常有用和非常受歡迎的組合。 不過，部署Ceph / OpenStack經(jīng)常會有一些容易避免的缺點 - 我們將幫助你解決它們。

使用 show_image_direct_url and the Glance v2 API

使用ceph的RBD（RADOS Block Device）,你可以創(chuàng)建克隆,你可以將克隆理解為可寫的快照（快照通常是只讀的）。克隆只會為相對于父快照變化的部分創(chuàng)建對象，這意味著：

可以節(jié)省空間。這是顯而易見的，但是這并不能很有說服力，畢竟存儲是分布式系統(tǒng)當中最便宜的部分

克隆中沒有修改的部分還是由原始卷提供。這很重要，因為很容易命中相同的RADOS 對象，相同的osd，不論是用的哪個克隆。而且這意味著，這些對象是從OSD的頁面緩存進行響應，換句話說，是RAM提供。RAM比任何存儲訪問方式速度都快，所以從內(nèi)存當中提供大量的讀取是很好的。正因為這樣，從克隆的卷提供數(shù)據(jù)讀取，要比相同數(shù)據(jù)全拷貝的情況下速度要快一些

Cinder（當從image創(chuàng)建一個卷）和Nova(從ceph提供臨時磁盤)都能夠使用ceph的后端的RBD image的克隆，并且是自動的，但這個只有在glance-api.conf中設(shè)置了show_image_direct_url=true 才會使用，并且配置使用 Glance v2 API進行連接Glance。

[[225735]]

設(shè)置 libvirt/images_type = rbd on Nova compute nodes

在NOVA中（使用libvirt的KVM計算驅(qū)動），有幾個存儲臨時鏡像的配置，不從Cinder卷啟動的情況。你可以設(shè)置 nova?compute.conf 的[libvirt]當中的images_type：

[libvirt]  
images_type = <type> 

默認的類型是磁盤，這意味著你啟動一個新的vm的時候，將會發(fā)生下面的事：

nova-compute在你的虛擬機管理節(jié)點上鏈接到Glance API,查找所需要的image，下載這個image到你的計算節(jié)點，默認在/var/lib/nova/instances/_base路徑下

然后會創(chuàng)建一個qcow2文件，使用下載的這個image做它的backing file

這個過程在計算節(jié)點上會占用大量的空間，并且會一旦這個鏡像沒有提前在計算節(jié)點上下載好，就會需要等很久才能啟動虛擬機，這也使得這樣的vm不可能實時的遷移到另外一臺主機而不產(chǎn)生宕機時間

將images_types設(shè)置為rbd后意味著disk是存儲在rbd的后端的，是原始鏡像的克隆，并且是立即創(chuàng)建的，沒有延時啟動，沒有浪費空間，可以獲得所有克隆的好處，參考文檔

在Nova計算節(jié)點上啟用RBD緩存

librbd是支持Qemu / KVM RBD存儲驅(qū)動程序的ceph的庫，可以使用虛擬化主機的RAM進行磁盤的緩存。你應該使用這個。

是的，它是一個可以安全使用的緩存。 一方面，virtio-blk與Qemu RBD 驅(qū)動程序的組合將正確地實現(xiàn)磁盤刷新。 也就是說，當虛擬機中的應用程序顯示“我現(xiàn)在想在磁盤上存儲此數(shù)據(jù)”時，virtio-blk，Qemu和Ceph將一起工作，只有在寫入完成時才會報告

• 寫入主OSD
• 復制到可用的副本OSD
• 只是寫入所有的osd journal才會acknowledged

此外，Ceph RBD具有一個智能保護：即使它被配置為write-back緩存，它也將拒絕這樣做（這意味著它將 write-through模式操作），直到它接收到用戶的第一次flush請求。 因此，如果你運行一個永遠不會這樣做的虛擬機，因為它被錯誤配置或者它的客戶操作系統(tǒng)很老的，那么RBD將固執(zhí)地拒絕緩存任何寫入。 相應的RBD選項稱為 rbd cache writethrough until flush，它默認為true，你不應該禁用它。

你可以通過修改nova-compute 配置文件的下面選項開啟writeback caching

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

你應該這樣去做

為images, volumes, and ephemeral disks使用單獨的池

現(xiàn)在你已經(jīng)在Glance開啟了enabled show_image_direct_url=true，配置Cinder and nova-compute與Glance交互 的時候使用 v2 API, 配置 nova-compute使用 libvirt/images_type=rbd，所有的VMs和volumes都使用rbd克隆，克隆可以跨存儲進行，意味著你可以創(chuàng)建RBD image(已經(jīng)快照)在一個存儲池，然后它的克隆在另外一個存儲池

你應該這樣做，有幾個原因：

單獨的池意味著您可以分別控制對這些池的訪問。 這只是一個標準的緩解危險方法：如果您的nova-compute節(jié)點被攻破，并且攻擊者可以損壞或刪除臨時磁盤，那么這是壞的 - 但如果他們也可能損壞您的Glance圖像那將會更糟。

單獨池也意味著您可以有不同的池設(shè)置，例如size或pg_num的設(shè)置。

最重要的是，單獨的池可以使用單獨的crush_ruleset設(shè)置。 下面我們會做介紹

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

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

在這篇文章的建議中，這一個可能是最令人感覺到奇怪和不認可的。 當然，傳統(tǒng)的情況下都會認為，你應該總是把你的OSD journal在更快的設(shè)備上，并且你應該以1：4到1：6的比例部署ssd和普通磁盤，對吧？

讓我們來看看。 假設(shè)你是按1：6的配比方法，你的SATA轉(zhuǎn)盤能夠以100 MB/s的速度寫。 6個OSD，每個OSD使用企業(yè)SSD分區(qū)上的分區(qū)作為。進一步假設(shè)SSD能夠以500MB/s寫入。

恭喜你，在那種情況下，你剛剛使你的SSD成為瓶頸。雖然你的OSDs聚合帶寬支持600 MB / s，你的SSD限制你大約83％的性能。

在這種情況下，你實際上可以用1：4的比例，但使你的聚合帶寬只快了一點點，SSD的沒有很大的優(yōu)勢

現(xiàn)在，當然，考慮另一種選擇：如果你把你的journal放在OSD相同的設(shè)備上，那么你只能有效地使用一半的驅(qū)動器的標稱帶寬，平均來說，因為你寫兩次到同一設(shè)備。 所以這意味著沒有SSD，你的有效單個osd帶寬只有大約50 MB/s，所以你從6個驅(qū)動器中得到的總帶寬更像是300 MB/s，對此，500MB/ s仍然是一個實質(zhì)性的改進。

所以你需要將自己的配比匹配到上面的計算當中，并對價格和性能進行自己的評估。 只是不要認為SSD journal將是萬靈藥，也許使用ssd算是一個好主意，關(guān)鍵在于比較

使用all-flash OSDs

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

使用ssd做OSD。 也就是說，不是OSD journal，而是具有文件存儲和journal的OSD。 這樣的ssd的OSD不僅僅是寫入速度快，而且讀取也會快。

將 all-flash OSDs 放入獨立的CRUSH root

假設(shè)你不是在全閃存硬件上運行，而是運行一個經(jīng)濟高效的混合集群，其中一些OSD是普通的，而其他是SSD（或NVMe設(shè)備或其他），你顯然需要單獨處理這些OSD。 最簡單和容易的方法就是，除了正常配置的默認根之外再創(chuàng)建一個單獨的CRUSH根。

例如，您可以按如下所示設(shè)置CRUSH層次結(jié)構(gòu)：

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。 我們現(xiàn)在可以創(chuàng)建兩個單獨的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。 你可以在線執(zhí)行此操作，而客戶端正在訪問其數(shù)據(jù) - 當然會有很多remapped和backfill，因此您的整體性能會受到一些影響。

現(xiàn)在，假設(shè)你的環(huán)境普通存儲比SSD存儲更多。 因此，您將需要為all-flash OSD選擇單獨的池。 這里有一些池可以先遷移到 all-flash。 您可以將以下列表解釋為優(yōu)先級列表：在向群集添加更多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) - 通常是這是最后一個轉(zhuǎn)換為 all-flash 的池。

配置一些具有低延遲本地存儲的非Ceph計算主機

現(xiàn)在，毫無疑問，有一些應用場景，Ceph不會產(chǎn)生你所需要的延遲。 也許任何基于網(wǎng)絡(luò)的存儲都無法滿足。 這只是存儲和網(wǎng)絡(luò)技術(shù)最近發(fā)展的直接結(jié)果。

就在幾年前，對塊設(shè)備的單扇區(qū)非緩存寫入的平均延遲大約為毫秒或1000微秒（μs）。 相比之下，在承載512字節(jié)（1扇區(qū)）有效載荷的TCP分組上引起的延遲大約為50μs，這使得100μs的往返行程。 總而言之，從網(wǎng)絡(luò)寫入設(shè)備（而不是本地寫入）所產(chǎn)生的額外延遲約為10％。

在過渡期間，對于相同價格的器件的單扇區(qū)寫入本身約為100μs，頂級的，一些價格還是合理的設(shè)備下降到約40μs。 相比之下，網(wǎng)絡(luò)延遲并沒有改變那么多 - 從千兆以太網(wǎng)到10 GbE下降約20％。

因此，即使通過網(wǎng)絡(luò)訪問單個未復制的SSD設(shè)備，現(xiàn)在的延遲將為40 + 80 = 120μs，而本地僅為40μs。 這不是10％的開銷了，這是一個驚人的三倍

使用Ceph，這變得更糟。 Ceph多次寫入數(shù)據(jù)，首先到主OSD，然后（并行）寫入所有副本。 因此，與40μs的單扇區(qū)寫操作相比，我們現(xiàn)在至少有兩次寫操作的延遲，再加上兩次網(wǎng)絡(luò)往返，即40×2 + 80×2 =240μs，是本地寫延遲的6倍

好消息是，大多數(shù)應用程序不關(guān)心這種延遲開銷，因為它們延遲不是關(guān)鍵的。 壞消息是，有些非常在意。

所以，你應該放棄Ceph因為這樣嗎？ 不。 但是請考慮添加一些未使用libvirt / images_type = rbd配置的計算節(jié)點，而是使用本地磁盤映像。 將這些主機進行主機聚合，并將它們映射到指定的flavor。 建議您的用戶，他們選擇這種flavor來跑低延遲的應用程序。