管理员指南

定义存储策略

使用 Swift 定义存储策略非常简单。重要的是，管理员在实际创建和使用存储策略之前，应了解其背后的概念，以便充分利用该功能，更重要的是，避免在策略部署到集群后进行不必要的更改。

强烈建议读者在进行策略管理之前，完整阅读并理解存储策略。请仔细规划，建议先在非生产集群上进行试验，以确保所需的配置满足用户需求。在规划现有部署的升级之前，请参阅升级和确认功能。

以下是您决定要执行的操作后，配置策略的几个简单步骤的高级视图

1. 在/etc/swift/swift.conf中定义您的策略

2. 创建相应的对象环

3. 将存储策略的名称告知集群用户

有关逐步说明的具体示例，请参阅向现有 SAIO 添加存储策略

管理环

您可以在任何安装了相应 Swift 版本的服务器上构建存储环。一旦构建或更改（重新平衡），您必须将环分发到集群中的所有服务器。存储环包含有关所有 Swift 存储分区以及它们如何在不同节点和磁盘之间分布的信息。

Swift 1.6.0 是最后一个使用 Python pickle 格式的版本。后续版本使用不同的序列化格式。**Swift 1.6.0 及更早版本生成的环可以被任何版本读取，但 1.6.0 之后生成的环只能被大于 1.6.0 的 Swift 版本读取。**因此，从 1.6.0 或更早版本升级到大于 1.6.0 的版本时，要么在所有 Swift 节点成功升级后**最后**升级您的环构建服务器，要么在所有 Swift 节点成功升级之前不要生成环。

如果您需要从大于 1.6.0 的 Swift 版本降级到小于或等于 1.6.0 的版本，请首先降级您的环构建服务器，生成新环，将其推送出去，然后继续其余的降级操作。

有关更多信息，请参阅环。

从环中删除设备

swift-ring-builder <builder-file> remove <ip_address>/<device_name>

从环中删除服务器

swift-ring-builder <builder-file> remove <ip_address>

向环中添加设备

请参阅准备环

查看服务器的哪些设备在环中

swift-ring-builder <builder-file> search <ip_address>

完成对环的所有更改后，需要“提交”这些更改

swift-ring-builder <builder-file> rebalance

新环构建完成后，应将其推送到集群中的所有服务器。

可选地，如果以“swift-ring-builder-safe”调用，则包含指定构建器文件的目录将被锁定（通过父目录中的.lock文件）。这提供了一个基本的安全防护措施，以防止swift-ring-builder的多个实例（或遵守此锁定的其他实用程序）在操作进行时尝试写入或读取构建器/环文件。这在环管理已自动化但操作员仍需要手动与环交互的环境中可能很有用。

如果环构建器没有产生您期望的平衡，您可以使用--debug标志来了解它正在做什么。

swift-ring-builder <builder-file> rebalance --debug

这会产生大量的输出，主要在您（a）尝试修复环构建器，或（b）针对环构建器提交错误时有用。

您可能会在重新平衡输出中注意到一个“分散”数字。这个数字的含义在分散中进行了解释，但本质上是环中在特定故障域内副本过多的分区百分比。您可以通过以下命令询问“swift-ring-builder”分散度

swift-ring-builder <builder-file> dispersion

这将再次给您百分比，如果您想查看详细的分散情况，只需添加--verbose

swift-ring-builder <builder-file> dispersion --verbose

这不仅会显示百分比，还会显示一个按层级列出分区分散情况的分散表。您可以使用此表来找出需要在哪里增加容量，或帮助调整过载值。

现在让我们以一个区域、三个区域和四个设备的例子。每个设备具有相同的权重，dispersion --verbose可能会显示以下内容

Dispersion is 16.666667, Balance is 0.000000, Overload is 0.00%
Required overload is 33.333333%
Worst tier is 33.333333 (r1z3)
--------------------------------------------------------------------------
Tier                           Parts      %    Max     0     1     2     3
--------------------------------------------------------------------------
r1                               768   0.00      3     0     0     0   256
r1z1                             192   0.00      1    64   192     0     0
r1z1-127.0.0.1                   192   0.00      1    64   192     0     0
r1z1-127.0.0.1/sda               192   0.00      1    64   192     0     0
r1z2                             192   0.00      1    64   192     0     0
r1z2-127.0.0.2                   192   0.00      1    64   192     0     0
r1z2-127.0.0.2/sda               192   0.00      1    64   192     0     0
r1z3                             384  33.33      1     0   128   128     0
r1z3-127.0.0.3                   384  33.33      1     0   128   128     0
r1z3-127.0.0.3/sda               192   0.00      1    64   192     0     0
r1z3-127.0.0.3/sdb               192   0.00      1    64   192     0     0

第一行报告区域 1 中有 256 个分区，每个分区有 3 个副本；在这种情况下（具有 3 个副本的单个区域），这是预期的输出，如“最大值”所报告。

