新闻来源：中央电视台 2016年08月03日 16:40 浏览次数：10537

----------------------------------------------------

　　广电行业网络化、文件化制播体系的快速发展，对于支撑广电行业节目制播的IT基础平台在稳定性、可靠性方面，提出了更高的要求，IT基础平台需要具备电信级高可靠性，提供7×24小时不间断服务的能力，才可以保障整个网络化文件化制播平台稳定可靠运行。

　　2012年中央电视台开始启用网络化文件化全流程制播平台。经过建设、试运行、正式运行几个阶段后，在基础平台的以下技术层面进行了相应的实践和探索。

　　一、应用系统

　　应用系统在服务器资源池上跨站点部署，同时利用虚拟化技术实现不影响业务的计划停机维护和快速故障恢复。主要技术点如下：

　　1.应用系统在服务器资源池上跨站点部署

　　中央电视台关键业务所使用的服务器资源池采用了结构和规模相同，但设备完全独立的两个资源池站点部署模式。如图1所示。

 图1.服务器资源池架构

　　在站点1内，基于x86刀片服务器和VMware虚拟化软件搭建虚拟化资源池-site1，由一对存储虚拟化设备（node1和node2）提供数据卷vdisk-0-site1用于存储虚拟机文件。在站点2内，使用另外一组服务器和存储虚拟化设备搭建虚拟化资源池-site2。两个站点上联的以太网交换机和FC交换机配置为2台构成冗余结构。

　　核心业务应用系统在部署时，将同一功能角色的两个服务器的节点VM1和VM2分别部署在不同的站点中，再通过负载均衡将VM1和VM2以统一虚拟IP对外提供服务。

　　由于两个站点从计算资源、网络资源到存储资源完全独立，应用的跨站点部署可以保障即使在一个站点发生灾难场景完全不能工作时，另外一个站点不受影响，在另一个站点上的应用节点仍在正常工作，只会短时间降低业务的服务性能而不会导致整个业务系统瘫痪。

　　这种服务器资源池部署模式相当于公有云上的可用区，应用服务器节点跨站点的部署与公有云上在不同可用区的高可用部署方案不谋而合。

　　2.不影响业务的计划内停机维护

　　计划内停机主要用于完成系统硬件维护更换、服务器物理位置迁移和固件更新等等，由于采用了服务器虚拟化技术，可以将虚拟机随时动态移动到其他宿主机上而不影响业务系统的运行。在需要进行计划内停机操作时，无需停止或中断服务，从根本上消除了日常维护操作所需的停机时间。

　　（1）宿主机服务器维护

　　通过对虚拟机执行VMotion操作，将需要维护的宿主机服务器上所有虚拟机动态迁移到池中的其他宿主机服务器后即可进行，迁移动作不影响相应虚拟机的正常运行。

 图2.VMotion 操作

　　（2）数据核心存储维护

　　需要对存放虚拟机配置文件等的核心存储进行维护时，可通过对相应虚拟机执行Storage VMotion 操作，即可实现在不中断服务的情况下将虚拟机的磁盘文件迁移到其他的物理存储空间。

　　3.服务器故障快速恢复

　　（1）宿主机故障时虚拟机业务自动恢复

　　通过将多台宿主机组成群集，借助虚拟化产品的高可用vHA （High Availability）技术，可以在某个宿主机服务器发生故障时，快速、智能自动重启集群中受影响的虚拟机，从宕机到重启虚拟机只需约5分钟左右，即可实现服务器资源的快速恢复，大大缩短意外宕机时间。

 图3.宿主机vHA

　　（2）宿主机业务处理能力的快速恢复

　　将全部的虚拟机文件存放在集中存储设备上，以提高存储的使用效率和数据的安全性，如果将宿主机的操作系统ESXi安装在本机的硬盘上，在宿主机硬件发生问题时，系统管理员或软件维护人员就必须重新安装和调试操作系统，造成宿主机业务恢复时间很长。经采用Boot From SAN技术，我们可将宿主机操作系统部署到外接的SAN存储上，利用存储的高可靠性和备份功能来保证宿主机业务运行连续性。在虚拟化宿主机乃至物理单机服务器硬件损坏时，可以通过快速将故障刀片的配置信息迁移至其他资源池内的冗余刀片后启动新刀片，数分钟内即可完全恢复宿主机的原有处理能力。

