某省级综合三甲医院，开放床位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地址就不需要考虑端口的问题。经过云端的端口管控，所有的信息系统都要对端口进行整体测试。私有云的底层架构中网卡的所有配置需要在底层运维人员的修改处理，所有网卡地址的修改都伴随着端口的统一管理，迁移后要与开发厂商共同协调各类端口。对于这个复杂的工作，整个迁移项目中采用初期调研，详细记录好所有系统及设备的端口使用情况，在云端先建立测试机，与厂商协同测试好相应网卡及端口配置，在系统测试成功后再进行迁移。

问题总结：该问题说明在一个单位将整个系统迁移到云端时一个微小的网络变动可能会带来巨大的工作量，由于端口管控符合三级等保要求，且医院未来的安全管理有赖于端口管控的实施，只能由前期充分的调研工作来减轻后期迁移的工作压力。

2）防火墙设置：信息系统上云后，所有数据将通过医院内的防火墙和云端的防火墙，防火墙的型号、支持的功能都有不同。医院内部因为历史原因，造成的复杂的网络构架，医院内网190.1.240.0/20网段的地址分布在vlan1与vlan80内，由于内网启用了mux-vlan，功能院内内网vlan1与vlan80的190.1.240.0/20网段内可以二层互通。随着业务逐步迁移至云端（vlan80的部分业务），造成院内vlan1中的IP地址无法与云端vlan80的地址进行二层通信，给正常业务造成影响。解决方案是医院内vlan1发起的流量访问至云端vlan80主机时，在云端核心交换机与防火墙对接链路的入接口上，配置基于源、目标mac地址的vlan映射。根据访问源、目mac地址，将vlan1内源主机的mac与访问到目的业务的虚机的mac进行匹配，并将该流量进行vlan tag映射，将vlan1转换vlan80，达到vlan1与vlan80互通需求。

问题总结：在将信息系统迁移到云端时，如果是新建私有云，那么最好尽量保证网络设备能够使用同厂家、型号，以免在后期工作因网络问题延缓工作进度。

二、服务器

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,集成平台等）建立应用级灾备，保证因为网络问题连接中断时在院内原有系统可以顺利接管。

问题总结：对不同业务系统要制定相应的灾备方案，在灾备资源有限的前提下要保证业务的正常运行才是灾备的核心，同时充分利旧院内原有设备也能节约成本。

五、结语

整体业务全部迁移到到云端是个复杂而庞大的工程，一定要有前期的充分调研，明确的需求定位，与云端厂商和系统厂商的充分交流沟通。即便如此在迁移的过程中仍旧会遇到各种预料不到的技术问题，所以当决定系统整体迁移的时候，务必规划好工期进度以及软硬件的需求，充分考虑好未来的扩容的需求，内外网互访，安全管理，灾备等方面内容。