OpenStack开源云王者归来——云计算、虚拟化、Nova、Swift、Quantum与Hadoop(txt+pdf+epub+mobi电子书下载)


发布时间:2020-08-27 08:43:36

点击下载

作者:戢友

出版社:清华大学出版社

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

OpenStack开源云王者归来——云计算、虚拟化、Nova、Swift、Quantum与Hadoop

OpenStack开源云王者归来——云计算、虚拟化、Nova、Swift、Quantum与Hadoop试读:

前言

为什么要写这本书

云计算已经从概念走向现实,从讨论走向实践。各种各样的云计算平台也层出不穷,基于云计算的应用也不断推出。相对于天价的商业云计算软件,众多的云计算爱好者和公司开始考虑一种易用的开源云计算软件。开源云OpenStack正是在这样的环境下诞生的。在OpenStack诞生之前也有很多的开源云软件,但是OpenStack却成为了当下最热门的开源云平台。这主要得益于OpenStack的优秀特性:灵活的结构、巧妙的模块化设计及极强的扩展性能。但是,OpenStack的入门却有着不低的门槛。除了技术本身的障碍之外,眼花缭乱的安装部署方式、尚待完善的官方文档、良莠不齐的技术博客、炒作概念的各种讨论会等,让希望了解开源云OpenStack的人望而却步。此外,OpenStack版本升级较快,模块变化较大,也给很多研究人员带了很重的学习负担。本书以实践为宗旨,由浅入深,从入门到精通,一点一滴地介绍了OpenStack的核心技术。

本书以OpenStack Grizzly版本为基础,详细介绍了OpenStack的几个方面:云计算技术的基础、集群搭建、组件剖析及扩展开发。阅读完本书后,读者能够掌握OpenStack实现的技术细节与设计思想,并且将这些技术灵活地运用在云计算的开发中。理解了OpenStack的精髓,无论OpenStack更新到何种版本,学习起来都会游刃有余。

本书有何特色

1.讲解了云计算入门所需的虚拟化技术

为了将读者带入云计算的领域,虚拟化技术是一个绕不开的坎。作者专门介绍了OpenStack用到的虚拟化技术,并编写了大量的实例、程序及脚本供读者参考。

2.涵盖OpenStack大部分组件

本书涵盖了MySQL、RabbitMQ、Keystone、Swift、Glance、Cinder、Quantum、Nova和Dashboard重要组件的安装。每一种组件的安装都单独成一个模块,并且介绍了这些组件之间安装部署的相互依赖关系。此外,还提供了多种多样的参考部署方式。通过安装篇提供安装脚本,读者只需要简单地配置,便可以快速地部署相应的服务。此外,本书对OpenStack用到的关键技术和重要组件都有源代码剖析。

3.案例经典,注重实践

为了讲解OpenStack的各种技术细节,书中编写了大量的程序和脚本。为了讲解云计算设计思想与实现细节,本书的每一章都设计了经典案例、脚本及代码实现。

4.循序渐进,由浅入深

本书从云计算最基本的虚拟化技术入手,由虚拟机、虚拟资源的管理引出开源云OpenStack的实现,由浅入深,层层解开了开源云OpenStack的关键技术与重要组件。

5.提供完善的技术支持

本书所有的程序、脚本和文件资源均可以在https://github.com/JiYou/openstack上下载,并且会提供后续的更新与支持,让作者与读者可以面对面直接交流。

本书内容及知识体系

第1篇 基础篇

(第1~2章)

本篇介绍了云计算的基本概念及开源云OpenStack的基本知识。主要包括云计算概念的产生与优势、开源云OpenStack的框架与特点、KVM和Libvirt虚拟化技术的使用。

第2篇 安装篇(第3~10章)

本篇介绍了OpenStack系统的安装与集成,包含了OpenStack所需组件的安装部署,涵盖MySQL、RabbitMQ、Keystone、Swift、Glance、Cinder、Quantum、Nova及Dashboard。每个组件的安装部署都单独成章,并且给出了OpenStack集群部署的几种常用参考架构。讲解安装的同时,也介绍了OpenStack各个组件之间的相互依赖关系。

第3篇 剖析篇(第11~16章)

本篇主要介绍了OpenStack重要组件所利用的关键技术。剖析的组件包括Keystone、Swift、Quantum和Nova。此外,还重点介绍了Nova Compute虚拟机管理服务。介绍的OpenStack关键技术包括OpenStack RESTful API的实现、RPC消息通信服务和Swift存储系统设计。介绍这些关键技术时,由浅入深地提供了大量的参考代码与实现细节,逐步剥开了OpenStack关键技术细节的面纱。

