IaaS云服务（精选4篇）
IaaS云服务 篇1
一、什么是云计算Iaa S?
说起Iaa S, 就不得不先提一下云计算。云计算其实只是一个概念, 就如“互联网+”, 有人说“互联网+”是一种互联网思维, 那云计算, 其实也算是一种思维的产物。
云计算是一种通过互联网进行访问, 按照使用量进行付费, 能够提供便捷网络访问的虚拟化资源。使用者可以进入计算资源共享池, 选取自己所需要的资源或者服务, 避免繁杂的操作和琐碎的管理, 从而大大提高工作效率。
而Iaa S便是云计算“货架”上的一种“商品”, 与Paa S和Saa S构成了云计算的三种不同资源形式。Paa S是平台即服务, Saa S是软件即服务, 而Iaa S则是基础设施即服务。Iaa S是云计算中的基础设施服务层, 通过采用资源池构建、资源调度、服务封装, 将厂商的计算单元、存储器、带宽等基础设施集中起来, 作为一个虚拟的资源池对外提供服务, 将IT资产迅速转变为可交付的IT服务。
比较典型的Iaa S有亚马逊的弹性计算云EC2, 借由提供web服务的方式, 让使用者弹性地运行自己的Amazon机器映像档, 可以在这个虚拟机器上运行任何自己需要的软件和应用程式。S3简单存储服务也是Iaa S的一种, 它表现为一个超大的硬盘, 使用者可以在其中存储和检索数字资产。
二、云计算Iaa S的发展
2.1云计算Iaa S的定价
实际上, 云计算也是一种交易, 而涉及交易, 必定会关系到定价的问题。使用者通过支付费用使用提供商的资源, 而提供商, 也通过为使用者提供资源获得利益。2006年弹性计算云被推出, 2009年12月, Amazon提出现货竞价实例的概念, 通过按使用量支付的方式收取服务费用, 今年亚马逊AWS云计算服务年收入达到50亿美元, 每年都以50%左右的速度增长。
当下, 中国云计算生态圈正处于快速进化的阶段, 据IDC发布的2015年技术发展趋势报告中显示, 云计算的市场规模到明年将达到1180亿美元。小米、金山、BAT、微软、IBM以及其他企业、运营商等等都在对云计算领域保持关注, 越来越多的资本和“玩家”进入, 让Iaa S定价成为需要关注的问题。
目前云计算Iaa S的定价模式有三种:按需运行、保留运行和现货竞价。
按需运行, 使用者可以根据实际应用情况调整需求, 采用按需求付费。类似于手机通话, 打多少分钟电话, 就缴纳多少通信费。用多少付多少, 方便灵活, 但是单价相对较高。
保留运行则是类似于手机的包年和包月套餐, 签订一定时长的合同, 并且一次性支付费用, 相对而言, 这种方法费用较低, 但是对于使用者的约束较高。
现货竞价则类似于竞拍, 厂商根据实际需求周期发布即时价格, 用户最高竞价高于即时价格, 服务则会继续执行, 而用户最高竞价低于即时价格, 服务则会被自动中断。
三种模式各有优缺, 在用户体验和厂商利润之间的取得平衡, 不仅关系到用户的实际利益, 也直接影响到厂商的生存延续。按照实际情况去执行, 甚至将多种定价模式进行组合, 能为云计算Iaa S的生态圈环境作出一些良性改变。
2.2云计算Iaa S的安全
在云计算Iaa S中, 存在着两个方面的安全问题:同用户的数据安全和不同用户之间的数据安全。
同用户的数据安全, 一般而言是指用户自己对于数据的用途不同。一部分数据, 如企业公开财务信息、公司最新新闻、公司股票信息、公司业绩等等, 是可以向社会大众公开的公共资源。而另一些, 如企业的技术信息、资金变动等等内部重要信息, 关乎到企业的生死存亡, 是不能对外公布的核心数据。
云计算Iaa S需要对两种数据进行分别处理, 并且进行全方位的保护, 保证数据的安全和隔离, 防止后者数据出现在前者的数据中。
不同用户之间的数据是不同的, 甚至有些用户数据是不能外泄的。一旦发生用户之间的数据相互覆盖、复制, 不仅对用户造成困扰, 也会让用户产生不信任感。这就需要对不同客户间的数据进行隔离, 保证各个客户的数据间的准确和安全, 防止“串门”事件的发生。
另外, 做好安全审计也是商用系统信息安全的重要部分, 对各类操作建立日志, 并且分析审计, 对虚拟机、数据库、管理信息等等进行安全审计, 保证系统的安全。
在此基础上, 还需要保证客户数据的完整、更新及时, 建立防火墙、数据加密、权限设置、数据备份等等对数据进行全方位的安全保障, 并且结合法律方面的东西, 在规章制度上对数据安全进行有效保护。
随着越多越多企业和政府的参与, 云计算Iaa S基础设施服务系统, 必将迎来百花齐放的美好未来!
摘要：本文阐述了云计算Iaa S基础设施服务系统的概念, 分析了云计算Iaa S定价和安全方面的问题, 为云计算Iaa S的未来发展提供借鉴。
关键词：云计算,IaaS,分析
参考文献
[1]岳冬利, 刘海涛, 孙傲冰.Iaa S公有云平台调度模型研究[J].计算机工程与设计.2011 (06) :1889-1892.
[2]房秉毅, 张云勇, 程莹, 徐雷.云计算国内外发展现状分析[J].电信科学.2010 (S1) :1-5.
IaaS云服务 篇2
为应对新媒体冲击,加快传统报业转型发展,2013年8月南方报业全面启动“创新媒体云”项目。该项目意在将云计算、移动互联与大数据分析技术引入传统媒体行业,对用户需求进行精细分析和深度挖掘,为不同人群提供更及时、更权威、更个性化的信息资讯,为广告客户提供更精准、更到位的整合营销服务,项目建设首当其冲的就是最底层基础IAAS云平台的打造。
2 面临的主要困难
我们调研了近30多个业界领先的云平台厂商,面对众多的技术方案,我们需要思考以下几个问题:
1. 技术绑定问题。云计算技术还在发展中,厂家私有化协议较多,未形成统一标准,几大阵营争夺激烈,一旦选择,有可能被技术绑定。
2. 成本费用问题。采用商业化的云软件,例如vmvare等使得整个IAAS项目建设和运维成本异常高,难以体现云计算节约成本的优势,不易获得集团支持。
3 开源架构——南方报业的选择
在调研中,我们发现大型互联网公司大都采用了开源技术架构,很多商业公司例如IBM、HP的产品也在底层大量应用开源架构,只不过在此之上再丰富开源架构的功能,包装成自己的产品予以销售。开源架构主要有以下几个方面的优势:
1. 开源云技术的发展特性吸引更多的IT厂商和互联网巨头应用推广,促进云计算基础架构成熟和相关标准形成;
2. 开源产品使得技术投入成本大幅下降,利于获得集团支持;
3. 开源技术的透明性利于培养自身团队,能通过多种渠道获得技术支持,一定程度上避免技术绑定,提高云平台研发运维的自主性;
当然采用开源技术也意味着我们需要通过自身的力量解决多种技术问题,在一定时期内有可能增加故障发生率,延长故障处理时间,但综合考虑开源技术优势,我们还是决定全面采用开源产品实施IAAS云平台建设,初期拟通过购买一些开源技术应急响应服务缓解运维压力。
4 南方报业IAAS基础云平台物理部署
根据业务分类,集团需建设私有云和公有云,其中私有云主要处理集团管控及采编类业务,公有云则处理新媒体公众服务类业务,由于两朵云在面向对象、业务种类、带宽资源上有明显区别,因此将私有云部署在集团机房,而公有云则部署在IDC机房,两者通过光纤连接,并设置严格的安全管控策略。为简化工程复杂度,利于项目实施,集团首先启动私有云IAAS平台建设。
私有IAAS云根据开发、测试、业务的需要设置子区域,各区域采取VLAN划分或物理方式隔离,部署如下图:
5 南方报业IAAS基础云平台管理架构设计
根据功能划分,南方报业IAAS基础云平台管理架构分为三大部分:IAAS基础云平台管理系统、核心支撑系统和辅助支撑系统。其中IAAS基础云平台管理系统的主要功能是整合计算、网络、存储资源,并按照需求自动分配或回收这些资源;而支撑系统主要包括监控、配置、负载均衡等,主要监控系统的运行状况,实现软件的自动部署和高可用。
5.1 主要软件产品选型分析
1. IAAS基础云平台管理系统:OpenStack,目前最主流的云计算开源框架,我们采用了其最新版本Icehouse。OpenStack有很多的组件模块,根据业务需要,我们将选择启用以下组件:
1) Nova:管理云的计算资源、网络、授权及调度。Nova通过Web服务API来对外提供处理接口,这些接口与Amazon的Web服务接口是兼容的。
2) Keystone: 为所有的OpenStack组件提供认证和访问策略服务。
3) Glance: 用于虚拟机镜像发现、注册、检索等管理服务。
4) Horizon: 管理、控制OpenStack服务的Web控制面板。
5) Swift: 提供一种分布式、持续虚拟对象存储服务,用API接口提供对象存储服务。
6) Cinder: 核心功能是对卷管理,整合后端多种存储,用API接口提供块存储服务。
7) Ceilometer: 数据采集(监控数据、计费数据)模块,采集到的数据提供给监控、计费、面板等项目使用。
2. 核心支撑系统:
1) 基础操作系统:OpenStack官方文档支持RHEL、CentOS、Fedora、Ubuntu、Debian、OpenSUSE等。基于集团已熟练应用CentOS的现状,选择CentOS。
2) 底层关系型数据库:OpenStack官方支持MySQL和PostgreSQL作为其底层数据库服务器,两者均可以稳定地提供数据存储服务。MySQL是目前开源社区内应用最为广泛的关系型数据库管理系统,各种解决方案也较为丰富,运维成本较低。根据实际生产环境案例的经验,双主MySQL方案在大中型OpenStack环境下经受了负载压力的考验,基于上述考虑,拟采用MySQL作为底层数据库服务器,采用Galera作为其集群解决方案。
3) 底层消息队列系统:OpenStack官方支持RabbitMQ与Apache Qpid作为其底层消息队列服务器,两者均可以稳定地为OpenStack提供消息队列服务,但RabbitMQ应用更广泛,因此选择RabbitMQ。
4) 底层虚拟化管理程序:比起其他的虚拟化管理程序,OpenStack对KVM和Xen的支持最好。相对KVM,Xen的性能更好,但配置和维护更加复杂,并且会给系统内核升级等工作带来更大困难,因此选择KVM。
3. 辅助支撑系统:
1) 监控系统:监控物理机与虚拟机性能,OpenStack平台各组件服务状况的监控是由OpenStack的Ceilometer组件负责。业界常用的开源性能监控系统主要有Zabbix、Nagios和Cacti等。Zabbix从功能、易用性、可扩展性以及应用广泛性上都要优于另外两者。为提高OpenStack平台的稳定性,将监控所需数据库与云平台数据基础库分离, 考虑到PostgreSQL技术特性及集团已有相关人才储备,选择PostgreSQL作为监控数据库。
2) 配置管理系统:业界常与OpenStack配合使用的开源配置管理系统主要有Chef和Puppet。其中Chef社区支持较好,并且OpenStack的发起人之一Rackspace也提供了基于Chef的OpenStack自动化部署方案,这将极大地节省部署时间,避免人工参与可能造成的错误。此外,Chef在性能方面优于其他方案。
3) 负载均衡系统:HAProxy提供基于TCP和HTTP应用的代理,支持虚拟主机。Keepalived的作用是检测服务器的状态,HAProxy+Keepalived组合是免费、快速并且可靠的高可用负载均衡解决方案。
4) 授时系统:采用NTP,它是用来使计算机时间同步化的一种协议,提供高精准度的时间校正。
5) 非关系型数据库:由于传统关系型数据库不适合存储云平台产生的大量监控数据和日志数据,因此,按照官方推荐,方案选择使用Mongodb数据平台存放Ceilometer产生的日志数据。Mongodb是非关系数据库当中功能最丰富,最像关系数据库的。它的特点是高性能、易部署、易使用。
6) 分布式存储系统:方案选择目前OpenStack社区使用最广泛的Ceph项目作为分布式存储系统。它可以同时提供对象存储、块存储。
综合上述分析,云管理平台模块选型如表1所示。
5.2 软件部署架构设计
OpenStack集群内的物理服务器按照服务功能分为三类,即管理节点、计算节点和存储节点。
管理节点上运行云平台的认证与授权、虚拟镜像服务、MySQL数据库、RabbitMQ消息队列服务等,负责云平台管理控制;
计算节点负责承载所有的虚拟机,部署OpenStack计算节点模块,负责提供云平台计算能力;
存储节点则作为存储服务后端挂载存储设备,分为传统集中式存储和分布式存储,运行OpenStack的Swift、Cinder模块,提供对象存储和块存储服务。
云平台各组件可按照其重要程度分为两类。重要程度较高的组件例如关系型数据库系统、消息队列系统等,此类系统一旦停止服务,将影响IAAS云平台管理系统的功能,因此这类系统均需要按照高可用的解决方案来部署。重要程度较低的包括授时系统、监控系统、配置管理系统、软件包镜像和网络启动安装系统,此类系统出错后不会对基础云平台的功能造成直接影响,尽快排除错误或恢复备份即可。
云高可用设计分为硬件和软件两部分,硬件高可用设计分为计算资源高可用、网络高可用及存储高可用,软件高可用设计分为云平台高可用及应用的高可用。
计算资源高可用主要为云主机提供动态迁移,这是为了避免物理机的单点故障,在物理机突发宕机时,云主机可以动态迁移到其他物理机上,以缩减业务宕机时间。但这需要部署共享存储。
网络高可用设计主要体现物理机网络和云主机网络两方面。物理网络即服务器网卡、接入和汇聚交换机都采取冗余连接。云主机网络方面,计算集群中每个节点均额外部署网络虚拟化(nova-network)以及元数据服务(nova-api)模块,避免单点故障。
存储系统的高可用性包括本地存储以及网络存储。计算节点服务器均本地硬盘做RAID1,网络存储盘做RAID5。对象存储服务采取数据冗余设计和多代理节点负载均衡部署方式提供高可用能力,而块存储服务则主要依靠其后端的存储自带高可用机制。
云计算平台高可用设计主要体现在各个控制节点的服务高可用上。控制集群采取冗余方式避免控制节点、管理服务、底层的数据库和消息队列的单点故障。
应用层的高可用性由应用层解决,需支持分布式部署。
5.3 存储系统设计
云平台存储利用传统集中式存储和新的分布式存储技术提供对象存储、块存储服务。
1. 对象存储:部署OpenStack的Swift组件,并与Glance进行集成,存储云主机模板及提供备份的存储后端等。
2. 块存储服务:部署OpenStack的cinder-volume模块,为虚拟机提供iSCSI形式存储,扩展云主机的存储空间。
集中式存储运维技术成熟,适合为数据库类型系统提供直接访问服务,云平台初期的存储主要由集中式存储提供。
分布式存储可任意扩展伸缩,在达到一定规模之后,能提供更好的IO性能,且单位存储空间成本明显低于集中式存储。但由于技术较新,缺乏运维经验,因此先对开发测试区域提供服务,待积累一定经验后,逐步向生产区域推广。为发挥分布式存储高IO处理的特长,分布式存储区域建立万兆网络。
云平台虚拟机动态迁移功能需共享存储资源支持。虽然集中式存储同样能实现共享存储,但云平台的规模会使得它在IO处理能力上出现瓶颈,因此适宜采用分布式存储提供共享存储服务。初期,云平台仅为开发测试业务提供虚拟机动态迁移能力,待分布式存储具备生产环境使用能力后再为生产系统提供虚拟机动态迁移功能。
5.4 网络架构设计
OpenStack中管理虚拟机网络共有两种方式,novanetwork和neutron。尽管OpenStack官方推荐使用neutron,但由于nova-network结构简单、稳定,有大规模使用案例,而以“软件定义网络”(SDN)为核心的neutron由于部署、维护复杂且未有大规模生产环境中成功案例,因此采用novanetwork来管理虚拟机网络。
在nova-network模块中,共有三种工作模式可供选择,Flat、FlatDHCP和VLANManager。其中VLANManager由于可以实现多租户网络隔离和计算节点上网络的高可用性部署,因此采用VLANManager模式管理虚拟机网络。
5.5 IAAS云架构逻辑图(见图3)
6 现有软硬件系统的迁移与整合
云平台建成后,原有软硬件经评估、测试后迁移至云平台。
硬件系统的整合流程如图3所示:
最低的配置原则建议:中央处理器为64位并支持虚拟化功能、至少具备两个千兆以太网口、服务器购置时间不超过两年等。
软件系统迁移有以下建议:
1. 原则上先将启用开发测试云,以检验云平台的稳定性;
2. 将业务系统按重要程度分级,按照从低往高的次序分批进行云迁移适应性评估测试,评估可行的才能迁至云平台;
3. 应用迁移应尽力避免服务中断,可先行在云平台上搭建目标系统,再进行数据备份与迁移,待测试稳定后,停止原有系统的运行并保留一段时间。
7 结束语
开源架构具备技术架构灵活、大幅降低成本、提升技术掌控力等优势,但是也将技术人才的培养提到了至关重要的位置。它把原来需要投入给软硬件平台的资金转向投入自身技术团队培养,集团采用开源架构建设IAAS平台是慎重考虑的结果,这个决定将使得整个技术部经历一个较长阵痛期,但是我们认为这种经历长远来看是值得的,它将全面提升集团信息技术人员的专业能力价值,向真正的互联网新媒体迈进。
IaaS云服务 篇3
加利福尼亚的Yourseff和IBM华盛顿研究中心的Butrico的等人根据可组合性对云系统进行了分类, 并重点介绍了云的层次栈[1], 阐述了个层次的内涵、作用、架构, 并分析了它们之间的相互关系。Yourseff等人认为云计算可以看做是一种新的计算机范式, 云计算的发展, 很大程度上是建立在现有的技术基础之上的。除了集群、网格计算和并行计算, 还包括了虚拟化技术。这些技术为云计算的诞生奠定了坚实的基础, 当然P2P、SOA等技术也间接的对云计算技术的形成产生影响。
Yourseff等人对云计算的各个组件进行了归类, 并阐明了它们之间的相互关系, 并将云计算的三种服务 (Saa S, Paa S, Iaa S) 归属到云系统的不同软件架构层。如图1所示。
2 Paa S形式的云计算架构
Hadoop是一个开源的云计算平台, 它实现了Google云计算的主要技术。我们可以知道Hadoop是属于Paa S的。Hadoop可以在大量廉价的机器组成的集群中运行, 能够为用户提供低成本、高效率和高可靠性的服务。Hadoop平台中最重要的两个架构是Map Reduce和HDFS (Hadoop分布式文件系统) , 但还有其它的子项目提供补充性服务。
Core:一系列分布式系统和通用I/O组件和接口, 是整个Hadoop项目的核心。
Avro:一种提供高效、跨语言RPC的数据序列系统, 提供持久化数据存储。
Map Reduce:分布式出数据处理和执行环境, 运行于大型的商用集群。
HDFS:运行于大规模集群、提供高吞吐量的分布式文件系统。
Pig:运行在Map Reduce和HDFS之上的数据流语言, 用以检索非常大的数据集。
Hbase:一个使用HDFS作为底层存储的分布式、列存储数据库系统。
Zoo Keeper:一个分布式、高可用的协调服务, 用以解决一致性问题。
Hive:管理HDFS中存储的数据, 提供基于SQL的查询语言, 是一个分布式数据仓库。
C h u k w a:分布式数据收集和分析系统, 运行HDFS中存储数据的收集器, 使用Map Reduce来生产报告。
3 Iaa S层的云计算架构
Eucalyptus[1]是专门用于支持云计算研究和基础设施的开发。它对应于基础设施即服务 (Iaa S) 层。Eucalyptus实现的Iaa S的特别之处在于它容易在研究环境中进行安装和维护, 以便于修改、实验和扩展。在研究环境下, 系统不可能为基础设施中的每个软硬件资源指定一个配置, 也不可能有大量的资源来保障系统的性能。因此, Eucalyptus是Iaa S中一个比较独特的例子, 也是未来的多集群开源设计的先驱。
不同于其它的云计算提供商所提供的云计算系统, 它所使用的计算和存储基础设施如集群和工作站可为学术研究组织所用, 为科研人员提供了一个开放的研究和试验平台, 该平台为用户提供了运行和控制部署在各种虚拟物理资源上的整个虚拟机实例的能力。Eucalyptus的设计强调模块化, 方便研究人员对资源调度、扩展性、安全性等进行实验分析。
4 构建综合形式 (Paa S+Iaa S) 的云计算架构
Google的云计算架构是基于Paa S和Saa S层的, 为用户提供平台服务如Google Ap p Engine, 也为用户提供软件服务, 如Goog le Docs等。当是由于Google的云计算系统是不开源的, 所以不可能获得Google的云计算系统。不过Hadoop恰恰是Google云计算系统的开源实现, 可以免费获得。所以我们将使用Hadoop做为我们Paa S层的云计算架构。如4.1节所讲的那样, Hadoop有很多的特点, 并且提供了很多服务, 如Hbase, Zoo K eeper, Pig等上层服务。
作为Iaa S的云计算架构也很多, 如Open Nebula、Eucalyptus等。之所以选择Eucalypt us作为我们的Iaa S的云计算架构, 主要是它是基于模块化开发, 而且面向对象的主要是科研人员。由于实验环境下, 物理机器资源不够, 所以Eucalyptus将主要向Paa S提供虚拟机实例。
安装环境为操作系统是Cent OS5.4, 虚拟机为Xen 3.0, Eucalyptus的版本为1.6.2。Euca2tools为1.2, Hadoop为0.20.1, JDK1.6。环境中共两台物理主机, 在一台物理主机上安装CLC, CC, WC, SC等节点, 在另一台物理主机上安装NC节点。pc XXX的IP地址为192.168.0.1, pc YYY的IP地址为192.168.0.2。把pc XXX作为Namenode和Job Track er, pc YYY中由Eucalyptus提供出来的虚拟机作为Datanode和Task Tracker。如图2。
Eucalyptus安装好后, 可以通过命令行启动前端和后端节点上的相应服务, 然后通过设置Eucalyptus的相应配置文件, 可以选择网络管理模式等。初期选择的是最简单的网络模式, 即VNET_MODE=SYSTEM。这个模式只能设置局域网中虚拟机的ip地址, 如果需要设置不同的外网及内网ip, 可以采取S T A T I C及M A N A G E D模式等。
5 结语
本章主要介绍了云计算平台体系结构方面的内容。首先介绍了两种体系结构的划分, 分别是Lenk等人和Yourseff等人的划分方法。然后介绍了Paa S的概念和基本功能, 并研究了P a a S层的云计算架构——Hadoop。其次, 再介绍了Iaa S的概念和基本功能, 研究了Iaa S层的云架构——Eucalyptus。最后, 针对现行的云计算平台提供的服务类型都比较单一, 要么是S a a S层的, 如Sale Force。要么是Paa S层的, 如Google App Engine。要么就是Iaa S层的, 如Amazon EC2等。为了提供更全面的服务, 本论文在其它开源软件的基础之上, 构建了一个既可以提供Paa S层服务又可以提供Iaa S层服务的云计算架构平台。
参考文献
[1]刘鹏.云计算, 2010.
[2]云安全联盟.云计算关键领域安全指南, V2.1, 2009.
[3]刘鹏.云计算发展现状.http://www.chinacloud.cn/show.aspx?id=754&cid=11.2009.
[4]Jeffrey Dean, Snjay Ghemawat.MapReduce:Simplified Data Processingon Large Cluster[C].OSDI, 2004.
[5]Sanja Ghemawat, Howard Gobioff, Shun-Tak Leung.The Google filesystem.SOSP, 2003.
IaaS云服务 篇4
云计算是一种新型的计算服务模式,以互联网为媒介,将资源虚拟化,按需为用户提供计算能力,正越来越广泛被接受和采用。云计算包括三种不同的服务模型:SaaS(软件即服务),PaaS(平台即服务),IaaS(基础设施即服务)[1]。云计算服务作为分布式计算的扩展和延伸,同样面临着QoS(服务质量)的管理问题,QoS管理通常以签订合适的SLA(服务等级协议)来实现。SLA规定了服务商在服务提供过程中必须满足的QoS属性——通常是以一系列的SLOs(服务等级目标)来定义。由于在服务提供过程中,这些QoS属性不断变化,同时也是为了保证SLA的实施,这些QoS属性需要被密切监控[2]。SLA既可以保障用户的利益(如违例之后的惩罚等),又可以帮助服务提供者有效地管理其资源。为了更好地创建和实施SLA,SLA协议文档的标准化是非常必要的。
虽然目前SLA没有一个统一的定义,但是在实际应用中,有两个比较成熟的标准:OGF提出的WS-A[3]以及IBM公司提出的WSLA[4]。这两种标准都基于XML来定义SLA文档。服务的描述通过WSDL实现,WSDL是一种用来描述Web服务和说明如何与Web服务通信的XML语言。因为WSDL是基于XML的,所以它既是机器可阅读的,又是人可阅读的,这将有利于SLA的自动协商与实施。经过对WS-A和WSLA的分析,发现虽然两者对整个SLA生命周期、监控以及SLA的管理都有描述,但其主要关注参与者、参数、保证等相关内容,对于这个协议到底是通过什么协商方式确定以及采用何种监控方式没有明确的规定。因此本文尝试在WSLA的基础上补充协商方式的相关描述,采用类似面向对象编程中类型与实例的概念,定义协商类型与协商实例。由于在WSLA中SLA参数以及SLOs的设置是完全开放的,用户和服务提供者可以根据实际的需求设计所需的参数和SLOs。云计算中有三种不同类型的服务,参数的设计根据服务类型的不同也会有所区别。本文将针对IaaS服务类型设计一些基本的参数,并且采用符合WSLA标准的XML语言来描述,此外还将提出一个协商协议用于具体的协商实施。上述工作实现了满足云计算IaaS服务的扩展WSLA,我们称为I-WSLA。
1 WSLA与协商协议
1.1 WSLA
WSLA是IBM公司提出的SLA框架。按照IBM公司的定义,WSLA有一套基于XML的语言用于服务描述,用户与服务提供商都可以通过WSLA来配置和管理自己的服务,其中部分内容可能需要第三方来辅助实现,比如参数的协商与监控等。通过一系列的协商,用户和服务提供商最终将会得到一个WSLA文档。文档定义了服务提供商所需提供的服务以及与服务相关的一些参数的保证,比如响应时间和吞吐量等。此外,还包括当服务提供商不能满足保证时要采取的措施,如通知发生违例等。在文档中还包含具体的度量与参数的定义,并且明确规定由哪一方来进行监控。
WSLA具备一般SLA的基本结构:参与者,SLA参数,用于计算SLA参数的输入,计算SLA参数的算法、服务等级目标以及这些目标未满足时应采取的行为。它通过参与者、服务描述、服务责任来描述以上内容。参与者确定所有协议的参与方,服务描述详细规定服务的特点以及用于监控的参数,服务责任规定SLA参数的保证与约束。
WSLA面向广泛的网络服务,云计算作为网络服务的一种新形式,显然是可以采用WSLA来保证服务的QoS,但是由于云计算具有一些自身的特点,直接应用WSLA可能无法准确的表达。
1.2 协商协议
协商协议是在协商过程中,双方所必须共同遵守的规定或规则。适用于WSLA的协商协议有许多种,完全自动化的机器可识别的协商协议将为云计算服务的协商提供很大的便利。为了描述这样的协商协议,需要明确一些协商元素,通过不同协商元素的组合可以制定出不同的协商协议。Alessio等针对电子商务环境,提出一个一般化协商元素的定义[5]。该定义虽然不能完全适应云计算环境下的SLA协商,但其关于自动协商和协商参数的内容值得借鉴。Peter等认为拍卖是一种特殊的协商,采用分类法定义了一系列拍卖的元素[6],并将其扩展到多维拍卖中[7]。本文将采用拍卖的协商方式来设计协商协议。
我们针对云计算SLA协商协议的研究,考虑了以下几点:云计算SLA通常包含许多参数,故协商协议需要支持多参数协商(同步或异步);云计算SLA中的参数不一定是同质的,故适用于传统的同质参数的协商协议不一定适用于云计算SLA协商;本文主要关注拍卖协商方式,故结合拍卖的特点来设计协商协议;最后,协商过程需要在网络上进行,协商协议的自动化是非常有必要的,所以协议的格式必须是严谨的并且是电脑能够自动识别的。
2 IaaS的参数设计与描述
IaaS、PaaS和SaaS三类云计算服务类型在用WSLA描述时可以通过不同的度量来区分,本文重点关注IaaS的WSLA描述。根据IaaS的特点,我们设计的度量主要考虑:1)服务可用性,表示云计算基础设施在一段时间内正常服务的概率;2)可扩展性,在云计算服务中有一些资源的需求可能是弹性的,可扩展性就是指这类资源的动态增加或减少,这样既能帮用户最大化收益,又能帮服务提供者最优化资源配置;3)成本计算,云计算服务是按需使用、按使用付费的服务,用户有权了解自己为那些资源支付了费用,服务提供商知道如何计算成本。
IaaS中需要考虑的度量很多,需要规定下列几个较重要的度量:CPU能力、内存容量、启动时间、存储容量、VM(虚拟机)递增量、VM递减量、VM递增时间、VM递减时间、是否支持自动扩展、可配置VM数量、可用性、响应时间等;此外,还要考虑到一般SLA的度量:监控、帐单、安全性、网络、隐私、服务支持、法律法规等[8]。
WSLA中也有度量的概念,但是WSLA的度量被分成资源度量和复合度量两类。在I-WSLA中度量直接采用了WSLA度量的定义,如下所示:
具体的资源度量和复合度量都是按照一般度量来定义的,区别在于资源度量是能直接在服务提供商处检索到的资源,而复合度量是由多个资源度量或者已有的复合度量按照某一算法生成的。
根据上述IaaS度量、一般SLA度量和WSLA中度量的定义,我们发现上述的绝大部分度量都可以直接按照WSLA的定义应用到I-WSLA中。IaaS中的CPU能力、内存容量、存储容量、VM递增量、VM递减量、是否支持自动扩展、可配置VM数量可以直接定义为资源度量,其中前三个度量是服务提供者系统中真实存在的资源,后面的度量都可以变量的形式存储在系统中供检索。IaaS中的其他几项度量均可以定义为复合度量。资源度量在WSLA中的定义非常简单,只要按照格式确定一个名字、来源、检索方式即可。复合度量相对复杂一点,除了名字之外,还需给出该度量的计算方式。
一般化的SLA度量(除网络可以直接用度量来定义)就不能直接套用WSLA中度量的概念,但是WSLA有其他方法来表达这些信息。监控在WSLA中是开放的,可以直接用IBM在WSLA体系中定义的监控模式,也可以用第三方来监控,这部分内容在WSLA协议中会给出说明。帐单是服务花费的计算,这块是WSLA中不包含的,但提供商有一套计算的办法。安全性、隐私、法律法规也是WSLA协议关注的内容,它们是服务提供商提供服务所必须保证的先决条件,但目前上述内容的度量表达或监控尚有困难,因此该方面内容以固定形式出现在WSLA协议中,而有关此方面的协商本文暂不涉及。关于服务支持,WSLA中有一套完整的定义。服务支持参与者定义了除签约双方之外提供辅助服务的主体,在WSLA的部署过程中,服务支持参与者只会获得自己服务所必需的信息(一部分的WSLA协议文档),并完成自己分配到的任务。
前面介绍了IaaS度量的WSLA描述,尚未涉及到WSLA中的参数。SLA参数是指一个能够被观察的服务性质,并用SLO(服务等级目标)来实现对该参数的保证。但WSLA中的参数不同于一般意义上的SLA参数,它必须基于度量,每个参数都需要引用一个度量,该度量可以是单个度量或者是多个度量的聚合,这个度量决定了对应参数的数值如何计算。此外一个参数还要包括它的来源和授权。在I-WSLA中SLA参数类型的一般定义也沿用了WSLA中的定义,如下所示:
设定参数之后,接下来需要定义基于参数的服务等级目标SLO以及SLO不能达到,即违例时应采取的行为。I-WSLA中的SLO与违例处理采用与WSLA相同的方案。
3 协商类型与实例描述
前面已经介绍了I-WSLA中IaaS的WSLA描述,下面将对SLA的协商过程进行描述。WSLA中并未对SLA的协商过程作具体规定,因此我们希望能在WSLA中补充协商过程的定义,也就是对每个WSLA都规定一个具体的协商方式。但是由于在实际操作过程中,协商方式有许多种,而且一个协商方式中由于个别条件的不同可能会细分成几个不同的具体协商,我们借鉴Sebastian等提出的协商类型与协商实例的概念[9]。
这里的类型与实例的概念与面向对象编程中的概念相一致,协商类型定义了基本的协商的类以及这些类中的公共属性,而协商实例则是在此基础上的更具体的协商。协商一般指是指双方或多方在一定时间范围内就某些有争议的内容进行沟通,争取达成一致。在I-WSLA中在定义一个基本协商类型时,从一般化的协商出发,公共属性至少要包括协商类型标志、参与者的类型(抽象的类型,不包含具体协商参与者的内容)、协商开始时间与截止条件、所协商的事物以及采用的协商类型所特有的内容(比如拍卖协商类型中的报价规则)。协商实例要初始化协商类型的公共属性,比如该协商实例具体的开始和截止条件等。开始和截止条件可以设置为具体的时间,也可以设置为某些限定条件,如从接到一个开始消息开始该协商到接到一个结束消息结束该协商。此外,两者最大的区别在于还要设置一个协商实例标志,表明该协商实例是用于哪个具体协商过程,同时不同的协商实例也可以通过该标志进行区分。最后,具体的协商的具体参与者的相关内容只出现在协商实例中,不同的协商实例的具体参与者也有所不同。因为在定义协商类型时,没有必要知道具体参与者的信息,只需要定义可能的参与者的类型,这样也使得协商类型能独立于具体的协商过程。因此关于某一个协商类型可能参与者类型的研究是在定义一个协商类型时要调研的问题。
以拍卖协商方式为例,协商类型中包括协商类型标识(Auction)、协商开始与结束的条件;参与者类型(拍卖者与竞标者);竞标者的动作,包括向拍卖者报价,向拍卖者查询等,报价需要遵循的规则;拍卖者的动作,包括响应报价、响应查询、发送通知等。协商实例要给出更具体的细节,比如本次协商实例的标识符、标的物和开始、结束的具体时间,本次协商的参与者是一对一、一对多或者多对多,拍卖者最后决定竞标成功者的规则(具体有英式、荷式或者次高价暗拍等)等。
在I-WSLA中,协商类型的定义需要给出协商类型的标识符、参与者类型这些基本信息。而对于同一个协商类型下的不同协商实例,对公有属性的具体设置不同。I-WSLA利用Michael等对拍卖所采用的分类学方式,将一个拍卖分解成多个参数,不同的参数组合构成一个特定的拍卖[6]。因此,I-WSLA的协商实例中可能用到的参数定义如下:
在定义一个具体的拍卖协商实例时,除了确定具体的开始、结束时间之外,只需要在上述不同协商类型参数中作一个组合就能构成一个特定的拍卖。比如英式拍卖需要组合{1:n}、{new bid should larger than latest bid}、{activity}、{schedule}、{Mth-price}即可。I-WSLA的一个英式拍卖实例如下所示:
4 协商协议
前面已给出协商类型与实例的定义,但协商过程的实现还未描述。一般来说,协商可以看作一个报价过程,如竞拍者提供一个报价,拍卖者接受报价、拒绝报价、提出还价或者终止协商。在一对一的协商中,报价过程比较简单,双方一直报价还价直至最终达成一致或不一致(一般在一个规定的时间范围内)。前文提出的协商类型不仅仅是一对一的,因此需要实现一对多甚至多对多的协商协议。整个协商过程我们通过消息机制来实现,所需消息如下所述。
竞拍者在协商过程中需要提出报价,需要一个报价消息(offer)。拍卖者在收到许多报价之后需要对报价进行处理,在协商结束之前并不会做出最终的决定,但是会有一个当前最优的选择,这个信息储存在当前协商状态中,所有的拍卖者应该可以查询当前协商状态,需要一个查询当前协商状态的消息(getstatus),以及对于这个查询的回复(returnstatus)。协商结束之后,拍卖者需要给所有的竞拍者发送信息,告知其报价是否被接受,因此需要接受报价消息(accept)和拒绝报价消息(reject)。另一种情况是用户对报价进行还价,那么需要一个还价信息(reOffer)。由于每个参与者可能同时参与多个协商,在不同的协商中扮演不同的角色,所有的消息必须还有协商的标识符以及其他一些必要信息以示区分。此外还需要一个广播消息(startnegotiation),告诉所有的竞标者,该次协商开始。
具体的消息设置如下:
① Offer(agentId,negotiationId,price);
② reOffer(agentId,negotiationId,price);
③ GetStatus(negotiationId);
④ ReturnStatus(negotiationId);
⑤ Accept(agentId,negotiationId);
⑥ Reject(agentId,negotiationId);
⑦ StartNegotiation(negotiationId)。
通过以上7类消息的不同组合,实现具体的协商实例。如在IaaS中采用I-WSLA实现次高价密封拍卖,该协商实例是一对多(或多对一,即逆向次高价密封拍卖)情形。需要设置一个协商平台,IaaS用户和IaaS服务提供者都在该平台上注册登记。整个协商过程如图1所示。
具体描述如下:
1. 用户广播开始某个标的物协商的信息⑦;
2. 每个服务提供商发送一个密封报价①给用户;
3. if(服务提供商i的报价是所有报价中最高的)
{用户发送接收报价信息⑤给服务提供商i}
/*由于该协商实例时一个次高价拍卖,得标的提供商所需支付的价格为次高价*/
else
{用户发送拒绝报价信息⑥给服务提供商i}。
上述实例中没有用到消息③④,因为次高价密封拍卖情形下无需查询当前的协商状态,但是在其他的一些实例中,比如英式拍卖时,用户有权知道其他用户的报价,并且在拍卖截止之前可以一直报价,此时就有必要使用消息③④来获取当前协商状态。
5 结 语
本文提出了一个适用于云计算IaaS的扩展WSLA——I-WSLA框架,该框架将云计算IaaS类型的服务用WSLA规定的格式描述,补充了协商协议与协商实例的定义,结合了参数化的概念,使得各种不同的协商过程都可以统一在一个框架下。与此同时,给出了一个通用的协商协议,可以适用于各种不同类型的协商过程。因此I-WSLA框架可以支持各种类型的协商,可以适应各种类型的云计算IaaS服务应用。整个协商的结果是一个扩展的WSLA文档,协商协议可以用机器可识别的语言定义,整个协商可以实现自动化。
参考文献
[1] Mell P, Grance T. The NIST definition of cloud computing (draft) recommendations of the National Institute of Standards and Technology[S]. NIST special publication,2011,145(6):1-2.
[2] Keller A, Ludwig H. The wsla framework: Specifying and monitoring service level agreements for web services[J]. Journal of Network and Systems Management,2003,11(1):57-81.
[3] Andrieux A,Czajkowski K,Dan A, et al. Web services agreement specification (WS-Agreement)[S]. Global Grid Forum,2004(2).
[4]Ludwig H,Keller A,Dan A,et al.Web service level agreement(WS-LA)language specification[S].IBM Corporation,2003.
[5]Lomuscio A R,Wooldridge M,Jennings N R.A classification schemefor negotiation in electronic commerce[J].Group Decision and Negoti-ation,2003,12(1):31-56.
[6]Wurman P R,Wellman M P,Walsh W E.The Michigan internet Auc-tionBot:a configurable auction server for human and software agents[C]//2nd international conference on autonomous agents,pages,1998:9-13.
[7] Wurman P R,Wellman M P, Walsh W E. A parametrization of the auction design space[J]. Games and economic behavior,2001,35(1-2):304-338.
[8]Alhamad M,Dillon T,Chang E.Conceptual SLA framework for cloudcomputing[C]//4th IEEE international conference on digital ecosys-tems and technologies,2010:606-610.