第一章 Openstack概述

缠中说禅

Openstack由来

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

说明：服务名是项目名的别名



三个核心项目

• 控制台
  
  
  • 服务名：Dashboard
    
  • 项目名：Horizon
    
  • 功能：web方式管理云平台，建云主机，分配网络，配安全组，加云盘
    
  
  
• 计算
  
  
  • 服务名：计算
    
  • 项目名：Nova
    
  • 功能：负责响应虚拟机创建请求、调度、销毁云主机
    
  
  
• 网络
  
  
  • 服务名：网络
    
  • 项目名：Neutron
    
  • 功能：实现SDN（软件定义网络），提供一整套API，用户可以基于该API实现自己定义专属网络，不同厂家可以基于此API提供自己的产品
    
  
  

两个存储项目

• 对象存储
  
  
  • 服务名：对象存储
    
  • 项目名：Swift
    
  • 功能：REST风格的接口和扁平的数据组织结构。RESTFUL HTTP API来保存和访问任意非结构化数据，ring环的方式实现数据自动复制和高度可扩展架构，保证数据的高度容错和可靠性
    
  
  
• 块存储
  
  
  • 服务名：块存储
    
  • 项目名：Cinder
    
  • 功能：提供持久化块存储，即为云主机提供附加云盘
    
  
  

三个服务项目

• 认证服务
  
  
  • 服务名：认证服务
    
  • 项目名：keystone
    
  • 功能：为访问openstack各组件提供认证和授权功能，认证通过后，提供一个服务列表（存放你有权访问的服务），可以通过该列表访问各个组件。
    
  
  
• 镜像服务
  
  
  • 服务名：镜像服务
    
  • 项目名：Glance
    
  • 功能：为云主机安装操作系统提供不同的镜像选择
    
  
  
• 计费服务
  
  
  • 服务名：计费服务
    
  • 项目名：Ceilometer
    
  • 功能：收集云平台资源使用数据，用来计费或者性能监控
    
  
  

高层服务项目

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

Openstack各组件详解及运行流程

各组件逻辑关系





新建云主机流程





虚拟机启动过程如下：

• 界面或命令行通过RESTful API的keystone获取认证信息
  
• keystone通过用户请求认证信息，并生产auth-token返回给对应的认证请求
  
• 界面或命令行通过RESTful API向nava-api发送一个boot instance请求（携带auth-token）
  
• nava-api接收请求后向keystone发送认证请求，查看token是否为有效用户和token
  
• keystone验证token是否有效，如有效则返回有效的认证和对应的角色（注：有些操作需要有角色权限才能操作）
  
• 通过认证后nova-api和数据库通讯
  
• 初始化新建虚拟机的数据库记录
  
• nova-api通过rpc.call想nova-scheduler请求是否有创建虚拟机的资源（Host ID）
  
• nova-scheduler进程监听消息队列，获取nova-api的请求
  
• nova-scheduler通过查询nova数据库中计算资源的情况，并通过调度算法计算符合虚拟机创建需要的主机
  
• 对于有符合虚拟机创建的主机，nova-scheduler更新数据库中虚拟机对应的物理主机信息
  
• nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息
  
• nova-compute会从对应的消息队列中获取创建虚拟机请求的消息
  
• nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息（Flavor）
  
• nova-conductor从消息队队列中拿到nova-compute请求消息
  
• nova-conductor根据消息查询虚拟机对应的信息
  
• nova-conductor从数据库中获得虚拟机对应信息
  
• nova-conductor把虚拟机信息通过消息的方式发送到消息队列中
  
• nova-compute从对应的消息队列中获取虚拟机信息消息
  
• nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求glance-api获取创建虚拟机所需要镜像
  
• glance-api向keystone认证token是否有效，并返回验证结果
  
• token验证通过，nova-compute获得虚拟机镜像信息(URL)
  
• nova-compute通过keystone的RESTfull API拿到认证k的token，并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息
  
• neutron-server向keystone认证token是否有效，并返回验证结果
  
• token验证通过，nova-compute获得虚拟机网络信息
  
• nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息
  
• cinder-api向keystone认证token是否有效，并返回验证结果
  
• token验证通过，nova-compute获得虚拟机持久化存储信息
  
• nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机
  

组件详解

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对Tenant中资源（包括Services）的操作权限。对于Keystone service来说，Policy就是一个JSON文件，默认是/etc/keystone/policy.json。通过配置这个文件，Keystone Service实现了对User基于Role的权限管理
  
• Token：是一个字符串表示，作为访问资源的令牌。Token包含了在指定范围和有效时间内可以被访问的资源。比如，在Nova中一个tenant可以是一些虚拟机，在Swift和Glance中一个tenant可以是一些镜像存储，在Network中一个tenant可以是一些网络资源。Token一般被User持有
  
• Credentials：用于确认用户身份的凭证
  
• Authentication：确定用户身份的过程
  
• Service：Openstack service，即Openstack中运行的组件服务
  
