幾年前，一些分析師曾經(jīng)提醒過IT專業(yè)人士，認為服務(wù)器虛擬化和數(shù)據(jù)中心網(wǎng)絡(luò)之間不匹配。服務(wù)器虛擬化引入了一種全新的虛擬接入交換機，這種交換機對于物理的交換基礎(chǔ)架構(gòu)來說是不可見的。此外，服務(wù)器虛擬化還引入了虛擬機的移動性，換句話說，虛擬機可以被遷移到企業(yè)物理網(wǎng)絡(luò)的策略與控制邊界之外去，這樣一來，一個虛擬機就有可能離線或者裸露在一個未受保護的網(wǎng)絡(luò)區(qū)段中，從而招致各種各樣的安全攻擊風險。

這些問題的確是實際存在的，但是也招來了業(yè)界的過度炒作。其實，很多廠商利用一種標準的修補手段就解決了這些問題——他們只不過是把他們的網(wǎng)絡(luò)管理工具與VMware vCenter集成一下而已，結(jié)果呢?即時可見性、自動配置變更、基于規(guī)則的接入控制、職責分離等功能就都有了。

基本的集成工作確實解決了一些戰(zhàn)術(shù)性的問題，但是還有其他一些問題尚未解決，因此一旦網(wǎng)絡(luò)的可見性/配置開放，就有可能再次招致蠕蟲的進攻。這些尚未解決的問題中的第一個就是使用多種服務(wù)器虛擬化的問題。根據(jù)ESG咨詢公司的調(diào)查，有超過70%的中型企業(yè)(即員工人數(shù)在500~1000人)和大型企業(yè)(員工人數(shù)超過1000人)都在使用多種服務(wù)器虛擬化技術(shù)。這就意味著網(wǎng)絡(luò)廠商必須超越vCenter，去了解他們的客戶在用Hyper-V、KVM、Oracle VM和Xen做些什么，然后去實施類似的管理集成。但正是在這里事情變得更為困難了，因為網(wǎng)絡(luò)廠商必須選擇合作伙伴、和不同的API集成、測試功能性，并盡可能標準化地跨多個服務(wù)器虛擬化平臺進行管理。沒有誰希望每個不同類型的虛擬機都有不同的指令和功能。

除此之外，服務(wù)器虛擬化并不等于云計算。當私有云和混合云逐漸落地之時，網(wǎng)絡(luò)廠商們還必須在各種云平臺上實施類似的集成。從vCenter向與VMware vCloud Director集成的過渡或許很容易，但是當網(wǎng)絡(luò)廠商還需要和其他的云平臺，例如Eucalyptus、OpenStack和OpenNebula等平臺進行網(wǎng)絡(luò)管理集成時會怎樣呢?在此處，網(wǎng)絡(luò)廠商們不得不再次押上相同的賭注。

當然，對于這一大堆定制化的集成項目來說，也還有一種替代方法。我們可以用一個標準抽象層或者中間件層用于網(wǎng)絡(luò)虛擬化管理，并跨任何品牌的網(wǎng)絡(luò)設(shè)備進行運營。換句話說，利用消息、標準調(diào)用和軟件智能等手段，可以讓任何網(wǎng)絡(luò)像服務(wù)器虛擬化那樣靈活。這會有助于網(wǎng)絡(luò)運營，可以讓網(wǎng)絡(luò)對于分布式橫向擴展和巨大的Hadoop數(shù)據(jù)集來說更易于控制。

唉。我知道我這里所描述的項目都還沒有出現(xiàn)。同時，網(wǎng)絡(luò)廠商和IT專家們似乎更多地是在為大量一次性的軟件集成項目做準備，只能為服務(wù)器虛擬化和云平臺提供參差不齊的支持。如此一來，未來可能會有不少的云計算項目會被推遲實施了。

原文鏈接：http://network.51cto.com/art/201106/272547.htm