Cloudstack入门指南(txt+pdf+epub+mobi电子书下载)


发布时间:2020-05-26 21:15:46

点击下载

作者:中国Cloudstack社区编写小组

出版社:电子工业出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

Cloudstack入门指南

Cloudstack入门指南试读:

前言

云计算是一个被热炒多年但仍然热门的词,是一个大家张口闭口都在说但大部分人仍然云里雾里的词。IaaS(Infrastructure-as-a-Service)、PaaS(Platform-as-a-Service)、SaaS (Software-as-a-Service)的概念被提出后,各种各样的“aaS”也相继被提出,使云计算变得更让人摸不着头脑。但就是这样一个看似玄虚的词,正在我们未曾关注的地方发生着深刻的变化,真真切切地改变着我们的工作和生活。

在4年前,作为一个只知道名词而不知道何为云计算的小“菜鸟”,我义无反顾地投身于这个大潮中,Open Xen、桉树平台(Eucalyptus)及Ceph的整合让我形成了对IaaS平台认识的启蒙。那个阶段,在学习过程中,我想:如果做这样的东西就算是做IaaS平台的话,会不会对不起“IaaS”这么玄虚的字眼?很快,公司决定改变发展方向,直接使用CloudStack作为IaaS平台。

初一上手,CloudStack原有的商业产品基因、简单易用的安装和操作及美观易懂的界面就深深吸引了我。虽说那时的我也和正在读这本书的各位朋友一样,在安装和使用中遇到了各种问题,但其实这些都不是CloudStack的错,错在我们对使用一个IaaS平台的技术储备不足。在学习和使用CloudStack的过程中,我翻阅各种相关资料,向其他高手请教,学着分析日志——通过不同项目的实践,终于对CloudStack有了比较全面的认识。但至今,在工作中,我仍然感觉自己对这个平台所包含的技术及知识的了解尚浅,我仍然需要不断学习。

作为一个IaaS平台,CloudStack不再是一个简单的单机软件,而是为了管理超大规模的硬件设备而生的。它兼容各种虚拟化管理软件(Hypervisor),支持各种存储类型,通过软件及虚拟机实现了很多网络功能,尽可能将流程自动化并对用户提供服务。所以,要想玩转CloudStack,需要积累相当全面的背景知识,主要包括以下部分。● 了解Linux操作系统的配置,才能正确安装CloudStack软件。● CloudStack可以安装在KVM、VMware、XenServer及硬件服务器

上,未来还会对Hyper-V、LXC等更多的虚拟化技术提供支持,

这就要求我们要对每种虚拟化管理软件的使用有一定的了解。● CloudStack是一个基础设施的管理平台,对硬件设备(包括服务

器、存储和网络设备)的使用和管理有一定的要求。在规划和运

维一套大型云平台系统时,硬件设备的参数往往会对整个系统的

性能起着相当重要的影响。● 在运维CloudStack系统时,与网络相关的知识最为重要。IaaS管

理平台不再是单机软件,也就意味着它对物理设备有大量需求。

虚拟设备都需要通过网络进行连接,而生产业务上的各种功能需

求大部分也都是通过网络上的设计来实现的。所以,一个好的网

络设计起着事半功倍的效果,可以更好地保证系统运行的稳定性

及应对未来变化的扩展性。● 系统运维能力,以及系统出现问题后解决问题的能力,也都成为

运维CloudStack系统所必需的技能。

在刚刚接触CloudStack的时候,我们往往不会具备这么全面的知识,但这并不可怕。多在网上查找相关资料,多在社区里请教高手,多在邮件组里查找别人提出的问题及解决方案或者自行提问,都是非常好的学习方式。

本书内容

本书基于CloudStack 4.0.2版本编写,这是目前比较稳定的、拥有广大用户基础的一个版本,它出现的错误较少,适合新入门的朋友学习。希望借由我们的经验,通过深入浅出的介绍,带领各位新手入门。● 第1章对CloudStack的来龙去脉,以及CloudStack社区进行了相

关介绍,包括如何更好地使用CloudStack社区的宝贵知识财富、

Apache的许可证对CloudStack的使用有哪些界定等。● 第2章介绍了CloudStack的基本架构,以帮助读者对CloudStack

形成整体认识。● 第3章介绍了CloudStack的网络架构,理解此部分,对实际规划

系统有很大的帮助。● 第4章和第5章是本书的重点,通过介绍一个简单、通用的

CloudStack环境的规划及安装配置,帮助读者学习如何安装一套

CloudStack系统并管理不同的虚拟化管理软件。建议读者在学习

过程中严格按照步骤及规划进行操作和配置,从而尽可能保证系

统的正常运行。我们的实践经验是:在一开始对CloudStack并不

了解的时候,不严格按照步骤进行操作最容易出现问题。所以,

在成功安装一套可以正常运行的CloudStack系统后,才能更好地

理解CloudStack,并且能获得一定的成就感和信心。此后,再通

过自己的理解去规划和安装自己想要的CloudStack系统,就会对

CloudStack有更全面的了解。● 第6章介绍了CloudStack的各项基本功能,包括虚拟机的生命周

期管理、如何上传模板及ISO文件、虚拟机实例的访问方式、磁

盘卷和快照的管理、服务方案的管理、域和账户的管理、项目功

能的使用。因为本书定位为入门级,所以就不介绍更多的高级功

能了。● 第7章介绍了CloudStack开发的相关入门知识,包括如何获取代

码、如何编译和调试代码等,并对API进行了简单的介绍。

致谢

本书能够完成,离不开本书各位作者的努力。在此感谢共同编写本书的各位作者:刘宇超、李学辉、白清杰、魏伟、曹伟、王磊、杨康泉、谭运华、袁帅、马营,也感谢梁顺斌、王耀峰为本书做出的贡献。虽然这些作者都是第一次写书,但还是尽最大努力将CloudStack的相关知识及经验介绍给各位读者。

另外,还要感谢各位作者的家人。没有他们的大力支持,我们是不可能在业余时间安心地花费大量时间写作本书的。

感谢支持本书的各位读者,希望书中的内容可以帮助大家更好地理解和使用CloudStack。

本书在编写过程中难免会有疏漏和错误之处,欢迎大家批评、指正。中国CloudStack社区编写小组2014年7月1日

主要作者简介

刘宇超

CloudStack中国社区管理员之一,社区技术沙龙活动的主要组织者之一,本书的主要组织者和作者。对CloudStack有多年研究经验,曾帮助多家企业实现CloudStack在公有云或私有云项目中落地,目前在Citrix任云平台咨询顾问一职。

李学辉

CloudStack中国社区创办者,Apache CloudStack Committor,天云趋势高级技术经理。拥有3年嵌入式开发经验,4年安全软件开发经验,以及4年的云计算开发经验。目前主要负责CloudStack的技术顾问及CloudStack在中国的推广应用工作。

白清杰

CloudStack中国社区管理员之一。原北京GNOME用户组负责人,喀纳斯儿童Linux发行版作者,曾在亚信联创负责操作系统集成工作。2012年8月创建北京开源愿景信息技术有限公司,从事云计算相关业务。

曹伟

中国航信运行中心高级方案工程师,中国航信TravelCloud云计算解决方案产品经理兼技术架构负责人。多年来专注于虚拟化技术及云计算产品的研究与推广,拥有丰富的云计算项目实施经验,对云计算市场的观察与理解非常深入。

谭运华

资深Java开发工程师,架构师,对软件设计开发有深入的理解和丰富的经验。专栏博客为众多CloudStack新手提供了很多解决问题的思路,得到了许多开发者的支持,分享的与CloudStack代码分析入门和API调用相关的知识,为许多开发者提供了帮助。

魏伟

曾任职于中国电信股份有限公司上海研究院。主要研究方向包括云资源能力开发、云资源弹性扩展和云资源跨平台迁移等的技术调研和业务模型设计。拥有6年的编程经验,对CloudStack与VMware vSphere平台的部署和运维有一定的研究。

王磊

供职于大连新桥科技发展有限公司。拥有多年C、C++、C#开发经验,爱好读书、摄影。目前热衷于CloudStack的应用和研究,专注于开源和虚拟化技术,以及敏捷项目管理实践和团队管理。

杨康泉

原神州数码系统工程师,拥有10年基于UNIX、Linux、Oracle、Cisco平台的信息系统和网络规划设计、实施及运维工作经验,参与过多个大型项目的规划设计与实施工作。2009年起就职于远光软件,从事虚拟化、云计算、企业信息化方面的规划和管理工作。

袁帅

5年以上Java开发工作经验。目前从事云计算平台的二次开发和部署工作,就职于江苏众瀛联合数据有限公司。

马营

供职于苏州唐人数码科技有限公司,现任运维工程师。热爱开源,对各类互联网技术都抱有浓厚兴趣,IT“宅男”。

第1章 CloudStack简介

1.1 CloudStack的历史与发展

本节简单介绍CloudStack的历史与发展。

1.1.1 CloudStack的历史

谈到CloudStack,就不得不提到一家公司——Cloud.com。这家公司的前身叫VMOps,由梁胜博士在2008年创立,员工以华人居多。之所以成立这家公司,据梁胜自己讲,是因为当时亚马逊公有云服务在美国已经成熟并大量商用。基于对云计算市场的预期,梁胜决定进入这个领域。从名字来看,VMOps最初很可能是打算做虚机运营管理的。

经过一年多的封闭开发,2010年年初,VMOps的初始版本已基本成型。同年5月,VMOps更名为Cloud.com,其开发的云管理平台CloudStack已经是2.0版本,CloudStack逐渐去除其神秘面纱,并开始积累一些商业应用案例。

CloudStack最初分为社区版和企业版:社区版采用GPLv3许可;与社区版相比,企业版保留了5%左右的私有代码。可以说,此后一段时间,Cloud.com在努力开发CloudStack的同时,也逐渐积累了更多的企业用户。

2011年年初发布CloudStack 2.2版本时,正值云计算在国外迅猛发展,Cloud.com在短短的4个月中与非常多的重量级用户签署了合作协议,比较著名的公司有韩国电信、Zynga、TATA、北海道大学等。这时,CloudStack能够管理的Hypervisor包括XenServer、VMware、KVM、OVM,甚至裸机。

正是由于CloudStack已经积累了相当多的企业应用案例,并以其成熟的商业应用、良好的管理及扩展功能为大家所熟知,因此最终被HP和Citrix两家公司竞购。2011年7月,Cloud.com被Citrix收购。

Citrix收购Cloud.com后,维持了其团队的完整性,并继续开发CloudStack。CloudStack 3.0就是在被Citrix收购之后开发的。2012年4月,Citrix宣布将CloudStack捐献给Apache软件基金会,且完全采用Apache 2.0许可。本书的故事由此开始。

1.1.2 CloudStack生态圈

在Cloud.com被Citrix收购之前,CloudStack已经有一些相当成功的商业应用案例。在Cloud.com被Citrix收购并捐献给Apache之后,越来越多的企业投身CloudStack之中。

通过CloudStack构建自己的公有云和私有云服务的用户很多,包括电信运营商、云服务提供商、跨国大型企业、大学等很多重量级用户。而在CloudStack成为Apache的开源项目之后,国外又涌现了一批云解决方案提供商来推动CloudStack项目的落地。一些公司开发了第三方插件,帮助完善CloudStack的功能,如对存储设备和网络设备的支持、计费模块、其他管理功能模块等。还有一些公司提供基于CloudStack的商业发行版本,如Citrix的商业发行版叫做CloudPlatform。这些公司集合在一起,形成了比较完整的CloudStack生态圈。

目前,使用CloudStack作为生产环境的公司有Zynga、KT、Tata、LeaseWeb、SAP、迪斯尼等。在Citrix的官方博客中有这样一个统计:如图1.1所示,CloudStack已经部署在至少200个大型生产系统中,其中最大的一个云的规模超过4万台,已经运行了很多年,并在持续扩展。图1.1 使用CloudStack的用户

国内开始使用CloudStack的时间比较晚,相对较早的公司有天云趋势(基于CloudStack开发自己的商业产品ElasterStack)、中国电信(基于CloudStack建立天翼云的公有云服务)。另外,PPTV曾在国内CloudStack社区的技术活动中分享了使用CloudStack的经验。目前,国内使用CloudStack的用户越来越多,中国用户组正在对相关数据进行详细的统计。CloudStack生态圈中的各个公司并不都是竞争关系,每个公司都有不同的优势和发展方向,集合在一起可以更好地推动CloudStack项目的落地。从长远看,CloudStack用户加入开源社区及CloudStack生态圈会获得更广、更深的长期利益。

1.1.3 CloudStack的路线规划

在讨论整个CloudStack的未来规划之前,我们看一下Citrix云平台架构师、Apache CloudStack PMC成员之一——Alex Huang的一段叙述:CloudStack的设计目标是更加易于使用和开发;它允许拥有不同技能的开发人员工作在CloudStack的不同功能模块之上;它要给运营人员提供选择CloudStack的一部分功能来实现自己所需的机制;它要支持使用除Java之外的其他语言来编写功能模块,要有较高的可用性和可维护性,要易于部署。

对外行人而言,这些话看似毫无意义,但有很多是当前要完成的目标,而且不容易完成。CloudStack 4.0及以后的版本都在为完成上述目标而不断调整,各模块更加轻量化,耦合度逐步下降,功能架构的定义越来越清晰,并且从之前的私有自定义模块转向用户熟知的框架(如Spring、RabbitMQ等),能够更好地组合资源以便与第三方设备集成。

实际上,CloudStack的规划向来不会太远,在Apache的Jira(Bug跟踪系统)上就有单独的一项叫做Road Map,上面会列出未来一段时间将要发布的CloudStack版本,地址为https://issues.apache.org/jira/browse/CLOUDSTACK?selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel。

CloudStack计划发布的版本很多,本书以4.0.2版本为基础展开讨论。到本书出版时,这个版本仍为用户数量最多、使用范围最广且比较稳定的版本。本书并未求新,因为此版本是新用户最容易上手的。CloudStack新旧版本的架构不会有太大改变,在学习此版本后会更容易理解新版本。如果读者对刚发布或尚未发布的版本感兴趣,阅读本书有助于学习、理解CloudStack的架构及操作。

1.2 如何加入CloudStack社区

每一个开源社区的背后都有一个开源项目,但不是每一个开源项目都会产生一个社区。社区由开发者、测试人员、使用者、用户等组成。开源社区是一个开源项目赖以生存的土壤,没有良好的社区基础,再优秀的项目都会衰落。社区一般包括项目站点、邮件列表或者交流论坛,以及报告问题和提交代码的入口。

