企业云计算基础设施解决方案构建指南

更新:11-14 名人轶事 我要投稿 纠错 投诉

大家好,今天来为大家分享企业云计算基础设施解决方案构建指南的一些知识点,和的问题解析,大家要是都明白,那么可以忽略,如果不太清楚的话可以看看本篇文章,相信很大概率可以解决您的问题,接下来我们就一起来看看吧!

在详细介绍之前,我们先来看看传统的IT建设方式是什么样的。我们用一个应用场景来说明:在企业内部,或多或少需要一些基础设施资源,包括计算资源、存储资源、网络资源。传统的做法是经过服务器选型、服务器采购、数据中心选型、服务器上线、网络建设等一系列流程后,组建系统团队,完成资源交付。整个过程比较漫长,需要较多的人力。对于初创公司或者中小企业来说,基础设施资源的建设是必要但不划算的投资。本来公司很小,人也不多。公司内部的人员应该更多地专注于自己的业务,基础设施资源的建设还不够。应该会花费公司更多的人力、物力。

与传统的IT建设方式不同,IaaS(基础设施即服务)作为一种新的基础设施资源获取方式而应运而生,即将服务器的基础资源以服务的形式提供给大家通过互联网租用和获取。假设一个企业打算搭建自己的服务,原本需要购买一堆服务器、网络带宽等,但现在可以通过IaaS服务商租用虚拟机,以及这些所需的存储资源和网络资源。虚拟机可以随时按需分配。这样可以节省大量的人力、物力。一般IaaS厂商会比个体企业拥有更大的服务器规模,在资源管理上也会更加专业。因此,无论是服务质量还是投资成本都比企业自建的更加优化。

一般来说,IaaS服务可以分为公共IaaS和私有IaaS。公共IaaS又称公有云,规模大、服务相对全面。它通过租赁方式向公众提供。 AWS、金山云、阿里云、腾讯云都是知名的IaaS服务提供商。私有IaaS也称为私有云,是在公司内部建立的,将服务器资源转变为服务并提供给公司内部的各个部门。这大大提高了资源分配的灵活性,缩短了资源交付周期。与公有云相比,安全可控性更高。 IaaS服务可以有效提高资源利用率,降低服务提供成本。由于企业内部私有云的建设更有价值,所以后面我们会重点介绍私有云的建设过程,以及使用过程中遇到的问题和解决方案。

IaaS平台选择

之前我们介绍过什么是IaaS。这里我们讨论IaaS形式之一的——私有云的构建过程。近年来,私有云建设吸引了众多国内外企业的关注和参与。阿里巴巴、腾讯、百度等都建立了自己的私有云平台。建立方式主要有两种:一是基于开源虚拟机计算平台,开发自己的云计算管理和分发平台;二是建立自己的云计算管理和分发平台。另一种是完全使用开源云技术解决方案,例如OpenStack,设计自己的私有云。平台。两种方法都有各自的优点和缺点。第一种方式采用自主开发,可控性好,对代码和功能完全掌控,更方便问题追踪。但开发周期长、建设速度慢,难以在短时间内完成项目。系统内实现完整的私有云平台;第二种方法使用开源云技术解决方案,可以在短时间内构建一个完整的私有云平台,但需要完全熟悉和掌握您所使用的开源软件。有一定的学习成本。随着开源软件变得越来越复杂,有时很难控制平台。采用哪种方式主要取决于公司的规模以及对私有云人力的投入。大公司人力充足,对私有云定制需求较大,对平台控制力要求较高,可以自行开发。小公司只想使用私有云方便自己的资源管理和分配,不需要对私有云进行过多的定制,所以选择开源的私有云解决方案是一个非常好的选择。后续内容主要讨论开源私有云解决方案的选择和建立过程。

OpenStack

OpenStack是一个非常流行的开源云计算平台。它获得Apache许可,提供计算资源、存储资源和网络资源的分配和管理。它是AWS服务的开源解决方案。它最初由NASA 和RackSpace 联合发起,目前由OpenStack 基金会管理和维护。 ATT、Dell、Intel、RedHat等200多家公司参与了该项目。

OpenStack的发展和更新非常快。从成立到现在,一直保持着每六个月一个版本的发布周期。在产品规划周期内,定期召开峰会,确定开发需求和方向。该操作系统还对OpenStack 有非常密切的支持。目前,Ubuntu和RedHat都对OpenStack有很好的支持。 OpenStack 是用Python 编写的。不同的功能分为不同的模块。这些模块是松散耦合的,并使用队列进行异步通信。 OpenStack拥有非常完善的功能,非常活跃的社区,以及众多支持和参与的厂商。这些都是它的优点。但缺点也非常明显,比如学习成本较高、稳定性差等。

OpenNebula

OpenNebula起源于2005年的一个研究项目,2008年3月发布第一个版本,现已发展成为流行的开源云软件,并得到了大量用户的参与和支持。 OpenNebula的目标是将一组物理集群转换为弹性虚拟基础设施设备,可以动态调整以适应服务器工作负载的变化。 OpenNebula作为服务器设备和应用程序之间的一个新的虚拟层,使服务器的使用效率得到极大的优化。目前OpenNebula支持Xen和KVM,更重要的是,它还支持EC2管理。 OpenNebula可以构建私有云和公有云,还提供Deltacloud适配器与Amazon EC2配合管理混合云。由于OpenNebula起源较早,并且由于该项目更侧重于学术研究,因此OpenNebula具有许多创新功能,其中许多功能已经应用于生产实践。鉴于其项目性质的特点,稳定性稍差,企业和社区的支持也较小。

