日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

云計算技術(shù)浪潮奔涌向前，以云原生為代表的新秩序?qū)砥髽I(yè)IT系統(tǒng)架構(gòu)的重構(gòu)。如何建設(shè)云平臺存儲實現(xiàn)業(yè)務(wù)穩(wěn)定與創(chuàng)新并舉？最近筆者通讀了《邁向YB數(shù)據(jù)時代》夏季刊關(guān)于“云平臺存儲”相關(guān)的內(nèi)容，有感而發(fā)。

下文是筆者對“近年云計算存儲技術(shù)發(fā)展趨勢”的解讀與洞察，也希望能帶給讀者朋友一些靈感啟發(fā)，共同交流！

當(dāng)提到云計算存儲時大家首先想到的是什么？分布式，軟硬解耦，通用硬件，甚至是去IOE后無存儲？云計算“創(chuàng)世紀(jì)”時，這些特征是存在的，但隨著近年需求和技術(shù)的發(fā)展云存儲已經(jīng)變得“面目全非”。本文試圖理清一些重要變化，為大家的工作提供一些參考。本人“身在此山中”，未必識得廬山真面目，僅以自己了解的一些信息，供朋友們打開新思路。

近年“云存儲”顛覆了哪些認(rèn)知 “企業(yè)存儲”反攻上云

云計算、大數(shù)據(jù)、互聯(lián)網(wǎng)應(yīng)用架構(gòu)火熱之后，普遍認(rèn)為隨著以互聯(lián)網(wǎng)為代表的新型IT架構(gòu)的出現(xiàn)，高性能、高可靠但高成本的企業(yè)存儲的需求會逐漸消失，同時“集中式存儲”或稱“企業(yè)存儲”成為了落后架構(gòu)，承載未來IT系統(tǒng)的云計算中的云存儲應(yīng)是分布式存儲的天下。這使得企業(yè)存儲已死的聲音不絕于耳。然而近幾年以AWS為代表的公有云廠商卻以行動推翻了這些觀點。

高可用、低時延、高性能密度仍是高端云存儲的追趕目標(biāo)

2020年底AWS推出塊存儲IO2 Express預(yù)覽版，號稱首個云上SAN存儲，無論是口號還是技術(shù)指標(biāo)都從SAN存儲已死變成SAN存儲真香我要成為它。伴隨產(chǎn)品對標(biāo)對象從服務(wù)器磁盤到企業(yè)存儲的轉(zhuǎn)變，IO2 Express的持久性、最大IOPS/GiB、時延三個關(guān)鍵指標(biāo)都有數(shù)量級的提升，業(yè)務(wù)范圍也從本地盤替代轉(zhuǎn)向商業(yè)數(shù)據(jù)庫、內(nèi)存數(shù)據(jù)庫等企業(yè)級存儲應(yīng)用：

“云存儲”不但參數(shù)的“面子”越來越像企業(yè)存儲，架構(gòu)的“里子”也是如此。AWS自2012年推出 IO1后8年沒有新產(chǎn)品，但收購存儲廠商E8 Storage獲得其硬件能力并將其CEO任命為塊存儲研發(fā)總監(jiān)后1年多時間就推出了IO2和IO2 Express2。以下為被AWS收購的E8 Storage存儲架構(gòu)，關(guān)于云存儲架構(gòu)與企業(yè)存儲的趨同趨勢分析詳見"濃眉大眼的叛變"一節(jié)：

企業(yè)級NAS存儲被直接搬上云

如果云上SAN存儲還是AWS“自研”（實為收購），那么企業(yè)級文件存儲則干脆把老牌NAS存儲廠?.NETApp的產(chǎn)品搬上了云。2021年9月AWS存儲日大會宣布與NETAPP合作推出OTNAP文件服務(wù)，成為與AWS自有FSx并列的4種托管文件服務(wù)之一，這一合作由AWS直接面向客戶提供服務(wù)，比此前NETAPP與AWS、微軟和谷歌的存儲軟硬件合作更為深入。有人認(rèn)為這是存儲廠商向云低頭，但反過來AWS在已經(jīng)有了多個文件服務(wù)的情況下與NETAPP合作又何嘗不是為了市場而向存儲廠商低頭呢？

