從架構細節到實施過程，如何基於Ceph做雲存儲設計

最新 06-14

導讀ID:TOP100case

導讀：最近幾年，全球的數據量出現爆炸式增長，大數據存儲需求發生了很大變化。數據量的大小由TB級增長至PB級，並仍在不斷增長，企業日益將數據的深度分析作為利潤增長的支撐點。隨著社會的發展，各行業、各領域的數據量都會不斷地增長，數據量的急劇增長不斷對存儲系統提出新的挑戰，雲環境下的大數據存儲成為未來數據存儲的發展趨勢。

本案例將從技術選型、架構細節、實施過程三個方面深入解說如何基於Ceph的雲存儲設計平安雲。

（全文共4425字預計閱讀時長：5分鐘）

問題的提出

隨著平安互聯網金融的快速發展，帶來數據爆炸式增長，傳統的存儲模式（SAN、NAS）已經不能滿足該類數據海量、高速增長的要求，需要打造一個全新的存儲平台，提供下一代海量數據存儲解決方案。主要體現在以下兩個方面。

1.1 平安雲

始建於2013年，其目的是為了打造一個可以整合整個基礎架構資源，來支撐互聯網金融快速發展的金融雲平台。圖1所示。

圖1 平安雲平台

在完成計算虛擬化之後，其後端存儲仍然使用傳統的集中存儲模式，隨著業務的快速增長，存儲已然成為性能及容量瓶頸，如圖2所示，創建一個全新的存儲虛擬化平台迫在眉睫。

圖2 業務爆炸式增長存儲成為瓶頸

1.2 存儲瓶頸的隱患

平安的影像系統平台管理著全集團的圖片、語音、視頻、文檔等非結構化數據，並分別在深圳數據中心和上海數據中心相互備份數據。隨著互聯網金融的快速發展，該類數據的也在急劇增長，數據量已經達到PB級，並且承擔每天千萬次實時訪問請求，漸漸已經不堪重負，必須要做出改變，如圖3所示，主要體現在以下兩點：

使用傳統NAS做終端存儲，上海和深圳加起來共計有上千個NAS卷，並錯綜複雜的關聯在上百台伺服器上，並且每年有大批量NAS卷過保需要進行數據遷移，卷管理已經越來越複雜。

每個文件的索引結構都是通過關係型資料庫存儲在Oracle中，每一次上傳和查詢都需要進行資料庫訪問，峰值可以達到每秒上千次操作，資料庫已經逐漸成為性能瓶頸隱患。

圖3 平安影像系統急需做出改變

實踐過程

介紹一下整個雲存儲平台建設的整個過程。

2.1 技術選型

我們更期望選擇適合平安的存儲系統，最終目標不僅是構建一套完整的IT基礎架構，更重要地是透過先進的功能、技術實現基礎架構在性能、功能上的改善和提升，為業務發展打下堅實的基礎。

為了實現此目標，我們先是評估了OpenStack Swift，看了GlusterFS，了解了DDN的WOS，而最終選擇了Ceph。

選擇Ceph的原因

統一的存儲

一套軟體可以解決塊存儲、對象存儲、文件系統三種存儲協議，大大降低了未來技術維護的難度。

軟體定義存儲

能夠將所有存儲相關的控制工作都僅在相對於物理存儲硬體的外部軟體中，具備極高的靈活性。

良好的伸縮性

支持使用X86硬體，存儲規模可以動態伸縮，滿足應用和用戶規模增長的需要。

易於維護

部署相對簡單容易，並且自身支持自動檢測、自動修復，大大降低了維護的難度。

Ceph技術架構的三種介面

Ceph技術架構的三種介面如圖4所示。

RGW：支持S3和Swift介面，適用於靜態數據基於REST協議使用。

RBD：快照、克隆。適用於虛擬機、資料庫以塊存儲方式使用。

CEPH-FS：Posix介面，支持快照。適用於文件系統方式使用。

圖4 Ceph技術架構的三種介面

目前RBD與RGW（RADOSGW的簡稱，本文後續都簡稱為RGW）的成熟度已經可以在生產上使用，CEPH-FS近期達到生產運行標準，更多處在驗證和嘗試階段。在平安使用RBD與平安雲進行對接，為KVM虛擬機提供存儲服務能力。RADOSGW未來將會替代影像系統平台，成為非結構化數據內容管理平台。

技術細節

