• 5台服务器 A B C D E ...nginx:0.6.33版本后不允许POST方法访问静态资源,swift 只有head get方法能用,post put等方法被阻挡在nginx,无法下发到proxyserver。错误表现为:405 Not Allowed 修改配置文件和改

    5台服务器 A B C D E

    A为负载均衡

    BCDE 既做proxy server 又做storage server


    负载均衡工具的选择:

    nginx:0.6.33版本后不允许POST方法访问静态资源,swift 只有head get方法能用,post put等方法被阻挡在nginx,无法下发到proxyserver。错误表现为:405 Not Allowed

    修改配置文件和改代码的方法都没有解决。


    pound  CPU负载过高(据说)


    HAProxy  :配置简单,均衡策略多样,负载小。还有一个简单的web监控页面,很方便。

    使用roundrobin 策略时,引发了多proxy server环境下 swift tempauth验证方式的问题,根本原因是多proxy之间无法共享各自产生的token。

    又在A上部署了keystone,将B C D E上swift的验证方式改为 keystone,成功!



    未完待续...


    性能待测...


    展开全文
  •  1、性能测试测试一:五个线程,每个线程上传一个大小差不多一个G的文件/data/swift/upload> du -sh test*.zip987M test1.zip987M test2.zip987M test3.zip987M test4.zip987M test.zip上传sw...

    延续上一个文章的做接下来的测试,环境是一个proxy和三个storage。

      

    1、性能测试

    测试一:五个线程,每个线程上传一个大小差不多一个G的文件

    /data/swift/upload> du -sh test*.zip

    987M    test1.zip

    987M    test2.zip

    987M    test3.zip

    987M    test4.zip

    987M    test.zip


    上传

    swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass upload container1 test.zip

    swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass upload container2 test1.zip

    swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass upload container3 test2.zip

    swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass upload container4 test3.zip

    swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass upload container5 test4.zip


    共用时8:30:45


    存储节点查看文件

    /srv/node/sdb1> du -sh *

    16K     accounts

    356M    async_pending

    129M    containers

    4.9G    objects

    0       tmp


    查看上传的文件

    /data/swift/upload> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass list container1 

    test.zip

    /data/swift/upload> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass list container2

    test1.zip

    /data/swift/upload> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass list container3

    test2.zip

    /data/swift/upload> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass list container4

    test3.zip

    /data/swift/upload> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass list container5

    test4.zip


    测试二,十个线程:

    /data/swift/upload/test100M> du -sh *

    /data/swift/upload/test100M> du -sh *

    505M    test10.zip

    505M    test1.zip

    505M    test2.zip

    505M    test3.zip

    505M    test4.zip

    505M    test5.zip

    505M    test6.zip

    505M    test7.zip

    505M    test8.zip

    505M    test9.zip


    单个线程测试上传2.6M/s,下载5.1M/s


    五线程测试:

    上传

    第一个用时03:20s,2.5M/s

    第二个用时04:30s,1.85M/s

    第三个用时05:50s,1.31M/s

    第四个用时06:55s,1.2M/s

    第五个用时07:00s,1.19M/s


    下载

    第一个用时30.263s, 17.461 MB/s

    第二个用时49.415s, 10.691 MB/s

    第三个用时54.724s, 9.653 MB/s

    第四个用时86.473s, 6.108 MB/s

    第五个用时97.919s, 5.417 MB/s


    十线程测试:

    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass upload container1 test1.zip  

    test1.zip


    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass upload container2  test2.zip 


    Object PUT failed: http://192.168.1.211:8090:8090/v1/AUTH_system/container2/test2.zip 404 Not Found  [first 60 chars of response] <html><h1>Not Found</h1><p>The resource could not be found.<


    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass upload container3 test3.zip  

    test3.zip


    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass upload container4 test4.zip

    Object PUT failed: http://192.168.1.211:8090:8090/v1/AUTH_system/container4/test4.zip 503 Internal Server Error  [first 60 chars of response] <html><h1>Service Unavailable</h1><p>The server is currently


    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass upload container5 test5.zip  

    Object PUT failed: http://192.168.1.211:8090:8090/v1/AUTH_system/container5/test5.zip 404 Not Found  [first 60 chars of response] <html><h1>Not Found</h1><p>The resource could not be found.<


    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass upload container6 test6.zip  

    Object PUT failed: http://192.168.1.211:8090:8090/v1/AUTH_system/container6/test6.zip 404 Not Found  [first 60 chars of response] <html><h1>Not Found</h1><p>The resource could not be found.<



    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass upload container7 test7.zip  

    Object PUT failed: http://192.168.1.211:8090:8090/v1/AUTH_system/container7/test7.zip 404 Not Found  [first 60 chars of response] <html><h1>Not Found</h1><p>The resource could not be found.<


    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass upload container8 test8.zip  

    Object PUT failed: http://192.168.1.211:8090:8090/v1/AUTH_system/container8/test8.zip 404 Not Found  [first 60 chars of response] <html><h1>Not Found</h1><p>The resource could not be found.<


    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass upload container9 test9.zip  

    Object PUT failed: http://192.168.1.211:8090:8090/v1/AUTH_system/container9/test9.zip 404 Not Found  [first 60 chars of response] <html><h1>Not Found</h1><p>The resource could not be found.<


    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass upload container10 test10.zip 

    Object PUT failed: http://192.168.1.211:8090:8090/v1/AUTH_system/container10/test10.zip 404 Not Found  [first 60 chars of response] <html><h1>Not Found</h1><p>The resource could not be found.<


    但是只有七个上传成功

    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass list container1

    test1.zip

    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass list container2

    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass list container3

    test3.zip

    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass list container4

    test4.zip

    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass list container5

    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass list container6

    test6.zip

    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass list container7

    test7.zip

    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass list container8

    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass list container9

    test9.zip

    /data/swift/upload/test100M> swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass list container10

    test10.zip



    上传

    第一个用时00:39s,12M/s

    第二个用时01:01s,8.19M/s

    第三个用时03:37s,2.3M/s

    第四个用时06:16s,1.32M/s

    第五个用时06:16s,1.32M/s

    第六个用时07:06s,1.17M/s

    第七个用时07:06s,1.17M/s


    下载

    第一个用时73.207s, 7.216 MB/s

    第二个用时107.437s, 4.916 MB/s

    第三个用时107.581s, 4.910 MB/s

    第四个用时108.457s, 4.870 MB/s

    第五个用时117.852s, 4.482 MB/s

    第六个用时121.565s, 4.345 MB/s

    第七个用时122.600s, 4.308 MB/s

    第八个用时122.413s, 4.315 MB/s

    第九个用时145.383s, 3.633 MB/s

    第十个用时174.677s, 3.024 MB/s


    2、破坏性测试


    测试一:测试关闭一个存储节点的服务之后上传文件会不会在开启该存储服务后同步


    查看一个存储节点的服务

    /srv/node/sdb1> ps -ef | grep swift

    swift     5651 10735  5 17:16 ?        00:01:10 /usr/bin/python /usr/bin/swift-object-updater /etc/swift/object-server.conf

    swift     8409 10727  3 17:38 ?        00:00:01 /usr/bin/python /usr/bin/swift-object-auditor /etc/swift/object-server.conf

    was_wcm   8477 12319  0 17:38 pts/0    00:00:00 grep swift

    swift    10723     1  0 Mar28 ?        00:00:50 /usr/bin/python /usr/bin/swift-container-updater /etc/swift/container-server.conf

    swift    10724     1  0 Mar28 ?        00:00:05 /usr/bin/python /usr/bin/swift-account-auditor /etc/swift/account-server.conf

    swift    10725     1  0 Mar28 ?        03:18:56 /usr/bin/python /usr/bin/swift-object-replicator /etc/swift/object-server.conf

    swift    10726     1  1 Mar28 ?        04:23:53 /usr/bin/python /usr/bin/swift-container-replicator /etc/swift/container-server.conf

    swift    10727     1  0 Mar28 ?        00:08:35 /usr/bin/python /usr/bin/swift-object-auditor /etc/swift/object-server.conf

    swift    10728     1  0 Mar28 ?        00:01:47 /usr/bin/python /usr/bin/swift-object-expirer /etc/swift/object-expirer.conf

    swift    10729     1  0 Mar28 ?        00:00:04 /usr/bin/python /usr/bin/swift-container-auditor /etc/swift/container-server.conf

    swift    10730     1  0 Mar28 ?        00:00:00 /usr/bin/python /usr/bin/swift-container-server /etc/swift/container-server.conf

    swift    10731     1  0 Mar28 ?        00:00:00 /usr/bin/python /usr/bin/swift-account-server /etc/swift/account-server.conf

    swift    10732     1  0 Mar28 ?        00:00:02 /usr/bin/python /usr/bin/swift-account-reaper /etc/swift/account-server.conf

    swift    10733     1  0 Mar28 ?        00:00:24 /usr/bin/python /usr/bin/swift-container-sync /etc/swift/container-server.conf

    swift    10734     1  0 Mar28 ?        00:06:13 /usr/bin/python /usr/bin/swift-account-replicator /etc/swift/account-server.conf

    swift    10735     1  0 Mar28 ?        00:00:06 /usr/bin/python /usr/bin/swift-object-updater /etc/swift/object-server.conf

    swift    10736     1  0 Mar28 ?        00:00:00 /usr/bin/python /usr/bin/swift-object-server /etc/swift/object-server.conf

    swift    10795 10730  0 Mar28 ?        00:18:29 /usr/bin/python /usr/bin/swift-container-server /etc/swift/container-server.conf

    swift    10796 10730  0 Mar28 ?        00:17:56 /usr/bin/python /usr/bin/swift-container-server /etc/swift/container-server.conf

    swift    10797 10736  0 Mar28 ?        02:58:11 /usr/bin/python /usr/bin/swift-object-server /etc/swift/object-server.conf

    swift    10798 10736  0 Mar28 ?        03:16:19 /usr/bin/python /usr/bin/swift-object-server /etc/swift/object-server.conf

    swift    10799 10731  0 Mar28 ?        00:04:15 /usr/bin/python /usr/bin/swift-account-server /etc/swift/account-server.conf

    swift    10800 10731  0 Mar28 ?        00:04:30 /usr/bin/python /usr/bin/swift-account-server /etc/swift/account-server.conf


    杀死服务

    # kill -9 `ps -ef | grep -v grep | grep object-server | awk '{print $2}'`


    上传文件

    swift -Ahttp://192.168.1.211:8090/auth/v1.0 -U system:root -K testpass upload container1 apache_install


    启动服务之前的三个存储文件对比

    swift@server2:/srv/node/sdb1/objects> ll | wc -l

    21


    swift@server3:/srv/node/sdb1/objects> ll | wc -l

    44


    swift@server4:/srv/node/sdb1/objects> ll | wc -l 

    44


    启动服务

    swift@server2:/srv/node/sdb1/objects> sudo swift-init all restart


    swift@server2:/srv/node/sdb1/objects> ll | wc -l

    44


    可以看到文件已经同步


    测试二:测试删除一个存储节点物理服务器上的文件会不会在之后同步其他存储节点上的文件


    删除一个存储节点的文件

    swift@server2:/srv/node/sdb1/objects> rm -rf *


    查看文件的同步变化

    swift@server2:/srv/node/sdb1> du -sh *

    16K     accounts

    356M    async_pending

    129M    containers

    0       objects

    0       tmp


    swift@server2:/srv/node/sdb1> du -sh *

    16K     accounts

    356M    async_pending

    129M    containers

    260K    objects

    0       tmp


    swift@server2:/srv/node/sdb1> du -sh *

    16K     accounts

    356M    async_pending

    129M    containers

    33M     objects

    0       tmp

    swift@server2:/srv/node/sdb1> du -sh *

    16K     accounts

    356M    async_pending

    129M    containers

    129M    objects

    0       tmp

    swift@server2:/srv/node/sdb1> du -sh *

    16K     accounts

    356M    async_pending

    129M    containers

    5.0G    objects

    0       tmp


    可以看到文件渐渐同步完成

    展开全文
  • 1 Swift概述Swift是Open Stack开源云计算项目的子项目之一,是一个多租户、高扩展性的和高可用性的对象存储系统,用于低成本地存储大量的非结构化数据;Swift通过在软件层面引入一致性哈希技术和数据冗余性,牺牲...

    1  Swift概述

    Swift是Open Stack开源云计算项目的子项目之一,是一个多租户、高扩展性的和高可用性的对象存储系统,用于低成本地存储大量的非结构化数据;Swift通过在软件层面引入一致性哈希技术和数据冗余性,牺牲一定程度的数据一致性来达到高可用性和可伸缩性,支持多租户模式、容器和对象读写操作,适合解决互联网的应用场景下非结构化数据存储问题。


    2  Swift关键特性

             扩展性:Swift可以根据存储的数据量和用户数量进行线性扩展,扩大规模时,可以通过增加存储节点来提升存储能力;    

             持久性:Swift采用了复制数据并且将副本分发到集群中来确保数据的持续可用性;

             高并发:Swift的设计原则允许将请求分发到多个服务器上。可充分利用可用的服务器性能来同时处理多个请求;

             无单点故障:Swift的元数据存储是完全均匀随机分布的,并且与对象文件存储一样,元数据也会存储多份;


    3  Swift集群部署

    3.1 部署环境

             本文主要讲述swift 3节点集群,实现accountcontainer信息存放在ssd盘,Object信息存放ssd盘和hdd盘,2副本策略的集群搭建。下面就是具体搭建步骤及注意事项;





    3.1.1 系统环境

    系统版本要求:CentOS7.3Build1611 X86_64

    更多参考官网:

    https://docs.openstack.org/swift/latest/getting_started.html#system-requirements


    3.1.2 存储环境

    数据盘:12

    文件系统:XFS

    备注:物理机多块数据磁盘,建议不使用RAID,不使用LVM管理


    3.1.3 网络环境

    多网段环境:swift绑定业务网卡地址

    单网段环境:bond 0.0.0.0

    万兆网卡:建议使用MTU 9000通信

    集群模式:集群模式下多台机器确保互通


    3.1.4 测试环境


    备注:三节点集群方式部署,测试环境中有4ssd,8hdd盘,因对磁盘的配置是一致的,本文以列举一块ssd01盘,一块hdd01盘为例进行介绍。


    3.2 部署准备

    3.2.1 配置文件打开数

    Swift服务是多线程服务,并且支持高并发。Swift通过基于httpREST服务接口对swift集群进行访问。在进行高并发TCP连接处理时,最高的并发数量都要受到系统对用户单一进程同时可打开文件数量的限制,这边需要配置下最大进程数和最大文件打开数:

    vim /etc/security/limits.conf

    *        soft  nproc  65536

    *        hard  nproc  65536

    *        soft  nofile  655350

    *        hard  nofile  655350        

    ulimit -n 65536


    3.2.2 配置系统内核

    由于Swift是通过基于httpREST接口对swift集群进行访问,需要对TCP/IP堆栈进行配置:

    vim /etc/sysctl.conf

    fs.file-max =655360

    net.core.somaxconn= 65535

    net.ipv4.tcp_tw_recycle= 1

    net.ipv4.tcp_tw_reuse= 1     

    sysctl –p


    其中:

    fs.file-max:表示进程可以同时打开的最大句柄数,这个参数直接限制最大并发连接数。

    net.ipv4.tcp_tw_reuse:设置为1,表示允许将TIME-WAIT状态的socket重新用于新的TCP链接。


    3.2.3 禁止防火墙

    1)禁用SELINUX

    vim /etc/selinux/config

    SELINUX=permissive

    2)关闭Firewall

    systemctl stop firewalld

    systemctl disable firewalld


    3.2.4 配置locale

    1) 配置为UTF-8,临时生效

    localectl set-locale LANG="en_US.UTF-8"

    2) 配置为UTF-8,永久生效

    vim /etc/locale.conf

    LANG="en_US.UTF-8"


    3.2.5 安装swift

    OpenStackSwift的官方发布版本在GitHubhttps://github.com/openstack /swift)上,可自由下载,对于OpenStack的每一个主版本,都有一个swift版本与之对应。

    安装swift

    cd/tmp

    gitclone https://github.com/openstack/swift.git

    cd/tmp/swift

    pythonsetup.py install


    3.2.6 安装swauth认证

    cd /tmp

    git clone https://github.com/openstack/swauth.git

    cd swauth

    python setup.py install

    注:swift节点均执行以上部署操作;


    3.3 配置Swift

             在启动swift服务进行之前,你需要对其进行配置。首先需要创建构造器文件(builder file),添加磁盘驱动器并构造环。


    3.3.1 复制swift配置文件

    创建swift目录并将源代码中的配置文件示例复制过去,以便能够在后续的配置过程中以它们作为模板来编辑配置文件。

    mkdir -p /etc/swift

    cd /opt/swift/etc

    cp account-server.conf-sample/etc/swift/account-server.conf

    cp container-server.conf-sample /etc/swift/container-server.conf

    cp object -server.conf-sample /etc/swift/ object-server.conf

    cp proxy -server.conf-sample /etc/swift/ proxy-server.conf

    cp swift -server.conf-sample /etc/swift/ swift-server.conf

    此时,可以运行swift-init命令,添加-h标志可以获取帮助信息:

    swift-init -h


    3.3.2 修改swift配置文件

    3.3.2.1 设置哈希路径前缀和后缀

    /etc/swift/swift.conf文件中swift_hash_path_prefix swift_hash_path_suffix字段设置一个随机的难以猜测的字符串。

    head -c 32 /dev/random | base64

    head -c 32 /dev/random | base64




    (用以上命令生成两个哈希串,分别设置到swift_hash_path_suffixswift_hash_path_prefix

    cd /etc/swift

    vim swift.conf

    swift_hash_path_suffix= EvjucvFN5aX1oAdjlQiw5+HV0JUqSSWwzoiem+fLAZE=

    swift_hash_path_prefix= O8wA4HPiYUpfL0TAAdDPMR2MMCzwDrsdS/qX06XXAJE=


    3.3.2.2 存储策略

    存储策略的主要作用是在集群中对存储空间进行定制化,包括:存储位置、副本数、硬件、分区,以满足特定的树存储要求。集群中至少有一个存储策略,若没有用户自定义策略,swift就会采用内置的存策略0,被称为policy-0.


    创建存储策略的分为两步:

    第一步在swift.conf文件中声明其名称和编码。

    第二步是创建对应的构造器文件和环,第二步中会用到第一步声明的编码。

    用户定义的存储策略在声明时,需要指定一个编号和一个名字。编辑/etc/swift目录下swift.conf文件,存储策略的一般格式如下:

    [storage-policy:N]

    name =

    default =

    optionaldeprecated =


    注:[storage-policy:N]是必需字段,其中N是存储策略的编号,可以取0或者一个正整数,不能重复;当存储策略不再需要时,deprecated =yes将其标记为弃用。声明了存储策略之后,就可以用它们来创建构造器了,对每一个存储策略(storage-policy:N),swift都会创建一个object-N.builder文件与之对应。


    测试集群的策略配置如下:

    [storage-policy:0]

    name = big

    default = yes

    aliases = hdd

    [storage-policy:1]

    name = small

    aliases = ssd


    3.3.2.3 设置swauth认证

    配置proxy-server.conf

    cd /etc/swift

    vim proxy-server.conf

    [pipeline:main]

    pipeline =catch_errors gatekeeper healthcheck proxy-logging cache container_sync bulktempurl ratelimit swauth copy container-quotas account-quotas slo dloversioned_writes proxy-logging proxy-server                

    #认证方式替换为swauth

    [filter:swauth]

    use =egg:swauth#swauth

    set log_name =swauth

    super_admin_key= swauthkey

    # swauthkeyswauth密钥,自行设置#

    default_swift_cluster= production#http:// 172.31.17.206:8080/v1

    #以上的IP是测试环境中任意节点主机的地址#

    allow_account_management= true

    account_autocreate= true

    #将以上两个值设为true,以允许对账户进行管理#


    3.3.3 创建环构造器文件

    构造器是用来构建环的,swift服务进程用这些环来进行数据的存储与检索。

    创建构造器文件的命令

    构造器文件可以看做是一个大数据库,里面记录了集群中所有的存储设备以及环构建器工具创建环时所用到的数值。

    swift -ring-buildercreate命令格式:

    swift-ring-builderaccount|container|object.buildecreate <part_power> <replicas> <min_part_hours>

    create命令中三个参数的作用分别为:

    part_power:分区幂指数,决定集群中要创建的分区数量。

    replicas:副本数,指定要给每份数据存储的副本数量。

    min_part_hours:移动分区的最小间隔时间(小时),指定副本能够被移动的频率。


    集群中添加构造器:

    构建account ring

    swift-ring-builder account.builder create10 2 1

    构建container ring

    swift-ring-builder container.builder create10 2 1

    构建object ring

    swift-ring-builder object.builder create 102 1

    swift-ring-builder object-0.builder create10 2 1

    swift-ring-builder object-1.builder create10 2 1


    3.3.4 向构建文件中添加磁盘

    在构建文件中添加磁盘,以及它们的逻辑分组(域、区)和权重,这部分的配置主要目的是:


    1)通过把每个节点放到一个域或区中来标记故障边界。

    2)通过设定设备权重来指定集群中的每个磁盘应当存多少数据。

    对于每个节点,需要把/srv/node下的存储磁盘加到构造文件中。如果某一磁盘是专门用于来存储特定的数据类型的,可以不把他添加到其他的环构建中。固态硬盘负责所有的账号和容器数据,需要你把这些固态硬盘添加到账号和容器的构造文件中。

    用如下格式将磁盘添加到文件中:

    swift-ring-builder account.builder add<region><zone>-<IP>:<port>/<device> <weight>

    swift-ring-builder container.builder add <region><zone>-<IP>:<port>/<device><weight>

    swift-ring-builder object.builder add <region><zone>-<IP>:<port>/<device><weight>

    swift-ring-builder object-n.builder add<region><zone>-<IP>:<port>/<device><weight>


    具体讲解下regionzoneweight的含义:

    Regionswift允许集群按物理位置来划分域。域通常被定义为地理边界,服务器(节点)的几个机架可以用放置在彼此延迟比较高,地理位置相隔较远的不同位置;当跨域集群收到一个读请求时,swift将通过延迟来选择更近的数据副本。

    Zones:在域中,swift允许你创建可用区来隔离故障。分区的目的是为了防止存储服务器大规模中断运行。

    IP:指定节点所在的IP地址;

    Port:每个账号、容器和对象服务进程在不同的端口运行。账号服务进程默认运行在6002端口,容器服务进程默认运行在6001端口,对象服务进程默认运行在6000端口。

    Weight(权重):权重是用来决定一个磁盘到底可以拥有多少分区(相对值)的,它是环构建过程的一部分,权重是一个相对数,可自行配置每个硬盘的权重。


    swift01节点上执行,向环中添加磁盘

    cd /etc/swift/

    account.builder中添加ssd01

    swift-ring-builder account.builder addr1z1-172.31.17.206:6202/ssd01 1600

    swift-ring-builder account.builder addr1z2-172.31.17.207:6202/ssd01 1600

    swift-ring-builder account.builder addr1z3-172.31.17.208:6202/ssd01 1600

    container.builder中添加ssd01

    swift-ring-builder container.builder addr1z1-172.31.17.206:6201/ssd01 1600

    swift-ring-builder container.builder addr1z2-172.31.17.207:6201/ssd01 1600

    swift-ring-builder container.builder addr1z3-172.31.17.208:6201/ssd01 1600

    object.builder中添加ssd01

    swift-ring-builder object.builder add r1z1-172.31.17.206:6200/ssd011600

    swift-ring-builder object.builder add r1z2-172.31.17.207:6200/ssd011600

    swift-ring-builder object.builder add r1z3-172.31.17.208:6200/ssd011600

    object-0.builder中添加hdd01

    swift-ring-builder object-0.builder addr1z1-172.31.17.206:6200/hdd01 1600

    swift-ring-builder object-0.builder addr1z2-172.31.17.207:6200/hdd01 1600

    swift-ring-builder object-0.builder addr1z3-172.31.17.208:6200/hdd01 1600

    object-1.builder中添加ssd01

    swift-ring-builder object-1.builder addr1z1-172.31.17.206:6200/ssd01 1600

    swift-ring-builder object-1.builder addr1z2-172.31.17.207:6200/ssd01 1600

    swift-ring-builder object-1.builder addr1z3-172.31.17.208:6200/ssd01 1600




    3.3.5 构建环

    硬盘添加完毕,就可以创建环文件了。利用rebalance命令来创建环文件,swift利用环文件来决定数据存储的位置。环创建好了以后,它们需要被复制到集群中每个节点的/etc/swift目录下。复制以后不需要任务操作,因swift15分钟检测一次环文件。


    • 构建环

    cd /etc/swift

    swift-ring-builder account.builderrebalance

    swift-ring-builder container.builderrebalance

    swift-ring-builder object.builder rebalance




    检查是否成功构建ring

    ll ./*.gz




    2)同步ring到集群中其他节点

    scp *.ring.gz 172.31.17.207:/etc/swift

    scp *.ring.gz 172.31.17.208:/etc/swift


    3.3.6 配置swift日志

    Swift使用RSyslog来帮它管理日志,在每个配置文件中有一个叫log_name的设置项,默认被设置为swift

    创建日志配置文件:

    mkdir /var/log/swift

    cd /etc/rsyslog.d

    cp openstack-swift.confopenstack-swift.conf.bak

    systemctl enable rsyslog.service;

    systemctl restart rsyslog.service;


    3.3.7 配置Rsync

    Swift集群需要很多一致性进程运行以确保集群正常工作。这部分包括:

    1)配置及启动rsync

    2)启动复制器进程

    3)启动其他的一致性进程


    配置rsync

    cd /etc

    cp rsyncd.conf rsyncd.conf.bak

    systemctl enable rsyncd.service

    systemctl restart rsyncd.service


    3.3.8 配置目录权限

    chown -R root:swift /etc/swift

    chown -R root:swift /srv/node

    chown -R swift:swift /var/cache/swift

    chown -R root:root /var/log/swift

    chmod -R g+w /etc/swift

    chmod -R g+w /srv/node

    chmod -R g+w /var/cache/swift

    chmod -R g+w /var/log/swift


    3.4 Swift服务管理

    3.4.1 配置开机自启动

    systemctl enable memcached.serviceopenstack-swift-proxy.service

    systemctl enableopenstack-swift-account.service openstack-swift-account-auditor.serviceopenstack-swift-account-reaper.serviceopenstack-swift-account-replicator.service

    systemctl enableopenstack-swift-container.service openstack-swift-container-auditor.serviceopenstack-swift-container-replicator.serviceopenstack-swift-container-updater.service

    systemctl enableopenstack-swift-object.service openstack-swift-object-auditor.serviceopenstack-swift-object-replicator.serviceopenstack-swift-object-updater.service


    3.4.2 启动所有服务

    systemctl restart memcached.serviceopenstack-swift-proxy.service

    systemctl restart  openstack-swift-account.service openstack-swift-account-auditor.serviceopenstack-swift-account-reaper.serviceopenstack-swift-account-replicator.service

    systemctl restart  openstack-swift-container.serviceopenstack-swift-container-auditor.serviceopenstack-swift-container-replicator.serviceopenstack-swift-container-updater.service

    systemctl restart  openstack-swift-object.serviceopenstack-swift-object-auditor.serviceopenstack-swift-object-replicator.serviceopenstack-swift-object-updater.service


    3.4.3 查看服务状态

    systemctl status memcached.serviceopenstack-swift-proxy.service

    systemctl status  openstack-swift-account.serviceopenstack-swift-account-auditor.service openstack-swift-account-reaper.serviceopenstack-swift-account-replicator.service

    systemctl status  openstack-swift-container.serviceopenstack-swift-container-auditor.serviceopenstack-swift-container-replicator.serviceopenstack-swift-container-updater.service

    systemctl status  openstack-swift-object.serviceopenstack-swift-object-auditor.service openstack-swift-object-replicator.serviceopenstack-swift-object-updater.service


    3.5 Swift验证服务

    3.5.1 创建用户

    swauth-prep -K swauthkey

    swift -Ahttp://172.31.17.206:8080/auth/v1.0 -U test:tester -K testing stat –v




    3.5.2 验证接口

    用户tester认证:

    curl -v -H 'X-Auth-User: test:tester' -H'X-Auth-Key: testing' http://172.31.17.206:8080/auth/v1.0


    展开全文
  • Intel开源了一个swift性能测试工具COSBanch。今天花了一点时间尝试了一下,感觉效果还不错。源码在github上可以很容易找到,user-guide也很比较详细,安装过程没有碰到麻烦。最终测试了一下本地的一套环境结果如下...

    Intel开源了一个swift的性能测试工具COSBanch。今天花了一点时间尝试了一下,感觉效果还不错。源码在github上可以很容易找到,user-guide也很比较详细,安装过程没有碰到麻烦。最终测试了一下本地的一套环境结果如下:



    结果简单分析:

    我测试的swift环境下安装了1台proxy和1台storage,用1Gbit网络连接。测试时读写比例是80%和20%,总throughput大约111.12ops (88.83+22.29)。由于测试的是小文件,网络显然并不是瓶颈。1台storage上会写3份。估计性能瓶颈是storage的磁盘IO上。95%-RT也要100ms-160ms延时还是偏大的。


    总的来说,这个工具还是不错的。至少可以作为一个基准,为swift性能调优有很多帮助。 Thanks for the open source.

    明天继续倒腾看看。

    展开全文
  • 对象存储Swift介绍

    2013-09-09 16:38:45
    OpenStack Object Storage(Swift)是OpenStack开源云计算项目的子项目之一,被称为对象存储,提供了强大的扩展性、冗余和持久性。本文将从架构、原理和实践等几方面讲述SwiftSwift并不是文件系统或者实时的数据...

    OpenStack Object Storage(Swift)是OpenStack开源云计算项目的子项目之一,被称为对象存储,提供了强大的扩展性、冗余和持久性。本文将从架构、原理和实践等几方面讲述Swift。 Swift并不是文件系统或者实时的数据存储系统,它称为对象存储,用于永久类型的静态数据的长期存储,这些数据可以检索、调整,必要时进行更新。最适合存储的数据类型的例子是虚拟机镜像、图片存储、邮件存储和存档备份。因为没有中心单元或主控结点,Swift提供了更强的扩展性、冗余和持久性。Swift前身是Rackspace Cloud Files项目,随着Rackspace加入到OpenStack社区,于2010年7月贡献给OpenStack,作为该开源项目的一部分。Swift目前的最新版本是OpenStack Essex 1.5.1。


    Swift功能

     Swift提供的服务与AWS S3相同,可以用以下用途:

         •作为IaaS的存储服务
                •与OpenStack Compute对接,为其存储镜像
                •文档存储
                •存储需要长期保存的数据,例如log
                •存储网站的图片,缩略图等
                Swift使用RESTful API对外提供服务,目前 1.4.6版本所提供的功能: •Account(存储账户)的GET、HEAD
                •Container(存储容器,与S3的bucket相同)的GET、PUT、HEAD、DELETE
                •Object(存储对象)的GET、PUT、HEAD、DELETE、DELETE
                •Account、Container、Object的元数据支持
                •大文件(无上限,单个无文件最大5G,大于5G的文件在客户端切分上传,并上传manifest文件)、
                •访问控制、权限控制
                •临时对象存储(过期对象自动删除)
                •存储请求速率限制
                •临时链接(让任何用户访问对象,不需要使用Token)
                •表单提交(直接从HTML表单上传文件到Swift存储,依赖与临时链接)
                •静态WEB站点(用Swift作为静态站点的WEB服务器)

    Swift特性

    在OpenStack官网中,列举了Swift的20多个特性,其中最引人关注的是以下几点。

    极高的数据持久性

    一些朋友经常将数据持久性(Durability)与系统可用性(Availability)两个概念混淆,前者也理解为数据的可靠性,是指数据存储到系统中后,到某一天数据丢失的可能性。例如Amazon S3的数据持久性是11个9,即如果存储1万(4个0)个文件到S3中,1千万(7个0)年之后,可能会丢失其中1个文件。那么Swift能提供多少个9的SLA呢?下文会给出答案。针对Swift在新浪测试环境中的部署,我们从理论上测算过,Swift在5个Zone、5×10个存储节点的环境下,数据复制份是为3,数据持久性的SLA能达到10个9。

    完全对称的系统架构

    “对称”意味着Swift中各节点可以完全对等,能极大地降低系统维护成本。

    无限的可扩展性

    这里的扩展性分两方面,一是数据存储容量无限可扩展;二是Swift性能(如QPS、吞吐量等)可线性提升。因为Swift是完全对称的架构,扩容只需简单地新增机器,系统会自动完成数据迁移等工作,使各存储节点重新达到平衡状态。

    无单点故障

    在互联网业务大规模应用的场景中,存储的单点一直是个难题。例如数据库,一般的HA方法只能做主从,并且“主”一般只有一个;还有一些其他开源存储系统的实现中,元数据信息的存储一直以来是个头痛的地方,一般只能单点存储,而这个单点很容易成为瓶颈,并且一旦这个点出现差异,往往能影响到整个集群,典型的如HDFS。而Swift的元数据存储是完全均匀随机分布的,并且与对象文件存储一样,元数据也会存储多份。整个Swift集群中,也没有一个角色是单点的,并且在架构和设计上保证无单点业务是有效的。

    简单、可依赖

    简单体现在架构优美、代码整洁、实现易懂,没有用到一些高深的分布式存储理论,而是很简单的原则。可依赖是指Swift经测试、分析之后,可以放心大胆地将Swift用于最核心的存储业务上,而不用担心Swift捅篓子,因为不管出现任何问题,都能通过日志、阅读代码迅速解决。

    Swift架构概述

    Swift主要有三个组成部分:Proxy Server、Storage Server和Consistency Server。其架构如图1所示,其中Storage和Consistency服务均允许在Storage Node上。Auth认证服务目前已从Swift中剥离出来,使用OpenStack的认证服务Keystone,目的在于实现统一OpenStack各个项目间的认证管理。

    主要组件

    Proxy Server

    Proxy Server是提供Swift API的服务器进程,负责Swift其余组件间的相互通信。对于每个客户端的请求,它将在Ring中查询Account、Container或Object的位置,并且相应地转发请求。Proxy提供了Rest-full API,并且符合标准的HTTP协议规范,这使得开发者可以快捷构建定制的Client与Swift交互。

    Storage Server

    Storage Server提供了磁盘设备上的存储服务。在Swift中有三类存储服务器:Account、Container和Object。其中Container服务器负责处理Object的列表,Container服务器并不知道对象存放位置,只知道指定Container里存的哪些Object。这些Object信息以sqlite数据库文件的形式存储。Container服务器也做一些跟踪统计,例如Object的总数、Container的使用情况。

    Consistency Servers

    在磁盘上存储数据并向外提供Rest-ful API并不是难以解决的问题,最主要的问题在于故障处理。Swift的Consistency Servers的目的是查找并解决由数据损坏和硬件故障引起的错误。主要存在三个Server:Auditor、Updater和Replicator。 Auditor运行在每个Swift服务器的后台持续地扫描磁盘来检测对象、Container和账号的完整性。如果发现数据损坏,Auditor就会将该文件移动到隔离区域,然后由Replicator负责用一个完好的拷贝来替代该数据。图2给出了隔离对象的处理流图。 在系统高负荷或者发生故障的情况下,Container或账号中的数据不会被立即更新。如果更新失败,该次更新在本地文件系统上会被加入队列,然后Updaters会继续处理这些失败了的更新工作,其中由Account Updater和Container Updater分别负责Account和Object列表的更新。 Replicator的功能是处理数据的存放位置是否正确并且保持数据的合理拷贝数,它的设计目的是Swift服务器在面临如网络中断或者驱动器故障等临时性故障情况时可以保持系统的一致性。

    Instructions for a Multiple Server Swift Installation (Ubuntu)

    Prerequisites

    • Ubuntu Server 10.04 LTS installation media

    Basic architecture and terms

    • node - a host machine running one or more Swift services
    • Proxy node - node that runs Proxy services; also runs TempAuth
    • Storage node - node that runs Account, Container, and Object services
    • ring - a set of mappings of Swift data to physical devices

    This document shows a cluster using the following types of nodes:

    • one Proxy node
      • Runs the swift-proxy-server processes which proxy requests to the appropriate Storage nodes. The proxy server will also contain the Temp Auth service as WSGI middleware.
    • five Storage nodes
      • Runs the swift-account-server, swift-container-server, and swift-object-server processes which control storage of the account databases, the container databases, as well as the actual stored objects.

    Network Setup Notes

    This document refers to two networks. An external network for connecting to the Proxy server, and a storage network that is not accessibile from outside the cluster, to which all of the nodes are connected. All of the Swift services, as well as the rsync daemon on the Storage nodes are configured to listen on their STORAGE_LOCAL_NET IP addresses.

    General OS configuration and partitioning for each node

    1. Install the baseline Ubuntu Server 10.04 LTS on all nodes.

    2. Install common Swift software prereqs:

      apt-get install python-software-properties
      add-apt-repository ppa:swift-core/release
      apt-get update
      apt-get install swift python-swiftclient openssh-server
    3. Create and populate configuration directories:

      mkdir -p /etc/swift
      chown -R swift:swift /etc/swift/
    4. On the first node only, create /etc/swift/swift.conf:

      cat >/etc/swift/swift.conf <<EOF
      [swift-hash]
      # random unique strings that can never change (DO NOT LOSE)
      swift_hash_path_prefix = `od -t x8 -N 8 -A n </dev/random`
      swift_hash_path_suffix = `od -t x8 -N 8 -A n </dev/random`
      EOF
    5. On the second and subsequent nodes: Copy that file over. It must be the same on every node in the cluster!:

      scp firstnode.example.com:/etc/swift/swift.conf /etc/swift/
    6. Publish the local network IP address for use by scripts found later in this documentation:

      export STORAGE_LOCAL_NET_IP=10.1.2.3
      export PROXY_LOCAL_NET_IP=10.1.2.4
    7. Create directory /var/run/swift and change the ownership to the user and groupwhich Swift services will run under. Since the directory is only needed for runtime,when system shuts down, the directory will be gone. It is necessary to havethe directory recreated when system is restarted. To do that, also add thefollowing lines into /etc/rc.local before line “exit 0”.:

      mkdir -p /var/run/swift
      chown swift:swift /var/run/swift
    8. Create directory /var/cache/swift and /srv/node. Change the ownership of thedirectory /var/cache/swift to the user and group which Swift account, containeror object services will run under. These directories are needed only for storagenode (account, container or object server). The ownership of /srv/node shouldbe root:root, this is to ensure that when storage disks unmounted unexpectedly,the objects for swift will not be created in the directory /srv/node. If you havea node only runs proxy server, you can skip this step.:

      mkdir -p /var/cache/swift /srv/node/
      chown swift:swift /var/cache/swift

    Configure the Proxy node

    Note

    It is assumed that all commands are run as the root user

    1. Install swift-proxy service:

      apt-get install swift-proxy memcached
    2. Create self-signed cert for SSL:

      cd /etc/swift
      openssl req -new -x509 -nodes -out cert.crt -keyout cert.key

    Note

    If you don’t create the cert files, Swift silently uses http internally rather than https. This document assumes that you have createdthese certs, so if you’re following along step-by-step, create them. In aproduction cluster, you should terminate SSL before the proxy server. SSLsupport is provided for testing purposes only.

    1. Modify memcached to listen on the default interfaces. Preferably this should be on a local, non-public network. Edit the IP address in /etc/memcached.conf, for example:

      perl -pi -e "s/-l 127.0.0.1/-l $PROXY_LOCAL_NET_IP/" /etc/memcached.conf
    2. Restart the memcached server:

      service memcached restart
    3. Create /etc/swift/proxy-server.conf:

      cat >/etc/swift/proxy-server.conf <<EOF
      [DEFAULT]
      cert_file = /etc/swift/cert.crt
      key_file = /etc/swift/cert.key
      bind_port = 8080
      workers = 8
      user = swift
      
      [pipeline:main]
      pipeline = healthcheck proxy-logging cache tempauth proxy-logging proxy-server
      
      [app:proxy-server]
      use = egg:swift#proxy
      allow_account_management = true
      account_autocreate = true
      
      [filter:proxy-logging]
      use = egg:swift#proxy_logging
      
      [filter:tempauth]
      use = egg:swift#tempauth
      user_system_root = testpass .admin https://$PROXY_LOCAL_NET_IP:8080/v1/AUTH_system
      
      [filter:healthcheck]
      use = egg:swift#healthcheck
      
      [filter:cache]
      use = egg:swift#memcache
      memcache_servers = $PROXY_LOCAL_NET_IP:11211
      EOF

      Note

      If you run multiple memcache servers, put the multiple IP:port listingsin the [filter:cache] section of the proxy-server.conf file like:10.1.2.3:11211,10.1.2.4:11211. Only the proxy server uses memcache.

    4. Create the account, container and object rings. The builder command is basically creating a builder file with a few parameters. The parameter with the value of 18 represents 2 ^ 18th, the value that the partition will be sized to. Set this “partition power” value based on the total amount of storage you expect your entire ring to use. The value of 3 represents the number of replicas of each object, with the last value being the number of hours to restrict moving a partition more than once.

      cd /etc/swift
      swift-ring-builder account.builder create 18 3 1
      swift-ring-builder container.builder create 18 3 1
      swift-ring-builder object.builder create 18 3 1

      Note

      For more information on building rings, see The Rings.

    5. For every storage device in /srv/node on each node add entries to each ring:

      export ZONE=                    # set the zone number for that storage device
      export STORAGE_LOCAL_NET_IP=    # and the IP address
      export WEIGHT=100               # relative weight (higher for bigger/faster disks)
      export DEVICE=sdb1
      swift-ring-builder account.builder add z$ZONE-$STORAGE_LOCAL_NET_IP:6002/$DEVICE $WEIGHT
      swift-ring-builder container.builder add z$ZONE-$STORAGE_LOCAL_NET_IP:6001/$DEVICE $WEIGHT
      swift-ring-builder object.builder add z$ZONE-$STORAGE_LOCAL_NET_IP:6000/$DEVICE $WEIGHT

      Note

      Assuming there are 5 zones with 1 node per zone, ZONE should start at1 and increment by one for each additional node.

    6. Verify the ring contents for each ring:

      swift-ring-builder account.builder
      swift-ring-builder container.builder
      swift-ring-builder object.builder
    7. Rebalance the rings:

      swift-ring-builder account.builder rebalance
      swift-ring-builder container.builder rebalance
      swift-ring-builder object.builder rebalance

      Note

      Rebalancing rings can take some time.

    8. Copy the account.ring.gz, container.ring.gz, and object.ring.gz filesto each of the Proxy and Storage nodes in /etc/swift.

    9. Make sure all the config files are owned by the swift user:

      chown -R swift:swift /etc/swift
    10. Start Proxy services:

      swift-init proxy start

    Configure the Storage nodes

    Note

    Swift should work on any modern filesystem that supportsExtended Attributes (XATTRS). We currently recommend XFS as itdemonstrated the best overall performance for the swift use case afterconsiderable testing and benchmarking at Rackspace. It is also theonly filesystem that has been thoroughly tested. These instructionsassume that you are going to devote /dev/sdb1 to an XFS filesystem.

    1. Install Storage node packages:

      apt-get install swift-account swift-container swift-object xfsprogs
    2. For every device on the node, setup the XFS volume (/dev/sdb is usedas an example), add mounting option inode64 when your disk is bigger than1TB to archive a better performance.:

      fdisk /dev/sdb  (set up a single partition)
      mkfs.xfs -i size=512 /dev/sdb1
      echo "/dev/sdb1 /srv/node/sdb1 xfs noatime,nodiratime,nobarrier,logbufs=8 0 0" >> /etc/fstab
      mkdir -p /srv/node/sdb1
      mount /srv/node/sdb1
      chown swift:swift /srv/node/sdb1
    3. Create /etc/rsyncd.conf:

      cat >/etc/rsyncd.conf <<EOF
      uid = swift
      gid = swift
      log file = /var/log/rsyncd.log
      pid file = /var/run/rsyncd.pid
      address = $STORAGE_LOCAL_NET_IP
      
      [account]
      max connections = 2
      path = /srv/node/
      read only = false
      lock file = /var/lock/account.lock
      
      [container]
      max connections = 2
      path = /srv/node/
      read only = false
      lock file = /var/lock/container.lock
      
      [object]
      max connections = 2
      path = /srv/node/
      read only = false
      lock file = /var/lock/object.lock
      EOF
    4. Edit the RSYNC_ENABLE= line in /etc/default/rsync:

      perl -pi -e 's/RSYNC_ENABLE=false/RSYNC_ENABLE=true/' /etc/default/rsync
    5. Start rsync daemon:

      service rsync start

      Note

      The rsync daemon requires no authentication, so it should be run ona local, private network.

    6. Create /etc/swift/account-server.conf:

      cat >/etc/swift/account-server.conf <<EOF
      [DEFAULT]
      bind_ip = $STORAGE_LOCAL_NET_IP
      workers = 2
      
      [pipeline:main]
      pipeline = account-server
      
      [app:account-server]
      use = egg:swift#account
      
      [account-replicator]
      
      [account-auditor]
      
      [account-reaper]
      EOF
    7. Create /etc/swift/container-server.conf:

      cat >/etc/swift/container-server.conf <<EOF
      [DEFAULT]
      bind_ip = $STORAGE_LOCAL_NET_IP
      workers = 2
      
      [pipeline:main]
      pipeline = container-server
      
      [app:container-server]
      use = egg:swift#container
      
      [container-replicator]
      
      [container-updater]
      
      [container-auditor]
      
      [container-sync]
      EOF
    8. Create /etc/swift/object-server.conf:

      cat >/etc/swift/object-server.conf <<EOF
      [DEFAULT]
      bind_ip = $STORAGE_LOCAL_NET_IP
      workers = 2
      
      [pipeline:main]
      pipeline = object-server
      
      [app:object-server]
      use = egg:swift#object
      
      [object-replicator]
      
      [object-updater]
      
      [object-auditor]
      EOF
    9. Start the storage services. If you use this command, it will try to startevery service for which a configuration file exists, and throw a warningfor any configuration files which don’t exist:

      swift-init all start

      Or, if you want to start them one at a time, run them as below.Note that if the server program in question generates any output on itsstdout or stderr, swift-init has already redirected the command’s outputto /dev/null. If you encounter any difficulty, stop the server and run itby hand from the command line. Any server may be started using“swift-$SERVER-$SERVICE /etc/swift/$SERVER-config”, where $SERVER mightbe object, continer, or account, and $SERVICE might be server,replicator, updater, or auditor.

      swift-init object-server start
      swift-init object-replicator start
      swift-init object-updater start
      swift-init object-auditor start
      swift-init container-server start
      swift-init container-replicator start
      swift-init container-updater start
      swift-init container-auditor start
      swift-init account-server start
      swift-init account-replicator start
      swift-init account-auditor start

    Create Swift admin account and test

    You run these commands from the Proxy node.

    1. Get an X-Storage-Url and X-Auth-Token:

      curl -k -v -H 'X-Storage-User: system:root' -H 'X-Storage-Pass: testpass' https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0
    2. Check that you can HEAD the account:

      curl -k -v -H 'X-Auth-Token: <token-from-x-auth-token-above>' <url-from-x-storage-url-above>
    3. Check that swift works (at this point, expect zero containers, zero objects, and zero bytes):

      swift -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass stat
    4. Use swift to upload a few files named ‘bigfile[1-2].tgz’ to a container named ‘myfiles’:

      swift -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass upload myfiles bigfile1.tgz
      swift -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass upload myfiles bigfile2.tgz
    5. Use swift to download all files from the ‘myfiles’ container:

      swift -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass download myfiles
    6. Use swift to save a backup of your builder files to a container named ‘builders’. Very important not to lose your builders!:

      swift -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass upload builders /etc/swift/*.builder
    7. Use swift to list your containers:

      swift -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass list
    8. Use swift to list the contents of your ‘builders’ container:

      swift -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass list builders
    9. Use swift to download all files from the ‘builders’ container:

      swift -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass download builders

    展开全文
  • swift是基于RESTFul设计的分布式对象存储系统,其工作原理类似于一个web服务器。当上层大量的访问或者上传数据时其会产生大量的http链接,每一个链接 都会消耗掉一个系统的端口(系统中默认最多有65536个端口,因此...
  • 本片文章详细介绍了OpenStack中对象存储swift的安装配置过程,并描述了遇到的问题及及解决方法。
  • 通过源码运行Swift

    2018-03-14 13:51:53
    通过源码运行Swift作者:张华 发表于:2012-4-8版权声明:可以任意转载,转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明( http://blog.csdn.net/quqi9...
  • 1.你认为cinder与swift区别是什么? 2.cinder是否存在单点故障? 3.cinder是如何发展而来的? 在openstack中,我们经常遇到这么个问题,cinder与swift的区别是什么? cinder与swift各自的用途是什么?
  • 在前阶段的工作中,对于OpenStack整体部署已经日渐熟练。可以较快速地在多台节点环境下,安装部署小型云环境,并测试使用。 通过该阶段的学习,对于虚拟实例的使用,归纳了很多心得,对于实例的存储,由于理论...
  • OpenStack Swift学习笔记

    2014-01-10 10:31:10
    OpenStack Object Storage(Swift)是OpenStack开源云计算项目的子项目之一。Swift的目的是使用普通硬件来构建冗余的、可扩展的分布式对象存储集群,存储容量可达PB级。 Swift并不是文件系统或者实时的数据存储系统...
  • Swift

    2018-10-30 14:59:57
    1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...OpenStack Object Storage(Swift)是...Swift并不是文件系统或者实时的数据存储系统,它是对象存储,用于永久类型的静态数据的长期存储,这些数据可以检索、...
  • 本系列文章着重学习和研究OpenStack Swift,包括环境搭建、原理、架构、监控和性能等。 (1)OpenStack + 三节点Swift 集群+ HAProxy + UCARP 安装和配置 (2)原理、架构和性能 (3)监控 对 Swift 集群的监控是...
  • 之前看了很多关于 Swift 派发机制的内容, 但感觉没有一篇能够彻底讲清楚这件事情, 看完了这篇文章之后我对 Swift 的派发机制才建立起了初步的认知. 正文 一张表总结引用类型, 修饰符和它们对于 Swift 函数...
  • Swift简介

    2018-05-23 20:51:35
    Swift可以解决什么问题1.数据持久性:用户数据存储到系统中丢失的可能性。为了防止数据丢失,Swift采用了冗余Replica(副本)的处理方法。Replica的默认值是3.2.对称性是指Swift架构设计上,每个服务器的功能和作用...
  • Swift简介(转)

    2013-11-19 16:53:44
    转自:...   0.术语约定.................................................................................................................... 3   1
  • 之前介绍了《OpenStack Swift All In One安装部署流程与简单使用》,那么接下来就说一说Swift集群部署吧。 1. 简介 本文档详细描述了使用两台... 每台机器都运行Swift的所有服务,既是Proxy Server,又是Storage Serve
  • 每个服务都需要做的如下: 配置服务的时候,步骤如下: 创建服务同名的用户(除了keystone),添加到services... 更新数据库(除了swift)   swift是用不到上面的数据库的。   安装swift软件包     M...
  • 本文简单讲述如何使用Ganglia监控Openstack Swift的状态
1 2 3 4 5 ... 20
收藏数 1,014
精华内容 405
热门标签