Garyy
作者Garyy2020-05-11 10:54
系统工程师, 某保险

云计算工程师日常运维OpenStack管理平台遇到的坑及难点总结

字数 19535阅读 6689评论 0赞 7

金融企业在云化方面一直勇于探索,创新,很多新兴技术应用总是走在多个行业的前列。很多企业都在积极努力的实践、学习,搭建自己的私有云平台。为了满足自主可控的要求和大策略,OpenStack自然成为很多企业的首选。从部署在测试环境的探索到生产环境的实践,OpenStack是一个灵活性非常强的云管理平台,各个组件开源独立,组合多样。自然就增加了安装和运维的复杂性和难度。

为了让企业云计算工程师在日常运维管理openstack平台的时候能更好的互助解决遇到的坑和难点问题。组织了一场交流,并且整理了交流探讨内容分享给大家。

1、如何把原有虚拟化下的系统迁移到openstack集群?哪种方案可行并更方便?

如何把在vmware下的应用系统整体平滑迁移至openstack集群?
1.虚拟机vmdk文件倒进倒出
2.在openstack集群新搭建虚拟机,进行业务系统迁移
哪种方案可行并更方便?

回复1:虽然第二种方式麻烦一些。不过终究还是比较稳妥的一种可进可退的方案。只是在一些实际环境中。一些应用过老。文档资料不全。技术支持中断等原因导致没有办法搭建一个新的环境。而不得不被迫采用V2V的方式。
我觉得还是要根据具体情况详细分析。针对所有的业务来制定适合的方案。如果可以新建环境进行业务迁移固然最好。如果新环境没办法成功搭建。考虑V2V的方式。也并不一定就是九死一生,做好虚拟机备份在进行迁移也未尝不可
回复2:为了业务的平稳迁移,建议采用第2中方案。虽然第1种的方案操作简单,但是vmdk磁盘格式转换的过程中有可能会出错。
回复3:根据项目经验,建议是重新建立VM,进行数据层的迁移,而不是VM的迁移,虽然vmdk可以转换,但是风险很高。
回复4:从工作简便易行上是第一种
从易用兼容是第二种,取决于你的数量级以及迁移时间与应用可接受的方式,看有没有应用组支撑您重新部署,如果没有就考虑第一吧,v2v把vmdk倒出,然后转换qcow2。但是可能会有兼容性或者倒出损坏的问题
回复5:在openstack集群新搭建虚拟机,进行业务系统迁移
虚拟机导出导入之后,不能保证原有的程序一定可以正常运行。也不好保证vmdk在做v2v转换之后就一定不会损失格式或者有虚拟化格式之后的效率损失。
迁移在大多数情况下比较靠谱,可以充分测试没问题之后再切换业务入口。
也可以两种同时进行,对于不同业务选择不同的迁移方案。
个人意见是尽量多的选择2。

2、使用openstack 建设企业桌面云平台, 成本控制?

openstack的私有云已使用,win7的云主机 可以使用
目标:使用openstack 建设企业桌面云平台
尝试:进行了桌面云的调查
困惑:
成本问题,服务器的资源:cpu、内存、硬盘的采购价是要高于pc机的;
为说服领导,建设桌面云,相对于pc采购没有劣势,如何考虑这个问题;
多谢讨论意见。

回复1:云桌面,有劣势,你要说明领导,首先你要知道缺点
(1) 不便宜, 现在pc机的价格大幅降低,但你要知道云桌面的一个节点,价格并不低,早些年,天
矶科技出过一款云桌面,服务器是送你的,你大概以为捡了个大便宜,但我告知你,一个节点一年收费近3千,你怎么想? 所以,如果你要上云桌面,首先,不是去说服领导,首先要去杀价。
(2)可靠性, 所有的节点都连上机房的服务器,请问,服务器挂了怎么办。再请问,网络堵住了又怎么办? 你一定会说,有维保啊! 好,又是钱,你买pc机需要这么贵的维保吗? 所以,第二点,还是去杀价,把云桌面维保的价格杀到比pc维保低。
(3)性能,随着你的节点数量的增加,服务器也要升级,问题又来了,供应商是否免费升,网络是不是也要升,又是钱。
科技是在进步的,但进步不意味着都合适,你要仔细分析,努力杀价。
回复2:云桌面有以下优势:
第一,运维成本。PC部署以及系统软件安装耗时较长,云桌面后台5分钟一台自动交付可供用户使用的虚拟机;PC扩大部署投入巨大,云桌面只需要购买少量服务器接入云系统,快速扩大部署。
第二,故障处理效率。PC有问题,有可能需技术人员到用户现场开箱检查,故障排查耗时较长,严重点的硬件问题如需更换配件,等待周期更长。云桌面故障标准是5分钟处理完毕。对于5分钟无法解决的问题,只需后台更换虚拟机解决。
第三,运维管理。PC分散在用户桌面,运维需要用户配合(比如保持开机)。云桌面提供了运维系统,只需设定好时间、安装任务参数,系统会全自动进行安装维护。同时,瘦客户端轻量,无任何用户数据,对用户也带来极大便利。典型的如用户位置迁移,云桌面无需搬移,只需用户到新位置登录即可。
云桌面整体低碳、环保。瘦客户端功率跟普通节能灯相近,比PC低一个数量级。
Openstack在资源整合方面,相对传统行业,还是有很多优势的。
回复3:云桌面的优势
第一,运维成本。PC部署以及系统软件安装耗时较长,云桌面后台5分钟一台自动交付可供用户使用的虚拟机;PC扩大部署投入巨大,云桌面只需要购买少量服务器接入云系统,快速扩大部署。
第二,故障处理效率。PC有问题,有可能需技术人员到用户现场开箱检查,故障排查耗时较长,严重点的硬件问题如需更换配件,等待周期更长。云桌面故障标准是5分钟处理完毕。对于5分钟无法解决的问题,只需后台更换虚拟机解决。
第三,运维管理。PC分散在用户桌面,运维需要用户配合(比如保持开机)。云桌面提供了运维系统,只需设定好时间、安装任务参数,系统会全自动进行安装维护。同时,瘦客户端轻量,无任何用户数据,对用户也带来极大便利。典型的如用户位置迁移,云桌面无需搬移,只需用户到新位置登录即可。
最后,云桌面整体低碳、环保。瘦客户端功率跟普通节能灯相近,比PC低一个数量级。
Openstack在资源整合方面,相对传统行业,还是有很多优势的。