第4篇 扩展篇(第17~19章)

本篇介绍了如何利用OpenStack做二次开发。涵盖的内容有:如何在OpenStack上搭建Hadoop大数据分析系统;Nova扩展开发;添加自定义组件。添加自定义组件时,介绍了如何从基础代码构建一个兼容OpenStack的独立模块。详细介绍了数据库的设计与实现、API接口的添加、模块之间RPC调用。还介绍了将OpenStack的关键技术运用在一个独立开发的模块中。

如何获得本书资源

为了方便读者阅读本书,笔者将本书所涉及的所有代码上传于https://github.com/JiYou/openstack。包括的内容如下:

● 本书引用的OpenStack Grizzly版本的源代码、image资源、脚本和python包;

● 剖析OpenStack关键技术细节时所编写的示例;

● 添加自定义组件时,创建的兼容于OpenStack的组件Monitor的整个项目源码和安装脚本;

● 后续勘误与安装脚本的更新。

适合阅读本书的读者

● 需要入门并且全面学习云计算的人员;

● 希望使用OpenStack开源云的研究人员;

● 需要了解云计算实现技术细节和内部运作机制的程序员;

● 需要利用OpenStack做快速二次开的程序员;

● 开源云OpenStack数据中心的管理员;

● 对云计算感兴趣的公司或个人。

阅读本书的建议

● 云计算初学者,请务必从一章开始阅读,并且熟练掌握第2章虚拟化技术。熟练的虚拟机管理操作,会给后续的研究与OpenStack系统安装带来极大的方便。此外,还需要基本的Python知识,以及熟练掌握Linux系统,特别是Ubuntu-12.10 Service Edition的使用。

● 云计算入门者,有一定云计算概念,并且知道如何操作KVM/Libvirt的读者,可以直接阅读安装篇,了解安装OpenStack各个组件的基本流程。

● 阅读本书时,请务必对照https://github.com/JiYou/openstack/tree/master/packages/source上提供的OpenStack的代码,以保持OpenStack版本一致。此外,操作系统最好选用Ubuntu-12.10,因为本书所提供的安装脚本和安装包均基于Ubuntu-12.10。

● 注意关键技术。由于OpenStack系统过于庞大,本书也只是挑选了OpenStack重要组件中的关键技术细节进行介绍。理解了这些关键技术细节,读通整个OpenStack项目的代码便绝非难事。

● 一切密秘尽在OpenStack的源码中,正所谓“师傅领进门,修行靠自身”。本书的目的在于将欲入门而不得其要领的人带入OpenStack开发的大门。就如同告诉“挖宝人”宝藏的所在地和挖掘方法一样,本书将读者带入门后,真正的挖掘还需要读者多看源码,多动手实践。

勘误和支持

由于笔者水平所限,加之本书的篇幅和编写时间的限制,使得本书写作比较仓促。因此书中可能会出现一些疏漏或者不准确的表述,恳请读者批评与指正。本书后续更新与勘误将会发布在https://github.com/JiYou/openstack相应的章节中。如果读者在阅读本时有疑问,或者对本书有什么宝贵的意见与建议,欢迎将邮件发送至jumail@qq.com或bookservice2008@163.com。

本书作者

本书由英特尔亚太研发中心的戢友主笔编写。其他参与编写的人员有梁胜斌、林阳、林珍珍、刘爱军、刘海峰、罗明英、马奎林、乔建军、施迎、石小勇、宋晓薇、苏亚光、谭东平、王守信、王向军、王晓东、王晓倩、王晓艳、魏来科、吴俊、闫芳、杨丹、杨艳、宜亮、余柏山、张春杰、张春晓、张娜、赵东、钟晓鸣、朱翠红、朱萍玉、龚力、黄茂发、邢岩、符滔滔。

致谢

感谢提供了大量帮助的贺丹,他为本书提供了大篇幅的修改意见。在介绍OpenStack关键技术时,他设计并参与了大量经典案例的编写与检测。本书素材的选取、内容章节的编排、OpenStack重要组件的剖析,他都给予了非常多而且极具参考价值的建议与意见。

感谢这本书的编辑们,正是由于他们积极而又耐心的帮助,才使得本书的出版成为可能。

感谢为本书部分章节提出修改意见的刘丹,他对本书安装篇的内容和脚本更正了不少错误。

感谢我的父母!他们对我的写书工作表示了极大的理解和支持,并给了我无处不在的关怀与照顾。

感谢我亲爱的老婆杨丹凤!她对于我写书给了极大的鼓励与支持。

