AWS DataSync を使用して Amazon FSx for NetApp ONTAP にファイル共有を移行する

このブログは Darryl Diosomito ( Senior Solution Architect ) によって執筆された内容を翻訳したものです。原文はこちらを参照して下さい。 

データ移行を計画する際は、移行ツールを評価し、オンライン移行に利用可能な帯域幅があるかどうかを判断し、移行元と移行先の特性を理解する必要があります。オンプレミスのストレージや他の AWS ストレージサービスから Amazon FSx for NetApp ONTAP ( 以降 FSx for ONTAPと表記 ) にデータを移行する場合、移行元が NetApp ONTAP ではない、あるいは SnapMirror ライセンスを保有していない場合があります。 FSx for ONTAP に移行する場合、移行戦略の一環としてボリュームデータの階層化ポリシーの特性を考慮する必要があります。

FSx for ONTAP ファイルシステムには、プライマリストレージとキャパシティプールストレージの 2 つのストレージ層があります。プライマリ層は、データセットのアクティブな部分やレイテンシーの影響を受けやすい部分のためにプロビジョニングされた高性能な SSD ( ソリッドステートドライブ ) ストレージです。キャパシティプール層は、ペタバイトサイズまで拡張できる弾力性の高いストレージ層で、アクセス頻度の低いデータに合わせてコストが最適化されます。 FSx for ONTAP ファイルシステムを作成する際は、プロビジョニングされた SSD の容量レベルを設定します。ファイルシステム作成後は、容量を拡張することはできますが縮小することはできません。

一般的にはプライマリ層の容量の 80% 以上を消費しないようにすることが推奨されています。しかし移行するデータセットが、割り当てたプライマリ層の容量より大きい場合はどうなるでしょうか ?

この記事では異なるポリシーが移行にどのように影響するかを説明し、プライマリ層の容量を考慮に入れるためのいくつかのテクニックについて紹介していきます。

ボリュームデータの階層化ポリシーを理解する

FSx for ONTAPは、データアクセスのパターンに基づいてシステムのプライマリ層とキャパシティプール層の間でデータを自動的に移行します。データ階層化により、データのごく一部に対して SSD ストレージの費用を支払うだけで、ワークロードに対して SSD レベルのパフォーマンスを実現することができます。結果として、データセットのアクティブな部分のみにプライマリ層をプロビジョニングし、残りのデータは低コストのキャパシティプール層に保存する必要があります。

FSx for ONTAPファイルシステム内の各ボリュームには階層化ポリシーが関連付けられています。この階層化ポリシーは、そのボリューム内のデータがプライマリ層とキャパシティプール層の間でどのように移行されるかを決定します。 FSx for ONTAP のボリューム管理のドキュメントに記載されている 4 つの階層化ポリシーから 1 つを選択することができます。この記事では移行に関する Auto ( 自動 ) と All ( すべて ) ポリシーに焦点を当てます。

• Auto ( 自動 ) : アクティブファイルシステムとスナップショットコピーの両方にあるコールドユーザーデータブロックを、キャパシティプール層に自動的に移動させます。キャパシティプール層からデータがランダムに読み込まれた場合、キャパシティプール層内のコールドデータブロックはホットとなり、プライマリ層に移動します。インデックススキャンやアンチウイルススキャンなどのシーケンシャルな読み取りが行われた場合、コールドデータブロックはコールドのままであり、プライマリ層に移動することはありません。
• All ( すべて ) : スナップショットのコピーとアクティブファイルシステムの両方にあるコールドユーザーデータブロックを、すべてキャパシティプール層に移行します。キャパシティプール層のコールドデータブロックが読み取られた場合はコールドのままとなり、プライマリ層に書き戻されることはありません。

Snapshot Only ( スナップショットのみ ) および Auto ポリシーには特定の冷却期間を設定することができ、その範囲は 2 ～ 183 日で、デフォルトではそれぞれ 2 日と 31 日です。

FSx for ONTAP のデータ移行には、階層化ポリシーを All に設定可能

パフォーマンスとコストのバランスを考慮して設計する場合、多くのお客様は階層化ポリシーを All に設定したボリュームにデータを移行します。これにより、プライマリ層のサイズを移行するデータセットよりも小さくすることができ、データの大部分をキャパシティプール層に格納することができます。階層化ポリシーを All に設定するとすべてのデータブロックがコールドとしてマークされ、冷却期間なしでキャパシティプール層にデータが移動します。

FSx for ONTAP ボリュームにデータ移行を行う場合、プライマリ層の SSD に直接書き込むことになります。階層化ポリシーがシステムにどのように影響するかを知ることは、移行したデータを SSD に保持することで高性能なプライマリ層の貴重なスペースを占有しないようにするために重要です。

例えば、階層化ポリシーを Auto に設定した場合、デフォルトの冷却期間を変更しない限り移行したデータは最低 31 日間プライマリ層に留まることになります。推奨容量の 80% 以内にすべての移行データを収めることができたとしても、そのデータをプライマリ層に留めておくかアクセスパターンに基づいてデータを移動するタイミングをシステムに知らせるかをすぐに検討する必要があります。移行が完了したらポリシーを Auto に戻して、アクティブなデータをプライマリ層に移動して保持できるようにします。

