专业咨询
致力推进中国医疗卫生信息化

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

来源: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项妇幼专项服务,实现居民健康卡和新生儿唯一标识应用支持,实现基于区域平台+健康卡的嵌入式妇幼保健信息系统,并实现电子病历嵌入式应用及公安、计生等系统信息的互联互通。参与原国家卫计委—联合国儿童基金会《孕产妇及儿童健康管理信息系统建设第二周期》项目并取得良好效果,获得国家专家组的高度认可。

关注HIT专家网微信订阅号
精彩不容错过!

【责任编辑:陈曦】

赞(14)

评论 抢沙发

评论前必须登录!

 


未经允许不得转载:HIT专家网 » 新院建设的背后故事 | 遭遇“史上最牛的坑”,折磨人的双活存储!
分享到: 更多 (0)