Application Migration Service やエラスティックディザスタリカバリのレプリケーションプロセスが「初期同期を完了中」のメッセージとともに 100% で停止するのはなぜですか？

簡単な説明

Application Migration Service または Elastic Disaster Recovery の同期中にレプリケーションプロセスが 100% のまま停止すると、次のエラーが表示されます。

• 「初期同期を完了中 - バックログのフラッシュ」
• 「初期同期を完了中 - 起動可能な最初のスナップショットの作成」

解決策

「初期同期を完了中 - バックログのフラッシュ」エラーのトラブルシューティング

バックログのフラッシュが完了して同期が初期化されるまで待ちます。

ソースマシンで書き込みが集中している場合、バックログのサイズが大きくなる可能性があります。Application Migration Service または Elastic Disaster Recovery コンソールで、マシンが初期同期を完了中状態のままになることがあります。このような場合は、次の手順を実行してください。

1. (CloudEndure ウェブサイトで)レプリケーション速度をテストします。
2. すべてのレプリケーションソースマシンに必要な帯域幅を計算します。レプリケーションインスタンスのネットワークスループットが十分であることを確認してください。
3. [レプリケーション設定] で、**[ネットワーク帯域幅スロットリング]**が有効になっているかどうかを確認します。構成でこのオプションを有効にする必要がある場合は、値を少なくとも必要な最小帯域幅に設定してください。詳細については、Application Migration Service または Elastic Disaster Recovery の帯域幅調整に関するドキュメントを参照してください。
4. Amazon CloudWatch メトリックスを使用して、レプリケーションサーバーのネットワークとディスクの使用率を確認します。リソースによってサーバーがスロットリングされる場合は、専用のレプリケーションサーバーまたはより大きな種類のレプリケーションサーバーを使用してください。または、SSD ベースのストレージを選択してください。詳細については、「ディスク設定 (Application Migration Service)」 または「ディスク設定 (Elastic Disaster Recovery)」を参照してください。
5. 特定のソースマシンが使用するレプリケーションサーバーを確認するには、次の例に示すように、ソースマシンで netstat コマンドを実行します。
   マシンがポート 1500 を介して接続するリモート IP アドレスを書き留めておきます。

netstat コマンド (Linux 版) :

$ netstat -anp | grep ":1500"

netstat コマンド (Windows 版) :

netstat -ano | findstr ":1500"

または、ソースマシン上の agent.log.0 ファイルを確認して、使用中のレプリケーションサーバを正確に特定してください。

agent.log.0 (Linux 版) :

$ sudo cat /var/lib/aws-replication-agent/agent.log.0 | grep :1500 | tail -n 1

agent.log.0 (Windows 版) :

findstr /L ":1500" "C:\Program Files (x86)\AWS Replication Agent\agent.log.0"

初期同期を完了中のトラブルシューティング - 起動可能な最初のスナップショットの作成エラー

このエラーをトラブルシューティングするには、次の 1 つまたは複数の手順を実行してください。

