ONTAP 9.17.1P1 では、 FlexCacheライトバックの大幅な機能強化が導入されました。オリジン クラスターとキャッシュ クラスターの両方で、9.17.1P1 以降の現在の推奨リリースを実行することを 強く 推奨します。9.17.1 コードラインを実行できない場合は、9.16.1 の最新の P リリースが次に推奨されるリリースです。ONTAP 9.15.1 には、 FlexCacheライトバックに必要な修正と改善がすべて含まれているわけではないため、本番環境のワークロードには推奨されません。

現在の反復計算では、FlexCacheボリューム全体に対して1つのコンスティチュエントを使用してFlexCacheライトバックキャッシュを設定する必要があります。マルチコンスティチュエントFlexCachesを使用すると、データが不要にキャッシュから削除される可能性があります。

テストは、100 GB 未満のファイルと、キャッシュとオリジン間の WAN ラウンドトリップ時間が 200 ミリ秒を超えないことで実行されました。これらの制限を超えるワークロードでは、予期しないパフォーマンス特性が発生する可能性があります。

SMB代替データストリームに書き込むと、メインファイルがキャッシュから削除されます。メインファイルのすべてのダーティデータは、そのファイルで他の操作を実行する前にオリジンにフラッシュする必要があります。代替データストリームもオリジンに転送されます。

ファイル名を変更すると、そのファイルがキャッシュから削除されます。ファイルのすべてのダーティーデータは、そのファイルで他の操作を実行する前に、オリジンにフラッシュする必要があります。

現時点では、ライトバックが有効なFlexCacheボリューム上のファイルに対して変更または設定できる属性は次のとおりです。

元のボリュームでSnapshotが作成されると、その元のボリュームに関連付けられたライトバックが有効になっているすべてのキャッシュから、未処理のダーティーデータがすべてリコールされます。大量のライトバック処理が実行中の場合は、これらのダーティファイルの削除に時間がかかることがあるため、処理の再試行が複数回必要になることがあります。

書き込み用の SMB 便宜的ロック (Oplock) は、ライトバック対応のFlexCacheボリュームではサポートされません。

原点の使用率が80%未満である必要があります。元のボリュームに20%以上のスペースが残っていないと、キャッシュボリュームに排他的ロック委譲が許可されません。この場合、ライトバックが有効なキャッシュへの呼び出しはオリジンに転送されます。これにより、元のスペースが不足して、ライトバックが有効なキャッシュにダーティデータが孤立したままになるのを防ぐことができます。

帯域幅が狭かったり、クラスタ間ネットワークに損失があったりすると、 FlexCache の書き戻しパフォーマンスに大きな悪影響を与える可能性があります。特定の帯域幅要件はありませんが、ワークロードに大きく依存するため、キャッシュとオリジン間のクラスター間リンクの健全性を確認することを 強く 推奨します。