媒體云平臺技術(shù)運(yùn)維問題研究

劉 鑫

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

0 引言

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

1 交互化云平臺架構(gòu)介紹

1.1 三層架構(gòu)設(shè)計標(biāo)準(zhǔn)

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

1.2 交互化混合云平臺架構(gòu)

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

1.3 交互化云平臺運(yùn)維實(shí)例

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

1.3.1 云平臺結(jié)構(gòu)復(fù)雜度高導(dǎo)致運(yùn)維負(fù)擔(dān)加重

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

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

1.3.2 PaaS 層故障

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

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

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

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

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

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

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

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

1.3.4 基于虛擬機(jī)技術(shù)的云平臺在實(shí)際運(yùn)維中顯露的問題

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

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

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

2 云平臺建設(shè)與運(yùn)維建議

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

2.1 引進(jìn)先進(jìn)的云平臺運(yùn)維技術(shù)構(gòu)建完整的運(yùn)維體系

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

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

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

2.3 建立健全云平臺的技術(shù)運(yùn)維管理模式

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

2.4 容器等新技術(shù)在媒體云中的應(yīng)用

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

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

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

3 結(jié)語

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