Openstack

Openstack（共10篇）

Openstack 篇1

1 案例简介

国家电网覆盖中国26个省市、88%的国土面积。国家电网的信息化建设面临着来自地域跨度大、异构化管理、利旧观念等问题。

九州云信息科技有限公司携手北京中电普华信息技术有限公司基于Open Stack框架研发了国家电网公司的基础设施云平台,采用了构建于英特尔硬件平台的软件定义基础设施解决方案。项目从2014年正式开始,到2015年9月已在九个省市顺利完成部署。2016年底将在全网26个省市数十个数据中心部署和实施,完成基础设施云平台的全网推广,届时将有超过6 000台服务器设备运行在由Open Stack管理的云中。

国家电网依托云平台的虚拟化(资源池化)、标准化和自动化技术,可以实现在自主可控程度上的提升、运维效率上的提升、服务质量上的提高、整体成本上降低和支持业务层面更高的利润收益。

2 案例的意义及必要性

国家电网是非常大的系统,各个省公司都有很多旧设备,由于它的发展周期比较长,网络非常复杂,覆盖到26个省市,每个省都有几百个机器,机房老旧。原来的布局规则比较复杂,要想把现有环境和开源的整体架构利用起来,需要克服很多困难。

除了面对传统信息化建设转型的挑战,国家电网还面临着来自“互联网+”的压力。以前,国家电网强调的是信息化服务于内部管理,但在“互联网+”的大环境中其业务形式、服务理念需要改变,国家电网认识到信息化一定要服务于用户,用户体验才是“互联网+”潮流中的主要竞争力。

在未来信息化构建中,“一平台、一系统、微应用”三大模块成为国家电网的三大关键词。平台是基础,为了适应数据的大规模爆发及业务多样化发展,其平台必须是复杂而庞大的。同时,展示在客户面前的应用,一定是反应迅速、简单、易操作。因此,云平台是基础,而分布式架构及微应用是国家电网直面用户的利器。

国家电网的云平台首先要能够管理混合式架构,在“互联网+”模式下,国家电网在保持传统集中式架构的基础上,添加了分布式架构,这样既能保留集中式架构的资源集中及高信息利用率的优势,又能拥有分布式架构的高扩展性。其次,该平台能够提供标准化服务,既能做到整合分装,保证对外的简单易行,又能保证系统内部各组件的无缝集成。

“十一五”阶段,国家电网整合了分散的信息化系统,对国家电网分散在全国的基础设施进行统一建设、管理及设计,将全国各地100多个数据中心,精简整合为20多个,使国家电网的信息化建设开始走向精益、集约、高效管控的新阶段。

“十二五”阶段是国家电网云起步阶段,同时也是信息化的创新阶段。国家电网将全国数据中心近万台服务器及大多数应用用资源池的形式进行重构组合。并通过定制资源池总体设计、制定入池规范、建设云管理平台等手段,使国家电网进入云计算部署阶段。

目前,国家电网进入云计算全面建设的“十三五”阶段,国家电网将引入Open Stack开源云管理平台,从以往闭环式正式迈向开源,这也是九州云承担的主要项目建设内容。

3 业务需求分析

国家电网作为国家范围内特大规模基础设施层的代表,拥有体量巨大、结构复杂,多地级联的数据中心设施,长久以来一直使用传统竖井式及孤岛式的管理方式,拥有一种新型的数据中心运行模式,资源池化并可弹性按需的自助提供服务势在必行。

数据中心的资源池化及云管回报体现在以下方面:

●提升系统利用率,节省服务器

建设资源池后,可显著提升现有设备的服务能力,有效降低信息系统采购服务器的投资成本。

●节省机房空间建设和运维成本

在原有的应用系统独占服务器的格局不变的情况下,随着应用软件的大量上线,购置的服务器逐年增加,机房内经常找不到合适的位置放置服务器,机房空调系统也已经接近满负荷运行,故障率和维护费越来越高。为降低运营成本,提高资源利用率和集约化管理水平,使用虚拟化技术对机房的服务器与应用系统进行整合,充分利用服务器的有效资源,提高各系统的运行速度和系统运行可靠性,同时降低能耗,提高对机房资源的集中管理能力。

●减少设备节省电费开支

就一台服务器从购买到最终被废弃的整个使用过程来看,其用电成本可能比实际购买价还要高。而虚拟化技术可以减少服务器的整体数量,也就是说可以用更少的物理服务器来完成相同的工作量。在确保正常运行时间和服务级别协议不变的前提下,虚拟化降低了对服务器、供电、制冷设备的要求,减少了用电,实现了节能减排的绿色计算。

●降低维保费用

硬件设备前三年维保费用已包含在采购费用内,但是后三年的维保费用按照市场平均15%的年维保费用计算,平均分摊到六年,每年7.5%,由于资源池的方式有效节省了服务器,所以每年的设备维保费用也会随之大幅降低,在设备的全生命周期中积累下来的维保费用也是很可观的。

国家电网当前计划实施的省市数据中心共27座,截至2016年11月已实施12处,2016将完成21处数据中心的建设,在2017年将全部完成,并实现一级平台对二级平台的完整纳管。整体的建设规划体量巨大,地域跨度庞大,服务器、网络设备、存储设备异构复杂,实施周期漫长,需多地相关单位配合。国家电网业务类型复杂,数据敏感,运行的业务关系民生实施过程要顾及原有系统的稳定过度及新型技术的可靠性保障,对九州云的技术团队提出了严苛的考验,但经过一年多的磨合双方建立稳固的信任基础,众多的疑难已逐步被攻破。

4 整体解决方案

基于Open Stack最新版本,通过一系列的定制化开发,根据实际生产需求,逐步建设运维人员可以支持的Iaa S服务及其上层服务,以满足国网信息化建设在资源池化、安全运行、集成测试、仿真运行等各方面的运行要求。

构建支持应用自动构建、自动收缩扩展、自动负载均衡的高可靠云平台。整体架构的核心是围绕Open Stack,集成开源分布式存储CEPH、开源或商用的SDN方案、高度定制深度集成的监控及日志收集分析产品,提供一体化的高性能的云计算解决方案。如图1所示。

技术实现上,通过“开源软件+定制化开发”模式,实现整个云服务平台,即将开源的自主可控和“商用的”稳定高效紧密结合。通过集成Ceph存储实现平台整体存储后端的统一,提供EB/ZB级别可自主掌控的存储容量池;结合商用或开源的网络解决方案,提供近乎原生的性能同时实现高层的服务,如负载均衡、防火墙、物理拓扑自动发现、物理流量动态监控等。如图2所示。

●统一了“物理分散”的数据中心互通接口,规范了“存量复杂”的异构资源调度方式。基于分布式存储,构建一个符合主流技术、易于扩展、高可用、具备国产自主可控的云计算基础设施管理方案;

●实现了异构虚拟化的集成,除兼容VMWare、KVM、XEN等标准虚拟化平台,还可以兼容国家电网特有的UVP、SG-VCS等国产虚拟化平台;

●通过存储虚拟化技术,实现了对集中式FC存储(HDS、HP、EMC等)和分布式存储(Ceph)的统一管理和调度;

●基于Dev Ops技术,实现了物理资源自动发现和入池,虚拟机操作系统的自动巡检和补丁下发功能,构建自动化运维模式;

●结合FWaa S、VPNaa S和安全组技术,对租户的隔离和访问进行加固,为系统安全保驾护航;

●结合SDN控制器和Vx LAN技术,实现了对物理服务器资源在不同等保网络间的调度。

(1)Open Stack计算区域

Open Stack计算区域由多种虚拟化技术同时作为虚拟化软件提供虚拟化能力。OVS为虚拟机提供vswitch,从而为灵活组网提供支撑。Libvirtd作为虚拟化管理API层,为上层Open Stack Nova-compute提供控制kvm的接入层。Nova-compute对集群节点进行计算资源管理,neutron-ovs-agent对集群节点网络进行管理,ceilometer-compute-agent提供数据采集,为上层的计费和监控提供数据。Zabbix-agent提供监控数据采集。平台可以通过划分Region和AZ的方法实现多区域以及多资源池的管理,解决平台规模扩展和性能瓶颈的问题,同时区分不能虚拟化的技术池。详见图3。

(2)Ceph分布式存储区域

