都知道數(shù)字化轉(zhuǎn)型的重要性，但怎么轉(zhuǎn)？依靠哪些數(shù)字科技？就不簡單了。數(shù)字科技的特點是概念頻出，眼花繚亂的同時，也讓人頭暈目眩，追趕不上發(fā)展的步伐。
這里要談論的是容器持久化存儲，相信對很多人來說，這是一個新概念。
如果從定義或者概念來了解它，涉及技術(shù)很多，用戶的基礎(chǔ)不同、認知不同，要快速掌握容器持久化存儲的價值，其實并不容易，叫存儲，但是意義超越存儲。
也許把定義放在一邊，了解它能夠解決哪些問題和痛點，不失為一個捷徑。
解決的問題關(guān)鍵嗎?
12月10日, 焱融科技以“Time To Change”為主題在京發(fā)布了分布式文件存儲產(chǎn)品YRCloudFile，并與Mellanox、科大訊飛、Rancher等200+客戶和合作伙伴，共同研討IT變革浪潮下的應對之策。
需要注意，所謂“Time To Change”，“適時改變”不僅指存儲，存儲之上，更重要的是TensorFlow、Spark、MySQL、Jenkins、ElasticSearch和WordPress為代表的應用，也就是云原生的應用也在發(fā)生改變。
如今，行業(yè)巨頭以及互聯(lián)網(wǎng)企業(yè)就是依靠這些呼風喚雨，改變世界。
私有云也好，公有云也好，傳統(tǒng)企業(yè)應用的云原生化改造迫在眉睫，否則會被越拉越遠。不僅是互聯(lián)網(wǎng)企業(yè)的沖擊，更大的危機來自轉(zhuǎn)型快的同行，快魚吃慢魚，贏者通吃，directadmin漢化，這才是硬道理!
首先說容器化。K8S已經(jīng)成為云原生的事實標準，被普遍接受和使用，也是云原生應用首要使用的編排工具。同樣，容器化也帶來基礎(chǔ)架構(gòu)的一系列改變。其中，容器持久化存儲首當其沖。
都知道容器的特點是召之即來，揮之即去。這是因為無狀態(tài)應用的緣故。對有狀態(tài)的應用，如MySQL、PostgreSQL、MangoDB、RabbitMQ、ElasticSearch來說，也采用容器來運行。當容器“死了”，需要快速重建，這個時候問題來了，數(shù)據(jù)也能夠快速重建嗎?
這時就需要持久化存儲了。
CSI、FlexVolume都是容器持久化存儲的規(guī)范接口，但是僅支持接口的存儲就是容器持久化存儲嗎？答案是否定的。目前市場上支持CSI存儲很多，有傳統(tǒng)的、分布式的、開源的、商用的，但在實際應用中，產(chǎn)品表現(xiàn)差別很大。是選用一款能在容器場景下基本可以使用的存儲，還是一款完全符合容器化場景容器持久化存儲，是每個IT決策者面臨的問題。
海量小文件處理和性能
對于容器持久化存儲來說，容器存儲熱點分析、可視化展現(xiàn)、K8S資源可視化管理、QoS性能管控、存儲卷彈性伸縮等，這些都是衡量容器持久化存儲功能的指標。
另一方面，海量小文件處理、海量小文件訪問熱點，有狀態(tài)Pod跨節(jié)點的秒級重建，以及跨數(shù)據(jù)中心的雙活解決方案等，也是容器持久化存儲重要的性能及可靠性指標。
海量小文件是很多應用場景經(jīng)常面臨的問題，以機器學習AI為例，數(shù)據(jù)訓練中需要依賴大量的小文件，規(guī)模會達到幾十億;此外，高性能計算也將涉及到海量文件的處理。
海量小文件會導致元數(shù)據(jù)管理瓶頸，最終拖累數(shù)據(jù)存儲的性能。為了應對海量小文件處理，YRCloudFile采用元數(shù)據(jù)集群，借助橫向擴展的方式來消除元數(shù)據(jù)管理的瓶頸。
測試結(jié)果顯示，從10億～70億小文件，YRCloudFile始終能夠保持元數(shù)據(jù)處理能力的持續(xù)穩(wěn)定。
熱點目錄是另一個造成性能瓶頸的來源，也就是多臺服務器集中訪問某個單一目錄下的文件，形成熱點目錄，如果系統(tǒng)對于熱點目錄并行處理能力不足，就會導致系統(tǒng)崩潰，或者性能低下。
針對熱點目錄，YRCloudFile提供虛擬目錄的技術(shù)，對于文件名(filename)進行Hash運算后放置在虛擬目錄中，虛擬目錄數(shù)據(jù)分布在不同的元數(shù)據(jù)節(jié)點，對上層應用透明，從而增強熱點目錄的并行處理能力。
與此同時，借助4k小文件的內(nèi)聯(lián)，YRCloudFile進一步提升了小文件訪問處理的性能。
海量小文件處理不限于容器持久化存儲，對AI等非結(jié)構(gòu)化數(shù)據(jù)規(guī)模巨大的新型應用而言至關(guān)重要，這也是YRCloudFile瞄準的主要場景。
塊數(shù)據(jù)的話題
