第一章 OpenStack概述

1.1 云计算简介

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

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

1.1.1 什么是云计算

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

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

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

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

1.1.2 什么是云存储

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

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

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

      云存储在设计的时候,为了达成这样的目标,将云存储系统分为4层。

      (1)硬件层:硬件层是云存储最底层、最基础的部分。硬件层包括了网络光纤、iSCSI设备、SSD硬盘或者其他多种多样的存储设备。有时候,这些设备并不集中于某一地,而是通过网络连接在一起。

      (2)管理层:管理层是最核心的部分。管理层主要是通过分布式文件系统、网络通信来实现,进而保证硬件设备协同工作。管理层保证了系统的可靠性、持久性和稳定性,进而向用户提供有效的存储服务。

      (3)API层：只是有了管理层还远远不够,还需要提供网络访问的API。有了这些API,就可以为各式各样的应用提供服务,比如视频点播、网盘和Dropbox等等。

      (4)客户端:一个完整的云存储系统还需要又方便易用的客户端。简介的UI和人性化的设计都是客户端yinggaokaolv

1.1.3 私有云与公有云

       公有云与私有云的差别主要体现在应用场景上。两种云计算系统核心实现甚至可以完全相同。但是,两个很关键的因素却导致了公有云的发展并没有跟上私有云的步伐。如果把私有云比作老婆管钱的话,那么公有云就是银行管钱。实际上银行管钱比老婆管钱要晚很多很多年。主要是以下两个原因。

1. 安全性
2. 服务可靠性

1.2 为什么使用云计算

1.2.1 方案1：简单的服务部署

1.部署方式

2.存在的问题

(1)安全

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

(2)可靠性

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

(3)扩展度难

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

(4)维护成本

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

1.2.2 方案2：分布式服务部署

1. 部署方式

优点:

(1)安全

由于服务器分散至了3台机器,3个服务之间是相互隔离的,并且每台机器可以针对性地设置防火墙。当一台机器被攻击的时候,别的服务可以不受影响。

(2)可靠性

每个服务不同的可靠性问题,在分布式架构下都可以得到解决。比如http需要的高可用服务,只需要额外添加一台备用服务器。

2.存在的问题

     (1)扩展难度

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

     (2)部署难度

     (3)维护难度

1.2.3 方案3：基于虚拟化的服务部署

1.部署方式

优点:

(1):安全

(2)可靠性

(3)扩展

(4)部署

(5)维护

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

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

1.2.4 方案4：云计算的解决方案

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

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

[html]  view plain  copy

1. virtual_machine *vm=malloc_virtual_machine()  
2. free_virtual_machine(vm);  

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

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

    采用云计算系统之后,网站应用程序就可以直接运行在虚拟机之上了。当有一个可用的云计算系统之后,还需要有哪些步骤:

(1)云计算系统搭建完成之后,可以申请、管理虚拟机。

(2)利用申请的虚拟机搭建MySQL、Apache和Ftp等服务。

(3)利用搭建的软件服务,搭建出互联网应用程序。

这3个步骤进行仔细的划分,也就成了著名的云计算三层架构模型，如图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,进一步生成应用程序,因此互联网应用开发变得更加容易、快速。

1.3 OpenStack架构

1.3.1 OpenStack与云计算

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

    云计算可以分为私有云和公有云,尽管OpenStack的最终目标是实现一个可以灵活定制的公有云IaaS软件。但是,由于OpenStack的灵活性,要定制一个私有云相当容易。

1.3.2 OpenStack发展与现状

    OpenStack采用了A~Z开头的不同的单词来表示各种不同的版本。

    2010年发布了Austin版本,也是OpenStack的第一版本。从Austin版本开始,经历了Bexar、Cactus、Diablo、Essex、Folsom,然后当下的Grizzly。Austin版本只有两个模块:Nova和Glance。在Bexar版本中,加入了云存储模块Swift。此外,值得一提的是,到Cactus为止,OpenStack一直都使用的是Amazon的API接口。

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

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

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

1.3.3 OpenStack优势

(1)模块松耦合

(2)组件配置较为灵活

(3)二次开发容易

1.3.4 OpenStack学习建议

OpenStack官网www.openstack.org

OpenStack源代码。较稳定的发行版位于https://launchpad.net/,比如https://launchpad.net/openstack就罗列了整个OpenStack的概貌。

