在前面一篇文章中，我們看到，當使用filestore時，osd會把磁盤分成data和journal兩部分。這主要是為了支持object的transaction操作。我的想法是，ceph需要具有數據保護功能，從client端寫入的數據（以返回I/O Completion為標志）不能丟失。對於object為什么要使用journal，ceph官方也給出了解釋：
-
速度：有了journal分區后，寫數據速度更快。這主要是因為journal的寫都是順序寫。
-
一致性：ceph要求I/O操作是原子性的，比如更新PG的元數據。
當然，有些人對此提出異議，因為以這種journal方式保持數據一致性的做法ext4也能干，為什么還要自己單獨整一個？正好這個問題opennebula有一個討論，正方的理由是ceph需要自己管理transaction，依賴文件系統沒有辦法獨立自主，而且文件系統層面無法把ceph的數據和其元數據關聯起來。
回到正題，我們先來看看一個I/O寫是如何處理的，引用ceph.com一篇文章的說法（具體網址在參考資料處）：
大致的過程是先寫primary osd的journal部分，使用libaio的DIO，然后使用writev向filesystem發起buffer-io。每隔一段時間fsync把buffer-io落盤。整個過程跟文件系統的journal處理方式類似。Replicated部分也是按照這個流程走。下面這個圖更直觀地描述了osd對I/O的處理。
不過上面並沒有指出osd什么時候返回I/O Completion，根據代碼分析，osd會在寫完journal后完成本次的I/O操作（Replicated 部分也一樣）。最后的落盤會有其他的線程來處理。
下面用一個例子來描述journal寫的部分細節。
我們操作的osd所在的盤被按照如下方式配置
在client進行寫操作時，可以看到這個osd上有3個線程在進行I/O，其中有兩個是實際的落盤操作，1個是journal寫。
進一步通過blktrace看看這個journal寫，如果下發10個隨機寫I/O（4KB），則對應的有10個journal寫。這10個寫都是16個sector，即8KB。那么可以推斷，多出來的4KB是journal的元數據。並且，這10個I/O都是按照LBA順序寫入。
通過對journal線程的分析，可以發現寫請求都是通過io_submit發出的，說明使用的是AIO，並且類型是pwritev。
這在ceph的配置文件中也能看到：
從代碼看，ceph直接使用libaio提供的API函數io_submit。
對比osd端和client端的I/O操作
client端在0.0135s處就完成了所有的寫操作，而physical端這時候只完成了所有的journal操作，那么可以推斷，寫操作只是當journal完成后就立即返回給client：原因是physical端journal寫之外的操作在0.56s才開始，這已經跟第一個寫完成相隔50多ms。
從代碼上看，當osd收到寫請求后，會先進行journal transaction然后將實際的I/O queue起來。
不同的client i/o blocksize產生的日志寫
blocksize為16KB 時=> 16KB+4KB
blocksize為32KB時=> 32KB+4KB
blocksize為64KB時=> 4KB+64KB+4KB
blocksize為128KB時=> 4KB+128KB+4KB
可以推斷當bs<=32KB時，4KB日志與data放在一起，而當大於這個值后，變成2*4KB日志，並且與用戶數據置於不同的vector。
從測試的數據可以看出，引入journal后，一次寫：I/O至少為ReplicatedNum*2，數據量大於ReplicatedNum*2*（Blocksize+JournalMetaData）。當blocksize越大時，Overhead越小，那么可以通過在client端合並數據（比如使能rbd的cache功能）來減小overhead。
以SSD作為osd journal提升Ceph寫性能
由於寫入journal后I/O會立即返回，所以提高性能最簡單的方法就是把journal放到SSD上。關於osd journal使用SSD的性能數據可以參考redhat和seagate的測試數據（具體來源見參考資料3）。
加入SSD后的4MB隨機寫帶寬性能（一個DC S3700搭配4個osd），每節點大概提升2倍。
加入SSD后的4KB隨機寫IOPS性能（一個DC S3700搭配4個osd），每節點大概提升1.5到3倍。
總結
本文主要介紹了ceph的journal寫，並通過實例說明journal帶來的overhead；journal部分是用戶優化的一個重點，可以將高性能的SSD作為journal的存儲。不過，filestore並不是唯一選擇，代表未來發展方向的Bluestore使用全新的設計能夠更大地發揮SSD的性能，已經受到越來越多的關注。
說明
本文最先發布於公眾號《存儲技術最前線》 ，歡迎關注獲取最新技術資訊！
參考資料
1，http://docs.ceph.com/docs/master/rados/configuration/journal-ref/
2，http://lists.opennebula.org/pipermail/ceph-users-ceph.com/2015-October/005479.html
3，https://www.redhat.com/en/files/resources/en-rhst-ceph-seagate-partner-tech-detail-INC0231356.pdf