CloudStack

CloudStack始于Cloud.com,其目标是使服务提供商和企业能够创建具有类似于亚马逊运营能力的公共云和私有云。 2010年,Cloud.com提供了基于GPLv3的社区版本供用户免费下载,随后发布了两个支持版本。 Citrix 于2011 年7 月收购了Cloud.com。Citrix 是OpenStack 社区的早期成员,但在2012 年决定离开社区。据媒体报道,做出这一决定是因为Citrix 认为Cloud.com 最初提供的代码更有价值。比OpenStack稳定,可以为用户提供更多功能。

CloudStack是一个开源云计算平台,具有高可用性和可扩展性,支持大多数主流Hypervisor的管理,如KVM、VMware、Oracle VM、Xen等。同时,CloudStack是一个开源云计算解决方案,可以加速高度可扩展的公共云和私有云(IaaS) 的部署、管理和配置。以CloudStack为基础,数据中心运营商可以快速、便捷地提供云存储服务和弹性云计算服务。 CloudStack采用Java编写,设计更加简单稳定。但在用户和社区支持方面,却比OpenStack差很多。

IaaS开源软件选择

上面介绍了三种IaaS平台,各有各的优缺点。图1为三者近年来的Google趋势图,其中蓝线代表OpenStack,红线代表CloudStack,黄线代表OpenNebula。从趋势来看,OpenNebula起源最早,但并未受到太多关注; CloudStack自2012年起就超过OpenNebula,排名第二; OpenStack自诞生以来就非常受欢迎,目前排名第一。

我们已经介绍了三个IaaS平台,是时候做出决定了。对于开源软件的选择,我们认为应遵循以下原则。

功能齐全:所需功能必须齐全,这是选型的前提。系统稳定性:由于该服务对系统稳定性要求较高,任何不稳定的软件都会给后续维护带来很大困难。广泛使用:我相信每个人的愿景,至少你不会因为和别人做同样的选择而受苦。社区支持:有了良好的社区支持,即使出现问题,也可以通过社区的力量轻松解决。图1 IaaS软件对比趋势图从以上几点来看,OpenStack在这些候选软件中综合指标最好。因此,使用OpenStack构建IaaS平台是一个更好的选择。后续将详细介绍基于OpenStack的IaaS平台的搭建过程。

IaaS平台建设

我们已经介绍了使用OpenStack构建IaaS平台的选择。在使用OpenStack构建IaaS平台时,我们首先需要明确自己的需求。我们为公司搭建一个IaaS平台,主要是为了满足公司内部服务器虚拟资源的使用,作为私有云平台。通过收集公司私有云平台需求,总结包括以下几点。

提供灵活高效的计算资源池,缩短机器交付周期。完善稳定、高可用的服务,支撑公司线上线下业务。它在网络连接方面与现有服务无缝集成,使用体验与物理机没有明显差异。有效管理虚拟机生命周期,有效管理虚拟机资产。以上四个需求是大多数企业构建云平台的首要需求。第一个需求是云平台的固有特性,不需要特别关注;第二点是提供高可用服务。鉴于OpenStack目前的稳定性,要提供企业级的高可用服务还需要做很多工作;第三点主要体现在网络方面,要求私有云网络与现有业务网络高效互通。另外,性能上与物理机相差也不大。第四点主要是与现有业务系统、管理系统的衔接。这个和每个企业的资产管理体系有关,这里就不详细说了。接下来我们就根据上述需求来了解整个私有云环境的搭建流程。

架构设计

在私有云建设过程中,OpenStack架构设计是非常重要的一环。由于OpenStack有相当多的组件,因此构建时会有不同的架构。考虑到之前收集到的需求,高可用是一个比较重要的需求,所以需要设计一个高可用的架构。 OpenStack提供的私有云服务主要分为计算、存储、网络、管理四类资源。对于每种资源,我们必须评估其高可用性。

计算资源主要由KVM、Xen等虚拟机提供。虚拟机技术在业界已经应用多年。这是一个相对成熟的解决方案,稳定性不再是问题。

存储资源分为本地磁盘和共享存储两种。本地磁盘的稳定性是由硬件的稳定性来保证的。一般来说,RAID等本地磁盘可以满足大多数应用的稳定性需求。如果您的应用程序需要更高的稳定性,可以考虑使用共享存储。 OpenStack的共享存储主要分为GlusterFS和Ceph,两者都保证了数据的高可用性。我们已经测试了GlusterFS和Ceph,但由于某些原因,我们最终投入了Ceph的怀抱。

网络资源是OpenStack私有云最重要的组成部分,决定着整个私有云的成败。必须选择高效、稳定的模型。 OpenStack提供了Flat/FlatDHCP、GRE、VLAN等多种网络模型。相比之下,VLAN模型最适合企业级需求。具体原因稍后详述。

鉴于目前OpenStack的稳定性还不够高,我们无法保证在大规模应用中,OpenStack出现问题不会导致整个云服务宕机。那么我们在架构设计上就必须保证任何一个OpenStack服务的故障都不会影响云服务的稳定性。基于以上考虑,我们的私有云架构如图2所示。