回复4: 1、桌面云从长远来看,集中管理, 可以减少运维成本; 2.如果网络可通达,可以随时随地连接到虚拟桌面开展工作; 3.就安全方面考虑,虚拟桌面更容易集中设置安全策略; 4.用电量也会减少;
2、采购pc机的话,需要人均一个,虚拟桌面的话,服务器的资源考虑满足并发的需求就可以。

三、OpenStack 与 K8S 容器平台的融合方案?

背景环境:
我们公司目前有两个轻量级的验证性平台一个是基于 OpenStack P版本的 IaaS 云平台,一个是基于 K8S 1.8版本的容器平台,都是使用的社区版本进行的构建,并且在进行了验证之后将公司内部的应用系统迁移到了云平台上,将与项目、研发等相关的产品迁移到了容器平台上。经过一年多的运行之后,现在因为管理上的需要,规划将两个平台进行整合,方便进行统一的管理。
现场信息:
云平台有10台主机,容器平台5台主机
已有的思考和尝试:
当前的想法是准备采用在云平台上开设虚机主机,通过虚拟主机的环境重新构建一套新的 K8S 环境,对现有容器平台的业务进行迁移。遇到的难点在于有些容器平台上的业务对性能要求比较高,经过这样两层包装处理性能衰减的会比较多,影响运行的效率。另外,还有一块儿我们的部分业务是需要直接和主机的外接物理设备进行通讯和交互处理的,在本身只有一层平台的时候配置虚拟主机或者容器可以访问到该硬件资源就比较复杂了,现在如果变成两层结构的话,感觉实施部署以及出现故障之后的排故,都会变的很复杂。
但之前有想尝试通过 K8S 来打包 OpenStack,但结果尝试失败了,也没找到比较合适的开源方案,而且感觉容器平台上部署云平台的思路,也有点儿本末倒置,就放弃了。
希望专家能够提供一些方案性的建议,如果可以的话最好是基于开源的方案,以及一些思路。

回复1:目前在 OpenStack 上部署 Kubernetes 有多种方式:
//Tectonic
由 CoreOS 开发,是开源企业级的 Kubernetes 部署解决方案,对 Kubernetes 做了一些改造,支持多集群管理(也就是支持多租户管理),更流畅的图形化管理等。但 Tectonic 主要的目标是在公有云上部署,比如 GCE、AWS 等,虽然也开始支持 OpenStack 等私有云,但目前还不够成熟,处于 pre-alpha 阶段,所以暂不考虑。
//kops
由 Kubernetes 社区开发,是一个部署 Kubernetes 的命令行工具,和 Tectonic 一样,主要的目标也是在公有云上部署 Kubernetes,而且对 OpenStack 的支持也不算好,目前处于 Alpha 阶段。所以 kops 也不予考虑。
//kubeadm
由 Kubernetes 社区开发,是 Kubernetes 目前官方推荐的部署方式,大幅简化了 Kubernetes 的部署复杂度,但依旧需要较多的手动操作,而且这和在裸机上部署是没有任何区别的,对 Kubernetes 没有任何的功能增强。但是可以考虑在其他方案实施难度较大时,作为备选方案:先用 kubeadm 在 OpenStack 上手动搭建好环境,做成镜像,再使用 cloud-init 注入个性化数据(可能这部分的工作量也不小)。

回复2:本来通过 Magnum 可以实现K8s在openstack环境下的部署,可你的实际情况又不允许,这就不好办了。你或者可以试着按照社区里面那样实现K8s和openstack各个组件的对接,但是工作量可不小。

四、公司规划基于Openstack开源架构方面的进行存储统一管理,是否有好的解决方案?

目前公司规划基于openstack开源架构方面的进行存储统一管理(例如对接ceph,或者对接glusterfs)但是开源存储针对openstack 页面管理等没有很好的支持,是否有好一些的解决方式?

回复1:对于开源的存储解决方案,都是不稳定的,比如glusterfs,就经常不可读,冒bug,让你不得不重启,总之,我们吃过无数的苦头。Ceph也一样,不过社区支持好,遇到问题总有前辈来解决。
所以,如果你一定要上开源的分布式存储,建议上ceph、hdfs等社区活跃的分布式存储。 ceph虽然源于openstack,但目前使用的领域已经远远不限于openstack了。当然openstack对它的支持是原生的,最好的。 如果你再不放心,就只能去买华为的分布式存储,性能很不错。
奥,对了,你可能意思是没有”界面‘’管理,不过你放心,ceph的新版本自己有比较好的管理界面了。

回复2:OpenStack私有云中,对传统存储的自动化统一管理,其实还是需要利用传统存储的自身工具,再开发一个统一的界面来进行管控。

五、Openstack的nova接管vsphere时需注意什么问题?

回复1:nova-scheduler 可调度的 nova-compute 可以有多个,并且每个 nova-compute 对应了 vSphere 上的一个 Cluster ,每个 Cluster 又都要有一个 Datastore 进行配置和使用。
通过 Openstack 来创建 vSphere 的虚拟机后,虚拟机在 vCenter 的总控界面中会得到呈现,并且可以支持 VMware 的高级功能。除此之外,在 Horizon 中也会得到呈现,能够像管理其他 Openstack 虚拟机一样管理 vCenter 中的虚拟机,但也可能会存在部分 VMware 的功能限制(如ssh keys等)。

