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.

2、新浪部署方案

上图是新浪在测试环境中部署的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、实验室测试环境方案

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

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

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