如何排查 Application Migration Service 的 Linux 源服务器上的复制滞后或积压问题?

4 分钟阅读
0

使用 AWS Application Migration Service 复制数据时,我发现我的 Linux 源服务器上出现滞后或积压。

简短描述

以下是在将数据从源服务器复制到目标服务器时导致复制滞后和积压的因素:

  • 网络上行链路速度和带宽可用性: 源服务器和目标复制服务器之间的网络连接速度可能会对复制性能产生重大影响。连接速度慢可能会影响复制过程的完成。此外,有限的带宽会限制在给定时间内可复制的数据量。
  • 复制过程中磁盘的变化: 在复制过程中,源服务器可能会继续向其磁盘写入新数据。如果源服务器写入的新数据量激增,那么数据就会积累起来,造成大量积压。AWS Replication Agent 必须在初始同步时发送这些积压数据。积压数据量越大,完成数据复制所需的时间就越长。
  • 存储磁盘的 I/O 速度: 在复制过程中,AWS Replication Agent 读取磁盘的存储块并将数据传输到目标复制服务器。但是,源服务器磁盘上读取延迟大可能会影响数据复制的速度和效率。磁盘读取速度慢会导致延迟,而磁盘读取速度快会提高复制速度。
  • 源服务器负载: 源服务器上的资源争用可能会导致 CPU 利用率高、内存使用率高、I/O 等待或其他资源约束。例如,CPU 利用率高可能会导致复制瓶颈。这是因为系统很难在 AWS Replication Agent 和其他进程之间分配 CPU 资源。同样,内存使用率高可能会导致系统将内存页交换到磁盘。这会导致 I/O 等待时间增加和复制过程变慢。
  • 复制资源预置不足: 以较低的吞吐量和 IOPS 暂存 Amazon Elastic Block Store (Amazon EBS) 卷可能会导致读写延迟较高,队列长度较长。所有这些问题都会影响复制性能。此外,复制服务器实例类型及网络吞吐量和 Amazon EBS 带宽低也会导致复制性能问题。

解决方法

要确定滞后的根本原因,请首先检查源服务器。然后,检查暂存区域。

源服务器检查

确认源服务器已启动并正在运行

确保准备进行数据迁移的源服务器已启动并正在运行。

确认源服务器是否可以与 Application Migration Service API 端点和复制服务器建立 SSL 连接

确保 SSL 证书在源服务器和 Application Migration Service API 端点之间的任意点都不会遭到拦截和更改。同时,确保 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 Replication Agent 进程都在运行

运行以下命令以列出正在运行的 AWS Replication Agent 服务:

# ps -u aws-replication

以下输出所示为必须处于正在运行状态的 AWS Replication Agent 进程:

 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 连接。

# 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 Replication Agent 的 CPU 内核的 CPU 利用率

AWS Replication Agent 是一个单线程进程,一次只能在一个 CPU 内核上运行。如果运行 AWS Replication Agent 的内核的 CPU 利用率很高,则数据复制会很慢。

1.    运行以下命令,然后查看输出确定以下几点:

  • AWS Replication Agent 的进程 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/s) 较低,则读取和复制的数据就会更少。记下 IO depth (avgqu-sz)I/O wait (await) 指标的任何增加。您可以使用 sariostat 工具来测量磁盘的读取吞吐量:

# iostat -myx 3
# sar -dp 2

检查源服务器写入操作是否有峰值

源服务器写入操作有峰值可能会导致复制滞后增加。这种增加会一直持续,直到 AWS Replication Agent 将所有写入的数据刷新到复制服务器。定期运行 iostat 测试,以确定工作负载变化时的 I/O 负载。如果写入吞吐量 (wMB/s) 超过可用的网络吞吐量,就会有复制滞后。

**注意:**要计算从源服务器到复制服务器所需的带宽,请参阅计算 TCP 端口 1500 所需的带宽

检查从源服务器到暂存区域子网的复制速度和可用带宽

1.    在目标 AWS 区域,使用发布型 AMI CE-ssl-speedtest启动测试 Amazon Elastic Compute Cloud (Amazon EC2) 实例。EC2 实例必须与复制服务器的实例类型相同。

2.    选择与源服务器复制设置中使用的子网相同的子网。

3.    确保安全组允许 TCP 端口 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 操作系统支持在重启时不重新扫描?

检查是否有内核升级

如果源服务器上升级了内核并重启了服务器,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 代理日志,以了解 TCP 端口 1500 上是否存在与复制服务器相关的任何连接问题。此外,还要检查是否存在表明连接经常断开的复制异常情况。确定这些问题后,查看网络拓扑,做进一步调查。

确认中间设备的 MTU 是否过低

确认复制路径中无 MTU 过低的中间设备。MTU 过低会降低复制速度并导致过程延迟。最佳做法是保持整个复制路径的 MTU 大小稳定一致。如果路径中有设备的 MTU 过低,请将其更新或替换为 MTU 更高的设备。

**注意:**如果您在通过公共互联网进行复制,请确保 MTU 为 1500。1500 是互联网网关、对等互连和 VPN 支持的最大的 MTU。Jumbo 帧只能在 Amazon Virtual Private Cloud (Amazon VPC) 或 AWS Direct Connect 中使用,有其自身的局限性。有关更多信息,请参阅以下内容:

确认在源服务器的复制设置中禁用了网络带宽节流

必须在源服务器的复制设置中关闭带宽节流。

在源服务器中启用带宽节流会限制 AWS Replication Agent 的数据传输速率。如果源服务器上存在积压,则这可能会导致滞后增加恒定或停滞。要使数据传输带宽保持恒定且受限,请启用网络带宽节流。

要检查带宽节流设置,请完成以下步骤:

1.    打开 Application Migration Service 控制台

2.    选择源服务器,然后选择源服务器。

3.    选择复制设置选项卡。

3.    如果限制网络带宽已启用,请确保限制值等于或大于数据复制所需的带宽。有关更多信息,请参阅上一节检查源服务器写入操作是否有峰值中的“注意”。

暂存区域资源检查

确认 TCP 端口 1500 入站访问未被阻止

确保复制服务器的安全组中 TCP 端口 1500 入站访问未被阻止。

**注意:**您必须在 Amazon Elastic Compute Cloud (Amazon EC2) 控制台中完成以下步骤。

1.    打开Amazon EC2 控制台

2.    选择附加到复制器实例的安全组。

3.    确认所附加的安全组是否允许 TCP 端口 1500 入站访问。

检查 NetworkIn CloudWatch 指标

如果复制服务器的 NetworkIn Amazon CloudWatch 指标接近带宽限制,则可能会出现节流问题。节流会导致复制速度变慢和滞后增加。考虑升级到能够提供所需带宽的更大实例类型。

检查目标复制服务器 EBS 卷的总吞吐量和 IOPS

如果 Amazon Elastic Block Store (Amazon EBS) 卷的总吞吐量和 IOPS 超过限制,目标复制服务器的性能可能会受到限制。如果出现节流问题,请更改目标复制服务器实例类型,使其能够满足您的复制需求并维持性能,不会出现节流问题。最佳做法是目标复制服务器使用最新一代 EBS 优化的实例类型。在不支持 EBS 优化吞吐量的实例上,网络流量会与您的实例和 EBS 卷之间的流量竞争。在 EBS 优化的实例上,这两种类型的流量是分开的。监控复制服务器网络和 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

相关信息

找出使用 AWS Application Migration Service 时的复制瓶颈

AWS 官方
AWS 官方已更新 1 年前