劉 鑫

（河南廣播電視臺，河南 鄭州 450008）

0 引言

交互化生產管理云平臺是河南廣播電視臺順應當前融合媒體的發(fā)展趨勢，在原有制播云系統(tǒng)的基礎上，整合臺內技術資源打造建設的全媒體節(jié)目生產管理系統(tǒng)。目前該系統(tǒng)已經運行多年，臺內包括新聞（四部一頻道）、衛(wèi)星頻道、都市頻道、電視劇頻道、歡騰購物頻道、國學頻道以及輪播頻道在內的多個欄目逐步上線實現送播，相關節(jié)目的新媒融合生產和發(fā)布也已逐步展開。交互化云平臺采用完整三層云架構技術體系，在四年多的實際運行維護過程中，體現了云計算在彈性擴展、業(yè)務靈活部署等方面的優(yōu)勢，但同時也給運維工作帶來了新的挑戰(zhàn)。

1 交互化云平臺架構介紹

1.1 三層架構設計標準

按照國家廣播電視總局《廣播電視臺融合媒體建設技術白皮書》的要求，廣電媒體云平臺要按照基礎設施即服務（Infrastructure as a Service，Iaas）、平臺即服務（Platform as a Service，PaaS）、軟件即服務（Software as a Service，SAAS）三層云架構建設。其中，IaaS 層為基礎資源層，提供系統(tǒng)所需的所有硬件資源，包含計算資源、存儲資源、網絡資源以及安全資源等。PaaS 層為平臺層，通過云管平臺中間件調用IaaS 層的資源，同時為其上層應用提供媒體資源管理、用戶數據管理、內容生產能力、內容分發(fā)能力以及公共服務等平臺支撐服務，并提供統(tǒng)一的接口標準給其上層應用。SaaS 層通過統(tǒng)一的接口調用PaaS 層提供的支撐服務，并為用戶提供各種媒體融合生產所需的應用服務。

1.2 交互化混合云平臺架構

河南廣播電視臺交互化云平臺的建設遵循了三層媒體云的架構，并采用混合云構架，使用統(tǒng)一的PaaS 管理系統(tǒng)，利用云管中間件成功將分布于私有云（臺內業(yè)務生產云）和專屬云（租用大象融媒云部分資源）的設備資源統(tǒng)一管理，實現了統(tǒng)一的云資源調度管理系統(tǒng)，形成橫跨不同IaaS 平臺的混合云構架。PaaS 平臺對內容生產系統(tǒng)和內容分發(fā)系統(tǒng)進行統(tǒng)一的虛機管理、實例管理、資源彈性管理、負載均衡、存儲管理、文件管理、應用管理、消息隊列以及智能工作引擎等，并根據應用系統(tǒng)的需求，實現不同環(huán)境條件下的SaaS 層各應用系統(tǒng)協(xié)調工作[1]。

1.3 交互化云平臺運維實例

三層架構的云平臺系統(tǒng)在河南廣播電視臺是首次使用。與傳統(tǒng)IT 架構不同，大量的分布式、云計算、虛擬化等技術的應用使得整個架構更為復雜。因此，對云平臺的運維是一個經驗積累的過程。運維人員在運維過程中不可避免地遇到了許多問題。通過對問題的分析解決和經驗總結，運維人員在完善整個系統(tǒng)運維工作的同時，也對云平臺運維工作有了新的認識和理解。下面通過列舉幾個實際運維中的實例來總結云平臺運維工作的經驗。

1.3.1 云平臺結構復雜度高導致運維負擔加重

云平臺復雜的結構導致復雜的流程，內容的生產與分發(fā)經過的節(jié)點較之以往更多。對于沒有相關運維經驗的運維人員，對系統(tǒng)架構和整體業(yè)務流程的理解和掌握就更為困難。當業(yè)務出現問題，在沒有系統(tǒng)的智能化運維監(jiān)控軟件輔助的情況下，運維人員很難精準定位問題，往往需要反復查看各個相關環(huán)節(jié)才能找到問題所在。

