对象存储中的swift_swift对象存储 - CSDN
  • 首先简单了解一下一些ceph对象存储的基本知识: Ceph: 起始于2006年 开发语言:C 强一致性 块存储 对象存储 Swift: 起始于2008年 开发语言:Python 最终一致性 对象存储 真正的大型公用云服务产品...

    首先简单了解一下一些ceph对象存储的基本知识:
    Ceph:
    起始于2006年
    开发语言:C
    强一致性
    块存储
    对象存储
    Swift:

    起始于2008年
    开发语言:Python
    最终一致性
    对象存储
    真正的大型公用云服务产品中使用

    对象存储介绍:

    Ceph本质上就是一个rados,利用命令rados就可以访问和使用ceph的对象存储,但作为一个真正产品机的对象存储服务,通常使用的是Restfulapi的方式进行访问和使用。而radosgw其实就是这个作用,安装完radosgw以后,就可以使用api来访问和使用ceph的对象存储服务了。
    本质上radosgw(其实也是一个命令)和rbd命令一样,其实是ceph集群的客户端。只不过,radosgw即作为rados的客户端,同时又提供http restful接口,作为服务端供用户使用。

    首先明白一下架构,radosgw其实名副其实,就是rados的一个网关,作用是对外提供对象存储服务。本质上radosgw(其实也是一个命令)和rbd命令一样,其实是ceph集群的客户端。只不过,radosgw即作为rados的客户端,同时又提供http restful接口,作为服务端供用户使用。Radosgw对用户而言就是一个http restful的应用,因此本质上来讲,对其进行使用就是通过http的方式,但显然每次都要用户构建http访问的url和headers不是一个很方便的方式,因此radosgw兼容了通用的对象存储接口,分别是亚马逊的s3和openstack的swift,这也就是说你可以用swift或者s3的客户端来访问radosgw。
    Radosgw包含两个命令行工具:
    一个是radosgw,这个是用来启动radosgw服务的脚本,是一个二进制文件;
    另外一个是radosgw-admin,这是用来管理radosgw的账号的一个命令行工具,主要用来创建、查看、修改radosgw的账号信息。

    注意,ragw的账号信息仅仅是对radosgw的用户而言,这个和ceph中的用户不是一个概念。
    Radosgw作为ceph集群(rados)的客户端,因此他在ceph中有一个账号,通常叫做client.radosgw.gateway。在启动radosgw这个服务时,会读取ceph.conf中[client.radosgw.gateway]这个section。

    开始操作:Ceph 对象存储服务提供了 REST 风格的 API ,它有与 Amazon S3 和 OpenStack Swift 兼容的接口。也就是通常意义的键值存储,其接口就是简单的GET、PUT、DEL和其他扩展;Ceph 对象存储可以简称为 RGW,Ceph RGW 是基于 librados,为应用提供 RESTful 类型的对象存储接口,其接口方式支持 S3(兼容 Amazon S3 RESTful API) 和 Swift(兼容 OpenStack Swift API) 两种类型。接下来就分别演示通过这两种方式使用 Ceph RGW。

    接下来就是我实际的配置操作:

    Ceph 对象存储可以简称为 RGW,Ceph RGW 是基于 librados,为应用提供 RESTful 类型的对象存储接口,其接口方式支持 S3(兼容 Amazon S3 RESTful API) 和 Swift(兼容 OpenStack Swift API) 两种类型。接着之前的文章,还是在之前搭建的ceph集群基础上操作。接下来就分别演示通过这两种方式使用 Ceph RGW。

    1、首先需要安装 Ceph 对象网关。
    Ceph 从 v0.80 开始,使用内嵌 Civetweb 作为 Web Server,无需额外安装 web 服务器或配置 FastCGI,其默认端口为 7480。在 mon节点目录通过 ceph-deploy 安装 Ceph RGW。一般是在管理节点下,但是搭建的ceph集群没有管理节点,所以就在mon节点下面,在这里我们还是使用 node1 节点(也就是我的mon节点)做测试。
    首先进入到mon节点的my-cluster目录下面,然后执行下面命令:
    $ ceph-deploy install –rgw node1
    2、新建 Ceph 对象网关实例
    在 mon节点工作目录创建一个 Ceph rgw 实例,一旦对象网关开始运行,我们就可以通过 http://node1:7480 地址访问啦。
    $ ceph-deploy –overwrite-conf rgw create node1
    [ceph_deploy.conf][DEBUG ] found configuration file at:
    …….
    省略
    …….
    [ceph_deploy.rgw][INFO ] The Ceph Object Gateway (RGW) is now running on host admin and default port 7480

    从日志中可以看到 RGW 已经运行起来了,我们来访问以下试下。
    $ curl http://node1:7480

    #!/usr/bin/pyhton
    import boto
    import boto.s3.connection
    access_key = 'OHP5X3XQSC1IOWQUYDNT'
    secret_key = 'BqiUlhfWGvsz30FVCjzUhPesGH4NDa69joNHEYep'
    conn = boto.connect_s3(
                aws_access_key_id = access_key,
                    aws_secret_access_key = secret_key,
                        host = '192.168.1.220', port=80,
                            is_secure=False,
                                calling_format = boto.s3.connection.OrdinaryCallingFormat(),
                                )
    bucket = conn.create_bucket('my-first-s3-bucket')
    for bucket in conn.get_all_buckets():
                print "{name}\t{created}".format(
                                        name = bucket.name,
                                                        created = bucket.creation_date,)
    

    “`

    注意:这里使用了python-boto 包,使用认证信息连接 S3,然后创建了一个 my-first-s3-bucket 的 bucket,最后列出所有已创建的 bucket,打印名称和创建时间。
    最后,执行脚本,看下结果是否正确。
    lxl@lxl-virtual-machine:~$ python s3.py
    my-first-s3-bucket 2018-03-04T08:17:40.921Z
    测试通过。

    我们可以看一下:

    注意:default.rgw.data.root。它包含bucekt和bucket元数据,bucket创建了两个对象一个:一个是< bucket_name > 另一个是.bucket.meta.< bucket_name >.< marker > 这个marker是创建bucket中生成的。 同时用户创建的buckets在.rgw.buckets.index都对应一个object对象,其命名是格式:.dir.< marker >
    然后查看:
    [root@node1 ~]# rados -p default.rgw.data.root ls
    .bucket.meta.my-first-s3-bucket:9ad5259a-77d7-4407-99b0-562c217cdb87.24101.1
    my-first-s3-bucket
    可以看到创建了my-first-s3-bucket

    创建 Swift 用户
    要通过 Swift 访问对象网关,需要 Swift 用户是作为子用户 subuser 被创建的。
    $ sudo radosgw-admin subuser create –uid=rgwuser –subuser=rgwuser:swift –access=full
    {
    “user_id”: “rgwuser”,
    “display_name”: “This is first rgw test user”,
    “email”: “”,
    “suspended”: 0,
    “max_buckets”: 1000,
    “auid”: 0,
    “subusers”: [
    {
    “id”: “rgwuser:swift”,
    “permissions”: “full-control”
    }
    ],
    “keys”: [
    {
    “user”: “rgwuser”,
    “access_key”: “OHP5X3XQSC1IOWQUYDNT”,
    “secret_key”: “BqiUlhfWGvsz30FVCjzUhPesGH4NDa69joNHEYep”
    }
    ],
    “swift_keys”: [
    {
    “user”: “rgwuser:swift”,
    “secret_key”: “twTTtZ8pCVENvXJUbxfNj0lPogwaCWHdDRQpM9DK”
    }
    ],
    “caps”: [],
    “op_mask”: “read, write, delete”,
    “default_placement”: “”,
    “placement_tags”: [],
    “bucket_quota”: {
    “enabled”: false,
    “max_size_kb”: -1,
    “max_objects”: -1
    },
    “user_quota”: {
    “enabled”: false,
    “max_size_kb”: -1,
    “max_objects”: -1
    },
    “temp_url_keys”: []
    }

    注意:返回的 Json 值中,我们要记住两个 secret_key 因为下边我们测试访问 Swift 接口时需要使用。
    测试访问 Swift 接口
    访问 Swift 接口可以通过 swift 命令行客户端来完成,然后通过客户端命令访问 Swift 接口。
    # 安装 Swift 命令行客户端
    sudoaptgetinstallpythonsetuptoolssudoapt−getinstallpython−setuptools sudo easy_install pip
    sudopipinstallupgradesetuptoolssudopipinstall–upgradesetuptools sudo pip install –upgrade python-swiftclient
    # 访问 Swift 接口
    $ swift -A http://192.168.1.220:80/auth/1.0 -U rgwuser:swift -K ‘twTTtZ8pCVENvXJUbxfNj0lPogwaCWHdDRQpM9D\’ list my-first-s3-bucket
    注意:192.168.1.220:80为网关服务器的外网访问 IP 地址,这里为mon节点 IP,端口默认 7480,因为上面已修改端口号,这里也需要对应修改为80。密钥 Key 为上边返回值中的 secret_key。
    同样,测试通过。

    参考:http://blog.csdn.net/aixiaoyang168/article/details/78825850

    展开全文
  • 八 OpenStack对象存储Swift&Ceph

    千次阅读 2018-05-11 20:02:31
    容器中存储对象 对象容器是储存对象的仓库。容器提供了一个整理对象的途径 容器就像是 Linux 的目录,只是容器无法嵌套用户可以在自己的帐户内创建任意数量的容器 容器可以公开,供任何人通过公共URL 访问该容器...

    (本文所有提及OSP=OpenStack Platform)

    1 对象存储架构

    1)Object Container 对象容器是什么?

    • 容器中存储了对象
    • 对象容器是储存对象的仓库。容器提供了一个整理对象的途径
    • 容器就像是 Linux 中的目录,只是容器无法嵌套用户可以在自己的帐户内创建任意数量的容器
    • 容器可以公开,供任何人通过公共URL 访问该容器中的对象

    2)Object 对象是什么?

    • 对象是数据: 在对象存储范畴内,对象就是存储的数据。对象存储为二进制文件,其元数据存储在文件的扩展属性(xattrs) 中,对象可以是许多不同类型的数据,如文本文件、视频、图像、电子邮件或虚拟机镜像
    • 伪文件夹: 伪文件夹对象,它可用于模拟一种层次结构,从而更好地组织容器中的对象。例如,名为books 的容器中有一个名为computer 的伪文件夹。computer 文件夹内又有一个名为linux的伪文件夹。linux 内有两个文件对象:一个名为the-introduction-to-linux-book 另一个名为the-introduction-to- linux-book.epub。
    • 对象所有权: 在创建了对象时,它归某一个帐户所有,如OpenStack 项目。帐户服务利用数据库来跟踪该帐户拥有的容器。对象服务利用数据库来跟踪和存储容器对象。
    • 访问对象: 对象的创建或检索由代理服务来处理,代理服务使用对象的路径哈希来创建唯一对象ID。用户和应用使用对象的ID 来访问该对象

    3)对象存储服务是什么?

    • 对象存储服务使用户能够存储和检索文件及其他数据对象,而无需文件系统界面
    • 该服务的分布式架构支持水平扩展。对象冗余通过基于软件的数据复制来提供
    • 由于通过异步复制支持最终一致性,它非常适合部署跨越不同地理区域的数据中心

    4)对象存储架构

    • openstack-swift-proxy :此代理服务使用对象ring来确定新上传对象的存储位置。它更新相关的容器数据库,以反映新对象的存在。如果新上传的对象进入新的容器,此代理服务也更新相关的帐户数据库,以反映该新容器。此代理服务也将GET 请求定向到被请求对象的副本所存储的节点之一,可以是随机的,或者基于从节点响应的时间。该服务提供对公共Swift API 的访问权限,并负责处理和路由请求。代理服务器无需假脱机便可以将对象流传输给用户。也可以通过HTTP 提供对象。代理还具备发现机制。对发现请求的响应中包括有关集群的信息,并且客户端可以用以确定Swift 集群中支持哪些功能
    • openstack-swift-accout 此帐户服务维护给定帐户可以访问的所有容器的数据库。每个帐户有一个数据库文件,它们在集群中予以复制。任何帐户都可以访问一组特定的容器。帐户映射到OpenStack身份服务中的项目。帐户服务通过引用容器数据库提供特定容器中的对象列表
    • openstack-swift-contaner 此容器服务在容器中维护对象数据库。每个容器有一个数据库文件 它们在集群中予以复制。容器通过将对象列表限定到具体的容器命名空间,加快查找对象的速度。容器服务利用帐户数据库来管理容器列表
    • openstack-swif-objcect 此对象服务负责将数据对象存储在磁盘设备上的分区内。每个分区是一个目录,而每个对象保存在其分区目录的子目录中。使用对象路径的MD5哈希值来识别对象本身。该服务存储、检索和删除对象.所有服务可以安装到各个节点上,或者也可安装到专用计算机上。此外,也提供下列组件以便能正常运行:
      1. Ring 文件Ring 文件将存储的实体的名称映射到物理位置。它们包含所有存储设备的详细信息,也用于推断特定数据片段所存储的位置。针对每一对象、帐户和容器服务器创建一个文件。
      2. 支持的文件系统: 对象服务将对象存储到文件系统。XFS 是推荐的文件系统,但ext4 也受到支持。文件系统的挂载必须启用xattr 属性以支持元数据条目。挂载点应当是/srv/node。
      3. House Keeping 进程: 复制确保在出现停机或磁盘故障时具有状态一致性。复制也可确保对象删除的同时移除文件。审核程序对对象、容器和帐户运行完整性检查。如果发现损坏,复制器会获得通知并将损坏的文件替换为来自其他副本之一的文件

    5)swift与Ceph对比

    • Ceph 功能集概览:
    • 在Ceph 中,对象存储在Ceph 对象存储设备(OSD) 中。,由于Ceph 中的代码库以C++ 为主,客户端可以直接和OSD 通信, 免除了代理服务的需要,因而能优化性能
    • Ceph 中的一致性模型由RADOS 网关来实施,它提供了强大的一致性。强大的一致性意味着新的和更新的对象写入到所有磁盘,然后才为客户端所见
    • Ceph 的用例包括镜像存储、备份服务,以及文件存储和共享
    • Ceph 网关(即RADOS 网关)是对象存储接口。它为应用提供了RESTful 网关,支持Amazon S3 和OpenStack Swift
    • Ceph 的1目标不仅仅是提供对象存储。
    • Ceph 将相同的存储集群用于对象存储、 块存储和基于文件的数据存储

    2 管理对象

    1)使用Horizon 控制面板管理容器对象:

    管理容器对象涉及多项任务,它们可以由个别项目用户执行, 在存储了大量要分发的数据对象时
    (如音乐或视频下载网站)也可由管理员执行
    程侧重于个别项目用户,以及管理容器和容器对象的基本任务
    OpenStack 对象存储容器和对象的管理可以通过多种方式来实现,如Horizon控制面板、对象存储API 和表述性状态转移(REST) Web 服务,或者OpenStack 统一CLI
    本节的这一部分侧重于Horizon 控制面板
    创建容器; 创建伪文件夹; 上传文件到文件夹; 下载文件对象; 删除文件对象;删除伪文件夹对象;删除容器

    2)使用CLI 管理容器对象:

    容器管理包括创建、列出和删除容器。伪文件夹和容器对象管理包括创建、列出和删除对象。使用OpenStack CLI 从命令行执行这些任务需要练习,但与操作图形界面相比能够更快产生结果
    若要创建容器,可使用openstack container create 命令
    若要列出用户项目中的所有容器,可使用openstack container list命令若要删除空容器,可使用openstack container delete 命令

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

    千次阅读 2015-12-16 17:09:09
    OpenStack Object Storage(Swift)是OpenStack开源云计算项目的子项目之一, 是整个OpenStack项目的一个模块。...先来熟悉一下Swift中的几个概念: Account 出于访问安全性考虑,使用Swift系统,每个用

    OpenStack Object Storage(Swift)是OpenStack开源云计算项目的子项目之一, 是整个OpenStack项目的一个模块。

    Swift最适合的就是永久类型的静态数据的长期存储。
    比如虚拟机的镜像啦,文档的备份啦,还有陈老师、李老师的艺术作品啦之类的。

    先来熟悉一下Swift中的几个概念:
    Account
    出于访问安全性考虑,使用Swift系统,每个用户必须有一个账号(Account)。只有通过Swift验证的账号才能访问Swift系统中的数据。提供账号验证的节点被称为Account Server。Swift中由Swauth提供账号权限认证服务。用户通过账号验证后将获得一个验证字符串(authentication token.),后续的每次数据访问操作都需要传递这个字符串。

    Container
    Swift中的container可以类比Windows操作系统中的文件夹或者Unix类操作系统中的目录,用于组织管理数据,所不同的是container不能嵌套。数据都以Object的形式存放在container中

    Object
    对象这个概念在后面会提到,这里先不说明了。

    Swift有如下几个特性:
    0、极高的数据持久性,上面已经提到了。
    1、各个存储的节点完全对等,是对称的系统架构。
    2、因为是对称的系统架构,扩容的时候只需简单的增加机器,扩展性很好。
    3、不存在单节点故障,前面提到因为各个节点完全对等,没有所谓的“主从”结构。

    存储在Swift里面的数据有好几个备份,而且各个节点之间是平等的关系,没有“主节点”这个概念,因此任意一个节点出现故障时,数据并不会丢失(注意,这里是任意一个节点出现故障)。而与它形成对比的是Hadoop的HDFS。

    HDFS有一个元数据存储节点,保存在HDFS集群中的所有文件都会在元数据存储节点上保留一份元数据,元数据记录了每个文件的一些必要的信息,例如文件大小,属于哪个用户,更新的时间,存储在HDFS哪台数据服务器上等等,感觉这个元数据的概念有点类似Linux中文件的inode信息。HDFS的缺点是一旦元数据服务器挂掉,那么整个HDFS集群就玩完了。当然,这只是我对HDFS一点浅显的认识,真正的部署的时候肯定还有很多保护措施,HDFS的健壮性是很好的。

    回到Swift上,Swift的元数据存储是完全均匀随机分布的,并且与对象文件存储一样,元数据也会存储多份。
    下图给出了Swift架构的一张示意图

    ————————更新———————

    下面是关于几个服务器作用,在上图中有 account server 和 container server 没有画出来。
    原文是英文,就直接放在这里了。

    Proxy server accepts incoming requests via the OpenStack Object API or just raw HTTP. It accepts files to upload, modifications to metadata or container creation. In addition, it will also serve files or container listing to web browsers. The proxy server may utilize an optional cache (usually deployed with memcache) to improve performance.

    Account servers manage accounts defined with the object storage service.

    Container servers manage a mapping of containers (i.e folders) within the object store service.

    Object servers manage actual objects (i.e. files) on the storage nodes.

    —————————————————

    其中Proxy Node是提供Swift API的服务器进程,我们要做的各个操作都是直接提交给Proxy Node, 由它来负责具体的操作。

    但是这里有个疑问:Client需要的数据,最后是由Proxy Node直接返回给Client? 还是Proxy Node只回复Client要的数据在哪台Storage Node上,然后Client再去对应的Stroage Node上取呢?(我猜测应该是后者)

    Storage Node就没什么好说的了,就好比是一个个大的数据仓库,提供存储服务。

    无论是HDFS也好,Swift也好,必须面对的一个问题就是如何保持数据的一致性。 因为一个文件并不是只保存一份的,在Swift中默认要保存3个副本,当更新的时候这3个文件要同时更新,当其中一个文件损坏时必须能迅速的复制一份完整的文件来替换。

    Swift有3个服务来解决这个问题:Auditor、Updater和Replicator。 Auditor运行在每个Swift服务器的后台持续地扫描磁盘来检测数据的完整性。如果发现数据损坏,Auditor就会将该文件移动到隔离区域,然后由Replicator负责用一个完好的拷贝来替代该数据。如果更新失败,该次更新在本地文件系统上会被加入队列,然后Updaters会继续处理这些失败了的更新工作。

    刚才提到过,Swift没有元数据服务器,也就是说,不会特意为每一个文件生成一个类似inode的东西,并且保存在特定的一个服务器上,这一点与HDFS有很大的不同。那么剩下最后一个问题:Client要存储一个文件,用什么策略决定存在哪台Storage Node上呢?

    实际上,与传统的文件系统不同,Swift保存的不是“文件”而是“对象”,这就是所谓的“对象存储”,具体可以通过下图理解:

    可以看出,在对象存储中,存储的不仅是数据,还有与丰富的数据相关的属性信息。系统会给每一个对象分配一个唯一的ID。对象本身是平等的,所有的ID都属于一个平坦的地址空间,而并非文件系统那样的树状逻辑结构。

    这种存储结构带来的好处是可以实现数据的智能化管理,因为对象本身包含了元数据信息,甚至更多的属性,我们可以根据这些信息对对象进行高效的管理。例如我们可以制定这样的存储策略,如果对象中包含priority:high,这样的属性,我们就对文件做比平常文件多的备份次数。

    平坦地址空间的设计使得访问对象只通过一个唯一的ID标识即可,不需要复杂的路径结构。

    因此,可以知道Swift中没有“路径”这个概念,所以也没有有所谓的“文件夹”这样的概念。

    现在,我们有了对象的ID了,那么如何根据这个ID把对象存在合适的Storage Node呢?

    在解决这个问题时,要注意几个约束条件:

    0、能快速的做一个决策,到底存在哪个Node上。
    解决这个问题,我们的第一反应应该是根据ID做一个Hash,不错,Swift确实是这么做的。

    1、Swift里面存储着成千上万,甚至上亿个 Object,当我们往集群中增加Storage Node的时候,最好不影响已有的数据。
    对于固定数量的Storage Node,使用普通的取模Hash法应该是又快又好的,当时当Node的数量会变动时,这种简单的Hash就不行了,因为这时所有对象的Hash值都会改变,这对于存储了上亿个对象的Swift来说是相当可怕的。

    解决的方法是使用“一致性Hash法”

    一致性哈希算法的基本实现原理是将机器节点和key(在本文里就是对象的ID)值都按照一样的hash算法映射到一个0~2^32的圆环上。当有一个写入缓存的请求到来时,计算Key值k对应的哈希值Hash(k),如果该值正好对应之前某个机器节点的Hash值,则直接写入该机器节点,如果没有对应的机器节点,则顺时针查找下一个节点,进行写入,如果超过2^32还没找到对应节点,则从0开始查找(因为是环状结构)。

    经过一致性哈希算法散列之后,当有新的机器加入时,将只影响一台机器的存储情况,例如新加入的节点H的散列在B与C之间,则原先由C处理的一些数据可能将移至H处理,而其他所有节点的处理情况都将保持不变,因此表现出很好的单调性。而如果删除一台机器,例如删除C节点,此时原来由C处理的数据将移至D节点,而其它节点的处理情况仍然不变。而由于在机器节点散列和缓冲内容散列时都采用了同一种散列算法,因此也很好得降低了分散性和负载。而通过引入虚拟节点的方式,也大大提高了平衡性。

    这个一致性hash算法倒是蛮有意思的,有时间应该详细的学习一下。

    以上就是本文的全部了,因为最近在实习,BOSS布置了这个任务,于是就去了解了一下OpenStack。这里也只是我对Swift的一些浅显的认识,如果文章里面有错误,欢迎指出,谢谢。

    在写这篇文章的时候,参考了很多网上的资料,但是很难一一列举出来,下面是我能找到参考资料的链接:

    http://blog.huanghao.me/?p=14

    http://os.zju.edu.cn/bbs/zjuos2011/?q=node/1501原创文章,转载请注明出处。本文链接地址: OpenStack 对象存储 Swift 简单介绍


    展开全文
  • swift对象存储

    万次阅读 2016-05-23 12:18:50
    swift对象存储简介OpenStack Object Storage(Swift)是OpenStack开源云计算项目的子项目之一,被称为对象存储,提供了强大的扩展性、冗余和持久性。对象存储,用于永久类型的静态数据的长期存储Swift 最初是由 ...

    swift对象存储

    简介

    OpenStack Object Storage(Swift)是OpenStack开源云计算项目的子项目之一,被称为对象存储,提供了强大的扩展性、冗余和持久性。对象存储,用于永久类型的静态数据的长期存储。
    Swift 最初是由 Rackspace 公司开发的高可用分布式对象存储服务,并于 2010 年贡献给 OpenStack 开源社区作为其最初的核心子项目之一,为其 Nova 子项目提供虚机镜像存储服务。Swift 构筑在比较便宜的标准硬件存储基础设施之上,无需采用 RAID(磁盘冗余阵列),通过在软件层面引入一致性散列技术和数据冗余性,牺牲一定程度的数据一致性来达到高可用性和可伸缩性,支持多租户模式、容器和对象读写操作,适合解决互联网的应用场景下非结构化数据存储问题。

    基本原理

    1.一致性散列(Consistent Hashing)

    面对海量级别的对象,需要存放在成千上万台服务器和硬盘设备上,首先要解决寻址问题,即如何将对象分布到这些设备地址上。Swift 是基于一致性散列技术,通过计算可将对象均匀分布到虚拟空间的虚拟节点上,在增加或删除节点时可大大减少需移动的数据量;虚拟空间大小通常采用 2 的 n 次幂,便于进行高效的移位操作;然后通过独特的数据结构 Ring(环)再将虚拟节点映射到实际的物理存储设备上,完成寻址过程。
    散列图片
    以逆时针方向递增的散列空间有 4 个字节长共 32 位,整数范围是[0~232-1];将散列结果右移 m 位,可产生 232-m个虚拟节点,例如 m=29 时可产生 8 个虚拟节点。在实际部署的时候需要经过仔细计算得到合适的虚拟节点数,以达到存储空间和工作负载之间的平衡。

    2.数据一致性模型

    按照 Eric Brewer 的 CAP(Consistency,Availability,Partition Tolerance)理论,无法同时满足 3 个方面,Swift 放弃严格一致性(满足 ACID 事务级别),而采用最终一致性模型(Eventual Consistency),来达到高可用性和无限水平扩展能力。为了实现这一目标,Swift 采用 Quorum 仲裁协议(Quorum 有法定投票人数的含义):

    (1)定义:N:数据的副本总数;W:写操作被确认接受的副本数量;R:读操作的副本数量
    (2)强一致性:R+W>N,以保证对副本的读写操作会产生交集,从而保证可以读取到最新版本;如果 W=N,R=1,则需要全部更新,适合大量读少量写操作场景下的强一致性;如果 R=N,W=1,则只更新一个副本,通过读取全部副本来得到最新版本,适合大量写少量读场景下的强一致性。
    (3)弱一致性:R+W<=N,如果读写操作的副本集合不产生交集,就可能会读到脏数据;适合对一致性要求比较低的场景。

    Swift 针对的是读写都比较频繁的场景,所以采用了比较折中的策略,即写操作需要满足至少一半以上成功 W >N/2,再保证读操作与写操作的副本集合至少产生一个交集,即 R+W>N。Swift 默认配置是 N=3,W=2>N/2,R=1 或 2,即每个对象会存在 3 个副本,这些副本会尽量被存储在不同区域的节点上;W=2 表示至少需要更新 2 个副本才算写成功;当 R=1 时意味着某一个读操作成功便立刻返回,此种情况下可能会读取到旧版本(弱一致性模型);当 R=2 时,需要通过在读操作请求头中增加 x-newest=true 参数来同时读取 2 个副本的元数据信息,然后比较时间戳来确定哪个是最新版本(强一致性模型);如果数据出现了不一致,后台服务进程会在一定时间窗口内通过检测和复制协议来完成数据同步,从而保证达到最终一致性。
    数据一致性

    3.环的数据结构

    环是为了将虚拟节点(分区)映射到一组物理存储设备上,并提供一定的冗余度而设计的,其数据结构由以下信息组成:
    存储设备列表、设备信息包括唯一标识号(id)、区域号(zone)、权重(weight)、IP 地址(ip)、端口(port)、设备名称(device)、元数据(meta)。
    分区到设备映射关系(replica2part2dev_id 数组)
    计算分区号的位移(part_shift 整数,即图 1 中的 m)
    以查找一个对象的计算过程为例:
    数据结构
    使用对象的层次结构 account/container/object 作为键,使用 MD5 散列算法得到一个散列值,对该散列值的前 4 个字节进行右移操作得到分区索引号,移动位数由上面的 part_shift 设置指定;按照分区索引号在分区到设备映射表(replica2part2dev_id)里查找该对象所在分区的对应的所有设备编号,这些设备会被尽量选择部署在不同区域(Zone)内,区域只是个抽象概念,它可以是某台机器,某个机架,甚至某个建筑内的机群,以提供最高级别的冗余性,建议至少部署 5 个区域;权重参数是个相对值,可以来根据磁盘的大小来调节,权重越大表示可分配的空间越多,可部署更多的分区。
    Swift 为账户,容器和对象分别定义了的环,查找账户和容器的是同样的过程。

    4.数据模型

    Swift 采用层次数据模型,共设三层逻辑结构:Account/Container/Object(即账户/容器/对象),每层节点数均没有限制,可以任意扩展。这里的账户和个人账户不是一个概念,可理解为租户,用来做顶层的隔离机制,可以被多个个人账户所共同使用;容器代表封装一组对象,类似文件夹或目录;叶子节点代表对象,由元数据和内容两部分组成,如图 4 所示:
    三层存储逻辑结构

    5.系统架构

    Swift 采用完全对称、面向资源的分布式系统架构设计,所有组件都可扩展,避免因单点失效而扩散并影响整个系统运转;通信方式采用非阻塞式 I/O 模式,提高了系统吞吐和响应能力。
    系统架构
    代理服务(Proxy Server):对外提供对象服务 API,会根据环的信息来查找服务地址并转发用户请求至相应的账户、容器或者对象服务;由于采用无状态的 REST 请求协议,可以进行横向扩展来均衡负载。
    认证服务(Authentication Server):验证访问用户的身份信息,并获得一个对象访问令牌(Token),在一定的时间内会一直有效;验证访问令牌的有效性并缓存下来直至过期时间。
    缓存服务(Cache Server):缓存的内容包括对象服务令牌,账户和容器的存在信息,但不会缓存对象本身的数据;缓存服务可采用 Memcached 集群,Swift 会使用一致性散列算法来分配缓存地址。
    账户服务(Account Server):提供账户元数据和统计信息,并维护所含容器列表的服务,每个账户的信息被存储在一个 SQLite 数据库中。
    容器服务(Container Server):提供容器元数据和统计信息,并维护所含对象列表的服务,每个容器的信息也存储在一个 SQLite 数据库中。
    对象服务(Object Server):提供对象元数据和内容服务,每个对象的内容会以文件的形式存储在文件系统中,元数据会作为文件属性来存储,建议采用支持扩展属性的 XFS 文件系统。
    复制服务(Replicator):会检测本地分区副本和远程副本是否一致,具体是通过对比散列文件和高级水印来完成,发现不一致时会采用推式(Push)更新远程副本,例如对象复制服务会使用远程文件拷贝工具 rsync 来同步;另外一个任务是确保被标记删除的对象从文件系统中移除。
    更新服务(Updater):当对象由于高负载的原因而无法立即更新时,任务将会被序列化到在本地文件系统中进行排队,以便服务恢复后进行异步更新;例如成功创建对象后容器服务器没有及时更新对象列表,这个时候容器的更新操作就会进入排队中,更新服务会在系统恢复正常后扫描队列并进行相应的更新处理。
    审计服务(Auditor):检查对象,容器和账户的完整性,如果发现比特级的错误,文件将被隔离,并复制其他的副本以覆盖本地损坏的副本;其他类型的错误会被记录到日志中。
    账户清理服务(Account Reaper):移除被标记为删除的账户,删除其所包含的所有容器和对象。

    特性

    1.极高的数据持久性

    数据持久性和系统可用性不同,指的是数据的可靠性,数据存储到系统后,到某一天丢失的可能性。AS3的数据持久性是11个9,即如果存储1万个(4个0)文件到S3中,1千万(7个0)年之后,可能会丢失1个文件。
    我们从理论上测算过,Swift在5个Zone、5×10个存储节点的环境下,数据复制份是为3,数据持久性的SLA能达到10个9。

    2.完全对称的系统架构

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

    无限的可扩展性

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

    3.无单点故障

    元数据问题,Swift的元数据存储是完全均匀随机分布的,并且与对象文件存储一样,元数据也会存储多份。

    4.简单、可依赖

    设计简单

    应用场景

    最典型的应用是网盘类的存储引擎,比如Dropbox背后使用的就是AS3。在OpenStack中还可以与镜像服务Glance结合,为其存储镜像文件。另外,由于Swift的无限扩展能力,非常适合用于存储日志文件和数据备份仓库。

    架构概述

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

    API接口

    Swift 通过 Proxy Server 向外提供基于 HTTP 的 REST 服务接口,对账户、容器和对象进行 CRUD 等操作。在访问 Swift 服务之前,需要先通过认证服务(keystone)获取访问令牌,然后在发送的请求中加入头部信息 X-Auth-Token。下面是请求返回账户中的容器列表的示例:

    GET /v1/<account> HTTP/1.1
    Host: storage.swift.com
    X-Auth-Token: eaaafd18-0fed-4b3a-81b4-663c99ec1cbb
    响应头部信息中包含状态码 200,容器列表包含在响应体中:
    HTTP/1.1 200 Ok
    Date: Thu, 07 Jan 2013 18:57:07 GMT
    Server: Apache
    Content-Type: text/plain; charset=UTF-8
    Content-Length: 32
    
    images
    movies
    documents
    backups

    swift restful api

    结束语

    OpenStack Swift 作为稳定和高可用的开源对象存储被很多企业作为商业化部署,如新浪的 App Engine 已经上线并提供了基于 Swift 的对象存储服务,韩国电信的 Ucloud Storage 服务。有理由相信,因为其完全的开放性、广泛的用户群和社区贡献者,Swift 可能会成为云存储的开放标准,从而打破 Amazon S3 在市场上的垄断地位,推动云计算在朝着更加开放和可互操作的方向前进。

    一切才是开始

    看完swift,发现原来云计算领域更为庞大。。。一切学习都是开始啊!

    基于Quorum投票的冗余控制算法

    1.简介

    Quorom 机制,是一种分布式系统中常用的,用来保证数据冗余和最终一致性的投票算法,其主要数学思想来源于鸽巢原理。

    在有冗余数据的分布式存储系统当中,冗余数据对象会在不同的机器之间存放多份拷贝。但是同一时刻一个数据对象的多份拷贝只能用于读或者用于写。

    该算法可以保证同一份数据对象的多份拷贝不会被超过两个访问对象读写。

    算法来源于[Gifford, 1979][3][1]。 分布式系统中的每一份数据拷贝对象都被赋予一票。每一个操作必须要获得最小的读票数(Vr)或者最小的写票数(Vw)才能读或者写。如果一个系统有V票(意味着一个数据对象有V份冗余拷贝),那么这最小读写票必须满足:

    Vr + Vw > V
    Vw > V/2
    第一条规则保证了一个数据不会被同时读写。当一个写操作请求过来的时候,它必须要获得Vw个冗余拷贝的许可。而剩下的数量是V-Vw 不够Vr,因此不能再有读请求过来了。同理,当读请求已经获得了Vr个冗余拷贝的许可时,写请求就无法获得许可了。

    第二条规则保证了数据的串行化修改。一份数据的冗余拷贝不可能同时被两个写请求修改。

    2.应用

    在分布式系统中,冗余数据是保证可靠性的手段,因此冗余数据的一致性维护就非常重要。一般而言,一个写操作必须要对所有的冗余数据都更新完成了,才能称为成功结束。比如一份数据在5台设备上有冗余,因为不知道读数据会落在哪一台设备上,那么一次写操作,必须5台设备都更新完成,写操作才能返回。

    对于写操作比较频繁的系统,这个操作的瓶颈非常大。Quorum算法可以让写操作只要写完3台就返回。剩下的由系统内部缓慢同步完成。而读操作,则需要也至少读3台,才能保证至少可以读到一个最新的数据。

    Quorum的读写最小票数可以用来做为系统在读、写性能方面的一个可调节参数。写票数Vw越大,则读票数Vr越小,这时候系统写的开销就大。反之则写的开销就小。

    文章参考如下两篇文章:
    http://www.ibm.com/developerworks/cn/cloud/library/1310_zhanghua_openstackswift/

    http://www.cnblogs.com/netfocus/p/3622184.html

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

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

    2019-04-25 19:09:11
    有没有研究swift对象存储大神,一起讨论相互进步qq:89666173
  • 背景 Ceph现在已经是Openstack官方主要支持的存储后端,而最新的Ceph不仅可以提供快服务,文件服务,而且还可以提供对象存储。Openstack Swift也提供对象存储服务,那这两者到底是竞争关系,还是互补关系呢?
  • 【IT168编译】在Ceph与Swift之间,存在一些孰优孰劣的争辩。Ceph在访问数据和存储信息方面提供了更大的灵活性,但这并不完全意味着它是一个比Swift更好的对象存储系统。  Swift和...
  • SWIFT工作原理

    2016-03-09 22:34:56
    swift API:对swift存储系统的请求都是通过Swift 的REST API 来进行的。对象的更新、上传、下载和删除都是通过使用http协议的PUT、GET、POST、DELETE来完成的。 Swift URL:对swift的服务请求都是通过 REST API用URL...
  • 简化的TCO无限的可扩展性可扩展的按需分配通用访问多租户模式数据耐久性和可用性云存储的局限性能新的API对象存储开源的重要性OpenStack Swift总结第二章:OpenStack Swift体系结构对象的逻辑结构Swift的实现和架构...
  • Swift架构和原理详解

    千次阅读 2018-02-21 19:54:01
    一 关于存储对象存储系统是综合了NAS和SAN的优点,同时具有SAN的高速直接访问和NAS的数据共享等优势,提供了高可靠行,跨平台性以及安全的数据共享的存储体系结构。二 Swift特点极高的数据持久性完全对称的系统架构...
  • 当您想了解OpenStack对象存储时,John Dickinson就是要问的人。 John是SwiftStack的技术总监,该公司依靠OpenStack Swift项目为全球客户提供非结构化数据存储。 他还担任OpenStack Swift的程序技术主管(PTL),...
  • Swift 不是文件系统或者实时的数据存储系统,而是对象存储,用于长期存储永久类型的静态数据。这些数据可以检索、调整和必要时进行更新。Swift最适合虚拟机镜像、图片、邮件和存档备份这类数据的存储Swift没有...
  • 对象存储Swift

    2017-05-09 10:48:11
  • openstack-r版(rocky)搭建基于centos7.4 的openstack swift对象存储服务 一 openstack-r版(rocky)搭建基于centos7.4 的openstack swift对象存储服务 二 openstack-r版(rocky)搭建基于centos7.4 的openstack swift...
  • 这可以说是OpenStack Swift发展过程的里程碑事件,之所以如此重要,是因为该版本引入了存储策略功能,这将允许人们针对不同需求的数据存储配置他们的Swift集群,同时存储成本也大幅下降。本文来自...
  • 所谓文件系统的本质是POSIX接口,“对象”这个名词是做对象存储的人为了把自己做的东西和文件系统区分开而用的术语,把存在对象存储里的文件叫做“对象”,所以选择文件系统还是对象存储,跟你把这堆数据称作对象...
  • 作者:李晓辉联系方式: Xiaohui_li@foxmail.com环境介绍类型控制节点和计算节点等在一起,形成all-in-one内存8G硬盘200G网卡2块对象存储服务概览OpenStack对象存储是一个多租户的对象存储系统,它支持大规模扩展,...
  • Swift3 本地存储array(UserDefaults)

    千次阅读 2017-02-07 15:40:44
    swift3 本地存储array, UserDefaults
1 2 3 4 5 ... 20
收藏数 30,171
精华内容 12,068
关键字:

对象存储中的swift