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

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

一、官方方案

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

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

此方案是官方文档上的方案，部署图以下：

 此方案中，有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.

二、新浪部署方案

上图是新浪在测试环境中部署的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从中选择一个节点下载文件。

 

三、实验室测试环境方案

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

 

四、本身笔记本上部署方案

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