回复2:逻辑上看,OpenStack与vCenter直接通信,VC管理整个ESXi集群,vMotion、HA、DRS也都能用了。但vCenter从Nova-Compute中抽离出了ESXi主机,Nova-Scheduler将整个自管理的集群作为一个独立主机接入——这会导致一些问题,大致特点如下:
· 不同于基于内核的hypervisor,vSphere需要一个单独的vCenter主机,VM是运行在ESXi主机上而不是计算节点上。
· 尽管OpenStack已支持多hypervisor,但一个计算节点同时只能支持一种hypervisor。因此,multi-hypervisor的OpenStack混合云,对于每一种hypervisor类型就至少要有一个计算节点来对应。
· VCDriver有限制,每个Nova-Compute服务仅能对应一个vSphere集群。当计算节点作为VM运行在同一集群下时,就具有了HA能力。
· VCDriver中每个cluster都要有一个datastore来进行配置和使用.

六、Zabbix 监控openstack虚拟机方式选择?

使用了openstack 私有云,被迫研究监控
想法是,使用zabbix监控 openstack'云主机
一种方式:在云主机中安装 zabbix'客户端,这个不讨论了。
另一种方式:zabbix'连接 openstack,

   查看了一些 zabbix的模板,实现不了云主机的监控;

目前还在困惑中。

回复1:分两层,不要混淆
对于用户层,只需要知道Iaas层的云虚拟机是否正常,当然是在openstack用zabbix来监控Iaas层的实例,这没有毛病是必须的。
对于底层,openstack集群的服务器的监控,当然你也可以用zabbix,是用内部的那个,还是自搭,我建议后者,由于网络的原因,最好不好混起来。

回复2:我们的做法是采用第一种方式:在云主机中安装 zabbix'客户端。第二种方式使用zabbix连接openstack监控云主机的话,监控的内容没有第一种方式多,只能简单的监控云主机的状态。

回复3:推荐第一种方案,openstack的监控这块做得并不好
如果通过openstack中转的话,很多方面会收到openstack社区的限制
我们通过prometheus实现的。

七、企业如何判断自己的私有云建设使用Openstack还是VMware?

越来越多的企业已经开始或计划建设自己的私有云,那么作为IT的规划人员,基于哪些维度选择适合自己的私有云平台?

回复1:私有云,如果用于生产,谁让你用原生的openstack,如果你在的不是bat性质的公司,你就把他给烧鱿鱼。都是坑啊,上生产,不是自己找药吃。
如果生产要用openstack,一定要买商业化的openstack,比如easystack、青云的、ibm等等,有底层运维团队的支持。其实就是bat团队自己搞底层运维,而你雇一个团队搞底层运维。
vmware基本不用如此,你只要买license就可以了,运维要求不高, 产品成熟啊! 所以,你的钱大部分都花在license上,license依据vcore,一个大约5000,我的天,上千台虚机不是天文数字,不过这是可谈的,一般超了不多,vmware公司也不会来找你要。一般每年你只要意思意思给个几十万就可以了, 但这不是法律承认的。 正规公司都必须和vmware谈一个总包价,不打擦边球。

回复2:首先要搞清楚,openstack是一个管控平台,包括主机,网络,存储,容器,编排,裸金属管理。。。诸多的项目。vmware是一个企业,里面包含了很多的产品,有和openstack相类似的平台管控vcloud,or vRA;也有虚拟化产品vsphere,分布式存储vSAN,防护vShield。。。
你说的使用openstack,还是VMware,可能是指用openstack系列,还是VMware系列的产品;他们其实客户相互包含的。具体要看项目的情况。

八、Openstack与VMware的优劣势有哪些?

目前私有云部署主要集中在开源领军阵营的Openstack和商用领军阵营对的老牌VMware,它们各自有哪些优势和劣势?

回复1:openstack
(1)openstack是免费的,但它是半成品,如果没有强大的“团队”做支撑,没人敢于用于生产
(2)就是有团队,我也很犹豫,因为太复杂,里面只要有一个故障,就是生产事故,而且排查困难。
(3)openstack是技术的方向,有了这个方向,各个商家去研发自己的类openstack产品,用于生产,比如Qcloud,青云。
vmware
(1)vmware是收费的,成熟的商业化产品,走强大的技术团队;
(2) vmware可以用于所有的环境,大量的产品在其中运行,基本上你不用担心挂了,稳定;
(3)vmware是cloud foundry的组件之一,cloud foundry是云平台的基础,走的是不同于openstack的一条路。

回复2:Openstack可塑性高,门栏高,开源,技术支持服务少。
VMware稳定,固化,收费,但是技术支持服务多,可靠。

回复3:openstack在2019年由几个大厂支持的环境部署已经很成熟,
技术层面,硬件sdn加openstack组件完成 联动虚拟化部署方案的 华为是最优势选择
反而vmware这些年的部署情况看了 vmware自己的sdn是软件构成几乎没有在金融行业部署
vmware如果集成cisco的sdn方案成本很高,包括日后的维护费用的运维费用
而且这些年容器的部署也开始逐步侵蚀vmware的部分业务,
但对于openstack和vmware的优缺点可总结如下, 这里特指金融行业,其他行业不具有参考力

  1. 公有云技术输出的能力
    openstack使用厂商级别支持, 硬件sdn集成,可做类似公有云部署进行技术输出
    vmware反而没有这个运维能力,资源无法完成租户等业务模块需要单独开发, 网络部分需要集成cisco硬件sdn,成本很高, vmwaer自己的软sdn无法满足业务需求,目前无法完成类似公有云的算力输出能力
  2. 价格方面
    openstack厂商级别 比如华为, 圈套服务器+ openstack系统+ sdn系统,打包后, 软件成本几乎对项目总成本来说占比很少,
    vmware架构做公有云技术输出是: 服务器硬件成本, + sdn硬件( cisco )成本 + vmware的软件成本 + 二次开发运维平台的成本.成本远远超过openstack方案
  3. 项目实施层面,
    openstack实施由厂商统一完成, 包括 sdn, openstack集成, 上层云运营平台部署可一体化无缝完成
    而且vmware需要分别进行sdn集成, 服务器集成, 公有云运维系统开发, 多方导致实施难度增大(即使又一家厂商完成总包方案也是分包到各个厂商的技术人员完成总体业务交付)
  4. 后期维护成本
    openstack 本身开源, 软件升级速度由产品支持厂商完成, 费用相对较低
    vmware本身技术成熟度搞, 维护费用由厂商支持(购买厂商的原厂支持license), 相对较高

