OpenStack Swift跨地域存储集群的部署与优化

xman

　　OpenStack  Swift，大家会说它是OpenStack的对象存储服务，或者对象存储项目，但是实际上对象存储这个词它的含义，不同的人有不同的理解。
　　首先，让我们先看一个例子，就是淘宝在06、07年的时候，开始用他们自己研发的分布式存储系统，或者用现在时髦的话说叫SDS存储系统，来替代NAS设备。就以前淘宝的图片都是放在NAS里面的，但是从06年开始逐步的替换，当然很快，现在早已经不见了，没有一台NAS，负责一台SAN在淘宝的后端里面。中间有一个数据，当然更新的数据在2010年的时候，淘宝后端的图片数量已经突破了280亿，这个数量也是非常巨大的。这也是造成他们为什么要替换NAS一个很重要的原因，就是因为对于海量数据存储，传统的NAS、传统的文件系统可能会遇到问题，这是一方面。另一方面，就是他要支持客户端直接访问。

　　也就是说，我们现在随着互联网的发展、移动互联网的发展，我们的手机，我们的移动互联网的发展，像网页如果要读取存储或者读取数据的话，我们会希望他能够直接访问存储系统，而不像再像以前，先通过Http服务，访问应用服务器或者访问web前端服务器，然后web再往后给到应用服务器。应用服务器再往后接到存储，然后再把数据吐出来，现在可能会希望能够由客户端直接访问存储，这样的话对整个存储系统的并发，一方面是对整个系统的并发有一个非常好的提升。另一方面，也对存储系统的并发提出了一个挑战，当然这样做以后就会大量节省中间那两层，web服务器和应用服务期的开销，简化整个系统的架构，所以他带来的好处也是很多的，这就是为什么像淘宝，他会在当年用，其实用现在的话就是SDS或者对象存储系统来替代当初的NAS。
　　那么淘宝只是一个例子，其实在互联网公司中，类似的架构、类似的技术在广泛的得到使用，互联网公司是这样。那对于传统行业，我们现在所谓的传统行业，或者我更习惯说是非互联网行业，
而过去将近一年多，将近两年时间我所从事的主要工作，就是我把所了解的互联网公司里面用到的比较好的技术推荐或者传播或者说帮助传统行业的非互联网产业的企业怎么样应用、怎么样改造他们的IT系统。
　　以前我们去银行办卡，需要排几十分钟的队才能办到一张卡，或者需要去指定网点才能办，而现在，比如在招行，进去10分钟，就可以办一张卡出来。为什么?因为我们不用再到柜台去排队了，虽然也要去网点，但是也有这样的一个机器，你站在这个机器前边，跟机器那边的人对话几句，然后签署几个电子档的文件就可以了。然后在他的后端，会把你的这段视频，实际上声音是要单独存储的。因为声文识别比视频识别目前来看，还是要更容易和准确一些，所以声音文件是要单独存储的，这是他们的业务，这是他们的应用，那后端的存储用什么?用以前传统存储还行不行，同样会面对像淘宝面对的两个问题，第一个是数据量的激增，以前银行可以说多长时间能存满100T的数据，，存100T会需要很长时间的数据积累，但是上了这套系统以后，因为大量的视频需要存储，所以很快这个存储容量就会发生一个非常大的增长，那以前传统的存储架构可能会有问题。另外这也是一种客户端，这个客户端，我们也会希望它能够直接访问存储系统，还有类似的，像以前我们去银行要复印一些，现在我们去了话，如果办借助卡，可能主要是复印一个身份证，但是实际上银行有很多贷款业务，中间有大量的票据需要复印、需要存档，那现在用什么?全都是扫描件，全都是电子档的数字图片存档。
　　面对这样的存储需求，背后最好的解决方案是什么?
　　就是我们今天在这里谈论的对象存储。对象存储，也可以叫类似于S3的存储，S3like storgae，它主要有两个特征。
　　

• 第一个是没有一级一级的文件夹、目录数的东西，它是用户在它的存储空间只能看到一级，类似于目录动，叫做桶或者叫做容器。然后它就把对象放到那些桶里面、容器里面，这个就跟我们使用传统文件系统一级一级建目录的方式不一样。大家知道在亚马逊的云上面，最早提出的服务，在它的虚机、云主机推出之先，最早提供的服务也是对象存储。
• 另外一个特点，提供REST API ，也就是说直接能够HTTP的访问。这个是HTTP的接口，它非常简单，因为它是REStful的，所以他主要通过put、get、Delete、post，四类接口对数据进行操作。
  

文件存储

跟文件存储非常类似，叫Object Storage。Object Storage是对象，这个在台湾那边给它翻译为物件存储，我觉得更准确一些，他说实际上这个Object 就是东西，东西往框里放，就是这样一个意思。那Object本质上或者从另外一个角度来说，它就是我们今天说的文件，只不过它的系统这种形态方面不太一样。

这个也涉及到一个问题，就是这个东西没有文件夹，没有目录数了，我们怎么管理数据对吧，现在很多人会想到这个事，他又会有疑虑，就是我的应用，以前用的文件夹管理数据，现在没有了，怎么管理数据?

其实仔细想一下，现在在很多场景下文件存储没有用到文件夹。这个听起来很疯狂，文件的存储没有用到文件夹，其实大家仔细想一下，举一个非常直接的例子，你知道你手记拍的照片存在哪个目录下，文件名是什么吗?其实你不知道，但是你用的很好。如果程序员来编程的话，在后端实现一个系统的时候，其实也是类似的，现在很多地方，都不需要用文件夹来管理数据的，不需要用目录来管理数据的。当然并不是说这种东西要否定它，只是说我们在遇到某些问题的时候可以多想一下，像buckets实现，还有像操作系统的实现，它肯定得依赖文件系统。

海量数据存储的场景

大数据存储场景主要包括这两个，一个是超大文件存储，一个是海量小文件存储。另外一个是极高的可靠性与可用性，就是极高的。就是这个基本上可以很容易做到你的数据永远不丢失，然后永远在线的访问，这个对于Swift来说要做到很容易。当然必须得做正确，不正确的做法其实也是很容易出问题的，所以我们强调运维这个事情。特别是对分布式系统来说，正确的做事情，运维在中间基本上，做OpenStack，有一句话叫三分产品、七分运维，这个是很重要的。

由于Swift采用的是全分布式架构，所以它的扩展性非常好，没有集中节点。比如说HDFS，包括像淘宝的TFS，其实还是有NAS接点的，那NAS接点往往就会成为大家关注瓶颈的关键，这个在Swift里面是没有的，所以它的扩展性非常好。而且很多存储系统，随着规模的扩展到一定程度，规模特别大的时候，性能可能会下降，或者说衰减的很厉害，但是Swift不会。Swift几乎在非常大的规模，仍然做到性能随着规模的线性提升。

那么，还有就是目前可以支持纠删码，所以分布式存储三副本或者多副本，不再耗裸存储容量的事情，其实在Swift里面目前已经是得到解决，

现在在Swift基础上，做了哪些企业级用户比较关心事情?

• 第一个是安全性。
• 第二个是我们除了支持对象结构以外，我们为了照顾以前习惯NAS的应用，我们也可以支持POSIX兼容的接口。
• 第三个就是就是支持应用开发。
  

另外，说到在跨地域的基础之上，我们其实还可以提供双活或者多活的存储解决方案。所以在我们存储解决方案里面，针对目前这种企业级客户比较关注的双活和多活的事情，提供了这种定制化的解决方案。

跨域部署主要是三个方面：

• 第一个是在硬件上
• 第二个就是Ring的创建
• 第三个是最终一致性的问题