有关ovm的29个问题解答及ovm产品经理对ovm的架构思考

第一部分分享内容《架构与技术分享》

首先非常感谢肖力、北极熊提供一个这么好的技术分享平台,能够和大家一起分享、讨论一些热门技术,也非常感谢主持人杨轩,一直忙前忙后的筹备本期分享,最后感谢各位听众对我分享的技术感兴趣,希望和大家一起探讨、学习、共同进步!

我是sam,目前在某公司负责基础设施架构做负责人,负责约1000台规模,最近正在迁移2000台vmware虚拟机到kvm平台上.

分享主题

1.企业为什么要虚拟化

2.OVM目标

3.OVM设计思路

 

1、企业为什么要虚拟化

使用虚拟化有什么好处,我结合自身单位几年运营,认为如下:

服务器整合

传统的服务器管理时代,服务器利用率不高,往往都是专机专用,一台服务器只安装一个应用,资源是严重的浪费;另外计算资源独立、资源无法共享也是传统服务器管理时代的一大弊端。随着互联网技术的快速发展,传统的管理模式已无法满足业务的快速发展。虚拟化可以在一台服务器上运行多个操作系统和应用,极大的提高了服务器的利用率,虚拟化也可以将所有资源池化,统一管理和分配资源,以此来降低公司的硬件和运维成本。

快速业务交付

现在的互联网时代,业务上线比的就是谁的速度快、反应快,这就对运维提出了更高的要求,必须保证业务可以快速上线、快速交付。虚拟化可以实现秒级交付虚拟机和容器,大大缩短了上线、交付时间,帮助公司业务抢占市场先机。

业务连续性

虚拟化提供的HA、在线迁移,可以帮助公司更好的应对硬件故障,做到业务零中断。

自动化运维

虚拟化提供的实时监控,以及经过封装的完善的对外接口,可以帮助公司更好的实现自动化运维。

 

2、OVM目标

OVM虚拟化的目标:是要实现混合虚拟化,做一个大一统的资源管理和交付平台

有关ovm的29个问题解答及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服务。

3、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),并自主打造新一代虚拟化管理平台——混合虚拟化。

网络  

 

有关ovm的29个问题解答及ovm产品经理对ovm的架构思考

网络方面,我们对所有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的29个问题解答及ovm产品经理对ovm的架构思考

OVM UI提供WEB自服务界面,OVM API负责UI和数据中心组件之间的交互,OVM数据中心组件分别提供不同的功能。七大模块分别负责不同的功能实现,和三大组件之间分别交互。

VDC资源限额

有关ovm的29个问题解答及ovm产品经理对ovm的架构思考

管理员可以为每个VDC设置资源限额,防止资源的过度浪费。

 

完整的RestFul API接口

OVM  RestFul  API

物理机管理

网络管理

虚拟数据中心管理

虚拟存储管理

虚拟网络管理

虚拟机生命周期管理

应用商店管理

账户管理

 

OVM提供存储SDK、备份SDK,以及虚拟防火墙SDK,轻松与第三方实现集成

 

成果展示—清晰的首页监控

有关ovm的29个问题解答及ovm产品经理对ovm的架构思考

成果展示—VDC资源限额

有关ovm的29个问题解答及ovm产品经理对ovm的架构思考

成果展示—统一的镜像中心

有关ovm的29个问题解答及ovm产品经理对ovm的架构思考

第二部分:提问互动环节

QQ群—KVM2群—Q1:VMware迁移到kvm 你是用什么工具呢?

答:VMware之前我们已经导入到平台实现了统一管理,下一步我们准备将部分相同业务转换成模板,然后在KVM部署新的虚拟机,部分直接淘汰,另外一部分可以直接导出vmware的镜像,然后基于这些镜像在KVM生成新的虚拟机,这些全部通过脚本来实现

QQ群—OpenStack群—Q1:企业虚拟化选用kvm xenopenstack怎么选择呢?这三个和OVM有那些异同点呢?

