OpenStack入门介绍

发表于

参考：原文链接

1、为啥要选择云计算

（1）有效的解决了硬件单节点故障问题

单点故障是指某个硬件的故障造成网站某个服务的中断。要真正解决这个问题，需要为每个硬件准备冗余，这不仅大大增加了硬件购置成本，而且部署与维护成本也不容小视。而云计算平台是基于服务器集群，从设计之初就考虑了单点故障问题，并在建设时有效地解决了这个问题。如果一家云服务商出现单点故障问题，就如同存在银行的钱丢了。

（2）按需增减资源

自己托管服务器，增/减硬件一直是头疼的问题。

1. 增加服务器的时候，购买服务器需要时间，而且这个时间自己无法控制。而使
   用云服务器，随时可以增加服务器——垂手可得。
2. 减服务器只能从机房拉回办公室，无法再把服务器退给厂商，购置服务器的成
   本就浪费了。而使用云服务器，如果下个月不用，不续费就行了（针对阿里云按月购买的情况）——想用就用，想扔就扔。
3. 不能按需增加满足基本需求的服务器配置。假如我们现在需要一台低配置的服务
   器用Linux跑缓存服务，如果为之单独购买一台便宜的低配置的服务器很不合算，因为这台服务器仅仅一年的电费就至少要3000元左右。所以只能尽量减少
    服务器数量，提高单台服务器的配置，在让一台服务器跑更多东西。而使用云服务器，需要什么样的配置就买什么样的配置，让各个服务器的职责更单
    一，互相之间的影响更小——职责分明，效率更高。

（3）BGP线路解决南北互通问题

南北互通问题是南方电信与北方联通线路之间的互通问题，这个问题困扰我们多年，之前用过双线机房，解决的也不是很好。目前只有BGP线路才能有效解决这个问题，而拥有真正的BGP线路的机房不是很多，成本也非常高。而我准备使用的阿里云用的就是BGP线路，这也是吸引我们的主要地方之一。
究竟什么是南北互通问题？基于我们的理解简体描述一下，不对之处欢迎指出。南北互通问题实际就是路由问题。假设我们的服务器放在上海电信的机房，上海一位联通的用户访问我们的服务器，要先绕到联通的北京总出口（假设总出口在北京），然后再绕回上海。实际上这位联通用户可以通过上海的线路直接到达我们的服务器，不用绕这么远，但上海电信的机房无法告知联通的路由器走近路过来，只能按照联通路由器设定好的路由走。本来即使走北京绕一下也没有大的影响，毕竟是光的速度，但是由于大多数联通的用户访问电信网络都这么绕着走，联通的总出口成为了瓶颈，总出口流量太大时，联通的用户访问电信的网络速度就会慢。BGP线路也没什么神奇之处，只是它能决定走什么路由过来，不绕远路，问题自然解决了。它有这样的特权，就不仅能解决南北互通的问题，而且能解决其他网络的互通问题，比如教育网。因为有权限决定路由，就可以优化路由，哪条路堵，我就换条路。

（4）按需增减带宽

带宽是主要成本，托管服务器时，与ISP服务商签一年合同之前就要确定带宽。用了一段时间之后，你发现带宽买多了，想减一些是不允许的。中途要临时增加带宽一段时间也是不行的，要买就买一年（这是根据我们接触过的ISP服务商）。所以，一般都会多买一些带宽，留一些余量。
使用云服务器可以灵活地增减带宽，不会浪费带宽，即使买少了也不用担心，随时可以增加。虽然各个云服务商会有一定的限制，比如在阿里云一次至少要购买1个月的带宽，但比自己托管服务器灵活很多，同样的带宽条件，会节省不少成本，尤其是带宽需求在一年中变化比较大的网站。

（5）更为合理的支付方式

在IDC机房托管服务器一般是签一年合同，一次支付一个季度的费用。
而使用云服务，一次可以支付更短时间的费用，比如阿里云可以一次只支付一个月的费用，节约了流动资金。
从总体上考虑，差不多的成本，却拥有更多的内存、更多的CPU、更多的硬盘空间、更优质的带宽线路，更重要的是可以随时按需扩展计算资源。

