はじめに

みなさんDataSyncをご存知でしょうか？

恥ずかしながらつい2ヶ月ほど前は「データ転送ができるいい感じのサービス」程度の知識しかなかったのですが、案件にて使用した際に、情報の少なさも相まってかなり苦戦しました。

ネット上には完全AWS上での検証記事はちょこちょこみられたのですが、今回はオンプレミスに対して導入を行ったので、AWS上の検証だと見えてこない懸念点やつまずきポイントなども紹介します。

本記事では主に以下を記載します。

  • DataSyncとは？
  • データ転送手順
  • DataSyncタスクの挙動
  • DataSyncを使用する際の注意点・問題点
  • 参考になった公式ドキュメント・ブログ

なお、本記事ではDataSync以外のリソースについての解説はしませんのでご了承ください。
 

DataSyncとは？

オンプレミスやAWS・GC・Azure上にあるデータをAWSのストレージサービス(S3・EFS・FSx)にデータを転送することのできるサービスです。

自動的に4つ(エージェントレスの場合は0または2つ)のENIを作成しAWS設計の転送プロトコルを使用して転送を行うほか、差分検知や転送検証も行ってくれるため、安全かつスピーディにデータ転送を行うことができます。
AWS DataSync の特徴

データ転送手順

DataSyncによってデータを転送できるようにするためには大きく分けて下記5つの手順を踏む必要があります。

  • DataSyncエージェントインストール(特定の条件※を満たすAWSリソース間での転送の場合は不要)
  • DataSyncまでの通信設定
  • DataSyncエージェントアクティベーション
  • ロケーション作成
  • タスク作成

※ DataSyncエージェントが不要となる条件

エージェントを必要としない状況は、 同じ AWS リージョン内で転送する場合でも、リージョン間で転送する場合でも適用されます。
・同じ AWS アカウント内の AWS ストレージサービス間での転送
・AWS アカウント間で S3 バケットと別の AWS ストレージサービス間の転送

AWS DataSync エージェントは必要ですか_ – AWS DataSync

なお、今回は下記構成図のようにEFSからS3に転送しており、本来であればエージェントは必要ありませんが、検証のためあえて使用しています。

 

1. DataSyncエージェントインストール

オンプレミスからデータ転送を行う際にはDataSyncエージェントのインストールを行っておきます。
DataSyncエージェントイメージは下記のようにしてダウンロードできます。

ダウンロード前にハイパーバイザー欄を使用する環境に合わせておいてください。

今回の検証ではEC2を使用するためインストールの詳細は省略しますが、実際の案件ではLinuxにKVMの導入から行っていきました。
その際に大いに役に立ったのは下記の公式ブログです。
AWS DataSync agent on Linux KVM Hypervisor _ AWS Storage Blog

実際に画像付きでエージェント導入手順を紹介してくれているため、検証で仮想環境が用意しづらい状態下ではかなり助かりました。

ただし、導入にあたって事前に考慮しておかないといけないつまずきポイントがいくつかあります。

つまずきポイントその1

DataSyncをインストールするサーバにはVMWareやKVM、Microsoft Hyper-Vのいずれかの仮想環境を用意しておく必要がある
AWS DataSyncエージェント要件 – AWS DataSync

仮想環境がインストールされていないサーバなら事前に導入しておく必要があるのですが、オンプレミスからファイル転送を行う場合というのは既に本番運用されている場合がほとんどだと思います。
そのため、上手く導入することができず失敗したときのリスクを考えると、この時点で導入コストがかなり高いことがわかります。

つまずきポイントその2

仮想環境自体の要求スペックがかなり高い

  • vCPU：4コア以上
  • ディスク容量：空き容量80GB以上
  • RAM：2000万ファイルまでなら32 GB、それ以上のファイル数なら64 GB

AWS DataSyncエージェント要件 – AWS DataSync

上記はホストマシンそのもののスペックではなく、あくまでも仮想環境に割り当てるスペックになります。
vCPUやディスク容量はまだしも、メモリ量は結構要求してきています。

※注意※

  • DataSyncをインストールするサーバはストレージサーバにアクセスできるサーバになります。
    (ストレージサーバそのものにはインストールしません！)
  • DataSyncエージェントは仮想アプライアンスのため、用意した仮想環境に仮想OSをインストールしておく必要はありません。

実は既にDataSyncエージェントをプリインストールしたAMIがAWSから公開されており、下記コマンドから取得できます。

aws ssm get-parameter --name /aws/service/datasync/ami --region <リージョン名>

エージェントをデプロイしてください。AWS DataSync – AWS DataSync

