企業金融雲端儲存建設之路

當前世界形勢千變萬化，各種技術創新層出不窮，新興業務模式也是波譎雲詭，企業的資訊化建設如何緊跟業務，適應業務乃至驅動業務轉型是各級管理者的頭等題目。對於底層執行者，如何能夠快速滿足企業的要求，如何緊跟當前業界技術發展趨勢，對其也提出了明確且緊張的學習要點。

對於企業業務發展所適配技術而言，根據時間發展，技術更新絡繹不絕，湧現了多種經典組合。

早期是單臺裝置（PC Server）加上作業系統（Linux、Windows等）直接執行，沒有什麼高可用的概念，資料直接存放到伺服器磁碟上，資料保護方式和技術更是簡陋。

在企業發展中期，技術便湧現了許多選擇，更因為單臺硬體裝置能容納的資源越來越多（最恰當得解釋便是摩爾定律），出現了各種虛擬化技術，包括UNIX虛擬化技術，例如PowerVM、vPar等，非常好用；基於Linux的虛擬化技術KVM、XEN、ESXI等；基於Windows的虛擬化技術Hyper-v等，儲存更是誕生了各種集中儲存技術（IBM DS、EMC VMAX、HP EVA等），這些技術為企業業務的發展保駕護航，無後顧之憂。

後期，企業業務發展不甚明瞭，各種成本的投入產出比（ROI）要求更加嚴格，此時，急切需要“物美價廉”的技術為發展“添磚加瓦”。

基於IaaS的雲端計算產品組合OpenStack+Ceph，基於PaaS的雲端計算產品組合Docker+Kubernetes+Ceph（GlusterFS等）都構成了某些層級的事實性標準，這些組合為業務發展迴圈不斷貢獻力量。從技術角度分類，其中包含兩個方面，計算和儲存，計算是解決執行時的問題，把業務形式進行串聯，使其運轉更加高效。儲存是解決狀態保持的問題，需把業務語言翻譯成計算機語言，然後進行加工並儲存，分析使其產生巨大價值，甚者更是可以驅動業務。今天我們要討論的就是如何利用這個價值，價值是如何接入的，又是如何反饋的。

在經過多種類（Ceph、GlusterFS和HDFS）和多維度選型之後，我們選擇以Ceph為基礎進行雲端儲存建設。在分析了業務特點和使用場景後，也確定了要自開發的功能。願景是將雲端儲存建設成為一站式服務平臺，所有與資料相關得服務均可在該平臺完成，也包括儲存空間的生命週期流轉，實現有求即有，來之即用，用完即走。如下：

從基礎設施層面，我們首先對儲存叢集節點之間的連通性進行優化。

從儲存節點的物理分佈上，要儘可能分散在不同的機櫃中，避免因為單機櫃掉電，影響儲存對外提供服務.

其次，儲存節點應連線到同一層級的交換機上，鏈路越長，經過節點越多，出問題可能性越高，效能也越差。同時，要充分考慮儲存的主要應用場景和平臺，儘量將它們與儲存放在同一C段，保證最優。

第三，連線管道要足夠粗，儲存節點和交換機全部做成聚合，儲存節點不同網路卡不同埠捆綁成bond4模式，保證出現問題時不影響服務。交換機與之相連埠也需要做成捆綁，否則會形成迴路，造成網路風暴。如果希望增大儲存吞吐量，還需要設定網路包的巨型幀。

專案可能出現的所有問題一定要扼殺在搖籃裡，否則墨菲定律會被一次又一次被證明。例如，網路連線為什麼要用bond4模式，而沒用bond1呢？

在網路連線出現問題時，bond1模式在節點空載情況下，是不丟包的，但是在高負載情況下，一般會丟1-2個包，再加上軟體系統出錯進行糾正的時間，即使有應用系統的重試機制，SLO也是無法滿足的，所以bond1是不夠的。

在儲存物理架構上，儲存叢集實現了3（monitor）+N（OSD）+2（client）的建設形式，實現角色隔離，功能分離，互不影響。3個monitor節點配置有monitor和mgr服務，作為儲存的大腦和監控使用。在N（數量可以線性擴充套件，所以未明確）個OSD節點上進行了一些優化，首先是磁碟的IO排程策略上。