然而，集群中存在一些不平衡，更准确地说是在区域 3 中。“最大值”报告此区域中最多有 1 个副本；但是 50.00% 的分区在此区域中存储 2 个副本（这在某种程度上是预期的，因为此区域中有更多磁盘）。

您现在可以向其他区域添加更多容量，减少区域 3 中的总权重，或者将过载设置为大于 33.333333% 的值 - 仅使用所需的过载量。

脚本化环创建

您可以创建脚本来创建账户和容器环并进行重新平衡。以下是账户环的示例脚本。使用类似的命令在代理服务器节点上创建 make-container-ring.sh 脚本。

1. 在代理服务器节点上创建一个名为 make-account-ring.sh 的脚本文件，内容如下

   #!/bin/bash
   cd /etc/swift
   rm -f account.builder account.ring.gz backups/account.builder backups/account.ring.gz
   swift-ring-builder account.builder create 18 3 1
   swift-ring-builder account.builder add r1z1-<account-server-1>:6202/sdb1 1
   swift-ring-builder account.builder add r1z2-<account-server-2>:6202/sdb1 1
   swift-ring-builder account.builder rebalance
   

   您需要将 <account-server-1>、<account-server-2> 等的值替换为您设置中使用的账户服务器的 IP 地址。您可以根据需要拥有任意数量的账户服务器。所有账户服务器都假定监听端口 6202，并且具有一个名为“sdb1”的存储设备（这是我们在设置账户服务器时在 /drives 下创建的目录名）。“z1”、“z2”等表示区域，您可以选择将设备放在相同或不同的区域中。“r1”表示区域，不同的区域指定为“r1”、“r2”等。

2. 使脚本文件可执行并运行它以创建帐户环文件

   chmod +x make-account-ring.sh
   sudo ./make-account-ring.sh
   

3. 将生成的环文件 /etc/swift/account.ring.gz 复制到 Swift 环境中的所有帐户服务器节点，并将其放在这些节点的 /etc/swift 目录中。确保每次更改帐户环配置时，都将生成的环文件复制到所有帐户节点。

处理系统更新

建议一次一个区域地进行系统更新和重启。这允许更新进行，并使 Swift 集群保持可用并响应请求。还建议在更新一个区域后，让它运行一段时间，然后再更新其他区域，以确保更新没有产生任何不利影响。

处理驱动器故障

如果驱动器发生故障，第一步是确保驱动器已卸载。这将使 Swift 更容易应对故障，直到解决。如果驱动器将立即更换，那么最好直接更换驱动器，格式化，重新挂载，并让复制填充它。

卸载驱动器后，请确保挂载点属于 root (root:root 755)。这可以确保一旦故障驱动器卸载，rsync 将不会尝试复制到根驱动器。

如果驱动器无法立即更换，则最好保持卸载状态，并将设备权重设置为 0。这将允许该驱动器上的所有副本在驱动器更换之前复制到其他位置。一旦驱动器更换，设备权重可以再次增加。将设备权重设置为 0 而不是从环中移除驱动器，可以让 Swift 有机会从故障磁盘复制数据（如果仍然可以读取某些数据）。

将设备权重设置为 0（或从环中移除故障驱动器）还有另一个好处：存储在故障驱动器上的所有分区都分布在集群中剩余的磁盘上，每个磁盘只需要存储少量新分区。这比将所有分区复制到一个新的磁盘要快得多。它显著缩短了从副本数量减少中恢复的时间，并且随着磁盘变大变得越来越重要。

处理服务器故障

如果服务器出现硬件问题，最好确保 Swift 服务没有运行。这将允许 Swift 在您进行故障排除时绕过故障。

如果服务器只需要重启，或者少量工作只需持续几个小时，那么最好让 Swift 绕过故障，然后修复机器并使其重新上线。当机器重新上线时，复制将确保在停机期间丢失的任何内容都将得到更新。

如果服务器出现更严重的问题，那么最好从环中移除所有服务器设备。一旦服务器修复并重新上线，服务器设备可以重新添加到环中。重要的是，在将设备放回环中之前对其进行重新格式化，因为它很可能负责一组与以前不同的分区。

检测故障驱动器

根据我们的经验，当驱动器即将出现故障时，错误消息会大量涌入/var/log/kern.log。有一个名为swift-drive-audit的脚本，可以通过 cron 定期运行以监视故障驱动器。如果检测到错误，它将卸载故障驱动器，以便 Swift 可以绕过它。该脚本接受一个包含以下设置的配置文件

[drive-audit]

选项	默认值	描述
user	swift	将非根任务的权限降级到此用户
log_facility	LOG_LOCAL0	syslog 日志设施
log_level	INFO	日志级别
device_dir	/srv/node	设备挂载目录
分钟	60	在/var/log/kern.log中回溯的分钟数
错误限制	1	卸载设备前查找的错误数
log_file_pattern	/var/log/kern*	带有通配符模式的日志文件位置，用于检查设备错误
regex_pattern_X	（见下文）	用于在日志文件中查找包含错误的设备块的正则表达式模式