以上结构是根据公司需求并结合公司业务定制的。

首先,OpenStack控制节点的故障不会影响虚拟机的正常使用。由于虚拟机只通过OpenvSwitch访问互联网,直接通过物理路由器进行路由,与控制节点无关,但无法管理虚拟机。如果出现短期宕机,则无需切换到备机,只需等待主节点启动即可。如果主控节点长时间失效,也可以启用备份控制节点。

图2 私有云架构图其次,计算节点不存在单点,计算节点之间互不依赖。单个计算节点的故障只会影响该节点的虚拟机。虚拟机可以使用本地磁盘和共享云存储的组合。本地磁盘可以提高虚拟机磁盘的性能,减少网络带宽消耗,但有一定的故障率(取决于系统硬件的故障率),适合运行。系统和其他非业务数据。如果是业务数据,为了提高数据可用性,还可以通过存储网络获取共享存储资源。对于使用共享存储的虚拟机,当主机出现故障时,可以通过热迁移或重新挂载的方式快速恢复虚拟机。

最后,虚拟机通过OpenvSwitch接入互联网,并直接连接到硬件交换机。无需通过L3 Agent等方式连接网络,避免了OpenStack L3 Agent不稳定的问题。不仅可以与现有业务接入无缝对接,还可以提升虚拟机网络的性能。高效、稳定,使得虚拟机网络的稳定性与其他物理机网络处于同一水平。

网络设计

基于OpenStack的私有云建设中最复杂的部分无疑是网络部分。前面我们提到OpenvSwitch是直接连接虚拟机网络中的交换机的。我们重点分析一下为什么要这样设计。 OpenStack中支持Flat/FlatDHCP、GRE、VLAN等多种模型。我们先来分析一下这些必要的网络模型。

(1)Flat/FlatDHCP

除了DHCP 功能外,Flat 和FlatDHCP 基本上没有太大区别。它们都属于扁平网络模型。所有虚拟机网络都处于一个大的二层环境中,不利于租户网络的隔离;由于共享段广播的存在,不利于在大规模网络中使用。

(2)GRE

一种网络隧道方式,通过OpenvSwitch GRE模块进行传输,在IP数据包上添加GRE头并重新封装。无需特殊的交换机配置即可实现租户网络之间的隔离,但GRE的性能不是很好。

(3)VLAN

OpenvSwitch用于在二层报文中添加相应的VLAN标签,实现租户网络隔离,获得更好的性能。但由于VLAN ID的最大数量为4096,因此网段数量只能限制为4096,需要对交换机进行相应配置。

Flat/FlatDHCP无法实现租户网络之间的隔离。同时,由于第二层IP地址数量的限制,不适合中型及以上私有云建设。 VLAN和GRE最大的区别就是性能差异,因此我们对VLAN和GRE的性能做了对比测试。我们在不同的主机上启动了两个虚拟机。主机使用10G网卡连接,CPU为Intel E5-2640。测试结果如表1所示。

表1 测试结果

网络模型吞吐量发送端CPU消耗(单核) 接收端CPU消耗(单核) VLAN9.5Gbps78%65%GRE2.5Gbps76%98% 从上面的测试结果可以看出,GRE的性能为不太好,同时会消耗大量CPU,无法达到10千兆网卡的极限;而VLAN的性能更好,可以轻松达到网卡的极限。在企业中,性能可能是需要追求到极致的东西,因此VLAN是大多数企业私有云的首选模式。

L3(Neutron L3 Agent)也是需要考虑的部分。到目前为止,OpenStack还没有提供高可靠性的L3解决方案。虽然可以采用多网络节点的部署方式,但这只是负载均衡方案,并不是高可用方案。直到最近的Juno版本,提供了基于Keepalived的HA解决方案,但这并不是一个完美的解决方案。我们将从以下三点来解释L3目前存在的问题。

首先,从我们的运营经验来看,OpenStack的L3 Agent本身还不够稳定。如果流量稍微大一点,就可能达到L3的性能瓶颈,甚至可能导致服务失败。

其次,多个网络节点可以解决负载均衡问题,但无法解决L3稳定性问题和节点故障问题。

第三,Juno版本基于Keepalived方案,依赖VIP和VRRP协议。理论上是可行的。但从我们的经验来看,在真实的网络环境中,VRRP并不是完全可信的,经常会出现高手的情况。来回切换的问题。由于上述问题无法解决,所以我们采用去掉L3的结构。图3是最终的网络方案图。

图3 私有云网络结构图网络结构图中,与原生OpenStack最大的区别是L3 Agent被禁用,由物理交换设备或路由器承担L3功能。比OpenStack软件的L3 Agent更加稳定、性能更高。有很大的提升,同时,不用再关注单一的问题点。如图3所示,控制节点提供Neutron-Server、DHCP等功能,通过eth0管理计算节点OVS-Agent,并控制OVS-Agent的VLAN ID映射规则的生成。虚拟机已连接到br-int。 br-int上已经制定了VLAN ID映射规则。 VLAN ID转换完成后,br-eth2通过eth2的Trunk模式连接到物理交换设备,并与其他网络连接。无需浮动IP即可实现与其他网络的互操作。

