[Amazon FSx for NetApp ONTAP] スループットキャパシティがボリュームバックアップ速度に影響を与えるのか確認してみた
リストア速度は圧倒的な差は感じなかったが、バックアップ速度はどうだろう
こんにちは、のんピ(@non____97)です。
皆さんはAmazon FSx for NetApp ONTAP(以降FSxN)ファイルシステムに設定したスループットキャパシティがバックアップ速度に影響があるのか気になったことはありますか? 私はあります。
以下記事でリストア速度に圧倒的な差はないことを確認しました。
では、バックアップ速度はどうでしょうか。
上述の記事では800GiBのデータを含むボリュームの初回バックアップにかかった時間が26分であることを紹介しました。速度で表現すると525MBpsです。
実際に他のスループットキャパシティでもバックアップをしてみて、どのぐらい速度に影響がるのか確認してみました。
いきなりまとめ
-
検証した限り、スループットキャパシティを増強すると、バックアップ対象のデータ転送速度がその分改善される
スループットキャパシティ バックアップ実行時間 バックアップ実行開始から完了までの速度 データ転送速度 128MBps 1時間26分 159MiBps 200MiBps 256MBps 46分 297MiBps 400MiBps 512MBps 27分 506MiBps 800MiBps -
初回バックアップ時や大きくデータ更新があった場合にはスループットキャパシティを増強しておくのも手
やってみた
スループットキャパシティ128MBpsの場合
まず、スループットキャパシティが128MBpsの場合です。
バックアップ対象のボリュームは上述の記事で用意した800GiBのデータを含むボリュームです。
また、FSxNのボリュームバックアップは差分バックアップです。
すべての Amazon FSxバックアップ (自動日次バックアップとユーザー主導バックアップ) は増分的です。つまり、前回のバックアップが完了した以降のデータにのみ変更が保存されます。これにより、バックアップの作成に必要な時間と、各バックアップで使用されるストレージの量の両方が最小限に抑えられます。増分バックアップは、重複データを保存しないことでストレージコストを最適化します。 ONTAP バックアップFSxの はボリュームごとであり、各バックアップには 1 つの特定のボリュームのデータのみが含まれます。Amazon FSxバックアップは、高い耐久性を実現するために、複数のアベイラビリティーゾーンに冗長的に保存されます。
Amazon FSxバックアップは point-in-time、ボリュームの読み取り専用イメージであるスナップショットを使用して、バックアップ間の増分を維持します。バックアップが作成されるたびに、Amazon はFSxまずボリュームのスナップショットを作成します。バックアップスナップショットはボリュームに格納され、ボリュームのストレージ領域を消費します。FSx 次に、Amazon はこのスナップショットを以前のバックアップスナップショット (存在する場合) と比較し、変更されたデータのみをバックアップにコピーします。
以前のバックアップスナップショットが存在しない場合は、最新のバックアップスナップショットの内容全体がバックアップにコピーされます。最新のバックアップスナップショットが正常に作成されると、Amazon は以前のバックアップスナップショットFSxを削除します。プロセスが繰り返される場合、最新のバックアップに使用されたスナップショットは、次のバックアップが作成されるまで、ボリュームに残ります。バックアップストレージコストを最適化するには、ONTAP は、ボリュームのストレージ効率の節約をバックアップに保持します。
バックアップを削除すると、そのバックアップに固有のデータのみが削除されます。各 Amazon FSxバックアップには、バックアップから新しいボリュームを作成し、ボリュームのスナップショットを効果的に復元 point-in-timeするために必要なすべての情報が含まれています。
バックアップジョブを実行する前にバックアップ対象のボリュームの全てのボリュームバックアップを削除しておきます。
全てのボリュームバックアップの削除が完了したら、AWS Backupからオンデマンドバックアップジョブを実行します。
バックアップは1時間26分で完了しました。バックアップ速度は単純計算で、159MiBpsです。
バックアップはAWS Backupのコンソールからだけでなく、FSxのコンソールからでも確認できます。
バックアップ実行時のFSxNファイルシステムのByte関連のメトリクスを確認します。
NetworkSentBytes
、NetworkReceivedBytes
、CapacityPoolReadBytes
が跳ねていることが分かります。つまり、キャパシティプールストレージの読み込んで転送しているということですね。
FSxNファイルシステムのパフォーマンス
のメトリクスは以下のとおりです。
ネットワークスループットとCPU使用率がバックアップ実行中は張り付いています。ネットワークスループットに至っては100%を超えていることからバーストしています。
スループットキャパシティ256MBpsの場合
続いて、スループットキャパシティ256MBpsの場合です。
先ほど取得したボリュームバックアップの削除が完了したら、同様にAWS Backupからオンデマンドバックアップジョブを実行します。
バックアップは46分で完了しました。先ほどの約半分ですね。バックアップ速度は単純計算で、297MiBpsです。
バックアップ実行時のFSxNファイルシステムのByte関連のメトリクスを確認します。
跳ねているメトリクスは同じですが、跳ねている量が異なります。128MBpsの場合は12GiBpmから13GiBpm程度でしたが、256MBの場合は22GiBpmから26GiBpmです。ここからもバックアップ速度が倍速になっていることを確認できますね。
FSxNファイルシステムのパフォーマンス
のメトリクスは以下のとおりです。
跳ねているメトリクスは同じですが、跳ねている時間が短いですね。
スループットキャパシティ512MBpsの場合
最後に、スループットキャパシティ512MBpsの場合です。
先ほど取得したボリュームバックアップの削除が完了したら、同様にAWS Backupからオンデマンドバックアップジョブを実行します。
バックアップは27分で完了しました。256MBpsの場合のさらに約半分ですね。バックアップ速度は単純計算で、506MiBpsです。
先述の記事で512MBpsの場合は26分で完了したので、ほとんど誤差ですね。
バックアップ実行時のFSxNファイルシステムのByte関連のメトリクスを確認します。
今回も跳ねているメトリクスは同じですが、跳ねている量が異なります。128MBpsの場合は12GiBpmから13GiBpm程度、256MBの場合は22GiBpmから26GiBpmでしたが、512MBの場合は41GiBpmから50GiBpmです。綺麗にバックアップ速度が倍速になっていることを確認できます。
FSxNファイルシステムのパフォーマンス
のメトリクスは以下のとおりです。
さらにネットワークスループットとCPU使用率が張り付く時間が短くなりました。
スループットキャパシティごとのByteメトリクスとパフォーマンスメトリクスの比較
せっかくなので、スループットキャパシティごとのByteメトリクスとパフォーマンスメトリクスの比較をします。
まずはByte関連のメトリクスです。
綺麗にスループットキャパシティを倍々にすると、転送量も倍々になっていることが分かります。
転送速度をMiBpsと分かりやすくするために[max: ${MAX}, last: ${LAST}] GiB
とMETRICS()/1073741824
になっている箇所を[max: ${MAX}, last: ${LAST}] MiBps
とMETRICS()/1048576/PERIOD(m1)
に変更します。
スループットキャパシティ | 転送速度 |
---|---|
128MBps | 200MiBps |
256MBps | 400MiBps |
512MBps | 800MiBps |
というように綺麗に転送速度が増加していることが分かりますね。
最後にファイルサーバーのパフォーマンスのメトリクスを確認します。
スループットキャパシティを増強する度に、ネットワークスループットとCPU使用率が張り付く時間が半分になっていることが確認できました。
スループットキャパシティはバックアップ速度に大きな影響がある
Amazon FSx for NetApp ONTAPのスループットキャパシティがボリュームバックアップ速度に影響を与えるのか確認してみました。
結論としてはスループットキャパシティはバックアップ速度に大きな影響を与えます。
初回のバックアップや移行などで大量のデータ更新があった際でも、バックアップ取得時間を短くしたい場合はスループットキャパシティを増強すると良さそうです。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!