AWS FSx For NetApp ONTAPを使ってNASサーバを構築
2026/06/08
オンプレミスからAWSクラウドへの移行において、既存のワークロードやアプリケーションに適したストレージ基盤を選定することは、プロジェクトの成否を左右する重要な検討事項の一つです。AWSが提供するマネージドファイルシステムサービスは、データの永続化・共有・高速アクセスといった用途に応じて複数の選択肢が用意されています。以下に、各サービスの概要とユースケースを示します。
AWSファイルシステムサービス一覧
| サービス | プロトコル | OS | スケール | 主な用途 |
| EFS | NFS | Linux | 自動 | 汎用共有ストレージ |
| FSx for Windows | SMB/NTFS | Windows | 固定 | Windowsアプリ |
| FSx for Lustre | Lustre | Linux | 固定 | HPC・ML |
| FSx for NetApp ONTAP | NFS/SMB/NTFS/iSCSI | マルチ | 自動 | エンタープライズ |
| FSx for OpenZFS | NFS | Unix系 | 固定 | ZFS移行・DevOps |
今回、ご紹介するは、Amazon FSx for NetApp ONTAPになります。
Amazon FSx for NetApp ONTAPとは
NetApp社のONTAPファイルシステムをAWSのマネージドサービスとして提供するものです。オンプレミスで広く使われているNetApp ONTAPをそのままクラウドで利用できるのが最大の特徴となっています。また、ほかのファイルシステムと比べると、LinuxもWindowsも同時扱うことができ、マルチプロトコルが対応されている点も、非常に優れています。
Amazon FSx for NetApp ONTAPを構築するにあたり、周辺サービスを含め、利用するアーキテクチャ図はこちらになります。
では、ここから、ステップごとに、FSx for NetApp ONTAPのファイルシステムを構築していきます。
ファイルシステムの作成
Amazon FSx for NetApp ONTAPの管理画面へ遷移し、「ファイルシステムを作成」タブから初期設定をしていきます。
ファイルシステムの詳細を指定のところ
検証のため、以下の値として設定していきます。
| 設定項目 | 設定値 | 備考 |
| 作成方法 | スタンダードを作成 | |
| ファイルシステム名 | fsx-test | |
| デプロイタイプ | シングル AZ 2 | ONTAPの第二世代を利用（シングル） |
| SSD ストレージ容量 | 1024 GiB | |
| プロビジョンド SSD IOPS | 3072 IOPS | 1TiBに対し設定する最低限の数値 |
| スループットキャパシティ | 384 MB/秒 | 384～6144 MB/秒まで指定可能 |
| ネットワークとセキュリティ | VPC,サブネット,SGを指定 | |
| ネットワークタイプ | IPv4 | |
| 暗号化 | デフォルト | |
| ファイルシステム管理パスワード | パスワードを指定 | |
| ストレージ仮想マシン名 | svm01 | |
| svm管理パスワード | パスワードを指定 | |
| ボリュームのセキュリティスタイル | Unix（Linux） | 目的に応じて設定 |
| Active Directory情報 | 参加しない | |
| ボリューム名 | vol01 | |
| ボリュームスタイル | FlexVol（推奨） | |
| ボリュームサイズ | 1TiB | |
| ボリュームタイプ | Read-Write (RW) | Data Protection (DP)は読込専用 |
| ジャンクションパス | /vol01 | |
| ストレージ効率 | 有効 | ストレージ重複排除機能利用有無 |
| スナップショットポリシー | Default | |
| 容量プールの階層化ポリシー | なし | |
| SnapLock 設定 | 無効 | |
| 毎日の自動バックアップ | 有効 19:00 UTC 1日 | 要件に応じて設定 |
| タグ | Env uat | タグ戦略的に、設定しましょう |
10-15分程度で、ONTAＰのファイルシステムが作成されます。
ONTAPユーザ作成関連
Amazon FSx for NetApp ONTAPを構築していく中で、避けて通れないのがユーザ・グループ管理の設定です。特にLinux（NFS）とWindows（SMB）が混在する環境では、ユーザIDとグループIDの関連づけや、ネーミングマッピングの設定が適切に行われていないと、ファイルアクセス時の権限エラーや予期しない動作につながることがあります。
FSx ONTAP においてONTAPのローカルユーザ作成・グループ作成・ユーザIDとグループIDの関連づけ、そしてネーミングマッピングの設定について、順を追って解説します。
上記ファイルシステム作成後、TeratermやEC2サーバ経由し、FSx ONTAPサーバにログインする。
※FSx ONTAPサーバへログインする方法や、ネットワーク周りの設定を割愛します。経路存在していることを前提とする。
ローカルユーザ作成コマンド
ONTAPでは、SVM内にローカルのUNIXユーザを作成することができます。外部のLDAPやNISサーバを使わない場合、このローカルユーザがNFSアクセス時の認証に使用されます。
cifs users-and-groups local-user create -vserver [svm] -user-name [username] -is-account-disabled false
グループ作成
ユーザと同様に、SVM内にローカルのUNIXグループを作成します。vserver services unix-group create -vserver [svm] -name [group name] -id 12345
ユーザIDとグループIDの関連付け
ユーザをグループに追加することで、グループ単位のアクセス制御を実現します。ONTAPではローカルグループにユーザを追加する操作を以下のように行います。vserver services name-service unix-user create -vserver [svm] -user [username] -id 12345 -primary-gid 12345
ネーミングマッピング
ネーミングマッピングは、NFSユーザ（UNIXユーザ名）とSMBユーザ（Windowsユーザ名）を相互に変換する仕組みです。マルチプロトコル環境（NFS + SMB 両対応）では必須の設定となります。name-mapping create -vserver [svm] -direction unix-win -position [number] -pattern [username] -replacement [SMB識別名]\smb-user
ネーミングマッピングの方向性
ONTAPのネーミングマッピングには以下の2方向があります。
| 方向 | 説明 |
| unix-win | UNIXユーザ → Windowsユーザへのマッピング（NFSアクセス時にWindowsのACLを評価する場合） |
| win-unix | Windowsユーザ → UNIXユーザへのマッピング（SMBアクセス時にUNIXのパーミッションを評価する場合） |
ONTAPポリシー作成関連
Snapshotポリシー作成
Snapshotポリシーは、ボリュームのスナップショットを自動的に取得するスケジュールと保持数を定義するものです。定期的なスナップショットを設定することで、誤削除やデータ破損からの迅速なリカバリが可能になります。snapshot policy create -vserver [svm] -policy [policy name] -enabled true -schedule1 hourly -count1 [時間単位保持数] -prefix1 hourly -schedule2 daily -count2 [日単位保持数] -prefix2 daily
SnapMirrorポリシー作成
SnapMirrorは、ボリュームのデータを別のSVMやリージョンにレプリケーションするONTAPの機能です。DR（災害対策）やデータ移行、オフサイトバックアップに広く利用されます。FSx ONTAPでは、同一リージョン内のSVM間、または別リージョンのFSx ONTAP間でSnapMirrorを構成できます。snapmirror policy create -vserver [svm] -policy [policy name] -type mirror-vaultsnapmirror policy add-rule -vserver [svm] -policy [policy name] -snapmirror-label [hourly/day] -keep [保持数]
SnapMirrorポリシーの適用snapmirror modify -destination-path [svm]:<dst_volume> -policy [policy name]
export-policy作成
Export Policy（エクスポートポリシー）は、NFSクライアントがボリュームやqtreeにアクセスする際の許可・拒否ルールを定義する設定です。どのIPアドレス・ネットワークから、どのプロトコルで、どのアクセス権限（読み取り専用・読み書き・root権限）でマウントを許可するかを制御します。export-policy create -vserver [svm] -policyname [policy name]
export-policyルール追加export-policy rule create -vserver [svm] -policyname [policy name] -ruleindex [number] -protocol any -clientmatch [アクセス許可IP] -rorule any -rwrule anyvserver export-policy rule modify -vserver [svm] -policyname [policy name] -ruleindex [number] -superuser any
export-policy適用volume modify -vserver [svm] -volume [volume] -policy [policy name]
NFSv4 ID Mapping Domainの設定
NFSv4 ID Mappingとは何か
NFSv3までは、ファイルのオーナー情報をUID/GID（数値）のまま送受信していました。一方、NFSv4ではUID/GIDの数値ではなく、ユーザ名@ドメイン名 という文字列形式（例appuser01@example.com）でオーナー情報をやり取りする仕様に変わっています。
この変換処理を担うのが ID Mapping（IDマッピング） であり、その基盤となるのが ID Mapping Domain（IDマッピングドメイン） の設定になります。vserver nfs modify -vserver [svm] -v4-id-domain [マッピングするドメイン名]
メインが一致しないと何が起きるか
FSx ONTAP（サーバ側）とLinuxクライアント（クライアント側）でIDマッピングドメインが一致していない場合、以下のような問題が発生します。
| 現象 | 原因 |
| ファイルのオーナーがnobodyと表示される | ドメイン不一致によりマッピングが失敗し、unknownユーザとして扱われる |
| ls -l でUID/GIDが数値のまま表示される | ユーザ名への変換が行われない |
session-num-slotsの設定
session-num-slotsとは何か
NFSv4.1では、クライアントとサーバ間の通信に セッション（Session） という概念が導入されました。このセッション内で、リクエストを並列処理するための「スロット（Slot）」が用意されており、同時に処理できるリクエストの最大数がスロット数によって制限されます。
この最大スロット数を制御するパラメータが session-num-slots です。
vserver nfs modify -vserver [svm] -v4.x-session-num-slots [session数値]ファイル領域の作成
Unix領域（Qtree）volume qtree create -vserver [svm] -volume [volume] -qtree [qtree名] -security-style unix
CIFS共有領域vserver cifs share create -vserver [svm] -share-name [共有領域name] -path [ディレクトリパス]
※CIFS共有領域を作成する前に、Qtree側にてファイルパスが存在すること
Linux側のNFSクライアントから、もしくは、WindowsのSMBからFSx ONTAPに対しマウントし、ディレクトリの作成・削除・更新ができるようになります。
今回は、メインサイトに対し、ONTAPの構築方法をご紹介しました。次回は、ONTAPのSnapMirror機能を利用し、東西間のデータレプリケーション方法も紹介していきますので、どうぞよろしくお願いいたします。
本記事については、すこし業務構築上お役に立てれば幸いです。