MWC

MWC"/>

MWC

机密度——3/5
复杂度——3/5

MWC和VGSA，LTG有关。注意，VGSA, MWC只与mirror有关，没有mirror的根本不会有这类的问题。VGSA全称是VG Status Area，也就是VG状态信息。每个PV至少有一个区域用于VGSA，最多有两个，之所以可能有两个，是为了在PV数是偶数个的时候保证Quorum仲裁不会混乱。Quorum是谁多谁说了算，如果偶数个PV，一半PV有问题（这在容灾场景很容易出现），那边是好的呢？就要靠那个有2份VGSA的PV了！看官说了，那个有两份VGSA的PV坏掉怎么办？汗。。。只能说尽力吧，每种理论的现实实现都是有优缺点的，在产品之间竞争时，只要我的实现方案比对手产品更不容易出错，更容易恢复，更快，更好管理，那我就赢了。与其它操作系统的LVM方案相比，至少AIX LVM看起来是一个比较好的方案，是（暂时）最终赢家，至于以后输给了外置存储、超融合存储，那是少林长拳输给洋枪洋炮的后话，达摩祖师已经尽力了。

言归正传，AIX操作系统每次IO的时候，都要更改VGSA么？而VGSA中PP stale的标记最多只有1016个，这是不是系统瓶颈呢？更改也太频繁了吧？而且VGSA也在磁盘上，每次更改VGSA是否也对应一次物理IO，如果这样，这不是出现了死循环了么？也就是写磁盘要更新VGSA，更新VGSA导致写磁盘。其实，这部分并不冲突，因为只有更改PP逻辑信息，才会更新VGSA，而写PP的数据不会触发更新VGSA。写PP数据需要写的是MWC控制区域，并不是全部VGSA。当然，由于每次IO都可能因此MWC变化，写MWC是存在性能问题的，AIX为了解决这个问题，采用了两个妥协的方案：

1. MWC并非只在磁盘上存在，在内存中是有一份copy常驻的，这样，任何更新磁盘PP的操作，首先更改的是内存中的MWC信息，并没有真正写磁盘，只有到了某个特定的时候，才会写磁盘，也就是采用了类似数据库SCN的方案，阶段性提交，这样就减少了更新磁盘MWC的次数，具体细节一会再说。
2. 磁盘的写操作是经过切割或者聚合的，如果大于LTG，则以LTG为单位，切割成小块；如果小于LTG，但IO是连续的，则通过pbuf进行聚合。
3. VGSA包含MWC区域，但不仅仅是MWC，大部分写操作都是写数据，只有可能更新MWC，而不需要更新VGSA其它的地方。两份VGSA是否对应两份MWC需要更新？这个我不确定，以后我找到理论依据再说，先按一份MWC考虑。

通过这两个方案，大大减少了更新磁盘MWC的次数。另外，为了配合阶段性提交，AIX也弄出了一个日志去保护提交的数据。注意，这个日志不是JFS/2 Log，是VG中隐藏的，在每个PV上将保留最后62次PP的IO的信息，就是记录了最后62次都是哪个PP被更新了。再次注意，不是数据而是信息，也就是只记录了那块数据被更新，但是并不记录更新数据本身。由于每次IO最大为LTG大小。这块数据就是著名的MWC机制/区域，这块区域在磁盘的最外角，也就是磁盘最快的位置。不过这个位置对于现代RAID阵列和智能存储已经没有任何意义，这是题外话，暂且不提。我们现在就按照磁盘写入数据的过程再走一遍，看看这个过程具体是怎样的。当然，我们只在LVM这层观光，对于上层的文件系统、数据库怎么写，不是本文的范畴，以后再侃。同时，我们要说的是包括Mirror和mwc的，如果没有这两个特别东西，也就不需要讨论了，该怎么写就怎么写吧。

数据写LV，被拆或组合，弄成LTG大小，如果真的没有LTG大，并且也不能组合，例如非连续的位置，那么该多大就多大，但也会占据一次IO。此处先插播一句，由于LTG直接影响了IO次数，如果能把系统平均IO大小调大，等于LTG大小（或稍小一点），则是性能优化的要点之一。当然，还有很多细节问题，例如对齐啦，LTG多大合适啦，如果现在讨论，就岔得太远了，大家先记下来，过几天提醒我。

下面，真正写磁盘了，在写某个IO之前，系统会先更新内存中的MWC cache，标记要写这块了，然后就写，如果写的是同一区域，只更新MWC cache，并不写磁盘，就是如果新IO写与最近62次IO之一写到了同一位置，后一次写将替换前一次写，磁盘上的MWC并不更新，只有要写的数据不在这62块之内，既位置与最后62次IO不同，才需要把MWC写磁盘，以便空出一个位置给新的LTG IO，确切来说，MWC记录的不是最后62次IO,而是最后62个存在IO操作的位置。好，现在发生crash了，发生crash还好？当然好，需要我们动脑筋思考，反正数据不是我银行帐号里的钱。不同时刻发生crash的后果不同，我们依次来看：

写MWC -> 完成MWC写 -> 磁盘IO写 -> 完成磁盘IO写

crash在写MWC内存cache的时候或者更新磁盘MWC之前。这时crash，什么事都没有，因为真正写盘还没开始呢。系统reboot之后，磁盘上的是旧MWC，跟MWC完好写完的效果一样，都是对MWC标记的62个IO所在PP，也只需要对这62个PP进行重新同步，最多也不过更新几个GB的数据，几秒钟就能完成。

