如何进行ECS对象存储技术架构剖析

这篇文章给大家介绍如何进行ECS对象存储技术架构剖析，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。

今天，我们来讲讲历史悠久的EMC家族的对象存储ECS，这里ECS可不是二传手的意思，而是指Elastic Cloud Storage。

为什么说ECS历史悠久呢，因为EMC在2001年就推出了内容存储Centera，后来在2008年推出Atmos，到2014年推出的ECS已经是第三代对象存储了。由于2014年以后，S3已经成为对象存储的事实标准，因此，EMC从ECS才支持S3协议的。但由于现网中有众多的Centera和Atmos的用户，因此，ECS被迫支持原来的很多API，可以想象，ECS的历史包袱还是很重的。

ECS的产品架构层次还是比较清晰的，从上到下依次是：

1. ECS门户和供应服务- 基于Web的GUI，允许自我服务，自动化，报告和管理ECS节点。它还处理许可，身份验证，多租户和配置服务。

2. 数据服务- 支持对象，HDFS和NFSv3协议的服务，工具和API。

3. 存储引擎- 负责数据存储和检索，管理事务，数据保护和复制。

4. Fabric - 提供群集，运行状况，软件和配置管理，升级功能和警报。

5. 基础架构- ECS的基本操作系统是SUSE Linux Enterprise Server 12或更高版本，用于交钥匙设备或用于商用硬件的合格Linux风格操作系统。

6. 硬件- 交钥匙设备或合格的商品硬件。

   
   

在数据服务上，前面我们讲过，ECS除了支持S3外，还向下兼容CAS和Atmos，而且，也支持Swift。不过，如果是新用户，肯定只用S3，不会选择那些过气的协议了。还有，ECS也支持HDFS和NFS协议，这个我们后面再讲。

不过，ECS在对HDFS的支持这块，没有和其他对象存储一样，采用社区的S3A协议，而是自己做了一个专用的ECS HDFS Client。

这样的好处就是自己来实现HDFS语义对自己对象的访问，一般都会比S3A有更好的性能和更多的功能。业界对象存储采用专用HDFS Client来连接对象存储除了EMC外，还有华为和XSKY，也是这个思路。

由于对象存储大部分都具有多站点的能力，因此，Hadoop用户一般采用ECS对象存储来做灾备，也可以实现多个数据中心同时分析。

采用存算分离，好处很多，特别是EC（纠删码）在对象存储里面非常成熟，但是在Hadoop里面算是比较新的特性，很少看到用户在生产系统里部署，主要是硬盘故障的时候重构时间太长，运维比较复制。生产系统用三副本，造成几乎所有的Hadoop项目都面临空间不足的问题，但如果一直扩容容量，则有HCI一样的问题，计算也要跟着做无谓的扩容，造成资源的大量浪费。

ECS内置了对NFS协议的支持，并且支持8个站点的统一命名空间，支持全局锁，支持NFS|HDFS|S3之间的互访。

ECS的Chunk是固定的128M，管理的粒度有点大。我们知道Ceph的缺省Chunk大小是4M。

ECS的数据管理采用B+树，支持用户自定义属性反查，但是限制比较多，每个桶只能有5个索引段，而且创建完成后就不能修改了。（原来的版本手册写了这些限制，但最近ECS今年又发布了新版本，不知道是否还是有这些限制，大家测试一下就知道了）。

由于ECS不支持SSD做写缓存，和其他SDS很不一样，它用内存做写缓存。但由于内存没有掉电保护，因此，ECS需要和Oracle数据库一样，在回应写完成前，必须完成日志的落盘。这种机制造成了数据双写，性能比较差。因此，EMC也打算在今年的新版本也要支持SSD做写缓存了。

ECS的索引数据采用3副本的方式来保证其安全性。

但数据保存全部采用EC（不支持副本）。写之前数据会压缩，如果对象大约128MB（Chunk的大小），就直接EC。如果不是，就先写三副本，然后异步做EC。这样做的好处就是提高小文件的性能。

而读嘛，接受读请求的节点先找索引所在的节点，然后再找数据所在节点读取数据，返回给host。因此，一般情况，一个读流程需要经过三个节点处理，IO访问路径长，请求访问一个对象需要做多次重定向磁盘访问，虽然可以借助于缓存元数据改善，但大规模随机访问情况下，缓存效果可能一般。

ECS还支持跨站点做EC，这种情况虽然空间利用率上升了，但对站点的带宽时延都有比较高的要求，特别是某个站点故障的情况下。因此，国内我了解很少这样的部署方式。

后来，EMC也认识到这样的问题，在3.1版本推出了第三站点容灾only特性，解决用户想花比较少的钱实现三站点容灾的问题。

ECS的数据复制虽然是异步的，但是元数据复制是同步的。这样，从用户角度看，数据是强一致的。但在这种方式如果主站点故障，还是会丢数据的。

Box-Carting是ECS的小文件归并功能，ECS在内存里把小文件归并为2MB大小再落盘，提高写性能。

至于本地数据保护，ECS只支持12+4和10+2两种保护方式，灵活性比较差。

ECS也支持和IBM一样的紧凑型EC，减少初始节点数。不过，ECS要求4节点起，而一般分布式存储都是三节点起。

由于ECS支持跨站点EC，因此，站点越多，利用率反而越高，这和一般传统存储数据复制的弊端正好是反过来的。不过，前面也讲过，中国好像这样部署的企业客户不多（公有云比较多）。

ECS的数据可用性只宣传3个9，太实在了，实在是泥石界的一股清流啊。其他的厂商恨不得都宣传6个9以上。不过，难得EMC不怕友商拿来控标的吗？O(∩_∩)O哈哈~

ECS的组件都是封装成容器，采用容器的方式部署。

ECS虽然支持纯SDS的方式，但销售更喜欢推广一体机，这样销售额比较大啦。ECS没有内置负载均衡功能，而且5节点起步，价格有点小贵。

ECS在扩容这块特性不是太丰富，重平衡的时间可能比较长。

我们看到，ECS今年有两个小版本，在3.3支持SSD做Cache等重要特性，3.4支持新硬件。我前面的分析都是基于去年的版本，新版本我还没有拿到太多资料。

从长远来说，ECS未来会支持全闪，支持混合云等特性。

ECS都是Gartner和IDC相关象限的领导者。

Gartner对ECS的UI和容器架构比较欣赏，但还是指出一些问题。

在产品关键能力得分上，只有管理能力做到了业界最佳。

整体来说，我感觉ECS功能还是比较丰富的，比如在跨站点EC和数据强一致这块做了不少工作，但是，由于国外厂商一般把对象存储定位在保存温冷数据上，其对性能不够重视。比如ECS刚刚才支持SSD做Cache，小文件归并策略太简单了，不支持副本做数据保护，不支持整池扩容和重构QoS等。

关于如何进行ECS对象存储技术架构剖析就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。