• ユーザーの AWS Identity and Access Management (IAM) ポリシーに Amazon Elastic Compute Cloud (Amazon EC2) API を実行するために必要なすべてのアクセス権限があることを確認します。詳細については、「CloudTrail を使用して AWS アカウントで発生した API 呼び出しとアクションを確認する方法を教えてください」を参照してください。
• レプリケーションサーバーが AWS リージョン内の Amazon EC2 エンドポイント (https://ec2.{region}.amazonaws.com) と通信していることを確認します。詳細については、「AWS サービスエンドポイント」を参照してください。
• レプリケーション設定の最近の変更を確認します。
• 正しいプロキシ設定を使用していることを確認します。
• Application Migration Service または Elastic Disaster Recovery エージェントが正しく動作していることを確認します。
• Service Quotas の問題がないか確認します。

Application Migration Service または Elastic Disaster Recovery ユーザーの AWS IAM ポリシーに、必要な Amazon EC2 API を実行するためのすべての権限があることを確認します。

Application Migration Service または Elastic Disaster Recovery のユーザーポリシーについては、Application Migration Service または Elastic Disaster Recovery に必要な AWS 認証情報を参照してください。または、AWS CloudTrail イベント履歴 を見て、設定したユーザーの API 障害を確認することもできます。

レプリケーションサーバーがリージョン内の Amazon EC2 エンドポイントと通信していることを確認する

1. ステージングエリアと同じサブネットで新しい Linux マシンを起動します。
2. 接続をテストするには、新しいマシンにログインし、次のコマンドを実行します。以下のコマンド例では、us-east-1 を自分のリージョンに置き換えてください。

$ dig ec2.us-east-1.amazonaws.com  
$ telnet ec2.us-east-1.amazonaws.com 443  
$ wget https://ec2.us-east-1.amazonaws.com

これらのコマンドのいずれかが失敗する場合、ネットワーク接続に問題があると考えられます。次のセクションに進んでください。

ネットワーク接続を妨げる要因を特定する

仮想プライベートクラウド (VPC)、サブネット、セキュリティグループ、ネットワークアクセスコントロールリスト（ネットワーク ACL）、およびルートテーブルの設定がレプリケーション設定と一致していることを確認します。設定に誤りがあると、レプリケーションサーバーから Amazon EC2 エンドポイントへの通信がブロックされる可能性があります。

レプリケーションサーバーがパブリックサブネットで起動する場合は、次の手順を実行してください。

1. セキュリティグループ、ネットワーク ACL、およびルートテーブルが TCP ポート 443 の Amazon EC2 エンドポイントとの通信を許可していることを確認します。
2. VPC レベルで enableDnsHostnames 属性と enableDnsSupport 属性が true に設定されていることを確認します。

$ aws ec2 describe-vpc-attribute --vpc-id vpc-a01106c2 --attribute enableDnsHostnames  
{   
 "VpcId": "vpc-a01106c2",  
 "EnableDnsHostnames": {   
 "Value": true  
 }   
}

$ aws ec2 describe-vpc-attribute --vpc-id vpc-a01106c2 --attribute enableDnsSupport  

{  
 "VpcId": "vpc-a01106c2",   
 "EnableDnsSupport": {  
 "Value": true   
 }  
}

レプリケーションサーバーがプライベートサブネットで起動する場合は、次の手順を実行します。

1. セキュリティグループ、ネットワーク ACL、およびルートテーブルが TCP ポート 443 の Amazon EC2 エンドポイントとの通信を許可していることを確認します。
2. ルートテーブルに NAT ゲートウェイまたはインスタンスを設定した場合は、TCP ポート 443 の EC2 エンドポイントへのアウトバウンドトラフィックが機能していることを確認します。
3. アウトバウンドトラフィックがトランジットゲートウェイまたは仮想プライベートゲートウェイを通過するか確認します。この場合、必ずルートテーブルが TCP ポート 443 の EC2 エンドポイントへのトラフィックを許可するようにしてください。
4. ファイアウォールが通信をブロックしていないか確認します。
5. VPC にインターフェイス VPC エンドポイントがある場合は、必ず TCP ポート 443 上の Amazon EC2 エンドポイント間でプライベートネットワーク経由で通信が行われるようにしてください。そのためには、次の手順を実行します。

VPC レベルで enableDnsHostnames 属性と enableDnsSupport 属性が true に設定されていることを確認します。VPC インターフェイスのエンドポイントで PrivateDnsEnabled の値が true に設定されていることを確認します。

$ aws ec2 describe-vpc-attribute --vpc-id vpc-a01106c2 --attribute enableDnsHostnames --query 'EnableDnsHostnames'  
{   
 "Value": true  
}

$ aws ec2 describe-vpc-attribute --vpc-id vpc-a01106c2 --attribute enableDnsSupport --query 'EnableDnsSupport'  
{   
 "Value": true  
}

$ aws ec2 describe-vpc-endpoints --vpc-endpoint-ids vpce-088d25a4bbf4a7abc --query 'VpcEndpoints[0].PrivateDnsEnabled'  
true

レプリケーション設定の最近の変更を確認する

UpdateReplicationConfiguration API 呼び出しを検索すると、CloudTrail イベント履歴からレプリケーション設定への変更を追跡できます。次に、ソースサーバーを使用してリソース名をフィルタリングします。たとえば、レプリケーションリソースタグフィールドに無効なタグが挿入されていないか確認します。使用できる文字の一覧については、「タグの制限」を参照してください。

正しいプロキシ設定を使用していることを確認する

1. レプリケーションサーバーがプロキシサーバーを使用している場合は、プロキシ設定で TCP ポート 443 のリージョン EC2 エンドポイントとの通信が許可されていることを確認します。
2. SSL インターセプトと認証の許可リストに mgn.<region>.amazonaws.com (Application Service Migration の場合) とdrs.<region>.amazonaws.com (Elastic Disaster Recovery の場合) が含まれていることを確認します。詳細については、「ソースサーバーとアプリケーション移行サービスコンソールの間でプロキシサーバーを使用できますか?」を参照してください。また、「ソースサーバーと Elastic Disaster Recovery コンソールの間でプロキシサーバーを使用できますか？」も参照してください。

**レプリケーションエージェントが正しく動作することを確認する **

AWS レプリケーションエージェントがソースマシンで正しく動作することを確認します。レプリケーションエージェントのログにエラーがないか確認すると、問題を特定しやすくなります。レプリケーションエージェントのログは、次のファイルの場所にあります。

Linux レプリケーションエージェントのログ:

/var/lib/aws-replication-agent/agent.log.0

Windows レプリケーションエージェントのログ:

C:\Program Files (x86)\AWS Replication Agent\agent.log.0

Amazon EC2 Service Quota の問題がないか確認する

Service Quota の問題やAPI スロットリングおよびレート制限の問題により、Application Migration Service や Elastic Disaster Recovery が起動可能な最初のリカバリースナップショットを作成できない場合があります。CloudTrail イベント履歴を確認して、Service Quota または帯域幅スロットリングの問題が存在するかどうかを判断します。