crash正好在MWC cache写磁盘的时候发生，无巧不成书，就是有这么巧的时候。由于MWC非常小，只有512字节，那么MWC只存在写完或者没写两种情况（有位兄弟问，那MWC写了一半怎么办？例如写完前256字节磁盘就没电了。。。这个问题你找磁盘生产厂去。。。我无法回答，磁盘工厂要保证这块数据只存在完成或没操作两种状态，不存在中间状态）。由于MWC有多份，每个PV 1份，因此可以依靠quorum的方案去恢复。要是恰好有多份不同，这。。。。也不是不可能发生的，AIX无法处理这个问题，但这种可能性非常小，因为：MWC只有512字节，写512字节只需要一次寻道到磁盘边缘的时间，既然所有磁盘的MWC写都是同时发生的，他们相差的时间最多是完成当前性能最差磁盘queue的时间，一块盘，不可能有不一致；两块或多块磁盘，最差情况就是完成scsi queue depth的时间。由于每次MWC写变化的只有一个LTG的位置，也就是说61个项目都相同，只有一个IO不同，一个IO数据不一致。scsi queue depth通常是20-256，而单独IO的时间一般是若干毫秒，以每天写100G数据为例，只有在一天特定的某几秒钟时间(大约是6秒）发生特定的故障，才会导致这种不一致，我估计我这辈子是碰不到了。并且，即使出现了这种不一致，也并不是说无法恢复，因为MWC还有一个备份；因为不一致并不一等于说数据错了，更重要的是实现一致，至少胡乱选择还有一半可能。即使选错了，也只是说明数据做了回退，没有用最新的数据而已，更高层的jfs log或者数据库回滚操作是解决这一类问题的手段。再强调一下，MWC是管数据镜像是否一致，不一致则用哪份数据去覆盖另一份，并且需要考虑到的数据只有区区62个PP，而无需对全部数据做一次完整比对，MWC机制是为了镜像的快速一致同步存而设计的。镜像为了保护数据，MWC为了保证被保护数据一致，不一致时用哪一份数据恢复，并且恢复时间很快。

crash发生在MWC cache写磁盘之后，由于数据没有真正写磁盘，但MWC认为已经写了，没关系，MWC都记录了哪些IO块被更新（其实是LV的LP），选择这些LP的一份copy同步其他的copy,数据没有真正写磁盘，所有这些copy的数据都是旧了，也就是都是一致的，不过再覆盖一遍而已，没有任何影响。

crash发生在磁盘IO写之前。与上例相同。

cash发生在LTG写之中，这时候，由于写操作是并行发布的，完成执行时间不同，几份LP copy的内容很可能不一样，有的写完，有的刚开始。无论发生了什么，MWC机制知道这个LP是哪个，于是就随便选择（一般是第一份copy）LP的一个copy去覆盖其它的copy。这种方案很不负责任，但它是MWC存在的最主要目的——保证数据（不同copy）的一致性，而不是正确，正确性是高层系统保证的，例如JFS log, 数据库log等等（好啰嗦，又说了一遍）。

crash发生在LTG写之后，但在IO成功确认之前。同上例。

crash发生在应用收到IO成功确认之后。磁盘上多份copy都是完整、正确的，只有多份copy都写完，IO才能成功返回，这与我们平时听说的概念不同，AIX并非写完任何一份copy就提交IO完成，而是全部的镜像，除非某份镜像多次尝试写失败，则AIX标记此份镜像的VGSA为stale，并且放弃今后对此份镜像（标记为stale部分）的更新，但其它未标记stale部分，则继续尝试。因此只有IO失败，并且系统继续幸福而快乐地活着，才会有stale。如果系统完全死翘翘，根本就不会更新VGSA的stale表。虽然如此，当我们把微观的行为放大，普通的IO问题发生往往不是一下子就死翘翘，中间有很“长”的半死不活的状态，这也就是为什么发生磁盘故障之后一般都会有pp stale的原因。

MWC引入了passive和active两种参数，上面说的都是active的状态，如果用passive模式，则重新varyonvg的时候则会自动对crash当时处于open状态的LV进行全同步，如此操作显然会有很大的性能问题，这就是个权衡了，到底是平时性能重要，还是回复速度重要。Linux的LVM采用的方案就是全卷同步，恢复时间很慢。

到此，我们了解到，VGSA和MWC是相互独立的两部分，但有些联系。他们都与Mirror有关，并且都是同时存在于磁盘和内存中。MWC要时时更新，是影响镜像系统性能的主要因素之一，

而VGSA只有IO错误（或者做mirror初始化、重新同步的时候）才会更新。MWC用于试图（不能永远保证，如那种你中六合彩的情况）保证镜像的多份copy是一致的，并不保证数据正确。

数据的正确性，数据本身的一致性，完整性，由数据库、jfs log等高层软件自身的log机制处理。

因此，每次系统crash之后，如果采用mirror机制保护数据，在mount文件系统之前，建议强制执行syncvg -f -v vgname说到底，mirror尽力保证，但并不能100%保证，而且只是多份copy的一致，不是数据一致，在IO提交完成之前，数据可能是新的，也可能是旧的，甚至是半新半旧的！不要怀疑，真的是这样，你别期望太高。当然，只要AIX回复了IO完成（在LV层/device driver层），则多份镜像一定已经确认一致、完整、正确，这一点毋庸置疑。