+ 李 偉 浙江省桐鄉(xiāng)市廣播電視臺

CDN常見故障的探討分析

+ 李 偉 浙江省桐鄉(xiāng)市廣播電視臺

結(jié)合CDN的運(yùn)營實踐，根據(jù)其建設(shè)過程中出現(xiàn)各種各樣異?，F(xiàn)象，以使用和管理為切入點，分析各類故障產(chǎn)生的原因，提出CDN日常維護(hù)中需要注意的幾個方面的要素和處理網(wǎng)絡(luò)上傳代理異常的一些建議和經(jīng)驗，使得CDN技術(shù)質(zhì)量可靠、性能穩(wěn)定地運(yùn)行，從而減輕網(wǎng)絡(luò)服務(wù)器的壓力，提升了網(wǎng)站的性能和可擴(kuò)展性。

CDN；上傳代理；中心端；邊緣程序視

引言

當(dāng)Akamai, Digital Island相繼建點，中國的CDN產(chǎn)業(yè)開始起步發(fā)展，國內(nèi)一些IDC,ISP開始代理銷售國外CDN服務(wù)商后，CDN的服務(wù)認(rèn)同度日漸提高[1]。在流媒體、數(shù)字交互電視、圖書館局域網(wǎng)、金融網(wǎng)絡(luò)、衛(wèi)星網(wǎng)絡(luò)和移動網(wǎng)絡(luò)等等建設(shè)中有著應(yīng)用的構(gòu)想和初步的實踐，數(shù)字電視信息資源的流媒體化使得CDN技術(shù)在遠(yuǎn)程廣電建設(shè)中有應(yīng)用之處，在搭建信息資源平臺時我們可以考慮應(yīng)用CDN方案來解決用戶訪問延時等問題，既減少維護(hù)成本和初期投入，又可增強(qiáng)網(wǎng)絡(luò)的擴(kuò)展性和設(shè)備利用率以及靈活性。

1 CDN技術(shù)介紹

CDN的全稱是Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)。其目的是通過在現(xiàn)有的Internet中增加一層新的網(wǎng)絡(luò)架構(gòu)，將網(wǎng)站的內(nèi)容發(fā)布到最接近用戶的網(wǎng)絡(luò)"邊緣"，使用戶可以就近取得所需的內(nèi)容，解決Internet網(wǎng)絡(luò)擁塞狀況，提高用戶訪問網(wǎng)站的響應(yīng)速度[2]。從技術(shù)上全面解決由于網(wǎng)絡(luò)帶寬小、用戶訪問量大、網(wǎng)點分布不均等原因，解決用戶訪問網(wǎng)站的響應(yīng)速度慢的根本原因。

2 問題原因分析及其解決方案

2.1 程序啟動失敗

原因分析：

1) 已經(jīng)有一個進(jìn)程在運(yùn)行；2) 交換文件引起配置文件不對或者加入不合法的數(shù)據(jù)引起數(shù)據(jù)庫配置有誤，如數(shù)據(jù)庫地址、端口或用戶名；3) 密碼配置錯誤需要連接數(shù)據(jù)庫的才會有此原因）；4) 目前需要連接數(shù)據(jù)庫的有cdn中心端和V300R002b03及以后版本的上傳代理；5) 數(shù)據(jù)庫連接不上網(wǎng)絡(luò)不通或者數(shù)據(jù)庫服務(wù)沒有啟動）；6) selinux服務(wù)開啟導(dǎo)致。

對應(yīng)的處理方法：

