Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Amazon FSx for Net App ONTAPにおけるファイルシステム/SVM/ボリ...
Search
のんピ
June 05, 2024
Technology
2.3k
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Amazon FSx for Net App ONTAPにおけるファイルシステム/SVM/ボリューム/qtreeの分割の考え方を整理してみる #storagejaws
Storage-JAWS #4 の登壇資料です
https://storage-jaws.connpass.com/event/319243/
のんピ
June 05, 2024
More Decks by のんピ
See All by のんピ
AWS Network Firewallの設計/運用の勘所 #NW_JAWS
non97
3
3.5k
コスト最適重視でAurora PostgreSQLのログ分析基盤を作ってみた #jawsug_tokyo
non97
2
2.2k
Aurora PostgreSQLがCloudWatch Logsに 出力するログの課金を削減してみる #jawsdays2025
non97
1
1.5k
VPC間の接続方法を整理してみた #自治体クラウド勉強会
non97
1
2.8k
Amazon FSx for NetApp ONTAPを利用するにあたっての要件整理と設計のポイント
non97
1
1k
Amazon FSx for NetApp ONTAPのパフォーマンスチューニング要素をまとめてみた #cm_odyssey #devio2024
non97
0
1.7k
オンプレミスネットワークとVPCとを接続する際に考慮すべきポイントを考えてみた #自治体クラウド勉強会
non97
1
7.6k
上手く活用すればコスト削減につながる、ONTAPの Temperature Sensitive Storage Efficiency (TSSE) の紹介
non97
0
1.2k
Amazon FSx for NetApp ONTAPへの移行方法を整理してみた
non97
0
2.6k
Other Decks in Technology
See All in Technology
Gemini Intelligence 入門 ― AppFunctions と Gemini Nano
takuroabe
0
300
パスキーの自動テストはどこまでいけるのか
teamlab
PRO
0
290
PHPカンファレンス関西の招待状 / Invitation to PHP Conference Kansai
ykanoh
0
210
Post AI時代のリファクタリング実践記 / Refactoring in the post AI era
kaminashi
1
290
DBについての基礎説明(MySQL編) - コロプラ 2026年度 新卒研修
colopl
0
130
AI導入は済んだ。次は統制を作り替える番だ_AI×開発組織 Summit 2026
techtekt
PRO
0
370
SAENM ~Jupyterで残すPoCの試行錯誤、未来の自分と仲間を助ける記録!~
terapyon
0
120
WasmをRustにする
sansantech
PRO
0
290
夫婦で子育てするための育児標準化
codmoninc
PRO
0
460
データエンジニアの次の戦場は "プロセスエンジニアリング"
sansantech
PRO
1
110
M5Stackで作る BLEマウス GPSログの世界
tomokusaba
PRO
0
440
hackers_champloo_2026_tidb
makocchi
0
170
Featured
See All Featured
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
10
1.4k
How Software Deployment tools have changed in the past 20 years
geshan
2
35k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
250
1.3M
The Invisible Side of Design
smashingmag
301
52k
A Modern Web Designer's Workflow
chriscoyier
699
190k
The Curious Case for Waylosing
cassininazir
1
570
Music & Morning Musume
bryan
48
7.4k
Technical Leadership for Architectural Decision Making
baasie
3
600
Being A Developer After 40
akosma
92
590k
Six Lessons from altMBA
skipperchong
29
4.5k
Why You Should Never Use an ORM
jnunemaker
PRO
61
10k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.5k
Transcript
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