• Endpoint：一个可以通过网络来访问和定位某个Openstack service的地址，通常是一个URL。比如，当Nova需要访问Glance服务去获取p_w_picpath 时，Nova通过访问Keystone拿到Glance的endpoint，然后通过访问该endpoint去获取Glance服务。我们可以通过Endpoint的region属性去定义多个region。Endpoint 该使用对象分为三类：
  
  
  • admin url：给admin用户使用，Post：35357
    
  • internal url：Openstack内部服务使用来跟别的服务通信，Post：5000
    
  • public url：其他用户可以访问的地址，Post：5000
    
  
  

创建完service后创建API Endpint，在Openstack中，每个service都有三种end points：admin url、internal url、public url。admin url是用作管理的，它能修改user/tenant（project）。public是让客户调用的，它可以部署在外网让客户可以管理自己的云。internal是Openstack内部调用的。三种endpoint在网络上开放的权限一般也不同。admin通常只能对内网开放，public通常可以对外网开放，internal通常只能对安装有Openstack对服务的机器开放



glance
V1



V2



nova
nova主要组成：

• nova-api
  
• nova-scheduler
  
• nova-compute
  
• nova-conductor
  

cinder
cinder主要组成

• cinder-api：cinder-api是cinder 服务的endpoint，提供rest接口，负责处理client请求，并将RPC请求发送至cinder-scheduler组件
  
• cinder-scheduler：cinder-scheduler负责cinder请求调度，其核心部分就是scheduler_driver作为 scheduler manager的driver，负责cinder-volume具体的调度处理，发送cinder RPC请求到选择的 cinder-volume
  
• cinder-volume：Cinder-volume负责具体的volume请求处理，由不同后端存储提供volume存储空间。目前各大存储厂商已经积极地将存储产品的driver贡献到cinder社区
  

neutron
neutron包含组件：

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

neutron-plugin分为：

• core-plugin：Neutron中即为ML2（Modular Layer 2），负责管理L2的网络连接。ML2中主要包括network、subnet、port三类核心资源，对三类资源进行操作的REST API被neutron-server看作Core API，由Neutron原生支持。其中：
  

• service-plugin：即为除core-plugin以外其他的plugin，包括l3 router、firewall、loadbalancer、×××、metering等等，主要实现L3-L7的网络服务。这些plugin要操作的资源比较丰富，对这些资源进行操作的REST API被neutron-server看作Extension API，需要厂家自行进行扩展
  

        Neutron对Quantum的插件机制进行了优化，将各个厂商L2插件中独立的数据库实现提取出来，作为公共的ML2插件存储租户的业务需求，使得厂商可以专注于L2设备驱动的实现，而ML2作为总控可以协调多厂商L2设备共同运行”。在Quantum中，厂家都是开发各自的Service-plugin，不能兼容而且开发重复度很高，于是在Neutron中就为设计了ML2机制，使得各厂家的L2插件完全变成了可插拔的，方便了L2中network资源扩展与使用。
        注意，以前厂商开发的L2 plugin跟ML2都存在于neutron/plugins目录下，而可插拔的ML2设备驱动则存在于neutron/plugins/ml2/drivers目录下。
        ML2作为L2的总控，其实现包括Type和Mechanism两部分，每部分又分为Manager和Driver。Type指的是L2网络的类型（如Flat、VLAN、VxLAN等），与厂家实现无关。Mechanism则是各个厂家自己设备机制的实现，如下图所示。当然有ML2，对应的就可以有ML3，不过在Neutron中L3的实现只负责路由的功能，传统路由器中的其他功能（如Firewalls、LB、×××）都被独立出来实现了，因此暂时还没有看到对ML3的实际需求。
        一般而言，neutron-server和各neutron-plugin部署在控制节点或者网络节点上，而neutron-agent则部署在网络节点上和计算节点上网络模式介绍

• 根据创建网络的用户权限，neutron可以分为：
  
  
  • provider network：管理员创建的和物理网络有直接映射关系的虚拟网络
    
  • tenant network：租户、普通用户创建的网络，物理网络对创建者透明，其配置由 Neutorn 根据管理员在系统中的配置决定
    
  
  
• 根据网络的类型，neutron可以分为：
  
  
  • VLAN network（虚拟局域网） ：基于物理 VLAN 网络实现的虚拟网络。共享同一个物理网络的多个 VLAN 网络是相互隔离的，甚至可以使用重叠的 IP 地址空间。每个支持 VLAN network 的物理网络可以被视为一个分离的 VLAN trunk，它使用一组独占的 VLAN ID。有效的 VLAN ID 范围是 1 到 4094。
    
  • GRE network （通用路由封装网络）：一个使用 GRE 封装网络包的虚拟网络。GRE 封装的数据包基于 IP 路由表来进行路由，因此 GRE network 不和具体的物理网络绑定
    
  • VXLAN network（虚拟可扩展网络）：基于 VXLAN 实现的虚拟网络。同 GRE network 一样， VXLAN network 中 IP 包的路由也基于 IP 路由表，也不和具体的物理网络绑定
    
  
  

VLAN





GRE与VXLAN