用于查找包含错误设备块的默认正则表达式模式是berrorb.*b(sd[a-z]{1,2}d?)b和b(sd[a-z]{1,2}d?)b.*berrorb。可以通过提供使用格式regex_pattern_X = regex_expression的新表达式来覆盖上述默认值，其中X是一个数字。

此脚本已在 Ubuntu 10.04 和 Ubuntu 12.04 上测试过，因此如果您使用的是不同的发行版或操作系统，在生产环境中使用前应谨慎。

防止磁盘满载场景

通过确保proxy-server阻止 PUT 请求并且 rsync 阻止复制到特定驱动器来防止磁盘满载情况。

您可以通过确保在account-server.conf、container-server.conf和object-server.conf中设置了fallocate_reserve来防止proxy-server向低空间磁盘发送 PUT 请求。默认情况下，fallocate_reserve设置为 1%。在对象服务器中，这会阻止导致可用磁盘空间低于磁盘 1% 的 PUT 请求。在账户和容器服务器中，这会阻止在可用磁盘空间低于 1% 时增加账户或容器数据库大小的操作。

强烈建议设置fallocate_reserve以避免磁盘完全填满。当 Swift 的磁盘完全满时，所有涉及这些磁盘的请求都将失败，包括原本会释放空间的 DELETE 请求。这是因为对象删除包括创建一个零字节的墓碑文件（.ts）以记录删除时间用于复制目的；这发生在删除对象数据之前。在完全满的 文件系统上，无法创建该零字节的 .ts 文件，因此 DELETE 请求将失败，并且磁盘将保持完全满。如果设置了fallocate_reserve，那么文件系统将有足够的空间来创建零字节的 .ts 文件，从而对象删除将成功并释放一些空间。

为了防止 rsync 复制到特定驱动器，首先在您的object-replicator中为每个磁盘设置rsync_module。在object-server.conf中进行设置

[object-replicator]
rsync_module = {replication_ip}::object_{device}

在rsync.conf中设置各个驱动器。例如

[object_sda]
max connections = 4
lock file = /var/lock/object_sda.lock

[object_sdb]
max connections = 4
lock file = /var/lock/object_sdb.lock

最后，监控每个磁盘的磁盘空间，并将每个驱动器的 rsync max connections 调整为-1。我们建议您利用现有的监控解决方案来实现此目的。以下是一个示例脚本

#!/usr/bin/env python
import os
import errno

RESERVE = 500 * 2 ** 20  # 500 MiB

DEVICES = '/srv/node1'

path_template = '/etc/rsync.d/disable_%s.conf'
config_template = '''
[object_%s]
max connections = -1
'''

def disable_rsync(device):
    with open(path_template % device, 'w') as f:
        f.write(config_template.lstrip() % device)


def enable_rsync(device):
    try:
        os.unlink(path_template % device)
    except OSError as e:
        # ignore file does not exist
        if e.errno != errno.ENOENT:
            raise


for device in os.listdir(DEVICES):
    path = os.path.join(DEVICES, device)
    st = os.statvfs(path)
    free = st.f_bavail * st.f_frsize
    if free < RESERVE:
        disable_rsync(device)
    else:
        enable_rsync(device)

为了使上述脚本正常工作，请确保包含/etc/rsync.d/配置文件，方法是在您的rsync.conf文件中指定&include

&include /etc/rsync.d

结合 cron 任务使用此脚本定期运行，例如

# /etc/cron.d/devicecheck
* * * * * root /some/path/to/disable_rsync.py

分散报告

有一个 swift-dispersion-report 工具，用于衡量集群的整体健康状况。通过检查一组故意分布的容器和对象当前是否在集群中的正确位置来实现。

例如，一个常见的部署是每个对象有三个副本。可以通过检查每个副本是否在正确的位置来衡量该对象的健康状况。如果只有 3 个副本中的 2 个在位，则该对象的健康状况可以说为 66.66%，而 100% 为完美。

单个对象的健康状况，特别是较旧的对象，通常反映了该对象所在整个分区的健康状况。如果我们创建足够多的对象在集群中不同百分比的分区上，我们可以获得对整体集群健康状况的相当有效的估计。在实践中，大约 1% 的分区覆盖率似乎在准确性和收集结果所需时间之间取得了良好的平衡。

为了提供此健康值，首先需要创建一个专门用于此用途的新帐户。接下来，我们需要将容器和对象放置在整个系统中，以便它们位于不同的分区上。swift-dispersion-populate 工具通过生成随机的容器和对象名称来实现此目的，直到它们落在不同的分区上。最后，并且在集群的整个生命周期中重复，我们需要运行 swift-dispersion-report 工具来检查每个容器和对象的健康状况。

这些工具需要直接访问整个集群和环文件（将其安装在代理服务器上可能会奏效）。swift-dispersion-populate 和 swift-dispersion-report 都使用相同的配置文件，/etc/swift/dispersion.conf。配置文件示例

[dispersion]
auth_url = https://:8080/auth/v1.0
auth_user = test:tester
auth_key = testing
endpoint_type = internalURL