2、云计算服务模式

（1）laaS：基础设施即服务

用户通过网络获取虚机、存储、网络，然后用户根据自己的需求操作获取的资源。 典型应用：亚马逊AWS等

（2）Paas：平台即服务

将软件研发平台作为一种服务， 如Eclipse/Java编程平台，服务商提供编程接口/运行平台等。典型应用：Google AppEngine、Force.com、微软Azure等

（3）SaaS：软件即服务

将软件作为一种服务通过网络提供给用户，如web的电子邮件、HR系统、订单管理系统、客户关系系统等。用户无需购买软件，而是向提供商租用基于web的软件，来管理企业经营活动。典型应用：Google Doc、Saleforce.com、Oracle CRM On Demand、Office Live Workspace等

3、openstack组件到介绍

（1）openstack的由来

openstack最早由美国国家航空航天局NASA研发的Nova和Rackspace研发的swift组成。后来以apache许可证授权,旨在为公共及私有云平台建设。openstack主要用来为企业内部实现类似于Amazon EC2和S3的云基础架构服务（Iaas）.每6个月更新一次，基本与ubuntu同步，命名是以A-Z作为首字母来的。

（2）openstack项目与组件

核心项目3个

1、控制台

服务名：Dashboard
项目名：Horizon
功能 ：web方式管理云平台，建立主机、分配网络，配安全组，加云盘

2、计算

服务名：Compute
项目名：Nova
功能 ：负责响应虚拟机创建请求、调度、销毁

3、网络

服务名：Network
项目名：Neutron （从Quantum改名而来的）
功能 ：在各接口设备之间提供网络即服务(networking as a service),而且受其他OpenStack服务管理,如Nova。 具体来说，Neutron为OpenStack云更灵活地划分物理网络，在多租户环境下提供给每个租户独立的网络环境。另外，Neutron提供API来实现这种目标。Neutron中“网络”是一个可以被用户创建的对象，如果要和物理环境下的概念映射的话，这个对象相当于一个巨大的交换机，可以拥有无限多个动态可创建和销毁的虚拟端口。

存储项目2个

1、对象存储

服务名：Object Storage
项目名：Swift
功能 ：
REST风格的接口和扁平的数据组织结构。RESTFUL HTTP API来保存和访问任意非结构化数据，ring环的方式实现数据自动复制和高度可以扩展架构，保证数据的高度容错和可靠性

2、块存储

服务名：Block Storage
项目名：Cinder
功能：提供持久化块存储，也就为云主机提共附加的云盘

共享服务项目：

1、认证服务

服务名：认证服务
项目名：KeySton
功能 ：为访问openstack各组件提供认证和授权功能，认证通过后，提供一个服务列表（罗列你有权限访问的服务）。

2、镜像服务

服务名：镜像服务
项目名：Glance
功能 ：为云主机安装操作系统提供不同的镜像选择

3、计费服务

服务名：计费服务
项目名：Ceilometer
功能 ：收集云平台资源使用数据，用来计费或者性能监控

高层服务项目1个

1、编排服务

服务名：编排服务
项目名：Heat
功能 ：自动化部署应用，自动化管理应用的整个生命周期。主要用于：PaaS

4、openstack各组件到详解和运行流程

各组件的逻辑关系图：

image

openstack新建云主机到流程图：

image

虚拟机的启动过程：