1）在運(yùn)行程序之前，務(wù)必用ps –ef|grep 執(zhí)行文件名稱如ps –ef|grep coshipcdnc）檢查是否已有運(yùn)行的進(jìn)程。如果想重新啟動程序，則先kill掉正在運(yùn)行的進(jìn)程，再啟動程序；否則不用再啟動程序。在此，特意提醒，更換程序之前也要先查看程序是否正在運(yùn)行，如果程序正在運(yùn)行，必須先kill掉正在運(yùn)行的程序才能更新版本；2）刪除已有的sharework. swp文件；3）檢查該程序的配置文件是否和發(fā)布包的配置文件模板格式和加載的組件一致，配置的數(shù)據(jù)是否有異?；蛘咛厥庵?，確保配置文件正確且配置數(shù)據(jù)正常后再啟動程序；4）檢查配置文件中的mysql_fhost和mysql_port、mysql_user、mysql_pass是否正確，確保

這些項配置的值是正確的； 5）在運(yùn)行程序的機(jī)器上ping數(shù)據(jù)庫服務(wù)器，確保運(yùn)行該程序的服務(wù)器與數(shù)據(jù)庫服務(wù)器之間網(wǎng)絡(luò)是通的；在數(shù)據(jù)庫服務(wù)器上，用ps –ef|grep mysql命令檢查數(shù)據(jù)庫服務(wù)是否啟動； 6）在/etc/sysconfig/selinux文件中增加一行，“SELINUX=disabled”，然后重啟服務(wù)器。

2.2 程序啟動后無法正常工作，前臺啟動報mysql錯誤

原因分析：

1）表結(jié)構(gòu)、數(shù)據(jù)庫腳本和程序版本不同；2）數(shù)據(jù)庫的表被其他程序死鎖；

3）mysql本身的bug；4）前臺報的錯誤為[MYSQL] Unsettled error: Got error 124 from storage engine[code:1030]。

對應(yīng)的處理方法：

1）導(dǎo)出表結(jié)構(gòu)，與所取版本對應(yīng)的表結(jié)構(gòu)比較，如果不同就是版本不匹配。數(shù)據(jù)庫腳本和程序需要通過文件名、版本號判斷。版本發(fā)布說明或測試申請表里有相關(guān)信息。在執(zhí)行文件所在目錄下執(zhí)行./執(zhí)行文件名 -v可查看程序版本號如./coshipcdnc –v）；2）在數(shù)據(jù)庫中執(zhí)行show PROCESSLIST; 結(jié)果集中的state就是使用了這個數(shù)據(jù)庫的各連接的狀態(tài)，可以通過狀態(tài)看是否死鎖，找到造成數(shù)據(jù)庫死鎖的程序，關(guān)閉該連接；3）先檢查數(shù)據(jù)庫服務(wù)器的空間，如果空間足夠就重啟mysql服務(wù)，如果還有該錯誤就說明數(shù)據(jù)庫需要修復(fù)。修復(fù)步驟如下：

A．使用Mysql-front客戶端打開要修復(fù)的數(shù)據(jù)庫；

b．選擇頁面頂端的“其他”à“表格維護(hù)”，彈出表格維護(hù)頁面；

C．把表格維護(hù)頁面中的所有選項都打勾；

D．點擊表格維護(hù)頁面上的“完成”，幾分鐘后修復(fù)完成。

注意：只有類型為myisam的表才支持修復(fù)，其他類型的尚未發(fā)現(xiàn)報這種錯誤。

2.3 網(wǎng)絡(luò)連接正常，cdn中心端運(yùn)行正常。上傳代理，分發(fā)源或者邊緣程序啟動后用net list on命令看節(jié)點狀態(tài)不在線，或者在數(shù)據(jù)庫cdn_nodeinfo表看到節(jié)點的node_state為0

原因分析：

1）cdn中心端的腳本文件不全；2）數(shù)據(jù)庫中配置的node_ip與程序?qū)嶋H運(yùn)行機(jī)器的IP不一致，或者數(shù)據(jù)庫中配置的node_id和node_port與配置文件中配置的和監(jiān)聽端口不一致[3]。

對應(yīng)的處理方法：

