ウサギでもわかるAmazon FSx for Windows概要と構築

さて、今回はAWSのマネージドファイルサーバーサービス、FSxを触ってみたいと思います。
#Amazon FSxとは
簡単に言うとWindowsServerのストレージを利用できるマネージドサービスです。
初めて聞いたときは「ついにWindows Storage Serverもクラウド化したのか～」などと頓珍漢なことを思った記憶があります。
当然ですがOSが丸ごと提供されるEC2とは異なるため、RemoteDesktopによる管理とはまた違う方法で管理する形になります。細かい設定方法は別のサーバー上でPowerShellから実行する必要もあるそうです。
##料金は
ファイルサーバーというと前職でもWindowsServerを「これでもか！」というほど構築してきたので、当然EFSとかFSxも発表されたときにそれなりに情報調査をし、提案することができるかを比較してきました。しかし、いまいち料金的に安くないし、管理方法も従来と変わることがデメリットにもなるということで、結論としては提案するところまでいきませんでした。

料金体系は以下の通りです。

• 容量課金　（バックアップも）
• 帯域課金

単純に1TBの容量をバックアップ込みで8MBps程度のスループットで利用する場合は以下の料金となります。

$202≒2万円超ですか、割とまともな金額ですね。
これが、もう少し帯域が欲しくなると金額が上がります。例えばNuroの回線を使ってRTX1210当たりのルーターでVPN Connectionで接続してもかなりのスループットが出るので、例えば36MBpsの帯域を確保すると以下のようになります。

• 36MBps　×　＄2.53　＝　＄91

＄73値上がりしたので＄275です。

##EC2で構築する料金は
これを普通のEBS＋Snapshotで計算とすると以下のようになります。

• m5.large　720時間　×　＄0.216　＝　＄156
• EBS　　　　1,024GB　×　＄0.12　＝　＄123
• Snapshot　1,024GB　×　＄0.05　＝　＄51

$330になりました。
なるほど。あまり変わらないどころか、FSxはむしろ安いですね。

ここでちょっと、中小企業向けに料金を最適化してしまいます。

• t3.large　720時間　×　＄0.1088　＝　＄78
• EBS(st1)　1,024GB　×　＄0.054　＝　＄55
• S3　　　　1,024GB　×　＄0.025　＝　＄25

＄158になりました。
EC2はTシリーズ、EBSはスループット最適化ディスク、バックアップにはS3を用いてCLIでファイルコピーとしました。中小企業向けの提案はここまで低価格にしてようやく導入に向けて話を聞いてもらえる、という価格帯でした。

ちなみに風の噂ですが、HDD(st1)を採用するタイプも発売を予定しているそうで、そっちはかなりの低料金になるようです。そっちが本命かもしれませんね。
##事前に調べたWindowsServerと異なる点
一般的な利用方法としてはこれまでWindowsServerで利用していたものを移行することが多いと思うので、WindowsServerで出来ていることが出来ないとツラミが深くなってしまいます。そこで、Webを検索して現時点でWindowsServerでできるけど、FSxではできない（っぽい？）情報を集めてみました。

###クォータ
各フォルダの最大容量を指定できるクォータ機能が、FSxにもあるのですが、どうも扱いが異なるようです。
WindowsServerでは、フォルダにクォータを設定し、そのフォルダの容量を監視して80%を超えたらメールを発報したり、100%に達すると書き込みが出いなくなるといったルールを設定できる機能です。
しかし、以下のページの説明を見てみると、ユーザごとのファイル容量という基準になっているように見受けられます。ユーザー毎のファイル容量をどのように集計するのか、そのような需要があるのかよくわかりませんし、挙動もよくわからないので、後ほど実際に試してみたいと思います。
https://aws.amazon.com/jp/about-aws/whats-new/2019/11/amazon-fsx-windows-file-server-enables-monitoring-user-level-storage-consumption/
「ストレージ管理者がファイルシステムでのユーザーレベルのストレージ消費を監視および制御」

###容量の変更ができない
以下のFSxのFAQページでも容量の変更について一切記載がありません。別のBlog記事ではre:Inventの質疑応答で「現時点ではスナップショットを取得して新しいストレージを作りしかない」と回答があったそうです。ダウンタイムが発生してしまいますね。
https://aws.amazon.com/jp/fsx/windows/faqs/
EBSでも増加はノンストップで可能になっているので、ぜひ早期に実現してほしい機能です。
風の噂では近々リリースされるかもしれません。

###アクセスログは取得不可
OSにRemoteDesktopなどでログインできないということは、ファイルシステムの読み書きログの取得もできないと考えたほうがよさそうです。ADサーバで認証ログだけは取得できると思いますが、それだけでは最近のセキュリティ監査がOKとは言えない可能性があります。
そして当然ですが、サーバー側の資産管理ソフトでのログ取得もできません。まぁこれはクライアント側で取得すればいいだけの話です。

###ウィルスチェック機能などはなし
単なるストレージサービスなので、ウィルスチェック機能なども提供していません。
Office365のSharepointやOnedriveはウィルスチェック機能を持っているようなので、よりシンプルなIaaSらしいサービスといえます。
これも風の噂ではサービス追加を予定しているとか。

###ホスト名の設定不可
作成時にホスト名を入力することができないため、ランダムな文字列のホスト名となってしまいます。
ADでエイリアスを作成することによって回避できる気がしますが、意味不明なホスト名がついているのも気持ち悪いので、こちらもアップデートを待つしかないようです。
もしくは名前空間の利用ですね。DFS-Rとの相性はいいですが、管理面でそこまでやりたくないという場合には面倒になるかもしれません。

