中断镜像关系是否会导致宕机？——宁夏银行宕机始末

存储在线 专栏文章：近宁夏银行宕机事件，引发种种猜测，谣传不断。原文报道不再多说，其中一句话耐人寻味，意思是“在中断数据录像之后即发生宕机”，带有明显的暗示色彩，解读这句话可以初步得出其所“暗示”的两个结论，第一个就是本次宕机的导火索是中断了数据录像，第二个就是提供数据录像的厂商很有可能就是飞康，当然，第二个结论已经是事实了。但是第一个结论，有待考证。如果一个系统已经出现了问题，而不可逆转的话，此时所做的任何动作，都有可能成为该系统最终宕机的理由，而如果不做这些动作，系统依然可能还会最终宕机，所以，报道里的这句话是模棱两可的。

但是不同的人，不同的位置和角色，就会产生偏见了，最终偏向对自己有利的那一侧。这里有三个角度。首先对于用户而言，这一灾难是巨大的，相关方面这时除了吸取教训，更重要的恐怕是对于责任的认定。如果有一种解释能淡化运维和操作相关的责任，不失为一种好的危机应对；对于飞康的竞争者们，当然是“希望”问题出在飞康身上，飞康一定是希望问题不出在自己身上。
根据有关宁夏银行之前的相关报道，宁夏银行的核心系统包括CDP在内，已稳定运行数年。在这其间，还曾经于2010年进行过成功的复杂条件灾备真实切换的演练并取得成功，这一事件当时被众多媒体和同行现场报道和观摩。那么，在数据库崩溃之前，到底系统已经出现了什么征兆和问题，在那天，除了关闭“录像”，用户对于数据库和主机还进行了哪些操作，在报告里却不得而知。

这里抛开这些人的因素，只谈技术。

中断数据录像这个动作到底是否会导致系统宕机，有多大几率？要回答这个问题，就得先搞清楚这些CDP方案是怎么执行数据录像，详细机制在《大话存储2》16章有详细描述，这里只是简单总结一下。首先生产数据先被镜像一份到一个独立的存储系统里，当达到同步收敛之后，生产卷和镜像卷的IO实时同步。基于这份镜像卷，CDP系统在其上实现数据持续捕获剂元数据记录，最后采用基准镜像+增量的方式实现任意时间点回滚。

这里所使用的IO同步镜像工具一般为LVM，也就是Linux和UNIX普遍使用的存储空间批发+零售的卷管理系统，Logical Volume Manager。其前提是应用的数据是部署在LV块设备上的，如果是部署在/dev/sda这种底层块设备上，就不能使用LVM作镜像了。正因如此，飞康在Windows下提供单独的Disksafe镜像和快照管理工具，因为WIndows下几乎没有应用使用系统自带的动态磁盘方案（Windows下的“LVM”）。

不管是LVM，还是Disksafe，其底层都需要在IO路径上插入filter driver，当然这是个Windows下的名词，Linux下更直白，不叫filter，叫hook，Windows不能随便让你hook来hook去，它的驱动框架都是定死的，你只要填空就行了，Linux则非常灵活，但是风险自负。Windows下不少时候的IO性能比发行版Linux是要强很多的，当然如果自己定制化了内核IO路径就另当别论了。在Linux下，LVM底层使用的是device mapper这个名正言顺的钩子驱动，当然这个钩子是经过千锤百炼的，稳定性应该不成问题，但是不排除其依然有bug，只是几率微乎其微。你也可以插入你自己的钩子驱动，但是你自己的钩子就得风险自负，内核态里出了问题系统多半宕机，所以一般商用产品，能用内核自带的就用，这样一来节省开发，二来名正言顺，三来出了问题也可以撇清关系。

LVM镜像一般都是同步模式的，也没有地方可供更改为异步，这就要求镜像卷缩在的系统性能足够强以至于不会拖慢生产系统，此外采用同步复制也可以保证不丢失数据，只要数据是一致的。

而且，根据飞康CDP的实施手册要求，LVM CDP 只建议配置成写入目标模式（ write target ）, 主机只向CDP写入I/O, 但平时并不读取。只有在需要恢复或验证某时间点数据时，才会将录像点磁盘mount 到验证机上。所以CDP 的故障或错误是不会反向影响到主机的数据的。现在，我们再来看下一步，如果要中断数据录像，就得在主机上进行针对LVM镜像卷的配置，将镜像切开，这一步必然需要通知底层驱动，驱动此时会断开对镜像卷的数据IO。这一步在低IO压力下，正常来讲没有问题，但是在高IO压力下，对IO路径任意一处做影响IO路径的更改，就很有可能导致系统卡死，因为牵扯到路径变更，势必导致对资源的锁操作，以及瞬间暂停IO，此时上层的IO仍然会不断压入队列，最终会导致queue full，内核迟迟不返回结果给应用，响应时间的增加，又会导致前端操作员不断刷新重试，又会导致大量新IO请求，最后系统越来越慢，内存耗费暴增，不得不借助swap暂存，最后swap如果要满了的话，那就真的没有可用内存了，最后就是僵死态，这属于连锁反应。这种现象在Linux x86 服务器上是有所耳闻的，但是后来的内核版本会自动杀进程来保证新资源被分配来确保系统尚在运行，此时已经算是抽风了。AIX则不会，swap满则卡死。

再说回来，为何要中断数据录像？恐怕那时候系统已经非常慢了，导致必须人为介入处理。但为什么慢？

7月初，很多业务都处于半年结算期，业务压力暴增，从另外一些报道，系统在彻底中断之前，有一些业务已经中断了。网上还有一些数据库专家的猜测，这个多年没有维保的Informix 系统踩到了那几个老版本Informix 上已知的“地雷”，中招的现象就是系统很慢，类似假死。但可怕的是数据库一旦重启，将系统崩溃。可能也正是由于此，才会人为介入，此时该系统已经是苟延残喘，动底层驱动，很有可能是压垮骆驼的最后一根稻草。但是这点必须根据现场经验和系统log日志才能够具体判断，如果中断录像之后没多久立即宕机，那么这个动作可以被判断为是最终那根稻草，如果没有立即宕机，那么这个动作或许本来对系统是没产生决定性影响的。另外，宕机类型也得搞清楚，是立即重启了，还是僵死态比如尚能ping通，这两个是很不一样的，如果是立即重启，则该动作导致的可能性就非常大了，如果是僵死，也不足以判断是否该动作产生决定性影响。

所以综上来看，该系统过于老旧，而新业务猛增的IO压力，是根因，中断录像可能是导火索，也可能根本没起决定性作用。这次事件至少给人一个教训，洪水是很快的，等到喷涌直下的时候再去筑堤坝是来不及的。技术上可以有些改善，当然，也要付出更多成本，比如可以利用交换机上的端口镜像功能或者封装之后的接口比如SANtap Service，这样就可以与主机彻底撇清关系了。

最后，利用此事件打击对手其实并不是明智之举，大家都是做容灾的，难道用了其他家的就不会出这种问题？如果能拿出针对IO方面的更好设计和技术，倒是值得讨论，如果只是煽风点火，其实最后都是砸自己的脚。