分布式存储Ceph由Ceph Monitor服务(三个节点各部署一个Ceph Monitor服务进程)与Ceph OSD服务(每个节点根据硬盘数量部署多个Ceph OSD服务进程)组成,每个Ceph OSD服务进程管理一块硬盘。分布式存储网络考虑到业务使用以及性能要求,将划分为四个网络,具体如图4所示。

管理网络:管理Ceph集群服务的网络,需1Gb以上带宽;

Ceph public网络:Open Stack及VM访问Ceph集群的数据网络,需10 Gb以上带宽;

Ceph cluster网络:Ceph集群内进程数据东西向通信的网络,需10Gb以上带宽。

(3)VMware纳管(图5)

通过对Open Stack平台网络部分的架构改造,使其适应于VMware、kvm共存的异构资源池,因VMware本身产品的限制,需要对网络进行部分改造以便对多个网络同时进行管理。

5 应用效果

选择Open Stack给国家电网云平台带来三大优势:

第一,实现了自主可控,这也是国家电网非常看重的一点。基于开源项目构建云平台,掌控系统的所有源代码,为自主可控目标的实现奠定了很好的基础。

第二,节省了成本。通过管理数千台物理服务器,支持数百个应用的运行,提高了资源利用率和运维效率。

第三,实现了精益管理和精益服务,按照不同应用的业务特点,适配相应的云资源。

除了成本节约外,国家电网建设云计算平台最大的价值是提升整个业务运行的可靠性,或者说高可用。资源能够弹性伸缩、故障能够自愈,有服务器坏了系统能自动检测故障,然后把业务放在新的服务器上。如果系统检测到现有资源负载不足以满足访问请求时,也会将一些空闲资源加入到集群中。这才是Open Stack云平台带给国网的价值。

运行在开源Open Stack的云计算平台,可以实现以下几点:

(1)提高安全可控

●安全可控:云平台体现国际主流Iaa S技术,基于类似Open Stack技术,实现云计算各个模块(包含前端自定义界面、计算资源管理、存储管理、网络管理、镜像管理、认证管理、分布式存储、后端分布式存储、虚拟化软件和计量管理)能够提供完整源码,可以基于源码做二次开发,做到自主可控。

●开放中立:防止厂商锁定,云平台提供开放的API供二次开发使用,API需要涵盖包括提供计算资源管理、存储管理、网络管理、镜像管理、认证管理、分布式存储和计量管理的接口。

(2)成本降低

●通过开放架构降低在商业软件上的成本支出,每年节约基础软硬件采购成本近亿元;

●提高资源使用率,降低单位资源使用成本,单个数据中心节约近200 m2的机房空间;

●降低资源池更新建设成本;

●降低运维成本。

(3)提升效率

●CPU利用率平均提升了7倍,内存利用率平均提升了2倍;

●更加高效的运维体系,IT运维效率提升3倍;

●更加快速的资源获取能力;

●更快速的业务响应能力;

●更快的系统恢复能力。

(4)利润提高

●支持新型互联网业务的扩展;

●更加快速的资源获取能力。

6 结语

从目前来看,Open Stack已经成为仅次于Linux的全球第二大活跃的开源社区。超过585家企业,近4万人通过各种方式支持超过2 000万行的开源项目,世界100强企业中超过50%的企业均采用了Open Stack,开发者和用户更是遍布全球。无论是从整个社区的活跃度、媒体宣传度、还是曝光度来看,Open Stack已发展成为全球最快的开源社区之一。Open Stack是一个明智的选择。

国家电网的信息化底层环境是由集中式存储、分布式存储、容器及SDN组成的异构环境。而Open Stack作为Iaa S层的核心,能够将复杂的异构环境整合,并显露出简单标准的服务接口,做到化“繁”为“简”、化“异构”为“标准”。

OpenStack的整合之道 篇2

相比较云计算这个大概念，OpenStack项目的名气要小得多。作为一个开源的云计算项目，OpenStack不仅在架构和应用上完整体现了整合与再分配的概念，甚至于其生态系统也是依照这个框架所搭建。整合，贯穿了OpenStack的始终。这种与云计算属性一致的基本构想，使得OpenStack能够迅速地由一个初创项目成长为云计算建设的支柱。

从骨子里带出来的整合

OpenStack最早由Rackspace和美国宇航局（NASA）共同研发，OpenStack最初的一些代码，都是取自美国宇航局的Nebula（星云）平台和Rackspace的Cloud Files平台。2010年7月，Rackspace和美国宇航局做出了一个重要的决定：将OpenStack开源，把其打造成为一个能够在工业标准硬件上运行的云计算操作系统。

三年前，正值全球云计算应用风生水起之时。亚马逊通过对其云计算服务Amazon Web Services的成功运营，俨然已经成为了这一领域的“霸主”。云计算将要形成寡头时代，这种局面使得IT业界惴惴不安 。OpenStack的出现，恰恰迎合了包括IT厂商、用户企业等的行业认知。因此，如同在Windows一统江湖时代的Linux一样，OpenStack带着“众人拾柴火焰高”的模式给予了业界一种全新的思维。在宣布开源后，很快的OpenStack开始采用Apache 2.0许可证发布源代码，这使得其彻底变成了一个共享的项目。

可以说从诞生之日起，OpenStack的核心思想就已经体现了整合：集智慧于大成。独特的开源架构、成熟的项目思想，使得OpenStack的队伍迅速壮大。在开源后第一年，OpenStack就从42个组织成员和95个开发者增长到80个组织成员和1200名开发者。而截至到2013年第四季度，在OpenStack生态系统里已经有269家公司参与其中，进行开发的独立开发者人数累计达到1633名，个人会员数量为12万，平均每月的贡献者人数为375人。其代码数量已经从最初的1万行增加到现在的1.7万行。

英特尔、IBM、思科、戴尔、惠普、微软、AT&T、AMD，几乎所有的IT大佬们都齐聚在OpenStack项目中。无论他们此前对于开源的态度如何，但是至少在OpenStack项目上，他们找到了一致的目标。Linux阵营对OpenStack这个与自己有相同身世的“小弟弟”同样给予了很大扶持，包括Ubuntu、SUSE Linux等在内的主流Linux发行版很早就宣布了自己对OpenStack的支持。现在，很多人对于OpenStack的评价是：其就是未来云世界中的Linux。

明确的分工与统一的管理

众多厂商的参与，特别是商业元素的渗入，让人们不禁担忧起一个问题：作为一个开源项目，OpenStack如何保持自己的公正与透明？

在这方面，OpenStack再次体现了云计算整合与再分配的思维模式。

首先，加入OpenStack基金会需要经过多重审批。而其中的考核原则之一就是申请者对基金会的贡献程度。换句话说，只有在前期先参与到项目中来，才有可能成为项目成员。

此外，在每个OpenStack版本中加入哪些技术和功能，都是由OpenStack基金会的技术委员会来决定的。该委员会的成员是各个子项目组的组长，由项目成员选举产生，任期为6个月。目前，OpenStack已经发布了包括Austin、Bexar、Cactus、Diablo、Essex、Folsom、Grizzly，以及Havana在内的8个代码版本，这一审核机制从未改变过。

同时，在分工合作方面OpenStack也有着自己的考量。作为整个云计算环境的操作系统，这一项目拥有自己的内核、框架标准和API，并围绕内核衍生出了多个不同的子项目，这些子项目涵盖了对云计算平台中计算、存储、网络等各种资源的监控、管理与配置。每个厂商根据自己所擅长的内容，参与到不同的子项目组中。比如，思科在2011年2月正式加盟OpenStack项目后，其被分配的开发重点项目就是OpenStack网络服务。

最新的OpenStack Havana包含了9个项目。

计算（代号“Nova”） ：这一子项目主要致力于根据用户需求提供计算虚拟服务。Rackspace公司和HP提供商业计算服务正是建立在Nova之上，OpenStack的创始人之一美国宇航局内部也是使用Nova。

对象存储（代号“Swift”）：其主要控制对象文件的存储或者检索。目前已经有几好家公司开始提供基于Swift的商业存储服务，同时一些企业也开始在内部使用Swift来存储数据。

块存储（代号“Cinder”）：提供了稳定的数据块存储服务，而并非某种文件系统。这个项目的很多代码最初来自于Nova之中。

网络（代号“Neutron”）：这是一种管理网络和IP地址的系统。该服务允许用户创建自己的网络，然后连接接口。其主要确保网络不会成为应用瓶颈。