配置文件中也有用于指定分散覆盖率（默认为 1%）、重试次数、并发数等的选项，尽管通常默认值就足够了。如果您想使用 Keystone v3 进行身份验证，则有 auth_version、user_domain_name、project_domain_name 和 project_name 等选项。

配置完成后，运行swift-dispersion-populate以在整个集群中填充容器和对象。

现在这些容器和对象已经就位，您可以运行swift-dispersion-report来获取分散报告，即集群的整体健康状况。这是一个处于完美健康状态的集群示例

$ swift-dispersion-report
Queried 2621 containers for dispersion reporting, 19s, 0 retries
100.00% of container copies found (7863 of 7863)
Sample represents 1.00% of the container partition space

Queried 2619 objects for dispersion reporting, 7s, 0 retries
100.00% of object copies found (7857 of 7857)
Sample represents 1.00% of the object partition space

现在我将故意将对象环中一个设备的权重翻倍（关闭复制），然后重新运行分散报告，以显示其影响

$ swift-ring-builder object.builder set_weight d0 200
$ swift-ring-builder object.builder rebalance
...
$ swift-dispersion-report
Queried 2621 containers for dispersion reporting, 8s, 0 retries
100.00% of container copies found (7863 of 7863)
Sample represents 1.00% of the container partition space

Queried 2619 objects for dispersion reporting, 7s, 0 retries
There were 1763 partitions missing one copy.
77.56% of object copies found (6094 of 7857)
Sample represents 1.00% of the object partition space

您可以看到集群中对象的健康状况显著下降。当然，我这个测试环境只有四个设备，在有大量设备的生产环境中，一个设备的改变影响要小得多。接下来，我将运行复制器以将所有内容恢复原位，然后重新运行分散报告

... start object replicators and monitor logs until they're caught up ...
$ swift-dispersion-report
Queried 2621 containers for dispersion reporting, 17s, 0 retries
100.00% of container copies found (7863 of 7863)
Sample represents 1.00% of the container partition space

Queried 2619 objects for dispersion reporting, 7s, 0 retries
100.00% of object copies found (7857 of 7857)
Sample represents 1.00% of the object partition space

您还可以仅对容器或对象运行报告

$ swift-dispersion-report --container-only
Queried 2621 containers for dispersion reporting, 17s, 0 retries
100.00% of container copies found (7863 of 7863)
Sample represents 1.00% of the container partition space

$ swift-dispersion-report --object-only
Queried 2619 objects for dispersion reporting, 7s, 0 retries
100.00% of object copies found (7857 of 7857)
Sample represents 1.00% of the object partition space

另外，分散报告也可以输出为 JSON 格式。这使得它更容易被第三方工具使用

$ swift-dispersion-report -j
{"object": {"retries:": 0, "missing_two": 0, "copies_found": 7863, "missing_one": 0, "copies_expected": 7863, "pct_found": 100.0, "overlapping": 0, "missing_all": 0}, "container": {"retries:": 0, "missing_two": 0, "copies_found": 12534, "missing_one": 0, "copies_expected": 12534, "pct_found": 100.0, "overlapping": 15, "missing_all": 0}}

请注意，您可以通过设置选项“–policy-name silver”或“-P silver”来选择要使用的存储策略（silver 是此处的示例策略名称）。如果未指定策略，则将按照 swift.conf 文件使用默认策略。当您指定策略时，创建的容器也包括策略索引，因此即使运行仅容器报告，您也需要指定策略而不使用默认值。

地理分布式 Swift 考量

Swift 提供两个功能，可用于将对象副本分发到多个地理分布式数据中心：通过全局集群，对象副本可以通过在环设备描述符中使用区域在不同数据中心的设备之间分散；通过容器到容器同步，对象可以在每个数据中心独立的 Swift 集群之间复制。每个功能的运行和配置在其各自的文档中都有描述。在选择最适合特定用例的功能时，应考虑以下几点

1. 全局集群允许集群操作员根据每个策略控制对象副本在数据中心之间的分布，因为分布由每个数据中心设备在每个策略的环文件中的分配决定。通过容器同步，最终用户可以根据每个容器控制对象在集群之间的分布。

2. 全局集群要求操作员协调跨多个数据中心的环部署。容器同步允许在每个数据中心独立管理单独的 Swift 集群，并允许现有 Swift 集群在容器同步关系中用作对等体，而无需部署新的策略/环。

3. 全局集群无缝支持可能依赖跨容器操作的功能，例如大型对象和版本化写入。容器同步要求最终用户确保所有必需的容器都已同步，以便这些功能在所有数据中心都能正常工作。

4. 全局集群使对象在两个数据中心都可用于 GET 或 HEAD 请求，即使对象副本尚未在数据中心之间异步迁移，通过在数据中心之间转发请求。容器同步无法在特定数据中心为对象提供请求，直到异步同步过程将对象复制到该数据中心。

