|
目次
|
お世話になっております、クロス・ヘッド 尾﨑です。
WindowsOSのファイルサーバーをクラウドに移行するとき、データの移行方法として真っ先に思いつくのは「robocopy」ですよね。Windowsに組み込まれたコマンドで信頼感もあります。
一方で、AWSでは「AWS Datasync」と呼ばれるデータ転送サービスが提供されています。選択肢があると、疑問に思ってしまいますよね。「AWSに移行するなら、AWS純正のDatasyncが良いのだろうか？」「Windowsのデータを移行するのだから、robocopyの方が良いのでは」等々。
今回はWindowsOSのファイルサーバーからAWS FSx環境にファイルデータを移行するケースを想定し、当社の検証結果に基づくパフォーマンス比較をご紹介させて頂きます。robocopyの実行コマンドオプションや、AWS DataSyncエージェントの導入方法についても、各セクションでご説明しながら進めてまいりますので、宜しければ最後までご確認頂ければと思います。
1.robocopyとは
robocopyはWindowsに標準搭載されているコマンドです。ファイルデータをある場所から別の場所にコピーします。正式にはRobust File Copyと呼ばれます。多彩なオプション指定が可能であり、データ移行においても強力なツールとなります。WindowsOSのファイルデータを移行する際には、真っ先に検討できると言える手段ではないでしょうか。標準搭載のコマンドですので、追加料金がかからない点も魅力です。
2.AWS DataSyncとは
AWSが提供するサービスで、オンプレミスにあるファイルまたはオブジェクトデータをオブジェクトストレージやファイルストレージサービスに移行するために利用できるデータ転送サービスです。データ転送機能を担うDataSyncエージェントは仮想アプライアンス形式で提供されており、主にはデータ移行対象が存在するオンプレミスの仮想基盤上にデプロイして利用することになります。
代表的な移行先として、Amazon S3やAmazon EFS、Amazon FSxが挙げられます。AWS DataSyncは従量課金型のサービスとなっており、コピーされたデータに対して0.0125USD/GBの料金がかかります。
※AWS DataSync料金はあくまでも2023年5月執筆時点の価格となります。詳細につきましては、最新のWEBサイト情報をご確認ください。
3.検証環境
検証環境の構成図はこちら。
- 各種サービスの詳細
・ Windowsファイルサーバーインスタンスの性能： m6i.large(2vCPU、メモリ8GiB)
・ Amazon FSx for Windows File Serverの性能： ストレージ2,000GiB(HDD)、32MB/sスループットキャパシティ
・ DataSyncエージェントの性能： m5.2xlarge(8vCPU、メモリ32GiB)
今回はデータ転送に関係する機能を全て同一VPC内で構成しました。robocopyの場合はAmazon FSxへ直接データをコピーし、DataSyncの場合はエージェントを経由してのコピー検証です。
- 移行対象のデータ
Windowsファイルサーバーのインスタンス上に1MBのファイルを50,000ファイル用意し、約50GBのデータ転送を実行する際の速度比較を行います。robocopy、DataSyncのオプション等については、後述の各セクションにて説明致します。
- 検証方法
初期同期と差分同期の2回に分けて時間を計測します。初期同期とは、データ移行先にデータが存在しない状態での最初のコピー作業。差分同期については、初期同期後にデータの変更分のみを同期することを指しています。データの更新がない場合の差分確認のみの所要時間と、実際にデータ更新があった場合の同期時間とをそれぞれ計測することにします。
4.robocopyでのデータ移行方法
まずはrobocopyコマンドの前提条件についておさらいしておきます。
4.1 実行コマンド
実行したコマンドはこちらです。
| robocopy [移行元共有フォルダパス] [移行先FSxのパス]/fft /ts /fp /e /COPY:DATSO /dcopy:T /np /it /r:3 /w:1 /purge /bytes /MT:32 /log |
それぞれのオプションの詳細は以下のとおりです。
| オプション | 説明 | |
| 1 | /fft | FAT ファイル時間 (2 秒の粒度) を仮定します。 |
| 2 | /ts | 出力にコピー元ファイルのタイム スタンプを含めます。 |
| 3 | /fp | 出力にファイルの完全なパス名を含めます。 |
| 4 | /e | 空のディレクトリを含むサブディレクトリをコピーします。 |
| 5 | /COPY:DATSO | 監査情報を除いたファイル情報をコピーします (Dデータ、A属性、Tタイムスタンプ、Sセキュリティ、O所有者情報、U監査情報) |
| 6 | /dcopy:T | ディレクトリのタイムスタンプをコピーします。 |
| 7 | /np | 進行状況なし – コピーの完了率を表示しません。 |
| 8 | /it | 属性のみを変更したファイルをコピーします。 |
| 9 | /r:3 /w:1 | コピー失敗時に1秒待機し、3回まで再試行します。 |
| 10 | /purge | コピー元に存在しないコピー先のファイル/ディレクトリを削除します。 |
| 11 | /bytes | ファイルサイズをバイト単位でログに出力します。 |
| 12 | /MT: | スレッド数を指定します。（デフォルト8） |
| 13 | /log: | 出力するログファイル名を指定します。 |
4.2 移行の確認方法
robocopyの場合はこの確認がやや苦労します。移行が無事に完了したかは、ユーザー責任で確認する必要があるためです。確認する方法の一例としては、転送後に転送元・転送先フォルダの比較をフリーツール等で行うことになります。今回の検証では50,000ファイルも存在するため、この確認作業には多くの時間がかかることが予想されます。
5.DataSyncでのデータ移行方法
5.1 DataSyncエージェント導入方法
DataSyncエージェントの導入手順は以下の通りとなります。基本的にはこちらのAWSドキュメントに従い、以降の作業を実施します。
① エージェントのAMI IDを特定する
今回はEC2インスタンスとしてエージェントを起動しますので、まずAMIを特定します。
まず、AWS CLIでコマンドを実行します。※東京リージョンを指定しました。
| aws ssm get-parameter –name /aws/service/datasync/ami –region ap-northeast-1 |
AMIIDを得ることができます。
| Parameter: ARN: arn:aws:ssm:ap-northeast-1::parameter/aws/service/datasync/ami DataType: text LastModifiedDate: ‘2023-05-03T22:39:16.808000+09:00’ Name: /aws/service/datasync/ami Type: String Value: ami-xxxxxxxxxxxxxxxx Version: 62 |
②AMIを起動
AWSコンソールから、先ほど特定したAMIを起動します。事前にVPCやサブネット等を選択する必要がありますので、ご注意ください。
③エージェントをAWSに接続
AWSマネジメントコンソールにサインインして、AWSへエージェントを接続します。
DataSyncコンソールから「エージェント」のページへ進み、「エージェントを作成する」を選択します。
今回はEC2としてデプロイしたため、ハイパーバイザーは「Amazon EC2」を選択します。
エンドポイントタイプについてはよりセキュアな「VPCエンドポイント」を選択します。※「datasync」サービスのVPCエンドポイントは事前に作成しておきます。
アクティベーションキーはエージェントから自動的に取得する方法を取りますので、エージェントのプライベートIPアドレスを入力します。
「キーを取得する」を選択すると画面が遷移し、アクティベーションキー取得成功の旨が表示されます。
あとはエージェントに任意の名前を付けて「エージェントを作成する」ボタンを押せば、無事作業完了です！
あとは、送信元(ファイルサーバ)と送信先(FSx)のロケーションと呼ばれるリソースをコンソール上で作成し、それらを指定したタスクを設定して「開始」すれば、データの同期が実行されます。
送信元・送信先双方にアクセスできるユーザーを用意しておくことを忘れないでください。(ここでは「migration」というユーザーを使用しています。)
5.2 データ検証オプション
DataSyncでは、転送したデータに対する検証方法について3つのオプションが用意されています。
一つ目は「転送中の整合性を確認する(転送後に追加の検証を実行しない)」、二つ目は「転送されたデータのみを確認する(転送後に、転送されたファイルのチェックサムを確認)」、三つ目は「送信先のすべてのデータを確認する(転送後に、送信元と送信先が完全に同期されているか確認)」です。推奨とされているものは二つ目になります。今回はそれぞれのパターンによるデータ移行完了までの時間を見てみましょう。
5.3 移行の確認方法
タスクの実行ステータスを見ると、「起動中」→「準備中」→「転送中」→「検証中」といったように遷移していきます。※前述のデータ検証オプション次第では、「検証中」ステータスはスキップされます。
実行ステータスが「成功」になれば、データの同期が完了したことを意味します。
「失敗」の場合は何かしら問題が起きていますので、調査が必要になります。
タスクの実行ごとにCloudWatchLogsにログをしてくれますので活用しましょう。
※こちらは実行ユーザーに共有フォルダへのアクセス権限が不足していた例です。
6.検証結果
さて、それでは前述までの条件の元で、それぞれの検証を実施致しました。その結果を表形式で見てみましょう。
6.1 パフォーマンス比較
| 同期内容 | Robocopy | DataSync | |||
| 転送中の整合性を確認 | 転送されたデータのみを確認 | 送信先のすべてのデータを確認 | |||
| 初期同期 | 1回目 | 23分20秒 | 15分59秒 | 45分20秒 | 50分29秒 |
| 2回目 | 20分22秒 | 20分31秒 | 28分58秒 | 33分57秒 | |
| 3回目 | 17分48秒 | 13分37秒 | 29分03秒 | 32分09秒 | |
| 差分 (更新なし) |
1回目 | 1秒 | 04分40秒 | 04分43秒 | 22分48秒 |
| 2回目 | 1秒 | 06分02秒 | 06分36秒 | 23分22秒 | |
| 3回目 | 1秒 | 00分40秒 | 04分57秒 | 23分14秒 | |
| 差分 (1MB×10,000ファイル更新) |
1回目 | 07分03秒 | 11分40秒 | 15分36秒 | 29分48秒 |
| 2回目 | 07分59秒 | 10分55秒 | 16分48秒 | 33分21秒 | |
| 3回目 | 07分48秒 | 11分23秒 | 17分54秒 | 30分24秒 | |
単純な比較は難しいですが、データ転送に関してだけでいえばRobocopyよりもDataSyncのほうがやや早いという結果になりました。さらに、Robocopyが開始時の差分確認後はひたすら転送するのみであるのに対し、DataSyncでは時間はかかるもののオプションの設定次第で検証も自動的に実施してくれます。Robocopy+別ツールで検証を実施する場合の労力や工数を考えると、DataSyncは有力な選択肢として検討の価値があると言えるでしょう。
7.まとめ
如何でしたでしょうか。あくまでも参考情報となりますが、本記事がお役に立てば幸いです。
実際には移行元のデータ容量やファイル数だけでなく、通信回線の速度等の様々な影響を受けてデータ移行を実施することになります。これらのデータ移行にまつわる様々な属性を考慮して計画を立てることは大変ですよね。
当社ではファイルサーバーのデータを移行する際に、環境診断と調査レポートを提供するアセスメントサービスに加えて、適切な環境へのデータ移行を実現するためのサービス「デジタル・ワゴン」を展開しております。
環境の調査から実施したい、実際のデータ移行についてPoCを行ってみたい等のご要望がございましたら、是非気軽にご相談ください
クロス・ヘッド関連サービス
※Cloud Compassはクロス・ヘッド㈱が運営するクラウドサービスです。