仪表台（代号“Horizon”）：为所有OpenStack服务提供了一个模块化的用户界面。使用这个Web GUI，可以在云上完成大多数的操作，如启动实例、分配IP地址、设置访问控制等。

认证服务（代号“Keystone”）：这个项目为所有的OpenStack服务提供身份验证和授权。它还提供了一个在特定OpenStack云服务上的服务目录。

镜像服务（代号“Glance”）：这是一个虚拟机镜像的存储、查询和检索系统，其提供了一个虚拟磁盘映像的目录和存储库，这些磁盘映像常常广泛应用于OpenStack的计算之中，而且这种服务在技术上是属于可选的，其适用于任何规模的云环境。

勘测 （代号“Ceilometer”）：其将为OpenStack项目的数据采集提供支持，将采集到的数据提供给监控、计费、面板等项目使用。

业务编排 （代号“Heat”）：这是一种将多种混合应用使用模板重新编排的服务，其通过OpenStack原生的ReST API和兼容CloudFormation Query API来完成。

竞合，竞争与合作

开源云计算项目描绘出了一个开放的云计算环境。在OpenStack之外，抱有同样愿景的还包括CloudStack、Eucalyptus等项目。在基本上相同的目标和构想下，这些项目彼此互为竞争，同时也在互相学习。

另一方面，就连被认为会是开源“死敌”的商业公司，也向开源云计算项目伸出了橄榄枝。2012年年中，虚拟化业界的大佬VMware正式加入OpenStack基金会。由于VMware如今在虚拟化领域无人能敌的地位，业界一直认为，OpenStack等项目所推行的开源虚拟化方针会遭到其阻击。同时，像vCloud这样的VMware产品同OpenStack也有很大冲突。因此，VMware的加入，使得人们认为，开源云计算项目在商业模式的整合方面已经取得了初步成功。

来自OpenStack基金会的调查显示，目前已知的OpenStack部署已经分布在56个国家的200多个城市中，其中美国超过了30个；英国、法国、德国、中国、印度的部署数量分别超过了10个；俄罗斯、澳大利亚、西欧部分国家和拉美部分国家部署数量分别超过了4个；另外在墨西哥、非洲部分国家、东欧和北欧部分国家至少已经开展了一个OpenStack部署。在国内，一些互联网企业已经将自己的云架构部署在OpenStack之上。

从理念到架构，再从架构到开发、产品、生态系统，OpenStack以一种开放的心态，整合了来自各方的资源。未来，这种整合的思维方式，将会成为IT行业的一条重要主线。

Openstack 篇3

OpenStack是一个开源云计算管理平台,由几个主要组件组合起来完成具体工作,该项目几乎支持所有类型云环境,项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算 管理平台。OpenStack通过各种 互补服务提供基础设施即服务(IaaS)的解决方案,为每个服务提供API以便进行集成。

Docker是由PaaS提供商dotCloud提供的基于LXC的开源高级容器引擎,整个项目基于Go语言开发,并遵从Apache 2.0开源协议。Docker可在容器内部快速自动化部署应用,并可通过 内核虚拟 化技术 (Namespaces及Cgroups等)提供容器资源隔离与安全保障。以现实世界中货物运输作类比,集装箱解决了各种型号、规格尺寸的货物用不同运输工具进行运输问题。发明Docker的初衷是将各种应用 程序和其 所依赖的 运行环境 打包成标 准container/image,进而发布到不同平台上运行。

2Docker特点及优势

2.1Docker特点

Docker是基于Linux Container(LXC)技术发展而来的一种轻量级打包应用程序框架,结合了LXC技术特点, Docker具有以下特 性:1密度大,启动关机 速度快;2 CPU/内存低消耗,省去GuestOS,节省更多CPU和内存资源;3隔离性好。容器解耦了应用与操作系统,为应用分发提供可能,更适合SaaS。它使用Namespace进程资源隔离(IPC,NET,PID,UTS,NS,USER),使用Chroot隔离根文件系统,并用Cgroup作资源限制;4所有容器共享内核,便于维护,所以无法做到彻底隔离,同时也带来安全性风险;5物美价廉,资源利用率高,所以应用运营成本比直接部署到OS要低很多;6跨云计算基础架构,不依赖IaaS层技术实现,无论是OpenStack还是AWS,只要有操作系统,即可创建容器;7隔离性不如虚拟机,如Netlink暂时不支持Namespace,所以导致不支持ISCSI存储;8无法在线迁移,所以最新推出的LXD要在LXC上添加等价虚机功能;9更高密度给网络设计带来了挑战。

2.2Docker与VM的对比

如图1所示,作为基于LXC技术构建的应用程序容器,Docker Container与普通虚拟机Image相比,最大区别是它并不包含操作系统内核。普通虚拟机将整个操作系统运行在虚拟的硬件平台上,进而提供完整运行环境供应用程序运行,而Docker则直接在宿主平台上加载运行应用程序。 本质上,Docker在底层使 用LXC启动一个Linux Container,通过Cgroup等机制对 不同的container内运行的应用程序进行隔离、权限管理和quota分配等。 每个container拥有独立的命名空间(即资源),包括:PID进程、MNT文件系统、NET网络,IPC、UTS主机名等。

由于Docker通过操作系统层虚拟化实现隔离,所以Docker容器在运行时,不需要类似虚拟机(VM)额外操作系统开销,提高资源利用率,并且提升IO等方面的性能。

2.3Docker优势

根据Docker特点及Docker与VM比较,可看出Docker具有以下优点:

(1)更快速的交付和部署。对开发和运维人员而言, 往往希望一次性创建或配置的应用程序可在任意地方正常运行。开发者可使用一个标准镜像构建一套开发容器, 完成开发 后,运维人员 可直接使 用该容器 部署代码。 Docker可快速创建容器,快速迭代应用程序,并使整个过程可视化,使团队中的其他成员更容易理解应用程序是如何创建和工作的。Docker容器很轻,容器启动 时间为秒 级,节约了大量开发、测试、部署时间。

(2)更轻松迁移 和扩展。Docker容器几乎 可在任意 平台上运行,包括物理机、虚拟机、公有云、个人电脑、服务器等。这种兼容性方便用户将应用程序从一个平台直接迁移到另外一个平台。

(3)管理更简单。使用Docker,只需局部 修改,就可替代以往大量的更新工作。所有修改都以增量方式被分发和更新,从而实现自动化、高效管理。

3Docker与OpenStack集成

Docker基于LXC,利用LXC容器作为基础来抽象一个运行单一应用程序的 容器。LXD建立于LXC功能之上,其提供管理多个宿主容器的高级特性,包括动态迁移和创建在线运行状态镜像等功能。LXD与OpenStack的结合使得私有云以及PaaS平台展现出更大优势,既可继承OpenStack的灵活性,又可发挥物理机性能,几乎没有额外虚拟机和内存开销。这个新driver允许Linux容器被安排为OpenStack实例。镜像通过OpenStack镜像服务Glance启动。实例之间 通讯基于Neutron网络功能, Docker在OpenStack中也可看 作是实例 的存在,类似于在KVM主机上运行虚拟机。

3.1Docker与Nova集成

在OpenStack中,Docker通过在Nova中以driver形式与OpenStack集成。这种实现将Docker容器当作虚拟机使用。但其目的并不是用来代替虚拟机,虚拟机有更好安全性和隔离性,Docker有更低损耗和更高的工作效率, 在特定应用场 合,虚拟机和 容器可以 相辅相成。Nova Docker driver与OpenStack集成流程如图2所示。

Nova Docker driver嵌入一个 微小的HTTP客户端与Docker内部REST API来通信,使用HTTP API控制Docker容器与获得 容器信息。通过配置Glance,Docker就能从Glance获得和上传镜像。

3.2Docker与Heat集成

在OpenStack中,社区更倾向于使用Heat来协调使用Docker,而不是通过Nova driver将Docker容器当作虚拟机使用。Nova Docker driver这种实现方式存在一定缺点,如标准API扩展会使用虚拟机的一些特有功能,但这些功能对于Docker并不适用,而且将Docker当作虚拟机使用,Nova很难利用Docker已有功能,如连接容器(主要指Docker容器间通信)。基于以上 原因,Heat是更好的 选择。

Heat在OpenStack中提供资源协调功能,与AWS的CloudFormation兼容,允许用户上传描述资源的模板。使用Heat插件机制,用户可以基于传统OpenStack部署方式部署和管理Docker容器。Heat插件已经被OpenStack社区接受,包含在Icehouse版本中。

