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.6k
コスト最適重視で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
Devin プロモコードの受け取りと適用(2026.10.27)
kinopeee
0
510
なぜAI時代に技術記事を書くのか?どう書くのか? 〜bunの場合〜
kworkdev
PRO
0
130
「Learning Outcome」を書きたくない私が、Learning Outcomeと折り合いをつけるまで
mhlyc
0
240
AI駆動開発における開発環境のセキュリティの考え方
yamahiro
2
620
2026-10-24 JAWS JAWS-UG 茨城 #18 IAM Policy Autopilotってなにさ。terraform planからIAM Policyつくれるの? / What's IAM Policy Autopilot
masasuzu
0
170
Codex を使った障害対応机上演習の実際
orgachem
PRO
0
360
国際カードブランドルール変更に伴うクレジットカード決済取引仕様変更について
k1style
0
240
Metadata - Section 2: Simple Metadata & Meta Tags
mohab1
0
140
BacklogのRAG 今ならこう作る - S3 Vectorsと自前パイプラインの勘所
revsystem
0
140
正解のない研修に放り出されて / Being thrown into a training program with no right answers
ohnoeight
1
150
ガチで放置できるClaude Code実行環境の作り方.pdf
lamaglama39
5
9.8k
CSS2026:OWS研究会・招待講演「世界観を、実装する」
atsush1_sada
2
330
Featured
See All Featured
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
1
640
Bootstrapping a Software Product
garrettdimon
PRO
306
120k
Between Models and Reality
mayunak
4
510
Building AI with AI
inesmontani
PRO
1
1.3k
The Anti-SEO Checklist Checklist. Pubcon Cyber Week
ryanjones
0
270
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.6k
Lightning Talk: Beautiful Slides for Beginners
inesmontani
PRO
2
740
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
2
330
Unlocking the hidden potential of vector embeddings in international SEO
frankvandijk
0
1k
Making Projects Easy
brettharned
120
6.8k
The innovator’s Mindset - Leading Through an Era of Exponential Change - McGill University 2025
jdejongh
PRO
1
380
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
600
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