存储选型

存储选型是OpenStack私有云建设的重要组成部分。良好的存储选择可以大大提高系统的稳定性和数据的可用性。一般来说可以分为本地存储和网络存储两种方式。

本地存储使用本地磁盘作为虚拟机的存储磁盘。操作简单,不需要任何配置。它是OpenStack默认的存储方式。性能方面,由于磁盘是直接读取的,不需要通过网络等设备传输,所以性能更好,更适合作为系统盘使用。但由于本地存储数据的可靠性依赖于本地硬件,可靠性不高,因此用户需要自己做一些冗余备份。

网络存储使用一些分布式文件系统作为存储,并提供通过网络对OpenStack私有云的访问。分布式存储一般采用多副本冗余技术。当副本丢失时,系统会自动检测,并将副本复制到其他机器上,保证副本数量不小于设定的副本数量。因此,分布式存储在数据可用性方面远远优于本地存储。当网络条件较好、存储集群规模较大时,分布式存储一般可以提供较高的存储性能。

但由于分布式存储冗余较大,建设成本也会较高。在一些典型的云计算环境中,本地存储一般用作系统盘,以提高本地磁盘利用率并减少网络带宽占用,而数据盘则使用分布式存储来提供数据的高可用性。例如,AWS就是这样做的。当系统出现故障时,数据盘可以方便地挂载到其他机器上,几乎不影响数据的使用。

1.块存储

OpenStack支持的存储中,比较常用的是Ceph和GlusterFS。 GlusterFS是一个开源项目,后来被RedHat收购,但仍然提供免费版本。它是一个PB 级分布式文件系统。 GlusterFS的主要特点如下。

(1)高可用性

GlusterFS 可以自动复制文件,例如镜像或多副本,确保数据始终可访问,即使在硬件故障的情况下也是如此。自我修复将数据恢复到正确的状态,并且修复在后台增量执行,几乎没有性能负载。

(2) 无元数据

GlusterFS采用弹性Hash算法进行数据分发和搜索,抛弃了传统的元数据节点结构。数据采用镜像复制结构,消除单点故障和性能瓶颈,真正实现并行数据访问。

(3)接入方式

Gluster存储服务支持NFS、CIFS、HTTP、FTP和Gluster本机协议,并且完全兼容POSIX标准。现有应用程序无需进行任何修改或使用专用API 即可访问Gluster 中的数据,非常方便。

在GlusterFS 中,存在三种卷类型:分布式卷、复制卷和条带卷。分布式卷通常用于扩展存储能力,不支持数据冗余,除非底层砖使用了RAID等外部冗余措施。复制卷为GlusterFS 提供高可用性。创建卷时可以指定副本数量,当卷出现故障时可以自动同步和修复。分片卷将单个文件分成小块(块大小支持配置默认为128KB),然后将小块存储在不同的Brick上,以提高文件访问性能。

在分布式存储领域,Ceph 是一颗冉冉升起的新星。这是其创始人Sage Weil 在加州大学攻读博士期间的研究课题。随着云计算的兴起,OpenStack社区将Ceph作为其核心开源存储解决方案之一,推动了Ceph的快速发展。 Ceph之所以成为OpenStack官方存储组件,与其优秀的特性和良好的性能是分不开的。一般来说,Ceph 的设计目标是卓越的性能、可靠性和可扩展性,是一个统一的分布式存储系统。在Ceph中,它包括三个组件:OSD、MON和MDS。 OSD负责数据存储和管理,MON负责数据一致性维护,MDS负责CephFS元数据的管理。其主要特点如下。

(1)高可用性

Ceph采用多副本技术进行数据冗余,从而防止一份数据丢失导致整个数据失效,没有任何一个点。 Ceph MON 组件实时监控和管理数据冗余和一致性,以及检测和自动恢复所有故障。恢复不需要人工干预,恢复过程中可以保持正常的数据访问。

(2)分布式元数据

在Ceph中,元数据存储是可选的,只有在使用CephFS时才会引入元数据节点。 Ceph的数据访问采用CRUSH算法,与GlusterFS类似。数据访问可以通过算法定位地址,真正消除单点和性能瓶颈。 CephFS中的元数据采用分布式存储,数据定位也采用CRUSH算法。

(3)多种接入方式

Ceph提供了块设备存储(Ceph RBD)、文件系统存储(CephFS)和对象存储三种方式,为用户提供了更多的访问方式。块设备存储允许用户像物理原始磁盘一样使用Ceph块设备,提供良好的性能和良好的功能,例如设备快照。 CephFS提供了一种方便的挂载方法。用户可以使用Ceph客户端轻松挂载它。访问更方便,但会引入Ceph元数据节点。 Ceph对象存储与Swift一样,提供海量的对象存储空间,并且具有良好的性能。

Ceph和GlusterFS在设计理念和产品特性上有很大的相似之处。但作为OpenStack的存储组件,我们应该如何选择呢?事实上,作为云存储组件,GlusterFS和Ceph被很多公司使用。我们考虑使用Ceph主要有以下几个原因。

OpenStack社区主要推广Ceph。作为社区的主要组成部分,从未来的趋势来看,它将更加有前途和活力。 Ceph提供了多种存储形式,特别是对象存储,GlusterFS不支持。对象存储是云计算的核心组件。 Ceph 在OpenStack 中使用时更稳定(我们的观点)。 Ceph在使用磁盘作为虚拟机时几乎没有问题,而GlusterFS偶尔会出现网络超时导致文件系统设置为只读的情况。 2对象存储