举例说明如何使用Heat协调使用Docker:

在上例中,只需要添 加更多类 似 “my_docker_container”片段,就可创建多个容器并将它们连接起来,它们不受OpenStack API限制,可以充分利用Docker Remote API。

3.3Docker与CloudFoundry集成

Cloud Foundry是VMware推出的第 一个开源PaaS云平台,其支持多种框架、语言、运行环境、云平台及应用服务,并建立在IaaS平台OpenStack上。开发人员 能通过Cloud Foundry在极短时间 内进行应 用程序部 署和扩展,无需担心任何基础架构问题。

应用程序通常依赖于服务(例如:数据库、消息传递、 第三方SaaS提供商运行)、存储数据和推动移动通知等。 除了为开发人员提供一个简单、快捷部署应用程序的方式外,Cloud Foundry还定义了服务实例。

当Cloud Foundry开发者定 义并绑定 一个服务 到应用程序,负责提供服务的实例就称之为“Service Broker”。 “ServiceBroker”告知CloudFoundry服务的目 录和计划 , 并接收Cloud Foundry生命周期的调用,包括创建、删除、 绑定和解除。代理将这些调用传递给服务本身,服务提供者决定服务如何实现,Cloud Foundry只要求服务提供者实现“服务代理API”。

Containers Service Broker允许给用户提供的服务运行在绑定了应用程序的容器Docker里,这些任务包括:用随机凭证提供一个服务容器;绑定一个服务容器到应用程序;从应用程序取消服务的容器绑定,释放一个服务容器; 显示服务容器管理面板。

4结语

Openstack 篇4

在OpenStack项目中任职的同时，Alan还在SUSE担任行业创新、新兴标准和开源总监。那么，在这个不乏思科、惠普、戴尔以及SUSE这样商业公司的项目中，保持透明公正就变成了首要问题。

“加入OpenStack是需要经过审批的。而其中的考核原则之一就是申请者对基金会的贡献程度。”Alan表示，这在某种程度上为“投机者”设置了门槛，“在每个版本中加入哪些技术和功能，是由OpenStack基金会的技术委员会来决定的。该委员会的成员是各个分支项目组的组长，由项目成员选举产生，任期6个月。”

为了保持项目的开放性和成长，目前OpenStack基金会的理事会和技术委员会正在着手完成两件事：保持与OpenStack社区成员的交流，同时更新孵化器流程，以应对快速增长的代码数量。

在OpenStack之外，还有CloudStack、Eucalyptus等云计算开源项目，大家的目标出奇地一致：做云计算的“操作系统”。

对此，Alan认为，OpenStack与竞争平台最大的差别在于项目的发展势头，以及项目的参与人数。他说：“相比OpenStack，CloudStack的社区参与度比较低，功能增长也很缓慢。”

OpenStack最为人所诟病的问题之一，就是没有官方的商业版产品，而只是交给成员企业来发布。Alan表示，未来OpenStack还是会延续这种做法。

Alan透露，在他两年的任期上，他将会做三件事：管理快速增长的业务、让更多社区会员积极参与、做一些市场。“现在使用OpenStack的人数比人们想象的多，所以我们希望做活动，向人们展示是什么类型的人在用OpenStack，他们为什么要使用OpenStack。”Alan表示。

Openstack 篇5

社区堪称疯狂, Open Stack主题的活动动辄数千人——2016年10月的Open Stack巴塞罗那峰会就聚集了5000多名与会者, 他们来自50个国家。登台演讲的人来自大名鼎鼎的企业, 西班牙国际银行 (Banco Santander) 、英国天空公司 (Sky UK) 、诺基亚、德国电信和欧洲核子研究中心 (CERN) 等, 它们都是部署了基于Open Stack开源技术的云平台的用户机构。从这类大会人数和参与者的分量看来, Open Stack炙手可热。

另一方面, 明星效应之后的营收数字却令人尴尬。即使调高了预计, 研究机构451 Research一份题为《Open Stack Pulse 2016》的报告给出的数字仍然显得贫瘠。451 Research估测, 2017年全球Open Stack市场规模约25亿美元, 保持大约35%的年增长率, 到2020年超过50亿美元。25亿美元?全球?一年?这个数字小于微软云产品Azure的年收入 (仅软件和服务部分) , 更小于亚马逊AWS的软件和服务收入。

合乎逻辑的解释有两个。

第一个, Open Stack是开源技术, 所有组件的代码都可以免费获得。因此, 如果用户自行部署, 软件费用可以为零, 如果自行维护, 服务费用也可以为零。当然, 天下没有免费的午餐, 用户将不得不建立一个强有力的技术团队, 在Open Stack的诸多组件中选择部署, 确保它们顺畅合作, 支持自己的业务, 同时常设维护团队, 随时排除故障。这笔人力成本, 不会记在Open Stack平台的软件和服务收入中。即使找技术供应商部署和维护, 因为Open Stack各组件本身是免费的, 也比Azure、AWS等闭源系统更节省费用。所以看到2017年25亿美元、2020年50亿美元这两个数字, 不同的视角会有不同的心情。用户看, 很开心——“数字不大, 是好消息!”技术公司看, 有点失望——“原来总盘子就这么一点!”好在增长迅速, 年增长率35%的预计能够带来一些安慰。

第二个, Open Stack还很年轻嘛!2010年7月诞生的技术, 今天已经有了超过3万名社区成员, 用户和开发者分布在176个国家或地区, 这已经是伟大的成绩。Open Stack处在高速成长期, 参与的技术企业、开发者、用户的数量和带来的营收数字都在陡峭上升。所以, 现在年收入规模偏低不是消极信号。

这两种说法对不对呢?几句话说不清楚。华信研究院信息化和信息安全研究所、《中国信息化》杂志长期跟踪Open Stack社区, 和社区里的机构用户、技术供应商面对面交流, 已经连续三年研究开源云用户的偏好, 今年还加入了对中国Open Stack市场规模的测算, 相关的研究成果将于12月6日在“第三届中国开源云计算大会”上发布。在定量的研究成果公开发表之前, 我们可以先做一些定性分析。Open Stack的前景如何, 尤其是Open Stack在中国市场将有怎样的表现, 涉及到不止一个问题。简单梳理, 也至少要回答五个问题, 其中第一个是最大的要点。

1公有云还是私有云?

云计算蓬勃发展的未来, 今天恐怕质疑的人不多了。过去是“云者自云”, 现在是“可云则云”, 今后可能要问“为何不云”。云计算的好处很明显, 可维护性、计算和存储能力的伸缩性、成本优势、数据安全等等。不用云计算的机构用户将成为少数派, 并不能算是脑洞大开的预测。当自来水的便捷程度和费用都好于打井时, 打井喝水就成特例了。

云不成问题。公有云还是私有云, 这是个问题。用公有云?自建私有云?不好说, 不同用户会各自考虑, 有不同的选择。不同市场在这个问题上表现出了不同的偏好。据我们粗略估计, 中国内地以外的市场, 公有云和私有云六四开, 意思是公有云份额比私有云份额, 约等于6:4;中国内地市场, 反过来, 4:6, 私有云的份额可能比60%更大。

原因有好几个。第一, 很多信息中心主任——来自中央政府机构 (部委办局) 的, 来自大型国企的, 来自地方政府机构的——全都重视数据安全。他们认为, 数据放在“组织内”的服务器上 (无论是否在云上) , 总归比放在“组织外”的公有云上要放心一些。放在公有云上, 万一数据泄露, 或者数据丢失, 损失惨重, 只能承担责任。放在自建的数据中心里, 或私有云上, 可以加强备份防止丢失, 可以“扎起篱笆”防止泄露, 在数据安全上有主动性, 万一出问题, 也可以想怎么改进。所以, 对于中央和地方政府机构, 以及大国企, 私有云比公有云更有吸引力。

第二, 经费使用方面, 上报一个“建设数据信息系统”的申请, 相比上报一个“采购IT服务”的申请, 感觉是大不一样的。负责批准经费的人, 读到这两种申请, 感觉也是大不一样的。简单地说, 人们愿意为“建设”某个有形的、硬件软件结合的“系统”投入重金, 但购买一个摸不着的“服务”, 即使批准经费, 经费的数目恐怕也比建设系统要少一两个量级。所以, 对于雄心勃勃的IT系统建设者和经费审批者而言, 拥有“一片”私有云比租用公有云来劲多了。当然两个选择的实际功能差不太多, 公有云一般更省钱, 但大机构的人们还是会倾向私有云。文化心理倾向使然?或许是的。

