【AWS】Amazon FSx for Windows File Server触ってみた
どうも、今回初めての技術記事を書くカフィです。
AWSのSAPの勉強をしていると「FSx」ってなんだ？？？となり間違え、実際に触ってみたので備忘録として残します。
Amazon FSx for Windows File Server とは
完全にネイティブな Windows ファイルシステムに支えられた、フルマネージド Microsoft Windows ファイルサーバーを提供します。（AWS公式ドキュメント参照）
- Windowsファイルサーバとは
ファイルサーバーとは、ファイル共有機能に特化したサーバー。
(参照)
検証概要
検証内容は以下サイトを用いて行いました。
検証結果
一旦記事通りにできました！！！！
追加で、、、、
一旦記事通りにできたものの、あれ、リブートすると認証毎回聞かれる、、、、
なんでだ、、、、
となったので、解消点も一応記載しておきます。
結論からお伝えするとマウント時に
「/persistent:(yes:no)」
のコマンドが足りていなかったことが問題でした。
-net usecommand — [] を使用した場合を除いて、複数のシステム再起動をまたいでは保持されません。/persistent:(yes:no)スイッチ。(参照)
「Amazon FSx for Windows File Server を最低限の手順で構築してみた」サイトの以下箇所を読み替えて頂ければ、解消可能となります。
解消前：
net use Z: \\amznfsxsmvf3f0i.hayakawa.local\share
解消後：
net use Z: \\amznfsxsmvf3f0i.hayakawa.local\share /persistent:yes
再度設定し直すと、毎回認証は聞かれなくなりました！
※意外と同じ場所で引っかかる方多いかもと勝手ながら個人的に思いましたので、、、
追加で公式ドキュメントに記載のコマンドも載せておきます。(AWS公式ドキュメント)
net use WindowsDriveLetter: \\GatewayIPAddress\FileShareName /persistent:yes
残った疑問点
作ってみたものは良いものの、実際に導入し運用していくことを考えた時に以下の疑問点が出ました。
- 通常時使用しているADへのドメイン参加は？
- 本来使用したいDNSサーバへの宛先を設定することができない？
疑問点への解消予測
- 通常時使用しているADへのドメイン参加は？
これは痛い。。。。
ただ様々な記事を見て、ファイルサーバを使用する上で一般的な考え方だということがわかりました。
そのため、AWSのマネージドサービス構成で構築するならしょうがない制約になるなと。
この考え方を踏まえて、上記検証構成で構築していくとなると「ADサーバの２台構成・管理・運用」が伴ってくるなと、、、、他のAWSのADサービスを使用することで解決できるのであろうか。
※これ以上深掘りすると今日はメンタル持たなさそうなので、後日調べてみます。。。
- 本来使用したいDNSサーバへの宛先を設定することができない？
ここは、以下の流れで整理したら解消されているのではと考えました。
- ADサーバのDNSを設定するという考えは一般的である
- ということは他のリソース群への名前解決もできるようにAWSはもちろん作り込んでくれているだろう
- ADサーバのDNSが名前解決できない範囲は、AWSのDNSが解決できるようにしてくれているはず
- 通常時VPCへデフォルトで設定されているDHCPのリソース、つまり「AmazonProvidedDNS」へフォワード設定が入っているはず
- これで各AWSサービスへの名前解決やグローバルNW環境への名前解決がFSxを使用するサーバ（EC2）から行えるはず
この仮説が正しくないと使い勝手が悪い気がします。そして使われないサービスになりそうかなと。。。。
ただこの仮説通りであれば、名前解決問題は解消し、ハイブリッドクラウド構成でも「Route 53 Resolver」を使用すれば難なく対応可能だなと考えました。
※こちらもどこかで「Route 53 Resolver」と別DNSサーバを用意して実際に試してみたいなと考えています。
終わりに
一旦疑問点や課題点は残りましたが、実際に試してみたことにより少しはサービス自体の実態を掴めた気がします。近いうちに疑問点は解消していきたいと思います。
引き続きまったりと勉強していきたいと思います！
Discussion