以臺內新聞頻道節(jié)目整備失敗為例。在此案例中，故障現象是制作系統(tǒng)送播節(jié)目提交流程后，整備系統(tǒng)未收到，通過制作系統(tǒng)查看接口日志，發(fā)現整備系統(tǒng)有反饋入庫報錯。而實際的節(jié)目送播流程包括制作系統(tǒng)的內部制作流程、制作系統(tǒng)素材在PaaS 平臺注冊環(huán)節(jié)、制作系統(tǒng)與整備系統(tǒng)的元數據交互環(huán)節(jié)、整備系統(tǒng)對PaaS 平臺的素材共享請求環(huán)節(jié)以及整備系統(tǒng)的入庫和反饋制作環(huán)節(jié)。這么多環(huán)節(jié)中的任何一個環(huán)節(jié)出問題，都有可能導致節(jié)目在整備系統(tǒng)入庫時報錯。因此，問題的定位十分復雜，需要制作系統(tǒng)、整備系統(tǒng)及PaaS 平臺三方一起逐個環(huán)節(jié)定位查找故障原因。雖然最終準確定位為整備接口服務器與整備數據庫通信故障并成功解決了問題，但消耗了大量的時間和人力。因此需要在系統(tǒng)內部署智能化運維監(jiān)控軟件來解決此類問題。

1.3.2 PaaS 層故障

PaaS 層數據庫等相關業(yè)務有可能成為系統(tǒng)單點故障點，PaaS層故障有可能導致整個系統(tǒng)的癱瘓。交互化云平臺使用一個PaaS 平臺對各個相關子系統(tǒng)進行統(tǒng)一管理，各個子系統(tǒng)的素材使用、業(yè)務流程等都需要經過PaaS 層。當PaaS 層的相關服務出現問題，就有可能影響到所有注冊在其上的子系統(tǒng)的業(yè)務。

以2019 年上半年頻繁出現的PaaS 層數據庫故障為例。交互化云的PaaS 層主數據庫為Mango數據庫，為了保障數據安全，數據庫設計為每節(jié)點3 切片的3 節(jié)點結構。在實際運行中，由于第一次使用Mango 數據庫，技術人員缺乏運維經驗，就出現了數次由于其中一個數據庫節(jié)點的某一切片不同步而導致整個數據庫停止對外服務，從而導致整個PaaS 層功能失效，最直觀的表現就是所有系統(tǒng)都無法在PaaS 上注冊素材，從而造成節(jié)目無法正常送播。

積累了一定的運維經驗與系統(tǒng)優(yōu)化后，這種情況會得到解決。但也反映出PaaS 層容易成為系統(tǒng)的單一故障點的隱患存在。PaaS 層一旦出現故障，就有可能導致整個系統(tǒng)的癱瘓。如果可以分別在內容生產系統(tǒng)和內容分發(fā)系統(tǒng)各自建立媒體專業(yè)PaaS 管理平臺，則會有效地解決此類問題，但勢必帶來更高的成本。

1.3.3 統(tǒng)一的存儲與素材管理帶來的問題

PaaS 層對注冊在其上的各子系統(tǒng)的素材進行統(tǒng)一管理，共用統(tǒng)一的存儲，節(jié)省了素材遷移的時間，提高了生產效率。但與此同時，由于不同的業(yè)務需要對存儲性能、容量、保存時間等要求都不同，因此統(tǒng)一管理會帶來存儲沖突，也會帶來過多的無用存儲占用。

以制作系統(tǒng)和分發(fā)系統(tǒng)為例。制作系統(tǒng)對存儲的要求是高帶寬和高IOPS（每秒進行讀寫操作的次數）來滿足多個終端的實時讀寫，而素材的實時性使得其對存儲容量沒有過多要求；而以媒資為例的分發(fā)系統(tǒng)對存儲的要求就是大容量，要能夠永久保存大量的節(jié)目與素材，而對存儲的實時帶寬和IOPS 則沒有太高要求。因此，讓制作系統(tǒng)和分發(fā)系統(tǒng)共用同一存儲，就會導致二者對存儲性能要求的沖突。大量的媒資等分發(fā)素材的長時間保存，也會不斷擠占制作空間。