AWS與NetApp合作的文件存儲服務(wù)

大數(shù)據(jù)存算分離成主流

大數(shù)據(jù)相關(guān)技術(shù)從被google三駕馬車和其開源實現(xiàn)HADOOP帶火開始就是去存儲化的架構(gòu)。但近十年來，AWS從EMR到數(shù)據(jù)湖（并不是業(yè)務(wù)視角的數(shù)據(jù)湖）不斷推動大數(shù)據(jù)存算分離理念。如今數(shù)據(jù)共享、靈活按量使用、高可靠性的存算分離數(shù)據(jù)湖理念已被所有主流云廠商接受，存儲已是云上數(shù)據(jù)湖的“中心”。

AWS數(shù)據(jù)湖圍繞S3存儲構(gòu)建

阿里云數(shù)據(jù)湖，同樣圍繞存儲構(gòu)建

甚至不僅叫賣基礎(chǔ)設(shè)施的云廠商，將服務(wù)構(gòu)建于云上的Snowflake也采用公有云對象存儲以存算分離架構(gòu)構(gòu)建數(shù)據(jù)倉庫服務(wù)：

Snowflake架構(gòu)，使用各種公有云對象存儲持久化數(shù)據(jù)

云原生數(shù)據(jù)庫回歸IOE架構(gòu)

與前面兩個同時發(fā)生的是分布式數(shù)據(jù)庫中存儲的回歸，領(lǐng)頭的叒是AWS，以下是AWS的Aurora數(shù)據(jù)庫架構(gòu)：

藍(lán)色為計算節(jié)點，綠色為共享存儲，S3用于備份數(shù)據(jù)

最初我把這個架構(gòu)拿給一個資深DBA同事時，他說這個架構(gòu)和ORACLE的一體機架構(gòu)很像。當(dāng)時我有點詫異AWS怎么走回頭路了？但看到更多的業(yè)界類似觀點后證明同事的判斷是正確的。在AWS帶動下，阿里，華為，騰訊都出現(xiàn)同架構(gòu)的稱為云原生數(shù)據(jù)庫的產(chǎn)品，共同點都是利用存算分離架構(gòu)的可靠性與靈活性優(yōu)勢和將大量利用存儲成熟能力解決數(shù)據(jù)庫難題來提升數(shù)據(jù)庫整體能力。如果說數(shù)據(jù)庫是IT業(yè)最難解的題，那么云原生數(shù)據(jù)庫與IOE架構(gòu)的解題思路就是一樣的。由于AWS用Aurora實現(xiàn)亞馬遜內(nèi)部業(yè)務(wù)去O（交易類業(yè)務(wù)），可以說是用魔法（IOE架構(gòu)）打敗魔法（IOE產(chǎn)品）。

云存儲的“架構(gòu)變異” 去除架構(gòu)色彩回歸云服務(wù)本質(zhì)

IT業(yè)只有事實標(biāo)準(zhǔn)，大量的概念是約定俗成的，會隨時間發(fā)生變化。比如現(xiàn)的“集中式存儲”概念本不存在，分布式存儲概念火起來后，原先的磁盤陣列才“變”成了集中式存儲。因為磁盤陣列代表產(chǎn)品Symmetrix存儲系統(tǒng)之父莫西·雅奈同時是最早的分布式存儲XIV的創(chuàng)始人，集中式存儲和分布式不但同父異母，架構(gòu)上也都繼承了Symmetrix中分布式的特征。“集中式存儲”的典型特征不是集中式，而是雙/多控架構(gòu)：

Ceph存儲架構(gòu)

華為高端企業(yè)存儲內(nèi)部架構(gòu)

云存儲的概念也是多樣的，世界第一個云服務(wù)就是存儲服務(wù)——AWS的S3。所以云存儲本來應(yīng)是云上的存儲。由于是存儲服務(wù)，云存儲又可以理解為存儲云服務(wù)。但由于早期的云廠商一般采用自研存儲軟件+通用服務(wù)器來構(gòu)建存儲，且多為分布式架構(gòu)，因此也會把軟硬解耦/分布式與云存儲等同起來。由于某一時期云的熱度要大于分布式，一些廠商會把具有分布式架構(gòu)的產(chǎn)品以云存儲的概念來宣傳，就顯得更為混亂。

