Amazon FSx for Windows File Serverを構築してみた

はじめに

最近、ファイルサーバーの移行案件に携わることが増えてきました。そこで今回は、あまり触ったことがなかったAmazon FSx for Windows File Server（長いので以降はFSxWと省略します）について検証していきたいと思います。

Amazon FSx for Windows File Serverとは

一言でいえば、『Windows File Serverのマネージドサービス』です。実際にWindows Server上で動作しており、次のような特徴を持ちます。

• Windows互換：Active Directoryと連携したアクセス制御やストレージクォータ、VSS（ボリュームシャドーコピー）等をサポート
• 柔軟なパフォーマンス：HDDとSSDの両方のストレージタイプをサポートしており、スループットやSSD IOPSの拡張が可能
• エンタープライズ対応：マルチAZ対応、自動バックアップ、監査ログ取得などエンタープライズでの利用に必要な機能を保有

FSxWは、Active Directoryとの連携を前提としたサービスです。AWS Managed Microsoft AD、セルフマネージドAD（=オンプレ等の一般的なAD）をサポートします。セルフマネージドADを利用する場合、以下の前提条件を満たす必要があります。

構築してみる

前提条件

今回は、EC2に構築したセルフマネージドADを利用します。セルフマネージドADとFSxWは同じVPC上に構築します。VPCとドメインコントローラーは事前に構築してある前提で進めます。最終的な構成は以下となります。

※ENIはFSxW作成時に自動で作成されます

ネットワーク設定

以下リンクの『ネットワークの設定』に従って、必要な通信を許可します。今回の環境では、ADとFSxWは同様のVPCにあるためセキュリティグループの設定だけ許可しておきます。

ADの事前準備

FSxWの構築にあたり、AD側で以下の事前準備を実施します。（必須ではないものもありますがベストプラクティスや以降の管理作業を見据えて実施します）

事前準備事項	概要
①ADサイトを適切に設定	Active Directoryのサイトとサービス（サブネット）を適切に設定します。サイトを設定しておくことで、FSxWがドメインコントローラーに安定した通信ができるようにします。
②FSxW専用OUを作成	FSxW専用のOUを作成します。作成したOUをFSxWの作成時に指定すると、該当のOUにコンピューターアカウントが作成されます。
③FSxW用のサービスアカウントを作成	FSxW（実態はWindows Server）をドメイン参加させるためのサービスアカウントを作成しておきます。
④FSxW管理用のグループとユーザーを作成	FSxW管理用のグループとユーザーを作成しておきます。

①ADサイトを適切に設定

Active Directoryのサイトとサービスを設定します。基本的にオンプレADを利用する場合、物理的に距離が近いサイトにサブネットを追加することになるでしょう。今回の検証ではドメインコントローラーがVPCにあるので、特に設定はせず『Default-First-Site-Name』のままとします。実業務ではサイトとサブネットを適切に構成しましょう。（ちなみにAWSのドキュメントでは、同じリージョンに存在するドメインコントローラーは単一のサイトとして構成することが推奨となっています）

②FSxW専用OUを作成

FSxW専用のOUを作成します。

③FSxW用のサービスアカウントを作成

サービスアカウントを作成します。所属グループはデフォルトの『Domain Users』のままで問題ありません。アカウント作成後、②で作成したOUの委任権限を設定します。

④FSxW管理用のグループとユーザーを作成

FSxW管理用のグループとユーザーを作成しておきます。FSxW管理用のグループは必須ではありませんが、FSxW作成時に管理用グループの指定があるため事前に作成しておきます。管理用グループを明示的に指定しない場合は、『Domain Admins』が管理グループになるため、実運用に合わせて作成するかどうかを検討するのが良いでしょう。

今回は検証のため、管理用グループとユーザーを事前に作成しました。

ファイルシステムの構築

事前準備ができたら、マネコンからFSxWを作成していきます。

どういった設定ができるかみておきたいので、「スタンダード作成」を選択します。マルチAZ構成で、その他は最小構成のままにします。

ネットワーク設定を行います。AWSサービスあるあるで、指定したサブネットにENIが生えてきます。

ADの形態や認証先のドメインを設定します。今回はセルフマネージドADを指定し、認証情報を設定します。また、事前に作成したサービスアカウントやFSxW管理用グループを指定します。

