FSx for Windowsに入門するための構成
本ページはFSx for Windowsの入門ということで、WindowsインスタンスからFSx for Windowsストレージにアクセスするところまでを扱います。
構築する環境
2つのAZにプライベートサブネットを作成し、各サブネットにWindowsインスタンスを配置します。インスタンスのOSは最新のWindowsServer2019とします。
FSx for Windowsを作成し、両サブネットを関連付けます。
同様にAWS Managed Microsoft ADを作成し、2サブネットを関連付けます。後述しますが、FSx for WindowsはActive Directory(AD)と連携して動作するサービスであるためです。
SSMドキュメントAWS-JoinDirectoryServiceDomainを使用して、WindowsインスタンスをAWS Managed Microsoft ADのドメインに参加させます。
FSx for Windowsの動作検証ですが、以下の手順で実施します。
- 一方のEC2インスタンスから、FSx for Windowsで作成した共有フォルダにデータを書き込む。
- もう一方のEC2インスタンスから、書き込まれたファイルにアクセスできることを確認する。
環境構築用のCloudFormationテンプレートファイル
上記の構成をCloudFormationで構築します。
以下のURLにCloudFormationテンプレートを配置しました。
https://github.com/awstut-an-r/awstut-saa/tree/main/02/003
テンプレートファイルのポイント解説
今回の構成のための、各テンプレートファイルのポイントを取り上げます。
AWS Managed Microsoft ADとAWS-JoinDirectoryServiceDomainの要件を満たす
今回の構成では、AWS Managed Microsoft ADを使用します。またWindowsインスタンスをAWS Managed Microsoft ADのドメインに参加させるために、SSMドキュメントAWS-JoinDirectoryServiceDomainを使用します。
2サービスを使用する際のポイントは、おおよそ以下の3点です。
- AWS Managed Microsoft ADを2AZ内のサブネットにまたがるように配置する。
- Windowsインスタンスがインターネットにアクセスできるための経路を確保する。
- Windowsインスタンスに適切なIAMロール(AmazonSSMManagedInstanceCoreおよびAmazonSSMDirectoryServiceAccess)を用意する。
詳細は以下のページをご確認ください。
FSx for Windows用のセキュリティグループはSMBを許可する
ポイントとなるリソースは、セキュリティグループです。セキュリティグループはEC2インスタンス用と、FSx用を作成します。
Resources:
InstanceSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupName: !Sub ${Prefix}-InstanceSecurityGroup
GroupDescription: Deny All.
VpcId: !Ref VPC
FSxSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupName: !Sub ${Prefix}-FSxSecurityGroup
GroupDescription: Allow SMB from InstanceSecurityGroup.
VpcId: !Ref VPC
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: !Ref SMBPort
ToPort: !Ref SMBPort
SourceSecurityGroupId: !Ref InstanceSecurityGroup
Code language: YAML (yaml)FSx fow Windowsを中心とした通信要件は、Amazon VPC によるファイルシステムのアクセス制御に示されています。
EC2インスタンス(上記ページにおけるSMB client)およびFSx for Windowsにおいて、インバウンド通信に注目すると、以下に整理されます。
- EC2インスタンス：なし
- FSx for Windows：SMB ※ EC2インスタンスから
セキュリティグループは上記に沿って作成します。
1つ目がEC2インスタンス用のセキュリティグループです。本グループでは、許可するインバウンド通信を指定しません。今回の構成では、上記の通り、EC2インスタンスへのインバウンド通信が発生しないためです。
2つ目がFSx for Windows用のセキュリティグループです。本グループでは、上記の通り、インバウンドのSMB通信のみを指定します。送信元に、先述のEC2インスタンス用のセキュリティグループを指定することで、EC2インスタンスからのSMB通信のみを許可します。
マルチAZタイプのFSx for Windowsを作成する
FSx for Windows本体を確認します。
Resources:
FSxForWindows:
Type: AWS::FSx::FileSystem
Properties:
FileSystemType: WINDOWS
SecurityGroupIds:
- !Ref FSxSecurityGroup
StorageCapacity: !Ref StorageCapacity
StorageType: SSD
SubnetIds:
- !Ref PrivateSubnet1
- !Ref PrivateSubnet2
WindowsConfiguration:
ActiveDirectoryId: !Ref MSAD
DeploymentType: MULTI_AZ_1
PreferredSubnetId: !Ref PrivateSubnet1
ThroughputCapacity: !Ref ThroughputCapacity
Code language: YAML (yaml)FileSystemTypeプロパティで作成するFSxのタイプを指定します。今回はFSx for Windowsを作成しますので、「WINDOWS」を指定します。
StorageCapacityプロパティおよびStorageTypeプロパティでプロビジョニングするストレージに関して指定します。今回はSSDタイプで32GBを確保します。
SubnetIdsプロパティでFSxを紐づけるサブネットを指定します。先述の2つのサブネットを指定します。
WindowsConfigurationプロパティでFSx for Windowsに関するパラメータを指定します。
ActiveDirectoryIdプロパティでADを指定します。こちらは先述のAWS Managed Microsoft ADのIDを指定します。ADリソースを指定する理由は、FSx for WindowsがADと連携して動作するサービスであるためです。
Amazon FSx は、Microsoft Active Directory (AD) と連携して、既存の Microsoft Windows 環境と統合します。 (中略) Amazon FSx でファイルシステムを作成するときは、そのファイルシステムを Active Directory ドメインに参加して、ユーザー認証とファイルレベルおよびフォルダレベルのアクセス制御を行います。
Amazon FSx for Windows File Server でのMicrosoft Active Directory の使用
DeploymentTypeプロパティでAZへの配置タイプを指定します。今回はマルチAZで配置する予定ですので、「MULTI_AZ_1」を指定します。マルチAZ配置にとすることで、可用性が高まり、AZ単位の障害にも耐えられるようになります。
アベイラビリティーゾーンが利用できない場合でも、データに対して継続的な可用性を提供するように設計されています。マルチ AZ 配置では、Amazon FSx は異なるアベイラビリティーゾーンにスタンバイファイルサーバーが自動的にプロビジョニングされて維持されます。ファイルシステム内のディスクに書き込まれた変更は、同期的に Availability Zone 間でスタンバイにレプリケートされます。
可用性と耐久性: シングル AZ およびマルチ AZ ファイルシステム
PreferredSubnetIdプロパティで、通常時にFSx for Windowsが稼働するサブネットを指定します。今回は「PrivateSubnet1」を指定します。これで通常時はPrivateSubnet1側で動作し、障害発生時にPrivateSubnet2側で動作するという挙動となります。
ThroughputCapacityプロパティで、FSx for Windowsのスループットを指定します。
スループット容量は、ファイル・システムをホストするファイル・サーバがファイル・データを提供できる速度を決定する要因の 1 つです。スループットを上げると、1 秒あたりの I/O オペレーションのレベル (IOPS) が上がり、ファイルサーバにデータをキャッシュするためのメモリが増えます。
スループット容量の管理
8〜2048が指定可能ですが、今回は8(MB/s)を指定します。
環境構築
CloudFormationを使用して、本環境を構築し、実際の挙動を確認します。
CloudFormationスタックを作成し、スタック内のリソースを確認する
CloudFormationスタックを作成します。
スタックの作成および各スタックの確認方法については、以下のページをご確認ください
https://awstut.com/2021/12/02/cloudformation-nested-stacks/
各スタックのリソースを確認した結果、今回作成された主要リソースの情報は以下の通りです。
- インスタンス1のID：i-0cd9e7d57d0cc526f
- インスタンス2のID：i-089301f6bd45a53e2
- AWS Managed Microsoft ADのID：d-956709edaf
- ADのドメイン名：awstut.com
- ドメインAdminのパスワード：P@ssw0rd
- FSx for WindowsのID：fs-0c4a95b9f68ba3dc3
AWS Managed Microsoft ADの作成状況をAWS Management Consoleから確認します。
Directory DNS nameの値を見ると、ADのドメイン名が指定通りに設定されています。CloudFormationテンプレートで指定した通り、Subnetsが2つ指定されています。これに応じてDNS addressが2つ割り当てられています。
次にFSx for Windowsを確認します。
DNS nameの値は、作成されたFSx for Windowsに割り当てられたDNS名です。後ほどこの値を使用します。Preferred File Server IP Addressの値は、FSx for Windowsに割り当てられたIPアドレスです。今回は「amznfsxznwdb9ix.awstut.com」が割り当てられました。AWS Managed AD directory IDの値が、先に確認したADリソースのIDが指定されています。今回は「10.0.1.250」が割り当てられました。
SSM Session Manager経由でトンネリングアクセスしてモートデスクトップ接続でアクセスする
準備が整いましたので、1台目のWindowsインスタンスにアクセスします。
今回はSSM Session Manager経由でトンネリングアクセスして、モートデスクトップ接続でアクセスします。
SSM Session Managerに関する詳しい説明は以下のページをご確認ください。
まずインスタンスにアクセスするためのパスワードを確認します。
$ aws ec2 get-password-data \
--instance-id i-0cd9e7d57d0cc526f \
--priv-launch-key MyKeyPair.pem
{
"InstanceId": "i-0cd9e7d57d0cc526f",
"PasswordData": "lX6K2p7K2vZ2pd$Vn7BVy6McSU;riCo;"
}
Code language: Bash (bash)次にクライアント側で以下のコマンドを実行し、インスタンスに対してトンネリングアクセスを行います。
% aws ssm start-session \
--target i-0cd9e7d57d0cc526f \
--document-name AWS-StartPortForwardingSession \
--parameters "portNumber=3389, localPortNumber=13389"
Code language: Bash (bash)次にクライアント側でリモートデスクトップクライアントを起動し、localhost:13389向けにリモートデスクトップ接続を行います。
ユーザー名(Administrator)および先ほど確認したパスワードを使用してリモートデスクトップ接続します。
しばらく待つと、デスクトップが表示され、リモートデスクトップ接続が完了します。
WindowsインスタンスにFSx for Windowsをマウントする
ログイン後、FSx for Windowsをマウントします。
マウントはコマンドプロンプトから行います。FSx for Windowsをマウントするためには、同リソースのDNS名か、IPアドレスを指定します。どちらを使用できるかは、インスタンスのドメイン参加状況に依存します。FSx for Windowsと同一ドメインに参加済みであれば、DNS名でアクセス可能です。未参加の場合はIPアドレスでのみアクセス可能です。
まずコマンドプロンプトでFSx for WindowsのDNS名を名前解決してみます。
C:\Users\Administrator>nslookup amznfsxznwdb9ix.awstut.com
Server: awstut.com
Address: 10.0.1.71
Name: amznfsxznwdb9ix.awstut.com
Addresses: 10.0.1.250
10.0.2.184
Code language: DOS .bat (dos)DNSサーバのIPアドレスは、AWS Managed Microsoft ADのアドレス(10.0.1.71)です。これでインスタンスが同ADのドメインに参加していることがわかります。次に名前解決結果が「10.0.1.250」および「10.0.2.184」となりました。これらは今回作成したFSx for Windowsに割り当てられたアドレスです。
次に実際にFSx for Windowsをインスタンスにマウントします。
C:\Users\Administrator>net use H: \\amznfsxznwdb9ix.awstut.com\share
Enter the user name for 'amznfsxznwdb9ix.awstut.com': Admin@awstut.com
Enter the password for amznfsxznwdb9ix.awstut.com:
The command completed successfully.
Code language: DOS .bat (dos)マウント時にユーザー名とパスワードを入力します。今回の構成では、以下となります。
- ユーザー名：Admin@awstut.com
- パスワード：P@ssw0rd
マウントに成功すると、FSx for Windowsのストレージ領域が以下のように表示されます。
検証として、ファイルを1つ作成して設置します。
続いてInstance2に接続します。
同様の手順で接続を行います。そして同様の手順でFSx for Windowsをマウントします。
無事にマウントでき、Instance1で設置したファイルにアクセスすることができました。
まとめ
FSx for Windowsを作成し、Windowsインスタンスにマウントし、インスタンス間でデータを共有する方法を確認しました。
FSx for WindowsにDNS名でアクセスするためには、FSxとインスタンスが同一のドメインに参加している必要があることを確認しました。