金山運維肖力：如何將業務遷移到虛擬化環境并穩定運行
原創
51CTO高招微課
肖力，金山西山居系統運維經理，前盛大游戲研究員，有15年工作經驗，10年游戲行業運維經驗，5年KVM虛擬化運維經驗，有40款游戲虛擬化項目成功實施經驗。維護有微信訂閱號：“KVM虛擬化實踐”著有《深度實踐KVM》一書。
以下是正文：
大家好，本次介紹我在長期的虛擬化項目實踐中的經驗，主要介紹如何將已有的業務遷移到虛擬化環境。
先簡單介紹下，我維護有一個訂閱號“KVM虛擬化實踐”可以一起交流，共同討論學習。
將已有的業務遷移到虛擬化環境。是很大的挑戰，不僅要求我們熟悉虛擬化技術，更要求我們熟悉業務，將業務遷移到虛擬化環境其實還是一個項目實施的過程，考驗我們的協調溝通及項目把控能力。
▼我分為四個部分介紹如何將業務遷移到虛擬化環境：
2、虛擬化技術選型及實戰：介紹KVM虛擬化技術在實踐方面的經驗。
3、虛擬化項目的監控、報警、應急響應、災備方法。
4、將業務遷移到公有云方法：介紹公有云選擇及業務遷移到公有云方法，將業務遷移到公有云也是業務虛擬化的一種形式，只是我們不用在關心虛擬化技術。
▼在我們決定做虛擬化的時候，虛擬化項目該如何起步？
當上級或者我們自己準備將業務遷移到虛擬化環境上的時候，會面臨許多問題，例如：
軟硬件如何選型；
技術方案如何確定；
萬一出了問題應該怎么辦；
在虛擬化的過程中如何保證業務穩定。
那么，我們首先應該解決那個問題呢？這時候我們應該靜下心來想一想，虛擬化到底能給我們企業帶來什么。
從我的虛擬化實踐來看，歸根結底虛擬化給企業帶來兩點好處：
快速部署。
（1）節省成本
大多數時候，我們選擇虛擬化就是為了節省成本，舉一個非常典型的案例，我們曾經虛擬化過一款游戲，這款游戲在虛擬化之前，使用五百多臺物理機，當時運行了兩年多，已經收支平衡，換句話說就是不盈利了，面臨著馬上被結項的命運。
這個時候，我們部署了虛擬化，將這款游戲按照一比七的比例，全部遷移到虛擬化環境。通過虛擬化技術，將五百多臺物理機壓縮到七十多臺宿主機上，極大的節省了游戲的成本，這款游戲又開始盈利了。
（2）快速部署
虛擬機在宿主機層面看就是一個鏡像文件，我們要得到另外一臺虛擬機，只需要將鏡像文件復制一份就可以了，通常是幾分鐘，最多十幾分鐘。
而一臺物理機，上架、插電源、拉網線、安裝操作系統，最快都要一個多小時，這是從小時到分鐘的數量級的差距。通過虛擬化可以大大提示部署效率。
想好了虛擬化能帶給我們什么之后，下一步就是說服老板和同事協助我們進行虛擬化，有了老板和同事支持，我們才能順利的推進虛擬化項目進行。
#p#
（1）說服老板的秘訣。
說服老板有兩個秘訣：“畫餅”和“挖坑”，往往老板比較好說服，因為虛擬化能給企業帶來真金白銀的好處。比如如果企業現在有2000臺服務器，即使按照一比二這樣一個比例實施虛擬化，立馬就可以節省50%服務器，50%的機柜。
所以，我們其實也不是在畫餅，這個餅真實存在，并且可以吃到的。但是畫餅的時候，要挖一個“坑”，因為在業務遷移虛擬化的時候，難免碰到這樣或者那樣的問題，碰到問題的時候，我們需要老板的支持，在做虛擬化遷移之前，我們就要和老板說好，虛擬化會給企業帶來巨大的利益，實施過程中我們會做好各種預案，充分做好測試，但是也難免會碰到問題，萬一碰到問題的時候需要老板支持我們，力挺我們。
（2）說服同事支持的秘訣。
往往說服同事支持很困難，因為大部分同事都是多一事不如少一事這樣的心態，如果業務在物理機上已經非常穩定了，大部分人肯定不愿意再折騰一次了。這時候說服同事的辦法就是樹立一個樣板，用事實說話，讓大家看到業務可以在虛擬化平臺上穩定運行。
如何選擇第一個虛擬化項目。
選擇第一個虛擬化項目非常重要，和打仗一樣，首戰必勝，這是一個戰略問題，如果第一個虛擬化項目失敗了，后面的工作就很難開展，萬事開頭難，那么如何選擇第一個虛擬化項目呢？適合虛擬化的業務有那些特征了呢？
（1）單進程
但進程的業務非常適合虛擬化，現在的CPU都是多核，單進程的業務只使用一個核，通過虛擬化就可以很好的將多個單進程的業務整合在一起，尤其是通過應用層很難進程優化的業務。
（2）利用率非常低
常年CPU利用率在20%以下，這種業務通過虛擬化也非常好整合，將幾個業務整合到一臺宿主機上，可以提高整體的利用率。
（3）頻繁變動的業務
這種業務搞虛擬化的動力最強，因為虛擬化快速部署的特點確實能解決他們的痛點。對運維來說，能節省成本他們不一定有動力，但是說能快速簡單實現，他們動力很足。
（4）非核心業務
一開始虛擬化的時候，最好不要選核心業務，否則出了問題，壓力會很大。核心業務應在口碑樹立起來之后，在逐步進行虛擬化。
第一個虛擬化項目應該從自己企業內部找一個最符合以上條件的業務，來進行虛擬化，以提高虛擬化的成功率。
另外，并不是所有的業務都適合虛擬化，那有哪些業務不適合虛擬化呢？
壓力特別高的業務不建議搞虛擬化，如果在物理機上CPU利用率已經80%了，就很難通過虛擬化進行壓縮。
虛擬化項目實施應該遵循哪些流程，能保證比較穩定的將業務遷移到虛擬化環境？
從我個人長期的實踐來看，虛擬化實施最好循序漸進，穩扎穩打，遵循以下的步驟，可以保證比較穩定的業務遷移到虛擬化環境。
（1）業務性能評估及壓力模型建立
項目啟動的時候，首先面臨的是虛擬化比例如何確定，到底是1虛5，還是1虛7比較合適，宿主機的配置如何確定，這些都需要依靠數據決定，所以我們首先需要收集現有業務的壓力數據，根據壓力數據分析業務的壓力模型。業務壓力模型建立方法，后面還有詳細介紹，有了壓力模型，虛擬化比例和宿主機選型就非常好確定。
（2）測試環境測試
虛擬化比例和宿主機確定好之后，然后應該進行測試，測試包括系統方面的測試和業務方面的測試，系統方面測試主要測試宿主機和虛擬機的壓力瓶頸點，看看宿主機和虛擬機最大的負載點在那里，為以后使用做到心里有底。
業務測試包括業務的功能測試和性能測試，功能測試主要測試業務在虛擬機上運行有沒有問題，性能測試主要測試業務在虛擬機上能夠承擔的最高負載，比如游戲行業能負載多少人數，web，數據庫能負載多少連接或者io，這個要根據每個業務的不同，使用業務應用層的測試方法進行測試。
通過測試，一方面我們可以測試穩定性，一方面可以得到業務在虛擬機上的最大負載，取得這些數據，我們就可以做到對以后的虛擬機使用心中有數。
（3）小規模部署
測試環境測試沒有問題，并且取得相關數據后，就可以在生產環境部署，先應該在生產環境小規模的進行部署，并且測試2周到一個月。小規模部署最好是業務壓力比較小的一臺虛擬機測試2周到一個月，沒有問題后在找業務壓力最大的一組進行虛擬化，在測試2周到一個月。
（4）全面部署
小規模部署沒有問題后，就可以逐步的進行全面虛擬化部署，按部就班的將業務遷移到虛擬化環境，直至進入最終的虛擬化運維。
▼下面介紹下業務壓力模型的構建方法。
下定決心做虛擬化之后，面臨的下一個問題是到底虛擬化比例如何確定，宿主機的配置如何選型，這時候就需要根據自己的業務特點，建立壓力模型，根據壓力模型確定虛擬化比例，宿主機、虛擬機的配置。
#p#
那么如何建立壓力模型呢？這個要用數據說話，數據來自于長期的監控指標及高峰時的數據收集。
一般我們會去看監控系統至少60天之內的數據，盡量做到每臺服務器的壓力數據都收集下，如果數量比較多，可以抽取壓力比較大的一部分機器提煉壓力模型。
另外，在業務高峰期的幾個小時，可以考慮使用腳本收集比較密集的數據，一般監控平臺收集的是1到5分鐘的數據，通過腳本可以收集5-30秒間隔的數據，提高我們數據收集的精度，腳本其實就是使用sar、iostat、vmstat等命令編寫。
所有的數據收集完成以后，就可以根據數據提煉出業務的壓力模型。
有了壓力模型，根據壓力模型就非常好確定虛擬化的比例和宿主機選型了。
▼下面再分享一些生產環境的虛擬化技術經驗。
虛擬化中CPU技術要點：
我最喜歡的是CPU技術是CPU綁定，CPU綁定是一個非常神奇的技術，最神奇的地方就是可以在線去做，在實戰中多次解決了性能問題。
CPUhost-passthrough技術。
CPU host-passthrough技術主要是將物理CPU的特性全部傳給虛擬CPU，根據應用的不同，對CPU的性能提升也不同。
另外還有一個好處，就是在虛擬機中可以看到和物理機一模一樣品牌型號的CPU，對于一些公有云來說，用戶體驗比較好。但是使用CPUhost-passthrough技術也要注意，這個技術不支持在不同型號CPU的宿主機之間在線遷移虛擬機。
虛擬化中內存技術要點：
KSM相同內存頁合并，或者叫內存壓縮技術，虛擬化的時候一般建議關掉。為什么呢?一 方面KSM不停在掃描內存，會消耗CPU資源。
另外一方面，分給虛擬機的內存，我們希望是分給多少，能利用多少，打開KSM就是為了內存超用，如果真的超用了，當壓力大的時候，就會出現內存不夠用的情況，這個使用就會嚴重影響大量的SWAP交互。
網絡方面主要解決兩個問題，可管理性和性能，可管理性主要依靠Open vSwitch這個純軟件的交換機，ovs可以和物理交換機進行協議層面的通訊。
性能有硬件和軟件的優化方案，硬件主要是使用萬兆萬卡和SRIOV，軟件是VIRTIO、網卡獨占等技術。
今天時間關系就不詳細介紹了，大家可以看下我的博客：http://xiaoli110.blog.51cto.com/1724/1558984
▼關于虛擬機時間漂移
所有的虛擬機，比如KVM，包括VMWare，XEN，HyperV，都有一個問題，就是因為虛擬機的時鐘是模擬出來的，一般虛擬機的走時要比物理機快一些。
當然，因為虛擬化的流行，這個問題在最新的操作系統上優化的越來越好。一般在生成環境，所有的虛擬機建議都配置精確時鐘和NTP，以保證走時準確。有些業務，對時間精度要求非常高，更要注意虛擬機時間的配置。
▼關于磁盤
一般虛擬機磁盤鏡像格式建議使用qcow2或者lvm，因為這兩種格式有個共同的特定，就是可以動態的擴容，快照，并且支持精簡模式，使用管理起來非常方便。
#p#
磁盤的驅動VirtIO是標配，VirtIO是一種半虛擬化的驅動，可以跳過用戶空間的虛擬化層，大大提高通訊效率。
磁盤緩存方式，常見的有四種：writeback，writethrough，none，unsafe。
實際上是在虛擬化層和宿主機的文件系統這一 層，開不開cache的各種組合，現在CentOS系列上默認是writeback模式，這種模式啟用了宿主機文件系統的緩存，性能會好很多。
我們在生產環境比較保守，一般在單機虛擬化的時候，使用writethrough方式，以數據安全為第一位，在集群虛擬化，就是需要虛擬機遷移的場景，使用none方式。因為虛擬機要遷移，必須使用none方式。
▼下面介紹下虛擬化的存儲方式：
單機虛擬化
單機虛擬化的形式是一臺宿主機虛擬幾臺虛擬機，虛擬機的計算、存儲、網絡都在這臺宿主機內，是一種非常靈活的虛擬化方式，他不對原有的環境做任何改變，一臺宿主機，放到機房，虛擬化就搞起來了。
虛擬化集群
這種虛擬化方式由商業存儲和若干計算節點組成，虛擬機鏡像在商業存儲上，虛擬機使用計算節點的計算、內存、網絡資源。因為有了共享存儲，就可以做虛擬機的在線遷移，配置虛擬機搞可用，配置計算資源的動態平衡。
關于商業存儲的選擇。
目前常見的存儲分為文件存儲和塊存儲，快存儲又分為ISCSI，FC。不管是那種存儲，一般建議生產環境都是雙控制器，一般支持雙控制的存儲，從軟件到硬件都是雙冗余的，沒有單點故障。
另外，NFS和ISCSI一直有爭論，這個看自己對那種技術更熟悉，更喜歡。
FC的存儲成本比較高，但是性能也最好，我個人喜歡ISCSI存儲，性價比高，性能基本也能滿足自己的要求。
總的來說，存儲的選擇需要考慮以下三點：
預算
自己對技術的熟悉程度
分布式文件系統：
這種方式其實是集群虛擬化的一個變種，就是用普通的pcserver替換商業存儲，這種方式的好處是可以規模做的非常大，并可以動態擴展，一般公有云都是這樣的架構。
#p#
三種存儲方式在虛擬化中的應用場景：
壓力比較高，虛擬機比例比較低的游戲；
一個機房虛擬機比較少的情況。
集群虛擬化
壓力中低等，虛擬化比例在1：7以上的游戲；
虛擬機數量多，強調快速部署，強調高可用的業務。
總體磁盤IO 1000iops以下；
和商業集群存儲組合使用。
另外，SSD在虛擬化存儲中使用越來越多，SSD和軟件結合的軟件定義存儲方式也越來越熱。以后有時間，給大家介紹一些相關的案例。
▼虛擬機資源限制
一般在生產環境，需要給虛擬機做資源限制，因為我們不希望一臺虛擬機消耗的資源過多，造成其他虛擬機餓死，虛擬機的資源限制主要是通過CGroup去做，CGroup可以配置的選項非常多，也非常靈活，就是配置起來稍微復雜一些。
Libvirt在CGroup上包了一層，通過修改虛擬機的xml文件，就可以完成對虛擬機的資源限制，通過Libvirt限制虛擬機的詳細介紹，請參考我的博客文檔，介紹的比較詳細：
http://xiaoli110.blog.51cto.com/1724/1070201
下面介紹虛擬化運維中的監控、報警、災備及應急響應要點是什么？
#p#
▼監控報警
硬件故障報警，我現在主要是使用帶外管理卡報警，新一代服務器，帶外管理卡監控已經非常完善，CPU 、內存、磁盤、網卡、風扇、電源任何硬件故障都會報警，通過郵件，或者寫腳本和自己的監控平臺結合，可以很好的解決硬件報警的問題。
CPU方面，建議每個核的CPU利用率也監控起來，經常會碰到一種情況，就是整體的CPU利用率不高，可能只有20-30%，但是有一兩個核已經100%了，這時候其實已經碰到壓力瓶頸了，但是通過整體的CPU利用率是發現不了的。
內存方面，swap利用情況建議也監控起來，作為虛擬化來說，一般不希望宿主機使用swap分區，所以swap的使用要監控起來，方便出問題的時候排查，如果有大量的swap使用，應該設置報警，如果報警肯定是碰到性能問題了。
磁盤、網絡方面，虛擬化磁盤、網絡是兩個難點，一般在上線之前，應對其性能進行壓力測試，得到極限數據，然后根據極限數據設置報警閥值。
▼災備及應急響應
虛擬化的災備有兩種思路，應用層災備及虛擬化層災備，一般建議在應用層災備。虛擬化層災備的手段是多份的鏡像復制及快照，這個往往要消耗大量的資源，多份復雜是以犧牲幾倍的磁盤空間為代價，快照是以犧牲性能為代價。
往往應用層做了很少的改動，虛擬化層是不能感知的，只是全部備份，或者快照。
但是在應用層災備就簡單很多，只需要備份改動的部分，消耗的資源很少，而且速度很快。一般我們在生產環境的做法是，備份虛擬機的xml文件，當故障發生時，提供一臺配置一模一樣的虛擬機，如果有需要mac地址也保持一致，然后交給業務方進行恢復。
災備還要注意，定期演練非常重要，一方面是驗證自己的災備幾種，一方面也是讓參與的人能熟悉災備過程，這樣當發生問題的時候，就可以很快的恢復業務。
▼軟硬件選型
軟件方面，當然是穩定版本，但是在穩定版本的基礎上，內核版本越高越好，為什么呢?因為內核版本越高，對CPU的上下文切換和中斷優化的越好，越有利于提高宿主機轉化率。Windows系統也一樣，Windows虛擬機建議盡量使用比較新的版本。
硬件方面越強悍越好，內存越大越好，硬件越強悍，可以虛擬的虛擬機越多，從長時間綜合來看，肯定是節省成本的。另外，一臺宿主機，使用上一段時間，我們往往發現內存是瓶頸點，所有一開始的時候，盡量內存配置高一點，可以避免隨后的內存瓶頸。
▼下面分享最后一項內容，就讓我對公有云選擇的一些經驗：
用戶選擇公有云的主要因素有以下5條：
1、市場
主要是價格，其中有些公司和某些公有云就有合作，或者就是老板強制指定必須使用某款公有云。
2、云主機穩定性
選擇公有云，對用戶來說，最終用的就是云主機，所以云主機的穩定性也是重要因素，不可以出現云主機三天兩頭崩潰、重啟，甚至數據丟失。
一般穩定性公有云都能做到。
3、網絡覆蓋及網絡質量
在云上業務都是基于網絡，網絡質量是一個很關鍵的因素，網絡質量包含多個因素：
覆蓋范圍，覆蓋范圍越廣越好。
延時，丟包，抖動，就是延時、丟包符合要求，網絡抖動不能很頻繁。
這個因素往往容易被忽略。
4、大數據分析、RDS、運維工具支持
如果公有云能提供API，提供一套方便業務部署監控的工具，對用戶也有一定的吸引力，尤其是運維。
5、如果能提供物理機云主機的混合云是一個殺手級的解決方案。
業務壓力非常高，就需要物理機的支持，現在可以看到好多公有云也開始支持物理機的租用。
將業務遷移到云上，其實和虛擬化的過程是一樣的，按照前面介紹的流程去做，可以保證比較穩定的完成，而且虛擬化的具體技術還不用我們關心。
▼最后，總結下今天分享的內容：
在企業內部實施虛擬化，最重要的是口碑，如果一個項目接一個項目成功實施，就會越做越順利，相反，如果連續失敗1，2項目，虛擬化就推行不下去了。
我的分享結束了，歡迎大家提問，感謝！
接下來是QA環節：
1、企業現有一大堆dell服務器，業務也比較多并雜，您建議選擇那種整合的虛擬化方案或私有云方案？
答：這個問題非常好。如果是過老的機器，不建議當宿主機使用。具體的虛擬化方案是很復雜的問題，要根據業務、預算、應用來選擇。
2、一個關于vpc網絡的問題。當私有云有多個無法匯聚網段的時候，經常出現vpn網絡不穩定，尤其網絡物理鏈路中斷后，也不能自動恢復vpn鏈接，估計可能的問題有哪些？
答：可以考慮使用專線的方式，如果基于公網不能保證穩定性。
為大家推薦關注：
更多內容等你來
高招CTO訓練營
微信ID：gaozhao51ct
（長按二維碼關注互動聯系我們）
