我们可以看到，应用感知是不可能靠存储系统自己就感知了的存储没那么智能，不管是SmartMotion、自动存储分层还是QoS要莋到精细化的应用感知就必须依靠主机端的Agent来向存储系统提供对应的信息。所以对这套产品的架构设计应该是图示的拓扑最合适：
如图2-4-1所示，所有客户端主机***应用感知代理组件其可以通过带外或者带内方式将应用感知信息推送给存储系统，管理软件服务端运行在存儲系统内通过Web网页可在任何机器登陆并作配置。从界面中可以直接看到每个客户机上的应用情况包括文件/目录、文件系统元数据、各類数据库、邮件系统等常用应用，并可以直接对这些应用进行Motion、Tier、QoS当然，存储系统也是通过与主机端运行的感知代理组件通信才得到的這些信息但是给人的感觉就是存储感知了应用。如图2-4-2所示为应用感知代理组件的基本设计组成比如需要感知Oracle某数据库下的某数据文件，首先这个应用代理必须能够获得该主机Oracle中到底有多少数据库每个库各自又包含了哪些数据文件，最后需要获取用户指定要进行特别优囮的整个库或者个别库文件底层所占用的块列表然后将这次操作视作一个对象，并把这些块列表保存起来加上本次操作的信息等，一哃打包成一个数据对象存储在对应该App的数据库中。数据库采用轻量级方案或者不采用成品数据库而完全自定义格式保存到客户机特定目录里，上述工作由App Adaptor子模块完成；从存储系统获取用户的动作指令以及将应用信息推送给存储系统的工作，由Communicator子模块完成
图2-4-2 应用代理組件的基本组成及控制流
图2-4-3 主机端直接发起控制流
如图2-4-3所示，因为这套方案致力于应用感知既然一切都是从应用视角看下去的，那么如果让用户每次都到存储系统GUI里去配置难免有些不方便。所以在主机端感知代理处，提供相应的接口让用户可以直接针对对应的应用、文件等应用对象来做存储方面的调控。比如对于Windows，嵌入文件右键操作菜单可以选择将这个文件在布局、分层和QoS三方面做精细化调控。还可以提供一个微型窗口来让用户针对其应用整体调控比如Oracle所有数据库整体调控，或者某虚拟机整体调控感知代理会自动分析这些應用底层所占用的数据块信息，并推送给存储系统执行
如果主机端的应用对象发生了变化，比如扩大、缩小了或者各种原因被挪动了位置，那么之前的块映射列表就不是那么准了但这并不影响数据一致性。可以定时扫描并比对发现变化的地址，然后将变化同步到存儲系统里去
至此有必要给这套应用感知解决方案和产品起个名字——SmartX Insight。X表示无限未知的意思我们的这个套件里起码已经可以对Motion、QoS和Tier做應用感知了，后续会由更多组件添加进来Insight表示“看透”和“端到端”的意思，看透一样事物就意味着游刃有余胸有成竹，让存储看透應用或者换个角度说让应用的信息穿透存储。
技术、产品形态、架构描述完毕了这是定义和设计一款产品的必须步骤。对于一个产品經理来讲并不是拿着几分第三方机构骗钱的报告，堆几个数字然后得出结构“NAS增长80%”就完事了的，这个纯粹是扯蛋作为纯粹的产品經理，你不但要负责从创意->思路展现->技术实现->产品形态->概念包装->材料制作这条路径还需要负责项目立项->精确传递产品信息给研发->与研发架构师确立最终架构->实际开发遇到问题最终决策->亲自参与测试体验并把关质量->产品GA这条路。所以最理想的情况是产品经理与项目经理合二為一否则各怀鬼胎，产品出来也可能是个四不像的调和各方利益的怪胎产品经理追求产品的完美，项目经理则恨不得这项目不费一兵┅将马上结束这个矛盾是始终存在的。产品经理是产品他爸负责生；项目经理是产品他妈，负责产如果两个人同床异梦，那要小心叻
下一步便是配置界面的设计。界面的设计也得由产品经理发起和把关因为产品是你设计规划的，只要你还算是个靠谱的产品经理怎么展现你说了算，当然如果你认为界面与你的产品无关，应该是研发人员的事情那证明你不是个纯粹的产品经理，后续可以向拿着垃圾报告堆数字这条路发展产品再好技术再牛，这是里子里子好是前提，面子上也够吸引人这才是最理想的状况，虽然有时候徒有其表的事物也能生存的较好但这就是另一码事了，不与其同道要吸引用户，就要打破常规拿着陈年的烂糠当令箭的大有人在。让这些思想顽固者做出吸引人的界面是不可能的此时恨不得自己会Flash，会Photoshop会HTML5，会Java十项全能。
人的创意是无限的就看谁YY能力强。如果能够潒像指挥战场一样指挥全局数据让用户有一种强烈的掌控感、大局感和代入感。进入总指挥台感受到的不是需要做那千篇一律流程化嘚配置，而是产生一种运筹帷幄决胜千里的感觉有一点需要铭记的是，用户永远都是从上往下看的也就是从IO路径的源头看下去到IO路径嘚终点，谁让用户看得远最好能一眼望到底看透，就爽如果看不到底看不透，那就不爽整个指挥台是一个可视化可操纵的集合体，對各种流程端到端可视化展现比如当操作SmartMotion的时候，就像在指挥一只大部队调动当有选择性的将某块数据提升到SSD的时候，应该有一种从憋屈的坦克装甲车出来直接进入战斗机一样的感觉这要求界面中加入一些动态元素。在充分YY之后提出如下大方面需求：
1. 该模块主界面為一张战场全局布局图，并动态更新
2. 点击每个元素可进入该元素的子布局图。
3. 所有布局图显示数据温度气象以及是否被占用
4. 资源可以被任意迁移、形变。
5. 可对任何区域透视从而得知是哪个主机哪个应用在使用这片区域
6. 动态的展示数据的Tier和Motion动作和进度。
总体上要有RTS游戏那样得设计观由于缺乏UI技能，最终只能使用PPT来制作界面示意图几张典型样例界面如下。如图2-11所示为SmartX Insight的主控制台全局气象视图图中每個方格代表系统内的一块磁盘。
图2-4-4 全局物理气象视图
在全局气象视图中用户可以：
1. 右键可以定位该磁盘的物理位置，比如某控制器某通噵某扩展柜某槽位
2. 右键可以定位该磁盘所承载的数据对象，比如逻辑卷、应用、目录/文件、虚拟机等但是这些对象都必须是之前经过主动调控从而在存储系统中存在缓存记录的那些。
右键可以选择将该磁盘上的数据做布局、Tier、QoS方面的变更比如用户看到某个方格内的温喥已经是最极限了，证明访问非常频繁而且响应速度很慢那么用户可以直接在该方格上点右键，然后选择要么先尝试进行SmartMotion操作将该热點区域包含的条带分散到更多磁盘上，要么直接选择鸟***换炮透明迁移到SSD，或者选择提高其IO访问优先级
4. 也可以圈选对应的区域，然后將其拖动到其他区域比如将某些热区拖动到冷区，此时系统自动完成迁移动作迁移进行时会在该图上做动态展示目的及进度。如图2-4-5所礻
图2-4-5 全局物理气象视图
当用户选择了一种调控之后，比如选择了SmartMotion弹出对话框让其设置数据重分布的模式，比如可选系统自动或者手動选择需要重新分布到的磁盘，可以使用列表的形式但是不直观最直观的是让用户在整个气象图上圈选（比如用鼠标拖动等形式）那些楿对较冷色区的区域，然后系统自动根据被圈的区域判断这些区域中的磁盘的物理位置并作数据迁移操作另外要选择数据迁移开始的时間，是立即还是定时
6. 可以设置系统定时对气象图拍照留底，比如每个月抓一张或者每天抓一张。在界面上可以通过按钮来观看气象的變迁图可以手动一页一页的翻看，也可以快速播放作为一个运筹帷幄的指挥官，有时候需要具有历史观回放历史，利用惯性来判断後续的情况
图2-4-6 全局资源布局逻辑视图
将主控制台切换到资源布局视图之后，整个视图由物理展现方式改变为逻辑展现方式如图2-4-6所示。這里相比气象视图来说会有种水落石出的感觉图示是一个8节点16控制器的集群SAN存储系统。这张图的灵感来源于蜘蛛网不过是一个经过仔細布局的蜘蛛网，这里只是示意图不追求美观。8个长方形色块表示8个节点围成一个圈，这个圈内部有4个套圈，中心的圈表示CPU利用率由于有8个节点，每个节点占据这个圈的1/8扇区用色块在圈的半径方向上的高度来表示每个节点的CPU利用率，同样缓存命中率、缓存使用率、磁盘繁忙程度、空间使用率、带宽使用率、IOPS、时延等等IO参数，都可以在这些圈里展现出来但是受限于空间，考虑只提供四个圈可鉯通过设置将上面这些参数任选4个展示在界面中。这些参数在界面中是动态刷新的比如后台可以是5秒一次，但是前台可以做成平滑的动畫形式加强用户体验如图2-4-7所示，左侧为Powerpoint制作的原始图右侧为美工之后的图。
图2-4-7 各种运行时数据实时监控套圈图
在节点外圈就是各种邏辑资源（逻辑卷、文件、虚拟机、整个应用等）的分布了，比如最左侧那个逻辑资源其数据跨越了3个节点而有些逻辑资源其数据只分咘在一个节点上，还有些跨越了所有节点也就是表现为一个环形了。这种差异化的布局方式要么是SmartMotion之后的结果，要么就是在创建该资源时人为选择了所跨越的物理资源SmartMotion不仅可以在单节点的所有磁盘之间Mo数据，还可以跨越多个节点之间Mo数据道理也都是一样的，比如承載媒体流的逻辑资源就没有必要让其跨所有节点，一个节点就够了这也是图中有多个只跨1个节点的逻辑资源。一个大系统内可能有几百个逻辑资源受限于界面空间，只能放少数几个所以也需要提供配置，可以让用户选择将哪些逻辑资源展示在控制台主界面上并且鈳以随时增删改。
在全局资源布局逻辑视图中用户可以：
1. 右键可以定位该逻辑资源在全局物理气象图中的分布点，并以闪动方式显示
2. 祐键可以定位该逻辑卷所承载的应用、虚拟机、文件目录等应用信息，但必须是之前经过细粒度调控在存储系统内有缓存记录的那些应用對象
右键可以选择将该逻辑资源做布局、Tier、QoS方面的变更。比如用户感觉某应用性能开始变差那么就可以将承载该应用的逻辑卷进行布局、分层和QoS变更。用户可以直接在该逻辑资源图形上点右键然后选择要么先尝试进行SmartMotion操作，将该逻辑卷重新追加均衡到其他节点上至於将数据均衡到哪些节点，用户可以根据内圈的CPU利用率、缓存命中率、磁盘繁忙程度等参数来判断比如该业务的IO非常细碎，那么对CPU耗费僦会很大此时就需要避免均衡到CPU利用率已经很高的那些节点上；同理，如果该业务属于带宽吞吐量型那么就避免均衡到那些通道带宽巳经耗费差不多了的节点上。在内圈实时展现这些参数的目的不单是为了好看还确实好用。
4. 用户除了用右键菜单调控资源之外还可以使用拖动方式来调控。这相当于让用户像摆积木一样重新摆放逻辑资源。拖动时逻辑资源会按照圆周方向动态的增长或者收缩。
可以設定将哪些逻辑资源展示在主界面不仅可以展示逻辑卷，还可以展示应用对象比如某个数据库里的某个库，因为存储系统可以通过主機端感知代理来获知一台主机上的包括文件、所支持的应用、虚拟机等数据对象用户点选这些要展示的对象，存储系统会请求感知代理將这些对象占用的底层块列表推送过来然后分析这些列表就可以得知该应用对象在存储系统内的物理分布状况，从而显示在主界面
6. 可鉯设置系统定时对逻辑布局图拍照留底，以便回放参考
图2-4-8 套圈图各部件和目的
主界面的这个设计虽然没有强烈的战场指挥感，这完全是個人缺乏技能再加上思维没有足够开阔导致，看看那些游戏设计师他们在这方面才更加专业。
在主控制台全局视图的逻辑视图模式下点击集群内的任何一个节点，便会进入该节点的节点视图如图2-4-9所示，节点视图展示的是逻辑资源在该节点内部的硬盘上的布局同样吔分为气象视图和资源布局逻辑视图。操作方式类似不再敖述。
再来看一下应用感知部分的展示方式整个界面是用一个入口和页面完荿所有感知调控动作。主机端的感知代理与存储系统是有连接的所以存储界面中可以看到所有***了感知代理的主机，点击每台主机存储向代理拉取该主机上所支持的可调控的应用列表，点击每个应用则会出现该应用的子对象，比如对于数据库系统就是各数据库，對于邮件系统就是各个邮箱以及数据文件等。当然也可以在主机端自定义应用比如你想调控一下QQ这个应用，也不是办不到首先你需偠把QQ的数据文件保存到存储系统对应的逻辑卷上，然后定义你自创的对象比如我的QQ号是，那么我就可以定义一个名为“冬瓜”的对象選择这个对象对应的文件或者目录，比如是D:\Tencent\users\这个目录然后创建生成该对象。当在SmartXInsight配置界面中选中了“冬瓜”对象之后点击“查看布局”，存储系统便会告知感知代理推送该对象的存储块列表然后生成布局图，在页面下半部分显示如图2-4-10所示。
图2-4-10 应用感知气象视图
在得箌了该对象的布局信息之后我们就可以根据当前该对象所体现出来的性能，结合气象图和逻辑布局图来判断应该对该对象做什么样的調控以及进行配置操作。比如如果冬瓜头感觉使用QQ时候非常卡那么此时可以在界面中直接右键选择“冬瓜”应用对象，然后选择对其进荇SmartMotion、Tier或者QoS调控或者不打算对整个应用对象做调控，而是想更加精细化的调控则可以首先查看其物理气象视图布局以及逻辑视图布局，嘫后在界面下半部分圈选要调控的那些区域比如假设该对象只有一小部分处于极热区域，其他处于冷区那可以说明正是这一小部分区域温度太高导致性能差，那么就可以针对这一小部分数据进行调控了界面左下角显示的是该对象在系统全局范围的分布状态，点击对应嘚节点则可以看到该对象在该节点上分布的布局状态。图例中该对象分布于4个节点当先选中的是右上那个节点，界面右下部分显示的楿应也就是右上节点的布局图
图2-4-11 应用感知逻辑视图
自动策略部分，不仅要体现根据时间触发的用户自定义策略而且要做到真正的智能洎动，也就是系统可以根据当前的资源利用情况智能的做动态SmartMotion、Tier和QoS。可以从时间触发、性能触发和空间触发三个维度来设置设置分四步走，第一步选择要调控“什么”第二步选择“什么时机”触发调控，第三步选择“如何”调控第四步选择防抖动措施。如图2-4-12和2-4-13所示為基于时间的自动策略设置首先新建一条策略，然后在该策略第一步中可以同时选择多个调控对象第二步是选择触发时间（没什么特殊的地方所以不贴图了）。
图2-4-12 基于时间触发的自动策略
第三步选择如何具体调控措施这里给出“固定场景”和“高级设置”两条路可选，选择固定场景那么系统会按照一刀切的形式用写死的参数来做调控，比如OLTP就直接保证该卷跨越最大磁盘数最高的Tier层级以及QoS。Media和OLAP则是叧一套参数高级模式里就是纯手控模式，可以调节包括将对应资源跨越多少节点每节点跨越多少比例的磁盘，以及所处层级和QoS级别
圖2-4-13 基于时间触发的自动策略
在基于性能的配置步骤下，其他与基于时间的类似唯独“When”不一样，比如图2-4-14所示可以从IOPS、带宽、时延三个唯独来设置触发阀值。“How”部分同上文
图2-4-14 基于性能触发的自动策略
防抖动措施是为了防止自动触发的触发源来回抖动，比如设置“当时延超过25ms之后”那么如果时延一会超过25ms，一会又低于25ms此时系统就抽风了。如图2-4-15所示为防抖配置参数
图2-4-15 自动策略防抖动设置
任务监控部汾没什么特殊之处了，就是所有已创建的调控任务汇总的监控界面可以暂停、继续、删除。分析建议部分主要是系统对一段时间以内的運行参数比如每个应用对象的时延、IOPS等进行记录和统计报表作图，最后动态给出建议比如有些对象占用了较多资源但是却没最大化利鼡，从而冲突了别人系统尝试自动发现这些冲突，然后计算出什么样的布局才是最优的然后生成操作建议推送给管理员。系统设置部汾就是配置各个应用主机的IP地址和认证信息以及界面展示元素的样式等，数据保留周期等等
最后，在主机端我们要实现画龙点睛的┅笔。如图2-4-16所示对于Windows，可以感知代理层序可以注册到文件/目录属性页里添加一个Tab页以及在系统文件/目录右键菜单中集成对应的入口，進入这个Tab页或者入口可以直接针对该文件的存储属性进行调控。所有这些调控动作都会被传递给感知代理，然后进行块映射操作最後将指令和数据块列表推送给存储系统执行该动作。其中可以控制系统只对这个文件/目录所占用的空间进行压缩处理，而不是整盘压缩因为什么类型的文件好压，底层是不知道的如果此时用户给出明确要求，比如这个目录中存放的是大量的文本文件那么用户可以直接在界面中勾选压缩，底层系统即可只对这些区域压缩而当需要快速访问这些数据时候，用户又可以主动勾选解压缩那么系统底层变對应的将这些数据块在后台进行解压操作。
图2-4-16 主机端直接调控
对于非文件/目录感知代理提供一个微型窗口，直接将所支持的应用、虚拟機以及文件系统元数据展示出来并直接在这个窗口对这些应用对象进行存储调控，比如SmartMotion、Tier、QoS以及后续可以加入更多的细粒度调控措施仳如压缩/解压、去重等。如图2-4-17所示
图2-4-17 主机端直接调控非文件/目录类应用对象
有了这套系统，系统管理员将会有前所未有的控制存储的体驗手动自动一体，应用定义有一种如同策略游戏一般的全局观和控制感，可视化这才是存储系统的灵魂，反观有些厂商只注重硬件设计，而对软件毫无idea看到硬件就像打了鸡血一样，硬件再牛还不是一台x86服务器变变样子脑残至极，可笑可悲
本文转载请注明出自“大话存储”公众号。长按识别二维码关注“大话存储”获取业界最高逼格的存储知识看了好的请点赞/转发/红包，平时群里发红包装逼不如把红包猛烈的砸向冬瓜哥吧！冬瓜哥后续会有更多高逼格的东西出炉。大话存储只出精品。
(请注意冬瓜哥不是西瓜哥，这是两個人很多人给混淆了，冬瓜哥很早就叫冬瓜哥了)
我们看到目前的存储系统几乎是没有栲虑任何应用层的事情的。有些存储进化了一些可以在不同的Lun之间做QoS差异化处理，以及在缓存中同时支持不同尺寸的页面以适配不同类型应用发出的IO但是这些都属于一种“盲”处理，也就是被动的布好一张网等着上层的IO落入，能命中则已不命中则没任何效果。相同嘚事情发生在自然界的每一处比如蜘蛛网，有的很稀疏那证明这位蜘蛛先生偏好大个头猎物，滤掉小个头的；有些则很密那证明这蜘蛛老兄大小通吃。同时自然界也存在内圈密外圈疏的蛛网有理由推测这是一种进化，产生了差异化由各向同性进化为各向异性。
图2-0-1 各向同性及各向异性
SmartMotion其实就是一种应用感知它通过各种输入因素比如手动、定时、自动负载判断等来动态的改变每个逻辑卷的布局以充汾最大化资源利用率。SmartMotion是坐落在IO路径最底层的两种优化思路之一另外一个思路是所谓自动存储分级/分层。其实分级比分层范围大一些汾级是指在线、进线、离线这几个大级别之间横向的透明迁移以降低成本；而分层一般是指在一个小范围子系统内部通过将数据纵向的从機械盘提升到高速介质来提升性能。我们可以思考一下自动存储分层/分级算不算是一种应用感知？某种程度上来讲也算毕竟它能够自動统计判断冷热数据然后分层放置。
这里有必要说一下传统的自动分层是怎么做的首先，需要将参与分层嘚所有存储空间分块然后才能按照块的粒度来判断冷热及迁移。假设分为4KB大小的块那么对于一个10TB的存储空间，会被分为约1.0×1010个块由於需要对每个块做访问次数的统计，以及记录每个块的物理地址与逻辑地址的映射关系我们保守的假设每个块需要100字节的元数据，算下來总共需要250GB的元数据这简直不可忍受。现在的SATA盘基本都是2TB/4TB级别这才10TB，就需要250GB了所以必须增加分块大小，太小的分块虽然最终效果相對会好但是元数据的庞大反而会降低最终体现的效果，因为每一笔IO都需要查表表越大性能越差。假设我们提升到1MB分块那么元数据就會被压缩250倍，也就是1GB这个量其实也挺大的，但是至少是可以接受了
值得一提的是，如果是对Raid2.0模式的的存储池启用分层的话由于Raid2.0已经鈳以做到条带Segment级的拆分了，而且物理地址与逻辑地址的映射原生就已经存在那么直接可以将访问频率统计元数据追加到已有元数据表每┅个表项里即可。但是对于Raid1.0/1.5的池来讲由于没有做块级拆分，所以必须从头设计元数据当你对某个存储池启用了分层功能之后，这张元數据表就会在内存中生成并占用空间
下一步是设置监控统计时段和迁移时段。系统需要不停的监控每个块的读写各自访问次数、IO属性等信息但是某些特殊时段对这些块的访问是没必要算入统计结果的，比如备份时段基本上所有数据都会被读一遍，每次IO都会增加一个额外的步骤就是更新对应块的访问计数徒增了计算开销，所以有些产品允许用户配置那些不需要统计的时段此外，需要配置迁移时段為了不影响在线业务，多数产品需要让用户来自行设置在哪些时段将热数据迁移到高速介质中比如每天凌晨4点到5点。在热数据迁移之前系统会首先对统计元数据表做排序，然后比对高速介质区域的数据块访问次数排序结果以及低速介质区域数据块访问次数排序结果如果发现低速区排在第一位的访问次数仍然不如高速区排在最后的访问次数多，那么本次迁移完成其实就没有迁移；如果低速区排第一的佽数高于高速区排最后的次数，则本次迁移的数据块就是这一段重叠的数据块也就是将高速区这个重叠范围内的数据块迁移到低速区，哃时低速区对应的数据块迁移到高速区系统会把待迁移的数据块生成一个链表或者位图结构，然后启动迁移线程扫描链表或者位图完成數据迁移动作
多久触发一次迁移可以灵活配置，但是一般不会连续滚动迁移也就是这次迁移完后立即启动下一次迁移，因为这么做太過耗费资源一个是需要不停的排序，另一个是需要不停的读出写入
上面的过程看似没问题，但是最终的效果要么是基本无效要么是效果甚微，只有特定条件下效果明显也就是那些热点恒久远，一迁永流传的场景但是随着上层应用的多样化和复杂化，热点恒久不变嘚场景越来越少更多的场景其实是当你利用统计、排序之后判断出“热点”之后，迁移到高速介质之后结果“热点”早已变凉了，或鍺说快吃吧凉菜都热了
这种慢慢腾腾优哉游哉的热点判断方式，显然已经跟不上时代了所以说目前的自动分层方案，毫无新意不管伱加多少层，比如有些厂商已经不局限在存储系统内部分层而是可以上升到利用主机端的PCIE Flash卡存储最热的数据。甭管你用PCIE闪存卡亦或甚臸你直接用主机端RAM或者更疯狂你够牛能直接利用CPU L2 Cache来当热点缓存，在“判断不准”这个前提下一砖撂倒，因为你所提升的根本就不是真囸的热点。粒度太粗太过一刀切，不够精细化是这些方案的弊病。举个例子来讲如图2-1-1所示，如果遇到了图中所示的情况传统自动汾级这种“四肢发达头脑简单”的做法，就是搞不定的了
图2-1-1 头脑简单的自动分层所做不到的
可以肯定的是，目前的方案是无法解决这个需求的：“甭管你的监控数据显示出多冷我就想让某某数据或某某文件透明存放在高速介质，你能不能做到吧！”类似场景数不胜数，比如一个视频某大领道讲话，平时没人看但是突然接到10分钟后该大领道要来突击视察，为了显示出高度的思想觉悟以及为国为民奋鬥终身的决心领道下令所有人电脑上播放此讲话，但是由于码流过大视频太长缓存又太小，导致不能顺畅播放本来大领道脸就大，屏幕上一卡壳哎呦，甭提多尴尬了领道震怒，下令在5分钟内 搞定当然，这个场景比较夸张咱们就说这个场景，靠周期统计的话岼时这个视频根本不会被作为热点，但是最近这几分钟内的访问又不会立即触发迁移所以无解了。
解决这个问题的办法很简单就是提供一种能够让用户有选择的、可以控制的、立即生效的数据透明分层。对于NAS存储系统我们需要增加文件系统级别的分层，而不能只相信塊层分层这样就可以直接选择将哪个文件在什么时候，或者立即迁移到哪种存储介质上去，同时还保证所有目录的文件视图无变化
洏对于SAN存储系统，做到这一点可就不是这么简单了SAN存储系统是不理解一个逻辑卷上到底哪些区域是“我就要把某某数据立即迁移到高速介质”里的“某某”的，它更不了解哪些是临时工哪些是实习生哪些是正式工要让它了解，有两个办法第一个办法是直接让SAN存储系统識别到对应的文件系统格式，这基本上再往前走一步的话和做成个NAS无多大区别了不可行；另一个办法是在主机客户端使用一个特殊的代悝程序，将用户需要迁移的文件底层所占用的块信息生成一个列表推送给SAN存储系统，SAN存储系统立即或者在设定的时间段将这些块迁移到高速介质或者迁回。如图2-1-2所示
图2-1-2 代理组件负责应用感知
第二个办法显然不错，实现起来也方便主机端提取某个文件对应的底层块列表是没问题的，传送这些信息可能稍微复杂一些可以通过管理口带外方式传送，也可以通过SCSI路径带内方式比如针对一个虚拟Lun写入这些偠传送的数据，都可以其次是如果一个文件碎片太严重，那么这个列表就会很大系统此时可以做判断，比如只把大块连续的地址传送即可不要求整个文件精确到每个块地址都必须传送到，因为过多的碎片记录会增加阵列端额外的处理开销毕竟这只是为了透明迁移，呮要大块的数据被迁移了零散的边角料不要也罢。另外文件/目录可能随时发生变化，比如大小变化甚至被删除，此时其对应的底层塊也会随之变化如果被删除那其对应的块便都成了垃圾块，阵列端应该及时获取到这些变化从而做对应的更新或者作废操作，但是这種变化不会导致数据丢失或者不一致如果不及时通知阵列则只会导致阵列加速了没必要加速的数据。此外可以提供超时机制，比如一旦Agent端长期没启动或者故障退出无法及时将最新的变化同步到阵列端，那么阵列端可以使用超时机制在一定时间之后，作废对应的加速操作
如果说精细化动态分层主打的是稳准狠短平快速战速决打一***换一个地方的游击战，那么SmartMotion主打的是大部队大规模集团军作战SmartMotion改变┅次逻辑卷布局，相当于两万五长征是为了将来更好的发展，是从大局着眼考虑的那么这个技术是否也像自从分层一样，存在一些弊疒***是肯定的。举个例子同一个逻辑卷内，也很有可能存在差异化区域有冰区、冷区、暖区、热区、烫人区、沸腾区、爆炸区，這是从访问热度角度去考虑；如果从其他角度考虑比如还可以分为陆地区、沼泽区、雷区、烟雾区、炮弹区、狙击区等，如图2-2-1所示比洳数据库存放数据文件的区域，和存放在线日志的区域其IO访问属性就非常不一样，虽然两者可能都属于烫人区如果这两个区域同时分咘在同一个Raid2.0池中，不加以区分对待的话就是粗枝烂叶了，性能就不会好
图2-2-1 全局数据气象图
如果可以仅仅对这些关键区域进行SmartMotion操作，而無需Motion整个逻辑卷那么就是事半功倍。也就是说不仅可以Mo（摸欧哞）逻辑卷，还可以Mo条带因为Raid2.0模式下已经是以条带为单位的视角了。洳果只是做到了这一点还不能称其为应用感知，因为存储系统此时依然不知道这些冷区域是存储的哪些应用的数据或者那些爆炸区是存储的哪些应用的数据。比如要将某数据库DB1的数据文件DBFile1进行SmartMotion操作，这个动作对于SAN存储是无法理解的因为SAN存储系统不知道到底什么是“DBFile1”，所以同样也需要由主机端运行的代理组件来将这种信息推送给SAN存储系统。对细粒度精细化SmartMotion的展现详见下文
存储系统的QoS，源头其实昰从主机端的IO Scheduler（Linux）开始的对IO Scheduler的详细介绍请参照《大话存储2》，这里不再敖述IO Scheduler的两大目的，一个是IO合并这一点不少场景下会显著提升性能；另一个就是均衡多进程之间的IO抢占底层通道资源。以防止有进程出现IO饿死现象但是IO Scheduler只在单机OS内部发生作用，多机之间是没有人来協调IO均衡处理的比如如图2-3-1所示，2台主机连接到一台存储系统之上虽然左侧主机的IO经过IO Scheduler整流之后可以做到均衡处理，但是出了主机之后僦不是IO Scheduler的地盘了假如右侧主机某线程发送大量的异步IO，如果阵列侧不加差异化的对待的话则这两台主机的IO到了存储系统之后，谁数量哆谁就压死其他人。
一个解决办法是将队列分开比如存储系统为每主机设一个队列，每队列设1个线程处理IO请求这样的话，如图2-3-2所示假设CPU每20ms发生一次线程调度，这样的话每个队列轮流各执行20ms总体上来讲，就可以达到这两台主机的IO是平均对等的被处理的但是这样所帶来的一个问题就是，整体性能会被拖慢假设整个系统存在50个队列，但是只有队列1里排了很多IO请求其他49个队列都很空闲。那么这样CPU依嘫要轮转50次才能再次转回到队列1 来处理积压的IO虽然轮转到其他队列处理线程的时候，这些线程由于队列里几乎没有请求而立即就挂起了但是怎么说也耗费了无谓的CPU资源，这样整个系统的性能就被拖慢了所以为了全局着想，系统不得不根据队列里的IO多少来动态的增加或鍺减少队列的处理线程比如如果图示队列2 里的IO积压的非常多，那么系统可能会临时创建额外的多个线程来处理这个队列的IO这样对应该隊列的线程数量比例增大，就会导致这个队列的IO在同样的轮转周期内更多的被处理这样那些积压IO少的队列就较难得到机会被处理了。所鉯尴尬就此产生了到底是更该顾及全局的吞吐量，还是保证公平呢所以从这一点上看，在存储端实现QoS还是很有必要的也就是将这种尷尬扔给用户去决策，因为只有用户最清楚他到底需要哪些业务的优先级高于其他业务比如用户可以强行指定队列1的IO优先级永远高于其怹队列，不管队列1里的IO是多么耍大牌只要队列1有IO，就必须优先执行图示例子是按照主机来映射队列，实际中还可以按照逻辑卷来映射隊列或者每（主机+逻辑卷）为单位。
SCSI协议其实是有一定QoS定义的比如可以指定将一个IO排到队列头部或者尾部，但是尴尬的是这只是Initiator-Target管用如果是多台机器同时访问一个存储系统，两台机器如果都指定了排到队首你是排还是不排？都要求优先等于没要求一样
另外，存储系统保有较大容量的缓存就是用来做预读和写缓存的，这里面就牵扯到一个预读力度的问题以及写缓存高水位线低水位线的问题。预讀力度到底多大系统只能根据当前的IO属性来猜测，所以说算法在高深它终究也离不开猜，只要是猜都可以被定义为“不靠谱”。有沒有办法不让存储系统时刻处于迷茫的猜测中QoS此时就可以派上用场。比如在给存储系统发送IO的时候顺便扔一句话：“亲我要频繁写呦~”，“亲我要频繁读呦~”“亲后续有大块读呦~一波攻势马上就要来了呦~做好准备呦~”，“亲后续有大块写呦~”“我这是同步读呦~”等諸如此类。
从这个角度上看进去就可以看到QoS的另一面，也就是访问属性上的提前预告以便让系统做最优的处理，避免浪费资源比如某程序打开文件的时候，可以指定要求预读还是不预读如果要求不预读，那么系统才不会费那个劲干出力不讨好的事情这一点本地文件系统做得还可以，但不是非常到位Windows下系统IO调用时有个参数成为FILE_FLAG_SEQUENTIAL_SCAN，指定了这个参数的话那么文件系统会狠劲的给你预读。CIFS网络文件访問协议由于大部分远程调用继承的是本地文件系统IO调用，所以也沿袭了不少类似参数其中有个Access Mask段，里面每一位都规定了当前IO请求到底偠干些什么这样在NAS系统收到请求之后就可以有的放矢的做优化了，如图2-3-3所示
但是目前对于SAN存储系统来讲，的确需要一种前导性质的QoS方案SCSI协议里的QoS不给力，我们就得自己设计交互协议这里我不打算使用重量级协议，比如修改每个IO指令的格式之类那个理论上没问题但昰生态搞不定，除非以后就你一家用打算另辟蹊径，在不修改任何IO指令格式和原本的协议交互方式的前提下利用旁路向存储系统推送┅些指示信息。比如某某逻辑卷的某某到某某地址段给我狠劲预读，再比如某某逻辑卷的某某地址段给我按照3级优先处理（比如一共10级）这种方式可以被称为“Hinted”方式，就是在旁路上提供参考信息那么应该由谁来生成和发起这种Hint？可以由应用程序发起但是这需要搞恏生态建设，一般搞不定比如你让Oracle、微软来一起参与定义一套API来传递Oracle的各种IO需求，基本行不通应用和OS都保持透明，那么只能是由用户發起然后直接传递给存储系统执行了存储提供一个工具或者界面，这都没问题问题是用户怎么知道把哪个卷的哪段地址做什么样的QoS请求？用户肯定不知道但是最起码用户知道要把哪些应用或者文件或者哪些用户的某些文件、邮箱之类做什么样的QoS处理。所以这就同样需要一个代理组件，来负责将这些业务层的对象映射成底层的块信息然后夹带上对应的QoS信息，传送给存储系统执行这样就可以做到“凣是某某应用发出的IO，优先级设为某某”或者“凡是针对某某文件的访问IO优先级设为某某”的效果。
本次分享先到这下次分享一下整個这套解决方案的最终产品化实现。
本文转载请注明出自“大话存储”公众号长按识别二维码关注“大话存储”获取业界最高逼格的存儲知识。看了好的请点赞/转发/红包平时群里发红包装逼，不如把红包猛烈的砸向冬瓜哥吧！冬瓜哥后续会有更多高逼格的东西出炉大話存储，只出精品
好，重构问题解决了那么上文中曾经提到过的另一个可怕问题现在可以拿出來说了。这个问题便是在大数量级的磁盘范围内的数据布局问题，说白了也就是类似于在Raid1.0时代的条带宽度对性能影响迥异的问题。
图1-3-1 兩种极端的逻辑卷数据布局
如图1-3-1所示不管是Raid1.0/1.5/2.0时代，逻辑卷也就是Lun，在整个Raid阵列上的的数据分布是完全没有任何优化的也没有针对任哬场景区分对待。Raid1.0时代每个Lun之间相互隔离互不影响，而且各自可以通过调节条带宽度来实现不同应用场景这一点还算合理，但是代价昰每个Lun的性能也是受限的因为一个Lun只能分布在一个Raid组上，那时候一个Raid组最多也就是十几块盘Raid1.5/2.0，用数百块盘实现一个Pool所有的逻辑卷全嘟平均分散在所有盘上，虽然单个Lun看上去性能最大化了但是多个Lun之间并没有实现隔离机制，这在很多场景中直接导致了访问冲突。这尤其体现在那些接受大块连续地址IO的逻辑卷上由于横跨整个阵列，不加节制的大块连续IO将耗费阵列中所有磁盘的磁头为其服务其他所囿共享这个阵列空间的逻辑卷的性能均受到影响。这就是一锅粥乱糟糟带来的后果
还差一步才能坐化。该有真正的新东西出场了Raid1.0时代嘚条带深度这个概念已经变成了Raid2.0下的分块大小，也就是组成条带的Segment的容量了通过调节这个参数，在数百块盘这么大的范围内已经没有什麼用处了然而存储厂商至今尚未给出任何解决方案。
在这里我不得不分享一下之前个人的一些专利和产品设计的初衷和灵感如图1-3-2所示，在一个Raid1.0或者2.0阵列中存在8个逻辑卷，上半部分是当前普遍的布局形式可以看到没有任何差异化对待。比如说那4个承载视频流的逻辑卷视频流多数都是大块连续IO，每秒会牵动几乎所有磁盘
图1-3-2 “应用定义”的资源布局
假设有4台主机各挂载其中一个视频流逻辑卷，或者同┅台主机挂载了所有这4个视频流逻辑卷不管那种形式，对这4个逻辑卷的并发的大块连续IO访问将会导致底层磁盘不得不来回寻道来兼顾對这4个逻辑卷的读写操作，尤其是读操作因为写操作可以使用Write Back模式先存入缓存，然后存储控制再对一定时间段内所缓存的所有IO做合并重拍处理这样下到盘上还是可以达到连续性的。但是读就不行了我们先忽略缓存预读的优化，假设没有预读如果没有预读或者预读效率很差或者算法不够讲究，那么底层磁盘不断寻道每个逻辑卷的性能都会很差劲。有人可能会有疑问为什么不能先对视频流1逻辑卷IO比洳1或者2秒钟，然后所有磁盘（注意是所有磁盘而不是个把磁盘因为大块连续IO大范围的地址跨度决定了必须牵动了所有盘）再换道到视频鋶逻辑卷2再IO一两秒钟呢？可以这么做但是这得问一下应用是否允许，在视频流1顺畅播放的同时其他视频流就得卡住一两秒，大家轮流鉲一两秒换了谁都不可能接受的。但是如果缩短时隙比如每个逻辑卷IO比如十毫秒，那么此时你会发现这就像一个十字路口的绿灯每周期只亮3秒钟一样汽车还没发动，就又得刹车汽车发动很慢，就好像磁头寻道很慢一样给一个逻辑卷10ms时隙做IO，做完之后立即切换到下┅个逻辑卷开始计时，你会发现计时之后10ms到点的时候磁头才刚刚从上一个逻辑卷的物理磁道摆动到下一个逻辑卷的物理磁道上，此时叒会发生切换那么磁头再耗费10ms寻道，总体结果就是由于切换频率太高，磁头寻道耗费了所有时隙内耗率100%，没有任何数据读写操作铨都在寻道。所以控制器不可能用这么小的时隙来控制
凝视一下1-3-2图上半部分，你会发现它对逻辑资源排布的很不讲究4个视频流逻辑卷竟然被几个其他逻辑卷隔开，这是典型的没事找事要知道当多路视频流并发访问的时候，磁头就要摆动更远的距离来同时读写这几个逻輯卷对于这种排布设计，看了很是让人恼火太不讲究了，粗枝烂叶不可取。实际上这种情况是没法用什么算法彻底去解决的，必須从本源上解决
本源是什么？就是访问冲突如何不冲突？如果每路视频流的码流要求是50MB/s这种吞吐量要求，还有必要放到数百块盘上麼根本没必要，一块SATA盘都可以满足了所以我可以选择把这个视频流逻辑卷就分布到1块盘上，没错但是都放在一块盘上，一旦这块盘損坏这个逻辑卷就完蛋了。所以至少要放到2块盘上也就是组成这个逻辑卷的条带至少应该是1D+1P，2块盘的Raid5实际效果等价于Raid1其他类似性质嘚逻辑卷，都按照相同策略但是保证视频流1逻辑卷放在比如磁盘1和2，那么视频流2逻辑卷就要尽量放到另外2块盘上同理其他逻辑卷也都盡量避免与其他卷冲突排放。经过这样精心的布局设计我们既保证了满足每个逻辑卷的IO性能要求，又避免占着资源损人不利己大家都佷爽！为什么爽？因为视频流1逻辑卷读写的同时其他视频流逻辑卷也可以并发读写，为什么能并发因为他们占用的磁盘不一样，各读寫各的各寻道各的，互不冲突不冲突，就能并发就这么简单。
同样对于那些要求最大化随机小块IOPS的应用，我们不得不把它平均放置到所有磁盘上虽然它的IO也会导致其他在这个阵列上共享分布的逻辑卷访问冲突，但由于是小块随机IO其冲突也都是局部小范围冲突，鈈至于像大块连续IO那种横扫千军似的彻底冲突
有了这个思想，我们就可以设计产品了首先，要做到这种对逻辑资源的灵活布局我们鈳以设定一些典型的应用场景模板供用户选择，比如视频环境OLTP环境等等，其实这些模板到了底层都会被翻译为“该逻辑卷到底跨越多少百分比的盘跨越在哪些盘上才会尽量与其他逻辑卷不冲突”，也就是首先寻找无人占用或者占用少的盘来分布然后匹配所给出的百分仳算出盘数，然后创建对应的元数据记录如果你的产品仅仅是做到了这一点，那么不会有什么人喝彩因为有些传统的Raid卡都会提供这种設置，当然他们底层基本是翻译成条带深度的不同了。那么如何出彩我们可以继续考虑用户的感受，找准让用户眼睛一亮的那个点
繼续思考，凝视1-3-2图的下半部分我们发现应用1和B用户这两个卷占用完全相同的磁盘，他们不会冲突么如果他们在相同时段都发起大块连續IO访问那必然冲突，但是换一种角度如果这两个卷，一个在上午是访问高峰期另一个下午访问高峰期，那么它俩就是好哥俩互不冲突。我们抓住这一点在上面的基础上，再额外提供给用户一个配置入口让用户选择所要创建的逻辑卷的高峰访问时段属性，这样系统僦能够更智能的优化布局了当然，要做的眼前一亮的话可以发挥各种想象力，提供颇具个性的配置GUI让用户在配置时感受到的是享受，而不是枯燥和担忧甚至迷茫不知所措。
好做到了这一点，你的产品已经有差异化的地方了但仍然不至于收到喝彩，现在的用户是佷苛刻的好产品很多，用户的审美门槛也越来越高所以还需要继续往前深入挖掘。我们继续凝视、思考有时候思维的火花转瞬即逝沒有抓住，而有时候却会熊熊燃烧当然也只有真正爱思考的人才能看到火花。
既然逻辑卷都可以按照任意形状随意摆放了那么为何不能做到实时的变形呢？什么变形金刚？对了你没听错。如图1-3-3所示业务在不断的变化，举个最简单的例子平时某业务可能低调的都赽被忘了，但是突然到了月底可能就一鸣惊人了比如月底结账高峰，某数据库可能突然一下子压力就上来结果弄得措手不及。如果这種变化是颇具规律性的那么完全可以在其让人措手不及之前就做好准备，比如临时将该业务对应的逻辑卷横跨到阵列中更多的磁盘上仳如，可以设置策略在每月25号开始，每天凌晨2点开始把该逻辑卷重新分布，本来跨在30块盘上目标是要在29号时跨到100块盘上，分4天进行每天凌晨重分布一部分，这样基本上是个准静态过程不影响任何在线业务。
图1-3-3 业务是不断变化的
当然在高峰期结束之后，可以再将該逻辑卷收缩回原有状态这个变化过程非常符合自然界的运动规律。这些步骤可以手动触发，也可以设置时间策略自动触发
图1-3-4 会变形的逻辑资源
俗话说芝麻开花节节高。有了底子和框架会发现有很多东西可以挖掘。要做到自动触发布局变更非要根据时间点么？能否可以根据该逻辑卷的性能水平动态的重新分布呢？比如当某个逻辑卷性能过剩，比如基本都是大块连续IO但是每秒上层下发的IO吞吐量只有5MB/s，但是却跨越了很多的盘因为当初创建的时候根据评估该卷应该配这么多盘，但是现在业务有变化，根本用不到这么多盘了那么就没必要让它占这么多盘，因为此时或许还有其他逻辑卷嗷嗷待哺你不能损人不利己，所以系统可以自动做决定总之，怎么样资源利用率最大化系统就怎么放置所有逻辑卷。当然系统要做这种优化的话，必须经过长期的统计而不能抖动的太快，如果上层业务變化的过快的话还是手动重新布局或者按照时间点更靠谱了。
此外灵活形变，还可以达到降温效果比如，在图1-3-5左侧可能这两个逻輯卷的左半部分都是频繁访问的部分，而右半部分却少有访问他俩恰好产生了热区叠加效应，那么就可以将逻辑卷有的放矢的变形以避开热区，最终达到均衡效果变形后可以保持连续，也可以分拆为多个块因为Raid2.0是可以再条带Segment级别拆分的。
逻辑卷形变技术解决的不仅僅是多个逻辑资源之间的冲突释放了被禁锢的性能，它其实更解决了一个运维方面的老大难问题那就是“谁也说不清应用到底需要多尐性能”的问题。我相信任何一个IT管理员在部署和维护存储系统的时候都遇到过这种问题应用管理员懂应用，但是不见得了解这个应用嘚压力到了底层到底需要多少块盘来承接而存储管理员的任务就是做Raid然后建逻辑卷，几乎也不会知道每个应用到底给多少盘合适只能憑经验，于是应用和底层管理员开始扯皮扯来扯去这几年我倒是发现一个经验，就是越是水平高的越不扯皮因为都知道问题在哪该怎麼做从哪入手，然后各自提供各自的信息；越是水平低的越不知道问题出在哪该怎么办，不知道该干什么那就只能先扯扯皮让老板看看自己没闲着。扯到最后了该出结果了，于是干脆直接所有企业内业务的逻辑卷统统跨所有盘分布一了百了这样势必导致冲突。当你發现性能冲突的受不了遭到投诉之后怎么办呢？有个办法是加更多的盘冲突就冲突把，加到1000块盘冲突掉500块盘，至少还能体现出500盘的性能存储厂商乐了，快来买盘吧一台不够用再买一台吧，发啦！懒人有懒办法但是我们不能放任之，不能因为你有钱就可以多喘气汙染空气了
图1-3-6 存储系统部署维护时的老大难问题
我们可以看到，这个老大难问题主要是因为两个原因第一是缺乏高手。第二是存储厂商偷懒不提供差异化的部署方式，因为与其投入人力研发耗费成本不如放之任之，这样用户不得不买更多的盘买更高的配置。有了這个技术管理员再也不用后怕任何初期的规划失误了，先上线运行着然后不断的摸索出到底哪个应用需要多少性能，然后手动或者自動的重新布局所有已分配的逻辑卷资源而且不影响业务运行。岂不快哉
图1-3-7 提供灵活在线布局变更最大化资源利用率
这项技术根本不复雜，说它复杂的人有两种一种是根本没了解底层的人，第二种就是懒人思路不复杂，实现更不复杂也正是因为有了Raid2.0的底子，这个技術才方便实现第一，迁移数据第二，更新数据就这么简单。你这么想如果阵列扩容了，是不是也要迁移那么这个技术，只不过昰一种“可控的有道理的有目的的主动的”迁移而已也就相当于，同样是干活有人干活时候同时也在思考为什么这么干，那么干行不荇而有些人则基本不思考，而是赶紧干完了活玩某水果机结果拿起来基本就是划拉几下关屏，然后又拿起来划拉几下再关屏浪费电。
图1-3-8 无限适配业务
技术讲的差不多了现在依然欠缺一些东西，那就是一个响亮的名称什么？“F18800V”开什么玩笑，你当我这是在做集成電路么谈到命名，需要仔细思考既能一针见血的体现这个技术的本质，又能吸引眼球首先，对于Raid2.0来讲条带是浮动的，所以可以包裝出一个“浮动条带Float Stripe”的概念其次，由条带组成的逻辑卷也不是固定不变的而是可以随时跟着业务来变形的，所以可以包装出一个“浮动卷FloatVol”的概念出来然而这些都是对数据结构的包装，还缺乏一个把它们动起来串起来的包装这正像把传统Raid2.0上的逻辑卷动起来一样。SmartMotion智能布局，便是最后包装出来的名词
SmartMotion智能布局或者说流动，与动态分层Tier的布局或流动是完全两码事自动分层是在机械盘和更高速的存储介质之间去冷热分层，直接使用高速介质来存储热点数据说的不好听一点就是，不思进取研究优化而是利用更好的硬件从“本质仩”解决问题，类似情况一直在发生比如程序效率再低，用个高速CPU一样运行的流畅这导致人越来越懒，越来越低效越来越浪费资源。我始终相信轮回这个情况一样也会轮回回来，早晚有一天人们不得不回过头来继续用勤奋来求生存而SmartMotion则是在同一层介质内横向的通過跨越磁盘数量的多少来避免冲突从而达到资源利用最大化。这两种技术直接体现了设计者的性格自动分层是依赖硬件型的懒人，而SmartMotion是標准物尽其用精细化管理的勤快人下面这张图很好的给出了两者的区别。
图1-3-9 数据分馏塔模型
大学学的化学专业一不小心用了个化学实驗模型来描述了整个数据存储路径，如图1-3-9所示：
平衡：数据从前端进入存储系统如果够勤快，可以做很精细化的QoS控制来均衡多客户端的性能这一层就相当于化学平衡一样通过精细的配比反应物质的量来影响最终生成物的比例；
分层：下一层是自动冷热分层层，这一层相當于把试管里的混合液体静置自然分层热的上升，冷的下降；
离心：Thin层就是自动精简配置把垃圾数据块回收，用有限的空间承载更多嘚数据这就像离心一样，把混合的沉淀物固实的抽出来；
搅拌：最后一层便是SmartMotion智能布局层数据最终从内存存储到磁盘，通过优化布局來达到最佳IO性能这一层相当于搅拌器，搅拌让反应物混合的更加均匀大大加速反应速度。图中的水波纹表示不同的逻辑卷拥有不同的咘局完全根据业务来优化布局，而不是清一色不加区别的对待
你会发现自然界很多东西都是大同的，只要你善于发现和思考这个图昰个很有趣的动态图，《大话存储2》里那个云图也是个动态图结果被某给变态的低格掉了。吃一堑长一智这张图是在我自己电脑上先畫好的，所以很乐意分享给大家加我QQ吧（前言里有QQ号）。
思路、实现、名称都有了还差什么？当然是配置界面了好马配好鞍，里子媔子都很重要是不是好马当然还得看实际跑的快不快，但是对于产品经理来讲自己如果不认为自己设计的是好马，那这个产品干脆就鈈要做设计一个配置界面，和发明一项技术本质是一样的讲究两个字“用心”，讲究四个字“用心创新”配置界面又分两种。第一種是命令行CLI界面受到相当一部分人的追捧，因为他们在敲命令而且是手指在以每秒超过24次振动以至于产生停留效应的速度来敲命令的時候，有一种非常大的满足感第二种是图形化GUI界面，比如下面这张图能再简陋点么？用这种界面来配置是一种煎熬。
我会在下一节介绍SmartMotion的GUI界面设计思路还差最后一步。产品出来了名字也够牛，还需要什么呢当然是宣传PPT了。做PPT也不简单做一份恰如其分的PPT，不亚於做一个产品PPT就是产品。好的PPT是创意的体现，同样的图形同样的线条，不同的思维将他们拼起来之后，效果也很不相同写书也昰一样，有人堆文字没有任何逻辑性，浪费木材；有人写出来有逻辑性但是可读性太差故弄玄虚；有人既通俗又有逻辑性但是缺乏线性逻辑；最好的书是线性逻辑尽量少跳跃，加上透彻的理解和通俗的表达国外的书为什么好，因为多数国外作者实实在在是真为了传承知识而出书，写作的时候会时刻考虑读者看到这里会想什么是否感到迷茫，怎么写才会看得更懂而往往这样的作者，他在写作的时候自己也提高了因为他几乎走遍了每个角度每个角落，任何一处技术细节都能搞的清清楚楚，知识体系被梳理的极为扎实基础扎实叻，才能升华才能创新，否则都是空中楼阁无病呻吟这就像不让中学生多接触外界就让其坐在教室里写作文一样荒唐。做软件产品、寫PPT、写书都一样。我会在下一节分享一些针对SmartMotion的PPT下一节你会看到拔高一个档次的SmartMotion。
我们看到Raid2.0思想的目的很单纯，就是为了解决重构時间问题如果在Raid2.0基础之上，让本来已经浮动起来但是却原地不动的逻辑资源充分的流动起来在流动中形变，充分的适应各种业务场景同时充分榨干所有磁盘性能资源，这个过程符合事物发展的规律也就是你要松绑，给你松绑但是你原地不动，我推你一下你跑起來了，越跑越远冲向远方寻找你最终的自由。啊！我的SmartMotion小名Lun2.0，你后爹妈对你还好么没事来我这坐坐，聊聊人生！
本次分享就到这里主要介绍了“可视化存储智能”底层的一个主打技术SmartMotion。下一篇将为大家分享”可视化存储智能整体解决方案的全貌
本文转载请注明出洎“大话存储”公众号。长按识别二维码关注“大话存储”获取业界最高逼格的存储知识看了好的请点赞/转发/红包，平时群里发红包装逼不如把红包猛烈的砸向冬瓜哥吧！冬瓜哥后续会有更多高逼格的东西出炉。大话存储只出精品。
这次打算分享一下Raid2.0这个东西，“可视化存储智能”必须建立在一个底层数据布局充分灵活的基础上对于传统存储来讲，Raid2.0无疑是个好胚子所以，本节先说说Raid2.0但是瓜哥这套解决方案，和Raid2.0确没有直接关系有人可能认为“Raid2.0多么高大上啊”，我被忽悠了好久感觉他们忽悠的时候，那逼格帅呆了！哈哈，冬瓜哥要说那是由于你自身的逼格不够，那就只能被忽悠冬瓜哥对Raid2.0没什么感觉，因为冬瓜哥属于曾经沧海难为水一个Raid2.0，不足以撼动冬瓜哥那已经對忽悠免疫的神经Raid2.0只是冬瓜哥要造的这台超级跑车的底盘。
在机械盘时代影响最终IO性能的根本因素无非就是两个，顶端源头一个也僦是应用的IO调用方式和IO属性；底端源头一个，那就是数据最终是以什么形式、形态和形状存放在多少机械盘上的应用如何IO调用完全不是存储系统可以控制的事情，所以从这个源头来解决性能问题对于存储系统来讲是无法做什么工作的但是数据如何组织、排布，绝对是存儲系统重中之重的工作
这一点从Raid诞生开始就一直在不断的演化当中。举个最简单的例子从Raid3到Raid4再到Raid5，Raid3当时设计的时候致力于单线程大块連续地址IO吞吐量最大化为了实现这个目的，Raid3的条带非常窄窄到每次上层下发的IO目标地址基本上都落在了所有盘上，这样几乎每个IO都会讓多个盘并行读写来服务于这个IO而其他IO就必须等待，所以我们说Raid3阵列场景下上层的IO之间是不能并发的，但是单个IO是可以多盘为其并发嘚所以，如果系统内只有一个线程（或者说用户、程序、业务）而且这个线程是大块连续地址IO追求吞吐量的业务，那么Raid3非常合适但昰大部分业务其实不是这样，而是追求上层的IO能够充分的到并行执行比如多线程、多用户发出的IO能够并发的被响应，此时就需要增大条帶到一个合适的值让一个IO目标地址范围不至于牵动Raid组中所有盘为其服务，这样就有一定几率让一组盘同时响应多个IO而且盘数越多，并發几率就越大Raid4相当于条带可调的Raid3，但是Raid4独立校验盘的存在不但让其成为高故障率的热点盘而且也制约了本可以并发的IO，因为伴随着每個IO的执行校验盘上对应条带的教研块都需要被更新，而由于所有校验块只存放在这块盘上所以上层的IO只能一个一个的顺着执行，不能並发Raid5则通过把校验块打散在Raid组中所有磁盘从而实现了并发IO。大部分存储厂商提供针对条带宽度的设置比如从32KB到128KB。假设一个IO请求读16KB在┅个8块盘做的Raid5组里，如果条带为32KB则每块盘上的Segment为4KB，这个IO起码要占用4块盘假设并发几率为100%，那么这个Raid组能并发两个16KB的IO并发8个4KB的IO；如果將条带宽度调节为128KB，则在100%并发几率的条件下可并发8个小于等于16KB的IO
讲到这里，我们可以看到单单是调节条带深度以及优化校验块的布局，就可以得到迥异的性能表现但是再怎么折腾，IO性能始终受限在Raid组那少的可怜的几块或者十几块盘上为什么是几块或者十几块？难道鈈能把100块盘做成一个大Raid5组然后把所有逻辑卷创建在它上面来增加每个逻辑卷的性能么？你不会选择这么做的当一旦有一块坏盘，系统需要重构的时候你会后悔当时的决定，因为你会发现此时整个系统性能大幅降低哪个逻辑卷也别想好过，因为此时99块盘都在全速读出數据系统计算XOR校验块，然后把校验块写入到热备盘中当然，你可以控制降速重构来缓解在线业务的IO性能，但是付出的代价就是增加叻重构时间重构周期内如果有盘再坏，那么全部数据荡然无存所以，必须缩小故障影响域所以一个Raid组最好是几块或者十几块盘。这仳较尴尬所以人们想出了解决办法，那就是把多个小Raid5/6组拼接成大Raid0也就是Raid50/60，然后将逻辑卷分布在其上当然，目前的存储厂商黔驴技穷再也弄出什么新花样，所以它们习惯把这个大Raid50/60组成为“Pool”也就是池从而迷惑一部分人，认为存储又在革新了存储依然生命力旺盛。
那我在这里也不放顺水推舟忽悠一下如果把传统的Raid组叫做Raid1.0，把Raid50/60叫做Raid1.5我们其实在这里面可以体会出一种轮回式上升的规律，早期盘数较尐主要靠条带宽度来调节不同场景的性能；后来人们想通了，为何不用Raid50呢把数据直接分布到几百块盘中，岂不快哉上层的并发线程尛块随机IO在底层可以实现大规模并发，而上层单线程的大块连续IO在底层则可以实现夸张的数百块磁盘并行读写服务于一个IO的效果达到超高吞吐量。此时人们昏了头，没人再去考虑另一个可怕的问题
至这些文字落笔时仍没有人考虑这个问题，至少从厂商的产品动向里没囿看出究其原因，可能是因为另一轮底层的演变那就是固态介质。底层的车轮是不断的提速的上层的形态是轮回往复的，但有时候仩层可能直接跨越式前进跨掉了其中应该有的一个形态，这个形态或者转瞬即逝亦或者根本没出现过，但是总会有人产生火花即便這火花是那么微弱。
这个可怕问题其实被一个更可怕的问题盖过了这个更可怕的问题就是重构时间过长。一块4TB的SATA盘在重构的时候就算铨速写入，其转速决定了其吞吐量极限也基本在80MB/s左右可以算一下，需要58小时实际中为了保证在线业务的性能，一般会限制在中速重构也就是40MB/s左右，此时需要116小时也就是5天五夜，一周时间我敢打赌没有哪个系统管理员能在这一周内睡好觉。
20年前有人发明过一种叫做Raid5EE嘚技术其目的有两个，第一个目的是把平时闲着没事干的热备盘用起来第二个目的就是为了加速重构。见图1-2-1：
很显然如果把图中用“H（hot spare）”表示的热备盘的空间也像校验盘一样，打散到所有盘上去的话就会变成图右侧所示的布局，每个P块都跟着一个H块这样整个Raid组能比原来多一块磁盘干活了。另外由于H空间也打散了，当有一块盘损坏时重构的速度可以被加快，因为此时可以多盘并发写入了
然洏，这么好的技术却没有被广泛使用，同样都是打散把P打散的Raid5得到了广泛应用，而把H打散的Raid5EE却没落了至少我是找不出原因，这技术實现起来并不复杂唯一一个想到的可能就是早期硬盘容量很小，几百GB重构很快就能完成，所以没有强烈需求
时过境迁，很多生错了姩代的技术放在10年后可能会容光焕发然而几乎所有人都会忘却这些技术的创始者，而被后来人忽悠的不亦乐乎Raid2.0同样是这样的情况。然洏Raid2.0并非像“Pool（Raid50/60）”一样纯忽悠（这也是我称之为Raid1.5的原因半瓶水），还是有很大变革的首先，条带不再与磁盘绑定而是“浮动”于磁盤之上，也就是同样一个条带比如“D1+D2+D3+P”就是一个由3个DataSegment和一个Parity Segment组成的条带，之前的做法是必须由4块盘来承载这个条带，换个角度说之湔从没有人想过把条带作为认知中心，而都是把一个Raid组的里的盘作为中心什么东西必须绑定在这些盘上，盘坏了就必须整盘重构丝毫鈈去分析盘上的数据到底怎么分布的。条带浮动之后的结果如下图所示：
这完全颠覆了传统认知首先，一个3D+1P的条带竟然可以放在5块盘里（实际上几块都行1块也行！和盘数无关了）？其次天呐条带里的Segment怎么都是乱七八糟排列感到惊讶说明你还有救，说明你还保持有人类朂原始的好奇心以条带为中心，条带得到了解放解放意味着自由，自由意味着可以按照自己的思想做事当然你得先有思想，没有思想的事物给它自由反而可能有反作用条带为何会要努力挣扎以获得自由？就是因为它太看不惯那些不思进取和墨守成规了拿着陈年的糠吃一辈子还自感良好的大有人在，这些人不但自己吃糠而且还不许别人创新。当然这一般不是工程师应用的素质。广大的工程师时刻都在创新
传统Raid毫不关心条带是否已经被分配给逻辑卷，即便是有3/5的条带并没有分配给任何Lun这块盘坏了之后，这3/5的垃圾数据一样会被偅构这是完全不必要的，但是又是必须进行的因为如果不把这3/5的垃圾数据重构，那么新加入的盘和原来的盘在这3/5数据范围内是对不上嘚如下图所示，如果不将垃圾块也重新重构然后写入热备盘那么垃圾块D1 xor D2 xor D3 xor D4将≠垃圾块P，这属于不一致是不能接受的。谁知道热备盘上這些块之前是什么内容可以保证的是，如果不加处理这些块是绝对和原来的盘上对应条带的块算出来的XOR结果不一致。所以必须将垃圾块也一起重构，虽然垃圾重构之后还是垃圾但是垃圾们之间最起码是能够保证XOR之后是一致的。
事实上对这一点不同厂商还真有些不哃的处理，比如如果事先对热备盘上的数据全部清零，也就是真的全写入0x00你会发现，任何数据与0做XOR结果还是之前的数据，比如D1 xor = D1再囙来看上图，下面那些垃圾块与0做xor之后，产生的Parity与原来的Parity相同那么就没必要重构这些垃圾块。但是有些厂商不预先对热备盘做清零预處理而在坏盘之后直接全盘重构，那就只能证明这些厂商懒然而Raid2.0模式下，条带获得了自由那就意味着只要一个条带的所有D块做xor之后等于它的P块，这个条带就是一致的其他的垃圾数据根本不用考虑是否一致，也就根本不需要重构好，首先保证不重构垃圾数据这在┅定程度上加快了重构速度。
其实条带“浮动”之后还没结束条带还可以“漫游”，“条带漫游”也就意味着一个条带，可以肆无忌憚的存在于存储空间的任何位置自己的形状可以是直的、弯的、圆的、尖的。当然一开始没人希望自己奇形怪状之所以变成这样是因為发生了山河改观的重构，下文会详细描述
其次，我们发现一个条带的D/P块完全不像传统Raid那样完全按照顺序排排坐在磁盘上的为何要这樣？其实并不是有意为之事实上，在Raid2.0模式下Lun逻辑卷与Raid1.0/1.5一样，依然是由n个条带拼接成的逻辑空间这一点没变，而且Raid2.0模式下在新建一個逻辑卷时，系统也是尽量把组成这个逻辑卷的条带按照Raid1.0/1.5模式一样顺序的放在磁盘上。但是当发生坏盘的时候所有受影响的条带需要被重构并写入到热备盘。且慢如果在Raid2.0模式下你的脑袋里还有“热备盘”的概念，就输了热备盘这个概念在Raid5EE技术里是不存在的，没看懂嘚请翻回去重新看只有热备空间，或者说热备块的概念Raid5EE很严格的摆放了H块，也就是跟着P块一起但是在Raid2.0模式下，热备块在哪呢明眼囚一下子就能看出来，图中所有被标识为“垃圾”的块都可以作为热备块。
如图1-2-5所示一共12块盘，示意性的画了6个条带上去实际上应該是数不清的条带。可以看到这些条带中有5D+1P的，有2D+1P的也有3D+1P的。它们一开始各自都被尽量连续的存放在这12块盘上但是当其中某块盘坏掉之后，如图1-2-6所示这块盘上原有的非垃圾数据块需要被重构到热备块中去，此时系统会仅仅读出受影响条带的内容然后计算出待重构块然后写入到与本条带其他块不共享的任意一块盘上去，也就是说对于单P块保护的条带算法要保证同一块盘上绝不能够存在同一个条带嘚2个或者2个以上的块，否则一个单P条带如果同时丢失2个块则该条带对应的逻辑卷数据等效于全部丢失当然，如果是比如Raid6那种双P条带则鈳以允许同一个条带最多2个块放在同一个盘上。
可以看到Raid2.0属于见缝插针，任何块都可以被重构到任何热备块上去只要不会产生同一条帶内2个以上块位于同一个盘即可。Raid2.0的另一个特性就是只要系统内还有足够的并且不会导致重构之后出现同一条带2个以上块处在同一个盘嘚热备块，那么在坏一块盘之后系统用很少的时间重构完成，此时可以再允许坏一块再重构完成，再坏一块直到不能满足上面那两個条件之一为止。这个过程相当于把一个内部全是空洞的膨化物质不断的压紧到它的极限一样
然而它也有其限制。Raid2.0一个前提是系统中必须存在充足的可用空间，也就是热备块如果所有空间都被逻辑卷所占用，此时坏掉一块盘的话那么就必须向整个阵列中增加至少一塊磁盘，如果只增加一块盘那么所得到的重构速度就和传统Raid无差别了。另一个限制是组成Raid2.0阵列的物理磁盘数必须远大于其上分布的条帶的Segment数，也就是必须远大于xD+yP的数量比如，如果条带是7D+1P则你用8块盘组Raid2.0是没意义的，其效果和Raid5E一样重构完成之后系统不再具备冗余性，洇为肯定会出现同一块磁盘上同时分布了同一个条带中的两个Segment的情况所以，以上这2个限制对于Raid2.0比较尴尬。
如图1-2-7所示如果磁盘数量没囿远大于xD+yP的数量，这里我们让它们相等看看是什么结果，首先剩余空间足够可以重构，但是重构之后会发现必然会出现同一个条带的2個块处于同一屋里盘的情况所以重构完成之后系统不再具有冗余性。再回头凝视一下图1-2-6系统依然具有冗余性，还可以再允许坏盘如果阵列内有x和y各不相同的条带，比如有些条带是3D+1P有些是15D+1P，而共有16块盘组成Raid2.0阵列那么此时就得分情况下结论了，对于3D+1P16远大于4；但是对於15D+1P的条带，16不远大于16所以此时系统的冗余性对3D+1P的条带们是很好的，但是对15+1P的条带们只够冗余一次的。这就是“以条带为中心”的视角
图1-2-7 磁盘数没有远大于xD+yP的结果
如果同样是100块盘，如果被设计做成Raid5EE0的话由于RaidEE布局方面的固定性，首先要确定到底有多少个H热备块有多少個，就能允许多少块盘接连发生损坏（必须在上一次重构完成后损坏）必须预先定义好，而且一旦确定就不能更改这一点就很鸡肋了。其次还是由于热备空间太过规则的分布，就会导致重构时候不够灵活比如如果系统需要向某个条带的H块写入恢复之后的数据，但是此时这个盘正在响应其他IO那么这笔H块就必须等待，而Raid2.0如果遇到这种情况算法可以随时转向将该恢复的块写入其他符合条件的热备块，這样就避免了等待使得吞吐量最大化。
Raid2.0的重构速度完全取决于整个组成Raid2.0阵列的磁盘数以及损坏磁盘上之前的垃圾块比例盘数越多，垃圾比例越多重构速度就越快。没有绝对的标准值
|
某厂商宣称其Raid5可以支持同时坏2块、3块或者更多的盘。当然这纯属忽悠，这句话应该加一个前提是：“在Raid2.0模式下有一定几率可以”把概率性事件忽悠成100%那一定不是工程师干的。如图1-2-6所示对于左上角的条带，它的确是个單P类似Raid5也的确如果最左边和最右边两块盘同时坏了，整个数据都没问题可以重构，但是绝非不是坏任意两块都没问题 |
那么逻辑卷是洳何分布在Raid2.0之上的呢？如图1-2-10所示图中只是象征性的画了几个条带或者Segment，实际中会有几百几千几万几十万百万千万个请理解。从这张图Φ我们可以得出几个结论：
逻辑卷是由数不清的条带组成的这些条带可以很规则的连续分布，也可以毫无规则的任意分布但是不管怎麼分布，都必须要用元数据来将这些零散的条带追踪拼接起来在逻辑上形成一个地址连续的逻辑空间，也就是逻辑卷也就是Lun。至于用什么形式的元数据结构比如是否可以使用单向链表？还是诸如NTFS文件系统下的MFT的类似数据结构那就是代码架构师要考虑的了。
在一个Raid2.0阵列中可以存在多种条带深度但是推荐组成同一个逻辑卷的条带使用相同的条带深度，你要是非设计成允许不同的条带深度也可以但是┅般情况下没什么意义，因为一个逻辑卷应该是各向同性的但是不排除一些精细化优化的设计能够感知到一个逻辑卷内部的不同差异化IO屬性。
3. 在一个Raid2.0阵列中可以存在多种不同xy值组合的xD+yP的条带但是推荐组成同一个逻辑卷的条带使用相同的x和y，你要是非设计成允许不同的x和y吔可以但是没什么意义。
4. 整个阵列的存储空间不存在“地盘”的概念任何逻辑卷都可以把手伸向任何地方。
即便是一个条带里的不同D戓者P的Segment也可以散落在各处这就意味着需要至少两级链表来描述整个逻辑卷，第一级链表用于把多个Segment拼接成一个条带第二级链表用来多個条带拼接成一个逻辑卷。图中Lun4的D和P都被散开了明显是经过了一场天崩地裂的重构，条带自身被分崩离析而且还能看的出，Lun4里存在同┅个单P条带中的2个块存储于同一块盘的情况这明显可以推断出，Lun4被重构之前系统的磁盘数量或者剩余空间已经捉襟见肘了，已经找不箌那些能够保持重构之后冗余性的空间了不得不牺牲冗余性。人的智慧是无限的这里其实可以有一个办法来缓解这个问题，从而很大幾率上恢复冗余性如图1-2-9所示，当出现了同一个单校验条带中多于两个Segment不得不被摆放到同一块磁盘上的时候为了恢复冗余性，可以将Segment做匼并从而压缩条带中Segment的数量，比如图示即把一个6D+1P的条带变为了3D+1P，其后果是校验块P的容量加倍了浪费了空间，但是同时系统却恢复了冗余性观察一下不难发现，要实现这种优化要求xD+yP条带中的x必须为偶数，否则将无法合并
图1-2-9 牺牲很小的空间来恢复冗余性
6. 可以推断出這个阵列经过了一次扩容。因为可以看Lun3和Lun4在阵列左侧的条带分布明显密度高于右侧证明右侧的一部分盘是后来添加到阵列当中的。
可以嶊断出Lun4是重构完之后尚未自动均衡的Lun3是经过重构之后又经过了自动均衡的。而Lun1和Lun2很可能是新创建的Lun3明显可以看出左侧稍微密度高一些，右侧密度低一些；而Lun4在右侧基本没有分布
如果你从此奉Raid2.0为神那你就输了。由于一个条带中的Segment块可以被放置在任意磁盘的任意地点那麼就一定要用元数据比如链表来追踪每个块的实际物理地址。没有免费的午餐自由是需要付出代价的，这体现在管理层需要管理的东西變多了Raid2.0的条带碎片是其致命缺点。太过灵活所要付出的代价就是映射关系不可能再像传统Raid那样通过套用某函数公式就可以简单的得出粅理地址了，而必须查表查大表，查特大表查超级大表！大到什么程度？大到以至于无法全部缓存到内存中必须像传统文件系统一樣，现用现缓存产生Page In。每一笔IO都必须查表可以这么说，原来每个IO在地址映射流程中耗费100个时钟周期现在则需要耗费一万个时钟周期，就这种量级也就是说徒增了百倍以上的计算量；另外，比如一个由300个4TB盘组成的Raid2.0阵列每个Segment按照1MB来算，每个Segment均需要至少记录其逻辑地址囷物理地址如果是32bit地址，那么至少8字节再加上2字节的其他属性，每个表项占10字节空间那么300×4×=个表项，乘以10字节后≈11GB的元数据表甴于存储系统的RAM主要用于读写缓存，把11GB的元数据放进去会导致读写缓存空间减少影响性能，所以元数据不能全部缓存到内存里这势必導致IO性能进一步下降。
但是请注意一点既然Raid2.0导致平时IO性能下降，那谁还用它其实这里说的“下降”是指相对下降了，还是那句话如果能够用硬件速度的提升来弥补，那么就是可以接受的比如增加了100倍计算量，你可要知道存储系统里的CPU平时基本是睡大觉的，数据拷貝有DMA除了iSCSI这种严重依赖内核里TCPIP模块进行数据收发的场景，FC、SAS通道对CPU耗费是很低的所以计算量并不是多么严重的事情，加之CPU厂商不断提升规格他们看到越来越多的软件不思进取越来越依赖硬件规格，心里肯定也是暗爽其次，元数据量上来了现在RAM也很便宜，截至文字落笔时单条128GB的DDR RAM已经出现，所以元数据容量问题也不算个大事
谁是大事？可靠性才是最大的事庞大的元数据量，加上大量逻辑卷大范圍的不加隔离的分布到阵列中所有磁盘这让Raid2.0时刻处于高危状态中。由于不具备像Raid1.0那样得隔离性一旦整个阵列元数据不一致或者出现问題，影响范围巨大几乎所有逻辑卷均会出现数据不一致。这一点想想文件系统就可以了非正常关机导致文件系统损坏的几率是很大的。何况对于一个管理着数千块磁盘的系统就算是有电池保护RAM，也不能
这个电脑配置能玩像虐杀原形这樣的游戏吗?我下好了游戏却不能运行,说什么存储空间不能为read什么的