1）查看cdn中心端應(yīng)用程序安裝目錄下是否有如下腳本文件：sql_ dc.txt, sql_nl.txt,sql_dm.txt, sql_descrip.xml。如果沒有將發(fā)布包中的這些文件拷貝至cdn中心端的安裝目錄下；2）查看數(shù)據(jù)庫中cdn_nodeinfo表中節(jié)點的配置（ip，port，node_id），以及配置文件中的配置（CLocal_ Pointer_Id，監(jiān)聽端口）是否一致。如果不一致，需要修改成一致。修改后必須重啟cdn中心端和節(jié)點本身。

注意：第三方的VS不會向cdn中心端注冊，所以在數(shù)據(jù)庫配置第三方VS的時候，需手動將其配置成1。

2.4 上傳代理解析xml失敗，會有類似的打印和日志：“xml文件格式不良好！ 已移至文件夾：???” 等

原因分析：

1) xml不符合ADI規(guī)范；2) xml中有無效的多字節(jié)序列，比如繁體字、UTF-8中未定義的符號等等?；蛘咴赩alue中出現(xiàn)" " 英文格式的引號，中文格式的引號是不會引起解析失敗的)，如；3) xml中缺少content項，或者content項的值格式不符合要求。

對應(yīng)的處理方法：

1)用xml編輯器打開該xml推薦用Altova XMLSpy），可以檢查xml是否符合標(biāo)準(zhǔn)的ADI格式；2）這種情況，去掉特殊字符或者英文的引號，如果實在要用引號請改成中文格式的引號；3）content項的值如果帶路徑，則只可支持本地路徑、\IPdir（如\172.30.20.23 s est.ts）、

