【作者】社区ID：diliangyu520，某三甲医院信息中心科员，从事虚拟化、大数据等领域，参与医院整个信息系统迁移云端的项目。
某省级综合三甲医院，开放床位 3092 张，开设住院病区 78 个，设有 38 个临床科室， 15 个医技科室。2019 年，医院完成年门急诊量 250.7 余万人次，出院 11.9 余万人次，完成手术 3.5 万台，平均住院日 8.8 天，属于中等规模的大型三甲医院。医院建设有 2 个机房，分别位于两栋不同的大楼中通过光纤相连接，院内共有 45 个各类信息系统，共有实体服务器及虚拟化服务器 200 余台。2019 年，根据省卫建委要求，所有医疗机构不建议新建机房，所有服务都应迁移至云端，至此医院决定将院内所有系统迁移至云端。
经过调研分析后，选择国内大型 ISP 商，距医院 15 公里外的核心机房中构建一个私有云，共需约 8 架 4KW 机柜，含 9 台计算节点服务器和 10 台存储节点服务器、 4 台管理监控服务器、 4 台数据库物理服务器、 1 台灾备前置机服务器、 2 台集中式双活存储、 2 台光纤交换机，配套网络设备 2 台四槽位核心交换机，万兆交换机 4 台、千兆交换机 3 台，并附有等保涉及的安全设备一并规划，安全设备将按照等保三标准统一建设。项目在建设过程中面临的技术问题和解决方案如下。
一、 网络问题
1） 端口管控：医院计划与云机房用 40G 带宽 4 路光纤专线连接。出于安全考虑，与云端的所有连接都要经过端口管控。医院经过十几年信息化的发展，也有着自己原本的网络构架，因为做了内外网隔离，所有院内系统都是在内网中传输，只需要设定好 IP 地址就不需要考虑端口的问题。经过云端的端口管控，所有的信息系统都要对端口进行整体测试。私有云的底层架构中网卡的所有配置需要在底层运维人员的修改处理，所有网卡地址的修改都伴随着端口的统一管理，迁移后要与开发厂商共同协调各类端口。对于这个复杂的工作，整个迁移项目中采用初期调研，详细记录好所有系统及设备的端口使用情况，在云端先建立测试机，与厂商协同测试好相应网卡及端口配置，在系统测试成功后再进行迁移。
问题总结：该问题说明在一个单位将整个系统迁移到云端时一个微小的网络变动可能会带来巨大的工作量，由于端口管控符合三级等保要求，且医院未来的安全管理有赖于端口管控的实施，只能由前期充分的调研工作来减轻后期迁移的工作压力。
问题总结：在将信息系统迁移到云端时，如果是新建私有云，那么最好尽量保证网络设备能够使用同厂家、型号，以免在后期工作因网络问题延缓工作进度。
二、 服务器
1）服务器的配置：项目开始初期，云端厂商做了大量的前期调研。整理了医院现有系统使用的 CPU 、内存、存储和数据库等相关信息。医院原有的无论实体机还是虚拟机都是按照 CPU 核数 1 ：1 比例的配置，迁移至云端后，因为云计算资源调配的灵活性， CPU 核数并非按照 1 ：1 比例配置。初期云端厂商使用 6 台服务器做虚拟化计算资源，院方认为医院内的信息系统比较复杂，有些应用系统对资源的需求量很高，云端如果按照 1 ：3 的虚拟 CPU 核数将无法达到院内需求，甚至影响医院未来信息化发展。通过与云端厂商的讨论研究，最终云端厂商同意将计算节点服务器由 6 台增至 9 台，并把虚拟 CPU 核数的虚拟比例由 1 ：3 降低至 1 ：2 ，为此扩容工作将工期多拖延 2 个月。
问题总结：在做私有云规划时一定与云端厂商做好充分沟通，做好需求定位的工作，大型厂商的采购流程繁琐，临时扩容就会拖延工期甚至影响正常业务。
2）操作系统的安装：医院现有服务器有实体的、有使用 ctrix 为底层的 XEN 构架的虚拟机。而云端使用的是使用 openstack+KVM 做虚拟机的构架。整体迁移方案时采用在云端重新安装操作系统、重新部署应用和安装数据库，这样在将医院系统迁移至云端就存在很多问题，一些常用的操作系统可以通过直接安装来解决，而院内虚拟机环境中有些系统是定制化的系统， openstack 支持 qCOW2 格式的虚拟机， XEN 架构只有 ova 或 ovf 格式的虚拟机，面对这样的定制系统时，如果原始系统安装镜像 iso 不能很好的转换成 qCOW2 格式，那么服务器的基本安装都存在问题。医院在迁移中就遇到因操作系统无法安装，导致一个重要的系统迟迟不能迁移，后来由云端厂商进行技术攻关才解决此问题。
问题总结：在迁移过程中，操作系统的安装是十分重要的一步，要考虑还原有系统环境，与院内系统厂商做好沟通，尽量使用原厂 ISO ，当系统厂商没有上云的经验，不能提供云端虚拟机能够正常安装的镜像文件时，只能完全依靠云端厂商技术攻关解决问题。
3） 数据的迁移：能够保证迁移数据完整性和一致性的整机迁移需要通过停机后才可以迁移，而因为医疗行业的特殊性，业务系统的运行不能中断，医院也存在各类占用极大空间的数据，使得整体迁移并不能通过短暂停机来实现。
经过论证最终迁移使用的方案就是在源服务器和目标服务器同时安装数据迁移代理软件，通过建立好互通的网络链路，架设一台用于迁移数据的控制服务器对数据进行传输校验。首先在云端建立全新目标机虚拟机，安装相同的操作系统、预留相同的磁盘空间、部署相同的环境，根据不同应用系统要求在后台传输目标服务器所需要数据，待数据传输完成经过校验后，将源服务器暂时停机数据库导出通过迁移代理传输至目标服务器，目标服务器将数据库导入恢复，将网络配置更改后关闭源服务器，启用新服务器。数据迁移的过程中一定要注意以下原则，以防目标服务器不可用时产生脏数据。
1. 确保业务系统平稳顺利迁移为最根本原则。
2. 在迁移工程中，不进行任何系统架构的调整或变更，以避免项目交叉导致的业务风险。
3. 制定相应的迁移方案，确保宕机时间可控。
4. 需要对迁移前后的应用服务器性能进行对比分析，保证资源利用率的合理性以及 IOPS 要求。
问题总结：数据迁移是整个迁移项目最重要的一环，为保证系统正常运行，数据迁移的每一步都要充分考虑做好相应的应急预案，根据不同的应用系统及环境做有针对性的措施。
三、 存储
医院的存储基本是用服务器自带硬盘（包括 SAS ， SATA 和 SSD ）和多个品牌型号的集中存储。云端使用的是 Ceph 存储，使用大量服务器插满硬盘做分布式存储，这样不同的存储方式也带来不同的问题。Ceph 本身就是分布式存储构架，优势在于能够动态地伸缩、再均衡和修复，医院内系统应用的复杂导致存储数据的格式差异非常大，如有需要实时读取的小碎片 XML 文件，也有体积巨大的 DCom 影像文件，而且不同的系统对文件存储响应时间要求也不同。项目初期时是使用 SAS 和 SATA 硬盘作为存储，院方与云端厂商提出不同系统的 IO 需求时，云端厂商使用 SSD 硬盘扩容，用于影像系统这类对 IO 要求较高的系统。
问题总结：云端厂商为保证灵活性和性价比，使用分布式存储，医院则需要强调院内应用系统的不同需求，如果有对 IO 性能要求较高的系统时，一定保证要有 SSD 以防未来出现瓶颈。
四、 灾备
当医院的所有信息系统迁移至云端后，所有的业务都通过光纤专线进行传输。尽管有 4 条专线，但仍旧存在光纤故障导致医院业务停滞的可能。
基于以上考虑，这次迁移后将对医院原有服务器进行充分利旧，做成一个紧急灾备机房，将核心业务系统在医院内做应用级备份。当线路出现故障时第一时间能够启用医院内的灾备应用，保障医院所有业务的正常运行。
本次信息系统的数据备份均采用网络方式进行数据备份，根据医院需求本次数据备份数据量共计 100TB ，容灾数据 15TB 。初期要分别对院内所有需求进行容灾和备份的业务系统进行调研并定级，在制定完善调研表后，其中 HIS 、 LIS 等核心系统需要实时数据保护， PACS 系统业务自身为冗余互备模式，不需要使用容灾系统，只需对部分数据做定期备份。根据对各业务系统的定级，确定每台服务器的灾备策略，并与各业务系统厂商确认要备份的文件目录和业务类型，如数据库或普通文件等，在灾备策略中进行配置。根据业务系统的要求配置对应的备份策略和数据保留策略，启动容灾备份服务，对核心系统（如 HIS ， EMR ， PACS,LIS, 集成平台等）建立应用级灾备，保证因为网络问题连接中断时在院内原有系统可以顺利接管。
问题总结：对不同业务系统要制定相应的灾备方案，在灾备资源有限的前提下要保证业务的正常运行才是灾备的核心，同时充分利旧院内原有设备也能节约成本。
五、 结语
整体业务全部迁移到到云端是个复杂而庞大的工程，一定要有前期的充分调研，明确的需求定位，与云端厂商和系统厂商的充分交流沟通。即便如此在迁移的过程中仍旧会遇到各种预料不到的技术问题，所以当决定系统整体迁移的时候，务必规划好工期进度以及软硬件的需求，充分考虑好未来的扩容的需求，内外网互访，安全管理，灾备等方面内容。