分佈式存儲介紹
分佈式存儲系統是網絡存儲的一種，依賴於以太網絡實現數據交互。傳統的網絡存儲系統（如NAS）採用集中的存儲服務器存放所有數據，存儲服務器成爲系統性能的瓶頸，並單點故障，不能滿足大規模數據存儲的需要。而分佈式存儲系統，是將數據分散存儲在多臺獨立的存儲節點（服務器）上。分佈式存儲系統採用可擴展的系統結構，利用多臺存儲服務器分擔存儲負荷，可以有效地提高存儲系統的可靠性、可用性和可擴展性。分佈式存儲系統在設計的時候，也需要遵循分佈式系統設計的CAP（一致性、可用性、分區容錯性）原則，具體說明如下：
- 一致性：分佈式存儲系統會使用多臺服務器共同存儲數據，爲了保證在有服務器出現故障的情況下系統仍然可用，會把一份數據分成多份存儲在不同的服務器中，這種做法也稱爲多副本機制。但是由於故障和並行存儲等情況的存在，同一個數據的多個副本之間可能存在不一致的情況。分佈式存儲要極力避免出現副本間數據不一致的情況，所以在副本可用的情況下，分佈式存儲系統都是要求強一致性的，也即一個數據只有對兩個副本的寫都完成才能返回成功。
- 可用性：分佈式存儲系統要求單個（甚至2個）節點的故障不影響整體系統的可用性，這就要求同一份數據的副本必須分佈到不同的節點上。
- 分區容錯性：分佈式存儲要盡力避免網絡中斷造成的分區影響，比如1個或者2個節點的網絡中斷不影響整個集羣的服務能力。這就要求分佈式存儲要對集羣內的節點網絡可用性有良好的探測和隔離機制，一旦某個節點的網絡出現故障、可以被快速的被隔離，集羣內其它好的節點可以根據策略決定是否重建副本。
此外，分佈式存儲還需要考慮節點間的負載均衡和容量均衡，也即負載和容量儘量平均地分配到所有節點上。所以對於分佈式存儲來說，數據分佈算法是核心，目前主流的算法有一致性哈希算法和CRUSH算法。比如Swift對象存儲使用就是一致性哈希算法，Ceph使用的就是CRUSH算法。
分佈式存儲在金融行業的前景
分佈式存儲目前在金融行業還沒有得到大規模的推廣，主要是金融機構現有應用架構對存儲的要求，和分佈式存儲可以提供的能力之間有一定的差距。金融機構目前使用存儲最多的場景主要是共享塊存儲（如數據庫、VMware虛擬化集羣、共享文件系統）。NAS由於在性能和可靠性方面不如SAN存儲，也沒有得到大規模的使用。提供共享存儲恰恰是分佈式存儲的劣勢，目前主流的分佈式塊存儲都基本不提供共享存儲能力，分佈式共享文件系統雖然可以提供共享存儲能力，但是都不支持多文件系統，只能一個存儲集羣提供一個共享文件系統，這距離不同應用使用不同文件系統的要求差距還很大。當然，這並不能說分佈式存儲的設計有很大問題，而是分佈式存儲從誕生之初，就不是用來替代傳統的SAN存儲的。它最初的設計用途是爲了給雲計算的計算節點提供塊和對象存儲能力。雲計算的虛擬機基本沒有共享塊存儲的需求，如果一定需要共享文件，也可以通過對象存儲解決，所以在很長時間對於共享塊存儲的需求是基本忽略的。至於對象存儲，大部分金融機構應該還沒有想好使用場景和使用方式。
分佈式存儲經過十多年的發展，也開始逐漸引入一些傳統SAN存儲支持的能力，希望能夠在企業數據中心拓寬其使用範圍。那麼，現階段分佈式存儲適合於那些應用場景呢？我們根據自己的實踐經驗總結如下：
- 基於KVM虛擬化的雲計算場景：VMware虛擬化集羣僅僅對自家的VSAN支持較好，其它的分佈式存儲只能通過iSCSI方式支持。而iSCSI是一種點對點的存儲通信協議，很容易因爲網絡抖動或者iSCSI機頭設備故障受到影響，此外統一的機頭入口也是性能瓶頸點，無法滿足金融機構對存儲可靠性和高性能的要求。但是如果使用基於KVM虛擬化的雲計算技術就不存在這樣的問題，比如OpenStack，已經能夠很好的將主流的商業和開源分佈式存儲用於爲KVM虛擬機提供塊存儲。
- 容器使用場景：容器技術在發展初期，就很好的擁抱了分佈式存儲技術。容器所需要的持久化存儲就需要依賴分佈式存儲。目前主流的容器編排系統（如Kubernetes）可以很方便的使用各種主流的商業或開源分佈式存儲技術。
- 文件共享場景：傳統的文件共享主要通過共享文件系統、或者FTP來解決。共享文件系統爲了確保不同業務間的數據安全隔離，只能爲一類業務系統建立獨佔的共享文件系統，共享範圍受限，成本高昂。使用FTP可以擴大共享範圍，但是FTP服務性能受限於單個FTP服務器的性能，並且缺少比較好安全管控手段（如白名單）。分佈式存儲，特別是對象存儲就比較適合這種場景，它不存在單點性能瓶頸，分佈式的性能和可靠性也會更高，同時還能提供多租戶的隔離機制。
分佈式存儲發展方向
分佈式存儲最開始的目的是支持雲計算（特別是公有云）和大數據的數據存儲，在這些方面已經證明了自己的能力，現在或者將來的重點方向是走向企業數據中心市場。爲了滿足企業數據中心的要求，分佈式存儲需要重點發展如下能力：
- 共享塊存儲能力：企業數據中心目前對塊存儲的重點需求就是共享塊存儲，誰能更早的滿足這個需求，誰就能更快的打開局面，贏得市場先機。目前個別商業分佈式存儲已經開始逐步支持共享塊存儲的需求，這樣受限就能滿足傳統數據庫和共享文件系統對共享存儲的需求。接下來，還需要繼續推進和主流虛擬化產品（如VMware、KVM）的結合。簡單來說，就是在共享塊存儲能力方面要和傳統的SAN存儲持平。
- 跨數據中心容災能力：分佈式存儲普遍在跨數據中心容災能力上較弱，集羣內多副本機制並不能很好的解決這個問題。企業數據中心希望的容災能力是類似傳統SAN存儲那樣的同城和異地容災能力。傳統SAN存儲能夠做到同城實現數據同步複製，異地實現異步複製。但是目前的分佈式存儲同城之間只能做到異步複製，無法滿足企業對RPO爲零的要求。
- 支持多文件系統的能力：現有的分佈式文件系統都只能支持一個文件系統，在數據隔離性方面不能達到要求。企業數據中心需要的是對多文件系統的支持，把分佈式文件系統看成一個資源池，不同應用可以被分配不同的文件系統，彼此之間完全邏輯隔離，同時提供相應的訪問權限控制機制。
- 混合部署能力：分佈式存儲需要支持在同一集羣內混合部署不同類型存儲池，比如SATA、SAS和SSD，實現分級存儲，滿足不同業務對性能的多樣要求。現有的一些商業或開源分佈式存儲產品已經支持混合部署，但是通常需要去手工編輯類似CRUSH Map這樣的核心配置文件，每次更換或者新增硬盤也都需要手工編輯，這給生產運營帶來巨大的風險，很容易由於誤操作導致數據丟失或者集羣不可用。正確的方式應該是實現對存儲池的全自動化管理，讓分佈式存儲系統自身自動化的識別節點或者硬盤變化，避免人爲干預。
- 硬盤亞健康狀態檢測：分佈式存儲的存儲節點都使用服務器的本地硬盤作爲數據存儲盤，一旦某一個硬盤出現亞健康狀態導致單盤性能下降，將會對整個集羣的性能產生影響。因此需要分佈式存儲自己就能及時發現性能明顯下降的硬盤，並將其隔離出去。
分佈式存儲部署使用原則
分佈式存儲在部署使用的時候，需要充分考慮到將可用性和性能提升到最高，通常應該遵循如下原則：
- 在生產和災備端各構建一個統一的集羣提供存儲供給能力，同一站點不搞多集羣。這樣便於維護，也能最大效率的實用分佈式存儲的橫向擴展能力，降低成本。在統一存儲池內，劃分不同級別的存儲能力，比如SATA和SSD，滿足不同業務類型的需求。
- 從客戶端角度，爲了滿足高速存儲需要的大帶寬，必須構建單獨的萬兆存儲IP網絡，和業務網絡分開。這就要求從網絡設計、服務器選型、佈線接入、虛擬化都要做調整。比如物理服務器必須有額外的存儲網絡接入網卡、虛擬機也必須有額外的存儲虛擬網卡。
- 爲了避免機櫃電源故障導致集羣故障，所有的計算節點和存儲節點都部署在不同列的機櫃中。
- 爲了避免更換故障盤時人爲誤操作導致事故，所有的操作都腳本化、自動化。運維人員所需要做的就是把狀態異常的盤從集羣中剔除，帶新盤更換完畢後，運行一條命令就可以自動發現新盤，並將新盤加入集羣。
- 爲了避免亞健康狀態的硬盤拖累整個集羣的性能，需要部署硬盤亞健康狀態自動監測和自動隔離工具。
- 爲了避免存儲節點重啓後產生大量的數據複製，需要調整分佈式存儲的數據恢復策略，節點宕機或重啓並不做數據rebalance，而是等節點恢復後同步增量數據
- 應用端使用對象存儲，需要充分考慮容災實現，也即在寫入的時候向生產、災備兩個集羣同時寫入，讀取的時候從某一個集羣優先讀取。單個集羣的失效不影響應用的寫入和讀取返回狀態，有些類似存儲端做鏡像的概念。
分佈式存儲部署架構
一個最小規模的可用於生產的Ceph集羣部署架構如下，包含3個Monitor節點和4個存儲(OSD)節點。其中，Monitor節點運行MON、MDS和RGW(RadosGW)實例，是對外提供服務接口的節點；存儲節點主要運行OSD示例，分配和存儲數據。
爲了使集羣性能達到最優，需要使用SSD盤來存放Metadata和journal。這樣每個Monitor節點需要2個SSD盤做Raid來存放Metadata，每個OSD節點需要2個SSD盤(非Raid)來存放journal。私有網絡是用來做節點間消息和數據傳遞，特別是OSD節點間在做數據恢復時會產生大量的I/O，因此OSD節點間的私有網絡都是採用萬兆網絡接入。Monitor節點之間以及Monitor和OSD節點間之間不涉及大吞吐量操作，因此Monitor節點通過千兆網絡接入私有網絡即可，這樣可以節省成本。公共網絡主要用於對外提供存儲服務，因此所有節點都採用萬兆接入。