托管云实现数据中心转型">

天津市武清区第二人民医院（下称“武清二院”）始建于1956年，
，，，是一所集医疗、、教学
、、、、科研、、
、、预防、、
、、保健、
、、康复于一体的二级综合医院，，，也是武清城区内医院唯一一所城乡医保门诊报销的公立医院。。
。

武清二院是拓客猫软件超融合老用户。。最初，，由于医院信息科老旧硬件持续故障及人力不足，，武清二院选择拓客猫软件超融合进行数字化升级。。。。随着数字化升级的深入，，，也因拓客猫软件持续高效的运维服务，，，，武清二院决定采用托管云模式建设其IT基础设施，，，将HIS、、、、PACS、
、、EMR、
、、、LIS及集成平台等全部核心业务迁上托管云。
。。

武清二院原有机房现状

存在的痛点与挑战

武清二院原机房为典型的三级医院拓扑，，，，划分内外网两个区域
，
，，中间通过网闸进行隔离，
，外网区域承载DMZ业务与外网办公区。。。内网区域承载核心业务与内网办公区
，，，同时卫健委的卫生专线和医保专线、
、银联结算专线都需要拉到内网。。
。。但存在以下痛点：

• 运维层面：业务繁多，，且大量物理设备运维难度大。。。。此外，，，服务器设备大量过保，
  ，，已无原厂服务。。出现过院内运维人员不足，
  ，运维故障处置不及时，，，，造成设备宕机，，，，HIS瘫痪，，导致P1级别重大事故。。。。在事故后，，，拓客猫软件协助医院排查拉通各方厂商，，
  ，，及时处置兜底，，，运维能力获得用户认可。。。。但用户认为在目前的环境与运维体系下，，很难避免再次出现类似问题。。。

• 成本层面：机房运维投入、、
  、设备维保投入、、、超融合资源扩容投入、、安全建设投入、
  、
  、、老旧设备换新投入等等
  ，，，平均每年170万+
  。。。。按医院当前的经费预算，，，很难一次性投入整体机房改造建设。。。。

原有组网拓扑

原有设备清单

安全设备清单

主要业务情况

拓客猫软件线上线下一朵云解决方案

本次方案采用专属托管私有云模式，
，，资源集群独享，，采用产品+服务的方式进行建设。。同时支持按年订阅弹性计费，，若后期需求变动可对资源以年为周期按照节点数进行动态弹性伸缩，，
，以灵活应对医院后续业务需求。
。。

基于同架构混合云统一管理能力，，线下机房利旧作为容灾机房，，，，主站点全业务上托管云
，，满足线上线下资源及业务的统一管理、、、统一监控诉求
，，也满足用户对业务连续性及合规性的要求。。。

同时，，，，针对医院的合规需求，，托管云线上一站式提供等保三级所需的安全组件及配套的安全运营服务
。。

网络架构规划

为保证最小化医院的网络拓扑改造带来的不必要业务影响，，医院机房现有网络架构保持不变
，，规划二层专线网络打通（下图绿色部分），
，
，将现有内网与专属云平台联通（网关放在医院本地内网核心交换机上），，，，专线采购中国电信专线
，，，共2条，，每条200Mbits，，专线类型为OTN（专线两端的交换机模块均为千兆单模，，由运营商负责提供；运营商网络接入设备安装在托管云机柜内），，
，，专线距离40km。
。。

专线接入

在专线高可靠保障上，，，运营商的接入采用了主备链路聚合方案，，
，，通过确保当主链路出现故障时，，被链路可以自动接管流量
。。在这种模式下，，，只有一条主链路是活跃的，
，所有流量都会通过主链路传输。
。。。备链路处于待命状态，，，仅在主链路故障时才会激活。。因此，，，，在专线选型时
，，也要确保单根专线带宽可以满足医院业务需求。。。。

在做专线接入建设时，，首先需要调研用户现网环境，，，，需要提前确认以下几个问题：

1. 与用户确认云上使用的网段、
   、VLAN-ID、
   、
   、VLANIF网关，，并和网络组确认是否存在VLAN-ID冲突情况。。。

2. 确认与专线互联的本地交换机上可以使用的两个物理端口，，，并确定好可用的ETrunk编号。。

3. 配置过程中，，，核对需要做聚合的口，，，并放通对应的VLAN号，，，确保云上云下的网络互通
   。。

专线建设流程如下：

VPC网络规划

由于医院本地的业务网络为172.31.1.x的网段，，，解决方案团队在调研用户环境时识别到了这一问题，，并提出风险
：托管云NFV中的防火墙与本地网段存在冲突问题。。。