そのためオンプレミス環境にインストールできないのであればこれを使えば良いと思いがちですが、余計なリクエスト増による通信コストや通信遅延の観点からAWS的にはストレージサーバにより近いところで導入することを推奨しています。そのため、選択肢としては挙げづらいという事情もあったりします・・・

上記よりどうしてもオンプレミス機器にDataSyncエージェントの導入が難しいのであれば、下記のような選択肢になると思います。

  • Snowconeを用いたDataSyncによる転送
  • DataSyncエージェントがプリインストールされたEC2インスタンスを用いた転送(非推奨)
  • DataSync以外でのデータ転送

DataSyncなかなか手強い・・・
 

2. DataSyncまでの通信設定

オンプレミスからDataSyncまでの通信経路について、パブリックエンドポイントかVPCエンドポイント(一部リージョンではFIPSエンドポイント)を選択します。
こちらも多くの場合パブリックにすることはないと思うため、今回はVPCエンドポイントを使用した接続を行います。

下記AWS公式ドキュメントにしたがって、VPCエンドポイントのセキュリティグループにいくつか許可ルールを追加しておきます。
AWS DataSyncネットワーク要件 – AWS DataSync

ソース プロトコル ポート 用途
DataSyncエージェント TCP 1024-1064 コントロールプレーントラフィック用
DataSyncエージェント TCP 443 データプレーントラフィック用
DataSyncエージェント TCP 22 AWSサポートによるトラブルシューティング用
(普段は使用しません)

※ 注意 ※

  • 通常はソースにDataSyncエージェントのIPアドレスを指定すればよいですが、VPNや専用線でAWSと接続している場合にオンプレミスルータのNAT機能が有効になっているとその限りではないことがあります。
    今回の案件ではそのケースに該当しており、Site-to-Site VPNの内部トンネルIPで通信されていました。
    どのIPで通信されているのか確認したうえで設定してください。
  • VPCエンドポイントの説明にPrivateLinkと記載があることがありますが、内部的にPrivateLinkを使用しているだけで新規にPrivateLinkの設定をする必要はありません。
     

3. DataSyncエージェントアクティベーション

DataSyncエージェントのインストールが完了すると、下記のようなDataSyncエージェントコンソールにログインできるようになります。
オンプレミスのホストサーバからログインする際の初期ID、パスワードはそれぞれadmin、passwordです。
AWS DataSyncエージェントのローカルコンソールでの作業 – AWS DataSync
(EC2の場合もadminユーザとしてSSH接続をすると自動的に表示されます)

AWS DataSync Activation - Configuration

#######################################################################
## Currently connected network adapters:
##
## eth0: 10.0.1.86
#######################################################################

1: Network Configuration
2: Test Network Connectivity
3: Test Connectivity to Self-Managed Storage
4: View System Resource Check (0 Errors)
5: Command Prompt
6: Upload agent logs via pre-signed S3 URL

0: Get activation key

Press "x" to exit session

Enter command:

※重要※
この画面から下記操作を行っておくことを推奨します。

  • 5を選択後、passwdコマンドからパスワードを変更する(通常のbashでのpasswdと使用方法は同じ)
  • 2や3を選択後、AWSやストレージサーバとの接続テストを実施

AWSとの接続テスト

AWS DataSync Activation - Test Network Connectivity

Choose the service endpoint type that this agent will connect to:

1: Public endpoints
2: FIPS endpoints
3: VPC Endpoints using AWS PrivateLink

Press "x" to exit

Select service endpoint type or exit: 3

Private IPv4 address of VPC endpoint: 172.168.0.153

Connectivity Test Results - VPC endpoints

> 172.168.0.153:443
[ SSL TEST: PASSED ]
[ NETWORK TEST: PASSED ]
> 172.168.0.153:1024-1064
[ NETWORK TEST: PASSED ]
> xxx.xxx.xxx.xxx(SUPPORT_CHANNEL_ENDPOINT):22
[ NETWORK TEST: PASSED ]

Press return to continue

ストレージサーバ(EFS)との接続テスト

AWS DataSync - Test Connectivity to Self-Managed Storage

Choose the location type for the connectivity test:

1: NFS server
2: SMB server
3: Object storage
4: HDFS
5: Azure Blob

Press "x" to exit

Select location type or exit: 1

IPv4 or NFS server name: 10.0.1.217

Connectivity Test Results

> 10.0.1.217:2049
[ PASSED ]

Press return to continue

上記まで完了したら、次はAWSマネジメントコンソールを操作してアクティベーションを行う必要があります。