回复4:(1)设计层面
VMware软件套件是自底向上的架构,下端边界为虚拟机管理器。像VMware的vSphere和vCloud director产品都是依赖于免费的ESX(i) 虚拟机管理器, ESX(i)虚拟机管理器为他们提供了非常优秀的部署架构。本身VMware的软件套件也是经过全面测试过的,并且都有单一部署框架。总的来说,VMware的产品由于其架构的健壮性,很多高规格用户在多数据中心规模的环境中都有使用。换句话说,VMware的软件系统是封闭的,并且软件的发展路线是完全遵循VMware自己的发展目标,用户或消费者在此方面没有任何控制权。
OpenStack作为一个开源系统,没有任何一家单独的公司在控制OpenStack的发展路线。本身OpenStack是年轻的,还不满三周岁,但是他却具有巨大的市场动力,与此同时,很多大公司都在支持OpenStack发展。有了如此多公司的资源投入,OpenStack的发展是多元化的。然而这也带来了问题,就是OpenStack部署和架构的实施和维护成本较比VMware有了陡然提高,与此同时,由于相对快速的版本更新速度,技术支持文档不能跟上产品的脚步。
(2) 在功能的支持方面和功能细节
OpenStack与VMware还是有差距的,但是这对OpenStack还是有优势的,因为较比VMware的昂贵价格,OpenStack免费、开放的优势显现出来。VMware高投入带来的功能,OpenStack大部分可以免费提供给客户。
从VMware在功能方面的领先可以看出,VMware还在继续研发除了vMotion、高可用、容错以外其他的新功能去保护他们的虚拟机;OpenStack一方面跟随VMware的脚步,另一方面他们投入精力在支持更多硬件厂商解决方案的上面。

总的来说,OpenStack入门门槛较高,但是随着项目规模的扩大,你将从中受益,因为不必支付高额的版权费用。VMware虽然在小规模安装时相对容易,但是随着规模扩大,事情就变了。这就是说,随着云应用大规模化,大家也更加熟悉OpenStack,那么OpenStack的入门门槛就低得多了。_

九、openstack的实施中遇到的难题?

在使用商用openstack产品,在纳管vmware的vcenter时是如何能匹配openstack产品的上层组织架构(如多租户的情况)进而有效避免多次重复纳管,在接管vcerter是如何能保证网络的正常使用,对网络的影响最小,在哪些操作的时候,对网络有影响,请专家给点意见呗。

1.根据VMWare中的VM所在的网络信息,在Openstack中创建对应的网络,VLAN ID保持一
2.在OpenStack中创建port对象,MAC地址保持与VMWare中VM的MAC地址一致
3.在OpenStack中创建VM对象,UUID保持与VMWare中VM的UUID一致
4.将新创建的VM对象连接到分布式vSwitch
5.将新创建的VM的VNC端口打开,以支持远程访问
方案的核心思想是在OpenStack里增加一个与创建VM过程类似的纳管过程,输入被纳管VM的IP、MAC、CPU和内存规格、操作系统等信息,将创建VM的各环节在OpenStack里跑一遍,从而在OpenStack数据库中构造被纳管的VM相关的配置管理数据,但在最后一步并不将相关指令真正下发到vCenter。

回复2:openstack产品纳管vmware稳态计算资源时候, 网络部分需要根据稳态网络变化来进行对应调整
这个联动技术,目前定义为云网联通, 意思就是 和云环境(openstack)进行联动变化
稳态网络变更时候需要调用云网(openstack接口)完成sdn的网络变化,下策略到sdn中使其能适应稳态网络环境的变化.
这个技术需要单独适应客户环境化开发(客制化)开发.比较难处理的一部分业务内容 。

十、openstack中的内部组件是靠什么协议通讯的,靠什么组件通讯的?如何保证通讯的可靠性?

回复1:OpenStack 组件之间的通信分为四类:
1 基于 HTTP 协议
2 基于 AMQP(Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议) 协议(基于消息队列协议)
3 基于数据库连接(主要是 SQL 的通信)
4 Native API(基于第三方的 API)
基于HTTP协议进行通信
通过各项目的 API 建立的通信关系,基本上都属于这一类,这些 API 都是 RESTful Web API,最常见的就是通过 Horizon 或者说命令行接口对各组件进行操作的时候产生的这种通信, 然后就是各组件通过 Keystone 对用户身份进行校验,进行验证的时候使用这种通信,还有比如说 Nova Compute 在获取镜像的时候和 Glance 之间,对 Glance API 的调用, 还有比方说 Swift 数据的读写,也是通过这个 HTTP 协议的 RESTful Web API 来进行的。
基于高级消息队列协议

