本系列文章着重学习和研究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地址。通过这个方法，如果你的主防火墙或者路由器失效，其它备可以几乎透明地接替它。
简单比较如下：
（本段内容来自 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.
（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 说明，在接下来的文章中会分析。
参考文档：
本文转自SammyLiu博客园博客，原文链接：http://www.cnblogs.com/sammyliu/p/4923432.html
，如需转载请自行联系原作者
