云存储(Swift+Keystone)部署策略
Swift是OpenStack的对象存储模块，Keystone是OpenStack的权限验证模块。可以于这两个模块搭建一个较为完善的云存储系统。
1、官方方案
云存储的服务器分三种类型：
- 验证节点 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。
最新文章
- Autoit3 获取WinForm下的ToolTip
- 在ionic/cordova中使用Form模型验证（w5cValidator）
- 张艾迪（创始人）： 整合全新的UIW.AD概念模式
- python之读取cdv
- 2.1 ARM家族大检阅
- MySQL-Front 建表引发的一点小思考（数据表格模版）
- ASP.NET Web API与Rest web api
- 6月27日 OGDF不同的布局算法
- some software that is used to speed up your system
- Maven本地安装JAR包组件
- WPF 之 实现TextBox输入文字后自动弹出数据(类似百度的输入框)
- DESTOON系统文章模块默认设置第一张图片为标题图的方法
- eclipse weblogic debug 简易配置版
- tastypie Django REST framework
- http&https&证书&数字签名
- stl中auto_ptr,unique_ptr,shared_ptr,weak_ptr四种智能指针使用总结
- 洛谷P3835 【模板】可持久化平衡树
- MySQL必知必会 前10章学习笔记
- pyspider环境部署1--python3安装
- python 进程锁 生产者消费者模型 队列 (进程其他方法,守护进程,数据共享,进程隔离验证)