基于 AMQP 协议进行的通信,主要是每个项目内部各个组件之间的通信,比方说 Nova 的 Nova Compute 和 Scheduler 之间,然后 Cinder 的 Scheduler 和 Cinder Volume之间。
需要说明的是,Cinder 是从 Nova Volume 演化出来的,所以 Cinder 和 Nova 之间也有通过 AMQP 协议的通信关系,由于 AMQP 协议进行通信也属于面向服务的架构, 虽然大部分通过 AMQP 协议进行通信的组件属于同一个项目,但是并不要求它们安装在同一个节点上,给系统的横向扩展带来了很大的好处,可以对其中的各个组件分别按照他们负载的情况进行横向扩展,因为他们不在一个节点上,分别用不同数量的节点去承载它们的这些服务。
( AMQP 是一种协议,OpenStack 没有规定它是用什么实现,我们经常使用的是 Private MQ,实际上用户也可以根据自身的情况选择其它的消息中间件。)
基于SQL的通信
通过数据库连接实现通信,这些通信大多也属于各个项目内部,也不要求数据库和项目其它组件安装在同一个节点上,它也可以分开安装,还可以专门部署数据库服务器, 把数据库服务放到上面,之间通过基于 SQL 的这些连接来进行通信。OpenStack 没有规定必须使用哪种数据库,虽然通常用的是 MySQL
通过Native API实现通信
出现在 OpenStack 各组件和第三方的软硬件之间,比如说,Cinder 和存储后端之间的通信,Neutron 的 agent 或者说插件和网络设备之间的通信, 这些通信都需要调用第三方的设备或第三方软件的 API,我们称为它们为 Native API,那么这个就是我们前面说的基于第三方 API 的通信。

回复2:我们知道对Openstack的各个组件(nova,cinder,neutron等)来说,跨组件交互时使用的是RestAPI相互调用公共接口,组件内部各个进程间通信时使用RPC消息通信,从而实现各组件、各进程之间的解耦。Openstack RPC(Remote Producer Call)机制基于AMQP(Advanced Message Queuing Protocol)协议,搭配各种消息服务器(RabbitMQ,Qpid等)实现各个组件内部进程间的消息传递。
AMQP*
AMQP是一个提供统一消息服务的应用层标准协议,基于此协议的客户端与消息中间件可传递消息,并不受客户端/中间件不同产品、不同开发语言等条件的限制,实现异步通信。
RPC.call:发送请求到消息队列,等待返回最终结果。
RPC.cast:发送请求到消息队列,不需要等待最终返回的结果。
在AMQP模型中,几个主要功能模块连接成一个处理链完成预期的功能:

Publisher:消息发送者,将消息发送到 Exchange。
Message:由Header和Body组成,Header是由Publisher添加的各种属性的集合,包括Message是否被持久化、由哪个Message Queue接受(Routing Key)、优先级是多少等。而Body是真正需要传输的数据,它是对Server不可见的二进制数据流,在传输过程中不受影响……
Exchange:接收发布应用程序发送的消息,并根据Routing Key和Binding信息、Exchange Type等参数将这些消息路由到消息队列。
Binding:关联Exchange和Message Queue,提供路由规则。
Message Queue:存储消息,直到这些消息被消费者安全处理完为止。
Consumer:**消息接受者,从 Message Queue 获取消息。

使用这个模型我们可以很容易的模拟出存储转发队列和主题订阅这些典型的消息中间件概念。

AMQP是非对称的,客户端生产和消费消息,服务器存储和路由这些消息。一个AMQP服务器类似于邮件服务器,Exchange类似于消息传输代理(email里的概念),Message Queue类似于邮箱。Binding定义了每一个传输代理中的消息路由表,发布者将消息发给特定的传输代理,然后传输代理将这些消息路由到邮箱中,消费者从这些邮箱中取出消息。

AMQP模型中不同类型的Exchange对应不同的routing算法:
Direct Exchange:Point-to-Point 消息模式,Direct Exchange 根据 Routing Key 进行精确匹配,只有对应的 Message Queue 会接收到消息。
Topic Exchange:Publish-Subscribe(Pub-sub)消息模式,Topic Exchange 根据 Routing Key 进行模式匹配,只要符合模式匹配的 Message Queue 都会收到消息。
Fanout Exchange:广播消息模式,Fanout Exchange 将消息转发到所有绑定的 Message Queue。

回复3:楼上的兄弟回答的很全面了,但问的是内部组件,我只摘录一段
rabbitmq是openstack的内部默认队列 ,非常关键,一旦阻塞或宕了,整体openstack就会全跨。原生的没有高可用,但如果真上生产,一定要要配置高可用

基于高级消息队列协议
基于 AMQP 协议进行的通信,主要是每个项目内部各个组件之间的通信,比方说 Nova 的 Nova Compute 和 Scheduler 之间,然后 Cinder 的 Scheduler 和 Cinder Volume之间。

需要说明的是,Cinder 是从 Nova Volume 演化出来的,所以 Cinder 和 Nova 之间也有通过 AMQP 协议的通信关系,由于 AMQP 协议进行通信也属于面向服务的架构, 虽然大部分通过 AMQP 协议进行通信的组件属于同一个项目,但是并不要求它们安装在同一个节点上,给系统的横向扩展带来了很大的好处,可以对其中的各个组件分别按照他们负载的情况进行横向扩展,因为他们不在一个节点上,分别用不同数量的节点去承载它们的这些服务。

( AMQP 是一种协议,OpenStack 没有规定它是用什么实现,我们经常使用的是 Private MQ,实际上用户也可以根据自身的情况选择其它的消息中间件。)

十一、同城双活数据中心机房如何规划使用openstack产品?

商用openstack产品时,对不同同城双活中心机房,如何进行纳管vmware的 vcenter,对纳管同城双活机房的Laas层的资源,架构如何规划,在实施过程中,请专家们在有这方便的多介绍一下经验,进而让大家尽量避免少跳坑,进而提高业务的连续性。