1、界面或命令行通过RESTful API向keystone获取认证信息（Horizon）
2、keystone通过用户请求的认证信息，并生成auth-token返回给对应的认证请求。
3、界面或命令行通过RESTful API向nova-api发送一个boot instance的请求（携带auth-token）
4、nova-api接受请求后，会向keystone发送请求认证信息，查看token是否为有效的用户和token
5、keystone验证token是否有效，如果有效则返回有效的认证和对应的角色
6、通过认证后，nova-api和数据库通讯
7、初始化新建的虚拟机数据库信息。
8、nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源（Host ID）
9、nova-scheduler进程侦听消息队列，获取nova-api的请求
10、nova-scheduler通过查询nova数据库中计算资源的情况，并通过调度算法计算符合虚拟机创建需要的主机。
11、对于有符合虚拟机创建的主机，nova-scheduler更新数据库中虚拟机对应的物理主机信息。
12、nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息
13、nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。
14、nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。（Flavor）
15、nova-conductor从消息队列中拿到nova-compute请求消息。
16、nova-conductor根据消息查询虚拟机对应的信息。
17、nova-conductor从数据库中获得虚拟机对应信息
18、nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。
19、nova-compute从对应的消息队列中获取虚拟机信息消息。
20、nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求glance-api获取创建虚拟机所需要镜像。
21、glance-api向keystone认证token是否有效，并返回验证结果。
22、token验证通过，nova-compute获得虚拟机镜像信息(URL)。
23、nova-compute通过keystone的RESTfull API拿到认证k的token，并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。
24、neutron-server向keystone认证token是否有效，并返回验证结果。
25、token验证通过，nova-compute获得虚拟机网络信息。
26、nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。
27、cinder-api向keystone认证token是否有效，并返回验证结果。
28、token验证通过，nova-compute获得虚拟机持久化存储信息。
29、nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。

对复杂的模块进行展开：

1、Keystone

User ：指使用Openstack service的用户，可以是人、服务、系统，但凡使用了Openstack service的对象都可以称为User

Project（Tenant）：可以理解为一个人、或服务所拥有的 资源集合 。在一个Project(Tenant)中可以包含多个User，每一个User都会根据权限的划分来使用Project(Tenant)中的资源。比如通过Nova创建虚拟机时要指定到某个Project中，在Cinder创建卷也要指定到某个Project中。User访问Project的资源前，必须要与该Project关联，并且指定User在Project下的Role。

Role：用于划分权限。可以通过给User指定Role，使User获得Role对应的操作权限。Keystone返回给User的Token包含了Role列表，被访问的Services会判断访问它的User和User提供的Token中所包含的Role。系统默认使用管理Role admin和成员Role member 。

Policy：OpenStack对User的验证除了OpenStack的身份验证以外，还需要鉴别User对某个Service是否有访问权限。Policy机制就是用来控制User对Project（Tenant）中资源(包括Services)的操作权限。对于Keystone service来说，Policy就是一个JSON文件，默认是/etc/keystone/policy.json。通过配置这个文件，Keystone Service实现了对User基于Role的权限管理。

Token ：是一个字符串表示，作为访问资源的令牌。Token包含了在 指定范围和有效时间内 可以被访问的资源。EG. 在Nova中一个tenant可以是一些虚拟机，在Swift和Glance中一个tenant可以是一些镜像存储，在Network中一个tenant可以是一些网络资源。Token一般被User持有。

Credentials：用于确认用户身份的凭证

Authentication：确定用户身份的过程

Service：Openstack service，即Openstack中运行的组件服务。

Endpoint：一个可以通过网络来访问和定位某个Openstack service的地址，通常是一个URL。比如，当Nova需要访问Glance服务去获取image 时，Nova通过访问Keystone拿到Glance的endpoint，然后通过访问该endpoint去获取Glance服务。我们可以通过Endpoint的region属性去定义多个region。Endpoint 根据使用对象分为三类：
● admin url –> 给admin用户使用，Post：35357
● internal url –> OpenStack内部服务使用来跟别的服务通信，Port：5000
● public url –> 其它用户可以访问的地址，Post：5000
创建完service后创建API EndPoint. 在openstack中，每一个service都有三种Endpoints. Admin, public, internal。 Admin是用作管理用途的，如它能够修改user/tenant(project)。 public 是让客户调用的，比如可以部署在外网上让客户可以管理自己的云。internal是openstack内部调用的。三种Endpoints 在网络上开放的权限一般也不同。Admin通常只能对内网开放，public通常可以对外网开放internal通常只能对安装有openstack对服务的机器开放。

2、nova和cinder

nova主要组成：
● nova-api
● nova-scheduler
● nova-compute
● nova-conductor
cinder主要组成：
● cinder-api
● cinder-scheduler
● cinder-volume

