Amazon FSx for Net App ONTAPにおける 
 ファイルシステム/SVM/ボリューム/qtreeの分割の考え 方を整理してみる 
 クラスメソッド株式会社 のんピ
 1

2 自己紹介 { "本名": "山本 涼太 (覚えなくていいです)", "部署": "AWS事業本部 コンサルティング部", "前職": "インフラエンジニア in データセンター", "興味のあること": "面白そうなブログネタ探し", "好きなAWSサービス": [ "Amazon FSx for NetApp ONTAP (FSxN)" "AWS Transit Gateway", "AWS Step Functions" "AWS CDK" ], "称号" : [ "2023 Japan AWS Ambassador", "NetApp Advanced Solution Leading Award 2023", ] }

3 みなさん気になりませんか? Amazon FSx for NetApp ONTAP (FSxN) の 各リソースの分割単位

4 Amazon FSx for Windows File Server (FSxW) と比較

5 なるほど とりあえず、作るべきリソースが多い

6 FSxNが更に伝えたいようです

7 では どんな時に、どのリソースを 集約/分割すれば良い？

8 というのを以降紹介します

9 先に結論 ● ファイルシステム ○ 物理的にリソースを分けたい、非機能要件が異なる場合 ● SVM ○ ファイルサーバーとしての用途が異なる場合 ● ボリューム ○ 保存データの用途や特徴、非機能要件が異なる場合 ● qtree ○ クォータをかけたいディレクトリが別れている場合

10 FSxNにおけるデータ保存周りの構成要素 ● ファイルシステム ● aggregate ○ スケールアップ FSxNファイルシステムにおいては1:1 ○ スケールアウト FSxNファイルシステムにおいては1:n ● SVM ● ボリューム ● qtree ※ RAIDグループはFSxNから認識できないので省略

11 スケールアップファイルシステムの大体のイメージ FlexGroupでは複数のaggregateに属すことが可能だが詳細は割愛

12 以降赤枠部分について説明 FlexGroupでは複数のaggregateに属すことが可能だが詳細は割愛

13 ファイルシステム概要 ● FSxN 全体のストレージ領域を管理 ● NetApp ONTAPクラスタと同じ ● 論理レイヤーのリソース間で物理リ ソースを共有 ○ 論理レイヤー = aggregate上のリソース 　

14 ファイルシステムの設定項目例 ● Multi-AZ or Single-AZ ● SSDサイズ ● SSD IOPS ● スループットキャパシティ ● ストレージの暗号化キー ● メンテナンスウィンドウ ● 管理パスワード ● ファイルシステムレベルの操作 ○ ジョブスケジューラーなど ● VPC ○ リージョン ○ セキュリティグループ ○ サブネット ○ 関連付けるルートテーブル ○ エンドポイントIPアドレス範囲

15 ファイルシステムの設定項目例 ● Multi-AZ or Single-AZ ● SSDサイズ ● SSD IOPS ● スループットキャパシティ ● ストレージの暗号化キー ● メンテナンスウィンドウ ● 管理パスワード ● ファイルシステムレベルの操作 ○ ジョブスケジューラーなど ● VPC ○ リージョン ○ セキュリティグループ ○ サブネット ○ 関連付けるルートテーブル ○ エンドポイントIPアドレス範囲 共通の設定で困る場合は、ファイルシステムを分ける

16 分割した方が良い具体的なシチュエーション ● コストを最適化するために Single-AZと Multi-AZを使い分けたい場合 ● ノイジーネイバー対策として QoSや クォータを使わずに環境を分離した い場合 ● ファイルシステムの管理を担当部門 で分けたい場合 ○ 主管部門を立てることができない場合 ● ファイルサーバーごとに求められるセ キュリティ要件が異なる場合 ● 異なるリージョンにデータを配置する 必要がある場合 ● セキュリティグループで送信元 IP アドレスを制御したい場合 ● 以下のクォータに到達しそうな場合 ○ SSD IOPS (最大160,000IOPS) ○ SSDサイズ (最大192TiB) ○ スループット (最大4,096MBps) ○ SVM数 (最大24個) ○ ボリューム数 (最大500個) ※ ()内はいずれもスケールアップファイルシステムの場合 ● リソース監視について異なる設定が 必要な場合 ● メンテナンスのタイミングを分けたい 場合

