Skip to main content
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

ONTAP FlexCacheライトバックガイドライン

共同作成者 elliott-ecton netapp-dbagwell elliottecton
PDF

FlexCacheライトバックには、オリジンとキャッシュ間の複雑な相互作用が多数発生します。最適なパフォーマンスを得るには、環境が以下のガイドラインに準拠していることを確認してください。これらのガイドラインは、コンテンツ作成時点で利用可能な最新のメジャーONTAPバージョン（ONTAP 9.17.1）に基づいています。

ベストプラクティスとして、本番環境のワークロードを非本番環境でテストすることをお勧めします。これらのガイドラインに従わずにFlexCacheライトバックを実装する場合は、特に重要です。

以下のガイドラインはNetApp社内で十分にテストされています。これらのガイドラインに従うことを*強く*推奨します。従わない場合、予期しない動作が発生する可能性があります。

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

  • 複数コンスティチュエントのFlexCacheライトバックキャッシュは、ONTAP 9.19.1 GA、9.18.1P2、9.17.1P3、9.16.1P10、および各リリースファミリの以降のPリリースでサポートされています。以前のONTAPリリースでは、FlexCacheボリューム全体に対して単一のコンスティチュエントを使用する必要があります。以前のリリースで複数コンスティチュエントのFlexCachesを使用すると、キャッシュから意図せずデータが削除される可能性があります。

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

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

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

  • 現時点では、ライトバック対応FlexCacheボリューム上のファイルで変更または設定できる属性は次のとおりです：

    • タイムスタンプ

    • モードビット

    • NT ACL

    • 所有者

    • グループ

    • サイズ

      その他の属性の変更または設定はオリジンに転送され、その結果、ファイルがキャッシュから削除される可能性があります。キャッシュでその他の属性の変更または設定が必要な場合は、アカウント チームにPVRの開設を依頼してください。

  • オリジンでスナップショットを作成すると、そのオリジンボリュームに関連付けられたライトバック対応キャッシュから、未処理のダーティー データがすべて呼び出されます。大量のライトバック処理が進行中の場合、ダーティファイルの削除に時間がかかるため、この操作を複数回再試行する必要がある可能性があります。

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

  • ライトバックキャッシュは、オリジンボリュームの空き容量が20%以下になると、自動的にライトアラウンドモードに切り替わります。これにより、ライトバックが有効なキャッシュにダーティー データが孤立したままになる原因となる、オリジンでのスペース不足を防ぐことができます。オリジンボリュームがオーバープロビジョニングされている場合、その論理プロビジョニングサイズはアグリゲート内の空き容量よりも大きくなります。20%のしきい値は、オリジンボリュームの利用可能なスペースとアグリゲートの利用可能な物理容量の両方に対して評価されます。 `percent-used`および `capacity`は、利用可能なスペースがすでにそのしきい値を下回っている場合でも、0%と表示されることがあります。

    以下の例は、過剰にプロビジョニングされたオリジンボリュームです。データはほとんど書き込まれませんが、アグリゲートは論理サイズ全体をサポートできません：

    ORIGIN::> vol show -volume origin_volume -fields percent-used,available,size
vserver             volume           size    available percent-used
------------------- ---------------- ------- --------- ------------
origin_svm          origin_volume    19.70TB 1.33TB    0%
    `percent-used` は0%ですが、利用可能な容量は19.70TBのうち1.33TBであり、1.33 / 19.70、つまり約7%が利用可能であることに注目してください。これは既に20%のしきい値を下回っているため、このオリジンのライトバックキャッシュはライトアラウンドモードに切り替わります。
    ORIGIN::> df -h origin_volume
Filesystem               total       used      avail   capacity  Mounted on       Vserver
/vol/origin_volume/      18TB        515MB     1363GB         0%    ---           origin_svm

2 entries were displayed.
    `capacity` も0%であり、515MBしか使用されていないことに注目してください。利用可能なスペースは18TB中1363GBで、ファイルシステムの約7%です。パーセンテージの列は、保存されているデータ量が少ないことを示しています。これらは、アグリゲートが実際に提供できるボリュームサイズがどれくらいかを示すものではありません。

  • 低帯域幅および/または損失のあるクラスタ間ネットワークは、FlexCacheのライトバックパフォーマンスに重大な悪影響を及ぼす可能性があります。帯域幅の要件はワークロードに大きく依存するため、特定の要件はありませんが、キャッシュとオリジン間のクラスタ間リンクの健全性を確保することを*強く*お勧めします。ネットワークでパケットロスが発生しやすく、ONTAP 9.19.1以降を実行している場合は、パフォーマンスを向上させるために"TCP RACK"を使用することを検討してください。