この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ネットワーク越しにアクセスするとレイテンシーが気になるからオンプレにキャッシュを置きたいな
こんにちは、のんピ(@non____97)です。
皆さんは「Amazon FSx for NetApp ONTAP(FSx for ONTAP)を構築したものの、ネットワーク越しにアクセスするとレイテンシーが気になるからオンプレにキャッシュを置きたいな」と思ったことはありますか? 私はあります。
例えDirect Connectを引いていたとしても物理的に距離が離れている分、どうしてもレイテンシーは発生してしまいます。
となるとよくアクセスするデータはキャッシュを手元に置いておきたいですよね。
そんな時はFlexCacheの出番です。
以降FlexCacheを紹介します。
いきなりまとめ
- FlexCacheはボリュームのデータをキャッシュする機能
- キャッシュはファイル単位ではなく、データブロック単位
- FlexCacheのメリットは以下
- 常にネットワーク越しにアクセスするよりもレイテンシーの影響が小さくなる
- 書き込みとキャッシュにないデータの読み込みのみオリジンにアクセスするため、Site-to-Site VPNやDirect Connect、Transit Gatewayのデータ転送量が減る
- キャッシュボリューム経由でアクセスすることでTransit Gatewayがなくてもアクセスできる
- FlexCacheはONTAP 9.5以上で使用可能
- FlexCacheのキャッシュボリュームはFlexGroup
- キャッシュボリュームのサイズはオリジンボリュームの10-15%が目安
- キャッシュボリュームのサイジング時にはオーバーヘッド分も加味すること
- クライアントから認識できるキャッシュボリュームのサイズはオリジンボリュームのサイズ
- キャッシュボリュームのメンバーボリューム(FlexGroup constituents)のサイズは最大ファイルのサイズ以上である必要がある
- デフォルトのメンバーボリューム数である4でキャッシュボリュームを作成した場合、キャッシュボリュームのサイズは少なくとも最大ファイルのサイズの4倍である必要がある
- キャッシュしている状態でオリジンボリューム上のファイルを変更した場合、キャッシュボリューム上のファイルにアクセスしたタイミングでオリジンボリュームから再度キャッシュされる
- キャッシュボリュームにオリジンボリュームのデータを事前に取り込むことも可能
- ファイルサイズに応じて適切なメンバーボリューム数に調整することが重要
- データブロックはファイル単位でキャッシュボリュームのメンバーボリュームにキャッシュされる
- ファイルのデータブロックは複数のメンバーボリュームに跨ってキャッシュはされない
- サイズが大きいファイルの割合が高い場合は、キャッシュボリュームのサイズに対してメンバーボリューム数が多すぎると上手くキャッシュされない
- メンバーボリューム数の目安はFlexCache in ONTAP 9.11.1 | TR-4743の
FlexGroup constituentsを参照
FlexCacheとは
FlexCacheとはボリュームのデータをキャッシュする機能です。
キャッシュ用のボリュームをオンプレやAWS上に作成しキャッシュを保持することで、常にネットワーク越しにアクセスするよりもレイテンシーの影響が小さくなります。
抜粋 : Amazon FSx for NetApp ONTAP を使ったデータキャッシング | Amazon Web Services ブログ
キャッシュはファイル単位でキャッシュするのではなくデータブロック単位でキャッシュします。
A FlexCache volume is a sparse container; not all files from the origin dataset are cached, and, even then, not all data blocks of a cached inode can be present in the cache. Storage is used efficiently by prioritizing retention of the working dataset (recently used data).
(機械翻訳)
FlexCacheボリュームはスパースコンテナであり、オリジンデータセットからすべてのファイルがキャッシュされるわけではなく、キャッシュされたinodeのすべてのデータブロックがキャッシュ内に存在するわけでもない。ストレージは以下の方法で効率的に使用されます。作業データセット（最近使用されたデータ）の保持を優先させることで、ストレージを効率的に使用します。
そのため、大きいファイルであってもファイル全体がキャッシュされるのを待つ必要がありません。
また、キャッシュを保持するということで、書き込みとキャッシュにないデータの読み込みのみオリジンにアクセスすることとなり、Site-to-Site VPNやDirect Connect、Transit Gatewayのデータ転送量が減るのも嬉しいですね。
FSx for ONTAPのボリュームをFlexCacheのオリジンボリュームで、オンプレにFlexCacheのキャッシュボリュームを配置したい場合に、オンプレにONTAPをどのように調達するかが問題になると思います。ONTAPをすでに使用されている場合はONTAPをそのまま活用し、ONTAPがない場合はONTAP SelectというONTAPの仮想アプライアンスを使うことになると考えます。
FlexGroupはONTAP 9.5以上で使用できます。また、キャッシュボリュームはFlexGroupになるようです。
ONTAP 9.5 では、元のボリュームは FlexVol ボリューム、 FlexCache ボリュームは FlexGroup ボリュームです。元のボリュームでは、 NFSv3 、 NFSv4 、 SMB の各プロトコルがサポートされます。ONTAP 9.5 では、 FlexCache ボリュームで NFSv3 プロトコルのみがサポートされます。ONTAP 9.8 以降では、 FlexCache ボリュームでも SMB プロトコルがサポートされます。ONTAP 9.10.1 以降の FlexCache ボリュームで NFSv4 プロトコルがサポートされるようになりました。FlexCache ボリュームでサポートされる機能の一覧については、を参照してください FlexCache ボリュームでサポートされる機能とサポートされない機能。
FlexCacheはクラスター間LIFのtcp/11104とtcp/11105を使用します。
- The FlexCache feature uses the intercluster LIFs to connect the cache to the origin
- The Remote Access Layer (RAL) uses TCP ports 11104 and 11105.
- The former port is used for intercluster communication sessions and the latter port is used to transfer data.
What TCP ports does FlexCache use between the cache and the origin in CMode? - NetApp Knowledge Base
クラスター間LIFのIPアドレスはフローティングIPではありません。ということはTransit Gatewayは不要です。
| データアクセス | Transit Gateway は必要ですか。 |
|---|---|
| NFS、SMB、NetApp ONTAP REST API/CLI 経由で FSx にアクセスする | 次の場合のみ必要です。 - ピアリング接続されたネットワーク (オンプレミスなど) からアクセスし、 - NetApp FlexCache またはグローバルファイルキャッシュインスタンスから FSx にアクセスしない |
| iSCSI 経由でデータにアクセスする | いいえ |
| SVM をアクティブディレクトリに結合する | いいえ |
| SnapMirror | いいえ |
| FlexCache キャッシュ | いいえ |
| グローバルファイルキャッシュ | いいえ |
抜粋 : AWS 内からデータにアクセスする - FSx for ONTAP
FSx for ONTAPファイルシステムをMulti-AZでデプロイしている場合、管理エンドポイントやSMBエンドポイント、NFSエンドポイントなどフローティングIPにオンプレや別VPCからアクセスする際はTransit Gatewayが必要になります。
Direct ConnectでTransit Gatewayに接続したい場合はTransit VIFを用意する必要があり、調達が難しいことがあります。
オンプレからFSx for ONTAP上のデータにアクセスする場合はFlexCacheのキャッシュボリュームにアクセスするように運用することで、Multi-AZの場合もTransit Gatewayが不要になります。
FlexCacheのベストプラクティスはNetAppの以下ドキュメントをご覧ください。
- キャッシュとオリジンの SVM は同じドメインにある必要がある
- ONTAP 9.10.1 以前の場合はオリジンの atime-updates を False に設定する
- ONTAP 9.11 以降の場合はオリジンの atime-updates を True に設定し、 atime-update-period を設定する
- read-after-write を使⽤しない
- ワークグループモードの UNIX セキュリティスタイル
- オリジン SVM がワークグループモードを使用している場合、FlexCache ボリュームを作成できるのは、セキュリティスタイルが UNIX に設定されているボリュームのみ
- FlexCache ボリュームには、サイズに基づいたメンバーボリューム数が必要
- キャッシュボリュームはFlexGroupであるため
- CIFS サーバー、LDAP クライアントおよびユーザー名のマッピングはオリジンと同じ⽅法で構成する
- CIFS サーバーを構成しウイルス対策保護のためにオンデマンド スキャンを使⽤する
- キャッシュサイズを具体的に定義する
- キャッシュサイズは最⼤サイズのファイルより⼤きくする必要がある
FlexCacheの導入フロー
FlexCacheの導入フローは以下の通りです。
FSx for ONTAPとオンプレ間でFlexCacheを設定したい場合は、以下ステップが必要ということですね。
- クラスターピアリングの作成
- SVMピアリングの作成
- FlexCacheボリュームの作成
FlexCacheでサポートされる機能
FlexCacheを使用するにあたって、いくつかサポートされていない機能があります。使用したい機能に制限がないか確認しておきましょう。
| 機能 | オリジンボリュームでのサポート | FlexCache ボリュームでのサポート |
|---|---|---|
| ランサムウェア対策による保護 | はい
ONTAP 9.10.1 以降の FlexVol の元のボリュームでは、 FlexGroup の元のボリュームはサポートされません。 |
いいえ |
| ウィルス対策 | はい
ONTAP 9.7 以降でサポートされます |
該当なし |
| 監査 | はい
ONTAP 9.7以降では、ONTAP の標準の監査を使用して、FlexCache 関係のNFSファイルアクセスイベントを監査できます。詳細については、を参照してください FlexCache ボリュームの監査に関する考慮事項 |
はい
ONTAP 9.7以降では、ONTAP の標準の監査を使用して、FlexCache 関係のNFSファイルアクセスイベントを監査できます。詳細については、を参照してください FlexCache ボリュームの監査に関する考慮事項 |
| Cloud Volumes ONTAP | はい
ONTAP 9.6 以降でサポートされます |
はい
ONTAP 9.6 以降でサポートされます |
| コンパクション | はい
ONTAP 9.6 以降でサポートされます |
はい
ONTAP 9.7 以降でサポートされます |
| 圧縮 | はい
ONTAP 9.6 以降でサポートされます |
はい
ONTAP 9.6 以降でサポートされます |
| 重複排除 | はい | はい
FlexCache 9.6 以降では、 ONTAP ボリュームでインライン重複排除がサポートされます。ONTAP 9.7 以降では、 FlexCache ボリュームでボリューム間重複排除がサポートされます。 |
| FabricPool | はい | はい
ONTAP 9.7 以降でサポートされます |
| FlexCache DR | はい | はい
ONTAP 9.9.2.1 以降で、 NFSv3 プロトコルのみがサポートされます。FlexCache ボリュームは、別々の SVM またはクラスタに配置する必要があります。 |
| FlexGroup ボリューム | はい
ONTAP 9.7 以降でサポートされます |
はい |
| FlexVol ボリューム | はい | いいえ |
| FPolicy | はい
ONTAP 9.7 以降でサポートされます |
はい
ONTAP 9.7 以降では、 NFS でサポートされます |
| MetroCluster の設定 | はい
ONTAP 9.7 以降でサポートされます |
はい
ONTAP 9.7 以降でサポートされます |
| Microsoft オフロードデータ転送( ODX ) | いいえ | いいえ |
| NetApp Aggregate Encryption ( NAE ) | はい
ONTAP 9.6 以降でサポートされます |
はい
ONTAP 9.6 以降でサポートされます |
| NetApp Volume Encryption ( NVE ) | はい
ONTAP 9.6 以降でサポートされます |
はい
ONTAP 9.6 以降でサポートされます |
| NFSv3 | はい | はい |
| NFSv4 | はい | はい
ONTAP 9.10.1 以降でサポートされます |
| QoS | はい | はい 注：ファイルレベルのQoSは、FlexCache ボリュームではサポートされません。 |
| qtree | はい
ONTAP 9.6 以降でサポートされます |
いいえ |
| クォータ | はい | いいえ
ONTAP 9.6 以降では、 FlexCache ボリュームでリモートクォータ( rquota )がサポートされます。 |
| SMB | はい | はい
ONTAP 9.8 以降でサポートされます。 |
| SnapLock ボリューム | いいえ | いいえ |
| SnapMirror 非同期関係 | はい | いいえ
SnapMirror関係の元のプライマリボリュームからFlexCache ボリュームを作成できます。 ONTAP 9.8 以降では、 SnapMirror セカンダリボリュームを FlexCache の元のボリュームにすることができます。 |
| SnapMirror Synchronous 関係 | いいえ | いいえ |
| SnapRestore | はい | いいえ |
| Snapshot コピー | はい | いいえ |
| SVM の IP 設定 | はい
ONTAP 9.5 以降でサポート。SVM DR 関係のプライマリ SVM に元のボリュームを含めることができます。ただし、 SVM DR 関係が解除された場合は、新しい元のボリュームを使用して FlexCache 関係を再作成する必要があります。 |
いいえ
プライマリ SVM には FlexCache を作成できますが、セカンダリ SVM には作成できません。プライマリ SVM 内の FlexCache ボリュームは、 SVM DR 関係の一部としてレプリケートされません。 |
| ストレージレベルのアクセス保護( SLAG ) | いいえ | いいえ |
| シンプロビジョニング | はい | はい
ONTAP 9.7 以降でサポートされます |
| ボリュームクローニング | はい
ONTAP 9.6 以降では、元のボリュームおよび元のボリューム内のファイルのクローニングがサポートされます。 |
いいえ |
| ボリューム移動 | はい | はい (ボリュームコンスティチュエントのみ)
ONTAP 9.6 以降では、 FlexCache ボリュームのボリュームコンスティチュエントの移動がサポートされます。 |
| ボリュームをリホスト | いいえ | いいえ |
抜粋 : FlexCache ボリュームでサポートされる機能とサポートされない機能
やってみた
検証のシナリオ
実際にFlexGroupの検証をしてみます。
FlexGroupのオリジンとキャッシュボリュームは別々のSVM上に作成します。プロトコルはNFSです。
FlexGroupの設定はNetAppの以下ドキュメントを参考に行います。
SVMピアリング
FlexCacheのオリジンボリュームとキャッシュボリュームのSVMが異なるので、SVMピアリングを行います。
ピアリングする際はFlexCacheで使用することが分かるように、-applications flexcacheを指定します。
# クラスター名の確認
::> cluster identity show
Cluster UUID: cc9673f1-8cca-11ed-946a-5191ab1a5297
Cluster Name: FsxId05f72eb8f8d03c709
Cluster Serial Number: 1-80-000011
Cluster Location:
Cluster Contact:
# SVMの確認
::> vserver show -vserver svm_*
Admin Operational Root
Vserver Type Subtype State State Volume Aggregate
----------- ------- ---------- ---------- ----------- ---------- ----------
svm_cache data default running running svm_cache_ aggr1
root
svm_origin data default running running svm_ aggr1
origin_
root
2 entries were displayed.
# SVMピアリングの作成
::> vserver peer create -vserver svm_origin -peer-vserver svm_cache -applications flexcache
Info: 'vserver peer create' command is successful.
# SVMピアリングの確認
::> vserver peer show
Peer Peer Peering Remote
Vserver Vserver State Peer Cluster Applications Vserver
----------- ----------- ------------ ----------------- -------------- ---------
svm_cache svm_origin peered FsxId05f72eb8f8d03c709
flexcache svm_origin
svm_origin svm_cache peered FsxId05f72eb8f8d03c709
flexcache svm_cache
2 entries were displayed.
::> vserver peer show -instance
Local Vserver Name: svm_cache
Peer Vserver Name: svm_origin
Peering State: peered
Peering Applications: flexcache
Peer Cluster Name: FsxId05f72eb8f8d03c709
Remote Vserver Name: svm_origin
Local Vserver Name: svm_origin
Peer Vserver Name: svm_cache
Peering State: peered
Peering Applications: flexcache
Peer Cluster Name: FsxId05f72eb8f8d03c709
Remote Vserver Name: svm_cache
2 entries were displayed.FlexCacheの設定
SVMピアリングが完了したらFlexCacheの設定を行います。
# FlexCacheのキャッシュボリューム確認
::> flexcache show
(volume flexcache show)
This table is currently empty.
# FlexCacheの作成
::> flexcache create -origin-vserver svm_origin -origin-volume vol1 -vserver svm_cache -volume vol1_cache -aggr-list aggr1 -size 256MB -junction-path /vol1_cache
(volume flexcache create)
Warning: The recommended size of the FlexCache volume is 4GB. If the FlexCache volume is less than this size, it might run out of space to cache data.
Do you want to continue? {y|n}: y
[Job 696] Job succeeded: Successful.
# FlexCacheのキャッシュボリューム確認
::> flexcache show (volume flexcache show)
Vserver Volume Size Origin-Vserver Origin-Volume Origin-Cluster
------- ----------- ---------- -------------- ------------- --------------
svm_cache
vol1_cache 256MB svm_origin vol1
FsxId05f72eb8f8d03c709
::> flexcache show -instance
(volume flexcache show)
Vserver Name: svm_cache
Cache Volume Name: vol1_cache
List of Aggregates for FlexGroup Constituents: aggr1
Volume Size: 256MB
Origin Vserver Name: svm_origin
Origin Volume Name: vol1
Origin Cluster Name: FsxId05f72eb8f8d03c709
Cache Junction Path: /vol1_cache
FlexCache Create Time: Tue Feb 14 18:04:57 2023
Space Guarantee Style: none
Global File Locking Mode Enabled/Disabled: false
# FlexCacheのオリジンボリューム確認
::> flexcache origin show-caches
(volume flexcache origin show-caches)
Origin-Vserver Origin-Volume Cache-Vserver Cache-Volume Cache-Cluster
-------------- -------------- -------------- ------------- --------------
svm_origin vol1 svm_cache vol1_cache FsxId05f72eb8f8d03c709
::> flexcache origin show-caches -instance
(volume flexcache origin show-caches)
Vserver Name: svm_origin
Origin Volume: vol1
Cache Vserver: svm_cache
Cache Volume: vol1_cache
Cache Cluster: FsxId05f72eb8f8d03c709
Cache Volume MSID: 2156877924
Relationship Create Time: Tue Feb 14 18:05:08 2023FlexCacheの設定ができました。FlexCacheを作成する際に、4GBが推奨と表示されていますね。キャッシュボリュームのサイズはオリジンボリュームの10-15%が目安となっています。
Cache volume size
What is the optimal cache volume size? It depends on your data. The working set is the amount of data used at the FlexCache volume for a particular run or job. The working set determines how the FlexCache volume should be sized. For example, if the origin volume has 1TB of data in it, but a particular job only needs 75GB of data, then the optimal size for the FlexCache volume is the working set size (75GB) plus overhead (approximately 25%). In this case, 75GB + 25% * 75 = 93.75GB or 94GB. This is the most aggressive sizing to make sure that all data that is being read is cached at the FlexCache. There are some exceptions to this rule that are outlined in this section.
The other method to determine optimal cache volume size is to take 10-15% of the origin volume size and apply it to the cache. For a 50TB origin volume size, a cache should be 5TB to 7.5TB in size. You can use this method in cases where the working set is not clearly understood and then use statistics, used sizes, and other indicators to determine the overall optimal cache size.
(以下機械翻訳)
キャッシュボリュームサイズ
最適なキャッシュボリュームサイズは？それはデータによって異なります。ワーキング・セットとは、特定の実行やジョブでFlexCacheボリュームで使用されるデータ量のことです。ワーキングセットは、FlexCacheボリュームのサイズを決定します。たとえば、オリジンボリュームに1TBのデータがあり、特定のジョブには75GBのデータしか必要ない場合、FlexCacheボリュームの最適なサイズは、ワーキングセットサイズ（75GB）にオーバーヘッド（約25%）を加えたサイズになります。この場合、75GB + 25% * 75 = 93.75GBまたは94GBとなります。これは、読み込まれるすべてのデータがFlexCacheでキャッシュされるようにするための、最も積極的なサイジングです。このルールにはいくつかの例外があり、このセクションで説明します。
最適なキャッシュボリュームサイズを決定するもう1つの方法は、オリジンボリュームサイズの10-15%をキャッシュに適用する方法です。50TBのオリジン・ボリューム・サイズでは、キャッシュは5TBから7.5TBのサイズであるべきです。この方法は、ワーキング・セットが明確に把握されていない場合に使用し、統計、使用済みサイズ、その他の指標を使用して全体的な最適キャッシュ・サイズを決定することができる。
オリジンボリュームのサイズは1GiBなので、オリジンボリュームのサイズ以上のサイズを要求されています。もしかしたらFlexCacheのオーバーヘッド分かもしれませんね。今回はこのまま256MBで検証してみます。
キャッシュボリュームの詳細を確認します。
::> volume show -volume vol1_cache
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
svm_cache vol1_cache - online RW 256MB 126.9MB 50%
::> volume show -volume vol1_cache -fields flexgroup-name, is-flexgroup
vserver volume flexgroup-name is-flexgroup
--------- ---------- -------------- ------------
svm_cache vol1_cache vol1_cache true
::> volume show -volume vol1_cache -instance
Vserver Name: svm_cache
Volume Name: vol1_cache
Aggregate Name: -
List of Aggregates for FlexGroup Constituents: aggr1
Encryption Type: none
List of Nodes Hosting the Volume: FsxId05f72eb8f8d03c709-01
Volume Size: 256MB
Volume Data Set ID: -
Volume Master Data Set ID: 2156877924
Volume State: online
Volume Style: flex
Extended Volume Style: flexgroup
FlexCache Endpoint Type: cache
Is Cluster-Mode Volume: true
Is Constituent Volume: false
Number of Constituent Volumes: 4
Export Policy: default
User ID: 0
Group ID: 0
Security Style: unix
UNIX Permissions: ---rwxr-xr-x
Junction Path: /vol1_cache
Junction Path Source: RW_volume
Junction Active: true
Junction Parent Volume: svm_cache_root
Comment:
Available Size: 126.9MB
Filesystem Size: 256MB
Total User-Visible Size: 256MB
Used Size: 129.1MB
Used Percentage: 50%
Volume Nearly Full Threshold Percent: 90%
Volume Full Threshold Percent: 98%
Maximum Autosize: 307.2MB
Minimum Autosize: 256MB
Autosize Grow Threshold Percentage: 85%
Autosize Shrink Threshold Percentage: 50%
Autosize Mode: off
Total Files (for user-visible data): 24316
Files Used (for user-visible data): 384
Space Guarantee in Effect: true
Space SLO in Effect: true
Space SLO: none
Space Guarantee Style: none
Fractional Reserve: 0%
Volume Type: RW
Snapshot Directory Access Enabled: false
Space Reserved for Snapshot Copies: 0%
Snapshot Reserve Used: 0%
Snapshot Policy: none
Creation Time: Tue Feb 14 18:04:57 2023
Language: C.UTF-8
Clone Volume: false
Node name: -
Clone Parent Vserver Name: -
FlexClone Parent Volume: -
NVFAIL Option: off
Volume's NVFAIL State: false
Force NVFAIL on MetroCluster Switchover: off
Is File System Size Fixed: false
(DEPRECATED)-Extent Option: off
Reserved Space for Overwrites: 64MB
Primary Space Management Strategy: volume_grow
Read Reallocation Option: off
Naming Scheme for Automatic Snapshot Copies: create_time
Inconsistency in the File System: false
Is Volume Quiesced (On-Disk): false
Is Volume Quiesced (In-Memory): false
Volume Contains Shared or Compressed Data: true
Space Saved by Storage Efficiency: 0B
Percentage Saved by Storage Efficiency: 0%
Space Saved by Deduplication: 0B
Percentage Saved by Deduplication: 0%
Space Shared by Deduplication: 0B
Space Saved by Compression: 0B
Percentage Space Saved by Compression: 0%
Volume Size Used by Snapshot Copies: 0B
Block Type: 64-bit
Is Volume Moving: false
Flash Pool Caching Eligibility: read-write
Flash Pool Write Caching Ineligibility Reason: -
Constituent Volume Role: -
QoS Policy Group Name: -
QoS Adaptive Policy Group Name: -
Caching Policy Name: -
Is Volume Move in Cutover Phase: false
Number of Snapshot Copies in the Volume: 0
VBN_BAD may be present in the active filesystem: false
Is Volume on a hybrid aggregate: false
Total Physical Used Size: 129.1MB
Physical Used Percentage: 50%
FlexGroup Name: vol1_cache
Is Volume a FlexGroup: true
SnapLock Type: non-snaplock
Vserver DR Protection: -
Enable or Disable Encryption: false
Is Volume Encrypted: false
Encryption State: none
Encryption Key ID:
Encryption Key Creation Time: -
Application: -
Is Fenced for Protocol Access: false
Protocol Access Fence Owner: -
Is SIDL enabled: off
Over Provisioned Size: 0B
Available Snapshot Reserve Size: 0B
Logical Used Size: 129.1MB
Logical Used Percentage: 50%
Logical Available Size: -
Logical Size Used by Active Filesystem: 129.1MB
Logical Size Used by All Snapshots: 0B
Logical Space Reporting: false
Logical Space Enforcement: false
Volume Tiering Policy: none
Performance Tier Inactive User Data: -
Performance Tier Inactive User Data Percent: -
Tags to be Associated with Objects Stored on a FabricPool: -
Does the Object Tagging Scanner Need to Run on This Volume: false
Is File System Analytics Supported: false
Reason File System Analytics is not Supported: File system analytics is not supported on FlexCache volumes.
File System Analytics State: off
File System Analytics Scan Progress: -
Activity Tracking State: off
Is Activity Tracking Supported: false
Reason Activity Tracking Is Not Supported: Volume activity tracking is not supported on FlexCache volumes.
Is SMBC Master: false
Is SMBC Failover Capable: false
SMBC Consensus: -
Anti-ransomware State: disabledキャッシュボリュームはFlexGroupであることが分かりますね。また、オーバーヘッド分なのかすでに129.1MB使用しています。
キャッシュボリュームへのアクセス
キャッシュボリュームにアクセスしてみます。
オリジンボリューム、キャッシュボリュームどちらもNFSでマウントします。
# マウントポイントの作成
$ sudo mkdir /mnt/fsxn/origin
$ sudo mkdir /mnt/fsxn/cache
# マウント
$ sudo mount -t nfs svm-095f0dadac6839b07.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol1 /mnt/fsxn/origin
$ sudo mount -t nfs svm-009cbf3dd37b7be59.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol1_cache /mnt/fsxn/cache
# マウントされたことを確認
$ df -hT -t nfs4
Filesystem Type Size Used Avail Use% Mounted on
svm-095f0dadac6839b07.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol1 nfs4 973M 58M 916M 6% /mnt/fsxn/origin
svm-009cbf3dd37b7be59.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol1_cache nfs4 973M 58M 916M 6% /mnt/fsxn/cacheキャッシュボリュームは256MBでサイジングしましたが、オリジンボリュームのサイズである1GBで見えています。
キャッシュされているかの確認
オリジンボリュームにファイルを追加して、そのファイルがキャッシュボリュームから参照できるか確認します。
まず、オリジンボリュームに128MiBのファイルを追加します、
# オリジンボリュームに128MiBのファイルを追加
$ sudo dd if=/dev/urandom of=/mnt/fsxn/origin/test-file-1 bs=128M count=1
1+0 records in
1+0 records out
134217728 bytes (134 MB) copied, 0.905366 s, 148 MB/s
# ファイルサイズ分増加していることを確認
$ df -hT -t nfs4
Filesystem Type Size Used Avail Use% Mounted on
svm-095f0dadac6839b07.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol1 nfs4 973M 186M 787M 20% /mnt/fsxn/origin
svm-009cbf3dd37b7be59.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol1_cache nfs4 973M 186M 787M 20% /mnt/fsxn/cache
# オリジンボリューム上のファイルを確認
$ ls -l /mnt/fsxn/origin
total 131592
-rw-r--r-- 1 root root 134217728 Feb 14 09:17 test-file-1
# キャッシュボリューム上のファイルを確認
$ ls -l /mnt/fsxn/cache
total 131592
-rw-r--r-- 1 root root 134217728 Feb 14 09:17 test-file-1オリジンボリュームから書き込まれたファイルをキャッシュボリュームで表示することができました。
ONTAP CLIからキャッシュボリュームの使用量を確認します。
::> volume show -volume vol1_cache
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
svm_cache vol1_cache - online RW 256MB 126.9MB 50%50%で変わりありませんね。
キャッシュはデータブロック単位で行われます。
ということでキャッシュボリュームから作成したファイルの全てのデータブロックを読み込んでみます。
$ dd if=/mnt/fsxn/cache/test-file-1 of=/dev/null bs=64M
2+0 records in
2+0 records out
134217728 bytes (134 MB) copied, 34.2035 s, 3.9 MB/s3.9 MB/sと物凄く遅いですね。
比較用にオリジンボリュームでも読み込んでみます。
$ dd if=/mnt/fsxn/origin/test-file-1 of=/dev/null bs=64M iflag=direct
2+0 records in
2+0 records out
134217728 bytes (134 MB) copied, 0.333658 s, 402 MB/sこちらは402 MB/sとかなり速いですね。
繰り返しキャッシュボリュームから読み込んでみます。
$ dd if=/mnt/fsxn/cache/test-file-1 of=/dev/null bs=64M iflag=direct
dd: error reading ‘/mnt/fsxn/cache/test-file-1’: Remote I/O error
0+1 records in
0+1 records out
5767168 bytes (5.8 MB) copied, 0.194798 s, 29.6 MB/s
$ dd if=/mnt/fsxn/cache/test-file-1 of=/dev/null bs=64M iflag=direct
dd: error reading ‘/mnt/fsxn/cache/test-file-1’: Remote I/O error
0+1 records in
0+1 records out
63700992 bytes (64 MB) copied, 10.1942 s, 6.2 MB/s
$ dd if=/mnt/fsxn/cache/test-file-1 of=/dev/null bs=64M iflag=direct
dd: error reading ‘/mnt/fsxn/cache/test-file-1’: Remote I/O error
0+1 records in
0+1 records out
31719424 bytes (32 MB) copied, 0.164634 s, 193 MB/s相変わらず遅いですね。また、全てのデータブロックを読み込んでいないようです。
試しに、オリジンボリュームに再度128MiBのファイルを作成して読み込んでみます。
# オリジンボリュームにテストファイルを追加
$ sudo dd if=/dev/urandom of=/mnt/fsxn/cache/test-file-2 bs=128M count=1
1+0 records in
1+0 records out
134217728 bytes (134 MB) copied, 0.861589 s, 156 MB/s
# ファイルサイズ分増加していることを確認
$ df -hT -t nfs4
Filesystem Type Size Used Avail Use% Mounted on
svm-095f0dadac6839b07.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol1 nfs4 973M 315M 659M 33% /mnt/fsxn/origin
svm-009cbf3dd37b7be59.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol1_cache nfs4 973M 315M 659M 33% /mnt/fsxn/cache
キャッシュボリュームから作成したファイルの全てのデータブロックを読み込み
$ dd if=/mnt/fsxn/cache/test-file-2 of=/dev/null bs=64M
2+0 records in
2+0 records out
134217728 bytes (134 MB) copied, 34.48 s, 3.9 MB/s
$ dd if=/mnt/fsxn/cache/test-file-2 of=/dev/null bs=64M iflag=direct
2+0 records in
2+0 records out
134217728 bytes (134 MB) copied, 34.1528 s, 3.9 MB/sファイルを変更しても、速度は相変わらず遅いです。
ここでNetAppの公式ドキュメントを確認してみます。
If there is a file in the dataset that must be cached that is larger than any of the constituents, then the file is always served from the origin. It is never cached because there is not enough room in the constituent volume for that file.
(以下機械翻訳)
データセットの中に、どの構成要素よりも大きい、キャッシュしなければならないファイルがある場合 キャッシュする必要があり、そのファイルがどの構成要素よりも大きい場合、そのファイルは常にオリジンから提供されます。それは決して 構成ボリュームにそのファイルを格納する十分なスペースがないため、キャッシュされることはありません。
FlexGroupの各メンバーボリュームのサイズ以上のファイルはキャッシュできないと記載されていますね。
FlexCache作成時のメンバーボリュームのデフォルトの数は4です。
[-aggr-list-multiplier ] - Aggregate List Repeat Count
Specifies the number of times to iterate over the aggregates listed with the -aggr-list parameter when creating a FlexGroup. The aggregate list will be repeated the specified number of times.
Example:
-aggr-list aggr1,aggr2 -aggr-list-multiplier 2will cause four constituents to be created in the order aggr1 , aggr2 , aggr1 , aggr2 . + The default value is 4.
volume flexcache create
キャッシュボリュームのサイズを256MBで指定したため、キャッシュボリュームの各メンバーボリュームのサイズは256MB / 4 = 64MBとなります。
これはオリジンボリュームに書き込んだファイルサイズよりも小さいため、キャッシュができなかったということですね。
キャッシュボリュームのサイズに応じて-aggr-list-multiplierを変更することがベストプラクティスなので、キャッシュボリュームを作成する場合は注意しましょう。
FlexGroup constituents
A FlexCache volume is a FlexGroup volume. This means that the total space of the FlexCache volume is made up of smaller constituent volumes. For more information about FlexGroup volumes, see TR-4557:
(中略)
NetApp recommends using the -aggr-list option to specify the aggregates to create the constituent volumes in. The option aggr-list-multiplier determines how many constituent volumes are being used per aggregate listed in the -aggr-list option. The recommendation on the total number of constituents is proportional to the size of the FlexCache volume:
- FlexCache volume < 100GB = 1-member volume
- FlexCache volume > 100GB < 1TB = 2 member volumes
- FlexCache volume > 1TB < 10TB = 4 member volumes
- FlexCache volume > 10TB < 20TB = 8 member volumes
- FlexCache volume > 20TB = the default number of member volumes (use -auto-provision-as flexgroup)
Best practice 5: FlexCache volumes should have constituent numbers based on size
Create the FlexCache with only the -aggr-list option so it creates the prescribed number of constituents.
fc_cluster::> flexcache create -vserver fc-svm1 -volume vol_fc_cache -origin-vserver originsvm -origin-volume vol_fc_origin -aggr-list aggr1_node1 -size 5TB -aggr-list-multiplier 4 -junction_path /vol_fc_cache1
今回はキャッシュボリュームのサイズを変更して対応します。試しに16GB(メンバーボリュームのサイズを4GB)に設定してみて再チャレンジします。
# キャッシュボリュームのサイズを16GBに変更
::> volume modify -vserver svm_cache -volume vol1_cache -size 16GB
[Job 704] Job succeeded: volume modify succeeded
# キャッシュボリュームのサイズが拡張されたことを確認
::> volume show -volume vol1_cache
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
svm_cache vol1_cache - online RW 16GB 15.86GB 0%キャッシュボリューム上のファイルを読み込んでみて、読み込み速度が改善していることを確認します。
$ dd if=/mnt/fsxn/cache/test-file-1 of=/dev/null bs=64M iflag=direct
2+0 records in
2+0 records out
134217728 bytes (134 MB) copied, 0.425265 s, 316 MB/s
$ dd if=/mnt/fsxn/cache/test-file-1 of=/dev/null bs=64M iflag=direct
2+0 records in
2+0 records out
134217728 bytes (134 MB) copied, 0.342662 s, 392 MB/s
$ dd if=/mnt/fsxn/cache/test-file-1 of=/dev/null bs=64M iflag=direct
2+0 records in
2+0 records out
134217728 bytes (134 MB) copied, 0.344473 s, 390 MB/s
$ dd if=/mnt/fsxn/cache/test-file-2 of=/dev/null bs=64M iflag=direct
2+0 records in
2+0 records out
134217728 bytes (134 MB) copied, 0.32919 s, 408 MB/s
$ dd if=/mnt/fsxn/cache/test-file-2 of=/dev/null bs=64M iflag=direct
2+0 records in
2+0 records out
134217728 bytes (134 MB) copied, 0.327547 s, 410 MB/s
$ dd if=/mnt/fsxn/cache/test-file-2 of=/dev/null bs=64M iflag=direct
2+0 records in
2+0 records out
134217728 bytes (134 MB) copied, 0.31504 s, 426 MB/sかなり速くなりましたね! オリジンボリュームにアクセスする時と同じぐらいの速度が出るようになりました。
この時のキャッシュボリュームの使用量を確認します。読み込み前後のAvailableを比較すると15.86GB - 15.57GB = 0.29GBと2ファイル分ほどキャッシュしていそうですね。
::> volume show -volume vol1_cache
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
svm_cache vol1_cache - online RW 16GB 15.57GB 2%キャッシュしている状態でオリジンボリューム上のファイルを変更した場合の挙動の確認
次にキャッシュしている状態でオリジンボリューム上のファイルを変更した場合の挙動を確認します。
キャッシュボリュームにアクセスした時に、オリジンボリュームに変更があっても、キャッシュ時点の状態を返してしまうのか気になりました。
オリジンボリュームのファイルとキャッシュボリュームのファイルをdiffしてみて差分がないか検証してみます。
# 差分がないことを確認
$ diff /mnt/fsxn/origin/test-file-1 /mnt/fsxn/cache/test-file-1 --text | wc -l
0
# オリジンボリュームのファイルを変更
$ sudo dd if=/dev/urandom of=/mnt/fsxn/origin/test-file-1 bs=128M count=1
1+0 records in
1+0 records out
134217728 bytes (134 MB) copied, 0.94461 s, 142 MB/s
# 差分があるか確認
$ diff /mnt/fsxn/origin/test-file-1 /mnt/fsxn/cache/test-file-1 --text | wc -l
0
# ファイルに追記
$ echo test | sudo tee -a /mnt/fsxn/origin/test-file-1
test
# 差分があるか確認
$ diff /mnt/fsxn/origin/test-file-1 /mnt/fsxn/cache/test-file-1 --text | wc -l
0はい、差分がないようです。
NetApp公式ドキュメントを確認すると、どうやらデリゲーションエントリーという情報が有効かどうかでオリジンにアクセスするか判断しているようですね。
File cached but not valid
File cached but not valid is a scenario in which the file was originally cached, but something changed at the origin causing the cached delegation to become invalid. This scenario means that even though the file is cached, it is not current, and it must be re-fetched from the origin. Prior to 9.8, the invalidation happens only at the file level so any changes at the origin invalidate the whole file. 9.8 adds the option to enable Block Level Invalidation to invalidate cached file data at the block level. Figure 8 outlines the steps in this scenario as follows:
- A protocol request from the client reaches the NAS layer.
- The NAS layer then parses the operation and passes the optimized operation to the storage layer.
- The storage layer then determines the operation is on a FlexCache (remote) inode. When it tries to load the inode, it finds it.
- Because this is a FlexCache inode, RAL kicks in and determines whether the inode still has a delegation entry in the RIM file.
- Because the delegation entry is not valid, the storage operation is paused and RAL generates a remote storage operation to retrieve the inode from the origin.
- The remote retrieval operation is sent over the cluster intercluster LIF to the origin node.
- The RAL monitor on the origin receives the request and then generates a storage operation for disk.
- The inode is retrieved from disk.
- RAL then updates the entry into the REM file for delegation and generates the response to the FlexCache node.
- The response is sent over the cluster intercluster LIF back to the FlexCache node.
- RAL receives the response, stores the data on local disk for the inode, and updates the entry or creates an entry in the RIM file about this inode.
- The original storage operation is restarted, the data is retrieved, and the response is sent back to the NAS layer.
- The NAS layer then sends the protocol response back to the client
(以下機械翻訳)
キャッシュされたが有効でないファイル
File cached but not validは、ファイルが元々キャッシュされていたが、オリジンで何かが変更され、キャッシュされたデリゲーションが無効となった状態です。このシナリオは、ファイルがキャッシュされていても、最新ではないので、オリジンから再フェッチする必要があることを意味します。9.8 より前のバージョンでは、無効化はファイルレベルでしか行われないため、オリジンでの変更はファイル全体を無効にしてしまいます。9.8では、ブロックレベルの無効化を有効にして、ブロックレベルでキャッシュされたファイルデータを無効化するオプションが追加されました。図8は、このシナリオのステップの概要を示しています。 シナリオの手順を以下に示します。
- クライアントからのプロトコル要求がNASレイヤーに到達する。
- NASレイヤーは操作を解析し、最適化された操作をストレージレイヤーに渡す。
- ストレージ層は、その操作がFlexCache（リモート）inodeに対するものであると判断する。そのinodeをロードしようとすると、それが見つかる。
- これはFlexCache inodeであるため、RALが起動し、そのinodeがRIMファイル内にまだデリゲーションエントリーを持つかどうかを判断する。
- デリゲーション・エントリーが有効ではないため、ストレージ操作は一時停止され、RALはオリジンからinodeを取得するためにリモート・ストレージ操作を生成する。
- リモート検索オペレーションは、クラスタ間LIFを介してオリジンノードに送信されます。
- オリジンのRALモニターは要求を受信し、ディスクのストレージオペレーションを生成する。
- inodeがディスクから取り出される。
- RALはデリゲーションのためにREMファイルのエントリーを更新し、FlexCacheノードへの応答を生成する。
- レスポンスはクラスタ間LIFを経由してFlexCacheノードに送信される。
- RALは応答を受信し、そのinodeのローカルディスクにデータを保存し、このinodeに関するRIMファイル内のエントリーを更新するか、エントリーを作成する。
- 元のストレージ操作が再開され、データが取り出され、応答がNASレイヤに送り返される。
- NAS 層はプロトコル応答をクライアントに送り返す。
つまりは「キャッシュしている状態でオリジンボリューム上のファイルを変更した場合、キャッシュボリューム上のファイルにアクセスしたタイミングでオリジンボリュームから再度キャッシュする」という動きになるようです。
常に最新のファイルの状態を見れるということで安心しました。
どの程度のデータをキャッシュするのか確認
キャッシュボリューム上でどの程度のデータをキャッシュしてくれるのか検証します。
キャッシュボリュームのサイズは16GBとしています。16GBのうち、どの程度キャッシュしてくれるのか検証してみます。
まず、オリジンボリュームのサイズを1GBから32GBに変更します。
::> volume modify -vserver svm_origin -volume vol1 -size 32GB
Volume modify successful on volume vol1 of Vserver svm_origin.
::> volume show -vserver svm_* -volume vol1_cache, vol1
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
svm_cache vol1_cache - online RW 16GB 15.57GB 2%
svm_origin
vol1 aggr1 online RW 32GB 30.09GB 1%
2 entries were displayed.オリジンボリューム上に2GiBのファイルを8つ作成します。
$ for i in {4..11}; do
sudo dd if=/dev/urandom of=/mnt/fsxn/origin/test-file-${i} bs=128M count=16
done
16+0 records in
16+0 records out
2147483648 bytes (2.1 GB) copied, 14.2546 s, 151 MB/s
16+0 records in
16+0 records out
2147483648 bytes (2.1 GB) copied, 14.7553 s, 146 MB/s
16+0 records in
16+0 records out
2147483648 bytes (2.1 GB) copied, 14.6177 s, 147 MB/s
16+0 records in
16+0 records out
2147483648 bytes (2.1 GB) copied, 14.6524 s, 147 MB/s
16+0 records in
16+0 records out
2147483648 bytes (2.1 GB) copied, 14.7012 s, 146 MB/s
16+0 records in
16+0 records out
2147483648 bytes (2.1 GB) copied, 14.5977 s, 147 MB/s
16+0 records in
16+0 records out
2147483648 bytes (2.1 GB) copied, 14.6672 s, 146 MB/s
16+0 records in
16+0 records out
2147483648 bytes (2.1 GB) copied, 14.619 s, 147 MB/sファイル作成後、キャッシュボリュームから作成したファイルを読み込みます。
$ for i in {4..11}; do
dd if=/mnt/fsxn/cache/test-file-${i} of=/dev/null bs=64M iflag=direct
done
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 9.50031 s, 226 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.8832 s, 197 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.0463 s, 214 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 7.35071 s, 292 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.1976 s, 211 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 9.98542 s, 215 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 9.60124 s, 224 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.019 s, 195 MB/sキャッシュされていない場合は、読み込み速度は200MB/sほどのようですね。
ボリュームの使用量を確認します。
::> volume show -vserver svm_* -volume vol1_cache -fields used, available, size
vserver volume size available used
--------- ---------- ---- --------- ------
svm_cache vol1_cache 16GB 10.84GB 5.15GB5GBほど使用されているようです。16GB読み込んだのにも関わらず5GBというのは気になりますね。
試しに5ファイル = 10GiBほど読み込んでみます。
$ for i in {4..8}; do
dd if=/mnt/fsxn/cache/test-file-${i} of=/dev/null bs=64M iflag=direct
done
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 8.80949 s, 244 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.3479 s, 208 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.2786 s, 209 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 7.27408 s, 295 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 9.36719 s, 229 MB/s
$ for i in {4..8}; do
dd if=/mnt/fsxn/cache/test-file-${i} of=/dev/null bs=64M iflag=direct
done
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 8.89105 s, 242 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.8324 s, 198 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.1293 s, 212 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 9.6688 s, 222 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.4673 s, 205 MB/s各ファイル2回読み込んでみましたが、速度の改善は見られませんでした。
キャッシュボリュームの使用量も大きな変化はありません。
::> volume show -vserver svm_* -volume vol1_cache -fields used, available, size
vserver volume size available used
--------- ---------- ---- --------- ------
svm_cache vol1_cache 16GB 10.35GB 5.65GBボリュームのサイズを自動拡張するように変更して再度チャレンジしてみます。
FlexCacheでは自動拡張を使うと良い場面があるようです。
Autogrow
Sometimes, autogrow might be a good option to use on the FlexCache volume to conserve space. You might consider using autogrow when you don’t know what the working set size is or if you must be conservative with space on the FlexCache cluster.
(以下機械翻訳)
自動拡張
FlexCacheボリュームで、スペースを節約するために、autogrowを使用するのが良い場合があります。このような場合 作業セットのサイズが不明な場合や、FlexCacheクラスターでスペースを節約する必要がある場合に、autogrowの使用を検討することができます。FlexCacheクラスターでスペースを節約する必要がある場合、autogrowの使用を検討することができます。
試しに64GBまで自動で拡張するよう設定します。
::> volume autosize -vserver svm_cache -volume vol1_cache -maximum-size 64GB -mode grow
vol autosize: Volume "svm_cache:vol1_cache" autosize settings updated.
::> volume show -volume vol1_cache -fields autosize-mode, autosize-grow-threshold-percent, max-autosize
vserver volume max-autosize autosize-grow-threshold-percent autosize-mode
--------- ---------- ------------ ------------------------------- -------------
svm_cache vol1_cache 64GB 85% growこの状態で数回読み込んで、速度の改善が見られるか確認します。
$ for i in {4..11}; do
dd if=/mnt/fsxn/cache/test-file-${i} of=/dev/null bs=64M iflag=direct
done
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 8.4103 s, 255 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.2456 s, 210 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.3446 s, 208 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 6.5403 s, 328 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.1608 s, 211 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.1771 s, 192 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.0191 s, 195 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.1189 s, 193 MB/s
$ for i in {4..11}; do
dd if=/mnt/fsxn/cache/test-file-${i} of=/dev/null bs=64M iflag=direct
done
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 9.09456 s, 236 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.041 s, 195 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.6726 s, 201 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 8.61966 s, 249 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.5166 s, 204 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.0356 s, 195 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.3964 s, 207 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.2538 s, 191 MB/s
$ for i in {4..11}; do
dd if=/mnt/fsxn/cache/test-file-${i} of=/dev/null bs=64M iflag=direct
done
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 9.46414 s, 227 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.9587 s, 196 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.8128 s, 199 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 9.05474 s, 237 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.8839 s, 197 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.4306 s, 188 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.1535 s, 193 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.9936 s, 195 MB/s特に速度の改善は見られないですね。
この時のキャッシュボリュームの使用量は10.31GBでした。また、1.92GBほど自動拡張しているようです。
::> volume show -vserver svm_* -volume vol1_cache -fields used, available, size
vserver volume size available used
--------- ---------- ------- --------- -------
svm_cache vol1_cache 17.92GB 7.61GB 10.31GBFlexCacheではキャッシュボリュームにデータブロックを事前に取り込むことができます。
FlexCache ボリュームを事前に取り込むことで、キャッシュされたデータにアクセスするまでの時間を短縮できます。
オリジンボリュームの全てのファイルを事前に取り込んでみます。
# 権限レベルを advanced に変更
::> set advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y
# オリジンボリュームの全てのファイルを事前に取り込み
::*> flexcache prepopulate start -cache-vserver svm_cache -cache-volume vol1_cache -path-list / -isRecursion true
(volume flexcache prepopulate start)
[JobId 725]: FlexCache prepopulate job queued.
# 取り込みが完了したことを確認
::*> job show -id 725 -instance
Job ID: 725
Owning Vserver: svm_cache
Name: FlexCache prepopulate job for volume "vol1_cache" in Vserver "svm_cache".
Description: FLEXCACHE PREPOPULATE JOB
Priority: Medium
Node: FsxId05f72eb8f8d03c709-02
Affinity: Cluster
Schedule: @now
Queue Time: 02/15 15:04:25
Start Time: 02/15 15:04:25
End Time: 02/15 15:06:01
Drop-dead Time: -
Restarted?: false
State: Success
Status Code: 0
Completion String: Successful.Total number of files read by FlexCache prepopulate job are "11".
Job Type: FLEXCACHE PREPOPULATE
Job Category: FLEXCACHE
UUID: 997ad239-acf6-11ed-946a-5191ab1a5297
Execution Progress: -
User Name: fsxadmin
Restart Is Delayed by Module: -
# キャッシュボリュームの使用量の確認
::*> volume show -vserver svm_* -volume vol1_cache -fields used, available, size
vserver volume size available used
--------- ---------- ------- --------- ------
svm_cache vol1_cache 17.92GB 9.61GB 8.31GBオリジンボリュームの11ファイルをキャッシュボリュームに取り込んだようですね。
この状態で読み込んでみます。
$ for i in {4..11}; do
dd if=/mnt/fsxn/cache/test-file-${i} of=/dev/null bs=64M iflag=direct
done
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 9.63965 s, 223 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.585 s, 185 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.5702 s, 186 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 8.82606 s, 243 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.3867 s, 189 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.1435 s, 193 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 12.8122 s, 168 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.1186 s, 193 MB/s事前にキャッシュボリュームに取り込んでいるはずが、速度の改善は見られませんでした。
奥の手として、キャッシュボリュームを32GBに拡張します。
# 権限レベルを admin に変更
::*> set admin
# キャッシュボリュームを32GBに拡張
::> volume modify -vserver svm_cache -volume vol1_cache -size 32GB
[Job 726] Job succeeded: volume modify succeeded
# キャッシュボリュームのサイズが変更されたことを確認
::> volume show -vserver svm_* -volume vol1_cache -fields used, available, size
vserver volume size available used
--------- ---------- ---- --------- -------
svm_cache vol1_cache 32GB 21.68GB 10.32GBこの状態で数回読み込んでみます。
$ for i in {4..11}; do
dd if=/mnt/fsxn/cache/test-file-${i} of=/dev/null bs=64M iflag=direct
done
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 9.16725 s, 234 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.3595 s, 189 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 8.46666 s, 254 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 9.74742 s, 220 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.9074 s, 197 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.9054 s, 197 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 7.12794 s, 301 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.4474 s, 188 MB/s
$ for i in {4..11}; do
dd if=/mnt/fsxn/cache/test-file-${i} of=/dev/null bs=64M iflag=direct
done
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 8.71341 s, 246 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 7.1176 s, 302 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 6.96549 s, 308 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 7.21734 s, 298 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 6.63047 s, 324 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.1503 s, 212 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 8.54069 s, 251 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 9.45546 s, 227 MB/s
$ for i in {4..11}; do
dd if=/mnt/fsxn/cache/test-file-${i} of=/dev/null bs=64M iflag=direct
done
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 8.65602 s, 248 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 7.09251 s, 303 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 6.95373 s, 309 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 6.59382 s, 326 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.2883 s, 209 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.4205 s, 206 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 6.93038 s, 310 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.3946 s, 207 MB/s若干の速度の改善が見られました。運用の中でキャッシュボリュームの適切なサイズを探していくことになりそうです。
キャッシュボリュームのメンバーボリューム数を変更した場合のキャッシュの効き方の確認
先の検証から、データブロックはファイル単位でキャッシュボリュームのメンバーボリュームにキャッシュされることが分かりました。
現在のキャッシュボリュームのメンバーボリューム(FlexGroup constituents)毎の使用量を確認してみます。
# キャッシュボリュームの使用量
::> volume show -vserver svm_cache -volume vol1_cache -fields used, available, size
vserver volume size available used
--------- ---------- ---- --------- -------
svm_cache vol1_cache 32GB 19.70GB 12.30GB
# キャッシュボリュームのメンバーボリューム毎の使用量
::> volume show -vserver svm_cache -volume vol1_cache* -fields used, available, size -is-constituent true
vserver volume size available used
--------- ---------------- ---- --------- ------
svm_cache vol1_cache__0001 8GB 3.92GB 4.07GB
svm_cache vol1_cache__0002 8GB 5.92GB 2.08GB
svm_cache vol1_cache__0003 8GB 7.94GB 57.43MB
svm_cache vol1_cache__0004 8GB 1.92GB 6.08GB
4 entries were displayed.おおよそ2GB単位で消費されていることから、ファイルのデータブロックは複数のメンバーボリュームに跨ってキャッシュはされていなさそうです。
NetApp公式ドキュメントを確認すると、これはFlexGroupの仕様であることが分かります。
FlexGroup volume. A FlexGroup volume is a single namespace that is made up of multiple constituent member volumes and that is managed and acts like FlexVol volumes to storage administrators. Files in a FlexGroup volume are allocated to individual member volumes and are not striped across volumes or nodes. This is the default volume style for the cache volume.
(以下機械翻訳)
FlexGroupボリューム。FlexGroupボリュームは、複数の構成メンバー ボリュームで構成される単一のネームスペースで、ストレージ管理者にとってはFlexVolボリュームのように管理・操作されます。FlexGroupボリュームのファイルは、個々のメンバー ボリュームに割り当てられ、ボリュームやノード間でストライピングされることはありません。これは、キャッシュ・ボリュームのデフォルトのボリューム・スタイルです。
つまりはサイズが大きいファイルの割合が高い場合は、キャッシュボリュームのサイズに対してメンバーボリューム数が多すぎると上手くキャッシュされないのではと予想します。
試しにメンバーボリューム数を1つにしたキャッシュボリュームで動作確認をしてみます。
# キャッシュボリュームの作成
::> flexcache create -origin-vserver svm_origin -origin-volume vol1 -vserver svm_cache -volume vol1_cache_2 -aggr-list aggr1 -aggr-list-multiplier1 -size 16GB -junction-path /vol1_cache_2
(volume flexcache create)
[Job 782] Job succeeded: Successful.
# キャッシュボリュームの確認
::> volume show -vserver svm_cache -volume vol1_cache_2 -fields used, available, sizevserver volume size available used
--------- ------------ ---- --------- -------
svm_cache vol1_cache_2 16GB 15.94GB 57.30MB
# キャッシュボリュームのメンバーボリュームの確認
::> volume show -vserver svm_cache -volume vol1_cache_2* -fields used, available, size -is-constituent truevserver volume size available used
--------- ------------------ ---- --------- -------
svm_cache vol1_cache_2__0001 16GB 15.94GB 57.30MB作成したキャッシュボリュームをマウントします。その後ファイルを複数回読み込んで、速度の改善が見られるか確認します。
# マウントポイントの作成
$ sudo mkdir /mnt/fsxn/cache2
# キャッシュボリュームのマウント
$ sudo mount -t nfs svm-009cbf3dd37b7be59.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol1_cache_2 /mnt/fsxn/cache2
# ファイルの読み込み1回目
$ for i in {4..11}; do
dd if=/mnt/fsxn/cache2/test-file-${i} of=/dev/null bs=64M iflag=direct
done
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 9.40147 s, 228 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.2767 s, 190 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.6673 s, 184 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 10.978 s, 196 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.8176 s, 182 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.5655 s, 186 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.4897 s, 187 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 14.592 s, 147 MB/s
# ファイルの読み込み2回目
$ for i in {4..11}; do
dd if=/mnt/fsxn/cache2/test-file-${i} of=/dev/null bs=64M iflag=direct
done
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 8.5926 s, 250 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.3004 s, 190 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 12.0118 s, 179 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 13.7759 s, 156 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.9576 s, 180 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.5781 s, 185 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 12.6398 s, 170 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 11.126 s, 193 MB/s2回目の読み取り実行時の速度の改善は見られないですね。
メンバーボリュームの使用量は14.18GBであることから、かなりキャッシュしていそうな気はします。
::> volume show -vserver svm_cache -volume vol1_cache_2* -fields used, available, size -is-constituent true
vserver volume size available used
--------- ------------------ ---- --------- -------
svm_cache vol1_cache_2__0001 16GB 1.82GB 14.18GB1ファイルが2GiBで、使用量が14.18GBということから7ファイル分キャッシュしているのではと推測します。読み込んでいるファイル数は8つなので、読み込む過程でキャッシュを追い出してしまっているかもしれないですね。
キャッシュボリュームの自動拡張を有効化とデータブロックを事前に取り込みを行い、読み込み速度が改善するか確認します。
# 64GBまで自動で拡張するよう設定
::> volume autosize -vserver svm_cache -volume vol1_cache_2 -maximum-size 64GB -mode grow
vol autosize: Volume "svm_cache:vol1_cache_2" autosize settings updated.
# 自動拡張が有効化されたことを確認
::> volume show -volume vol1_cache_2 -fields autosize-mode, autosize-grow-threshold-percent, max-autosize
vserver volume max-autosize autosize-grow-threshold-percent autosize-mode
--------- ------------ ------------ ------------------------------- -------------
svm_cache vol1_cache_2 64GB 85% grow
# メンバーボリュームのサイズを確認
::> volume show -vserver svm_cache -volume vol1_cache_2* -fields used, available, size -is-constituent true
vserver volume size available used
--------- ------------------ ------- --------- -------
svm_cache vol1_cache_2__0001 16.85GB 2.67GB 14.18GB
# 権限レベルを advanced に変更
::> set advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y
# オリジンボリュームの全てのファイルを事前に取り込み
FsxId05f72eb8f8d03c709::*> flexcache prepopulate start -cache-vserver svm_cache -cache-volume vol1_cache_2 -path-list / -isRecursion true
(volume flexcache prepopulate start)
[JobId 788]: FlexCache prepopulate job queued.
# 権限レベルを admin に戻す
FsxId05f72eb8f8d03c709::*> set admin
# 取り込みが完了したことを確認
::> job show -id 788 -instance
Job ID: 788
Owning Vserver: svm_cache
Name: FlexCache prepopulate job for volume "vol1_cache_2" in Vserver "svm_cache".
Description: FLEXCACHE PREPOPULATE JOB
Priority: Medium
Node: FsxId05f72eb8f8d03c709-01
Affinity: Cluster
Schedule: @now
Queue Time: 02/18 10:50:43
Start Time: 02/18 10:50:46
End Time: 02/18 11:02:48
Drop-dead Time: -
Restarted?: false
State: Success
Status Code: 0
Completion String: Successful.Total number of files read by FlexCache prepopulate job are "11".
Job Type: FLEXCACHE PREPOPULATE
Job Category: FLEXCACHE
Execution Progress: -
User Name: fsxadmin
Restart Is Delayed by Module: -
# キャッシュボリュームの使用量の確認
::> volume show -vserver svm_cache -volume vol1_cache_2* -fields used, available, size -is-constituent true
vserver volume size available used
--------- ------------------ ------- --------- -------
svm_cache vol1_cache_2__0001 19.38GB 3.01GB 16.38GBオリジンボリュームの11ファイルをキャッシュボリュームに取り込んだようですね。
この状態で読み込んでみます。
$ for i in {4..11}; do
dd if=/mnt/fsxn/cache2/test-file-${i} of=/dev/null bs=64M iflag=direct
done
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 4.80175 s, 447 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 6.09359 s, 352 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 5.34346 s, 402 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 4.64489 s, 462 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 4.58336 s, 469 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 4.65763 s, 461 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 4.65322 s, 462 MB/s
32+0 records in
32+0 records out
2147483648 bytes (2.1 GB) copied, 4.6198 s, 465 MB/s爆速です。同じボリュームサイズでもメンバーボリューム数によってキャッシュの効き方がかなり変わりますね。
このことから、ファイルサイズに応じて適切なメンバーボリューム数に調整することが重要ということが分かりました。
メンバーボリューム数の目安は先述したFlexCache in ONTAP 9.11.1 | TR-4743のFlexGroup constituentsをご覧ください。
オンプレミスからのアクセスのレイテンシーを抑えたいならFlexCacheを検討しよう
Amazon FSx for NetApp ONTAPでFlexCacheを試してみました。
オンプレミスからのアクセスのレイテンシーを抑えたいならFlexCacheを検討することになりそうですね。
オリジンをFSx for ONTAPにして、キャッシュを各拠点に作成するなんてこともできそうです。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
20
