Windowsおじさんこと、技術4課の鎌田です。 re:Inventで発表された、AWSにもついに来ました、マネージドのファイルサーバー!その名もAmazon FSxです。
これは使ってみるしかない、という訳で、実際に環境を構築して触ってみました。 なお、記事執筆時点(2018年12月)では東京リージョンに来ていないため、オレゴンリージョンで展開しています。
前提条件にご注意を
FSxのサービスですが、使うにあたっての前提条件があります。 以下にポイントを3つ挙げておきますので、良くご確認の上ご利用ください。
1.Directory ServerのAWS Directory Service for Microsoft Active Directory(以下、MSAD)を利用していること
これが意外なハードルかも知れません。ドキュメントにもしっかり書いてあります。 既存のドメインを使いたい場合は、MSADを展開の上、既存のドメインと信頼関係を結びます。 信頼関係の結び方は、以前に私が書いたブログ記事を参照してください。
2.アクセスがサポートされるクライアント
2018年12月現在、以下からのアクセスがサポートされています。
- Amazon Elastic Compute Cloud (Amazon EC2) instances
- Amazon WorkSpaces instances
- Amazon AppStream 2.0 instances
- VMs running in VMware Cloud on AWS environments
オンプレミスからの直接のアクセスは、記事執筆時点ではサポートに入っていません。 ファイルサーバーの移行をご検討の場合は、ご注意ください。
3.アクセスがサポートされるOS
ドキュメントには、以下のOSが挙がっています。
- Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016
- Windows Vista, Windows 7, Windows 8, Windows 8.1, and Windows 10 (including the Windows 7 and Windows 10 desktop experiences of Amazon WorkSpaces)
- Linux (cifs-tuilsを使ったアクセスが可能なOS)
SMB protocol (versions 2.0 through 3.1.1)に対応していることが要件となります。
実際に構築する
実際に触ってみましょう。 なおFSxは東京リージョンにないので、FSxが来ているリージョンを選択しておきましょう。
まずはAmazon FSxのマネジメントコンソールの画面に移動します。 画面の右側にある、「Create File system」をクリック。
今回はWindowsからアクセスするファイルサーバーを作るので、左側の「Amazon FSx for Windows File Server」を選択します。 選択したら、Nextをクリック。
ファイルシステム作成の画面に移動します。 「File system name」は、AWS上の管理名の入力欄です。分かり易い名前を付けておきましょう。 次に、容量を入力します。容量は最低300GiBから64TiBです。私は一旦最低容量の300で作ってみます。 容量は、記事執筆時点では後からの変更が出来ない仕様となっていますので、ご注意ください。
スループットの性能はAWS側で自動計算して最適な値を設定してくれるのですが、指定も可能です。 ドキュメントに、指定可能なスループット性能に関しての記述があるので参考にしてください。 最適値を使うので、ここでは「Recommended throughput capacity」を選択して進めます。
容量とスループット性能を決めると、推定コストをAWSで提示してくれます。
次はFSxを配置するVPC、サブネット、セキュリティグループの設定を行います。 この画面でセキュリティグループを作成できないので、あらかじめ作成しておきましょう。 アクセス要件はこちらのドキュメントに記載があります。
基本は、FSxがファイルサーバーとしてアクセスされる際の、アクセス元IPからのアクセス許可を設定します。 ファイルサーバーということもありますので、サブネット丸ごと許可されるケースが多くなるかと思います。
VPC、AZ、サブネット、セキュリティグループを選択していきます。
次は認証に関する設定です。ここで、Directory ServiceのMSADを選択することになります。 こちらも、FSxがドメイン参加するため、あらかじめ構築しておく必要があります。 ドメインを選択してましょう。
次は暗号化に関する設定です。 FSxはKMSにてデータ領域もバックアップも暗号化がデフォルトとなっています。 (ドキュメントもご参照ください。) KMSキーに指定がある場合は、指定をします。 指定がない場合はデフォルトのまま進めても問題ありません。
最後はメンテナンスの設定です。 RDSにあるような、バックアップウィンドウ、メンテナンスウィンドウの設定です。 No preferenceを選択した場合、FSxのデフォルト設定が使われます。 本番環境で使われるようなケースでは、指定してご利用ください。 バックアップウィンドウは毎日のバックアップ時間をUTCで、メンテナンスウィンドウは毎週の曜日と時間をUTCで、それぞれ指定します。 こちらも、設定後は変更が出来ない仕様のため、ご注意を。
ここまで指定が完了したら、Nextをクリックします。
確認画面になるので、「Create file system」をクリックしましょう。
しばらく待っていますと、出来上がります。待ち時間は15分程度でした。
出来上がった後、File system nameをクリックし、Network & securityをクリックすると、DNS nameが表示されます。 こちらが、ファイルサーバーにアクセスする時のコンピューター名になりますので、控えておきましょう。
WindowsのEC2を立てて、コンピューター名にエクスプローラーからアクセスしてみると、Shareという共有フォルダが見えます。 これで無事、FSxにアクセスできました!
構築して分かったこと
構築して触ってみて分かった点をまとめておきます。
FSxはMulti-AZで動かすには手組みが必要
FSxは、記事執筆時点では、サービス側で冗長化はされておらず、単一AZで動かすことが前提となっています。 Multi-AZで動かす場合、ドキュメントにも記載がありますが、WindowsのDFSを使って冗長化することとなります。 ※サポートが明記されています。
共有フォルダ名は変えられない
Shareという共有フォルダ名は、残念ながら変更できません。
バックアップのリストはもう一つFSxが出来上がる
ファイル単位で戻すといった運用は、マネジメントコンソール上ではできません。
考えられるユースケース
こんな場合に、良いのではないでしょうか。
1.WorkSpacesをAWSで初期構築し利用する際に、ファイルサーバーも用意したい場合 2.AWS上でシステム構築する中でファイルサーバーが必要になったが、メンテナンスコストをかけたくない場合
まとめ
1.MSAD必須だが、構築は簡単にできる 2.色々と注意点があるため理解して利用、運用する必要がある
Windows Updateから開放されるだけでも、利用価値は高いと思います。是非皆さんも、お試しください!