此外,感谢在Intel IT Flex部门一起工作的各位Manager和同事们!

谨以此书献给我最亲爱的家人及众多热爱开源云OpenStack的朋友们!

最后希望各位读者通过阅读本书,能很好地掌握OpenStack开源云技术,成为这个领域中的“王者”。我将倍感欣慰!所学授之于人,不亦乐乎?最后祝读书快乐!戢友于上海第1篇基础篇第1章OpenStack概述

云计算从提出到成熟,中间经历了较长的时间。云计算的各种概念也在不断发展更新。了解各种概念,学习各种理论,只是纸上谈兵。中国南宋的陆游曾经说过:“纸上得来终觉浅,绝知此事要躬行。”在了解这些概念的同时,初学者都希望有一个初具规模的云计算系统可供学习、试验和使用。幸运的是,OpenStack正是这样一个开源的云计算系统,可供学习及使用。在开始动手搭建OpenStack之前,本章首先介绍一些云计算的基本常识,然后对OpenStack的框架做一个概述性的介绍。

本章主要涉及到的知识点如下。

● 云计算:了解云计算,可以知道云计算产生的原因,以及应用场景。

● 云存储:了解云存储,可以知道云计算系统中大数据的存储方式。

● 私有云和公有云:云计算两种不同的应用场景,本章将会介绍两者的联系与区别。

● OpenStack架构:了解OpenStack框架,并且明白OpenStack内部各个部件的作用。1.1 云计算简介

本节介绍云计算技术产生的原因,以及发展过程,并且介绍如何利用云计算解决问题。

云计算从功能上可以分为两类:云计算,主要是提供虚拟主机服务;云存储,主要是提供海量数据存储服务。

云计算从应用场景上可以分为两种:公有云,面向社会个人或企业提供云服务;私有云,面向企业内部部门或员工提供云服务。1.1.1 什么是云计算

每天打开电视、拧开水龙头,有没有想过这些资源使用起来为什么这么方便?不需要亲自去建一个发电站、自来水厂,电和水想用就用,不用的时候就关掉了,也不会出现浪费。这些资源都是按需收费的,用多少,付多少的费用。这些资源的产生、输送和维护都有专门的工作人员来操作,使用者并不需要过多地担心,真是太方便了!

如果把计算机、网络、磁盘存储这种IT基础设施与水电等资源做比较的话,IT基础设施还远未达到像水电资源那样的高效利用。就当下而言,无论是个人还是企业,都是自己准备这些IT基础设施,空置率相当高,并没有得到有效地利用。产生这种情况的主要原因是由于IT基础设施在流通性上并不如水电那样便利。

科技在飞速发展,网络带宽、硬件计算能力都在不断提升。这些硬件技术的发展,为IT基础设施的流通创造了关键的条件。那么当IT基础设施具备流通性的时候,就有企业开始考虑转向IT基础设施提供商的角色。其实发电站与自来水厂的产生,也是需要解决流通性这个关键的问题(铺设管道与线路成为可能)。任何商品的产生,也是首先要解决流通的问题。如果物品不能流通,进而无法交换,那么也就具备不了商品价值。

首先设想一下,有那么一个IT基础设施提供商,愿意提供个人和企业所需要的IT基础设施(按需收费与使用)。这些IT基础设施,如CPU、存储、硬件维护、硬件更新都有人来维护,不需要个人和企业参与。这是多么方便的一件事情!如果IT基础设施能够像水电一样流通、按需收费,便是狭义上的云计算。如果把IT资源从基础设施扩展至软件服务、网络应用、数据存储,就引申出了广义的云计算。这也就意味着IT资源能够通过网络交付及使用了。

由于云计算期望达到的目标是与水电资源的交付一样,因此云计算具备的特征(虚拟化除外),水电都具备。表1.1中罗列了云计算与水电特征的比较。表1.1 云计算与水电资源特征比较

云计算技术上的实现,需要虚拟化、并行计算、效用计算、网络存储和负载均衡等旧有的技术。虽然云计算是旧有技术的整合,却能够带来生活、生产方式以及商业模式的变化,因此云计算的实现总是引人瞩目。1.1.2 什么是云存储

云计算将IT资源变得像水电资源一样易于管理与流通。但是云计算系统却面临另外一个大问题:存储。这好比,自来水厂需要大容量的存储设备来处理从水源抽取的水(保存起来以供净化)。云计算系统除了修建数据中心存放物理设备之外,还需要存储大规模的数据。这些数据来源有多种可能:用户数据、系统运行所需数据以及互联网数据(比如搜索引擎抓取的数据)。

