标签 IaaS 下的文章

IaaS层实现思路

云计算,什么是云计算,它到底离我们有多远?
这些内容我已经在《云计算的定义和特征》中阐述过了,需要看的朋友可以再去翻出来看看。
这篇文章我们重点讨论IaaS
IaaS的使用者是谁?IaaS能提供怎样的服务?他们怎么利用提供的服务?
是研发人员,有了IaaS层以后,他们就不需要等待公司的流程,盼星星盼月亮似地等着审批机器。IaaS层提供资助服务,完全可以由使用者自助申请,通过云管理平台审批,而后得到想要的机器。这种是直接提供虚拟机。
还有一种场景,我的IaaS层在外面是看不到东西的,这里的IaaS层只是为内部的中间件提供一个可部署、易维护的一个环境,而用户使用的服务是中间件提供的。这种我们得到的服务是间接的,看不到摸不着的。
我们可以像想,在我的I层有一堆的PC Server ,每台PC Server上都有内存、CPU、硬盘这些重要组件。虚拟化带来的切割资源,将一个性能较好的机器,切分成相对性能较差的机器。
未完待续……

Xen

Xen和kvm一样,都是虚拟化开源软件,拥有同样出色的架构设计和性能。Xen和kvm都用于构建IaaS层。
Xen 是一个开放源代码虚拟机监视器,由剑桥大学开发。它打算在单个计算机上运行多达100个满特征的操作系统。操作系统必须进行显式地修改(“移植”)以在Xen上运行(但是提供对用户应用的兼容性)。这使得Xen无需特殊硬件支持,就能达到高性能的虚拟化。
Xen通过一种叫做准虚拟化的技术获得高性能,甚至在某些与传统虚拟技术极度不友好的架构上(x86),Xen也有上佳的表现。与那些传统通过软件模拟实现硬件的虚拟机不同,在Intel VT-X支持下3.0版本之前的Xen需要系统的来宾权限,用来和Xen API进行连接。到目前为止,这种技术已经可以运用在NetBSD, GNU/Linux, FreeBSD和Plan 9系统上。在Brainshare 2005会议上,Novell展示了NetWare与 Xen的连通。与Windows XP连通的技术曾在Xen开发初期进行,但微软的协议未能允许它发布。Sun微系统公司也正在积极地将Solaris移植到Xen平台之上。
Xen虚拟机可以在不停止的情况下在多个物理主机之间实时迁移。在操作过程中,虚拟机在没有停止工作的情况下内存被反复的复制到目标机器。虚拟机在最终目的地开始执行之前,会有一次60-300秒的非常短暂的暂停以执行最终的同步化,给人无缝迁移的感觉。类似的技术被用来暂停一台正在运行的虚拟机到磁盘,并切换到另外一台,第一台虚拟机在以后可以恢复。
Xen目前可以运行在x86系统上,并正在向x86_64、IA64、PPC移植。移植到其他平台从技术上是可行的,未来有可能会实现。
Xen 是一个基于X86架构、发展最快、性能最稳定、占用资源最少的开源虚拟化技术。Xen可以在一套物理硬件上安全的执行多个虚拟机,与 Linux 是一个完美的开源组合,Novell SUSE Linux Enterprise Server 最先采用了XEN虚拟技术。它特别适用于服务器应用整合,可有效节省运营成本,提高设备利用率,最大化利用数据中心的IT基础架构。

运营商私有云聚焦IaaS/PaaS OSS系统应用重在内部服务

