5 云存儲
5.1 云存儲實例分析
現(xiàn)有的云存儲更多的是一種在線遠(yuǎn)程備份系統(tǒng),Hu等人針對上面的4種云存儲系統(tǒng)進(jìn)行了測試、比較和分析,當(dāng)將8GB的文件備份到云存儲系統(tǒng)中時,有的系統(tǒng)的備份時間超過了30個小時,還有的系統(tǒng)在經(jīng)過4天的時間還未備份完成,當(dāng)他們將數(shù)據(jù)集減小到2GB左右時,云備份系統(tǒng)才回復(fù)到基本正常的工作狀態(tài)。
圖6 2.12GB數(shù)據(jù)的備份時間
圖6表示Hu等人在四個不同的云存儲系統(tǒng)下備份2.12GB數(shù)據(jù)時的遠(yuǎn)程備份時間,其中橫坐標(biāo)從左到右的四種情況分別表示單個2.12GB的大普通文件、單個2.12GB的大稀疏文件、很多小的普通文件組成2.12GB的數(shù)據(jù)集、很多小的稀疏文件組成2.12GB的數(shù)據(jù)集,這里的稀疏文件表示該文件不包含用戶數(shù)據(jù),也沒有分配用來存儲用戶數(shù)據(jù)的磁盤空間,當(dāng)數(shù)據(jù)被寫入稀疏文件時,文件系統(tǒng)(例如:NTFS)才逐漸地為其分配磁盤空間.可以看到對于正常2,12GB的文件數(shù)據(jù)四個系統(tǒng)的備份時間都超過了5小時,圖7表示相應(yīng)的恢復(fù)時間,恢復(fù)比備份要相對塊很多,這主要是由于網(wǎng)絡(luò)的上行鏈路和下行鏈路帶寬的不對稱造成的,通過大量的測試分析,Hu等人得出了以下結(jié)論:
圖7 2.12GB數(shù)據(jù)的恢復(fù)時間
1)云存儲系統(tǒng)必須對于網(wǎng)絡(luò)失效具有回彈性,同時能夠?qū)崿F(xiàn)大文件的增量備份;
2)云存儲提供商在進(jìn)行大數(shù)據(jù)的網(wǎng)絡(luò)傳輸時還要進(jìn)行加密、壓縮等預(yù)處理以避免網(wǎng)絡(luò)延遲;
3)云存儲用戶需要手動檢測重要的文件是否都已經(jīng)進(jìn)行了備份;
4)云存儲用戶應(yīng)該將云存儲系統(tǒng)作為本地備份系統(tǒng)的一種補充,而不能將其當(dāng)成主要的備份策略。
個人認(rèn)為,現(xiàn)有的云存儲應(yīng)對普通用戶小數(shù)據(jù)的備份與恢復(fù)應(yīng)該問題不大,但是企業(yè)級用戶大數(shù)據(jù)量的存儲與恢復(fù)則要慎重考慮。
5.2云存儲系統(tǒng)面臨的挑戰(zhàn)
云存儲系統(tǒng)中主要的存儲設(shè)備磁盤驅(qū)動器是一種機(jī)電混合設(shè)備,這使得和計算相比,存儲系統(tǒng)具有了很多不同的特性,由于信息數(shù)字化所產(chǎn)生的呈指數(shù)級增漲的數(shù)據(jù)對存儲系統(tǒng)提出了嚴(yán)峻的挑戰(zhàn),隨著社會信息化程度的不斷提高,對數(shù)據(jù)存儲的急劇提升,導(dǎo)致了以"計算"為中心到以"數(shù)據(jù)存儲"為中心的觀念革新,在過去的十多年中,磁盤的區(qū)域密度、軌密度和線密度分別獲得了100%,50%和30%的增長,在存儲領(lǐng)域有兩個重要的技術(shù)對存儲系統(tǒng)的發(fā)展和存儲容量的擴(kuò)展產(chǎn)生了重要的影響,第一個是并行存儲,比如磁盤陣列技術(shù),第二個就是網(wǎng)絡(luò)技術(shù)對存儲系統(tǒng)體系結(jié)構(gòu)的影響,通過將網(wǎng)絡(luò)引入存儲系統(tǒng),改變主機(jī)與外部存儲節(jié)點間的連接模式,出現(xiàn)了若干新型存儲體系結(jié)構(gòu):附網(wǎng)存儲(networkattached storage,NAS)和存儲區(qū)域網(wǎng)(storage area network,SAN),網(wǎng)絡(luò)存儲技術(shù)對于解決存儲設(shè)備的分散性、I/O的并行性、協(xié)議的高效性提供了一種很好的手段,網(wǎng)絡(luò)與存儲設(shè)備不同的結(jié)合方式可以形成不同拓?fù)浣Y(jié)構(gòu)的網(wǎng)絡(luò)存儲系統(tǒng),不同的拓?fù)浣Y(jié)構(gòu)對于系統(tǒng)性能的影響又各不相同.但由于性能、價格、可擴(kuò)展性等各方面的原因,他們也還是不足以應(yīng)對爆炸性的數(shù)據(jù)增長。
存儲系統(tǒng)必須要從少數(shù)的存儲引擎向連在網(wǎng)絡(luò)上的成千上萬的商用化存儲設(shè)備進(jìn)行轉(zhuǎn)變,在過去的十多年中集群網(wǎng)絡(luò)的重要進(jìn)展之一是可以將成千上萬的節(jié)點連起來,同時保證高可擴(kuò)展性和相對較低的通訊開銷,因此,我們認(rèn)為,采用商用化的技術(shù)來構(gòu)造可擴(kuò)展的集群是云存儲的基本組件,因為,我們可以像搭積木的形式來聚合存儲組件以構(gòu)造大規(guī)模的存儲系統(tǒng),但是現(xiàn)有的存儲系統(tǒng)進(jìn)行規(guī)模的擴(kuò)展之后還存在很多待解決的問題。
5.2.1 名字空間
存儲器空間的組織和分配,數(shù)據(jù)的存儲、保護(hù)和檢索都依賴于文件系統(tǒng),文件系統(tǒng)由文件和目錄組成,數(shù)據(jù)按其內(nèi)容、結(jié)構(gòu)和用途命名成不同的文件,而目錄則構(gòu)建文件系統(tǒng)的層次化結(jié)構(gòu),現(xiàn)代的文件系統(tǒng)一般都是按樹形的層次架構(gòu)來組織文件和目錄,集群文件系統(tǒng)往往也采用樹形架構(gòu)來構(gòu)造名字空間,然而,當(dāng)數(shù)據(jù)的訪問從樹根走向樹葉的時候,訪問的延遲會響應(yīng)的增加,另外,還有兩個重要的因素導(dǎo)致樹形架構(gòu)不適合于云存儲環(huán)境,第一,樹根本身就是一個單一失效點,而且很容易形成系統(tǒng)的瓶頸,第二,樹形架構(gòu)很難在Internet上擴(kuò)展到地理上分布的規(guī)模,另外,層次化結(jié)構(gòu)使得文件的訪問效率不高,每一層目錄都隱藏了它所包含的子目錄和文件,用戶很難知道一個目錄下面到底有哪些文件和子目錄,因此,用戶訪問某個文件時,必須通過層次型的目錄樹結(jié)構(gòu)到達(dá)其保存位置,如果不知道文件保存位置,必須遍歷整個目錄,因此云存儲只有采用非集中式的名字空間來避免潛在的性能瓶頸和單點失效。
5.2.2 元數(shù)據(jù)組織
元數(shù)據(jù)是描述數(shù)據(jù)的數(shù)據(jù),主要用來反映地址信息和控制信息,通常包括文件名、文件大小、時間戳、文件屬性等等.元數(shù)據(jù)主要是用來管理的操作數(shù)據(jù),研究表明,在文件系統(tǒng)的操作中,超過50%的操作是針對元數(shù)據(jù)的,另有研究指出,使用NFS3,0時,其客戶端和服務(wù)器端交互的信息中65%的信息是和元數(shù)據(jù)相關(guān)的,元數(shù)據(jù)最重要的特點是其往往是小的隨機(jī)請求,一般來講,元數(shù)據(jù)都是存儲在磁盤上的,然而,和磁盤存儲容量的增長不同的是,由于機(jī)械組件所帶來的延遲,磁盤的平均訪問時間每年的降低不足8%.圖8表示了Hitachi的磁盤在過去十年里磁盤訪問時間和尋道時間的發(fā)展趨勢,對于這種由小的隨機(jī)請求所組成的數(shù)據(jù)訪問流中,磁盤的尋道時間是磁盤訪問延遲中最組要的部分,這是由于磁頭的穩(wěn)定時間主導(dǎo)著磁盤的尋道時間,而且磁頭的穩(wěn)定時間數(shù)年來基本上沒有太大的變化,因此,對于大規(guī)模系統(tǒng)來講,元數(shù)據(jù)的訪問往往成為制約整個系統(tǒng)性能的瓶頸。
很多分布式的存儲系統(tǒng)將數(shù)據(jù)訪問和元數(shù)據(jù)的訪問分離開來,在這樣的系統(tǒng)中,客戶端首先和元數(shù)據(jù)服務(wù)器通訊來獲取元數(shù)據(jù)包括文件名、文件位置等信息,然后,利用該元數(shù)據(jù),客戶端直接和數(shù)據(jù)服務(wù)器通訊去訪問相應(yīng)的數(shù)據(jù),一般來講,元數(shù)據(jù)服務(wù)器的內(nèi)存可以滿足大部分的讀請求,但服務(wù)器不得不周期性地訪問磁盤來讀取需要的數(shù)據(jù),并且所有元數(shù)據(jù)的更新也要寫回到磁盤,存儲系統(tǒng)空間的增長可以通過增加額外的存儲服務(wù)器來保證,然而,對于一個管理數(shù)以億計的數(shù)據(jù)文件的云存儲系統(tǒng),如何保證元數(shù)據(jù)的訪問性能和可擴(kuò)展性?對于象云這樣的需要高可擴(kuò)展性的環(huán)境,對元數(shù)據(jù)的依賴性給系統(tǒng)設(shè)計帶來了巨大的挑戰(zhàn)。
6 云傳輸
按照Nielsen法則,終端用戶的網(wǎng)絡(luò)帶寬以每年50%的速度增長,然而,和局域網(wǎng)形成鮮明對照的是,廣域網(wǎng)的性能不盡人意,例如,一條T1線路的帶寬只相當(dāng)于千兆網(wǎng)的千分之一,許多幀中繼線路的帶寬只有256Kbits/秒,Garfinkel通過測量發(fā)現(xiàn)從美國伯克利大學(xué)到西雅圖的平均網(wǎng)絡(luò)寫帶寬大約是5to18Mbits/秒,通過使用網(wǎng)絡(luò)測試工具iperf,采用256個數(shù)據(jù)流,我們的測量數(shù)據(jù)表明在格林尼治標(biāo)準(zhǔn)時間下午7點到10點,從英國劍橋大學(xué)到中國北京的平均網(wǎng)絡(luò)帶寬大約是14Mbits/秒。
基于以上的測試數(shù)據(jù),如果假設(shè)網(wǎng)絡(luò)帶寬為20Mbits/秒,Armbrustetal,等人作了簡單的計算,計算結(jié)果表明從美國伯克利大學(xué)傳輸10TB數(shù)據(jù)到西雅圖需要45天的時間(10×1012Bytes/(20×106bits/秒)=4,000,000秒=45天).如果通過亞馬遜來進(jìn)行該數(shù)據(jù)傳輸,需要另外向亞馬遜支付1000美金的網(wǎng)絡(luò)傳輸費用,另外,由于廣域網(wǎng)物理距離的原因,不可避免的時延也會對帶寬造成影響,例如,一個T3鏈路(44.736Mbits/秒),當(dāng)時延超過40ms時,其帶寬很快就下降到與T1鏈路(1.544Mbits/秒)相當(dāng)。
如果是進(jìn)行云備份,時間上的開銷相對還可以忍受,因為用戶在本地還有一個數(shù)據(jù)拷貝可供使用,但如果是從云存儲系統(tǒng)中恢復(fù)數(shù)據(jù),這是無法讓人接受的,特別是對于那些需要提供24×7×365業(yè)務(wù)連續(xù)性的企業(yè)級用戶,為了緩解這個問題,對于云存儲系統(tǒng)中大數(shù)據(jù)量的恢復(fù),云存儲提供商Mozy和CrashPlan提供了一個不得已的選擇,在用戶許可的情況下,將數(shù)據(jù)轉(zhuǎn)存在DVD或者硬盤上,然后通過特快專遞的形式交付給用戶。
為了優(yōu)化廣域網(wǎng)環(huán)境下大規(guī)模數(shù)據(jù)傳輸?shù)男阅,我們曾將?shù)據(jù)在套接字層,在發(fā)送端進(jìn)行分割,然后利用多個套接字流進(jìn)行并行傳輸,最后在接收端進(jìn)行數(shù)據(jù)的重組(如圖10(c)所示),理論上講,對TCP管道而言,其最大的吞吐量為帶寬延遲乘積,即容量=帶寬×環(huán)回時間,在傳輸窗口一定的情況下(圖10中紅色的方形區(qū)表示傳輸窗口,缺省為64K字節(jié)),按通常100Mb的網(wǎng)絡(luò)帶寬來計算,傳統(tǒng)的單套接字流顯然無法填滿TCP管道(如圖10(a)所示),使得其效率極低,通過加大傳輸窗口可以在一定程度上提高TCP管道的利用率(如圖10(b)所示),但在丟包的情況下,會導(dǎo)致每次重傳的數(shù)據(jù)增加,因此,通過多個套接字流來并行傳輸?shù)男Ч^好,另外,由于采用了多流,不同的數(shù)據(jù)流在必要的情況下可以走不同的路由,也能夠進(jìn)一步優(yōu)化廣域網(wǎng)的性能。
正如前面提到的,云基礎(chǔ)設(shè)施必須是地理上分布的,因為云的成功在很大程度上決定于其規(guī)模效應(yīng),計算和存儲相對便宜,然而,由于廣域網(wǎng)環(huán)境下的低帶寬、高延遲和較高的丟包率,使得廣域網(wǎng)成為云環(huán)境下那塊最短的木板,因此,在地理上分布的云環(huán)境下進(jìn)行大規(guī)模的數(shù)據(jù)傳輸是非常昂貴的.圖靈獎獲得者JimGray在2006年就指出在廣域網(wǎng)上處理大數(shù)據(jù)集時,應(yīng)該將程序傳給數(shù)據(jù),而不是將數(shù)據(jù)傳給程序,另外,也可以通過數(shù)據(jù)壓縮、數(shù)據(jù)的去重等方法來減少網(wǎng)域網(wǎng)上的數(shù)據(jù)傳輸流量,降低對網(wǎng)絡(luò)帶寬的需求,還可以采用動態(tài)緩存、IP流量管理以及QoS等方法來降低廣域網(wǎng)的延遲,但是,這些方法只能在一定程度上來緩解網(wǎng)絡(luò)瓶頸問題,不能從根本上解決問題,因此,在設(shè)計云架構(gòu)時,必須要考慮廣域網(wǎng)的帶寬、延遲和包丟失率所帶來的影響。
7 討論
云正成為當(dāng)前學(xué)術(shù)界討論的熱點問題,工業(yè)界也紛紛推進(jìn)自己的云產(chǎn)品,例如,EMC的云存儲產(chǎn)品Atmos,亞馬遜的云計算產(chǎn)品EC2、云存儲產(chǎn)品S3(Simple Storage Service)和EBS(Elastic Block Store),IBM的云計算產(chǎn)品BlueCloud,Google推出的在線存儲服務(wù)GDrive,Microsoft也推出WindowsAzure,各IT業(yè)巨頭也紛紛將云計算作為其戰(zhàn)略制高點并在世界各地建立龐大的數(shù)據(jù)中心。
但是,正如我們在4.2節(jié)和5.2節(jié)中提到的,云計算環(huán)境下虛擬機(jī)的I/O問題,云存儲環(huán)境下的元數(shù)據(jù)性能問題必將是云基礎(chǔ)設(shè)施的設(shè)計者不得不面對的挑戰(zhàn),閃存(FlashMemory)是一種非易失性(在斷電情況下仍能保持所存儲的數(shù)據(jù)信息)的存儲器,它可以被電擦除和重編程,它具有很多優(yōu)點,例如尺寸小、沒有機(jī)械部件、低功耗、高性能等,閃存已經(jīng)在越來越多的場合開始取代傳統(tǒng)的磁盤,下頁圖11和圖12分別比較了4種不同性能的磁盤和由閃存組成的固態(tài)盤的帶寬和訪問時間,可以看到固態(tài)盤在性能方面具有非常大的優(yōu)勢,在論文中我們還進(jìn)一步比較了磁盤和固態(tài)盤的功耗,結(jié)果表明固態(tài)盤也具有相當(dāng)?shù)膬?yōu)勢,這表明,從性能的角度,固態(tài)盤可以在一定程度上解決云計算和云存儲所面臨的I/O問題,更為詳細(xì)的分析請參看論文。
閃存具有4個特點:
1)數(shù)據(jù)擦除是以塊為單位,但數(shù)據(jù)寫是以頁為單位,一個塊往往是由多個頁組成;
2)在向某一個塊寫數(shù)據(jù)之前,該塊中的數(shù)據(jù)必須要擦除;
3)每一個塊只能被寫有限的次數(shù);
4)在一個塊內(nèi)寫數(shù)據(jù)必須要順序進(jìn)行。
這些特性導(dǎo)致固態(tài)盤的寫性能比較微妙,另外,和磁盤的壽命相比,固態(tài)盤有限的寫次數(shù)也是不得不考慮的問題,再者,固態(tài)盤的價格和容量目前還無法和磁盤競爭,因此,在試圖使用固態(tài)盤來緩解I/O問題時,還必須要同時考慮到磁盤的優(yōu)勢,兩者結(jié)合使用才能發(fā)揮各自所長。
同云計算和云存儲相比,對于云傳輸?shù)膱蟮老鄬^少,現(xiàn)有的工作主要集中在對廣域網(wǎng)下的大規(guī)模數(shù)據(jù)傳輸?shù)男阅苓M(jìn)行優(yōu)化,EMC就采用SilvERPeak公司的廣域網(wǎng)優(yōu)化產(chǎn)品來提高廣域網(wǎng)環(huán)境下數(shù)據(jù)復(fù)制的性能、可擴(kuò)展性和安全性,同時降低在進(jìn)行遠(yuǎn)程復(fù)制以實現(xiàn)災(zāi)難恢復(fù)和業(yè)務(wù)連續(xù)性時的廣域網(wǎng)的帶寬需求,Cisco也收購了Actona公司來提高其網(wǎng)絡(luò)設(shè)備在網(wǎng)域網(wǎng)環(huán)境下的性能問題,主要原因在于,目前廣泛使用的TCP/IP協(xié)議是在實驗室低速網(wǎng)絡(luò)環(huán)境下誕生的,在設(shè)計初期只是為了保證數(shù)據(jù)在鏈路上的可靠傳輸,因此,它并不是為廣域網(wǎng)而設(shè)計的網(wǎng)絡(luò)傳輸協(xié)議,例如,TCP/IP協(xié)議的滑動窗口,重傳和恢復(fù)等機(jī)制使得廣域網(wǎng)的傳輸效率急劇下降,另外,TCP的窗口尺寸、慢啟動等機(jī)制也無法充分利用已有的網(wǎng)絡(luò)帶寬。
云傳輸問題,在5,2節(jié)中提到的云存環(huán)境下的名字空間問題,都促使我們要重新審視在大規(guī)模數(shù)據(jù)存儲和傳輸?shù)那闆r下的性能優(yōu)化相關(guān)的一系列問題。
P2P是一種分布式網(wǎng)絡(luò),網(wǎng)絡(luò)的參與者共享他們所擁有的一部分資源(如處理能力、存儲能力、數(shù)據(jù)資源等),在此網(wǎng)絡(luò)中的參與者既是資源提供者(Server),又是資源的獲取者(Client),P2P網(wǎng)絡(luò)由于其高可擴(kuò)展性得到了廣泛的使用。其中分布式且結(jié)構(gòu)化的P2P網(wǎng)絡(luò)尤其具有應(yīng)用前景,這種P2P網(wǎng)絡(luò)中的關(guān)鍵技術(shù)是使用分布式哈希表(DistributedHashTables,DHT)來構(gòu)造結(jié)構(gòu)化拓?fù),?mesh、ring、d-dimensiontorus and butterfly等等,在這種網(wǎng)絡(luò)中,每個節(jié)點都有一個ID,每個文件有一個關(guān)鍵字Key,當(dāng)宣告一個關(guān)鍵字為K1的文件時,先通過哈希映射得到對應(yīng)的K1→ID1,然后將該文件存到ID號為ID1的節(jié)點,文件的存放過程需要將文件路由到該節(jié)點ID1,反過來,當(dāng)查找一個關(guān)鍵字為K1的文件時,先進(jìn)行哈希映射得到K1→ID1,然后將該文件從ID號為ID1的節(jié)點上取到該文件,從該網(wǎng)絡(luò)中取文件需要將請求消息路由到ID1節(jié)點,然后文件從ID1節(jié)點原路返回,其優(yōu)點在于,在資源管理過程中同時擁有自組織特性、規(guī)模的強可縮放特性以及部署的廉價性等等,這為規(guī)模龐大的資源整合及共享提供了可能性,其中OceanStore,PAST,F(xiàn)reeHeaven,是最具有代表性的幾個大規(guī)模的、結(jié)構(gòu)化的P2P存儲系統(tǒng)的代表。
圖 帶寬比較和訪問時間比較和OceanStore 的體系結(jié)構(gòu)
圖表示了OceanStore的體系結(jié)構(gòu),其中最關(guān)鍵技術(shù)是將多個資源池進(jìn)行高度的互連,從而允許數(shù)據(jù)在各個不同的資源池中自由地流動,用于可以根據(jù)需要連接到一個或者多個資源池,例如,如果離用戶最近的資源池中存在其所需要的數(shù)據(jù)副本,用戶可以連接到該資源池以最大程度地降低廣域網(wǎng)對其性能的影響,個人認(rèn)為,這種結(jié)構(gòu)化的P2P如果能和云存儲結(jié)合起來,對于其云存儲名字空間的管理,對于廣域網(wǎng)環(huán)境下大規(guī)模數(shù)據(jù)傳輸?shù)男阅軆?yōu)化都會帶來很大的幫助。
8 結(jié)論
在云計算之前,網(wǎng)格計算在學(xué)術(shù)界曾被廣為推崇并進(jìn)行了大量的研究,網(wǎng)格計算依托互聯(lián)網(wǎng)絡(luò),將地理上分布的、異構(gòu)的各種不同資源組織起來,統(tǒng)一調(diào)度,組成虛擬的超級計算機(jī),以協(xié)同完成需要大量計算機(jī)資源的任務(wù),網(wǎng)格計算的這種架構(gòu)主要用于科學(xué)計算、并行計算等問題,其往往通過作業(yè)的形式向網(wǎng)格提交任務(wù),并等待處理結(jié)果的完成,因此,缺乏和普通用戶的交互性,由于其面向特定的有限的用戶,未被工業(yè)界廣泛推廣,另外,大部分的網(wǎng)格環(huán)境和平臺都是基于Globus來開發(fā)的,雖然Globus是一個典型的網(wǎng)格計算平臺,但是其構(gòu)筑在傳統(tǒng)的操作系統(tǒng)之上,現(xiàn)代軟件往往采用模塊化的分層設(shè)計,物理資源的性能經(jīng)過每一層軟件都會導(dǎo)致性能不同程度的降低,因此,由Globus軟件本身所帶來的性能開銷在加上操作系統(tǒng)的性能開銷所導(dǎo)致的網(wǎng)格環(huán)境性能的整體下降一直是網(wǎng)格研究社區(qū)里經(jīng)常討論的問題。
不同于網(wǎng)格計算,云計算以用戶需求為導(dǎo)向,利用虛擬化技術(shù)將存儲資源、計算資源、軟件資源、數(shù)據(jù)資源等構(gòu)造成動態(tài)和、可伸縮的虛擬資源,并通過網(wǎng)絡(luò)以服務(wù)的方式交付給廣大用戶,由于其以普通用戶為主導(dǎo),并具有廣泛的市場前景,所以,最開始是由工業(yè)界以產(chǎn)品的形式大力推動并在短時間內(nèi)產(chǎn)生廣泛的影響,云計算擁有網(wǎng)格計算所不具備的大量潛在的普通用戶,但是,云如果要避免網(wǎng)格計算的重蹈覆轍,必須要從體系結(jié)構(gòu)進(jìn)行一個全新的顛覆性的設(shè)計,當(dāng)然,云最終能否成功,還受到其它很多因素的影響(例如,大量的數(shù)據(jù)存儲在云端,如何保證數(shù)據(jù)的安全和用戶隱私)。
轉(zhuǎn)載請注明出處:拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標(biāo)題:云基礎(chǔ)設(shè)施下的體系結(jié)構(gòu)、挑戰(zhàn)與機(jī)遇(下)
本文網(wǎng)址:http://www.ezxoed.cn/html/support/1112156979.html