媒体云平台技术运维问题研究

刘 鑫

（河南广播电视台，河南 郑州 450008）

0 引言

交互化生产管理云平台是河南广播电视台顺应当前融合媒体的发展趋势，在原有制播云系统的基础上，整合台内技术资源打造建设的全媒体节目生产管理系统。目前该系统已经运行多年，台内包括新闻（四部一频道）、卫星频道、都市频道、电视剧频道、欢腾购物频道、国学频道以及轮播频道在内的多个栏目逐步上线实现送播，相关节目的新媒融合生产和发布也已逐步展开。交互化云平台采用完整三层云架构技术体系，在四年多的实际运行维护过程中，体现了云计算在弹性扩展、业务灵活部署等方面的优势，但同时也给运维工作带来了新的挑战。

1 交互化云平台架构介绍

1.1 三层架构设计标准

按照国家广播电视总局《广播电视台融合媒体建设技术白皮书》的要求，广电媒体云平台要按照基础设施即服务（Infrastructure as a Service，Iaas）、平台即服务（Platform as a Service，PaaS）、软件即服务（Software as a Service，SAAS）三层云架构建设。其中，IaaS 层为基础资源层，提供系统所需的所有硬件资源，包含计算资源、存储资源、网络资源以及安全资源等。PaaS 层为平台层，通过云管平台中间件调用IaaS 层的资源，同时为其上层应用提供媒体资源管理、用户数据管理、内容生产能力、内容分发能力以及公共服务等平台支撑服务，并提供统一的接口标准给其上层应用。SaaS 层通过统一的接口调用PaaS 层提供的支撑服务，并为用户提供各种媒体融合生产所需的应用服务。

1.2 交互化混合云平台架构

河南广播电视台交互化云平台的建设遵循了三层媒体云的架构，并采用混合云构架，使用统一的PaaS 管理系统，利用云管中间件成功将分布于私有云（台内业务生产云）和专属云（租用大象融媒云部分资源）的设备资源统一管理，实现了统一的云资源调度管理系统，形成横跨不同IaaS 平台的混合云构架。PaaS 平台对内容生产系统和内容分发系统进行统一的虚机管理、实例管理、资源弹性管理、负载均衡、存储管理、文件管理、应用管理、消息队列以及智能工作引擎等，并根据应用系统的需求，实现不同环境条件下的SaaS 层各应用系统协调工作[1]。

1.3 交互化云平台运维实例

三层架构的云平台系统在河南广播电视台是首次使用。与传统IT 架构不同，大量的分布式、云计算、虚拟化等技术的应用使得整个架构更为复杂。因此，对云平台的运维是一个经验积累的过程。运维人员在运维过程中不可避免地遇到了许多问题。通过对问题的分析解决和经验总结，运维人员在完善整个系统运维工作的同时，也对云平台运维工作有了新的认识和理解。下面通过列举几个实际运维中的实例来总结云平台运维工作的经验。

1.3.1 云平台结构复杂度高导致运维负担加重

云平台复杂的结构导致复杂的流程，内容的生产与分发经过的节点较之以往更多。对于没有相关运维经验的运维人员，对系统架构和整体业务流程的理解和掌握就更为困难。当业务出现问题，在没有系统的智能化运维监控软件辅助的情况下，运维人员很难精准定位问题，往往需要反复查看各个相关环节才能找到问题所在。

以台内新闻频道节目整备失败为例。在此案例中，故障现象是制作系统送播节目提交流程后，整备系统未收到，通过制作系统查看接口日志，发现整备系统有反馈入库报错。而实际的节目送播流程包括制作系统的内部制作流程、制作系统素材在PaaS 平台注册环节、制作系统与整备系统的元数据交互环节、整备系统对PaaS 平台的素材共享请求环节以及整备系统的入库和反馈制作环节。这么多环节中的任何一个环节出问题，都有可能导致节目在整备系统入库时报错。因此，问题的定位十分复杂，需要制作系统、整备系统及PaaS 平台三方一起逐个环节定位查找故障原因。虽然最终准确定位为整备接口服务器与整备数据库通信故障并成功解决了问题，但消耗了大量的时间和人力。因此需要在系统内部署智能化运维监控软件来解决此类问题。

1.3.2 PaaS 层故障

