這兩天看了幾個大V的Blog，不禁倒吸一口涼氣，原來VMware Virtual SAN要做成一款通用的存儲。
大家知道，VMware VSAN給大家的印象就是它只在VMware vSphere環(huán)境下使用，大家都理解它就是vSphere內(nèi)核的一部分。由于VMware在Hypervisor領(lǐng)域處于壟斷地位，大家本來就很怕了，現(xiàn)在VMware居然要把VSAN做成一款通用的存儲。這么多SERVER SAN廠商還怎么活啊?
首當(dāng)其沖肯定就是EMC的ScaleIO，它相比VSAN的優(yōu)勢就是擴(kuò)展性比較強(qiáng)，而且可以脫離VMware使用，支持異構(gòu)的Hypervisor?？墒乾F(xiàn)在，VSAN未來也是一款通用的存儲平臺，擴(kuò)展性肯定也不是問題。雙方的市場再也沒有交錯的地方，全面的沖突不可避免。
DELL收購EMC后，EMC對VMware的控制權(quán)轉(zhuǎn)移到了DELL這邊。預(yù)計VMware會更加獨(dú)立，更加自由。沒有了EMC聯(lián)邦的約束，VSAN的通用存儲平臺夢想應(yīng)該很快就要到來。其他SERVER SAN的好日子快結(jié)束了。
好了，不替VSAN做廣告了。我們簡單來理解一下為啥VMware要這么做?因?yàn)轳R上要進(jìn)入一個后虛擬化的時代，那個時候，vSphere就不是必須的了，但存儲還是必須的。
話說VMware剛做VSAN的時候，確實(shí)定位為只針對vSphere環(huán)境。因?yàn)槟莻€時候，hypervisor如日中天，docker還是非常小眾。關(guān)鍵是應(yīng)用都是典型的傳統(tǒng)的大型(monolithic)應(yīng)用，如SQL SERVER，ORACLE，Exchange等等。很多的應(yīng)用都不是為了分布式環(huán)境設(shè)計的，因此，vSphere豐富的功能，如DRS，HA，F(xiàn)T還有豐富的數(shù)據(jù)服務(wù)對提高這些應(yīng)用的可靠性、可用性價值很大。
在這樣的情況下，VSAN捆綁vSphere就帶來巨大的差異化優(yōu)勢。
1、用戶無需配置和管理存儲集群，避免SAN管理里面復(fù)雜的zoning和fencing相關(guān)的配置;
2、無縫集成vSphere的管理工作流，如升級，維護(hù)，HA等等，無需單獨(dú)再開發(fā)，使用也更簡單;
3、所有存在的API和工作流都可以工作，只需要增加存儲相關(guān)的API;
4、計算和存儲集群成員的緊耦合簡化管理和排錯，可以重用vCenter的告警和任務(wù)管理。
也就是說，設(shè)計VSAN的時候，和vSphere緊耦合是最符合VMware當(dāng)時市場和研發(fā)策略的。
但現(xiàn)在時代變了，Docker容器和微服務(wù)大行其道，大有取代hypervisor之勢。VMware也宣布推出Photon平臺，全面擁抱容器時代。
但VSAN怎么辦，在新時代，可能不需要vSphere，VSAN還能用嗎?
現(xiàn)在VM使用存儲的方式是采用 Virtual SCSI (VSCSI) 磁盤的方式，主要是這樣沒有兼容性問題。VSAN也是仿真成hypervisor里面的SCSI控制器和設(shè)備，其他廠商也一樣。但VSAN最重要的轉(zhuǎn)折在于細(xì)粒度的存儲策略供給和管理(SPBM)。
在VSAN里，每一個VM甚至每一個VMDK(VSCSI disk)都可以采用不同的QoS特性供給。而用戶用策略去使用不同的存儲資源。這種方法好處很多。不像VMFS，VSAN不是一個集群文件系統(tǒng)。它實(shí)際上是一個基于對象的存儲系統(tǒng)。一個VM包含一定數(shù)量的對象。對象就像一個數(shù)據(jù)+元數(shù)據(jù)的自給單位，它包含部分或者整個文件系統(tǒng)，VSCSI磁盤的內(nèi)容等等。從這個意義講，VSAN和Ceph對象后端的RADOS很像。
這個太重要了。因?yàn)檫@說明VSAN是通用的基于對象的存儲平臺，因此就不僅只用作VSCSI磁盤，不僅僅只支持今天的虛擬化環(huán)境。也就是說，其實(shí)ESXi軟件的VSCSI模塊和VM元數(shù)據(jù)模塊(VMFS文件系統(tǒng))都是VSAN的接口層。值得注意的是，這個對象接口和控制平面VMware把它對外開放了，這就是今天的VASA Virtual Volumes規(guī)范。我終于知道為啥VVOLs要晚于VSAN推出了，原來是這樣的啊，原來以為是VMware故意的呢。
現(xiàn)在的IT世界已經(jīng)處于軟件驅(qū)動的變革當(dāng)中。第三平臺的應(yīng)用(或者叫原生云應(yīng)用)越來越多，新的應(yīng)用基本都是這個形態(tài)。這種應(yīng)用的分發(fā)，擴(kuò)展和資源控制都是以微服務(wù)的粒度。vSphere那種類型的資源池和DRS/HA服務(wù)不再適應(yīng)于新的應(yīng)用。實(shí)際上，作為管理抽象的vSphere的集群甚至不再重要。那是一種完全不同的管理模型，其物理基礎(chǔ)架構(gòu)對應(yīng)用本身是可見的和可管理的，這種方式很適合DevOps模型。
微服務(wù)對存儲的擴(kuò)展性要求更高，如何管理?有一些原則：
1、采用鳥瞰的方式進(jìn)行配置和健康管理;
2、使用大數(shù)據(jù)分析來幫助用戶;
3、同時支持一站式可視化的用戶界面和API(自動化)。
這就需要新的分布式，可擴(kuò)展的存儲管理架構(gòu)。
在容器時代，每個容器都共享一個OS image，這個OS image可以利用任何驅(qū)動，如輕量級的塊驅(qū)動或者文件系統(tǒng)驅(qū)動/客戶端。開發(fā)者抽取對他們應(yīng)用有意義的東西和應(yīng)用打包成容器，無需向后兼容。因此也就無需必須像VM環(huán)境采用虛擬的SCSI仿真方式。
VSAN未來就可以擴(kuò)展支持容器應(yīng)用，支持輕量級的塊驅(qū)動(也許使用NVMe協(xié)議)，原生文件甚至通過REST API支持對象。
文件對于容器映像的管理特別重要。VMware已經(jīng)在VMWorld 2015上演示了VSAN的分布式文件系統(tǒng)原型，還有馬上推出的重刪壓縮，糾刪碼特性?？磥鞻SAN已經(jīng)準(zhǔn)備好迎接容器時代了。
VMware支持容器分兩步走，第一步把容器功能集成到現(xiàn)在的vSphere環(huán)境，這種情況現(xiàn)在的VSAN就可以支持。最徹底就是采用全新平臺Photon Platform。我想，到了這一步，也就是VSAN獨(dú)立于vSphere的時候。這個時候，VSAN完全可以作為一個獨(dú)立的通用SERVER SAN產(chǎn)品對外進(jìn)行銷售，和EMC ScaleIO形成直接的競爭。不過，按照進(jìn)度，這個應(yīng)該在DELL完成EMC收購后了。
【學(xué)習(xí)心得】
VSAN先是作為vSphere的內(nèi)核緊密集成，然后慢慢發(fā)展獨(dú)立出去。華為也有虛擬化產(chǎn)品FusionSphere和SERVER SAN產(chǎn)品FusionStorage，但華為的FusionStorage一開始就是一個獨(dú)立的產(chǎn)品，并沒有把它做到FusionSphere內(nèi)核里面去。VSAN的發(fā)展思路，感覺VMware走了一個彎路，但其實(shí)不是這樣的。全容器時代還有點(diǎn)遙遠(yuǎn)，目前階段的主要部署場景還是混合場景，存儲融入Hypervisor內(nèi)核，還是起到管理簡單，降低TCO的作用的。因此，估計華為還是需要繼續(xù)在FusionSphere和FusionStorage融合上繼續(xù)投入，也不一定啥時候也學(xué)習(xí)VMware開放一個類似VVOLs的接口出來，讓其他國產(chǎn)存儲廠商也更好支持FusionSphere，構(gòu)造一個國產(chǎn)化的數(shù)據(jù)中心架構(gòu)生態(tài)圈。
今天學(xué)習(xí)筆記，純粹是學(xué)習(xí)老外的博客的個人解讀。目前還沒有跡象說VSAN獨(dú)立銷售，未來預(yù)計也只是作為其Photon平臺的一部分而已，雖然VSAN在技術(shù)上獨(dú)立銷售沒有問題，但好像沒有這個動力，就像其他超融合廠商也不單獨(dú)銷售其存儲軟件一樣。
轉(zhuǎn)型的最終目的 -提質(zhì)降本增效
分享到微信 ×
打開微信，點(diǎn)擊底部的“發(fā)現(xiàn)”，
使用“掃一掃”即可將網(wǎng)頁分享至朋友圈。