OpenStack 对象存储 Swift 架构、企业级应用实践(序)

一、背景及选型

随着公司业务的不断增长,继续使用传统的NAS+DB的存储架构来支撑海量的非结构化数据存储(已经到PB级),运维变的越来越困难。导致存储数据的快速增长带来运维成本的几何级增长,系统的稳定性和成本越来越不能让人接受。基于此种现状,期望寻求一种全新的存储解决方案。

通过分析整理需求如下:分布式、海量非结构化数据存储(100PB+)、多租户模式(为了实现精细化授权)、自定义元数据、无单点架构、高性能、高吞吐、自动化运维(95%以上自动运维管理)。通过调研、选型、POC最终选定为OpenStack Swift。

理由:

1、Apache 2.0协议,非常友好的协议,不会因修改了代码而带来麻烦。开源二次开发首选。

2、其本身设计就是海量非结构化数据存储的解决方案,支持分布式、支持多租户模式、分布式元数据管理方式(无单点)、基于对象存储概念的一种实现。

3、OpenStack目前在云计算中还是比较红火,社区非常活跃,并且swift做为一个子项目不受其它要求的依赖,相对非常独立,非常方便、简单的拿来使用。

4、基于python编写,设计巧妙、代码结构非常清晰、易读性还好。(但是有些代码也实在不敢恭维,一个方法写了好几屏都看不到结尾,有点感觉像是天才的设计,小白的填写)

5、新浪的SAE已经进行了应用,至少在国内已经看到有人吃了这个螃蟹。

二、基本概念

CAP理论:

Consistency(一致性)、Availability(可用性)、Partition-tolerance(分区容错性)三者不能兼得,只能兼得其二。为了实现可用性和分区容错性,所以swift将一致性的要求的选择权交给了需求方。

NWR原则(一致性的选择):

N-副本个数、W-一次写最少写成功的个数、R-一次读可以成功读到的个数。一般分布式存储都会抛弃磁盘阵列、RAID等技术来实现数据安全,而是回归到最原始的磁盘使用方式(我管它叫裸盘-不做任何RAID,只要能连接到计算机即可)通过存储多份副本来实现数据安全。

NWR=322  强一致性。可以看到读和写必有交集,所以最新的版本总是能被读到。
NWR=321  弱一致性。读和写有可能没有交集,所以最新的版本有可能被取不到。(但是性价比会更好)

而我们的需求会更变态:要求按照不同的租户可以选择不同的NWR策略,并且N要指定在不同数据中心的副本数。swift本身肯定是做不到的,我们对它整体做了改造。

数据对象化:

原始文件、系统元数据、自定义元数据,三者相加叫做数据对象化,在此种存储模式下,上层系统涉及的非结构化数据保存相对传统的NAS、SAN会变的更简单。


三、一致性HASH算法

一致性Hash算法,会建立一下0~2的32次方的圆环(没找到幂次方如何表示),而存储节点会通过Hash值排列在此圆环上。当一个数据到来时,会先通过Hash值定位在圆环上,然后再顺时针查找到的第一个节点则为关联节点。此种寻址方式的优势在于,当节点数发生变化时,尽量的移动较少的数据来达到重新分布。

此种方式的缺陷在于:增减节点后,平衡即被打破,分布会越来越不均匀。

所以我们为了解决此问题,引入了虚节点(swift叫分区),我们先创建足够多的分区,让其分布在圆环上,然后让分区再和我们实际的物理节点进行关联,只要保证分区不变,均匀分布就能保证,增减物理节点,只需要改变分区和物理节点间的关系即可。



四、XFS文件系统

我对此文件系统连接也不是很多,知道它可以支持更大容量的分区格式化(百TB级别),支持以KEY/VALUE的方式扩展属性的存储,相对EXT3或EXT4处理文件性能会更优越。
Swift可以使用多种文件系统,但是官方推荐是XFS,并且要在物理机上,才能完全发挥性能。
XFS文件系统不支持windows,所以我们的开发环境是linux。

总结

有了上面的知识储备,我们就可以进入swift的设计世界,我后续会将我理解的设计原理及代码,向大家做一次详细的介绍。。


阅读更多
个人分类: OpenStack Swift
想对作者说点什么? 我来说一句

OpenStack对象存储Swift必读

2015年12月23日 7.38MB 下载

openstack对象存储swift简介

2015年10月30日 980KB 下载

没有更多推荐了,返回首页

不良信息举报

OpenStack 对象存储 Swift 架构、企业级应用实践(序)

最多只允许输入30个字

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