为电子发现打造一个存储架构

    在最近几年，电子发现的理念改变了企业机构对待信息的方式，催生了众多旨在满足电子发现要求的解决方案。本文我们将把重点放在这些电子发现解决方案存在的存储难题上，例如，存储架构师需要考虑他们是否希望能够与数据增长、性能以及备份和恢复需求保持一致。

　　现在的电子发现系统基本上有两种组织数据的方法，而且大多数系统都是基于刀片的，所以添加刀片会提高系统性能。除了那些拥有大容量内存并主要应用大型机领域的特殊系统以外，目前基于刀片的电子发现是最常见的电子发现解决方案。

　　这些系统主要有两种组织数据的方式：

　　·每个刀片都有与之相关的本地存储，而且这个本地存储是用于保存经过分析的数据信息。

　　·每个刀片都与一个网络相连接，用户可以通过电子发现系统共享存储。

　　这两种方法的本质区别就在于：第一种情况下，应用连接不同的节点，并在节点之间分布数据。应用与不同的节点进行通信，哪些节点上有哪些信息;在第二种情况下，请求发送到节点，节点再向共享文件系统发送I/O请求。

　　究竟采用哪种方法最好应该取决于数据本身、搜索的类型、数据层(文件系统以及存储互连性)以及应用。从存储角度来说，两种方法都存在着优点和不足，这需要我们的进一步探索。当然，电子发现应用与存储的使用效率有很大关系，但是了解电子发现应用的底层需求能够让你更好地了解存储扩展程度，以及电子发现应用可能的扩展程度。

　　方法一：存储分治法

　　在这种方法中，每个刀片都有自己的本地存储和文件系统。因为本地文件系统相对较小的，所以数据分配和数据分片(data fragmentation)的文件系统性能应该不成问题。而且，对于大多数电子发现系统来说，数据并不是被删除，而只是添加，所以在这种分治方法中，当数据增加的时候也会相应增加节点和文件系统。有时候一个头结点或者多个节点包括了每个节点上保存了什么信息的索引数据。用户可以通过添加相应的刀片和存储来完成对这种系统的扩展。应用也许会从添加CPU中受益，也许不会，但这是实施扩展的途径。

　　这种系统可能带来的存储挑战包括：

　　·备份和恢复

　　·软件和硬件方面的刀片升级

　　·磁盘故障

　　备份和恢复

　　如果你拥有很多节点，那么管理备份和恢复就会变成一项复杂的工作。由于D2T备份的性能问题，你通常无法直接向磁带备份，因此你只能做D2D或者D2VirtualT。所有这些都会增加在本地磁盘上恢复数据需要花费的时间，所以许多应用镜像磁盘甚至有时会镜像整个节点。以上所有这些都是需要在硬件、软件、能源和冷却的成本。

　　软件和硬件方面的刀片升级

　　我经常问软件厂商这样一个问题：我如何升级和更新节点?如果他们的答案是在宕机时间进行的话，你就得问自己，我是否能够接受宕机时间?一些系统无法承担硬件与软件升级所需的长时间宕机。如果你现有软件升级涉及多个节点，那么升级必须能够推向系统并且没有宕机时间，就像硬件升级必须镜像节点然后推向系统一样。你需要一个周密的计划来作为作出安装过程的一部分，否则整个过程可能花上三年时间。

　　磁盘故障

　　尽管磁盘驱动器在最近几年经过完善以后可靠性更高了，但是仍然无法避免故障的发生。你应该知道，当系统中磁盘驱动器出现故障的话会发生什么。替换节点、镜像节点、还是其他什么?

　　方法二：全球存储池

　　如果你正在使用一个全球存储池，那么所有处理节点都通过NAS中的一个共享文件系统或者共享挂接点连接的。文件系统的扩展是有局限性的，每个节点都可以查看到所有数据。并行搜索要求大量I/O请求被发送到存储池中，同时由于有了大型存储网络，这种方法访问存储的延迟更高，但是这种延迟可以被第一种方法互连之间的延迟所抵消。

　　这种方法面临的挑战是：

　　·备份和恢复

　　·分片和文件系统扩展

　　·存储架构复杂性

　　备份和恢复

　　对于一个接收大量数据的大型文件系统来说，文件系统被分片存储的可能性就更大。有人会说，分片存储并不是问题所在，因为所有I/O请求都是随机的，不过从我自己的经验来说，许多电子发现应用有一些连续的I/O，因为这是数据被写入文件系统的方式。从搜索过程中我看到，有些请求是先连续、再跳跃增加、然后又是连续。目前标准的RAID系统无法连续地看到这种现象，尤其是当文件系统由于分片而不能按顺序写入数据。未来，目标系统将缓解这个问题，OSD目标可以识别访问模式。

　　存储架构复杂性

　　大型共享文件系统甚至是大型NAS系统都变得越来越难以管理和维护。这并不是说大型节点集群就容易管理，而是说你正在将管理问题从集群转向存储。在我看来，存储似乎要比集群更难管理，至少就使用目前现有的工具来说。

　　哪个是最佳方法?

　　我认为，添加相等数量的存储的计算能力似乎应该假设有所的因素都是相等的，每字节的存储需要X数量级的计算能力。因为存储密度的增长速度与CPU性能以及存储性能的增长速度并不一致，寻道和延迟需要的时间是不能根据CPU的性能增长计算出来的，所以我认为这种模式并不完美。如果基于相同数量刀片增加某些因素，而且比率并不均衡的话，为了达到均衡你往往需要付出比预期更多，因为能源和冷却成本在不断增长。

　　从次要方面来看，共享文件系统往往存在扩展问题，需要我们把大量精力放在架构计划上。

　　究竟哪种方法最好并没有一个定论，为了达到最佳结果你需要了解信息的类型以及电子发现应用如何运作。要是很简单的话谁都可以胜任了。