同時，統(tǒng)一的素材管理使得存儲管理策略變得更加復雜。一份素材文件往往被不同的子系統(tǒng)所共享引用，只有當所有人都解除共享之后該素材才會被徹底刪除。實際運維過程中，有很多實際上已經無用的素材由于某個引用的用戶沒有解除綁定而無法刪除，造成存儲空間的白白占用。目前，交互化云系統(tǒng)的共享存儲空間已經占用過半，由于無法準確地確定哪些素材是所有系統(tǒng)都不再用的，因此無法進行空間清理。

如果將內容生產系統(tǒng)和內容分發(fā)系統(tǒng)的存儲分開管理，就可以有效地解決此類問題。

1.3.4 基于虛擬機技術的云平臺在實際運維中顯露的問題

虛擬化和云計算的應用確實給運維工作帶來了便利。交互化云平臺使用了基于Openstack 的服務器虛擬化技術以及Citrix 桌面虛擬化技術等，這些虛擬機的使用使得業(yè)務的部署更加靈活，對虛擬機的維護也更加方便[2]。

然而，即使虛擬機技術相對于傳統(tǒng)物理機十分便利，但實際使用中，其自身也存在一些問題。虛擬機技術屬于系統(tǒng)虛擬化，每個虛機都要配備完整的虛擬硬件資源和單獨的操作系統(tǒng)，因此在系統(tǒng)級的虛擬機運行時，其對硬件資源的開銷還是比較大的。在更輕量級的Docker 等容器技術逐漸成熟后，虛擬機技術的這種資源開銷大的弊端就更加凸顯。比如交互化云平臺的虛擬化存儲空間占滿問題。系統(tǒng)建設時，為整個云平臺的虛擬化專門配置了大容量的存儲空間以供虛機使用，但隨著系統(tǒng)的運行，所需的虛機增多，而每臺虛機都要求配置相應的專屬存儲空間，導致整個虛擬化存儲空間被占滿，從而無法繼續(xù)創(chuàng)建新的虛機，只得再采購新的存儲硬件以增加空間。同樣的問題還會影響到CPU、內存等計算資源，只不過在本系統(tǒng)中問題表現還不明顯。

如果在系統(tǒng)里采用容器技術，可以節(jié)省系統(tǒng)資源開銷。另外，也可以采用超融合架構，則增加節(jié)點方式的硬件資源擴展實現起來就會更加便捷。

2 云平臺建設與運維建議

通過對交互化云平臺的運維經驗的總結，結合實際應用中遇到的問題以及解決辦法，可以對云平臺的建設以及后續(xù)的運維工作提供一些建議與幫助。

2.1 引進先進的云平臺運維技術構建完整的運維體系

云平臺的運維工作不能單靠人工完成，需要利用智能化的運維工具，構建自動化的云平臺運維體系，需要利用云管、網管、日志分析等智能化管理工具，同時搭建業(yè)務全流程的監(jiān)控平臺，在出現問題時可以輔助運維人員快速定位問題并解決問題。此外，在諸多云平臺運維的討論中，DevOps 無疑是提及最多的概念。DevOps 將開發(fā)和運維兩個領域合并起來，實現從設計到編碼，然后從開發(fā)環(huán)境部署到生產環(huán)境上，由開發(fā)人員和運維人員共同參與的迭代過程。這不僅提高了現場交付的效率，也能讓日常的運維工作變得簡單[3]。

2.2 內容生產系統(tǒng)與內容分發(fā)系統(tǒng)的隔離

