本系列文章着重学习和研究OpenStack Swift，包括环境搭建、原理、架构、监控和性能等。
（1）OpenStack + 三节点Swift 集群+ HAProxy + UCARP 安装和配置
（2）原理、架构和性能
（3）监控
对 Swift 集群的监控是必要的，特别是集群规模很大的时候。
1. 监控目标
主要的监控目标包括：
- 硬件故障
- 操作系统故障
- Swift 集群健康状态
- Swift 集群状态
2. Swift 提供的工具
2.1 Swift 自带的各种 Audit 工具
2.1.1 磁盘监控工具 swift-drive-audit
该工具分析 /var/log/kern.log 文件，根据预定义的 regexp 来探测 kernel 报告的磁盘错误。通常地它会被 cron 周期性地运行。它使用一个配置文件，比如 /etc/swift/drive-audit.conf。如果该脚本发现了某个磁盘存在问题，它会自动 unmount 它，而且会在 /etc/fstab 中将它注释掉。然后后端 replication 进程就会从其它 replica 中拷贝出一个新的 replica。 这是示例配置文件。
要使用它，必须首先创建一个配置文件 driver-audit.conf：
[drive-audit]
device_dir = /srv/node
log_facility = LOG_LOCAL0
log_level = INFO
minutes =
error_limit =
log_file_pattern = /var/log/kern*
regex_pattern_1 = \berror\b.*\b(dm-[-]{,}\d?)\b
然后运行该工具：swift-drive-audit driver-audit.conf，然后上面描述的各种 action 就会有了。
2.1.2 account，container 和 object auditor
功能：
- swift-account-auditor 会打开 account server 的 sqlite db，运行 SQL 查询，确保 db 是有效的，并报告一个account 是否有 replica 缺失或者错误的对象。
- swift-container-auditor 会对 containers 做同样的事情.
- swift-object-auditor 会打开一个对象服务器上的所有对象，确保它们的元数据是正确的，而且有有合适的大小和 MD5
它们都必须在各自对应的服务的配置文件中的 [account/object/container-auditor] 部分做相应配置，然后它们就会定期运行，并输出日志。
2.2 集群监控状态获取工具 swift-dispersion-populate 和 swift-dispersion-report
这两个工具用于获取和报告集群的总体健康状态。它需要访问Swift 集群以及 Ring 文件。它需要一个自己的配置文件，往往把该配置文件放在 proxy server 上的 /etc/swift 目录下。
（1）创建配置文件 /etc/swift/dispersion.conf ：
[dispersion]
auth_url = http://controller:35357/v3
auth_user = service:swift
auth_version = 3
auth_key = 1111
swift_dir = /etc/swift
concurrency = 25
retries = 5
该配置文件的详细说明可以参见 Ubuntu 文档。注意 Kilo 版本的 Swift 环境中需要添加配置项 auth_version。
（2）运行 swift-dispersion-populate 去获取系统的健康状况，它和 swift-dispersion-report 使用同一个配置文件。详细说明可以参见 Ubuntu 文档。
root@swift1:/etc/swift# swift-dispersion-populate dispersion.conf
Created containers for dispersion reporting, 0s, retries
Created objects for dispersion reporting, 0s, retries
（3）运行 swift-dispersion-report 获取监控报告。详细说明请参加 Ubuntu 文档。
root@swift1:/etc/swift# swift-dispersion-report
Queried 11 containers for dispersion reporting, 0s, 0 retries
100.00% of container copies found (33 of 33)
Sample represents 1.07% of the container partition space
Queried 10 objects for dispersion reporting, 0s, 0 retries
There were 10 partitions missing 0 copy.
100.00% of object copies found (30 of 30)
Sample represents 0.98% of the object partition space
2.3 性能获取工具 swift-recon 中间件
2.3.1 它是什么（what）
Swift Recon是一个安装在对象服务器的pipeline上的中间件，它有一个必填选项：一个本地缓存目录。它可以获取：
- How many unmounted (failed) drives there are in the cluster, and on which servers those are located
- How many async pendings are present
- Drive usage and balance
- Load Average (for easy access later on*)
- Memory Usage (for easy access later on*)
- Checking ring md5sum’s
- Logged replication stats
- Connection stats (tbd)
- Quarantine Statistics (a new pending addition)
要使用它，需要首先修改 object-server 的配置文件，添加该中间件：
[pipeline:main]
pipeline = healthcheck recon object-server [filter:recon]
use = egg:swift#recon
recon_cache_path = /var/cache/swift
recon_lock_path = /var/lock
2.3.2 使用命令行工具（How）
swift-recon <server_type> [-v] [--suppress] [-a] [-r] [-u] [-d] [-l] [--md5] [--auditor] [--updater] [--expirer] [--sockstat]
参数：
- -a, --async: Get async stats
- --auditor: Get auditor stats
- --updater: Get updater stats
- --expirer: Get expirer stats
- -r, --replication: Get replication 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 cop
- --all Perform all checks. Equivalent to -arudlq --md5
- -z ZONE, --zone=ZONE: Only query servers in specified zone
- --swiftdir=PATH Default = /etc/swift
（1）获取全部zone 上 updater，auditor 和 expier 的状态
root@swift1:/etc/swift# swift-recon --auditor --updater --expirer
===============================================================================
--> Starting reconnaissance on hosts
===============================================================================
[-- ::] Checking auditor stats
[ALL_audit_time_last_path] low: , high: , avg: 0.0, total: , Failed: 0.0%, no_result: , reported:
[ALL_quarantined_last_path] low: , high: , avg: 0.0, total: , Failed: 0.0%, no_result: , reported:
[ALL_errors_last_path] low: , high: , avg: 0.0, total: , Failed: 0.0%, no_result: , reported:
[ALL_passes_last_path] low: , high: , avg: 1.0, total: , Failed: 0.0%, no_result: , reported:
[ALL_bytes_processed_last_path] low: , high: , avg: 5.0, total: , Failed: 0.0%, no_result: , reported:
[ZBF_audit_time_last_path] low: , high: , avg: 0.0, total: , Failed: 0.0%, no_result: , reported:
[ZBF_quarantined_last_path] low: , high: , avg: 0.0, total: , Failed: 0.0%, no_result: , reported:
[ZBF_errors_last_path] low: , high: , avg: 0.0, total: , Failed: 0.0%, no_result: , reported:
[ZBF_bytes_processed_last_path] low: , high: , avg: 0.0, total: , Failed: 0.0%, no_result: , reported:
===============================================================================
[-- ::] Checking updater times
[updater_last_sweep] low: , high: , avg: 0.1, total: , Failed: 0.0%, no_result: , reported:
===============================================================================
[-- ::] Checking on expirers
[object_expiration_pass] - No hosts returned valid data.
[expired_last_pass] - No hosts returned valid data.
===============================================================================
（2）磁盘使用情况
root@swift1:/etc/swift# swift-recon -d
===============================================================================
--> Starting reconnaissance on hosts
===============================================================================
[-- ::] Checking disk usage now
Distribution Graph:
% **********************************************
% *********************************************************************
% ***********************
Disk usage: space used: of
Disk usage: space free: of
Disk usage: lowest: 2.59%, highest: 4.56%, avg: 3.31952247191%
（3）系统负载
root@swift1:/etc/swift# swift-recon -l
===============================================================================
--> Starting reconnaissance on hosts
===============================================================================
[-- ::] Checking load averages
[5m_load_avg] low: , high: , avg: 0.1, total: , Failed: 0.0%, no_result: , reported:
[15m_load_avg] low: , high: , avg: 0.1, total: , Failed: 0.0%, no_result: , reported:
[1m_load_avg] low: , high: , avg: 0.1, total: , Failed: 0.0%, no_result: , reported:
（4）检查所有节点上的 ring 文件和 swift.conf 是不是完全一致
root@swift1:/etc/swift# swift-recon --md5
===============================================================================
--> Starting reconnaissance on hosts
===============================================================================
[-- ::] Checking ring md5sums
/ hosts matched, error[s] while checking hosts.
===============================================================================
[-- ::] Checking swift.conf md5sum
/ hosts matched, error[s] while checking hosts
2.3.2 通过 REST API 使用
URL 及功能列表：
3. 其它监控工具
Swift 自身带的监控工具能提供比较丰富的功能，但是使用起来还不是很方便，因此，业界已经出现了很多商业的或者开源的监控工具。这些监控工具，要么向 swift-recon 一样实现了一个新的中间件，要么调用 Swift 自身的工具提供的接口。 以下（1 - 4 部分）文字引用自 OpenStack Object Storage Monitoring 一文：
（1）Swift-Informant
Florian Hines 开发的 Swift-Informant 中间件可以获得 OS 客户请求的实时结果。它位于proxy server的 pipeline，在每一个请求到达Proxy server之后，它发送3类统计数据到StatsD server.
- 一个类似obj.GET.200 or cont.PUT.404的增量计数器。
- 请求处理的时间长度
- 传输数据数量
这有利于了解客户正体验的服务品质，也可以了解各种服务类型，命令以及响应码的不同排列的数量。Swift-Informant也要求no change to core Swift code因为它是用中间件实现的。然而，也因为如此，它不能让人看到代理服务器后面的工作情景。如果一个存储节点的响应降低，你也可能看到你的请求变差－要么是高延迟，要么返回错误状态码。你不会知道具体是为什么，或者请求是要去哪里。或许你所考虚的container服务器是在一个好的节点的，而对象服务器是在另一个性能差的节点。
因此我们需要深入视觉到proxy server的后面，集群的操作里去。
（2）Statsdlog
Florian 的 statsdlog 工程增加了 StatsD 基于日志事件的计数器。正如Swift-Informant，它也是非侵入式的。但是statsdlog可以从Swift后台进程中追踪事件，而不仅仅是代理服务器。后台进程监听syslog信息的UDP流，当一条日志匹配于一个正则表达式时，StatsD计数器递增。Metric名字映射到JSON文件中的正则pattern。JSON文件允许灵活配置以能从日志流中抽取出想要的metrics。
（3）Swift StatsD Logging
StatsD 使用程序代码来作深入分析。Metrics被有针对性的代码实时发送。发送一个metric的开销相当低：一个sendto UDP包。如果你认为这样的开销还算高的话，StatsD client library可以只发送样本的随机比率部分，flushing metrics upstream时StatsD将估算实际数据。要避免基于中间件的监控与事后日志处理所带来的弊端，我们把StatsD metrics发送过种整合到Swift本身。我们当前所提交的更改报告了遍布15个swift后台进程的124个metrics以及tempauth中间件。metrics细节可参考https://review.openstack.org/#patch,sidebyside,6058,2,doc/source/admin_guide.rst
（4）总结
我们认为 Swift 集群动作最好的监控方法是综合了一个通用服务器监控系统，一个Swift特定统计指标收集（polling Swift-specific gauge metrics）机制，一个Swift内部counter与timing metrics深度StatsD日志手段的结合体。对于polling Swift-specific gauge metrics，最好使用一个通用的收集插件。这个插件即可以从swift-recon读数据，也可以自己直接收集信息。在 SwiftStack，我们使用 collectd 加上一些服务器监控用 python 插件代码。我们也在collectd中嵌入StatsD服务器，这样每个节点都有一个进程将stats数据“倒”给Graphite"(http://graphite.wikidot.com/)集群。有了这个装置，我们拥有前述所有问题的全覆盖解决方案：general purpose monitoring, Swift-specific gauge monitoring, and real-time counter and timing data directly from Swift。除了图形化，你也可以实现异常检测，触发警告，维护一个实时的实体健康状态视图，避免各种突发问题。
（5）SwiftStack 监控工具的部分截图：
（6）另外一个监控环境示例
（7）Benchmarking 工具
Intel 开源了对象存储的 Benchmarking 工具 COSBench，https://github.com/intel-cloud/cosbench
4. 一些影响性能的因素
注：以下内容引用自 "Leveraging open source tools to gain insight into OpenStack Swift“ ，by Michael Factor,Dmitry Sotnikov, dmitrys@il.ibm.com。他们使用的测试环境：
4.1 Container 数量和 Swift 版本
（PUT 操作）
版本和 container 数目带来的性能差异还是非常大的。建议使用 Swift 2.2 版本以上，以及多个 container。
4.2 客户端 worker 数目
可见客户端 worker 数目不是越多性能就会线性增加。
4.3 Container 中的对象数目
4.4 前端和后端网络带宽
说明后端网络的带宽压力是前端的至少3倍。
4.5 存储节点的磁盘I/O 和前端网络 I/O 的关系（12倍）
4.6 对象大小
这说明 Swift 不合适处理大量的小文件。
4.7 IOPS 性能不是随着存储节点数目线性扩展的
也就是说这个环境中，存储节点数目为7的话，它们就不是 IOPS 性能瓶颈了。
参考文档：