アクティベーションの方法は自動入力と手動入力の2種類用意されています。
「それなら自動入力でええやん」と飛びつきたくなるのですが、ここにもつまずきポイントがありました・・・

つまずきポイントその3

自動アクティベーションを行うにはAWSとインターネットを介してhttp通信を行う必要がある

インターネット経由でhttp通信を許可できるようなオンプレミス環境はそうはないと思われるので、セキュリティ的にこの選択肢は取れないと思います。

そうなると必然的に手動取得せざるを得ないという。

そのため、DataSyncエージェントコンソールから0を選択して、アクティベーションコードを発行してアクティベーションを行います。

Get activation key

Enter AWS Region (e.g. us-east-1): us-east-1

Choose the service endpoint type that this agent will connect to:

1: Public endpoints
2: FIPS endpoints
3: VPC Endpoints using AWS PrivateLink

Press "x" to exit

Select service endpoint type or exit: 3

Private IPv4 address of VPC endpoint: 172.168.0.153

Activation key: xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

Press return to continue

※注意※
発行したアクティベーションコードは30分経過で有効期限切れとなります。
AWS DataSyncエージェントを有効化します。 – AWS DataSync

通信経路に問題がなければ下記のように作成され、エージェントのステータスがオンラインになっていることが確認できます。

 

4. ロケーション作成

アクティベーションが完了したら転送元と転送先の2つのロケーションを作成します。

※ 注意 ※
オンプレミスの場合には特にリージョンの変更をする必要はないですが、AWSのみで完結する転送 かつ リージョンが異なる場合には各リソースの存在するリージョンでロケーションを作成する必要があります。

今回は内部的にエージェントレスで動作するため、EFSのロケーションを作成時に2個、S3のロケーション作成時には0個で計2個のENIが自動作成されていることが確認できました。
AWS DataSyncネットワーク要件 – AWS DataSync

 

5. タスク作成

ロケーション作成が完了したらタスクを作成します。
なお、タスクの場合だとリージョンは特に指定がないので、管理しやすいリージョンで作成すれば問題ありません。

 

フィルター設定

タスク作成時にincludesやexcludesフィルターをかけて転送するディレクトリ・ファイルの指定をすることができます。
他の設定項目は基本名前の通りなのですが、このフィルター設定のみは少し注意が必要です。

パスについて

フィルター設定に記載するパスはマウントパスからみた相対パスになります。

絶対パスを記載しても内部的には相対パスとして判断されているので、大体は「そんなディレクトリ無い」とみなされ何も転送されずにタスクが終了してしまいます。
 

includes・excludesフィルターの挙動

includes・excludesフィルターの動きを見るために下記状況を設定します。

実験1
  • マウントパスは/を指定
  • ディレクトリ構成は下記
$ tree
.
├── test.txt
├── testdir_1
│ └── testfile.size2GiB
├── testdir_2
│ ├── testfile.size10GiB
│ └── testfile.size4GiB
├── testfile.size1GiB
└── testfile.size3GiB
  • ディレクトリ testdir_1 と testdir_2 のみを転送

