VFC的配置工作在Hyper-V管理器中完成，使用的是新的Virtual SAN Manager(虛擬SAN管理器)選項，詳見上圖。只有HBA以及支持NPIV的固件才能正確為VFC所使用。換句話來說，只有像Emulex HBA這類傳輸能力在4Gb/秒以上的新HBA方能符合要求。顯然SAN光纖也必須同樣支持NPIV。一個HBA只能歸屬于一個虛擬SAN，然而一個虛擬SAN中卻可以包含多個HBA。在虛擬SAN創(chuàng)建完成之后，我們就可以利用Add Hardware(添加硬件)選項中的Settings(設(shè)定)子集將虛擬HBA分配給客戶機(jī)。光纖通路ID理論上可以使用任何16位長度的16進(jìn)制數(shù)字，不過官方并不建議用戶使用那些已經(jīng)預(yù)留的數(shù)值。微軟公司在默認(rèn)情況下設(shè)定了一些標(biāo)準(zhǔn)值，我們在點(diǎn)擊“Create Addresses”(創(chuàng)建地址)按鈕時這些值會自動生成以供使用。不過到現(xiàn)在我也沒搞清楚為什么光纖通路似乎只有兩組地址可見并直接可用。

在客戶機(jī)啟動完成之后，即使我們沒有安裝客戶機(jī)O/S，光纖登錄進(jìn)程也會自動開始。如上圖所示，額外的節(jié)點(diǎn)指明了源Hyper-V服務(wù)器(在本實(shí)例為中PH03)，但卻無法正確顯示客戶機(jī)名稱，而只是標(biāo)注為“Hyper-V VM Port”(Hyper-V虛擬機(jī)端口)。希望這一點(diǎn)在今后的更新中能有所改善，畢竟看不見虛擬機(jī)名稱的話管理工作實(shí)在很難進(jìn)行。

要想在Hyper-V客戶機(jī)上使用VFC需要滿足兩大條件：

第一，使用指定的O/S——Windows Server 2008、Windows 2008 R2或者Windows 2012都可以;

第二，安裝Windows Server 2012中附帶的集成服務(wù)更新。也就是說虛擬光纖通路適配器無法被模擬為本機(jī)設(shè)備，因此我們不能使用以Linux為代表的其它操作系統(tǒng)。上圖顯示的是我為主機(jī)設(shè)置的模擬HBA控制器以及磁帶驅(qū)動器。

最近我發(fā)現(xiàn)很多博文都在對Windows Server 2012的磁帶驅(qū)動器支持能力展開討論。這里我要澄清一下，磁帶驅(qū)動器絕對是能夠正常工作的，但目前微軟官方還沒有在任何說明文檔中正式表示他們提供相關(guān)支持。

性能表現(xiàn)

我選擇了一款磁帶驅(qū)動器，這正是展示W(wǎng)indows Server 2012處理性能的絕佳方式。在將Backup Exec 2012部署到我的Windows 2008 R2客戶機(jī)并向LTO2驅(qū)動器進(jìn)行寫入操作時，我發(fā)現(xiàn)測試成績達(dá)到12MB/秒，這比我在vSphere 5.0上進(jìn)行模擬設(shè)備測試時的成績要好一些。雖然這與驅(qū)動器本身的最大傳輸能力(40MB/秒)還有一定差距，但在小型業(yè)務(wù)環(huán)境中已經(jīng)足夠用了。要想得出更有說服力的結(jié)論，我們還需要進(jìn)行大量測試工作，畢竟在Hyper-V服務(wù)器上的數(shù)據(jù)遷移管理工作量并不太大。

架構(gòu)師觀點(diǎn)

虛擬光纖通路的出現(xiàn)為本地SAN設(shè)備帶來了有力的技術(shù)支持。不過這項新功能在實(shí)際使用方面仍然存在各種限制，其中最令人難以接受的就是必須使用最新的硬件以及微軟系統(tǒng)平臺。到目前為止我還沒有看到任何真正成功的VFC實(shí)踐經(jīng)驗，例如將多個HBA與單一虛擬SAN相匹配或者將其構(gòu)建為故障轉(zhuǎn)移體系，因此具體實(shí)施方案還需要用戶耐心等待。

VFC的主要改進(jìn)方向有兩點(diǎn)：首次，驅(qū)動器應(yīng)該能夠支持其它平臺，尤其是Linux環(huán)境;其次，如果供應(yīng)商能夠利用虛擬設(shè)備進(jìn)行代碼編寫，那么虛擬SAN裝置(簡稱VSA)應(yīng)該能夠比目前的iSCSI更好地與光纖通路進(jìn)行協(xié)作。

最后再說一句，微軟在這些全新存儲功能的細(xì)節(jié)說明方面做得并不好。直到現(xiàn)在我們也無法在高端博客之外找到任何實(shí)際使用經(jīng)驗，這對于用戶而言顯然不夠貼心。希望這一點(diǎn)能夠盡早得到改觀，讓微軟潛心打造的新功能真正為廣大消費(fèi)者服務(wù)。

tangrong