PaaS 层数据库等相关业务有可能成为系统单点故障点，PaaS层故障有可能导致整个系统的瘫痪。交互化云平台使用一个PaaS 平台对各个相关子系统进行统一管理，各个子系统的素材使用、业务流程等都需要经过PaaS 层。当PaaS 层的相关服务出现问题，就有可能影响到所有注册在其上的子系统的业务。

以2019 年上半年频繁出现的PaaS 层数据库故障为例。交互化云的PaaS 层主数据库为Mango数据库，为了保障数据安全，数据库设计为每节点3 切片的3 节点结构。在实际运行中，由于第一次使用Mango 数据库，技术人员缺乏运维经验，就出现了数次由于其中一个数据库节点的某一切片不同步而导致整个数据库停止对外服务，从而导致整个PaaS 层功能失效，最直观的表现就是所有系统都无法在PaaS 上注册素材，从而造成节目无法正常送播。

积累了一定的运维经验与系统优化后，这种情况会得到解决。但也反映出PaaS 层容易成为系统的单一故障点的隐患存在。PaaS 层一旦出现故障，就有可能导致整个系统的瘫痪。如果可以分别在内容生产系统和内容分发系统各自建立媒体专业PaaS 管理平台，则会有效地解决此类问题，但势必带来更高的成本。

1.3.3 统一的存储与素材管理带来的问题

PaaS 层对注册在其上的各子系统的素材进行统一管理，共用统一的存储，节省了素材迁移的时间，提高了生产效率。但与此同时，由于不同的业务需要对存储性能、容量、保存时间等要求都不同，因此统一管理会带来存储冲突，也会带来过多的无用存储占用。

以制作系统和分发系统为例。制作系统对存储的要求是高带宽和高IOPS（每秒进行读写操作的次数）来满足多个终端的实时读写，而素材的实时性使得其对存储容量没有过多要求；而以媒资为例的分发系统对存储的要求就是大容量，要能够永久保存大量的节目与素材，而对存储的实时带宽和IOPS 则没有太高要求。因此，让制作系统和分发系统共用同一存储，就会导致二者对存储性能要求的冲突。大量的媒资等分发素材的长时间保存，也会不断挤占制作空间。

同时，统一的素材管理使得存储管理策略变得更加复杂。一份素材文件往往被不同的子系统所共享引用，只有当所有人都解除共享之后该素材才会被彻底删除。实际运维过程中，有很多实际上已经无用的素材由于某个引用的用户没有解除绑定而无法删除，造成存储空间的白白占用。目前，交互化云系统的共享存储空间已经占用过半，由于无法准确地确定哪些素材是所有系统都不再用的，因此无法进行空间清理。

如果将内容生产系统和内容分发系统的存储分开管理，就可以有效地解决此类问题。

1.3.4 基于虚拟机技术的云平台在实际运维中显露的问题

虚拟化和云计算的应用确实给运维工作带来了便利。交互化云平台使用了基于Openstack 的服务器虚拟化技术以及Citrix 桌面虚拟化技术等，这些虚拟机的使用使得业务的部署更加灵活，对虚拟机的维护也更加方便[2]。

然而，即使虚拟机技术相对于传统物理机十分便利，但实际使用中，其自身也存在一些问题。虚拟机技术属于系统虚拟化，每个虚机都要配备完整的虚拟硬件资源和单独的操作系统，因此在系统级的虚拟机运行时，其对硬件资源的开销还是比较大的。在更轻量级的Docker 等容器技术逐渐成熟后，虚拟机技术的这种资源开销大的弊端就更加凸显。比如交互化云平台的虚拟化存储空间占满问题。系统建设时，为整个云平台的虚拟化专门配置了大容量的存储空间以供虚机使用，但随着系统的运行，所需的虚机增多，而每台虚机都要求配置相应的专属存储空间，导致整个虚拟化存储空间被占满，从而无法继续创建新的虚机，只得再采购新的存储硬件以增加空间。同样的问题还会影响到CPU、内存等计算资源，只不过在本系统中问题表现还不明显。

如果在系统里采用容器技术，可以节省系统资源开销。另外，也可以采用超融合架构，则增加节点方式的硬件资源扩展实现起来就会更加便捷。

2 云平台建设与运维建议

通过对交互化云平台的运维经验的总结，结合实际应用中遇到的问题以及解决办法，可以对云平台的建设以及后续的运维工作提供一些建议与帮助。