　　4.效果总结

　　上述几种技术的应用，使得中央电视台基础平台的服务器运行更加稳定可靠，日常业务的运行未因为某个宿主机硬件的故障受影响。通过对关键业务的服务器使用分布式部署技术，使得这些业务的关键服务不会因为某个物理设备的故障而中断，保证了业务连续性。另外，依托一系列虚拟化技术，实现了数据中心主动维护工作可以不停业务进行。在单台宿主机的故障情况下，快速恢复受到影响宕机的虚拟机等目标。

　　二、数据库

　　数据库的主备+应急架构实现数据库高可靠运行、快速切换以及恢复。

　　1.数据库主库的双活技术

　　中央电视台的核心数据库主库采用了oracle数据库软件，版本为11g R2，每个数据库部署2个x86服务器构成可以同时对外提供服务的RAC节点。

　　除心跳网络外，每个节点配置1个public IP，1个VIP，两个节点共同配置1个SCAN IP，SCAN IP运行在任意一个工作正常的RAC节点上。应用系统通过SCAN IP连接数据库，由SCAN IP将访问请求均衡地分配给两个RAC节点，实现数据库两节点共同分摊负载。在一个节点出现故障宕机时，2个VIP和SCAN IP会漂移到另外正常工作的节点上，漂移切换的时间为秒级。SCAN IP通过自己的健康检查机制，不会将访问请求分配给不工作的RAC节点，对于使用数据库连接池的应用程序，几乎感受不到单节点宕机造成的影响。

　　2.四层交换机的使用与主/备切换、应急切换

　　为了确保核心数据库业务的不间断运行，除数据库主库之外，还配备了一套完全独立于主库设备的应急数据库。使用DataGuard软件在主库与应急库间通过日志同步来实现数据的同步。应急数据库的数据与主库保持完全一致，在主库的两节点都不可用时，可将业务切换至应急库上运行。

　　由于应急数据库的IP地址与主库的IP地址不同，在做应急切换时，除了数据中心运维人员完成主库和应急库的切换操作之外，同时也需要应用系统将应用前端所有需要连接数据库的设备的连接字符串中的IP地址进行替换。由于前端应用涉及的设备很多，在应急情况下进行上述配置改动非常不便，操作时间大约在30分钟至1小时左右。造成业务的中断时间无法达到保障播出安全的要求。

　　另外从数据库的运行情况来看，主库的两个节点同时工作尽管充分利用了服务器资源，但节点间双活需要存在大量的数据交互，容易引发节点间的互相干扰；而SCAN IP的自动故障切换机制也不尽完善，出现过单节点故障发生切换后VIP、SCAN IP不生效等bug。

　　鉴于SCAN IP技术的一些缺陷，后期，我们在应用系统与数据库系统之间部署了四层交换机，后台数据库主库节点以及应急节点均通过四层交换机虚拟出一个服务IP提供给应用系统。

　　正常情况下，这个IP对应一个RAC节点的Public IP，用户对数据库的访问请求只能被分配到这个节点上，另外一个RAC节点没有负载，只作为热备机。

　　当主节点出现故障时，通过四层交换机将数据库四层IP指向备节点，完成数据库的主备切换。当主库两个节点都不能正常工作时，采用Switchover或Failover方式进行应急切换，并将数据库四层IP指向应急库。

　　Switchover的切换仍保持主库与应急库之间的同步关系，但是将同步反向。

　　Failover的切换更为彻底，直接将应急库打开提供服务，由于这种模式下主库与应急库的数据已没有同步关系，主库数据不可再使用。

    图4.数据库架构 

 图5.数据库架构

　　3. 数据库数据双写技术的实现

　　为了保证在单一核心数据存储体出现故障的情况下，数据库依然能够继续正常对外提供服务，我们必须考虑对相关数据存储进行冗余设计，我们主要在以下两方面进行了设计：

　　（1）Voting disk模式

　　如图6所示。