当前,国内各运营商在多个专业领域正不同程度、不同方向地进行云计算环境构建的尝试和实施工作。在这股热潮中,作为电信运营商中重要的支撑体系之一的OSS体系也在努力尝试和推进,以期紧随发展的步伐。
从当前运营商OSS体系来讲,基于客观的历史原因,每个省至少都存在着10余套支撑系统,而这些系统基本属于“烟囱型”的结构,即从服务器、存储、数据库、中间件、应用软件都是独立并完备的,系统间相互孤立分离,并在网络中通过VLAN的划分进行系统间网络隔离。
在这种背景下,业界对于“虚拟化”、“云计算”、“SOA”、“融合重组”的讨论非常热烈——运营商清晰地认识到过去由于受到历史客观原因的限制所采取的分散独立的建设模式已经无法满足未来的发展形势需要。在运营支撑系统不断完善改进的过程中,运营商也就不可避免地要搞清楚这些概念之间的关系,从而形成相对清晰的OSS体系云计算建设规划。
IaaS层亟待实现存储集中化
云计算基本分为IaaS、PaaS、SaaS三层架构,以此分析OSS体系,其要向云计算方向发展,也需要分层、分阶段地进行。IaaS主要包括网络、主机、存储几个方面,这部分实际上也是当前热度最高的环节,这与技术成熟度相关,更与硬件厂商的推动密不可分。
从当前技术发展角度来讲,实际上就是基于x86平台的虚拟化技术的成熟度最高,它在IT基础架构层面大规模地推动了“虚拟化”、“云计算”的实施。而其中的虚拟化可以认为是云计算的一个基础条件,无论是IT基础架构还是上层软件均需要考虑虚拟化技术所带来的变化。
按照以往经验,具体到OSS体系,运营商应当慎重审视如何推动IaaS的建设。按照当前的现状背景来讲,存储设备的集中化应当排在第一位——这部分分散建设的模式使得每套系统中均需要配置中低端的存储设备,而这些设备扩展能力又很有限,且存储对于系统相关性也是最差的,对于软件系统属于透明的存在,所以OSS体系的云计算环境构建,笔者认为,存储集中化应当排在第一位。
一个不争的现实是,OSS体系的核心模块绝大部分是基于UNIX小型机环境来研发,所以不能简单地将应用直接迁移到x86平台上的Windows环境或Linux环境,这其中需要解决非常多的技术问题。另外,对于中高端UNIX主机进行分区使用,从而规避部署大量的中低端UNIX主机,这与x86平台的物理服务器的配置部署原则是有区别的,这主要是由于技术区别而造成的。
当前的云计算环境构建不可避免地采取了“先集中化、再虚拟化”的建设模式,这样对系统运行安全性实际上构成了新的隐患。与传统的所谓“烟囱型”系统的区别在于它将所有的故障隐患也集中化,一旦某设备资源池出现问题,则将不再是影响一套系统,而是影响多套系统。而且OSS体系中存在大量的采用perl、awk等解释性语言编写的脚本程序,这些程序的典型特征就是高CPU负荷、高I/O负荷,这些程序能否适合部署在虚拟化环境中也还需要进一步的技术研究工作。
需要特别注意的就是,网络是云计算环境构建中不容忽视的重要环节。绝大部分的OSS系统均是按照每个系统一个独立VLAN进行建设的,那么在云计算环境中将大幅度增加网络设置的复杂性。而这部分恰恰是在推进虚拟化或云计算过程中最容易被忽视的环节。
PaaS层技术研究重点在ESB
对于PaaS层,当前OSS体系的技术研究的工作基本是集中在ESB方面,而对于如何构建平台层的研究却很少。从当前的发展方向来讲,对于PaaS这层,应当做到尽可能的“业务无关”——并不是与OSS无关,而是与故障监控、性能分析、业务流程等无关。除了ESB外,在PaaS层实际上还可以对数据库进行集中化,从而通过统一的安全策略和参数设置来形成统一的数据库支撑能力。
当前各个系统中数据库访问效率依然是一个非常典型和重要的瓶颈所在,主要原因在于当前各个系统开发商普遍缺乏代码研发人员与DBA密切互动。由此,数据库比较适宜进行适度的集中规划与部署,然后再“按需”分配能力来满足不同系统的使用需求,而这也恰恰符合云计算的理念。
OSS尚无对外服务打算
对于SaaS层来讲,当前运营商的OSS体系还不适用,因为OSS体系并不具备对外提供服务的能力。
OSS体系内的应用层系统和软件,现阶段的任务是追求如何去适应云计算环境,而不是盲目地追求提供对外服务。如果希望能力外暴,这实际上需要大幅加强软件的可配置性和快速响应能力。例如OSS中的监控系统是可以对外提供设备监控能力,但是在能力分离打包、资源模型调整、告警分析接入、监控规则适应等方面还存在反应速度慢的问题,这样实际上就基本无法达到SaaS的要求。而将内部服务作为系统应用则问题不大。这也是后续OSS应用软件需要重点关注的发展问题。
笔者认为,为了更好地可持续发展,OSS体系的应用程序层应当充分重视到SOA的发展,云计算与SOA是相辅相成的,只有软件符合SOA或者向SOA方向发展,才能逐步形成SaaS的能力,否则各个软件系统依然是孤立的系统。
总而言之,当前运营商OSS体系的建设模式决定了其服务对象是企业内部,甚至是部门内部。基于这种认知,我们需要非常慎重地看待“云”的需求,更应当学习“云计算”倡导的技术和理念,而不一定是过分地追求“对外服务”。