一、前言

隨著各行業(yè)業(yè)務(wù)的快速發(fā)展和新型業(yè)務(wù)的建設(shè)，面對互聯(lián)網(wǎng)業(yè)務(wù)的沖擊及敏態(tài)IT的建設(shè)需求，一方面企業(yè)業(yè)務(wù)所處的基礎(chǔ)架構(gòu)環(huán)境需要具備足夠靈活的IT軟硬件基礎(chǔ)平臺以提供對業(yè)務(wù)能力支撐，另一方面，企業(yè)快速增長的業(yè)務(wù)目標(biāo)和IT基礎(chǔ)設(shè)施發(fā)展也越來越不平衡，急劇上升的客戶量、持續(xù)增長的日交易量、工作日高峰的并行壓力、負(fù)載分析的響應(yīng)時(shí)間要求等等，導(dǎo)致系統(tǒng)越來越不能滿足日益增長的性能需求，這些性能需求首先反映在后端存儲系統(tǒng)的響應(yīng)上。

[[240457]]

因此如何整合當(dāng)前IT基礎(chǔ)架構(gòu)中的存儲系統(tǒng)，實(shí)現(xiàn)存儲資源池化、云化轉(zhuǎn)型，并進(jìn)一步滿足業(yè)務(wù)系統(tǒng)的高并發(fā)、低延時(shí)的性能需求，成了企業(yè)信息化的迫切需求。

一是要借助FLASH閃存陣列來大幅提高生產(chǎn)系統(tǒng)性能，擺脫傳統(tǒng)機(jī)械磁盤系統(tǒng)的物理限制，讓數(shù)據(jù)的讀寫處理更加快速和高效；二是要利用先進(jìn)的存儲架構(gòu)，實(shí)現(xiàn)不同性能的存儲資源池間/多云存儲池間在線無縫切換，大大增強(qiáng)生產(chǎn)系統(tǒng)存儲資源調(diào)度的靈活性；三是要實(shí)現(xiàn)存儲資源“質(zhì)量分層”，根據(jù)業(yè)務(wù)系統(tǒng)的業(yè)務(wù)特性和需求，可靈活地選擇不同性能或不同質(zhì)量的存儲作為后端服務(wù)存儲，當(dāng)前存儲不滿足性能需求時(shí)，可立即遷移至性能高的存儲，并無縫切換，對上層業(yè)務(wù)系統(tǒng)無任何感知和影響。

但由于每家企業(yè)IT基礎(chǔ)架構(gòu)中的存儲系統(tǒng)都有差異，或是涉及到了多種類型的存儲產(chǎn)品，或是已經(jīng)有部分已經(jīng)實(shí)現(xiàn)了存儲資源池化，或是原來的存儲系統(tǒng)已經(jīng)老舊，需要進(jìn)行系統(tǒng)更換，等等。因此，要實(shí)現(xiàn)存儲資源池化、云化轉(zhuǎn)型，還需要根據(jù)各家企業(yè)的實(shí)情來進(jìn)行分別對待，提出合理且有針對性的解決方案。

在社區(qū)組織的主題為“如何整合當(dāng)前的存儲系統(tǒng)，實(shí)現(xiàn)存儲資源池化、云化轉(zhuǎn)型？”同行技術(shù)活動中，邀請了已經(jīng)實(shí)現(xiàn)了存儲資源池化、云化轉(zhuǎn)型企業(yè)中的實(shí)踐專家，以及大型銀行中的存儲技術(shù)專家和IBM存儲技術(shù)專家，在線根據(jù)各家企業(yè)的實(shí)情，來了一場有的放矢的同行技術(shù)交流。

活動中，來自多家金融機(jī)構(gòu)的技術(shù)大拿和IBM原廠存儲專家踴躍發(fā)言和解答問題，提出了許多寶貴和針對性的問題，為了更好、更方便的讓大家了解到本次交流活動的干貨內(nèi)容，體驗(yàn)一下IBM新一代閃存陣列FS9100的速度與激情，在此由社區(qū)專家鄧毓將本次活動的問題和解答進(jìn)行了詳細(xì)的總結(jié)。

二、 存儲如何實(shí)現(xiàn)數(shù)據(jù)遷移和整合，向資源池化和云化轉(zhuǎn)型？

1、存儲整合需考量的因素，可能帶來的新問題和性能影響等等問題

【Q1】