　　在Oracle 11g R2这个版本中， OCR和Voting disk都存放在ASM diskgroup里，OCR 记录的是节点成员的配置信息，如数据库、ASM、实例、监听器、VIP等CRS资源的配置信息；Voting disk里面记录着节点成员的信息。在统一数据库平台我们采用了普通冗余模式磁盘组，里面包含三个Voting disk，分别来自三个独立的存储设备。Oracle 集群正常工作的前提是，必须要有一半以上的Voting disk同时可用，否则集群会立刻宕掉。在当前我们采用的模式下，如果单一存储体出现故障时，不会对集群的运行造成影响。

图6.票盘冗余架构 

 图7.数据冗余架构

　　（2）数据冗余技术

　　如图7所示。

　　在应用数据层面，ASM DISK GROUP 提供三种冗余级别（外部冗余、普通冗余、高度冗余），在统一数据库平台我们采用了普通冗余模式，普通冗余的磁盘组包括两个故障组，对于文件里面的每个AU（Allocation Units），都会存在该AU的一份镜像副本，单个磁盘损坏或者整个故障组损坏，始终都不会丢失数据。通过此技术每份数据至少会分别写入到两个不同的存储体中，即使一个存储出现故障也不会造成业务数据的丢失。提供FG1和FG2的两台物理存储配置完全一致，经实际测试验证，数据双写所造成的性能损失在2%左右，可以忽略不计。

　　4. 数据库应急切换后的快速恢复

　　当主库发生灾难故障需进行Failover切换，在业务切换至应急库运行后，故障的处理并未完成。主库急待恢复，只有业务从应急库切正常切换回主库后，整个故障处理才算告一段落。

　　对于主库的恢复，一般采用RMAN备份数据导入方式，将备份点的数据还原，将主库的状态回退到备份时间点上，再通过配置DG将应急库上保留的日志传送到主库，将备份时间点至当前的数据差找平，做到应急库与主库之间数据实时同步，再通过Switchover切换将业务回切到主库上。

　　虽然过程看起来比较简单，但对于数据量较大的库，进行一次RMAN恢复的时间往往达到十几个小时甚至更长，完整的数据库恢复代价很大。在面对主库以天计算的漫长恢复时间时，故障切换的决策甚至会受到影响，运维人员往往寄希望于重启主库尝试恢复业务，不愿意立即执行Failover切换，由此造成应急数据库不能发挥应有的作用，无法做到业务的快速切换。

　　中央电视台在运维实践过程中，除了保留RMAN备份恢复的方案，还采用了存储层面的快照技术来完成Failover切换之后的主库恢复，加速主库的恢复。具体实现方法如下：

　　日常运行时，在主库上执行脚本，开启主库的Oracle备份模式，其目的是锁定数据库状态，然后在存储上对卷打快照，将锁定了状态点的数据库做一份快照。在关闭Oracle备份模式后，再进行standby controlfile备份。为了不影响系统性能，可选择在每日业务非繁忙时间执行脚本，对主库创建该时间点的快照。

　　在恢复主库时，在存储上应用快照，将主库的卷退回到快照点，通过standby controlfile打开数据库，此时主库的状态以及数据回退到了快照时间点上，之后的操作与RMAN备份恢复方案完全一致。

　　由于在存储级别对卷执行快照回退操作速度极快，可秒级完成，将RMAN备份数据导入所需的大量时间省略，从而大大缩短了主库的恢复时间。

　　对比存储快照恢复和RMAN恢复的效率，通过RMAN恢复主库的时间要视数据库中的数据量而定，对一个1.4TB数据文件的数据库进行主库数据恢复测试比较：存储快照方案大约为30分钟，而通过RMAN方式恢复需要10小时。

　　5.效果总结

　　通过在运维过程中逐步进行的上述加固优化，根据运维可靠性需要，将数据库主库从两个节点同时工作，改为主/备工作模式，避免主库两个节点间大量数据交互和由于节点间干扰带来的系统出错风险，解决了系统自动切换可能失败的问题，提高切换操作的可靠性。

　　同时实现了数据双读、双写两个存储体，避免存储设备单点故障引发数据库服务中断的隐患。