第三, 已经说到“大机构”了——大机构, 无论文化心理倾向如何, 理智上也更容易选择私有云。超过1000人, 在中国算不上很大的企业, 但这种人力规模的机构, 已经有空间设立一个专业的信息技术部门来为自己服务。其他市场, 比如欧洲或美国市场, 超过1000人的企业比中国数量少很多。这样比较, 有能力选择私有云的企业数目, 中国比美国多, 也比欧洲多。

中国内地市场私有云份额明显大于公有云, 是合理的。

另有混合云的情况。本刊采访IBM高级副总裁、IBM系统部总经理罗思民 (Tom Rosamilia) , 和他探讨混合云的几种情形。至少有四种建设混合云的动机——

一是“整合混合”, 对运行在不同平台 (包括本地和不同云平台) 的程序和应用进行统一协调管理;二是在云环境中进行应用开发, 最终在本地环境中将其投入生产;三是用混合实现应用的可迁移性, 让某些应用既可以在本地运行, 也可以在需要时在公有云环境里运行;四是通过混合云带来计算能力的提升, 即在本地运行能力达到极限后, 使用云计算来进一步增加能力。罗思民认为有第四种需求的客户, 在他接触的企业里并不常见。我们 (《中国信息化》杂志) 认为有第三种需求的机构也不占可观的比例。而前两种动机, 重心仍在“本地环境”, 要么把重要的应用迁移到“本地环境”, 要么仅仅在开发时借助公有云。

因此, 混合云虽然是公有云和私有云的混合体, 但对大多数用户而言, 偏私有云而不是相反。

2开源还是闭源?

决定上私有云, 紧接着的问题是, 开源还是闭源?答案还是“看情况”。中国内地市场又有特色, 那就是对自主可控的追求。

闭源私有云技术平台, 常见的可选技术供应商包括VMware、微软和亚马逊等境外公司。一旦用户要求“软件自主可控”, 且不说“自主”, 这几家境外技术公司如何在代码不公开的技术平台上证明“可控”呢?通过合同条款作数据安全承诺恐怕是唯一的办法, 但合同条款马上可能遇到与技术公司注册地所在国法律相抵触的情况。

在国内闭源私有云平台技术供给尚不成气候的现在, 要讨论私有云系统的软件自主可控, 舍去开源软件还有什么呢?开源软件是遍布全球的开发者共同建设的, 更关键之处在于, 开源软件的每一行代码都是可以审计的。这对“软件后门防范者”实在是个好特性。

由于中国政府设置了自主可控“大筛子”——这是完全正当的——, 很多技术供应商被“筛”出局了。

3Open Stack还是其他技术?

决定上私有云, 决定使用开源技术, 紧接着的问题就是, Open Stack还是其他?

在Iaa S解决方案中, Open Stack有Apache Cloud Stack、Eucalyptus、Open Nebula等几个曾经的对手, 现在Open Stack已经遥遥领先了。一般的说法是社区为它带来了无穷活力, 这没错, 但我们对用户做访谈发现, 很多用户看好Open Stack的丰富功能和迅速升级适应技术前沿发展的能力——当然众多的版本和太快的迭代也给他们带来了困扰。

私有云的Iaa S解决方案, 用户选择Open Stack是不令人意外的。

4短处在哪里?

我们可以引用《Open Stack基金会2016双年调查报告》里的几个说法, 因为本刊调查中国用户问及“最不喜欢Open Stack哪里”时, 也出现了几乎一致的说法。

Open Stack的主要不足之处是:组件太多, 一致性差, 整合困难;文档零散;版本太多, 兼容性差;自动化部署难以实现。

5谁能赚到钱?

在这个问题之前, 还有一个附加问题——Open Stack在哪些行业能挣到钱?Gartner研究总监张毅接受本刊采访时说, 本身信息技术储备强的行业, 比如银行业, 有很多采用Open Stack的案例;此外, 对计算能力和存储能力的弹性要求高的行业, 比如电信业、广电业, 也倾向采用开源云平台。

Openstack 篇6

近年来关于云计算的研究成果层出不穷,众多与云计算相关的技术由此迅速发展,Open Stack就是其中之一。Open Stack平台是一个开源的项目,作为旨在提供基础设施即服务( IAAS) 的云平台,在文献[1]中IAAS也被称作Cloud Provider,其最大的特点是可扩展性强,这来源于该平台不是一个整块而是由扮演不同角色的组件组成的,最新的是第七个发行版名为Grizzly[2],共有七个组件,如Compute、 Object Storage、Image Service等等,本文使用的是Es- sex版本,这里不讨论Open Stack平台的组成架构, 可以参考Open Stack官方文档[3],那里有关于Open- Stack的所有介绍包括API和开发的说明。

如仅仅想成功安装[4]Open Stack平台进行简单的体验并非难事,只要了解基本的Linux系统操作即可,而且有不少关于这方面的技术文档可供参考, 但是基于这种方法构建的云平台是极不稳定的,不能在实际应用中发挥其应有的功能。在实际应用前至少要研究并做好以下两点: 第一,找到最佳的组合方式。Open Stack云平台是由多种组件共同组成的, 构建该平台的实质就是组合这些组件,最佳的组合方式取决于需求和现有物理环境,而前提是对Open Stack整体及其各个组件有深入的理解和丰富的实践经验。第二,保证虚拟机的安全。安全问题是云计算技术推广的一道坎,对于提供IAAS的Open Stack平台所针对的安全问题主要是虚拟机的安全。

组合稳健的Open Stack平台是保证虚拟机安全的前提,但这只是虚拟机安全问题的一个方面,高安全级别的虚拟机还应该能够防止来自公网和同平台上其他虚拟机的攻击。例如,以TPM硬件为基础,建立可信虚拟机管理器( VMM) 、可信安全域( VM) 或通过可信链保证上层应用的安全[5],这种安全机制主要针对来自公网的攻击,如VMBR攻击[6]。有特殊要求的虚拟机还应该可以独占物理内存及CPU。

本文讨论云平台上虚拟机之间的安全问题,提出一种安全策略防止不法用户窃取或篡改其他用户的数据。该策略具备良好的通用性,即与组件组合方式、虚拟机种类无关; 而能为虚拟机用户提供不同的安全级别,管理人员可利用现有的攻防技术自主地控制加解密、数据流等,则体现了该策略的可控性。

1系统模型与问题描述

Open Stack云平台的七大组件中有几个是可选组件,为了突出所要描述的虚拟机安全策略,这里仅仅选择必备的组件: compute ( Nova) 、image service ( Glance) 、Identity( Keystone) 。另外,假设拥有比较理想的物理环境,比如采用双网卡物理机,虚拟机使用Xen,在这种情况下来分析Open Stack云平台中虚拟机的安全问题,一般的系统模型如图1[3]所示。

Open Stack的网络访问原理在文档[3]中有详细的说明,简单叙述一下: 所有的用户虚拟机( VM) 均是虚拟桥接在物理网卡eth2上,这些eth2网卡连接到私有交换机上,而虚拟机若要访问外网则须使用外网ip( floating_ip) ,具体地,遵循一般的虚拟机访问网络机制[7]。

由于用户虚拟机间是通过桥接的方式通信,虚拟机之间相互可见,从而不法用户会很容易地侵入其他用户的虚拟机窃取或破坏数据,尽管有许多现有的攻防技术可以保护虚拟机数据,如各种加解密、 身份认证、IP过滤等,但是这种桥接方式的存在仍然是安全保障最大的软肋。

2安全策略的提出与分析

由上述分析可知,要加强Open Stack中虚拟机的安全,必须改变虚拟机直接桥接的现状。本文采用的思路就是变内网虚拟节点为公网节点,具体地, 我们把用户虚拟机看作“公网节点”,把Internet上的节点( 如服务器节点) 看作“内网节点”,虚拟机通过VPN虚拟专用网络桥接到网卡上,如图2所示, 图中所示的是某台物理机Host - n上部署虚拟机的情况,其他物理机像该机一样部署,并通过Privateswitch交换机连在一起,同时通过Public switch与外网通信。

从图2可以看出,VM - 1、VM - 2、VM - n与VM - 3处于不同的层次,本文称之为安全级别。其中,VM - 1、VM - 2、VM - n处于高安全级别,VM - 3处于低安全级别,后文有对此做详细解释和实验证明。

