Iscsi mpio

在ESXi 5.0之前的版本中,要想實現完整的iSCSI MPIO(容錯/負載均衡),需要通過複雜的命令列才能實現。
在ESXi 5.0中,可以通過圖形管理介面來簡單的實現。
步驟:

1 首先,新增一個iSCSI-1 VMKernel (同時會新建一個vSwitch2),(本案例使用vmnic2/vmnic3兩張物理網卡)


9-27-2011 17:27:22 上传

下载附件 (72.99 KB)


9-27-2011 17:27:23 上传

下载附件 (66.8 KB)


9-27-2011 17:27:24 上传

下载附件 (59.8 KB)

2 在vSwitch2中,再添加一個iSCSI-2 VMKernel


9-27-2011 17:27:25 上传

下载附件 (80.8 KB)

然後會得到這樣一個配置的vSwitch2


9-27-2011 17:27:26 上传

下载附件 (21.41 KB)

3 在vSwitch2中,編輯iSCSI-1 VMKernel的屬性,在NIC Teaming下的Override switch failover order處打上勾,
然後將vmnic2設為Active Adapters, vmnic3設為Unused Adapters


9-27-2011 17:27:28 上传

下载附件 (106.95 KB)

同樣的方法編輯iSCSI-2 VMKernel的屬性,在NIC Teaming下的Override switch failover order處打上勾,
這裡要注意,要將vmnic3設為Active Adapters, vmnic2設為Unused Adapters


9-27-2011 17:27:29 上传

下载附件 (97.59 KB)

到此,iSCSI VMKernel設置完成。

4 創建Software iSCSI Adapter(iSCSI Initiator)
在ESXi 5.0中,默認是不存在Software iSCSI Adapter的,沒關係,可以在Storage Adapter中創建一個


9-27-2011 17:27:12 上传

下载附件 (58.13 KB)

 


9-27-2011 17:27:21 上传

下载附件 (23.14 KB)



9-27-2011 17:27:21 上传

下载附件 (78.17 KB)

5 然後在iSCSI SAN中給予此iSCSI Initiator訪問共用vmfs lun的存取權限。
然後在此Software iSCSI Adapter(vmhba35)的屬性中設置iSCSI LUN的連結。


9-27-2011 17:27:30 上传

下载附件 (33.61 KB)


9-27-2011 17:27:31 上传

下载附件 (46.41 KB)

6 在Software iSCSI Adapter(vmhba35)的屬性中設置Network Configuration,將 iSCSI-1和 iSCSI-2加入到其中


9-27-2011 17:27:32 上传

下载附件 (84.48 KB)


9-27-2011 17:27:33 上传

下载附件 (95.36 KB)

然後Rescan All Storage … 添加上分配的LUN, 這是可以看到Patch Status由原來Not used變為了Active.


9-27-2011 17:27:34 上传

下载附件 (82.66 KB)

到此,只實現了 iSCSI MPIO的容錯功能,要實現負載均衡,繼續一下步

7 打開iSCSI Storage的屬性,點擊右下角的Manager Paths…


9-27-2011 17:27:36 上传

下载附件 (111.93 KB)

可以看到默認的Path策略是Fixed(VMWare) – 【固定】,
在下面的路徑資訊中可以看到路徑C1的Status為Active(I/O),
並在Preferred(首選)中標注了*, 而路徑C0的Status為Active,
Preferred中沒有標注*這個策略是不能實現負載均衡的.


9-27-2011 17:27:37 上传

下载附件 (102.46 KB)

將策略改為Round Robin(VMWare) – 【迴圈/輪轉】


9-27-2011 17:27:37 上传

下载附件 (107.03 KB)

修改完成後可以看到:路徑C1和C0的Status都為Active(I/O),Preferred中都沒有標注*


9-27-2011 17:27:38 上传

下载附件 (77.51 KB)

至此,設置基本完成,測試一下多個VM的I/O,可以看到由原來的集中於vmnic2的I/O,現在平均分佈到
vmnic2/vmnic3兩者當中。


9-27-2011 17:27:35 上传

下载附件 (82.05 KB)


9-27-2011 17:27:39 上传

下载附件 (89.5 KB)


9-27-2011 17:27:11 上传

下载附件 (93.17 KB)

鏈路負載均衡策略除了以上的基本設置,還可以通過2個主要參數進行細調,
以符合不同的要求或環境。調整Round Robin策略通過命令列進行操作:

設置完預設的Round Robin策略後,以命令列模式執行

esxcli storage nmp device list

可以看到Round Robin策略的默認設置,其中紅字處標明了當前啟用的策略及其應用參數:
naa.6000eb38732d44470000000000000027
Device Display Name: LEFTHAND iSCSI Disk (naa.6000eb38732d44470000000000000027)
Storage Array Type: VMW_SATP_DEFAULT_AA
Storage Array Type Device Config: SATP VMW_SATP_DEFAULT_AA does not support device configuration.
Path Selection Policy: VMW_PSP_RR
Path Selection Policy Device Config: {policy=rr,iops=1000,bytes=10485760,useA NO=0;lastPathIndex=0: NumIOsPending=2,numBytesPending=36864}

Path Selection Policy Device Custom Config:
Working Paths: vmhba35:C0:T00, vmhba35:C1:T00

VMW_PSP_RR說明當前啟用了Round Robin策略
2個主要的參數 iops=1000, bytes=10485760
前者限定在進行1000次io操作後切換到下一個路徑,後者限定在發送10485760位元組的資料後切換到下一個路徑
可以通過以下命令列來修改這2個參數的值,以符合不同的要求或環境。

