新院建设的背后故事 | 遭遇“史上最牛的坑”，折磨人的双活存储！

来源：HIT专家网 作者：佛山市妇幼保健院信息中心 黄国兴 马丽明

【编者按】

2020年12月23日，佛山市妇幼保健院新城院区正式开业。为实现信息共享和业务联动的高水平建设，新城院区信息化相关投入达到2亿元、系统数量超过100个、大小设备数量约2万台，此外，信息中心团队负责的建设范围也大幅增加，不但包括信息系统的选型、建设及相关软硬件的采购安装调试和弱电智能化管理，也包括与信息系统密切相关的非医疗设备及其配套工程的建设。

在全力支持新城院区建设与顺利开业的过程中，佛山市妇幼保健院信息中心团队经历了不少甜酸苦辣，克服了各种平时难以想象的困难。坐镇指挥的马丽明主任更是通盘筹划，随事制宜，带领团队在连工作用电都不能得到保证的情况下，确保了新院的准时开业。

开业之际，辛劳与喜悦一起涌现，别有一番滋味在心头。马丽明主任组织团队成员，讲一讲新院建设背后的那些故事。第三期故事的讲述者，依然是信息中心DBA、系统架构师黄国兴。

新医院、新院区建设，不啻为一项大工程；信息化建设又是一所现代化新医院开业投运的前提基础。在品读这些带着“泥土”气息的文字记录的同时，相信医院信息化同仁们也能从中感悟到宝贵的经验借鉴。

接上篇：《新院建设故事 | 一个DBA被“流放”到新医院建机房的那半年》

俗语有云：“世上不如意之事，十常八九”。有些事情真的不是你按部就班、循序渐进，或是你有多努力就能避免发生的，即使你事前已经做好各种准备、测试和演练，因为意外总在计划外！

“万无一失”的实施前准备

在数据中心这个项目中，最关键的一项工作就是搭建核心业务的存储双活。我（编者注：黄国兴）清楚地记得，两年多前，技术选型小组与多家厂商讨论“新院的数据中心究竟应该使用什么方式实现双活机房”这个问题的激烈程度。

虽然我们在2009年通过DIY的方式搭建了老院区的双活机房，但毕竟只是在同一院区。如何搭建新的数据中心，以便满足相隔十多公里的新旧院区实现“一院两区三址”的统一集中管理？这需要我们仔细研究和规划。而且，现在的技术实现方式和产品与当初相比，也已发生了很大变化。

选型时，我们就“使用网关模式，还是使用存储的aa模式或as模式？”“使用多套中端存储双活模式，还是一套高性能混合存储双活模式？”等关键问题展开了讨论和针对性研究，对每种方式都进行了细致分析，对各个环节的因素也分别进行了详实的测试对比，记录了每个方案的服务器型号、数据库版本、操作系统版本、存储性能、硬件配置及详细测试步骤。在对拟选方案进行反复测试、确认部署应用依然能达到预期效果后，我们选定了新院数据中心的技术解决方案。

受疫情等因素影响，新院建筑主体的工程进度缓慢，这使得数据中心从技术选型到进场实施之间相隔两年多的时间。为加快进度和稳妥起见，在新院区正式实施前，我们在老院区搭建了类似的测试环境，并进行了不下十次的前期测试，一切都很顺利。

然而，正当大家都认为万无一失，准备进场实施时，意外发生了，我们遭遇“史上最牛的坑”！

那个国庆假期，我看不到月亮

2020年国庆长假，别人都在度假，我们却在赶工。按原定计划，我必须在这七天内完成相关部署和测试，在国庆后第一周组织试运行测试，在2020年10月15日正式迁移第一个应用系统——PACS。

2020年10月1日晚上，当我模拟一个存储故障，手动把其中一个存储所有系统卷组一次性停止时，系统卡住了，Oracle-RAC报失败，识别不到存储。而此前两套存储间的双活未接入其他系统测试时是正常的，且单个系统接入后的双活存储切换测试也没有问题，符合当时测试的效果。问题出在哪里？

接下来的3天，我们不断测试分析：重刷了存储微码，重启了相关服务器、存储、数据库、操作系统、应用和中间件；分析了数据库、操作系统及服务器、存储、交换机等所有相关软硬件日志；对存储、操作系统、数据库等参数，甚至集群心跳参数都进行了多次调整，结果依然报失败。

无奈之下，我们决定重装操作系统和数据库，尝试看问题能否解决。在剩下的3天时间里，我们完成了9套Oracle-RAC、1套13个节点的虚拟化及1套Windows2016的HA的重新安装，再次进行测试。然而，结果并没有因为我们的努力有所改变，测试还是失败了。