在OpenStack中,Swift是对象存储的核心组件。 Swift 是一款高可用、完全对称、无单点、无限可扩展的对象存储软件。它最初是RackSpace开发的高可用分布式对象存储服务。它于2010年加入OpenStack开源社区,作为其原始核心子项目之一。 Swift 包括以下核心服务。

(1)代理服务器

负责处理每个客户端的请求并均匀分发到后端Storage Server。 Proxy 提供RESTful API,遵守标准HTTP 协议规范,允许开发者快速构建定制的Client 与Swift 交互。

(2)存储服务器

提供磁盘设备上的存储服务。 Swift 中有三种类型的存储服务器:Account、Container 和Object。容器服务器负责处理对象列表。容器服务器不知道对象存储在哪里。它只知道指定的Container中存储了哪些Object。该对象信息以SQlite数据库文件的形式存储。 Container服务器还做一些跟踪统计,例如Object的总数和Container的使用情况。

(3)一致性服务器

查找并解决由数据损坏和硬件故障引起的错误。他们将在后台持续扫描磁盘以检测对象、容器和帐户的完整性。如果发现数据损坏,他们将使用副本来修复数据。

从Swift的服务特性可以看出,Swift是一个分布式、无单点、自动容错的存储系统。因此,Swift的特点可以总结如下。

(1)高可用性

Swift采用多副本技术冗余,能够自动故障恢复和容错,提供极高的可用性。强一致性、容错性和完全对称的结构保证任何一个节点的故障都不会影响整个系统的可用性。

(2)可扩展性

Swift 的容量通过添加机器而线性增加。同时,由于Swift具有完全对称的结构,扩容时只需要简单添加新机器,系统就会自动完成数据迁移等任务,将各个存储节点恢复到平衡状态,完全不需要人工干预。

(3)无单点故障

Swift 的元数据存储是完全均匀、随机分布的,与对象文件存储一样,元数据会存储在多个副本中。在整个Swift集群中,没有一个角色是单点的。良好的结构和设计确保没有单点故障。

典型的Swift架构如图4所示,各个节点采用完全相同的软件结构,完全对称的结构。机器的管理和维护非常方便,无单点。

图4 Swift架构图虽然Swift是OpenStack最稳定的组件之一,但它也是

penStack社区推荐的对象存储组件,但我们在Swift使用过程中也遇到了一些问题。在使用过程中,作为存储Swift没有丢失过任何数据,作为OpenStack的Glance后端也完全能够胜任,但是如果作为其他目的使用,比如图片存储等服务,只要流量稍微一上来,Swift就必然遇到性能瓶颈,反应速度变慢,最后导致服务完全中断。因此,Swift对象存储不建议使用在流量较大的业务上。

通过前面的介绍我们知道,Ceph和GlusterFS大体的思想是差不多的,都是没有元数据节点的分布式存储,采用算法进行数据寻址,都是非常优秀的分布式文件系统。我们在使用GlusterFS作为虚拟机镜像时,经常会出现文件系统被写保护情况,非常影响虚拟机的使用。后续来我们换成了Ceph,在使用过程中,并没有出现明显的问题,因此推荐使用Ceph作为块存储。同时,Ceph的社区非常活跃,更新速度也非常快,相信在不久的将来,Ceph一定会变得更加稳定和成熟。另外,在对象存储方面,虽然OpenStack官方主推Swift,但是从笔者的惨痛经验来看,Swift的性能问题已经非常影响使用,因此Ceph的对象存储也是一种不错的选择。

服务器选型

私有云的架构和网络模型已经确定了,接下来我们将对硬件配置进行描述。控制节点需要运行MySQL服务和RabbitMQ服务,在稳定性上要求较高。同时,Glance服务也是运行在控制节点上的,由于Glance需要存储大量的镜像文件,因此也需要较大的存储空间。总地来说,控制节点需要稳定的大存储服务器。计算节点兼计算和本地存储两部分功能,计算性能和存储性能要求服务器性能比较均衡,网络节点由硬件路由设备担任,不需要网络节点。存储节点只需能够多挂载硬盘,使用普通存储性服务器即可。下面给出我们使用的硬件配置,如表2所示,供大家参考。 表2 硬件配置 节点类型机型系统版本数量CPU内存系统盘数据盘网卡控制节点DELL R620CentOS 6.4≥2Xeon E5-262016GB×4600GB SAS×2,10k转,RAID 1600GB SATA×6,RAID51Gb×2计算节点DELL R720CentOS6.4≥2Xeon E5-2640x216GB×24600GB SAS×2,RAID 12TB SATA×6,RAID 51Gb×2, 10Gb×2存储节点DELL R720XDCentOS6.4≥3Xeon E5-262016GB×4600GB SAS×2,RAID 12TB SATA×1210Gb×2

安装部署