采用何种方式存储与管理这些大规模的数据,就成了云计算系统需要考虑的问题。因此,云计算系统中需要实现一个以存储为目标的子系统,即云存储系统。

云存储的概念应该是被云计算所包含,平时所提及的云计算包含了云存储。之所以云存储需要单独提出来,则是因为云存储在整个云计算系统中,是一个比较完整的子系统。与云计算的其他模块相比,比较独立。甚至云存储可以从云计算系统中脱离出来,只是单纯地面向用户提供存储服务(如Dropbox、微盘、网盘等等)。由于云存储的特殊性,云存储经常被单独讨论。

那么云存储要实现怎么样的目标呢?由于云的真正含义是将IT资源变得像水电一样流通使用。那么云存储的目标就是将存储资源变得像水电一样方便人们使用。

云存储在设计的时候,为了达成这样的目标,将云存储系统分为4层。(1)硬件层:硬件层是云存储最底层、最基础的部分。硬件层包括了网络光纤、iSCSI设备、SSD硬盘或者其他多种多样的存储设备。有时候,这些设备并不集中于某一地,而是通过网络联接在一起。(2)管理层:管理层是最核心的部分。管理层主要是通过分布式文件系统、网络通信来实现,进而保证硬件设备协同工作。管理层保证了系统的可靠性、持久性和稳定性,进而向用户提供有效的存储服务。(3)API层:只是有了管理层还远远不够,还需要提供网络访问的API。有了这些API,就可以为各式各样的应用提供服务,比如视频点播、网盘和Dropbox等等。(4)客户端:一个完整的云存储系统还需要有方便易用的客户端。简洁的UI和人性化的设计都是客户端应该考虑的重点。1.1.3 私有云与公有云

什么是私有云?什么又是公有云?两者有什么区别?

打个比方,小李开了个大公司,在生产的时候,不能停水,并且要保证水质纯净。如果过度依赖自来水厂,那么有两种情况可能发生:输水管道破裂,断水;水源出现污染。当出现这两种情况的时候,大公司由于产品不达标,就会巨额亏损。这个时候怎么办呢?小李就想干脆在公司内部成立一个供水部门,买来净化水的设备,直接向生产部门供应水。在运作时,供水部门需要检查供水管道,并且保证水质。

与此类似,很多公司在使用云计算系统的时候,出于安全、性能和保密等原则,自己设计了云计算系统以供本公司使用。这样的云计算系统就是私有云(相当于小李自己成立的供水部门)。

公有云的地位则相当于面向公共供水的自来水厂。公有云并不特定地面向某个公司,或者某个个人提供服务,而是面向需要云计算资源的所有企业和个人提供服务。简而言之,面向公众的云计算称之为公有云。

公有云与私有云的差别主要体现在应用场景上。两种云计算系统核心实现甚至可以完全相同。但是,两个很关键的因素却导致了公有云的发展并没有跟上私有云的步伐。如果把私有云比作老婆管钱的话,那么公有云就是银行管钱。实际上银行管钱比老婆管钱要晚很多很多年。那么是什么原因导致这种情况呢?主要是以下两个原因。(1)安全性:个人,尤其是企业非常关心数据的安全性。一旦出现数据泄漏,企业的核心数据外泄,那么导致的后果很有可能会严重影响企业的发展。相对而言,私有云的安全性,则由于访问控制等原因,可以得到一定的保证。同样的道理,在遥远的古代,银行尚未成型的时候,老婆管钱可能比地下钱庄管钱安全得多。(2)服务可靠性:公有云为了节省资源,在超负荷运行、出现宕机的时候,容易对企业造成影响。比如某视频网站在直播春晚的时候,发现申请的公有云资源宕机了,直播就只能暂停。同样的道理,在遥远的古代(黄金白银还是硬通货的时候),急用钱时只需要向老婆申请就可以了,地下钱庄则并不能保证急用时能把钱给预支出来。

在公有云开成型的今天,主要是有上面两大因素制约着公有云的发展。而私有云则还处于发展阶段。但是两者的核心实现,对程序员而言,差异并不大。对于初学者而言,只需要关心云计算的核心实现。当具备一定基础与实力之后,可以在公有云或者企业私有云上大展拳脚。1.2 为什么使用云计算

上一节中,从理论上介绍了云计算的作用:将IT资源变得像水电一样可流通。但是为什么使用云计算?云计算对于互联网的设计会带来怎么样的变化?云计算产生的背景又是什么呢?