5. 全局集群可能比容器同步需要更少的存储容量来实现每个数据中心等效的对象持久性。全局集群可以使用来自其他数据中心的副本恢复在一个数据中心丢失或损坏的副本。容器同步要求每个数据中心独立管理对象的持久性，这可能导致每个数据中心存储的副本比全局集群更多。

6. 全局集群会同步执行所有帐户/容器元数据更新到所有数据中心中的帐户/容器副本，这在通过广域网进行更新时可能会导致延迟。容器同步仅在数据中心之间复制对象，所有 Swift 内部流量都限制在每个数据中心内。

7. 当一个数据中心离线时，全局集群尚未保证纠删码策略中存储的对象的可用性。使用容器同步，一旦对象同步，每个数据中心中对象的可用性独立于其他数据中心的状态。容器同步还允许使用不同策略类型在不同数据中心存储对象。

检查切换分区分布

您可以通过比较预期分区数量与磁盘上的实际数量来检查切换分区是否堆积在服务器上。首先使用swift-ring-builder的dispersion命令获取当前分配给服务器的分区数量

swift-ring-builder sample.builder dispersion --verbose
Dispersion is 0.000000, Balance is 0.000000, Overload is 0.00%
Required overload is 0.000000%
--------------------------------------------------------------------------
Tier                           Parts      %    Max     0     1     2     3
--------------------------------------------------------------------------
r1                              8192   0.00      2     0     0  8192     0
r1z1                            4096   0.00      1  4096  4096     0     0
r1z1-172.16.10.1                4096   0.00      1  4096  4096     0     0
r1z1-172.16.10.1/sda1           4096   0.00      1  4096  4096     0     0
r1z2                            4096   0.00      1  4096  4096     0     0
r1z2-172.16.10.2                4096   0.00      1  4096  4096     0     0
r1z2-172.16.10.2/sda1           4096   0.00      1  4096  4096     0     0
r1z3                            4096   0.00      1  4096  4096     0     0
r1z3-172.16.10.3                4096   0.00      1  4096  4096     0     0
r1z3-172.16.10.3/sda1           4096   0.00      1  4096  4096     0     0
r1z4                            4096   0.00      1  4096  4096     0     0
r1z4-172.16.20.4                4096   0.00      1  4096  4096     0     0
r1z4-172.16.20.4/sda1           4096   0.00      1  4096  4096     0     0
r2                              8192   0.00      2     0  8192     0     0
r2z1                            4096   0.00      1  4096  4096     0     0
r2z1-172.16.20.1                4096   0.00      1  4096  4096     0     0
r2z1-172.16.20.1/sda1           4096   0.00      1  4096  4096     0     0
r2z2                            4096   0.00      1  4096  4096     0     0
r2z2-172.16.20.2                4096   0.00      1  4096  4096     0     0
r2z2-172.16.20.2/sda1           4096   0.00      1  4096  4096     0     0

从输出中可以看出，每个服务器应存储 4096 个分区，每个区域应存储 8192 个分区。此示例使用了 13 的分区幂和 3 个副本。

启用 write_affinity 后，磁盘上的分区数量预计会高于 swift-ring-builder dispersion 命令报告的值。区域 r1 中额外（切换）分区的数量取决于您的集群大小、传入数据量以及复制速度。

让我们以上述示例为例，在两个区域中有 6 个节点，并且 write_affinity 配置为首先写入区域 r1。swift-ring-builder报告每个节点应存储 4096 个分区

Expected partitions for region r2:                                      8192
Handoffs stored across 4 nodes in region r1:                 8192 / 4 = 2048
Maximum number of partitions on each server in region r1: 2048 + 4096 = 6144

最坏的情况是区域 1 中的切换分区以比复制能够将它们移动到区域 2 更快的速度填充新的对象副本。在这种情况下，您将在区域 r1 中的每个服务器上看到约 6144 个分区。您的实际数量应该更低，介于 4096 和 6144 个分区之间（最好是较低端）。

现在，计算区域 1 中给定服务器上的对象分区数量，例如在 172.16.10.1 上。请注意，路径名可能不同；/srv/node/是默认挂载位置，objects仅适用于存储策略 0（存储策略 1 将使用objects-1，依此类推）

find -L /srv/node/ -maxdepth 3 -type d -wholename "*objects/*" | wc -l

如果此数字总是处于预期分区号范围（4096 到 6144）的上限或正在增加，您应该检查您的复制速度，甚至可能禁用 write_affinity。请参阅下一节如何从 Swift 收集指标，特别是swift-recon -r如何检查复制统计信息。

集群遥测和监控

可以使用 recon 服务器中间件和 swift-recon cli 从帐户、容器和对象服务器获取各种指标和遥测数据。为此，请更新您的帐户、容器或对象服务器管道以包含 recon 并添加相关的过滤器配置。

object-server.conf 示例

[pipeline:main]
pipeline = recon object-server

[filter:recon]
use = egg:swift#recon
recon_cache_path = /var/cache/swift

container-server.conf 示例

[pipeline:main]
pipeline = recon container-server