SSD磁碟採用NOOP IO排程策略，NOOP遵循先入先出（FIFO）原則，對請求進行了簡單的佇列處理，NOOP對bio進行了後向合併，最大程度保證相鄰bio進行合併處理，提高了效率。SAS磁碟採用預設的DeadLine IO排程策略，Deadline排程策略對讀和寫進行區分，執行FIFO策略，每個請求會被分配一個時間戳，在讀優先的情況下，可以知道哪個寫請求已經長時間沒有被排程，進行優先排程，避免了寫餓死的情況發生。

其次，基於儲存的讀寫策略設定，我們進行了OSD硬碟型別的混插，SSD硬碟和SAS硬碟按照1：2的比例配置，保證每次讀操作都落在效能較好的SSD硬碟上，同時每次寫操作也會相應提高效率。

第三，我們對讀、寫快取和bluestore快取進行了優化，增加了預讀快取、寫快取和bluestore快取的大小，對整體效能表現提高很多。以下是預讀快取大小的一個效能測試：

第四，我們對Bucket index進行了重新配置，修改crushmap，將其全部放置在ssd高速磁碟上。單個桶索引大概是200 bytes，當單個桶存放大量物件資料時，索引不進行單獨分離或存放在高速磁碟上，會造成效能下降。因此，我們對crushmap進行匯出，反編譯，修改、重新編譯，注入操作，使索引全部放置到ssd磁碟上，減少延遲，提高效能。

最後，我們為儲存設計了一個閘道器，由兩個節點組成，將我們的使用場景和儲存本身完全解耦，即使存在配置失誤或損壞，完全不會影響整個儲存的健壯性和資料完整性。在閘道器節點上安裝了Ceph rgw、Nginx和Pacemaker。由於業務對全域性共享檔案系統讀寫得需求，需利用高可用軟體管理檔案系統並對外暴露，供多個容器對同一檔案系統進行掛載，讀寫資料。所以我們選擇Pacemaker高可用軟體對外提供唯一IP地址，保證服務唯一可訪問性。

眾所周知，rgw單例項在可用性、擴充套件性和效能上存在低效問題，所以我們利用Nginx負載均衡改善效果。我們對外提供三種型別的基礎儲存服務，即物件儲存、塊儲存、全域性共享儲存。

在儲存效能優化設計方面，我們大概做了以上五點。當然，還有一些小的優化在這裡就不詳細介紹了，比如TCMalloc引數調整，ulimit引數調整，kernel pid_max引數調整等。

在儲存資料保護方面，我們應用了Ceph原生的multisite資料同步技術。在同城另一個機房建立一套分散式儲存，作為主機房分散式儲存的備份。兩機房間通過10GB資料專線進行連線，保證資料傳輸頻寬。在設計和實施上沒有進行特別優化，基本根據社群要求進行。這裡我想重點說一下multisite的後期執行和維護問題。在上線後multisite的執行中，我們發現大部分桶中的資料是實時進行同步的，在主從儲存中基本一致，但是少部分桶資料不是實時同步的，而且有可能會相差很大。為此，我們在運維平臺上專門設計了一個功能，用以實現檔案同步狀態的檢查，並且當單桶物件檔案數量在主從儲存端差異量\u0026gt;10時，會自動觸發資料同步，從而保證了資料的安全性和完整性。

從儲存適配方面，我們根據S3 API開發了一整套完整功能的、適用我們的crud API和SDK，包括物件儲存和塊儲存。其中物件儲存API直接開放給開發人員使用，支援檔案以目錄形式進行儲存。塊儲存API開放給容器雲平臺，在容器雲平臺可以直接操作雲端儲存塊裝置，進行建立、檢視和刪除等操作。

同時，針對金融行業的特點，我們自研了檔案加密功能與上傳下載（FTP和SFTP）功能。

