企業(yè)存儲資源池化整合轉(zhuǎn)型方案探討

1、 目 錄 TOC o 1-3 h z u HYPERLINK l _Toc522784735 一、前言 PAGEREF _Toc522784735 h 3 HYPERLINK l _Toc522784736 二、存儲數(shù)據(jù)整合與源池化轉(zhuǎn)型 PAGEREF _Toc522784736 h 3前言隨著各行業(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ù)載分析

2、的響應(yīng)時(shí)間要求等等，導(dǎo)致系統(tǒng)越來越不能滿足日益增長的性能需求，這些性能需求首先反映在后端存儲系統(tǒng)的響應(yīng)上。因此如何整合當(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ù)存儲，

3、當(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)行分別對待，提出合理且有針對性的解決方案。存儲數(shù)據(jù)整合與源池化轉(zhuǎn)型1、存儲整合需考量的因素，可能帶來的新問題和性能影響等等問題【Q1】存儲整合時(shí)所要考慮哪些因素？對任何現(xiàn)有業(yè)務(wù)的改造我覺得都不如新建來的容易。但很多時(shí)候又不得不硬著頭皮去這樣做。雖然衍生出了很多的產(chǎn)品和方

4、案。但風(fēng)險(xiǎn)終究還是多了很多。對于現(xiàn)有的多套業(yè)務(wù)。多格不同時(shí)期，不同應(yīng)用規(guī)格的存儲。在整合時(shí)有哪些要考慮的因素呢？【A】應(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路徑的變化等，是否能滿足遷移后的要求。在整合的過程中，需要考慮各環(huán)節(jié)的兼容性；考慮用于作為整合后的虛擬化

5、管理節(jié)點(diǎn)自身的能力，包括性能功能等；考慮虛擬化管理節(jié)點(diǎn)的橫向或縱向兼容；考慮能夠用于割接的窗口；考慮廠家執(zhí)行整合案例的經(jīng)驗(yàn)案例?！綫2】存儲整合及集中之后,如何解決系統(tǒng)架構(gòu)深度帶來的IO延時(shí)問題？存儲整合及集中之后，必然會導(dǎo)致系統(tǒng)架構(gòu)深度加深，如何解決系統(tǒng)架構(gòu)深度帶來的IO延時(shí)問題？【A】進(jìn)行存儲整合，需要實(shí)現(xiàn)了解清楚整合后業(yè)務(wù)的IOPS要求、延時(shí)要求，選擇合適的后端存儲再進(jìn)行遷移；降低IO延時(shí)，還是可以通過高端存儲的動態(tài)分層技術(shù)、業(yè)務(wù)錯峰規(guī)劃部署、業(yè)務(wù)服務(wù)器應(yīng)用層面IO整合，還可以引入性能更高的全閃盤集中式存儲、分布式SSD群集等滿足IO的延時(shí)要求；并且還可通過引入高IO的網(wǎng)絡(luò)設(shè)備、高速網(wǎng)卡

6、、高速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ī)制，

7、其實(shí)都是可以實(shí)現(xiàn)性能的加速的?！綫3】存儲資源池化對讀寫速度的影響？存儲系統(tǒng)實(shí)現(xiàn)存儲資源池化后，對讀寫速度有多大影響？是否會造成I/O瓶頸？【A】存儲資源池化，從最上層來看，目前的架構(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)，

8、盡量避免數(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)

9、關(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è)

10、公司經(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í)不大的。如果不是研發(fā)性單位，建議還是采用成熟一點(diǎn)的管理工具平臺，或者采用開源社區(qū)生態(tài)比較

11、好的開源組件，如果選擇自行開發(fā)，還是需要有原廠支持進(jìn)行，管理平臺的二次開發(fā)，對于API的理解還是有一定要求。但對于存儲產(chǎn)品來說，一般廠商開放的API還是比較少，而且市面上除了Openstack生態(tài)中有一部分比較老的API提供出來，接口還是相對較少。并且對于代碼的健壯程度、兼容性，功能性測試可能也是個(gè)挑戰(zhàn)?！綫2】存儲池化按什么原則進(jìn)行存儲池的劃分？劃分存儲資源池的原則是什么，業(yè)務(wù)類型？應(yīng)用場景？容災(zāi)級別？如何實(shí)現(xiàn)存儲池的分級呢？有沒有實(shí)現(xiàn)自動化管理的同行可以分享下成功經(jīng)驗(yàn)？【A】從經(jīng)驗(yàn)來看，我認(rèn)為應(yīng)用場景和業(yè)務(wù)類型是劃分存儲池需要考慮的2個(gè)主要因素；舉個(gè)栗子來說，was應(yīng)用服務(wù)器基本可接受3s

12、以內(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)境目前有多臺舊存儲

13、（全部是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ù)。逐步替換。保證存儲的可靠性使用全閃存儲，在SSD設(shè)

14、備成本降低、穩(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)

15、關(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ù)。如果沒有

16、網(wǎng)關(guān)設(shè)備，很多同品牌的存儲間遷移都提供在線遷移的工具，可以咨詢廠商工具。操作系統(tǒng)層，通過lvm mirror、rsync等方式做數(shù)據(jù)層的同步，如果是GPFS等特殊文件系統(tǒng)的話，也支持從工具層的遷移?！綫5】集中存儲在云化環(huán)境中的未來如何？分布式存儲會在云環(huán)境中大行其道吧，已經(jīng)開始試水ceph了，無論從接口耦合，自動化分配，云環(huán)境的存儲管理來說，分布式存儲的優(yōu)勢盡顯，云環(huán)境中集中存儲有非存在不可的可能嗎？【A】從分布式存儲提供的基本功能來看與集中式存儲并無大的區(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è)