云存储(Swift+Keystone)部署策略

Swift是OpenStack的对象存储模块,Keystone是OpenStack的权限验证模块。可以于这两个模块搭建一个较为完善的云存储系统。

1、官方方案

云存储的服务器分三种类型:

  • 验证节点 Auth node – 运行 Auth service (keystone )
  • 代理节点 Proxy node – 运行 Proxy services
  • 存储节点 Storage node – 运行 Account, Container, and Object services

此方案是官方文档上的方案,部署图如下:

云存储(Swift+Keystone)部署策略

 此方案中,有1个Proxy node ,运行 swift-proxy-server。 proxy server用于代理请求,把请求路由到合适的 Storage nodes。有5个 Storage nodes ,运行 swift-account-server, swift-container-server, and swift-object-server ,这几个服务管理着 account databases, container databases, 存储objects.

2、新浪部署方案

云存储(Swift+Keystone)部署策略

上图是新浪在测试环境中部署的Swift集群,集群中又分为5个Zone,每个Zone是一台存储服务器,每台服务器上由12块2TB的SATA磁盘组成。Swift采用完全对称的系统架构,在这个部署案例中得到了很好的体现。图中每个服务器的角色是完全对等的,系统配置完全一样,均安装了所有Swift服务软件包,如Proxy Server、Container Server和Account Server等。

上面的负载均衡(Load Balancer)并不属于Swift的软件包,出于安全和性能的考虑,一般会在业务之前挡一层负载均衡设备。当然可以去掉这层代理,让Proxy Server直接接收用户的请求。

图中分别表示了上传文件PUT和下载文件GET请求的数据流,两个请求操作的是同一个对象。上传文件时,PUT请求通过负载均衡随机挑选一台Proxy Server,将请求转发到后者,后者通过查询本地的Ring文件,选择3个不同Zone中的后端来存储这个文件,然后同时将该文件向这三个存储节点发送文件。下载文件时,GET请求也通过负载均衡随机挑选一台Proxy Server,后者上的Ring文件能查询到这个文件存储在哪三个节点中,然后同时去向后端查询,至少有2个存储节点“表示”可以提供该文件,然后Proxy Server从中选择一个节点下载文件。

 

3、实验室测试环境方案

云存储(Swift+Keystone)部署策略

将验证服务和代理服务部署到了同一台机器上(即,验证、代理两个结点合二为一),部署了两个存储节点,数据的Replica的值为2。

 

4、自己笔记本上部署方案

云存储(Swift+Keystone)部署策略

将验证、代理、存储服务都部署到同一个虚拟机中。数据的冗余副本数量为1。

 

 

你可能感兴趣的:(swift)