對於檔案加密功能，金融行業涉及很多資質檔案、身份證和銀行卡資訊，所以為了符合監管要求，必須要進行加密。在開發加密功能的過程中，我們調研了兩種方法，一種是開啟https進行加密，rgw_crypt_require_ssl值預設設定為true，利用openssl生成crt和key證書，然後載入到ceph.conf的rgw_frontends選項中，同時需要在API載入該私鑰證書予以生效。第二種方法是關閉rgw_crypt_require_ssl，不啟用https加密，而是在http下采用Server-side Encryption，官方文件有明確說明，根據Amazon SSE-C規範在S3中實現。在調研了兩種方法之後，我們選擇了第二種方式實現。

因為業務場景要求，我們利用開源的Apache Commons VFS和Ftp Server自研了FTP和SFTP Server功能，連線物件儲存和檔案系統。在訪問入口處部署了路由功能，讓廣大商戶有選擇的從儲存某區域上傳下載檔案，最終達到控制使用者使用哪種協議（FTP或SFTP）在哪些區域（檔案系統或桶）進行指定操作（上傳或下載）的目的。

在管理便捷性方面，我們開發了雲端儲存管理平臺，在該平臺上可以很便捷的為使用者建立FTP\u0026amp;SFTP服務，登入使用者賦權（上傳或下載）。支援線上瀏覽檔案內容，下載檔案。開發了靜態資源託管的功能，在建立靜態資源桶的時候，會利用我們開發的API自動將桶設定為公共讀，然後使用API或雲端儲存管理平臺上傳HTML、CSS、JS等檔案，支援單個檔案和zip包上傳。

儲存桶具備健康檢查功能，方便開發人員自測。支援Ceph使用者屬性檢視和配置，支援桶屬性和配額的線上檢視和配置。另外一個最重要功能是自服務功能。眾所周知，雲端計算的要義是線上橫向擴充套件，功能全面，自服務。我們的自服務支援儲存的申請，自動建立，自動擴容等，配置儲存形成的工單可以顯示審批狀態（審批中、完成、被駁回），建立和擴容儲存支援按使用者要求設定quota，根據需求擴充套件。

以上介紹了我們建設雲端儲存的一點技術歷程，下面對我們建設雲端儲存的一些心路歷程進行一些總結。

首先，做這個的基礎建設需要上級的支援。其包括人員和資源的支援，也包括專案進度與範圍的控制審視，這些都是非常重要的。例如，良好完備的人員配置。我們的專案由一個專案負責人（總體負責把控專案進度和需求），兩個開發人員（負責程式前後端開發），兩個運維人員（負責基礎設施運維、需求收集和功能測試），一個專案管理師（負責輔助專案的進度安排）構成，其中角色包括開發、運維、需求、專案管理、測試，一一齊全，這讓專案能夠順利有序開展如虎添翼。

其次，專案成員的團結協作。在Google SRE的書裡，形容運維和開發之間的關係是”regid boundaries are couterproductive”，但在我們專案裡，開發同事從來沒有因為害怕增加工作量而不推卸功能實現，相反而是積極提出並實現某些新功能，每個人都盡職盡責，多做一絲。專案管理師在其他部門參加會議時，聽到關於可能會使用雲端儲存的需求時，會主動推薦雲端儲存並跟蹤需求，最終使其資料全部上雲。這樣即幫助兄弟部門又很好的推介雲端儲存，一舉兩得。

第三，使用者的支援。使用者是產品的最終使用者，是一個產品好壞的定論者，是一個產品成功推廣使用的推介者。我們需要將產品推廣給儘可能多的使用者使用，發現其中的問題，進行修改補充，再發布，從而形成一個良性迴圈。在公司內部發動所有人通過各種渠道和會議不斷的宣傳雲端儲存是什麼，它的優勢，它的特點。使用者支援才是戰勝波特五力的根本。

第四，詳細完備的解決方案。在進行產品推廣時，需要有一個完善的解決方案，使其形成閉環生態。對於我們雲端儲存而言，需要提供資料接入介面、資料高效執行平臺、資料安全存放技術、資料災難備份方案等，使客戶不為業務外的任何事情擔心。