![[Amazon FSx for NetApp ONTAP] SMBのサーバーサイドコピーはできるのか確認してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-9e9d102dfa6d7896319b16fe069cdf55/c3bbbeab42ba5764c5a573e979719805/amazon-fsx-for-netapp-ontap)
[Amazon FSx for NetApp ONTAP] SMBのサーバーサイドコピーはできるのか確認してみた
2025.02.20ONTAPでSMBのサーバーサイドコピーができるか気になる
こんにちは、のんピ(@non____97)です。
皆さんはONTAPでSMBのサーバーサイドコピーができるか気になったことはありますか? 私はあります。
通常サーバー上のファイルのコピーをする際には一度クライアント側で読み込んで、クライアントからサーバーに書き込む必要があります。
一方、サーバーサイドコピーはクライアントが間に入らずにサーバー内で読み書きを行います。
間にクライアントが入らないため、ネットワーク転送のコストが減り、コピー速度の向上が見込まれます。また、クライアントのCPUやメモリ、ネットワーク負荷の軽減も見込まれます。
イメージは以下が分かりやすいです。
抜粋 : Accelerating NFS with Server-side Copy
NFSではNFSv4.2からサーバーサイドコピーをサポートしています。
- Server-Side Copy
The server-side copy features provide mechanisms that allow an NFS
client to copy file data on a server or between two servers without
the data being transmitted back and forth over the network through
the NFS client. Without these features, an NFS client would copy
data from one location to another by reading the data from the source
server over the network and then writing the data back over the
network to the destination server.If the source object and destination object are on different file
servers, the file servers will communicate with one another to
perform the COPY operation. The server-to-server protocol by which
this is accomplished is not defined in this document.The copy feature allows the server to perform the copying either
synchronously or asynchronously. The client can request synchronous
copying, but the server may not be able to honor this request. If
the server intends to perform asynchronous copying, it supplies the
client with a request identifier that the client can use to monitor
the progress of the copying and, if appropriate, cancel a request in
progress. The request identifier is a stateid representing the
internal state held by the server while the copying is performed.
Multiple asynchronous copies of all or part of a file may be in
progress in parallel on a server; the stateid request identifier
allows monitoring and canceling to be applied to the correct request.RFC 7862 - Network File System (NFS) Version 4 Minor Version 2 Protocol
では、SMBはどうでしょうか。
SMBはサーバーサイドコピーとは別にOffload Data Transfer (ODX)という類似の機能があります。
通常サーバーサイドコピーは同一ストレージ内に閉じたコピーのみをサポートする形を指すことが多いのですが、ODXでは異なるストレージ間でのコピーも可能です。
抜粋 : Windows オフロード データ転送 - Windows drivers | Microsoft Learn
これはありがたいですね。
ODXをサポートしているかはSMBサーバー次第です。
例えば、SambaではODXをサポートしていないようです。
Samba does not currently support ODX - SMB2 FSCTL_SRV_COPYCHUNK server-side copies offer similar benefits, without the need for an ODX capable storage array or emulation within Samba.
気になるONTAPですが、ODXをサポートしています。
Microsoft Offloaded Data Transfer （ ODX ；オフロードデータ転送）は コピーオフロード とも呼ばれ、この機能を使用すると、ストレージデバイス内または互換性があるストレージデバイス間で、ホストコンピュータを介さずにデータを直接転送できます。
ONTAPでは、SMBプロトコルとSANプロトコルの両方でODXがサポートされます。
ODX以外のファイル転送では、ソースからデータが読み取られ、ネットワーク経由でホストに転送されます。ホストは、データをネットワーク経由でデスティネーションに転送します。ODXファイル転送では、ホストを経由せずに、データがソースからデスティネーションに直接コピーされます。
NetAppのドキュメントには以下のようにODXのトークンのやり取りについても細かく説明されています。
- エクスプローラを使用するか、コマンドラインインターフェイスを使用するか、仮想マシンの移行の一環として、ユーザがファイルをコピーまたは移動します。または、アプリケーションによってファイルのコピーまたは移動が開始されます。
- ODX 対応のクライアントが、この転送要求を ODX 要求に自動的に変換します。
CIFS サーバに送信される ODX 要求には、トークン要求が含まれています。- CIFS サーバで ODX が有効になっていて、接続が SMB 3.0 経由の場合は、ソースのデータを論理的に表したものであるトークンが CIFS サーバによって生成されます。
- クライアントは、データを表すトークンを受信し、書き込み要求を使用してそのトークンをデスティネーション CIFS サーバに送信します。
ネットワーク経由でソースからクライアントにコピーされ、クライアントからデスティネーションにコピーされるのは、このデータだけです。- トークンがストレージサブシステムに送信されます。
- コピーまたは移動が SVM によって内部的に実行されます。
コピーまたは移動されるファイルが 8MB より大きい場合、コピーを実行するには複数のトークンが必要になります。コピーが完了するまで、必要に応じて手順 2~6 を実行します。
気合い十分という感じですね。
実際にAmazon FSx for NetApp ONTAP(以降FSxN)でもODXを使用できるか確認してみます。
いきなりまとめ
- Amazon FSx for NetApp ONTAPでもODXはサポートしている
- ODXが動作している場合、クライアントとSMBサーバー間の読み書きのリクエストは最小限に抑えられる
- Readは数百KBは必ず発生する
- Writeはファイルを作成する際に発生する
- ODXが動作している場合、
FSCTL_OFFLOAD_READとFSCTL_OFFLOAD_WRITEのリクエスト/レスポンスが発生する - 異なるSMBサーバー間のファイルコピーでもODXは動作する
- FSxNにおけるODNの条件は以下のとおり
- ソースボリュームサイズが1.25GB以上
- ボリュームタイプがDPおよびLSMではない
- ソースボリュームの重複排除が有効
- 同一FSxNファイルシステム内
- ファイルサイズが256KB以上
- ODXをサポートするアプリケーションを使用している
- エクスプローラー
- PowerShell の copy コマンド
- コマンドプロンプト の copy コマンド
- Robocopy
ONTAPにおけるODXの要件
SMBでアクセスする際のONTAPにおけるODXの要件を確認します。
まず、大きな前提としてODXはSMB 3.0以上 かつ サーバーとクライアントがODXをサポートしている場合に動作します。
SMB環境では、この機能は、クライアントとストレージサーバの両方でSMB 3.0およびODX機能がサポートされている場合にのみ使用できます。SAN環境では、この機能は、クライアントとストレージサーバの両方でODX機能がサポートされている場合にのみ使用できます。ODXをサポートしていてODXが有効になっているクライアントコンピュータでは、ファイルの移動またはコピー時にオフロードされたファイル転送が自動的かつ透過的に使用されます。ODXは、ファイルをエクスプローラでドラッグアンドドロップしたか、コマンドラインのファイルコピーコマンドを使用したか、クライアントアプリケーションによってファイルコピー要求が開始されたかに関係なく使用されます。
その他ソースボリュームのサイズやボリュームタイプ、ファイルサイズなどの制約があります。
ボリュームに関するガイドライン
- 次のボリューム構成では、ODXをコピーオフロードに使用できません。
- ソースボリュームサイズが 1.25GB 未満である必要があります
ODXを使用するには、ボリュームサイズが1.25GB以上である必要があります。- 読み取り専用ボリューム
負荷共有ミラー、SnapMirrorまたはSnapVaultデスティネーションボリュームにあるファイルやフォルダにはODXを使用できません。- ソースボリュームが重複排除されていない場合
- ODXコピーはクラスタ内のコピーでのみサポートされます。
ODXを使用して、ファイルやフォルダを別のクラスタ内のボリュームにコピーすることはできません。その他のガイドライン
- SMB環境でコピーオフロードにODXを使用するには、256KB以上のファイルである必要があります。
サイズが小さいファイルは、従来のコピー処理を使用して転送されます。- ODXコピーオフロードでは、コピープロセスの一部として重複排除が使用されます。
データのコピーまたは移動時にSVMのボリュームで重複排除が発生しないようにするには、そのSVMでODXコピーオフロードを無効にする必要があります。- データ転送を実行するアプリケーションは、ODXをサポートするように記述する必要があります。
ODXをサポートするアプリケーションの処理は次のとおりです。
- 仮想ハードディスク（VHD）の作成と変換、スナップショットの管理、仮想マシン間でのファイルのコピーなど、Hyper-Vの管理操作
- エクスプローラでの操作
- Windows PowerShell の copy コマンド
- Windows コマンドプロンプトの copy コマンド
WindowsコマンドプロンプトのRobocopyはODXをサポートしています。
やってみた
検証環境
実際に試してみます。
検証環境は以下のとおりです。
![[Amazon FSx for NetApp ONTAP] SMBのWrite LengthとRead Lengthをパケットキャプチャして確認してみた検証環境構成図.png](https://devio2024-2-media.developers.io/upload/0RqxpJ2Gm3nEdxVLGKLWmq/2025-02-12/ItcgSQDI7xl0.png)
SMBクライアントのEC2インスタンスからSMBでファイルの読み書きをして、その時発生するSMBのパケットを確認します。
EC2インスタンスはWindows_Server-2022-English-Full-Base-2024.07.10から作成しました。また、インスタンスタイプはt3.largeです。
Amazon FSx for NetApp ONTAP(以降FSxN)ファイルシステムのスループットキャパシティは128MBpです。
使用するSMBファイル共有は以下記事で作成したprevious-version-test-shareです。
エクスプローラーでコピーアンドペースト (ODX無効)
まず、ODXが無効な状態でエクスプローラーでファイルをコピーアンドペーストします。
接続で使用しているSMBバージョン、ボリュームサイズ、重複排除、ODXの状態を確認します。
::> version
NetApp Release 9.15.1P5: Sun Nov 24 16:31:37 UTC 2024
::> cifs session show
Node: FsxId0e64a4f5386f74c87-01
Vserver: svm
Connection Session Open Idle Connection
ID ID Workstation Windows User Files Time Count
---------- ------- ---------------- ---------------- --------- ------------ ---------------
338489469 12524229088740638735 17s 4
10.0.0.34 CORP\ 3
Administrator
::> cifs session show -instance
Vserver: svm
Node: FsxId0e64a4f5386f74c87-01
Session ID: 12524229088740638735
Connection ID: 338489469
Incoming Data LIF IP Address: 10.0.8.246
Workstation IP Address: 10.0.0.34
Authentication Mechanism: Kerberos
User Authenticated as: domain-user
Windows User: CORP\Administrator
UNIX User: root
Open Shares: 1
Open Files: 3
Open Other: 0
Connected Time: 20m 28s
Idle Time: 20s
Protocol Version: SMB3_1
Continuously Available: No
Is Session Signed: false
NetBIOS Name: -
SMB Encryption Status: unencrypted
Large MTU Enabled: true
Connection Count: 4
Active Shares: previous-version-test-share
::> volume show -vserver svm -volume vol_previous_version_test -fields size
vserver volume size
------- ------------------------- ----
svm vol_previous_version_test 32GB
::> volume efficiency show -vserver svm -volume vol_previous_version_test
Vserver Name: svm
Volume Name: vol_previous_version_test
Volume Path: /vol/vol_previous_version_test
State: Enabled
Status: Idle
Progress: Idle for 03:54:20
Type: Regular
Schedule: -
Efficiency Policy Name: auto
Blocks Skipped Sharing: 0
Last Operation State: Success
Last Success Operation Begin: Thu Feb 20 05:00:02 2025
Last Success Operation End: Thu Feb 20 05:00:07 2025
Last Operation Begin: Thu Feb 20 05:00:02 2025
Last Operation End: Thu Feb 20 05:00:07 2025
Last Operation Size: 180.8MB
Last Operation Error: -
Changelog Usage: 0%
Logical Data Size: 286.9MB
Logical Data Limit: 1.25PB
Logical Data Percent: 0%
Queued Job: -
Stale Fingerprint Percentage: 0
Compression: false
Inline Compression: false
Storage Efficiency Mode: efficient
Constituent Volume: false
Inline Dedupe: true
Data Compaction: true
Cross Volume Inline Deduplication: false
Cross Volume Background Deduplication: false
Extended Compressed Data: true
::*> cifs options show -vserver svm -fields copy-offload-enabled
vserver copy-offload-enabled
------- --------------------
svm false
また、クライアントがODXがサポートしていることを確認します。
> Get-ItemPropertyValue HKLM:\System\CurrentControlSet\Control\FileSystem -name "FilterSupportedFeaturesMode"
0
0の場合はODXが有効です。
FilterSupportedFeaturesMode 値 意味 0 (既定値) 通常のオプトイン処理を行います。 1 オプトインしない (接続されているすべてのフィルターで SupportedFeatures を 0 に設定することと同じ) 抜粋 : Windows オフロード データ転送 - Windows drivers | Microsoft Learn
では、実際に試してみます。
現在のSMBファイル共有内のファイルは以下のとおりです。
この中いのASCII_256KiB.txtというファイルをコピーアンドペーストします。
この時のRead RequestおよびRead Responseは以下のとおりです。
クリップボードにコピーしたタイミングで256KiBのいくつか箇所は読み取られていることが分かります。
また、ペーストしたタイングで131,072 Byteが2回 = 256KiB読み取られていることからファイル全体が読み込まれている事が分かります。
続いてWrite RequestおよびWrite Responseです。
_Write.png>)
はい、256KiB分のWrite Requestを投げていることが分かります。つまりは、ODXは動作していなさそうです。
ちなみに、ODXが行われている場合、FSCTL_OFFLOAD_READとFSCTL_OFFLOAD_WRITEが発生します。
smb2.ioctl.functionでフィルタリングしましたが、いずれもありませんでした。
PowerShellでコピー (ODX無効)
念の為、PowerShellでも試します。
> cp \\SMB-SERVER.corp.non-97.net\previous-version-test-share\ASCII_256KiB.txt \\SMB-SERVER.corp.non-97.net\previous-version-test-share\ASCII_256KiB_copy.txt
smb2.cmd == 8 || smb2.cmd == 9 || smb2.ioctl.functionでフィルタリングした結果は以下のとおりです。
はい、ファイルサイズ分のWrite Requestが発生していることからODXによる転送はされていないですね。
エクスプローラーでコピーアンドペースト (ODX有効)
ODXを有効にした状態で再度試してみましょう。
ODXを有効にします。
::*> cifs options modify -vserver svm -copy-offload-enabled true
::*> cifs options show -vserver svm -fields copy-offload-enabled
vserver copy-offload-enabled
------- --------------------
svm true
また、SMBサーバーがODXをサポートしているかの情報のやり取りをどこで行なっているのか不明であったため、念の為SMBのセッションは切断しておきました。
::> cifs session close -session-id 12524229088740638735 -connection-id 338489469 -node FsxId0e64a4f5386f74c87-01 -vserver svm
この状態で256KiBのファイルをエクスプローラーでコピーアンドペーストします。
この時のパケットをsmb2.cmd == 8 || smb2.cmd == 9 || smb2.ioctl.functionでフィルタリングした結果は以下のとおりです。
Write Requestがファイルを作成する1回分だけしか行われていないことが分かります。
また、FSCTL_OFFLOAD_READとFSCTL_OFFLOAD_WRITEのリクエスト/レスポンスが発生していることが分かります。
ODXが動作していそうですね。
なお、ペースト時にRead Requestは何回か発生していますが、Read Lengthのサイズを足し合わせても124KiBと、ファイルサイズ256KiBの半分未満です。
FSCTL_OFFLOAD_WRITEのリクエストを見ると、Copy Lengthが262,144 Byte = 256KiBのファイルを書き込むリクエストをしている事が分かります。
せっかくなので、64MiBのファイルでも試してみます。
こちらもWrite Requestがファイルを作成する1回分だけしか行われておらず、FSCTL_OFFLOAD_READとFSCTL_OFFLOAD_WRITEのリクエスト/レスポンスが発生していることからODXが動作している事が分かります。
また、FSCTL_OFFLOAD_WRITEのリクエストを見る限り32MiBの書き込みを2回に分けて行なっているようです。
ペースト時に発生したRead RequestのRead Lengthのサイズ合計は192KiBと、ファイルサイズ64MiBと比較すると非常に小さいです。
これはネットワーク帯域を圧迫が気になる場合は嬉しいですね。
PowerShellでコピー (ODX有効)
PowerShellでも試してみます。
64MiBのファイルを以下のようにコピーします。
> cp \\SMB-SERVER.corp.non-97.net\previous-version-test-share\ASCII_64MiB.txt \\SMB-SERVER.corp.non-97.net\previous-version-test-share\ASCII_64MiB_copy.txt
この時のパケットをsmb2.cmd == 8 || smb2.cmd == 9 || smb2.ioctl.functionでフィルタリングした結果は以下のとおりです。
FSCTL_OFFLOAD_READとFSCTL_OFFLOAD_WRITEのリクエスト/レスポンスが発生していることからODXが動作している事が分かります。
コピーアンドペーストと比較して、Read Requestの回数が少ないですね。
大量のファイルのコピーをする場合はPowerShellなどコマンド経由で行った方が良さそうです。
異なるSMBサーバーのSMBファイル共有間でのODX
異なるSMBサーバーのSMBファイル共有間でもDOXが動作することを確認します。
以下NON-97-AD-TESTというSMBサーバーのSMBファイル共有c$を送信先として指定します。
::> cifs show -vserver non-97-ad-test
Vserver: non-97-ad-test
CIFS Server NetBIOS Name: NON-97-AD-TEST
NetBIOS Domain/Workgroup Name: CORP
Fully Qualified Domain Name: CORP.NON-97.NET
Organizational Unit: OU=FSxForONTAP,DC=corp,DC=non-97,DC=net
Default Site Used by LIFs Without Site Membership:
Workgroup Name: -
Authentication Style: domain
CIFS Server Administrative Status: up
CIFS Server Description:
List of NetBIOS Aliases: -
::> cifs share show -vserver non-97-ad-test
Vserver Share Path Properties Comment ACL
-------------- ------------- ----------------- ---------- -------- -----------
non-97-ad-test c$ / oplocks - BUILTIN\Administrators / Full Control
browsable
changenotify
show-previous-versions
non-97-ad-test ipc$ / browsable - -
2 entries were displayed.
::> volume efficiency show -vserver non-97-ad-test
There are no entries matching your query.
::> volume show -vserver non-97-ad-test -fields is-sis-volume, junction-path
vserver volume junction-path is-sis-volume
-------------- ------------------- ------------- -------------
non-97-ad-test non_97_ad_test_root / false
ためしにNON-97-AD-TESTのc$にエクスプローラーでアクセスすると、以下のようにSMBのセッションが張られました。
::> cifs session show
Node: FsxId0e64a4f5386f74c87-01
Vserver: non-97-ad-test
Connection Session Open Idle Connection
ID ID Workstation Windows User Files Time Count
---------- ------- ---------------- ---------------- --------- ------------ ---------------
338489478 12524229088740638737 26s 4
10.0.0.34 CORP\ 3
Administrator
Node: FsxId0e64a4f5386f74c87-01
Vserver: svm
Connection Session Open Idle Connection
ID ID Workstation Windows User Files Time Count
---------- ------- ---------------- ---------------- --------- ------------ ---------------
338489474 12524229088740638736 42s 4
10.0.0.34 CORP\ 3
Administrator
2 entries were displayed.
この状態で以下のように64MiBのファイルをコピーします。
> cp \\SMB-SERVER.corp.non-97.net\previous-version-test-share\ASCII_64MiB.txt \\NON-97-AD-TEST.corp.non-97.net\C$\ASCII_64MiB_copy.txt
この時のパケットをsmb2.cmd == 8 || smb2.cmd == 9 || smb2.ioctl.functionでフィルタリングした結果は以下のとおりです。
FSCTL_OFFLOAD_READとFSCTL_OFFLOAD_WRITEのリクエスト/レスポンスが発生していることからODXが動作している事が分かります。
ということで異なるSMBサーバー間でもDOXが動作することが分かりました。
SMBサーバーが異なるということはボリュームも異なるということです。FSxNのファイルシステム内であれば、他要件をを満たす場合は高速にファイルのコピーが出来そうです。
Amazon FSx for NetApp ONTAP内で大量のファイルのコピーが発生する場合でもクライアントとのネットワークトラフィックは抑えられる
Amazon FSx for NetApp ONTAPにて、SMBのサーバーサイドコピー(正しくはODX)はできるのか確認してみました。
FSxNファイルシステム内で大量のファイルのコピーが発生する場合でもクライアントとのネットワークトラフィックは抑えられそうですね。
なお、そもそも大量のデータのコピーをするのであれば、FlexCloneがおすすめです。FlexCloneを使うことによって高速にボリュームのクローンを作成することが可能です。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
