识别问题和解决方案¶
系统是否正常运行？¶
如果您收到 Swift 宕机的报告，请执行以下基本检查
运行 Swift 功能测试。
从您的数据中心的服务器上，使用
curl检查/healthcheck（见下文）。如果您有监控系统，请检查您的监控系统。
检查您的硬件负载均衡器基础设施。
在代理节点上运行 swift-recon。
功能测试用法¶
我们建议您设置功能测试以针对您的生产系统运行。定期运行，这可以成为验证系统配置是否正确的有用工具。此外，它还可以提供有关系统故障的早期预警（如果功能测试停止工作，用户应用程序也可能停止工作）。
运行功能测试的脚本位于 swift/.functests 中。
外部监控¶
我们使用 pingdom.com 监控外部 Swift API。我们建议以下操作
对
/healthcheck执行 GET 请求创建一个容器，使其公开 (
x-container-read: .r*,.rlistings)，在容器中创建一个小文件；对该对象执行 GET 请求
诊断：通用方法¶
查看您的监控系统中服务状态。
除了系统监控工具和用户的问题日志记录外，Swift 错误通常会导致日志条目（参见 诊断：解释 /var/log/swift/ 文件中的消息）。
查看您的部署工具生成的任何日志。
应审查日志文件是否存在错误签名（如下所示），这些错误可能指向已知问题，或诊断工具报告的根本原因问题，然后再进行升级。
依赖项¶
Swift 软件依赖于整体系统健康状况。操作系统层面的网络连接、域名解析、用户管理、硬件和系统配置以及内存和可用磁盘空间方面的容量问题，可能会导致次要的 Swift 问题。应在诊断 Swift 问题之前解决系统层面的问题。
诊断：Swift-dispersion-report¶
swift-dispersion-report 是一个用于评估系统整体健康状况的有用工具。配置 swift-dispersion 报告，至少覆盖您系统中的每个磁盘驱动器（通常为 1% 的覆盖率）。有关如何配置和使用离散报告工具的详细信息，请参见 离散报告。
swift-dispersion-report 工具可能需要很长时间才能运行，尤其是在任何服务器宕机的情况下。我们建议您定期运行它（例如，在 cron 作业中）并保存结果。这样可以轻松地参考最新的报告，而无需等待长时间运行的命令完成。
诊断：系统是否响应 /healthcheck？¶
当您想确定 Swift 端点是否正在运行时，请运行 curl -k 针对 https://$ENDPOINT/healthcheck。
诊断：解释 /var/log/swift/ 文件中的消息¶
注意
在 Hewlett Packard Enterprise Helion Public Cloud 中，我们将日志发送到 proxy.log（代理服务器日志）、server.log（对象服务器、帐户服务器、容器服务器日志）、background.log（所有其他服务器 [对象复制器等]）。
下表列出了已知问题
日志文件 |
签名 |
问题 |
采取的步骤 |
|---|---|---|---|
/var/log/syslog |
kernel: [] sd …. [csbu:sd…] Sense Key: Medium Error |
表明磁盘表面存在问题 |
在目标节点上运行 |
/var/log/syslog |
kernel: [] sd …. [csbu:sd…] Sense Key: Hardware Error |
表明存储硬件存在问题 |
在目标节点上运行诊断程序以检查磁盘故障，更换故障磁盘 |
/var/log/syslog |
kernel: [] …. I/O error, dev sd…. ,sector …. |
在目标节点上运行诊断程序以检查磁盘错误 |
|
/var/log/syslog |
pound: NULL get_thr_arg |
多个线程被唤醒 |
噪音，可以忽略 |
/var/log/swift/proxy.log |
…. ERROR …. ConnectionTimeout …. |
存储节点没有及时响应 |
检查节点是否宕机、未运行 Swift、未配置、存储离线或网络问题是否存在于代理和未响应的节点之间 |
/var/log/swift/proxy.log |
proxy-server …. HTTP/1.0 500 …. |
代理服务器报告了内部服务器错误 |
检查日志中在报告错误时发生的任何错误，以尝试了解错误原因。 |
/var/log/swift/server.log |
…. ERROR …. ConnectionTimeout …. |
存储服务器没有及时响应 |
检查节点是否宕机、未运行 Swift、未配置、存储离线或网络问题是否存在于服务器和未响应的节点之间 |
/var/log/swift/server.log |
…. ERROR …. Remote I/O error: ‘/srv/node/disk…. |
存储设备没有按预期响应 |
运行 |
/var/log/swift/background.log |
object-server ERROR container update failed …. Connection refused |
无法联系到容器服务器节点 |
检查节点是否宕机、未运行 Swift、未配置、存储离线或网络问题是否存在于服务器和未响应的节点之间 |
/var/log/swift/background.log |
object-updater ERROR with remote …. ConnectionTimeout |
远程容器服务器很忙 |
如果容器很大，则更新它时可能会出现一些错误。但是，如果网络存在问题，也可能发生此错误。 |
/var/log/swift/background.log |
account-reaper STDOUT: …. error: ECONNREFUSED |
网络连接问题或目标服务器宕机。 |
解决网络问题或重新启动目标服务器 |
/var/log/swift/background.log |
…. ERROR …. ConnectionTimeout |
存储服务器没有及时响应 |
目标服务器可能很忙。但是，如果网络存在问题，也可能发生此错误。 |
/var/log/swift/background.log |
…. ERROR syncing …. Timeout |
同步到另一个节点的数据时发生超时。 |
目标服务器可能很忙。但是，如果网络存在问题，也可能发生此错误。 |
/var/log/swift/background.log |
…. ERROR Remote drive not mounted …. |
存储服务器磁盘不可用 |
修复并重新挂载文件系统（在远程节点上） |
/var/log/swift/background.log |
object-replicator …. responded as unmounted |
存储服务器磁盘不可用 |
修复并重新挂载文件系统（在远程节点上） |
/var/log/swift/*.log |
STDOUT: EXCEPTION IN |
发生意外错误 |
阅读 Traceback 详细信息，如果它与已知问题（例如，活动网络/磁盘问题）匹配，请在解决主要问题后检查是否会再次发生。 |
/var/log/rsyncd.log |
rsync: mkdir “/disk….failed: No such file or directory…. |
本地存储服务器磁盘不可用 |
在节点上运行诊断程序以检查故障或未挂载的磁盘 |
/var/log/swift* |
Exception: Could not bind to 0.0.0.0:6xxx |
可能的 Swift 进程重启问题。这表明旧的 Swift 进程仍在运行。 |
重新启动 Swift 服务。如果报告某些 Swift 服务已宕机，请检查它们是否留下了残留进程。 |
诊断：Parted 报告备份 GPT 表已损坏¶
如果 GPT 表损坏，则在运行以下命令时应观察到如下消息
$ sudo parted -l
Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used. OK/Cancel?
要修复，请转到 修复损坏的 GPT 表（损坏的磁盘分区）
诊断：驱动器诊断报告文件系统标签不可接受¶
如果诊断报告类似于“FS label: obj001dsk011 is not acceptable”，则表明分区具有有效的磁盘标签，但无效的文件系统标签。在这种情况下，请按以下步骤操作
验证磁盘标签是否正确
$ FS=/dev/sd#1 $ sudo parted -l | grep object
如果分区标签不一致，则在继续之前解决磁盘标签问题
$ sudo parted -s ${FS} name ${PART_NO} ${PART_NAME} #Partition Label $ # PART_NO is 1 for object disks and 3 for OS disks $ # PART_NAME follows the convention seen in "sudo parted -l | grep object"
如果缺少文件系统标签，则小心创建它
$ sudo xfs_admin -l ${FS} #Filesystem label (12 Char limit) $ # Check for the existence of a FS label $ OBJNO=<3 Length Object No.> $ # I.E OBJNO for sw-stbaz3-object0007 would be 007 $ DISKNO=<3 Length Disk No.> $ # I.E DISKNO for /dev/sdb would be 001, /dev/sdc would be 002 etc. $ sudo xfs_admin -L "obj${OBJNO}dsk${DISKNO}" ${FS} $ # Create a FS Label
诊断：失败的 LUN¶
注意
HPE Helion Public Cloud 使用直接连接的 SmartArray 控制器/驱动器。此处的信息特定于该环境。此处提到的 hpacucli 实用程序在您的环境中可能称为 hpssacli。
swift_diagnostics 挂载检查可能会返回警告，指示 LUN 已失败，通常伴随着驱动器审核检查失败和设备错误。
这种情况通常是由驱动器故障引起的，如果驱动器检查也报告了底层驱动器的故障状态，则请按照更换磁盘的步骤操作。
否则，可以按以下方式重新启用 LUN
生成 hpssacli 诊断报告。此报告允许 DC 团队排除潜在的电缆或硬件问题，因此在排除故障时立即运行它非常重要。您稍后会返回并 grep 此文件以获取更多详细信息，但现在只需生成它即可。
$ sudo hpssacli controller all diag file=/tmp/hpacu.diag ris=on xml=off zip=off
使用以下说明导出以下变量，然后再继续操作。
打印逻辑驱动器及其编号的列表，并记下故障驱动器的编号和数组值（示例输出：“array A logicaldrive 1…” 将导出为 LDRIVE=1）
$ sudo hpssacli controller slot=1 ld all show
将从上一个命令检索到的逻辑驱动器编号导出到 LDRIVE 变量
$ export LDRIVE=<LogicalDriveNumber>
打印数组值和 Port:Box:Bay，用于所有驱动器，并记下故障驱动器的 Port:Box:Bay（示例输出：“ array A physicaldrive 2C:1:1…” 将导出为 PBOX=2C:1:1）。将此输出的数组值与之前命令获得的数组值进行匹配，以确保您正在处理相同的驱动器。此外，数组值通常与设备名称匹配（例如，在“array c”的情况下为 /dev/sdc），但我们将运行另一个命令以确保我们正在处理正确的设备。
$ sudo hpssacli controller slot=1 pd all show
注意
有时，LUN 可能看起来已失败，但实际上并非如此，并且无法挂载，但 hpssacli/parted 命令可能未显示 LUN/驱动器存在任何问题。在这种情况下，文件系统可能已损坏，并且可能需要运行 sudo xfs_check /dev/sd[a-l][1-2] 以查看是否存在 xfs 问题。运行此命令的结果可能需要运行 xfs_repair。
将故障驱动器的 Port:Box:Bay 导出到 PBOX 变量
$ export PBOX=<Port:Box:Bay>
打印物理设备信息并记下磁盘名称（示例输出：“Disk Name: /dev/sdk” 将导出为 DEV=/dev/sdk）
$ sudo hpssacli controller slot=1 ld ${LDRIVE} show detail | grep -i "Disk Name"
从前面的命令导出设备名称变量（例如：/dev/sdk）
$ export DEV=<Device>
导出文件系统变量。在操作系统和数据存储之间拆分的磁盘，通常 sda 和 sdb，应仅对其数据文件系统进行修复，通常为 /dev/sda2 和 /dev/sdb2。其他仅数据磁盘在设备上只有一个分区，因此文件系统将为 1。无论哪种情况，您都应该通过运行
df -h | grep /srv/node并使用列表中针对相关设备的数据文件系统作为导出进行验证。$ export FS=<Filesystem>
验证 LUN 是否已失败，并且设备是否未失败
$ sudo hpssacli controller slot=1 ld all show $ sudo hpssacli controller slot=1 pd all show $ sudo hpssacli controller slot=1 ld ${LDRIVE} show detail $ sudo hpssacli controller slot=1 pd ${PBOX} show detail
停止 Swift 和 rsync 服务
$ sudo service rsync stop $ sudo swift-init shutdown all
卸载有问题驱动器，修复 LUN 和文件系统
$ sudo umount ${FS}
如果卸载失败，则应运行 lsof 搜索挂载点并杀死任何残留进程，然后再重复卸载
$ sudo hpacucli controller slot=1 ld ${LDRIVE} modify reenable $ sudo xfs_repair ${FS}
如果
xfs_repair抱怨可能存在日志数据，请使用xfs_repair -L选项来将日志零化。完成测试后挂载文件系统，并清理其 lost and found 区域。
$ sudo mount ${FS} /mnt $ sudo rm -rf /mnt/lost+found/ $ sudo umount /mnt
挂载文件系统并重新启动 Swift 和 rsync。
运行以下命令以确定是否需要 DC 工单来检查节点的电缆
$ grep -y media.exchanged /tmp/hpacu.diag $ grep -y hot.plug.count /tmp/hpacu.diag
如果输出报告任何非 0x00 值，则表明应检查电缆。例如，记录 DC 工单以检查驱动器和扩展器之间的 sas 电缆。
诊断：慢速磁盘设备¶
注意
collectl 是一种开源的性能收集/分析工具。
如果诊断报告了类似 sda: drive is slow 的消息，则应登录到节点并运行以下命令（删除 -c 1 选项以连续监视数据）
$ /usr/bin/collectl -s D -c 1
waiting for 1 second sample...
# DISK STATISTICS (/sec)
# <---------reads---------><---------writes---------><--------averages--------> Pct
#Name KBytes Merged IOs Size KBytes Merged IOs Size RWSize QLen Wait SvcTim Util
sdb 204 0 33 6 43 0 4 11 6 1 7 6 23
sda 84 0 13 6 108 21 6 18 10 1 7 7 13
sdc 100 0 16 6 0 0 0 0 6 1 7 6 9
sdd 140 0 22 6 22 0 2 11 6 1 9 9 22
sde 76 0 12 6 255 0 52 5 5 1 2 1 10
sdf 276 0 44 6 0 0 0 0 6 1 11 8 38
sdg 112 0 17 7 18 0 2 9 6 1 7 7 13
sdh 3552 0 73 49 0 0 0 0 48 1 9 8 62
sdi 72 0 12 6 0 0 0 0 6 1 8 8 10
sdj 112 0 17 7 22 0 2 11 7 1 10 9 18
sdk 120 0 19 6 21 0 2 11 6 1 8 8 16
sdl 144 0 22 7 18 0 2 9 6 1 9 7 18
dm-0 0 0 0 0 0 0 0 0 0 0 0 0 0
dm-1 0 0 0 0 60 0 15 4 4 0 0 0 0
dm-2 0 0 0 0 48 0 12 4 4 0 0 0 0
dm-3 0 0 0 0 0 0 0 0 0 0 0 0 0
dm-4 0 0 0 0 0 0 0 0 0 0 0 0 0
dm-5 0 0 0 0 0 0 0 0 0 0 0 0 0
查看 Wait 和 SvcTime 值。这些值超过 50 毫秒是不正常的。已知这会影响客户性能（上传/下载）。对于控制器问题，许多/所有驱动器都会显示较长的等待时间和响应时间。重启可能会解决问题；否则需要更换硬件。
另一种查看数据的方式如下
$ /opt/hp/syseng/disk-anal.pl -d
Disk: sda Wait: 54580 371 65 25 12 6 6 0 1 2 0 46
Disk: sdb Wait: 54532 374 96 36 16 7 4 1 0 2 0 46
Disk: sdc Wait: 54345 554 105 29 15 4 7 1 4 4 0 46
Disk: sdd Wait: 54175 553 254 31 20 11 6 6 2 2 1 53
Disk: sde Wait: 54923 66 56 15 8 7 7 0 1 0 2 29
Disk: sdf Wait: 50952 941 565 403 426 366 442 447 338 99 38 97
Disk: sdg Wait: 50711 689 808 562 642 675 696 185 43 14 7 82
Disk: sdh Wait: 51018 668 688 483 575 542 692 275 55 22 9 87
Disk: sdi Wait: 51012 1011 849 672 568 240 344 280 38 13 6 81
Disk: sdj Wait: 50724 743 770 586 662 509 684 283 46 17 11 79
Disk: sdk Wait: 50886 700 585 517 633 511 729 352 89 23 8 81
Disk: sdl Wait: 50106 617 794 553 604 504 532 501 288 234 165 216
Disk: sda Time: 55040 22 16 6 1 1 13 0 0 0 3 12
Disk: sdb Time: 55014 41 19 8 3 1 8 0 0 0 3 17
Disk: sdc Time: 55032 23 14 8 9 2 6 1 0 0 0 19
Disk: sdd Time: 55022 29 17 12 6 2 11 0 0 0 1 14
Disk: sde Time: 55018 34 15 11 12 1 9 0 0 0 2 12
Disk: sdf Time: 54809 250 45 7 1 0 0 0 0 0 1 1
Disk: sdg Time: 55070 36 6 2 0 0 0 0 0 0 0 0
Disk: sdh Time: 55079 33 2 0 0 0 0 0 0 0 0 0
Disk: sdi Time: 55074 28 7 2 0 0 2 0 0 0 0 1
Disk: sdj Time: 55067 35 10 0 1 0 0 0 0 0 0 1
Disk: sdk Time: 55068 31 10 3 0 0 1 0 0 0 0 1
Disk: sdl Time: 54905 130 61 7 3 4 1 0 0 0 0 3
这显示了一天内等待时间和响应时间的历史分布。阅读方式如下
sda 执行了 54580 次操作，等待时间较短，371 次操作等待时间较长，65 次操作等待时间更长。
sdl 执行了 50106 次操作，等待时间较短，但正如你所看到的，许多操作花费了更长时间。
很明显，sdf 到 sdl 存在问题。实际上，sda 到 sde 通常会有很多零数据。但也许这是一个繁忙的系统。在这个例子中，更换控制器是值得的，因为单个驱动器可能没问题。
更换控制器后，使用 collectl -s D（如上所述）查看问题是否已解决。disk-anal.pl 将继续显示历史数据。你可以按如下方式查看最近的数据。它仅查看 13:15 到 14:15 的数据。正如你所看到的，这是一个相对干净的系统（很少或没有较长的等待或响应时间）
$ /opt/hp/syseng/disk-anal.pl -d -t 13:15-14:15
Disk: sda Wait: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdb Wait: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdc Wait: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdd Wait: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sde Wait: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdf Wait: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdg Wait: 3594 6 0 0 0 0 0 0 0 0 0 0
Disk: sdh Wait: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdi Wait: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdj Wait: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdk Wait: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdl Wait: 3599 1 0 0 0 0 0 0 0 0 0 0
Disk: sda Time: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdb Time: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdc Time: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdd Time: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sde Time: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdf Time: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdg Time: 3594 6 0 0 0 0 0 0 0 0 0 0
Disk: sdh Time: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdi Time: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdj Time: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdk Time: 3600 0 0 0 0 0 0 0 0 0 0 0
Disk: sdl Time: 3599 1 0 0 0 0 0 0 0 0 0 0
对于较长的等待时间，如果响应时间看起来正常，请检查逻辑驱动器缓存状态。虽然缓存可能已启用，但它可以按驱动器禁用。
诊断：慢网络链路 - 测量网络性能¶
网络故障可能导致 Swift 节点之间的性能下降。建议使用 netperf 进行测试。其他方法（例如复制大文件）也可能有效，但可能会产生不确定的结果。
如果尚未安装，请在所有系统上安装 netperf。检查其控制端口的 UFW 规则是否到位。但是，netperf 的数据连接没有预先打开的端口。选择一个端口号。在此示例中，使用 12866，因为它比 netperf 的默认控制端口号 12865 大 1。如果得到非常奇怪的结果，包括零值，你可能没有在目标上打开 UFW 中的数据端口，或者你可能输入了错误的 netperf 命令行。
选择一个 source 和 target 节点。源通常是代理节点，目标通常是对象节点。使用相同的源代理，你可以测试与不同 AZ 中的不同对象节点的通信，以识别可能的瓶颈。
运行测试¶
按如下方式准备
target节点$ sudo iptables -I INPUT -p tcp -j ACCEPT
或者，执行
$ sudo ufw allow 12866/tcp
在
source节点上，运行以下命令以检查吞吐量。请注意，-P 选项前有双破折号。该命令需要 10 秒才能完成。target节点是 192.168.245.5。$ netperf -H 192.168.245.5 -- -P 12866 MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 12866 AF_INET to <redacted>.72.4 (<redacted>.72.4) port 12866 AF_INET : demo Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 10.02 923.69
在
source节点上，运行以下命令以检查延迟$ netperf -H 192.168.245.5 -t TCP_RR -- -P 12866 MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 12866 AF_INET to <redacted>.72.4 (<redacted>.72.4) port 12866 AF_INET : demo : first burst 0 Local Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 16384 87380 1 1 10.00 11753.37 16384 87380
预期结果¶
故障将显示在不同节点对之间的差异。但是，作为参考，以下是一些预期数字
对于吞吐量，代理到代理，预计为 ~9300 Mbit/sec（代理具有 10Ge 链路）。
对于吞吐量，代理到对象，预计为 ~920 Mbit/sec（在撰写本文时，对象节点具有 1Ge 链路）。
对于吞吐量，对象到对象，预计为 ~920 Mbit/sec。
对于延迟（所有类型），预计为 ~11000 个事务/秒。
诊断：重新映射正在经历 URE 的扇区¶
在
kern.log中找到坏扇区、设备和文件系统。设置环境变量 SEC、DEV 和 FS，例如
$ SEC=2930954256 $ DEV=/dev/sdi $ FS=/dev/sdi1
验证扇区是否损坏
$ sudo dd if=${DEV} of=/dev/null bs=512 count=1 skip=${SEC}
如果扇区损坏，此命令将输出输入/输出错误
dd: reading `/dev/sdi`: Input/output error 0+0 records in 0+0 records out
防止 chef 在修复进行时尝试重新挂载文件系统
$ sudo mv /etc/chef/client.pem /etc/chef/xx-client.xx-pem
停止 Swift 和 rsync 服务
$ sudo service rsync stop $ sudo swift-init shutdown all
卸载有问题驱动器
$ sudo umount ${FS}
覆盖/重新映射坏扇区
$ sudo dd_rescue -d -A -m8b -s ${SEC}b ${DEV} ${DEV}
首次运行此命令时，该命令应报告输入/输出错误。如果成功重新映射了坏扇区，第二次运行该命令不应报告输入/输出错误。
验证扇区现在可读
$ sudo dd if=${DEV} of=/dev/null bs=512 count=1 skip=${SEC}
如果扇区现在可读，此命令不应报告输入/输出错误。
如果列出了多个有问题扇区，请将 SEC 环境变量设置为列表中下一个扇区
$ SEC=123456789
从第 8 步重复。
修复文件系统
$ sudo xfs_repair ${FS}
如果
xfs_repair报告文件系统具有有价值的文件系统更改$ sudo xfs_repair ${FS} Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this.
你应该尝试挂载文件系统，并清除 lost+found 区域
$ sudo mount $FS /mnt $ sudo rm -rf /mnt/lost+found/* $ sudo umount /mnt
如果文件系统无法挂载，则需要使用
xfs_repair -L选项强制日志清零。重复第 11 步。如果
xfs_repair报告遇到其他输入/输出错误，请按如下方式获取扇区详细信息$ sudo grep "I/O error" /var/log/kern.log | grep sector | tail -1
如果报告了新的输入/输出错误，请将 SEC 环境变量设置为有问题扇区号
$ SEC=234567890
从第 8 步重复
重新挂载文件系统并重新启动 swift 和 rsync。
如果 kern.log 中的所有 URE 都已修复，并且你仍然无法修复 xfs_repair 磁盘，则可能是 URE 损坏了文件系统或可能完全破坏了驱动器。在这种情况下，第一步是重新格式化文件系统，如果失败，则更换磁盘。
诊断：高系统延迟¶
注意
此处描述的延迟测量特定于 HPE Helion Public Cloud。
代理服务器上的坏网卡。但是，如上所述，这通常会导致峰值上升，但平均值应保持在正常参数附近。快速解决方法是关闭代理。
卡住的 memcache 服务器。接受连接，但随后不会响应。预计会在
/var/log/proxy.log（端口 11211）中看到超时消息。Swift Diags 也会将其报告为失败的节点/端口。快速解决方法是关闭代理服务器。坏的/损坏的对象服务器也会导致问题，如果监视程序使用的帐户恰好位于坏的对象服务器上。
数据中心的通用网络问题。将结果与 Pingdom 监视器进行比较，看看它们是否也存在问题。
诊断：接口报告错误¶
如果 Swift 节点上的网络接口开始报告网络错误，则可能表明存在电缆、交换机或网络问题。
使用以下命令获取接口概览
$ sudo ifconfig eth{n}
$ sudo ethtool eth{n}
如果网卡已连接电缆，则 Link Detected: 指示器将显示 yes。
使用以下命令确定适配器类型
$ sudo ethtool -i eth{n}
使用以下命令收集接口统计信息
$ sudo ethtool -S eth{n}
如果网卡支持自检，可以使用以下命令执行自检
$ sudo ethtool -t eth{n}
如果网卡正常运行，自检应显示 PASS。
可以通过小心地卸载和重新安装模块（这避免了重新启动服务器）来重新初始化网卡模块驱动程序。例如，mellanox 驱动程序使用两部分驱动程序 mlx4_en 和 mlx4_core。要重新加载这些驱动程序，必须小心地删除 mlx4_en（以太网）然后是 mlx4_core 模块，并以相反的顺序重新安装它们。
由于在卸载模块时接口将被禁用，因此你必须非常小心不要把自己锁定在外，因此最好编写脚本。
诊断：挂起的 swift 对象复制器¶
复制器在其日志中报告剩余时间超过 100 小时。这可能表明 swift object-replicator 卡住且没有进展。另一种检查此情况的有用方法是在 swift 代理服务器上使用“swift-recon -r”命令
$ sudo swift-recon -r
===============================================================================
--> Starting reconnaissance on 384 hosts
===============================================================================
[2013-07-17 12:56:19] Checking on replication
[replication_time] low: 2, high: 80, avg: 28.8, total: 11037, Failed: 0.0%, no_result: 0, reported: 383
Oldest completion was 2013-06-12 22:46:50 (12 days ago) by 192.168.245.3:6200.
Most recent completion was 2013-07-17 12:56:19 (5 seconds ago) by 192.168.245.5:6200.
===============================================================================
此示例中 Oldest completion 行表明 swift 对象服务器 192.168.245.3 上的 object-replicator 尚未完成复制周期 12 天。此复制器卡住了。对象复制器周期通常小于 1 小时。虽然如果将节点添加到系统并部署了新环，则复制器周期可能为 15-20 小时。
你可以通过登录对象服务器并使用以下命令检查对象复制器进度来进一步检查对象复制器是否卡住
$ sudo grep object-rep /var/log/swift/background.log | grep -e "Starting object replication" -e "Object replication complete" -e "partitions rep"
Jul 16 06:25:46 192.168.245.4 object-replicator 15344/16450 (93.28%) partitions replicated in 69018.48s (0.22/sec, 22h remaining)
Jul 16 06:30:46 192.168.245.4object-replicator 15344/16450 (93.28%) partitions replicated in 69318.58s (0.22/sec, 22h remaining)
Jul 16 06:35:46 192.168.245.4 object-replicator 15344/16450 (93.28%) partitions replicated in 69618.63s (0.22/sec, 23h remaining)
Jul 16 06:40:46 192.168.245.4 object-replicator 15344/16450 (93.28%) partitions replicated in 69918.73s (0.22/sec, 23h remaining)
Jul 16 06:45:46 192.168.245.4 object-replicator 15348/16450 (93.30%) partitions replicated in 70218.75s (0.22/sec, 24h remaining)
Jul 16 06:50:47 192.168.245.4object-replicator 15348/16450 (93.30%) partitions replicated in 70518.85s (0.22/sec, 24h remaining)
Jul 16 06:55:47 192.168.245.4 object-replicator 15348/16450 (93.30%) partitions replicated in 70818.95s (0.22/sec, 25h remaining)
Jul 16 07:00:47 192.168.245.4 object-replicator 15348/16450 (93.30%) partitions replicated in 71119.05s (0.22/sec, 25h remaining)
Jul 16 07:05:47 192.168.245.4 object-replicator 15348/16450 (93.30%) partitions replicated in 71419.15s (0.21/sec, 26h remaining)
Jul 16 07:10:47 192.168.245.4object-replicator 15348/16450 (93.30%) partitions replicated in 71719.25s (0.21/sec, 26h remaining)
Jul 16 07:15:47 192.168.245.4 object-replicator 15348/16450 (93.30%) partitions replicated in 72019.27s (0.21/sec, 27h remaining)
Jul 16 07:20:47 192.168.245.4object-replicator 15348/16450 (93.30%) partitions replicated in 72319.37s (0.21/sec, 27h remaining)
Jul 16 07:25:47 192.168.245.4 object-replicator 15348/16450 (93.30%) partitions replicated in 72619.47s (0.21/sec, 28h remaining)
Jul 16 07:30:47 192.168.245.4 object-replicator 15348/16450 (93.30%) partitions replicated in 72919.56s (0.21/sec, 28h remaining)
Jul 16 07:35:47 192.168.245.4 object-replicator 15348/16450 (93.30%) partitions replicated in 73219.67s (0.21/sec, 29h remaining)
Jul 16 07:40:47 192.168.245.4 object-replicator 15348/16450 (93.30%) partitions replicated in 73519.76s (0.21/sec, 29h remaining)
上述状态每 5 分钟输出到 /var/log/swift/background.log。
注意
“remaining”时间随着时间的推移而增加，通常剩余时间应减少。另请注意分区号。例如，15344 在几个状态行中保持不变。最终，对象复制器检测到挂起并尝试通过杀死有问题线程来取得进展。复制器然后继续到下一个分区，但通常它会再次卡在同一个分区上。
对象复制器卡住的其中一个原因是驱动器上的文件系统损坏。以下是对象复制器检测到的损坏文件系统的典型日志条目
$ sudo bzgrep "Remote I/O error" /var/log/swift/background.log* |grep srv | - tail -1
Jul 12 03:33:30 192.168.245.4 object-replicator STDOUT: ERROR:root:Error hashing suffix#012Traceback (most recent call last):#012 File
"/usr/lib/python2.7/dist-packages/swift/obj/replicator.py", line 199, in get_hashes#012 hashes[suffix] = hash_suffix(suffix_dir,
reclaim_age)#012 File "/usr/lib/python2.7/dist-packages/swift/obj/replicator.py", line 84, in hash_suffix#012 path_contents =
sorted(os.listdir(path))#012OSError: [Errno 121] Remote I/O error: '/srv/node/disk4/objects/1643763/b51'
对有问题文件或目录的 ls 通常显示如下内容
$ ls -l /srv/node/disk4/objects/1643763/b51
ls: cannot access /srv/node/disk4/objects/1643763/b51: Remote I/O error
如果在 background.log 中未出现带有 Remote I/O error 的条目，则无法确定对象复制器卡住的原因。可能是 Remote I/O error 条目早于 7 天，因此已从日志中轮换。在这种情况下，最好只是重新启动对象复制器。
停止对象复制器
# sudo swift-init object-replicator stop
确保对象复制器已停止，如果它已卡住，则停止命令将无法停止卡住的进程
# ps auxww | - grep swift-object-replicator
如果上一个 ps 显示对象复制器仍在运行，请杀死该进程
# kill -9 <pid-of-swift-object-replicator>
启动对象复制器
# sudo swift-init object-replicator start
如果上述 grep 找到了 Remote I/O error，则可能可以修复有问题的文件系统。
停止 swift 和 rsync
# sudo swift-init all shutdown # sudo service rsync stop
确保所有 swift 进程都已停止
# ps auxww | grep swift | grep python
杀死仍在运行的任何 swift 进程。
卸载有问题的文件系统
# sudo umount /srv/node/disk4
修复文件系统
# sudo xfs_repair -P /dev/sde1
如果
xfs_repair失败，则可能需要重新格式化文件系统。请参阅 Procedure: Fix broken XFS filesystem。如果xfs_repair成功，请使用以下命令重新启用 chef，并应重新开始复制。
诊断：高 CPU 负载¶
如“uptime”命令所示，对象服务器上的 CPU 负载平均值通常在服务器负载轻度到中度时低于 10
$ uptime
07:59:26 up 99 days, 5:57, 1 user, load average: 8.59, 8.39, 8.32
在活动增加期间，由于用户事务或对象复制，CPU 负载平均值可以增加到大约 30。
但是，有时 CPU 负载平均值会显著增加。以下是 CPU 负载极高的对象服务器示例
$ uptime
07:44:02 up 18:22, 1 user, load average: 407.12, 406.36, 404.59
进一步的问题和解决方案¶
注意
每个 Action 列中的紧急程度级别指示是否需要立即采取行动，或者问题是否可以在工作时间内处理。
场景 |
描述 |
行动 |
|---|---|---|
|
|
检查网络。使用 紧急程度：如果还有其他迹象表明你的系统速度慢，你应该将此视为紧急问题。 |
Swift 进程未运行。 |
你可以使用 |
运行此命令 $ sudo swift-init all start
检查 swift 日志文件中的消息，查看自您运行 采取任何看似必要的纠正措施。 紧急程度：如果这仅影响一台服务器，并且您有多台服务器，则识别和解决问题可以等到工作时间。如果相同的问题影响多台服务器，则需要立即采取纠正措施。 |
ntpd 未运行。 |
NTP 未运行。 |
配置并启动 NTP。 紧急程度：对于代理服务器，这至关重要。 |
主机时钟未与 NTP 服务器同步。 |
节点时间设置与 NTP 服务器时间不匹配。重启后同步可能需要一些时间。 |
假设 NTP 已配置并正在运行，您必须等待时间同步。 |
一个 swift 进程拥有数百到数千个打开的文件描述符。 |
可能发生在任何 swift 进程中。已知发生在 |
重启受影响节点上的 swift 进程 $ sudo swift-init all reload
|
一个 swift 进程不属于 swift 用户。 |
如果 swift 用户的 UID 已更改，则进程可能不属于该 UID。 |
紧急程度：如果这仅影响一台服务器，并且您有多台服务器，则识别和解决问题可以等到工作时间。如果相同的问题影响多台服务器，则需要立即采取纠正措施。 |
对象帐户或容器文件不属于 swift。 |
这通常发生在服务器重新安装或重新镜像期间，swift 用户的 UID 已更改。对象帐户和容器目录中的数据文件属于原始 swift UID。因此，当前 swift 用户不拥有这些文件。 |
将 swift 用户的 UID 更正为与原始 UID 一致。另一种方法是更改所有文件系统上每个文件的所有权。这种替代方法通常不切实际，并且需要大量时间。 紧急程度：如果这仅影响一台服务器，并且您有多台服务器，则识别和解决问题可以等到工作时间。如果相同的问题影响多台服务器，则需要立即采取纠正措施。 |
一个磁盘驱动器具有较高的 IO 等待时间或服务时间。 |
如果单个磁盘显示较高的等待 IO 时间，则磁盘驱动器是问题所在。如果大多数/所有设备都较慢，则控制器可能是问题来源。控制器缓存也可能配置不当，这将导致类似的长时间等待或服务时间。 |
首先，如果您的控制器具有缓存，请检查它是否已启用，并且其电池/电容器是否正常工作。 其次，重启服务器。如果问题仍然存在，请提交 DC 工单以更换驱动器或控制器。请参阅 诊断：慢速磁盘设备，了解如何检查驱动器等待时间或服务时间。 紧急程度：中等 |
网络接口未启动。 |
使用 |
您可以尝试重启接口。但是，通常接口（或电缆）可能已损坏，尤其是在接口上下波动的情况下。 紧急程度：如果这仅影响一台服务器，并且您有多台服务器，则识别和解决问题可以等到工作时间。如果相同的问题影响多台服务器，则需要立即采取纠正措施。 |
网络接口卡 (NIC) 未以预期的速度运行。 |
NIC 的运行速度低于其标称额定速度。例如，它以 100 Mb/s 的速度运行，而 NIC 是 1Ge NIC。 |
紧急程度：高 |
接口 RX/TX 错误计数非零。 |
通常值为 0，但计数为 1 或 2 不表示有问题。 |
紧急程度：高，如果错误计数正在增加。 |
在 swift 日志中，您会看到一条消息，表明一个进程已经超过 24 小时未复制。 |
复制器在过去 24 小时内未成功完成一次运行。这表明复制器可能已挂起。 |
使用 紧急程度：低。但是，如果您最近添加或更换了磁盘驱动器，则应紧急处理此问题。 |
容器更新器未在 4 小时内运行。 |
该服务可能正在运行，但是，它可能已挂起。检查它们的 swift 日志，查看是否有与容器更新器相关的任何错误消息。这可能潜在地解释了为什么容器未运行。 |
紧急程度：中等。这可能是由最近重启 rsyslog 守护程序引起的。使用以下命令重启服务： $ sudo swift-init <service> reload
|
对象复制器：报告剩余时间，并且该时间超过 100 小时。 |
每次复制周期，对象复制器都会将其日志记录到日志中，报告有关当前周期的统计信息。这包括估计完成所有对象复制所需的剩余时间。如果此时间超过 100 小时，则复制过程中存在问题。 |
紧急程度：中等。使用以下命令重启服务： $ sudo swift-init object-replicator reload
检查剩余复制时间是否正在减少。 |