回复1:同城的双数据中心和异地中心通过专线互联,搭建大二层网络,并实现数据中心业务数据二层网络的联通,真正意义的实现了计算、存储、网络资源的统一管理统一调度。配合业务应用的高可用设计,可以实现同城双活数据中心中有一个出现故障,可以由另一个中心无缝接替业务,业务连续运行,用户使用无感知。而如果出现重大事故,同城的两个双活中心都出现故障,异地的灾备中心可以分钟级启动并承载业务,从而最大限度保障业务连续性。
OpenStack采用multi-region方式,将平台可以部署在3个数据中心,其中两个为同城双活数据中心实现业务无缝切换,和一个为异地容灾中心,实现在同城的主数据中心出现重大故障的情况下,分钟级业务切换。同时3个数据中心采用统一接口对接上层云资源管理平台,集中化的认证keystone。各个数据中心的基础资源有独立调度平台。

回复2:个人想法,
商用openstack这里 只了解华为, 目前以华为来描述下面方案
每个数据中心部署 openstack云平台(虚拟化平台)区域, 统一由上层云管理平台完成那管,
vmware区域由openstack的 wmware的纳管接口完成纳管,
资源规划需要详细调研你的业务云化需求,
具体
方案参考 vmware的一个虚拟化资源池 由48个服务器构成, 每16个服务器一个机柜, 内部部署vc等关联系统, 接入传统网络环境,IP地址等按照稳态计算环境部署(传统虚拟化环境)
openstack一个虚拟化资源池区域 15台服务器组成一个区域, 3个控制节点,其他是计算节点,接入硬件SDN构成租户方式的云化虚拟化环境,通过弹性ip和外部系统完成互联.
两个底层虚拟化技术通过云管理平台完成互联互动,对SDN进行集成(创建vmware系统的vm后,调用sdn接口完成网络配置下发)
要求实现
双活需要每个数据中心部署对应的虚拟化池, 上层统一管理, 对vmware资源池要提前规划好所需资源包括IP地址,网络vlan,存储空间等, 尤其网络部分需要完整规划避免日后有过多变更
openstack由于云化管理为敏态技术,sdn 加持可通过接口后期定义完成网络变化.
双活的核心业务系统需要安装业务需求完成规划部署, 在两个数据中心实现双活运行,
先规划好基础的云架构, 然后挑选一个业务系统进行测试部署,测试成功后可推广实施.
对于不适用的稳态业务系统, 目前还是应按照稳态技术进行部署在vmware中。

十二、Openstack刚填好坑,更新版本后又要填坑,如何才能高效的运维,避免踩坑?

Openstack的坑是超多的,有的同学说不惧怕填坑,我要说等你填完,半年时间又上一个新版本,难道你继续填坑?如何才能高效的运维,避免踩坑?听听大家日常运维经验!

回复1:无法,因为软件的更新迭代太快了,你看现在大家学习都不去书店了,为什么能,一方面是因为电子书,但更重要的原因是软件更新太快,写书的都写不过来了,写好书,可能写书的版本就被淘汰了,所以,现代IT学习都靠原版的document。 所以,你要“高效运维”, 除非你不改版本。
(1) 选用成熟开源软件,github上star低于200的,坚决不碰;
(2) 选用LTS版本,稳定版;
(3) 不追逐潮流,基本上2年内,不更新版本。

回复2:简单来说的话:
1.有开发能力的单位是不惧怕的,但是运维成本超高;
2.没有开发能力的,建议使用成熟的商业套件;
3.无论开源还是商用,必须要做好架构的高可用和存储的高可用。

十三、怎样将数据中心现有的物理机和虚拟机平滑的迁移到云平台上?风险和工作量怎样评估?成熟的产品怎样选型?

回复1:传统行业上云痛点分析
传统企业上云会有一些痛点,大致分为以下几个层面。
用户体验方面的考虑。可能因为业务过去的包袱太重,导致他们迁移上云会涉及到部分代码层面的修改、打包、重发布、应用管理方式等变化,这会有一定技术门槛,使得迁移上云有一定难度。比如企业软件上云,过去企业的开发人员都是使用传统的开发模型和开发工具做开发,而在云上,很多应用的开发直接就是基于云原生应用架构进行开发的用户体验。这就好比一个使用 WindowsXP 的用户,突然要他去马上适应 Windows10——过程类似,体验不同。在云上,开发工具和开发理念不同,云原生应用开发会将应用的每个部分都打包在自己的容器中,动态编排,以便每个部分都被主动调度和管理,以优化资源利用率和面向微服务的应用程序,从而提高应用程序的整体灵活性和可维护性。如此便捷轻度的开发体验,是原来传统的开发模式所无法达到的。当然,云原生应用给拥有多年传统企业开发经验的开发人员也带来不少的学习成本,在一定程度上打破了他们固有的开发习惯和开发方式,这对于企业业务软件上云,也带来了不少的门槛。我相信,随着整个行业不断的发展,企业的 IT 管理人员、开发人员,能够有更多机会体验到新技术带来的效率提升、应用开发更灵活,大家慢慢用起来,这种现状就可以得到改善。
数据安全方面的考虑。比如说他可能担心数据放在公有云上数据本身是否安全?数据的请求与控制、访问与授权,数据防泄露等安全谁来保障?其实客户的疑问是可以理解的,当然,公有云厂商也提供了诸多的技术保障了数据安全,比如说我们客户的核心业务系统,他的数据要放到云上去做灾备,就涉及到很多技术,比如使用加密技术传输数据。使用密钥技术来加密数据,数据的访问需要客户自主的、多因素的认证,即便是公有云厂商,自已后端的 IT 管理人员,他也没有办法看你的数据。另外,云上数据可以在多个不同区域间进行多副本存储,避免了单一云区域离线后,数据无法请求的问题,在我看来,云上数据安全是有保障的。只不过,用户可能始终会有一种感受,好像数据不在自己家里心里不踏实的那种感受,随着越来越多的用户接入云,大家也在适应云计算技术优势,慢慢相互建立信任的过程。
历史包袱方面的考虑。比如有一些用户过去筹建自己的业务系统,都是烟囱式或者叫孤岛式的。今天我要上一个 XX 应用系统,找一个厂商过来,好,系统上线;到了明天,我又上一个系统……慢慢,系统越来越多,但是,这些个系统之间没有去把数据全部打通,业务流程流转仅限于几个主流的企业应用,长期下来,你会发现一个大的企业里面可能有上百个小业务系统,其中打通的只有那么几个。这时候因为前期孤岛式的业务筹建方式,如果要上云的话,就需要花大量的时间去梳理不同业务逻辑间的关联性、前端和后端的关系,或者是说,从上帝视角来看这些业务如何重新进行顶层设计,这是很多企业面临的的痛点。所以,公司的业务如何在一个全面,有一定高度的方向和基于新平台正确的应用架构设计方式去做设计,是非常重要的。
关于企业上云,虽然有痛点,但办法总比问题多,我们也有非常优秀的云厂在提供好的平台和技术来解决这些问题,也有类似我们这样的云服务合作伙伴一直在努力帮助客户去消除这些痛点,前方一片光明,我们都在路上。

