河北 王春海 楚小彬 趙志波 薛慶友
某企業VMware vSphere虛拟化環境，虛拟化管理中心vCenter Server版本是7.02，該vCenter Server管理了多個群集，其中2個群集是ESXi 7.02的版本，剩餘其他群集是ESXi 6.7版本。每個群集有幾十台到上百台業務虛拟機不等。該虛拟化群集使用Veeam Backup & Replication（下面簡稱VBR） V11.0的版本實作虛拟機的備份和虛拟機的複制。
1 虛拟機複制中出現問題
使用者備份的虛拟機數量從最初的幾十台增加到二百多台。當備份虛拟機的數量增加後，有的時候備份任務不能在24小時以内完成，這樣就造成備份任務積壓。雖然備份的虛拟機數量較多，但這些虛拟機的資料增量并不大。在目前的備份方案設計中，VBR備份與管理機與備份代理都是vSphere中的虛拟機，其中VBR管理虛拟機配置了16 vCPU和32GB記憶體，用于VBR備份代理虛拟機配置了8 vCPU和16GB記憶體，從VBR備份伺服器到VMware vSphere虛拟化環境是10G bit/s的網絡，備份伺服器的存儲性能足夠，不存在明顯的瓶頸。
經過檢查備份任務，發現在備份某些虛拟機時花費的時間較長。圖1是備份一台配置設定了較大容量磁盤（合計14.1 TB）虛拟機的備份執行時間截圖，這台虛拟機的增量備份使用了14小時13分鐘多的時間。
圖1 備份的虛拟機及花費的時間
檢視備份任務，發現VBR在備份該虛拟機時無法使用hotadd功能，而是使用Network方式。
【說明】Veeam Backup & Replication（VBR）在備份虛拟機時，支援3種傳輸模式：Direct Storage Access（直接存儲通路）、Virtual Appliance（虛拟裝置）和Network（網絡）。在這3種傳輸模式中，Direct Storage Access效率最高，Virtual Appliance其次，Network最差。
Direct Storage Access主要用于通過 FC、FCoE、iSCSI 和共享 SAS 存儲連接配接到 ESXi 主控端的共享 VMFS SAN LUN 上的虛拟機。
Virtual Appliance不如Direct Storage Access高效，但性能比Network模式高。如果将備份代理的角色配置設定給虛拟機，則建議使用虛拟裝置模式。
在Virtual Appliance模式下，VBR使用 VMware SCSI HotAdd 功能，該功能允許在虛拟機運作時将裝置連接配接到虛拟機。對于備份vSAN存儲的虛拟機，建議優先使用Virtual Appliance的HotAdd功能。
通過檢視Veeam官方文檔，檢視hotadd的要求，得到如下的相關資訊：
（1）對于vSphere 5.5及更高版本，hotadd支援的最大VMDK上限為62TB。
（2）Hotadd是SCSI功能，不支援IDE磁盤。VMware 虛拟SCSI控制器，每個SCSI控制器最多支援15個裝置。
（3）如果任何磁盤是使用比正在備份的 VM 更新的硬體版本建立的，如果磁盤從硬體版本 8 的 VM 移動到硬體版本 7 的 VM，則 HotAdd 可能會失敗。要解決這個問題應更新 VM 的硬體版本。
使用VBR備份虛拟機的時候，如果源端或目标端不支援hotadd時，可以檢查虛拟機硬體版本、備份代理并發數量、資料傳輸模式等配置，下面一一介紹。
2 檢查VBR管理伺服器與備份代理虛拟機硬體版本
首先檢查需要備份的虛拟機的硬碟大小。檢查發現，需要備份的虛拟機單一虛拟硬碟不超過62TB，并且都是SCSI虛拟磁盤。這些都滿足hotadd的要求。
但在檢查中發現，使用hotadd備份成功的虛拟機的硬體版本和VBR虛拟機備份版本相同，備份不成功的虛拟機硬體版本高于VBR虛拟機硬體版本。
安裝VBR備份管理軟體的虛拟機硬體版本是ESXi 6.0（虛拟機版本11）（如圖3所示），而要備份的虛拟機的硬體版本是ESXi 6.7及更高版本（虛拟機版本14），如圖4所示。
圖3 檢查VBR虛拟機硬體版本
在使用hotadd備份虛拟機版本為14的虛拟機時，該虛拟機建立快照并且快照前的磁盤以“從屬”模式添加到VBR的虛拟機時，由于VBR所在虛拟機硬體版本為11，無法使用hotadd模式備份虛拟機硬體版本為14的虛拟機，這就導緻使用hotadd功能備份失敗。
找到問題原因，解決就比較容易了。等VBR目前備份任務完成後，關閉VBR的虛拟機，更新虛拟機硬體到最新版本（該虛拟機所在環境為vSphere 7.0 U2），将VBR虛拟機硬體版本更新到ESXi 7.0 U2及更高版本（虛拟機版本19）。更新完成後打開虛拟機電源。
在更新虛拟機硬體的時候，并不需要關機，但需要重新啟動。對于需要批量更新虛拟機硬體版本的虛拟機，例如目前配置為VBR備份代理的虛拟機，可以選中這些虛拟機并用滑鼠右鍵單擊，在彈出的快捷菜單中選擇“相容性→排程虛拟機相容性更新”（如圖6所示），在彈出的“排程虛拟機相容性更新”對話框中選擇“是”，在“調試虛拟機相容性更新”對話框的“相容”選項下拉清單中選擇“ESXi 7.0 U2及更高版本”，并且選中“僅在正常關閉客戶機作業系統後更新”，單擊“确定”按鈕，如圖8所示。
圖6 相容性
圖8 更改相容性
然後批量重新啟動備份代理虛拟機。等虛拟機重新啟動後，虛拟機硬體版本更新到ESXi 7.0 U2及更高版本（虛拟機版本19）。
在更新了VBR備份管理虛拟機及備份代理虛拟機硬體相容性版本到最高後，再次重新啟動備份任務，同樣的任務此次隻用了24分17秒。
3 檢查備份代理的并發數量
VBR備份代理支援多個并發，每個并發處理一個VMDK。VBR備份管理伺服器與備份代理安裝在虛拟機中，VMware虛拟機預設隻添加一個虛拟SCSI控制器，每個虛拟SCSI控制器最大支援15個SCSI裝置。如果VBR備份管理伺服器配置15個以上CPU并且設定VBR備份代理并發上限超過15個時，就可能會出現問題。
例如：對于VBR備份代理虛拟機，假設配置設定16個vCPU和32GB記憶體，該備份代理虛拟機配置1個100GB的虛拟硬碟，那在配置1個虛拟SCSI控制器時，剩餘的可用并發裝置隻剩下14個。在設定16個并發時，就有2個不足。對于設定15個及以上vCPU時，關閉VBR管理伺服器或備份代理虛拟機，編輯虛拟機設定，在“添加新裝置”中選擇“控制器→SCSI控制器”，添加第2個SCSI控制器（如圖11所示），每台虛拟機最多可以添加4個SCSI控制器（如圖12所示），最多可以支援60個SCSI裝置。
圖11 添加SCSI控制器 圖12 一共4個SCSI控制器
在添加控制器之後，打開虛拟機電源，修改VBR備份代理并發數為16個（Veeam推薦每個并發代理使用1個vCPU），如圖13所示。
圖13 設定并發代理數量
4 檢查備份代理是否有卡住的VMDK
正常情況下，用做備份代理的虛拟機隻有1個硬碟。在本次備份任務完成後，檢查備份代理虛拟機配置，應該隻有1個硬碟。但是，如果檢查中發現有“遺留”的快照磁盤（如圖14所示），需要檢視“多出”硬碟的具體位置，通過硬碟的名稱和儲存位置，檢視多出的硬碟是屬于需要備份的虛拟機（生産中的虛拟機），還是已經備份後的虛拟機（副本虛拟機）。如果是生産虛拟機，檢視一下生産虛拟機是否有多餘的快照。如果是副本虛拟機，同樣檢查是否有非正常的副本快照，檢查副本虛拟機是否需要“整合”的提示（如圖15所示）。在确認備份代理中有“遺留”的快照磁盤後，編輯虛拟機裝置，移除遺留的硬碟但不要選中“從資料存儲删除檔案”（如圖16所示）。
圖14 備份代理中有2個遺留的硬碟
圖15 檢查虛拟機複制的副本 圖16 移除多出的硬碟
5 檢查備份（複制）任務資料傳輸模式
首先檢查備份任務，在“Data Transfer”的“Source proxy（源端代理）”和“Target proxy（目标端代理）”中選擇“Automatic selection（自動選擇）”，如圖17所示。
然後檢查備份代理，在“Transport mode”中選擇“Automatic Selection（自動選擇）”，如圖18所示。
圖17 自動選擇
圖18 自動選擇傳輸模式
6 嘗試修改ESXi虛拟交換機網卡綁定順序
在運作幾天之後檢查發現，有的虛拟機在使用VBR備份時，無法在目标代理使用hotadd，進而導緻備份速度較慢，如圖19所示。
圖19 目标端代理無法使用hotadd
這個問題，經過反複檢查，是VBR管理伺服器與VBR備份代理虛拟機所在的ESXi主機虛拟交換機網卡綁定順序造成的。在目前的示例中，VBR管理伺服器（虛拟機名稱為VeeamSer01-200.25）、VBR備份代理（虛拟機名稱為Veeam-Proxy07-200.37）所在的ESXi主機使用标準交換機vSwitch0，該虛拟交換機管理端口、虛拟機流量端口使用了2塊10G bit/s的網卡用于備援，隻要修改vSwitch0的綁定順序，将其中一塊網卡設定為“活動擴充卡”（本示例為vmnic2），将另一塊網卡設定為“備用擴充卡”（本示例為vmnic3）（如圖20所示），修改之後如圖21所示。
圖20 指定網卡綁定順序
圖21 指定網卡綁定順序
經過這樣修改後，VBR再執行備份後，可以在目标備份代理使用hotadd技術，備份速度提升。
7 備份虛拟機數量較多時增加并發快照數量
VBR備份作業預設情況下，最多同時為4個VM建立快照。如果一個備份任務中VM數量很多時，即使你配置了多個備份代理，仍然隻能最多同時處理4個VM，其他的虛拟機會顯示：Resource not ready: Active snapshots limit reached for datastore。如圖23所示。
圖23 快照數量限制
如果要解決這個問題，增加同時處理VM的數量，需要修改系統資料庫，在VBR備份管理伺服器上運作regedit，定位到HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication，添加類型為REG_DWORD ，名稱為MaxSnapshotsPerDatastore的字元串值，修改為4以上的數值，例如修改為8（如圖24所示）。注意，不要将此數值修改的過大，以防止超過存儲的承受能力。在實際的生産環境中，可以在每次備份任務完成後，依次增加該數值，然後重新開機伺服器，然後檢視下次備份任務完成的時間。不要為了追求減少備份的時間而過多修改此數值以避免對存儲造成過載。
圖24 修改并發數
在修改并發數并重新開機生效後，在下一次任務執行時，當某個備份任務中虛拟機數量較多時，并且配置了足夠多的備份代理時，備份任務執行的總體時間會縮短許多。
例如：某備份任務中，需要備份的虛拟機數量為59台。在快照上限為4時，備份完成的時間是3小時28分29秒（如圖25所示）。修改快照上限為8後，備份完成的時間是2小時35分58秒（如圖26所示）。對比其中備份任務，當備份任務中，需要備份的虛拟機數量超過4台時，并發任務的增加可以減少任務總體完成的時間。
圖25 快照并發上限為4 圖26 快照并發上限為10
【說明】不同的虛拟機，根據需要可以建立不同數量的虛拟硬碟，在備份的時候，每一塊虛拟硬碟占用一個（并發）備份代理。假裝置份任務中有20台虛拟機，每台虛拟機有2塊硬碟。在不修改快照上限為4時，啟動備份任務時，同時為4台虛拟機建立快照，一共需要8個并發備份代理即可。在修改快照上限為8後，啟動備份任務後，同時為8台虛拟機建立快照，一共需要16個并發備份代理。
有的虛拟機隻有1個硬碟，那麼這個虛拟機備份的時候隻需要1個并發代理。
大多數的虛拟機會有2至3個硬碟，那麼這些虛拟機備份的時候就需要2到3個并發代理。
是以，如果備份的源虛拟機都在同一台共享存儲上（vSAN可以看做一台共享存儲），并且需要備份的虛拟機的硬碟數量較少時，即使設定了過多的備份代理也沒有多少實際的意義。
（1）這篇文章最初發表在《網絡安全和資訊化》雜志2021年第11期的第146～151頁。
（2）更加詳細的内容可以參看以下圖書：
VMware虛拟化與雲計算應用案例詳解（第3版）
https://item.jd.com/12939315.html
（3）檢視相關視訊可以看
基于Veeam V11的實體機和虛拟機的備份容災應用視訊
https://edu.51cto.com/course/27783.html