その他の設定はデフォルトのままにします。

設定に問題ないか確認して、FSxWを作成します。

ファイルシステム作成後の確認

FSxW（ファイルシステム）の作成が完了すると、ステータスが「利用可能」になります。

FSxW用のOUでは、コンピューターアカウントが4つ作成されていました。

実際に共有フォルダにアクセスするため、FSxWの詳細画面からDNS名を控えておきます。

ドメイン参加したコンピューターから共有フォルダにアクセスすることができます。

アクセス許可を確認すると、FSxW管理用グループがフルコントロールを持っていることを確認できます。

共有、監査設定はFSxW管理用グループ以外のユーザーで確認しようとすると、閲覧権限がないようでした。（FSxW管理用グループのユーザーからは閲覧可能です）

ファイル共有の作成

ファイル共有を作成してみます。今回はGUIから「fsmgmt.msc」を利用して作成します。PowerShellを使って作成することも可能です。

FSxW管理用グループのユーザーでログインし、管理共有（d$）にアクセスします。（FSxW管理用グループ以外のユーザーでは管理共有にアクセスできません）

共有したいフォルダを作成しておきます。

この時点では、共有フォルダから上記のフォルダは見えません。

ファイル名を指定して実行から「fsmgmt.msc」を起動します。

別のコンピューターへ接続からFSxWに接続します。

新しい共有を作成します。

ウィザードに従い、先ほど作成したフォルダを選択します。

共有フォルダの設定はデフォルトのままとします。（実業務ではアクセス許可を適切に設定する必要があるでしょう）

設定が完了すると、共有フォルダとして見えるようになります。

PowerShellによる設定

FSxWでは、PowerShell（Amazon FSx CLI）でしか設定できない項目がいくつかあります。

• データ重複排除
• VSS（ボリュームシャドーコピー）
• 転送時の暗号化強制
• ストレージクォータ
• アクセスベースの列挙（ABE）

リモートセッション確立

PowerShell（Amazon FSx CLI）による操作を行うためには、リモートセッションの確立が必要です。（Invoke-Commandを使うこともできますが、本記事では基本この方法で進めます）FSxW管理用グループのユーザーでログインしているコンピューターからPowerShellを起動し、以下コマンドでリモートセッションを確立します。

※<>部分は自身の環境に合わせて設定してください

Enter-Pssession -ComputerName <Windows Remote PowerShell Endpoint> -ConfigurationName FsxRemoteAdmin -SessionOption (New-PSSessionOption -uiCulture "en-US")

以降は、アクセスベースの列挙（ABE）を除き、リモートセッションが確立している前提で進めます。

データ重複排除

FSxWでは、重複排除を有効にすることでストレージコストの削減が可能です。重複排除はデフォルトで有効になっていないため、PowerShellコマンドにより有効化します。

# デフォルトのスケジュールで重複排除を有効化
Enable-FsxDedup

# 重複排除設定の確認
Get-FSxDedupConfiguration

# 重複排除スケジュールの確認
Get-FSxDedupSchedule

# 重複排除ステータスの確認
Get-FSxDedupStatus

重複排除はリアルタイムに実行されているわけではなく、スケジュールに従って実行されます。重複排除のしくみについてはMSのドキュメントを見るのが良いでしょう。なお、FSxWでは、デフォルトで以下のスケジュール（UTC）で重複排除が実行されるようです。

VSS（ボリュームシャドーコピー）

FSxWはVSSをサポートします。こちらもデフォルトでは有効化されていないため、必要に応じて有効化します。

# デフォルト設定(ストレージサイズの最大10%)でVSSを有効化
Set-FsxShadowStorage -Default

# デフォルト設定(UTC平日の午前7時と正午12時)でスケジュールを有効化
Set-FsxShadowCopySchedule -Default -Confirm:$False

# シャドウコピーのスケジュール確認
Get-FSxShadowCopySchedule

なお、以下のコマンドを実行することで、実行時点のコピーを取得することができます。

# シャドウコピーの実行
New-FSxShadowCopy

エクスプローラーから、コマンド実行時点のバージョンが作成されていることを確認できました。復元を実行すると、コピー取得の時点にフォルダを戻すことができます。