传统企业数据中心向云数据中心迁移的优势
传统企业的数据中心,都是标准化的三层架构(主机层、网络层、存储层)。这种架构经过多年的企业业务的检验,其实也是较为稳定可靠的架构。当然,这是相对于过去的情况而言,因为过去企业的业务可能只是企业内部,在大部分的情况下,访问人数不多。不过仍然有一些大型集团公司的业务会面临并发访问的压力。例如,在某个工作时间,所有人都要去访问 OA 系统查看内部公文、收发电子邮件等。
在传统架构下,比如 X86 的服务器,作为一个计算资源,有节点内部的瓶颈,南桥与北桥的交互,CPU 与内存的交互,磁盘 IO 性能的吞吐。也有节点外部的瓶颈,比如服务器速度很快,但网络如果是千 M 或者是万 M,数据交互经过一层层网络设备中转,有大量的延迟响应;比如你网络是 25G 或者是 100G 快速网络,但你的存储机头是有性能极限的,如存储机头的 CPU、内存、IO 控制器、存储缓存高低等,都会成为传统三层架构中,出现木桶原理中的那个短板……
说到底,传统数据中心的设计,并非是为大规模高并发的应用场景去设计的,很难承载较大的并发访问压力。
例如,云计算中心的后台,X86 架构的计算能力,从主机层面开始就是定制的机器,并非市面通用的 X86 2U 或者是 4U 服务器。这种云计算后端的主机通过一切可能的定制,优化减少各类接口和提高总线间访问速度,精简流转过程,提高数据端到端的交互速度,通过融合架构的方式实现分布式计算、存储等。
大量分布式软件定义的技术,实现网络的高速通道,存储亦是直接就是分布式存储管理系统、分布式文件系统、分布式调度系统等,专为密集型高并发业务场景而设计,并起到很好的集约化效益,为企业用户节省成本。
通过将企业线下数据中心与云上数据中心打通,实现业务数据级灾备或者是应用级双活,可以更灵活的实现业务的多重保护。
而基于云计算构建的云上数据中心,显然有更多的优势凸现。

回复2:首先要有一个正确的理解,你要迁移不是几个虚机和物理机,而是一个或者多个应用系统。这样这个问题就回到正轨了。
1、应用系统上云,先要对应用系统对一个评估,看是否具备上云的条件,比如应用的架构,是单体架构还是分布式架构,应用运行环境,小机还是X86还是虚机,应用的资源占用情况,应用对资源是否有特殊需求,比如机密狗或者特殊硬件等等,需要对应用性能做一个周期型监测和评估;
2、如果是小机势必会涉及应用改造的问题,需要跟应用开发商沟通,评估代码迁移改造的可行性和对性能的需求,然后再进行迁移上云;
3、如果是物理机,则需求对应用系统的性能需求进行评估,一般一台物理机需要折算成若干台虚拟机的算力,在云环境里面需要做一个架构设计,需要SLB等组件的配合,还有评估应用系统是否支持无状态部署,如果不支持,也得做无状态的改造;
4、如果虚机,需要评估原系统虚拟机镜像的直接迁移的可行性,是否兼容等等
5、至于具体如何进行迁移的实施,又得分若干情况,如果应用可以停机迁移,那是做踏实的,直接做就行了,如果非得在线热迁移,那就比较麻烦,只能用工具。
6、一般来说,如果是公有云,或者主流大厂的云平台,他们都有原厂的迁移工具,可以很好的利用,第三方的比如英方,也提供第三方迁移热迁移工具,都可以试试。
保险起见,建议找一个提供msp服务的云服务商去帮你做这些工作。

十四、openstack如何与Kubernetes做整合?

回复1: vmware + Kubernetes = PKS, 可以做私有云的商业化部署;
openstack也有自己的组件marathon来对接docker容器,不过,方向错了,应该去对接Kubernetes,结果却是docker。

所以,要把openstack和Kubernetes整合,只能由openstack构建虚机Iaas,Kubernetes在虚机实例上建立集群。但很不稳定,因为openstack不稳定啊。 所以,现在都是由公有云厂商,对openstack的改进后,再和Kubernetes整合; 分为全托管(只管用集群)+半托管(master节点不管)+自建三种模式.

回复2:openstack与k8s关注的层面不一样, OpenStack关注IaaS资源以及管理,K8S专注容器,没必要整合在一起吧。

回复3:这是两种不同的技术,同时是两种不同的虚拟化层面。openstack关注IAAS,k8关注的是容器。两者可以独立使用,也可以融合使用。

十五、OpenStack虚拟机、裸金属的OS agent应该如何统一嵌入?

