PACS 搬上分布式存储：一场三甲医院改造的架构账

医疗影像对存储的要求很拧巴：单次 CT 或 MRI 检查的文件能到 2GB，但 95% 的数据存进去之后几乎不再被调阅，而法定保存期又要 15 年起步。传统集中式存储三个短板全占了：调阅延迟、扩容成本、容灾弱。某三甲医院 PACS 改造选了分布式对象存储路线，本文按该项目的实施口径，把这笔架构账拆开算。

落地架构与项目数据

Ceph 集群 32 节点承载数据切片，存储利用率从 65% 提到 92%，支持跨院区异地容灾。模拟 10Gbps 网络下调阅 3000 份 DICOM 文件，平均响应 1.2 秒。处理层用微服务把三维重建、病灶特征提取这类计算密集任务拆成子任务并行跑，Kubernetes 动态调度在高峰时段扩到 200 个容器实例，夜间批量处理效率提升 4 倍。年度存储硬件投入降低 37%——以上均为该项目口径的数据。

选 Ceph 有一个绕不开的版本问题：从 Luminous（12.2）开始 BlueStore 就是默认存储引擎，旧 FileStore 已停止维护。新集群直接上 BlueStore，别再从 FileStore 起步——它的写放大和运维成本，在影像这种大文件场景会被进一步放大。

安全与容灾

静态数据用国密 SM4 加密，访问控制接医院 HIS 系统的 RBAC 权限模型。项目演练结果：抵御模拟勒索软件攻击，数据恢复时间从 48 小时压到 15 分钟。

两个成本要提前算进预算。SM4 加解密有吞吐损耗，大文件批量调阅的峰值带宽会受影响，上密评前先做一轮压测。跨院区容灾走专线，带宽是按年计费的固定支出。另外这套架构需要既懂医疗 IT 又懂云平台的复合团队，人力成本经常被低估。

def check_node_health(node_list):
    healthy_nodes = []
    for node in node_list:
        resp = requests.get(f'http://{node}/health')
        if resp.json()['status'] == 'UP':
            healthy_nodes.append(node.id)
    return sorted(healthy_nodes)

验收怎么做

DICOM 链路验收用 dcmtk 工具集最直接：echoscu 对存储节点做 C-ECHO 连通校验，全部返回通过才算链路正常；dcmdump 抽查文件的元数据完整性；对象存储侧用 ceph -s 看集群健康、rados df 看数据分布。判定标准三条：C-ECHO 全通、抽检文件校验值与源一致、PG 状态无 degraded。数据完整性按 99.999% 行业标准设计，靠哈希比对加副本交叉验证兜底。