下面使用兩張圖分別介紹RBD和RADOSGW的技術細節。

RBD技術架構（紅框是平安的應用路線），如圖5所示。

圖5 RBD技術架構

隨著OpenStack的快速崛起，越來越多的人使用Ceph做為OpenStack的後端存儲，而Ceph也不負眾望，表現出良好的性能和穩定性，現在Ceph在OpenStack的塊存儲佔有率已經超過50%，甚至在Linux Kernel的2.6.34以後版本也加入了RBD的模塊，可見RBD在塊存儲領域發展前景還是非常好的。

RGW技術架構如圖6所示。

圖6 RGW技術架構

AWS是全球雲計算的領軍人物，其在2009年推出了S3（Amazon Simple Storage Service）服務，是一個Web 應用程序開發人員可以使用它存儲數字資產（包括圖片、視頻、音樂和文檔）的服務。S3 提供一個 RESTful API 以編程方式實現與該服務的交互，這也是最早的對象存儲的體現。

而目前S3協議已經變為業界開發對象存儲的事實標準，Ceph本身就支持S3協議，同時還支持OpenStack的Swift介面協議，以及其自身的Admin協議。

2.2實施過程

硬體選型

在接觸Ceph以前，我們更多做的是應用層面的開發工作，對硬體的知識還停留在家用PC的層面上，猜想無非就是CPU、內存、硬碟的差異，但當真正要為Ceph選擇一個匹配的硬體，並要求能適應平安未來5年的發展需要時，才發現沒有充分的測試真是不容易，我們也吃了不少暗虧。

下面就為大家介紹一下Ceph對硬體的要求。

硬體要與存儲需求適配，如圖7所示。

圖7 硬體與存儲需求適配

X86 PC：必選。X86 PC本身具備計算和存儲能力，並且體積、配置都非常靈活，容易搭配出較優的配置，有其組成的集群具有良好的伸縮性。

磁碟密度高：做存儲，如果沒有磁碟密度高的機器，其成本和容量都是很難接受的。但是磁碟密度也要和實際情況相匹配才行。磁碟密度過低則單位空間內能提供的存儲容量較低，將會帶來較高的成本；而磁碟密度過高會帶來較高的共振及相互影響，導致磁碟損壞的機率也會增高。所以磁碟配比要按照實際情況均衡選擇（平安使用的是2U 12盤）。

熱插拔：磁碟變多了，磁碟損壞應該就是常態，如果磁碟不支持熱插拔，壞一塊硬碟，要整個伺服器停機維護，顯然這種維護方式是不能接受的。

低耗電：集群中的伺服器個數會逐漸增加到成百上千，如果每台伺服器能節約1瓦電，估計整體就能節約1千瓦，絕對不能讓電力成本成為未來的主要成本。所以在CPU和單台磁碟個數的選擇上要進行均衡匹配。

硬體配置要與軟體適配，如圖8所示。

圖8 硬體配比

在圖8中的硬體配比是在平安環境中測試總結得出的，具備一定的參考意義，下面分別進行說明：

CPU：1塊HDD對應一個CPU CORE足夠使用（Erasure Code除外）。

內存：正常情況下，1TB的磁碟容量需要對應1GB的內存，但是如果存儲的都是小文件（1MB以下認為是小文件），內存則需要更大，1TB容量對應1.5GB內存。

磁碟：Ceph存在Journal機制，用來進行加速。而Journal需要放在SSD上，建議使用Intel S3700做為Journal使用，而1塊SSD可以對應5塊HDD使用。

模擬真實場景進行測試

充分的測試，是一個軟體系統達到生產應用級別的重要保障，而往往我們在制定測試方案時，更多關注的是重現真實的應用場景，往往會忽略硬體是否與真實生產匹配。所謂硬體匹配是指測試時要使用生產即將使用的機型，要品牌相同、型號相同、配置相同，以此來降低風險。

下面為大家介紹平安應用Ceph過程中遇到的問題和優化。

Bucket Index性能瓶頸

在Amazon S3中，定義了租戶、Bucket、Object概念，租戶代表租用空間下的用戶，Bucket則表示其租用空間下的一個數據分類，而Object是分類下的數據對象。在Ceph中底層的支持集群為RADOS，其本身是一個分布式對象存儲集群，它會將一起數據都當做對象文件來對待，而Bucket就是被當做一個對象存儲在磁碟上。