VM - VPN也是在Open Stack平台中创建的一个虚拟机,相当于一台VPN服务器[8],关于VPN涉及的技术[9 - 10]已经相对成熟,各用户虚拟机若要访问公网( Internet) 上的资源,须在VM - VPN上进行NAT( 地址转换) 。当然用户虚拟机也可以选择不使用该安全策略,而是按照原有的模型接入网络。

从改进后的系统整体模型来看,Open Stack原有的网络通信机制以及各组件的功能并没有改变,同时也不涉及虚拟机的版本和种类,因此该安全解决方案具备良好的通用性。

如图3所示,处于广域网中的设备节点可以使用VPN服务访问局域网中的资源[9 - 10],而利用广域网与局域网的相对性,可以将Internet中的资源 “相对地”看作局域网资源,另一边虚拟机可以通过VPN访问该资源。

具体地,对于Openstack环境中,在技术实现上将用户虚拟机当作是公网中的普通节点,而VM - VPN的另外一边则看作为局域网。根据VPN的隧道技术理论,公网中的节点可安全地访问局域网资源[10],而众所周知,公网的节点间( 这里指的是诸如VM - 1和VM - 2之类的虚拟机) 未经地址转换是不能直接相互通信的,从而相对地证明了在这种模型下用户虚拟机仍可以安全地访问Open Stack云平台之外的资源,同时实现了用户虚拟机之间的隔离。 且在虚拟专用网络( VPN) 中,用户数据在逻辑链路中传输,与网络模型无关,即与Open Stack所使用的flat网络模型并不冲突。综上,使用2. 1节提出的Open Stack云平台中虚拟机安全策略是有效可行的。

3实验验证

实验环境: 两台双网卡计算机host - 1和host - 2; 两张网卡分别连接外网( eth1 ) 和私有交换机( eth2) ; 每台计算机对等地部署Open Stack平台中的必备组件: computer、image service、Identity。对象存储组件( swift) 不必部署。

3. 1搭建平台

按照实验环境要求以及系统模型( 如图2所示) 搭建Open Stack云平台,可参见文献[4],并在平台中建立三台用户虚拟机和一个VPN虚拟机,分别命名为VM - 1、VM - 2、VM - 3、VM - VPN,并在VM - VPN上配置VPN服务。说明,为了减少实验复杂度,使结果更加清晰明了,这里使用Open Stack提供的强制虚拟机运行在指定主机上的功能,将VM - 1、VM - 2、VM - VPN运行在host - 1上,VM - 3运行在host - 2上虚拟机列表如图4所示。

说明,图5中的Vif3. 0和Vif4. 0分别是连接VM - 1和VM - 2的虚拟网络设备。

3. 2比较验证

3. 2. 1 VM - 1与VM - 2之间的通信

VM - 1与VM - 2之间的通信如图6所示。

结论: 由于VM - 1与VM - 2的关系是对等的, 所以可判定受安全策略保护的虚拟机之间不能相互访问。

3. 2. 2 VM - 1与VM - 3之间的通信

VM - 1与VM - 3之间的通信如图7所示。

结论: 受安全策略保护的VM - 1可以访问不受策略保护的VM - 3,但VM - 3不能访问VM - 1,如图8所示。基于此,该云平台可以为用户提供不同的安全级别,具体应用前需要包括界面( Dash-board[2]) 的二次开发。

3. 2. 3 VM - 1连接公网( Internet)

VM-1连接公网如图9所示。

结论: 实施安全策略后,VM - 1仍可以访问公网。

通过三组的比较验证可以得出,依据本文提出的安全策略部署的Open Stack云平台更加安全稳定,虚拟机可自主地控制其安全级别,处于保护下的任意两个虚拟机之间不能直接通信,即它们相互间是隐藏的,而公网上的节点对它们来说则是可见的。 实验证明,本文提出的部署策略可显著提升Open- Stack平台中虚拟机的安全。

4结束语

本文首先叙述了在Open Stack中存在的虚拟机安全问题,即用户虚拟机之间的威胁,然后分析了这种安全问题的原由以及可能解决的办法,提出并理论证明了一种基于VPN技术的安全策略,最后进行实验验证其有效性。现如今VPN的相关技术如隧道技术、加解密技术、密钥管理技术等已经非常成熟,所以按照本文提供的策略部署Open Stack云平台是足以保证虚拟机安全的。

另外,该安全策略具备良好的可控性。 对于Open Stack云平台的管理者,他们可以在VM - VPN虚拟机上依据各自的需求部署自己的VPN服务,包括传统的数据流加解密与控制。

Openstack 篇7

随着云计算技术的不断发展, 诞生出了很多出色的云管理工具, Open Stack作为云管理工具的代表, 集成了云管理所必须的组件, 这些组件中就包括了SDN控制器:Neutron。Neutron添加了一层虚拟的网络服务, 能让用户 (实际是租户) 构建自己的虚拟网络。Neutron公开了一组可扩展的API, 可以通过改组API创建和管理虚拟网络, 实现方式如图1所示。

在图1中, 我们可以看到Neutron通过代理服务的方式去实现SDN的抽象功能, 其中Neutron Server负责创建Neutron守护进程 (Daemon) , 包括Neutron Server主进程 (neutron-server) 和Neutron各插件进程 (neutron-*-plugin) 。Neutron的插件包括如Linux Bridge、Openv Switch、Cisco、Cisco等。

Neutron Server主进程负责提供API接口, 并对其它服务的API的调用请求传递给Neutron插件进行处理。Neutron插件会通过访问数据库来查询状态、策略、配置等信息。在Neutron中, 真正的数据包不由插件直接进行转发, 而会通过相应的插件代理 (Plugin Agent) 服务来处理。

Neutron的主要代理服务包括以下几个:

DHCP代理 (DHCP Agent) :DHCP代理可以为相应的租户网络提供DHCP服务, 虚拟机实例可以通过DHCP服务获取IP地址。

三层转发代理 (L3 Agent) :为虚拟机实例提供三层路由转发功能, 可以通过L3代理创建GRE网络。

Metadata代理 (Metadata Agent) :负责为相应租户创建虚拟机实例传递属性, 主要用于传递虚拟机实例的ssh公钥。

负载均衡代理 (LBaa S Agent) :提供负载均衡服务, 通过调用编配 (Heat) 服务的模板, 实现网络流量负载均衡。

Neutron作为Open Stack原生的SDN控制器, 可以支持多种网络类型, 包括扁平化网络 (FLAT) , 三层网络 (GRE) , 虚拟局域网 (VXLAN) 等。Open Stack在Havana版本中, 新增了ML2 (The Modular Layer2) 插件, ML2插件可以通过Type Drivers和Mechanism Drivers来让多种插件并存。原生的ML2的插件支持Open Stack自家的Openv Switch插件, 可以通过ML2插件配合Openv Swith快速部署FLAT网络。

2 Openv Switch的的基本功能

Openv Switch (以下简称OVS) 作为Open Stack自家的插件, 在Open Stack的SDN实现上起到了至关重要的作用, OVS在整个云网络中承担虚拟交换机 (virtualswitch) 的角色, 通过Open Flow协议与Controller节点统一管理, 可以被Controller所管理的还有一些支持Open Flow的硬件交换机, 他们与虚拟机实例一起组成了整个云计算网络。

OVS通过Open Flow协议去构建自己的流控表 (Flow Table) , 当数据包通过虚拟交换机时, OVS会根据自己的Flow Table与数据包进行匹配, 从而控制数据包的流向或改变数据包结构。通过一系列对数据包的操作, 使OVS实现SDN的业务需求。

OVS在根据业务需求对数据包进行修改时, 会通过查询数据库获取业务和云网络中其它设备 (包括物理设备和虚拟设备) 的信息, 从而改变自己的Flow Table。

3 一种Open Stack网络模型

本文提出一种新的基于Open Stack的网络基本网络的组件, 提出一种新的按功能层次划分的网络模型, Open Stack就针对Neutron云计算网络, 如图2所示, 首先Open Stack以节点的方式分布相应服务, 图2中构建了三节点 (Controller节点、Compute节点、Network节点) 并将Network的功能集中到了Controller节点上。

该网络模型主要将Open Stack网络划分为以下三种:

3.1 External Network (外部网络) :

外部网络主要用作虚拟机实例访问外网, 这个网络之间连接外网, 该网络还可以用作外网服务 (如ssh) 连入内部虚拟机实例。