1.2.1 CloudStack社区有哪些资源

CloudStack的官方网站是最权威的CloudStack资源中心,网址是http://CloudStack.apache.org。

通过CloudStack的官方网站,我们可以找到与CloudStack有关的大部分信息,如软件及源代码、软件使用文档、软件开发文档等。

CloudStack的官方网站还提供了CloudStack社区博客。

CloudStack社区博客的地址是https://blogs.apache.org/CloudStack/。该博客会不定期发布目前的Bug统计、新的Feature统计、最近社区的主要讨论话题、CloudStack版本的开发进度、近期的开发计划、近期世界各地与CloudStack有关的活动、新的社区Commitor、PMC Member的变化等比较全面的社区活动介绍。通过该博客,我们可以对CloudStack的近期发展有一个总体了解。如果要跟踪CloudStack的发展,阅读社区周报是最好的方法之一。

刚开始使用CloudStack时面临的第一个问题就是下载CloudStack软件。CloudStack的源码下载地址是http://CloudStack.apache.org/downloads.html。下载源码之后,需要进行编译。对于需要进行二次开发的人员,建议使用源码的方式编译安装。对于初学者,建议下载已经编译好的二进制包,下载地址如下。● 基于RHEL或CentOS的RPM安装包:http://CloudStack.apt-get.eu/

rhel/● 基于Ubuntu的DEB安装包:http://CloudStack.apt-get.eu/ubuntu

在该网站内,可以看到很多已经编译好的二进制安装包。需要注意的是,在CloudStack的代码中,部分对VMware提供支持的代码不符合Apache 2.0协议,因此官方发布的代码中剔除了该部分代码。如果需要CloudStack支持VMware,就要自行编译代码,或者找到带有“nonoss”标记的二进制安装包。

在使用CloudStack的过程中,总会遇到这样或那样的问题,到底是操作问题、系统环境问题,还是CloudStack的Bug,我们需要进行深入的研究和判断。当我们无法确认是否是CloudStack的问题时,可以访问CloudStack的Bug管理系统,通过搜索相关问题来获得帮助。如果确认其他人发现了同样的问题,可以检查这个问题是否已被修复,以及在哪个版本中得到了解决。如果确认是一个新问题,可以将问题描述清楚并提交,由社区帮助解决。CloudStack的Bug管理系统是通过Jira进行管理的,地址为https://issues.apache.org/jira/browse/CLOUDSTACK。

在这个问题管理系统中,我们除了可以了解目前已经发现的问题、社区成员对问题的讨论及处理状态,还可以查看开发路线图等。作为开源社区的成员,我们也可以帮助社区回复问题,为社区贡献一份力量。

1.2.2 如何使用邮件列表

在CloudStack社区中,用户及开发者之间的交流主要通过邮件列表进行。CloudStack的开发者和专家基本都是通过邮件列表进行交流的。通过邮件列表,我们可以直接提问,CloudStack的热心专家会帮助解答。以往我们问问题的方式大多是直接找一个专家并向他提问,但一个人的精力总是有限的,不可能随时回答我们的问题。在邮件列表中,会有很多热心的朋友帮助我们得到答案和解决问题的方法。另外,除了提问,我们还可以了解其他人遇到的问题。其他人现在遇到的问题,有可能是我们以后会遇到的问题,在别人的邮件往来中吸取相关经验,也是很好的学习方式。也许有的读者会说,在新加入的邮件列表中看不到之前的讨论邮件。不用担心,所有邮件都会被记录下来并允许搜索引擎进行索引,通过搜索引擎一样可以了解之前是否有人遇到了和我们相同的问题,这样也省去了我们提问及等待回答的时间。所以说,用好社区的邮件列表对使用CloudStack有非常大的帮助。

CloudStack的邮件列表地址为http://CloudStack.apache.org/mailing-lists.html,具体如下。● 公告邮件列表:announce@CloudStack.apache.org● 全球用户邮件列表:users@CloudStack.apache.org● 中文用户邮件列表:users-cn@CloudStack.apache.org● 开发者邮件列表:dev@CloudStack.apache.org● 代码提交者邮件列表:commits@CloudStack.apache.org● 问题邮件列表:issues@CloudStack.apache.org● 市场运作邮件列表:marketing@CloudStack.apache.org

建议加入全球用户、中文用户、开发者这3个邮件列表,它们是目前讨论比较集中的邮件列表。尤其是中文用户邮件列表,对Apache开源社区有了解的读者也许知道,几乎没有其他开源项目像CloudStack一样专门为中文用户开辟独立的邮件列表,这对中文用户而言是很好的便利条件。

如果要加入邮件列表,可以发送一封邮件到以上邮件地址之一,根据提示即可加入相应的邮件列表。推荐使用Gmail邮箱或网易邮箱订阅邮件列表。

下面以中文用户邮件列表为例,介绍如何加入邮件列表(这里虚构一个邮箱地址CloudStack@gmail.com)。

①使用邮箱CloudStack@gmail.com向users-cn-subscribe@CloudStack.apache.org发送一封电子邮件。因为是机器自动应答而非人工审核,所以并不关心内容,只关心邮箱地址,邮件主题和内容可以随意编写。

②检查收件箱,看看是否会收到一封主题为“confirm subscribe to users-cn@CloudStack.apache.org”的确认邮件。若未收到确认邮件,可到垃圾邮件列表中查找。在收到的确认邮件中,会有类似这样的内容。Hi!This is the ezmlm program. I'm managing theusers-cn@CloudStack.apache.org mailing list.To confirm that you would likeCloudStack@gmail.comadded to the issues mailing list,please send a short reply to this address:users-cn-sc.1394178631.bomkflhcpeggpddmainc-CloudStack=gmail.com@CloudStack.apache.orgUsually,this happens when you just hit the “reply” button.If this does not work,simply copy the address and paste it into the “To:” field of a new message.This confirmation serves two purposes. First,it verifies that I am able to get mail through to you. Second,it protects you in case someone forges a subscription request in your name.……

③对加入的邮件列表进行确认。根据邮件中的叙述,正常情况下,直接使用回复功能回复这封邮件进行确认即可。回复的目的邮件地址会变为类似“users-cn-sc.1394178631.bomkflhcpeggpddmainc-CloudStack=gmail.com@CloudStack.apache.org”的样子,在发送前要再次检查回复的邮件地址是否正确。如果正确,直接发送即可;如果不正确,则需要手动单击这个超链接进行发送。正确发送邮件后,就算是订阅成功了。

④检查收件箱,如果收到主题为“WELCOME to users-cn@CloudStack.apache.org”的邮件,则表示已经成功加入。请一定保存这封邮件,因为里面有如何退订邮件组的方法,以及加入其他邮件组的方法。当然,最重要的是将users-cn@CloudStack.apache.org这个电子邮件地址保存到邮箱的通讯录中。当我们需要向邮件组中的专家提问时,直接向此邮件地址发送邮件即可。加入中文用户邮件列表后,就算是加入CloudStack社区了。

为了更好地使用邮件列表,这里有几个建议希望读者能够采纳或遵守。● 使用邮件过滤功能:由于邮件列表中的讨论很频繁,邮件组活跃

的时候,可能每几分钟就会有一封邮件发送,所以建议使用邮箱

或邮件管理软件中的过滤功能,将CloudStack邮件自动保存在一

个单独的文件夹中。● 图片要用外链:邮件列表不支持附件和图片,如果邮件中包含这

些内容,将会被过滤。因此,如果想在邮件中提供问题的截图,

最好将相应的图片发布到其他网站,然后在邮件中提供图片的可

访问链接。这样,社区成员就可以看到问题的截图了。● 注意礼貌:在邮件列表中进行交流时,一定要注意措辞,要有礼

貌。在社区中,大家都是以志愿者的方式帮助其他人解决问题,

所以一定要尊重别人。● 学会提问:提问题也需要技巧,问题要尽可能具体、清晰、简洁。

要尽量将问题描述清楚,如操作系统的版本、CloudStack的版本、

Hypervisor的类型及版本,以及在进行什么操作时遇到了问题及

问题的表现,并附上较为准确和完整的报错日志。CloudStack作

为一个大型云环境,可能有许多种造成相同问题表象的原因,这

些内容描述得越清楚,看邮件的人就越容易判断,问问题的人也

就越容易得到答案。如果多次往返邮件询问系统环境,可能会使

帮助我们的人失去耐心。● 一次问一个问题:在邮件列表中交流时,尽量一次只提一个问题,

以便解答问题的人理解我们提出的问题。如果在一封邮件中一下

子提两三个问题,会让想回答我们问题的人无所适从。● 别指望别人做我们的工作:不要指望别人把解决问题的步骤一一

告诉我们。别人只能提供解决问题的思路,问题的最终解决还是

要靠我们自己。● 不要给社区开发者发私信:当有人回复了我们提出的问题,但是

问题还没有解决时,心急的人就会想直接给开发者或者自己认为

很牛的人发邮件,这样做是非常不礼貌的,一定不要这样做。● 时刻牢记别人的帮助都是自愿的:一定要时刻记住,没有人欠我

们什么,别人的帮助都是自愿的,不要强迫人来帮助自己。● 仔细阅读别人的回复,按照别人指点的方向去尝试:当有人对问

题进行了回复时,不要想当然地认为“这样行不通”或者“我已

经这样尝试过了”,一定要按照别人的指点进行尝试,因为我们

之前的尝试可能有盲点。● 确认建议是否有效:当其他社区成员对问题给出回复后,要进行

尝试,并告诉回复的人这样的尝试是否有效。如果问题解决了,

一定要给出最终的解决方法,这样也能帮助别人从我们的问题中

学习(因为我们在浏览别人提出的问题时,也会想知道这个问题

的解决方法是否有效)。

1.2.3 如何成为Commitor

成为开源项目的Commitor是一件很有荣誉感的事情,这说明我们所做的工作及我们的能力得到了社区的认可,而Commitor也会有更多的权限去参与社区的工作。1.成为Commitor的步骤

成为Commitor需要以下步骤。

①使用邮箱订阅CloudStack的社区邮件组。

②参与社区邮件组的讨论。成功订阅社区邮件组后,会收到邮件组中其他成员提出问题和讨论问题的邮件。积极参与讨论和解答别人的问题是我们的积极性及技术实力的展现。请在社区邮件组的讨论中多投入一些精力。发送邮件时要直接向邮件组的邮件地址发送,回复时同样只需向邮件组地址回复,无须回复实际发送人。

