服务器维护¶
一般假设¶
假设任何尝试更换硬件组件的人员已经阅读并理解了相应的维护和维修指南。
假设如果需要将服务器离线进行硬件更换，将按顺序进行，在将下一个服务器离线之前，先将服务器重新上线。
假设将使用运维指导流程来识别需要更换的硬件。
评估 Swift 的健康状况¶
您可以在 Swift 代理节点上运行 swift-recon 工具，以快速检查 Swift 的运行状况。请注意，以下数字必然具有一定的主观性。有时，对于我们说“低值是好的”的参数，可能会在一段时间内显示出相当高的值。通常，如果您等待一段时间，情况会好转。
例如
$ sudo swift-recon -rla
===============================================================================
[2012-03-10 12:57:21] Checking async pendings on 384 hosts...
Async stats: low: 0, high: 1, avg: 0, total: 1
===============================================================================
[2012-03-10 12:57:22] Checking replication times on 384 hosts...
[Replication Times] shortest: 1.4113877813, longest: 36.8293570836, avg: 4.86278064749
===============================================================================
[2012-03-10 12:57:22] Checking load avg's on 384 hosts...
[5m load average] lowest: 2.22, highest: 9.5, avg: 4.59578125
[15m load average] lowest: 2.36, highest: 9.45, avg: 4.62622395833
[1m load average] lowest: 1.84, highest: 9.57, avg: 4.5696875
===============================================================================
在上面的示例中，我们请求有关复制时间 (-r)、负载平均值 (-l) 和异步挂起 (-a) 的信息。这是一个健康的 Swift 系统。对于“良好”recon 输出的经验法则如下
响应的节点正在运行 Swift。如果所有节点都响应，这是一个好兆头。但有些节点可能会超时。例如
-> [http://<redacted>.29:6200/recon/load:] <urlopen error [Errno 111] ECONNREFUSED> -> [http://<redacted>.31:6200/recon/load:] <urlopen error timed out>
这可能是可以接受的，也可能需要调查。
异步挂起的低值（例如 < 10 对于高和平均值）是好的。较高的值出现在磁盘关闭和/或系统负载过重时。同时向同一个容器进行许多 PUT 操作可能会导致异步挂起增加。这可能是正常的，并且可能在一段时间后自行解决。如果它持续存在，一种跟踪问题的方法是找到具有高异步挂起的节点（使用
swift-recon -av | sort -n -k4），然后检查其 Swift 日志。通常异步挂起很高是因为节点无法将数据写入另一个节点上的容器。通常这是因为节点或磁盘离线或损坏。如果我们知道这一点，这可能是可以接受的。复制时间的低值是好的。当推送新的环时，以及当节点和设备重新上线时，这些值会上升。
我们的“高”负载平均值通常在 9-15 范围内。如果它们更大，值得查看导致平均值上升的系统。运行
swift-recon -av以获取各个平均值。要对条目进行排序，并将最高值放在末尾，请运行swift-recon -av | sort -n -k4。
为了进行比较，这是在两个 Swift 机架完全关闭时相同系统的 recon 输出
[2012-03-10 16:56:33] Checking async pendings on 384 hosts...
-> http://<redacted>.22:6200/recon/async: <urlopen error timed out>
-> http://<redacted>.18:6200/recon/async: <urlopen error timed out>
-> http://<redacted>.16:6200/recon/async: <urlopen error timed out>
-> http://<redacted>.13:6200/recon/async: <urlopen error timed out>
-> http://<redacted>.30:6200/recon/async: <urlopen error timed out>
-> http://<redacted>.6:6200/recon/async: <urlopen error timed out>
.........
-> http://<redacted>.5:6200/recon/async: <urlopen error timed out>
-> http://<redacted>.15:6200/recon/async: <urlopen error timed out>
-> http://<redacted>.9:6200/recon/async: <urlopen error timed out>
-> http://<redacted>.27:6200/recon/async: <urlopen error timed out>
-> http://<redacted>.4:6200/recon/async: <urlopen error timed out>
-> http://<redacted>.8:6200/recon/async: <urlopen error timed out>
Async stats: low: 243, high: 659, avg: 413, total: 132275
===============================================================================
[2012-03-10 16:57:48] Checking replication times on 384 hosts...
-> http://<redacted>.22:6200/recon/replication: <urlopen error timed out>
-> http://<redacted>.18:6200/recon/replication: <urlopen error timed out>
-> http://<redacted>.16:6200/recon/replication: <urlopen error timed out>
-> http://<redacted>.13:6200/recon/replication: <urlopen error timed out>
-> http://<redacted>.30:6200/recon/replication: <urlopen error timed out>
-> http://<redacted>.6:6200/recon/replication: <urlopen error timed out>
............
-> http://<redacted>.5:6200/recon/replication: <urlopen error timed out>
-> http://<redacted>.15:6200/recon/replication: <urlopen error timed out>
-> http://<redacted>.9:6200/recon/replication: <urlopen error timed out>
-> http://<redacted>.27:6200/recon/replication: <urlopen error timed out>
-> http://<redacted>.4:6200/recon/replication: <urlopen error timed out>
-> http://<redacted>.8:6200/recon/replication: <urlopen error timed out>
[Replication Times] shortest: 1.38144306739, longest: 112.620954418, avg: 10.285
9475361
===============================================================================
[2012-03-10 16:59:03] Checking load avg's on 384 hosts...
-> http://<redacted>.22:6200/recon/load: <urlopen error timed out>
-> http://<redacted>.18:6200/recon/load: <urlopen error timed out>
-> http://<redacted>.16:6200/recon/load: <urlopen error timed out>
-> http://<redacted>.13:6200/recon/load: <urlopen error timed out>
-> http://<redacted>.30:6200/recon/load: <urlopen error timed out>
-> http://<redacted>.6:6200/recon/load: <urlopen error timed out>
............
-> http://<redacted>.15:6200/recon/load: <urlopen error timed out>
-> http://<redacted>.9:6200/recon/load: <urlopen error timed out>
-> http://<redacted>.27:6200/recon/load: <urlopen error timed out>
-> http://<redacted>.4:6200/recon/load: <urlopen error timed out>
-> http://<redacted>.8:6200/recon/load: <urlopen error timed out>
[5m load average] lowest: 1.71, highest: 4.91, avg: 2.486375
[15m load average] lowest: 1.79, highest: 5.04, avg: 2.506125
[1m load average] lowest: 1.46, highest: 4.55, avg: 2.4929375
===============================================================================
注意
即使有 80 个对象存储关闭，复制时间和负载平均值也在合理范围内。然而，异步挂起却很高。这是因为关闭的服务器上的容器无法更新。当这些服务器恢复时，异步挂起应该会下降。如果异步挂起在没有解释的情况下处于这个水平，我们就有问题了。
Recon 示例¶
这是一个记录和使用 recon 解决问题的示例。
运行 recon 显示了一些异步挂起
$ ssh -q <redacted>.132.7 sudo swift-recon -alr
===============================================================================
[2012-03-14 17:25:55] Checking async pendings on 384 hosts...
Async stats: low: 0, high: 23, avg: 8, total: 3356
===============================================================================
[2012-03-14 17:25:55] Checking replication times on 384 hosts...
[Replication Times] shortest: 1.49303831657, longest: 39.6982825994, avg: 4.2418222066
===============================================================================
[2012-03-14 17:25:56] Checking load avg's on 384 hosts...
[5m load average] lowest: 2.35, highest: 8.88, avg: 4.45911458333
[15m load average] lowest: 2.41, highest: 9.11, avg: 4.504765625
[1m load average] lowest: 1.95, highest: 8.56, avg: 4.40588541667
===============================================================================
为什么？再次运行带有 -av swift 的 recon（此处未显示）告诉我们，具有最高值 (23) 的节点是 <redacted>.72.61。查看 <redacted>.72.61 上的日志文件，我们看到
$ sudo tail -f /var/log/swift/background.log | - grep -i ERROR
Mar 14 17:28:06 <redacted> container-replicator ERROR Remote drive not mounted
{'zone': 5, 'weight': 1952.0, 'ip': '<redacted>.204.119', 'id': 5481, 'meta': '', 'device': 'disk6', 'port': 6201}
Mar 14 17:28:06 <redacted> container-replicator ERROR Remote drive not mounted
{'zone': 5, 'weight': 1952.0, 'ip': '<redacted>.204.119', 'id': 5481, 'meta': '', 'device': 'disk6', 'port': 6201}
Mar 14 17:28:09 <redacted> container-replicator ERROR Remote drive not mounted
{'zone': 5, 'weight': 1952.0, 'ip': '<redacted>.204.20', 'id': 2311, 'meta': '', 'device': 'disk5', 'port': 6201}
Mar 14 17:28:11 <redacted> container-replicator ERROR Remote drive not mounted
{'zone': 5, 'weight': 1952.0, 'ip': '<redacted>.204.20', 'id': 2311, 'meta': '', 'device': 'disk5', 'port': 6201}
Mar 14 17:28:13 <redacted> container-replicator ERROR Remote drive not mounted
{'zone': 5, 'weight': 1952.0, 'ip': '<redacted>.204.119', 'id': 5481, 'meta': '', 'device': 'disk6', 'port': 6201}
Mar 14 17:28:13 <redacted> container-replicator ERROR Remote drive not mounted
{'zone': 5, 'weight': 1952.0, 'ip': '<redacted>.204.119', 'id': 5481, 'meta': '', 'device': 'disk6', 'port': 6201}
Mar 14 17:28:15 <redacted> container-replicator ERROR Remote drive not mounted
{'zone': 5, 'weight': 1952.0, 'ip': '<redacted>.204.20', 'id': 2311, 'meta': '', 'device': 'disk5', 'port': 6201}
Mar 14 17:28:15 <redacted> container-replicator ERROR Remote drive not mounted
{'zone': 5, 'weight': 1952.0, 'ip': '<redacted>.204.20', 'id': 2311, 'meta': '', 'device': 'disk5', 'port': 6201}
Mar 14 17:28:19 <redacted> container-replicator ERROR Remote drive not mounted
{'zone': 5, 'weight': 1952.0, 'ip': '<redacted>.204.20', 'id': 2311, 'meta': '', 'device': 'disk5', 'port': 6201}
Mar 14 17:28:19 <redacted> container-replicator ERROR Remote drive not mounted
{'zone': 5, 'weight': 1952.0, 'ip': '<redacted>.204.20', 'id': 2311, 'meta': '', 'device': 'disk5', 'port': 6201}
Mar 14 17:28:20 <redacted> container-replicator ERROR Remote drive not mounted
{'zone': 5, 'weight': 1952.0, 'ip': '<redacted>.204.119', 'id': 5481, 'meta': '', 'device': 'disk6', 'port': 6201}
Mar 14 17:28:21 <redacted> container-replicator ERROR Remote drive not mounted
{'zone': 5, 'weight': 1952.0, 'ip': '<redacted>.204.20', 'id': 2311, 'meta': '', 'device': 'disk5', 'port': 6201}
Mar 14 17:28:21 <redacted> container-replicator ERROR Remote drive not mounted
{'zone': 5, 'weight': 1952.0, 'ip': '<redacted>.204.20', 'id': 2311, 'meta': '', 'device': 'disk5', 'port': 6201}
Mar 14 17:28:22 <redacted> container-replicator ERROR Remote drive not mounted
{'zone': 5, 'weight': 1952.0, 'ip': '<redacted>.204.20', 'id': 2311, 'meta': '', 'device': 'disk5', 'port': 6201}
这就是为什么此节点具有许多异步挂起：一些未挂载在 <redacted> 和 <redacted> 上的磁盘。可能还有其他问题，但解决这个问题可能会大大减少异步挂起，因为其他节点也会遇到相同的问题。
当多个存储服务器关闭时评估可用性风险¶
注意
此过程会告诉您是否存在问题，但是，在实践中，您会发现您不会经常使用此过程。
如果三个存储节点（或者，更准确地说，三个不同存储节点上的三个磁盘）关闭，则用户对象、容器或帐户不可用的概率很小但非零。
步骤¶
注意
swift 有三个环：分别用于对象、容器和帐户。应在代理节点上运行此过程三次，每次指定适当的 *.builder 文件。
通过在代理节点上运行环构建器来确定存储节点位于哪个 Swift 区域，以确定所有三个节点是否位于不同的 Swift 区域。例如
% sudo swift-ring-builder /etc/swift/object.builder /etc/swift/object.builder, build version 1467 2097152 partitions, 3 replicas, 5 zones, 1320 devices, 0.02 balance The minimum number of hours before a partition can be reassigned is 24 Devices: id zone ip address port name weight partitions balance meta 0 1 <redacted>.4 6200 disk0 1708.00 4259 -0.00 1 1 <redacted>.4 6200 disk1 1708.00 4260 0.02 2 1 <redacted>.4 6200 disk2 1952.00 4868 0.01 3 1 <redacted>.4 6200 disk3 1952.00 4868 0.01 4 1 <redacted>.4 6200 disk4 1952.00 4867 -0.01
这里，节点 <redacted>.4 位于区域 1。如果正在考虑的三个节点中的两个或更多节点位于同一 Swift 区域，它们没有共同的环分区；如果所有三个节点都关闭，则几乎没有数据可用性风险。
如果节点位于三个不同的 Swift 区域，则需要确定节点是否具有共同的环分区。再次运行
swift-ring构建器，这次使用list_parts选项并指定正在考虑的节点。例如% sudo swift-ring-builder /etc/swift/object.builder list_parts <redacted>.8 <redacted>.15 <redacted>.72.2 Partition Matches 91 2 729 2 3754 2 3769 2 3947 2 5818 2 7918 2 8733 2 9509 2 10233 2
环构建器的
list_parts选项指示节点有多少个环分区是相同的。如果，在这种情况下，列表中的第一项的“Matches”列为 2 或更少，则如果所有三个节点都关闭，则没有数据可用性风险。如果“Matches”列包含等于 3 的条目，则如果所有三个节点都关闭，则存在一些数据可用性风险。风险通常很小，并且与“Matches”列中具有 3 的条目数成正比。例如
Partition Matches 26865 3 362367 3 745940 3 778715 3 797559 3 820295 3 822118 3 839603 3 852332 3 855965 3 858016 3
快速计算具有 3 个匹配项的行数的方法是
% sudo swift-ring-builder /etc/swift/object.builder list_parts <redacted>.8 <redacted>.15 <redacted>.72.2 | grep "3$" | wc -l 30
在这种情况下，节点有 30 个，总共有 2097152 个分区；大约为 0.001%。在这种情况下，风险很小/非零。请记住，分区只是环映射空间的一部分，而不是实际数据。因此，具有共同分区是数据不可用性的必要条件，但不是充分条件。
注意
我们不应该为了维修而关闭一个节点，如果它显示与其他也已关闭的节点有 3 个“Matches”条目。
如果三个具有 3 个分区相同的节点都关闭，则数据不可用的概率非零，我们应该努力尽快启动一些或所有节点。
Swift 启动/关闭¶
使用 reload - 不要 stop/start/restart。
尝试以小于您服务器 20% 的组来滚动服务器（尤其是代理）。
