本系列文章着重學習和研究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 說明，在接下來的文章中會分析。
參考文檔：