　　在应急操作方面，将应用前端改为通过四层交换机转换的IP连接数据库，使得切换应急系统不再需要前端改应用配置，大大加快切换速度。在四层交换机的Web管理界面操作，主库、备库的切换大约10s左右即可完成，前端应用同步恢复正常工作状态；在数据库应急切换模式方面，通过执行脚本使用DG Switchover切换，5min左右即可切换到应急库；Failover模式切换需要1min左右。

　　另外，通过采用存储快照恢复主库数据，可将恢复时间从十几小时缩短到数十分钟，大大加快主库恢复的速度，解决了Failover应急切换后主库恢复困难的问题。

　　三、存储虚拟化

　　存储虚拟化加固技术实现了基础平台关键数据和文件的双活存储。

　　在数据库存储高可用方面，我们采用了Oracle的ASM卷管理软件技术，实现对两个存储体的双读双写。除此之外，承担关键业务的UNIX服务器以及虚拟化环境所需要的集中存储，也需要采用相关的技术手段避免单一存储设备的单点故障时引发服务中断的问题。

　　1.基于存储设备卷复制的容灾方案

　　UNIX服务器：正常运行时，由一个存储体对主机输出卷，在另外一个存储体上配置“影子卷”，依靠存储的卷复制技术，将数据定期同步到“影子卷”上。在单存储故障时，手工从另一台存储将“影子卷”输出给主机，主机重新挂载并配置。

　　VMware虚拟化环境：在原理上与上述UNIX服务器的容灾方式一样，略有区别在于故障切换完全由站点容灾软件SRM（Site Recovery Manager）执行，在单台存储故障时，脚本自动执行从另一台存储将“影子卷”内的虚拟机启动。

　　基于存储设备的卷复制容灾方案的不足在于单一存储体故障后，应急切换时业务会中断，而且切换时间很长。一组HA的UNIX服务器手工切换大约需要1小时左右，多组服务器还需要顺序进行人工操作。即便是SRM切换，一个站点300多台虚拟机恢复，也需要数十分钟。

　　因此，为缩短单一存储设备单点故障时的业务中断时间，中央电视台采用基于存储虚拟化设备的容灾技术方案代替了卷复制方案。

　　2.基于存储虚拟化技术的高可用容灾方案

　　如图9所示：存储虚拟化设备对存储硬件资源进行抽象化处理，其功能类似存储的控制器，在SAN网络内对服务器提供数据卷。后端挂载的是多个FC-SAN存储设备，将两个存储设备分别输出的同样大小的卷，逻辑上捆绑为1个卷，再对主机输出。存储虚拟化设备可以将两个节点组成一个I/O group，同时对外提供服务。

　　存储虚拟化设备，将来自不同存储系统的磁盘空间通过存储虚拟化设备统一池化管理，并基于不同的存储系统创建镜像虚拟卷。实现了数据在两个存储设备上双读、双写，即使单台存储虚拟化节点或者单存储出现故障，主机不用进行任何操作仍能保证其上运行的业务系统持续稳定运行，高可用性得到了很大程度的提升。

　　3. 效果总结

　　通过进行实际功能及性能测试，当单台存储虚拟化节点或者单台存储设备发生故障宕机时，前端主机大约有10秒左右的存储I/O中断，然后恢复正常的读、写操作。在模拟实际场景（混合读写模式即70%读30%写）下，引入存储虚拟化设备大约会造成10%左右的性能损失。

 图8.基于存储设备的容灾架构

 图9.存储虚拟化架构

　　四、总结

　　在这些年的运维工作中，上述高可用技术的组合使用，大大提高了中央电视台基础平台的可靠性，在日常安播保障维护工作中，结合全台IT统一监控系统的合理使用，实现了系统架构坚固稳定，发现问题主动快速，应急切换快速有效，系统恢复及时可靠的目标。

　　本文在技术讨论中，未就技术的实现原理以及详细的配置进行细节描述，旨在通过一些方法和实践经验的介绍，为广电行业同仁在提高制播系统整体高可靠运行方面提供一些参考和借鉴。

　　下一阶段我们面临着云平台建设任务以及双活数据中心建设任务，如何使用适合的技术实现平台先进有效，同时稳定可靠也是系统建设考虑的关键。

上一篇： 融媒体演播室节目制作实践
下一篇： “十三五”时期加快我国电视媒体创新创优发展的思考与展望