【導(dǎo)讀】本文介紹了目前云原生環(huán)境下，支持有狀態(tài)應(yīng)用的幾種典型存儲方案的特點，并對市場主流的云原生存儲產(chǎn)品實際測試性能進行對比。
現(xiàn)狀
當前，云原生已經(jīng)成為應(yīng)用開發(fā)者在選擇架構(gòu)設(shè)計時的首選。云原生讓應(yīng)用開發(fā)者可以將所有精力都集中在開發(fā)業(yè)務(wù)邏輯本身，這極大降低了應(yīng)用開發(fā)者的負擔。
而應(yīng)用系統(tǒng)的敏捷性、擴展性、可靠性、高可用等，則由基礎(chǔ)設(shè)施軟件和運維團隊共同承擔。一方面，運維團隊需要利用基礎(chǔ)設(shè)施軟件，快速響應(yīng)業(yè)務(wù)系統(tǒng)提出的部署、擴容、遷移等需求，另一方面，也要時刻保持業(yè)務(wù)系統(tǒng)和基礎(chǔ)設(shè)施軟件的穩(wěn)定運行。這為基礎(chǔ)設(shè)施軟件和運維團隊都帶來了更大的挑戰(zhàn)。
如何正確的為基礎(chǔ)架構(gòu)軟件進行設(shè)計和選型，就成為了運維主管們最具挑戰(zhàn)的任務(wù)之一。
云原生場景下的存儲系統(tǒng)
存儲系統(tǒng)一直以來都是基礎(chǔ)設(shè)施軟件中的核心之一。無論業(yè)務(wù)采用什么樣的運行環(huán)境和架構(gòu)，都離不開存儲系統(tǒng)的支撐。
在過去的30年中，業(yè)務(wù)系統(tǒng)的運行環(huán)境經(jīng)歷了巨大的變化，從單獨部署的物理機，小規(guī)模部署的虛擬化環(huán)境，大規(guī)模部署的云環(huán)境，以及目前的K8s平臺。在這個變革的過程中，業(yè)務(wù)系統(tǒng)對平臺敏捷性的要求越來越高。在物理機時代，運維人員需要手動配置存儲系統(tǒng)和部署業(yè)務(wù)系統(tǒng)，業(yè)務(wù)上線以周為單位。而在云原生時代，每分鐘都可能發(fā)布新的應(yīng)用版本，每天都可能有大量的業(yè)務(wù)要上線。
這意味著，云原生時代的存儲系統(tǒng)，除了要滿足性能、穩(wěn)定性、可靠性的要求以外，還要滿足業(yè)務(wù)系統(tǒng)對敏捷性的要求，能夠通過統(tǒng)一的編排系統(tǒng)配合業(yè)務(wù)上線，并且可以實現(xiàn)快速擴容。同時，為了減輕運維管理員的工作負擔，存儲系統(tǒng)自身的自動化運維能力，也成為運維團隊關(guān)注的核心焦點。
云原生的存儲方案
圖1.使用/部署容器的主要挑戰(zhàn)（圖片來源于CNCF報告）
從CNCF的調(diào)查可以看出，目前存儲系統(tǒng)依然是云原生場景使用和部署中面臨的最主要障礙之一。接下來我們來介紹一下云原生場景下不同存儲方案的優(yōu)劣點。
本地磁盤
本地磁盤是最容易想到的方式，也是從物理機時代就一直在使用的方式。
在服務(wù)器的硬盤槽上插上硬盤，并利用HBA卡或軟件的方式制作RAID，劃分邏輯卷，格式化成某種文件系統(tǒng)后，掛載到容器中。
由于磁盤和應(yīng)用系統(tǒng)中間的IO路徑最短，本地磁盤可以提供最佳的性能。同時RAID提供了一定程度的可靠性的保證，可以避免因單個磁盤故障而導(dǎo)致的數(shù)據(jù)丟失。因此，目前有大量用戶采用這種方式為有狀態(tài)的應(yīng)用提供存儲服務(wù)。
然而本地磁盤方案也存在著巨大的缺陷。
首先，本地磁盤無法提供節(jié)點級別的高可用，當物理節(jié)點發(fā)生故障時，由于數(shù)據(jù)都存儲在故障節(jié)點上，所以應(yīng)用無法被恢復(fù)到其他節(jié)點。如果業(yè)務(wù)系統(tǒng)有節(jié)點級高可用的要求，則必須由業(yè)務(wù)系統(tǒng)自己實現(xiàn)數(shù)據(jù)層面的高可用，這極大的增加了業(yè)務(wù)系統(tǒng)的復(fù)雜度。
其次，本地磁盤在敏捷性上也無法滿足業(yè)務(wù)需求，業(yè)務(wù)使用的存儲空間受限于本地磁盤的大小，如果達到磁盤空間的上限后難以擴容。部署RAID也是相當耗時的操作，難以實現(xiàn)在短時間內(nèi)部署大量的應(yīng)用系統(tǒng)。
此外，該方案無論是部署還是故障后的修復(fù)，都需要大量人力的參與，這使得本地存儲方案的運維成本非常高。同時由于節(jié)點間的存儲空間無法共享，也很容易造成存儲空間的浪費。
總的來說，本地磁盤的方案只適合在業(yè)務(wù)容器化的初期階段進行小規(guī)模試用，難以在大規(guī)模場景下被廣泛使用。
集中式存儲
集中式存儲提供了可遠程訪問共享存儲的能力。和本地磁盤的方案相比，集中式存儲解決了應(yīng)用系統(tǒng)高可用的問題，當業(yè)務(wù)系統(tǒng)所在的服務(wù)器發(fā)生故障時，由于數(shù)據(jù)不再存儲在服務(wù)器本地，而是存儲在遠端的共享存儲中，所以可以在其他節(jié)點上把應(yīng)用拉起來，以實現(xiàn)業(yè)務(wù)系統(tǒng)的高可用。此外，由于數(shù)據(jù)集中存儲，也一定程度解決了本地存儲對磁盤空間浪費的問題。
很多商用存儲都采用集中式存儲架構(gòu)，除了基本的數(shù)據(jù)讀寫能力外，還提供了很多高級功能，包括快照、克隆、容災(zāi)等等，進一步提升業(yè)務(wù)數(shù)據(jù)的可靠性。
然而集中式存儲的架構(gòu)決定了它不適合云原生的場景。
集中式存儲采用存儲控制器加盤柜的形式，控制器負責提供性能和存儲功能，盤柜提供可擴展的存儲容量。
盡管集中式存儲可以為單個業(yè)務(wù)系統(tǒng)提供較高的性能保證，但是當面臨大量業(yè)務(wù)并發(fā)訪問時，存儲控制器則成為了性能瓶頸。如果想要滿足大量業(yè)務(wù)對性能需求，需要采用多套集中式存儲系統(tǒng)，存儲系統(tǒng)的管理成本也會急劇上升。
此外，由于集中式存儲誕生在幾十年前，在設(shè)計上就沒有把敏捷性和運維便利性考慮進去，無法應(yīng)對短時間內(nèi)大量Volume的并發(fā)創(chuàng)建和銷毀操作，無法滿足業(yè)務(wù)系統(tǒng)對敏捷性的要求。
分布式存儲
分布式存儲的誕生就是為了解決集中式存儲無法解決的問題。
分布式存儲天然具有橫向擴展能力，在性能和高可用方面遠優(yōu)于集中式存儲，非常適合應(yīng)對大規(guī)模虛擬化場景。與此同時，分布式存儲也逐漸具備了企業(yè)級存儲的能力，包括快照、克隆等等。
不過，盡管分布式存儲在架構(gòu)上具備眾多優(yōu)點，但在實現(xiàn)難度上具備非常大的挑戰(zhàn)，并不是所有的分布式存儲都能夠充分發(fā)揮出分布式架構(gòu)的優(yōu)勢。在實際的使用過程中，大部分分布式存儲的性能和穩(wěn)定性都難以達到生產(chǎn)級別的標準，這使得很多運維團隊不敢輕易地部署分布式存儲產(chǎn)品。
總結(jié)
圖2.不同存儲方案對比
云原生有狀態(tài)應(yīng)用對存儲系統(tǒng)的需求
談存儲技術(shù)無法脫離應(yīng)用場景。在云原生架構(gòu)下，大部分業(yè)務(wù)系統(tǒng)不會處理數(shù)據(jù)存儲的邏輯，而是盡可能將數(shù)據(jù)存儲和處理能力交給數(shù)據(jù)庫來完成。
目前越來越多的數(shù)據(jù)庫也在采用云原生架構(gòu)，數(shù)據(jù)庫迎來了云原生時代。云原生數(shù)據(jù)庫將實例運行在容器中，具備了快速部署，快速擴容的能力。同時，云原生數(shù)據(jù)庫也采用了“存算分離”的架構(gòu)，將數(shù)據(jù)庫計算邏輯和存儲邏輯進一步進行分離，存儲能力交給更專業(yè)的存儲系統(tǒng)完成，數(shù)據(jù)庫只專注在數(shù)據(jù)庫的業(yè)務(wù)邏輯處理。
在某種程度上講，我們可以說云原生時代的有狀態(tài)應(yīng)用，大部分指的就是“云原生數(shù)據(jù)庫”。接下來，我們分兩種典型的數(shù)據(jù)庫類型進行介紹。
交易型數(shù)據(jù)庫（OLTP）
常見的OLTP數(shù)據(jù)庫有MySQL，PostgreSQL等，通常承載的都是核心交易類業(yè)務(wù)，對存儲系統(tǒng)的數(shù)據(jù)可靠性、性能要求極高。交易類業(yè)務(wù)本身對延遲非常敏感，所以存儲系統(tǒng)的性能直接決定了OLTP系統(tǒng)能提供的能力。存儲系統(tǒng)的帶寬越高、延遲越低，OLTP能提供的TPS越高。
每一套業(yè)務(wù)系統(tǒng)通常都會有N套獨立的OLTP數(shù)據(jù)庫作為業(yè)務(wù)支撐。由于業(yè)務(wù)系統(tǒng)會頻繁的進行部署以及擴容，所以支撐OLTP的存儲系統(tǒng)必須具備很高的敏捷性，可以快速提供數(shù)據(jù)庫對存儲空間的需求，同時也要方便的進行擴容等操作。
大部分OLTP數(shù)據(jù)庫采用塊存儲系統(tǒng)作為數(shù)據(jù)存儲系統(tǒng)，因為塊存儲通?？梢蕴峁┳罴训男阅?。此外，商業(yè)塊存儲還提供了快照、克隆等技術(shù)，可以很好地保證數(shù)據(jù)庫業(yè)務(wù)的延續(xù)性。
分析型數(shù)據(jù)庫（OLAP）
OLAP數(shù)據(jù)庫主要用在數(shù)據(jù)分析場景，對存儲系統(tǒng)的可靠性以及延遲的要求都不像OLTP數(shù)據(jù)庫那么高，且因為數(shù)據(jù)量巨大，所以對存儲成本也非常敏感。
為了支撐OLAP對存儲成本的要求，存儲系統(tǒng)通常采用EC技術(shù)，以降低數(shù)據(jù)存儲的成本。而考慮到文件接口難以支撐百億級別的文件數(shù)量，所以O(shè)LAP使用的存儲系統(tǒng)通常采用對象接口，例如S3接口。
OLAP系統(tǒng)對敏捷性沒有特殊的需求，一旦部署好后，最常見的運維操作是擴容，并不會對數(shù)據(jù)庫頻繁的進行重新部署和銷毀操作。
基于以上因素，分析型數(shù)據(jù)庫通常采用支持EC的對象存儲作為數(shù)據(jù)存儲服務(wù)，通過S3接口訪問數(shù)據(jù)。
總結(jié)
圖3.OLTP和OLAP對存儲系統(tǒng)的不同要求
多云環(huán)境對存儲系統(tǒng)帶來的新挑戰(zhàn)
隨著云技術(shù)越來越成熟，越來越多的企業(yè)面臨多云的需求：部分對數(shù)據(jù)安全不敏感且具有大量網(wǎng)絡(luò)流量的業(yè)務(wù)需要使用公有云服務(wù)，而對數(shù)據(jù)安全性和服務(wù)穩(wěn)定性要求較高的業(yè)務(wù)需要使用私有云服務(wù)。
公有云和私有云在產(chǎn)品設(shè)計理念上完全不同，產(chǎn)品的使用方式、運維方式、服務(wù)質(zhì)量、產(chǎn)品參數(shù)也完全不同。即使同樣是公有云或者私有云，不同的服務(wù)提供商之間也存在著巨大差異。多云的環(huán)境，對企業(yè)的運維團隊提出了巨大的挑戰(zhàn)。
而云原生架構(gòu)的誕生，就是為了應(yīng)對多云的挑戰(zhàn)：開發(fā)者在設(shè)計云原生應(yīng)用時，只需要關(guān)注應(yīng)用被如何創(chuàng)建和部署，無需關(guān)注在哪里運行。
然而盡管目前有相當多的開發(fā)者采用了云原生的架構(gòu)設(shè)計應(yīng)用系統(tǒng)，但是對于基礎(chǔ)架構(gòu)軟件來說，目前還是由不同的云廠商來提供?；A(chǔ)架構(gòu)的運維人員需要為不同服務(wù)商提供的存儲系統(tǒng)，準備不同的運維方式，這極大的增加了運維人員的負擔。
由此也誕生一個新的存儲系統(tǒng)類別：云原生存儲系統(tǒng)。云原生存儲系統(tǒng)可以良好的運行在各種不同服務(wù)商提供的公有云環(huán)境或私有云環(huán)境，并且為運維人員提供相同接口和運維方式。云原生存儲系統(tǒng)可以極大的降低運維團隊的負擔。
云原生存儲有什么不同
此處我們以IOMesh的架構(gòu)圖作為示例，說明云原生存儲的特點。
圖4.IOMesh產(chǎn)品架構(gòu)圖
云原生存儲不僅僅可以做到支持在公有云和私有云運行，而且提供了容器化部署、自動運維、聲明式接口等特征，讓用戶可以采用和運維其他云原生應(yīng)用一樣的方式對存儲系統(tǒng)進行部署、運維和管理。
除此之外，云原生存儲還需要能夠很好地和其他云原生基礎(chǔ)設(shè)施配合，例如云原生數(shù)據(jù)庫，使得云原生數(shù)據(jù)庫可以真正的在公有云和私有云都能夠得到一致的用戶體驗。
如何選擇云原生存儲
云原生存儲也是存儲系統(tǒng)，所以存儲系統(tǒng)所必備的可靠性，性能，高可用等等特點都是必不可少的。
除此之外，“云原生”對存儲系統(tǒng)提出了更高的要求。
盡量減少環(huán)境依賴：云原生存儲系統(tǒng)應(yīng)盡量不對軟硬件環(huán)境存在任何依賴，例如對內(nèi)核的依賴，對特定的網(wǎng)絡(luò)設(shè)備和磁盤型號的依賴等等。只有盡量少的依賴，才能夠做到最大的適配性。
避免資源過度消耗：云原生存儲系統(tǒng)以容器的形式和業(yè)務(wù)系統(tǒng)混合部署在容器平臺上。如果存儲系統(tǒng)占用過多的計算資源（CPU、內(nèi)存），則會導(dǎo)致整體投入成本太高。
聲明式運維方式：存儲系統(tǒng)應(yīng)支持通過聲明式的接口進行運維管理，同時支持一定程度的自動化運維，包括在線擴容、升級等等。當發(fā)生硬件故障時，存儲服務(wù)可以自動恢復(fù)，以保證業(yè)務(wù)系統(tǒng)不受影響。
云原生生態(tài)：云原生存儲系統(tǒng)應(yīng)該可以很好地和云原生的運維生態(tài)系統(tǒng)結(jié)合，包括監(jiān)控、報警、日志處理等待。
云原生存儲系統(tǒng)的性能對比
性能是評判存儲系統(tǒng)是否能夠支撐核心業(yè)務(wù)的關(guān)鍵指標。本文將對4個常見的云原生存儲系統(tǒng)，IOMesh、Longhorn、Portworx、OpenEBS，的性能測試結(jié)果進行對比。
我們準備了三個Worker節(jié)點作為運行應(yīng)用和云原生存儲的節(jié)點，每個節(jié)點配備了兩塊SATA SSD，四塊SATA HDD，以及萬兆網(wǎng)卡。
在測試中，我們采用最常見的MySQL數(shù)據(jù)庫作為有狀態(tài)應(yīng)用，并使用sysbench-tpcc模擬業(yè)務(wù)負載。
下表提供了四個云原生存儲系統(tǒng)在TPC-C MySQL測試中的TPS、QPS以及P95延遲數(shù)據(jù)。
圖5.TPC-C MySQL綜合性能測試
下圖對比了四個云原生存儲系統(tǒng)的性能測試結(jié)果。在坐標軸中，橫軸代表時間，縱軸分別代表：TPS、QPS、以及P95延遲。
圖6.TPC-C MySQL性能穩(wěn)定性測試
從以上數(shù)據(jù)與對比可以明顯地看出，IOMesh在絕對性能，以及穩(wěn)定性上，都遙遙領(lǐng)先于其他的云原生存儲系統(tǒng)，具備為核心生產(chǎn)系統(tǒng)提供存儲支撐的能力。
總結(jié)
隨著云原生時代的到來，越來越多的業(yè)務(wù)系統(tǒng)會采用云原生架構(gòu)。存儲系統(tǒng)作為承載業(yè)務(wù)穩(wěn)定運行的核心組件，在云原生的架構(gòu)下，也面臨著新的挑戰(zhàn)。與此同時，數(shù)據(jù)庫以及存儲系統(tǒng)自身也受到了云原生架構(gòu)的影響，逐漸發(fā)展出云原生數(shù)據(jù)庫和云原生存儲系統(tǒng)。未來可以看到越來越多的云原生數(shù)據(jù)庫和云原生存儲出現(xiàn)在數(shù)據(jù)中心中，成為被廣泛使用的技術(shù)。
作者：張凱，現(xiàn)任SmartX聯(lián)合創(chuàng)始人兼CTO。碩士畢業(yè)于清華大學計算機系，擁有十余年分布式存儲研究與產(chǎn)品經(jīng)驗。在創(chuàng)立SmartX之前，曾就職于百度，負責大數(shù)據(jù)平臺基礎(chǔ)設(shè)施建設(shè)、穩(wěn)定性和性能優(yōu)化。