この場合はincludesに /testdir_1/* と /testdir_2/* を指定するだけで良く、特にexcludesフィルターで何かを指定する必要はありません。

ちゃんと指定したディレクトリのみ転送できていることが確認できます。

%  aws s3 ls s3://kono-destination-data-bucket/ --recursive
2024-07-10 13:48:19 0 .aws-datasync-metadata
2024-07-10 13:48:19 0 testdir_1/
2024-07-10 13:44:19 2147483648 testdir_1/testfile.size2GiB
2024-07-10 13:48:19 0 testdir_2/
2024-07-10 13:44:19 10737418240 testdir_2/testfile.size10GiB
2024-07-10 13:44:19 4294967296 testdir_2/testfile.size4GiB
実験2

次に一旦S3内を空にして、下記のような状況を設定します。

  • マウントパス・ディレクトリ構成は変化なし
  • ディレクトリtestdir_2 のみ転送から除外

この場合は特にincludesには何も指定しない or /*と指定、かつ excludesに/testdir_2/* を指定すればよいです。

少しわかりにくいですが、testdir_2の空ディレクトリはあるもののその配下のみ転送されていないのが確認できます。

%  aws s3 ls s3://kono-destination-data-bucket/ --recursive
2024-07-10 14:43:22 0 .aws-datasync-metadata
2024-07-10 14:42:12 19 test.txt
2024-07-10 14:43:23 0 testdir_1/
2024-07-10 14:42:13 2147483648 testdir_1/testfile.size2GiB
2024-07-10 14:43:23 0 testdir_2/
2024-07-10 14:42:13 1073741824 testfile.size1GiB
2024-07-10 14:42:13 3221225472 testfile.size3GiB
実験3

再度S3内を空にして、次は下記のようにincludesとexcludesの条件が一部重複している状況を設定します。

  • マウントパス・ディレクトリ構成は変化なし
  • ディレクトリtestdir_1 とファイル/testdir_2/testfile.size10GiB のみを転送
  • ディレクトリtestdir_2 を転送から除外

すると testdir_2 の空ディレクトリのみ作成され、 testdir_2 配下のファイルは何も転送されていませんでした。

%  aws s3 ls s3://kono-destination-data-bucket/ --recursive
2024-07-10 14:33:17 0 .aws-datasync-metadata
2024-07-10 14:33:17 0 testdir_1/
2024-07-10 14:32:21 2147483648 testdir_1/testfile.size2GiB
2024-07-10 14:33:17 0 testdir_2/

これにより、includesフィルターよりもexcludesフィルターが優先して適用されていることがわかります。
 

タスク実行

タスク作成が完了したら作成したタスクから開始、もしくはスケジューリング済みであればその時間に実行されます。

タスク実行停止時の挙動

タスクが進行している最中に手動で停止させた際の挙動を確認しておきます。
S3内を空にして、下記のような状況にしておきます。

停止操作後、しばらくするとタスクのステータスはエラーの表示に変わりました。

S3バケットを確認すると、転送されたファイル自体はそのまま残っているものの、検証用に使用される .aws-datasync がそのまま残ってしまっています。

 %  aws s3 ls s3://kono-destination-data-bucket/ --recursive
2024-07-11 16:16:16          0 .aws-datasync/task-xxxxxxxxxxxxxxxxx/0/node0.HardlinkDiscover
2024-07-11 16:16:11          0 .aws-datasync/task-xxxxxxxxxxxxxxxxx/0/node0.MkTempDir
2024-07-11 16:16:14          0 .aws-datasync/task-xxxxxxxxxxxxxxxxx/0/node0.Mkdirs
2024-07-11 16:16:35          0 .aws-datasync/task-xxxxxxxxxxxxxxxxx/0/node1.Copy
2024-07-11 16:16:16          0 .aws-datasync/task-xxxxxxxxxxxxxxxxx/0/node1.HardlinkDiscover
2024-07-11 16:16:11          0 .aws-datasync/task-xxxxxxxxxxxxxxxxx/0/node1.MkTempDir
2024-07-11 16:16:14          0 .aws-datasync/task-xxxxxxxxxxxxxxxxx/0/node1.Mkdirs
2024-07-11 16:16:16         19 test.txt
2024-07-11 16:16:17 2147483648 testdir_1/testfile.size2GiB
2024-07-11 16:16:17 1073741824 testfile.size1GiB

また、コンソール上からもFiles verifiedが0になっているので検証が行われていないことがわかります。
加えて「転送されたデータ」を確認すると10GiB程度あるものの、実際にはデータは3GiB程度しかありません。

これより、中途半端に転送されていたデータは一旦削除されていることが予想されます。

この状態で再度タスクを実行するとすべてのファイルは転送されているものの、前回の検証用データは何もされず残っていました。

 %  aws s3 ls s3://kono-destination-data-bucket/ --recursive
2024-07-11 16:16:16          0 .aws-datasync/task-xxxxxxxxxxxxxxxxx/0/node0.HardlinkDiscover
2024-07-11 16:16:11          0 .aws-datasync/task-xxxxxxxxxxxxxxxxx/0/node0.MkTempDir
2024-07-11 16:16:14          0 .aws-datasync/task-xxxxxxxxxxxxxxxxx/0/node0.Mkdirs
2024-07-11 16:16:35          0 .aws-datasync/task-xxxxxxxxxxxxxxxxx/0/node1.Copy
2024-07-11 16:16:16          0 .aws-datasync/task-xxxxxxxxxxxxxxxxx/0/node1.HardlinkDiscover
2024-07-11 16:16:11          0 .aws-datasync/task-xxxxxxxxxxxxxxxxx/0/node1.MkTempDir
2024-07-11 16:16:14          0 .aws-datasync/task-xxxxxxxxxxxxxxxxx/0/node1.Mkdirs
2024-07-11 16:16:16         19 test.txt
2024-07-11 16:16:17 2147483648 testdir_1/testfile.size2GiB
2024-07-11 16:46:26          0 testdir_2/
2024-07-11 16:43:26 10737418240 testdir_2/testfile.size10GiB
2024-07-11 16:43:26 4294967296 testdir_2/testfile.size4GiB
2024-07-11 16:16:17 1073741824 testfile.size1GiB
2024-07-11 16:43:26 3221225472 testfile.size3GiB

コンソール上から、このタスクで転送されたデータに関しては検証されていますが、他のデータに関しては検証されていないことが確認できます。
加えて、「転送されたデータ」も未転送となっていた17GiB分がきっちり転送されていました。

以上より、やむを得ずデータ転送を停止せざるを得ない場合には、最後のデータ転送時には検証モードを「Verify all data in the destination」にしておくのが良いと思われます。

※ 注意 ※
通信速度やデータ量にもよりますが、初回のデータ転送はデータ量が多いと予想されるためにはそれなりに時間がかかることが想定されます。
また、スケジュールにより開始時間を指定することはできますが、停止時間の指定はできません。
手動停止をなるべく避けるためにも、あらかじめデータをいくつかのディレクトリに分けておき、フィルターを併用して転送スケジュールを立てることを推奨します。
 

案件時に発生した困ったエラー

案件遂行時の転送元ストレージサーバはNFSサーバだったのですが、下記のエラーに遭遇。

mount.nfs: access denied by server while mounting <NFSサーバIP>:<マウントパス>

このエラーが非常に厄介でした。

前提としてAWS公式ドキュメントにはNFSサーバに対して下記設定をしておくよう記載があります。

  • ディレクトリの実行権限
  • ファイルの読み取り権限(ro)
  • ルートアクセス権限(no_root_squash)
  • 2049ポートのネットワークアクセス許可

NFS AWS DataSync ファイルサーバによる転送の設定 – AWS DataSync

使用した環境はNetApp ONTAPを使用していたので、ドキュメント記載の設定をONTAP用に変更して設定していたのですが、このマウントエラーが続いていました。
もちろんFWも特段問題なく、DataSyncエージェントからのNFSサーバの接続テストも問題なし。

下記のトラブルシューティングでは次のように記載がありますが、満たしていることは確認済み。

実行するアクション

まず、指定した NFS サーバーとエクスポートの両方が有効であることを確認します。そうでない場合は、タスクを削除し、正しい NFS サーバーを使用する新しいタスクを作成してからエクスポートします。詳細については、「NFS AWS DataSync ファイルサーバによる転送の設定」を参照してください。

NFS サーバーとエクスポートが両方有効である場合、通常 2 つのうちのいずれかです。エージェントが NFS サーバーをマウントするのをファイアウォールが妨げているか、エージェントがマウントできるように NFS サーバーが設定されていません。

エージェントと NFS サーバーの間にファイアウォールがないことを確認してください。次に、NFS サーバーが、タスクで指定されたエクスポートのマウントをエージェントに許可するよう設定されていることを確認します。ネットワークおよびファイアウォールの要件については、AWS DataSyncネットワーク要件を参照してください。

AWS DataSync 転送に関する問題のトラブルシューティング – AWS DataSync

検証としてオンプレミス環境の別のLinux上に構築されたNFSサーバやNetApp 7-Modeでも試してみたのですが、同じエラーが出力されていました。

そこで、調査を進めているとDataSyncとは関係ないもののNFSサーバのエクスポート設定にはinsecureが必要となる場合があるとの情報が。

このinsecureとは1024番ポート以降のポートからのリクエストも受け付ける設定なのですが、NFSサーバのデフォルト設定ではsecureで1024番未満のポートを使用するように設定されています。

また、NetAppの公式ナレッジベースでも同様の問題が挙げられていました。
(閲覧にはNetAppへのユーザ登録が必要になります。)

その後、Linux NFSサーバやNetApp ONTAP、7-Modeのそれぞれにinsecureに相当する設定を入れたところ、なんとすべて正常マウントされ始め、無事成功。

このことよりDataSyncエージェントはNFSサーバへのリクエストに1024番以降のポートを使用している可能性があるため、NFSサーバデータ転送にはinsecureが必要となる可能性があります。
このエラー解決までに2日ほど時間を要したので、オンプレミスNFSサーバのデータ転送の際にはお気をつけください・・・！
 

まとめ

今回はDataSyncを用いたデータ転送について、導入手順に加えて実際の体験談やハマりどころも踏まえて紹介しました。

基本的には本番稼働中の環境に対して設定を行うため、実際に使用されるときにはドキュメント通りにはいかない可能性を十分に考慮する必要があります。
実際設定を進めていく際には事前の検証もそうですが、トラブルも考慮したうえでスケジュール調整を行ってください。

今回の記事がなにかのお役に立てれば幸いです。