存儲整合時(shí)所要考慮哪些因素？對任何現(xiàn)有業(yè)務(wù)的改造我覺得都不如新建來的容易。但很多時(shí)候又不得不硬著頭皮去這樣做。雖然衍生出了很多的產(chǎn)品和方案。但風(fēng)險(xiǎn)終究還是多了很多。對于現(xiàn)有的多套業(yè)務(wù)。多格不同時(shí)期，不同應(yīng)用規(guī)格的存儲。在整合時(shí)有哪些要考慮的因素呢？

【A】

@aditowh：

應(yīng)結(jié)合不同的業(yè)務(wù)場景實(shí)施存儲整合或者存儲遷移，例如不可長時(shí)間停機(jī)的數(shù)據(jù)庫數(shù)據(jù)，盡量通過數(shù)據(jù)庫主備同步或者數(shù)據(jù)存量備份方式，直接實(shí)施數(shù)據(jù)遷移后的業(yè)務(wù)短暫切換即可；

對于虛擬機(jī)應(yīng)用服務(wù)器遷移，負(fù)載均衡可實(shí)施類似灰度升級方式，業(yè)務(wù)低峰期停機(jī)或者在線遷移到新存儲（前提是可共享掛載存儲到宿主機(jī)）；

數(shù)據(jù)整合評估時(shí)，需要多考慮存儲性能要求（IOPS/讀寫延時(shí)）、橫向擴(kuò)展（容量需求）要求、IO路徑的變化等，是否能滿足遷移后的要求。

@DK：

在整合的過程中，需要考慮各環(huán)節(jié)的兼容性；

考慮用于作為整合后的虛擬化管理節(jié)點(diǎn)自身的能力，包括性能功能等；

考慮虛擬化管理節(jié)點(diǎn)的橫向或縱向兼容；考慮能夠用于割接的窗口；

考慮廠家執(zhí)行整合案例的經(jīng)驗(yàn)案例。

【Q2】

存儲整合及集中之后,如何解決系統(tǒng)架構(gòu)深度帶來的IO延時(shí)問題？存儲整合及集中之后，必然會導(dǎo)致系統(tǒng)架構(gòu)深度加深，如何解決系統(tǒng)架構(gòu)深度帶來的IO延時(shí)問題？

【A】

@aditowh：

進(jìn)行存儲整合，需要實(shí)現(xiàn)了解清楚整合后業(yè)務(wù)的IOPS要求、延時(shí)要求，選擇合適的后端存儲再進(jìn)行遷移；

降低IO延時(shí)，還是可以通過高端存儲的動態(tài)分層技術(shù)、業(yè)務(wù)錯(cuò)峰規(guī)劃部署、業(yè)務(wù)服務(wù)器應(yīng)用層面IO整合，還可以引入性能更高的全閃盤集中式存儲、分布式SSD群集等滿足IO的延時(shí)要求；

并且還可通過引入高IO的網(wǎng)絡(luò)設(shè)備、高速網(wǎng)卡、高速HBA卡，系統(tǒng)層面實(shí)現(xiàn)bond4擴(kuò)充帶寬等來滿足性能要求。

@鄧毓：

不會，原因很簡單，讀還是和以前一樣，直接讀底層存儲，加了層網(wǎng)關(guān)，并不會增加延時(shí)；

寫和以前類似，之前的寫是寫底層存儲緩存，存儲雙控間完成緩存同步后，返回主機(jī)完成寫IO周期，加了層網(wǎng)關(guān)后，先寫網(wǎng)關(guān)緩存，待存儲網(wǎng)關(guān)雙節(jié)點(diǎn)完成緩存同步后，返回主機(jī)完成寫IO周期；

對比這兩個(gè)過程，寫延時(shí)也沒見哪里增加了。所以該問題不存在的。

@DK：

您提到的架構(gòu)深度，可能是考慮到存儲層之上增加了虛擬化引擎這一層級會不會導(dǎo)致io延時(shí)，您在用SVC或FS9100的時(shí)候，這兩個(gè)產(chǎn)品本身所提供的寫緩存能力和easy tier熱點(diǎn)分層，或者是vdm鏡像場景下的優(yōu)先讀機(jī)制，其實(shí)都是可以實(shí)現(xiàn)性能的加速的。

【Q3】

存儲資源池化對讀寫速度的影響？存儲系統(tǒng)實(shí)現(xiàn)存儲資源池化后，對讀寫速度有多大影響？是否會造成I/O瓶頸？

【A】

@aditowh：