3.2 Data Network (数据网络) :

数据网络用于虚拟机实例之间的数据传递, 包括虚拟机实例与虚拟路由器之间的数据传递都是依托于数据网络。

3.3 Management Network (管理网络) :

管理网络负责处理OpenStack各个组件之间的交互, 连接数据库, AMQP通信数据都是在管理网络中传输。

三个网络互不干扰, 相对隔离, 这样的设计既出于安全考虑同样也方便了流量隔离, 对于流量较小的管理网络, 显然不需要与数据网络抢占资源, 也不需要进行任何形式的流量控制, 整个网络可以相对稳定的运转。

参考文献

[1]王鹏, 黄华峰, 曹珂著.云计算:中国未来的IT战略[M].北京:人民邮电出版社, 2010.

[2]邓自立.云计算中的网络拓扑设计和Hadoop平台研究[D].上海:上海交通大学, 2010.

Openstack 篇8

1 OpenStack概述

OpenStack的作用把多台计算机整合成为一个云计算系统,以对外提供IaaS服务,也就是说,它提供对云的基础设施运行环境的管理。来自世界各地的开发人员和云计算技术专家共同创建了OpenStack项目,它的源代码是开放的[2]。

OpenStack的功能由多个子项目协同实现,在这些子项目中,帮助实现核心功能的有七个,它们分别是OpenStack Compute (代号为Nova),OpenStack BlockStorage(代号为Cinder),OpenStack Object Storage(代号为Swift),OpenStack Identity(代号为Keystone),OpenStack Network(代号为Neutron,原Quantum),OpenStack Image Service(代号为Glance) 以及OpenStackDashboard(代号为Horizon)。其总体架构图如图1所示。

根据架构图可以看出,Heat的作用是编排云,Horizon为其他云服务提供UI,Ceilometer负责监控其他服务,其他项目通过Keystone进行身份验证。实现云计算核心的是虚拟机,在OpenStack中,Nova负责创建虚拟机,Glance为虚拟机提供镜像,Cinder为虚拟机提供块存储,Neutron则负责虚拟机的网络活动服务。另外,OpenStack的对象存储由Swift负责,Glance的镜像文件以及Cinder的备份卷都是存储在Swift上的。

2 OpenStack各组件详析

为设计、部署和配置OpenStack,使用者必须了解OpenStack详细的逻辑结构。

在OpenStack的各子项目中,Horizon项目比较简单,主要负责接受来自Internet的HTTP请求,为最终用户和管理员提供一个基于Web的操作界面,本文不再详细分析该项目。接下来将详细介绍其他各项目之间的交互情况以及各项目的详细逻辑。

2.1 Nova

OpenStack的核心管理部分就是Nova,它主要执行创建和维护虚拟机、管理网络等作用。Nova与Keystone交互以获得授权认证服务,与Glance交互以获得虚拟机镜像,与Horizon交互以获得用户及管理员接口。它通过用户和租户来实现对云的访问控制,以项目为单位来控制配额(比如实例数等)。Nova项目内部的逻辑结构如图2所示。

在Nova中,nova-api组件在接收http请求后将请求转换成命令,通过队列或http与其他组件通信;nova-compute是一个通过hypervisor API来创建或终止虚拟机的worker守护进程,它的过程很复杂但基本原理却相当简单:接受队列中的动作指令后执行一系统的系统命令,在执行这些命令的同时更新数据库;novadatabase使用基于SQL的中央数据库,这个数据库中所存储的数据能够被所有组件共享;Queue组件负责在各守护进程间传递消息,nova所有主要组件均可运行在多个服务器上,Queue就是组件间实现通信的机制,nova目前由RabbitMQ实现消息传递;nova-conductor组件负责传导nova-compute与数据库之间的交互消息,旨在消除两者之间的直接访问,该组件是水平可扩展的;nova-scheduler从队列中接受虚拟机实例请求并决定在哪台服务主机上执行请求。

2.2 Swift

Swift主要负责构建一个存储对象的系统,主要用于长期存储一些可被检索、调整和更新的静态数据[3]。它是一个高度可扩展的多租户的系统,主要针对非结构化数据。Swift内部的逻辑结构如图3所示。

Swift-proxy对外提供API,负责Swift组件间的通信。对于每个客户端的请求,它查询存储服务器的位置并将请求转发给相应服务器。

Swift的存储服务器包括Account、Container和Object三类,其中Container负责存储Object列表,它并不知道对象存放的具体位置,而只知道该Container中存放了哪些Object,此外,Container服务器也做一些例如Object的总数的跟踪统计。

2.3 Cinder

Cinder的前身是Swift中的swift-volume模块,负责提供两种级别的块存储:短暂性的块存储基本上可以看作是虚拟机的本地磁盘;持久性的块存储则并不依赖虚拟机,它的volume可以附在到任一虚拟机上,也可从某个虚拟机卸载再附贴到另外一台虚拟机上,这样做并不损坏volume中的数据。Cinder为实例提供块存储服务。其内部的逻辑结构如图4所示。

cinder-api负责接受API请求并把这些请求转发给cinder-volume来执行;cinder-volume对cinderdatabase进行读写操作,负责响应请求,它使用Queue与其他进程交互,运行在存储节点上,管理存储空间;cinder-scheduler负责块存储的资源调度,简单的说,它接受任务然后根据选定的策略把任务交给合适的节点来执行[4]。

2.4 Neutron

Neutron项目的核心理念是网络即服务(Networkas a Service),它创建了一组一致性的网络服务,而OpenStack的其他项目可以使用这个服务。其项目内部的逻辑结构如图5所示。

neutron-server负责接受API请求并把这些请求转发给其他组件来执行;neutron agents和neutron plugins负责启用和禁用端口、创建网络和子网、提供IP地址等功能,plugins和agents的不同之处在于其在特定的云中所使用的供应商和技术不同,常用的agents有L3,DHCP和插件agent等;Queue负责neutron-server与各种agents以及存储特定插件网络状态的数据库之间的通信。

2.5 Glance

Glance与虚拟文件系统的作用有些相似,它向Nova提供一个统一的操作接口以发现、注册、检索虚拟机镜像,使用者不必关心镜像具体是存储在Swift上还是在Amazon S3上。Glance的逻辑架构如图6所示。

glance-api的作用是为其他组件提供接口和接受调用请求;glacne-registry则主要用于执行存储或者获取镜像的元数据时与数据库的交互操作。

2.6 Keystone

OpenStack使用Keystone来完成认证和管理用户、帐号和角色信息以及授权的服务。因为每个项目都必须使用keystone来进行身份、授权等认证,所以各项目与keystone均有交互关系。接下来以创建一个虚拟机的流程为例简述keystone的作用。

首先,用户(user)向keystone申请token,keystone会要求用户提供用户名和密码,当它们被验证为有效后,keystone将token1返还给用户;接下来,用户使用token1向keystone查询他拥有的租户(tenant)列表,如果token1被判定为有效,则把用户所有的租户列表返还给用户;然后,用户选择其中某个租户,再次申请token,如果用户的用户名、密码和租户均被keystone验证无误,则返回token2;最后,用户使用token2发送创建虚拟机的请求,keystone负责检查token2的有效性以及权限,如果验证成功,则keystone通知nova该用户需要创建虚拟机,操作成功,流程结束。

2.7 Ceilometer

Ceilometer项目的主要作用是收集OpenStack内部各个服务以及将来很多未知服务的信息,这个需求决定了它的架构必须是灵活可扩展的,因此,Ceilometer的架构是微内核,它通过插件来实现扩展。该项目目前包括五个组件以及一条消息总线(MessageBus),各个组件分别如下。

Compute Agent组件用来收集计算节点上的信息,在每个计算节点上都要运行一个Compute Agent,它通过使用插件调用Hypervisor的API来获取虚拟机的使用信息,目前它只支持Libvirt的API。CentralAgent运行在控制节点上,它主要收集其它服务(Image, Volume, Objects, Network)的信息,实现逻辑和Compute Agent类似,但是是通过调用这些服务的REST API去获取这些数据的。Ceilometer最核心的组件是Collector,该组件主要于用监控消息总线并将收到的消息以及相应的数据写入到数据库中,它是在核心架构中唯一能够对数据库进行写操作的组件。Ceilometer的数据存储现在支持MongoDB, MySQL, Postgresql,HBase以及DB2,其中对MongoDB是支持最好的。Ceilometer提供的REST API是唯一能对数据库进行读操作的组件。Message Bus是所有数据流的通道,Collector要想收集数据进而写入数据库就必须使用Message Bus,目前Ceilometer采用RabbitMQ实现它。