考虑这样一个简单的问题。设计一个网站来提供http、MySQL和ftp这3个服务。http提供动态页面显示, MySQL提供后台数据记录与查询服务,ftp提供简单的文件上传与共享服务。1.2.1 方案1:简单的服务部署1.部署方式

对于有经验的互联网的开发人员而言,很快就有了图1.1所示的模型。图1.1 http、ftp和MySQL服务都部署到一台主机中

在这个模型中,所有的服务都在一台主机里。很多开发人员在开发时候,都会采用这种部署方式,优点是开发、调试都很简单。2.存在的问题(1)安全

所有的服务都是放在一台机器上,当出现安全问题的时候,所有的服务都受到了威胁。整个网站都暴露了,没有任何隐秘信息可言。(2)可靠性

采用这种方式,可靠性太低了。当物理服务器一出现问题,所有的服务都不可用了。整个系统的可靠性相当差。(3)扩展难度

当访问量以及数据量开始上升之后,方案1又会遇到扩展的制约。一种简单的办法是,换一台更强劲的服务器(旧的机器就被闲置浪费了)。但是市场上的最好的服务器,它的性能以及所能支撑的数据访问量也是有限的。(4)维护成本

维护时,服务软件本身的故障较易处理,毕竟只需要把精力集中于一台机器上。但是,当造成故障的原因是操作系统、硬件时,维护就变得较为困难,因为所有的服务都受到了严重的干扰。3.生活实例

这种部署方式,好比小李想开一个饭店。小李征求到的方案1:会计、厨师、采购员都小李一个人做。这种简单的做法,会有哪方面的隐患呢?

安全性而言,当采购员小李钱包被偷了,没买到菜。小李也没法做菜,于是收入也没有了。一个小问题,就直接导致小李的饭店停业一天。

可靠性而言,比如小李生病了,那么会直接导致饭店关门歇业。

扩展性而言,由于所有的业务都需要一个人来做,需要找到一个与小李一样精通会计、厨师、采购的人还真不容易。

维护而言,就小李一个人,看似简单。不过有一天,小李手受伤了,缠着绷带要休息几天,饭店又关门歇业了。

有这么多缺陷的一个方案,很快被小李否决了。1.2.2 方案2:分布式服务部署1.部署方式

在投资界,有一句至理名言,“不要把鸡蛋都放在一个篮子里”。说的是投资需要分散风险,以免因孤注一掷的失败造成巨大的损失。在服务器架设方面,一般也需要满足这个原则。方案1由于把所有的服务都放到一个服务器上,带来的风险是巨大的。当这个服务器一出现问题,所有的服务都瘫痪了。

针对这个问题,很自然地会想到分布式系统的处理方法,也就是方案2。既然架设在一台服务器上是危险的,那么把这3个服务分散至3台不同的物理服务器上,提出图1.2所示模型。图1.2 分布式架构模型

采用分布式模型,会带来很多优点。(1)安全

由于服务都分散至了3台机器,3个服务之间是相互隔离的,并且每台机器可以针对性地设置防火墙。当一台机器被攻击的时候,别的服务可以不受影响,不会出现所有服务都崩溃的情况。因此,可以说,在安全性方面,相比简单模型方案1而言,分布式的方案2已经有了明显的改观。(2)可靠性

每个服务不同的可靠性问题,在分布式架构下都可以得到解决。比如http需要的高可用服务,只需要额外添加一台备用服务器,当http服务器出现问题的时候,就使用备用服务器。MySQL服务可以采用高可用集群的部署方式。ftp文件存储服务,可以替换为分布式存储服务,或者直接采用云存储作为存储服务。2.存在的问题

采用分布式架构之后,可以解决安全、可靠性、扩张等等问题。但是,扩展、部署和维护都会直接面对大量的物理服务器,其难度也相应增加。(1)扩展难度

当用户增加,访问量开始上升的时候,对系统管理员、维护人员来说,又要进行采购设备、配置硬件、安装系统、配置软件等一系列重复而又繁琐的工作。

此外,还存在潜在的浪费。比如对于持续高访问量的网站而言,只需要连续不断地增加服务器,可称之为添油战术。但是有的网站的访问量,在特定的时期会出现暴发式增长。采用添油战术的情况下,平时的低访问量,将造成大量的服务器闲置和浪费。(2)部署难度

部署这么一套分布式系统,实在是比较麻烦的事情。可以想象的是,开发人员的开发环境、测试环境和生产环境都需要不断地重复验证。在此期间,需要经历多少次反复。交付客户之后,还需要保证客户能够维护这样一套复杂的系统。(3)维护难度