在构建基于OpenStack的云解决方案,虚拟机、裸金属往往需要使用一个带内agent帮助其中的监控、管理(如修改密码)能力补齐。但在虚拟机、裸金属两种典型不同的计算实例场景下,如何做到其统一嵌入agent是一个比较难的问题,涉及几个点:
1.虚拟机、裸金属镜像统一是各云特别是公有云积极尝试的点,如果裸金属、虚拟机各自嵌入的agent不同,那镜像统一难度又将变大;
2.按照OpenStack已有的虚拟机方案,其默认使用的qga使用虚拟机的VirtIO serial保证平台与agent通讯的,裸金属目前没有此方案,且在裸金属之上实现虚拟的VirtIO serial难度也较大;
以上,抛出这个问题,暂不了解AWS、阿里云为代表的公有云都是如何实现的,如有大神了解,请帮忙介绍下。

回复1:qga是通过compute节点socket与虚拟机serial隧道建立通信的,这种方案只适用于虚拟机,裸机无法支持。
目前OpenStack好像还没有统一的OS agent可以同时适用虚拟机和裸机,可以参考trove guest agent自己写一个应用层agent实现如监控、修改密码等功能。
AWS也是通过应用agent进行监控和管理的,可以参考ssm-agent。

回复2:据我所知,这两个方案是独立的。
1.虚拟机是使用qga来监控虚拟机的,不适合裸金融的使用;
2.其他的平台,如阿里、腾讯等用的是自开产品;
3.建议在openstack环境内部署saltstack等类似的运维自动化软件,便于监控和维护。

回复3:裸机云计算服务综合了物理服务器和公共云两者的优点,但是这可能并不适用于所有的工作负载。用户在做出决定之前应权衡利弊。
在某些情况下,公共云服务无法为管理员提供全面的可见性和控制权,特别是在可变工作负载运行性能和安全性方面尤是如此。一些供应商通过提供裸机云来解决这一挑战。
何为裸机云服务?
裸机云服务是基础设施即服务(IaaS)的一个变体,它可允许用户租用和配置单租户服务器(通常没有虚拟化层)。裸机云可同时提供公共云的灵活性与可扩展性,以及本地服务器的可预测性、精细粒度以及安全性。
并不是所有的工作负载都能够在构成众多IaaS产品的虚拟化云实例中正常运行的。例如,需要访问物理硬件的原有应用程序或特别需要稳定性而不需要可扩展性的工作负载可能就更适合裸机云。
裸机云服务与其他云服务类似——用户可使用亚马逊网络服务(AWS)弹性计算云(EC2)实例或Azure D系列虚拟机对其进行访问。它与裸机的主要差别在于该服务映射至一台物理服务器而非虚拟机。
由于服务器很少被虚拟化,用户可获得直接访问整台服务器及其所有计算、存储和网络资源的全部权限。裸机云实例与传统服务器几乎是一样的,但前者通常使用了与公共云供应商所采用相同的按需租赁模式。
在裸机云市场上有着众多的供应商,其中包括甲骨文、IBM、baremetalcloud、Rackspace以及Internap等。 包括Azure和谷歌在内的主流公共云供应商都没有提供强大的裸机云产品。AWS推出的专用EC2主机服务是与其最接近的一款产品,它为用户提供了一整台物理服务器。
裸机云服务的优缺点?
裸机云服务的最显著优点就是用户能够直接控制服务器及其资源。这一点远不同于典型的虚拟化云实例,后者会有意识地对用户掩盖底层硬件操作。此外,由于没有虚拟化层,裸机云减少了管理程序的开销,从而提高了系统整体运行性能。
因为大多数的公共IaaS环境都是多租户的,所以企业用户们都非常关注安全性和合规性问题。裸机云实例解决了这两个问题,因为他们提供了一个专供单个用户使用的单租户硬件平台。但是,裸机云并不保证安全性或合规性; 企业用户们需要了解正确安全与监管态度的相关法律条文和行业最佳做法。
与公共云实例相比,裸机云实例具有更高的成本效益,因为用户通常仅为底层硬件而非使用支付费用。但是,企业用户们必须考虑成本问题,并将其与内部硬件采购、部署以及运营总费用进行比较。
但是,与虚拟化实例相比,裸机云服务可能具有一定的局限性。例如,当一台物理服务器被虚拟化,管理人员可以由低层硬件提供广泛的标准化虚拟机类型。但是因为裸机云实例是一台完整的服务器,所以其可用实例大小与类型的数量都是有限的。
是什么让裸机云管理变得独一无二?
就裸机云实例与典型虚拟机公共云实例两者来说,他们的管理之间是几乎没有根本性的区别。
例如,裸机云供应商们(如Rackspace和甲骨文等公司)提供了管理界面,其中包括控制台和命令行界面。Rackspace所提供的控制面板采用了一个基于Web的界面来启动云服务器、访问和查看KPI,安排诸如快照和访问支持功能等服务。管理员们可以使用控制面板来执行某些任务,如服务器重启等,这些任务对于常见的虚拟机实例来说是不可想象的。 但是,裸机服务器通常需要比常见云实例更精细的管理与控制级别。
例如,甲骨文公司将裸机云服务纳入隔离专区的实体中,它可提供与其他业务单元或项目相互隔离的云实例。这意味着用户可以根据活动或组别来监视、管理和跟踪资源的计费,并且为每个用户分配精细的安全与数据保护特征。
熟悉基于虚拟机的公共云管理的管理人员可能需要为建立和管理裸机云环境学习一些额外的知识。
裸机云是否是高级别服务的更好选择?
当工作负载的计算需求由于缺乏可扩展性要求而相对较稳定时,裸机云服务可能是一个很好的选择。适合这一模式的工作负载应用包括大数据分析、周期性备份与恢复、媒体编码任务、机器学习、可视化渲染项目以及其他I/O密集型应用程序。
例如,一个大数据应用的工作负载需要采集、转换和处理大量数据,然后将处理结果传回存储设备。
一旦完成任务,该服务器可能会持续数周或数月时间保持等待使用状态。这就使得裸机云成为了一个极具可行性的选项,用户可以不必采购并永久性拥有该服务器。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

7

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广