标签：
本系列文章着重学习和研究OpenStack Swift，包括环境搭建、原理、架构、监控和性能等。
（1）OpenStack + 三节点Swift 集群+ HAProxy + UCARP 安装和配置
（2）Swift 原理和架构
（3）Swift 监控
（4）Swift 性能
要实现的系统的效果图：
特点：
使用 OpenStack Swift Kilo 版本，按照社区官方文档安装Swift，没什么花头。特点：
使用 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
进行常见操作：
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#
在每个节点上安装 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 进程。
UCARP 允许多个主机共享一个虚拟的ip地址，以提供自动的故障恢复功能，当其中某个主机宕机时，其它的主机会自动接管服务。UCARP是CARP协议（通用地址冗余协议，最早在OpenBSD上实现）的linux实现版本，同时也能移植到其它多个unix平台，UCARP的官方网站：http://www.ucarp.org/project/ucarp 。CARP协议的特点在于其非常低的开销，主机间使用加密数据传递信息，并且在冗余主机之间不需要任何额外的网络链接。
在三个节点上安装 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 进程。
（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 中了。
这本来是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 时区的话，上面蓝色字体部分的两个时间会不一致，会导致问题。
更详细的 Swift 说明，在接下来的文章中会分析。
参考文档：
理解 OpenStack Swift （1）：OpenStack + 三节点Swift 集群+ HAProxy + UCARP 安装和配置
标签：
原文地址：http://www.cnblogs.com/sammyliu/p/4923432.html