[filter:recon]
use = egg:swift#recon
recon_cache_path = /var/cache/swift

account-server.conf 示例

[pipeline:main]
pipeline = recon account-server

[filter:recon]
use = egg:swift#recon
recon_cache_path = /var/cache/swift

recon_cache_path 简单地设置存储少数项目统计信息的目录。根据部署方法，您可能需要手动创建此目录并确保 Swift 具有读/写访问权限。

最后，如果您还希望跟踪对象服务器上的异步待处理任务，您需要设置一个 cronjob 定期在对象服务器上运行 swift-recon-cron 脚本

*/5 * * * * swift /usr/bin/swift-recon-cron /etc/swift/object-server.conf

一旦启用 recon 中间件，向后端对象服务器发出“/recon/<metric>”的 GET 请求将返回 JSON 格式的响应

fhines@ubuntu:~$ curl -i https://:6230/recon/async
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 20
Date: Tue, 18 Oct 2011 21:03:01 GMT

{"async_pending": 0}

请注意，对象服务器的默认端口是 6200，但在 Swift All-In-One 安装中，它使用 6210、6220、6230 和 6240。

目前公开以下指标和遥测数据

请求 URI	描述
/recon/load	返回 1、5 和 15 分钟负载平均值
/recon/mem	返回 /proc/meminfo
/recon/mounted	返回*所有*当前已挂载的文件系统
/recon/unmounted	如果 mount_check = True，则返回所有未挂载的驱动器
/recon/diskusage	返回存储设备的磁盘利用率
/recon/driveaudit	返回驱动器审计错误的数量
/recon/ringmd5	返回对象/容器/帐户环的 MD5 校验和
/recon/swiftconfmd5	返回 swift.conf MD5 校验和
/recon/quarantined	返回隔离对象/帐户/容器的数量
/recon/sockstat	返回 /proc/net/sockstat|6 中可消耗的信息
/recon/devices	返回设备列表和设备目录，例如 /srv/node
/recon/async	返回异步待处理计数
/recon/replication	返回对象复制信息（用于向后兼容）
/recon/replication/<type>	返回给定类型（帐户、容器、对象）的复制信息
/recon/auditor/<type>	返回给定类型（帐户、容器、对象）上次报告扫描的审计器统计信息
/recon/updater/<type>	返回给定类型（容器、对象）上次更新器扫描时间
/recon/expirer/object	返回上次对象过期器扫描期间经过的时间和删除的对象数量
/recon/version	返回 Swift 版本
/recon/time	返回节点时间

请注意，对象复制信息中的“object_replication_last”和“object_replication_time”被认为是过渡性的，并将在后续版本中删除。请改用“replication_last”和“replication_time”。

此信息也可以通过 swift-recon 命令行实用程序查询

fhines@ubuntu:~$ swift-recon -h
Usage:
        usage: swift-recon <server_type> [-v] [--suppress] [-a] [-r] [-u] [-d]
        [-R] [-l] [-T] [--md5] [--auditor] [--updater] [--expirer] [--sockstat]

        <server_type>   account|container|object
        Defaults to object server.

        ex: swift-recon container -l --auditor


Options:
  -h, --help            show this help message and exit
  -v, --verbose         Print verbose info
  --suppress            Suppress most connection related errors
  -a, --async           Get async stats
  -r, --replication     Get replication stats
  -R, --reconstruction  Get reconstruction stats
  --auditor             Get auditor stats
  --updater             Get updater stats
  --expirer             Get expirer stats
  -u, --unmounted       Check cluster for unmounted devices
  -d, --diskusage       Get disk usage stats
  -l, --loadstats       Get cluster load average stats
  -q, --quarantined     Get cluster quarantine stats
  --md5                 Get md5sum of servers ring and compare to local copy
  --sockstat            Get cluster socket usage stats
  -T, --time            Check time synchronization
  --all                 Perform all checks. Equal to
                        -arudlqT --md5 --sockstat --auditor --updater
                        --expirer --driveaudit --validate-servers
  -z ZONE, --zone=ZONE  Only query servers in specified zone
  -t SECONDS, --timeout=SECONDS
                        Time to wait for a response from a server
  --swiftdir=SWIFTDIR   Default = /etc/swift

例如，要从区域“3”中的所有主机获取容器复制信息

fhines@ubuntu:~$ swift-recon container -r --zone 3
===============================================================================
--> Starting reconnaissance on 1 hosts
===============================================================================
[2012-04-02 02:45:48] Checking on replication
[failure] low: 0.000, high: 0.000, avg: 0.000, reported: 1
[success] low: 486.000, high: 486.000, avg: 486.000, reported: 1
[replication_time] low: 20.853, high: 20.853, avg: 20.853, reported: 1
[attempted] low: 243.000, high: 243.000, avg: 243.000, reported: 1

向 StatsD 报告指标

注意

本节中描述的传统 StatsD 指标正在通过带标签的指标进行补充。

如果您正在运行 StatsD 服务器，Swift 可以配置为向其发送实时操作指标。要启用此功能，请设置以下配置条目（请参阅示例配置文件）