由于OpenStack的组件较多,安装部署一直是OpenStack一个被诟病的问题。限于篇幅的原因,这里我们不再探讨每个组件该如何安装,只是简单地说明各种安装方式需要注意的问题。我们尝试过的安装方式有三种:Fuel安装、RDO安装和手动安装。以下是这三种安装方式的特点。 (1)Fuel安装 OpenStack的一键部署工具,由Mirantis公司提供,提供硬件自动发现机制。通过简单的Web界面操作,就可以将OpenStack连同操作系统一起部署完成。这是最简单的一种部署方式。 (2)RDO安装 RDO安装是使用PackStack安装部署工具,将OpenStack的RPM包安装部署并且完成配置的一种部署方式。整个过程只需配置一个PackStack的配置文件,部署较为方便。 (3)手动部署 使用Yum源,按照OpenStack官方部署文档,一步一步安装配置,安装比较麻烦,但是能够增进对OpenStack各组件的了解。 Fuel安装无疑是最简单的部署方式,作为初学者使用一个快速搭建的工具是一个不错的选择。但是Fuel作为一个整体会连操作系统一起安装,企业一般会有自己的长期使用的操作系统版本,同时会在此版本下做大量适合自己业务的定制和优化,因此,Fuel一般不适合已经成熟的企业用来部署私有云,而且若对OpenStack做了定制化修改,采用Fuel也不是一个太好的选择。 RDO部署相对Fuel来说复杂度略高,需要指定PackStack的配置文件,后续的过程也是自动化安装。有几个问题也是要注意的:第一,由于网络的问题,PackStack在安装的过程中有可能失败,需要反复重试。第二,部署完成以后,尽量不要手动修改集群配置,因为增加节点时,PackStack会再次检查配置,将修改的配置覆盖,可能造成不可预知的错误。第三,由于依赖Yum源,若集群扩容机器,前后时间相隔太长,Yum源上软件包可能已经更新,可能造成前后安装的小版本不一致,这可能导致软件版本不兼容问题。 手动安装是最复杂的一种方式,但也是最可控的一种方式。对操作系统和软件的依赖最小,只要在一个系统上正确完成一次安装,其他节点就可以大批量部署,效率极高。由于依赖Yum源,因此和RDO安装有相同的问题。为了解决Yum源更新问题,我们可以在第一次部署完成以后,就将Yum源同步到自己的机器上并且做成自己的Yum源,以后安装使用自己的源即可,速度快而且不易出错。因此,手动安装OpenStack是我们比较推荐的一种方式。

性能优化

虚拟化技术已经是一项非常成熟的技术,但是在使用虚拟机时,很多人还是持半信半疑的态度,质疑虚拟机的性能问题。当然,使用虚拟机,服务器的性能会有所降低,到底会降低多少,我们用测试数据说话。在测试之前,我们需要对虚拟机——KVM主机进行一系列调优,以便虚拟机的性能达到较好的发挥。 1.CPU调优 CPU绑定是提升虚拟机性能比较常用的方法,通过绑定VCPU,能够减少CPU Cache的失效,从而提高虚拟机的性能。但是目前OpenStack虚拟机VCPU绑定不能自动化,必须手动使用virsh对虚拟机CPU绑定。另外,为宿主机预留CPU资源,是一个非常不错的选择。预留一定数量的CPU资源,也能提高整体的计算性能,通过配置nova.conf的参数就可以做到,如下所示: vcpu_pin_set = 4-$ 为宿主机预留了4个核,保证了宿主机对虚拟机的正常调度。另外,通过配置NUMA属性,能够显著提升虚拟机性能,因为绑定在同一个CPU上的两个超线程核心性能低于不同CPU上的两个超线程核心,不过这个特性只有J版本才支持。 2.内存调优 宿主机上的多个虚拟机会存在大量相似的内存页,如果将这些相似的内存页进行合并,就能节省大量的内存,KVM中的KSM就是这种技术,开启后会节省虚拟机的内存使用,但是同时会带来一定的CPU消耗。考虑到宿主机一般内存比较宽裕,而CPU增加成本较高,建议关闭内存合并,如下所示: echo 0 >/sys/kernel/mm/ksm/pages_shared echo 0 >/sys/kernel/mm/ksm/pages_sharing 另外,采用Huge Page开启也能提升一定的性能,不过目前Nova不支持,只能通过修改源码,需要在Libvirt生成的配置中加入以下内容: 3.IO优化 在磁盘方面,通过改变磁盘的调度策略提高磁盘的效率,主要是将磁盘的调度方式改为Deadline,如下所示: echo dealine >/sys/block//queue/scheduler 另外,使用SR_IOV网卡虚拟化技术可以显著提高网卡性能,不过配置起来有点复杂,感兴趣的读者可以按照https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking自行配置。

性能测试