ftp(如：ftp://user:passwd@IP:Por//mpeg/test.ts)和http(http://172.30.20.23/ts/test.ts)這四種格式的URL不帶路徑那就表明待上傳文件在上傳代理配置的uptask_dir目錄下即放在掃描xml的目錄下）。缺少content項則添加符合上傳代理要求的content項，如果不符合要求，則按照上述格式修改。

2.5 上傳代理報錯：文件格式不合法或者生成索引文件失敗

原因分析：

1） 編碼格式不對，非MPEG2或H264；2） 碼率小于1000bps，時長小于等于0；3） 碼率波動最大碼率與平均碼率的差值）超過了配置文件中的配置即max_fluctuate配置的值）；4）思遷上載時SI_VIDEO_PID不等于SI_PCR_PID。

對應(yīng)的處理方法：

1）用碼流分析工具如泰克分析工具）分析編碼格式，我們的系統(tǒng)只支持MPEG2

和H264這兩種編碼格式的ts流上傳；2）用碼流分析工具查看碼率大小和時長，上傳代理日志也有打印最大碼率和時長，查看是否是不滿足要求；3）用碼流分析工具查看最大碼率和平均碼率，看兩者差值是否超出了配置的范圍；4）用碼流分析工具查看SI_VIDEO_PID和SI_PCR_PID的值，思遷服務(wù)器要求這兩者的值必須相等。

2.6 上傳代理從中心端獲取任務(wù)失敗，會有類似打印和日志提示：如“向CDN中心請求任務(wù)不成功，包括：中心端保存xml失敗，中心端獲取不到數(shù)據(jù)庫連接，分發(fā)源不在線，沒有合適的VS等，等待重新啟動”，“從中心端獲取任務(wù)信息失敗，任務(wù)中止”

原因分析：

1）上傳代理配置文件中配置的cdn中心端節(jié)點,IP或端口錯誤；2）cdn中心端配置的數(shù)據(jù)庫地址、訪問密碼錯誤，或者數(shù)據(jù)庫服務(wù)被停掉，重啟導(dǎo)致連接不上數(shù)據(jù)庫；3）沒有在provider表配置xml中的provider_ ID；4）數(shù)據(jù)庫中配置的cdn中心端xml存儲路徑不對或者沒有配置，或者在數(shù)據(jù)庫中修改該路徑后未重啟cdn中心端的程序；5）分發(fā)源或者第三方VS不在線；6）分發(fā)源或者第三方VS的空間已達(dá)到限制；7）使用的上傳策略不正確；8）分發(fā)源或者第三方VS的realdir，ftpurl配置錯誤[4]。

對應(yīng)的處理方法：

1）檢查上傳代理的配置文件，保證下配置的cdn中心端的節(jié)點，IP和端口與數(shù)據(jù)庫中cdn_nodeinfo表配置的一致；2）檢查cdn中心端的配置文件，保證Db_modul下配置的數(shù)據(jù)庫地址和訪問密碼是正確的。如果不正確，修改后重啟程序。如果配置正確，則檢查數(shù)據(jù)庫服務(wù)是否開啟，如果沒開啟則啟動數(shù)據(jù)庫服務(wù)；3）檢查xml中的provider_ ID有沒有在provier表配置，如果沒有，則需要根據(jù)實際情況配置。沒有配置的provider_ID，上傳代理認(rèn)為是不合法的媒資提供商，不允許其提供的內(nèi)容被上傳；4）檢查數(shù)據(jù)庫中node_savedir表中有沒有配置cdn中心端保存xml的路徑，即node_savedir中是否有一條node_id是cdn_ nodeinfo表中cdn中心端的node_id，dir_type為-2，real_dir是cdn中心端服務(wù)器上真實存在的一個目錄的一條記錄，如果沒有請配置，然后重啟cdn中心端的程序。如果已存在但是中途有修改過路徑，則重啟cdn中心端程序；5）檢查分發(fā)源的進(jìn)程是否存在，不存在就重新啟動進(jìn)程；6） 檢查node_savedir中分發(fā)源或者第三方VS的空間是否都達(dá)到了上傳策略createtaskforuproxy）中對VS的空間要求；7）檢查使用的上傳策略，與在線的VS是否一致，比如使用的上傳策略是文件同時上傳至思科和coship的分發(fā)源，但是cdn_nodeinfo中根本沒有node_state為1的思科VS。所以在選擇上傳策略的時候要根據(jù)現(xiàn)場擁有的資源情況來選擇；8）檢查node-savedir表中是否配置了為空的real_dir，只有coship的分發(fā)源的ftpUrl項需要配置，不能配置為空或者不符合要求。

2.7 上傳代理提示：“該文件已經(jīng)上傳過,錯誤號: 2”

此種情況是由于之前已經(jīng)用該xml上傳過文件且上傳成功過，此次又重復(fù)上傳，這只是一個提示，不算錯誤。如果確定需要重傳，則需要從CMS系統(tǒng)發(fā)送刪除該文件的請求，等待48小時候再重傳該文件（因為MAP要求cdn在文件被刪除48小時后才能清除數(shù)據(jù)庫中的記錄）。

2.8 上傳代理報錯：上傳超時

原因分析：

1）文件過大，上傳的時間超過了上傳代理配置文件中配置的上傳超時時間；

2）第三方VS出現(xiàn)問題，主動上報的傳輸狀態(tài)或者上傳代理主動去查詢得到的傳輸狀態(tài)一直為非complete狀態(tài)[5]。

處理的方法：

1）配置上傳超時時間時要根據(jù)現(xiàn)場的網(wǎng)絡(luò)速度和最大片源的大小來配置，默認(rèn)的超時時間是3600s；2）檢查日志，就會看到在上傳超時時間內(nèi)，上傳代理打印的日志都是去查詢傳輸狀態(tài)或者VS主動上報的傳輸狀態(tài)，但是一直都是非complete，到了上傳超時時間，上傳代理主動取消了本次傳輸任務(wù)，認(rèn)為此次上傳失敗，清理掉了資源。需要第三方VS去查詢這么久不成功的原因是什么。

2.9 上傳文件時報錯：文件不能創(chuàng)建，pFile=NULL

原因分析：

1) 訪問分發(fā)源的ftp權(quán)限不夠；2）數(shù)據(jù)庫中ftpUrl配置的格式不對

