Amazon Web Services ブログ
Amazon FSx for NetApp ONTAP でアップストリームのワークロードを強化する
この記事は Tom McDonald によって執筆された内容を日本語化したものです。原文はこちらを参照して下さい。
アップストリーム・エネルギー事業における地質学および地球物理学 ( G&G ) のワークロードでは、貯留層シミュレーション、地下構造解析、坑井の掘削・仕上げなどのさまざまなワークフローがあります。これらのワークフローには多様なパフォーマンスとクライアントの要件があるため、企業はさまざまなプロトコルに対応する複数のソリューションにデータをコピーするという運用上の大きな負担に直面することがよくあります。彼らは最近まで、Windows と Linux のどちらからでも同じファイルに同時にアクセスできるマルチプロトコルアクセスを実現するために、独自のソリューションを開発するという課題に直面していました。このプロセスには時間がかかるだけでなく、複雑さとメンテナンスのオーバーヘッドも増えていました。
現在、企業は Amazon FSx for NetApp ONTAP ( FSx for ONTAP ) を利用することができるようになりました。このフルマネージドサービスは、マルチプロトコルアクセスのためのシームレスなソリューションを提供します。これにより企業は複雑なインフラストラクチャを管理する代わりに、コアビジネスの活動に集中することができます。
この記事ではフルマネージドサービスとしての FSx for ONTAP を検証し、さらに利用可能な機能について説明します。その中には高度なパフォーマンス技術やアクティブ・モニタリング手法も含まれます。これらの側面を探ることで、読者は FSx for ONTAP の潜在能力を最大限に活用するための深い知見を得ることができるでしょう。
ソリューション概要
図 1 に示すように、Amazon Elastic Compute Cloud ( Amazon EC2 ) のネットワーク接続型ストレージ ( NAS ) インスタンスは、企業が AWS への移行を開始する際に定番な構成で利用されています。AWS Well Architected Framework には「運用上の優秀性」と「信頼性」の 2 つの柱があります。EC2 を NAS インスタンスとして構成する場合、インスタンスにパッチを適用し、フェイルオーバーが必要な場合に回復力を持つように複数のインスタンスを構築し、サービスを自己管理しなければなりません。これらすべてが運用上のオーバーヘッドとなります。
図 1 : EC2 を NAS インスタンスとして実行する際の構成
図 2 に示すように、FSx for ONTAP はマルチプロトコルアクセスを実現するフルマネージドなファイルシステムを提供します。個々のインスタンスのプロビジョニング、フェイルオーバー出来るような設計、アップグレードの管理などは不要です。NetApp ONTAP は、数十年にわたりアップストリーム・エネルギー事業で利用されてきました。データは FSx for ONTAP ファイルシステム内のアクティブファイルサーバとスタンバイファイルサーバ間で、自動的にミラーリングされます。このソリューションはシングルアベイラビリティーゾーン ( Single-AZ ) 構成で、2 台のファイルサーバをアクティブ – スタンバイ構成にすることで、データアクセスの可用性を高めます。
図 2 : シングルアベイラビリティーゾーンの設計
Single-AZ ソリューションの配置だけではなく、図 3 に示すようなマルチアベイラビリティーゾーン ( Multi-AZ ) ファイルシステムも利用でき、AZ を跨いだ耐障害性を実現できます。SnapMirror やSnapVault などの従来の ONTAP テクノロジは、さらに災害復旧要件や事業継続要件に利用できます。監視用の Amazon CloudWatch や Amazon CloudTrail に加え、BlueXP や NAbox など、NetApp エコシステムのツールも利用でき、FSx for ONTAP ファイルシステムの優れた運用性とテレメトリーデータを活用できます。
FSx for ONTAP のサービスは、さまざまなスループットと IOPS 構成で利用できます。FSx for ONTAP は個々のプロジェクトに使用することも可能で、企業は必要な分だけ料金を支払うこともできますし、永続的なファイルシステムとして利用することもできます。
図 3 : マルチアベイラビリティーゾーンの設計
FSx for ONTAP をアップストリームのワークロードに最適化する
アップストリームのワークロードの I/O パターンは多くの場合、同時実行処理は少なくシーケンシャルな読み取りで構成されます。このようなワークロードのために、FSx for ONTAP ソリューションには読み取りを高速化する NVMe リードキャッシュが用意されています。NVMe リードキャッシュに加えて、利用者は FlexGroup を作成することができます。
FlexGroup の作成
FlexGroup は、コンスティチュエントボリュームから構成されるボリュームです。ONTAP 側で自動負荷分散とスケーラビリティが提供され、いくつかのワークロードに効果をもたらします。FlexGroup の利点の 1 つは、通常の FlexVol よりもはるかに大きく拡張し、より多くのファイルを格納できることです。 標準の FlexVol には 100 TB の制限がありますが、FlexGroup には実質的に制限がありません ( NetApp は最大 20 PB を推奨しています ):
FSxId0::> vol create -vserver svm0 -volume flexg -aggr-list aggr1 -size 400T
Notice: The FlexGroup volume "flexg" will be created with the following number of constituents of size 100TB: 4.
Do you want to continue? {y|n}: y
上記の例では、ONTAP は 4 つの 100 TB コンスティチュエントボリュームから FlexGroup を作成します。4 つのコンスティチュエントボリュームは ONTAP のデフォルトで、ワークロード要件に基づいて調整することができます。
Flexible IO Tester ( FIO ) は、ストレージ・ソリューションを検証し定義するための一般的なツールです。Linux と Windows オペレーティングシステム用のクライアントがあります。FlexGroup の利点を調べるために、筆者はスループットが 512 MB/s のファイルシステムを作成しました。次の図では 1 行につき 8 回 FIO を実行して平均しています。FG/VOL および NFS バージョンの列は、それぞれさまざまなボリュームタイプとプロトコルのバージョンを示しています。
G&G のワークロードでは、アプリケーションは様々なブロックサイズと多数のクライアントを持つことになります。さらにほとんどの ISV アプリケーションは、NFS の nconnect のような新しい機能を制限する古いオペレーティングシステムを今でも使用しています。どのワークロードにも微妙な違いがあり、アプリケーションとそれをサポートするオペレーティングシステムに基づいてバリエーションを特定する必要があります。図 4 では、64 KB ブロックの一般的なワークロードサイズで、単一クライアントからランダム I/O とシーケンシャル I/O の両方を実行し、これらの違いを示しています。混合ワークロードの場合、読み取りの割合は 70 ％、同時書き込みの割合は 30 ％ であると想定します。次の表は、FlexGroup の影響、nconnect が助けになるか、プロトコルのバージョンによってさまざまなオーバーヘッドが発生する、などを示しています。
図 4 : FlexGroup の比較表
FSx のバックアップ機能や AWS Backup だけではなく、SnapMirror などの他の技術を使用することでもバックアップとディザスタリカバリのソリューションを実現できます。
解釈アプリケーションのパフォーマンスのための SMB 専用最適化
Windows 上の多くの地下探査アプリケーションは、 解釈、分析、可視化のために大量のデータを読み書きします。いくつかのチューニングを検討するために、2 GB/sec のスループットとデフォルトの SSD IOPS を持つ FSx for ONTAP から g4ad.4xlarge インスタンスへ、 SEGY データを Robocopy で読み取ることから始めます。g4ad.4xlarge は最大 10 Gb のネットワーキングを提供し、以下のチャートに見られるようなバースト機能があります。その後、I/O の方向に意味があるかを検証するために SEGY と Robocopy での書き込みを続けました。
ここで筆者が検討した 2 つのオプションは、FSx for ONTAP 側の SMB Maximum Transition Unit ( MTU ) 設定 ( デフォルトでは Large MTU が有効 )、そしてクライアント側の帯域幅制限 ( デフォルトではクライアントの観点からも有効 ) です。図 5 に示すように、クライアント側の帯域幅制限が有効でも無効でも、目に見えるパフォーマンス向上はこれらのプロファイルにはありませんでした。
これは特定のデータ型の単純な移動ですが、SMB の MTU サイズの影響についてさらに深掘りするには十分なパフォーマンスの違いが確認されました。
図 5 : SMB 帯域制限の性能比較表
Large MTU は SMB ブロックを最大 1 MB まで転送できるようにする機能で、無効にするとブロックサイズが 64 KB と小さくなります。これはアプリケーション固有の要件であり、組織のニーズに基づいて評価されなければなりません。解釈アプリケーションでは、ファイルサイズが小さいものと大きいものが混在していることが多いですが、データの同時実行性はそれほど高くはありません。SMB の MTU が大きいと、ファイルサイズに関係なくパフォーマンスに影響を与える可能性があります。これらのブロックサイズを調べるために、筆者は 64 KB をブロックサイズとし、I/O 深度が 16、70 % が読み取りで 30 % が書き込みの FIO プロファイルと、それに対応する 1 MB の大きな MTU ブロックサイズのプロファイルを選びました。これはファイルシステムに対して複数のプロセスを実行させるためです。ファイルシステムに負荷が増えると、ブロックサイズに関係なく、シーケンシャルな処理負荷に対しては、Large MTU を無効にする方が有利な結果となりました。ランダム I/O については結果はまちまちでした。結果を図 6 に示します。
結果を視覚化するために大きなファイルをメモリにストリーミングするこれらのアプリケーションでは、SMB の Large MTU を無効にした場合のパフォーマンス結果をアプリケーションと環境で検証して、さらなるパフォーマンス向上を目指す価値があります。
図 6 : SMB の Large MTU 性能比較表
SMB の Large MTU を無効にするコマンド
Large MTU を無効にするには以下の手順に従ってください :
1. アドバンスモードに入る :
FSxId::> set -privilege advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y
2. 既定値が true に設定されていることを確認する :
FSxId::*> cifs options show -vserver svm0 -fields is-large-mtu-enabled vserver is-large-mtu-enabled ------- -------------------- svm0 true
3. Large MTU を false に設定する :
FSxId::*> cifs options modify -vserver svm0 -is-large-mtu-enabled false
4. Large MTU が false に設定されていることを確認する :
FSxId::*> cifs options show -vserver svm0 -fields is-large-mtu-enabled vserver is-large-mtu-enabled ------- -------------------- svm0 false
変更を有効にするには、Windows ホスト上の SMB 共有を切断し再接続する必要があります。
アクティブ監視
アクティブ監視とは、ワークロードを実行し、ワークロードのリアルタイム統計を監視することです。これはファイルシステムで何が発生しているかをすぐに把握するためによく使用されます。quality of service (QoS) はストレージオブジェクトを制限する技術ですが、FSx for ONTAP の qos statistics コマンド にはボリュームのパフォーマンス監視も含んでいます。以下の QoS コマンドは、vsadmin SVM アカウントではなく fsxadmin ファイルシステム管理者アカウントでのみ利用可能になっています。これはファイルシステムレベルで実行されますので注意してください。
FSxId::> qos statistics workload latency show
statistics コマンドはアクティブなベンチマークやレイテンシーの確認に非常に有効で、ネットワーク、データ、ディスクなどの情報が表示されます ( 図 7 の例の様に見えます )。これはレイテンシーの問題を特定するのに役立ちます。さらに、そのデータを時系列データベースに送ってグラフ化することも可能です。
図 7 : qos statics workload latency コマンドの出力例
リフレッシュ表示を有効化 :
FSxId::> qos statistics workload latency show -refresh-display true
スループットとアグリゲートのレイテンシーについては、以下のコマンドで図 8 のような結果が得られる :
FSxId::> qos statistics workload performance show
図 8 : qos statistics workload performance コマンドの出力例
IOPS、スループット、およびレイテンシーはすべて、全体的なパフォーマンスを把握するために必要です。IOPS は 1 秒あたりの入出力操作で、アプリケーションによって同時に処理されたものです。スループットは 1 秒間に転送されるバイト数のことで、IOPS にブロックサイズをかけたものです。レイテンシーはリクエストを処理するのにかかる時間のことで、サービスに関連するキャッシュやインフラストラクチャの影響を受け、IOPS の数に直接影響します。パフォーマンスのボトルネックを調査する際には、これらすべてを深く掘り下げることが重要なポイントです。
SVM レベルの権限は、自由に使えるコマンドの数がより制限されます ( SVM は分離された仮想ファイルサーバーであるため、これは各 SVM がファイルシステム全体にアクセスを制限するために行われます ）。利用可能なコマンドには statistics コマンドがあります。SVM 管理者アカウントから計測できるパフォーマンス統計は以下のように記録されています。このコマンドでは、 -iterations ( 報告させたい統計の回数 ) と -interval ( 報告が表示されるまでの時間 ) を指定します。
svm0::> statistics volume show -iterations 10 -interval 5
svm0 : 10/25/2022 14:52:35
*Total Read Write Other Read Write Latency
Volume Vserver Ops Ops Ops Ops (Bps) (Bps) (us)
------ ------- ------ ---- ----- ----- -------- ----- -------
vol5 svm0 1575 1575 0 0 95835136 0 524
vol7 svm0 1545 1545 0 0 93981696 0 518
vol8 svm0 1516 1516 0 0 92125184 0 543
vol1 svm0 1506 1506 0 0 91600896 0 548
vol6 svm0 1487 1487 0 0 90232832 0 485
vol4 svm0 1435 1435 0 0 87359488 0 546
vol2 svm0 1412 1412 0 0 85709824 0 512
vol3 svm0 1353 1353 0 0 82245632 0 514
svm0_root
svm0 0 0 0 0 0 0 0
NetApp Harvest
CloudWatch は高レベルのメトリクスを提供しますが、ONTAP Command Line Interface で示した、より深いパフォーマンスのメトリクスは CloudWatch では提供されません。しかし、NetApp Harvest や Grafana、NetApp Cloud Insights のようなツールは、より多くのメトリクスを提供することができます。詳細については、FSx for ONTAP ユーザーガイドのファイルシステムのモニタリングのセクションを参照してください。
Harvest と Grafana を使用した FSx for ONTAP ファイルシステムのモニタリング
クリーンアップ
必要以上の AWS コストが発生しないよう、上記の手順を実行した後、Amazon EC2 インスタンスや FSx for ONTAP リソースなど、作成された AWS リソースをすべて削除してください。
まとめ
この記事では、FSx for ONTAP の高度な機能を活用し、既存の Amazon EC2 を NAS として実装するのに対して Amazon FSx for NetApp ONTAP の耐久性と回復力のメリットを紹介しました。FSx for ONTAP のマルチプロトコル機能、豊富なツールセット、マネージドサービスの簡素化とともに、FSx for ONTAP は既存のアプリケーションとワークロードを AWS で問題なく実行できるようになります。
アップストリーム、ミッドストリーム、ダウンストリームのワークロードにはマルチプロトコルの要件があり ( フルマネージドサービスならなお良い )、AWS と FSx for ONTAP ではこの機能をすぐに利用できます。特定の SMB ワークロードのための FlexGroup と SMB チューニングを使用するテクニックも紹介しました。Command Line Interface と NetApp エコシステムによるモニタリング手法により、信頼性の高いテレメトリーデータを得ることができます。FSx for ONTAP は、ワークロードに最適なパフォーマンスを提供するように高度なチューニングが可能です。
Amazon FSx for NetApp ONTAP は、ほとんどの AWS リージョンでご利用いただけます。コメントや質問がありましたら、お気軽にコメント欄にご記入ください。
翻訳はネットアップ合同会社の方様、監修はソリューションアーキテクトの長田が担当しました。