OpenStack最新的代码,则位于GitHub(https://github.com/openstack)

1.4 OpenStack各个组件及功能

1.4.1 虚拟机管理系统Nova

  先简单介绍一下每个模块的作用。

  (1)Web UI:主要呈现给管理员使用。主要要求是：界面简洁、流程简单、稳定。

  (2)Nova: 主要负责用户、权限管理；数据库交互;最主要的还是虚拟机资源管理。

  (3)Hypervisor:虚拟机管理软件,比如Qemu、KVM/Libvirt、XEN等开源软件。

  (4)操作系统：采用Linux发行版。

1.4.2 磁盘存储系统Glance和Swift

       安装虚拟机,每次虚拟机从ISO安装都是一个繁琐的过程。在互联万应用中，往往需要大规模地创建新的虚拟机。如果每台虚拟机都从ISO进行安装,无疑会浪费许多的时间。尽管PXE(https://github.com/JiYou/easyinstall)网络自动化安装,也是一个不错的选择,但是依然会把时间浪费在操作系统的安装上(只是节省了人力时间)。并且PXE网络安装还面临的问题是虚拟机所处的网络环境可能比较复杂的。

       有一种简单的虚拟机安装方式：复制Image。当安装号一台虚拟机之后,关闭这台虚拟机,保留Image。当需要创建一台新的虚拟机的时候,直接复制Image作为新建虚拟机的Image就可以了。

       采用这种方式,还有一个好处。用户在使用云计算系统的时候,可以定制一个自己的Image,然后上传到云系统中,就可以创建自己定制的虚拟机系统了。

       虚拟机Image的传输常常需要占用大量的网络带宽。如果所有的Image的传输都通过Nova模块进行,那么Nova接口的压力会变得相当大。所以,应该考虑Image的管理独立出来,成为一个独立的Image管理系统,在OpenStack中命名为Glance。无论是用户Image的传输以及管理,或者Nova内部对Image的请求,都转向Glance。虚拟机Image的管理,则由Glance全权代理了。

       Glance主要的功能是管理Image。但是Glance只是一个代理。Glance本身并不实现存储功能,她只是提供了一系列的接口来调用底层的存储服务。为什么要采用这样的设计呢？最主要的原因是由于用户在Image的存储方案上,有着各式各样的复杂的需求。比如：

       (1)有的公司有着独有的存储系统(包括硬件和软件)。

       (2)大型企业需要高可靠性、高稳定性的存储需求,但是没有自己的存储系统。

       (3)小企业与开发人员需要简单易用的存储系统。

       针对一系列不同的需求,把Glance设置成代理是一种比较好的解决方案。有的企业可能有自己的存储系统,那么只要接在Glance的后端,就可以提供给云计算系统作为Image存储服务了。但是,对于没有自己独有的存储系统的企业而言,Glance后端可以使用开源免费的Swift存储系统。

       Swift是OpenStack的三大部件之一,同时也是object storage及云存储的开源实现。在只需要云存储的环境中(比如只提供存储服务,各种云盘、网盘等等),也可以单独使用。

1.4.3 虚拟网络管理Quantum

      在大型互联网应用中,虚拟机都不是单独使用的,往往需要组件局域网,甚至需要划分子网,以实现虚拟机与主机,及虚拟机之间的通信。传统的组网方式都是直接基于硬件进行操作。但是，在解决虚拟机的网络问题的时候,并不需要也不能采用硬件手工操作方式了。需要用软件来定义虚拟机的网络(亦称之为虚拟网),即Software defined network(SDN)。

      虚拟网络如此重要,实在没有任何理由将其放到Nova中。云计算的虚拟网路管理,应该独立出来,在OpenStack中取名为Quantum。

      虽然Quantum已经从Nova中独立出来了,并且已经成为重量级部件,但是依照Glance的设计原理与经验,在这里依然需要依从使用者的需求,也不外乎同样的3个问题:

      (1)有的企业可能使用私有的网络设备以及自定义的SDN软件。

      (2)有的企业有SDN软件的需求,但是并没有这样的软件。

      (3)小型环境或开发人员有时候只需要简单的网络环境(比如开发的重点并不在虚拟网络)。

      针对这些不同的需求,Quantum采用代理模式是一个较好的选择。那么使用者可以根据自己的情况,在Quantum的后端选择接入自己的设备,或者采用SDN的开源实现OpenvSwitch,或者直接采用Linux bridge桥接网络,这时,Quantum的结构就跟家清晰,如图1.11所示。

1.4.4 OpenStack三大组件