存儲資源池化，從最上層來看，目前的架構(gòu)方案大部分的實(shí)現(xiàn)方案還是通過上層控制器就行IO終端的納管，其實(shí)對于IO路徑來說基本沒有變化；

例如Openstack中對于FCSAN的納管方案，是通過cinder納管盤機(jī)驅(qū)動、納管光纖交換機(jī)驅(qū)動，通過WWN進(jìn)行劃zone，對于納管的每臺物理機(jī)來說，只是納管掛盤的方式通過控制器來實(shí)現(xiàn)，而物理機(jī)到盤機(jī)的路徑?jīng)]有實(shí)際變化，因此我們認(rèn)為讀寫速度沒有影響，只是要防范數(shù)據(jù)熱點(diǎn)，因此要通過抽象出一定的盤機(jī)選擇算法通過控制來實(shí)現(xiàn)，盡量避免數(shù)據(jù)熱點(diǎn)和過多的IO爭用。

@鄧毓：

存儲資源池化跟單存儲比較，并不影響讀寫速度，不會造成IO瓶頸，無非多了道物理到虛擬的轉(zhuǎn)換而已，這種級別的轉(zhuǎn)換效率是非常高的，與實(shí)際物理落盤和機(jī)械尋址相比，不是同一個(gè)級別的延時(shí)，幾乎可忽略。

而單存儲如有有IOPS的壓力，通過LUN數(shù)據(jù)打散在多個(gè)存儲中，反而還可以增加整體IOPS，對業(yè)務(wù)性能也是有所提升的。

@劉文：

我理解存儲虛擬化不等于存儲的池化，池化的重點(diǎn)在于存儲管理和分配方式的變化。

存儲池化決定了用什么形式去進(jìn)行管理，是用cinder接口直接連接各類型存儲，或者自己基于smis等協(xié)議開發(fā)的平臺，這些對于業(yè)務(wù)是無感知的，不影響使用，自然也不影響讀寫速度。

至于用不用存儲網(wǎng)關(guān)設(shè)備，比如通過SVC等網(wǎng)關(guān)設(shè)備間接管理，這個(gè)就依賴于管理水平了。

2、如何實(shí)現(xiàn)存儲整合，轉(zhuǎn)向存儲云化，資源池該如何劃分，新老存儲數(shù)據(jù)如何遷移與復(fù)用，集中式存儲是否使用云化環(huán)境等問題

【Q1】

存儲池化的統(tǒng)一網(wǎng)關(guān)如何實(shí)現(xiàn)？在云環(huán)境下，越來越多的自主開發(fā)工具，云平臺，是否還有SVC這種存儲網(wǎng)關(guān)設(shè)備存在的必要，直接通過smis等協(xié)議開發(fā)，暴露api接口，直接調(diào)用，實(shí)現(xiàn)存儲底層黑盒化，是否可行？

【A】

@DK：

您這樣做，其實(shí)就是通過定制開發(fā)去覆蓋類似于虛擬網(wǎng)關(guān)的能力，并非不可以，但是，估計(jì)要考慮到以下三個(gè)方面:

一是這樣做代價(jià)不一定更小，人力和時(shí)間的投入；

二是成熟度穩(wěn)定性和商用專業(yè)設(shè)備的差別，畢竟類似產(chǎn)品是商業(yè)公司經(jīng)歷了較長的研發(fā)和實(shí)際使用產(chǎn)品更迭周期的；

三是不一定所有的存儲都能提供合適的API，并且被調(diào)用。

@鄧毓：

通過更好的方式去調(diào)用吧，比如IBM自己的POWERVC，但前提是要有POWER。

用您所說的SMIS也并非不可，需要進(jìn)行二次開發(fā)，像TPC和IBM的容災(zāi)切換工具，都是可以對接SVC的，就說明SVC也的確是有接口的，看IBMER愿不愿意和云平臺合作，自己查資料弄得話，折騰折騰估計(jì)也行，就是得不到IBM認(rèn)證，怕有后續(xù)的維保風(fēng)險(xiǎn)。

我們之前就實(shí)現(xiàn)了TSM調(diào)用腳本來實(shí)現(xiàn)SVC自動化進(jìn)行卷的快照，從側(cè)面反映這個(gè)對接難度其實(shí)不大的。

@aditowh：

如果不是研發(fā)性單位，建議還是采用成熟一點(diǎn)的管理工具平臺，或者采用開源社區(qū)生態(tài)比較好的開源組件，如果選擇自行開發(fā)，還是需要有原廠支持進(jìn)行，管理平臺的二次開發(fā)，對于API的理解還是有一定要求。