2.1 引进先进的云平台运维技术构建完整的运维体系

云平台的运维工作不能单靠人工完成，需要利用智能化的运维工具，构建自动化的云平台运维体系，需要利用云管、网管、日志分析等智能化管理工具，同时搭建业务全流程的监控平台，在出现问题时可以辅助运维人员快速定位问题并解决问题。此外，在诸多云平台运维的讨论中，DevOps 无疑是提及最多的概念。DevOps 将开发和运维两个领域合并起来，实现从设计到编码，然后从开发环境部署到生产环境上，由开发人员和运维人员共同参与的迭代过程。这不仅提高了现场交付的效率，也能让日常的运维工作变得简单[3]。

2.2 内容生产系统与内容分发系统的隔离

对于广播电视台内的节目生产来说，由于内容生产系统与内容分发系统在业务范围、存储要求以及安全等级上的不同，用统一的PaaS 层管理也是造成上文所述问题的一个原因。因此，在新建台内云平台时，可以将内容生产系统和内容分发系统分开建设。一种思路是将二者由IaaS 层硬件资源层面就完全隔离开，建立各自的云平台，形成台内两朵云；另一种思路是，在需要将硬件资源集中在一起的情况下，可以在PaaS 这一层面将二者分开管理，在统一的云管平台上为制作云和分发云分别建立各自的PaaS 层，使其业务功能职责划分更加清晰。同时，需要为两个云分别配置更有针对性、更适合各自业务的存储，将素材分开管理，也能更好地实现应用多分布。与之搭配系统中已经成熟使用的大数据摆渡技术，也会使素材传输更加高效、便捷[4]。

2.3 建立健全云平台的技术运维管理模式

在针对媒体云平台的运行维护中，不能仅仅依靠技术支撑，还需要形成一套行之有效的运维管理模式。借鉴通用IT 云平台的管理模式，可以按照媒体业务分开、分层管理，有助于管理更有针对性，划分更明确；各个管理者之间不是各行其是，而是一个相辅相成的整体。各层之间的管理在宏观上也是一个松耦合的整体，遇到问题时协同解决。

2.4 容器等新技术在媒体云中的应用

上文提到虚拟机技术在系统开销上的问题，并且引入了Docker 等容器技术。与虚拟机的系统级虚拟化不同，容器技术属于应用级虚拟化，容器化应用时使用的资源都是宿主机系统提供的，仅仅是在资源的使用上做了某种程度的隔离与限制。比起虚拟机，容器拥有更高的资源使用效率，实例规模更小、创建和迁移速度也更快。这意味着，相比于虚拟机，容器在相同的硬件设备当中可以部署数量更多的容器实例。将容器技术引用到媒体云中，不仅可以解决硬件资源开销问题，还可以使应用部署更加快速和便捷，使整个系统更有弹性[5]。

然而，容器技术虽好，但也不能立刻就在媒体云中广泛应用，还要看是否适合媒体云的业务类型。就目前来看，媒体云中确实有一些业务可以采用容器技术，比如转码能力、技审服务以及新媒体应用等模块。但对于目前媒体云的核心制作等业务特别是需要保障安全制播的业务，还不适合采用容器技术。由于容器是应用级别的虚拟化，各个应用进程之间的隔离程度不高，容器应用之间可能会相互影响，因此其安全性和稳定性方面还有待加强。

不过，以Docker 为代表的容器技术，甚至是应用Docker Overlay Network 和Kubernetes 等技术实现的容器云以及基于微服务架构和Docker 容器技术的PaaS 云平台等，都是业界云平台的发展方向，并且已经在其他领域广泛应用。技术人员可以先尝试将容器技术引入媒体云平台，取代一些系统内轻量级的应用。

3 结语

在交互化云平台的实际运维过程中遇到的问题，或多或少都因对新技术和新系统缺乏运维经验导致，相信经过一定时间的积累，这些问题会得到改善与解决。与此同时，新技术的发展与应用，势必会给现有的云平台运维工作带来模式上的改变和效率上的提高，也能很好地解决现有系统的一些问题。对于新的云平台技术以及运维技术，技术人员应该大胆地将其引入现有的云平台业务，通过对这些新技术的实际应用来进行更深入的了解，以便未来进行更深层次的应用。