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

宣告：本文為CSDN原創投稿文章，未經許可，禁止任何形式的轉載。
作者：劉科，攜程系統研發雲平臺桌面虛擬架構師，多年從事分散式計算、通訊系統平臺設計、開發。本文為劉科在第六期[攜程技術微分享]中的分享內容。
責編：錢曙光，關注架構和演算法領域，尋求報導或者投稿請發郵件qianshg@csdn.net，另有「CSDN 高階架構師群」，內有諸多知名網際網路公司的大牛架構師，歡迎架構師加微信qshuguang2008申請入群，備註姓名+公司+職位。

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

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

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

一、為什麼要使用虛擬雲桌面

1、背景

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

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

2、雲桌面的優勢

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

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

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

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

3、攜程雲桌面現狀

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

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

二、如何實現虛擬雲桌面

1、雲桌面原架構

攜程雲桌面後臺雲平臺在實踐中進行了多次迭代，原有架構如上圖所示。該架構特點是，直接在OpenStack Nova進行定製開發，新增了分配虛擬的介面，實現瘦客戶端直接訪問OpenStack獲取虛擬機器資訊。

這個架構下，雲桌面平臺可以直接訪問全部的虛擬機器資訊，直接進行全部的虛擬機器操作，資料也集中存在OpenStack資料庫，部署方便。使用者許可權通過OpenStack Keystone直接管控，管理介面使用OpenStack Horizon並新增雲桌面管理頁面。

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

Nova根據瘦客戶端設定的坐席資訊，首先查詢這個坐席是否已分配虛擬機器。如有直接返回對應虛擬機器。如無，從後臺空閒虛擬機器中進行分配並更新資料庫分配，返回遠端桌面協議連線資訊。

2、原架構侷限性

隨著業務增長，原架構出現一些侷限性，首先，業務與OpenStack呈強繫結關係，導致OpenStack升級涉及業務重寫；修改業務邏輯需要對整個雲平臺做迴歸測試。

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

管理層面，因為Horizon的面向雲資源管理的，但業務主要面向運維的。這部分差異，導致我們開發新的Portal來彌補，管理人員需要通過兩套系統來進行運維。

整體方案上，雲桌面遠端桌面協議由第三方提供，如果第三方方案不支援OpenStack，就無法在攜程雲桌面系統使用。

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

3、新架構

經過架構調整，新架構實現了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分配一臺虛擬給，返回給使用者。

最後，對使用者部門來說，看到的是使用者屬於一個組，這個組對應特定的虛擬機器。只需調整使用者屬性，即可實現使用者分配特定的虛擬機器，充分滿足他們的各種需求。

三、大規模部署中遇到各種坎

1、軟體版本選取

在搭建OpenStack前，必須進行需求分析，確定所需的需求。然後根據需求選取滿足條件的OpenStack及相關元件的版本，以避免後期出現各種系統及虛擬機器問題。

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

2、資源超分

超分與應用場景強關聯。一定要首先確定需求，是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控制在可接受範圍。

3、網路細節

多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保活機制，設定一個合理的保活間隔解決問題。

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

1、運維工具

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

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

2、監控告警

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

同時，對OpenStack 的各種告警、ERROR的也新增了監控，確保雲平臺的穩定。 對虛擬機器網路、CPU等也進行了相應監控，確保虛擬機器對於使用者的高可用性。

3、自動化測試

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

同時，通過傳統的CI框架，我們搭建了程式碼的單元測試、整合測試環境，已經大量的線上測試用例，不僅有力的保障了軟體質量，還能定期對線上系統進行體檢，第一時間發現系統異常。

---

2016年9月22日-23日，SDCC 2016大資料技術&架構實戰峰會將在杭州舉行，兩場峰會大牛講師來自阿里、京東、蘇寧、唯品會、美團點評、遊族、餓了麼、有贊、Echo等知名網際網路公司，共同探討海量資料下的應用監控系統建設、異常檢測的演算法和實現、大資料基礎架構實踐、敏捷型資料平臺的構建及應用、音訊分析的機器學習演算法應用，以及高可用/高併發/高效能系統架構設計、電商架構、分散式架構等話題與技術。
9月4日24點前仍處於最低六折優惠票價階段，單場峰會（含餐）門票只需499元，5人以上團購或者購買兩場峰會通票更有特惠，限時折扣，預購從速。（票務詳情連結）。