在業(yè)務(wù)范圍發(fā)生巨大變化的同時，云計算存儲系統(tǒng)的架構(gòu)已經(jīng)不能再簡單和分布式、通用服務(wù)器、軟硬解耦等關(guān)聯(lián)了。除了引入普遍認(rèn)為應(yīng)該是“集中式存儲的NetApp這種公然投敵行為外，自研存儲也向架構(gòu)融合，軟硬協(xié)同方向發(fā)展了。因此再審視云存儲概念時，架構(gòu)的色彩已逐漸褪去，回歸到它云服務(wù)的本質(zhì)。

“濃眉大眼的叛變” 融合“集中式存儲”架構(gòu)

再次對比一下典型的分布式存儲Ceph、被AWS收購的E8 Storage和被認(rèn)為是”集中式存儲“的華為Dorado架構(gòu)：

Ceph組網(wǎng)架構(gòu)

被AWS收購的E8全閃存組網(wǎng)及節(jié)點內(nèi)雙控架構(gòu)

華為高端企業(yè)存儲內(nèi)部架構(gòu)

很明顯分布式架構(gòu)是分布式存儲、云存儲、集中式高端存儲的共同點，區(qū)別在于“頭”（控制器架構(gòu)）。

E8 Storage是介于典型分布式存儲和磁盤陣列之間的形態(tài)：它采用了和高端存儲類似的雙控架構(gòu)，因而更容易實現(xiàn)低時延和高性能密度。但它的雙控制器只和24塊硬盤固定組成一臺物理機，相對高端企業(yè)存儲實現(xiàn)簡單，但靈活性不足。

除此之外，在緩存技術(shù)、高速網(wǎng)絡(luò)等方面云存儲也越來越多使用與磁盤陣列類似的技術(shù)，只是不那么顯眼而已，這里就不一一分析了。

軟硬協(xié)同

自研硬件并和自研存儲軟件緊耦合則更早出現(xiàn)。定制服務(wù)器、自研芯片早已廣泛用于各類存儲服務(wù)器。雖然沒有自己生產(chǎn)，但這更多是從產(chǎn)業(yè)分工的經(jīng)濟性上的考慮，實際上大型云廠商的存儲軟硬一體化已經(jīng)是很普遍的情況，換成普通服務(wù)器可能軟件都無法安裝。

軟硬協(xié)同最早可能是出于成本考慮，現(xiàn)在則主要是為提升性能和可靠性，是實現(xiàn)支撐云存儲向企業(yè)存儲能力發(fā)展，支撐大數(shù)據(jù)，數(shù)據(jù)庫等業(yè)務(wù)需求的需要。公有云是封閉全棧模式，存儲軟件多為自研或深度魔改開源版本，軟硬協(xié)同反倒是效率最高的模式。

探尋顛覆性變化的根因

如果把云存儲的現(xiàn)狀與之前尤其是去IOE火熱時云廠商的宣傳對比一下可能會覺得有點魔幻。正面來看看這些轉(zhuǎn)變的根本原因。

不改造上云的需求驅(qū)動

由于AWS、阿里等云廠商都是以支撐自身互聯(lián)網(wǎng)業(yè)務(wù)來構(gòu)建最初的云計算能力，所以云并不完美適配所有業(yè)務(wù)，需要改造才能上云。由于互聯(lián)網(wǎng)架構(gòu)有其先進(jìn)性，部分業(yè)務(wù)改造綜合收益還是不錯的，改造難度也不大。

但即使傳統(tǒng)業(yè)務(wù)要使用互聯(lián)網(wǎng)的應(yīng)用架構(gòu)也面臨大量的改造，比如亞馬遜到2019年才完成去O，還用的是IOE架構(gòu)的Aurora數(shù)據(jù)庫。對互聯(lián)網(wǎng)企業(yè)來說，云架構(gòu)就是為自己的業(yè)務(wù)量身設(shè)計的，改造投入已被消化，云的研發(fā)成本還能變現(xiàn)賺錢，但普通用戶就只能自己承擔(dān)改造成本和風(fēng)險。最終結(jié)果就是：好改造或不需要改造的應(yīng)用，很早就上云了，而難以改造的業(yè)務(wù)則一直動不了。

