Application Migration Service のLinuxソースサーバーのレプリケーションラグまたはバックログをトラブルシューティングする方法を教えてください。
Application Migration Service を使用してデータを複製すると、Linux ソースサーバーに遅延またはバックログが表示されます。
簡単な説明
ソースサーバーからターゲットサーバーにデータを複製する際、複製の遅延とバックログの原因となる要因は次のとおりです。
- ネットワークのアップリンク速度と帯域幅の可用性: ソースサーバーとレプリケーションサーバー間のネットワーク接続速度は、レプリケーションのパフォーマンスに大きな影響を与える可能性があります。接続が遅いと、レプリケーションプロセスが完了しない場合があります。また、帯域幅が限られていると、特定の時間に複製できるデータ量が制限されます。
- 複製中のディスクの変更: レプリケーション処理中、ソースサーバーは引き続き新しいデータをディスクに書き込むことがあります。ソースサーバーが書き込んでいる新しいデータの量が急増すると、データが蓄積され、大量のバックログが発生します。AWS レプリケーションエージェントは、このバックログを最初の同期で送信する必要があります。バックログが大きいほど、データ複製の完了に要する時間が長くなります。
- ストレージディスクの I/O 速度: レプリケーションプロセス中、AWS Replication Agent はディスクのストレージブロックを読み取り、データをレプリケーションサーバーに送信します。ただし、ソースサーバーディスクの読み取り待ち時間が長いと、データ複製の速度と効率に影響する可能性があります。遅いディスクは遅延を引き起こし、速いディスクはレプリケーション速度を向上させます。
- ソースサーバーへの負荷: ソースサーバーでリソース競合が発生すると、CPU 使用率が高くなったり、メモリが消費されたり、I/O 待機が発生したり、その他のリソース制約が発生したりする可能性があります。たとえば、CPU 使用率が高いと、レプリケーションのボトルネックが発生する可能性があります。これは、システムが AWS レプリケーションエージェントと他のプロセス間で CPU リソースを割り当てるのに苦労しているためです。同様に、メモリ消費量が多いと、システムがメモリページをディスクにスワップする可能性があります。その結果、I/O 待ち時間が長くなり、レプリケーションプロセスが遅くなります。
- プロビジョニングが不十分なレプリケーションリソース: Amazon Elastic Block Store (Amazon EBS) ボリュームを低いスループットと IOPS でステージングすると、読み取りと書き込みのレイテンシーが高くなり、キューが長くなる可能性があります。これらの問題はすべて、レプリケーションのパフォーマンスに影響します。また、ネットワークスループットが低く、Amazon EBS 帯域幅が低いレプリケーションサーバーインスタンスタイプは、レプリケーションパフォーマンスの問題を引き起こします。
解決方法
遅延の根本的な原因を特定するには、まずソースサーバーでチェックを行います。次に、ステージング領域でチェックを行います。
ソースサーバーチェック
ソースサーバーが起動して稼働していることを確認する
移行のソースサーバーが起動して実行されていることを確認します。
ソースサーバーが、地域のアプリケーション移行サービス API エンドポイントとレプリケーションサーバーとの SSL 接続を確立できることを確認します。
ソースサーバーとアプリケーション移行サービス API エンドポイントの間で SSL 証明書が傍受されたり変更されたりしないようにしてください。また、SSL 証明書がソースサーバーとレプリケーションサーバーの間で傍受されたり変更されたりしないようにしてください。これを行うには、以下のコマンドを実行します。
# echo -n | openssl s_client -connect mgn.<region>.amazonaws.com:443 # echo -n | openssl s_client -connect <replication server IP>:1500
**メモ:**次の [アクティブなTCP接続の検証] セクションに記載されているコマンドを使用して、レプリケーションサーバーのIPアドレスを確認します。
すべての AWS レプリケーションエージェントプロセスが実行中であることを確認する
次のコマンドを実行して、実行中の AWS レプリケーションエージェントサービスを一覧表示します。
# ps -u aws-replication
次の出力は、実行する必要がある AWS レプリケーションエージェントプロセスを示しています。
PID TTY TIME CMD 30878 ? 00:00:00 update_onprem_v 30879 ? 00:00:00 run_linux_migra 30880 ? 00:00:00 tailer 30881 ? 00:04:45 java 30902 ? 00:00:01 tailer 30904 ? 00:00:00 run_linux_migra 30905 ? 00:00:10 update_onprem_v 31023 ? 00:00:00 tail
アクティブな TCP 接続を確認
次のコマンドを実行して、TCPポート1500上のレプリケーションサーバーとのアクティブなTCP接続が5つ確立されていることを確認します。
# sudo netstat -anp | awk '$5 ~ /:1500$/ {print}'
コマンド出力を確認して、アクティブな接続を確認してください。
tcp6 0 0 172.31.1.39:54814 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54828 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54832 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54812 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54800 172.31.0.82:1500 ESTABLISHED 30881/java
AWS レプリケーションエージェントが実行されている CPU コアの CPU 使用率を確認する
AWS レプリケーションエージェントは、一度に 1 つの CPU コアで動作するシングルスレッドプロセスです。AWS Replication Agent が実行されているコアの CPU 使用率が高いと、データレプリケーションが遅くなります。
1. 次のコマンドを実行し、出力を確認して次のことを確認します。
- AWS レプリケーションエージェントのプロセス ID。
- 実行中の CPU コア ([psr] で表示)。
# ps --pid $(pidof /var/lib/aws-replication-agent/jre/bin/java) -o psr,pid,comm # mpstat -P <psr column value> 3
2. 次に、特定された CPU コアの CPU 使用率を確認します。
ソースサーバーのディスクパフォーマンスを確認する
ソースディスクの読み取りスループット (RMB/秒) が低い場合は、読み取りと複製されるデータが少なくなります。[I/O 深度 (avgqu-sz)] と [I/O 待機 (await)] メトリックが増加した場合は書き留めておきます。[sar] または [** iostat**] ツールを使用してディスクの読み取りスループットを測定できます。
# iostat -myx 3 # sar -dp 2
ソースサーバーで書き込み操作が急増していないか確認してください
ソースサーバーでの書き込み操作が急増すると、レプリケーションの遅延が大きくなる可能性があります。この増加は、AWS Replication Agent が書き込まれたすべてのデータをレプリケーションサーバーにフラッシュするまで続きます。[iostat] テストを定期的に実行して、ワークロードの変化に伴う I/O 負荷を判断します。書き込みスループット (WMB/s) が使用可能なネットワークスループットを超えると、レプリケーションの遅延が発生します。
**メモ:**ソース・サーバからレプリケーション・サーバまでの必要な帯域幅を計算するには、TCPポート1500に必要な帯域幅の計算」を参照してください。
ソースサーバーからステージングエリアのサブネットまでのレプリケーション速度と使用可能な帯域幅を確認する
1. ターゲット AWS リージョンで、パブリッシュ AMICE-SSL-SpeedTest を使用してテスト用の Amazon エラスティックコンピュートクラウド (Amazon EC2)インスタンスを起動します。EC2 インスタンスは、レプリケーションサーバーと同じインスタンスタイプでなければなりません。
2. ソースサーバーのレプリケーション設定で使用されているサブネットと同じサブネットを選択します。
3. セキュリティグループが TCP Port 1500 インバウンドアクセスを許可していることを確認します。
4. ソースサーバーで、次の例に示すように SpeedTest CLI を設定します。
# cd /tmp # git clone https://github.com/librespeed/speedtest-cli.git # cd speedtest-cli/ # ls -l # ./build.sh # cat << EOF >> ./servers.json [ { "id": 1, "name": "PHP Backend", "server": "https://<test server private IP>:1500/speedtest/", "dlURL": "/garbage.php", "ulURL": "/empty.php", "pingURL": "/empty.php" } ] EOF
メモ:前の例では、テストサーバーの IP アドレスを必ず置き換えてください。テストサーバーのパブリック IP を速度テストに使用する場合は、[PingUrl] 行の後に["getIpURL": "/getIP.php]を含めてください。
5. 次の例に示すように LibreSpeed CLI を実行して、レプリケーション速度をテストします。
# ./out/librespeed-cli-linux-amd64 —local-json ./servers.json —server 1 —no-icmp —skip-cert-verify —simple Ping: 11.00 ms Jitter: 0.00 ms Download rate: 503.84 Mbps Upload rate: 493.56 Mbps
ソースサーバーが不正にシャットダウンされていないか確認してください
ソースサーバーが不適切にシャットダウンされた場合、AWS Replication Agent はサーバーの再起動後にすべてのディスクを再スキャンします。AWS Replication Agent はディスクを再読み込みし、再スキャンが完了するまで遅延が継続的に増加します。詳細については、再起動時に再スキャンを行わないようにする Windows および Linux OS はどれ?を参照してください。
カーネルのアップグレードを確認
ソースサーバーでカーネルがアップグレードされ、サーバーが再起動されると、AWS Replication Agent は実行されません。実行中のカーネルバージョンは、エージェントのインストール中に AWS Replication Agent ドライバーがコンパイルされたカーネルバージョンと一致します。
次のコマンドを実行して、実行中のカーネルバージョンが AWS Replication Agent ドライバーがコンパイルされたカーネルバージョンと一致することを確認します。
$ uname -r $ modinfo -F vermagic /var/lib/aws-replication-agent/aws-replication-driver.ko
注: [vermagic] は、カーネルドライバーがどのカーネルバージョンをコンパイルされているかを検証するために使用されます。
TCP ポート 1500 がアウトバウンドでブロックされていないことを確認する
TCPポート1500がソースサーバーからレプリケーションサーバーへのアウトバウンドがブロックされていないことを確認します。
MGN エージェントログを確認する
MGN Agent のログを調べて、TCP ポート 1500 のレプリケーションサーバーとの接続に問題がないかどうかを確認します。また、接続が頻繁に切断されていることを示すレプリケーションの不規則性も確認してください。これらの問題を特定したら、ネットワークトポロジを確認してさらに調査します。
中間デバイスのMTUが低くないことを確認する
レプリケーションパス内の中間デバイスのいずれも MTU が低くないことを確認します。MTU が低いと、レプリケーション速度が低下し、処理に遅延が生じます。レプリケーションパス全体で一貫した MTU サイズを維持することがベストプラクティスです。パス内のデバイスの MTU が低い場合は、更新するか、MTU が高いデバイスと交換します。
**メモ:**パブリックインターネット経由で複製する場合は、MTUが1500であることを確認してください。1500は、インターネットゲートウェイ、ピアリング、およびVPNがサポートする最大のMTUです。ジャンボフレームは Amazon 仮想プライベートクラウド (Amazon VPC) または AWS ダイレクトコネクト内でのみ機能し、独自の制限があります。詳細については、以下を参照してください。
ソースサーバーのレプリケーション設定でネットワーク帯域幅調整がオフになっていることを確認します。
ソースサーバーのレプリケーション設定で帯域幅調整をオフにする必要があります。
ソースサーバーで帯域幅調整をオンにすると、AWS Replication Agent のデータ転送速度が制限されます。これにより、ソースサーバーにバックログがあると、ラグが絶え間なく増加したり、停滞したりする可能性があります。データ転送の帯域幅を一定かつ制限された状態に維持するには、ネットワーク帯域幅調整をオンにします。
帯域幅調整を確認するには、次の手順を実行します。
2. [ソースサーバー] を選択してから、ソースサーバーを選択します。
3. [レプリケーション設定] タブを選択します。
3. [ネットワーク帯域幅のスロットル] がオンになっている場合は、スロットル値がデータ複製に必要な帯域幅と同じかそれ以上であることを確認してください。詳細については、前のセクションの [ソースサーバーで書き込み操作が急増していないか確認してください] の注記を参照してください。
ステージングエリアのリソースチェック
TCP ポート 1500 がインバウンドでブロックされていないことを確認する
TCPポート1500がレプリケーションサーバーのセキュリティグループでインバウンドでブロックされていないことを確認します。
**メモ:**Amazon エラスティックコンピュートクラウド (Amazon EC2) コンソールで以下の手順を完了する必要があります。
2. レプリケーターインスタンスにアタッチされているセキュリティグループを選択します。
3. 接続されているセキュリティグループでインバウンド TCP ポート 1500 が許可されていることを確認します。
CloudWatch のネットワークメトリックスを確認する
レプリケーションサーバーの [NetworkIN] Amazon CloudWatch メトリックスが帯域幅制限に近づくと、スロットリングが発生する可能性があります。スロットリングを行うと、レプリケーション速度が遅くなり、ラグが大きくなります。必要な帯域幅を処理できる、より大きなインスタンスタイプへのアップグレードを検討してください。
レプリケーションサーバーの EBS ボリュームの集約スループットと IOPS を確認する
Amazon Elastic Block Store (Amazon EBS) ボリュームの合計スループットと IOPS が制限を超えると、レプリケーションサーバーのパフォーマンスが制限される可能性があります。スロットリングが発生した場合は、レプリケーションのニーズに対応し、スロットリングなしでパフォーマンスを維持できるレプリケーションサーバーインスタンスタイプに変更してください。レプリケーションサーバーには、現行世代の EBS 最適化インスタンスタイプを使用するのがベストプラクティスです。EBS 最適化スループットをサポートしていないインスタンスでは、ネットワークトラフィックがインスタンスと EBS ボリューム間のトラフィックと競合します。EBS 最適化インスタンスでは、2 つのタイプのトラフィックは別々に保持されます。レプリケーションサーバーネットワークと EBS CloudWatch メトリクスを監視します。詳細については、以下を参照してください。
すべてのレプリケーション EBS ボリュームのメトリックスを監視
レプリケーションサーバーのボリューム書き込み速度がソースサーバーの変化率と一致しない場合、ラグとバックログが蓄積します。レプリケーションの遅延を避けるには、IOPS と帯域幅が高い、より高速なボリュームタイプを使用してください。EBS ボリュームのパフォーマンスを最適化するには、すべてのレプリケーション EBS ボリュームの CloudWatch メトリックスを監視することがベストプラクティスです。
スナップショットから作成された EBS ボリュームを確認する
スナップショットから EBS ボリュームが作成されているレプリケーションサーバーでは、各ブロックに初めてアクセスしたときに I/O 操作の待ち時間が長くなる可能性があります。この遅延により、再スキャンプロセスが完了するまでの遅延や停滞が発生する可能性があります。詳細については、スナップショットからボリュームを初期化するときのパフォーマンスの低下に注意してくださいを参照してください。
ターゲットリージョンのスナップショットクォータを確認してください
ソースサーバーをレプリケートしている AWS リージョンの AWS アカウントがスナップショットクォータ制限に達していないことを確認してください。次の AWS コマンドラインインターフェイス (AWS CLI) コマンドを使用して、リージョンのスナップショットクォータに達したかどうかを確認します。次の例では、リージョンをターゲット AWS [リージョン] に置き換えます。
# aws service-quotas get-service-quota --service-code ebs --quota-code L-309BACF6 --region region --query "Quota.Value" # aws ec2 describe-snapshots --owner-ids self --region region --query "length(Snapshots)"
**メモ:**AWS CLI コマンドの実行中にエラーが発生した場合は、AWS CLI の最新バージョンを使用していることを確認してください。
関連情報