2.8 Heat

Heat有些类似AWS的CloudFormation功能,用户可以预先定义一个规定格式的任务模版,任务模版中定义了一连串的相关任务,然后将模版交由Heat执行,就会按一定的顺序执行heat模版中定义的一连串任务。

以上几个项目综合起来,帮助OpenStack实现了一个云计算系统。然而在实际使用中,一个节点上根据需求可以安装其中一项服务,也可以安装多项服务。

3 结论

Openstack 篇9

【摘要】本文从微信公众平台的发展现状以及趋势入手，结合其开发环境与操作系统的兼容性问题和资源占用过大问题，结合微信公众平台和云计算平台的特点，探讨利用云计算平台来实现微信公众平台开发的可行性分析与研究。

【关键词】微信公众平台;云计算平台;OpenSatck;兼容性;资源占用

1引言

移动互联网将移动网络和互联网通过移动终端设备结合起来，是传统互联网与移动通信互相融合下的产物。在当今信息高速发展的时代，微信成为了新型移动即时通讯应用的一个标志。由于微信公众平台自带的后台编辑系统功能比较的单一，已经不能满足需求。但是，微信公众平台为广大的微信公众平台开发者提供了二次开发的接口。然而，由于搭建其环境的过程的复杂性，开发平台所需要的软件和操作系统的兼容性问题和所需软件占用资源问题，使一些开发者头痛不已。云计算平台的诞生，可以很好的解决以上这几个问题。

2微信公众平台的现状分析及开发环境问题

2.1 微信公众平台的现状分析

微信公众平台是腾讯公司在微信的基础上新增加的功能模块，它是一个腾讯官方推出的集服务与宣传功能的订阅平台，可以实现和目标群体的语音、图片、文字的全方位的沟通、交流。微信公众平台分为订阅号和服务号、企业号三类平台。可以根据不同的需求来申请不同的公众账号以满足不同群体的需求。

微信公众平台操作性简单，方便了广大用户的使用，根据其本身的优势和qq客户群的庞大，使其发展速度很快，使用人数不断的增加。微信公众平台提供了很多的功能比如用户可以体会多元化、全方位的功能。用户可以自由的选择订阅公众账号，提供了自由、开放的交流环境。

2.2 微信公众平台开发环境问题

由于微信公众平台自带的后台编辑系统功能比较的单一，不能体现出公众账号之间的不同。因此，这就需要开发者在后台通过API来更改或添加一些功能模块，使其内容更加的丰富，功能更加的齐全。AppServ和zendstudio是经常用来搭建微信公众开发平台的两种软件。AppServ是一个软件集合，包括Apache（HTTP服务器软件）、PHP（网页程序设计语言）、MySQL（数据库管理系统软件）phpMyAdmin（图形界面的数据库管理软件）四个组成部分。AppSer是一个HTTP服务的集成开发环境。AppSer把这些软件集合在一起的，目的使在部署整套环境变得更简单。虽然安装过程比较简单，但是花费的时间很长，而且占用的资源很大。因为每个服务端口号是唯一的，但是AppServ中的端口号也许会和你已存在的程序的端口号起冲突，导致不能使用。卸载AppServ软件也非常的繁琐，一旦没有卸载干净，会导致下次安装AppServ软件的失败，一般这种情况下，只有重装系统。

3 OpenStack搭建的云计算平台的特点

云计算是通过改进网格计算、分布式计算和并行计算发展起来的全新商业计算模式，它包括3个层次的服务：基础设施即服务（IaaS），平台即服务（PaaS）和软件即服务（SaaS），并且将基础设施、软件以及平台作为服务通过网络提供给用户，从而使用户节约了管理软件和硬件资源的费用。目前广为接受的是中国云计算专家咨询委员会副主任、秘书长刘鹏教授给出的定义：“云计算是通过网络提供可伸缩的廉价的分布式计算能力”。IaaS通过虚拟化和分布式存储等技术，实现了对包括服务器、存储设备、网络设备等各种物理资源的抽象，从而形成了一个可扩展、可按需分配的虚拟资源池。

OpenStack是一个美国国家航空航天局和Rackspace合作研发的云端运算软件，以Apache许可证授权，并且是一个自由软件和开放源代码项目。它支持所有类型的云环境，提供了一个“基础设施即服务”（IaaS）的解决方案，每个服务提供了一个应用程序编程接口（API）来促进这种集成。

OpenStack搭建的云计算管理平台具有超大规模，虚拟化、高可靠性、兼容性、通用性、高可扩展性、按需服务、及其廉价等特点。图3.1 OpenStack搭建的云管理平台。

图3.1 OpenStack搭建的云管理平台

4云计算平台上实现微信公共开发平台的解决方案

云计算平台具有强大的功能。在以管理员身份登录云管理平台时，可以通过打开“管理员”找到“镜像”选项，然后点击“创建镜像”.在用户申请实例的时候，只需要告诉用户选择带有AppServ软件的镜像就行。而用户本身不需要搭建任何的开发环境，只是需要一个浏览器和申请一个“用户”的名字就行，这样就解决了安装开发环境过程中遇到的各种问题，也不用担心兼容性问题。非常适合微信公众平台开发者的需求，而电脑上不需要做任何更改，openstack搭建的云计算平台安全性也极高。

小结

新技术的诞生都会对人们的生活产生一定的影响，应该尽可能让其对人们的生活带来便利。如果把微信公众平台的开发放在云计算平台上运行，那么即使电脑的配置比较低或者是与其他的软件产生冲突，也可以进行微信公众平台的开发。本文只是提出实现微信公众开发平台解决方案，而创建带有AppServr软件的镜像的具体的解决方案，本人会在以后的文章中进行详细的介绍！

参考文献：

[1]Chigona，W.，Beukes，D.，Vally，J.，& Tanner，M.Can mobile Internet helpalleviate social exclusion in developing countries？.The Electronic Journal ofInformation Systems in Developing Countries，2009，36，1–16.

[2]兰欣.微信公众平台CMS的设计与实现[D]，2015（1），II、1.

[3]http：//baike.haosou.com/doc/5335445-5570883.html.

[4]白浩，郝晶晶.微信公众平台在高校教育领域中的应用研究[J].中国教育信息化，2013（4）：79.

[5]http：//docs.openstack.org/.

[6]王霄飞.基于OpenStack構建私有云计算平台[D]，2012（6），1-3.

Openstack 篇10

现在, 华为将与全球最大的开源技术厂商红帽公司 (Red Hat) 合作, 来满足电信运营商的上述要求。

红帽和华为 (服务器软件与电信设备供应商) 正在推动名为Open Stack的新兴开源技术, 并使其代替传统的电信网络系统。Open Stack正以全新的方式管理着大量的计算机服务器。红帽与华为的合作旨在将Open Stack的基层概念贯彻到网络中, 该网络管理计算机服务器的网络流量, 并输出给消费者。

电信运营商是全球在高科技硬件、软件和服务投入最大的用户群之一。例如, AT&T最近表示, 该公司计划明年投入180亿美元, 用于电信网络和系统设备等设施——这一金额是谷歌今年资本支出的近一倍之多。如此巨额的预算, 意味着电信运营商的技术选择将对IT厂商的发展产生重大影响。

如果红帽和华为的合作能取得成功, 他们的联盟将对思科和爱立信等公司产生威胁。爱立信的设备目前被电信运营商广泛使用, 但这些电信公司的传统设备采用的是专有技术, 常常需要耗费大量时间才能重新配置, 而且一旦使用该技术便难以更换供应商。

AT&T等电信运营商是Open Stack技术的最大支持者之一, 而红帽和云计算公司Rackspace是这项技术的积极推动者。红帽与华为合作的目标之一, 是让Open Stack这一新兴且有门槛的技术, 能更紧密地应对行业紧迫、严苛的网络部署需求, 比如电信业。

红帽公司负责基础设施业务的高级副总裁蒂姆·伊顿 (Tim Yeaton) 表示, Open Stack对于电信运营商来说“仍然是一个过于通用的平台”。

思科和其他大型电信设备供应商也正在为电信公司和其他行业客户提供基于Open Stack的解决方案。红帽今年早些时候曾宣布与思科建立与华为类似的全球合作伙伴关系。