###移行時のDFS-RはDelfManaged AD　＆　Single AZのみ対応
ファイルの移行は基本的にrobocopyコマンドによる移行が案内されていますが、特定の条件を満たせばWindowsのレプリケーション機能DSF-Rを用いて移行することができるようです。
さらにNameSpaceを用いれは、ノンストップでの移行もできるかもしれません。

#FSx for Windowsを使ってみる
さて、発表当初からいろいろとアップデートがあったので、今は東京リージョンでも使えますし、ADもAWSのサービスではなくユーザーの運用しているADサーバがあれば問題なく利用できるようです。
##ADサーバの条件は
しかしどのようなADでもよいわけではなく、FSxを利用できる条件がAWSから示されています。
https://docs.aws.amazon.com/fsx/latest/WindowsGuide/self-managed-AD.html

• 自己管理ディレクトリの完全修飾ドメイン名

注意
ドメイン名は、単一ラベルドメイン（SLD）形式であってはなりません。現在、Amazon FSxはSLDドメインをサポートしていません。

• ドメインのDNSサーバーのIPアドレス

• ファイルシステムをADドメインに参加させるためにAmazon FSxが使用する、ADドメインのサービスアカウントのユーザー名とパスワード

• （オプション）ファイルシステムを参加させるドメイン内の組織単位（OU）

• （オプション）ファイルシステムで管理アクションを実行する権限を委任するドメイングループ。たとえば、このドメイングループは、Windowsファイル共有の管理、ファイルシステムのルートフォルダーのACLの管理、ファイルとフォルダーの所有権の取得などを行います。このグループを指定しない場合、Amazon FSxはデフォルトでADドメインのDomain Adminsグループにこの権限を委任します。

機械翻訳ですが要件は伝わりますね。
要するにADサーバのIPアドレスと、管理者アカウントがあればOKということです。
専用管理者アカウントを構成することを推奨していて、次のページにその詳細が記載されています。
https://docs.aws.amazon.com/fsx/latest/WindowsGuide/self-managed-AD-best-practices.html

###Active Directoryドメインのサービスアカウントを作成するには

1. Active Directoryドメインのドメイン管理者としてログインしていることを確認してください。
2. Active Directoryユーザーとコンピューター MMCスナップインを開きます。
3. 作業ウィンドウで、ドメインノードを展開します。
4. 変更するOUのコンテキスト（右クリック）メニューを見つけて開き、[ 制御の委任]を選択します。
5. [ 制御の委任ウィザード]ページで、[ 次へ]を選択します。
6. [ 追加]を選択して、選択したユーザーとグループに特定のユーザーまたは特定のグループを追加し、[ 次へ]を選択します 。
7. 上の委任にタスクページ、選択したデリゲートにカスタムタスクを作成し、次に選択し、次へを。
8. 選択したフォルダ内の次のオブジェクトのみを、その後、選択した コンピュータのオブジェクトを。
9. 選択して、このフォルダ内の選択したオブジェクトを作成し、このフォルダに選択したオブジェクトを削除します。次に、次を選択します。
10. [ アクセス許可]で、次を選択します。

• パスワードを再設定する

• アカウント制限の 読み取りと書き込み

• DNSホスト名への検証された書き込み

• サービスプリンシパル名への検証された書き込み

1. 選択して[次へ]をして、選択し、完了を。
2. Active DirectoryユーザーとコンピューターMMCスナップインを閉じます。

#FSxの検証準備
##ADを立てます
割愛します

##ADでFSx管理ユーザーの設定
ADサーバーで「ADユーザーとコンピュータ」を開き、FSxの管理者とするユーザーを作成します。
通常通りドメインユーザーを作成する手順で作成し、特別にグループなどに所属させたりはしていません。
次に右クリックで「制御の委任」を選択します。

FSxさんを選択します。

「委任するカスタムタスクを作成する」を選択。

「フォルダー内の次のオブジェクトのみ」を選択し、「コンピューターオブジェクト」にチェック、さらに欄外の「選択された・・・作成する」と「選択された・・・削除する」両方にチェックを入れます。

「全般」にチェックが入っているので、その下から「パスワードの変更」「アカウントの制限の読み取りと書き込み」「DNSホスト名への検証された書き込み」「サービスプリンシパル名への検証された書き込み」の4つにチェックを入れます。

##FSxを作成します
サービスのリストではここにあります。

ここから作成します。

「FSx for Windows」を選択し、NEXTを押します。

必要なパラメーターを設定します。
ここで先ほど作成したADの管理を委任したユーザー情報も入力します。

確認画面でSUBMITすると完了です。

作成が始まりました。

今回は最小容量の32GBをデプロイしましたが、完了まで13分間かかりました。

容量の違いでデプロイ時間に差異があるのかなども、検証してみました。
比較として1TBをデプロイしてみました。

おっ！14分間でデプロイ完了しました。早いですね。
容量によってデプロイ時間の変化はそれほど大きくないようです。

#使ってみよう
EC2インスタンスへリモート接続し、接続できるか見てみます。
その前にWebコンソールでホスト名（DNS Name）を調べておきましょう。

早速見てみましょう。
##Explolerの表示は
見えました。
「share」という共有ポイントが一つありました。

当然、普通にアクセスできてNASのように利用することができました。
ちょっとだけプライベートなオンラインストレージが欲しいときにも利用できるかもしれませんね。
(グローバルIPでポート開放するというリスクがありますが)

次回はPowerShellによる各種管理機能を試してみたいと思います。