17 SVM概要 ● 仮想ファイルサーバ ● それぞれ独自の管理者資格情報と エンドポイントを持つ ● クライアントからはそれぞれ単一の独 立したサーバとして認識される ● 1つのSVMでNFSサーバーと SMB サーバーを最大一つずつ動作可能 ● 複数のファイルシステムにまたがる SVMの作成はできない ● SVMごとにボリュームを持つ 　

18 SVMの設定項目例 ● SMBファイル共有 ● 参加するドメイン ● NetBIOS名 ● NFSエクスポート ● SMB/NFSの有効バージョン ● Vscan ● ONTAP S3 ● NASアクセスの監査ログ出力 ● ルートボリュームのセキュリティ スタイル ● ローカルユーザー /ローカルグループ ● ユーザーネームマッピング ● SVM管理者の管理パスワード ● ボリュームのデフォルト言語設定 ● QoS ● SnapShotポリシー管理 ● SnapMirrorポリシー管理 ● エクスポートポリシー管理 ● SMB/NFSセッション管理

19 分割した方が良い具体的なシチュエーション ● ファイルサーバーの使用用途が異な る場合 ○ 社員毎のドキュメント管理領域 ○ データ分析 ○ ゲーム開発リポジトリ ○ VDIのユーザープロファイル など ● 開発/検証/本番で環境を分割したい 場合 ● SVMの管理を担当部門で分けたい場 合 ○ 主管部門を立てることができない 場合

20 ボリューム概要 ● ファイルやディレクトリ、 LUNが 格納される独立したデータコンテナ ● ボリュームは複数の SVM、ファイルシ ステムにまたがって配置することは できない 　

21 ボリュームの設定項目例 ● ボリューム名 ● ジャンクションパス ● ボリュームサイズ ● Storage Efficiency ● Tiering Policy ● ボリュームサイズの自動拡張 ● inode数 ● セキュリティスタイル ● FlexCache ● FlexClone ● QoS ● クォータ ● SnapShotポリシー ● SnapMirrorポリシー ● エクスポートポリシー ● SnapLock

22 重要なポイント1. メタデータアクセス ボリューム内のメタデータアクセスはシングルコアで動作 1ボリュームにデータを詰め込むとパフォーマンスが出ないことも 抜粋 : TR-4571 NetApp ONTAP FlexGroup volumes Best practices and implementation guide

23 重要なポイント2. ボリューム内のデータ移動 SnapMirrorで以下の操作はできない ● 複数ボリュームから1つのボリュームにデータを集約 ● 1ボリューム内の一部データを別ボリュームに分離 RoboCopyやDataSyncで転送する必要がある → 重複排除や圧縮が外れる → ボリュームの分割単位は特に慎重になるべき

24 分割した方が良い具体的なシチュエーション ● データの非機能要件が異なる ○ 低頻度アクセスデータの階層化 ○ SnapMirrorの転送間隔 ○ 許可する認証方式とIPアドレス ○ NTFS ACL or NFSv4ACL ● データの重複排除・圧縮の効き具合が 異なる ○ データによってはパフォーマンスが 悪化すること ● データの用途・属性が異なる ○ 監査ログなど

25 qtree概要 ● ボリューム内に作成される特殊な サブディレクトリ ● qtreeごとにクォータやセキュティ スタイルを個別に設定可能 　

26 qtreeとクォータの詳細 自称日本一詳しい記事に 書いています 　

27 qtreeの設定項目例 ● qtree名 (ディレクトリ名 ) ● セキュリティスタイル ● oplock (日和見ロック ) ● エクスポートポリシー ● ACL ● クォータ

28 分割した方が良い具体的なシチュエーション ● ディレクトリごとにクォータをかけたい (かける未来が見える )

29 まとめ ● ファイルシステム ○ 物理的にリソースを分けたい、非機能要件が異なる場合 ● SVM ○ ファイルサーバーとしての用途が異なる場合 ● ボリューム ○ 保存データの用途や特徴、非機能要件が異なる場合 ● qtree ○ クォータをかけたいディレクトリが別れている場合

30