1、OVM虛擬化的目標：
OVM是要實現混合虛擬化，做一個大一統的資源管理和交付平臺，縱觀虛擬化市場，現在當屬開源的KVM和Docker最火，我們工作過去有vmware,現在大量使用kvm,未來一定會考慮docker,但現有市場上的產品要么架構太大，開發難度高，易用性不夠強，要么就是單純的虛擬化，類似vmware等。
新形式下，我們需要的產品要同時具備如下目標:
跨平臺，支持KVM、Esxi和Docker容器
因為我們單位過去采用虛擬化技術混雜，上面又遺留很多虛擬機，這就要求我們新開發產品能夠兼容不同hypervior,同時還能識別并管理原有hypervior上的虛擬機，能夠識別并導入原數據庫技術并不難，難的是導入后還能納入新平臺管理，這部分我們又研發了自動捕獲技術，而不同混合虛擬化管理技術可以擺脫對底層Hypervisor的依賴，專心于資源的統一管理。
單獨的用戶自助服務門戶
過去采用傳統虛擬化時，解決了安裝部署的麻煩，但資源的申請和擴容、準備資源和切割資源仍然沒有變，還是要讓我們做，占據了日常運維工作的大部分工作量，每天確實煩人，所以我們想而這部分工作是可以放給相關的部門Leader或者專員，來減少運維的工作量，所以我們希望新設計的OVM允許用戶通過一個單獨的Web門戶來直接訪問自己的資源（云主機、云硬盤、網絡等），而且對自己的資源進行管理，而不需要知道資源的具體位置，同時用戶的所有云主機都建立在高可用環境之上，也不必擔心實際物理硬件故障引起服務癱瘓。
Opscode Chef自動化運維集成
實行自助服務后，有一個問題，就是軟件不同版本部署不兼容，這就需要設計能夠把操作系統、中間件、數據庫、web能統一打包部署，減少自助用戶哭天喊地甚至罵我們，我們通過對chef的集成，可以一鍵更新所有的虛擬機，在指定的虛擬機上安裝指定的軟件。有了chef工具，為虛擬機打補丁、安裝軟件，只需要幾個簡單的命令即可搞定。
可持續性
做運維不要故障處理辦法是不行，而且還要自動化的，同時我們有vmware和kvm,就需要新平臺能在esxi上（不要vcenter,要付錢的）和kvm同時實現ha功能
可運維性
一個平臺再強大，技術再厲害，如果不可運維，那結果可想而知。因此我們希望OVM可以給用戶帶來一個穩定、可控、安全的生產環境
彈性伸縮
自助服務部門拿到資源后，通過對各項目資源的限額，以及對各虛擬機和容器性能指標的實時監控，可以實現彈性的資源伸縮，達到合理分配利用資源。
資源池化
將數據中心的計算、存儲、網絡資源全部池化，然后通過OVM虛擬化平臺統一對外提供IaaS服務。
2、OVM設計思路
OVM架構選型一
我們覺得架構就是一個產品的靈魂所在，決定著產品日后的發展。
我們團隊在產品選型初期，分別調研了目前比較熱門的openstack，以及前幾年的明星產品convirt、ovirt，這幾個產品可謂是典型的代表。
Openstack偏重于公有云，架構設計的很不錯，其分布式、插件式的模塊化架構，可以有效避免單點故障的發生，從發布之初便備受推崇，但是其存在的問題也同樣令人頭疼目前使用Openstack的大多是一些有實力的IDC、大型的互聯網公司在用。而對于一般的企業來說，沒有強大的開發和維護團隊，并不敢大規模的采用openstack，初期使用一段時間后我們放棄了OS。
而前幾年的convirt，在當時也掀起了一股使用熱潮，其簡單化的使用體驗，足以滿足小企業的虛擬化需求，但是他的問題是架構采用了集中式的架構，而且對于上了規模之后，也會帶來性能方面的瓶頸，除非是把數據庫等一些組件松藕合，解決起來也比較麻煩，所以到了后期也是不溫不火，官方也停止了社區的更新和維護。
OVM架構選型二
通過對以上產品的優劣勢分析，我們決定采用用分布式、松耦合的模塊化插件架構，分布式使其可以規避單點故障，達到業務持續高可用，松耦合的模塊化特點讓產品在后期的擴展性方面不受任何限制，使其向下可以兼容數據中心所有硬件（通過OVM標準的Rest API接口），向上可以實現插件式的我們即將需要的工作流引擎、計費引擎、報表引擎、桌面云引擎和自動化運維引擎。
而目前階段我們則專心于實現虛擬化的全部功能，發掘內部對虛擬化的需求，打造一款真正簡單、易用、穩定、可運維的一款虛擬化管理軟件，并預留向上、向下的接口留作后期發展。（架構圖大家可以查看剛才上面發的圖片）
虛擬化技術選擇
Docker當下很火，其輕量級、靈活、高密度部署是優點，但是大規模使用還未成熟。許多場景還是需要依賴傳統的虛擬化技術。所以我們選擇傳統虛擬化技術KVM Docker，確保線上業務穩定性、連續性的同時，開發、測試環境又可以利用到Docker的輕量級、高密度和靈活。
另外很多用戶的生產環境存在不止一種虛擬化技術，例如KVM Esxi組合、KVM XenServer組合、KVM Hyper-V組合，而目前的虛擬化管理平臺，大多都是只支持一種Hypervisor的管理，用戶想要維護不同的虛擬化技術的虛擬機，就要反復的在不同環境之間切換。
基于此考慮，我和團隊內部和外部一些同行選擇兼容（兼容KVM、Esxi，Docker），并自主打造新一代虛擬化管理平臺——混合虛擬化。
網絡
網絡方面，我們對所有Hypervisor的虛擬機使用統一的網絡管理（包括Docker容器），這樣做的一個好處就是可以減少運維工作量，降低網絡復雜性。初期我們只實現2層的虛擬網絡管理，為虛擬機和容器提供Vlan隔離、DHCP分配網絡，當然也可以手工為虛擬機挑選一個網絡，這個可以滿足一般的虛擬化需求，后期我們會在此基礎上增加虛擬網絡防火墻、負載均衡。
存儲
存儲上面我們采用本地存儲 NFS兩種方式，對于一般中小企業來說，不希望購買高昂的商業存儲，直接使用本地存儲虛擬機的性能是最好的，而且我們也提供了存儲快照、存儲熱遷移、虛擬機的無共享熱遷移來提升業務安全。此外NFS作為輔助，可以為一些高風險業務提供HA。后期存儲方面我們會考慮集成Ceph和GlusterFS存儲來提升存儲管理。
鏡像中心
顧名思義，鏡像中心就是用來存放鏡像的。傳統虛擬化我們使用NFS來作為鏡像中心，所有宿主機共享一個鏡像中心，這樣可以更方便的來統一管理鏡像，而針對Docker容器則保留了使用Docker自己的私有倉庫，但是我們在WEB UI的鏡像中心增加了從Docker私有倉庫下載模板這么一個功能，實現了在同一個鏡像中心的管理，后期我們會著重打造傳統虛擬化鏡像與Docker鏡像的相互轉換，實現兩者內容的統一。
HA
OVM 主機HA依然堅持全兼容策略，支持對可管理的所有Hypervisor的HA。
在啟用HA的資源池，當檢測到一個Hypervisor故障，創建和運行在該Hypervisor共享存儲上的虛擬機將在相同資源池下的另外一個主機上重啟。
具體工作流程為：
第一次檢測到故障會將該故障主機標記；
第二次檢測依然故障將啟動遷移任務；
遷移任務啟動后將在該故障主機所在的資源池尋找合適的主機；
確定合適主機后，會將故障主機上所有的虛擬機自動遷移到合適的主機上面并重新啟動；
VM分配策略
負載均衡
PERFORMANCE（性能）: 這條策略分配虛擬機到不同的主機上。它挑選一組中可用資源最多的主機來部署虛擬機。如果有多個主機都有相同的資源可用,它使用一個循環算法,每個虛擬機分配到一個不同的主機上。
PROGRESSIVE（逐行掃描）: 這條策略意味著,所有虛擬機將被分配在同一個主機上,直到它的資源被用盡。此項策略將一個主機資源使用完,然后再切換到另一個主機。
負載均衡級別
所有資源池: 如果選定此選項,則負載均衡級別策略將適用于所選定數據中心的所有資源池中的主機。
所有主機: 該策略將適用于所選數據中心單個資源池的所有主機。
特定主機: 該策略僅適用于所選的特定主機。
VM設計一
VM是整個虛擬化平臺的核心，我們開發了一個單獨的模塊來負責虛擬機的相關操作。其采用異步通信和獨立的并行操作，提升了虛擬機性能、穩定性和擴展性。
可擴展性：獨立、并發
可追溯性：錯誤信息和log、監控控制臺、性能
非阻塞操作：穩定性、改進重新配置、改進回滾、標準、統一的hypervisor通信、自動化測試
VM設計二
我們設計基于vApp來部署虛擬機，一個vApp可包含N個虛擬機：
N 個虛擬機配置
N個開機請求
我們希望并行運行N個配置（要求資源允許），并在配置后每個虛擬機請求一個開機。這些操作都是并發和獨立的。
平臺設計
OVM產品目前由三大組件、七大模塊組成。其中三大組件分別為OVM UI、OVM API和OVM數據中心組件。
OVM UI提供WEB自服務界面，OVM API負責UI和數據中心組件之間的交互，OVM數據中心組件分別提供不同的功能。七大模塊分別負責不同的功能實現，和三大組件之間分別交互。
VDC資源限額
管理員可以為每個VDC設置資源限額，防止資源的過度浪費。
賬戶管理
OVM提供存儲SDK、備份SDK，以及虛擬防火墻SDK，輕松與第三方實現集成
獲得幫助
下載請訪問OVM社區官網：51ovm.com
使用過程中遇到什么問題及獲得下載密碼，加入OVM社區qq官方交流群：22265939
“ 實踐是檢驗真理唯一標準“,OVM社區視您為社區的發展動力,此刻，誠邀您參與我們的調查,共同做出一款真正解決問題、放心的產品，一起推動國內虛擬化的進步和發展。
填寫調查問卷！只需1分鐘喔！
https://www.wenjuan.com/s/iiEVZv
Tags: 數據庫技術 硬件故障 虛擬機 工作量 產品
文章來源：