摘要：一為什么要使用虛擬云桌面背景攜程呼叫中心，即服務(wù)聯(lián)絡(luò)中心，是攜程的核心部門之一，現(xiàn)有幾萬員工。他們?nèi)晷r為全球攜程用戶提供服務(wù)。為此，攜程正式引入了虛擬云桌面。攜程云桌面現(xiàn)狀攜程云桌面現(xiàn)已部署上海南通如皋合肥信陽穆棱六個呼叫中心。

編者：本文為劉科在第六期【攜程技術(shù)微分享】中的分享內(nèi)容。在攜程技術(shù)中心(微信號ctriptech）微信后臺回復(fù)【云桌面】，可加入微信交流群，和關(guān)注云桌面的小伙伴一起玩耍~

劉科，攜程系統(tǒng)研發(fā)云平臺桌面虛擬架構(gòu)師，多年從事分布式計算、通信系統(tǒng)平臺設(shè)計、開發(fā)。

【攜程技術(shù)微分享】是攜程技術(shù)中心推出的線上公開分享課程，每月1-2期，采用目前最火熱的直播形式，邀請攜程技術(shù)人，面向廣大程序猿和技術(shù)愛好者，一起探討最新的技術(shù)熱點，分享一線實戰(zhàn)經(jīng)驗。

本期視頻回放點擊這里。

OpenStack是當前最主流、最熱門的云平臺，攜程OpenStack環(huán)境除了應(yīng)用在攜程網(wǎng)站，還廣泛應(yīng)用于攜程呼叫中心的桌面云系統(tǒng)。作為業(yè)界最領(lǐng)先的呼叫中心之一，攜程服務(wù)聯(lián)絡(luò)中心幾萬員工365x24小時提供全球化服務(wù)，讓說走就走的親們毫無后顧之憂。

桌面云極大地提升了IT運維效率，顯著降低了用戶故障率，是未來IT的一大發(fā)展趨勢。那么攜程是如何把這兩者高效結(jié)合部署于攜程呼叫中心的呢？

本文將主要分享攜程呼叫中心廣泛使用的桌面云系統(tǒng)，介紹這套基于OpenStack的云桌面系統(tǒng)架構(gòu)以及在開發(fā)過程中碰到的一些OpenStack相關(guān)問題，并分享云桌面系統(tǒng)運維、監(jiān)控、自動化測試等。

1、背景

攜程呼叫中心，即服務(wù)聯(lián)絡(luò)中心，是攜程的核心部門之一，現(xiàn)有幾萬員工。他們?nèi)?x24小時為全球攜程用戶提供服務(wù)。以前呼叫中心桌面使用臺式PC，隨著業(yè)務(wù)規(guī)模的擴大，PC維護量倍增，需要投入大量人力、物力、財力來報障系統(tǒng)穩(wěn)定運行。為此，攜程正式引入了虛擬云桌面。

虛擬云桌面是什么呢？如圖所示，用戶桌面PC機換成了一個云桌面瘦客戶端（ThinClient，TC）。所有的CPU、內(nèi)存、硬盤都在云端。云端跑滿虛擬機，用戶桌面通過瘦客戶端連入虛擬機使用Windows。其中，虛擬機采用QEMU加KVM實現(xiàn)，云環(huán)境是用OpenStack進行管理，遠程桌面協(xié)議是第三方高度定制、修改過的spice協(xié)議。

2、云桌面的優(yōu)勢

第一，運維成本。PC部署以及系統(tǒng)軟件安裝耗時較長，云桌面后臺5分鐘一臺自動交付可供用戶使用的虛擬機；PC擴大部署投入巨大，云桌面只需要購買少量服務(wù)器接入云系統(tǒng)，快速擴大部署。

第二，故障處理效率。PC有問題，有可能需技術(shù)人員到用戶現(xiàn)場開箱檢查，故障排查耗時較長，嚴重點的硬件問題如需更換配件，等待周期更長。云桌面故障標準是5分鐘處理完畢。對于5分鐘無法解決的問題，只需后臺更換虛擬機解決。

第三，運維管理。PC分散在用戶桌面，運維需要用戶配合（比如保持開機）。云桌面提供了運維系統(tǒng)，只需設(shè)定好時間、安裝任務(wù)參數(shù)，系統(tǒng)會全自動進行安裝維護。同時，瘦客戶端輕量，無任何用戶數(shù)據(jù)，對用戶也帶來極大便利。典型的如用戶位置遷移，云桌面無需搬移，只需用戶到新位置登錄即可。

最后，云桌面整體低碳、環(huán)保。瘦客戶端功率跟普通節(jié)能燈相近，比PC低一個數(shù)量級。

3、攜程云桌面現(xiàn)狀

