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

本系列文章着重学习和研究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 的配置如下：

[email protected]:/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 操作：

[email protected]:~/s1# swift upload conatiner10 a
a
[email protected]:~/s1# swift list conatiner10
a
[email protected]:~/s1# swift download conatiner10 a
a [auth 0.408s, headers 0.458s, total 3.564s, 34.404 MB/s]
[email protected]:~/s1# swift delete conatiner10 a
a
[email protected]:~/s1# swift list conatiner10
[email protected]:~/s1#

如果不使用配置文件，也可以在命令行中直接指定参数，比如 swift [-A *Auth URL*] [-U *username*] [-K *password*] stat。

2. HAProxy 安装和配置

在每个节点上安装 HAProxy，然后修改配置文件：

[email protected]:~/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地址）：

[email protected]:/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

[email protected]:/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

[email protected]:/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：

[email protected]:~/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

[email protected]:~/s1# swift post -m "Temp-URL-Key:1111" #设置
[email protected]:~/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 的值。

[email protected]:~/s1# swift tempurl GET 3600 /v1/AUTH_dea8b51d28bf41599e63464828102759/container1/1 1111
/v1/AUTH_dea8b51d28bf41599e63464828102759/container1/1?temp_url_sig=fc9f80211aa5c6262f62ca4d57db65b25f1cef7a&temp_url_expires=

客服电话

电子邮件