log_statsd_host = localhost
log_statsd_port = 8125
log_statsd_default_sample_rate = 1.0
log_statsd_sample_rate_factor = 1.0
log_statsd_metric_prefix =                [empty-string]

如果未设置log_statsd_host，则此功能被禁用。其他设置的默认值如上所示。log_statsd_host可以是主机名、IPv4 地址或 IPv6 地址（不带括号，因为端口是单独指定的，因此不需要）。如果主机名解析为 IPv4 地址，即使主机名也可以解析为 IPv6 地址，也将使用 IPv4 套接字发送 StatsD UDP 数据包。

采样率是介于 0 和 1 之间的实数，它定义了发送任何给定事件或计时测量的样本的概率。此采样率随每个样本发送到 StatsD，并用于乘以该值。例如，如果采样率为 0.5，StatsD 在将指标刷新到上游监控系统（Graphite、Ganglia 等）时，会将该计数器的值乘以 2。

一些相对高频率的指标的默认采样率小于 1。如果您想覆盖所有默认采样率未在 Swift 源代码中指定的指标的默认采样率，您可以将log_statsd_default_sample_rate设置为小于 1 的值。不建议这样做（请参阅下一段）。更好的方法是调整log_statsd_sample_rate_factor为一个小于 1 的值。 log_statsd_sample_rate_factor在处理之前会乘以任何采样率（无论是全局默认值还是 Swift 源代码中实际指标日志调用指定的采样率）。换句话说，这一个可调参数可以按比例降低所有 StatsD 日志记录的频率。

为了获得最佳数据，请从默认的log_statsd_default_sample_rate和log_statsd_sample_rate_factor值 1 开始，并且仅在需要时才降低log_statsd_sample_rate_factor。log_statsd_default_sample_rate不应使用，仅为向后兼容性保留。

指标前缀将添加到发送到 StatsD 服务器的每个指标前面。例如，如果

log_statsd_metric_prefix = proxy01

指标proxy-server.errors将作为proxy01.proxy-server.errors发送到 StatsD。当将统计信息发送到中央 StatsD 服务器时，这对于区分不同的服务器很有用。如果您每个节点运行一个本地 StatsD 服务器，您可以在那里配置每个节点的指标前缀，并将log_statsd_metric_prefix留空。

请注意，报告给 StatsD 的指标是计数器或计时数据（以毫秒为单位发送）。StatsD 通常会将计时数据扩展为每个计时指标的最小值、最大值、平均值、计数和第 90 百分位数，但此行为的详细信息将取决于您的 StatsD 服务器的配置。一些重要的“仪表”指标可能仍需要使用其他方法收集。例如，object-server.async_pendingsStatsD 指标实时计数 async_pendings 的生成，但不会告诉您任何时间点磁盘上 async_pending 容器更新的当前数量。

另请注意，收集的指标集、它们的名称和它们的语义并未锁定，并且会随时间变化。有关更多详细信息，请参阅下面列出的特定服务表

• account-auditor 指标
• account-reaper 指标
• account-server 指标
• account-replicator 指标
• container-auditor 指标
• container-replicator 指标
• container-server 指标
• container-sync 指标
• container-updater 指标
• object-auditor 指标
• object-expirer 指标
• object-reconstructor 指标
• object-replicator 指标
• object-server 指标
• object-updater 指标
• proxy-server 指标
  • proxy-logging 中间件
  • tempauth 中间件
  • tempurl 中间件
  • formpost 中间件

或者，以一页的形式查看所有 Statsd 指标。

调试技巧和工具

当向 Swift 发出请求时，它会获得一个唯一的事务 ID。此 ID 应该出现在与该请求相关的每个日志行中。这在查看单个请求所涉及的所有服务时非常有用。

如果您需要知道集群中特定帐户、容器或对象的位置，swift-get-nodes将显示每个副本应所在的位置。

如果您正在查看服务器上的对象并需要更多信息，swift-object-info将显示对象的帐户、容器、副本位置和元数据。

如果您正在查看服务器上的容器并需要更多信息，swift-container-info将显示所有信息，例如容器的帐户、容器、副本位置和元数据。

如果您正在查看服务器上的帐户并需要更多信息，swift-account-info将显示帐户、副本位置和帐户的元数据。

如果您想审计帐户数据，可以使用swift-account-audit来遍历帐户，检查是否可以找到所有容器和对象。

管理服务

Swift 服务通常使用swift-init进行管理。一般用法是swift-init <service> <command>，其中 service 是要管理的 Swift 服务（例如 object、container、account、proxy），command 是以下之一

命令	描述
start	启动服务
停止	停止服务
重启	重启服务
shutdown	尝试正常关闭服务
重新加载	尝试正常重启服务
无缝重新加载	尝试无缝重启服务

正常关闭或重新加载将允许所有服务器 worker 在退出前完成所有当前请求。父服务器进程立即退出。