攜程云桌面現(xiàn)已部署上海、南通、如皋、合肥、信陽、穆棱六個呼叫中心。幾百臺計算節(jié)點、近萬坐席，而且規(guī)模還在不斷擴大中，新的呼叫中心也在計劃中。

同時，云桌面平臺故障率、瘦客戶端故障率也遠低于PC故障率。下圖是攜程運維部門的故障率統(tǒng)計圖。

1、云桌面原架構(gòu)

攜程云桌面后臺云平臺在實踐中進行了多次迭代，原有架構(gòu)如上圖所示。該架構(gòu)特點是，直接在OpenStack Nova進行定制開發(fā)，添加了分配虛擬的接口，實現(xiàn)瘦客戶端直接訪問OpenStack獲取虛擬機信息。

這個架構(gòu)下，云桌面平臺可以直接訪問全部的虛擬機信息，直接進行全部的虛擬機操作，數(shù)據(jù)也集中存在OpenStack數(shù)據(jù)庫，部署方便。用戶權(quán)限通過OpenStack Keystone直接管控，管理界面使用OpenStack Horizon并添加云桌面管理頁面。

典型的分配虛擬機用例中，瘦客戶端通過OpenStack Keystone進行認證、獲取Token，然后訪問Nova請求虛擬機。如上圖所示，瘦客戶端會通過Keystone進行認證，Keystone確認用戶存在后向域LDAP進行密碼校驗，確認用戶合法后返回Token；瘦客戶端再通過Token向Nova申請?zhí)摂M機。

Nova根據(jù)瘦客戶端設(shè)置的坐席信息，首先查找這個坐席是否已分配虛擬機。如有直接返回對應(yīng)虛擬機。如無，從后臺空閑虛擬機中進行分配并更新數(shù)據(jù)庫分配，返回遠程桌面協(xié)議連接信息。

2、原架構(gòu)局限性

隨著業(yè)務(wù)增長，原架構(gòu)出現(xiàn)一些局限性，首先，業(yè)務(wù)與OpenStack呈強綁定關(guān)系，導(dǎo)致OpenStack升級涉及業(yè)務(wù)重寫；修改業(yè)務(wù)邏輯需要對整個云平臺做回歸測試。

其次，用戶必須要是Keystone用戶，用戶管理必須使用Keystone模型。導(dǎo)致Keystone與LDAP之間要定期同步進行，有時還需手工同步特殊用戶。

管理層面，因為Horizon的面向云資源管理的，但業(yè)務(wù)主要面向運維的。這部分差異，導(dǎo)致我們開發(fā)新的Portal來彌補，管理人員需要通過兩套系統(tǒng)來進行運維。

整體方案上，云桌面遠程桌面協(xié)議由第三方提供，如果第三方方案不支持OpenStack，就無法在攜程云桌面系統(tǒng)使用。

最后，用戶部門有各種需求，直接在OpenStack內(nèi)進行開發(fā)難度大，上線時間長，開發(fā)人員很難實現(xiàn)技術(shù)引領(lǐng)業(yè)務(wù)發(fā)展。

3、新架構(gòu)

經(jīng)過架構(gòu)調(diào)整，新架構(gòu)實現(xiàn)了OpenStack與我們的業(yè)務(wù)解耦，同時適應(yīng)用戶部門的業(yè)務(wù)發(fā)展方向，方便功能快速迭代上線。

從圖中可以看出，云桌面業(yè)務(wù)邏輯從OpenStack中獨立出來，成為了VMPool，Allocator；管理層獨立開發(fā)一套面向IT運維的Portal系統(tǒng)，取代Horizon；云平臺可直接原生的OpenStack。

其中VMPool負責(zé)維護某種規(guī)格虛擬機的可用數(shù)量，避免需要的時候沒有虛擬機可用，讓用戶等待。Allocator滿足符合條件的用戶請求，返回用戶對應(yīng)的虛擬機或者從VMPool分配虛擬機分配用戶。

對于用戶分配虛擬機的典型用例，與原有架構(gòu)改動較大。首先，業(yè)務(wù)層瘦客戶端將直接訪問業(yè)務(wù)層的API。API層會直接通過LDAP進行用戶認證，并獲取用戶OU、組別等信息。

接著，業(yè)務(wù)層將進行用戶規(guī)則匹配。每個Allocator通過用戶組、OU、tag等進行規(guī)則匹配，以確定該用戶是否由自己進行服務(wù)。如不滿足Allocator所定義的規(guī)則，將按Allocator的優(yōu)先等級，繼續(xù)選取下一個Allocator進行匹配，直到匹配或者默認規(guī)則為止。

匹配后，如果是有綁定關(guān)系的分配規(guī)則，比如用戶綁定或者坐席綁定、TC綁定，那Allocator將直接從數(shù)據(jù)庫返回已有的綁定；如果無綁定關(guān)系，Allocator就會從對應(yīng)的VMPool分配一臺虛擬給，返回給用戶。