另一方面很多業(yè)務(wù)改造是甩鍋游戲。以容器化改造為例，首先要做的是應(yīng)用“無狀態(tài)”改造，簡單理解最主要是數(shù)據(jù)與應(yīng)用解耦。但解耦后的數(shù)據(jù)還是要放到文件存儲，消息或數(shù)據(jù)庫之類數(shù)據(jù)服務(wù)中，當(dāng)這部分?jǐn)?shù)據(jù)服務(wù)要上云時會發(fā)現(xiàn)要么沒有好的存儲能力很難實現(xiàn)，如數(shù)據(jù)庫、NAS；要么是要做存算分離否則無法發(fā)揮云計算/容器的效率優(yōu)勢，比如大數(shù)據(jù)。最終還得存儲接鍋。

當(dāng)容易上云的業(yè)務(wù)都吃差不多后，那些高價值（如核心業(yè)務(wù)）或數(shù)據(jù)量大（如大數(shù)據(jù)）業(yè)務(wù)就被盯上了。既然客戶沒法改造業(yè)務(wù)，那我就做業(yè)務(wù)能用的存儲唄，至于怎么做到無所謂，畢竟“賺錢嘛，生意，不寒磣”。

存算分離是最優(yōu)解

除了直接給客戶提供存儲，云廠商通過多年的去IOE實踐也發(fā)現(xiàn)，有些問題用IOE架構(gòu)來解決才是最優(yōu)的。以當(dāng)前火熱的云原生為例，其五大代表技術(shù)中一項為“不可變基礎(chǔ)設(shè)施”，要求部署服務(wù)之后決不會被修改，上文容器無狀態(tài)改造就是要達(dá)到類似的效果。這一架構(gòu)避免因故障切換或擴縮容的服務(wù)啟停、增減時需要搬遷數(shù)據(jù)而無法快速完成的問題。但數(shù)據(jù)層的大數(shù)據(jù)、數(shù)據(jù)庫不可能再通過“甩鍋”的方式解決問題，只能讓存儲“回來”。

所以雖然數(shù)據(jù)庫、大數(shù)據(jù)等云服務(wù)并不直接向用戶提供存儲，但云廠商都選擇主推存算分離架構(gòu)——為自己省錢省事就是多賺錢。

長大后我就成了你

那么為什么云廠商一開始不這樣做，而非要現(xiàn)在推翻一部分原來的理念呢？

一來互聯(lián)網(wǎng)作為新興業(yè)務(wù)有必要做新嘗試，并不是所有東西都能預(yù)先想到，掉坑也很正常；而最重要的是，云廠商也要追求自主可控，而這需要很長的過程進(jìn)行能力積累。

云廠商的自主可控更多是從商業(yè)上的考慮，一方面要擺脫自身業(yè)務(wù)對IOE壟斷廠商的依賴獲得議價權(quán)，二來需要通過自己的業(yè)務(wù)磨練產(chǎn)品。互聯(lián)網(wǎng)出身的AWS、阿里最早的存儲產(chǎn)品都是對象存儲，與互聯(lián)網(wǎng)結(jié)合緊密，技術(shù)門檻比較低，非常適合一邊支撐業(yè)務(wù)一邊變現(xiàn)一邊提升技術(shù)能力。之后他們都經(jīng)歷了十多年的積累，甚至最終通過收購等手段才有了前文分析的產(chǎn)品能力。手中有自主可控的產(chǎn)品，即使能力差一些，也從當(dāng)年求著廠商變成了廠商求著自己。這時再與傳統(tǒng)存儲廠商合作也與當(dāng)初大不相同了。

雖然路徑是必然的，但在自己產(chǎn)品能力還比較弱時，當(dāng)然希望用戶改造業(yè)務(wù)來適應(yīng)產(chǎn)品能力了；現(xiàn)在產(chǎn)品雖然還在追趕，至少有模有樣了，那么各位覺得如果是你會怎么宣傳呢？

用戶視角看云存儲的規(guī)劃與構(gòu)建

