理解 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 說明，在接下來的文章中會分析。

參考文檔：