答:目前的底层hypervisor技术有kvm、xen、esxi等,openstack是属于管理平台,可以管理kvm,但是我们觉得openstack太重,不适合于一般企业采用;OVM希望做的是一个混合虚拟化管理平台,可以管理目前所有主流的底层hypervisor,用户无论使用何种hypervisor都可以使用OVM实现统一管理和运维

QQ群—OpenStack群—Q2:虚拟机的自动迁移是要基于共享存储吗,nfs?

答:虚拟机的自动迁移是需要共享存储的,但不限于NFS,手工在线迁移目前我们可以支持无共享存储的在线迁移

QQ群—OpenStack群—Q3:外部存储主要支持哪些?SAN、NAS、cifs等

答:外部存储目前支持NAS和cifs,后期会考虑支持SAN

QQ群—OpenStack群—Q4:vm基于非共享存储创建是否可以迁移?

答:可以,支持手工迁移,但基于非共享存储创建的vm不支持HA

QQ群—OpenStack群—Q5:外部存储系统映射的lun,ovm上的vm是否可以共享?
答:外部存储系统映射的lun,这个功能我们正在做,当前版本还不支持

QQ群—OpenStack群—Q6:今天内容还有整理的文档?

答:官网51ovm.com 微信公众号,openvm

QQ群—OpenStack群—Q7:nas存储走的是网络,稳定性并不如san,如网络突然中断,基于nas目录上的运行的vm是否down

答:是的,nas的性能及稳定性是不如san,如果网络突然中断是会对运行于其上的虚拟机造成影响,这种可以采取多路径绑定来避免该问题,下一步我们会提供对SAN的支持

QQ群—OpenStack群—Q8:目前你们实际案例或是测试出来,一个ovm平台最多有几台服务器运行?是否支持超分配?

答:实际案例是一个OVM平台到了300台物理服务器,测试模拟数据达到了万台,支持超分配,并可在UI设置超分比例

QQ群—KVM1群—Q1:ovm安装程序,有网盘下载链接吗?

答:ovm安装程序,有网盘下载链接的,可以到官网51ovm.com下载

QQ群—KVM1群—Q2:ovm部署教程?

答:ovm部署教程,在51ovm.com官网有提供,ovm社区交流qq群也有提供

QQ群—KVM1群—Q3:要么就是单纯的虚拟化,类似vmware等、这句话怎么理解 ?

答:要么就是单纯的虚拟化,类似vmware等——这句话我想可以这么理解,目前的虚拟化管理平台大多只提供对一种底层hypervisor的管理,而大多公司由于历史原因、成本考虑等共存了多种hypervisor,我们希望做的是提供一个统一管理这些底层hypervisor的管理平台,另外我们还将其扩展到了对docker的统一管理,实现了传统虚拟化和轻量级docker的混合管理

QQ群—KVM1群—Q4:思路不错!后面测试看看。目前有比较大的公司或者管理较多的设备实际使用吗?超过100台物理机的

答:目前我们这套产品有某知名广电单位在用,物理机规模已经超100,虚机规模达到了3000+

QQ群—KVM1群—Q5:ovm安装程序,网盘下载密码是多少?

ovm安装程序,网盘下载密码请到OVM社区交流群查询,在公告里面有

QQ群—KVM1群—Q6:本地存储如何在线迁移?

答:本地存储通过块复制来实现在线迁移

QQ群—KVM1群—Q7:外部存储目前支持NAS和cifs,后期会考虑支持和SAN。请问,CIFS都可以呀?smb2.0 or smb3.0 ?

答:是的,CIFS可以的

QQ群—KVM1群—Q8:本地存储通过块复制来实现在线迁移。请问,块复制?DRBD

答:目前没有用到DRBD

QQ群—KVM1群—Q9:如何在线同步不同主机的数据块?

答:关于虚拟机的无共享存储热迁移后期我们会出一个详细的原理性介绍文档,届时你可以关注

QQ群—KVM1群—Q10:windows8有没有办法读取xfs格式的移动硬盘

答:这个问题貌似需要微软工程师来回答,目前没有做过这个验证

