中文版BlueSkyACloudBackedFileSystemfortheEnterprise.docx
《中文版BlueSkyACloudBackedFileSystemfortheEnterprise.docx》由会员分享，可在线阅读，更多相关《中文版BlueSkyACloudBackedFileSystemfortheEnterprise.docx（29页珍藏版）》请在冰点文库上搜索。
中文版BlueSkyACloudBackedFileSystemfortheEnterprise
蓝天：
云计算虚拟文件系统的企业
1.摘要
蓝天—基于云存储的网络文件系统。
蓝天坚持在云存储提供商处存储数据，如AmazonS3或WindowsAzure存储供应商。
这些存储供应商是允许用户利用的具有可靠性以及大容量存储的，并且避免了需要专门的服务器硬件的云存储供应商。
客户端访问存储的数据，通过代理现场运行，缓存代理的存储数据提供低延迟的回复以及额外的优化机会。
为了获得好的性能和低成本，一些优化是必要的，包括日志结构的设计和云的日志清洁和安全。
蓝天支持很多协议（包括NFSCIFS），并且可以适用于不同的提供商。
简介
第三方云计算的承诺是三房连胜降低成本、动态可扩展性以及高可用性。
虽然对确切的性质和性质的限制还存在争议，但是很难否认这样一个事实，即云服务提供的实际效用明显大于大部分的生产系统。
这些生产系统现通过服务（如Amazon’sAWS和Microsoft’sAzure）成为云托管。
然而，迄今为止，在云中托管的服务已经大体分为两类：
1.面向消费者的Web应用程序（如Netflix客户的网站和流控制）；2.大规模数据处理（如Netflix的媒体编码管道）。
这项活动虽小，但却带动了广泛的外包企业计算和存储应用。
其原因是多种多样的，但他们在很大程度上反映了现有的客户端-服务器部署的本质上的惯性。
企业在客户端的软件上有大量的资金和操作的投资。
企业依赖与传统服务器平台的熟悉的性能、可用性和安全特性。
从本质上来说，企业还不是透明的替换现有服务。
有一些实质性的技术需要被克服。
因为传统的客户端服务器应用程序的设计要点（如文件系统、数据库等）常常不能够与云服务提供商所提供的服务配合好。
尤其是，很多应用程序被设计为带宽饥饿，延迟敏感（在一个局域网中是一个合理的设计），而远程云服务的性质是会增加延迟以及带宽的消耗。
此外，云服务将一些有代表性的简单地接口提取出来作为抽象的资源（如Amazon’sS3的“putfile”操作），而传统的服务器协议将更多的功能封装。
因此直到这些应用程序被重新设计，许多外包计算和存储服务的潜能才能才能被开发出来。
事实上，中小型企业，在一个巨大地服务器和存储设备为代表的市场上，以每年115美元的支出，应该解决这些问题。
【9】即使最终的演化是对云中所有应用程序进行托管，那也需要很多年才能完成。
在此期间，组织需要支持本地应用程序和云计算的混合使用。
在本文中，我们探索桥接这些领域的一种特定的应用程序，网络文件服务。
特别是，我们关注传统的网络文件服务可被云服务产品替换的程度。
然而，我们在建立文件系统客户端软件的设计上是故意限制了巨大的投资（无论是资金上还是培训上）。
我们需要一个给定的终端系统软件保持不变。
因此，我们专注与基于代理的解决方案中，在其中的一个专用代理，为一个企业环境中传统的服务器提供的“错觉”，将请求转换成相应的云存储中的API调用。
我们将探讨这种方法通过一种原型—蓝天，支持NFSCNFS，网络文件系统协议，包括AmazonEC2/S3和Microsoft’sAzure的驱动程序。
这样一个系统的工程面临很多的设计挑战，其中最明显的是需要反复考虑周围环境的性能（即缓存、隐藏延迟、网络带宽最大化的使用），但是，并不直观的同成本有强烈的相互作用。
尤其是，在存储接口和调度开销的相互作用中。
这种相互作用是由当前的云服务提供商共同设计出来的，有利于基于分段式的布局的设计（以及基于云的文件系统清洁）。
我们可以证明，忽视了这些问题，没有显著的提高了性能而我们的成本将明显的增加（在我们的测试中高达30%）。
最后，在一系列的基准中，我们表明，当使用这样的设计，基于云存储的服务的商品，能够提供更有竞争力的性能，相比于本地文件服务器的容量以及工作组所要求的企业工作负载，同时有第三方云服务所带来的好处：
可积累的可扩展性和成本优势。
2.相关的研究
在网络存储系统方面已经产生了大量的文献，很多都致力于客户端服务器的设计和性能，比如：
NFSCNFSAFSWAFL【67825】.最近，一系列的努力已经考虑其他的结构，包括在基于对等存储的分布式集中的不受信任的服务器【1213】，这些能够间接通知随后的基于云计算的设计。
云存储是一个比较新的主题。
它是由亚马逊的S3以及其他一些供应商提供的商品服务可用性所引起的。
云存储的弹性性质让人回想到Plan9只写一次【1920】的动机，尽管云通信的开销以及价钱成本反对块接口和没有存储回收。
也许我们最接近于学术的工作室safestore【11】，而条纹消除编码跨越多个存储提供商，最终数据对象通过NFS接口探索访问。
但是，safestore明确的重点是可用性，而不是性能或者成本，因此其设计的决策会有很大的不同。
一个类似的是DepSky【2】，一个更复杂的系统，也重复强调了可用性，提出了“云的云”的模式来复制在提供者。
在一个更抽象的层次上，Chen和Sion创建一个评估云存储成本的经济框架并得出结论：
加密所需的操作必须确保隐私，并且其计算的成本可以压倒其他的经济利益【3】。
然而，这项工作早于Intel的AES-NI的架构扩展，这个架构扩展大大加快了数据加密操作。
也有一系列非学术性的尝试，提供传统的文件系统接口，为key-value存储系统提供服务，比如亚马逊的S3。
这些每个客户端安装新的文件系统驱动程序。
典范包括s3sf【22】，试图直接将文件系统映射到S’3的存储模型中（这种做法将会改变文件系统的语义以及显著的增加成本）；ElasticDrive【5】，它提供一个块级别的页面（丢弃了一些潜在的使用文件级所产生的优化，比如预取）。
但是我们自己的系统最接近的是“云存储网关”。
云存储网关在过去的几年里出现（与同时代的努力），是存储服务器的一个新的类别。
Cirtas，Nasuni，TwinStrata，StorSimple和Panzura，这些系统等公司提供缓存网络文件系统代理（或网关）。
以这些公司为例，至少在表面上，这些系统非常类似于我们的设计。
这些系统的定价安排反映了在原云存储成本之上的两倍的保证金。
尽管这些系统的很少的细节是公开的，然而，一般说来，他们验证了我们所选择的设计点。
在商业云存储网关中，Nasuni[17]也许是同蓝天最相似的。
Nasuni提供了一个“虚拟NAS设备”（或者“文件管理器”）。
在用户的硬件电脑上，运行着客户的虚拟机，而软件包装在这个虚拟机上运行，这点同我们建立的蓝天代理软件非常相似。
Nasuni文件管理器作为高速缓存并且将数据持久写入到云中。
由于Nasuni不公开具体的实施细节，所以我们不知道Nasuni和蓝天是有多么相似，虽然他们的外部有一些差异。
在成本上，Nasuni只是简单地根据磁盘空间所消耗的数量（约0.30/GB/month，由云服务提供商所决定），一点也不考虑数据传输的功能和操作的执行。
据预测，为了避免吃进他们的利润，Nasuni在优化他们的系统以降低网络和每个操作的开销，但是他们是如何做的的细节目前还不清楚，除非他们采用缓存技术。
Cirtas【4】也建立了一个云网关。
但是它是以设备的形式出售。
Cirtas的的Bluejet是一个安装在机架上的计算机。
它在单个封装中集成软件来缓存文件系统的数据并存储于硬件中。
同Nasuni相比，Cirtas具有更高的前期成本，但更容易部署。
Panzura提供了另外的一种CIFS/NFS云存储网关。
不像蓝天和其他的一些系统，Panzura允许多个客户站点每次运行一个云网关。
这些网关都访问相同的底层文件系统，因此Panzura特别适合团队在一个大的区域内分享数据。
但是，同样其实施细节没有公开。
TwinStrata[29]和StorSimple[28]实现了网关，它们提供了块级存储接口，如ElasticDrive，从而也失去了很多文件系统级的优化。
在某些方面，蓝天的作用就像一个本地服务器一样。
它将数据备份到云—
一个本地的NFS服务器同Mozy【15】，Cumulus【30】，或其他类似的软件结合来提供类似的功能。
然而，这样备份的工具不支持高频率的备份（确保数据能够快速的到达云）并且不支持高效的随机访问云中文件。
此外，他们把本地的数据（而不是云中的副本）作为权威性的数据，来防止本地服务器缓存只是文件的一个子集。
3.结构
蓝天通过一个基于代理的透明的结构向在一个企业中的客户提供服务。
这种结构在云存储提供商处持续的存储数据（如图1）。
我们要特别的考虑到一个企业的环境，包括：
一个单一的代理缓存，与企业的客户相搭配，与一个相对高延迟然而高带宽的与云存储的连接相搭配，与典型的办公室和工程总达数十TB的文件的工作负载的要求相搭配。
本节我们将讨论代理器的作用，云服务提供商的组成，以及蓝天所支持的安全模型。
在第4和第5节中，我们将分别描述蓝天文件系统的布局和操作，和蓝天的代理。
云存储的作用就像在存储层次中的另一个层。
然而它提出并结合了新的设计考虑方法，使得它不同于其他的层，并且强烈影响了其作为一个文件服务的使用。
云计算的高延迟使得对企业的积极缓存成为必要。
另一方面，云存储具有一个有弹性的容量，具有独立于空间局部性的操作服务时间的提供，因此它大大的缓解了自由空间的管理以及数据的布局。
云存储的接口往往只支持对一个完整的对象进行写操作，防止有效地更新只是一个存储对象的一部分。
这种约束刺激了对现有内容的增加，附加，而不是对一个存储数据模型进行重写。
货币成本也成为优化的一个明确的度量值。
云存储的容量是有弹性的，但是我们仍然需要极度节省的去管理它，来降低随着时间推移而增加的存储成本【30】。
使用附加模型的存储，垃圾回收成为一种必然。
提供商也为每个操作收取少量的费用。
虽然较少，但当写入数据时，促进聚集小的对象（元数据和小文件）成为更大的单元，成本也是足够高的。
最后，外包数据存储的安全是首要考虑的因素。
图1
3.1本地代理
蓝天的核心组成部分是位于客户端和云服务提供商之间的一个代理。
这个代理使用标准网络文件系统协议与企业中的客户端进行通信，使用云存储协议与云服务提供商进行通信。
对于客户端，我们的原型支持NFS（version3）和CIFS协议；针对于云服务，支持亚马逊的S3的RESTful协议和WindowsAzure。
理想情况下，在同一个企业网络环境中，代理为客户端减少延迟。
代理缓存本地的数据和管理客户端之间共享数据，而无需进行到云中昂贵的往返。
客户端不需要修改，因为它们仍然使用标准的文件共享协议。
它们使用安装蓝天文件系统导出的代理，就好像它们在使用NFS或CNFS服务器的出口一样。
另外，通过共享语义等价于Samba，同一个蓝天文件系统可以安装在任何类型的客户端。
在后面我们将进行更详细的描述，蓝天通过对存储在云服务提供商的文件系统使用日志结构数据布局，来降低了成本，提高了性能。
系统的清洁需要对不再包含有有效数据的老的日志段进行垃圾回收，以及以将新的有效数据复制到老的段中的方法来处理空段。
作为一个回写高速缓存，蓝天代理通过写入到其本地磁盘可以充分使客户写的请求对本地网络文件系统的性能感到满意---只要它的缓存容量能够处理写突发其间的写请求，因为代理必须是受云服务提供商的带宽所限制的（6.5节）。
对于读请求，代理可以对工作集中客户的读工作负载进行缓存来提供一种当地的性能（6.4节）。
3.2云服务提供商
因此蓝天可以使用任何类型的云服务提供商来进行持久的存储服务。
它是假设的最小的提供商。
在我们的实验中，我们使用亚马逊的S3和WindowsAzureBlob服务。
蓝天只需要一个基本的接口的支持：
getputlistdelete操作。
如果提供商也支持一个托管服务，蓝天能够在提供者中协同文件系统清洁工作来降低成本和提高清洁的性能。
3.3安全
在外包的关键性能中，安全成为一个关键的关注点，比如：
数据存储。
在蓝天的设计中，我们的目标是为用户的数据的机密性和完整性提供高可靠保证。
在客户端的数据在通过网络发送之前，代理对数据进行加密，因此提供商不能阅读私人的数据。
加密是在对象水平上的（索引节点，文件块等），而不是在日志段上的加密。
在提供商上的数据存储还包括完整性检查。
这种完整性检查来探测是否有由存储供应商的任何篡改。
然而，对于云服务提供商的一些信任是不可避免的，特别是对数据的可用性。
供应商可以删除或者损坏存储的数据，使得数据变得不可用。
如果提供商可能是恶意的或者意外的，这些行动可能是故意的，比如：
在面对相关硬件灾难，不足的数据冗余。
最终，针对这样的问题，最好的防卫方法是通过审计和使用多个独立的服务提供商【2】【11】。
蓝天可以很容易的将这种功能合并，但这样做仍然在我们的工作范围之外。
一个错误或者恶意的存储提供商可能存储过时的数据，而不是返回最新的数据。
它可能返回一个老的但仍具有有效标签（因为它是被用户在一个很早的时间写入的）的数据对象的副本。
通过验证从根对象开始的对象的指针，蓝天阻止一个提供商有选择的回滚文件数据。
一个提供商只能回滚到某个以前状态的整个的文件系统中，而这个状态必须是用户可检测到的。
蓝天还可以利用云中的计算来运行文件系统清洁程序。
正如存储空间，我们不想完全的信任计算服务，然而这样做提供了一个紧张的设计。
为了保持机密性，数据加密的密钥不应该被云计算的节点使用。
然而，如果云计算的节点用于文件系统的维护任务，计算机节点必须是能够读取和操纵文件系统数据的结构。
对于蓝天，我们做了一个折中，即加密文件的数据，然而保留文件系统清洁所需要的元数据信息不进行加密。
因此，存储提供商能够理解文件系统的布局，但是数据仍然保持机密性，并且代理可以验证其完整性。
总之，蓝天提供很强的机密性和略弱的完整性的担保（一些数据的回滚攻击是可能的，但是大部分被阻止了，但必须依靠提供商的可用性）。
3.3安全性
外包的关键功能中安全性成为了一个关键问题，例如数据存储。
在设计蓝天，我们的目标是为客户提供高保证数据的机密性和完整性。
代理首先加密所有的客户数据，然后再把它发送到网络上，这样供应商就不能看到私人数据。
加密是在对象级别的机密（例如inodes，fileblocks等），而不是整个日志段。
存储在供应商处的数据还需要进行完整性检查以检测存储供应商是否篡改数据。
然而，一些云服务供应商的信任问题是不可避免的，特别是对数据的可用性。
供应商总是可以删除或者顺坏存储的数据，使其不可用。
这些行为可能是故意的，例如供应商会恶意或者意外的删除一些数据，比如在因为没有足够的冗余空间面对灾难相关的硬件问题时。
最终，对付这些问题的最好方法是通过审计和使用多个独立的服务提供商。
蓝天很愿意做这样的功能，但是这些在我们当前工作的范围之外。
一个错误或恶意的存储供应商也可以提供过时的数据。
它不提供最新的数据，而是返回一个有有效签名的旧副本的数据对象（因为它是由客户在较早之前写的）。
然而，通过认证从根部开始的对象之间的指针，蓝天防止供应商选择回滚文件数据。
供应商只能回滚到客户可以轻易检测到得整个文件系统。
蓝天也可以利用云计算来运行系统的清理程序。
对于存储，我们不希望安全信任计算服务，但是这在设计中提供了一种张力。
为了保持机密性，数据加密密钥不应该是云计算节点上。
然而，如果使用云计算节点的文件系统维护任务，计算节点必须能够读取和处理文件系统的数据结构。
对于蓝天系统，我们做出权衡在加密文件数据时同时保留必要的元数据来清除没有加密的文件系统。
因此，存储供应商能够知道文件系统的布局，但数据任然维持保密性并且代理仍然可以验证其完整性。
总之，蓝天提供了较强的机密性和较为薄弱的完整性担保（一些数据回滚攻击是可能的，但大部分会被阻止），但是必须依靠供应商来提供可用性。
4.蓝天文件系统
本节介绍了蓝天的文件系统布局。
我们提出包含在文件系统中的数据结构，而他们的组织保存在一个日志结构的格式中。
我们还描述了蓝天如何清除文件系统的日志，以及如何方便地设计为自己提供文件系统中存储数据的版本备份。
4.1对象类型
蓝天在日志结构文件系统格式中使用四种类型的对象来表示数据和元数据：
数据块，inode，inode图，和检查点。
这些对象被存入一个日志段中存储。
图2出示了文件系统中布局的关系。
在这个物理布局的顶层，蓝天提供了标准的POSIX文件系统的语义，包括的原子重新命名和硬链接。
数据块存储文件数据。
文件被分解成固定大小的块（最后一个块可以是短）。
蓝天使用的是32KB大小的文件块而不是典型磁盘文件系统的4KB大小的块来减小开销：
蓝天系统的块指针和额外的头信息每块的利用率都比磁盘文件系统高。
在后面第六节的评估中，我们展示了这一决定的成本和性能的平衡。
没有什么根本防止，但是可以防止蓝天系统使用可以可变大小的块来优化每个文件的访问模式，但是我们还没有实现这个方法。
所有类型的文件的inode包括基本的元数据：
所有权和访问控制，时间戳等。
对于常规文件，索引节点包含了一系列指向包含文件内容的数据块的指针。
目录项内联存储在目录节点中以减少遍历路径的开销。
蓝天系统不使用间接块来寻址文件数据——节点直接包含所有数据块的指针（很容易做到，因为索引节点是不固定大小的）。
Inode图列出最新版本的日志中每个inode的地址。
由于不存储在固定地点的inode，inode图提供必要的间接定位的inode。
检查点对象确定的根目录下的文件系统的快照。
检查点包含指向当前的inode映射对象的位置的指针。
在初始化时，代理反向扫面日志中最近检查点的位置，因为检查点是最后写入的对象之一。
检查点在代理失效的时候负责维护文件系统的完整性，去耦清除，文件服务以及提供版本备份。
图2蓝天文件系统布局。
顶部显示了逻辑结构。
对象指针由实线箭头所示。
阴影部分是加密的（但是指针不是加密的）。
图的底部说明了日志项是怎么样装入段中存储在云端的。
图3.大多数对象中的数据字段
4.2云日志
对于每个文件系统，蓝天为文件系统的用户维持一份独立的日志文件。
通常有两种：
代理管理文件系统中客户的行为，垃圾清理器收集清理覆盖数据。
每位客户存储一个文件段到一个独立的目录（不同的键前缀），这样客户可以独立的对文件系统进行更新。
每个日志由几个日志段组成，每个日志段中将多个对象聚合在一个固定大小的容器中来存储于传输。
在目前的实现中段的大小约为4MB，这已足够大来避免处理许多小对象的开销。
虽然存储接口要求每个每个日志段在写入时采用单独的操作，但是典型的云服务提供商允许对象的部分读操作。
所以，不论段大小如何，蓝天都可以读取每个独立的对象。
6.6节量化了将数据分组成段和选择读取的性能优势，6.7节量化了他们的利益。
一个单调递增的序列号标识目录中的每个日志段，在每个段中用字节偏移量来标识特定的对象。
目录、序列号和偏移量三个变量共同表示每个对象的物理位置。
对象指针还包含了对象的大小；虽然不是必须的但是这个提示允许蓝天快速的获得读取对象所需的确切字节数。
在蓝天的安全目标（3.3节）的支持下，文件系统对象都是单独加密（AES）并由代理保护好密钥的消息认证码（HMAC-SHA-256），然后上传到云服务。
每个对象都包含数据保护的混合：
一些数据进行加密和验证，一些数据是验证的纯文本，一些数据是XX的。
加密密钥和认证不共享在云端，虽然我们假定客户保存一个安全的密钥备份用于灾难恢复的备份。
图3总结了在对象中包含的字段。
每个对象在写入日志时，蓝天为其生成一个唯一标识符（UID）。
项目被简单地搬迁到一个新的日志位置时UID保持不变。
一个对象可以包含指向其他对象的指针（例如，一个inode指向数据块），指针同时还列出了UID和物理位置。
清洁器在云中可以搬迁对象和更新指针的新位置，只要在指针和对象的UID匹配，代理服务器可以验证的数据不被篡改。
4.3清洁器
对于任何结构的文件系统，蓝天系统需要一个清洁器来收集已被覆盖的垃圾数据。
不同于传统的基于磁盘的文件系统，具有弹性的云存储系统可以有效的无限增长。
因此，清洁器没有必要再写入新数据时工作，而仅仅是降低存储成本和碎片整理以便更有效的访问数据。
我们设计的蓝天清洁器，它可以运行在方便、低廉的访问存储设备的云服务提供商的代理或计算实例内。
例如，当运行在AmazonEC2的清洁器访问S3的存储设备，Amazon不收取任何传输费用（但是它仍然收取经营费用）。
在云中运行的清洁器不需要完全被信任（它需要读取和写入云存储的权限），但是并不需要文件系统的加密和认证密钥。
清洁器联网运行但没有与代理同步：
客户端可以继续访问和修改的文件系统，即使在清洁运行。
代理会合并相同的对象的冲突更新，这个在5.3中讲到。
4.4备份
日志结构的设计，让蓝天很容易集成文件系统的快照来进行备份。
事实上，只要清洁器没有运行，任何检查点可以用来重建当时文件系统的状态。
虽然不是在原型中实现，清洁剂或快照工具可以记录检查点的列表，保留和保护所有必需的日志段不被删除。
这些段可能在其他地方也可以存档保管。
4.5多代理访问
在目前的实现的蓝天系统中只有一个代理可以写入到文件系统中，同时还运行着一个清洁器。
我们需要有多个代理服务器读取和写入到同一个蓝天文件系统（无论是从一个单一的网站，以增加容量和吞吐量，或从多个站点，优化延迟地理分布的客户端）。
在蓝天系统中支持多种文件系统日志可以方便地添加支持多个并发的代理。
目前有两个可行的方法。
与Ivy类似，代理服务器可以不同步，而是提供宽松的一致性保障并假设在大部分时间只有一个单一的站点在更新数据。
在万一发生更新冲突时，该系统将提供给用户有多个版本的文件来调整。
第二种方法是，排列多个代理服务器的并发访问以提供更强的一致性。
这种方法增加了系统的某些分布式锁管理的复杂性。
由于云存储本身并没有提供所需的锁定语义，锁管理器需要运行在云计算节点或者代理上（理想的情况下，代理服务器用于容错分布）。
探索任一选项仍然是今后的工作。
5蓝天代理
本节介绍了设计和实现了蓝天代理，包括如何缓存在内存和磁盘上的数据，管理其网络连接到云，并间接与清洁器合作。
5.1高速缓存管理
代理服务器使用本地磁盘存储，实现了一个回写的高速缓存。
代理日志文件系统将来自客户端的请求（包括数据和元数据）写到本地磁盘上的一个日志中，同时确保了在告诉客户端数据被提交之前数据安全地在磁盘上。
写操作被异步地发送到云。
实际上，该日志被分解成顺序编号的几百兆的文件（日志段）存放在磁盘上。
这个回写高速缓存意味着在代理服务器发生灾难性故障的情况下，如果代理服务器的存储丢失，那么一些数据可能不能被写入到云中并且将会丢失。
如果本地存储是完整的那么没有数据将会丢失；代理服务器将重新演示一下在日志中记录的变化。
每隔一段时间，代理服务器会快照文件系统的状态，收集新文件系统对象和任何inode映射并更新到一个或者多个日志段中，同时上传这些日志段到云存储。
我们的原型代理实现目前不执行重复数据删除，同时我们没有为将来的工作探索这样一种优化的折中。
在选择如何快速将数据刷新到云中有一个权衡。
快速写数据到云可以使数据丢失窗口最小化。
但是，更长的超时也具有优点：
它能使日志段变大，同时它允许以组合的方式重叠写入。
短命的临时文件在极端情况下，没有数据需要被上传到云中。
目前，BlueSky代理服务器尽量频繁地每五分钟提交一次数据。
在前一个检查点完成之前，BlueSky没有开始写一个新的检查点，所以在写入负载很重的情况下，检查点可能触犯较少。
代理服务器在磁盘上保持一个高速缓存以满足保存多个没有发送的云的读请求，这个高速缓存包含从云存储下载的旧期刊段和日志段（journalsegmentsandlogsegments）。
期刊段和日志段被使用LRU策略的高速缓存丢弃，除了还没有被提交到云的期刊段被保存在高速缓存中。
在一大半的磁盘中，使用这种方式可以可以固定高速缓存。
当只需要一个日志段
升级会员 