處理方法：

1）在地址欄輸入ftp的地址訪問，看能否登陸ftp，如果可以登陸，拷貝一個文件到ftp，看能否成功，如果都可以，則將ftp的絕對路徑的權(quán)限改為755；

2）數(shù)據(jù)庫中node_savedir配置的ftpurl的格式為：ftp:// user:passwd@IP:port/ 后面不能有路徑。

2.10 配置了邊緣，但是文件不分發(fā)

原因分析：

1）cdn中心端配置文件中配置的cdn_task_num的值為0；2）cdn_ task_num的值不為0，但是在線的邊緣數(shù)小于cdn_task_num的值。

對應(yīng)的處理方法：

1）cdn_task_num的值表示要分發(fā)文件至幾個邊緣，如果想要文件一上傳就預(yù)分發(fā)至2個邊緣，那就將cdn_task_num的值配置為2；2）在某些腳本的runtask存儲過程做了限制，如果在線的邊緣數(shù)小于cdn_task_ num的值，就不產(chǎn)生分發(fā)任務(wù)，所以出現(xiàn)該問題的時候，需要檢查runtask存儲過程是不是有這樣的限制。如果有則必須保證至少啟動cdn_task_ num個邊緣節(jié)點。

2.11 邊緣節(jié)目表中content_state的值一直是1或者9

原因分析：

1）文件源可能是分發(fā)源，可能是同區(qū)域的邊緣）根本就不存在待分發(fā)的文件，可能是丟失，也可能是自動刪除了，但是數(shù)據(jù)庫的記錄未更新狀態(tài)成功，沒被刪除掉；2）也可能是當(dāng)初上傳成功寫數(shù)據(jù)庫file_dir_id寫錯了，文件其實在分發(fā)源的另一個目錄下。

對應(yīng)的處理方法：

1）可以去被分發(fā)的邊緣的安裝目錄下查看task_description.xml文件，

根據(jù)這三項的值，去對應(yīng)的服務(wù)器的對應(yīng)目錄下查看文件是否真的存在，如果文件確實不存在，則停掉邊緣程序，去邊緣的安裝目錄下刪除task_description.xml和sequence_file.xml，如果對應(yīng)的是分發(fā)源，將vod_edge_program表中記錄刪除掉，若是邊緣，則將vod_ edge_program中content_state的值更新為0。之后再重啟邊緣；2）去分發(fā)源所在服務(wù)器查找文件，若找到的目錄與數(shù)據(jù)庫中記錄的目錄不一致，則更新數(shù)據(jù)庫中記錄的目錄id，更新后停掉邊緣程序，去邊緣的安裝目錄下刪除task_description.xml和sequence_file.xml，將content_state的值更新為0，然后重啟邊緣。這樣的問題都是因為程序bug造成的，所以只能這樣手動改，一般情況下不會出現(xiàn)。

2.12 不去通知CMS（表示notify_pms表中沒有產(chǎn)生通知任務(wù)）

原因分析：

1）配置的是2，表示要等分發(fā)完成之后通知CMS，如果分發(fā)不成功，則不會去通知；2）vod_program中pms_list為空，或者pms_list中的平臺名稱未在provider表中配置；3）vod_program表中notice_flag的值為1。

對應(yīng)的處理方法：

1）檢查不分發(fā)的原因，讓文件能分發(fā)，如果不需要等待分發(fā)完再通知cms，則可以停掉cdn中心端程序，修改的值為1，然后重啟cdn中心端；2）pms_list的值的格式是“,平臺名稱,”，目前只支持CiTV和GCSS，如果沒在provider表配置provider和pms_list中出現(xiàn)的平臺名稱的對應(yīng)關(guān)系，則加上配置；3）如果notice_flag的值為1，則表明該文件在上傳的時候是不需要通知CMS同步內(nèi)容的，該文件對應(yīng)的provider_id在provider表對應(yīng)的need_notify_pms配置的應(yīng)該是0，如果想要此provider_id提供的文件上傳后通知CMS同步內(nèi)容，則在provider表將此provider_id對應(yīng)的need_notify_pms值改為1[6]。

