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.2k
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.4k
コスト最適重視でAurora PostgreSQLのログ分析基盤を作ってみた #jawsug_tokyo
non97
2
2.1k
Aurora PostgreSQLがCloudWatch Logsに 出力するログの課金を削減してみる #jawsdays2025
non97
1
1.4k
VPC間の接続方法を整理してみた #自治体クラウド勉強会
non97
1
2.8k
Amazon FSx for NetApp ONTAPを利用するにあたっての要件整理と設計のポイント
non97
1
1k
Amazon FSx for NetApp ONTAPのパフォーマンスチューニング要素をまとめてみた #cm_odyssey #devio2024
non97
0
1.6k
オンプレミスネットワークとVPCとを接続する際に考慮すべきポイントを考えてみた #自治体クラウド勉強会
non97
1
7.5k
上手く活用すればコスト削減につながる、ONTAPの Temperature Sensitive Storage Efficiency (TSSE) の紹介
non97
0
1.2k
Amazon FSx for NetApp ONTAPへの移行方法を整理してみた
non97
0
2.5k
Other Decks in Technology
See All in Technology
iOSDC Japan 2026 day1 TrackC 10:50
feedtailor
1
160
おい、エージェントを使って終わらせろ
nwiizo
0
240
Claude Code本って、 読む必要あるの?
oikon48
2
460
OpenTelemetryのメトリクスをCloudWatchに送ってPromQLで見てみた
ota1022
0
150
アプリログインとWeb認証基盤をつなぐ ASWebAuthenticationSession 作法
shimastripe
1
320
CLIライブラリ開発を支える技術
htnabe
0
100
AIネイティブプロダクトで顧客価値を最大化するプロダクトエンジニアとFDEの協働
righttouch
PRO
0
310
株式会社シーエーシー エンジニア向け会社紹介資料
cac
0
57k
Spring BootからQuarkusへの移行
tatsuya1bm
2
120
絵ではじめるKubernetesセキュリティ
aoi1
3
560
Railsのように考える: See through the Master
snoozer05
PRO
3
820
AIを活用するために決めた "やらないこと" - 価値に注目する / Not betting on AI
soudai
PRO
1
520
Featured
See All Featured
Visual Storytelling: How to be a Superhuman Communicator
reverentgeek
2
660
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
1
540
We Are The Robots
honzajavorek
0
370
Claude Code のすすめ
schroneko
67
230k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
990
The AI Search Optimization Roadmap by Aleyda Solis
aleyda
1
6.2k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.2k
Thoughts on Productivity
jonyablonski
76
5.4k
Building the Perfect Custom Keyboard
takai
2
870
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
420
How STYLIGHT went responsive
nonsquared
100
6.3k
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
230
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