NetApp

2020.04.23

みなさん、こんにちは
SB C&S　技術担当の小川です。

「オブジェクトストレージとの自動階層化を実現する『FabricPool』」ではFabricPoolの概要を紹介させて頂きましたが、技術的な詳細を知りたいと思った方もいるかと思います。
今回から全3回に渡りFabricPoolのアーキテクチャを紹介いたします。第1回は「FabricPoolの構成イメージ」と「データ書き込み時のCloud Tierのデータ転送」について説明いたします。

　FabricPoolの構成イメージ　　　　　　　　　　　　　　　　　　　　　　　　　　　　

FabricPoolはクラスタ全体に設定されるわけではなく、データアグリゲートに対しFabricPoolを有効にします。FabricPoolを有効にするとオブジェクトストレージも含めて1つのアグリゲートとして管理されます。その後、データアグリゲートから切り出されたFlexVol単位で階層化のポリシーを設定しオブジェクトストレージとのデータ階層化が実現されます。FlexVol単位でポリシーを設定できるため「移動ユーザープロファイル用のFlexVolにはSnapshot Onlyを適用」、「アーカイブデータ用のFlexVolにはAllを適用」といったようにFlexVolの用途に合わせてポリシーを選択できるため柔軟な運用が実現できることがメリットの1つです。

FlexVolの容量について「階層化されるからクライアントから見た空き容量が増えるのでは？」と思われるかもしれませんがオブジェクトストレージへの階層化はあくまでアグリゲート単位のバックグラウンド処理で階層化される仕組みです。FlexVolはあくまで論理的な容量を管理しているためアグリゲートでデータがオブジェクトストレージに移動していてもクライアント側にはFlexVolで割り当てられた容量が見えます。例えば50GBのFlexVolを共有しOSから10GB書き込む場合、FabricPoolによりデータがオブジェクトストレージに移動していてもOSから見た残り容量は40GBになります。

　Local TierからCloud Tierへのデータ移動　　　　　　　　　　　　　　　　　　　　　　　　　　　　

Local Tier(プライマリストレージとなるONTAPのデータ保存領域)からCloud Tier(オブジェクトストレージ)へのデータ転送は特定の条件を元に実施されます。ここでは「アグリゲートの使用量に基づくデータ転送の条件」と「それぞれのポリシーごとのデータ書き込み時のデータ転送の動作」について説明いたします。それぞれのポリシーの説明に関しては「オブジェクトストレージとの自動階層化を実現する『FabricPool』」をご参照下さい。

■アグリゲートの使用量に基づくデータ転送

FabricPoolにおけるCloud Tierへのデータ転送は階層化ポリシー設定後すぐにデータ転送が行われるわけではありません。FabricPoolでは、アグリゲート(Local Tier)の使用率があらかじめ定めておいた数値を超えた際にデータ転送が実行されることになっています。データ転送が実行されるアグリゲート使用率のデフォルトのしきい値は50％に設定されています。なお、このアグリゲート(Local Tier)使用量に基づくデータ転送はAutoポリシーとSnapshot Onlyポリシーで使用される仕組みです。

このしきい値は変更することができます。CLIのAdvanced特権レベルで以下のコマンドを実行することにより変更できます。

storage aggregate object-store modify -aggregate <Aggregate名> -tiering-fullness-threshold <#> (0%-99%)

例えばONTAPを用いたストレージ統合を実施した際、移動ユーザープロファイルのようにアクセス頻度が高いデータと長期保存目的の書類データのようにアクセス頻度の低いデータを同一のONTAPに格納することがあるかもしれません。その際、長期保存データは必ずしもオンプレのONTAP環境に常にある必要がないためオンプレのONTAPの使用量を無駄に増やしていることも考えられます。このような場合にアグリゲート(Local Tier)の使用率のしきい値をデフォルトの50%から下げておくことでオンプレのONTAPの容量を最小限に抑えることができます。

■Autoポリシーにおけるデータの書き込み時のCloud Tierへのデータ転送

