1 城轨云总体架构概述

城轨云采用中心级和站段后备级两级架构，中心级和站段后备级由同一云平台纳管。中心级由生产中心和灾备中心构成，站段后备级云节点主要是在双中心平台同时故障，或双中心到站段网络同时故障时，承担相应站段后备或降级应用服务。城轨云系统总体架构如图1所示。

城轨云架构下，多条线路业务应用系统可统一部署。线网、线路级的同一类业务可按需划分为同一个虚拟数据中心(virtual data center，VDC)。VDC内的计算资源池、存储资源池、网络资源池可按线路扩展，且同一VDC内可进行虚机迁移。同时，同一业务VDC内根据需求可按线路划分虚拟专有云(virtual private cloud，VPC)，VPC可提供安全、隔离的虚拟专网。如图2所示。

2 城轨云灾备概述

2.1 生产/灾备中心

采用生产中心/灾备中心模式建设，生产中心提供所有生产管理、运维管理、开发测试以及综合培训等业务系统主用服务，灾备中心提供热备或冷备服务。当生产中心出现故障时，可以将单个或多个关键应用，甚至生产中心整体切换到灾备中心。

图1 城轨云系统总体架构Fig. 1 Urban rail cloud system architecture

图2 城轨云业务规划Fig. 2 Urban rail cloud business planning

这种模式下，仅生产中心提供服务，灾备中心处于热备或冷备状态。当生产中心发生故障时，灾备中心接管相关业务系统应用。该方案技术实现复杂度较低，主要通过跨生产中心和灾备中心资源部署，通过资源冗余，提高业务可用性。生产中心和灾备中心业务部署的范围和层次存在差异，业务的高可用性和连续性有待提高，资源利用率较低。

2.2 双运营控制中心

采用双运营控制中心模式建设，生产业务系统的应用在生产中心运行，灾备中心提供容灾服务。运维管理、开发测试以及综合培训等应用系统，灾备中心提供主用服务，生产中心提供容灾服务。两个数据中心业务应用互备，当某个应用出现故障时，由对应的生产中心或灾备中心接管应用[1]。

这种模式下，生产中心和灾备中心同时提供服务，但对于某一个业务系统，只由其中的一个中心提供应用服务，当该中心的业务系统故障时，由另一中心接管该业务系统的应用，生产中心和灾备中心互为备份。该方案技术实现复杂度较高，可实现资源跨中心调度，资源利用率较生产/灾备模式有所提高。

2.3 双活控制中心

采用双活控制中心模式建设，所有业务系统的应用同时运行在生产中心和灾备中心，且同时持续提供服务。当某个中心业务系统应用故障时，另一个中心业务系统应用持续提供服务[2]。

这种模式下，同一业务系统在两个中心同时提供服务，根据策略将同一业务系统流量均衡负载于两个中心。该方案技术实现复杂度最高，但能够充分利用两个中心的所有资源，业务高可用性和连续性最优。

3 城轨云容灾关键技术

容灾方案的确定，需增加概算，采购更多主机、存储以及相应软件。基于灾备投资成本与风险控制综合考虑，建议事先分析、评估业务系统需求，再确定灾备的目标以及灾备方案的选择。

结合目前城轨各应用系统的应用现状及云计算技术的应用特性，在实现底层存储双活、数据库双活、网络双活甚至计算层双活的基础上，统筹考虑城轨云承载各业务系统应用的可靠性、可用性、可维修性(reliability，availability，maintainability，RAM)指标，规划适合当地城轨信息化平台建设的容灾方案。

针对城轨云容灾方案，可采用分期建设、分步实施策略。基于目前现状，生产中心与灾备中心可选择active-standby双活容灾模式。该模式下，实现底层存储双活、网络层双活、数据库双活，计算层、应用层可根据具体应用系统的容灾需求和投资情况灵活选择。

3.1 存储双活

存储双活是生产、灾备中心容灾的重要基础。存储双活A/A(active-active)方案，相较于A/S(active- standby)方案，有效利用计算资源，可减少阵列间通信，优化I/O路径，可获得高效访问性能和快捷故障切换速度。存储双活A/A与A/S交互流程如图3所示。

存储A/A双活，可将在生产中心和灾备中心两个域内不同的存储系统构建为单一资源，实现数据共享读写和双向镜像同步。A/A双活允许地理位置分散在不同域间的存储设备同时进行数据I/O，使用者对于具体提供服务的存储设备是透明无感知的，数据可用性和可靠性高。存储A/S 双活，主机无法通过灾备中心的从端直接访问双活逻辑单元号(logical unit number，LUN)，须通过生产中心的主控端访问，主控端通过镜像链路I/O把数据同步到从端设备上，数据跨主备中心传输，影响写入性能[3]。故建议采用A/A架构构建底层存储双活。