客服电话
APP下载
迪恩网络APP
随时随地掌握行业动态
官方微信
扫描二维码
关注迪恩网络微信公众号
|
本系列文章着重学习和研究OpenStack Swift，包括环境搭建、原理、架构、监控和性能等。 （1）OpenStack + 三节点Swift 集群+ HAProxy + UCARP 安装和配置 （2）原理、架构和性能 （3）监控
要实现的系统的效果图： 特点：
1. Swift 集群安装和配置1.1 Swift 安装Swift 是被设计来在商用硬件上运行的。而且在存储磁盘上不需要而且不推荐使用RAID，相反，使用 RAID 5 或者 6 的和，会带来严重的性能下降。Swift 中包含多种服务，主要的有四种：
这些服务都可以独立运行。这些服务中，Proxy service 是更需要 CPU 和 网络带宽的，因此，可以使用 10GbE 或者更高的带宽。如果将 SSL 段设在proxy service 上的话，它也会消耗 CPU。其它三种服务是磁盘和网络带宽敏感的。由于每个服务的独立性，因此，有多种部署方式。比如将所有服务部署在一个节点上，这样所有服务都可以水平扩展。也可以将 proxy service 单独出来，它可以使用 10GbE 或者更高的网络，而 storage 节点可以使用更加经济的 1GbE 网络。如果你需要更高的 Account 或者 Container service 吞吐能力，他们都可以被部署在单独的服务器上，比如使用更快的 SAS 或者 SSD 磁盘来放置它们的数据库文件。另外，还需要考虑负载均衡问题。 本案例使用 OpenStack Swift Kilo 版本，按照社区官方文档安装和配置 Swift，没什么花头。基本流程：
本案例使用的环境的特点：
1.2 Swift 配置1.2.1 Ring 配置Swift 配置中，需要注意的是 Ring 的配置，它包含几个关键值：
然后使用 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。它表示：
然后使用 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 MemcachedSwift 本身不对数据做任何缓存，它的 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 地址 然后运行命令/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 其中比较关键的几个参数：
要触发主备zh failover，通常有几个办法：
同时，你也可以看到，CARP 只是创建和管理虚拟网络设备；系统管理员需要去在应用之间同步数据。 （以上文字翻译自 http://www.kernel-panic.it/openbsd/carp/carp4.html。更多信息，可参考 http://www.openbsd.org/faq/pf/carp.html） 3.1.2 CARP， VRRP 和 HSRP 之间的比较
这三个协议都能向防火墙和路由器提供 failover redundancy，通过在多个实例之间共享虚拟MAC地址和IP地址。通过这个方法，如果你的主防火墙或者路由器失效，其它备可以几乎透明地接替它。 简单比较如下：
（本段内容来自 https://ppires.wordpress.com/2007/02/07/hight-network-availability-vrrp-hsrp-carp/） 3.2 UCARPUCARP 允许多个主机共享一个虚拟的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
然后，
触发主备 failover 的两个方法:
更多信息，可以参考： 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] 另外，需要确保 [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_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 时区的话，上面蓝色字体部分的两个时间会不一致，会导致问题。 一直没机会试试 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 说明，在接下来的文章中会分析。 参考文档： |
请发表评论