EVA的缓存的缓存 为什么小却依然性能卓越 企业级高档手动自动一体化的存储阵列企业级高档手动自动一体化的存储阵列 Alex Chu 朱圣瑜 中国惠普网络存储方案产品部技术中心经理 Alex.Chuhp.com 简介简介 为了提高性能，存储控制器经常要使用高速缓存来减轻磁盘的机械存取的影响。缓存的提供数量是 在最初的设计阶段决定的，不同控制器之间的缓存数量有着很大的差异。另外，它还在很大程度上 取决于操作系统环境，也就是说，大型机（MainFrame）IO应用程序一般要频繁地访问存储上的缓 存，存储子系统上的缓存越大，它就受益越大。另一方面，开放操作系统应用程序一般将IO请求储 存在服务器内存中，结果是产生对存储子系统错过缓存(Cache-Miss)的密集的IO请求。这样，大量缓 存就不会为开放系统应用程序带来任何益处（必须等待从物理后端磁盘的实际读操作来满足存取）。 人们常问的一个问题是，EVA在只有2 GB高速缓存的情况下为何会有如此出色的性能？答案是EVA 专门为开放系统环境量身定制，与前面几代业界领先的存储控制器有着很深的渊源。HSG-80 （MA8000和EMA12000上使用的）控制器只有1 GB高速缓存，但在开放系统工作负荷的环境中，性 能却往往胜过配有8GB或16GB缓存的竞争对手的存储控制器。（例如在 Lycos.com 的 HSG80 与 Symmetrix 的 UIOX 性能测试的结果）。 这个令人讶异的事实背后的原因，在于典型应用程序访问存储器的方式与HSG80上内嵌的缓存算法 的结合。这些算法在EVA HSV-1x0控制器上 （EVA系列）得到大大增强，它们能够以最少的高速缓 存提供更高的性能。这些算法产生的结果，就是人们所达成的共识：“重要的不是大小；而是如何重要的不是大小；而是如何 使用！使用！” 本文余下部分稍微详细地讨论应用程序如何访问存储器，以及EVA如何利用这个信息，在最大限度 减少高速缓存数量的同时，实现缓存效率的最大化。 缓存的功能缓存的功能 控制器缓存的主要用途，是隐蔽由于磁盘存取的机械性质而产生的较长的服务时间。当前磁盘驱动 器的平均存取时间以毫秒计，而高性能控制器的缓存存取时间一般小于200微秒。由于磁盘存取花费 的时间要比缓存存取多30到40倍，因此高效的缓存算法可以对总体的存储性能产生显著的影响。 根据I/O的工作负荷，控制器缓存算法的主要功能可以分为四个方面：随机读，顺序读，随机写，顺 序写。为保证良好的性能而需要的缓存数量取决于是否有针对其中每个方面的算法，以及这些算法 的设计和执行的优秀程度。 为了理解这四种工作负荷为什么有如此之大的差异，以及为什么需要个别的缓存算法，我们将花一 点时间研究各个I/O工作负荷，以及专门为这些工作负荷开发的EVA算法。 2003年4月14日 第1页 随机读随机读 读缓存可以减少重复访问相同数据的磁盘存取。在访问磁盘存储块时，假定（或者希望）会再次访 问相同的数据，因此将数据置于缓存中。如果主机再次访问该数据，则数据可以直接从缓存返回， 从而避免磁盘访问。尽管这看起来是一个不错的方法，但从现实的角度看还是有一些问题： 1. 随机访问磁盘驱动器意味着缓存命中(hit)机率的可能性非常低。例如，如果应用程序随机访问一 个1 TB的文件，控制器就需要1 TB的缓存。大部分交互式的数据库应用程序都是随机访问，因 此读缓存的帮助很小，因为几乎所有的访问都错过(miss)缓存。如此一来，大量的读缓存对于随 机访问工作负荷而言帮助甚少，甚至没有任何益处。 2. 从磁盘读数据时，必须在缓存上为那些新数据准备空间，因此较早的数据将被移走。在随机存 储带来的高缓存错过概率与数据库的高I/O速率情况下，这意味着控制器增加了额外的开销及附 加的延迟时间。此外，由于其它的随机读的缓存错过活动，缓存中会被访问的任何数据都有可 能已经被移走。 3. 现代数据库都有自己的在服务器里面的内部缓存（例如Oracle上的SGA）。数据库最了解哪些数 据应当被缓存，因此重复访问的任何数据都保存在主机内存（SGA）内，存储器永远也看不到 这个I/O。这是大量缓存在存储控制器级提供的效用很小的另外一个原因。 尽管如此，仍有随机访问缓存能够受益的时候。最常见的情况是磁盘上有“热点”(hot spot)，这可 能是由于被重复访问的、但未被应用程序或操作系统缓存的特定文件或其中的一部分。数据库索引 区域就是一个很好的例子。尽管随机访问读缓存可能使这种访问模式受益，但在现实环境中有一个 问题，现在我们就讨论这个问题。 除了小区域内重复访问数据的I/O之外， 通常其它磁盘上还进行其它完全随机的I/O操作。 如果其它的 这些访问发生速率比较高，并且被读入缓存，那么它们就有可能将数据从热点区域置换，其结果就 是热点数据错过(miss)缓存。克服这个问题的一个常用方法，是简单地增加缓存数量，期待足够大量 的缓存能够使热点数据保留在缓存中，这种方法既成本高昂，又效率不高。当然，它的问题主要在 于是否有运气，这取决于随机访问流与热点I/O之间的关系。最终结果可能是为了保证数十MB热点 数据的缓存击中率，需要数十GB的高速缓存。 第二种方法是在不会缓存命中的LUN上禁用读缓存，从而避免其中的数据污染缓存。尽管这种方法 可能会帮助热点数据保留在缓存中，但也有着需要人工监测和干预的缺点。不仅如此，如果已经禁 用了读缓存的LUN工作负荷在数据中突然出现热点，就会失去通过缓存提高性能的可能性，因为该 LUN上的缓存已被禁用。 EVA不是以低效率的方式不必要地消耗大量的高速缓存，也不需要不间断的人工监测，它采用的是 一种能够以最少的缓存处理各种情况的先进算法，包括上述的情况。 EVA内置监测缓存命中(cache hit)情况的代码，如果某个LUN的命中率低于某个水平，就会自动禁止该LUN使用读缓存。因此随机 访问流不会被读入缓存中，也不会置换其它数据。但EVA通过数据结构继续监测该LUN的访问，如 果缓存能够为访问模式提供帮助，EVA就会重新启用该LUN的读缓存。这种根据不断变化的I/O工作 负荷动态启用和禁用读缓存的方法，是EVA不需要大量读缓存的众多原因之一（它极其高效地使用 现有缓存）。 2003年4月14日 第2页 顺序读顺序读 顺序读在很多应用程序上都十分常见，但它通常与其它应用程序的I/O流混合在一起。此外，很多应 用程序发出传输块非常小的顺序I/O请求，效率极低。一种简单化的处理方法是对每一个请求都提取 大量的数据，它背后的想法（或者其中缺少的东西）是读入比被请求更多的数据，这样对数据的下 一个顺序请求就已经在缓存中。这种想法有双重谬误。首先，实际上只有很小比例的请求是顺序的， 因此读入“额外数据”所花费的附加时间会大大降低所有访问的性能，不管是否是顺序访问。其次， 这些不需要的数据保存在缓存中，再一次导致将其它数据从缓存中清除。一般来说，这种不必要的 缓存清除要再次通过增加大量（不必要的）缓存来处理。 EVA采用的预取(prefetch)数据的算法要先进得多（已获得专利）。EVA不断监测I/O流，搜索顺序访 问模式。即使插入非顺序的I/O，也可以检测到顺序I/O流。例如，如果一个请求流请求了逻辑块100、 2367、17621、48、101、17、2、15和102，EVA就会识别有一个顺序请求流存在（块100、101和102）。 由于EVA是被设计来能够处理大量LUN的数目，因此预取算法被设计成在不同LUN的不同区域里面 可以识别多达512个同时发生的顺序流。所以，EVA不仅可以处理多种操作系统环境下不同应用程序 同时发生的I/O流，而且可以根据需要，发动很多LUN上的并行预取操作。 检测到顺序流，并且在原先请求的数据返回主机之后，EVA将向LUN请求额外的数据。在预取更多 的数据前等待原先数据的返回，这样就不会对主机I/O产生附加的延迟时间。如果EVA在主机请求之 前预取数据，该算法就推断预取操作速度足够快，不会落后于主机，然后这个过程继续（主机请求 数据后，开始另外一次预取）。另一方面，如果主机在EVA预取之前请求数据，就表明EVA速度太 慢，或者主机速度太快。为解决这个问题，EVA将增大预取的大小并且继续。当从主机顺序读的操 作继续时，EVA将根据需要动态增大预取的大小，以便领先于主机的请求。 将数据返回主机后，EVA将从缓存中清除这些数据，因为即使有，也很少会有再次请求被顺序访问 过的数据。由于这些数据要从缓存中清除，因此它几乎不占用空间，这样主机就可以顺序的读整个 LUN，从EVA那里获得100%的缓存命中率，并且只使用几百KB的缓存。这个算法的结果是不影响 随机访问的数据（不会触发预取的），只在需要的时候预取所需要的大小（动态调整预取大小）， 缓存的使用量是最低的（预取数据在返回主机之后会被冲洗flushed）。因此，EVA预分配的1GB读 缓存足以保持高性能的和同时发生的随机读和顺序读的工作负荷。 随机写随机写 写缓存主要用作于速度相匹配的缓冲区。对于随机写，当数据进入缓冲区后立即向主机发出完成信 号，因此延迟时间非常短。当缓存缓冲区开始填满时，EVA将执行后台冲洗(flush)操作，将数据写 入磁盘。EVA上配置了大量的磁盘，因此正在进行的主机读操作与冲洗操作冲突的可能性非常低， 冲洗(flush)不会导致明显的性能损失。 非常有趣的是，写缓存的大小对超出几百MB以上的随机工作负荷的影响非常之小。只要来自主机的 写速度低于缓存冲洗到磁盘上的速度，缓存就永远不会填满，应用程序总是会得到微秒级的写响应 时间。但是，如果主机写速度大于向磁盘冲洗数据的速度，那么不管缓存有多大，最终缓存都会填 满，主机的写速度也将降低为磁盘的速度。这与用水喉管为有洞的水桶灌水非常类似。增加流入速 度使其超过流出速度，水桶就会完全装满并溢出。 2003年4月14日 第3页 如果控制器冲洗(flush)算法没有很好地实现，那么非常可能出现缓存被填满的情形，应用程序I/O必 须降低速度，以便为缓存的冲洗留出时间。这种行为相对比较容易注意到，因为写速度是以缓存或 磁盘时间为基础的，因此应用程序的响应时间有波动的趋势。 因此， 写缓存的数量只需大到以满足猝发的(bursts),没有完全填满的瞬时写I/O活动。 大于此数量的缓 存不能带来更多益处，因为它们永远也不会填满。同样，如果持续写速度大于写缓存冲洗速度，那 么多大的高速缓冲存储器也不会避免缓存被完全填满和变得无效的。 顺序写顺序写 顺序写流一般与日志文件相关联，从性能角度看，它们通常是其中较为关键的I/O流。这些写操作通 常传输块的大小较小，例如8KB或16KB，从存储的角度看，效率非常低。而且，它们经常与数据库 “检查点（checkpoint）”或“提交（commit）”操作相关；因此其它应用程序I/O在完成这些写操 作后才开始。 除了检测顺序读流，EVA还检测顺序写流。多个顺序写请求将被聚合在缓存中，当清洗数据的时间 来临时，这些请求将作为一个单一的大的请求而不是很多的小的请求发送给磁盘存储器。这种方法 的一个明显优势，是可以在磁盘级获得高得更多的数据速率，从而提高传输效率，同时最大限度地 减少对可能指向到该磁盘驱动器的其它任何I/O请求的影响。 当写数据达到所谓的“条带（stripe）”大小时，EVA将把这些数据冲洗到磁盘上。一个“条带”的 大小是512 KB，它与作为基础的虚拟化技术相关。尽管讨论虚拟化技术超出了本文的范围，但一次 写一个条带意味着，对于VRaid 5 LUN来说，一次大的写操作将包含VRaid 5冗余组的所有成员，校 验可以在当时被计算和写入，从而消除了典型的读/修改/写操作的需要。这个操作意味着VRaid 5顺 序写可以达到接近VRaid 1的性能。VRaid 1 LUN的冲洗也可以以512 KB