修改iops參數:
esxcli storage nmp psp roundrobin deviceconfig set –type=iops –iops 888 –device naa.xxxxxxxxxxxxxxxxxx

修改bytes參數:
esxcli storage nmp psp roundrobin deviceconfig set –type “bytes" -B 12345 –device naa.xxxxxxxxxxxxxxxxxx

iSCSI LUN的UUID(naa.xxx)可以通過命令: esxcli storage core path list 獲取

有很多人關心Jumbo Frames的設置,那就補充一下:
要設置 Jumbo Frames,打開連接iSCSI SAN的vSwitch(vSwitch2)的屬性,在這裡你可以針對整個vSwitch2(All Port)
做JF修改,也可以只針對其中所有設置了MPIO的iSCSI VMkernel(port group)做JF修改。


9-28-2011 10:45:03 上传

下载附件 (52.78 KB)


9-28-2011 10:45:02 上传

下载附件 (62.16 KB)

注1:要能實際啟用Jumbo Frames,整個iSCSI鏈路的所有連接設備(網卡/OS or Hypervisor/交換機/存儲端)都要支援和啟用JF,
才能實現效果。另外,不是所有的設備或環境下啟用Jumbo Frames都能帶來很大性能的提升,建議以自己的評估測試結果
來決定是否啟用。

注2:另外要提醒一點,如果VM中設置了MSCS群集服務,MSCS不能通過設置為Round Robin策略
的路徑來連接MSCS共用盤,否則會出現I/O錯誤。

VM VCB & VDR Collection

VM Backup

 

淺談VMWare虛擬環境架構下的備份方式

VMware虛擬環境架構中,常見的備份主要有四種,分別為:傳統備份方式、VMware

Consolidated Backup (VCB)VMware Data Recovery (VDR)、儲存裝置備份方式。

傳統備份方式:

這種備份方式是將每一個虛擬機器當作實體機器來看待,在每個虛擬機器中安裝所需要的

備份代理程式,並透過既有的成熟備份方案進行作業。優點:

1. 可沿用過去所使用的備份解決方案。

2. 減少資訊管理人員額外的備份教育訓練需求。

缺點:

1. 因為需要在每個虛擬機器安裝備份代理程式,傳統的計價方式可能會造成成本過高。

2. 備份時將嚴重影響線上機器的運作效能(包含其他在同一部實體主機上的虛擬機

器)。

3. 無法充分利用HADRSvMotion等技術帶來的好處。

4. 還原可靠度備受考驗,需不斷進行災害復原演練確保還原作業可行。

 

 

VCB備份方式:

VMware Consolidated Backup (VCB)VMWare所提供的一組Framework,可透過第三方備

份軟體(如:Symantec Back EXEC 2010Vizioncore vRanger ProVeeamPHD

esXpress)或VCB指令,並結合虛擬機器快照及FC / iSCSI傳輸技術來進行備份作業。

其備份動作簡述如下:

1. 凍結虛擬機器,並進行應用程式一致性備份(VSS)

2. 進行虛擬機器快照作業。

3. 解凍虛擬機器。

4. 將快照檔案載入至備份代理伺服器。

5. 執行備份作業。

6. 移除虛擬機器快照檔案。

 

VCB

 

使用VCB備份方式帶來的優點很多,簡述如下:

1. 透過備份代理伺服器,可減低ESX主機的負載(甚至可達到零負載)。

2. 不需要在每個虛擬機器上安裝備份代理程式,可減輕管理負擔及減少軟體授權費用。

3. 透過SAN的傳輸,可大幅減少備份時的網路負載。

4. 可做到映像層級及檔案層級的備份,亦即可完整備份整個系統,也可還原單一檔案。

5. 減少備份所需的時間。

依照系統架構的不同,VCB運作的方式可分為三種,分別為SAN模式、Hot Add模式、

NBD模式,簡述如下:

 

VCB SAN模式:

1. 需要有SAN儲存裝置架構。

2. 備份代理伺服器直接透過FC / iSCSI讀取SAN資料內容。

3. 效能最高、系統負載最小、不會產生額外網路流量


 

 

VCB Hot Add模式:

1. 使用虛擬機器作為備份代理伺服器。

2. 無需將儲存裝置的LUN對應到備份代理伺服器。

3. 可備份該ESX主機上的本機磁碟區及NAS存放裝置(如需備份多台ESX主機上的儲存

裝置,需在各ESX主機上安裝備份代理伺服器)。

4. 會消耗ESX主機資源,備份效能低於SAN模式。

簡單說明如下圖:



VCB NBD模式:

1. SAN儲存裝置架構。

2. 透過網路進行備份傳輸(支援加密傳輸模式)。

3. 備份代理伺服器可安裝於實體機器或虛擬機器。

4. 效能低於SAN模式及Hot Add模式,但仍高於傳統備份方式。

 


 

 

VDR備份方式:

VMware Data Recovery (VDR)VMWarevSphere開始加入的一項備份軟體。

提供於vSphere Essentials PlusAdvancedEnterpriseEnterprise Plus,其備份原理類似於

VCB,支援100個虛擬機以下的備份,適合於中小型的虛擬環境中使用。

VDR為運作於虛擬環境中的虛擬主機,透過VMWare提供的OVF格式進行安裝佈署,其作

業系統平台為CentOS Linux

優點如下:

1. 無需額外的軟體及備份代理程式費用,很適合中小型環境使用。

2. 虛擬機器無需安裝任何備份代理程式。

3. 支援增量備份方式(強制啟用)。

4. 整合vCenter Server排程備份作業。

5. 提供資料重複刪除技術(磁碟映像等級)。

6. 可進行檔案層級還原(實驗階段,僅支援Windows平台)。

缺點如下:

1. 只支援本機、NAS儲存裝置、SAN儲存裝置,不支援磁帶備份。

2. 至多同時支援兩個目標儲存區。

3. 目標儲存區容量限制(網路磁碟500GB、本機磁碟1TB)。

4. 只支援vSphere主機,無法支援ESX 3.5主機。

儲存裝置備份方式:

透過SAN儲存裝置的複寫機制進行備份,如NetAPP SnapMirrorIBM Enhanced Remote

MirroringMetro Mirror等,透過此種備份方式可達到最佳的備份效能,並能透過VMWare

Site Recovery Manager完成異地備援架構。

 

儲存裝置備份一般分為三種方式,簡述如下:

同步複製模式:

1. 主站點需收到遠端站點的I/O回報後,才算完成整個I/O作業。

2. 同步模式適用於高度資料保全要求或機房內部使用,此模式不會產生資料遺失。

3. 因同步模式需等待遠端站點的I/O回報,因此整體運作效能較低,也會受限於頻寬及

距離的限制。

 

非同步模式(無一致性):

淺談VMWare虛擬環境架構下的備份方式 « SaSa技術隨筆手札頁 4 / 6

1. 主站點完成I/O後即算完成整個I/O作業,不需等待遠端站點的回報。

2. 非同步模式適用於大多數的情況。

3. 不保證備援端與主站點有相同的I/O順序。

4. 非同步模式斷線時可能會造成部分資料遺失,需視網路頻寬及距離而定。

5. 非同步模式整體效能高於同步模式,亦較不受頻寬及距離的限制。

 

非同步模式(一致性):

1. 其運作方式與非同步模式(無一致性)相同,差別在於可保證備援端與主站點有相同

I/O順序。

 

Good Article For SNAPSHOT NOTES

大家在用虛擬機器的時候最最看重可能就是虛擬機器的快照功能了,做個快照,然後隨便開始整就算系統壞了,在用快照恢復一

下就OK了,多好的技術呀。但是請記住快照不等於備份,千萬不要把快照當作備份。

 

當虛擬機器開著時,快照提供了一個備份原始VMDK檔的好辦法。所有的寫入操作在原始檔上暫停了,因此,複製它在另

一個存儲卷很安全。這就是像
VMware Consolidated BackupVizioncorevRanger功能那樣的備份應用。它們給虛擬機器進

行快照、備份磁片檔並在完成時刪除快照。

 

諸如VMBK這樣的腳本也提供這種功能。這些程式允許複製VMDK檔到本機存放區或網路共用以提供另一種恢復重要虛擬機器

的方法。

 

只有一個快照的虛擬機器在刪除快照時不需要額外的磁碟空間。不過如果你有許多快照,當刪除所有快照時,你將需要額外的

磁碟空間。這是由於這些快照要合併到原始磁片檔

 

例如,假設你要刪除有三個快照的虛擬機器上的所有快照,我們稱它們為快照1、快照2及快照3。首先,快照3將合併到快

2,快照2的大小將增加。接下來,快照2合併到快照1,快照1的大小也將增加。最後,快照1將合併到原始磁片檔,這

不需要額外的磁碟空間。當原始磁片檔在整個操作結束時更新,快照檔被刪除,而不是每個合併過程時刪除。因此,當

刪除它們時,擁有20GB快照檔的虛擬機器可能需要額外的20GB
( NEW Method When delete all snaopshots all delta direct copy to Base Image)

 

如果你有一台低磁碟空間的ESX主機,這將用光所有可用的磁碟空間,並且阻止你刪除快照。

使用較少額外磁碟空間來刪除多個快照的解決辦法是一個一個刪除它們,從虛擬機器父級快照開始到子級。使用這種方法,當

快照被合併到先前的快照,只有先前快照增加了,然後刪除。這個方法雖然沉悶,但不需要較多的額外磁碟空間。

注意:當虛擬機器有一個快照運行時,不要運行Windows磁片磁碟重組。磁碟重組操作改變許多磁片塊並能引起快照檔急

速增加。

 

多長時間刪除快照當使用VMware Infrastructure ClientVI Client)刪除快照時,這個任務狀態列容易使人誤解。一般來說,任務狀態跳

95%完成率時應該很快完成,不過能注意到它在95%一直不動,直到整個刪除過程完成。VirtualCenter15分鐘的超時時

間。因此,就算你的檔仍然在刪除,VirtualCenter將報告這個操作超時. 找到任務完成的方法是使用VI Client裡的資料存

儲流覽器查看虛擬機器目錄。當delta檔消失了,你就知道快照刪除完成了。

活動了很長時間的快照(因此變得很大)在刪除時需要很長時間。快照刪除需要的時間的變化取決於虛擬機器活動等級;當關

閉虛擬機器時,刪除時間短。ESX主機上的磁片子系統活動數量也能影響快照刪除時的時間。100GB的快照需要36小時合併

到原始磁片。

使用ESX 3.5的話,由於整合演算法的變更,將需要更長的時間。這將影響虛擬機器和ESX主機的性能。正因如