2.13 通知CMS失敗

原因分析：

1）文件對應(yīng)的xml文件不存在；2）xml中有不符合CMS要求的字段。

對應(yīng)的處理方法：

1）去cdn中心端保存xml的路徑下去查看有沒有以content_id.xml命名的xml文件，如果不存在，則證明cdn中心端保存xml的路徑被修改了，去以前保存xml的目錄下將xml拷貝至新的目錄，因為cdn中心端保存的xml是不會被刪除的，除非被手動刪除，而且如果之前保存xml不成功，會報錯，后續(xù)步驟是進(jìn)行不了的；

2）根據(jù)notify_pms中的錯誤碼，將錯誤碼變成正數(shù)，然后減去2得到的值去CMS提供的《CMS內(nèi)容同步接口返回錯誤碼表.xls》中查看對應(yīng)的錯誤原因，然后去cdn中心端保存xml的目錄下找到對應(yīng)的xml，修改錯誤的地方，然后將notify_pms表中該文件通知失敗的記錄刪除掉，再去vod_program表中將notice_flag改為0。讓其重新通知。

2.14 Upwindow進(jìn)程不能打開

原因分析：

安裝Upwindow的機(jī)器上沒有VC6環(huán)境。

處理的方法：

去Upwindow的安裝目錄下雙擊vcredist_x86.exe即可。

3 小結(jié)

隨著我國巨大潛在市場的逐步開發(fā)，CDN將大大提高中國互聯(lián)網(wǎng)網(wǎng)絡(luò)的使用效率。內(nèi)容提供商使用CDN服務(wù)可以更加專注于提供精彩的內(nèi)容，而接入服務(wù)則通過CDN將可靠的內(nèi)容提供給用戶，從而加速CDN的內(nèi)容管理從靜態(tài)頁面向流媒體、動態(tài)頁面發(fā)展，最終走向全面應(yīng)用。我國的網(wǎng)絡(luò)建設(shè)也會因此而發(fā)展的更加完善，人們足不出戶便可享受到優(yōu)質(zhì)的網(wǎng)絡(luò)教育服務(wù)。

CDN是否質(zhì)量可靠、性能穩(wěn)定，對于我國的互聯(lián)網(wǎng)絡(luò)發(fā)展有著至關(guān)重要的作用。在日常維護(hù)中只有勤觀察、勤記錄、勤思考，才能不斷提高自己的故障處理能力，有效地提高業(yè)務(wù)辦理效率和提升用戶服務(wù)滿意度。

[1] 宋家友，桑紅濤.CDN技術(shù)的發(fā)展及應(yīng)用.中國有線電視,2005，（6）：75～77.

[2] 鄧永紅.內(nèi)容分發(fā)網(wǎng)絡(luò)技術(shù)綜述.有線電視技術(shù)，2005，（13）：15～20.

[3] 曹毅，賀衛(wèi)紅.CDN網(wǎng)絡(luò)關(guān)鍵技術(shù)研究.現(xiàn)代計算機(jī)，2004，（10）：39～42.

[4] 石磊,劉欲曉.提高網(wǎng)絡(luò)服務(wù)質(zhì)量的方法研究.平原大學(xué)學(xué)報,2005，（8）:118～120.

[5] 付鵬，周華春，陳旭東.CDN技術(shù)在IPTV系統(tǒng)中的應(yīng)用.中國有線電視,2004，（7）：47～50.

[6] 彭湘凱.CDN網(wǎng)絡(luò)及其應(yīng)用.微計算機(jī)信息，2005，（2）：150～151.