Amazon FSx for NetApp ONTAPのパフォーマンスチューニング要素をまとめてみた #cm_odyssey #devio2024

DevelopersIO 2024の登壇資料です。
https://event.classmethod.jp/odyssey-offline

Transcript

1. Amazon FSx for NetApp ONTAPの パフォーマンスチューニング要素を まとめてみた 2024.7.20 AWS事業本部 のんピ
2. Xへの投稿の際は、 ハッシュタグ #devio2024 でお願いいたします。 2 お願い
3. ⾃⼰紹介 { "本名": "⼭本 涼太 (覚えなくていいです)", "部署": "AWS事業本部 コンサルティング部", "前職": "インフラエンジニア in データセンター", "興味のあること": "⾯⽩そうなブログネタ探し", "好きなAWSサービス": [ "Amazon FSx for NetApp ONTAP (FSxN)", "AWS Transit Gateway", "AWS Step Functions", "AWS CDK" ], "称号" : [ "2024 Japan AWS Ambassador", "NetApp FY 24 Advanced Solution Leading Award" ] } 3
4. パフォーマンスが思ったよりも 出ないという経験ありますか? 4
5. よくあるシチュエーション • 構築PJの負荷テスト中に発覚 • 運⽤時に利⽤者からクレームが • ⽉次バッチ処理を流しても処理が終わらない 5
6. もちろん 私はあります 6
7. トラブル時の困りごと 単純なシステムでもボトルネックの把握が⼤変 7
8. どんなシステムも ストレージはありますよね 8
9. ということで FSxNにおける パフォーマンスチューニング について語ります 9
10. ⽬次 • なぜパフォーマンスチューニングは重要か • パフォーマンスチューニングのステップ • Amazon FSx for NetApp ONTAP(FSxN)とは • シチュエーションで考えるFSxNの パフォーマンスチューニング 10
11. 話さないこと • クライアント側やミドルウェア側での パフォーマンスチューニング • オンプレミスネットワークのチューニング • TCPやNFS、SMBなどのプロトコルの話 11
12. なぜパフォーマンス チューニングは重要? 12
13. それを理解するためには なぜパフォーマンスが重要かを理解する 13
14. 仮に パフォーマンスが⼗分に出ない場合を考える 14
15. パフォーマンスが出ない場合 15 ユーザー離脱 遅いレスポンスによりユーザーが 不満を感じ、サービスの利用を中止する 機会損失の発生 システムの遅延、場合によって中断によ り収益が減少する コスト増加 非効率な処理によりリソースが過剰に消 費され、コストが上昇する 競争力の低下 他社より劣るパフォーマンスにより 競争力が低下し、市場シェアを失う
16. パフォーマンスが出れば 16 ユーザー満足度向上 継続してサービスを使い続けてくれる ビジネス機会拡大 システムの高速化により、より多くの取引 や顧客対応が可能となり、収益が増加す る コスト削減 効率的な処理により金銭的コスト、 運用コストが削減できる 競争力の増加 市場での評価が高まり、新規顧客の 獲得につながる
17. 本番リリース前に負荷テストをしましょう 17
18. ポイント 最⼩限の投資で 最⼤限の成果を出す 18
19. 注意 「最⼩限の投資」は 「運⽤コスト」や「設計コスト」などの 「⼈的コスト」も鑑みる ↓ 財布で解決した⽅がコスパが良いことも 19
20. 要するに 細かいパラメーターを変更するだけが パフォーマンスチューニングではない 20
21. パフォーマンスチューニングで 具体的に何をチューニングする? 21
22. パフォーマンスチューニングでは パフォーマンス低下に影響を与えている 要素の除去/改善/最適化をする 22
23. よろしくない極端な例 [現状] • サーバーのNICが10Gbps • サーバーに接続にしているスイッチのポートは1Gbps [要望] • 25Gbpsで通信したい [対応] • サーバーのNICだけを100Gbpsに増強する [結果] • 論理最⼤転送速度は1Gbpsのまま 23
24. つまり ボトルネックを正確に把握しなければ 「最⼩限の投資で最⼤限の成果を出す」 ができない 24
25. そのために何をするか 計測と環境情報の整理 25
26. 計測⽅法 26 SNMP / NetFlow / sFlow ネットワーク機器 パフォーマンスモニター Wireshark / tcpdump traceroute / tracert iperf クライアント CloudWatch AWS ONTAP CLI / ONTAP REST API NetApp BlueXP FSxN
27. パフォーマンスチューニングサイクル 27 ワークロードの⽤途と ⽬的、要件の把握 発⽣事象と計測結果、 環境情報の整理 問題の切り分けと 原因の特定 改善策の⽴案 改善策の実施 評価
28. 改善策⽴案の注意点 改善策の影響範囲を理解し、前提条件を満たすこと 28
29. FSxNとは 29
30. FSxNとは NetApp ONTAP をベースにした、AWSが提供するフルマネージド型ユニファイド ストレージサービス フルマネージド型ファイルストレージサービス「Amazon FSx」のラインナップ の⼀つ 30 汎用ファイルストレージ （NFS） HPC向けファイルストレージ （Lustre） 汎用ファイルストレージ （SMB） 汎用ファイルストレージ （SMB, NFS） ブロックストレージ （iSCSI） 高速・低コスト ファイルストレージ （NFS） Amazon Elastic File System (Amazon EFS) Amazon FSxfor Lustre Amazon FSx for Windows File Server Amazon FSx for NetApp ONTAP Amazon FSx for OpenZFS ご参考 : Amazon FSx ファイルシステムの選択のサポート | Amazon Web Services (https://aws.amazon.com/jp/fsx/when-to-choose-fsx/)
31. FSxNの特徴的な機能 • マルチプロトコル対応 ◦ NFS / SMB / iSCSI • データ保護 ◦ データレプリケーション(SnapMirror / SnapVault) ◦ スナップショット(Snapshot) • ストレージ利⽤効率の最適化 ◦ 重複排除 / データ圧縮 / データコンパクション / シンプロビジョニング • セキュリティ ◦ 保管時と転送時の暗号化 ◦ アンチマルウェアソフトやNetApp製品との統合 ◦ Active DirectoryによるIDベース認証 • ストレージ容量：事実上無制限 ◦ プライマリストレージ(ホットデータ⽤) : 最⼤192TB (Single-AZ 1HAペアの場合) ◦ キャパシティプールストレージ(コールドデータ⽤) : 容量上限なし 31
32. FSxNの中⾝ 32
33. FSxNにおける物理的な世界 33 抜粋 : https://docs.aws.amazon.com/ja_jp/fsx/latest/ONTAPGuide/performance.html
34. データ保存周りの論理構成要素 34 • ファイルシステム • aggregate ◦ スケールアップFSxNファイルシステムにおいては1:1 ◦ スケールアウトFSxNファイルシステムにおいては1:n • SVM • ボリューム • qtree ※ RAIDグループはFSxNから認識できないので省略
35. スケールアップファイルシステム 35
36. パフォーマンスチューニングを シチュエーションで考える 36
37. オンプレミスから接続する場合 37
38. ポイントまとめ 38
39. ポイント (メトリクスから判断) 39 No 説明 対応 備考 1 CPUに余裕があるか - スループットキャパシティの増強 - Storage Efficiency/Snapshot/SnapMirrorの 実⾏タイミングの⾒直し - QoS - ダイレクトにコストに影響する - 変更時はフェイルオーバーが発⽣する - 何にCPUパワーを割いているかはONTAP CLIから確認可能 - CPU負荷が⾼いとStorage EfficiencyやTieringがかかりにくくなる 2 - ネットワークのスループットとIOPSに余裕があるか - スループットのバーストクレジットを使い切っているか - スループットキャパシティの増強 - QoS - クライアントのアクセス先をSnapMirror転送先に変更 - スループットキャパシティ変更はダイレクトにコストに影響する - スループットキャパシティ変更時はフェイルオーバーが発⽣する - アクセス先をSnapMirror先に向けうるのはReadのみ 3 - SSDのスループットとIOPSに余裕があるか - IOPSとスループットのバーストクレジットを使い切っているか - スループットキャパシティの増強 - SSD IOPSの増強 - Storage Efficiencyの実⾏タイミングの⾒直し - QoS - クライアントのアクセス先をSnapMirror転送先に変更 - スループットキャパシティとSSD IOPSの変更はダイレクトにコス トに影響する - スループットキャパシティ変更時はフェイルオーバーが発⽣する - アクセス先をSnapMirror先に向けうるのはReadのみ 4 特定ボリュームにアクセスが偏っていないか - 複数ボリュームへの分散 - FlexGroupの利⽤ - 単純なボリューム分散をする場合、クライアントにてアクセス先の パス変更が必要 - FlexGroupの制約事項に注意 5 キャパシティプールストレージへのアクセス頻度は妥当か Tiering Policyの⾒直し SSDの使⽤量が増加する 6 キャッシュヒット率は妥当か - スループットキャパシティの増強 - Multi-AZへの変更 - ダイレクトにコストに影響する - スループットキャパシティ変更時はフェイルオーバーが発⽣する - Single-AZ <-> Multi-AZの直接の変更は不可 7 Transit GatewayやSite-to-Site VPNの使⽤帯域に余裕はあるか - ネットワーク経路を他ワークロードと分離 - Site-to-Site VPN ECMPの利⽤ - FlexCacheの利⽤ - ネットワーク切り替えコストは⾼いことを念頭に⼊れる - 各サービスの帯域上限は以下 - Transit Gateway : 100Gbps - Site-to-Site VPN : 1.25Gbps/トンネル
40. ポイント (FSxNの設定) 40 No 説明 対応 備考 8 SMB/NFSの暗号化を使⽤しているか 暗号化の無効化 - ポリシー的に認められるのかは要確認 - ONTAPではデフォルト無効化 - SMBにおいては暗号化によるパフォーマンス影響度合いはSMBバー ジョンおよびONTAPバージョンによって異なる - Nitroベースの暗号化はパフォーマンスに影響を与えない 9 SMB Large MTUが使われているか SMB Large MTUの有効化 - SMB ブロックを最⼤1MB まで転送できるようにする機能 - クライアント側でも有効化する必要がある - macOSの場合はパフォーマンスが低下することもある - macOSの場合はOSによってはMax Credits to Grant (SMBの未処理 同時操作最⼤数)も調整する必要がある 10 NFSの TCP 最⼤転送サイズが適切か NFSのTCP最⼤転送サイズの調整 - クライアント側でも設定が必要 - 1MBが⽬安 11 LIFのMTUが⼩さくなっていないか LIFのMTUをクライアントとのパスのMTUに調整 クライアントや途中のネットワーク機器のMTUが⼩さい場合は効果 を発揮できない 例) Site-to-Site VPN は 1,446固定 12 Storage Efficiencyは有効化されているか Storage Efficiencyを有効化する - 多くのワークロードでノードとストレージとの転送量が減るためパ フォーマンスが改善される - 逆にパフォーマンスが悪くなることも考えられるため要検証 13 圧縮タイミングとアルゴリズムは適切か - Inactive data compressionを無効化する - Inactive data compressionの閾値を調整する - lzopro から zstd に変更する - Tieringのcooling daysとInactive data compressionの閾値が近い のであれば無理に実⾏する必要はない - Inactive data compressionを⾏わないことによってSSD使⽤量増加 が予想される - 既存の圧縮済みブロックを再圧縮するには⼀度解凍する必要がある
41. ポイント (ネットワーク) 41 No 説明 対応 備考 14 レイテンシーは⼗分に低いか - Accelerated Site-to-Site VPNの利⽤ - Direct Connectの利⽤ - FlexCacheの利⽤ - 別リージョンに⽴てる - いずれも変更にはランニング/イニシャルコストに影響がある - 同⼀VPCでもAZが異なる場合はAZを揃えることを検討 15 回線帯域は⼗分か 回線の増強 - 回線切り替え時にダウンタイムがある可能性がある 16 ネットワーク機器がサポートしているトラフィック上限には余裕がある か - ネットワーク機器の増強 - LAGの設定 - 機器切り替え時にダウンタイムがある可能性がある
42. ポイント (クライアント) 42 No 説明 対応 備考 17 クライアントのスペックに余裕はあるか - クライアントマシンの増強 - クライアント上で他に動作している⾼負荷なアプリケー ションの⾒直し 18 NFS/SMBのTCPマルチコネクション機能を活⽤しているか - NFS nConnectを使⽤する - SMBマルチチャネルを使⽤する - 複数のTCPコネクションを使うことでパフォーマンス改善が⾒込ま れる - NFSv4.1のnConnect はFSxN側ではデフォルト有効化されている - SMB 3.0ではデフォルト無効化されている - NFS/SMBどちらもクライアント側で設定が必要 19 iSCSIのマルチパスIOを使⽤しているか マルチパスIO(MPIO)を使⽤して接続する - MPIOを使⽤することで異なるiSCSIパスで負荷分散できる - ALUAはデフォルトで有効化されている 20 ⼀部のクライアントからのアクセスが⽀配的か - QoSをかける - 処理時間帯をズラすことができるのであればズラす - ファイルに対してもQoSをかけることも可能 21 iSCSIを使⽤しているか 第⼆世代ファイルシステムに切り替えNVMe-over-TCPを使 ⽤する - iSCSIよりも低レイテンシーで接続可能 - クライアント側でもNVMe-over-TCPをサポートする必要がある 22 ⼤量のファイルやディレクトリの操作をしているか - ファイルやディレクトリを圧縮した上で操作する - FlexCacheを使⽤する - クライアントをAWS上に⽤意する - ファイルやディレクトリを⼤量に転送する場合は、メタデータや ファイルロックのオーバーヘッドやレイテンシーの影響を受けやす い 23 SMB署名が有効化されているか SMB署名を無効化する - ポリシー的に認められるのかは要確認 - 暗号化によるパフォーマンス影響度合いはSMBバージョンおよび ONTAPバージョンによって異なる
43. ONTAPの細かいチューニングはKBを 43 https://kb-ja.netapp.com/on-prem/ontap/Perf/Perf-KBs/ONTAP_9_Performance_Resolution_Guide# https://kb-ja.netapp.com/on-prem/ontap/Perf/Perf-KBs/ONTAP_9_Performance_Resolution_Guide#
44. みなさん 多いな！ と思いませんでしたか? 44
45. では、どこから着⼿するか 確認する際はインフラ側から (≠ 設定変更はインフラ側から) 45
46. 対応⽅法の詳細をいくつか紹介 46
47. その前に 「頻度」と「意図した使い⽅なのか」をチェックしよう • ⼀時的なのか ◦ 初期移⾏で⼤量のトラフィックを流している ◦ Storage Efficiency / Inactive data compressionでフルスキャンをかけて いる • 周期的なイベントなのか ◦ 毎⽇夜間に分析バッチ処理が⾛る ◦ 週次でアンチマルウェアソフトのスキャンをかけている • 恒常的なのか ◦ オンラインバッチが常時動作している 47
48. 変更したあとは 事象が解消されたか都度チェック 48
49. スループットキャパシティの 変更 49
50. Single-AZの場合 50 抜粋 : https://docs.aws.amazon.com/ja_jp/fsx/latest/ONTAPGuide/performance.html#impact-throughput-cap-performance
51. Multi-AZの場合 51 抜粋 : https://docs.aws.amazon.com/ja_jp/fsx/latest/ONTAPGuide/performance.html#impact-throughput-cap-performance
52. Multi-AZの⽅がキャッシュ量が多い 52 引用 : https://docs.aws.amazon.com/ja_jp/fsx/latest/ONTAPGuide/performance.html#impact-throughput-cap-performance
53. 第⼆世代ファイルシステムでは 53 スケールアウトファイルシステムが 使⽤できる
54. 何がスケールアウト? HAペアが スケールアウト 54 引用 : https://docs.netapp.com/us-en/ontap/concepts/high-availability-pairs-concept.html
55. HAペア単位でスケールアウト 55
56. 簡単にWriteで1GiBps以上出せる 56
57. 詳細はこちらの記事から 57
58. どの⽤途によるCPU負荷かは 58 qos statistics workload resource cpu show -node <ノード名>で確認可能 ボリュームへのアクセスはもちろん WAFLのスキャンなどのバックグラ ウンドワークロードも表⽰される
59. qos statisticsのワークロード名 59 抜粋 : https://kb-ja.netapp.com/on-prem/ontap/Perf/Perf-KBs/What_are_some_internal_ONTAP_workloads_in_qos_statistics_commands#
60. ボリューム分割/FlexGroup採⽤ 60
61. メタデータアクセスはシングルコア ボリューム内のメタデータアクセスはシングルコアで動作 1ボリュームにデータを詰め込むとパフォーマンスが出ないことも 61 引用 : https://kb-ja.netapp.com/on-prem/ontap/Perf/Perf-KBs/Lower_than_expected_performance_while_utilizing_a_single_volume
62. FlexGroupとは 1つのボリュームで⼤きな空間を扱うためのONTAPの機能 Constituent volumesと呼ばれる複数のボリュームを束ねる 62 抜粋 : https://docs.netapp.com/ja-jp/ontap/flexgroup/definition-concept.html
63. FlexGroupにすることで CPUのスレッド利⽤率を最⼤化することができる 63 抜粋 : TR-4571 NetApp ONTAP FlexGroup volumes Best practices and implementation guide
64. FlexGroupの注意点は以下記事に 64
65. WAFLの並列処理の仕組みについては 65 抜粋 : https://www.usenix.org/conference/osdi16/technical-sessions/presentation/curtis-maury
66. FabricPoolのTiering Policyの⾒ 直し 66
67. NetApp ONTAPのストレージ階層化機能 FabricPoolとは 67 プライマリストレージ • SSD • 性能に最適化 • 容量は 1〜192TB (Single-AZ 1HAペア) キャパシティプールストレージ • オブジェクトストレージで比較的低速 • プライマリストレージと比較して安価 • 実質容量制限なし(PBクラス)
68. Tiering Policyの種類 Tiering Policyによって階層化 68 ポリシー名 挙動 Auto アクセス頻度の低いデータブロックを階層化 2〜183日で設定 Snapshot-only Snapshotのデータブロックを階層化 2〜183日で設定 All メタデータを除く全てのデータブロックを階層化 None 階層化をしない アクセス頻度と求める性能に応じて適切なものを
69. Storage Efficiencyの有効化 69
70. Storage Efficiencyとは 70
71. Storage Efficiency (TSSE) の流れ 71
72. データ削減によって 72
73. FlexCacheの導⼊ 73
74. FlexCacheとは ボリュームのデータをキャッシュさせる機能 74 抜粋 : https://aws.amazon.com/jp/blogs/news/caching-data-using-amazon-fsx-for-netapp-ontap/
75. コミックス‧ウェーブ‧フィルムさんの事例 数KB〜数GB混在する数千万規模のファイル環境をキャッシュ する数1,000規模のファイル 75 抜粋 : https://www.netapp.com/ja/pdf.html?item=/ja/media/82316-230220a_web.pdf
76. まとめ 76
77. まとめ • 最⼩限の投資で最⼤限の成果を出す ◦ ボトルネックを正確に把握する ◦ 改善策の影響範囲を理解し、満たすべき 前提条件を満たせられるか注意する ◦ 細かいパラメーターを変更するだけが パフォーマンスチューニングではない 77