今年是 RADOS 塊裝置（RBD），Ceph 塊儲存介面誕生後的第十五年。Ceph 是一個分散式儲存系統。它由 Sage Weil 在加州大學聖克魯斯分校的博士論文中啟動，最初的設計只是作為一個從頭開始構建的分散式檔案系統。隨著 Ceph 發展成為一個統一的企業級儲存平臺，除了檔案系統介面外，Ceph 現在還支援物件和塊儲存。RESTful 物件儲存介面（RADOS Gateway，或 RGW），旨在與 AWS S3 相容，以及 RBD，一個塊儲存系統，是後來增加的，擴充套件了 Ceph 的能力。這個週年紀念是一個很好的回顧 RBD 如何誕生的機會。
我於 2008 年加入 Ceph 專案。我的第一次提交是在一月份；那年晚些時候我開始全職工作。一開始就很激動人心。Sage 和我在洛杉磯市中心一棟高層建築的五十層共用一間辦公室。每天午餐時，我們都有一個非常私人的 Ceph 會議。如今，Cephalocon，一年一度的 Ceph 會議吸引了來自世界各地的數百名參與者。那時，Ceph 剛剛從學術界畢業，在 DreamHost （Sage 多年前與人共同創立的一家公司）開始了第二階段的孵化。全職從事 Ceph 工作的總人數就 2 個。
在我工作的第一天，Sage 告訴我，儲存庫裡有一個 TODO 檔案，我應該做我想做的。我把這句話的兩個部分視為兩個不同且獨立的資訊。在看了 TODO 檔案後，我傾向於“我應該做我想做的”，並看到以下內容：
- ENOSPC - 完成客戶端故障恢復（長時間退出後重新連線；以及慢速延遲重新連線）- 使 kclient 使用 ->sendpage？- 移除 io 中斷？缺陷 - 日誌斷言（header.wrap）在 print_header() 中大專案 - ENOSPC- 可執行的配額？- mds 安全執行 - 客戶端，使用者認證 - cas ......在早期，我們能做的事情堆積如山，所以我們真的嘗試探索了很多方向。Sage 最近為 Ceph 新增的快照功能佔用了這個 TODO 檔案的很大一部分。我選擇的第一個專案，ceph.conf 配置系統，它不那麼引人注目，但卻是必不可少的。在此之前，為了執行任何 Ceph 命令，你需要在命令列中傳入所有配置。對於一個學術專案來說，這可能是可以接受的，但任何有用的應用程式都需要一個可行的配置系統。
我們繼續致力於讓 Ceph 檔案系統為黃金時間做好準備，在此過程中，我們還考慮了儲存系統可以做的其他偉大的事情。在 2009 年初，我開始研究一個新的和令人興奮的 RESTful 物件儲存系統（最初命名為 C3，很快切換到臨時名稱 RADOS Gateway 或 RGW）。Ceph 已經有了一個名為 RADOS 的內部物件儲存系統，那麼為什麼不直接透過 S3 API 暴露它呢？結果發現有很多原因可以解釋為什麼將 RADOS 直接 1:1 對映到 S3 不是一個好主意。
RADOS 語義與 S3 相容系統所需的語義有很大不同。例如，RADOS 的物件大小限制相對較小，而 S3 可以支援高達 5TB 的物件。S3 將物件儲存在索引桶中。然而，RADOS 將物件儲存在未索引的池中，因此列出沒有索引的物件是一種非常低效的操作。我們在弄清楚正確的 RGW 架構的過程中遇到了很多這樣的問題。
我探索了一個並行的工作，我們稱之為“活動物件”，這是 Ceph 物件類的前身。我們的想法是讓計算更接近資料，這樣我們就可以擴充套件儲存做更多的事情。在第一次迭代中，你可以推送一個 Python 程式碼片段，然後在 Ceph 物件儲存守護程序（OSDs）中執行。
那時，當你在谷歌上搜索 Ceph 時，大多數搜尋結果要麼是關於公共衛生教育委員會的，要麼是關於電子藝術 Crysis 遊戲系列中的 Ceph 外星物種的。我為“Ceph”關鍵詞設定了一個谷歌新聞提醒，看看是否有人發表了關於我們專案的任何內容。在 2009 年 11 月初，我收到了一個通知，連結到一篇 關於 Sheepdog 的文章，這是一個新的 QEMU 分散式塊儲存系統。這觸發了谷歌新聞提醒，因為有人在評論中建議 Ceph 可能是一個更可行的解決方案。我指著 Sage 說：
我：http://www.linux-kvm.com/content/sheepdog-distributed-storage-management-qemukvm注意評論中的 ceph 引用 Sage：很好！是的，這讓我想到，製作一個塊裝置驅動程式非常容易，只是覆蓋物件 我：是啊.. 我們可能需要花點時間來做這件事，也許有一些 rados 核心客戶端，並且在此基礎上設定一個塊裝置Sage：這意味著清理 monc，osdc 介面.. 但無論如何這可能是件好事.........可以理解的是，我們並沒有為了實現這一點而擱置所有其他工作。我們正忙於實現 CephX，Ceph 的身份驗證和授權子系統（在我們決定如何命名之前，X 是一個佔位符，這是一項我們從未有時間完成的任務）。Ceph 檔案系統核心模組尚未合併到 Linux 核心中，這是我們一段時間以來一直在積極努力實現的一個里程碑。為了保持 Ceph 的真正開放過程，Sage 在接下來的一週釋出了一封郵件列表訊息，介紹了這個想法。他建議了 兩個專案（Weil, Sage, Email to Ceph-devel 郵件列表。2009 年 11 月 11 日）：
- 組裝一個類似的 qemu 儲存驅動程式，使用 librados 儲存影像片段。這應該非常簡單（儲存驅動程式完全在使用者空間實現）。我懷疑最難的部分將是決定如何命名和管理可用影像列表。- 編寫一個 Linux 塊裝置驅動程式，做同樣的事情。這在功能上類似於在 ceph 之上建立一個迴環裝置，但可以避免檔案系統層和與 MDS 的任何互動。這樣做的好處是完全支援 TRIM 和壁壘。幾個月後，Christian Brunner 對我們的行動呼籲做出了回應，他向我們傳送了一個 QEMU 驅動程式的初始實現。我們能夠使用他建立的基礎，並開始準備將其包含到上游 QEMU 中。Ceph 檔案系統模組在幾周內被合併到 Linux 核心中，這對專案來說是一個巨大的成功。我還決定開發第二個核心驅動程式，這次是一個與這個 QEMU 驅動程式相容的塊裝置驅動程式。
這兩個 RBD 驅動程式是兩個獨立的實現；它們之間共享的程式碼非常少，因為其中一個是編寫為在使用者空間執行並與 QEMU 塊介面整合，而另一個是建立為作為 Linux 核心模組執行並實現核心塊驅動程式的介面。兩個驅動程式都非常精簡，並將 I/O 操作轉換為 RADOS 物件操作。一個單一的塊影像被分割成多個小尺寸的 RADOS 物件，這允許操作在多個 OSD 上並行執行，這得益於 Ceph 的橫向擴充套件功能。
我們為兩個 RBD 驅動程式添加了更多功能：用於 RBD 卷的管理工具和對快照的支援。為了使快照正確工作，執行例項需要在建立時瞭解它們。為此，我實現了一個新的 Ceph 子系統，稱為 Watch/Notify，它允許透過 RADOS 物件傳送事件。RBD 例項“監視”其影像元資料物件，管理工具在建立新快照時向其傳送通知。
我們建立的首次使用的另一個子系統是 Ceph 物件類。這種機制允許在 RADOS I/O 路徑中建立專門的程式碼，可以被呼叫以對 RADOS 物件進行變異或進行復雜的讀取操作。第一個物件類被實現以跟蹤 RBD 快照的名稱及其對映到 RADOS 快照 ID。與需要更復雜的鎖或其他機制來處理競爭的動態讀 – 修改 – 寫週期不同，我們只會傳送一個單一的 RBD 快照建立呼叫，它將在 OSD 上原子地完成。
建立 RBD Linux 核心裝置驅動程式需要清理所有 Ceph 核心程式碼，並將通用的 RADOS 程式碼移動到一個單獨的核心庫中。我們在創紀錄的時間內將其納入 Linux 核心。它於 2010 年 10 月在上游被合併，距離檔案系統被合併後僅六個多月。
Christian 繼續幫助 QEMU 驅動程式的開發，現在他回憶起讓 QEMU 驅動程式上游的最困難的部分是：
“當時，為了說服 QEMU 專案相信分散式儲存系統的驅動程式是必要的，我們進行了相當大的討論。”
此外，在 QEMU 專案內部還有一場單獨的討論，討論是否應該合併驅動程式，或者他們是否應該建立一個外掛塊儲存機制，允許外部新增不同的驅動程式，而不需要它們的參與。大約在同一時間，sheepdog 專案也在審查中，並參與了同樣的討論。QEMU 專案開發人員不想處理新驅動程式不可避免會帶來的問題和錯誤。我們和 sheepdog 開發人員都表示我們將處理我們的驅動程式出現的問題。最後，單體路徑佔了上風，並決定將驅動程式作為 QEMU 儲存庫的一部分。
我們經歷了審查過程，並確保我們對審查人員提出的所有問題做出了回應和解決。例如，驅動程式使用的原始執行緒模型是錯誤的，需要解決。最後，在將核心 RBD 驅動程式合併到 Linux 核心幾周後，我們還合併了上游的 QEMU 驅動程式。
從第一個想法到兩個驅動程式被合併，只花了大約一年的時間。整個專案催生了多個子專案，這些專案現在已成為 Ceph 生態系統的基礎。RBD 建立在 RADOS 提供的堅實基礎之上，因此，它得益於所有 Ceph 專案貢獻者的辛勤工作。
RBD 幾乎一夜成名。現在，它成為了虛擬化和雲系統中的關鍵儲存基礎設施。由於其無縫整合和可擴充套件性，它成為了 OpenStack 事實上的標準持久儲存。在 Kubernetes 中，它提供了有狀態容器化應用程式所需的可靠持久儲存層。在傳統的虛擬化和私有云環境中，它提供了一個開放的、分散式的、高可用的虛擬機器儲存，作為專有儲存的替代品。由於許多 Ceph 專案貢獻者和其他與之交叉的專案的努力，它仍在不斷改進和演變。
這是一個展示開源力量的合作努力。希望取代舊 TODO 檔案的內容不會那麼模糊，但不會更短。我們仍然有很多工作要做，還有更多我們甚至無法想象的創新領域。有時，一個想法的火花和一個有願意的社群就是所需要的一切。
感謝 Christian Brunner 和 Sage Weil 提供的寶貴意見。
原文連結：
https://www.infoq.com/articles/ceph-rbd-open-source/
宣告：本文由 InfoQ 翻譯，未經許可禁止轉載。