分布式存储元数据设计浅析.docVIP

分布式存储元数据设计浅析 　　【摘 要】近年来分布式存储以其良好的扩展性、优秀的性能和可靠性等多方面的优势在很多大型数据中心广泛应用，作为存储系统的核心部分，元数据的存取策略很大程度上影响到整个存储系统的性能和适用方向，本文将对主流的元数据设计进行了分析。 　　【关键词】元数据；主从模型；多副本模型 　　一、分析 　　元数据最基本的作用在于数据对象的定位。对象存储的任务是保存用户提交的数据对象，并以用户指定的名称（Key）对其标识。用户如需获取一个数据对象，要向对象存储系统提交Key，存储系统便会根据Key找到相应的数据对象，然后反馈给用户。元数据系统的好坏关系到整个对象存储系统的可靠性、可用性和一致性，并且会影响到性能。因此，元数据部分是对象存储系统的核心，也是架构和保障的重中之重。 　　（一）无中心模型 　　无中心模型是利用算法确定数据对象的位置，最常见的算法是一致性哈希。此方案如果仅考虑数据对象的存取，逻辑很简单，实现上也简单；但如果考虑到可靠性、可用性、一致性，以及运维，就会变得复杂。 　　简单来说无中心模式主要有以下两个优点：不存在单点故障和性能瓶颈；因为没有中心节点，理论扩展能力无限。但是它还存在一些普遍存在的难点，以下详细说明。 　　1.坏盘修复 　　无中心方式是通过key推算这个key的存储位置。但是在磁盘损坏（单盘故障）时最直接的处理方式是去掉坏盘，换上新盘，将这些数据拷贝过来。这样的处理方式在小型系统上非常适用。但针对目前日益增大的磁盘容量，比如4T的Sata盘，即使在千兆网下写入速度也只能达到100MB/s，考虑容量占用是80%，那么修复时间将达到8到9个小时，所以不适合用于大型系统。 　　2.扩容 　　在无中心节点的设计中，从key可以推算它存储的位置，并且我们要求key是均匀Hash的。此时如果集群规模从一百台扩容到二百台，意味着新加的一百台机器的存储负载要和以前的一致，那将会有一半的数据要进行迁移。但集群很大时，数据迁移过程中所花的时间通常会很长，这时会出现网络拥塞，以及系统性能的急剧下降。 　　3.不支持异构存储 　　提供云存储服务的公司必然会面临一个问题，有很多客户存储的文件非常小，而另外很多客户存储的文件非常大。小文件通常伴随着很高的IOPS需求，比较简单的做法是将Sata盘（100IOPS）换成SAS盘（300 IOPS）或者SSD盘（10000 IOPS以上）来得到更高的IOPS。但是对于无中心存储，由于key是Hash的，所以根本不知道小文件会存在哪里，这时能提高IOPS的唯一办法是加强所有机器的能力。使得整体的成本会增加很多。 　　4.数据不一致 　　比如要覆盖一个key，基于Hash意味着要删除一个文件，再重新上传一个文件，新上传的文件和之前的一个文件会在同一块磁盘的同一个目录下使用同样的文件名。如果覆盖时出现意外，只覆盖了三个副本中的两个或者一个，那么就很容易读到错误的数据，让用户感觉到覆盖没有发生，但原始数据已经丢失了。这是最难容忍的一个问题。 　　（二）多副本模型 　　多副本模型是利用众多元数据副本来保证可靠性和可用性的。多副本模型的各副本之间没有主次之分，所有的副本都处于相同的地位。因而，在向多副本模型写入元数据时，是同时向这些副本发起写入。而读取元数据时，也是向这些副本同时读。 　　多副本模型基于这样一个简单而直观的思路：单点会造成数据丢失，并引发可用性问题，将数据同时写入多个服务器就可以避免单点的出现。无论哪台服务器下线，都不会引起系统运行状态的变化，没有服务下线的顾虑。针对软硬件升级等日常维护工作，可直接将服务器下线进行更新。多副本模型的系统甚至可以容忍多台服务器下线，也不会造成系统运行的波动。 　　多副本的问题是一致性。由于我们允许副本服务器写入失败，再加上各种原因造成的数据退化，所以副本服务器之间的数据会不一样。我们无法确定哪台副本服务器包含了完整新鲜的数据。实际上不可能有这样的服务器存在。因而我们也就无法从任何一台服务器中准确无误地读出所需的数据。唯一的办法就是同时读所有的副本服务器，综合所得的副本数据，以获得所需的信息。 　　为了综合副本数据，首先要确定判断数据有效的基准，有时间基准和空间基准之分。时间基准用来处理元数据的先后覆盖，而空间基准用于处理副本之间的对应关系。 　　一般采用以下这样一个准则：对于一个数据对象的元数据，只有时间最近的那条是有效的。这样可以为每一次元数据写入加上一个时间戳，并且确保一次元数据写入的各个副本拥有相同的时间戳，同时还需保证历次写入的元数据拥有不同的时间戳。通过确保这两个条件，数据的基准就可以确立了。 　　（三）主从模型 　　元数`据系统是一个数据库系统，保障数据库系统可靠性最常用手