VPC上AF和路由器管理IP用的是业界通用的私有保留网段172.31.1.x和172.31.2.x，，，所以产品上后台为防止路由器直接限制了 172.31.X.X的创建限制，，因此无法在VPC内创建和本地同网段的业务进行互通。。。同时桌面云所使用的172.31.45.x需要在VPC内创建，，后台也限制了，，，，实际用不上那么多保留地址。。

摆在面前有三种方案：

1. 用户线下网段整体进行修改
   ，，但对信息科来讲工作量较大
   ，，，
   ，且影响到现有业务。。。。

2. 修改过后台强行修改AF与路由器管理IP地址，，，但这种方式只是临时性，，，一旦后续组件或平台升级，，，还是会恢复成172.31.1.x网段
   ，，，此时必然会影响到业务
   。。。

3. 从云上入手
   ，，
   ，云上业务需要能整体将网段改为与线下一致。。。

最后与用户对方案反复论证，
，
，解决方案团队决定在云上重新进行网络规划设计，，提非标部署，，，最终方案为云上业务均采用经典网络部署
，，通过VLANID直接透进来
，，，避免以上的风险，
，，，也保证云上业务与线下业务同网段，，，减少线下网段改造成本
。。
。。仅桌面云采用VPC网络的方式进行部署。。。

医院线上线下网络规划

由于内网业务上云，
，因此托管云上不设计公网出口，，线下内网核心交换机通过专线的方式连到托管云机房打通大二层，，，，将托管云节点作为武清二院本地数据中心的延伸。。。

原有的卫健委的卫生专线、、政务外网、、政务内网与运营商专线从外部连到内网核心
，，中间经过防火墙和IDS检测，，，此处无需更改机房原有网络拓扑，，，，减少业务变更影响。。

医院线上业务分为几个区域，，除了桌面云VPC外
，，，，经典网络通过VLAN划分安全子网区、、、业务运维区
、、、、生产业务区（新建和迁移业务也做隔离）
、
、、、测试业务区，，，，不同VLAN之间通信则通过三层互通。。。

医院原有线下内网防护区的的等保设备可以复用，，保障线下办公区和部分边缘业务安全
；同时线上经典网络与线下网络用VLAN隔开，，，线上部分同时划分一个VLAN作为安全区域部署云上安全组件，
，专门负责线上业务安全防护
。。。。

资源规划

本次项目共计规划4节点的托管私有云
，，，，型号均为aServer-R-2305。。
。一共提供350TB的混闪存储。。

由于医院规模相对三级医院较小，，且ISV厦门智业HIS对当前医院业务存储性能无性能要求，，，因此采用混闪卷承载。。。最后由院方和ISV验证效果即可。。

原先超融合上运行的业务虚机，，由于线上线下同构，，虚机配置基本不用修改。。。部分线下虚拟机CPU、、内存的使用率已大于50%
，
，考虑到未来的增量，，规划对应的资源进行扩大1.5倍
。。
。。当虚拟机的存储容量小于60%时，，，则保持对应的规格不变，，，如果大于60%，，，，则将对应的存储容量进行扩容1.5倍。。。。

容灾规划

规划的医院业务上云后，
，原有承载业务的两套超融合也相应闲置。。。。因此
，，
，，线下的超融合可利旧构建线下业务容灾集群，，极端情况下业务也可恢复到本地灾备站点
，
，保障业务正常运转。
。
。。其余的超融合可以承载部分非核心业务，，，，包括院内一卡通、、智慧食堂业务等。。。

当前武清二院主数据中心部署在托管云上，，承载医院的核心业务系统（如HIS
、、、PACS、、
、EMR等）。。。。灾备中心通过利旧的形式部署在原有的线下机房，，，作为主数据中心的备份容灾节点
，，实现数据中心与灾备中心之间的异步数据传输。。。
。容灾的业务包括：HIS、
、
、EMR
、、、内镜
、、、血糖监测等核心业务
，，，
，确保在发生主数据中心故障时，，，，灾备中心能够迅速接管业务
，，，医院的核心业务不受影响。。

在容灾策略上
，
，，，院方基于资源和实际业务需要考虑，，，，对重要需容灾业务本地备份每小时备份一次，
，，将RPO定在2小时，，，，每2小时线上受保护业务会向线下容灾站点传输数据。
。从而实现兼具效果和高资源利用率的一朵云容灾。。

DaaS规划

由于院内各部门科室的办公电脑老旧、、、型号不一，，运维管理难度也随之增大。。借助此次上云机会，
，院方也希望通过云桌面统一管理院内终端，，，，同时实现更好的安全管控。
。。此次项目也规划了托管云DaaS方案。。。

DaaS单独划分了一个VPC，，
，，医院各科室办公PC替换成瘦终端、、或以PC上登录VDI客户端的方式接入到医院外网或内网办公区，
，，，再经过专线到达托管云节点，，通过专线连接的业务口、、
、VLAN网关，，走三层路由进入承载桌面云虚机的业务运维区子网
，
，
，从而实现数据不落地，，，全留在数据中心内网的安全防护效果。。。院内的桌面云虚拟机也由托管云节点内管理集群的VDC统一管理，，，从而实现办公业务与内网业务统一运维
。。

