戳藍字“CSDN云計算”關注我們哦！

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

對于企業業務發展所適配技術而言，根據時間發展，技術更新絡繹不絕，涌現了多種經典組合。早期是單臺設備（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的運行中，我們發現大部分桶中的數據是實時進行同步的，在主從存儲中基本一致，但是少部分桶數據不是實時同步的，而且有可能會相差很大。為此，我們在運維平臺上專門設計了一個功能，用以實現文件同步狀態的檢查，并且當單桶對象文件數量在主從存儲端差異量>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，官方文檔有明確說明http://docs.ceph.com/docs/master/radosgw/encryption/，根據Amazon SSE-C規范在S3中實現。在調研了兩種方法之后，我們選擇了第二種方式實現。

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

在管理便捷性方面，我們開發了云存儲管理平臺，在該平臺上可以很便捷的為用戶創建FTP&SFTP服務，登錄用戶賦權（上傳或下載）。支持在線瀏覽文件內容，下載文件。開發了靜態資源托管的功能，在創建靜態資源桶的時候，會利用我們開發的API自動將桶設置為公共讀，然后使用API或云存儲管理平臺上傳HTML、CSS、JS等文件，支持單個文件和zip包上傳。

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

以上介紹了我們建設云存儲的一點技術歷程，下面對我們建設云存儲的一些心路歷程進行一些總結。首先，上級的支持。其包括人員和資源的支持，也包括項目進度與范圍的控制審視，這些都是非常重要的。例如，良好完備的人員配置。我們的項目由一個項目負責人（總體負責把控項目進度和需求），兩個開發人員（負責程序前后端開發），兩個運維人員（負責基礎設施運維、需求收集和功能測試），一個項目管理師（負責輔助項目的進度安排）構成，其中角色包括開發、運維、需求、項目管理、測試，一一齊全，這讓項目能夠順利有序開展如虎添翼。

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

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

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

? 文章轉自云技術實踐

1.微信群：

添加小編微信：color_ld，備注“進群+姓名+公司職位”即可，加入【云計算學習交流群】，和志同道合的朋友們共同打卡學習！

2.征稿：

投稿郵箱：liudan@csdn.net；微信號：color_ld。請備注投稿+姓名+公司職位。

推薦閱讀

• 程序員怒了！阿里 Antd 圣誕彩蛋害我被離職了！

• 云計算到底是怎么玩的？

• 面向對象編程，再見！

• AI女性界的“扛把子”，憑一己之力迫使NIPS改名

• 00后也會「玩」區塊鏈，你對「朝陽」行業焦慮啥 ？| 圣誕特輯
  

• 20k~65k, 2018年最后一波熱門技術崗位, 立刻投簡歷, 跳槽才是加薪的捷徑
  

• 可替代Android的6大開源移動操作系統

• 程序員求助：被領導強行要求寫Bug該怎么辦？網友的回答讓我笑翻
  

點擊“閱讀原文”，打開 CSDN App 閱讀更貼心！

喜歡就點擊“好看”吧！

總結

以上是生活随笔為你收集整理的企业云存储建设之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。