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

冬瓜头

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

但是不同的人，不同的位置和角色，就会产生偏见了，最终偏向对自己有利的那一侧。这里有三个角度。首先对于用户而言，这一灾难是巨大的，相关方面这时除了吸取教训，更重要的恐怕是对于责任的认定。如果有一种解释能淡化运维和操作相关的责任，不失为一种好的危机应对；对于飞康的竞争者们，当然是“希望”问题出在飞康身上，飞康一定是希望问题不出在自己身上。
根据有关宁夏银行之前的相关报道，宁夏银行的核心系统包括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方面的更好设计和技术，倒是值得讨论，如果只是煽风点火，其实最后都是砸自己的脚。

muslin529

冬瓜兄威武

锅铁做

回复 1# 冬瓜头

大家好，

我的观点是这样的：
首先要弄清飞康用的是哪个产品，这个很重要，如果NSS，而CDP仅仅作为辅助，这个故障出现的几率很小；
（但如果甲方说了:既然问题出了，必须站出来个背锅的，否则第二年预算下来你就可以滚了，我想作为厂商则没什么脾气，对吗？所以这里面事情也许能写出一本书出来）

而此时，我仅仅想在技术发表下看法：

其次，如果飞康用的是IPstor+CDP就难说了，因为在应用主机安装一个Agent拆分IO给CDP有很大的隐患，随之主机业务并非越高，Agent越是要向主机请求更多的性能来拆分IO至CDP设备，所以，这是一个潜在的放大效应，当某些组件出现瓶颈（如：CDP存储响应，应用主机CPU负载,链路等等），那会导致很多问题出来，即使停机也在所难免。

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

很早之前，很多网友就因为CDP引发了无数的口水战与不理解，我想说的是，CDP的技术原理也许大同小异，但是每个厂商CDP所运用的场景是不同的，因为某次事故而枪毙所有的CDP厂商，产品，方案，这并不是一个技术人员的职业操守，请往下看我的诠释：

对CDP有诸多分歧，我想很多时候是因为不同技术领域的代沟，很多人还停留在利用CDP做容灾的阶段，没错，还有很多厂商致力于CDP容灾，尤其是国内厂商。
但是：类似EMC Recoverpoint，上海爱数的CDP等等，并不是寄托于CDP容灾的，我自己认为。
他们容灾的手段是存储阵列之间的实时镜像-Synchronous Mirroring；也就说，在同城的两个中心，各放置若干套EMC VPLEX引擎，或者爱数的什么虚拟化网关，让两个数据中心存储阵列之间永远保持两份相同的数据副本，待其中一个数据中心阵列或者整个数据中心毁掉，那第二个数据中心会即时接管业务。这已然成为了一套最高级别的高可用解决方案。
那回到之前，那EMC和上海爱数还要扩展CDP方案做什么？替用户多消化下预算？
坦白的说Synchronous Mirroring，也有一个很小的弊端，那就是为了履行即时接管的职责，两个数据中心的数据副本永远会保持一致，包括运维人员不小心删掉了一些数据在HOST上面，包括病毒蠕虫**，网络入侵或者软件bug，这时候CDP就能够非常精细的回滚数据之上一个时间点，上一天，上一个小时，甚至“秒”，CDP能够提供一个较短的RTO，并且缩小RPO，尤其是TRUE CDP技术。

在上面例子能够看出，不是每个厂商都是依靠CDP做容灾的，也许仅仅是辅助，对于逻辑错误的辅助；因为对于单个NODE或单个数据中心已然有Sync Mirroring，如果还不放心区域故障，还可以扩展为远程容灾至另一个城市/国家，利用EMC Geo或者上海爱数的远程复制（这就是两地三中心），而CDP仅仅是对用户的一种高度负责及节省备份产品的投入。

如果，因为一个技术人员自身学艺不精，就草草的对某些事情下定论，到头来可悲的却是自己。

再次重申，以上是我个人的看法，根据我的经验，阅历，不为任何厂商漂白或粉饰什么，我只为我自己代言。


基于人道主义，我倒是期盼这件事情不会对飞康带来多大影响，因为这几个Q飞康的业绩已经令人堪忧了。

hxsaj

都是存储大拿，牛逼。

mike1979

AIX里swap满了也会杀进程，errpt里有时会有记录。但这些其实都没啥用，你杀死一些进程释放的资源根本无济于事。

飞康CDP功能强大，但是缺陷也很明显。LVM镜像要求两个分支存储的性能相当。而飞康CDP上还要周期性做快照，那么飞康CDP的存储性能应该比另一个分支存储更强些才是。可实际中大都是1台高端存储+1台飞康CDP，完全颠倒了。

回过去说为什么系统慢？有可能是informix bug，但也可能是飞康CDP拖累了。宁夏银行用的是DMX800+飞康CDP，这就是我说的性能颠倒。LVM镜像是同步写，写性能取决于性能差的分支存储。

飞康CDP号称能做备份和容灾，同时生产系统中它也要插一脚。可问题是备份和容灾是IT系统的最后防线，要是都用飞康CDP，就是把鸡蛋放在同一个篮子里了。最坏情况下就是都不能用。

比较奇怪的是，就算把飞康CDP关掉，那么在DMX800上还有一份完整数据，这份数据应该是可用的。哪怕系统宕掉重起，也应该能把数据库拉起来。出现公告中说的“数据库损坏”很奇怪。

冬瓜头

3楼黑的太明显了。

锅铁做

回复 6# 冬瓜头

首先，黑与不黑取决您的心态，心态不正做什么都是变质的对吗？可我只能保证自己的心态在写这些时候是正常的。

其次，看东西不能只看喜欢的部分，正如我所担心的，我在倒数第二句写了：
"再次重申，以上是我个人的看法，根据我的经验，阅历，不为任何厂商漂白或粉饰什么，我只为我自己代言"
--------而--之所以追加这个没有意义的回复，完全是因为之前拜读过某个网友送的一本书，正是阁下的 -存储2.

最后，不是每个厂商的CDP技术都是镜像数据至另一个存储的，也许仅仅是捕捉变化的IO，到头来仅仅需要个日志空间，最终需要依赖源数据才能恢复，所以，即使写书里了，这段话并非通用在所有厂商：

“首先生产数据先被镜像一份到一个独立的存储系统里，当达到同步收敛之后，生产卷和镜像卷的IO实时同步”

勿回，
晚安！

   

mike1979

锅铁做 发表于 2014-08-08 22:31
最后，不是每个厂商的CDP技术都是镜像数据至另一个存储的，也许仅仅是捕捉变化的IO，到头来仅仅需要个日志空间，最终需要依赖源数据才能恢复，所以，即使写书里了，这段话并非通用在所有厂商：

“首先生产数据先被镜像一份到一个独立的存储系统里，当达到同步收敛之后，生产卷和镜像卷的IO实时同步”

你跟他说的根本不是一回事。你自己也说依赖源数据才能恢复，你这个源数据只能在CDP上吧？他说的就是CDP上的源数据是怎么来的。之于你说的日志空间，那是同步后在CDP上做快照。

冬瓜头

越来越有意思了，我还是少说话，以免又被版主给封号一年。

pingfan2

mike1979 发表于 2014-08-08 22:37
你跟他说的根本不是一回事。你自己也说依赖源数据才能恢复，你这个源数据只能在CDP上吧？他说的就是CDP上 ...

同意！