业务落地

网络架构规划

在本次业务迁移上，
，院方着重考虑两个方面的事情
：

• 业务迁移后IP地址是否需要重新规划，，如何保障业务之间互访正常？
  ？？

• 业务系统迁移过程中，，如何保障整体迁移的效果和迁移的速度？？

关于第一个问题
，，如前文所述，，由于线上经典网络和线下直接大二层打通，，，，且划分到同个VLAN中，
，，，因此无需再更改业务IP。。。。

针对第二个问题，，，我司与医院从迁移的计划
，，切割窗口的安排，，，，各方协调验证
，，兜底等也做了详细的评估
：

院内全业务迁移分多批次迁移
，
，整体历时3个月。。为保证预留足够的时间检验业务迁移效果，，
，每次只迁移1-2个业务系统
。。迁移时所有数据传输通过热备的形式，，，不影响业务，，数据传输完成后等待切割，，，，等待切割阶段有增量数据也会持续传输。。。。因为医院本身属于二级医院，
，，，周末晚上业务较少，，
，，因此切割窗口定在周末的晚上8-9点
，，中断时间控制在30分钟以内。
。切割完成后，，，由信息科协调好的ISV厂商会进行上线前与上线后的应用验证。。。最后院方夜间值班的医护人员和住院部会验证已上线业务的使用情况。。。
。整个流程持续4-5个小时。。

上云业务主机共计34台业务，，，，同时配合用户侧新开云主机17台，，，，后续按用户需求持续进行部署添加。。。

业务运行情况

当前业务通过经典网络的方式和线下互通，，，线上拓扑如下：

当前业务已稳定运行在托管云上
，，各项业务运行正常。。。

容灾演练

业务整体迁移完成后，，，，除了业务验证外，，用户也十分看重容灾的效果。。。我们的服务团队也制定了对应的容灾演练方案。。
。此次容灾演练选取了HIS中的血糖监测服务器和内镜服务器，，属于核心但相对影响面不是特别大的业务。。虽然血糖和内镜服务器没有关联性，，
，
，但用户认为不止需要验证单机拉起的容灾效果，，也需要验证业务组拉起的效果，，，因此将两者绑定为受保护业务组
，，，
，可做到一次容灾
，，即可按规划的顺序拉起指定业务。。。。容灾时间也安排在晚上
。。

容灾演练流程记录如下
：

方案价值

• 专属托管私有云支持按年弹性计费，，，若后期需求变动可对资源以年为周期按照节点数进行动态弹性伸缩
  ，，，
  ，以灵活应对医院后续业务需求。。。。

• 基于同架构混合云统一管理能力，，，满足线上线下资源及业务统一管理、
  、、统一监控诉求

• 方案设计过程中，
  ，，，专属运维团队为用户提供一客一案的架构优化设计服务，，，，根据用户实际业务情况，，，，及时调整网络规划解决线上线下IP冲突问题。。。

• 通过双专线提供高SLA的链路质量，，实现分钟级自动恢复
  ，，，同时保证线上线下业务低时延
  。。。。

• 为医院提供混合云容灾方案，
  ，同时提供包括信息收集、、、规划设计、、
  、建设实施、
  、、、验证移交的全流程容灾服务，，，在医院可控的晚间时间完成了关键业务容灾演练，，，，整体方案及演练效果均可满足用户对业务连续性及合规性要求。
  。。

• DaaS建设保障院内数据不落地，，，，统一终端运维，
  ，，减轻用户运维和安全管理压力。。

• 上线即等保，，
  ，
  ，免去复杂的等保合规改造（含：日志审计系统、、、、漏洞扫描系统、、、、数据库安全审计系统、、、
  、运维安全管理系统、、安全态势感知系统、、、、SSL VPN）及配套的安全运营服务
  ，，同时等保测评整改不用用户操心
  。。。。相比之前0安全团队
  ，，
  ，，现在有7*24小时的安全服务，，，还有安全兜底勒索赔付服务。。
  。。

• 高SLA的基础设施，，
  ，，机房环境更好，，减少故障发生
  ，
  ，，及时出现问题也能实现最快1分钟发现，，，，5分钟内响应，，，，且7*24小时均有专人值守服务。。运维人员更专业，，能释放信息科人员精力，，，，让医院信息科更专注在业务上。。。

拓客猫软件托管云持续关注用户的真实需求，，以贴心服务、、安全有效、
、、
、专属可控、
、、灵活开放为核心，
，，，为各行业用户打造更全面的云底座，，以创新技术与完善方案支撑用户业务发展
。。。