基本优化工作已经完成,下面对虚拟机性能做一个对比测试,测试对比机型配置如表3所示。 表3 测试对比机型配置 机器类型机器型号CPU核数内存磁盘网卡物理机SuperMicro 3U8E5-1230, 3.2G832GB500GB SATA1Gbps虚拟机KVME5-2640, 2.5G832GB500GB QCOW2(物理机2TB SATA)1Gbps为了避免虚拟机之间的竞争,影响测试结果,在物理主机上只运行了一个虚拟机。若有多个虚拟机,虚拟机性能必然下降,此测试的主要目的是测试出KVM Hypervisor带来的性能损耗,因此单个虚拟机就可以说明问题。首先,通过UnixBench测试系统的整体性能,如图5所示。 图5 UnixBench性能测试结果从测试结果可以看出,虚拟机大约相当于物理机5/6的性能。而且从参数上看,物理机的CPU主频更高。因此,KVM虚拟机能够达到物理机接近90%的性能。 接下来,我们使用iozone对磁盘的性能进行测试,如图6所示。 图6 磁盘性能测试结果从磁盘的性能测试结果来看,Reader和Re-reader的性能下降较多,下降20%左右;而Write和Re-Write性能下降较小,下降10%左右。 最后,我们对虚拟机的网络性能进行测试,分别采用小包和大包进行测试,如图7所示。 对于小包的测试,我们采用一个字节的文件,通过Web服务下载,最后吞吐量8Kbps左右,大约是物理主机的1/4,主要是受限于虚拟机网卡的PPS。对于大包的测试,使用一个320KB的文件,通过Web服务进行下载,虚拟机和物理机基本差不多,都能将网卡跑到800bps以上。 图7 网络性能测试结果总地来说,虚拟机的性能和物理机已经非常接近,CPU的性能达到物理机的90%,磁盘性能达到物理机的80%以上,网络性能在小包处理上较差。但是在现实应用中,存储小包的场景较少,虚拟机已经足够应付一些常规业务场景。若一定要追求较好的网络性能,则可以使用网卡虚拟机技术(SR-IOV),相信能够带来非常显著的提升。

IaaS平台运营心得

版本升级

版本升级是开源软件都会遇到的一个问题,OpenStack也同样遇到此问题。由于OpenStack组件很多,各组件之间相互关联,不同版本之间的组件可能存在兼容性问题,不同版本的数据表也存在差异性,因此,OpenStack的版本升级成本较高,需要慎重。OpenStack版本升级一般有以下两种原因。 Bug修复。对于此问题,首先应考虑能否直接采取Bug修复补丁,这种方法成本较小,最后才考虑版本升级。添加新功能。此种需求,首先应考虑新功能是否必需,有没有其他的代替方法,最后再考虑升级。建议的升级方法如下: 在新服务器上搭建新版本控制节点,然后将线上控制节点数据库导入到新控制节点上,检查数据库兼容问题,两个控制节点数据库配置密码最好保持一致,使用OpenStack-status查看各组件状态,如果状态正常,说明控件节点升级完成。计算节点升级可能会升级Libvirt,有可能会导致虚拟机重启,因此应先升级一台做测试。为了安全起见,必须先通知虚拟机使用者,告知服务维护期间可能发生重启。准备工作都做好了以后,升级安装Nova和Neturon等,将控制节点指向新控制节点,其他节点都按照此操作,OpenStack的升级完成。

宿主机维护

虚拟机都运行在宿主机上,OpenStack的宿主机维护也是必须面临的一个问题。宿主机的维护一般分为可预知的维护和不可预知的故障。 可预知的维护比较好处理,一般采用虚拟机迁移方式,OpenStack支持实时迁移和带磁盘迁移。如果使用了Ceph等共享存储的话,实时迁移是非常不错的选择,实时迁移的时间与内存大小及内存修改速度有关。一般说来,虚拟机实时迁移宕机时间会在1秒以下。OpenStack带磁盘迁移需要的时间会比较长,而且需要停机。由于虚拟机的磁盘一般较大,要想将宿主机上的虚拟机全部迁出,在短时间之内是无法做到的,因此可以挑选一些重要性较高的虚拟机做带磁盘迁移。 对于不可预知的故障,宿主机已经停机,处理就比较麻烦,如果虚拟机使用的是共享存储,只需要修改Nova数据库中宿主机字段,然后硬重启虚拟机,虚拟机就可以恢复。如果使用的是本地磁盘,虚拟机就无法很快启动了,必须等宿主机故障恢复以后,虚拟机才能启动。如果是磁盘问题,虚拟机磁盘可能就无法找回了。因此,虚拟机最好要做备份。虚拟机备份也是一个比较棘手的问题,可以从两个方面进行处理,一是由于虚拟机磁盘大,备份成本较高,不停机备份磁盘可能出现数据不一致性问题,直接备份虚拟机磁盘的操作成本也较高,这种方法适合一些重要而且能够短时间停机的虚拟机使用;二是采用应用服务冗余机制,在业务层面保证有多个虚拟机提供同一服务。

RabbitMQ使用和监控

在OpenStack中,大量使用消息队列作为各组件交互的媒介,因此,消息组件的稳定性至关重要。在运营过程中,我们经常发现Nova或者Neutron连接RabbitMQ假死,导致虚拟机无法分配,或者虚拟机无法上网等情况。官方推荐使用RabbitMQ作为消息组件,尽量对RabbitMQ做高可用性配置,但是即使做了高可用性配置以后,还是会出现RabbitMQ连接超时的问题,因此需要对RabbitMQ进行监控。可以用Nagios或者Collectd等监控工具,监测到队列大于某个长度就可以告警,如果能写程序模拟队列的生成消费行为则更可靠。另外,可以对Nova-Compute和Neutron-OpenvSwitch-Agent的日志进行监控,一旦出现连接超时而且没有恢复就可以断定组件已经假死,需要重启才能恢复。为了减少消息队列的压力,尽量不要使用Ceilometer组件,若Ceilometer是必需组件,Ceilometer尽量使用单独的RabbitMQ队列,以减少对核心队列的压力。

