甲方工程师的目光不该只落在厂商们“高大上”的系统架构上，更应关注一些很可能在未来运维中带来困难的细节。
其他
一例PACS故障运维的分析与心得
PACS是医疗信息系统中不可或缺的组成部分之一，也是我进入医院信息科工作后，第一个接手运维的重要信息系统。该系统是医疗数据的“生产大户”，是院内存储系统的主要压力来源。
与通用存储系统的特点类似，医院检查科室对PACS系统的要求一般是高效传输和可靠存储两个方面，而在PACS系统运维过程中，最难确保的往往也正是这两个方面。为了满足用户对PACS系统越来越高的要求，各大厂商不断将系统架构进行升级。然而作为甲方工程师，我们的目光不该只落在厂商们“高大上”的系统架构上，更应关注一些很可能在未来运维中带来困难的细节。
本文是我在PACS运维中遇到的一例比较有代表性的故障，特与同行们分享。
一、我院PACS架构
我院PACS于2012年底开始部署，2013年初正式上线，当时我还没有到医院工作，未能参与系统上线工作。当该系统交到我手中时，一没有实施文档、二没有厂商技术支持、三没有了解情况的前辈，完全靠自己从应用服务器开始，一点一点地摸索出整个系统的架构。
1.服务器及存储架构
我院PACS服务器与存储架构如图1所示，数据库服务器双机热备，应用服务器全部使用虚拟化技术实现，SAN进行负载均衡和主备设置等。作为2012年以前设计的系统，当时处于业内领先水平。
图1 PACS架构
2.业务逻辑
由于必须遵循DICOM标准（医学图像和相关信息的国际标准），各厂商的PACS系统在业务逻辑上大同小异。对于检查影像归档环节，一般遵循以下流程：
（1）Worklist视图从数据库中读取设备需要的患者列表；
（2）设备从应用服务器端口获取Worklist视图；
（3）设备在产生图像时将获取的每个患者信息写入DICOM图像并将图像按指定地址上传到应用服务器；
（4）应用服务器将接收到的图像集中暂存；
（5）应用服务器将暂存的图像信息与数据库中患者信息进行匹配后最终归档存储。
二、存在的问题现象分析
我院PACS在运行4年时间后，开始故障频发，主要现象是归档服务器频繁死机。即使服务器可用时，终端图像上传成功率也极低，而且在PACS日志中找不到有意义的报错信息。在意识到问题的严重性后，解决问题这个光荣而艰巨的任务就交到了我的手里。
这里有必要提一下前文所述的业务逻辑中第（4）步：应用服务器将接收到的图像集中暂存。我院PACS的做法是：在存储上指定一个文件夹，再将接收到的图像都暂时存入这个文件夹，然后由归档服务从文件夹中读取图像文件进行信息匹配和归档。
图2 图像缓冲文件夹故障
在发生故障后，根据终端图像上传成功率低的现象，第一反应就是查看缓冲区，果然发现缓冲区存在严重问题。如图2所示，缓冲区中积压了大量图像无法归档，少则几千个，多则几万个。在图像过度积压后，甚至直接造成缓冲文件夹无法打开的情况。文件夹损坏后，只能重新指定缓冲文件夹，但新文件夹使用不超过24小时，就会又发生同样的问题。
缓冲区出错的同时，发现系统日志中记录了大量PACS应用程序错误。如图3所示，这样的错误在每次服务器死机前会发生数十次。为此，我们编写计划任务将PACS服务定期重启，但并没有任何效果。
图3 PACS应用程序错误
三、解决方法
在尝试了各种可能性，经历了无数人工重启恢复服务的日子后，一个偶然的发现给我们提供了新的思路。
在查看系统日志时，我们发现了大量I/O错误记录，这让我们想到一种可能，缓冲池的问题可能不是出在操作系统的文件系统上，而是在SAN上。那么，是否由于大量的底层读写失败造成了文件系统的瘫痪，从而导致服务器死机？为此，我们特地请来了存储方面的专家排查磁盘阵列的问题。但存储专家表示磁盘阵列除了一个“未使用优先通道”警告外并无其他问题，那么问题就只可能出现在虚拟化与存储交互的环节上了。
最后，苦于对虚拟化问题难以定位，医院咬牙“放血”之后，终于请到了原厂工程师协助重新部署PACS。出于对虚拟化的不信任，我们将整个虚拟化架构彻底拆除，直接使用原宿主服务器作为物理应用服务器，同时将缓冲文件夹裸映射到存储的独立SSD中以提高缓冲区性能。
PACS重新部署至今近2年，未再出现频繁瘫痪现象。
四、问题总结
1.我院的问题主要出在对虚拟化和SAN没有专业管理人才，又不愿负担高昂服务费邀请原厂工程师排除故障。因此，如使用私有云、SAN等一些较为复杂的系统架构时，就必须要有能够熟练掌握相关技术的工程师或技术实力强的厂商支持。否则在遇到难以定位的故障时，就只能“忍痛割爱”。
2.市场上服务器内存配置越来越高，已经不存在空间上的瓶颈。对图像文件缓冲区这样频繁读写的区域，完全可以考虑设置在内存中或独立映射到特定SSD组中，不宜视同一般存储区域。
3.医院在进行PACS系统规划时，必须要求厂商充分考虑操作系统层面及更底层错误带来的问题，并将这些问题尽可能清晰地反映在错误日志之中。
4.在业务逻辑设计上，可以考虑采用消息队列机制控制客户机的上传峰值速度及服务器的归档峰值速度，以免出现使用高峰期对服务器和存储压力过大的问题。
【作者简介】
李子木，某三甲医院信息科工程师。计算机专业硕士，先后就读于重庆大学、北京理工大学。做过基层主官，后回归信息化领域，习惯用管理思维看待技术问题。期待与医疗信息化同行们切磋交流。
HIT专家网∣致力推进中国卫生信息化
想加入HIT专家网专业交流群吗？
请扫码添加“HIT专家网”小助手微信好友后提交你的申请哦！（请注明姓名、单位名称、职务、主管技术或产品领域，以便有针对性加群）
微信订阅号：HIT180com
微信服务号：chinaHIT
投稿：tan_xiao@hit180.com
商务合作：(010)82373062