本系列文章着重学习和研究OpenStack Swift，包括环境搭建、原理、架构、监控和性能等。
（1）OpenStack + 三节点Swift 集群+ HAProxy + UCARP 安装和配置
（2）原理、架构和性能
（3）监控
要实现的系统的效果图：
特点：
- 使用三个对等物理节点，每个节点上部署所有Swift 服务
- 使用开源的 UCARP 控制一个 VIP，它会被绑定到三个物理网卡中的一个。
- 使用开源的 HAProxy 做负载均衡
- 开启 Swift TempURL
1. Swift 集群安装和配置
1.1 Swift 安装
Swift 是被设计来在商用硬件上运行的。而且在存储磁盘上不需要而且不推荐使用RAID，相反，使用 RAID 5 或者 6 的和，会带来严重的性能下降。Swift 中包含多种服务，主要的有四种：
- Proxy Services
- Object Services
- Container Services
- Account Services
这些服务都可以独立运行。这些服务中，Proxy service 是更需要 CPU 和 网络带宽的，因此，可以使用 10GbE 或者更高的带宽。如果将 SSL 段设在proxy service 上的话，它也会消耗 CPU。其它三种服务是磁盘和网络带宽敏感的。由于每个服务的独立性，因此，有多种部署方式。比如将所有服务部署在一个节点上，这样所有服务都可以水平扩展。也可以将 proxy service 单独出来，它可以使用 10GbE 或者更高的网络，而 storage 节点可以使用更加经济的 1GbE 网络。如果你需要更高的 Account 或者 Container service 吞吐能力，他们都可以被部署在单独的服务器上，比如使用更快的 SAS 或者 SSD 磁盘来放置它们的数据库文件。另外，还需要考虑负载均衡问题。
本案例使用 OpenStack Swift Kilo 版本，按照社区官方文档安装和配置 Swift，没什么花头。基本流程：
- 系统盘准备（操作系统磁盘往往使用 RAID 1提高可靠性）
- 操作系统安装
- Swift 软件安安装
- 数据盘准备（不需要 RAID）
- Swift 配置
本案例使用的环境的特点：
- 物理节点运行 Ubuntu 操作系统
- 三个物理节点，每个节点上部署所有Swift 服务，因此三节点是对等的。
- 只使用一个网络。其实是可以将Swift 集群的数据复制（replication）需要的网络单独出来。
- 每个节点添加两块磁盘，使用 XFS 文件系统，作为 Swift 的数据盘。
- Swift 使用 Keystone 来进行用户验证。
1.2 Swift 配置
1.2.1 Ring 配置
Swift 配置中，需要注意的是 Ring 的配置，它包含几个关键值：
- Partition 数目：推荐集群磁盘数目（将来的或者说规划的）乘以100，然后取模2。同时，这个数字也不能过大，因为过大的话，Swift replicator 和其它后端进程就会消耗更多的内存。因此，需要在 small ring 和 最大的集群规模之间做平衡。
- Replica 数目：推荐 3.越大，消耗的存储空间会越大，当然，丢失数据的可能性就越小。
- Zone 数目：社区推荐至少5个zone。
然后使用 swift-ring-builder <builder_file> create <part_power> <replicas> <min_part_hours> 命令分布创建 Account，Container 和 Object ring。比如本案例使用的命令是 swift-ring-builder object.builder create 10 3 1。它表示：
- 集群规划的最大规模为 10 块磁盘
- 数目保存 3 份
然后使用 swift-ring-builder <builder_file> add z<zone>-<ip>:<port>/<device_name>_<meta> <weight> 命令将每个节点上的数据服务（比如 Object-server 服务）加入到 ring 中：
swift-ring-builder object.builder add r1z1-9.115.251.235:6000/sdb1 100
swift-ring-builder object.builder add r1z1-9.115.251.235:6000/sdc1 100
swift-ring-builder object.builder add r1z2-9.115.251.234:6000/sdb1 100
swift-ring-builder object.builder add r1z2-9.115.251.234:6000/sdc1 100
swift-ring-builder object.builder add r1z3-9.115.251.233:6000/sdb1 100
swift-ring-builder object.builder add r1z3-9.115.251.233:6000/sdc1 100
这里配置了 3 个 zone，就是每个节点单独一个 zone。另一个比较ticky 的参数是 weight，它表示一个磁盘上分区的数目，因此它和磁盘的大小有直接关系，社区推荐使用 100 * TB 作为该值。
接下来就需要运行 swift-ring-builder <builder_file> rebalance 命令了。它会使得Ring配置在所有磁盘的分区上生效，并会生产 object.ring.gz 文件。该文件和 container.ring.gz 以及 account.ring.gz 文件一道，需要发到集群所有的存储节点上。
最终 object ring 的配置如下：
root@swift1:/etc/swift# swift-ring-builder object.builder
object.builder, build version
partitions, 3.000000 replicas, regions, zones, devices, 0.00 balance, 0.00 dispersion
The minimum number of hours before a partition can be reassigned is
The overload factor is 0.00% (0.000000)
Devices: id region zone ip address port replication ip replication port name weight partitions balance meta
9.115.251.235 9.115.251.235 sdb1 100.00 0.00
9.115.251.235 9.115.251.235 sdc1 100.00 0.00
9.115.251.234 9.115.251.234 sdb1 100.00 0.00
9.115.251.234 9.115.251.234 sdc1 100.00 0.00
9.115.251.233 9.115.251.233 sdb1 100.00 0.00
9.115.251.233 9.115.251.233 sdc1 100.00 0.00
当 Ring 的配置需要改动的话，上面步骤需要重做。
1.2.2 磁盘性能
为了提高 Account service 和 Container service 的性能，可以将它们的挂载点放在SAS 或者 SSD 磁盘上，然后修改它们的配置文件中的 devices 选项：
1.2.3 Memcached
Swift 本身不对数据做任何缓存，它的 Proxy service 服务会利用 Memcached 来做数据缓存，比如用它来缓存 tokens、account 和 container 数据等。因此，memcached 往往会安装在 proxy service 所在的服务器上。
1.2.4 其它
（1） 文件系统
理论上Swift 支持所有支持扩展属性的文件系统，但是社区推荐使用 XFS。使用其他的文件系统之前，建议进行严格的测试。
（2）worker 数目
每个服务的 workers 数目可以进行配置。设置的值需要考虑可用的内核数目。
（3）日志
Swift 的日志会被输出到系统日志。官方建议使用 syslog-ng 来进行日志的分离，更多的资料可以参考 使用 syslog-ng 搭建安全的日志集中服务器 和 syslog-ng.conf 实例。
1.3 Swift 使用
要访问 Swift，必须安装 Swift 客户端。在 Ubuntu 环境中，运行 “sudo pip install python-swiftclient” 即可，然后再使用 admin-openrc.sh 中的如下配置：
export OS_PROJECT_DOMAIN_ID=default
export OS_USER_DOMAIN_ID=default
export OS_PROJECT_NAME=admin
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=***
export OS_AUTH_URL=http://controller:35357/v3
export OS_IMAGE_API_VERSION=
export OS_VOLUME_API_VERSION=
export OS_AUTH_VERSION=
进行常见的 swift 操作：
root@controller:~/s1# swift upload conatiner10 a
a
root@controller:~/s1# swift list conatiner10
a
root@controller:~/s1# swift download conatiner10 a
a [auth .408s, headers .458s, total .564s, 34.404 MB/s]
root@controller:~/s1# swift delete conatiner10 a
a
root@controller:~/s1# swift list conatiner10
root@controller:~/s1#
如果不使用配置文件，也可以在命令行中直接指定参数，比如 swift [-A *Auth URL*] [-U *username*] [-K *password*] stat。
2. HAProxy 安装和配置
在每个节点上安装 HAProxy，然后修改配置文件：
root@swift1:~/s1# vi /etc/haproxy/haproxy.cfg
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
user haproxy
group haproxy
daemon defaults
log global
mode http
option httplog
option dontlognull
contimeout
clitimeout
srvtimeout frontend localnodes
bind *:1002 #HAProxy 在 1002 端口上监听
mode http
default_backend swift-cluster
maxconn
option forwardfor backend swift-cluster
mode http
balance roundrobin #使用轮询策略
option httpchk HEAD /healthcheck HTTP/1.0
option forwardfor # 当 mode 为 ”http“时，设置 forwardfor，使得通过 X-Forward-For 头来保存原始的源 IP 地址
server proxy1 9.115.251.235: weight check inter 5s #节点1
server proxy2 9.115.251.233: weight check inter 5s #节点2
server proxy3 9.115.251.234: weight check inter 5s #节点3
然后运行命令/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg 来启动 HAProxy 进程。
3. UCARP 配置和安装
3.1 CARP 协议
3.1.1 CARP 协议
CARP 是由 FreeBSD 提出并率先实现的一种协议。UCARP 是 CARP 在 Linux 上的一个实现。
CARP （Common Address Redundancy Protocol，公共地址冗余协议）是一个用来实现系统冗余性的协议，通过将一组在同一个网段内的（on the same network）主机放到一个冗余组来共享一个IP地址。这么配置以后，在一个机器宕机的情况下，冗余组内的另外一个主机会接替它承担的任务。它同时也运行系统之间一定程度的负载共享。
一开始，OpenBSD 团队打算做 IETF 标准协议 VRRP （Virtual Router Redundancy Protocol，定义在 RFC3768）的一个免费实现；但是，Cisco 声称他们拥有专利，“坚定地通过 OpenBSD 社区，Ciso 肯定会保护他们的VRRP实现的专利”（参考 CARP 获得更多的信息），因此，这也使得 OpenBSD 团队去创造一个新的，与VRRP基础性不同的，竞争性的协议。
CRAP 是一个多播协议，将多个物理主机组成一个使用一个或者多个虚拟地址的组。该组内，一个系统是主（master），它响应目的为该组的网络包；其它主机是备（backup），它们会 standby，等待主出现问题而接替它。
在一个可配置的时间间隔上，主在 IP 协议号码 112 上不断向网段发出广播，使得各备实例都知道它还活着。如果备实例在一段时间内收不到主的广播，它们中的一个将成为新主 (其中那个配置了最小advbase 和 advskew值的那个实例）。当老主重新恢复后，默认地它成为一个备，尽管可以通过配置让它尝试着重新成为新的主。
每个 CARP 冗余组以一个虚拟网卡表示，使用 ifconfig 来创建和配置。
ifconfig carpN create
ifconfig carpN vhid vhid [pass password] [carpdev carpdev] [advbase advbase] [advskew advskew] [state state] [group|-group group] \
ipaddress netmask mask
其中比较关键的几个参数：
- carpN：虚拟网卡的名字，其中 N 是一个整数，表示虚拟网卡的号码
- vhid：冗余组ID
- password：一个CARP 实例和组内其它实例通信使用的密码
- carpdev：绑定的网卡
- advbase：广播的频率，单位为秒，默认为1s。值越小，越大概率成为主。
- advskew：how much to skew the advbase when sending CARP advertisements。影响主选举的另一个因子。值越大，越小概率成为主。
- ipaddress/mask：虚拟IP和子网掩码
要触发主备zh failover，通常有几个办法：
- 在主节点上 ifup carp 网卡：ifconfig carp1 down。这会使得主的广播信息中 advbase 和 advskew 为无限大，备收到后会立刻选举出新主。
- 增加主节点上 carp 的 advskew 值，使得它比备大。这个办法会使得主保留在 carp 冗余组内。
同时，你也可以看到，CARP 只是创建和管理虚拟网络设备；系统管理员需要去在应用之间同步数据。
（以上文字翻译自 http://www.kernel-panic.it/openbsd/carp/carp4.html。更多信息，可参考 http://www.openbsd.org/faq/pf/carp.html）
3.1.2 CARP， VRRP 和 HSRP 之间的比较
- VRRP：Virtual Router Redundacy Protocol
- HSRP：Hot Standby Router Protocol
- CARP：Common Address Redundancy Protocol
这三个协议都能向防火墙和路由器提供 failover redundancy，通过在多个实例之间共享虚拟MAC地址和IP地址。通过这个方法，如果你的主防火墙或者路由器失效，其它备可以几乎透明地接替它。
简单比较如下：
- HSRP 是 Cisco 的一个专利私有协议。具体内容可以查看 RFC 2281 - Cisco Hot Standby Router Protocol (HSRP)。
- VRRP 是一个 IETF 标准协议，它解决了 HSRP 的一些问题。但是，Cisco 声称它拥有它的实现专利。Virtual Router Redundancy Protocol (VRRP)
- CARP 是由 OpenBSD 开发的与 HSRP 和 VRRP 类似的一个协议。
（本段内容来自 https://ppires.wordpress.com/2007/02/07/hight-network-availability-vrrp-hsrp-carp/）
3.2 UCARP
UCARP 允许多个主机共享一个虚拟的ip地址，以提供自动的故障恢复功能，当其中某个主机宕机时，其它的主机会自动接管服务。UCARP是CARP协议（通用地址冗余协议，最早在OpenBSD上实现）的linux实现版本，同时也能移植到其它多个unix平台，UCARP的官方网站：http://www.ucarp.org/project/ucarp 。CARP协议的特点在于其非常低的开销，主机间使用加密数据传递信息，并且在冗余主机之间不需要任何额外的网络链接。
3.2.1 ucarp 工具
ucarp 1.5. - Mar --interface=<if> (-i <if>): bind interface <if>
--srcip=<ip> (-s <ip>): source (real) IP address of that host
--vhid=<id> (-v <id>): virtual IP identifier (1-255)
--pass=<pass> (-p <pass>): password
--passfile=<file> (-o <file>): read password from file
--preempt (-P): becomes a master as soon as possible
--neutral (-n): don't run downscript at start if backup
--addr=<ip> (-a <ip>): virtual shared IP address
--help (-h): summary of command-line options
--advbase=<seconds> (-b <seconds>): advertisement frequency
--advskew=<skew> (-k <skew>): advertisement skew (0-255)
--upscript=<file> (-u <file>): run <file> to become a master
--downscript=<file> (-d <file>): run <file> to become a backup
--deadratio=<ratio> (-r <ratio>): ratio to consider a host as dead
--shutdown (-z): call shutdown script at exit
--daemonize (-B): run in background
--ignoreifstate (-S): ignore interface state (down, no carrier)
--nomcast (-M): use broadcast (instead of multicast) advertisements
--facility=<facility> (-f): set syslog facility (default=daemon)
--xparam=<value> (-x): extra parameter to send to up/down scripts
3.2.2 通常的做法
在冗余组内的所有节点上，编辑 /etc/network/interfaces，添加：
ucarp-vid 1
ucarp-passwd tequila123
ucarp-vip 192.168.3.31
ucarp-advbase 1
ucarp-advskew 50
ucarp-master no
iface eth0:ucarp inet static
address 192.168.3.31
netmask 255.255.255.0
然后，
- 在 upscript 文件中，ifup eth0:ucarp
- 在 downscript 文件中，ifdown eth0:ucarp
触发主备 failover 的两个方法:
- ifdown eth0
- kill -usr2 <pid of ucarp>
更多信息，可以参考：
3.3 UCARP 配置
在三个节点上安装 UCARP，然后分配创建三个 shell 文件（注意每个节点上需要使用不同的IP地址）：
root@swift1:/etc/ucarp# cat master.sh #用于启动 ucarp 进程，指定 VIP 为 9.115.251.238
#!/bin/bash /usr/sbin/ucarp -i eth0 -v -p gw22 -a 9.115.251.238 -u /etc/ucarp/master-up.sh -d /etc/ucarp/master-down.sh -s 9.115.251.235 -P -B root@swift1:/etc/ucarp# cat master-up.sh #当UCARP使得本节点做为 VIP 的承载节点时运行的脚本
#!/bin/bash GATEWAY=9.115.251.1
/sbin/ip addr add 9.115.251.238/ dev eth0
/bin/hostname swiftproxy
/sbin/route add default gw $GATEWAY
service httpd start root@swift1:/etc/ucarp# cat master-down.sh #当 UCARP 使得本节点不再作为 VIP 的承载节点时运行的脚本
#!/bin/bash GATEWAY=9.115.251.1
/sbin/ip addr del 9.115.251.238/ dev eth0
/bin/hostname swift1
/sbin/route add default gw $GATEWAY
service httpd stop
简单来说，UCAPR 类似于一个简化版的 VRRP。它在三个服务器之间选择一个作为主节点，由它提供服务，另外两个节点做为备节点，在主节点无法提供服务时升级为主节点。脚本也相对简单，就是将 VIP 加到物理网卡上，在修改 hostname 和 gateway。
最后运行 master.sh 来启动 ucarp 进程。
4. Glance 使用 Swift 的配置
（1）创建 openstack endpoint，使用 UCARP 管理的 VIP 和 HAProxy 管理的 port：
root@controller:~/s1# openstack endpoint show 1f107e61c4024f0a9655fa7276a09c61
+--------------+-------------------------------------------------+
| Field | Value |
+--------------+-------------------------------------------------+
| adminurl | http://9.115.251.238:1002 |
| enabled | True |
| id | 1f107e61c4024f0a9655fa7276a09c61 |
| internalurl | http://9.115.251.238:1002/v1/AUTH_%(tenant_id)s |
| publicurl | http://9.115.251.238:1002/v1/AUTH_%(tenant_id)s |
| region | RegionOne |
| service_id | 3281409aec0c4628a3360bf9403e45e8 |
| service_name | swift |
| service_type | object-store |
+--------------+-------------------------------------------------+
（2）配置 Glance API
使用 Glance API V2，不使用 glance-registry V2。使用 keystone V3 API。修改 /etc/glance/glance-api.conf 文件，
[glance_store]
stores = glance.store.filesystem.Store, glance.store.swift.Store
default_store = swift swift_store_auth_version =
swift_store_auth_address = http://controller:35357/v3/
swift_store_user = service:glance
swift_store_key =
swift_store_container = glance
这里的一个疑惑是 glance 是 service account 而不是 end user account，按照一些文章，需要配置 proxy node 上的 reseller_prefix，但是在这个环境中没配置功能也能工作。
（3）接下来就可以使用 glance CLI 来将镜像保存到 Swift 中了。
当使用 glance image-download CLI 下载 image 时，从 glance-api 的日志中可以看出，glance 是使用 python-swiftclient 来从 Swift 中获取 image 的：
-- ::21.723 DEBUG swiftclient [req-df449af5-7ac5--a65c-89e3d37d82f4 0677bcabfe36412199289a21f773c03c dea8b51d28bf41599e63464828102759 - - -] REQ: curl -i http://9.115.251.238:1002/v1/AUTH_25c6bd7a4b174d54bc483dae2e293a14/glance/6b3acfc1-0012-4c92-85ba-5946a96bab65 -X GET -H "X-Auth-Token: d6e8681da8384715b3e446117e91424c" http_log /usr/lib/python2.7/dist-packages/swiftclient/client.py:95
-- ::21.724 DEBUG swiftclient [req-df449af5-7ac5--a65c-89e3d37d82f4 0677bcabfe36412199289a21f773c03c dea8b51d28bf41599e63464828102759 - - -] RESP STATUS:
5. Swift TempUrl
这本来是Swift一个比较简单的功能，但是用由于存在于不同文档中的问题（不一致、不全面、没更新），导致花了不少时间才弄出来。
（1）配置
修改 /etc/swift/proxy-server.conf 文件，在 main pipeline 中加入 tempurl 这个 middleware。需要注意的是，它必须加到 auth middleware 前面，这是因为这些middleware 是按照顺序被调用的。然后打开允许使用的 HTTP 操作。
[pipeline:main]
pipeline = catch_errors gatekeeper healthcheck proxy-logging cache container_sync bulk ratelimit tempurl authtoken keystoneauth container-quotas account-quotas slo dlo proxy-logging proxy-server
[filter:tempurl]
use = egg:swift#tempurl
# The methods allowed with Temp URLs.
methods = GET HEAD PUT POST DELETE
另外，需要确保 [filter:authtoken] 部分设置了 delay_auth_decision = true。
（2）添加 Temp-URL-Key meta，设置它为一个 secret key
root@controller:~/s1# swift post -m "Temp-URL-Key:1111" #设置
root@controller:~/s1# swift stat #查看
Account: AUTH_dea8b51d28bf41599e63464828102759 （下面第三步会用到）
Containers:
Objects:
Bytes:
Containers in policy "policy-0":
Objects in policy "policy-0":
Bytes in policy "policy-0":
Meta Temp-Url-Key: 1111
（3）产生 Temp URL。这里需要注意的是，AUTH 后面不是 account name 比如 “admin”，而是 project id。这个也可以使用 swift stat 命令查看其 Account 的值。
root@controller:~/s1# swift tempurl GET /v1/AUTH_dea8b51d28bf41599e63464828102759/container1/
/v1/AUTH_dea8b51d28bf41599e63464828102759/container1/?temp_url_sig=fc9f80211aa5c6262f62ca4d57db65b25f1cef7a&temp_url_expires=
（4）使用 tempurl。需要确保URL的完整性，否则会得到 401 错误。
root@controller:~/s1# curl "http://9.115.251.238:1002/v1/AUTH_dea8b51d28bf41599e63464828102759/container1/1?temp_url_sig=fc9f80211aa5c6262f62ca4d57db65b25f1cef7a&temp_url_expires=1447087996"
另外需要注意的是，各个节点需要（最好）使用 UTC 时区，必须使用 NTP 服务确保时间一致。
（5）得到 401 错误时的调试
Swift 默认情况下日志会写到 /var/log/syslog 文件中。有如下一下调试技巧：
（a）. 设置 proxy-server 的 log leve 为 DEBUG
[app:proxy-server]
# You can override the default log routing for this app here:
set log_name = proxy-server
set log_level = DEBUG
[filter:tempurl]
set log_name = tempurl
set log_level = DEBUG
（b）. 将 worker 数目设为 0 可以方便调试，默认的话为 2.
workers =
（c）可以在 /usr/lib/python2.7/dist-packages/swift/common/middleware/tempurl.py 中加入 logger 输出。
然后你就可以看到 proxy server 和 tempurl 的详细日志了：
Nov 9 15:55:48 swift3 proxy-server: 9.115.251.219 9.115.251.233 09/Nov/2015/15/55/48 GET /v1/AUTH_dea8b51d28bf41599e63464828102759/container1/%3Ftemp_url_expires%3D1447087996%26temp_url_sig%3Dfc9f80211aa5c6262f62ca4d57db65b25f1cef7a HTTP/1.0 - curl/7.35. - - - tx9ce884232d5a48bb9b5d8-005640c204 - 0.0261 - - 1447084548.853318930 1447084548.879395962
Nov 9 15:55:48 swift3 tempurl: hmac_vals is ['fc9f80211aa5c6262f62ca4d57db65b25f1cef7a'] (txn: tx9ce884232d5a48bb9b5d8-005640c204)
如果使用非 UTC 时区的话，上面蓝色字体部分的两个时间会不一致，会导致问题。
6. 备份 Cinder 卷到 Swift
一直没机会试试 cinder-backup，现在有 Swift 了，终于可以试试了。
在 cinder.conf 中的配置：
backup_driver = cinder.backup.drivers.swift
backup_swift_url = http://9.115.251.238:1002/v1/AUTH_
backup_swift_auth = per_user
backup_swift_auth_version =
backup_swift_user = cinder
backup_swift_tenant = service
backup_swift_key =
backup_swift_container = volumebackups
backup_swift_object_size =
backup_swift_retry_attempts =
backup_swift_retry_backoff =
backup_compression_algorithm = zlib
重启 cinder-backup 服务，然后创建一个 cinder backup：
root@controller:~/s1# cinder backup-create --name vol100bk 76192a47-3be3-4ce9-b6df-0416558910a6
+-----------+--------------------------------------+
| Property | Value |
+-----------+--------------------------------------+
| id | c4b31f0b--4bf2-b033-68779716b151 |
| name | vol100bk |
| volume_id | 76192a47-3be3-4ce9-b6df-0416558910a6 |
+-----------+--------------------------------------+
然后一段时间（和卷大小有关）后，Swift 中就有了若干个对象：
root@controller:~/s1# swift list volumebackups
volume_76192a47-3be3-4ce9-b6df-0416558910a6//az_nova_backup_c4b31f0b--4bf2-b033-68779716b151-
volume_76192a47-3be3-4ce9-b6df-0416558910a6//az_nova_backup_c4b31f0b--4bf2-b033-68779716b151-......
0416558910a6//az_nova_backup_c4b31f0b--4bf2-b033-68779716b151-
volume_76192a47-3be3-4ce9-b6df-0416558910a6//az_nova_backup_c4b31f0b--4bf2-b033-68779716b151_metadata
volume_76192a47-3be3-4ce9-b6df-0416558910a6//az_nova_backup_c4b31f0b--4bf2-b033-68779716b151_sha256file
然后就可以继续使用cinder backup 相关的一些命令来操作它：
backup-delete Removes a backup.
backup-export Export backup metadata record.
backup-import Import backup metadata record.
backup-list Lists all backups.
backup-restore Restores a backup.
backup-show Shows backup details.
具体的细节，比如为什么创建了那么多的对象，还得进一步的学习。
7. 向已有集群添加新的节点
7.1 步骤
添加一个带 3TB 磁盘的节点：
$ swift-ring-builder account.builder add z1-192.168.12.104:/d16
$ swift-ring-builder container.builder add z1-192.168.12.104:/d16
$ swift-ring-builder object.builder add z1-192.168.12.104:/d16 $ swift-ring-builder account.builder rebalance
$ swift-ring-builder container.builder rebalance
$ swift-ring-builder object.builder rebalance $ scp account.ring.gz swift-node-:/etc/swift/account.ring.gz
$ scp container.ring.gz swift-node-:/etc/swift/container.ring.gz
$ scp object.ring.gz swift-node-:/etc/swift/account.ring.gz $ scp account.ring.gz swift-node-:/etc/swift/account.ring.gz
$ scp container.ring.gz swift-node-:/etc/swift/container.ring.gz
$ scp object.ring.gz swift-node-:/etc/swift/account.ring.gz
...
$ scp account.ring.gz swift-node-:/etc/swift/account.ring.gz
$ scp container.ring.gz swift-node-:/etc/swift/container.ring.gz
$ scp object.ring.gz swift-node-:/etc/swift/account.ring.gz
7.2 问题
文章 Swift Capacity Management 说明了这么做的一个问题：由于数据移动，会导致短期内集群的性能大大下降。建议是分步增加 weight：
- 第一次：
$ swift-ring-builder account.builder add z1-192.168.12.104:6002/d16 25 - 第二次：
$ swift-ring-builder account.builder set_weight z1-192.168.12.104:6002/d16 50 - ...
- 第120次：
$ swift-ring-builder account.builder set_weight z1-192.168.12.104:6002/d16 3000
更详细的 Swift 说明，在接下来的文章中会分析。
参考文档：