虚拟机网络故障

在OpenStack中,经常会遇到虚拟机无法联网的情况,定位网络故障也是OpenStack运维必选课,主要追查流程如下。 (1)在虚拟机控制台中使用ifconfig检查IP配置,然后ping网关。 如若不通,执行步骤2。 (1)(2)通过Dashboard检查Security Group,查看出口和入口的ICMP协议是否开启,若在开启情况下网络仍然不通,执行步骤3。 (3)在虚拟机宿主机上查看OpenFlow流。 (3)若看到VlanID的转换规则,则说明VLAN转换没有问题;否则,需要重启Neutron-Server和RabbitMQ,再次查看VlanID转换规则是否已经生成。若还不通,执行步骤4。 (4)在出网的网卡(如em3)上抓包。 (4)查看是否有包出去,如果看到包,则说明OpenStack配置没有问题,需要检查交换机是否配置Trunk模式。

总结

在本章中,我们介绍了IaaS建设的意义,探讨了两种搭建私有IaaS平台的方式:自己开发和采用开源方案。考虑到建设成本,对比了不同的开源IaaS建设方案后,我们选择基于OpenStack来搭建IaaS平台。在架构设计中,重点讨论了网络架构设计,因为网络架构设计是OpenStack搭建过程中最复杂的部分,也是决定成败的关键。鉴于对稳定性和性能方面的考虑,采用虚拟机通过Trunk直联交换机的方式,停用了Neutron-L3-Agent的功能,由物理设备直接担任路由转发的功能;在存储方面,通过经验选择了Ceph,因为它使用起来更加稳定,并且在不断的完善过程中。对象存储Swift的稳定性没有问题,但是性能问题非常明显,期待Swift的改进。在安装部署上,推荐使用手动安装方式,这是一种最可控的安装方式,但是需要对OpenStack的安装方法深入了解,增加了学习成本,同时建议将Yum源同步到本地,防止OpenStack源升级后产生不可预知的错误。接着,我们对虚拟机的性能进行了测试,以便消除大家对虚拟机性能的担忧。最后,介绍了一些OpenStack运营心得,比如版本升级、宿主机维护等常见问题,供大家参考。

好了,文章到此结束,希望可以帮助到大家。

用户评论

◆残留德花瓣

现在越来越多的企业选择使用IaaS平台了。

    有9位网友表示赞同!

←极§速

搭建自己的数据中心成本太高,IaaS能大大节省开销

    有17位网友表示赞同!

轨迹!

想快速部署新系统,IaaS真是个好工具!

    有13位网友表示赞同!

葵雨

听说很多IaaS平台都提供了各种安全保障措施,很安心的

    有20位网友表示赞同!

病房

用IaaS的话,是不是就能随时随地访问自己的数据?

    有10位网友表示赞同!

江山策

我公司最近也在考虑使用IaaS平台,不过还没选到合适的

    有10位网友表示赞同!

素颜倾城

听说IaaS平台的弹性很高,可以根据需要添加或减少资源吗?

    有8位网友表示赞同!

安好如初

对新手来说,学习如何使用IaaS平台会不会太难?

    有19位网友表示赞同!

失心疯i

不同的IaaS平台服务范围各有不同吧!

    有5位网友表示赞同!

熏染

IaaS平台的发展速度真快,新功能层出不穷。

    有6位网友表示赞同!

|赤;焰﹏゛

对于小型企业来说,是不是也适合使用IaaS平台呢?

    有5位网友表示赞同!

水波映月

想了解一下目前市面上的主流IaaS平台有哪些?

    有9位网友表示赞同!

将妓就计

建设好IaaS平台是公司数字化转型的重要一步啊!

    有16位网友表示赞同!

别悲哀

将来所有企业都可能要用到IaaS吧?

    有13位网友表示赞同!

瑾澜

使用IaaS能提高企业的IT效率吗?

    有17位网友表示赞同!

凉话刺骨

IaaS平台的成本优势主要体现在哪里?

    有11位网友表示赞同!

秒淘你心窝

学习使用IaaS平台,是不是有很多在线教程可以参考?

    有19位网友表示赞同!

陌颜幽梦

选择IaaS平台的时候要注意哪些方面呢?

    有6位网友表示赞同!

玩味

搭建自有的IT基础设施太复杂了,IaaS能帮我简化很多环节

    有20位网友表示赞同!

陌颜

对安全意识强的朋友来说,IaaS平台是安全的吗?

    有12位网友表示赞同!

【企业云计算基础设施解决方案构建指南】相关文章:

1.蛤蟆讨媳妇【哈尼族民间故事】

2.米颠拜石

3.王羲之临池学书

4.清代敢于创新的“浓墨宰相”——刘墉

5.“巧取豪夺”的由来--米芾逸事

6.荒唐洁癖 惜砚如身(米芾逸事)

7.拜石为兄--米芾逸事

8.郑板桥轶事十则

9.王献之被公主抢亲后的悲惨人生

10.史上真实张三丰:在棺材中竟神奇复活

上一篇:同样是下跪,为何董卿备受赞誉,杜海涛却遭遇争议? 下一篇:蜡笔小新与哆啦A梦:TV全集及剧场版资源汇总(珍藏版)