此,你應該限制保留快照的時間長度,在你不需要它們時就刪除。

快照和遠資料鎖定影響ESX性能

快照對ESX主機和虛擬機器的影響有幾種方式。當你第一次創建一個快照時,虛擬機器活動將暫時停止;當創建快照時,如果虛

擬機響了,你將注意到超時。同樣,創建快照引起中繼資料更新,將導致SCSI預留衝突以致鎖定LUN(邏輯單元號)。結果,

在一小段時間裡,LUN只能在ESX Server主機上可用。

如果你創建了個虛擬機器快照並運行虛擬機器,這個快照是活動的。如果這個快照是活動的,由於ESX有區別地寫入delta檔,
不如寫入標準的
VMDK檔那樣有效率,虛擬機器性能將降低。由於中繼資料鎖定了,當一個寫入到磁片時,其他的都不能寫入
delta文件。

同樣,隨著delta檔以每個
16MB增量增加,將引起另一個中繼資料上鎖。這能影響虛擬機器和ESX主機。
性能影響有多大取決於虛擬機器和ESX主機有多繁忙。

最後,刪除一個快照也創建一個中繼資料鎖定。另外,當delta檔正被commit時,你正刪除的快照將造成虛擬機器性能的大幅

度下降。如果虛擬機器非常繁忙,這將很容易看到。為避免這個問題,最好在主機伺服器不繁忙的閒時刪除大的或多個快照。

當快照運行時不要擴充磁片檔

 

當一個快照是活動的時候不能擴充虛擬磁片。在ESX 3.0.x,你只能使用vmkfstools——X command擴充磁片;不過,當你試

圖擴充磁片時,這個指令不會警告你磁片擁有快照。你也可以通過VI Client擴充虛擬磁片,VI Client允許你使用快照擴充磁

盤。VI Client將成功地報告任務完成,不過實際上卻沒有擴充磁片檔。

當一個快照活動時,如果你使用vmkfstools擴充虛擬磁片,虛擬機器將不再工作並出現錯誤:不能打開磁片‘.vmdk’或在它之

上的一個快照磁片。

拒絕虛擬磁片使用快照如果你的一台虛擬機器有多個磁片,你希望拒絕一個磁片使用快照,你必須通過改變磁片模式為獨立來

編輯虛擬機器設置。獨立設置能讓你獨立地控制每個磁片的功能,磁片檔和構造沒有區別。一旦一個磁片是獨立的,它將不

包括任何快照。

另外,你將不能在擁有獨立磁片的虛擬機器上包括存儲快照。這麼做是為了保護獨立的磁片,萬一你恢復到先前的有存儲狀態

的快照,有一個寫入獨立磁片的應用在運行。當其他磁片在恢復時,由於這個獨立磁片沒有恢復,在它上面將有潛在的損壞

數據。


 

vSphere Data Protection replaces VDR with vSphere 5.1

vSphere Data Protection replaces VDR with vSphere 5.1

This new backup product replaces VMware Data Recovery, which has been introduced in vSphere 4.0 and which will still be supported. But from vSphere 5.1 the vSphere Data Protection (VDP) is going to be The Backup product bunled with vSphere.