最后，對用戶部門來說，看到的是用戶屬于一個組，這個組對應(yīng)特定的虛擬機。只需調(diào)整用戶屬性，即可實現(xiàn)用戶分配特定的虛擬機，充分滿足他們的各種需求。

1、軟件版本選取

在搭建OpenStack前，必須進行需求分析，確定所需的需求。然后根據(jù)需求選取滿足條件的OpenStack及相關(guān)組件的版本，以避免后期出現(xiàn)各種系統(tǒng)及虛擬機問題。

我們根據(jù)攜程呼叫中心的業(yè)務(wù)需要，選好了幾個版本的KVM、QEMU，以及OpenVSwitch，在選取能適配它們的幾個可用kernel、Libvirt版本，并剔除了不穩(wěn)定版本或者有已知問題的版本，將這些組件組成合理的組合，進行7x24小時用戶模擬自動測試，找到最穩(wěn)定、合適的并滿足需求的，作生產(chǎn)上線使用。

2、資源超分

超分與應(yīng)用場景強關(guān)聯(lián)。一定要首先確定需求，是CPU密集、內(nèi)存密集、IO密集還是存儲密集。在做了充足的用戶調(diào)查后，我們準備了大量用戶模擬自動化腳本，進行自動化測試，以選取最合理超分值。

從我們的測試結(jié)果看，瓶頸主要是內(nèi)存。內(nèi)存超分過度會導(dǎo)致主機直接OOM（Out Of Memory）宕機。Windows及Windows應(yīng)用吃內(nèi)存比較嚴重，特別是像Chrome這些程序，優(yōu)先占用內(nèi)存先。雖然我們使用KSM（Kernel Samepage Merging，相同內(nèi)存頁合并功能），省了一些內(nèi)存，但最終上線也只能達到1:1.2的超分。

對于IO，在Windows啟動階段比較明顯。大量Windows同時啟動時會造成啟動風(fēng)暴情，在我們的極端條件測試中出現(xiàn)過啟動Windows需要40分鐘，硬盤IO 100%使用，每個讀寫請求平均0.2秒響應(yīng)。所以，在大規(guī)模部署時，對虛擬機并發(fā)開機數(shù)一定要有一定限制。同時，硬盤一定要多塊做RAID，以提供更高的IO吞吐量。

最后是CPU。 CPU過度超分會嚴重影響用戶體驗。但是一般不會造成宿主機宕機。在我們的測試條件下，超分到1:2用戶體驗開始下降，所以實際上線超分不多。

最終我們現(xiàn)在生產(chǎn)環(huán)境，是以內(nèi)存為標準進行超分，硬盤、CPU控制在可接受范圍。

3、網(wǎng)絡(luò)細節(jié)

多DNSMasq實例問題

我們虛擬機的IP地址通過DHCP獲取。DHCP服務(wù)端我們使用的DNSMasq比較老，只是簡單的實現(xiàn)了多實例運行，但并未真正實現(xiàn)綁定到虛擬接口。

在生產(chǎn)環(huán)境，我們觀察到VM都能獲取IP，但是在續(xù)租IP的時候大量失敗。經(jīng)抓包分析，虛擬機在第一次請求IP時，由于自身無IP地址，使用的是廣播方式進行DHCP請求；在續(xù)租時，由于本身有IP地址，也已明確DHCP服務(wù)端地址，所以采用IP點對點單播請求。

服務(wù)端，多個DNSMasq實例運行的情況下，如果是廣播包，所有DNSMasq都收到消息，所有廣播請求能正確回復(fù)。在單播情況下，只有最后啟動的DNSMasq能收到請求，最終導(dǎo)致虛擬機得不到正確的DHCP續(xù)租響應(yīng)。最終我們通過升級DNSMasq解決。

宿主機重啟導(dǎo)致虛擬機網(wǎng)絡(luò)不通

在物理機重啟后，有時會出現(xiàn)VM網(wǎng)絡(luò)不通。經(jīng)過調(diào)查，我們分析出根本原因是libvirt, ovs的啟動、關(guān)閉順序。

在正常情況下，libvrit退出時會刪除它管理的OpenVSwitch Port以及它創(chuàng)建的對應(yīng)的Tap虛擬網(wǎng)卡。libvirt啟動時會創(chuàng)建需要的Tap網(wǎng)卡，并請求OpenVSwitch 創(chuàng)建對應(yīng)的Port建立虛擬連接。

邏輯上，OpenVSwitch Port相當于交換機網(wǎng)口。Tap網(wǎng)卡，相當于PC的網(wǎng)卡。他們之間需要連線網(wǎng)絡(luò)才能正常通信。

