• 设为首页
  • 点击收藏
  • 手机版
    手机扫一扫访问
    迪恩网络手机版
  • 关注官方公众号
    微信扫一扫关注
    公众号

理解 OpenStack Swift (1):OpenStack + 三节点Swift 集群+ HAProxy + UCARP 安装和 ...

原作者: [db:作者] 来自: [db:来源] 收藏 邀请

本系列文章着重学习和研究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,没什么花头。基本流程:

  1. 系统盘准备(操作系统磁盘往往使用 RAID 1提高可靠性)
  2. 操作系统安装
  3. Swift 软件安安装
  4. 数据盘准备(不需要 RAID)
  5. 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_filerebalance 命令了。它会使得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 之间的比较

  • VRRPVirtual Router Redundacy Protocol
  • HSRPHot Standby Router Protocol
  • CARPCommon Address Redundancy Protocol

这三个协议都能向防火墙和路由器提供 failover redundancy,通过在多个实例之间共享虚拟MAC地址和IP地址。通过这个方法,如果你的主防火墙或者路由器失效,其它备可以几乎透明地接替它。

简单比较如下:

(本段内容来自 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地址):

[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=
                      

鲜花

握手

雷人

路过

鸡蛋
该文章已有0人参与评论

请发表评论

全部评论

专题导读
热门推荐
热门话题
阅读排行榜

扫描微信二维码

查看手机版网站

随时了解更新最新资讯

139-2527-9053

在线客服(服务时间 9:00~18:00)

在线QQ客服
地址:深圳市南山区西丽大学城创智工业园
电邮:jeky_zhao#qq.com
移动电话:139-2527-9053

Powered by 互联科技 X3.4© 2001-2213 极客世界.|Sitemap