樂視雲計算基於OpenStack的IaaS實踐
[日期：2015-09-22] 來源： KVM虛擬化實踐 作者： [字體：大 中 小]
本文作者嶽龍廣，現在就職於樂視雲計算有限公司，負責IaaS部門的工作。
從開始工作就混在開源世界裏，在虛擬化方面做過CloudStack/Ovirt開發，現在是做以OpenStack爲基礎的樂視雲平臺。所以對虛擬化情有獨鍾，也對虛擬化/雲計算的未來充滿了信心。
樂視網的所有服務是跑在樂視雲上的，樂視雲提供所有的底層支撐，包括IaaS/PaaS/Storage/CDN等等。爲了帶給用戶更好的體驗，樂視網的服務到哪，樂視雲的底層服務就會跟到哪。
其中虛擬化是必不可少的部分，它的快速提供、按需分配、資源隔離顯得特別重要，但我們會遇到什麼問題呢?
今天的主要目的是分享我們在OpenStack項目中做的一部分工作，它們解決了內部的一些需求，也是實際經驗，希望對大家有所啓發。
開始之前 首先感謝肖總、浩宇、victor等朋友給予的大力支持，感謝羣友、技術愛好者的圍觀。
很榮幸有這次機會來與大家做這個分享。
提綱：
1. IaaS Architecture
2. OpenStack Deploy & QOS
3. Multiple Regions
4. LeTV LBaaS
5. DEV
樂視雲計算IaaS的基本架構
首先就是介紹一下樂視雲計算基礎架構，再介紹OpenStack 網絡組件的部署，Multiple Regions是什麼樣子的，更方便於使用的LeTV LBaaS，最後是開發/上線流程。
樂視雲計算 IaaS 採用了 OpenStack 和 Ceph 的開源方案，爲樂視提供了雲主機、虛擬網絡、雲硬盤和 S3 對象存儲。
我們採用了 Ceph RBD 作爲 統一存儲，OpenStack使用的Cinder，後端接的是Ceph，Glance也是共享Ceph存儲。
我們同時還提供了 S3 對象存儲，用作於 CND 源站，存儲樂視網的視頻以及客戶需要分發的資源。
S3 也是全國分佈式部署，用戶可以就近上傳，再推送到北京。
目前樂視雲 OpenStack 規模已達 900 個物理節點，對象存儲的數據達到數PB。
Neutron Deployment & QOS
我們 Havana 版本採用了 nova-network 的 FlatDHCP 類型。
Icehouse 版本採用了 Neutron，再做足調研的前提下，我們對 Neutron 做了大量的減法，所用服務僅爲 Neutron Server 和 OpenvSwitch Agent，控制節點部署 Neutron Server(with ML2 plugin)，計算節點部署 OpenvSwitch Agent。
沒有網絡節點，因而沒有用到DHCP Agent，L3 agent 和 Metadata Agent。 物理網絡使用 VLAN 做隔離。由於 Region 數量較多，每個 region 有不同的物理網絡(對應ml2_conf 中的 physical_network 字段)，可以緩解 VLAN 數量的限制。
私有云環境通過 Config Drive 配置虛擬機網卡和 metadata，Public IP 地址直接配在虛擬機網卡上，走物理路由器。無論是 nova-network 還是 neutron，我們都採用了穩定可靠的網絡，由於不存在網絡節點的單點問題，因此集羣在滿足私有云的需求前提下，兼顧了可靠性、穩定性和可擴展性。
優點：簡單穩定，性能更好，這也是業務最需要的，線上業務穩定、可用性是最重要的。
缺點：犧牲了靈活性，和物理網絡的耦合度高
爲了防止某個虛擬機負載過高而影響其它虛擬機或者宿主機，我們做了了 CPU，Network 和 Disk IO 的 QoS，其中 Cpu 的 QoS 採用 cgroup 實現，虛擬機網卡的 QoS 通過 TC 實現。
一開始我們採用了 cgroup 限制 Disk IO，由於 ceph 採用了 Non-host-block，故 cgroup 無法限制基於 ceph 的 Disk IO, 因此我們採用了 qemu io throttling。和 cgroup 相比，qemu io throttling 不僅僅能支持 non-host-block IO，同時限速的效果也更爲出色，限速後，虛擬機的 IO 不會有太大抖動。
此外，如果基於 cgroup 的 Disk IO 設置過小，會導致虛擬機刪除失敗。原因在於 qemu 提交的 Direct IO 必須完成後才能退出，使用過小的磁盤帶寬導致此動作需很長時間才能完成，導致 qemu 進程不能及時響應 libvirt 發出的 SIGTERM 和 SIGKILL 信號。
而如果使用 qemu io throttling，則 io 會現在 qemu block layer 中加入 queue，此時 qemu 可以響應 libvirt 發出的信號而退出 。
使用 qemu io throttling 需要需注意的是，當 Xfs 扇區大小爲4k時，qemu 以 cache=none 方式啓動失敗
Multiple Regions
由於樂視網業務的特殊性，爲了讓用戶有更好的體驗，服務會分散部署在全球。
樂視網的視頻服務需要 CDN 的支持，對於某些 CDN 節點，特別是國外，需要提供雲主機等基礎設施服務。我們在國內外部署了有 20 多個集羣，每個集羣規模大小不一，其中最大的有上百個物理節點，這種需求也是極罕見的。
這些節點既有 Havana 版本，又有 Icehouse 版本。每個集羣均維護獨自的 Dashboard 和用戶信息，這就造成了以下四個問題：
1. 用戶租戶信息不統一，不同集羣的用戶信息不一致，對用戶使用有很大的影響
2. 訪問不同的集羣，用戶需要登錄不同的 IP
3. 運維難度增加
4. 維護 H 和 I 版本的 Keystone 和 Horizon
隨着集羣數量的不斷增加，上述問題將顯得越發突出，於是我們採用了 Multi-Region 方案，把這些集羣做了統一的管理。
部署方面， Keystone 和 Horizon 全局唯一，其中 Keystone 部署在公網，從而能夠被其它服務訪問，Horizon 部署在內網，從而能夠訪問其它集羣。這是大概的分佈圖:
LeTV LBaaS
LeTV LBaaS,在原生LBaaS基礎上做了定製化，爲了區分開來，就叫做LeTV LBaaS。
樂視網的服務需要高可用、擴展性。Neutron LBaaS 看起來是個不錯的選擇，基本框架有了，但是還不能完全滿足業務需要。
要想滿足業務需要，除了增強已有的接口，還有開發新的功能，比如HaProxy 冗餘，本身服務健康檢查，以及與LVS整合。
這是實際業務架構，通過域名解析到LVS，LVS把流量負載到LB機器，在通過LB把流量負載到其他機器，實際提供服務的機器可以橫行擴展，不管是虛擬機還是物理機，甚至是容器。
Letv LBaaS 可以輕鬆滿足業務需求，優勢如下：
1. 不同業務之間的LB，互不干擾。Haproxy跑在各自的namespace裏面
2. Haproxy HA 冗餘功能，保證服務的高可用
3. 方便動態增加機器
4. 與LVS整合
DevOps & Community
開發上線流程，基本和社區一致，是方便、可靠的：
Commit->Review->Auto Testing->Package->Testing->Production
最後總結一點建議：
方案的選取
1. 合適的纔是最好的
2. 業務需求優先，穩定性優先
組件的選取
1. 儘量採用主流軟件，遇到問題可以快速解決
版本的選取
1. 成熟度與時新並重
虛擬化，虛擬計算，虛擬網絡，虛擬存儲，我們大多會第一個想到OpenStack，或者由OpenStack帶來的這些功能。
其實這些技術是可以獨立的，可以完美用到其他方面。讓所有的業務都跑在虛擬網絡裏，爲他們提供虛擬資源，並且可以輕而易舉的控制調整它們，方便管理整個數據中心，希望我們以後可以探討更大的話題。
Q&A
1.爲什麼沒有使用swift?
答： switft 我不熟悉，但是ceph 數據分佈，性能方面都很不錯，crush算法是它的亮點。
2.可否介紹下你們的網絡架構 ，以及你們目前架構下對網絡的要求
答：總體的架構是標準的neutron架構，但是我們沒有部署網絡節點，直接使用物理路由器，這適合穩定性高的場景。
3.監控咱們這邊是怎麼做的，是用社區原生的Celimeter還是自己的監控系統
答：是的ceilometer，做過優化，以及換成influxdb，包括對floatingIP的流量監控。
4.iaas層是否提供了nas接口，視頻轉碼，合成等業務軟件訪問存儲是通過S3 接口還是其他接口呢;
答：沒有NAS接口。視頻提供了S3和HTTP接口。
5.選Haproxy有什麼優勢嗎?
答：HaProxy 是專注於負載均衡的功能，提供的算法比較豐富，併發性也更好。
6.你提到有的有集羣上百個物理節點，部署這些物理節點時候，採用什麼方法的?
答：參照問題2。
7.集羣把公網線和心跳線用反了有什麼後鍋，我感覺誰當心跳誰當公網，沒什麼大不了，求解
答：你說的心跳線是指什麼? 公網是收費的，大家不希望浪費購買的帶寬，所有不穩定的因素多。 內網做心跳更好，心跳實時性要求高。
8.交換機上的VLAN全手動配置?交換機也手動配置與虛擬機TC相對應的QoS?
答：是的，這個地方的QOS 主要是限速。
9.高可用如何保證的
答：DNS負載均衡 和 LVS 高可用，共同保證總的高可用。
10.那db性能怎麼解決?
答：一般沒問題，如果ceilometer 採樣頻繁，vm多的話，撐不住。我們現在是influxdb，已經對採樣頻率和採樣的內容進行裁剪。
11.對於些開發能力小的公司來說，使用上openstack不?openstack在虛擬機的基礎上做了資源管理，目的是充分利用資源吧?cpu方面的分配很好理解，IO能調配不?有一些場景是，部分機器io很閒，部分IO很忙，可以調整利充分用上?樂視的定製版在這方面有改進呢?
答：如果沒有太多需求，可以用virt-manager,直接管理。 openstack 還是比較複雜的。但是虛擬化可以大量節省成本io就是限制讀寫磁盤的速率iops 或者帶寬 ，qemu 自身可以限制。
12.公網絡這塊，這接把pub ip配置到容器，那平臺的防火牆策略在哪一層做限制?
答：外層防火牆，一般是3，4層. 是否控制 7層，我不能確定。
13.二次開發主要是改了哪些地方
答：社區有我們提交的代碼。
14.底層操作系統是啥?rehl6,7? or ubuntu?
答：centos6.5～。
15.上線往各個節點推送文件，是用什麼推的呢
答：是puppet。
16.LVS是什麼?會有單點問題嗎?
答：LVS 是linux virtual server, 沒有單點故障，參見問題9。
17.會有一個業務幾個region都有vm，需要互通嗎?
答：部署在幾個region 是爲了高可用性。 大家都會訪問同一個數據庫。
18.請問平均一個節點多少虛機?
答：爲了保證業務，我們的配比 比較低。沒有超過1：10. 主要看業務和重要程度。
19.每次版本更新需要多長時間，什麼範圍內更新呢?
答：我們現在是長期維護一個穩定版本。
20.在問個成本問題，是用的整理櫃服務器還是定製的服務器，一個機櫃裝幾臺?
答：不好意思，這個問題，我回答不了你，抱歉。
21.華爲分佈式存儲要求各個機器硬盤配置一樣，ceph有這個要求嗎?
答：沒有強制要求，ceph 可以設置機器的權重。
22.keystone，horizon全局唯一，是放在一個region裏面還是怎麼做冗餘的?
答：主要做好數據庫冗餘就好，前端部署LB，提供 高可用和併發。
23.想問下硬件資源cpu,mem,storage的超配比，是怎麼調配的
答：這個要根據自己的策略來定，看你的flavor，超配等。
24.請問是否有對雲主機安裝agent用做監控來收集信息
答：一般不需要，這個地方只是爲了取內存數據。
25. ceph穩定性如何?性能和san或者nas做過對比測試嗎?
答：和本地做過對比， san 和nas 品種很多，看對IO的要求，業務要求，ceph性能和穩定性都不錯。
小米OpenStack項目概況
小米目前內部建設的是高可用的私有云平臺，爲全公司提供統一的雲服務平臺。提供彈性的資源分配和部署方式，同時提高資源的分配和管理效率。減少服務資源的交付週期。爲此小米定了四大目標：
• 穩定第一：支撐公司多條產品線業務，力求穩定
• 性能優化：儘快可能的降低虛擬機的資源消耗，保證虛擬機的性能
• 內網互通：虛擬機需要和公司其他主機互聯互通。對其他主機透明
• 業務定製：OpenStack需要和公司其他系統互通（監控和主機信息）
小米基於這四點做了私有云平臺，有着數千臺VM的OpenStack集羣，穩定服務公司線上線下業務一年多時間，數據說明如下：
• 可用度達到99.99%。運行16個月，2次故障，分別是GlusterFS和OpenvSwitch引發的問題：1.GlusterFS的bug有可能導致文件系統被置爲Readonly，據說bug目前已經修復；2.在廣播風暴的情況下，OpenvSwith由於起軟件性能的問題，最有可能被打死，這個問題是所有的軟網橋（包括VMware）都存在的問題；
• 目前使用率：平均40%（物理機利用率），1虛12；
• 覆蓋度：小米所有產品線；
• 業務類型：開發，測試，線上（線下70%）。
現在整個平臺上運行在四個機房，有2000+VM，4500+物理機內核（E5-2640）；機器的配置主要爲：50T內存、1200T虛擬磁盤、480T塊存儲、120T對象存儲。
上圖是小米根據自己的情況定製的Dashboard的，分爲動態信息和靜態信息兩個部分，靜態信息顯示的是資源的分配情況，動態信息顯示的是目前資源的使用情況。
上圖是OpenStack物理主機的使用情況，機器是負載明顯看出是分層的，因爲是一批一批上的機器，後面機器由於虛擬機的使用還沒有分配滿，所以CPU LOAD會低一些。
上圖是虛擬機的負載情況，可以看出，有些虛擬機的負載程週期性變化，可能是跑的和流量相關的一些線上業務；而有些虛擬機的CPU卻一直持續在500%左右，可能是虛擬機裏面跑了高負載的離線計算業務。
小米OpenStack探索之路
機器選型
在進行機器選擇時，可選的類型並不多，一般是在公司內部已有的套餐類型中選擇，然後稍加定製，主要的要求實現服務器性能的均衡，而且性能比較好的主機類型。機器配置詳細參數爲：
計算節點: DELL _R720
• CPU： E5-2640v22(32核)
• MEM：16G24
• 磁盤：2600G SAS（Raid1) + 64T（Raid5） SATA
• 網卡: 1G 2 + 10G2 (Intel 82599EB 10-Gigabit SFI/SFP+ )
控制節點: DELL_R620
• CPU： E5-2630v22 (24核)
• MEM：16G4
• 磁盤：2600G SAS（Raid1) + 2240G SSD(Raid1)
• 網卡: 1G 2 + 10G2 (Intel 82599EB 10-Gigabit SFI/SFP+ )
其實Dell R720是Dell官方推薦的虛擬機雲計算主機，作爲OpenStack的計算節點還是比較合適的。
版本選擇
操作系統
操作系統選擇：Ubuntu vs CentOS。
OpenStack最早默認支持的操作系統版本是Ubuntu，後來才加入了Redhat系列操作系統的支持，但公司一般使用CentOS的系統，裝機方便，系統穩定，爲了穩定性和兼容性，我們也是採用CentOS做爲OpenStack的操作系統。採用RDO的方式進行安裝，但是在裝的過程中也遇到一些問題。比如在三個月之前採用RDO部署了一套系統，在三個月以後我們再需RDO部署的時候，RDO源上的版本就更新了，有可能導致老版本和新版本不兼容，由於OpenStack版本之間的測試不是特別完備，儘管是大版本相同但是小版本有差異，都有可能導致不兼容，但也有解決的方法：把yum源down下來，即解決了版本問題，同時也能加快軟件安裝下載的速度。
採用RDO安裝還有另外一個問題，就是在安裝完成以後，不能手動更改系統配置的路徑，如數據庫路徑或者鏡像存儲路徑，如果一定要改，須連packstack中的Puppet配置路徑一起改。否則在下次啓動RDO安裝時，他會再次將路徑再改成默認配置，這個將導致不可預知的錯誤。如果此時已經跑了服務，那很有可能會影響的服務。
總的來說，RDO的優點是簡單快速部署，支持多種網絡結構，缺點也明顯，添加計算節點是個坑，存在各種兼容性問題（packstack版本、qpid版本、libvirt版本），而解決的辦法就是建立自己的源，手動添加計算節點。
網絡
組件可選擇有Neutron 和 Nova-network。
我們選擇的是Neutron，也是跟着大趨勢走。網絡模型可選擇FLAT、GRE和VLAN。我們選擇了VLAN，因爲公司現有網絡模型也是採用VLAN模型，和OpenStack原生的網絡模型相比，我們的主要改進點是停用了L3 Agent，無單獨的網絡節點，讓虛擬機網絡通過Trunk直接和物理路由器相連，因此虛擬機網絡比較高效和穩定。與此同時，OpenStack工程師大部分是做開發和運維的，網絡管理不是他們所擅長的，所以把網絡節點去掉由交換機進行管理，全部交由網絡工程師去做，他們更專業。同時，若採用一個物理的主機作爲一個網絡節點，無論是性能上還是可操作性上，都不如成熟的交換機。Neutron的穩定性確實不高，經常斷掉，導致OpenVswtich無法配置網絡策略。
塊存儲
塊存儲的組件選擇有兩個，一個是Ceph，另外一個是GlusterFS。我們對Ceph和GlusterFS做了測試，在四臺機器上都部署了Ceph和GlusterFS，Ceph和GlusterFS在每臺機器上各佔一塊磁盤，2副本策略，機器是單網卡，測試結果請看下圖。
從上圖IOSP測試對比中，可以看出在塊比較小的時候，Ceph的IOPS性能非常高，在塊大小爲4KB的時候，甚至高出GlusterFS 40%左右，但是塊大小大於1MB的時候，Ceph的性能就不如GlusterFS了，我們推動是Ceph和GlusterFS不同的副本同步策略造成的。GlusterFS採用Client直接寫入的策略，即每次寫入以後，節點之間不需要再同步；而Ceph採用的鏈式寫入，即Client先寫入到一個節點上，然後節點之間再同步，因此會消耗一定的帶寬，當沒有專門的同步網絡的時候，同步所使用的網絡帶寬可能會影響到Ceph的寫入性能。因此，寫入方式的差異剛好能夠解釋GlusterFS在大塊寫入的時候會比Ceph性能好。
上圖是對Ceph和GlusterFS進行4KB大小塊的連續測試，我們會發現Ceph的整體性能會比GlusterFS高，但是他呈現出性能波動現象，而GlusterFS卻一直比較穩定，這也從一個層面上說明了Ceph這種鏈式寫入的機制對連續測試可能會產生波動性的結果。總的來說，兩者各有千秋，存儲沒有完美的方案，Ceph逐漸成熟，在小塊寫入的時候Ceph性能比較好，但是大塊寫入卻不如不如GlusterFS，同時Ceph的性能具有波動性。但是，GlusterFS在實際使用中可以導致虛擬機的文件系統被置爲Readonly（據說此Bug已經被修復），需要慎重考慮和測試。不管是Ceph，還是GlusterFS作爲虛擬機的共享存儲，都能夠提供毫秒級別的實時遷移，對虛擬機的負載均衡、主機維護非常有用；同時多副本的技術保證用戶數據的安全性，將數據丟失的風險降低最低。
對象存儲
所用組件是Swift，架構請參見上圖，Swift可以說是OpenStack最古老最成熟的一個組件，良好的設計思想，完全對稱的部署結構，無單點的系統架構。縱容有很多好處，但是在用Swift的時候，有一個慘痛的教訓，Swift作爲存儲服務器沒有丟失過數據，但是swift扛壓能力非常小，曾使用Swift做爲CDN的源服務器，流量稍一上來，Swift的服務器就被打死了，當時觀測流量大約10Mb左右，觀察Swfit資源消耗情況，在完全沒有壓力的情況下，Swift自動的組件性能消耗會佔一個核。
私有云架構
上圖所描述的是小米的OpenStack架構的使用，目前只有兩種節點，一種是計算節點，另一種是控制節點，但沒有網絡節點，所以網絡不會存在單點，任何一個計算節點宕機，只會影響其上面承載的虛擬機，不會影響其他節點，如果是一個可以預知的宕機，你甚至可以先將其上的虛擬機遷移到其他機器，這樣就可以將對服務的影響降到最低。另外，控制節點是主備模式，並且採用冷備的方式，但是數據庫保持實時同步。因爲這種私有云的架構對控制節點的依賴非常小，控制節點宕機，在不重啓計算節點的OpenVswitch-Aagent的情況下，幾乎不會影響虛擬機的正常運行。在網絡的架構上，我們有三種網絡：虛擬機網絡、存儲網絡和管理網絡。虛擬機網絡通過網橋，採用Trunk模式，直接連接到交換機，具有較好的性能和極高的穩定性。管理網絡是OpenStack各個組件通信的網絡，包括鏡像分發，虛擬機遷移等都是走這個網絡。存儲網絡是虛擬機訪問共享存儲Ceph的網絡。
上圖是小米私有云的網絡詳細架構圖，基於L3-Agent的穩定性和性能，我們停用了L3-Agent，虛擬機首先連接到br-int,，br-int連接到br-em3上，通過Trunk就可以達到外部網絡，這樣的架構解決了兩個問題：第一，能夠保證網絡的性能和穩定性，第二，能實現和內網其他機器無縫互通，
性能測試
在使用虛擬機時候，很多人抱着一個懷疑的態度，他們會擔心虛擬機的性能是否夠用，我們對虛擬機的性能做了如下測試：
測試1：整體性能測試
UnixBench是一個測試系統整體系能的軟件，測試中我們分別對比了AWS, MiStack,3U8j機器，從測試結構看，同樣是虛擬機，MiStack的機器會比AWS相同的機型性能好很多，主要原因是AWS爲了保障每個虛擬機的服務質量，對虛擬機的資源佔用情況做了嚴格的限制，因此可比性並不大，但是MiStack和3U8相比，其實相比相差不大，3U8作爲一種物理機器，在性能上只比MiStack主機好1/6左右，因此，我們可以說虛擬機的性能可以相當於相同配置的物理機行的80%以上。
測試二：磁盤性能測試
測試二是詞用IOzone對虛擬機的磁盤性能進行了測試，對比的是MiStack和3U8機器，從圖上可以看出，在讀取方面，虛擬機相當於物理機的5/6左右，在寫方面，虛擬機相當於物理機的9/10左右。
測試三：網絡性能測試
網絡測試分爲了兩組測試，一個測試是用HelloWorld做的，另一個是PhoInfo做的。採用PhoInfo測試時，虛擬機和物理機的差別並不大，但是在採用HelloWorld測試時，差別非常明顯，虛擬機僅相當於物理機的1/4。我們對原因進行了分析，由於HelloWorld頁面非常小，測試過程相當於產生了很多小數據包，而PhpInfo相對頁面很大，從而產生的數據包也比較大。當在小包測試下，網絡的瓶頸在PPS上，我們反覆測試過，虛擬機軟網橋的性能只能到達5wPPS左右，此時OpenVswitch已經到了極限，而普通的物理網卡確定達到200wPPS。在打包測試時，網絡的瓶頸在網絡帶寬上，因此，虛擬機和物理機帶寬相差不大，因此測試的結果也相差不大。
維護方案-虛擬機遷移
爲實現物理機故障維護和虛擬機的負載均衡，虛擬機通常需要遷移，主要分爲兩種維護方案：實時遷移和帶磁盤的遷移。
維護方案-實時遷移
因爲企業很難接受頻繁的更換，如果一兩個月換一次，那麼一個月要維護一兩次，若這時全部都通知用戶把機器和業務停了，會很痛苦。虛擬機遷移可以很好地實現“無痛遷移”。虛擬機遷移方案中的實時遷移是用一個precopy算法去迭代拷貝，在每次拷貝的過程中用內部記錄的方式記錄內存“髒”頁，當“髒”張頁數據集小於一定程度時，比如4K的時候，停止虛擬機，把內容和寄存器遷移，由於需要停機拷貝的內容非常少，因此停機的時間非常短，不過實時遷移一般是相同體系的CPU才能相互遷移。上圖是實時遷移，它的停機時間會很短。
維護方案-帶磁盤遷移
帶磁盤的遷移是將磁盤和內存一起拷貝到目前機器，由於磁盤數量很大，所以一般是先做快照，然後將形成的數據寫到增量中去，然後我們開始拷貝快照，當所有的快照都已經拷貝完成以後，再開始拷貝增量文件，一般在拷貝的過程中，產生的增量文件是非常小的，因此停機時間還是可以接受的。但是OpenStack沒有這麼做，他只做了一個快照，那就是鏡像文件，其他的數據都是增量，這樣會導致OpenStack虛擬機的增量文件非常大，停機拷貝的時間非常長，如上圖。
總的來說，實時遷移是採用precopy算法循環拷貝內存到目的機器，停機時間極短，但需要共享存儲；而帶磁盤遷移：將磁盤做快照後拷貝磁盤到目的機器，後面過程跟實時遷移一樣，整個過程時間取決於磁盤大小，停機時間稍長。（責編/周建丁）
作者簡介：潘曉東，畢業於華中科技大學集羣與網格實驗室，從2007年開始研究虛擬化雲計算技術，曾對XEN的實時遷移算法進行改進和優化。先後在百度、小米等公司從事運維、開發工作，現爲小米OpenStack項目負責人。在小米一直致力於高穩定的OpenStack私有云建設，目前小米集羣分佈在多個IDC、數千臺虛擬機，服務公司幾十個產品線的線上和線下業務。