③编辑文档。CloudStack社区中有很多文档是开放的,供社区成员编辑和修订,找出文档中的错误或编写新的文档都是对社区的一份贡献(文档入口为https://cwiki.apache.org/confluence/display/CLOUDSTACK/Home)。

④提交程序问题及修改补丁。作为CloudStack的贡献者,参与代码修改和提交问题并修复是非常重要的工作。一定要将大量精力放在修改Bug上,这是展示技术实力的主要方式(访问http://CloudStack.apache.org/developers.html可以了解普通贡献者所能访问的资源及可以完成的工作)。CloudStack程序中有很多Bug,开发人员可能没有时间一一修复,需要社区内所有成员一起贡献力量来修复(访问https://issues.apache.org/jira/browse/CLOUDSTACK可以查看、提交、追踪、修复Bug)。关于CloudStack中存在的问题,也可以在“issues”邮件组中进行讨论。

⑤重复以上步骤,直到工作被社区认可。当按照以上步骤积极参与社区事务,为社区工作一段时间后(预计是2~3个月,根据具体所做工作而定),我们的技术实力及积极意愿肯定能够得到CloudStack社区PMC(Project Management Committee)成员的注意和认可。PMC成员会先进行内部投票,投票通过后,会邀请我们成为Committor。2.新Committor指南

在成为CloudStack的Committor之后,会有更多访问CloudStack资源的权限。但在这之前,需要签署一些协议,下载地址为http://www.apache.org/licenses/icla.pdf。签署这份协议后可以邮寄、传真或通过电子邮件发送扫描文件到secretary@apache.org,相关说明参见http://www.apache.org/licenses/#clas。完成协议签署工作后,还要完成创建用户、登录服务器和Subversion等工作(可以参考http://www.apache.org/dev/new-committers-guide中的详细说明)。如果还有不清楚的地方,可以直接向PMC寻求帮助。3.Apache社区参考说明页面的超链接

常用的Apache社区参考说明页面的超链接如下。● http://www.apache.org/dev/contributors.html● https://www.apache.org/dev/committers.html● http://www.apache.org/dev/new-committers-guide● http://CloudStack.apache.org/mailing-lists.html● http:/CloudStack.apache.org/developers.html● http://CloudStack.apache.org/contribute.html

1.2.4 使用Transifex翻译Apache CloudStack文档

一个国际软件项目要在中国扎根,中文化是非常重要的。

Apache CloudStack的文档格式是DocBook XML格式(DocBook是一种模式,非常适合用在关于计算机硬件和软件的书籍和论文中)。使用Publican工具,可以将这些文档转换成多种格式。现在,CloudStack 4.0的所有文档都是以DocBook XML格式存储的。

所有官方文档位于Apache CloudStack源代码目录的“/docs”文件夹下。即使不是Apache社区的维护者,也可以添加DocBook文档和提交补丁。一个非常有用的方法是从现在开始修正现有的文档。

将文档转换成DocBook XML和Publican格式的好处之一是能够生成多种语言的文档。Publican能够定义一个便携式对象(Portable Object),这个对象是一个翻译原始文档的框架,Apache CloudStack使用Transifex翻译它们。尽管Transifex Client能够通过命令行进行翻译,但是最简单的方式还是通过Transifex的在线界面(On-line Interface)进行翻译,接下来演示整个流程。

首先,创建一个Transifex账户并登录。

在www.transifex.net网站上注册一个用户,如图1.2所示。图1.2 登录Transifex

登录后进入管理控制面板,单击“Join an existing organization”按钮,如图1.3所示。图1.3 加入已存在的组织

在搜索框中输入关键词“CloudStack”,会找到一些与CloudStack有关的项目。选择一个感兴趣的工程文档项目(当然,也可以选择Runbook或者UI),如图1.4所示。图1.4 搜索关键词“CloudStack”

单击“Apache CloudStack Docs”项目进入新页面,我们会看见多种语言及它们的翻译工作完成百分比,如图1.5所示。单击“资源”选项查看所有可以翻译的资源,如果已经下载了ACS源代码,那么在“/docs/en-US”目录下会看到与这些资源同名的DocBook XML文档,图1.6所示。图1.5 项目翻译进度图1.6 可翻译资源

选择一个我们想翻译的项目资源,会看到该项目各个语言版本的翻译进度列表,单击翻译的目标语言,如图1.7所示。图1.7 资源翻译进度

这时会弹出一个对话框,其中为这个语言版本的该项目资源提供了多种操作方式,单击“立即翻译”按钮可以对该项目进行翻译,如图1.8所示。图1.8 翻译对话框

在翻译页面中,左侧是要翻译的源语言。选择要翻译的文件内容,在源语言右侧的工作区就可以做相应的翻译工作。翻译完成后单击“保存”按钮,如图1.9所示,页面右上角会出现一个进度条。图1.9 翻译页面

当然,我们也可以不使用在线翻译方式。选择“下载进行翻译”的方式,翻译完成后上传翻译的内容,如图1.10所示。图1.10 下载翻译资源

单击“下载进行翻译”选项,下载文件格式为“po”。开始下载前,系统会提示“正在试图锁定资源”,如图1.11所示。图1.11 锁定资源

下载完成后,使用Notepad++(或者其他文档编辑软件)打开文件,“msgid”后面的内容就是需要翻译的语句,“msgstr”后面的内容就是翻译完成的语句,如图1.12所示。图1.12 使用Nodepad++翻译资源

翻译完成后,保存文件,然后上传,如图1.13所示。图1.13 上传文件

单击“上传文件”选项,选择要上传的文件即可。

当翻译工作有比较大的进展时,审核者会审核新翻译的内容。如果合格,可以提交翻译的内容并使用Publican将这些内容放到新文档中。

1.2.5 小结

现在我们已经知道自己在社区里可以做哪些工作。在社区里,每一个人都是重要的。在社区里,每一个人都可以找到自己的价值。人活着应该做点有意义的事情,而参与社区工作是IT人员最值得做的事情之一,可以选择以下一件或多件事情来做。● 加入中文用户邮件列表。● 在邮件列表中回答问题。● 发表博客文章,介绍CloudStack的使用经验。● 提交问题与错误。● 参与功能开发或错误修改。● 参与文档翻译工作。● 参与社区组织的活动。● 为社区活动提供场地。● 为社区活动提供赞助。● 做社区活动的志愿者。● 通过微博、博客、微信等互联网媒体推荐宣传CloudStack。

1.3 CloudStack中国用户组

2012年4月,CloudStack被Citrix公司捐献给Apache基金会,进入了开源项目的孵化阶段。2012年5月,在天云趋势公司的支持下,由李学辉牵头,成立了CloudStack中国用户组,并创建了用于发布信息的网站,同时建立了QQ群,将爱好者集合起来,一起讨论和学习CloudStack。

2012年5月22日,社区举办了第一次技术分享活动,邀请Alex Huang介绍了CloudStack及其技术架构,并由李学辉分享了天云趋势在一年多的时间里对CloudStack的研究经验。随后,社区又在南京、上海、广州等多个城市举办了巡回活动,为CloudStack在中国的发展迈出了第一步。从2012年至今,社区一直坚持每月举办一次技术沙龙,分享相关技术知识与经验,主要集中在北京和上海两地。社区活动聚集了大量的参与者,已经成功举办了24次。除此之外,2013年下半年,参考其他社区的活动方式,在北京组织每两周一次的周四晚咖啡之夜活动,加强了社区用户之间的交流与互动。社区每个月的活动会在当月的第一周公布,如果有兴趣参加,可在每月月初多多关注社区网站发布的新活动。

2014年,CloudStack中国用户组尝试开展培训及商务合作,希望能从更多方向推动CloudStack在中国的发展。

在社区运营和发展的两年中,先后有多名新的志愿者加入并为社区贡献力量,白清杰、刘宇超、刘莹等都成了社区的主要管理运营者,在社区组织的活动中分享技术经验的讲师超过50人次。他们的无私和努力为CloudStack在中国的发展奠定了坚实的基础。

到2014年3月为止,CloudStack中国用户组的网站已经发布了技术及新闻报道共110篇;QQ群的数量共5个,参与者达3000人,每天群内讨论会话超过1000条;社区中文用户邮件列表中的邮件数量近3000封;新浪微博粉丝数超过2300人;近1500人次参与线下活动。

下面列出各种参与CloudStack中国用户组的方式的入口。● 中国用户组网站的地址为http://www.cloudstack-china.org/。● QQ群有如下5个。 用户群1:236581725(2000人群,已满,禁止申请) 用户群2:253201150(1000人群) 技术开发1:215533675(1000人群) 技术开发2:276747327(500人群) 市场群1:368649692(500人群,以商务合作交流为主,申请加

入者必须能代表自己所在的公司)● 新浪微博用户名为“CloudStack中国”。

CloudStack中国用户组一直秉承为CloudStack爱好者服务的目标,致力于推进CloudStack 在中国的发展、技术的普及、项目的实际落地。未来,希望CloudStack在中国各地开花结果,并建立起一套完整的CloudStack生态圈,形成燎原之势。

1.4 Apache基金会与Apache 2.0协议

Apache软件基金会(Apache Software Foundation,简称ASF)是专门为支持开源软件项目而举办的一个非盈利性组织。在它所支持的Apache项目与子项目中,所发布的软件产品都遵循Apache许可证(Apache 2.0 License)。

Apache软件基金会的前身是Apache组织(Apache Group)。Apache软件基金会是一个非盈利性组织,基于成员制,以保证Apache项目在个人志愿者参与之外能够继续存在。如果一个人承诺参与开源软件的开发,并不断地为Apache软件基金会的项目做出贡献,就有资格成为Apache软件基金会的成员。只有获得Apache基金会现有大部分成员的赞同和任命,个人才能成为软件基金会的成员。因此,Apache软件基金会由它所直接服务的社区来管理,成员都对社区内的项目进行协作。

Apache软件基金会的成员按照基金会的规章制度,每隔一段时间选举一个董事会来管理基金会的组织事务,董事会成员将监管基金会的日常事务,社区可以公开获取Apache基金会的运营记录。

Apache软件基金会的项目之所以被人认可,其中一个主要原因就是称作“Apache方法”的哲学理念。

如下内容尽管不是官方发布的,但已被认为是Apache基金会的核心哲学理念。● 协作化的软件开发。● 商业友好的标准许可证。● 永远保证高质量的软件。● 成员之间的交往要互相尊重、诚实、以技术为主。● 依据标准的忠实实现。● 强制的安全特性。

Apache软件基金会的项目品质已被广泛认可,如Apache HTTP Server、Apache Tomcat、Apache Hadoop等。

Apache为人们所熟知的不仅包括Apache软件基金会管理的项目,还包括Apache 2.0协议。Apache 2.0协议以其对商业的友好性著称。

所有Apache项目的版权都归Apache软件基金会所有,并使用Apache 2.0协议发放许可。同时,Apache软件基金会和项目管理委员会采用各种方法来保证:当没有合法绑定时,Apache的代码中不包含由第三方拥有知识产权的代码,并且发布的软件的修改权受Apache 2.0协议的保护。值得注意的是,虽然Apache掌握一个项目的整体版权,但是项目中某个部分的版权可能归个人贡献者所有,并基于Apache软件基金会的条款发放许可。

Apache 2.0协议是一个自由的软件许可证,它基于传统的BSD和MIT软件许可证,增加了符合时代要求的一些重要条款,满足自由软件和开源软件所有已经被接受的定义。

当我们谈到“软件自由”时,一般都会有“言论自由”的感觉。软件自由主要体现在任何人都有想做什么就做什么的自由。源代码开放也是软件自由的一个必要组成部分。

软件价格和软件自由无关。Apache基金会内的各种项目可能会通过各种价格获得——从免费下载到捆绑在一个商业软件包中,甚至付费购买由商业组织以修改的方式开发的软件产品。

Apache许可证是一个自由软件许可证,可能会有一些专利终止的情况。对于技术开发者来说,当今最大的“危险”就来自专利,这种情况在美国尤为突出。在美国,专利系统一直被看作是维护经济垄断的工具——为“我们”的公司申请成千上万的专利,然后通过世界贸易组织(World Trade Organization,WTO)的条约将这些专利执行,以期获得全球竞争优势。结果就是,美国专利局要处理大量专利事务,导致没有办法对每个专利进行详细的审查和质量控制,因此很多专利掌握在对技术没有丝毫兴趣的人手上(他们希望从合法的商业行为中获利)。

Apache 2.0协议的一个非同寻常的限制就是尽可能地处理这种情况。接受Apache的许可,意味着不能有任何反对Apache软件基金会和损害Apache用户专利权的行为。从目前的情况看,Apache从未被卷入知识产权案件中。Apache的知识产权通过版权和许可证进行保护。同时,Apache不会侵犯其他人的知识产权,这一点也很重要,这意味着所有对Apache的重要贡献都必须是通过正确的方式捐赠的。● 在一个开发者成为提交者之前,必须签署一份贡献者许可协议(Contributor License Agreement,CLA),使得Apache软件基金

会被授予所有必需的权利来使用这位开发者的贡献,并将其许可

通过Apache软件基金会条款向第三方发放。贡献者许可协议使

得开发者在加入Apache之前将他们的所有贡献的所有权签字移

交给Apache。● 如果一个开发者自己不能做出决定(例如雇主可能对其雇员的工

作成果拥有某些权利),就需要该开发者的授权上级领导(例如

首席技术官或IT主管)签发一个企业贡献者许可协议(Corporate CLA,CCLA)。● 在开发者被授予提交访问权限之前,所有的贡献者许可协议、企

业贡献者许可协议必须形成文档并保存在Apache软件基金会。

这些协议被用来保证提交者及其雇主不能阻止Apache软件基金

会或Apache用户使用他们的贡献。

另外,每一位提交者都必须保证其贡献没有侵犯第三方的知识产权,这是他们的责任。项目管理委员会对项目中新出现的贡献进行评估,以确保其不侵犯第三方的知识产权。

尽管已经考虑得很周到了,但仍然可能出现侵犯第三方知识产权的问题。Apache有一条由Subversion管理的完整的审计链。因此,即使在最坏的情况下,任何有问题的代码也都会被查出并删除。

Apache 2.0协议全文如下(仅供参考,具体协议内容参见原始版本)。Apache许可证2.0版 2004年1月http://www.apache.org/licenses/http://www.apache.org/licenses/关于使用、复制和分发的条款1. Definitions.“License” shall mean the terms and conditions for use,reproduction,and distribution as defined by Sections 1 through 9 of this document.“Licensor” shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.“Legal Entity” shall mean the union of the acting entity and all other entities that control,are controlled by,or are under common control with that entity. For the purposes of this definition,“control” means (i) the power,direct or indirect,to cause the direction or management of such entity,whether by contract or otherwise,or (ii) ownership of fifty percent (50%) or more of the outstanding shares,or (iii) beneficial ownership of such entity.“You” (or “Your”) shall mean an individual or Legal Entity exercising permissions granted by this License.“Source” form shall mean the preferred form for making modifications,including but not limited to software source code,documentation source,and configuration files.“Object” form shall mean any form resulting from mechanical transformation or translation of a Source form,including but not limited to compiled object code,generated documentation,and conversions to other media types.“Work” shall mean the work of authorship,whether in Source or Object form,made available under the License,as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).“Derivative Works” shall mean any work,whether in Source or Object form,that is based on (or derived from) the Work and for which the editorial revisions,annotations,elaborations,or other modifications represent,as a whole,an original work of authorship. For the purposes of this License,Derivative Works shall not include works that remain separable from,or merely link (or bind by name) to the interfaces of,the Work and Derivative Works thereof.“Contribution” shall mean any work of authorship,including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof,that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition,“submitted” means any form of electronic,verbal,or written communication sent to the Licensor or its representatives,including but not limited to communication on electronic mailing lists,source code control systems,and issue tracking systems that are managed by,or on behalf of,the Licensor for the purpose of discussing and improving the Work,but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as “Not a Contribution”.“Contributor” shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.2. Grant of Copyright License. Subject to the terms and conditions of this License,each Contributor hereby grants to You a perpetual,worldwide,non-exclusive,no-charge,royalty-free,irrevocable copyright license to reproduce,prepare Derivative Works of,publicly display,publicly perform,sublicense,and distribute the Work and such Derivative Works in Source or Object form.3. Grant of Patent License. Subject to the terms and conditions of this License,each Contributor hereby grants to You a perpetual,worldwide,non-exclusive,no-charge,royalty-free,irrevocable (except as stated in this section) patent license to make,have made,use,offer to sell,sell,import,and otherwise transfer the Work,where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement,then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium,with or without modifications,and in Source or Object form,provided that You meet the following conditions:1. You must give any other recipients of the Work or Derivative Works a copy of this License;and2. You must cause any modified files to carry prominent notices stating that You changed the files;and3. You must retain,in the Source form of any Derivative Works that You distribute,all copyright,patent,trademark,and attribution notices from the Source form of the Work,excluding those notices that do not pertain to any part of the Derivative Works;and4. If the Work includes a “NOTICE” text file as part of its distribution,then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file,excluding those notices that do not pertain to any part of the Derivative Works,in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works;within the Source form or documentation,if provided along with the Derivative Works;or,within a display generated by the Derivative Works,if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute,alongside or as an addendum to the NOTICE text from the Work,provided that such additional attribution notices cannot be construed as modifying the License.You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use,reproduction,or distribution of Your modifications,or for any such Derivative Works as a whole,provided Your use,reproduction,and distribution of the Work otherwise complies with the conditions stated in this License.5. Submission of Contributions. Unless You explicitly state otherwise,any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License,without any additional terms or conditions. Notwithstanding the above,nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.6. Trademarks. This License does not grant permission to use the trade names,trademarks,service marks,or product names of the Licensor,except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing,Licensor provides the Work (and each Contributor provides its Contributions) on an “AS IS”BASIS,WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,either express or implied,including,without limitation,any warranties or conditions of TITLE,NON-INFRINGEMENT,MERCHANTABILITY,or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.8. Limitation of Liability. In no event and under no legal theory,whether in tort (including negligence),contract,or otherwise,unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing,shall any Contributor be liable to You for damages,including any direct,indirect,special,incidental,or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill,work stoppage,computer failure or malfunction,or any and all other commercial damages or losses),even if such Contributor has been advised of the possibility of such damages.9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof,You may choose to offer,and charge a fee for,acceptance of support,warranty,indemnity,or other liability obligations and/or rights consistent with this License. However,in accepting such obligations,You may act only on Your own behalf and on Your sole responsibility,not on behalf of any other Contributor,and only if You agree to indemnify,defend,and hold each Contributor harmless for any liability incurred by,or claims asserted against,such Contributor by reason of your accepting any such warranty or additional liability.END OF TERMS AND CONDITIONS

鉴于法律条款的严谨性,本书就不对以上内容进行翻译了。

下面我们以CloudStack为例,对该协议进行解读。

根据第2条对版权许可的授予可知,任何个人和组织都可以在任何地方基于任何目的免费使用CloudStack,免费制作CloudStack的衍生版本,免费分发CloudStack或者CloudStack的衍生品。这里的“免费”是指不需要向CloudStack的贡献者支付任何费用。根据第2条,任何组织和个人可以基于CloudStack开发商业衍生版本而不需要支付版权费用。

根据第3条对专利许可的授予可知,任何组织和个人使用CloudStack时均不需要支付专利费。当CloudStack代码中出现侵犯其他专利的情况时,该授权将会终止。Apache基金会为了规避专利侵权问题,会要求所有的代码提交者签署贡献者许可协议(CLA)或企业贡献者许可协议(CCLA)。

根据第4条对重新分发的规定可知,任何组织和个人在进行分发时必须保留Apache 2.0协议的副本,这意味着所有CloudStack的衍生品必须保留Apache 2.0协议的副本。衍生品的分发组织和个人可以设定自己的授权协议,这意味着CloudStack的衍生品可以是商业授权,这也是Apache 2.0协议“对商业友好”的原因所在。

Apache软件基金会对所管理的项目,从代码的版权、专利及开发质量上对品质进行保证。Apache软件基金会的管理流程保证了CloudStack项目的品质及可持续性。

第2章 CloudStack架构

2.1 CloudStack的功能与特点

“云计算”的概念说了很多年,到现在为止,虽然云计算项目仍然有很多,很多人依旧是雾里看花,但已经有更多的人开始理性地思考——因为他们慢慢地看清了其中的门道。

云计算最早进入大众视线是在2006年亚马逊推出弹性计算云服务,Google也在同年提出“云计算”概念的时候。但到底什么是云计算,一直也没有一个明确的定义。后来,美国国家标准和技术研究院的云计算定义中描述了云计算的部署模型,具体如下。● 公有云(Public Cloud):简而言之,公有云服务可通过网络及第

三方服务提供者开放给用户使用。“公有”一词并不一定代表“免费”,只是可能代表免费或相当廉价。“公有”并不表示用户

数据可供任何人查看,公有云服务提供者通常会对其用户实施访

问控制机制。公有云作为解决方案,既有弹性,又具备成本效益。● 私有云(Private Cloud):私有云具备许多公有云环境的优点(例如弹性、适合提供服务)。两者的差别在于,私有云服务中

数据与程序皆在组织内管理,且不会受到网络带宽、用户对安全

性的疑虑、法规限制的影响。此外,因为用户与网络都受到了特

殊限制,所以私有云服务能让其提供者及用户更好地掌控云基础

架构,改善安全性与弹性。● 社区云(Community Cloud):社区云由众多利益相仿的组织掌

控和使用(例如特定安全要求、共同宗旨等),社区成员共同使

用云数据及应用程序。● 混合云(Hybrid Cloud):混合云结合了公有云及私有云。在这

个模式中,用户通常将企业非关键信息外包,并在公有云上进行

处理,但同时掌控企业关键服务及数据。

如果提供云服务,还有几个特点是一定要满足的。● 支持多租户。● 能够按需提供自服务。● 宽带网络的接入。● 将所有资源池化。● 能够快速进行弹性增减。

云计算的定义也明确了3种服务模式,如图2.1所示。图2.1 云计算的3种服务模式。● 软件即服务(SaaS):消费者使用应用程序,但不掌控操作系统、

硬件或网络基础架构。这是一种服务观念的基础,软件服务提供

商以租赁的概念向用户提供服务,而非销售,比较常见的模式是

提供一组账号和密码,如Microsoft CRM和Salesforce.com。● 平台即服务(PaaS):消费者使用主机操作应用程序。消费者掌

控运行应用程序的环境(也拥有主机的部分掌控权),但不掌控

操作系统、硬件或网络基础架构,平台通常是应用程序基础架构,

如Google App Engine。● 基础架构即服务(IaaS):消费者使用基础计算资源(如处理能

力、存储空间、网络组件或中间件),能掌控操作系统、存储空

间、已部署的应用程序及网络组件(如防火墙、负载平衡器等),

但不掌控云基础架构,如Amazon AWS、Rackspace。

这3种服务模型之间是有关系的。IaaS层会对底层的硬件设施进行统一管理,并向上提供服务。PaaS层建立起一个平台向上提供服务,但不需要管理硬件设施,只要使用IaaS层提供的服务即可。对于PaaS层来说,硬件是透明的。SaaS层使用PaaS层这个平台,通过软件为用户提供服务。对于SaaS层的软件来说,IaaS层是完全透明的。

CloudStack这个开源项目设计的初衷,就是提供基础架构即服务(IaaS)的服务模型,建成一个硬件设备及虚拟化管理的统一平台,将计算资源、存储设备、网络资源进行整合,形成一个资源池,通过管理平台进行统一管理,弹性增减硬件设备。根据云环境中的5个特点,CloudStack进行了功能上的设计和优化,为了适应云的多租户模式,设计了用户的分级权限管理机制,通过各种技术手段保证用户数据的安全,保护用户的隐私。用户可以直接通过浏览器访问,在一定权限下自由使用自己的资源,实现自服务模式。在多租户环境下,用户使用资源的计量计费功能也是必不可少的,CloudStack会通过多种手段尽可能地记录用户使用的所有资源的情况,并将其保存下来,供计费时使用。对于云系统管理员来说,绝大部分管理工作通过浏览器就可完成。CloudStack提供资源池化管理、高可靠性等功能,帮助云系统管理员尽可能地将管理工作简化和自动化,减少切换界面的次数。CloudStack既可以直接对用户提供虚拟机租用服务,也开放API接口为PaaS层提供服务,所以就有了一个简化的概念图,如图2.2所示。图2.2 CloudStack平台的基本概念

通过图2.2可以看出,最终用户只要在CloudStack的平台上直接申请和使用虚拟机就可以了,无须关注底层硬件设备是如何被设计和使用的,也不用关心自己使用的虚拟机到底在哪个计算服务器或哪个存储上。

我们先了解一下CloudStack系统向下管理这一层。CloudStack的管理是比较全面的,且尽可能地兼容,可以管理多种Hypervisor虚拟化程序,包括XenServer、VMware、KVM、OracleVM、裸设备,如图2.3所示。凡是这些虚拟化程序支持的计算服务器,CloudStack也都可以正常支持,这样就具有了非常广泛的兼容性。图2.3 CloudStack支持的设备类型

CloudStack可以使用的存储类型也非常广泛。虚拟机所使用的主存储可以使用计算服务器的本地磁盘,也可以挂载iSCSI、光纤、NFS;存放ISO镜像及模板文件的二级存储可以使用NFS,也可以使用Openstack的Swift组件,如图2.4所示。图2.4 CloudStack支持的存储类型

CloudStack除了支持各种网络连接方式外,其自身也提供了多种网络服务,不需要硬件设备就可以实现网络隔离、防火墙、负载均衡、VPN等功能,如图2.5所示。图2.5 CloudStack支持的网络功能

下面看一下CloudStack支持多租户的特点。前面提到过,多租户是云计算架构的一个基本特点,支持多租户是一个IaaS云管理平台应该具备的基本条件之一。从图2.2中可以了解到,CloudStack支持不同的组织和个人在同一平台上申请和使用资源。CloudStack也必须通过一定的手段保证资源使用的限制和通畅,这两个看起来矛盾的描述,在云平台上却是十分正常的现象和需求。

先说限制。因为云平台上的多租户可以开放给任意用户访问和使用,所以首先要解决的问题就是如何保证用户数据的安全,然后要考虑的是如何保证用户申请的资源不会被其他用户占用。分析一下这两个需求就可以了解:从技术方面考虑,就是对网络访问方式的限制,以及对虚拟化资源和物理资源使用的隔离与限制。对网络访问的限制可以通过网络架构的设计及虚拟防火墙和安全组的功能来实现,这可以说是CloudStack的一大特点,具体如何设计,本章后面会仔细讲解,这里先卖个关子。对所使用资源的限制也是CloudStack全面支持的功能:用户所申请的虚拟化资源自不必多说,由多个成熟的虚拟化程序来保证;如果有更进一步的要求,需要单独使用物理资源,如某几台配置不同的服务器和存储,甚至是一个或几个集群,都可以很容易地做到。在管理界面上将资源直接指定给某个用户或用户组,或者通过标签的方式标记某些资源,就可以根据用户和应用场景的需求分开使用了。管理上的灵活性,可以很方便地支持和兼容更多的用户需求和使用场景。

再来看看CloudStack是如何在多租户之间保证使用的通畅的。在云平台上申请使用资源的用户,不仅可能是一个个单独的个体,也可能是以组织或公司为名义的多个用户。CloudStack设计了用户组的概念,组内的用户可以设置管理员,进行一定权限内的自治管理。用户组可以平级创建扩展,也可以在用户组下建立子用户组。理论上,无论是横向扩展还是纵向扩展,都没有限制,都可以无限扩展下去。某资源可以直接分配给用户组使用,用户组内的用户可以共享该资源。另外,CloudStack还有一个“项目”(Project)功能,即不同用户组下的用户以项目为前提共享一个资源集合(包括物理资源及网络)。

2.2 CloudStack系统的主要组成部分

从物理设备相互连接的角度看,CloudStack的结构其实很简单,可以抽象地理解为:一个CloudStack管理节点或集群,管理多个可以提供虚拟化计算能力的服务器,服务器使用内置磁盘或外接存储,如图2.6所示。接触过虚拟化的读者很容易理解这样一个抽象的架构,尤其是计算服务器和存储,这是传统虚拟化技术中必须使用的结构。图2.6 CloudStack节点的基本结构

但这样肯定是不够的,作为管理节点不可能这么简单地对所有服务器的管理一把抓。这样的架构太过单一,除了一些应用场景外,不能适应大部分灵活、复杂、多变的云环境。在云环境里,网络的设计方式千变万化,一个云管理平台必须有很好的适用性和通用性、异构的兼容性和灵活的可扩展能力。

登录CloudStack的Web界面,在区域的管理界面内可以找到如图2.7所示的架构图。图2.7 CloudStack各部件的架构图

通过图2.7,我们可以很好地理解CloudStack各部件之间的关系,其中区域(Zone)、提供点(Pod)、集群(Cluster)属于逻辑概念,既可以对照实际环境进行理解,也可以根据需求灵活配置使用。以下是对这几个概念的详细介绍。1.管理服务节点

管理服务节点(Management Server)是CloudStack云管理平台的核心,整个IaaS平台的工作统一汇总在管理服务节点中处理。管理服务节点接收用户和管理员的操作,包括对硬件、虚拟机和网络的全面管理操作。管理服务节点会对收到的操作请求进行处理,并将其发送给对应的计算节点或系统虚拟机去执行。管理服务节点还会在MySQL数据库中记录整个CloudStack系统的所有信息,并监控计算节点、存储及虚拟机的状态,以及网络资源的使用情况,从而帮助用户和管理员了解目前整个系统各个部分的运行情况。

CloudStack管理程序是用Java语言编写的。前端界面是用JavaScript语言编写的,做成了Web APP的形式,通过Tomcat这个容器对外发布。在安装CloudStack管理程序的时候,会自动安装和配置Tomcat的相关参数,这样就可以省去用户手工配置和发布Web页面的相关操作了。当安装完CloudStack程序后,剩下的所有管理工作就是直接打开浏览器,访问CloudStack管理程序的页面,在友好的Web图形化页面上进行单击、输入等管理操作。后台程序的逻辑及数据完全通过Web页面展现,用户对后台程序的操作也都在Web页面上进行。简单的访问和操作方式,使用户不再需要安装任何程序。这也是近些年互联网和云计算领域比较流行的一种思想——网站即软件。

由于CloudStack采用集中式管理架构,所有的模块都封装在管理节点的程序中,便于安装和管理,安装的时候使用几条命令就可以完成管理程序的安装,所以在节点上只需要分别安装管理服务程序、MySQL数据库和Usage服务程序(可选)即可。● 管理服务程序:基于Java语言编写,包括Tomcat服务、API服务、

管理整个系统工作流程的Server服务、管理各类Hypervisor的核

心服务等组件。● MySQL数据库:记录CloudStack系统中的所有信息。● Usage服务程序:主要用于记录用户使用各种资源的情况,为计

费提供数据,所以当不需要计费功能时可以不安装此程序。

在小规模的使用环境中,可以将以上所有组件集中安装在一台物理服务器或虚拟机上。而在一个计划上线的生产环境中,根据设计需求,可以部署多台管理服务器来分担不同的功能,举例如下,如图2.8所示。图2.8 部署多台管理服务器● 安装多个管理服务程序并使其成为一个集群,在前端使用负载均

衡设备,可以负载大量的Web访问或API请求。● 将MySQL数据库安装在独立的服务器中,并搭建主从方式(Master-slave)的MySQL数据库(作为一种备份方案)。● 将Usage服务程序安装在独立服务器上,用于分担管理服务器的

压力。

CloudStack在设计中还有一个优点,就是管理服务器本身并不记录CloudStack的系统数据信息,而是全部存储在数据库中。所以,当管理服务程序停止或所在节点当机,所有的计算节点、存储及网络功能会在维持现状的情况下正常运行,只是可能无法接收新的请求,用户所使用的虚拟机仍然可以在计算服务器上保持正常的通信和运行。

CloudStack管理程序的停止并不影响平台的工作,但数据库就不一样了。MySQL数据库中所记录的数据是整个云平台的全部数据,包括整个云平台的规划、物理设备、虚拟机、存储文件、IP使用信息等,因此,在使用过程中一定要注意保护数据库。不得不说,CloudStack在这方面的设计并不完善,到CloudStack 4.0.2版本为止,CloudStack管理程序或集群只能连接单一的数据库,解决方法是为此数据库搭建一个实时同步的从属数据库。如果主数据库出现故障,只要手工进行切换,在做好MySQL数据库备份的情况下,恢复整个系统的正常运行还是可以实现的。所以,保护好数据库中的数据、维持数据库的稳定运行是非常重要的。2.区域

区域(Zone)可以理解为一个数据中心或机房,是CloudStack系统中逻辑范围最大的组织单元,由一组提供点(Pod)、二级存储(Secondary Storage)及网络架构组成。在完成管理服务器的安装后,登录CloudStack的管理界面,第一步就是创建区域,完成整个IaaS平台的初步整合。创建区域的步骤包括网络架构的选择、网络的各种规划和配置、添加计算服务器和存储。对管理员来说,创建区域的时候会设置该区域的所有重要参数,所以必须要对整个区域有一个很好的规划,使区域的架构可以满足目前的使用需求,并适应未来的扩展需求。在完成创建区域的步骤后,随着需求的变化,还可以继续添加提供点、集群、计算服务器和存储。在一个区域内,提供点的数量是没有限制的。

在一个CloudStack系统中可以添加多个区域,区域之间可以完全实现物理隔离,硬件资源、网络配置、虚拟机也都是独立的。在建立一个区域的时候,只能选择一种网络架构——或是基本网络(Basic Zone),或是高级网络(Advanced Zone)。如果系统中有多个区域,每个区域还可以使用不同的网络架构。根据这一特点,就可以实现CloudStack对多个物理机房的统一管理。从业务的需求上说,也可以在一个机房内划分出两个独立的区域,供需要完全隔离的两个系统使用。由于区域之间是相互独立的,所以如果需要进行通信,只能在网络设备上配置打通区域的公共网络(关于网络的内容,将在第3章详细介绍)。区域之间只能复制ISO和模板文件,虚拟机不能进行区域之间的迁移操作,如果需要进行这些操作,应将虚拟机转换为模板,然后复制到另一个区域中使用。

另外,区域对用户是可见的,管理员创建区域的时候可以配置该区域是对所有用户可见的公共区域,或者是只对某组用户可见的私有区域。如果一个用户能够看到多个区域,在创建虚拟机时就可以选择在某个区域中创建虚拟机。3.提供点

提供点(Pod)是CloudStack区域内的第二级逻辑组织单元,可以理解为一个物理机架,包含交换机、服务器和存储。所以,参照物理机架的概念,在CloudStack的提供点中也有网络边界的概念,即所有提供点内的计算服务器、系统虚拟机都在同一个子网中。一般来说,提供点上的服务器连接在同一个或一组二层(Layer2)交换机上,所以在很多实际部署中基本也都是以一个物理机架来进行规划的。一个区域内可以有多个独立的提供点,提供点的数量没有上限。一个提供点可以由一个或多个集群构成,一个提供点中的集群数量也没有上限。为了实现网络的灵活扩展,提供点是CloudStack不可或缺的一个层级。另外,机架对最终用户而言是不可见的。4.集群

集群(Cluster)是CloudStack系统中最小的逻辑组织单元,由一组计算服务器及一个或多个主存储组成。同一个集群内的计算服务器必须使用相同的Hypervisor虚拟化管理程序,硬件型号也必须相同(带有高级功能的XenServer和vSphere可以兼容异构的CPU)。提供点内的集群之间使用任何计算服务器、Hypervisor程序都不会产生冲突,所以一个提供点内可以包含使用不同Hypervisor程序的集群。集群内的虚拟机可以在集群内的不同主机之间实现动态迁移(Live Migrate)。虽然CloudStack不限制集群的数量,但由于提供点所划分的子网范围有限,所以提供点内的集群和主机数量不会是完全无限制的。根据最佳实践的结果,不同类型的计算服务器的建议数量也是不同的,请参考KVM、XenServer和vSphere的相关文档。

需要注意的是,vSphere集群由vCenter服务器进行统一管理,每个vCenter服务器可以管理多个vSphere集群。

集群内可以添加多个作为共享存储所使用的主存储(Primary Storage),主存储的类型没有限制,只要能够与计算服务器正常通信即可。在新版本中,CloudStack可以将虚拟机的镜像文件在多个主存储之间进行迁移,但进行该操作需要关闭虚拟机电源。5.计算节点

计算节点(Host)又称计算服务器,是CloudStack中最基本的硬件模块之一,用于提供虚拟化能力和计算资源,运行用户创建的虚拟机,可以根据系统压力的变化进行弹性增减。计算服务器上需要安装Hypervisor程序用以支持虚拟化技术的实现和功能,目前CloudStack 4.0.2支持Citrix XenServer、VMware ESXi、KVM(包括RHEL和Ubuntu)、Oracle VM等Hypervisor,具体支持的Hypervisor程序及版本可以在CloudStack的图形界面上找到,如图2.9所示。图2.9 Hypervisor程序及版本

计算服务器具有以下特点。● 提供虚拟机需要的所有CPU、内存、存储和网络资源。● 互相通过高速网络互联互通,并与Internet连接。● 可以位于不同地理位置的不同数据中心。● 可以具有不同的规格(如不同的CPU速度、内存大小等)。● 高性能通用x86兼容服务器,自身相对可靠,但规模较大时允许

出现个别服务器故障的情况。

CloudStack可以兼容绝大多数硬件设备,其实就是指所使用的绝大多数硬件能够被Hypervisor程序兼容。在安装Hypervisor程序之前,需要确定该服务器所使用的CPU能够支持虚拟化技术,并在BIOS中打开CPU对虚拟化技术的支持功能。要想知道服务器上的所有硬件是否与Hypervisor程序兼容,可到Citrix、VMware等官方网站查询。6.主存储

主存储(Primary Storage)一般作为每个集群中多台计算服务器共同使用的共享存储存在。一个集群中可以有一个或者多个不同类型的存储,主存储用于存储所有虚拟机内数据的镜像文件和数据卷文件。主存储分为两种,分别是共享存储和本地存储。

共享存储一般是指独立的集中存储设备,它允许对所属集群中的所有计算节点进行访问,集中存储该集群内所有虚拟机的数据。使用共享存储可以实现虚拟机的在线迁移(Live Migrate)和高可用性(High Available),通过专业的存储设备或技术可以保证较高的数据安全性,但相应地会牺牲一定的读写性能。

本地存储是指使用计算节点服务器内置的磁盘存储虚拟机的运行数据文件,可以使虚拟机磁盘拥有很高的读写性能,但无法解决因主机或磁盘故障导致的虚拟机可能无法启动或数据丢失等严重问题。7.二级存储

二级存储(Secondary Storage)又称辅助存储,是CloudStack根据IaaS平台的架构和使用特点专门划分出来的一种存储。二级存储可以支持NFS存储和OpenStack的组件——Swift存储。每个区域只需要一个二级存储,用于存放创建虚拟机所使用的ISO镜像文件、模板文件,以及对虚拟机所做的快照及卷备份文件。

为什么要单独设计一种存储呢?我们可以再分析一下刚刚提到的这几种类型的文件的特点。● 占用很大的空间:安装操作系统所用的ISO文件,动辄都是数吉

字节(GB);而模板内除了操作系统文件外,还包含一些应用程

序和数据,十几吉字节也是很常见的;快照文件大小不一,但数

量可能很多。● 读写频率很低:基本是一次性写入后只有读取操作,使用也不会

非常频繁,与最终用户使用虚拟机数据卷文件的频率相比,读写

频率几乎可以忽略不计。● 文件损坏或丢失既不会影响现有系统的运行,也不会影响用户所

使用的虚拟机。

所以,像这种占用空间大、读写频率低的数据文件,我们可以称之为冷数据。这些数据对整个系统而言并不是关键数据,所以使用配置不高的、最简单的NFS来存储就足够了,只需要很低的成本就能满足系统使用的需求。

2.3 CloudStack的架构

2.2节中介绍了CloudStack中所有的关键组件,本节主要介绍CloudStack管理平台是如何将这些组件进行统一管理,并使它们相互合作的。

从网络通信和数据交换的角度进一步分析CloudStack的架构,如图2.10所示。图2.10 CloudStack网络通信架构

从图2.10的左边可以看到,用户通过界面登录,前端界面与后端管理程序的交互使用了目前最流行、最通用的做法:完全调用RESTful风格的API来实现。用户所使用的Web界面上的任意功能都由Web转义为API命令发送给API服务,API服务接收请求后交由管理服务进行处理,然后根据不同的功能将命令发送给计算节点或系统虚拟机去执行,并在数据库中进行记录,完成后将结果返回前台页面。而使用目前最通用的RESTful API接口也是出于对兼容性的考虑,既可以使用CloudStack本身进行统一管理,也支持用户根据需求开发全新的界面或通过其他平台调用CloudStack的API来管理,通用性强,在对编程语言的支持上也没有任何障碍。由CloudStack Usage程序所统计的监控数据可以通过API进行调用,为计量计费提供了很好的支持。如果用户使用亚马逊的EC2接口管理在亚马逊云上的虚拟机,就可以使用相同的EC2 API命令来管理CloudStack平台。

下面分析一下CloudStack管理服务是如何管理物理基础设施的。最简单、最直接的办法就是调用设备所开放的API命令,如XenServer的XAPI、vCenter的API;而对不方便直接调用API的设备(如KVM),会采取安装代理程序(Agent)的方式协助进行管理。在第3章中会介绍CloudStack的很多网络功能,这些功能在旧版本中只能由系统虚拟机实现,新版本的改进对用户的自服务有很大的帮助。但系统虚拟机毕竟只是一个虚拟的机器,就算提高资源配置,其性能也是有限的,如果遇到对网络要求较高的情况就会出现瓶颈。从CloudStack 4.0开始,支持使用其他物理设备扩展网络功能来代替虚拟路由器的对应功能,既保持了CloudStack的原有架构,又提升了性能以满足应用需求。如图2.10所示,包括Juniper的SRX防火墙、Citrx的NetScaler设备、F5的负载均衡设备,都是调用这些设备上开放出来的特有API来进行控制的。如果未来需要扩展其他可支持的设备,也会选择这两种方法之一来 实现。

CloudStack只对这3种设备的某些型号提供支持,并没有全面提供支持,毕竟实现全面支持需要做很多工作并考虑兼容性。但作为开源平台,在开放出这样的接口之后,相信会有很多第三方企业来一起协助开发支持接口。

细心的读者可能会发现,这里并没有介绍存储设备,图2.10中也没有画出管理节点连接到存储设备的线。其实,CloudStack并不是直接对存储设备进行管理。在2.2节中曾经介绍过,在CloudStack架构中,存储有两种角色,它们分别提供不同的功能,具体如下。● 主存储通过调用计算节点所使用的Hypervisor程序进行管理,如

在存储上创建磁盘或执行快照功能等,其实都是通过调用

Hypervisor程序的API来进行的。这样做的优点是,这些

Hypervisor程序能支持什么类型的存储,CloudStack就能直接配

置和使用而不需要进行更多的兼容性开发;其缺点是,最新的存

储技术(如分布式存储或对象存储等)就没有办法在XenServer

和vSphere这样的商业产品上得到支持了。虽然使用KVM在理论

上可以使用各种新的分布式存储,但使用效果是否能够满足虚拟

化生产的需要,还没有定论。● 二级存储是一个独立的存在,它不在某一个计算节点或集群的管

理下,在CloudStack的架构中就有二级存储虚拟机挂载此存储进

行管理的设计,具体方式会在下面具体讲解。

系统虚拟机是整个CloudStack架构中很有特色且非常重要的组成部分,会承担很多重要的功能。CloudStack的系统虚拟机有3种,分别是二级存储虚拟机(Secondary Storage VM)、控制台代理虚拟机(Console Proxy VM)、虚拟路由器(Virtual Router VM)。

系统虚拟机有特别制作的模板,使用的操作系统是Debian 6.0,只安装必备的程序用以减小系统虚拟机所消耗的资源,安装较新的补丁以防止可能存在的漏洞,针对不同的Hypervisor有不同格式的模板文件,并安装支持此Hypervisor的驱动和支持工具来提高运行性能。CloudStack使用同一个模板来创建系统虚拟机,它会根据不同角色的系统虚拟机进行特殊配置,当系统虚拟机创建完成后,每种系统虚拟机会安装不同的程序,使用不同的配置信息。

CloudStack为了保证系统的正常运行,所有的系统虚拟机都是无状态的,不会独立保存系统中的数据,所有相关信息都保存在数据库中,系统虚拟机内存储的临时数据也都是从数据库中读取的,方便系统虚拟机的运行及任务的执行。所有的系统虚拟机都带有高可用性(HA)的功能。当CloudStack管理节点检测到系统虚拟机出现问题时,将自动重启或重建系统虚拟机(系统会通过数据库中记录的配置信息进行重建)。管理员也可以随时手动删除系统虚拟机,然后由系统自动重建(除虚拟路由器外),无须担心删除系统虚拟机会造成数据丢失或功能错误。系统虚拟机对普通用户而言是透明的、不可直接管理的,只有系统管理员可以检查及访问系统虚拟机。● 二级存储虚拟机(Secondary Storage VM)用于管理二级存储,

每个区域(Zone)内有一个二级存储虚拟机。二级存储虚拟机

通过存储网络连接和挂载二级存储,直接对其进行读写操作,如

果不配置存储网络,则使用管理网络进行连接。通过公共网络实

现ISO和模板文件的上传和下载、用户虚拟机的卷下载、将用户

虚拟机的快照存放在二级存储上、多区域之间ISO和模板文件的

复制等重要功能。可以配置SSL加密访问,以达到保护用户数据

的目的。● 控制台代理虚拟机(Console Proxy VM)支持用户使用浏览器在

CloudStack的Web界面上打开虚拟机的图形界面。每个区域内默

认生成一个控制台代理虚拟机。当CloudStack平台上有较多用户

打开虚拟机的Web界面时,系统会自动建立多个控制台代理虚拟

机,用以承担大量的访问进程,对应的配置可以在全局变量中找

到。访问控制台默认使用域名realhostip.com进行访问,DNS会

将该域名解析为控制台代理虚拟机的公共网络地址。可以配置

SSL加密访问,以达到保护用户数据的目的。用户虚拟机的图像

通过管理网络从所在的主机获取,而不必关心用户虚拟机的网络

架构,这样便实现了代理的目的。● 虚拟路由器(Virtual Router)可以为用户提供虚拟机所使用的多

种功能,它在用户第一次创建虚拟机时自动创建。在基本网络里

只有DHCP和DNS转发的功能;在高级网络里除了DHCP和DNS

转发的功能外,还可以实现类似防火墙的功能,包括网络地址转

换(Network Address Translation,NAT)、端口转发(Port

Forwarding)、虚拟专用网络(Virtual Private Network,VPN)、

负载均衡(Load Balance)、网络流量监控,以保证用户虚拟机

在隔离网络中与外界通信的安全。

第3章 CloudStack的网络功能

3.1 网络即服务

说起CloudStack,就得着重介绍一下它提供的网络功能。在CloudStack完全开源之前,其网络功能就一直是它最大的卖点。本章会对CloudStack提供的所有网络功能进行详细讲解。当然,随着版本的更新,CloudStack的网络功能还会不断加强。但有了本章的基础,读者对CloudStack新增的网络功能会更容易理解。

在正式开始讨论CloudStack的网络结构之前,先看一个现实中的场景。

有一位项目经理,为了部署新的业务系统而需要配置一套IT基础设施资源。在传统的IT模式下,此时他需要向系统管理员提交申请,除了服务器与存储空间资源外,还需要一部分网络资源,可能包括服务器接入所需要的私有网络、能够连接到Internet的防火墙的保护及负载均衡器等。系统管理员拿到需求后,首先会评估现有的网络资源能否满足需求。如果不能满足,系统管理员会申请采购,这个过程通常会很长。如果现有资源可以满足需求,系统管理员则会选择一个合适的时机(通常是在业务低峰时段)进行网络结构与配置的变更,最后将结果反馈给申请人。显然,这种模式的周期漫长且效率低下,很难满足业务快速变化的要求。

如果这位项目经理为了快速获取IT基础设施资源以让自己的业务能够快速上线,而选择使用像亚马逊AWS这样的公有云服务平台,接下来他所经历的就完全不同了,他只需要登录自服务页面进行一些简单的配置。例如,先申请一个安全组,对安全组的访问控制策略进行配置,再申请网络负载均衡服务,配置公网IP地址的NAT映射等,只需几分钟时间便可以实现网络方面的所有需求。

在这里,传统的网络物理设备上增加了一个经过抽象的虚拟网络资源层,原来针对网络基础设施的烦琐工作变成了基于虚拟网络服务的简单配置,我们称这种云平台上的新的服务模式为网络即服务(Network as a Service)。作为一个典型的IaaS云计算平台,CloudStack的网络结构与功能完全依照网络即服务的思想进行设计。看到这里,最终用户会放心很多,因为它减少了很多工作量,他们不需要了解网络拓扑,也不用关心物理网络的所有技术细节。但如果想部署、运维并管理CloudStack云平台,仍然需要了解这些细节,甚至要对这些细节非常清楚。CloudStack的网络肯定构建在我们需要的特定物理网络之上,我们要配置交换机,要了解VLAN,要知道主机流量标签,要熟悉网卡绑定……于是我们明白了,天下没有免费的午餐。本章会详细介绍CloudStack提供的网络功能,帮助读者了解如何规划网络拓扑,但不会详细介绍配置交换机和路由器时设备端口应如何设置VLAN、网卡接线等,因为这些已经超出本书的讨论范围。

3.2 网络类型

我们知道,传统的数据中心里都有一整套网络拓扑。如果拿一个数据中心与CloudStack的一个区域(Zone)来做对比,可以认为一个区域对应于一套物理网络设置。也就是说,CloudStack中物理网络的设置和拓扑结构是以区域为边界的,同一个区域共享一套物理网络拓扑(当然,可以让多个区域共享相同的物理网络拓扑)。

在创建某一种网络类型的区域时,首先需要创建物理网络(Physical Network)。所谓物理网络,其实是CloudStack中的一个基本的逻辑概念,无论是基础网络模式还是高级网络模式都会涉及。一个物理网络将包括一种或多种类型的网络流量(Network Traffic),建议在物理设备层面对应一个物理网络接口。

在CloudStack中,物理网络包括4种网络流量,分别是公共网络(Public Network)、来宾网络(Guest Network)、管理网络(Management Network)和存储网络(Storage Network)。公共网络是高级区域所独有的。在基本区域里没有公共网络的概念,可认为来宾网络就是公共网络。

除此之外,CloudStack里还有一种网络是本地链路网络(Link-local Network)。这种网络只提供给系统虚拟机使用,只负责主机与系统虚拟机之间的通信。

下面将对这几种类型的网络类型进行具体介绍。

3.2.1 公共网络

不要一看到“公共网络”就认为必须连接到Internet,这只是一种情况,并且实际操作中这样应用的很少。因为公共IP池是非常昂贵的资源,所以还是需要对其进行有效的管理。只有运营商之类的机构才有能力直接使用Internet的IP资源作为公共网络,但他们不一定会这么做,因为安全性对它们而言很重要。我们所说的公共网络是CloudStack云环境中的一个概念,它是在高级网络模式下使用的一种网络流量类型,是经过隔离的私有来宾网络之间进行通信及对外通信的共享网络空间。所有隔离的私有来宾网络均需要经过公共网络与其他私有来宾网络通信(注意:同一来宾网络下客户虚拟机之间的通信不经过公共网络),或者经过公共网络与外部网络(如Internet)通信。当然,在某些网络环境下,也可以直接将Internet网络作为公共网络使用。

3.2.2 来宾网络

来宾网络是用户虚拟机直接使用的网络,一般属于用户的私有网络空间。每一个用户所创建的虚拟机都将首先接入来宾网络。在基础网络模式中,多个用户将共用一个来宾网络(Shared类型),彼此之间需要通过安全组进行隔离。在高级网络模式中,每个用户将拥有专属的来宾网络(Isolate类型),这些来宾网络属于不同的VLAN,彼此之间通过VLAN进行隔离,通过虚拟路由器的设置进行互访。

3.2.3 管理网络

CloudStack内部资源之间的通信需要借助管理网络进行,这些内部资源包括管理服务器发出的管理流量、服务器主机节点的IP地址与管理服务器通信的流量、系统虚拟机(System VM)的管理IP地址与管理服务器及服务器主机节点IP地址之间的网络通信流量。

3.2.4 存储网络

在CloudStack中,存储网络并没有它的名字所代表的严格含义。相反,其实它只不过是二级存储虚拟机(SSVM)与二级存储(Secondary Storage)设备之间通信的网络流量而已。如果没有设置这个网络,默认会使用管理网络。由于这个网络主要承担模板、快照及ISO文件的复制或迁移工作,因此对带宽的要求很高,有条件的话可以单独设置,这样管理网络就不会受实际操作的影响了。

3.2.5 本地链路网络

以上4种网络是CloudStack根据自己的功能需求而进行的区分,并非要求我们必须采用这样的物理网卡设置。实际上,这4种流量可以在同一块物理网卡上传送,只要我们对交换机的端口进行适当的设置即可。如果条件允许,也可以对网卡进行绑定来提高稳定性或吞吐率。例如,主机有8块网卡,那么这4种流量就可以通过将网卡两两绑定来提供更优质的服务。同样,在基本区域下,通过CloudStack的界面无法将不同的网络流量指定到不同的物理网卡上,也就是说,想增加吞吐或提高稳定性,只能靠网卡绑定实现。

本地链路网络只供系统虚拟机使用,默认使用IP地址段169.254.0.0/24。在CloudStack环境搭建完成后,每个计算节点的物理机上会自动建立本地链路网络。

在系统虚拟机的创建过程中,多数配置是无法得到的,所以设计了本地链路网络,让CloudStack管理节点将配置信息传入系统虚拟机。根据安全策略,虚拟路由器无法通过管理网络或公共网络的IP地址对其进行直接访问,而是通过主机的这个链路来传输配置 参数。

3.3 虚拟路由器

不管是基本区域还是高级区域,虚拟路由器(Virtual Router)都是不可或缺的系统组件。在基本区域中,虚拟路由器负责提供来宾网络的DHCP、DNS等服务;而在高级区域中,虚拟路由器提供了来宾网络与公共网络之间的接口,并为来宾网络提供了各种网络服务,包括防火墙、NAT地址映射、DHCP、DNS、负载均衡、端口转发服务、VPN、VPC等一系列高级网络服务。

在默认情况下,应为每个租户的来宾网络配置一个虚拟路由器。当租户的来宾网络创建完成后,将从来宾网络的VLAN资源池中获得一个预分配VLAN ID。当租户创建属于该来宾网络的第一个虚拟机实例时,CloudStack会首先创建该来宾网络的虚拟路由器。当虚拟路由器创建完成并正常运行后,虚拟机实例才会被创建。如果需要,租户可以创建多个属于自己的私有来宾网络,相应地,每个来宾网络会对应生成一个新的虚拟路由器。

在基础网络模式下,虚拟路由器仅仅作为共享来宾网络的DHCP、DNS及User Data服务的提供者;而在高级网络模式下,虚拟路由器的作用就重要得多了,它不仅将成为租户的私有来宾网络访问公共网络的接口,还将为来宾网络内的虚拟机实例提供各种网络服务(这部分内容将在3.5节具体介绍)。

虚拟路由器的网络结构如图3.1所示。图3.1 虚拟路由器的网络结构

虚拟路由器是为满足来宾网络的网络服务而提供的系统模块,实际上也是一个虚拟机,我们称之为系统虚拟机。虚拟路由器要占用一部分系统资源,并且不同的来宾网络都要拥有单独的虚拟路由器,在大规模部署中,这一部分所占用的资源也要考虑在内。好在虚拟路由器是高度定制的系统虚拟机,默认情况下只会分配256MB内存,CPU核心也会精简到只安装必要的服务,整个虚机的磁盘大小只有几百兆字节,因此单个虚拟机所占资源很少。以下是系统虚拟机的一些信息(CloudStack的所有系统虚拟机来自同一个模板)。● 采用Debian 6.0版本32位操作系统(新版本有可能支持64位操作

系统,管理员也可以定制操作系统)。● 根据不同的模板选择安装Xen、VMware或KVM,以实现更好的

性能。● 只安装必要的网络工具,如Haproxy、SSHD、IPSec、

IPTABLES等。

3.4 基础网络

下面介绍CloudStack基本区域(Basic Zone)的网络模式,即基础网络模式,以帮助读者了解基本网络模式的架构特点与基本原理,以及其能够实现的主要功能。

3.4.1 基础网络概述

第一次部署CloudStack并创建一个区域(Zone)时,有两种类型的区域可供选择,分别是Basic Zone与Advanced Zone。对于一个IaaS云基础架构来说,网络结构及功能的实现是其中极为重要的部分。CloudStack的两种风格完全不同的网络结构及与之相对应的功能如图3.2所示。图3.2 CloudStack的两种网络模式

基础网络是CloudStack中Basic Zone所使用的网络模式,其最主要的特点是类似亚马逊AWS风格的扁平式网络结构。这种结构可以充分利用IP地址资源,十分适合进行大规模的扩展。基础网络模式中所有不同租户的虚拟机将被分配到同一个网络中,并获得连续的IP地址,而彼此之间的安全隔离是通过安全组(Security Group)的方式实现的。另外,相对于高级网络模式,基础网络模式提供的虚拟网络服务功能较少,只能提供DHCP、DNS及User Data功能,而其他的网络服务功能(如路由转发、NAT、负载均衡)则需要通过外部物理网络设备实现。

3.4.2 安全组

在基础网络模式下,不同租户之间的安全隔离是通过安全组(Security Group)的方式实现的,每一个用户都拥有一个默认的安全组,当用户申请创建虚拟机后,虚拟机会被添加到默认的安全组中。同时,用户也可以根据需要创建新的安全组,并将新建的虚拟机添加到其中。

什么是安全组?简单地说,安全组就是一组具有相同网络访问策略的虚拟机的集合。用户可以通过配置安全组来控制对虚拟机的网络访问。在默认情况下,安全组会拒绝所有来自外部的网络流量(我们称之为默认的入站策略——Ingress Rules)通过,同时允许所有对外发送的网络流量(我们称之为默认的出站策略——Egress Rules)通过。一旦配置了入站策略,那么相应的外部访问就会被允许;而一旦配置了出站策略,那么除了被配置为允许的网络访问,所有其他对外访问都会被拒绝。

那么,安全组到底能够进行哪些具体的配置呢?我们看一下表3.1。表3.1 安全组可配置项

举个例子。用户创建了虚拟机A(获得的IP地址为192.168.10.25),并将其添加至默认的安全组“Default Security Group”中。然后,用户创建了新的安全组“New Security Group”,并将新创建的虚拟机B(获得的IP地址为192.168.10.30)添加到其中。那么此时,虚拟机A与虚拟机B是无法相互通信的。随后,用户对安全组“New Security Group”进行了配置,如表3.2所示。表3.2 安全组配置项参数举例(1)

那么此时,虚拟机A可以通过“Ping”命令访问虚拟机B(反之不可以)。

用户接着对默认安全组“Default Security Group”进行配置,如图3.3所示。表3.3 安全组配置项参数举例(2)

这时,虚拟机B可以通过SSH工具登录并访问虚拟机A,如图3.3所示。图3.3 配置安全组后的访问结果

3.4.3 参考架构

下面我们通过讨论一个典型的CloudStack基础网络参考架构进一步加深对基础网络结构的认识与理解,如图3.4所示。图3.4 基本网络拓扑架构

在结构方面:所有资源部署在一个Zone(Zone 1)中;Zone1由若干Pod组成,由于每一个Pod的来宾网络属于一个独立的广播域,所以我们为每个Pod的来宾网络分配一个子网;在Pod之下是Cluster,同一个Pod下所有Cluster的来宾网络位于同一子网内,来自不同租户的所有虚拟机被放置在该来宾网络内;对于每一个虚拟机,通过安全组的方式实现安全隔离。

在网络物理设备方面:为每一个Pod配置一台交换机L2作为接入设备使用;为整个Zone配置一个(组)交换机L3作为核心交换与转发设备使用;在Internet与内网的边界部署防火墙设备,提供内外网之间的NAT转换及网络保护;在核心交换机L3上可以接入负载均衡设备,为来自外部的访问请求提供负载分发服务。

3.5 高级网络

在3.4节中介绍了CloudStack的基础网络模式。在本节中,我们将讲解CloudStack高级网络的基本概念和具体功能。读完本节内容,读者会对高级网络的应用方式有更深刻、直观的理解。

3.5.1 高级网络概述

通过前面的介绍我们了解到,CloudStack通过基础网络模式实现了一种类似AWS的大规模扁平网络拓扑。在这种模式下,不同的租户将虚拟机实例部署在同一个来宾网络的子网内,彼此之间通过安全组实现访问隔离,并且同一个虚拟机只能被接入一个来宾网络之中。这种模式的优点是结构简单,便于应对大规模的部署与扩展,缺点是无法应对更加复杂的网络拓扑,也无法提供更加丰富的网络服务,而高级网络模式则可以弥补这些不足,如图3.5所示。图3.5 高级网络VM访问架构

在CloudStack的高级网络模式下,每个租户将获得一个或多个私有来宾网络,每个来宾网络都属于一个单独的VLAN,且由虚拟路由器为这些来宾网络提供网关服务。这样一来,一个个来宾网络就好像一个个独立的“房间”,而虚拟路由器是这些“房间”里唯一能够打开的门。位于这些“房间”内的虚拟机实例足够安全,租户可以通过控制虚拟路由器上的防火墙服务策略来保证内部虚拟机实例只接受经过授权的访问。

除了来宾网络,公共网络也是高级网络模式的重要组成部分。如果一个个来宾网络是一个个独立的“房间”,那么公共网络就是连接所有“房间”的“楼道”,所有进出来宾网络的网络流量都要通过公共网络传输。

高级网络还可以通过虚拟路由器为来宾网络内的虚拟机实例提供各种高级网络服务,3.5.2节将具体介绍这方面的内容。

3.5.2 高级网络服务

当高级网络创建完成后,虚拟路由器会作为租户来宾网络的网关使用,同时租户来宾网络内的虚拟机实例通过虚拟路由器的DHCP与DNS服务自动获取IP地址与主机名。此外,高级网络模式还会通过虚拟路由器为来宾网络的虚拟机实例提供其他高级网络服务。CloudStack可以提供的高级网络服务包括防火墙、源NAT、静态NAT、负载均衡、端口转发与VPN。本节将对这些高级网络服务逐一进行介绍。

源NAT是指定公共网络的IP地址。如图3.6所示,虚拟路由器会将所有来宾网络内的虚拟机实例发起的对公共网络目标地址的请求映射为基于该公共网络IP地址的请求,所有虚拟机实例的对外请求都会使用该公共网络的IP地址。虚拟路由器默认会将获得的第一个公共网络IP地址作为源NAT地址(无须配置)。图3.6 源NAT功能示意图

静态NAT用于指定公共网络的IP地址,同时指定目标虚拟机实例的IP地址。如图3.7所示,虚拟路由器会将该公共网络的IP地址与这台虚拟机实例的IP地址进行绑定,这台虚拟机实例的所有网络请求和访问都会使用该公共网络IP地址,同时该公共网络IP地址不能再被其他虚拟机实例使用。源NAT地址不能配置静态NAT功能。图3.7 静态NAT功能示意图

在默认情况下,虚拟路由器会拒绝所有来自外部的访问请求,同时允许所有对外的访问请求。用户可以通过配置防火墙对外部访问的源IP地址、网络协议、端口范围进行限制,如图3.8所示。图3.8 防火墙功能示意图

负载均衡用于指定虚拟路由器公共网络的IP地址及网络端口,同时指定使用负载均衡服务的虚拟机实例及对应的网络端口,虚拟路由器会将公共网络访问中对指定目标地址及网络端口的请求分发到这些虚拟机实例的对应端口上,如图3.9所示。CloudStack的负载均衡服务可以配置负载均衡的分发模式,支持的分发模式有轮询、基于最少连接数、基于源地址 3种。图3.9 负载均衡功能示意图

端口转发用于指定虚拟路由器公共网络的IP地址及网络端口,同时指定作为转发目标的虚拟机实例及对应的网络端口,虚拟路由器会将公共网络访问中对指定目标地址及网络端口的请求转发到这台虚拟机实例的对应端口上,如图3.10所示。使用端口转发功能可以将访问同一公共网络IP地址但被分发至不同网络端口的请求分别转发到不同的虚拟机实例上,从而减少公共网络IP地址的消耗。图3.10 端口转发功能示意图

CloudStack允许用户创建虚拟私有网络(VPN)访问自己位于来宾网络内的虚拟机实例。CloudStack支持L2TP IPSec VPN类型的VPN服务,将虚拟路由器作为VPN的服务网关。如图3.11所示,用户只要在自己的客户端设备上创建一个新的VPN连接,访问启用了VPN服务的虚拟路由器上的公共网络的IP地址,经过身份验证后便可建立网络加密隧道。此时,用户的客户端设备将被分配一个CloudStack的VPN客户端IP地址,并可以访问来宾网络内的虚拟机实例。图3.11 VPN功能示意图

3.5.3 参考架构

与前面介绍基础网络时一样,本节也讨论一个CloudStack高级网络的参考架构,以帮助读者加深对高级网络结构的认识和理解。

如图3.12所示是CloudStack高级网络的参考架构。在Zone中有两个租户,分别是Guest 1和Guest 2,每个租户各分配了一个来宾网络:Guest 1的来宾网络叫做“Guest Network 1”,VLAN ID为1500;Guest 2的来宾网络叫做“Guest Network 2”,VLAN ID为1501。Zone的公共网络VLAN ID为150。

创建来宾网络“Guest Network 1”并在其中建立第一个虚拟机实例Guest1 VM1,系统会为该来宾网络创建虚拟路由器Guest 1 VR。根据Zone的ClDR参数的配置,这里会为虚拟路由器的内部接口分配IP地址10.1.1.1,并将其作为该来宾网络内所有虚拟机实例的网关地址。同时,虚拟路由器会通过DHCP服务为虚拟机实例Guest1 VM1分配IP地址10.1.1.2。随后创建的Guest 1的虚拟机实例的IP地址会依次分配。接着创建Guest 2的虚拟机实例Guest2 VM1。同样,系统会创建虚拟路由器Guest 2 VR,并为其分配内部网关地址10.1.1.1。Guest2 VM1的IP地址为10.1.1.2。

到这里实际上已经完成了租户Guest 1与Guest 2的私有网络的创建,并配置了虚拟路由器作为私有网络的网关。当租户虚拟机实例互访时,将在租户的来宾网络内部进行通信。当虚拟机实例需要访问其他租户系统的IP地址时,流量会经过虚拟路由器的NAT服务将私有地址映射为一个公共网络的IP地址(如65.37.141.36),然后通过公共网络及其他租户的虚拟路由器提供的静态NAT、负载均衡或端口转发服务访问目的地址。公共网络的网关地址将直接指向物理交换机,并可以通过防火墙与Internet建立连接。图3.12 隔离网络架构示意图

3.5.4 共享型来宾网络

我们知道,一般情况下交换机只能支持4096个VLAN,如果为每个租户的私有来宾网络都分配一个单独的VLAN,那么整个网络所能容纳的租户数量将会受到极大的限制。而且,对某些业务来说,并不需要将不同租户的虚拟机实例分配到不同的VLAN中去。CloudStack通过共享型(Shared)的来宾网络解决了这个问题。

在CloudStack中,按照特性将来宾网络分为两种类型,分别是Isolate与Shared,如图3.13所示。可以通过创建不同的网络服务方案来生成不同类型的网络。图3.13 选择网络类型

高级网络模式下的来宾网络类型都是Isolate。如图3.14所示是一个典型的Isolate型来宾网络,每个租户的来宾网络都属于单独的VLAN,并需要经过虚拟路由器和公共网络与外界进行通信。图3.14 Isolate型网络架构

如图3.15所示,在Shared型来宾网络中,不同租户的虚拟机实例可以同时部署在同一个来宾网络中并属于相同的VLAN。虚拟路由器在这里将不再是来宾网络的出口,而只是作为DHCP、DNS服务的提供者。所有属于Shared型来宾网络的虚拟机实例的网关将直接指向物理交换机(物理网关)。使用Shared型的来宾网络,不但可以极大地节省VLAN资源,还可以与现有物理网络设备更好地结合,以实现更加复杂的网络拓扑。图3.15 Shared型网络架构

3.5.5 VPC简介

下面简单介绍VPC的相关知识。1.VPC的概念

在CloudStack 4.0及之后的版本里,新增了一种网络服务模式——VPC(Virtual Private Cloud)。CloudStack VPC的概念源自亚马逊的AWS VPC服务,如图3.16所示。

我们知道,对中小型用户来说,直接租用AWS的EC2计算服务,并申请创建自己的私有网络、EIP及安全组,即可搭建一套位于云上的生产系统。但对规模稍微大一些的企业用户来说,在租用AWS的云计算服务的同时,还希望能对位于云上的资源及自己数据中心内部的资源进行统一的访问和管理,也就是说,他们希望云上的虚拟资源池是自己已有数据中心的外部延伸。但是,基本的EC2和网络服务无法满足这种需求。于是,AWS推出了VPC服务。使用VPC服务后,用户可以在自己的数据中心与位于亚马逊服务器中的VPC云资源池之间通过Site-to-Site VPN的方式建立加密网络隧道,使自己的数据中心直接通过Internet访问亚马逊的VPC云资源池。图3.16 VPC的概念

对CloudStack来说,VPC不仅参考了AWS VPC的概念,也解决了原有CloudStack网络服务的不便之处。在CloudStack网络架构出现之前,如果租户创建了多个不同的来宾网络,并且在每个来宾网络里都部署了虚拟机实例,那么属于不同来宾网络的虚拟机实例之间的相互访问会比较“曲折”,网络流量需要经过公共网络,这对用户来说不是最好的解决方案,如图3.17所示。图3.17 Isolate型网络的访问方式

而当CloudStack中增加了VPC的特性之后,在VPC中由租户创建的来宾网络(称为“层”——Tier)会同时连接到同一个VPC虚拟路由器,该VPC虚拟路由器会负责与不同“层”之间的路由器进行通信,因此,租户内部的网络流量就不需要再到公共网络去“绕一圈”了,如图3.18所示。这无疑是一种更加合理的网络方案。图3.18 VPC架构2.VPC的组成

一个VPC由以下部分组成。● VPC:VPC扮演了网络容器的角色,其中包含租户的多个相互隔

离的来宾网络。虚拟路由器让这些来宾网络之间可以互相通信。● 网络层(Tier):代表租户的一个来宾网络,每一个网络层作为

一个隔离的网络都有自己的VLAN ID和ClDR。● 虚拟路由器(VPC Virtual Router):在VPC创建完成后,虚拟路

由器会被自动创建。在VPC中,虚拟路由器是网络访问的中枢,

它连接着不同的网络层、专有网关、VPN网关和公共网络。对于

每一个网络层,虚拟路由器都有与其相对应的接口和IP地址,并

作为该网络层的默认网关。虚拟路由器还为网络层内的虚拟机实

例提供DNS和DHCP服务。● 公共网关(Public Gateway):VPC中的虚拟机实例需要通过

CloudStack的公共网络访问外部网络。这里的公共网关地址就是

CloudStack公共网络的网关地址,该地址将在VPC创建的时候被

自动分配,无须用户配置。● 专有网关(Private Gateway):VPC通过添加专有网关与数据中

心内部的其他网络区域进行通信。● VPN网关(VPN Gateway):VPC通过Site-to-Site VPN与远程用

户数据中心网络建立连接。在CloudStack中配置一个指向用户数

据中心的VPN网关设备的VPN客户网关(VPN Customer

Gateway),之后就可以在VPC中建立并配置VPN网关了。● 访问控制列表(ACL):可以在虚拟路由器上定义访问控制列表,

以控制不同网络层之间及网络层与外部网络之间的网络流量。访

问控制列表可以对所有进出网络层的IP地址范围、网络端口范围、

网络协议进行限制。● 负载均衡器(Load Balance):VPC可以对网络层中的虚拟机实

例提供负载均衡服务。

在CloadStack中,虚拟路由器的功能如图3.19所示。图3.19 CloudStack虚拟路由器的功能

第4章 CloudStack的安装与配置

4.1 CloudStack系统的安装与规划

有很多用户反映,在配置CloudStack参数的时候不知道该如何填写,这通常是对CloudStack的整体架构不清楚,不知道应该如何规划整套系统,或者在不是十分了解CloudStack系统的情况下填写了错误的配置信息导致系统四处报错、无法正常运行所致。因为在填写参数的时候,简单的错误可以直接查出,但大部分问题只有在系统运行过程中多个组件和参数配合使用时才会暴露出来,所以,作为一项系统工程,在搭建系统前进行规划是非常重要的,如果规划的信息正确,一次安装就可以保证系统顺利运行。为了帮助读者在学习CloudStack的安装方法时更好地理解其操作及整个结构,本书规划了一个完整的系统。

如果完全按照本书的规划,可以完成基于CentOS或Ubuntu操作系统的管理节点的安装和配置、NFS存储设备的配置,以及XenServer、KVM、vSphere这3种类型的计算节点的安装和配置。一个CloudStack管理节点管理一套基本网络类型的区域(Zone)并包括3个不同Hypervisor的群集;一个CloudStack管理节点管理一套高级网络类型的区域并包括3个不同Hypervisor的群集。

在本书的系统规划中,分别设计了一套基本网络环境和一套高级网络环境,每套环境有独立的IP地址范围。虽然在CloudStack中,一个管理节点可以管理多个区域(包括基本网络区域和高级网络区域),但由于网络方面的配置较为复杂,而本书主要是讲解CloudStack的基本安装配置方法的,所以当读者熟悉这些操作之后,就可以结合网络知识对CloudStack架构进行扩展了。建议读者在学习安装方法的过程中,随时回到本节查看架构拓扑图及IP地址和VLAN等规划表,理解架构规划与参数配置之间的对应关系。

4.1.1 基本网络架构的配置信息

在搭建基本网络架构的系统时,我们会安装一个CloudStack管理节点并配置MySQL数据库、XenServer群集、KVM群集,每个群集各含有2个计算节点。使用另外一台Linux节点(基于CentOS操作系统)来提供NFS存储,配置不同目录供二级存储和各个群集的主存储使用。基本网络架构如图4.1所示。在基本网络架构中,最重要的安全组功能无法在ESXi主机上实现,所以本书不再介绍vSphere的安装,如果读者对此感兴趣,可以参照高级网络架构的配置方法进行安装和测试。图4.1 基本网络区域的拓扑结构

在本章规划的这个标准的基本网络环境中,管理节点、计算群集、存储及客户虚拟机的IP地址都在同一个网段中。在第3章中曾经介绍过,就算是扁平的基本网络也提供了多IP网段的扩展方式以适应不同的扩展需求。希望读者先了解标准的规划环境,再根据第3章的内容进行深入研究。这里规划的主机名稍显复杂,主要是为了提醒读者所使用的主机会应用于何种类型的CloudStack网络中。

基本网络区域内所有节点的IP地址和操作系统信息如表4.1所示。表4.1 基本网络区域内所有节点的配置

基本网络区域所使用的NFS存储路径信息如表4.2所示。表4.2 基本网络区域所使用的NFS存储路径

基本网络区域内所有节点的硬件配置建议如表4.3所示。表4.3 基本网络区域所有节点的硬件配置

为了统一,本书将所有密码都设置为“cspassword”(包括所有节点的root用户,以及MySQL数据库中的root和cloud用户)。在真实环境中,出于对安全性的考虑,一定要将密码设置为复杂的强密码。

由于很多读者的实验环境中硬件资源不足,常会考虑是否可以把CloudStack的这套环境都架设在虚拟机中,也就是说,是否可以在一台高配置的物理机上完成整套环境的搭建。由于二层虚拟化技术的实现,所以在表4.3中也提到了,进行测试的所有节点均可使用虚拟机,但需要的最低配置不变。也正是因为二层虚拟化架构,如果在测试中出现问题,会使排查故障的步骤更为复杂,不利于读者理解CloudStack的网络架构,再加上性能上的大量损耗,所以建议读者在学习CloudStack的早期,尽可能使用物理节点搭建整套 环境。

4.1.2 高级网络架构的配置信息

在搭建高级网络架构的CloudStack系统时,我们同样会安装一个CloudStack管理节点并配置MySQL数据库、XenServer群集、KVM群集和vSphere群集,每个群集各含有2个计算节点。使用另外一台Linux节点(基于CentOS操作系统)来提供NFS存储,配置不同目录供二级存储和各个群集的主存储使用。高级网络架构如图4.2所示。图4.2 高级网络区域的拓扑结构

高级网络区域所使用的IP地址规划及在添加区域时需要填写的信息如表4.4所示。表4.4 高级网络区域的相关配置信息

在高级网络中,IP地址的分配方式和基本网络有很大区别。CloudStack设计了类似传统概念上的内网和外网。由第3章中关于高级网络架构的介绍可知,CloudStack有4种逻辑网络流量,根据不同的需求,我们可以将这4种逻辑网络流量在物理节点的多块网卡上进行组合。在本书中,我们规划为:一块网卡只用于公共网络的通信,类似于传统网络的“外网”;另一块网卡用于管理网络、来宾网络、存储网络的通信,类似于传统网络的“内网”。这种设计方式用户比较容易接受,但从性能方面考虑,并不是很好的设计。本书只是提供一种设计方式以帮助读者理解,本书所有的架构规划和配置操作也都是基于此的。虽然CloudStack设计的4种逻辑网络流量可以任意组合,本书也鼓励读者根据实际需求进行配置,但如果对CloudStack的架构理解得不是很清晰,建议还是先遵照本节的设计进行 实践。

那么,如何让CloudStack系统接受我们的设计,使不同的逻辑网络流量从不同的物理网卡通过呢?首先将KVM的网桥名称、XenServer的网络标签名称进行重命名,然后在添加区域、配置不同网络的流量的时候,填入我们希望这个网络流量通过的网桥或虚拟交换机的名称即可。不同网络的命名如表4.5所示。另外需要注意的是,重命名的名称中不要带有空格,填写的时候要注意大小写,否则CloudStack会无法识别,导致系统新建虚拟机的时候因为找不到物理网络而报错。表4.5 不同网络的命名

高级网络区域内所有节点的IP地址和操作系统信息如表4.6所示。表4.6 高级网络区域内所有节点的IP地址和操作系统信息

高级网络区域所使用的NFS存储路径信息如表4.7所示。表4.7 高级网络区域所使用的NFS存储路径信息

高级网络区域内所有节点的硬件配置建议如表4.8所示。表4.8 高级网络区域内所有节点的硬件配置建议

为了统一,本书将所有密码都设置为“cspassword”(包括所有节点的root用户,MySQL数据库中的root和cloud用户,以及vCenter所在的Windows操作系统中得administrator用户)。在真实环境中,出于对安全性的考虑,一定要将密码设为复杂的强密码。

由于很多读者的实验环境中硬件资源不足,常会考虑是否可以把整套CloudStack环境都架设在虚拟机中,也就是说,是否可以在一台高配置的物理机上完成整套环境的搭建。基于二层虚拟化技术的实现,所以在表4.7中也提到,进行测试的所有节点均可使用虚拟机,但最低配置不变。也正是因为二层虚拟化架构,如果在测试中出现问题,会使排查故障的步骤更为复杂,不利于帮助读者理解CloudStack的网络架构,再加上性能上的大量损耗,所以建议读者在学习CloudStack的早期,尽可能使用物理节点搭建整套环境。

4.1.3 交换机的规划与配置

在完整的CloudStack基础设施管理平台的环境规划和搭建过程中,网络的规划最为重要。一方面,CloudStack的网络功能,尤其是高级网络的功能,依赖网络的规划和配置才能实现;另一方面,根据不同生产系统的需求,网络架构也是千变万化的。所以,我们先通过4.1.1节和4.1.2节进行入门学习,当对这两个规划有了一定的了解后,再根据网络知识和实际需求对CloudStack系统的网络进行变化和扩展。但是,仅将以上规划的这些参数填入CloudStack系统是不够的,还需要二层交换机和三层路由器的支持。CloudStack社区提供的开源版本不能控制交换机和路由器等硬件设备,所以我们需要对交换机进行手动配置。

我们来详细地规划一下交换机的配置。● 对于基本网络架构,因为不需要进行VLAN隔离,所有的物理机

和虚拟机都在一个扁平的IP网段中,所以无须对交换机设备进行

特殊配置。● 对于高级网络架构,需要通过VLAN进行数据流量的隔离,但不

同的网络流量设置又是不同的,具体如下。 公共网络:通过一个VLAN ID进行隔离。 管理网络:由于不能设置VLAN ID,故需要为通过这个网口的网

络流量设置Native VLAN。 存储网络:在本规划中没有涉及,与管理网络合并。 来宾网络:设置了一组VLAN ID,由CloudStack自动给每个用户

分配一个用于隔离用户间数据的VLAN。用户的虚拟机会随机运

行在物理机上,CloudStack会在每个计算节点上建立针对每个用

户的独立网络并为其分配VLAN ID,这样就可以保证用户的数据

从计算节点的网口传送出去的时候是带有VLAN ID的。而我们也

不能完全控制一个网口只允许带有某一个VLAN ID的数据通过,

所以要将来宾网络流量通过的网口设置为允许通过所有来宾网络

的VLAN ID。

我们回头看一下高级网络的规划(如图4.2所示)。● 管理节点有2个网口,一个用于公共网络的通信,一个用于管理

网络的通信。● 计算节点有2个网口,一个用于公共网络的通信,一个用于管理

网络和来宾网络的通信。● vSphere群集需要的vCenter和NFS存储服务器,各有1个网口用

于管理网络通信。

这样统计下来,交换机上需要提供7个网口来保证公共网络的通信,2个网口来保证管理网络的通信,6个网口来保证管理网络和来宾网络的混合通信。可以得出,整套CloudStack高级网络环境会占用15个交换机网口,使用一个24口交换机即可满足需求。交换机的网口配置方式如表4.9所示。表4.9 交换机的网口配置

有了表4.9,就有了配置交换机的思想。不同品牌的交换机配置方法不同,在此就不再一一详细说明具体操作步骤了。如果读者需要设备的配置操作说明,建议查看设备厂商的相关文档或通过厂商的技术支持帮助解决。

4.1.4 安装时需要的其他信息

本书使用的CloudStack的版本为CloudStack 4.0.2 NonOSS,这是支持vSphere群集的版本。从CloudStack社区下载该安装包的地址为http://CloudStack.apt-get.eu/rhel/4.0/。

CloudStack社区提供的安装包是完全开源的版本,其中没有支持vSphere群集的代码(因为支持vSphere的代码不是开源的)。所以,我们需要在完成第6章的学习后,在源代码中加入支持vSphere的代码,编译属于自己的CloudStack安装包。

以上的方法略显复杂,对于新手来说有一定难度,所以本书已经编译好一个可以支持vSphere群集的安装包供读者下载使用,地址为http://pan.baidu.com/share/link?shareid=431835&uk=1261729203。支持不同虚拟机管理程序的系统虚拟机模板的下载地址为http://pan.baidu.com/s/1lASth。

由于读者实践时所处的网络条件不一,所以建议读者先下载CloudStack程序的安装包及系统虚拟机模板,以节约时间。

4.2 CloudStack管理节点的安装

4.1节介绍了CloudStack的安装环境架构。可以看到,CloudStack主要由管理节点、计算节点、主存储和二级存储等部分组成。作为CloudStack的“大脑”,管理节点起到了非常重要的作用。CloudStack程序可以安装在CentOS或RHEL 6.3以上的版本及Ubuntu 12.04版本的操作系统内,本节会分别介绍将CloudStack管理程序安装在CentOS 6.3和Ubuntu 12.04操作系统中的具体步骤。

根据4.1节的规划,管理节点的配置信息如表4.10所示。表4.10 管理节点的配置信息

4.2.1 CentOS下管理节点的安装方法

CentOS下管理节点的安装方法如下。1.安装和配置管理节点

安装和配置管理节点的步骤如下。(1)配置系统IP地址

首先,全新安装一台物理节点或虚拟机作为CloudStack的管理节点,操作系统使用CentOS 6.3 x64,其他注意事项如下。● 根据系统环境规划,在安装操作系统的过程中手动配置IP地址。 如果配置高级网络环境的管理节点,将IP地址设置为192.168.1.1。 如果配置基本网络环境的管理节点,将IP地址设置为192.168.0.1。● 设置root的登录密码为“cspassword”。● 在选择要安装的软件组时,选择默认的“Basic Server”类型即

可,如图4.3所示。图4.3 安装CentOS操作系统时选择“Basic Server”类型(2)配置主机名

①当操作系统安装完成并重启后,先以root用户登录系统并检查主机名。如果在系统安装过程中没有特别指定主机名的话,会显示如下内容。

建议读者在配置自己的CloudStack环境时,规范所有主机的命名,从而在使用时便于识别和管理。

②使用“vi”命令编辑“/etc/hosts”文件,在最后一行添加一条记录,指定本机IP地址所对应的主机名。● 如果配置高级网络环境的管理节点,应添加“192.168.1.1 A-

MS.china.cs”。● 如果配置基本网络环境的管理节点,应添加“192.168.0.1 B-

MS.china.cs”。

保存修改,退出文件编辑状态。

③修改当前主机名。● 如果配置基本网络环境的管理节点,应执行命令“[root@localhost ~]# hostname B-MS.china.cs”。● 如果配置高级网络环境的管理节点,应执行命令“[root@localhost ~]# hostname A-MS.china.cs”。

④使用“vi”命令编辑“/etc/sysconfig/network”文件,修改“HOSTNAME=localhost”行的内容。● 如果配置基本网络环境的管理节点,应添加“HOSTNAME=B-

MS.china.cs”。● 如果配置高级网络环境的管理节点,应添加“HOSTNAME=A-

MS.china.cs”。

保存修改,退出文件编辑状态。

⑤重新使用root用户登录,使用“hostname -fqdn”命令验证此时hostname的配置。当显示“B-MS.china.cs”或“A-MS.china.cs”时,说明主机名的配置正确。按照以上步骤配置,才能保证重新登录或者重启服务器时主机名保持现有配置。

⑥如果使用“hostname -fqdn”命令进行验证,将得到如下错误提示。

这时需要仔细核对之前的几个步骤,包括修改的主机名称是否完全相同、是否有拼写错误等。(3)关闭SELinux安全组件

在安装过程中,我们首先要关闭CentOS操作系统中的SELinux。SELinux是强制访问控制(MAC)系统的实现,其本身是一个功能强大的安全模块。由于基于SELinux的访问控制烦冗复杂,所以官方文档建议在测试环境中将其关闭,以免造成未知错误。对此感兴趣的读者可以访问维基百科进行学习,地址为http://en.wikipedia.org/wiki/Selinux。

①如果没有特殊配置,在默认安装的CentOS操作系统中,SELinux服务是打开的,可以使用如下命令进行检查。

当“Current mode”这一行显示为“enforcing”时,说明程序处于启用状态。

②使用“vi”命令编辑“/etc/selinux/config”文件,示例如下。

将“SELINUX=enforcing”这一行中的“enforcing”改为“permissive”,然后保存修改并退出文件编辑状态。一般情况下,用户需要重启主机才可以使此修改生效,但我们也可以通过执行命令“[root@B-MS ~]#setenforce permissive”使其即时生效。

如果只执行以上命令,在主机重启后,SELinux的状态仍会回到“enforcing”,因此要将以上两步都做完才能保证完全修改。

③检查SELinux现在的状态,示例如下。

可以看到,“Current mode”这一行显示为“permissive”,说明SELinux已经不会影响接下来的配置和使用了。(4)配置Yum源

在管理节点上安装所有的程序时,都要使用Yum工具进行操作。我们知道,在CentOS操作系统中安装程序,实际上是安装RPM包,但安装一个RPM包时有可能依赖很多其他的RPM包才可以正确安装。而Yum是一个基于RPM包的字符前端软件包管理器,能够从指定的RPM源自动下载RPM包并安装,可以处理依赖性关系,且能够一次安装所有依赖的软件包,无须烦琐地一次次下载、安装。所以,我们首先来配置Yum源。

Yum源有两种获取方法:一种是直接通过Internet获取并安装RPM包;另一种是指定本地或内网的源进行安装。考虑到测试环境中网速可能较慢或者根本不能连接Internet,本书主要介绍如何配置本地RPM包的源。另外,我们需要配置两个源:一个是CloudStack安装包的源;另一个是操作系统自带的所有RPM包的源。在安装新程序及CloudStack的时候会用到这两个源。

①挂载操作系统安装光盘或ISO文件。其实,操作系统安装光盘内就带有所有的RPM包,只是我们在安装过程中只选择了一些默认程序进行安装,所以,只要将CentOS 6.3系统安装光盘或者ISO文件挂载到系统中就可以使用了。在本例中,我们只需使用CentOS 6.3系统安装光盘的DVD1即可将RPM包挂载至系统的“/media”目录。● 如果使用安装光盘,可将光盘插入管理节点的光驱,然后执行命

令“[root@B-MS ~]# mount -t/dev/cdrom/media”。需要注意的是,

如果管理节点安装在虚拟机上,那么光驱的设备文件名可能就不

是“/dev/cdrom”了,这与虚拟机管理程序有关,例如

XenServer虚拟机的光驱设备文件名为“/dev/xvda”。● 如果使用ISO文件,可将ISO文件上传至管理节点的“/opt”目录

中,然后执行命令“[root@B-MS ~]# mount -o loop /opt/

CentOS-6.3-x86_64-bin-DVD1.iso/media”。

挂载成功后验证目录内容,示例如下。

试读结束[说明:试读内容隐藏了图片]

下载完整电子书


相关推荐

最新文章


© 2020 txtepub下载