我们陷入了沉思：问题究竟出在哪里呢？看着大家疲惫不堪的样子，我决定暂停，让大家休息一天，借此冷静一下，思考分析，看看有没头绪。

7天长假，别人快活玩耍，我们在机房玩命工作。每天早上7点不到就出门，没有一个晚上能在11点前离开医院，回广州的地铁早就没有了，每次都只能自费打车回家，却还是没达到预期目标，甚至连希望的曙光都没看到，这种感觉让人非常沮丧，工期的紧迫也让我感觉压力山大！工作不顺，老爸又有病，感觉生活真的很闹心！我陷入悲观中，忍不住拿起电话与一位同事诉苦。短暂的悲观之后，我知道诉苦并不能解决问题，只有努力振作，自己给自己打气：“一切都会好起来的！总会找到解决方法的！！月有阴晴圆缺，不过是这几天看不到月亮罢了，月亮总会有出来的时候！！！”

“问题不解决，没脸面对领导与同事”

2020年10月9日，技术小组再次碰头，探讨解决办法和方向。我们根据选型时的测试文档，对各环节、各步骤进行回顾分析，发现除服务器和存储的型号、容量配置及操作版本与测试不一致外，其余产品、配置包括操作步骤都没有任何变化。

我们在测试时使用的是CentOS 6.9，后按最新等保安全要求换成CentOS 7。按理说，操作系统间差0.1个版本应该没太多差别，且通常系统是向下兼容的。同时，该型号产品在全球也有很多成功案例，没听说遇到过这样的情况，问题究竟出在哪？

最后，我们决定一切从头再来，把存储也重新装一次，再逐套接入应用系统，毕竟服务器未接入时双活存储是正常的。经过几天的多轮测试，我们发现HIS系统加入后，问题出现了！按计划，作为医院最重要的核心业务系统，HIS系统放在本次迁移工作的最后，目的是通过前面的九大应用迁移，充分试错，完善切换方案，确保将业务影响降至最低。前面九大应用系统的接入都没有问题，当HIS加入后，存储连接才出现问题，我们终于看到了希望的曙光！

HIS系统使用IBM的AIX 7，难道是AIX 7的操作系统内核参数问题？抑或是AIX的Oracle-RAC存储心跳机制或多路径软件问题？存储的HBA卡驱动、SAN交换机的模块、存储的软件版本都是我们怀疑的对象，于是再次咨询存储、小机、Oracle厂家的资深工程师，一起远程尝试解决，同时，我们又从公司调用两台同型号服务器参与测试。

接下来的几天，我们处于反复测试调试状态中，对AIX的内核参数、多路径参数以及存储内核、数据库、存储交换机、HBA卡等参数都进行了尝试调整。所有能想到的方法都用了，包括升级存储版本，甚至更换HBA卡，问题依然无解。

时间一天天地流逝，眨眼到了2020年10月18日晚上10点30分，当天还是一个周日。眼看18天就这么过去了，我们依然卡在双活存储上。同事们得知后，都主动分担了我的其他工作，以便让我全心全力冲破这个难关，领导也常来探望，每次都自掏腰包给我们带来温暖的慰问品。哎，问题不解决，我真不知道该怎么面对他们啊！要不是当初所有的暴力测试、功能测试、性能测试都是我亲手执行，而且每个步骤都有详细记录并保留截图的话，我都怀疑报告是假的！在老院区，我还搭建了一整套测试系统，用于各个系统的模拟迁移、升级和应用测试，各系统管理员给出的前期测试报告没有任何问题，系统应用也都兼容。现在，大家都如期完成任务，可是项目却卡在我这里没有任何进展，真是非常迷惘！主任通过电话给公司厂家各方老总施压，希望能有效果吧。

2020年10月22日，我们在现场配合厂商二线做测试，二线同时在实验室搭建相同环境，测试结果都出现链路异常。在未打开数据库的情况下，观察多路径软件状态后，初步怀疑存储存在BUG。

2020年10月23日，升级存储到最新的两个版本，问题依旧。厂商升级到三线处理，未果。10月26日，问题升级到美国总部，实验室模拟还原测试场景，出现相同故障。10月29日，根据实验室反馈意见还是未能解决问题。主任当机立断，立即向公司及厂商发出最后通牒：限期解决，否则更换产品和方案。

终于雨过天晴

黑暗终将过去，黎明总会到来。在领导的施压下，2020年11月2日，厂商和公司最后派出三大“骨灰级”专家（Oracle、存储、操作系统）抵达现场。

总体分析后，在不启动数据库的情况下，直接从操作系统层查看存储、存储交换机、服务器HBA卡及服务器多路径软件等分析日志；经过4天的通宵达旦，通过对不同参数的调整，相互匹配，终于确保存储路径已切换就位，各操作系统多路径都正常，并最终定位问题出在CentOS 7。因此，只要匹配操作系统连接存储的多路径及数据库心跳参数即可。