転送時の暗号化強制

転送時の暗号化を強制することで、SMB3.0暗号化をサポートしていないクライアントからのアクセスを制限することができます。

デフォルトでは、SMB3.0以降のSMB暗号化をサポートするクライアントとの通信は自動的に暗号化されます。一方、FSxWではSMB2.0から3.1.1をサポートしているため、暗号化を強制していない場合、SMB2.xによる非暗号化通信も可能です。転送時の暗号化を強制すると、SMB3.0の暗号化をサポートしていないクライアントからアクセスできなくなります。

# 転送時の暗号化を強制
Set-FsxSmbServerConfiguration -EncryptData $True -RejectUnencryptedAccess $True -Confirm:$False

# 転送時の暗号化設定の確認
Get-FSxSmbServerConfiguration

なお、クライアントPCからPowerShell（管理者権限）で以下実行することにより、接続に使用されているSMBのバージョンを確認できます。
※Amazon FSx CLIではないため、リモートセッションの確立は不要

Get-SmbConnection -ServerName <ServerName> | Select-Object -Property *

ストレージクォータ

FSxWでは、ユーザーレベルでのストレージクォータに対応しています。

# 1GBのユーザーストレージクォータを設定
Enable-FSxUserQuotas -Enforce -DefaultLimit (1GB) -DefaultWarningLimit (500MB)

# ユーザーストレージクォータ設定の確認
Get-FSxUserQuotaSettings

ユーザーストレージクォータを設定したため、1ユーザーあたりに利用できる容量が1GBに制限されました。ちょうど良いサイズのフォルダがあったので、共有フォルダにコピーして動作を確認してみます。

1回コピーすると、Warningとして設定した500MBを超えるため、ステータスが「Warning」になっています。

# 個々のユーザーおよびグループの現在のユーザーストレージクォータの状態を確認
Get-FSxUserQuotaEntries

もう一度コピーすると、容量不足との表示がでてきます。

ネットワークドライブとして割り当てすると、容量がギリギリになっているのがわかります。

他のユーザーから同じ共有フォルダを確認すると、容量に余裕ある状態になっています。

FSRMを有効にすることで、フォルダに対してクォータを設定することも可能です。

https://docs.aws.amazon.com/ja_jp/fsx/latest/WindowsGuide/fsrm-quota-management.html

アクセスベースの列挙（ABE）

アクセスベースの列挙 (Access-based Enumeration：ABE）は、ユーザーがアクセス可能なフォルダのみを見えるようにする機能です。デフォルトでは、ユーザーに権限がないフォルダも存在としては確認できます。

アクセスベースの列挙設定を確認するためには、Select-ObjectでFolderEnumerationModeを指定する必要がありますが、リモートセッションを確立した状態では制限？があるようでエラーになるためInvoke-Commandを利用します。

# 特定のファイル共有でアクセスベースの列挙を有効にする
Invoke-Command -ComputerName <ComputerName> -ConfigurationName FSxRemoteAdmin -scriptblock { Set-FSxSmbShare -Name '<share-name>' -FolderEnumerationMode AccessBased }

# 特定のファイル共有でアクセスベースの列挙を無効にする
Invoke-Command -ComputerName <ComputerName> -ConfigurationName FSxRemoteAdmin -scriptblock { Set-FSxSmbShare -Name '<share-name>' -FolderEnumerationMode Unrestricted }

# アクセスベースの列挙設定の確認
Invoke-Command -ComputerName <ComputerName> -ConfigurationName FSxRemoteAdmin -scriptblock { Get-FSxSmbShare } | Select-Object Name, Path, FolderEnumerationMode

アクセスベースの列挙設定確認の出力で、FolderEnumerationModeが1（デフォルト）の場合はアクセスベースの列挙が有効になっていません。0は、有効になっていることを表しています。

アクセスベースの列挙を有効にした後、アクセス許可がない「Admin」フォルダが見えなくなったことを確認できました。

検証では、すぐにアクセスベースの列挙の設定が反映されないことがありました。その場合は、クライアントPCの再起動を試してみてください。

さいごに

実際に触ってみることで、どういった設定ができるかを具体的にイメージできるようになった気がします。次はAWS DataSyncについても検証してみたいです。