我既做過幾年乙方，更做過十幾年的半個甲方，在從廠商視角做完趨勢分析后，最后以用戶視角分析一下在當(dāng)前趨勢下如何規(guī)劃與建設(shè)云（主要是私有云）中的存儲系統(tǒng)的想法。

回歸到以需求指導(dǎo)選型

經(jīng)過多年的實踐，很多企業(yè)容易上云的業(yè)務(wù)已經(jīng)遷到云上了。當(dāng)前云存儲最迫切要解決的不是已經(jīng)成熟的可上云業(yè)務(wù)的存儲需求，而是核心業(yè)務(wù)以及一些新業(yè)務(wù)新技術(shù)如大數(shù)據(jù)、容器的上云存儲需求。

核心業(yè)務(wù)改造難度大、風(fēng)險高，少改造平移上云是最好選擇。云廠商的種種轉(zhuǎn)變就是受此驅(qū)動。核心業(yè)務(wù)存儲的關(guān)鍵能力的要求是疊加核心業(yè)務(wù)對存儲的原有可靠性、性能需求和云服務(wù)化的使用、管理需求，前者是要重點解決的問題。

相對于原來就使用存儲的核心業(yè)務(wù)，部分新業(yè)務(wù)原來不使用存儲，那么需要直接從業(yè)務(wù)需求的角度，甚至是更上層業(yè)務(wù)角度考慮使用存儲后是否能保證業(yè)務(wù)能力不下降以及能帶來哪些新價值。與核心業(yè)務(wù)類似，不改或少改，盡量在平臺層而非應(yīng)用層改造是最佳選擇。

過去選型中經(jīng)常會以某一架構(gòu)或部署形態(tài)來作為產(chǎn)品分檔和選型依據(jù)。但從公有云的發(fā)展來看，我們傳統(tǒng)的云存儲應(yīng)是“分布式”、“通用”、“軟硬解耦”等觀念已經(jīng)被云廠商自己推翻了，仍以這些為依據(jù)劃圈圈很可能無法選擇到滿足業(yè)務(wù)需求的存儲，需要打破原有的觀念條框。當(dāng)然這在實操中可能面臨很多困難，在首先堅持需求導(dǎo)向的前提下，可以考慮一些變通手段。比如把分布式由分類變?yōu)樘匦裕褑我环诸惥S度變?yōu)槎嗑S度，通過量化需求指標(biāo)引導(dǎo)廠商等。

利用成熟存儲能力

通過AWS收購和直接引入企業(yè)存儲廠商能力的案例可以看到，面對云存儲與業(yè)務(wù)需求間的較大差距，拿來主義是一條捷徑。在企業(yè)云存儲規(guī)劃中，將可滿足業(yè)務(wù)需求的成熟產(chǎn)存儲直接上云同樣是一條捷徑：一來簡化了選型，畢竟核心業(yè)務(wù)的需求有時只可意會，不可言傳（量化），二來也解決了傳統(tǒng)云存儲能力不足的問題。

實現(xiàn)平臺集成與服務(wù)化

各種云常被說成XaaS，這個不變的S就是服務(wù)，是云的基本特征。當(dāng)我們淡化架構(gòu)之爭，并試圖引入成熟存儲能力時，可能會面臨像NetApp的問題，即傳統(tǒng)存儲資源管理、配置分發(fā)和運維需要適應(yīng)云的服務(wù)化模式。

首先是解決集成和對接問題。傳統(tǒng)的塊和文件基本能力絕大多數(shù)存儲都提供了OpenStack，K8S等標(biāo)準(zhǔn)接口，比較有挑戰(zhàn)的是一些新技術(shù)和存儲特性功能的對接：如大數(shù)據(jù)存儲、FC網(wǎng)絡(luò)替代技術(shù)、存儲快照特性等面臨重新開發(fā)或擴展原有接口，以及打通云全流程的問題。對于體量較小的用戶，可以選擇有多廠家配套集成的方案，對于金融、運營商等IT能力比較強的用戶，則可以考慮牽引各廠商集成適配。