QQ群—KVM1群—Q11:举个极端例子,如果ovm平台出问题,我当前运行的虚拟机及宿主机会有影响吗?

答:如果ovm平台出问题,对当前运行的虚拟机及宿主机均不会有任何影响

QQ群—KVM1群—Q12:HA方面,管理节点自身如何做到HA高可用?

答:管理平台HA方面,管理节点目前我们通过zookper来实现,具体的我们随后也会安排工程师整理出一个文档提供到官网,不过管理平台部署到虚拟机是最容易实现HA的

QQ群—KVM1群—Q13:负载均衡中,性能是如何判断的,比如CPU  内存,哪个参数更优先?

答:负载均衡策略中,可以对CPU和内存参数分别设置,所以不存在哪个优先

QQ群—OVM社区群—Q1:ovm管理平台支持集群吗?如果不支持对kvm有没有影响?

答:OVM HA不限于nfs,只要是共享存储均可,ovm管理平台支持集群的

QQ群—OVM社区群—Q2:整个平台自身的性能有没有什么样的性能指标。假设一个标准的ovm平台,支持管理多少台物理机,支持多少虚拟机数量等等。还有虚拟机创建有没有内置一套策略,(虚拟机创建合理分配到资源空闲的物理机和存储。)

平台是分布式的架构,可以做成多个多个数据中心的模式,支撑万台规模没什么问题,虚拟机的数量可支撑到10万+(我们测试数据,具体生产环境可能有差异),关于虚拟机创建合理分配到资源空闲的物理机和存储,这个我们内置有策略,用户可以配置策略,分配时会根据策略判断

QQ群—OVM社区群—Q3:OVM在支持VDI方面有哪些设计?

答:目前我们还没考虑对VDI的支持,后期可能会考虑

QQ群—OVM社区群—Q4:OVM支持哪些虚拟化引擎

目前支持KVM和Docker,后期我们会考虑增加Esxi、XenServer、Hyper-V

微信群-免费虚拟化OVM-Q1:有这个整体的拓扑图吗?

答:关于OVM的图片可以参考今晚分享提供的图片,另外后期我们也会将更多OVM相关的设计图、架构图分享到51ovm.com,希望大家持续关注我们官网

微信群-免费虚拟化ovm-Q2 能详细说下sdn和存储吗?

答:SDN我们不打算重写,计划集成现有比较成熟的开源方案,并给大家提供更多种选择,具体的可以持续关注我们微信公众号和官网,关于存储,目前我们只支持简单的NAS,后期会考虑集成ceph和GlusterF

微信群-免费虚拟化ovm-Q3:可以自定义CPU超分比?内存、硬盘允许复用?内存、硬盘允许预先分配?

答:内存、硬盘允许复用问题请看分享内容,硬盘允许预分配,我的理解是假如创建了一个200GB磁盘的虚拟机,其在物理硬盘上的占用以虚拟机的实际使用空间来计算,那么剩余的部分依然可以分配给其他虚拟机使用,但是不建议这么用;至于内存预分配,我觉得这个没必要,只要支持内存热添加,那么就不存在虚拟机内存不够用的情况


免费虚拟化,从ovm开始

KVM云技术社区微信群,加入请联系北极熊:

KVM社区QQ群,99.99%纯技术交流气氛

QQ 1群:434720759(已满

QQ 2群:131961942,加入密码大写KVM

1000人VMWare技术交流群494084329,加入密码小写vm

OpenNebula QQ群:495571573 加入密码Nebula

2000人OpenStack开发纯技术群: 334605713 加入密码nova

Cloudstack纯技术交流群:515249455密码cs

2000人桌面云行业讨论: 484979056 加入密码大写VDI

2000超融合行业讨论群:65779632 加入密码大写HC

2000云技术招聘求职群: 279875515 加入密码hr

您可以选择一种方式赞助本站

支付宝转账赞助

支付宝扫一扫赞助

  • 版权声明:本文源自互联网,于1年前,由olinux整理发表,共 7784字。
  • 原文链接:点此查看原文

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

图片 表情