但對于存儲產(chǎn)品來說，一般廠商開放的API還是比較少，而且市面上除了Openstack生態(tài)中有一部分比較老的API提供出來，接口還是相對較少。并且對于代碼的健壯程度、兼容性，功能性測試可能也是個(gè)挑戰(zhàn)。

【Q2】

存儲池化按什么原則進(jìn)行存儲池的劃分？劃分存儲資源池的原則是什么，業(yè)務(wù)類型？應(yīng)用場景？容災(zāi)級別？如何實(shí)現(xiàn)存儲池的分級呢？有沒有實(shí)現(xiàn)自動化管理的同行可以分享下成功經(jīng)驗(yàn)？

【A】

@aditowh：

從經(jīng)驗(yàn)來看，我認(rèn)為應(yīng)用場景和業(yè)務(wù)類型是劃分存儲池需要考慮的2個(gè)主要因素；舉個(gè)栗子來說，was應(yīng)用服務(wù)器基本可接受3s以內(nèi)數(shù)據(jù)中斷，ftp甚至可以忍受時(shí)間更長，但數(shù)據(jù)庫業(yè)務(wù)或者ETCD的應(yīng)用場景來看，忍受的數(shù)據(jù)中斷要在ms級；我們在制定方案時(shí)，IO壓力較低，平均IOPS再幾十以下可以選擇分布式sata存儲；數(shù)據(jù)庫重要的業(yè)務(wù)場景建議使用集中式存儲；IOPS壓力超過數(shù)百的建議采用分布式SSD存儲；

存儲池分級，本身FCSAN盤機(jī)已經(jīng)有動態(tài)分成技術(shù)，對于熱點(diǎn)數(shù)據(jù)可以通過增加SSD緩存層增加磁盤響應(yīng)效率，而我們再此基礎(chǔ)上要做的是通過管理平臺進(jìn)行好不同級別存儲的管理，例如抽象出金銀銅級存儲，每個(gè)級別存儲對接不同的后端存儲，總之還是要劃分邏輯存儲池，抽象邏輯存儲劃分算法，通過控制平臺實(shí)現(xiàn)管理

【Q3】

測試環(huán)境目前有多臺舊存儲（全部是15K sas盤），計(jì)劃將其整合，并提升性能，有以下2個(gè)疑問：

1、使用全閃，或者混合存儲（ssd+sas）的方式，兩者性能差距能有多大？混合存儲方式，感覺只要將oracle log這類高IO的數(shù)據(jù)放到ssd上，不會比全閃性能差多少

2、數(shù)據(jù)遷移，目前主流的架構(gòu)，是否扔需要svc或者vplex這類設(shè)備的支持？還是說有其他更先進(jìn)的方式？

【A】

@潘延晟：

個(gè)人覺得舊存儲隨著時(shí)間的推移。存在的不僅僅是性能問題。還有可靠性和穩(wěn)定性的問題。

所以如果配合閃存形成混合存儲，可以采用數(shù)據(jù)分層來提高效率。另外在條件允許的情況。還是過度一段時(shí)間后逐漸將舊存儲脫離重要業(yè)務(wù)。逐步替換。保證存儲的可靠性

@aditowh：

使用全閃存儲，在SSD設(shè)備成本降低、穩(wěn)定性越來越高的趨勢下，以后會成為主流，全閃的IO延時(shí)一般可以在1ms以下，而且主要IOPS的能力會大幅提升，對于單盤質(zhì)量非常好的SSD來看，IOPS會是sas盤的上百倍，組成群集后也會有數(shù)十倍的IOPS提升；選擇存儲類型，還是要根據(jù)業(yè)務(wù)場景來看，IO密集型，而且IOPS要求非常高、延時(shí)要求高的重要數(shù)據(jù)庫業(yè)務(wù)場景下，建議選擇穩(wěn)定的全閃存儲，消除存儲性能帶給業(yè)務(wù)的壓力；

除了磁盤間的數(shù)據(jù)遷移外，對于跨平臺或者異構(gòu)，我們采用比較多的業(yè)務(wù)層面遷移，如Oracle數(shù)據(jù)庫的TTS技術(shù)，其他數(shù)據(jù)庫廠商也有自己的數(shù)據(jù)遷移方案可以采用

【Q4】

如何不停機(jī)的把數(shù)據(jù)遷移過來？

【A】

@鄧毓：

