FileサーバーをAWSに移行してみた　FSx for Windows移行

mochizuki.t

はじめに

皆様お疲れ様です。
オンプレミス環境からAWS環境にFileサーバーを移行して行きます。
オンプレミス環境内の共有FileサーバーはWindowsサーバーで動いています。
Windowsサーバーで構築したFileサーバーをAWSへ移行する際に真っ先に思い浮かぶのが「FSx for Windows」ですよね。
オンプレミスからFileサーバー移行する際に、要件にあったAWSのストレージサービスを選ぶことが大事かと思います。

  • Amazon S3
  • Amazon EBS
  • Amazon FSx
  • AWS Snow Family
  • on EC2
    などがあります。
    代表的なFSxとon EC2の比較を下記に記載します。
FSx for Windows on EC2
メリット 簡単な管理: FSx for Windowsは管理が容易で、AWSがサービスのメンテナンスやバックアップを行うため、管理の手間が少なくなります。
高可用性: FSx for WindowsはマルチAZ展開が可能であり、データの冗長性と可用性が高いです。
パフォーマンス: FSx for WindowsはSSDストレージを使用し、高いパフォーマンスを提供します。
セキュリティ: FSx for WindowsはAWSのセキュリティモデルに従っており、データの保護が確保されます。		 柔軟性: EC2インスタンスを使用すると、OSやファイルシステム、アプリケーションを完全に制御できます。
コスト: EC2インスタンスは、必要に応じて選択できるため、使用状況に応じてコストを最適化できます。
デメリット コスト: EC2インスタンスに比べて、FSx for Windowsはより高価な場合があります。
柔軟性の制限: FSx for Windowsは管理がAWSに委託されているため、カスタマイズや特定のニーズに対する柔軟性が制限される場合があります。		 管理の負担: EC2インスタンスの管理は、セキュリティパッチの適用やバックアップなどのタスクが含まれるため、管理の手間がかかります。
可用性の制限: 単一のEC2インスタンスを使用する場合、可用性が低くなる可能性があります。
コスト
(シングルAZ、Site to Site VPNなどのネットワーク関係はコストから省きます)		 シングルAZ
ストレージタイプ-HDD
ストレージ容量-2TB
バックアップストレージ-3TB

113.42USD

 EC2(Windows,m6a.larges,ストレージ(gp3-30GB))