在分布式系统中,当发现某台物理服务器出现故障的时候,补救措施一种是在原机器上进行修复;一种是找一台新的物理服务器,重新安装操作系统和服务软件。在此期间,需要经历漫长的修复过程。3.生活实例

如果觉得以上这些理论不容易理解,那么还是回到小李开饭店这个生动而又形象的例子上吧。小李征求的方案2:会计、厨师、采购分别由不同的人来担当。

扩展而言,就是当某个职位上人手比较少的时候,需要找新人进行相应职能的培训。比如缺少采购,需要招新人进行采购的培训。每次招人的时候,还需要考虑到人员过剩的情况。

部署而言,就是需要找齐相应的人,并且进行相应的培训。还要保证这些人员之间可以进行较好的合作。方案2的实施由于涉及到很多人,小李部署这套方案也有很大压力。

维护而言,就是当某个人身体出现问题的时候,小李有两种方案:一种是等待这个员工恢复健康;一种是另外找人,并进行培训。这两种方案都会浪费不少时间。

尽管方案2存在一系列问题,不过已经基本能够满足开一个小饭店的需要了,小李有点犹豫了。1.2.3 方案3:基于虚拟化的服务部署1.部署方式

在使用分布式方案部署的过程中,会遇到一系列难以解决的问题。一种有趣的想法是,能不能把这些服务部署到虚拟机上。通过虚拟机管理软件(Hypervisor)来进行管理。粗略一看,部署到虚拟机上,与部署到物理机上,没什么差别,并且还需要考虑性能损失的问题(虚拟机与同样配置的物理机,性能方面会有一定的损失)。

设计一个系统的时候,需要考虑的因素很多。比如在这个系统中,要考虑的因素就有:性能、安全、可靠性、扩展难度、部署难度和可维护性等。需要综合这些所有的因素来设计这样一个系统。值得考虑的是,如果把服务部署到虚拟机中,带来的便利性是否胜过性能上的损失,以及性能上的损失是否是在可接受的范围内。

在这种思路下,可以提出方案3:利用虚拟机架构的系统,见图1.3。图1.3 基于虚拟机方案的架构

图1.3中,KVM(Kernel Based Virtual Machine)表示运行于Linux平台上的虚拟机管理软件。在KVM上面,运行着3台虚拟机,分别运行着http、ftp和MySQL 3个服务。采用这种方式,与分布式的架构相比,有以下这些优点。(1)安全

采用虚拟机的架构,除了保证物理服务器的安全之外,还需要保证虚拟机的安全。物理机与虚拟机,以及虚拟机与虚拟机之间,可以通过设置不同的网络、防火墙策略进行隔离,避免相互感染。(2)可靠性

采用虚拟机架构的情况下,可靠性与分布式方案略有不同。分布式方案中需要添加物理机,在此方案中,只需要添加虚拟机。(3)扩展

扩展的时候,首先是在资源空闲的物理机上建立虚拟机。当且仅当物理机资源不够时,才需要添加物理机资源。创建虚拟机的方式是将现有资源充分利用(当访问量低的时候,甚至可以把虚拟机集中于某些服务器,把空闲的关机以节省资源)。(4)部署

虚拟机的部署远比物理机的部署方便。添加一个新的虚拟机,最简单的办法是复制一个虚拟机磁盘模板。维护人员只需要通过Hypervisor便可以部署虚拟机(可以免掉那些重复的操作系统安装、软件配置过程)。(5)维护

把服务架设于虚拟机上面后,物理服务器的维护可以交给少量专业的机房管理员。整个系统的管理员可以专注于虚拟机的管理。

由此,可以看出,基于虚拟机的架构主要是把系统部署在虚拟机上。那么整个系统并不直接依赖于底层物理服务器,而是直接依赖于虚拟机。因此,整个系统可以分为如图1.4中的3个层次。

从图1.4可以看出,系统依赖于虚拟机,虚拟机依赖于底层硬件。整个系统分为了3层,每层都有相应的管理人员或工具进行管理与维护,职能更加专一。网站管理员可以从繁琐的物理服务器管理中解脱出来,把精力放在网站功能及虚拟机管理上。图1.4 基于虚拟机架构分层示意图2.存在的问题

方案3已经能够解决很多问题了。但是现在仍然面临一个问题:当规模上去之后,怎么办?采用方案3,小规模部署方式如图1.5所示。图1.5 虚拟机架构小规模示意图