之前沒有接入存儲虛擬化網(wǎng)關(guān)的，存在底層存儲映射給存儲網(wǎng)關(guān)，再映射給主機(jī)這樣的過程轉(zhuǎn)變，才能完成后面的數(shù)據(jù)遷移工作，映射改變的過程必然要停機(jī)。

如果不采用存儲虛擬化網(wǎng)關(guān)的方式，不停機(jī)的話，能允許部分?jǐn)?shù)據(jù)丟失也是可行的，比如新搭一套系統(tǒng)，利用備份、恢復(fù)、前滾的方式遷移數(shù)據(jù)也是可行的

不停機(jī)的方式，還可以用OS層的LVM鏡像，待同步完成后，解除原存儲的鏡像即可。

@DK：

不知道您這個(gè)問題是不是指的通過FS9100去實(shí)現(xiàn)異構(gòu)存儲的數(shù)據(jù)遷移，在已有FS9100等虛擬化設(shè)備的前提下，可以實(shí)現(xiàn)不停機(jī)的數(shù)據(jù)遷移，但是之前沒有部署好FS9100的情況下，需要停機(jī)窗口。

@劉文：

如果已經(jīng)有存儲網(wǎng)關(guān)設(shè)備，一般都可以進(jìn)行在線migration的任務(wù)。

如果沒有網(wǎng)關(guān)設(shè)備，很多同品牌的存儲間遷移都提供在線遷移的工具，可以咨詢廠商工具。

操作系統(tǒng)層，通過lvm mirror、rsync等方式做數(shù)據(jù)層的同步，如果是GPFS等特殊文件系統(tǒng)的話，也支持從工具層的遷移。

【Q5】

集中存儲在云化環(huán)境中的未來如何？分布式存儲會在云環(huán)境中大行其道吧，已經(jīng)開始試水ceph了，無論從接口耦合，自動化分配，云環(huán)境的存儲管理來說，分布式存儲的優(yōu)勢盡顯，云環(huán)境中集中存儲有非存在不可的可能嗎？

【A】

@aditowh：

從分布式存儲提供的基本功能來看與集中式存儲并無大的區(qū)別，但是從穩(wěn)定性、IO路徑、性能要求來看的話，集中式存儲還是有一定的應(yīng)用場景。

例如IO密集型的應(yīng)用會要求較高的IOPS，雖說通過SSD群集可以解決IOPS，但是從實(shí)現(xiàn)架構(gòu)的原理來看，分布式存儲的穩(wěn)定性易受到單節(jié)點(diǎn)網(wǎng)絡(luò)因素或者單盤亞健康因素的影響，因此對于IO穩(wěn)定性要求高的業(yè)務(wù)場景下，盡量還是采用集中式存儲。

@鄧毓：

分布式存儲歸根到底，性能相對集中式存儲來說，肯定是比不上的，尤其是閃存大行其道的時(shí)代，一代要比一代強(qiáng)，從SATA接口的SSD到SAS，再到NVMe接口，IO響應(yīng)時(shí)間已經(jīng)縮短到了us級別，對響應(yīng)時(shí)間要求嚴(yán)格的數(shù)據(jù)庫起碼不怎么會選擇分布式存儲，云環(huán)境下也是同樣，集中式存儲如果開放了API接口，或者通過間接的方式對接云平臺，也是可以適用云環(huán)境的。沒有誰替代誰的關(guān)系，看業(yè)務(wù)的要求。

看了大神的回答，突然想再接一個(gè)問題，那超融合的未來呢。現(xiàn)在或未來是不是集中存儲和分布式相互靠攏的過程？

@aditowh：

超融合，我認(rèn)為也是針對一定業(yè)務(wù)場景出現(xiàn)的，也不是適用于所有場景，超融合理論上所有的支持分布式架構(gòu)的應(yīng)用都可以承載，但如果對于運(yùn)維要求比較高的單位，會有一定不便性，例如節(jié)點(diǎn)維護(hù)時(shí)，需要同時(shí)考慮到計(jì)算和存儲的停機(jī)時(shí)間；

但對于機(jī)房環(huán)境緊張而且停機(jī)敏感性沒那么高的企業(yè)還是可以嘗試推行。 

集中式和分布式存儲，以后也是根據(jù)應(yīng)用場景來的，根據(jù)定位的業(yè)務(wù)特性進(jìn)行不同平臺的選擇，借用鄧?yán)蠋熞痪湓挘瑳]有誰代替誰的，只能是誰更適合，結(jié)合性能、擴(kuò)展、各種成本。