OpenStack虛擬雲桌面在攜程呼叫中心的應用

編者：本文爲劉科在第六期【攜程技術微分享】中的分享內容。在攜程技術中心(微信號ctriptech）微信後臺回覆【雲桌面】，可加入微信交流羣，和關注雲桌面的小夥伴一塊兒玩耍~

劉科，攜程系統研發雲平臺桌面虛擬架構師，多年從事分佈式計算、通訊系統平臺設計、開發。

【攜程技術微分享】是攜程技術中心推出的線上公開分享課程，每個月1-2期，採用目前最火熱的直播形式，邀請攜程技術人，面向廣大程序猿和技術愛好者，一塊兒探討最新的技術熱點，分享一線實戰經驗。

本期視頻回放點擊這裏。

OpenStack是當前最主流、最熱門的雲平臺，攜程OpenStack環境除了應用在攜程網站，還普遍應用於攜程呼叫中心的桌面雲系統。做爲業界最領先的呼叫中心之一，攜程服務聯絡中心幾萬員工365x24小時提供全球化服務，讓說走就走的親們毫無後顧之憂。

桌面雲極大地提高了IT運維效率，顯著下降了用戶故障率，是將來IT的一大發展趨勢。那麼攜程是如何把這二者高效結合部署於攜程呼叫中心的呢？

本文將主要分享攜程呼叫中心普遍使用的桌面雲系統，介紹這套基於OpenStack的雲桌面系統架構以及在開發過程當中碰到的一些OpenStack相關問題，並分享雲桌面系統運維、監控、自動化測試等。

1、爲何要使用虛擬雲桌面

一、背景

攜程呼叫中心，即服務聯絡中心，是攜程的核心部門之一，現有幾萬員工。他們整年7x24小時爲全球攜程用戶提供服務。之前呼叫中心桌面使用臺式PC，隨着業務規模的擴大，PC維護量倍增，須要投入大量人力、物力、財力來報障系統穩定運行。爲此，攜程正式引入了虛擬雲桌面。

虛擬雲桌面是什麼呢？如圖所示，用戶桌面PC機換成了一個雲桌面瘦客戶端（ThinClient，TC）。全部的CPU、內存、硬盤都在雲端。雲端跑滿虛擬機，用戶桌面經過瘦客戶端連入虛擬機使用Windows。其中，虛擬機採用QEMU加KVM實現，雲環境是用OpenStack進行管理，遠程桌面協議是第三方高度定製、修改過的spice協議。

二、雲桌面的優點

第一，運維成本。PC部署以及系統軟件安裝耗時較長，雲桌面後臺5分鐘一臺自動交付可供用戶使用的虛擬機；PC擴大部署投入巨大，雲桌面只須要購買少許服務器接入雲系統，快速擴大部署。

第二，故障處理效率。PC有問題，有可能需技術人員到用戶現場開箱檢查，故障排查耗時較長，嚴重點的硬件問題如需更換配件，等待週期更長。雲桌面故障標準是5分鐘處理完畢。對於5分鐘沒法解決的問題，只需後臺更換虛擬機解決。

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

最後，雲桌面總體低碳、環保。瘦客戶端功率跟普通節能燈相近，比PC低一個數量級。

三、攜程雲桌面現狀

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

同時，雲桌面平臺故障率、瘦客戶端故障率也遠低於PC故障率。下圖是攜程運維部門的故障率統計圖。

 

2、如何實現虛擬雲桌面

一、雲桌面原架構

 

攜程雲桌面後臺雲平臺在實踐中進行了屢次迭代，原有架構如上圖所示。該架構特色是，直接在OpenStack Nova進行定製開發，添加了分配虛擬的接口，實現瘦客戶端直接訪問OpenStack獲取虛擬機信息。

這個架構下，雲桌面平臺能夠直接訪問所有的虛擬機信息，直接進行所有的虛擬機操做，數據也集中存在OpenStack數據庫，部署方便。用戶權限經過OpenStack Keystone直接管控，管理界面使用OpenStack Horizon並添加雲桌面管理頁面。

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

Nova根據瘦客戶端設置的坐席信息，首先查找這個坐席是否已分配虛擬機。若有直接返回對應虛擬機。如無，從後臺空閒虛擬機中進行分配並更新數據庫分配，返回遠程桌面協議鏈接信息。

二、原架構侷限性

隨着業務增加，原架構出現一些侷限性，首先，業務與OpenStack呈強綁定關係，致使OpenStack升級涉及業務重寫；修改業務邏輯須要對整個雲平臺作迴歸測試。

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

管理層面，由於Horizon的面向雲資源管理的，但業務主要面向運維的。這部分差別，致使咱們開發新的Portal來彌補，管理人員須要經過兩套系統來進行運維。

總體方案上，雲桌面遠程桌面協議由第三方提供，若是第三方方案不支持OpenStack，就沒法在攜程雲桌面系統使用。

最後，用戶部門有各類需求，直接在OpenStack內進行開發難度大，上線時間長，開發人員很難實現技術引領業務發展。

三、新架構

通過架構調整，新架構實現了OpenStack與咱們的業務解耦，同時適應用戶部門的業務發展方向，方便功能快速迭代上線。

 從圖中能夠看出，雲桌面業務邏輯從OpenStack中獨立出來，成爲了VMPool，Allocator；管理層獨立開發一套面向IT運維的Portal系統，取代Horizon；雲平臺可直接原生的OpenStack。

其中VMPool負責維護某種規格虛擬機的可用數量，避免須要的時候沒有虛擬機可用，讓用戶等待。Allocator知足符合條件的用戶請求，返回用戶對應的虛擬機或者從VMPool分配虛擬機分配用戶。

 

對於用戶分配虛擬機的典型用例，與原有架構改動較大。首先，業務層瘦客戶端將直接訪問業務層的API。API層會直接經過LDAP進行用戶認證，並獲取用戶OU、組別等信息。

接着，業務層將進行用戶規則匹配。每一個Allocator經過用戶組、OU、tag等進行規則匹配，以肯定該用戶是否由本身進行服務。如不知足Allocator所定義的規則，將按Allocator的優先等級，繼續選取下一個Allocator進行匹配，直到匹配或者默認規則爲止。

匹配後，若是是有綁定關係的分配規則，好比用戶綁定或者坐席綁定、TC綁定，那Allocator將直接從數據庫返回已有的綁定；若是無綁定關係，Allocator就會從對應的VMPool分配一臺虛擬給，返回給用戶。

最後，對用戶部門來講，看到的是用戶屬於一個組，這個組對應特定的虛擬機。只需調整用戶屬性，便可實現用戶分配特定的虛擬機，充分知足他們的各類需求。

3、大規模部署中遇到各類坎

一、軟件版本選取

在搭建OpenStack前，必須進行需求分析，肯定所需的需求。而後根據需求選取知足條件的OpenStack及相關組件的版本，以免後期出現各類系統及虛擬機問題。

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

二、資源超分

超分與應用場景強關聯。必定要首先肯定需求，是CPU密集、內存密集、IO密集仍是存儲密集。在作了充足的用戶調查後，咱們準備了大量用戶模擬自動化腳本，進行自動化測試，以選取最合理超分值。

從咱們的測試結果看，瓶頸主要是內存。內存超分過分會致使主機直接OOM（Out Of Memory）宕機。Windows及Windows應用吃內存比較嚴重，特別是像Chrome這些程序，優先佔用內存先。雖然咱們使用KSM（Kernel Samepage Merging，相同內存頁合併功能），省了一些內存，但最終上線也只能達到1:1.2的超分。

對於IO，在Windows啓動階段比較明顯。大量Windows同時啓動時會形成啓動風暴情，在咱們的極端條件測試中出現過啓動Windows須要40分鐘，硬盤IO 100%使用，每一個讀寫請求平均0.2秒響應。因此，在大規模部署時，對虛擬機併發開機數必定要有必定限制。同時，硬盤必定要多塊作RAID，以提供更高的IO吞吐量。

最後是CPU。 CPU過分超分會嚴重影響用戶體驗。可是通常不會形成宿主機宕機。在咱們的測試條件下，超分到1:2用戶體驗開始降低，因此實際上線超分很少。

最終咱們如今生產環境，是之內存爲標準進行超分，硬盤、CPU控制在可接受範圍。

三、網絡細節

多DNSMasq實例問題

咱們虛擬機的IP地址經過DHCP獲取。DHCP服務端咱們使用的DNSMasq比較老，只是簡單的實現了多實例運行，但並未真正實現綁定到虛擬接口。

在生產環境，咱們觀察到VM都能獲取IP，可是在續租IP的時候大量失敗。經抓包分析，虛擬機在第一次請求IP時，因爲自身無IP地址，使用的是廣播方式進行DHCP請求；在續租時，因爲自己有IP地址，也已明確DHCP服務端地址，因此採用IP點對點單播請求。

服務端，多個DNSMasq實例運行的狀況下，若是是廣播包，全部DNSMasq都收到消息，全部廣播請求能正確回覆。在單播狀況下，只有最後啓動的DNSMasq能收到請求，最終致使虛擬機得不到正確的DHCP續租響應。最終咱們經過升級DNSMasq解決。

宿主機重啓致使虛擬機網絡不通

在物理機重啓後，有時會出現VM網絡不通。通過調查，咱們分析出根本緣由是libvirt, ovs的啓動、關閉順序。

在正常狀況下，libvrit退出時會刪除它管理的OpenVSwitch Port以及它建立的對應的Tap虛擬網卡。libvirt啓動時會建立須要的Tap網卡，並請求OpenVSwitch 建立對應的Port創建虛擬鏈接。

邏輯上，OpenVSwitch Port至關於交換機網口。Tap網卡，至關於PC的網卡。他們之間須要連線網絡才能正常通訊。

若是關機時，OpenVSwitch比Libvirt先中止，Libvirt將不能成功刪除它管理的OpenVSwitch Port ；開機時，若是OpenVSwitch先啓動，它將建試圖重建以前存在的port。但由於Libvirt還未啓動， OpenVSwitch Port對應的Tap網卡還未建立（即虛擬網口對應的虛擬網卡不存在），OpenVSwitch重建Port最終失敗而且Port將被銷燬。

因爲Port信息對OpenVSwitch來講是用戶配置信息，OpenVSwitch並不會從數據庫中清理掉對應的Port記錄。因此等到Libvirt啓動調用OpenVSwitch建立Port時，OpenVSwitch發現數據庫裏面已經存在這些Port，因此並未真正觸發Port重建，最後形成VM網絡不通。

最終咱們經過開、關機順序調整實現問題修復。

RabbitMQ長鏈接

RabbitMQ是OpenStack使用的一種消息交交互組件。OpenStack在某些時候，會出現沒法建立虛擬機的狀況。經過日誌分析咱們發現計算節點沒有收到對應的建立請求消息。而後抓包分析進一步發現，TCP數據包被防火牆攔截、丟棄。原來防火牆對TCP會話有數量限制，會按期丟棄長久無數據交互的TCP會話。

在瞭解根本緣由後，一方面經過按期自動冒煙測試保證網絡不空閒，一方面想解決方案。從應用層面上，咱們調研到RabbitMQ已經有心跳機制，但要升級。因爲升級影響範圍太廣，最終沒有進行。

接着咱們對網絡層面進行了調查，發現TCP自己有Keepalive保活機制，同時RabbitMQ代碼自己也有TCP保活，但默認不開啓。最後咱們經過啓用RabbitMQ TCP保活機制，設置一個合理的保活間隔解決問題。

4、系統穩定背後的黑科技

一、運維工具

運維是雲桌面的一大難題，爲此咱們專門設計了運維繫統，經過兩套SaltStack系統實現了對瘦客戶端與虛擬機的管理；經過Portal系統實現對整個系統的管理。

具體功能上，運維上，實現了對虛擬機、宿主機的可視化監控、管理，並能對虛擬機實現遠程管理；對IT管理人員，實現了自動化的軟件安裝、文件下發、密碼修改、數據找回，、發送通知等功能；對資產管理員，實現了TC狀態監控，TC異常狀況及時發現。還有其它大量工做仍在開發進行中。

二、監控告警

監控方面，除了常規的服務器、操做系統層面的監控，咱們實現了大量業務層監控。好比經過監控已經鏈接雲桌面的瘦客戶端用戶輸入事件，實現實時活躍用戶監控，使得咱們能實時監控系統負載、用戶數量。經過對比部門排班，第一時間發現用戶數異常。

同時，對OpenStack 的各類告警、ERROR的也添加了監控，確保雲平臺的穩定。 對虛擬機網絡、CPU等也進行了相應監控，確保虛擬機對於用戶的高可用性。

三、自動化測試

經過在瘦客戶端實現用戶輸入輸出模擬，咱們實現了全自動的測試環境。咱們搭建了專門的雲桌面測試實驗室，數十臺盒子進行7x24小時自動測試，全力驗證系統各項變動，支持業務各類研究探索，保障系統穩定性。

同時，經過傳統的CI框架，咱們搭建了代碼的單元測試、集成測試環境，已經大量的線上測試用例，不只有力的保障了軟件質量，還能按期對線上系統進行體檢，第一時間發現系統異常。