Amazon Web Services ブログ
Amazon FSxへのファイルサーバーの移行とAWS Managed Microsoft Active Directoryとの統合
本投稿は Kyaw Soe Hlaingによる記事を翻訳したものです。
「Amazon FSx」は、Windowsベースのストレージ・ハイパフォーマンスコンピューティング（HPC）・機械学習・電子設計自動化（EDA）等といった多様な用途に堪える様々な機能を提供します。Amazon FSxを活用することによって、ハードウェアの調達・ソフトウェアの設定・パッチ適用・バックアップ等、時間と労力のかかる従来の運用作業を自動化することができます。豊富な機能に加え、クラウドネイティブな他のAWSサービスとも容易に統合できるため、幅広いワークロードにおいて便利に利用できます。
中でも「Amazon FSx for Windowsファイルサーバー」は、業界標準のServer Message Block（SMB）プロトコルで利用できるマネージドファイルストレージを提供します。実際にWindows Server上に構成されており、データ重複排除・ユーザーによるファイルのリストア・Microsoft Active Directory（AD）との統合等幅広い管理機能を備えています。
この記事ではADドメイン移行のシナリオにおいて、オンプレミスのファイル共有をAWS DataSyncを用いてどのようにAmazon FSxに移行できるかを説明していきたいと思います。多くのお客様がオンプレミスのADからAWS Managed Microsoft Active Directoryへの移行と同時に、ファイルサーバーもAmazon FSxに移行しています。
前提条件
この記事の内容を実施する前に、こちらのブログを参考にユーザーアカウントやグループをAWS Managed Microsoft ADに移行しておく必要があります。
実施手順
ADの移行手法には様々なものがありますが、一般的には下記の5つのステップで構成されます。
- オンプレミスのADとAWS Managed Microsoft AD間に双方向の信頼を設定する
- ADMT等のツールでユーザーアカウントとグループを移行する
- ファイルサーバー上のアクセス権限であるAccess Control List（ACL）を複製する
- AWS DataSyncを利用し、既存のACLを保ったままファイルとフォルダをAmazon FSxに移行する
- ユーザーの端末を移行する
この記事では、ACLの複製とAWS DataSyncによるファイルとフォルダの移行に焦点を当てます。ACLの複製には、Microsoftから提供されるSubInACLツールを活用します。
ACLを複製する理由は、移行後にもユーザーがシームレスに既存のファイルとフォルダにアクセスできるようにするためです。大規模の組織ではユーザー環境の移行は短期間では終わらせることは難しいため、フェーズを分けていくつかの段階を踏んで実施することが一般的です。ACLを複製することによって、移行後も移行前と変わらない方法でファイル共有にアクセスすることができます。
ACLの複製
ACLを複製する前に、まずはユーザーアカウントとグループの移行が完了していることを確認しなければなりません。今回のデモ環境では、既にオンプレミスのユーザーをAWS Managed Microsoft ADに移行完了しており、ユーザー名も変更せず従来のものを引き継いでいることを前提とします。
移行の過程でユーザー名を変更しなければならないケースも考えられますが、その場合はSubInACLの実行において適切な処理を追加する必要があります。詳細な手順やコマンドの利用方法に関しては、SubInACLのドキュメントをご参考ください。
下記のスクリーンショットの通り、今回はオンプレミスのAD（onprem.local）上に2つのユーザーアカウントが存在しており、同じユーザーをAWS Managed Microsoft AD（corp.example.com）側にも作成しています。
下記のスクリーンショットは、オンプレミスのファイルサーバーにて「HR_Documents」というフォルダを共有設定にしていることを表しています。同じフォルダにおいてもユーザーが異なればアクセス権も異なります。例えば、「John Smith」さんは「フルコントロール」権限を持っていますが、「Onprem User1」は「読み取りと実行」の権限しか持っていません。今回の設定の目的は、既存のオンプレミスのAD上のユーザーが持つ権限をAWS Managed Microsoft AD（corp.example.com）上に作成されたユーザーにもそのまま同様に引き継ぐことです。それによって、John Smithさんのアカウントが移行された後も今までの慣れた手順でAmazon FSx上のファイル共有にアクセスすることができるためです。
実際に「HR_Documents」フォルダのACLの内容を確認してみると、onprem.local上のユーザー二人がそれぞれ異なるアクセス権を持っていることが分かります。
続けて、SubInACLをオンプレミスのファイルサーバーにインストールします。SubInACLのインストールが完了すれば、デフォルトでは「C:\Program Files (x86)\Windows Resource Kits\Tools」フォルダ内に実行ファイルが配置されます。ACLの複製を行うためにはコマンドプロンプトを「管理者として実行」した後、下記のコマンドを実行します。
Subinacl /outputlog=C:\temp\HR_document_log.txt /errorlog=C:\temp\HR_document_Err_log.txt /Subdirectories C:\HR_Documents\* /migratetodomain=onprem=corp
上記のコマンドではいくつかの引数を指定しています。
- Outputlog=：通常の実行ログの出力先
- ErrorLog=：エラーログの出力先
- Subdirectories：すべてのファイルとサブフォルダに対して適用する
- Migratedomain=：移行元ドメインと移行先ドメインのNetBIOS名
コマンドが正しく実行されると、結果のサマリーが表示されます。エラーや失敗等がなければ、ACLが正しく複製されているか実際にファイルとフォルダのプロパティから確認してみましょう。デモ環境では、corp.example.comの同じアカウントに対するACLエントリが追加されていることを確認できました。
※移行対象のファイルとフォルダにおいて、onprem.localドメインのユーザーに対するものとcorp.example.comドメインのユーザーに対するもの、2通りのACLエントリが作成されます。
AWS DataSyncによるファイルとフォルダの移行
「AWS DataSync」は、オンプレミスのストレージとAmazon S3・Amazon Elastic File System・Amazon FSx for Windowsファイルサーバー等といったAWS上のストレージサービス間のデータ移行をサポートするオンラインデータ転送サービスです。手動作業に頼るデータ移行はマイグレーションプロジェクトにおける作業量とスケジュールに大変な負担になります。AWS DataSyncはデータのコピーと整合性検証・転送スケジュール管理と進捗監視・ネットワーク帯域利用の最適化等、データ移行に必要なほとんどの作業を自動化してくれます。
AWS DataSyncエージェントの作成
AWS DataSyncエージェントはオンプレミスのデータセンターに仮想マシンとしてデプロイできます。動作可能なハイパバイザー環境はESXi・KVM・Microsoft Hyper-Vです。AWS DataSyncエージェントはオンプレミス側のデータをAWS DataSyncサービスに向けて転送する役割を果たし、常に差分コピーを実施するため実際に変更のあったデータのみを効率的に転送します。
AWS DataSyncでは下記のプロトコルが移行元としてサポートされます。
- Network File System （NFS）
- Server Message Block （SMB）
この記事ではオンプレミスのWindowsファイルサーバーを移行元として想定しているため、SMBを移行元プロトコルとして利用します。AWS DataSyncでサポートされるSMBのバージョンは2.1と3.0です。
AWS DataSyncはファイルそのものと同時に各種メタデータや特殊ファイルもコピーします。SMBファイル共有からFSx for Windows File Serverへの移行の際には、下記のメタデータがコピーされます。
- ファイルのタイムスタンプ：アクセス日時・変更日時・作成日時
- ファイルのオーナーとグループのセキュリティ識別子（SID）
- ファイル属性
- NTFS随意アクセス制御リスト（DACL）：各オブジェクトに対するアクセス権を判別するためのアクセス制御エントリ（ACE）
AWS DataSyncによるデータ同期
AWS DataSyncのタスクは、開始されると複数のステップを踏んで同期を実施します。まずファイルシステムの調査から始まり、移行先へのデータの転送に進みます。転送が一旦完了すると、以降は定期的にデータの整合性を確認し不足しているデータを随時補う動きをします。詳細に関しては、データ同期の各ステータスに関するドキュメントをご参考ください。
DataSyncエンドポイント
下記のうちいずれかのエンドポイントタイプを利用し、エージェントを有効化することができます。
- パブリックエンドポイント：DataSyncエージェントからAWSに対する通信はすべてインターネットを介して行われます。
- 連邦情報処理標準（FIPS）エンドポイント：AWS GovCloud（US-East）またはAWS GovCloud（US-West）リージョンにアクセスする際にFIPS 140-2標準の暗号化モジュールを利用する必要がある場合は、このエンドポイントをご利用ください。このエンドポイントはAWS CLIまたはAPIを通じてアクセスできます。
- Virtual Private Cloud（VPC）エンドポイント：DataSyncエージェントからAWSサービスに対する通信はVPCエンドポイントを介して行われます。この方式ではオンプレミスのデータセンター・お客様の管理するVPC・AWSサービス間を行き交う通信の経路をすべてプライベートなものに限定できるため、より厳しいセキュリティ基準を満たすことができます。
今回のデモ環境では、AWS DataSyncを下記の図の通りに実装しています。DataSyncエージェントはオンプレミスのデータセンター内のVMware・Hyper-V・KVMいずれかのプラットフォーム上で実行できます。
DataSyncエージェントのインストールが完了し、移行元ファイルサーバーと移行先Amazon FSxを指定したタスクを追加できたら、以降はAWS管理コンソールからエージェントのステータスを確認することができます。
該当の「Task」を選択し、「Start」を押してファイルとフォルダの移行を開始させます（もしくは、1時間毎に自動実行される同期スケジュールを待つこともできます）。「History」タブからは今までのタスクの実行履歴を確認できます。
これでオンプレミスのファイルサーバーの中身をAmazon FSxに移行することができました。念の為に、移行先のファイル共有においてACLが問題なく保持されていることも確認しておきましょう。下記のスクリーンショットが表しているように、「Payroll」フォルダはオンプレミス側のユーザーとAWS Managed Microsoft AD側のユーザー両方のACLを保持したままとなっています。今後ユーザー端末もAWS Managed Microsoft ADに移行されれば、そちらのユーザーを利用してAmazon FSx上のファイル共有を従来通りにアクセスできるということになります。
クリーンアップ
もしここまでの手順に従ってご自身のAWSアカウント上に各種リソースを作成した場合は、そのまま従量課金が続いてしまうことを避けるためにリソースを削除しておきましょう。
- EC2インスタンス
- AWS Managed Microsoft AD
- Amazon FSxファイルシステム
- AWS DataSyncのタスク
まとめ
ここまで、Amazon FSxへの移行におけるファイルとフォルダのアクセス権（ACL）の複製手順を見てきました。この方式では、ユーザー端末がAWS Managed Microsoft ADに移行された後は単純にAmazon FSxを新しいネットワークドライブとしてマッピングすれば済むため、ユーザーにとってシームレスな移行になります。ネットワークドライブのマッピングはグループポリシー配布で自動化させることもできます。もし移行元のファイルサーバーに新しいファイルやフォルダが作成されれば、AWS DataSyncが自動的に差分を同期してくれます。
オンプレミスのADからAWS Managed Microsoft ADへの移行を検討する状況では、ファイルサーバーも同時に移行しなければならない場面が予想されます。なるべくシームレスな移行を実現するためにはファイルとフォルダのアクセス権に対する適切な処理が必要で、その手段としては今回ご紹介した「ACLの複製」や、「ADMTツールを利用したSIDの移行」等が考えられます。もしSID履歴を移行する場合は、SIDフィルターを一時的に無効化する必要があります。
翻訳はソリューションアーキテクトRyan Choが担当しました。原文はこちらです。