如果關(guān)機時，OpenVSwitch比Libvirt先停止，Libvirt將不能成功刪除它管理的OpenVSwitch Port ；開機時，如果OpenVSwitch先啟動，它將建試圖重建之前存在的port。但因為Libvirt還未啟動， OpenVSwitch Port對應(yīng)的Tap網(wǎng)卡還未創(chuàng)建（即虛擬網(wǎng)口對應(yīng)的虛擬網(wǎng)卡不存在），OpenVSwitch重建Port最終失敗并且Port將被銷毀。

由于Port信息對OpenVSwitch來說是用戶配置信息，OpenVSwitch并不會從數(shù)據(jù)庫中清理掉對應(yīng)的Port記錄。所以等到Libvirt啟動調(diào)用OpenVSwitch創(chuàng)建Port時，OpenVSwitch發(fā)現(xiàn)數(shù)據(jù)庫里面已經(jīng)存在這些Port，所以并未真正觸發(fā)Port重建，最后造成VM網(wǎng)絡(luò)不通。

最終我們通過開、關(guān)機順序調(diào)整實現(xiàn)問題修復(fù)。

RabbitMQ長連接

RabbitMQ是OpenStack使用的一種消息交交互組件。OpenStack在某些時候，會出現(xiàn)無法創(chuàng)建虛擬機的情況。通過日志分析我們發(fā)現(xiàn)計算節(jié)點沒有收到對應(yīng)的創(chuàng)建請求消息。然后抓包分析進一步發(fā)現(xiàn)，TCP數(shù)據(jù)包被防火墻攔截、丟棄。原來防火墻對TCP會話有數(shù)量限制，會定期丟棄長久無數(shù)據(jù)交互的TCP會話。

在了解根本原因后，一方面通過定期自動冒煙測試保證網(wǎng)絡(luò)不空閑，一方面想解決方案。從應(yīng)用層面上，我們調(diào)研到RabbitMQ已經(jīng)有心跳機制，但要升級。由于升級影響范圍太廣，最終沒有進行。

接著我們對網(wǎng)絡(luò)層面進行了調(diào)查，發(fā)現(xiàn)TCP本身有Keepalive保活機制，同時RabbitMQ代碼本身也有TCP?；睿J不開啟。最后我們通過啟用RabbitMQ TCP?；顧C制，設(shè)置一個合理的?；铋g隔解決問題。

1、運維工具

運維是云桌面的一大難題，為此我們專門設(shè)計了運維系統(tǒng)，通過兩套SaltStack系統(tǒng)實現(xiàn)了對瘦客戶端與虛擬機的管理；通過Portal系統(tǒng)實現(xiàn)對整個系統(tǒng)的管理。

具體功能上，運維上，實現(xiàn)了對虛擬機、宿主機的可視化監(jiān)控、管理，并能對虛擬機實現(xiàn)遠程管理；對IT管理人員，實現(xiàn)了自動化的軟件安裝、文件下發(fā)、密碼修改、數(shù)據(jù)找回，、發(fā)送通知等功能；對資產(chǎn)管理員，實現(xiàn)了TC狀態(tài)監(jiān)控，TC異常情況及時發(fā)現(xiàn)。還有其它大量工作仍在開發(fā)進行中。

2、監(jiān)控告警

監(jiān)控方面，除了常規(guī)的服務(wù)器、操作系統(tǒng)層面的監(jiān)控，我們實現(xiàn)了大量業(yè)務(wù)層監(jiān)控。比如通過監(jiān)控已經(jīng)連接云桌面的瘦客戶端用戶輸入事件，實現(xiàn)實時活躍用戶監(jiān)控，使得我們能實時監(jiān)控系統(tǒng)負載、用戶數(shù)量。通過對比部門排班，第一時間發(fā)現(xiàn)用戶數(shù)異常。

同時，對OpenStack 的各種告警、ERROR的也添加了監(jiān)控，確保云平臺的穩(wěn)定。 對虛擬機網(wǎng)絡(luò)、CPU等也進行了相應(yīng)監(jiān)控，確保虛擬機對于用戶的高可用性。

3、自動化測試

通過在瘦客戶端實現(xiàn)用戶輸入輸出模擬，我們實現(xiàn)了全自動的測試環(huán)境。我們搭建了專門的云桌面測試實驗室，數(shù)十臺盒子進行7x24小時自動測試，全力驗證系統(tǒng)各項變更，支持業(yè)務(wù)各種研究探索，保障系統(tǒng)穩(wěn)定性。

同時，通過傳統(tǒng)的CI框架，我們搭建了代碼的單元測試、集成測試環(huán)境，已經(jīng)大量的線上測試用例，不僅有力的保障了軟件質(zhì)量，還能定期對線上系統(tǒng)進行體檢，第一時間發(fā)現(xiàn)系統(tǒng)異常