vSphere Replication で trim/unmap ゲスト OS コマンドを使用すると、ストレージおよびネットワーク バンド幅の要件が増加することがあります。また、RPO 違反が発生する場合もあります。
ゲスト OS の trim/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 構成によっては、レプリケートされた仮想マシンのストレージ消費量がソース仮想マシンの使用量の 2 倍以上になることがあります。
ターゲット サイトでは、レプリケートされた仮想マシンごとにストレージ使用量を確認することはできません。表示できるのは、vSAN データストア全体での総使用量です。したがって、解放されたストレージ容量を仮想マシン ディスク レベルで追跡することはできませんが、vSAN データストアに残っている空き容量の合計を確認することで追跡できます。
ソース仮想マシンに trim/unmap コマンドを使用した後の目標復旧ポイント違反
trim/unmap コマンドは、手動で呼び出すか、または特定の間隔でゲスト OS から呼び出すことができます。どちらの場合も、コマンド実行後の同期にかなりの時間がかかることがあります。
trim/unmap コマンドを使用してソース仮想マシンの未使用領域を再要求すると、変更されたディスク ブロックが大量に生成されることがあります。これらの変更の同期には、構成された RPO よりも長い時間がかかる場合があるため、vSphere Replication は RPO 違反の報告を開始します。
レプリケーションは RPO スケジュールの後に配置されるため、変更されたディスク ブロックを同期するために、新しい増分同期は前のインスタンスの同期の完了直後に開始されます。この連続した増分同期プロセスは、vSphere Replication が RPO スケジュールに従うレプリカ インスタンスを作成し、RPO 違反を報告しなくなるまで継続されます。レプリケーション ステータスは [OK] になります。
vSphere Replication フィルタ ドライバのマッピング解除処理モードの使用
ESXi 7.0 Update 3 以降、デフォルトでは SCSI UNMAP コマンドによってターゲット サイトに転送されたコンテンツがオーバーライドされた場合、同期操作中に vSphere Replication フィルタ ドライバからこのコマンドを実行することはできません。ゲスト OS では、仮想マシンで実行されるアプリケーションに影響を与えずに、コマンドを後から再試行します。一部のゲスト OS はフィルタ ドライバのこの動作に対応しておらず、同期操作の進行中に応答しなくなることがあります。
ESXi 7.0 Update 2 以前では hbr_filter のマッピング解除処理モードが異なり、転送されたコンテンツを保持することで UNMAP コマンドに対応します。一部のゲスト OS はこのモードで適切に動作しますが、この方法には次に示すようないくつかの欠点があります。
- 低速ストレージで重複する領域を保持するための追加の読み取り/書き込み操作により、予期しない遅延が発生する可能性があります。これらの遅延が原因で、一部のゲスト OS が同期操作中にデバイスのリセットを実行することがあります。
- 保持されたディスク コンテンツによるストレージ容量の使用が一時的に増加します。
前提条件
- ESXi 7.0 Update 3 以降では、ESXi の詳細設定を使用して、以前の動作に戻すことができます。