但是對象存儲定義Bucket需要同步知曉其下數據對象的變化，例如個數、列表、總大小等，所以只要對此Bucket中的數據進行變更，就需要同步更新對應的Bucket，而Bucket又是做為一個數據對象存儲在某塊硬碟、某台主機上，其效率就會受限於單個硬體設備性能。

經過測試，在將Bucket放到HDD（7200轉）上，然後進行單Bucket 100KB隨機並發寫，其IOPS最高只能在100～200之間，整個存儲集群IO利用率極不均衡，主要原因是Bucket的index成為瓶頸，性能低下，我們需要對其進行優化，如圖9所示。

圖9 Bucket優化

首先會將Bucket進行虛擬化，用戶在創建Bucket時，後台將其虛擬化成100份，用戶在實際訪問時會基於Hash演算法將請求均勻分布在虛擬化後的Bucket上，這樣就成功分散一個Bucket的瓶頸壓力。經過測試，實施Bucket虛擬化後，再執行單Bucket 100KB文件並發寫測試，其IOPS可以提升到500～800之間，效果和預期相符。

繼續優化，引入SSD進行加速，調整Crush規則，將Bucket Index對象全部存放在SSD上，利用SSD小文件高速讀寫能力，來提升訪問Bucket Index的IO性能。加入SSD後，再次進行測試，IOPS可以達到1000以上，單個Bucket已不再是瓶頸，瓶頸已經轉移到整個集群的磁碟數量上，基本滿足性能要求。

小文件數據遷移內耗較高

Ceph本身會對Object進行分塊（條帶化），假如設置4MB一個條帶，當Object對象大於4MB時，會以4MB為基準對文件進行拆分，而對於小於4MB的對象則保持不變。

RGW主要是用來管理靜態數據，其中會存儲著海量的圖片數據，而在金融行業圖片更多是50～500KB的小文件。而HDD的小文件的隨機寫IO性能一向低下，我們測試過，使用一塊7200轉的HDD，4KB小文件隨機寫的IOPS也就在75～100之間，讓人難於接受。

在這種數據環境下，一旦進行大批量的機器擴容，為了保證數據均衡，必然會實施大量的數據遷移，而因HDD處理小文件隨機寫效率低，就會佔用更多磁碟的IO來進行數據遷移，則會大大影響用戶正常訪問。但是如果不能大量快速的擴容，如何談其伸縮性。

為了避免擴容帶來大量的數據遷移，又要保證具備良好的擴展性，但是又不能土豪的都換成SSD，最後決定採取對集群分套策略，如圖10所示。首先開發一個路由伺服器，負責管理所有訪問的路由策略，來達到較好的擴展性和多個集群的性能。

圖10 對集群分套策略

其訪問過程變為：

應用服務非同步通過路由服務獲取路由策略，並將策略持久化本地。

在發生數據寫時，通過本地的最新路由策略來決定數據應該寫入哪個集群中。

應用服務定時通過路由服務更新最新的路由策略。

路由服務可以對所有集群設置權重和路由規則，自動進行路由策略切換。

此優化方式雖然解決了小文件數據遷移的問題，但是較為遺憾的是破壞了Amazon S3的協議標準，後續可以考慮是否有更好的解決辦法。

多數據中心備份優化

對於金融行業，數據異地備份是必不可缺少的功能，Ceph提供了RGW-AGENT來實現異地備份的要求。但是直接使用原生態的AGENT還是存在不少問題，特別是它無法以Bucket維度進行備份，只能備份整個集群讓人較難接受。我們在此基礎上進行優化，如圖11所示。

圖11 Bucket維度多數據中心數據同步

數據調閱異常策略進行重定向嘗試

既然數據已經在多個數據中心都有副本，我們當然期望當訪問某個數據中心的數據異常後，如果在其他數據中心有其備份時，可以自動重定向到其他數據中心獲取，甚至期望可以通過Bucket的維度來定義它重定向規則，如圖12所示。我們準備在RGW的Apache上開發一個模塊來實現此功能，在編寫此文檔時，此功能還在開發中。

從接觸Ceph開始到現在已經有15個月了，雖然我們已經將其程度推向生產，並逐漸應用範圍再逐漸擴大，但是其本身還是有很多問題需要解決的。例如：Scrub帶來高IO消耗，是否可以不做Scrub？Journal帶來雙倍IO，未來New Store是否可以改善？等等。我們期望可以和Ceph一起相互補足共同向前發展。