本系列文章着重学习和研究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 6 1024 partitions, 3.000000 replicas, 1 regions, 3 zones, 6 devices, 0.00 balance, 0.00 dispersion The minimum number of hours before a partition can be reassigned is 1 The overload factor is 0.00% (0.000000) Devices: id region zone ip address port replication ip replication port name weight partitions balance meta 0 1 1 9.115.251.235 6000 9.115.251.235 6000 sdb1 100.00 512 0.00 1 1 1 9.115.251.235 6000 9.115.251.235 6000 sdc1 100.00 512 0.00 2 1 2 9.115.251.234 6000 9.115.251.234 6000 sdb1 100.00 512 0.00 3 1 2 9.115.251.234 6000 9.115.251.234 6000 sdc1 100.00 512 0.00 4 1 3 9.115.251.233 6000 9.115.251.233 6000 sdb1 100.00 512 0.00 5 1 3 9.115.251.233 6000 9.115.251.233 6000 sdc1 100.00 512 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=2 export OS_VOLUME_API_VERSION=2 export OS_AUTH_VERSION=3
进行常见的 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 0.408s, headers 0.458s, total 3.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 5000 clitimeout 50000 srvtimeout 50000 frontend localnodes bind *:1002 #HAProxy 在 1002 端口上监听 mode http default_backend swift-cluster maxconn 100 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:8080 weight 5 check inter 5s #节点1
server proxy2 9.115.251.233:8080 weight 5 check inter 5s #节点2
server proxy3 9.115.251.234:8080 weight 5 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.2 - Mar 25 2014 --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 40 -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/24 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/24 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 = 3 swift_store_auth_address = http://controller:35357/v3/ swift_store_user = service:glance swift_store_key = 1111 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 的：
2015-11-09 10:39:21.723 28246 DEBUG swiftclient [req-df449af5-7ac5-4413-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 2015-11-09 10:39:21.724 28246 DEBUG swiftclient [req-df449af5-7ac5-4413-a65c-89e3d37d82f4 0677bcabfe36412199289a21f773c03c dea8b51d28bf41599e63464828102759 - - -] RESP STATUS: 200
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: 5 Objects: 11 Bytes: 416894908 Containers in policy "policy-0": 5 Objects in policy "policy-0": 11 Bytes in policy "policy-0": 416894908 Meta Temp-Url-Key: 1111
（3）产生 Temp URL。这里需要注意的是，AUTH 后面不是 account name 比如 “admin”，而是 project id。这个也可以使用 swift stat 命令查看其 Account 的值。
root@controller:~/s1# swift tempurl GET 3600 /v1/AUTH_dea8b51d28bf41599e63464828102759/container1/1 1111 /v1/AUTH_dea8b51d28bf41599e63464828102759/container1/1?temp_url_sig=fc9f80211aa5c6262f62ca4d57db65b25f1cef7a&temp_url_expires=1447087996
（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" 222222222222
另外需要注意的是，各个节点需要（最好）使用 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 = 0
（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/1%3Ftemp_url_expires%3D1447087996%26temp_url_sig%3Dfc9f80211aa5c6262f62ca4d57db65b25f1cef7a HTTP/1.0 200 - curl/7.35.0 - - 12 - 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 = 3 backup_swift_user = cinder backup_swift_tenant = service backup_swift_key = 1111 backup_swift_container = volumebackups backup_swift_object_size = 52428800 backup_swift_retry_attempts = 3 backup_swift_retry_backoff = 2 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-5145-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/20151110123343/az_nova_backup_c4b31f0b-5145-4bf2-b033-68779716b151-00001 volume_76192a47-3be3-4ce9-b6df-0416558910a6/20151110123343/az_nova_backup_c4b31f0b-5145-4bf2-b033-68779716b151-00002...... 0416558910a6/20151110123343/az_nova_backup_c4b31f0b-5145-4bf2-b033-68779716b151-00021 volume_76192a47-3be3-4ce9-b6df-0416558910a6/20151110123343/az_nova_backup_c4b31f0b-5145-4bf2-b033-68779716b151_metadata volume_76192a47-3be3-4ce9-b6df-0416558910a6/20151110123343/az_nova_backup_c4b31f0b-5145-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:6002/d16 3000 $ swift-ring-builder container.builder add z1-192.168.12.104:6001/d16 3000 $ swift-ring-builder object.builder add z1-192.168.12.104:6000/d16 3000 $ swift-ring-builder account.builder rebalance $ swift-ring-builder container.builder rebalance $ swift-ring-builder object.builder rebalance $ scp account.ring.gz swift-node-1:/etc/swift/account.ring.gz $ scp container.ring.gz swift-node-1:/etc/swift/container.ring.gz $ scp object.ring.gz swift-node-1:/etc/swift/account.ring.gz $ scp account.ring.gz swift-node-2:/etc/swift/account.ring.gz $ scp container.ring.gz swift-node-2:/etc/swift/container.ring.gz $ scp object.ring.gz swift-node-2:/etc/swift/account.ring.gz ... $ scp account.ring.gz swift-node-10:/etc/swift/account.ring.gz $ scp container.ring.gz swift-node-10:/etc/swift/container.ring.gz $ scp object.ring.gz swift-node-10:/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 说明，在接下来的文章中会分析。
参考文档：