另外要注意的是傳統(tǒng)存儲不是服務(wù)化的，借鑒云服務(wù)化SLA量化和設(shè)計服務(wù)對精準(zhǔn)規(guī)劃有很大幫助。例如數(shù)據(jù)庫典型特點是峰值IOPS高，數(shù)據(jù)有熱點，對時延極敏感，因此常常一個數(shù)據(jù)庫總共只使用了幾萬IOPS，但大部分集中在熱點數(shù)據(jù)，峰值IOPS則是平時的幾倍，而選型時如果對存儲IOPS的評估不限制時延就會有虛高的IOPS能力。AWS的IO系列存儲可以對IOPS能力進(jìn)行保底來應(yīng)對峰值，而其將最大IOPS/GiB作為承諾SLA則使用戶可以按熱點數(shù)據(jù)的IO需求選擇合適的存儲。除此之外，像快照、容災(zāi)等存儲特性雖在云上廣泛使用，但也都是以備份、容災(zāi)等服務(wù)形式提供，需要端到端而非段到段的模式。在云存儲規(guī)劃構(gòu)建中，需要圍繞服務(wù)化考慮幾點：

•  

  選型中要考慮存儲對多租戶、SLA精細(xì)化管理的基本能力；

   

•  

  要構(gòu)建云與存儲間的服務(wù)化的接口能力，如多租戶能力，云對快照、容災(zāi)的調(diào)用能力；

   

•  

  要由云構(gòu)建服務(wù)提供給用戶使用，如快照以備份服務(wù)、遷移服務(wù)形式提供，QoS以租戶SLA能力供用戶選擇；

   

•  

  要借機量化業(yè)務(wù)對性能、可靠性和可靠性的需求，如對IOPS需求量化到單位容量，時延要分檔等

   

關(guān)注新場景

從公有云存儲發(fā)展過程看，無論是進(jìn)軍大數(shù)據(jù)等新業(yè)務(wù)還是嘗試核心業(yè)務(wù)替代，都是在擴大云的邊界。從業(yè)務(wù)角度，上云可能帶來意想不到的價值：比如新的業(yè)務(wù)形勢下，一部分穩(wěn)態(tài)業(yè)務(wù)也需要有一定的業(yè)務(wù)彈性，那么結(jié)合新的云存儲能力和容器化等多種技術(shù)組合有可能實現(xiàn)“穩(wěn)態(tài)業(yè)務(wù)敏捷上云”，利用云來解決資源彈性伸縮和管理問題。而大數(shù)據(jù)往往不僅業(yè)務(wù)和數(shù)據(jù)是孤島，在云上的資源也是孤島，實現(xiàn)存算分離的彈性上云后，不僅數(shù)據(jù)共享更方便，資源利用也更高效，甚至能實現(xiàn)與交易業(yè)務(wù)的“混部”為業(yè)務(wù)提供更多資源保障。在解決現(xiàn)有業(yè)務(wù)問題之外，未來可關(guān)注以下新場景對云存儲的需求：

•  

  容器化中存儲需求：這既包括以有狀態(tài)容器實現(xiàn)“穩(wěn)態(tài)業(yè)務(wù)敏捷上云”需要的符合穩(wěn)態(tài)業(yè)務(wù)高性能、高可靠要求的存儲技術(shù)，也包括容器數(shù)據(jù)服務(wù)如消息、搜索引擎、數(shù)據(jù)庫、大數(shù)據(jù)等有狀態(tài)應(yīng)用對存儲的需求；

   

•  

  大數(shù)據(jù)/數(shù)據(jù)湖：雖然大數(shù)據(jù)/數(shù)據(jù)湖上云往往使用容器化技術(shù)，但容器不是唯一方式，同時數(shù)據(jù)湖對成本、性能、可靠性有獨特要求，因此單獨列出；

   

•  

  核心交易數(shù)據(jù)庫：IOE架構(gòu)的成功，O在前臺，IE在幕后，缺一不可。云原生數(shù)據(jù)庫架構(gòu)的出現(xiàn)說明云廠商已意識到存算解耦的架構(gòu)以及向存儲做能力下沉來增強數(shù)據(jù)庫能力對最終實現(xiàn)數(shù)據(jù)庫替代的重要性。云原生數(shù)據(jù)庫架構(gòu)對存儲的要求是最高的，但其業(yè)務(wù)價值也是巨大的，值得關(guān)注與嘗試。