图1.5显示了小规模部署的情况,只有4台服务器,一两台虚拟机。如果采用人工管理的方式,可以轻松搞定。但是,由于Hypervisor只能管理到某一台物理机上的虚拟机,当物理机与虚拟机数量上升之后,直接基于Hypervisor的管理方式就不太适合了。大型互联网应用往往有上千万台虚拟机,采用人工管理的方式就不适用了。此外,除了负责虚拟机创建之外,还需要处理虚拟机的网络、磁盘、内存等等的管理,人工来处理这些事务极繁琐且易出错。3.生活实例

小李征求意见时,看到了方案3:会计、厨师、采购人员依然由不同的人来担任,额外添加两个部门,一个是人事部门(人事部门对应图1.4中的服务器维护人员),一个是培训部门(培训部门对应图1.4中的虚拟机管理软件)。

在平时,人事部门负责人员管理、招聘、裁员和医疗等事务(对应了物理服务器的维护)。培训部门主要是负责将人事部门招聘来的新人培训成具备某种技能的员工(对应了虚拟机管理软件的功能)。

当业务扩张的时候,首先是向培训部门要人,如果培训部门发现有人可以培训,则把这些人培训为所需要的员工。如果培训部门发现没有人可供培训,那么会向人事部门要人。人事部门则会寻找相应的人,并提供给培训部门。裁员则比较简单了。

由于将人员管理、人员培训和饭店运作这3种功能进行了明白的划分,小李看了这个方案很满意。但是小李还有一个疑问就是人事部门与培训部门又怎么运作呢?人事部门与培训部门又如何管理呢?1.2.4 方案4:云计算的解决方案

采用方案3,使用虚拟机架构,还是会面临同时管理物理机与虚拟机的难题。特别是当系统规模扩大之后,使用的物理机与虚拟机数目都会急剧地增加。这时,Hypervisor的管理功能已经不适合这种大规模的场景。需要设计一个虚拟机提供系统。

使用过C语言的人,都能够体会到内存资源使用的便利性。只需要简单地使用malloc与free两个函数,就可以很方便地申请和释放内存。那么,能否把虚拟机资源管理系统设计得如同内存管理系统一样,通过简单的函数调用,就可以生成或销毁虚拟机?

这样的虚拟机资源管理系统,就被称为云计算系统。虚拟机管理是云计算系统较为核心的功能,除此之外,还包含着对存储、网络和CPU资源的管理。在过去的示意图中,经常用云来表示互联网及底层基础设施,当计算能力可以通过虚拟机,转化成为基础设施的时候,这样的系统也就称为云计算系统。

当采用云计算系统之后,整个系统的结构就发生了变化,如图1.6所示。图1.6 采用云计算系统之后的三层结构示意图

采用云计算系统之后,网站应用程序就可以直接运行在虚拟机之上了。不过,仔细想一下也就容易发现问题。从虚拟机到一个可供使用的网站应用程序还是有很长的路要走。那么按照以前的设想,能不能把这些步骤加以细化和系统化?当有一个可用的云计算系统之后,还需要有哪些步骤:(1)云计算系统搭建完成之后,可以申请、管理虚拟机。(2)利用申请的虚拟机搭建MySQL、Apache和Ftp等服务。(3)利用搭建的软件服务,搭建出互联网应用程序。

这3个步骤进行仔细的划分,也就成了著名的云计算三层架构模型,如图1.7所示。图1.7 云计算系统三层架构

在这三层中,每层代表的具体含义如下。(1)IaaS(Infrastructure as a Service)基础设施即服务。IaaS包括的部分如:物理机的管理、虚拟机的管理和存储的管理。(2)PaaS(Platform as a Service)平台即服务。PaaS包括的部分如:在虚拟机中搭建开发环境。比如配置好Apache、MySQL和PHP等环境。(3)SaaS(Software as a Service)软件即服务。SaaS包括的部分如:搭建一个购物网站、博客网站、微博网站等等,这种互联网应用可以像商品一样进行流通。

采用这三层架构有什么优势呢?

●资源的管理与有效利用。IaaS管理了底层物理资源,并且向上层提供虚拟机。因此数据中心的管理员只需要维护物理服务器就可以了,并不需要了解上层应用程序。此外,SaaS层的应用程序是按需请求虚拟机,当需求量较少的时候,可以关闭空闲的服务器以节省电量;当需求量上升的时候,可以新开一些服务器提供虚拟机,从而可以达到资源的有效利用。

● 快速部署中间件服务。PaaS可以快速批量地生成中间件服务,用来支持上层各种各样的互联网应用。如网上商店、博客应用都需要各自的数据库服务,可以分别向PaaS请求各自的数据库。此时,PaaS会自动生成两个相互独立的数据库服务,而不需要开发人员手动配置数据库。