Autoポリシーはアクセス頻度の高いデータをホットデータ、アクセス頻度の低いデータをコールドデータと自動で判別し、ホットデータはLocal Tierに保存し、コールドデータはCloud Tierに転送するポリシーです。保存されたデータのブロックは「Block Temperature」という仕組みに基づき、ホットブロックとコールドブロックのいずれかに判別されます。
「Block Temperature」ではデータブロックに対し2種類のスキャンを実行します。

Cooling scan：データブロックを監視し、一定期間アクセスがないブロックをコールドブロックと判断
Tiering scan：コールドブロックを収集し、4MB(4KBのブロック1024個)のオブジェクトにパッケージしオブジェクトストレージに転送する。Tiering scanは1日1回実施される。

ここでデータ書き込みからオブジェクトストレージへのデータ転送の流れを見てみましょう。
Autoポリシーが設定されたボリュームにデータを書き込まれると全てのデータはホットデータとしてLocal Tierに保存されます。

Cooling scanが実行され一定期間アクセスがないブロックをコールドブロックと判断します。Autoポリシーはデフォルトで31日間アクセスがないとコールドブロックとして判断されます。未アクセスを判断する期間は2〜63日の間で設定を変更できます。

その後アグリゲートの使用率が50%を超えている場合、1日1回Tiering scanが実行されコールドブロックを4MB(4KBブロック1024個)のオブジェクトにまとめCloud Tierのオブジェクトストレージに転送されます。

■Snapshot Onlyポリシーにおけるデータの書き込み時のCloud Tierへのデータ転送

　Snapshot OnlyポリシーはAutoポリシーと同様に「Block Temperature」を利用して階層化が実施されます。Autoポリシーとの違いは「転送対象となるデータがSnapshotデータ」、「Cooling scanのしきい値」となっています。

まず、Cooling scanでSnapshotを構成するデータブロックで2日間アクセスがないブロックをコールドブロックと判断します。Autoポリシーと同様に未アクセスを判断する期間を2〜63日の間で設定変更できます。

■Allポリシーにおけるデータの書き込み時のCloud Tierへのデータ転送

AllポリシーではAutoポリシーやSnapshotポリシーとは異なりBlock Temperatureによるホットブロックとコールドブロックの判定を行わずに書き込まれたデータは全てコールドブロックと判定されます。

その後、即座にTiering Scanが実施されます。他のポリシーとは異なり1日待つことはしません。Tiering Scanが実行されると4MBのオブジェクトにまとめCloud Tierに転送します。4MBに満たない場合は転送されません。

ここまでFabricPoolの構成とイメージとそれぞれの階層化ポリシーにおけるCloud Tierへのデータの移動について説明させて頂きました。
今回の説明させて頂いた内容のポイントは以下となります。

今回のポイント

FabircPoolはデータアグリゲートに対して有効化
オブジェクトストレージを含めて1つのアグリゲートになるイメージ
階層化ポリシーはFlexVol単位で設定
AutoポリシーとSnapshot OnlyポリシーではLocal Tierの使用率が50%を超えないとCloud Tierにデータを転送しない
ブロックのアクセス頻度により「ホットブロック」と「コールドブロック」を判定
Cooling Scanにより、Autoポリシーでは31日間、Snapshot Onlyポリシーでは2日間、それぞれアクセスがないブロックをコールドブロックと判定
1日1回のTiering scanでコールドブロックを4MB(4KBのブロック1024個)のオブジェクトにまとめてCloud Tierに転送
Allポリシーでは書き込み後すぐコールドブロックと判定
AllポリシーではTiering scanが1日1回ではなく即座に実行されコールドブロックを4MB(4KBのブロック1024個)のオブジェクトにまとめてCloud Tierに転送

次回はFabricPoolのデータの読み込みの動作について説明いたします。

【SB C&SNetAppプロモーションTwitterアカウント】

NetAppに関するさまざまな情報を公開しています。

皆様フォロー宜しくお願いいたします。

@sbcas_netapp_pr

TwitterアプリからはこちらのQRコードもどうぞ

Twitter_QRコード.PNG