オンプレミスからAWSクラウドへの移行において、既存のワークロードやアプリケーションに適したストレージ基盤を選定することは、プロジェクトの成否を左右する重要な検討事項の一つです。AWSが提供するマネージドファイルシステムサービスは、データの永続化・共有・高速アクセスといった用途に応じて複数の選択肢が用意されています。以下に、各サービスの概要とユースケースを示します。
　
　AWSファイルシステムサービス一覧

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方向があります。

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-vault
snapmirror 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 any
vserver 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マッピングドメインが一致していない場合、以下のような問題が発生します。

ファイル領域の作成
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機能を利用し、東西間のデータレプリケーション方法も紹介していきますので、どうぞよろしくお願いいたします。

本記事については、すこし業務構築上お役に立てれば幸いです。