在 vSphere Replication 中使用 trim/unmap 客體作業系統命令時,儲存區和網路頻寬需求可能會增加。您可能還會觀察到 RPO 違規。
使用客體作業系統 Trem/Unmap 命令後的增量同步
呼叫 trim/unmap 命令可能會增加目標站台上的儲存區耗用量。
在來源站台磁碟上使用 trim/unmap 命令後,磁碟上的可用空間將新增到 vSphere Replication 在下一個 RPO 週期內傳輸到目標站台的資料區塊。因此,當來源站台磁碟空間不足時,傳輸到目標站台的已變更區塊的大小會更大。
例如,如果來源站台磁碟為 10 TB,且僅配置了 1 TB,則呼叫 trim/unmap 命令將導致至少向目標站台傳輸 9 TB 資料。
如果來源站台磁碟為 10 TB,配置了其中的 9 TB,且刪除了 2 TB 資料,則呼叫 trim/unmap 命令將導致至少向目標站台傳輸 3 TB 資料。
由於增量同步,並且根據目標站台上虛擬機器儲存區原則定義的 RAID 組態,複寫虛擬機器的儲存區消耗可能是來源虛擬機器消耗的兩倍以上。
在目標站台上看不到複寫虛擬機器的儲存區消耗。您只能查看整個 vSAN 資料存放區的總體消耗。因此,您無法在虛擬機器磁碟層級追蹤回收的儲存空間,但可以透過查看 vSAN 資料存放區上剩餘的總體可用空間來追蹤該空間。
在來源虛擬機器上使用 Trim/Unmap 命令後出現復原點目標違規
您可以手動呼叫 trim/unmap 命令,也可以由客體作業系統在特定時間間隔呼叫這些命令。在這兩種情況下,命令後的同步可能需要很長時間。
使用 trim/unmap 命令回收來源虛擬機器上未使用的空間時,可能會產生大量變更的磁碟區塊。同步這些變更可能需要比已設定 RPO 更長的時間,並且 vSphere Replication 開始報告 RPO 違規。
由於複寫落後於 RPO 排程,因此為了同步變更的磁碟區塊,新的增量同步將在前一個執行個體同步完成後立即開始。此即時後續增量同步程序將繼續進行,直到 vSphere Replication 建立滿足 RPO 排程的複本執行個體且不報告 RPO 違規。複寫狀態變為 [正常]。
使用 vSphere Replication 篩選器驅動程式的 Unmap 處理模式
在 ESXi 7.0 Update 3 或更新版本上,依預設,如果 SCSI Unmap 命令覆寫傳輸到目標站台的內容,vSphere Replication 篩選器驅動程式在同步作業期間將無法執行這些命令。客體作業系統稍後將重試該命令,而不會影響在虛擬機器中執行的應用程式。某些客體作業系統不喜歡篩選器驅動程式的這種行為,在同步作業正在進行時可能會變得無回應。
在 ESXi Update 2 或更早版本上,hbr_filter
具有不同的 Unmap 處理模式,該模式透過保留傳輸的內容來執行 Unmap 命令。某些客體作業系統在此模式下表現更好,但是該方法存在一些缺點:
- 用於保留慢速儲存區上的重疊區域的額外讀取和寫入作業可能會導致意外延遲。這些延遲可能會導致某些客體作業系統在同步作業期間發出裝置重設。
- 保留的磁碟內容會暫時增加儲存空間耗用量。
必要條件
- 在 ESXi 7.0 Update 3 或更新版本上,可以使用 ESXi 進階設定恢復到以前的行為