随后，我们不断尝试。2020年11月6日晚，在经过对多路径配置300多个参数的调整测试后，成功通过调整多路径配置参数适配数据库IO延迟，问题终于解决了！！！

2020年11月7日，经过一整天的全面多重测试（包括压力测试），确认这个“拦路虎”真的解决了。而且经过一番调整，目前所有参数都是最适合的。公司表示此前该型号存储未经过CentOS 7接入测试，故未发现这个BUG，经此一役，公司会尽快升级补丁和配置相关信息。雨过天晴，一些都变得很美好。

经过一系列的压力测试、系统测试后，终于到了迁移阶段。第一个迁移的核心业务还是PACS，因为这个系统准备最完善、架构简单、影响范围小，且算是可控系统，即使切换失败还可以快速回退。2020年11月13日晚上8点，我们正式开始迁移工作。按照预定方案和步骤，稳步进行，仅用55分钟便完成数据迁移、数据库升级、打补丁、优化等核心工作，比预计的2小时提前了1小时5分钟。随即，交付到负责该系统的同事处理接下来的工作。不过，由于PACS系统还需进行自身系统功能和数据结构升级，导致该系统的最终启用时间比预期略长。通过这次切换，我们总结经验，不断完善切换方案，接下来的几个系统切换都很顺利，核心工作都在1小时内完成。

最后一战

值得一提的是，由于本次迁移后使用新的应用服务器，且我们利用这次新院建设对照等保2.0对网络架构进行了重新规划和调整，因此应用系统服务器的IP地址不得不发生改变，也就意味着对于那些采用C/S结构的应用系统，需要到每个客户端逐台修改其连接数据库或应用服务器的IP地址。硬件部的同事采取了“扫楼”的方式，每个人按照分配任务，在全院范围内逐个楼层、逐个房间、逐台电脑检查、修改并测试系统可用性。

不过，这样的修改显然需要时间，负责网络安全的同事灵机一动，在防火墙上做了一个IP映射的临时策略，这样客户端即使不改IP也可以连接到新的数据库。虽然，这只是一个临时策略，但为我们赢得了足够的缓冲时间，堪比千军万马，大大减轻我们的压力，也保证了用户的及时使用和业务不中断。

在综合各系统的迁移经验后，2020年11月27日晚9点30分，我们终于迎来最核心的HIS系统迁移。信息中心尽锐出战，各相关公司悉数到场。由于影响范围涉及全院各个科室的方方面面，本次迁移启用门诊应急小网络（基础数据与业务正式库同步）。再次确认应急系统与LIS、PACS等接口正常及基础数据同步完成后，我们正式停止使用HIS系统，门诊挂号、收费、分诊、护士站、医生站及药房等自动切换到应急服务器，检验、检查申请可正常传送到PACS、LIS等系统并返回检查结果，大大减少了对后续业务的影响。在数据迁移完毕后，切换期间应急系统产生数据回传到HIS。

这次HIS切换历时约两小时，在全体同事及各公司大力协助下，我们把业务停顿降至最低，是近期系统迁移中最高效的一次切换。不过，即便如此，当天的一些后续工作依然还是让我们加班到了凌晨4点。

离开医院时，看着灯火璀璨中的医院，我感慨万千！迁移完HIS，也就意味着消除了影响开业进度的最大隐患，后面的工作对主体业务影响不大，唯一需要的就是时间。我们终于可以稍作歇息，好累好累！！今天应该能睡上一个近半年未有过的安稳好觉了吧？

【作者简介】

黄国兴，佛山市妇幼保健院信息中心DBA、系统架构师，广东医科大学医学信息管理专业院外导师。

2005—2008年，任职于广州慧通计算机有限公司，任研发部后勤管理组组长，全面负责药库、药房、物资、资产、供应室、体检等管理系统的设计与研发；2008年至今，任职于佛山市妇幼保健院，负责医院数据中心管理与全院信息化系统架构设计与运维。

曾主导佛山市区域妇幼信息平台的系统架构设计，并参与该项目的开发与管理，应用范围覆盖五区59所产院和200多个社区的28项妇幼专项服务，实现居民健康卡和新生儿唯一标识应用支持，实现基于区域平台+健康卡的嵌入式妇幼保健信息系统，并实现电子病历嵌入式应用及公安、计生等系统信息的互联互通。参与原国家卫计委—联合国儿童基金会《孕产妇及儿童健康管理信息系统建设第二周期》项目并取得良好效果，获得国家专家组的高度认可。

【责任编辑：陈曦】