● 加速互联网应用开发。当PaaS平台稳定之后,开发人员不再需要从底层搭建各种中间件服务。可以直接调用PaaS的API,进一步生成应用程序,因此互联网应用开发变得更加容易、快速。

一般而言,提到云计算系统的时候,就是指IaaS系统。可以说,IaaS是整个云计算系统最核心的部分,也是最难实现的部分。1.3 OpenStack架构

IaaS是云计算系统中最复杂、最难实现的部分。尽管当下有许多云计算系统,但是能够让程序员操作并且能够通过源码实践的,也就只有开源云计算软件。开源云计算软件中,OpenStack的出现并不早,但是却通过优美的代码、灵活的模块和不断地完善得到了开源社区的青睐。OpenStack在开源云计算的影响力也直线上升。因此,本书就OpenStack进行了专门的介绍与研究。1.3.1 OpenStack与云计算

OpenStack是美国国家宇航局(NASA)和Rackspace合作开发的旨在为公有云和私有云提供软件的开源项目。OpenStack是一个IaaS层的软件,其目标在于提供可靠的云部署方案及良好的可扩展性,从而实现类似于Amazon的云基础架构服务(IaaS)。

云计算可以分为私有云和公有云,尽管OpenStack的最终目标是实现一个可以灵活定制的公有云IaaS软件。但是,由于OpenStack的灵活性,要定制一个私有云相当容易。正是由于这个原因,OpenStack作为开源云计算的佼佼者,除了有Rackspace和NASA的大力支持外,也得到了Dell、Citrix、Cisco、Canonical、惠普、Intel和AMD等公司的大力扶持。底层的虚拟机可以支持KVM、XEN、VirtualBox、Qemu、LXC和vmware等。

在应用方向,很多企业如Intel、IBM、新浪都在做基于OpenStack私有云方面的测试和部署。新浪联合众多合作者推出stacklab,使得对OpenStack感兴趣的人,可以随时使用OpenStack。在开发方面,除了Racksapce与NASA在大力研发之外,Intel、IBM、新浪以及大量的开源爱好者都在OpenStack开源社区提交了大量的patch,从而推动着OpenStack快速发展。1.3.2 OpenStack发展与现状

OpenStack有着众多的版本,但是,OpenStack在标识版本的时候,并不采用其他软件版本采用数字的标识方法。OpenStack采用了A~Z开头的不同的单词来表示各种不同的版本。

2010年发布了Austin版本,也是OpenStack的第一版本。从Austin版本开始,经历了Bexar、Cactus、Diablo、Essex、Folsom,然后是当下的Grizzly。Austin版本只是有两个模块:Nova和Glance。在Bexar版本中,加入了云存储模块Swift。那时,Bexar版本已经拥有了云计算与云存储两个重要的模块。但是Bexar版本还存在相当多的问题,安装、部署和使用都比较困难。发展至Cactus版本的时候,OpenStack才真正具备了可用性。但是在易用性方面,还是只能通过命令行进行交互。此外,值得一提的是,到Cactus为止,OpenStack一直都使用的是Amazon的API接口。

Diablo版本的出现,可以认为是OpenStack的分水岭。因为以前的版本,都是在强调如何模仿Amazon的云计算平台。从Diablo开始,OpenStack的发展方向开始朝着自由化的方向发展。Diablo中添加了更多可用的模块,更加灵活的OpenStack API(Amazon的API只是兼容)。在Diablo中,加入了基于Python语言Django框架的Horizon模块。大大提高了可用性与易用性。

但是Diablo版本发行不久,由于Bug较多,在修改Bug的基础上做了大量的改动。不断提交的Bug和Patch,催生了Essex版本的快速出现。在Essex版本中,Nova、Horizon和Swift都变得较为稳定。因此,如果是要基于OpenStack做二次开发,不要选择Diablo。此外,由于软件定义网络的出现,Essex中还出现了网络管理模块Quantum。尽管Quantum还是存在着各种各样的问题。Quantum的出现,标志着OpenStack可以对虚拟网络加强定制与管理。

Folsom版本的出现,则标志着OpenStack开始真正走向正轨。Folsom中,将OpenStack分为3大组件:Nova、Swift和Quantum。这3个组件分别负责云计算、云存储和网络虚拟化。Folsom也是OpenStack中较为稳定的版本。

Grizzly版本在执笔之时,还处于开发之中。本书的安装及代码分析都基于Grizzly-rc2两版本。1.3.3 OpenStack优势

在云计算领域,从程序员角度,可以将云计算软件分为两部分:

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

下载完整电子书


相关推荐

最新文章


© 2020 txtepub下载