无缝重新加载将使新的配置设置生效，并且不会出现客户端请求因没有活动的监听套接字而失败的窗口。父服务器进程将重新执行自身，保留其现有的 PID。在重新执行的父服务器进程绑定其监听套接字后，旧的监听套接字将关闭，旧的服务器 worker 在退出前完成任何当前请求。

还有一种特殊情况是swift-init all <command>，它将对所有 swift 服务运行该命令。

在服务存在多个配置的情况下，可以使用swift-init <service>.<config> <command>来管理特定配置。例如，当使用单独的复制网络时，对象服务器可能有/etc/swift/object-server/public.conf，复制服务可能有/etc/swift/object-server/replication.conf。在这种情况下，可以使用swift-init object-server.replication restart来重新启动复制服务。

对象审计器

在系统故障时，XFS 文件系统有时会截断它正在尝试写入的文件并生成零字节文件。对象审计器会捕获这些问题，但在系统崩溃的情况下，建议运行额外的、限制较少的扫描来检查这些特定文件。您可以按如下方式运行此命令

swift-object-auditor /path/to/object-server/config/file.conf once -z 1000

-z表示仅以每秒 1000 个文件的速度检查零字节文件。

有时，能够在特定设备或设备集上运行对象审计器会很有用。您可以按如下方式运行对象审计器

swift-object-auditor /path/to/object-server/config/file.conf once --devices=sda,sdb

这将仅在 sda 和 sdb 设备上运行对象审计器。此参数接受逗号分隔的值列表。

对象复制器

有时，能够在特定设备或分区上运行对象复制器会很有用。您可以按如下方式运行对象复制器

swift-object-replicator /path/to/object-server/config/file.conf once --devices=sda,sdb

这将在 sda 和 sdb 设备上运行对象复制器。您也可以使用--partitions运行该命令。两个参数都接受逗号分隔的值列表。如果两者都指定，它们将进行“与”操作。这些只能在“一次”模式下运行。

Swift 孤儿进程

Swift 孤儿进程是 Swift 服务器重新加载后留下的进程。

例如，升级代理服务器后，您可能会使用swift-init proxy-server reload或/etc/init.d/swift-proxy reload完成。这会终止父代理服务器进程，并让子进程继续运行以完成它们当时可能正在处理的任何请求。然后它会启动一个新的父代理服务器进程及其子进程来处理新的传入请求。这允许零停机升级，对现有请求没有任何影响。

孤立的子进程可能需要一段时间才能退出，具体取决于它们正在处理的请求的长度。但是，有时由于某些错误或硬件问题，旧进程可能会挂起。在这些情况下，这些孤立进程将永远挂在那里。swift-orphans可用于查找并终止这些孤立进程。

swift-orphans在没有参数的情况下只会列出它找到的在 24 小时前启动的孤儿进程。在重新加载 24 小时后，您不应该真正检查孤儿进程，因为有些请求可能需要很长时间才能处理。swift-orphans -k TERM会向孤儿进程发送 SIG_TERM 信号，或者如果您愿意，可以自己kill -TERM这些进程的 PID。

您可以运行swift-orphans --help以获取更多选项。

Swift 老旧进程

Swift 老旧进程是指运行时间较长的进程。这本身不一定有问题，但如果您定期升级和重新加载/重启服务，这可能表明存在挂起进程。您可能有太多的服务器，以至于您没有注意到重新加载/重启失败；swift-oldies可以帮助解决这个问题。

例如，如果您在两天前升级并重新加载/重启了所有服务，并且您已经使用swift-orphans清理了所有孤儿进程，您可以运行swift-oldies -a 48来查找任何在两天前启动的 Swift 进程，然后进行相应的调查。

自定义日志处理程序

Swift 支持通过指定在日志记录设置时调用的逗号分隔函数列表来为服务设置自定义日志处理程序。它通过log_custom_handlers配置选项来实现。调用的记录器钩子会传递与 Swift 的get_logger函数相同的参数，以及logging.Logger和SwiftLogAdapter对象

名称	描述
配置	从中读取设置的配置字典
name	收到的记录器名称
log_to_console	（可选）将日志消息写入标准错误控制台
log_route	收到的日志记录路由
fmt	覆盖收到的日志格式
logger	logging.getLogger 对象
adapted_logger	LogAdapter 对象

注意

包装logging.Logger对象的SwiftLogAdapter实例可以在运行时被克隆实例替换，例如使用不同的日志前缀和相同的logging.Logger。因此，自定义日志处理程序不应修改SwiftLogAdapter实例的任何属性，除了那些在克隆时会被复制的属性。

设置自定义记录器的基本示例可能如下所示

def my_logger(conf, name, log_to_console, log_route, fmt, logger,
              adapted_logger):
    my_conf_opt = conf.get('some_custom_setting')
    my_handler = third_party_logstore_handler(my_conf_opt)
    logger.addHandler(my_handler)

有关示例用例，请参阅自定义记录器钩子。

保护 OpenStack Swift

请参阅安全指南：https://docs.openstack.org/security-guide，特别是对象存储部分。