FabricPool ボリューム階層化ポリシー
FabricPool ボリューム階層化ポリシーは、ボリューム内のどのデータが階層化の対象となるかを決定し、階層化の最小冷却日数パラメータは、データが非アクティブとみなされ、階層化の対象となる時期を決定します。
|
|
アクセス制御リスト(ACL)、ディレクトリ構造、メタデータは階層化されず、常にローカル層に留まります。 |
毎日のバックグラウンド階層化スキャンでコールド ブロックが検索されます。同じボリュームから十分な4KBブロックが収集されると、それらは4MBオブジェクトに連結され、ボリューム階層化ポリシーに基づいてクラウド階層に移動されます。
階層化ポリシーの仕組みを理解することで、ストレージ管理のニーズに合った適切なポリシーを選択できるようになります。
ボリューム階層化ポリシーオプション
デフォルトでは、ボリュームは「None」ボリューム階層化ポリシーを使用します。例外として、FabricPoolアグリゲート上に新規作成されたFlexVolボリュームは、「Snapshot-Only」ボリューム階層化ポリシーを使用します。
`volume object-store tiering show`コマンドを使用して、FabricPoolボリュームの階層化ステータスを表示できます。link:https://docs.netapp.com/us-en/ontap-cli//volume-object-store-tiering-show.html["ONTAPコマンド リファレンス"^]の `volume object-store tiering show`の詳細をご覧ください。
FabricPoolの階層化ポリシーはボリューム レベルで指定し、次の4つから選択できます。
Snapshot のみ
この `snapshot-only`階層化ポリシーは、アクティブ ファイル システムに関連付けられなくなったスナップショットデータを階層化します。デフォルトでは、スナップショットが階層化の対象となるには、2日間アクティビティがない状態が続く必要があります。ほとんどのデータ保護スケジュールは1時間ごとまたは1日ごとで、データは階層化される前にローカルで読み取られます。
階層化の最小冷却期間のデフォルト設定は、 `-tiering-minimum-cooling-days`パラメータを使用して、 `volume create`および `volume modify`コマンドの上級権限レベルで変更できます。ONTAP 9.8以降での有効な値は、2~183日です。ONTAP 9.8より前のバージョンでの有効な値は、2~63日です。
スナップショットコピーに関連付けられたコールドブロックは、読み取られた際にコールド状態のままとなり、ローカル層に書き戻されることはありません。
Auto
この `auto`階層化ポリシーは、ボリューム内のすべてのコールドデータ(スナップショットとアクティブ ファイル システムの両方)をクラウド層に階層化します。デフォルトの階層化最小冷却期間は 31 日で、アクティブ ファイル システムとスナップショットの両方を含むボリューム全体に適用されます。
階層化の最小冷却期間のデフォルト設定は、 `-tiering-minimum-cooling-days`パラメータを使用して、 `volume create`および `volume modify`コマンドの上級権限レベルで変更できます。有効な値は2~183日です。
階層化ポリシーが「Auto」に設定されているボリュームでは、ランダムに読み取られる際に、コールドブロックがホットブロックとなり、ローカル階層に書き戻されます。
階層化ポリシーが「自動」に設定されているボリュームでは、シーケンシャルに読み込まれる場合、コールドブロックはコールド状態のままクラウド階層に留まります。ローカル階層には書き戻されません。
All
`all`階層化ポリシーは、ボリューム内のすべてのデータを即座にコールドデータとしてマークし、可能な限り速やかにクラウド階層への階層化を開始します。 `all`階層化ポリシーを使用するボリューム内の新しいブロックがコールドになるまで、48時間待つ必要はありません。
階層化スキャンの実行後すぐにクラウド階層にデータが移動され、階層化の最小クーリング期間は適用されません。この設定は変更できません。
階層化ポリシーが「すべて」に設定されているボリューム内のコールドブロックが読み取られた場合、それらはコールド状態のままクラウド階層に留まります。それらはローカル階層には書き戻されません。
|
|
`all`ボリューム階層化ポリシーは、通常のクライアント トラフィックがある読み取り / 書き込みボリュームでは使用しないでください。 オブジェクトストレージは、ファイルストレージやブロックストレージのようにトランザクション処理に対応していません。「すべて」階層化ポリシーを使用しているボリュームにオブジェクトとして保存されているファイルに変更を加えると、新しいオブジェクトの作成、既存のオブジェクトの断片化、読み取りパフォーマンスの低下、およびストレージの非効率性の増加が発生する可能性があります。 |
なし
`none`階層化ポリシーでは、ボリュームのデータはパフォーマンス階層に保持され、データの階層化は行われません。
階層化ポリシーを `none`に設定すると、新たな階層化は行われません。以前にクラウド階層に移動されたボリュームデータは、ホットになるまでクラウド階層に残り、その後自動的にローカル階層に戻されます。
データがクラウド階層に移動されることはないため、階層化の最小クーリング期間は適用されません。この設定は変更できません。
階層化ポリシーが `none`に設定されたボリューム内のコールド ブロックが読み取られると、そのブロックはホット ブロックになり、ローカル階層に書き込まれます。
`volume show`コマンド出力には、ボリュームの階層化ポリシーが表示されます。FabricPoolで一度も使用されていないボリュームの場合は、出力に `none`階層化ポリシーが表示されます。
|
|
SVM DR 関係では、ソース ボリュームと宛先ボリュームはFabricPoolアグリゲートを使用する必要はありませんが、同じ階層化ポリシーを使用する必要があります。 |
ボリューム階層化ポリシーを変更するとどうなりますか?
`volume modify`操作を実行することで、ボリュームの階層化ポリシーを変更できます。階層化ポリシーを変更すると、データがコールド状態になってクラウド階層に移動されるまでの時間にどのような影響があるかを理解しておく必要があります。
-
階層化ポリシーを `snapshot-only`または `none`から `auto`に変更すると、ONTAPは、アクティブ ファイル システム内のすでにコールド状態のユーザー データ ブロックを、それらのユーザー データ ブロックが以前はクラウド階層に適格でなかった場合でも、クラウド階層に送信します。
-
階層化ポリシーを `all`から別のポリシーに変更すると、ONTAPはアクティブ ファイル システムとスナップショット内のすべてのユーザーブロックを可能な限り速やかにクラウドに移動します。ONTAP 9.8より前のバージョンでは、ブロックは次の階層化スキャンが実行されるまで待機する必要がありました。
移動されたブロックを高パフォーマンス階層に戻すことはできません。
-
階層化ポリシーを `auto`から `snapshot-only`または `none`に変更しても、すでにクラウド階層に移動されているアクティブ ファイル システム ブロックがパフォーマンス階層に戻されることはありません。
それらのデータを高パフォーマンス階層に戻すには、ボリュームの読み取りが必要になります。
-
ボリュームの階層化ポリシーを変更すると、階層化の最小クーリング期間は常にそのポリシーのデフォルト値にリセットされます。
ボリュームを移動した場合の階層化ポリシーへの影響
-
ボリュームをFabricPool対応アグリゲートに移動したりFabricPool対応アグリゲートから移動しても、別の階層化ポリシーを明示的に指定しないかぎり、ボリュームの階層化ポリシーは元のままです。
ただし、階層化ポリシーが適用されるのは、ボリュームがFabricPool対応アグリゲート内にある場合のみです。
-
宛先に別の階層化ポリシーを指定しない限り、ボリュームの `-tiering-minimum-cooling-days`パラメータの既存の値はボリュームとともに移動します。
別の階層化ポリシーを指定した場合は、そのポリシーのデフォルトの階層化の最小クーリング期間が使用されます。デスティネーションがFabricPoolかどうかは関係ありません。
-
アグリゲート間でボリュームを移動し、同時に階層化ポリシーも変更できます。
-
`volume move`操作に `auto`階層化ポリシーが関係する場合は、特に注意する必要があります。
ソースと宛先の両方がFabricPool対応アグリゲートであると仮定すると、次の表は `auto`に関連するポリシー変更を伴う `volume move`操作の結果をまとめたものです:
階層化ポリシーが設定されているボリュームを移動する場合…
そして、移行に伴って階層化ポリシーを変更します…
その後、ボリュームの移動後…
allautoすべてのデータが高パフォーマンス階層に移動されます。
snapshot-only、none、またはautoautoデータ ブロックがソースと同じデスティネーションの階層に移動されます。
autoまたはallsnapshot-onlyすべてのデータが高パフォーマンス階層に移動されます。
autoallすべてのユーザ データがクラウド階層に移動されます。
snapshot-only,autoまたはallnoneすべてのデータが高パフォーマンス階層に残ります。
ボリュームをクローニングした場合の階層化ポリシーへの影響
-
ONTAP 9.8以降、クローン ボリュームは常に階層化ポリシーとクラウド読み出しポリシーの両方を親ボリュームから継承します。
ONTAP 9.8 より前のリリースでは、親に `all`階層化ポリシーがある場合を除き、クローンはその親から階層化ポリシーを継承します。
-
親ボリュームに `never`クラウド取得ポリシーがある場合、そのクローン ボリュームには `never`クラウド取得ポリシーまたは `all`階層化ポリシーのいずれかと、対応するクラウド取得ポリシー `default`が必要です。
-
すべてのクローン ボリュームにクラウド取得ポリシー `never`が設定されていない限り、親ボリュームのクラウド取得ポリシーを `never`に変更することはできません。
ボリュームをクローニングするときには、次のベストプラクティスに留意してください。
-
`-tiering-policy`オプションと `tiering-minimum-cooling-days`クローンのオプションは、クローン固有のブロックの階層化動作のみを制御します。そのため、親FlexVolの階層化設定では、クローンと同じ量のデータを移動するか、クローンよりも少ない量のデータを移動する設定を使用することをお勧めします。
-
親FlexVolでは、すべてのクローンの読み出しポリシーと同じまたはそれより多い量のデータを移動するクラウド読み出しポリシーを使用してください。
階層化ポリシーとクラウド移行
FabricPoolのクラウド データ読み出しは階層化ポリシーで制御されます。階層化ポリシーは、読み取りパターンに基づいてクラウド階層から高パフォーマンス階層へのデータの読み出しを決定します。読み取りパターンにはシーケンシャルとランダムがあります。
次の表に、各階層化ポリシーとそのクラウド データ読み出しルールを示します。
階層化ポリシー |
読み出し動作 |
なし |
シーケンシャル リードとランダム リード |
snapshot-only |
シーケンシャル リードとランダム リード |
auto |
ランダム リード |
all |
データ読み出しなし |
ONTAP 9.8 以降では、クラウド移行制御 `cloud-retrieval-policy`オプションによって、階層化ポリシーによって制御されるデフォルトのクラウド移行または取得動作がオーバーライドされます。
次の表に、サポートされるクラウド読み出しポリシーとその読み出し動作を示します。
クラウド読み出しポリシー |
読み出し動作 |
default |
階層化ポリシーによって、どのデータをプルバックするかが決定されるため、“default,” `cloud-retrieval-policy`によるクラウド データの取得には変更はありません。このポリシーは、ホストされているアグリゲートの種類に関係なく、すべてのボリュームのデフォルト値になります。 |
on-read |
クライアントによって読み取られたデータはすべてクラウド階層から高パフォーマンス階層に移行されます。 |
never |
クライアントによって読み取られたデータはクラウド階層から高パフォーマンス階層に移行されません。 |
promote |
|
この手順で説明されているコマンドの詳細については、"ONTAPコマンド リファレンス"を参照してください。