EBS(ブロックストレージ(ST1-2TB),スナップショット(3TB)

414.835USD

コストに関して下記サイトを参考にしました。
「Windows ファイルサーバーを AWS クラウドで構築 （入門編）」

「AWS Pricing Calculator」

今回はFSx for Windowsを使用して移行していきます。

要件・構成図・目次

要件、構成図を下記に記載しております。
今回はDataSyncを用いて移行していきます。
FSxとDataSyncエージェントの作成は前後しても構いません。移行の際にDataSyncエージェントが必要になるので、移行前に作成していただければスムーズにいくのかなと思います。
FSx、DataSyncエージェント作成後にDataSyncのロケーション・タスクを設定して移行という流れになります。
私は、流れがつかみやすいように下記の目次の順で作成していきました。

要件

  • オンプレミス環境は既存の環境。
  • Site to SiteVPN接続は構築済み。
  • AWS環境も既存の環境を使用。
  • AWS環境で使用するFileサーバーはFSx for Windows。
  • 移行はDataSyncを使用。
  • FSx、オンプレミスサーバー共にActive Directory Server on EC2のAD参加している。

構成図

構成図はこちらになります。
file

目次

  1. FSx for Windowsの構築
  2. DataSyncエージェントの作成
  3. Fileサーバーの移行
  4. 移行検証
  5. AD信頼関係構築後の作業
  6. まとめ
  7. 参考

FSx for Windowsの構築

それではさっそく構築していきたいと思います。

セキュリティグループの作成

セキュリティグループの設定方法は「AWS Managed Microsoft AD移行」をご確認ください。

FSxのセキュリティグループは下記のインバウンド/アウトバウンドルールを設定する必要があります。

プロトコル ポート ロール
TCP/UDP 53 DNS
TCP/UDP 88 Kerberos
TCP/UDP 389 LDAP
TCP/UDP 464 Kerberosパスワードの変更/設定
TCP/UDP 2049 NFS
TCP 123 NTP
TCP 135 レプリケーション
TCP 445 SMB/CIFS
TCP 636 LDAP SSL
TCP 3268-3269 LDAP GCおよびLDAP GC SSL
TCP 9389 Microsoft AD DS Webサービス、PowerShell
TCP 49152-65535 RPC

アウトバンドルールでAWS Managed Microsoft ADのセキュリティグループも追加します。

FSx for Windowsの構築

FSxのコンソール画面から「ファイルシステム」→「ファイルシステムの作成」を押下。
file

ファイルシステムのオプションから「Amazon FSx for Windows ファイルサーバー」を選択し次へ。
file

作成方法-任意。

ファイルシステムの詳細で、ファイルシステム名-任意、デプロイタイプ-任意、ストレージタイプ-「SSD」、ストレージ容量-任意、プロビジョンドSSD IOPS-「自動」、スループットキャパシティ-任意。

ネットワークとセキュリティは、VPC-作成したもの、VPCのセキュリティグループ-先ほど作成したもの、推奨サブネット・スタンバイサブネット-任意。

Windows認証で、「自己管理型 Microsoft AD」を選択、オンプレミスのドメイン名・IPアドレス・ユーザーアカウント名・ユーザーアカウントのパスワードを入力。オプション-任意。

暗号化-任意。

その他のオプション-任意で次へ。

file

確認画面で間違いなければ「ファイルシステムの作成」を押下。

Windows Server用のEC2の作成

「AWS Managed Microsoft AD移行」で作成したものと同様のEC2を作成します。
ただし、ドメイン結合ディレクトリは設定せずに作成します。

DataSyncエージェントの作成

AWS環境外のオンプレミスなどからAWS環境にデータを移行する際には、必ずDataSyncエージェントが必要になってきます。
DataSyncエージェント→DataSyncロケーション→DataSyncタスク実行の順序で作業を行うので、その順序で書き綴らせていただきます。

DataSyncエージェントの作成

DataSyncエージェントは、VMWare/カーネルベースの仮想マシン/EC2/Microsoft Hyper-vでデプロイできます。
今回はVMWareで建てたところ落ちてしまったので、EC2にデプロイする方法を説明していきます。

サービスにアタッチするセキュリティグループの作成

VPCエンドポイント、DataSyncエージェントのセキュリティグループを作成します。

要件はこちらのAWS公式ドキュメントから参照ください。

VPCエンドポイントの作成

今回は外部には出ずVPNを使用してデータ移行をするので、AWSの公開エンドポイントは使用せず作成したものを使用します。

VPCコンソール画面の左ペインから「エンドポイント」→「エンドポイントを作成」を押下。
file

サービスカテゴリで「AWSのサービス」を選択、サービスで「DataSync」と入力し出てきたサービスを選択し、VPCを作成したものを選択し「エンドポイントを作成」を押下して完了。
file

作成したエンドポイントを選択、「アクション」→「セキュリティグループの管理」を押下。
file

VPCエンドポイント用のセキュリティグループを選択し、「セキュリティグループの変更」を押下。

DataSyncエージェントのデプロイ

最初にこのコマンドをAWS CLIで流し、最新のDataSync AMIのIDを確認します。

aws ssm get-parameter --name /aws/service/datasync/ami --region region

（最後のregion部分を構築するリージョンに変更して流してください。）

例）
file

EC2コンソール画面から「インスタンスを起動」を押下。

AMIイメージの検索バーに、取得したDataSyncAMIイメージを張り付け検索します。

画面が遷移しますので、「コミュニティAMI」に1つだけAMIが出てきますのでそちらを選択し画面が再遷移します。
file

インスタンスタイプは要件があり、
・m5.2xlaarge
最大2000万個のファイルを転送するタスク
・m5.4xlaarge
2000万個を超えるファイルを転送するタスク
（もう1つあるのですが、Snowcone用なので割愛します。）
この要件に照らし合わせながら選んでください。

・キーペア-既存または新規作成したもの
・VPC-作成したものを
・サブネット-FSxと同じ
・パブリックIPの自動割り当て-有効化
・セキュリティグループ-エージェント用に作成したもの
そのほかはデフォルトのまま「インスタンスを起動」を押下。

DataSyncエージェント作成

DataSyncのコンソール画面左ペインから「エージェント」→「エージェントを作成する」を押下。
file

エージェントをデプロイするウィンドウのプルダウンから「EC2」を選択。
file

エンドポイントを作成したもの、アクティベーションキーを「エージェントからアクティベーションキーを自動的に取得する」を選択し、アドレス欄にエージェントEC2のパブリックIPを入力し「キーを取得する」を押下。
file

取得できたら、エージェントの名前やタグを入力して「エージェントを作成」を押下して完了。

Fileサーバーの移行

共有ファイルサーバーをFSxに移行していきます。
ロケーションはファイルの場所を指しています。ロケーションだけ作成してタスク作成時に指定しても、タスク作成時にロケーションを作成してもどちらでも大丈夫です。

タスクの設定

DataSyncコンソール画面から、「タスク」→「タスクを作成する」を押下。
file

送信元のロケーションのオプションで「新しいロケーションを作成する」を選択、
設定のロケーションタイプで「ネットワークファイルシステム」を選択、
エージェントで作成したエージェントを選択、
NFSサーバーでIPアドレスを入力、
マウントパスで、NFSサーバーの移行したいファイルを入力し次へを押下。
file

送信先のロケーションのオプションで「新しいロケーションを作成する」を選択、
設定のロケーションタイプで「FSx」を選択、
共有名で、FSxの移行先ファイルを入力し次へ、
セキュリティグループで（FSxのセキュリティグループへの接続を許可したセキュリティグループを作成しておく）作成したセキュリティグループを選択、
ユーザー設定のユーザーでアクセス許可を持つユーザーを入力、
パスワードでユーザーのパスワードを入力、
ドメインでFSxサーバーのドメインを入力し次へ。
file

タスク名を任意、
Source data optionsはデフォルトのまま、
Transfer optionsのTransfer modeは「Transfer all data」を選択し、
そのほかはデフォルトのまま次へを押下。
file

確認画面で間違いなければ「タスクを作成する」を押下して完了。

タスクの実行

DataSyncのコンソール画面から、作成したタスクを選択して「アクション」→「開始」を押下してタスクを実行する。
file

ステータスが成功になれば完了。

移行検証

今回の移行で移行したフォルダはこちらになります。
CPI.Localの中にテキストファイルとバックアップを入れております。
file

EC2からFSxへアクセスするとこちらの通りテキストとバックアップが表示されました。
file

AD信頼関係構築後の作業

ADの信頼関係構築後の作業になるのですが、上記で作成したEC2をオンプレミスのドメインに参加させ、FSxからファイルを参照するために、マッピングを行います。

マッピング方法

まず作成したEC2に入り、「エクスプローラー」→左ペインから「ネットワーク」を右クリック→「ネットワークドライブの割り当て」を押下。
file

割り当てるドライブを選択し、フォルダーには「\\＜FSxのDNS名＞\share」を入力し、参照を押下。
file

フォルダーを選択し「OK」を押下、「サインイン時に再接続する」にチェックを入れ完了を押下。

これでFSxの共有ファイルを他のデバイスから開くことができます。

まとめ

FSx for Windowsの構築が完了いたしました。
AWS Managed Microsoft ADよりもスムーズに構築できたのではないでしょうか。
今回はオンプレミスのドメインを使用することが前提だったので、Windows認証でオンプレミスのドメインを使用しました。
新規で構築される方は、AWS Microsoft Managed ADのドメイン名で良いかと思います。
おわり！！

参考

AWSドキュメント
「AWS Data Sync 要件」

「Amazon FSx for Windows File Server」

「Amazon FSxへのファイルサーバーの移行とAWS Managed Microsoft Active Directoryとの統合」

Last modified: 2024-05-23

Author