理解 OpenStack Swift （1）：OpenStack + 三节点Swift 集群+ HAProxy + UCARP 安装和配置

时间 2019-11-24

标签理解 openstack swift 三节集群 haproxy ucarp 安装配置栏目 Swift 繁體版

原文原文链接

本系列文章着重学习和研究OpenStack Swift，包括环境搭建、原理、架构、监控和性能等。html

（1）OpenStack + 三节点Swift 集群+ HAProxy + UCARP 安装和配置 node

（2）原理、架构和性能python

（3）监控linux

要实现的系统的效果图：git

特色：github

使用三个对等物理节点，每一个节点上部署全部Swift 服务
使用开源的 UCARP 控制一个 VIP，它会被绑定到三个物理网卡中的一个。
使用开源的 HAProxy 作负载均衡
开启 Swift TempURL

1. Swift 集群安装和配置

1.1 Swift 安装

Swift 是被设计来在商用硬件上运行的。并且在存储磁盘上不须要并且不推荐使用RAID，相反，使用 RAID 5 或者 6 的和，会带来严重的性能降低。Swift 中包含多种服务，主要的有四种：shell

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，没什么花头。基本流程：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>

更多信息，能够参考：

https://ucarp.wordpress.com/

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 说明，在接下来的文章中会分析。

参考文档：

利用ucarp实现虚拟IP故障转移