cinder-api是cinder服务的Endpoint，提供rest接口，负责处理client请求。并将RPC请求发送给cinder-scheduler组件

cinder-scheduler负责cinder调度，其核心部分就是scheduler_drver，作为scheduler manager的driver，负责cinder-volume具体的调度处理，发送cinder RPC请求得到选择的cinder-volume

cinder-volume负责具体的volume请求处理，由不同的后端存储提供volume存储空间。

cinder架构图：
image

RPC介绍：

openstack组件的通信：调用各个组件的api提供的rest接口，
组件内的通信：基于RPC（远程过程调用）机制，而RPC机制是基于

从RPC使用的角度出发，nova、neutron，和cinder的流程是相似的，所以我们以cinder为列，阐述RPC机制：

Openstack 组件内部的 RPC（Remote Producer Call）机制的实现是基于 AMQP(Advanced Message Queuing Protocol)作为通讯模型，从而满足组件内部的松耦合性。AMQP 是用于异步消息通讯的消息中间件协议，AMQP 模型有四个重要的角色:
1、Exchange：根据 Routing key 转发消息到对应的 Message Queue 中
2、 Routing key：用于 Exchange 判断哪些消息需要发送对应的 Message Queue
3、Publisher：消息发送者，将消息发送的 Exchange 并指明 Routing Key，以便 Message Queue可以正确的收到消息
4、Consumer：消息接受者，从 Message Queue 获取消息

消息发布者 Publisher 将 Message 发送给 Exchange 并且说明 Routing Key。Exchange 负责根据 Message 的 Routing Key 进行路由，将 Message 正确地转发给相应的 Message Queue。监听在 Message Queue 上的 Consumer 将会从 Queue 中读取消息。Routing Key 是 Exchange 转发信息的依据，因此每个消息都有一个 Routing Key 表明可以接受消息的目的地址，而每个 Message Queue 都可以通过将自己想要接收的 Routing Key 告诉 Exchange 进行 binding，这样 Exchange 就可以将消息正确地转发给相应的 Message Queue。

Publisher可以分为4类：

  1. Direct Publisher发送点对点的消息；
  2. Topic Publisher采用“发布——订阅”模式发送消息；
  3. Fanout Publisher发送广播消息的发送；
  4. Notify Publisher同Topic Publisher，发送 Notification 相关的消息

Exchange可以分为4类：

  1. Direct Exchange根据Routing Key进行精确匹配，只有对应的 Message Queue 会接受到消息；
  2. Topic Exchange根据Routing Key进行模式匹配，只要符合模式匹配的Message Queue都会收到消息；
  3. Fanout Exchange将消息转发给所有绑定的Message Queue。

AMQP消息模型：

Client 端发送 RPC 请求由 publisher 发送消息并声明消息地址，consumer 接收消息并进行消息处理，如果需要消息应答则返回处理请求的结果消息。OpenStack RPC 模块提供了 rpc.call，rpc.cast, rpc.fanout_cast 三种 RPC 调用方法，发送和接收 RPC 请求。

3、neutron

neutron包含组件：

  1. neutron-server
  2. neutron-plugin
  3. neutron-agent
    各个组件的作用到介绍
    1.Neutron-server可以理解为一个专门用来接收Neutron REST API调用的服务器，然后负责将不同的rest api分发到不同的neutron-plugin上。
    2.Neutron-plugin可以理解为不同网络功能实现的入口，各个厂商可以开发自己的plugin。Neutron-plugin接收neutron-server分发过来的REST API，向neutron database完成一些信息的注册，然后将具体要执行的业务操作和参数通知给自身对应的neutron agent。
    3.Neutron-agent可以直观地理解为neutron-plugin在设备上的代理，接收相应的neutron-plugin通知的业务操作和参数，并转换为具体的设备级操作，以指导设备的动作。当设备本地发生问题时，neutron-agent会将情况通知给neutron-plugin。
    4.Neutron database，顾名思义就是Neutron的数据库，一些业务相关的参数都存在这里。
    5.Network provider，即为实际执行功能的网络设备，一般为虚拟交换机（OVS或者Linux Bridge）。