The VDP has the most of the code from EMC’s Avamar backup product and in fonctionnalities. It’s has more or less the same functions as VDR, (no fancy “Run VM from backup") but much more robust than VDR, and including features that can even rollback the appliance to previous point in time. The backup limit per appliance is 2 Tb and you can have up to 10 VDP appliances managed by single vCenter with tight integration into the New vSphere 5.1 Web Client.

It’s agent-less and disk based backup architecture, which uses vSphere API for Data protection (VADP) with Changed Blocks tracking (CBT) … like VDR does, but there is also some Avamar goodnes there. The appliance uses an EMC’s Avamar variable-length segment de-duplication engine to optimize backup and recovery times. De-duplication is used not only within each VM, but across all backups jobs and all VMs being backed up by the VDP appliance.

Initial backups take a fair amount of time, but subsequent backups can be as little as a few minutes depending on the number of changes that have occurred since the last backup. CBT tracks the changes made to a VM at the block level and provides this information to VDP so that only changed blocks are backed up. VMware Tools on Windows VMs are using Volume Shadow Copy Service (VSS) components to assist with guest OS and application quiescing when backing up Windows VMs.

What are the new functionality and how the product is delivered to the end user?

The VDP is a virtual appliance which is available in 3 sizes for the destination datastores, which will be as in the case of VDR, be used as a deduplication store, to store the backups. So the destination datastore can be configured in 3 sizes:

– 500Gigs, 1Tb, 2Tb

The actual virtual appliance which runs the Suse Linux Enterprise Server 11 (SLES) runs with 4 vCPU and 4 Gigs of RAM. During the deployment process, the thick disks are used, and those disks consume 850 GB (3 .vmdk files), 1600 GB (7 .vmdk files), and 3100 GB (13 .vmdk files) respectively. To create the necessary deduplication destination datastore, which will be used later for the target of the backup jobs.

The VDP appliance can be managed only by vCenter Server 5.1 through web client. VMware is shifting away of the “thick" client so the management of backups through the vSphere Client is possible only through the new vSphere Web Client. And there is no plugin for the “thick" client anymore…. Curiously, the plugin for vSphere Update manager (VUM) hasn’t been released at the same time, but AFAIK the integration of VUM will follow in the days to come.


It’s possible to make a backup of powered Off VMs, since no agent is installed inside of backed up VMs.

The management through web clientrelaying on Flash – good or bad – The management of the appliance is only possible through supported browsers. Currently supported browsers: IE 7, 8 on Windows. Firefox 3.6 and higher on Windows or Linux. Adobe Flash is required, it means that MAC iOS users can’t manage this backup solution (unless they Install VMware Fusion and Windows or Linux VM).

Update: The MAC users can of course use alternate browser supporting Flash plugin. (Firefoex, Chrome).. I’m using Chrome, because ist’s so fast.

The Backup/Restore/Schedulling Possibilities – The Possibilities are about the same as we use to have with VDR, but the product seems to me more robust…. more professional looking and hopefully more reliable than VDR was.

The Sizing of the VDP’s has to be done before the deployment – When deploying the solution, you must think before on what size you’ll need at the destination deduplication datastore since this size cannot be changed later. The same as in VDR.

Here is a screenshot what it looks like just after the deployment of the appliance. The “maintenance mode".


Backup/restoration jobs and scheduling – those tasks are Wizard driven and permits the configuration of backup job. In the UI There are containers such as data centers, clusters, hosts, folders, etc. An individual VMs can be selected for backup. If new VMs are added to a container that is currently backed up (backup job has already been configured), these new VMs will automatically get backed up on the next run of the backup job.


The restore operations – to restore a VM, it seems that the UI stays fairly similar (if not the same) with VDR. There is possibility to restore full VM or FLR (file level restore), by selecting the restore point. Also wizard driven, it’s necessary to provide a name for the restored VM and a location. There is checkbox which enables to select the original location as a restore location.

But again, compared to VDR, the product seems just more mature and more robust, giving you for example more choices when restoring individual files from VM image.

There are some requirements for the FLR though, like the VMware Tools installed inside of the VMs and the file Systems supported (currently Windows NTFS and Linux LVM, Ext 2, Ext 3 and basic disks – non-extended).


Monitoring restore jobs – there is a possibility to monitor restore jobs, by clicking the Monitor Resources button, and see the progress of the restore operations.

8 mount points mounted simultaneously – another thing is that you can mount more than one restore point simultaneously (eight maximum), which can helpful if you are not sure of the exact version/date of the file you need to restore.


Advanced Login Possibilities – 2 ways of login (basic and advanced). The basic login uses local credentials only. The basic login can be used by owners of the VM for example to restore the files inside of that particular VM only.

As for the advanced login, the admin has the possibility to restore files from a VM elsewhere. The advance login requires credentials with administrative permissions on the local machine and credentials with administrative permissions on vCenter Server.

Locking and unlocking backup images – this might be useful for keeping restore points for archiving purposes. The restore point is kept even the retention policy says that the restore point should be deleted.


Reporting capabilities – The VDP has a reporting TAB which provides several pans, which shows each detailed information about the appliance’s status, the status of the backup jobs, the storage capacity, the success (and failures) of backup/restoration jobs.

There are possibility to create filters on specific criterias like VM, last backup date, last backup job occurred within x number of days, etc.


E-mail Reporting – the application provides e-mail reporting capability, which can be schedulled daily at specific time. You can also change the default English language to specific locale (which is pretty nice for customers wishing to receive this information in french, Dutch, or Japanese language).

Backup and Maintenance window – the backup window (Green) runs by default from 8:00 PM to 8:00 AM, the blackout window (Black) blackout window runs from 8:00 AM to 11:00 AM, and the maintenance window (yellow). During backup window the backup jobs can run only. The jobs starts at the beginning of backup window automatically (up to 8 jobs simultaneously – per appliance). If the job overlap the backup window, the job fails.

When the VDP appliance is first deployed and configured, the maintenance services are disabled for the 24-48 hours. This allows for a longer backup window to support the initial backups, which are full backups.

– What is the Blackout Window? – During the blackout window the Garbage collection deletes orphaned chunks of data that are no longer references within any backups on the system. Only restores can be executed, but no other (including administrative) activity can be performed.

Maintenance window – there are integrity checks, which progress is stored in VDP appliance itself. If the process has not finished at the end of maintenance window, it will be picked up the next day, where it left off. You can also force the Integrity checks manually, but obviously the tasks are Full Integrity Checks.


The Integrity checks which runs in the maintenance window are verifying the integrity of deduplication stores. are two types:

– Full: Checks the entire de-duplication store.
– Incremental: Checks the checkpoints since the last full or incremental integrity check.

VDP Rollback and Checkpoints – this feature that I mentioned at the beginning, helps you (if needed) to restore the appliance to the previous point in time (like in windows, the system restore application).


The VDP appliance uses EMC’s Avamar deduplicaiton technology which should perform more smoothly and more efficiently than the VDR. The VDR will still be supported but further developpement was stopped.

I haven’t seen any way to import existent jobs or deduplication stores into VDP….. Any suggestions here from VMware? Are the thousands of customers left to themselves here? Is the only way to setup the new product by re-creating new jobs for your virtual infrastructure?

In my opinion, VMware did a good job here to replace the VDR, since there has been quite a problems with the stability and reliability of VDR.

VMware vSphere 5.1 – More about VMware vSphere 5.1 news from the launch

vSphere 5.1 – New features and enhancements


High Performance Solution

(譯自High Performance Solution)

From EMC 技術觀察員

A revolution has started to free data center networks from the tyranny of inflexibility, complexity, vendor stranglehold, and high costs.

It’s time to decouple network services from the underlying physical hardware.

It’s time to never have to think about the network again.

It’s time to virtualize the network.but…

Adapt From nicira Main Page


引言

接觸網絡虛擬化純屬偶然。那天無意中看到了一條新聞:Xsigo公司推出了業界第一個資料中心網路全虛擬化解決方案。
巧的是Xsigo公司的方案是基於Infiniband技術的,所以就重點關注了一下。這一關注不要緊,才發現裡面水很深。
不管是傳統IT豪強還是網路巨人都對這一領域虎視眈眈,謀篇定局,更有無數的創業者們在此展開深耕。 抱著對技術要略懂的心態,一探究竟。

這篇博文算作者涉水的總結,網路虛擬化發展到現在牽涉的技術非常多,每種技術都可以單獨寫一篇文章來介紹,限於精力和知識水準,只能給大家做個整體的簡單介紹,如果有讀者對某種技術感興趣可以搜索相關資料做更詳細的瞭解。


什麼是網路虛擬化

首先我們需要明確一個問題,什麼是網路虛擬化,網路虛擬化簡單來講是指把邏輯網路從底層的實體網路分離開來。
這個概念存在一段時間了,VLAN,VPN, VPLS等其實都可以歸為網路虛擬化的技術。
近一,二年來, “計算“的浪潮席捲IT界。幾乎所有的IT基礎構架都被有意的朝向著 ““的方向發展。在雲計算的發展中,虛擬化技術一直是重要的推動因素之一。
作為基礎構架,伺服器和存儲的虛擬化已經發展的有聲有色,而同作為基礎構架的網路卻還是一直沿用傳統方式。在這種環境下,網路確實期待一次變革,使之更加符合雲計算和互聯網發展的需求。
雲計算的大環境下,網路虛擬化的定義沒有變,但是其包含的內容卻大大增加了。

雲計算環境下的網路虛擬化需要解決端未到端未的問題,作者將其歸納為三個部分:

(一)第一部分是伺服器內部。隨著越來越多的伺服器被虛擬化,網路已經延伸到Hypervisor內部,網路通信的端已經從以前的伺服器變成了運行在伺服器中的虛擬機器,資料包從1.虛擬機器的虛擬網卡流出,通過2.Hypervisor內部的虛擬交換機,在經過3.伺服器的實體網卡流出到上聯4.交換機。在整個過程中,虛擬交換機網卡的I/O問題以及虛擬機器的網路接入都是研究的重點。

(二)第二部分是伺服器到網路的連接。10Gb乙太網 和Infiniband等技術的發展使一根連接線上承載的頻寬越來越高。為了簡化,通過一種連接技術聚合互聯網路和存儲網路成為了一個趨勢。

(三)第三部分是網路交換,需要將實體網路和邏輯網路有效的分離,滿足雲計
算多租戶,按需服務的特性,同時具有高度的擴展性。

以下面我就圍繞這三個方面來講述網路虛擬化中的一些主要技術和標準。

伺服器內部

I/O虛擬化

多個虛擬機器共用伺服器中的實體網卡,需要一種機制既能保證I/O的效率,又要保證多個虛擬機器對用實體網卡共用使用。
I/O虛擬化的出現就是為了解決這類問題。I/O虛擬化包括了從CPU到設備的一群解決方案。

1.從CPU的角度看,要解決虛擬機器訪問實體網卡等I/O設備的性能問題,能做的就是直接支援虛擬機器記憶體到實體網卡的DMA操作。IntelVT-d技術及 AMD IOMMU技術通過DMARemapping 機制來解決這個問題。
DMARemapping機制主要解決了兩個問題,一方面為每個VM創建了一個DMA保護區域並實現了安全的隔離,另一方面提供一種機制是將虛擬機器的Guest Physical Address翻譯為實體機的Host Physical Address。


2.從虛擬機器對網卡等設備訪問角度看,傳統虛擬化的方案是虛擬機器通過
Hypervisor來共用的訪問一個實體網卡,Hypervisor需要處理多虛擬機器對
設備的併發訪問和隔離等。
這樣Hypervisor容易行成一個性能瓶頸。為了提高性能,一種 做法是虛擬機
器繞過Hypervisor直接操作實體網卡,這種做法通常稱作PCIpass through,
VMware,Xen和KVM都支援這種技術。
但這種做法的問題是虛擬機器通常需要獨佔一個PCI插槽,不是一個完整的解
決方案,成本較高且擴展性不足

另一種做法是設備如網卡直接對上層作業系統或Hypervisor提供虛擬化的功
能,一個乙太網卡可以對上層軟體提供多個獨立的虛擬的PCIe設備並提供虛
擬通道來實現併發的訪問

這種方法也是業界主流的做法和發展方向,目前已經形成了標準,主要包括
SR-IOV(Single Root I/O Virtualization)和
MR-IOV(Multi-Root I/O Virtualization)。
這方面的技術在網上已有很好的文章來做介紹,推薦想進一步瞭解的讀者讀一
下:http://t.cn/aK72XS

(虛擬接入)

在傳統的伺服器虛擬化方案中,從虛擬機器的虛擬網卡發出的資料包在經過伺
服器的實體網卡傳送到外部網路的上聯交換機後,虛擬機器的標識資訊被遮罩
掉了,上聯交換機只能感知從某個伺服器的實體網卡流出的所有流量而無法感
知伺服器內某個虛擬機器的流量,這樣就不能從傳統網路設備層面來保證QoS
和安全隔離。
虛擬接入要解決的問題是要把虛擬機器的網路流量納入傳統網路交換設備
管理之中,需要對虛擬機器的流量做標識。
在解決虛擬接入的問題時,思科和惠普分別提出了自己的解決方案。思科的是
VN-Tag, 惠普的方案是VEPA(VirtualEthernet Port Aggregator)。為了制定
下一代網路接入的話語權,思科和惠普這兩個巨頭在各自的方案上都毫不讓
步,紛紛將自己的方案提交為標準,分別為802.1Qbh802.1Qbg

 

 

 

 

 

關於虛擬接入也有一篇很好的文章來介紹,想深入瞭解的可以看看:
(http://t.cn/hGWnOQ)

網路連接

網路連接技術一直都在追求更高的頻寬中發展。比如Infiniband和10Gb乙太網。在傳統的
企業級資料中心IT構架中,伺服器存儲網路互聯網路的連接是不同結構且分開的。
存儲網路用光纖,互聯網用乙太網線(ISCSI雖然能夠在IP層上跑SCSI,但是性能與光纖比
還是差的很遠)。

資料中心連接技術的發展趨勢是用一種連接線將資料中心存儲網路和互聯網路聚合起來,使伺
服器可以靈活的配置網路埠,簡化IT部署。乙太網上的FCOE技術和Infiniband技術本身都
使這種趨勢成為可能。

Infiniband

Infiniband 技術產生於上個世紀末,是由Compaq、惠普IBM戴爾英特爾微軟Sun七家公司共同研究發展的高速先進的I/O標準。最初的命名為SystemI/O,1999年10月,正式改名為InfiniBand。InfiniBand是一種長纜線的連接方式,具有高速、低延遲的傳輸特性。基於InfiniBand技術的網卡的單埠頻寬可達20Gbps,最初主要用在高性能計算系統中,近年來隨著設備成本的下降,Infiniband也逐漸被用到企業資料中心。為了發揮Infiniband設備的性能,需要一整套的軟體栈來驅動和使用,這其中最著名的就是OFED(Open Fabrics Enterprise Distribution) ,它基於Infiniband設備實現了RDMA(remote direct memory access). RDMA的最主要的特點就是零拷貝和旁路作業系統,資料直接在設備和應用程式記憶體之間傳遞,這種傳遞不需要CPU的干預和上下文切換。
OFED還實現了一系列的其它軟體棧:IPoIB(IP over Infiniband), SRP(SCSI RDMA Protocol)等,這就為Infiniband聚合存儲網路和互聯網路提供了基礎。
OFED由Open Fabrics聯盟負責開發。Open Fabrics最初叫做OpenIB,從2006年開始OpenIB在Infiniband之外也開始支援乙太網,業務做的大了名字也從OpenIB改為Open Fabrics。OFED現已經被主流的Linux發行版本本支持,並被整合到微軟的windows server中。


查看大图

圖1 OFED 軟體棧

 

FCOE

就在大家認為Infiniband就是資料中心連接技術的未來時,10Gb乙太網的出現讓人看到了其它選擇,乙太網的發展好像從來未有上限,目前它的性能已經接近Infiniband(詳見http://www.cisco.com/en/US/prod/collateral/ps10265/le_32804_pb_hpc10ge.pdf),而從現有網路逐漸升級到10Gb乙太網也更易為用戶所接受。
FCOE的出現則為資料中心互聯網路和存儲網路的聚合提供了另一種可能。FCOE是將光纖通道直接映射到乙太網線上,這樣光纖通道就成了乙太網線上除了互聯網網路通訊協定之外的另一種網路通訊協定。FCOE能夠很容易的和傳統光纖網路上運行的軟體和管理工具相整合,因而能夠代替光纖連接存儲網路。雖然出現的晚,但FCOE發展極其迅猛。與Infiniband技術需要採用全新的鏈路相比,企業IT們更願意升級已有的乙太網。在兩者性能接近的情況下,採用FCOE方案似乎性價比更高


網路交換

在這一層面上要解決的問題則是要對現有的互聯網路進行升級,使之滿足新業務的需求,網路虛擬化則是這一變革的重要方向。在這一方向上目前有兩種做法,一種是在原有的基礎設施上添加新的協議來解決新的問題;另一種則完全推倒重來,希望設計出一種新的網路交換模型。

當虛擬資料中心開始普及後,虛擬資料中心本身的一些特性帶來對網路新的需求。實體機的位置一般是相對固定的,虛擬化方案的一個很大的特性在於虛擬機器可以遷移。當虛擬機器的遷移發生在不同網路,不同資料中心之間時,對網路產生了新的要求,比如需要保證虛擬機器的IP在遷移前後不發生改變,需要保證虛擬機器內運行在第二層(鏈路層)的應用程式也在遷移後仍可以跨越網路和資料中心進行通信等等。

在這方面,Cisco連續推出了OTV,LISP和VXLAN等一系列解決方案。

OTV

OTV的全稱叫做Overlay Transport Virtualization。通過擴展鏈路層網路,它可以使局域網跨越資料中心。很多應用需要使用廣播和本地鏈路多播。通過擴展鏈路層網路,OTV技術能夠跨地域的處理廣播流和多播,這使得這些應用所在的虛擬機器在資料中心之間遷移後仍然能夠正常工作。
OTV擴展了鏈路層網路實際上也擴展了其相關的IP子網,需要IP路由同樣的做改變,這就引出了新的問題,這個問題就由LISP來解決了。


LISP

LISP的全稱是Locator/ID Separation Protocol。傳統的網路位址IP蘊含了兩個含義,一個是你是誰(ID),另一個是你在哪裡(Locator)。這樣帶來的一個問題就是如果你的位置變了(Locator變了),IP必須跟著變化。LISP的目標是將ID和Locator分開,再通過維護一個映射系統將兩者關聯。這樣虛擬機器和伺服器在網路不同位置進行遷移時可以保持相同的IP位址。


查看大图


圖2 OTV和LISP的應用

 

VXLAN

VXLAN的目的是在雲計算環境中創建更多的邏輯網路。在雲計算的多租戶環境中,租戶都需要一個邏輯網路,並且與其它邏輯網路能夠進行很好的隔離。在傳統網路中,邏輯網路的隔離是通過VLAN技術來解決的。不幸的是在IEEE802.1Q標準中,VLAN的標識號只有12位元,這就限制了在一定範圍內虛擬網路最多只能擴展到4K個VLANs。為了解決這個問題,思科聯合VMware在今年推出了VXLAN技術,通過MAC in User Datagram Protocol(MAC-in-UDP)封裝技術,加入了一個24位的段識別字。用UDP的多播代替廣播,將資料包限定在目標網段內。VXLAN技術極大的擴充了雲計算環境中所能支援的邏輯網路的數量,同時通過邏輯段可以將邏輯網路擴展到不同的子網內,使虛擬機器能夠在不同的子網間做遷移。

 


查看大图

圖3 VXLAN 框架格式


查看大图

圖4 通過VXLAN來擴展網路

 

NVGRE

對於雲計算環境中的下一代網路,各大IT廠商們都不想隨便就丟掉操控權,就在Cisco推出VXLAN不久,Microsoft就聯合Intel, HP& Dell 提出了NVGRE標準。
NVGRE的全稱是NetworkVirtualization using Generic Routing Encapsulation。它和VXLAN解決相同的問題,只是用了稍微不同的方式,使用GRE (Generic Routing Encapsulation) key的低24位元作為網路租戶的識別字。

 

前面我們講的都是在原有的基礎設施上添加新的協議來解決新出現的問題,而近年來Software Defined Networking (SDN) 的興起則期待從根本上改變目前的網路交換模式。

SDN中最著名的就是OpenFlow。

OpenFlow

0penFlow論壇起源於斯坦福大學的"Clean slate"計畫,開始主要是為了設計一種新的互聯網實驗環境。在目前的實驗網上沒有實際足夠多的使用者或者足夠大的網路拓撲來測試新協定的性能和功能,最好的方法是將運行新協定的實驗網路嵌入實際運營的網路,利用實際的網路環境來檢驗新協定的可行性和存在的問題。
OpenFlow的切入點是目前已有的互聯網上的交換設備。無論是交換機還是路由器,最核心的資訊都保存在flow table裡面,這些flow table用來實現諸如轉發、統計、過濾等各種功能。雖然不同生產廠家有不同格式的flow table,但可以抽取出絕大多數switch和router都有的一些通用的功能。OpenFlow試圖提出一種通用的flow table設計,能被所有廠家的設備所支援。通過控制flow table能夠實現網路流量的分區,將網路流量劃分為不同的資料流程,這些資料流程能被歸於不同的組且相互隔離,能夠按照需要來處理和控制。更重要的是flow table支持遠端的訪問和控制。OpenFlow的flow table中每一個entry支援3個部分:規則,操作與狀態規則是用來定義flow;操作就是轉發丟棄等行為狀態部分則是主要用來做流量的統計

有了Open FLow,我們可以在正常運行的網路中自己定義一些特殊的規則,通過定義不同的flow entry讓符合規則的流量按照我們的需求走任意的路徑,可以達到把實體網路切成若干不同的虛擬邏輯網路目的。所以,OpenFlow將傳統的互聯網改造成為了動態可變的軟體定義互聯網(SoftwareDefined Networking )。OpenFlow的發展異常迅速,就連Cisco如今也開始擁抱Open Flow。

總結

網路虛擬化當前IT發展最熱門的方向之一,是雲計算基礎架構的核心技術。網路虛擬化涉及的面非常的廣,本文也只為認識做了粗淺的介紹。

 

備註

在網路虛擬化方面不僅很多大公司在搶佔操控權,很多初創公司也在努力開拓機會,這裡把知道的中小公司稍微做下總結,供大家參考:

Nicira:專注於Open Flow的神秘公司。

Big Switch:提供基於OpenFlow的網路虛擬化解決方案

Juniper Networks:支持OpenFlow

Open vSwitch: 一個開源的虛擬switch ,它是一個軟體switch能運行在Hypervisor裡, 目前已是XenServer 6.0 的預設switch。

Conte Xtream:借鑒Grid的思想,通過DHT(Distributed Hash Table)在傳統的網路之上建立一個虛擬的抽象的網路,解決雲主機服務提供者們在網路靈活性,多租戶和擴展性方面的挑戰。

Embrane: 提供一種on-demand的虛擬化網路服務,比如服務的負載均衡,防火牆,VPN。

Xsigo: 提供基於Infiniband技術的資料中心全虛擬化方案。

NextIO:提供基於PCIe技術 的I/O虛擬化產品。

希望通過粗略的理解,引來更多專家的討論,最終對這個概念提出一個明確、清晰的認識。畢竟,技術名詞是要落地的,我們需要的是"雲計算"而不是"暈計算"或是 “雲而不計算"。