金融行業如何使用分散式儲存技術
分散式儲存介紹
分散式儲存系統是網路儲存的一種，依賴於乙太網絡實現資料互動。傳統的網路儲存系統（如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節點通過千兆網路接入私有網路即可，這樣可以節省成本。公共網路主要用於對外提供儲存服務，因此所有節點都採用萬兆接入。