一种卫星电视容灾管理原型系统的设计与实现.pdf

无线发射与节传Wireless&Transmission1 引言经过近几年的发展，卫星电视用户规模快速增长，前端平台支撑能力不断提高，在卫星电视的业务发展中起到了重要的保障作用。因此，一旦出现不可恢复的平台故障或数据丢失，造成的社会影响和经济影响都将是不可估量的，此种情况下，建设异地灾备数据中心平台势在必行。业务运营系统汇聚了大量的用户信息等重要数据，按照广播电视网络安全等级保护基本要求中关于“数据安全与备份恢复”的要求，应能够对重要信息进行异地备份，利用通信网络将关键数据定时批量传送至备用场地。在发生不可抗拒的故障或灾难时，提供不间断的业务支撑服务，并对重要数据在实现本地备份的基础上，增加异地备份，有效地管控数据，提升数据的安全性和可用性。考虑到卫星电视用户量大，业务活跃，且存在超过数十倍的销售峰谷比，有必要对用户进行分系统管理或分中心管理，实现在提高系统安全保障能力的同时，降低高并发量下的系统压力。因此，本文设计并实现了一套容灾管理原型系统，提出在灾备数据中心新建一套卫星电视业务运营系统，并将该新建业务系统部署在生产数据中心。与此同时，将生产数据中心现有业务运营的业务系统也同步部署在灾备数据中心，主备系统在同一数据中心，通过资源调度系统互为备份，也可以分担业务，通过数据同步系统实现数据在主备系统、主备数据中心的实时同步转换和备份。当主中心因重大事故瘫痪后，备中心可在电信部门按应急预案调整备中心的网络地址后，及时全面接管所有业务运营业务。综上所述，主备业务运营系统可以按异构双活方式建设，异地部署。此外，还需建立有效的异地数据传输机制，利用可靠的通信网络，将增量数据传送至灾备数据中心；建立有效的数据完整性校验机制，能够对重要业务数据的完整性进行校验，并在其完整性遭到破坏时，采取必要的恢复措施。2 容灾管理原型系统设计建设统一的资源管理系统，并在生产数据中心和灾备数据中心同时部署，对智能卡、机顶盒、产品卡等基础资源统一管理；建设数据同步系统，并在生产数据中心和灾备数据中心同时部署，对两套应用系统数据进行采集、清洗，以标准格式存储，将存储的标准格式数据同步至异构业务系统，实现双系统核心数据实时同步；建设容灾调度管理系统，并在生产数据中心和灾备数据中心同时部署，支撑容灾必备的统一监控、系统切换、测试演练等功能。数据中心异地灾备总体架构设计如图 1 所示。2.1 系统并行运行机制设计按照容灾规划，在生产数据中心和灾备数据中心同时部署主备两套业务运营系统。在日常运行中，生产数据中心承担全部生产任务，并将动态业务数据实时同步给灾备数据中心，同时将更新的应用软件和配置文一种卫星电视容灾管理原型系统的 设计与实现文/国家广播电视总局广播电视卫星直播管理中心 王鹏鹏摘要：本文在研究卫星电视平台现状的基础上，提出了一种卫星电视容灾管理系统的设计，并完成了相关原型系统开发，经过验证，达到了预期效果。关键词：卫星电视容灾管理系统 设计 原型系统开发 结果验证无线发射与节传 Wireless&Transmission 2023年7月 月刊 总第375期件同步给灾备数据中心，保证生产数据中心与异地灾备数据中心的数据和应用始终一致。当生产数据中心的某一套业务运营系统出现故障时，可以将业务切换至本中心的另外一套业务运营系统；当生产数据中心出现灾害时，可以将业务全部切换至灾备数据中心，通过灾备数据中心的主用业务运营系统和备用管理系统，共同承担全部业务。通过上述应急切换，保证业务连续性。业务运营系统主要包括用户管理、位置管理及服务区域等子系统，分别实现用户管理、位置管理和服务区域管理等功能，并通过三个子系统的联动，实现卫星电视业务和用户的统一管理。2.1.1 用户管理子系统两个中心的主用用户管理子系统和备用用户管理子系统之间进行实时数据同步，实现应用级容灾；双数据中心与业务运营系统之间进行实时数据同步，实现平台级容灾。2.1.2 位置管理子系统每个中心部署一套位置管理子系统，两个子系统之间实时数据同步，实现应用级容灾。机顶盒开户更换设备时，主用用户管理子系统完成业务处理后，将用户注册信息实时同步给本中心的位置管理子系统。位置管理子系统与另一中心的位置管理子系统进行实时数据同步，保证两个子系统中用户数据的一致性。如果启用主备系统各承担一部分业务的方式，主用位置管理子系统能够自动判断用户归属，并将比对结果发送给生产数据中心对应的用户管理子系统，进行后续业务处理。2.1.3 服务区域子系统每个中心部署一套服务区域子系统，两个子系统之间实时数据同步，实现应用级容灾。考虑到服务区域业务处理较为简单，且访问人员为各级广电部门工作人员，用户总量较少，两个中心的服务区域子系统采用主备方式部署。现有生产数据中心服务区域子系统作为主用系统，负责完成服务区域以及库信息更新，并将更新数据实时同步给异地的备用服务区域子系统。按照约定的更新时间，服务区域子系统分别将服务区域信息、库信息等更新至用户管理子系统和位置管理子系统。2.2 容灾故障切换机制设计故 障 切 换 机 制 分 为 服 务、系统、平台三个层面。服务层面是指生产系统内部某服务器繁忙或发生故障时，针对此类故障，只需按照常规高可用方案，将相应服务请求调度到其他应用负载实例即可；系统层面是指当生产系统出现应用级不可恢复故障时，可通过容灾调度系统，将用户流量平滑牵引至同一中心的备用业务系统；平台层面是指当两地之间的主备数据同步链路均出现故障中断时，可通过容灾调度系统进行紧急切换，异地灾备数据中心迅速接管原业务系统。2.3 双中心交互带宽估算灾备数据中心在进行选址时，需要考虑的传输线路包括两类，即生产数据中心与灾备数据中心的专线线路、灾备数据中心与互联网的接入线路。生产数据中心与灾备数据中心之间的数据同步包括两种情形：一种为原始数据的同步，这是在灾备数据中心建成后，一次性将生产数据中心的数据同步到对应灾备数据中心同构系统上去；另一种为生产数据中心与灾备数据中心每天需要实时同步的数据。对于原始数据的同步，可以一次集中进行同步（时间可以长些）；对于实时同步，需要每天进行同步，这就涉及生产数据中心与灾备数据中心直接部署多少带宽，才能满足数据同步的需求。数据同步包括系统数据的实时同步，考虑到双数据中心之间为异构系统，且异构系统之间的数据同步主图 1 数据中心异地灾备总体架构设计 无线发射与节传Wireless&Transmission要依靠数据库事务日志（Redo Log），因此，可以用事务日志量来估算传输带宽需求。网络带宽估算公式为传输带宽=（所需传输的数据 8bit/传输时间）（1+冗余量）/数据传输压缩比率；所需传输的数据=在线 Redo Log 容量 Redo Log 切换次数。通过查询业务运营系统字典视图，可以获得忙时在线 Redo Log 每分钟的切换次数。与每个在线 Redo Log的大小相乘，则是忙时数据库每分钟需要传输的 Redo Log 信息总量，容灾网络的带宽应至少满足此条件。业务运营系统，含用户管理子系统、位置管理子系统、服务区域子系统，用户管理子系统与 CA 接口平台，每个在线 Redo Log 的容量约为 2GB，业务最高峰期间，业务运营系统数据库在线 Redo Log 约为每两分钟切换一次，考虑到 20%的冗余量和 90%的数据压缩比，则网络带宽=在线 Redo Log每分钟切换次数 在线 Redo Log 容量 81.2 数据压缩比/1 分钟=在线 Redo Log 每分钟切换次数 在线Redo Log 容量 81.20.9/60=0.52102481.20.9/60147Mbps。故拟采用临时一路 155Mbps SDH，满足原型系统设计与验证需要。3 容灾管理原型系统容灾管理原型系统拟采用“2+2”方式搭建，即主用与备用业务运营系统、生产数据中心与备份数据中心；在生产数据中心建设统一的资源管理中心并建设备用业务运营系统，在灾备数据中心建设备份数据中心。备份数据中心采用 1:1 部署模式，部署各个核心业务系统，即主生产数据中心与备份中心部署环境完全一致。为了在生产数据中心出现不可恢复故障时，备份数据中心能承载业务，需保证生产数据中心与备份数据中心的软件版本与配置完全一致，数据库数据实时同步，并完全一致。3.1 系统主要实现功能开发备用业务运营系统。正常情况下，主用业务运营系统承载业务，备用业务运营系统不承载业务，单向将主用业务运营系统的数据同步至备用业务运营系统；在主用业务运营系统出现无法恢复的应急故障时，将业务切换至备用业务运营系统，使用备用业务运营系统承载业务，在主用业务运营系统故障完全修复后，再将业务从备用业务运营系统切换至主用业务运营系统。开发容灾管理原型系统应用软件版本管理子系统，对各业务系统软件版本进行管理。同步更新备份数据中心的软件版本，在更新生产数据中心软件版本时，软件版本管理子系统将自动部署软件同步复制到备份数据中心。开发数据比对子系统。可以比对生产数据中心主用与备用业务运营系统之间的数据，比对生产数据中心与灾备数据中心同一个业务系统的数据。开发容灾管理调度子系统。在主用业务运营系统出现故障时，将业务切换至备用业务运营系统，在生产数据中心整体出现不可恢复故障时，通过人工指令触发自动执行方式，通过容灾调度子系统将业务切换至备份数据中心。开发统一资源管理中心，将资源管理模块作为独立的资源管理服务，向主用与备份业务运营系统提供资源管理服务。3.2 容灾管理原型系统实现3.2.1 异构系统数据同步实现主用与备用业务运营系统采用实时异步数据同步方式，即在主用与备用业务运营系统中间，搭建高性能分布式事务型消息队列，主用业务运营系统与备用业务运营系统分别将生产业务数据实时通过高性能消息队列发送到对端应用，对端应用从消息队列获取业务数据，重放写入数据库。主用与备用业务运营系统实时异构系统数据同步交互如图 2 所示。图 2 主用与备用业务运营系统实时异构系统数据同步交互无线发射与节传 Wireless&Transmission 2023年7月 月刊 总第375期统一资源管理中心以 Restful 方式，向主用与备用业务运营系统提供资源管理服务。消息队列为主用与备用业务运营系统提供消息服务。主用与备用业务运营系统为异构系统，两个系统之间的数据同步采用消息队列异步同步方式，两个系统之间对于同一个用户，按照不同的表进行存储。具体来说，可采取存量全量比对与增量比对方式，对两个系统之间的数据进行比对。对于用户实体创建领域实体对象表，使用数据比对子系统，将两个系统的用户数据转化为领域实体对象，对转化完成的数据生成数据指纹，使用 SQL 语句对数据指纹进行全量比对，每周将两个系统产生的增量数据转化为用户实体创建领域实体对象，并生成数据指纹，同时对增量数据指纹进行比对。对于不一致的数据采用人工修复。3.2.2 业务系统容灾调度实现通过对当前核心业务系统的梳理，各个业务系统的子系统大多采用集群部署模式，Linux 与 Windows均有部署，使用脚本方式对子系统进行启停。业务系统各模块均采用脚本方式进行启动和停止，业务系统数据库采用脚本方式进行启停管理。容灾管理系统切换管理器通过命令行方式（Windows 采用 Telnet，Linux 采用SSH）登录业务系统所在服务器，执行切换脚本，对各业务系统进行启动和停止。容灾管理系统容灾调度交互如图 3 所示。数据库是容灾管理系统切换的关键部分，数据是否一致、是否可用，直接决定了灾备数据中心是否能够在生产数据中心出现不可恢复故障时承载核心业务。考虑到生产数据中心与灾备数据中心距离过长，数据同步传输时延较长，数据同步只能采用异步复制模式。对于各业务系统数据同步，采用数据库同步软件进行数据实时异步同步，通过软件最高可用模式数据保护机制，将数据同步至灾备数据中心。同一个业务系统在生产数据中心与容灾数据中心为同构系统，数据存储格式一致，数据相同的表采取全量比对表行数和抽样比对实体列的方式进行数据比对。3.3 结果验证容灾管理原型系统开发完成后，首先在测试环境完成了服务区域系统、位置管理系统的切换测试，经过测试，系统能够成功停止生产数据中心服务区域的业务，并在灾备数据中心启动应用，全部系统切换共耗时 24min，经过验证，业务完全正常，验证了容灾管理原型系统的可用性；其次，在测试环境完成了核心业务运营系统的切换测试，成功完成了业务运营系统从生产数据中心切换到灾备数据中心的演练，共耗时 48min，经过验证，业务系统、数据同步完全正常。4 结语本文设计的容灾管理原型系统能够实现异地数据同步和应用容灾切换，通过开发原型系统，验证了相关异构数据同步和业务系统容灾调度切换的可行性。本文的研究可为相关广播电视异地灾备数据中心建设提供思路，同时随着分布式、云计算等技术的成熟应用，后期可在本方案基础上开展异构分布式双活数据中心相关机制设计，为更好地保障广播电视系统稳定运行和数据安全备份提供技术参考。参考文献：1 贾如春,周晓花,陈新华,等.数据安全与灾备管理M.北京:清华大学出版社,2016.2 葛长芝,鲁盈盈,欧仕强.质量全面管控:从项目管理到容灾测试 M.北京:电子工业出版社,2017.3陈康贤.大型分布式网站架构设计与实践M.北京:电子工业出版社,2014.4 宋 丽 君,徐 建 民.关 于 异 地 灾 备 中 心数据解决方案研究 J.数字技术与应用,2016(10):209.5 程龙.业务支撑系统灾备方案 J.电信工程技术与标准化,2008(6):21-28.图 3 容灾管理系统容灾调度交互