對于廣播電視臺內的節(jié)目生產來說，由于內容生產系統(tǒng)與內容分發(fā)系統(tǒng)在業(yè)務范圍、存儲要求以及安全等級上的不同，用統(tǒng)一的PaaS 層管理也是造成上文所述問題的一個原因。因此，在新建臺內云平臺時，可以將內容生產系統(tǒng)和內容分發(fā)系統(tǒng)分開建設。一種思路是將二者由IaaS 層硬件資源層面就完全隔離開，建立各自的云平臺，形成臺內兩朵云；另一種思路是，在需要將硬件資源集中在一起的情況下，可以在PaaS 這一層面將二者分開管理，在統(tǒng)一的云管平臺上為制作云和分發(fā)云分別建立各自的PaaS 層，使其業(yè)務功能職責劃分更加清晰。同時，需要為兩個云分別配置更有針對性、更適合各自業(yè)務的存儲，將素材分開管理，也能更好地實現應用多分布。與之搭配系統(tǒng)中已經成熟使用的大數據擺渡技術，也會使素材傳輸更加高效、便捷[4]。

2.3 建立健全云平臺的技術運維管理模式

在針對媒體云平臺的運行維護中，不能僅僅依靠技術支撐，還需要形成一套行之有效的運維管理模式。借鑒通用IT 云平臺的管理模式，可以按照媒體業(yè)務分開、分層管理，有助于管理更有針對性，劃分更明確；各個管理者之間不是各行其是，而是一個相輔相成的整體。各層之間的管理在宏觀上也是一個松耦合的整體，遇到問題時協(xié)同解決。

2.4 容器等新技術在媒體云中的應用

上文提到虛擬機技術在系統(tǒng)開銷上的問題，并且引入了Docker 等容器技術。與虛擬機的系統(tǒng)級虛擬化不同，容器技術屬于應用級虛擬化，容器化應用時使用的資源都是宿主機系統(tǒng)提供的，僅僅是在資源的使用上做了某種程度的隔離與限制。比起虛擬機，容器擁有更高的資源使用效率，實例規(guī)模更小、創(chuàng)建和遷移速度也更快。這意味著，相比于虛擬機，容器在相同的硬件設備當中可以部署數量更多的容器實例。將容器技術引用到媒體云中，不僅可以解決硬件資源開銷問題，還可以使應用部署更加快速和便捷，使整個系統(tǒng)更有彈性[5]。

然而，容器技術雖好，但也不能立刻就在媒體云中廣泛應用，還要看是否適合媒體云的業(yè)務類型。就目前來看，媒體云中確實有一些業(yè)務可以采用容器技術，比如轉碼能力、技審服務以及新媒體應用等模塊。但對于目前媒體云的核心制作等業(yè)務特別是需要保障安全制播的業(yè)務，還不適合采用容器技術。由于容器是應用級別的虛擬化，各個應用進程之間的隔離程度不高，容器應用之間可能會相互影響，因此其安全性和穩(wěn)定性方面還有待加強。

不過，以Docker 為代表的容器技術，甚至是應用Docker Overlay Network 和Kubernetes 等技術實現的容器云以及基于微服務架構和Docker 容器技術的PaaS 云平臺等，都是業(yè)界云平臺的發(fā)展方向，并且已經在其他領域廣泛應用。技術人員可以先嘗試將容器技術引入媒體云平臺，取代一些系統(tǒng)內輕量級的應用。

3 結語

在交互化云平臺的實際運維過程中遇到的問題，或多或少都因對新技術和新系統(tǒng)缺乏運維經驗導致，相信經過一定時間的積累，這些問題會得到改善與解決。與此同時，新技術的發(fā)展與應用，勢必會給現有的云平臺運維工作帶來模式上的改變和效率上的提高，也能很好地解決現有系統(tǒng)的一些問題。對于新的云平臺技術以及運維技術，技術人員應該大膽地將其引入現有的云平臺業(yè)務，通過對這些新技術的實際應用來進行更深入的了解，以便未來進行更深層次的應用。