AWS DataSync による移行を開始するには、オンプレミスのストレージシステムやストレージサービスの送信元と FSx for ONTAP の送信先としてロケーションを作成します。

図 1 は AWS DataSync を使って FSx for ONTAP にデータを移行する例で、スループット容量は 512 MB/s 、移行先ボリュームの階層化ポリシーは All に設定されています。この移行では合計 1.1 TiB の 1 GB ファイルで構成されるランダムデータのソースデータセットが使用されました。移行先ファイルシステムには、 1540 GiB のプロビジョニングされたプライマリ層があり、 2 TB ボリュームをターゲットにした 1.37 TiB の利用可能容量があります。移行するデータは利用可能なプライマリ層に収まっています。この移行では平均 450 MiB/s を達成し、緑の線で示すようにプライマリ層の容量が消費され、同時に赤の線で示すようにキャパシティプール層にデータが移行されていることが分かります。

図 1: 割り当てた容量に収まるデータを移行した時の、 FSx for ONTAP ファイルシステムのプライマリ層の使用状況

書き込みとの競合

目標はデータ移行をできるだけ早く効率的に行うことです。しかし、階層化ポリシーを All に設定しても、データセットが利用可能なプライマリ層の容量より大きい場合、受信データはポリシーによりキャパシティプール層に移動する速度より速くプライマリ層に書き込まれる可能性があります。プライマリ層を消費できるかどうかは、移行元ファイルシステムからの読み取り速度、移行元のファイルの数とサイズ、ネットワーク帯域幅、 FSX for ONTAP ファイルシステムのプロビジョニング済みスループット容量など、さまざまな要因に左右されます。

前の例と同様の構成で別の移行ユースケースを見てみましょう。ただし今回は利用可能なプライマリ層の容量が 910 GiB しかなく、 1.1 TiB のデータセットより少ないです。 AWS DataSync を使ったこの移行のデータスループットは平均 472 MiB/s で、図 2 に見られるように推奨される 80% の空き容量ではプライマリ層を使い切ってしまいます。 90% の閾値まで消費すると、アクティブなデータの読み込みがプライマリ層に移動しなくなり、すべての階層化操作が完全に停止する 98% の閾値に近づきます。プライマリ層が満杯になると、データ移行そのものだけでなく他の実行中のアプリケーションのパフォーマンスにも影響を与える可能性があります。

図 2: 割り当てた容量に収まらないデータを移行した時の、 FSx for ONTAP ファイルシステムのプライマリ層の使用状況

理想的なシナリオでは、移行のためにプライマリ層の容量を増やすことができますが、それは結局使用しない性能のためにコストを追加することになるかもしれません。また現在プライマリ層の上限は 192 TiB であり、データセットが 192 TiB を超える場合移行の制限要因になる可能性があります。

AWS DataSync では個々のタスク実行ごとに帯域を制限する機能があり、プライマリ層にデータを取り込む速度を制御することで、取り込んだデータがキャパシティプール層に移行するまでの時間を確保することができます。

最後の移行シナリオでは 33 TB のボリュームを対象に、 27 TiB のデータセットを 1.37 TiB の空きがあるサイズの小さいプライマリ層に移行します。ただし今回は AWS DataSync タスクの帯域幅スロットルを 100 MiBs に設定しました。プライマリ層の容量を監視すると、帯域幅スロットルによって階層化ポリシーが受信する書き込みに追従し、プライマリ層の 80% を消費するのを回避できていることがわかります。

図 3: 帯域幅が制限されつつ、割り当てた容量に収まらないデータを移行した時の、 FSx for ONTAPファイルシステムのプライマリ層の使用状況

AWS DataSync の帯域幅制限の設定は、進行中のタスクの実行中に動的に変更することができます。これにより FSx for ONTAP がキャパシティプール層に書き込む速度に基づいてスロットルを調整する機能が提供されます。図 3 ではプライマリ層の使用量の変動が大きい時期があることがわかります。その期間に AWS DataSync タスク実行の帯域幅制限を 200 MiB/s に変更しました。その後、移行の残りの期間、帯域幅制限は 100 MiB に戻されました。 FSx for ONTAP は詳細なメトリクスを提供しているため、帯域幅制限の設定を調節するために移行中の一定期間におけるキャパシティプール層への書き込みを計算することができます。

まとめ

この記事では FSx for ONTAP ファイルシステムにおけるプライマリ層とキャパシティプール層の違い、ボリューム階層化ポリシーがプライマリ層に与える影響の違いについて、データ移行を計画し、プライマリ層の利用可能な容量を考慮する際の注意点についてお話しました。

次に AWS DataSync を使って FSx for ONTAP に移行する例として、移行されるデータセットが利用可能なプライマリ層より少ない場合と、移行がプライマリ層全体を消費する場合のシナリオを説明しました。また、帯域幅の調整とボリューム階層化ポリシーの設定により、プライマリ層の消費とキャパシティプール層のバランスを取る方法を紹介しました。

これらの手法を使用することで、通常運用に十分な容量をプライマリ層に維持しながらデータ移行を完了し、主要ワークロードのダウンタイムや中断を最小限に抑えることができます。

AWS DataSync を使用して、 FSx for ONTAP への移行を今すぐ開始しましょう。

翻訳はネットアップ合同会社の榎本様、監修はソリューションアーキテクトの長田が担当しました。