OpenStack先容说明、OpenStack架构说明、OpenStack焦点服务说明、OpenStack ...

OpenStack先容说明

OpenStack劈头

• 2006年亚马逊推出AWS，正式开启云计算的新纪元
  
• 2010年7月美国国家航空航天局（NASA）与Rackspace合作，共同公布OpenStack开放源码筹划，由此开启了属于OpenStack的时代
  
• OpenStack从诞生之初对标AWS，不停在向AWS学习，同时开放接口去兼容各种AWS服务
  

熟悉openstack【重要】

• OpenStack是什么？
  OpenStack是一种云操作体系，可控制整个数据中心内的大型计算、存储和网络资源池，所有资源都通过具有通用身份验证机制的API进行管理和配置。管理员也可通过Web界面控制，同时授权用户通过Web界面配置资源。
  
  
  
  
  
  
  • OpenStack是虚拟机、裸金属和容器的云基础架构
    
  • OpenStack可控制整个数据中心的大型计算、存储和网络资源池
    
  • 所有资源都通过API或Web界面进行管理
    
  
  
• OpenStack能做什么？
  OpenStack既是一个社区，也是一个项目和一个开源软件，提供开放源码软件，建立公共和私有云，它提供了一个摆设云的操作平台或工具集，其宗旨在于资助构造运行为虚拟计算或存储服务的云，为公有云、私有云，也为大云、小云提供可扩展的、灵活的云计算。
  作为一个开源的云计算管理平台，OpenStack由几个主要的组件组合起来完成具体工作。OpenStack支持几乎所有类型的云情况，项目目的是提供实行简朴、可大规模扩展、丰富、标准统一的云计算管理平台。OpenStack通过各种互补的服务提供了基础设施即服务（IaaS）的解决方案，每个服务提供API以进行集成。
  
  
  
  
  
  
  • OpenStack通过一组相互关联的服务提供基础设施即服务 （IaaS）解决方案。每个服务都提供了一个应用步伐编程接口 （API）来促进这种集成
    
  • OpenStack项目是一个实用于所有类型云的开源云计算平台，项目目的是提供实行简朴、可大规模扩展、丰富、标准统一的云计算管理平台
    
  
  
• OpenStack工作原理概述
  
  
  
  
  
  
  • OpenStack现实上由一系列叫作脚本的下令组成。这些脚本会被捆绑到名为项目的软件包中，这些软件包则用于传递创建云情况的任务
    
  • 为了创建这些情况，OpenStack还会利用 2 种其他类型的软件：
    
    
    
    • 虚拟化软件，用于创建从硬件中抽象出来的虚拟资源层
      
    • 基础操作体系（OS），用于实行OpenStack脚本发出的下令
      
    
    
  • OpenStack本身不会虚拟化资源，但会利用虚拟化资源来构建云
    
  • OpenStack、虚拟化和基础操作体系，这 3 种技术协同工作服务用户
    
  
  
• 开源OpenStack版本演进
  
  
  
  • OpenStack第一版代号为Austin，以Rackspace所在的美国德克萨斯州Texas首府定名，筹划每隔几个月发布一个全新版本，而且以26个英笔墨母从A到Z序次定名背面的版本代号。通常以举办OpenStack峰会所在地的某个都会或地区来定名。
    
  • 2017光阴为成功晋级为白金会员，成为亚洲首家OpenStack白金会员。
    
  • OpenStack基金会答应最多8家白金会员资格和24家黄金会员资格，如今已有AT&T、爱立信、华为、英特尔、Rackspace、红帽、SUSE和腾讯这8家白金会员，以及九州云、中国移动、中国联通、中国电信、思科、EasyStack、烽火、浪潮、新华三以及中兴通讯等黄金会员。
    
  • OpenStack每年两个大版本，一样平常在4月和10月中旬发布，版本定名从字母A-Z
    
    
    
    
  
  
• OpenStack筹划理念
  
  
  
  
  
  
  • 开放：
    
    
    
    • 源代码开放，筹划与开辟流程开放。
      
    • “不重复发明轮子”，“站在巨人的肩膀上”。
      
    • 倒霉用任何不可替代的私有/贸易组件。
      
    
    
  • 灵活：
    
    
    
    • 架构可裁剪，可以根据现实需要决定选取的组件范围。
      
    • 大量采用驱动与插件机制。
      
    • 通过配置项控制对体系功能特性进行便捷配置。
      
    
    
  • 可扩展：
    
    
    
    • 松耦合架构，组件间RESTful API通讯，组件内消息总线通讯。
      
    • 无中心架构，焦点组件无中心节点，有效避免单点故障。
      
    • 无状态架构，各组件无本地持久化数据，所有持久化数据生存在数据库中。
      
    
    
  
  
• OpenStack与虚拟化
  OpenStack优先关注控制面，OpenStack优先思量如何将计算、存储、网络领域的各类资源抽象为资源池。在此基础上，对资源池内的各类逻辑对象实行控制操作，并将控制操作包装成面向用户的服务。数据面、管理面如今不是OpenStack的重点关注内容。
  
  
  
  • OpenStack不是虚拟化，OpenStack只是体系的控制面，不包括体系的数据面组件，如Hypervisor、存储和网络设备等
    
  • 虚拟化是OpenStack底层的技术实现本事之一，但并非焦点关注点
    
  • OpenStack与虚拟化的关键区别：
    
    
    
    
  
  
• OpenStack与云计算
  
  
  
  • OpenStack是框架：以OpenStack为框架，将计算、存储、网络、管理、运营、运维等多个领域的软硬件产品组件整合在一起，共同组成面向业务场景的团体解决方案。
    
  • OpenStack主要关注的题目：框架本身的开放性，生态的繁荣与活跃；控制面的服务本领、高可靠、高性能、可扩展、易操作、易维护等。
    
  • Cloud BSS：Cloud Business Support System，云业务支撑体系。
    
  • Cloud OSS：Cloud Operation Support System ，云运营支撑体系。
    
  • 综上两个对比，可以总结出云计算与虚拟化的关键区别：
    云计算的特点是IT本领的服务化，按需利用，按量计费，多租户隔离等。
    虚拟化的特点是情况隔离，资源复用，降低隔离消耗，提拔运行服从，提供高级虚拟化特性等。
    
  • openstack只是构建云计算的关键组件：内核、骨干、框架、总线
    
  • 为了构建云计算，我们还需要许多东西：
    
    
    
  
  

OpenStack架构说明

OpenStack架构概览

• OpenStack被分解为服务，答应用户根据需要即插即用组件。OpenStack舆图让用户可以“一目了然”地相识OpenStack情况，以相识这些服务适合的位置以及它们如何协同工作。
  
  
  
  • 图1
    
    
    
    
  • 图2
    
    
    
    
  
  

OpenStack逻辑架构

• 要筹划、摆设和配置OpenStack，管理员必须相识其逻辑架构
  
• 每个OpenStack服务内部是由多个进程组成。所有服务（Keystone除外）都至少有一个API进程，负责监听API哀求，对哀求进行预处理并将它们传递给服务的其他部分
  
• 每个OpenStack服务的进程之间的通讯，利用AMQP消息代理。服务的状态存储在数据库中。在摆设和配置OpenStack云时，管理员可以在多种消息代理和数据库解决方案中进行选择，比方RabbitMQ、MySQL、MariaDB和SQLite
  
• 用户可以通过Web用户界面、下令行客户端以及通过浏览器插件或curl等工具发出API哀求来访问OpenStack
  

OpenStack生产情况摆设架构示例

• 生产情况中，一样平常会有专门的OpenStack摆设服务节点、控制节点、计算节点、网络节点和存储服务节点等。
  
• 生产情况的控制节点建议三台以上，其他节点按需求摆设。
  
• 假如只是测试，OpenStack服务可以摆设在单节点上。
  

OpenStack焦点服务说明

通用组件

• Message Queue
  
  
  
  
  
  
  • 消息队列，OpenStack利用 Rabbit MQ
    
  • OpenStack各服务内部组件协作的方式
    
  
  
• Database
  
  
  
  
  
  
  • 数据库， OpenStack利用Mariadb
    
  • OpenStack中大部分服务都有本身DB
    
  
  

认证服务Keystone

Keystone：焦点概念

• 焦点概念（Keystone V3）
  
  
  
  • 用户相干
    
  • domain（域）：是项目和用户的容器，用于为管理身份入口定义管理边界
    
  • project（项目）：一个用于分组或隔离资源的容器，资源的所有权是属于项目的，用户只有加入项目后才气访 问该项目的资源，每个项目可设置Quota
    
  • user（用户）：任何利用OpenStack服务的实体，OpenStack 为 nova、cinder、neutron 等服务创建了相应 的 user
    
  • group（用户组）：用户的集合，可以对group赋予角色，group中的用户都拥有该角色对应的权限
    
  • role（角色）：权限的集合，各服务通过本身的policy.json文件定义各角色的权限，默认只有admin和非admin 两种角色。keystone通过role进行鉴权
    
  • token（令牌）：由数字和字母组成的字符串，是credentials的一种，用户认证成功后keystone天生token分 配给用户，用作访问服务的credential。有效期默认24小时，UUID/PKI/PKIZ/Fernet多种情势的token
    
  • 服务相干
    
    
    
    • service（服务）：OpenStack 服务，如nova、neutron等，每个服务提供一个或者多个 endpoint 供用户访问 资源以及进行操作
      
    • endpoint（端点）：endpoint是一个网络上可访问的地址，通常是URL。service 通过 endpoint 暴露本身的API，每个Service有public、internal、admin三个endpoint，keystone 负责管理和维护每个 Service 的 Endpoint
      
    
    
  
  

用户相干说明

• 用户相干
  
  
  
  • domain（域）
    
  • project（项目）
    
  • user（用户）
    
  • group（用户组）
    
  • role（角色）
    
  • token（令牌）
    
  
  
• 一个Region中可以包罗多个Domain，一个Domain中可以包罗多个Group、user和Project，一个Group中可以包 含多个user。
  
• 通过role可以建立起Group与Project，user与Project之间的联系，即赋予相应的权限。比方：可以通过Group1将
  
• Role 直接赋予Domain1，则Group1中的所有用户都将会对Domain1中的所有Projects拥有admin权限。
  
• 查看用户下令：openstack user list
  
  
  
  
• 查看角色下令：openstack role list
  
  
  
  

服务相干说明

• 服务相干
  
  
  
  • service（服务）
    
  • endpoint（端点）
    
  
  
• 查看服务下令openstack service list
  
  
  
  
• 查看endpoint下令openstack endpoint list
  
  
  
  

举例：user1用户要登录dashboard查看VM列表

• 举例：user1用户要登录dashboard查看VM列表，流程如下
  
  
  
  • user1在horizon登录界面输入用户名和密码（也是credential的一种）
    
  • horizon将用户名和密码发给keystone进行认证
    
  • 用户名密码认证通过后，keystone为user1用户天生token并返回，token中包罗了用户的role信息
    
  • 根据token信息可以知道user1用户可以访问哪些服务、哪些Project，而且在这些Project 中是什么角色
    
  • 根据user1的可访问的服务、Project列表，在Project中的角色，以及角色对应的policy权 限，在界面上显示user1可访问的服务、项目、资源
    
  • 当user1点击Instance时，会将哀求发给nova的endpoint，nova根据user1的token进行 鉴权，判定user1在这个项目中有是什么角色、有哪些权限，假如有查看Instance的权限，
    
  • 则将Instance列表返回给user1，user1通过界面查看到VM列表信息
    
  
  

镜像服务Glance

组件和架构

• 组件和架构
  
  
  
  • glance-api：对外提供 REST API，相应 image 查询、获取和存储的调用。glance-api 不真正处理哀求， 假如操作是与 image metadata（元数据）相干，glance-api 会把哀求转发给 glance-registry； 假如操 作是与 image 自身存取相干，glance-api 会把哀求转发给该 image 的 store backend。
    
  • glance-registry：负责处理和存取 image 的 metadata，如 image 的大小和类型。
    
  • database：利用Mariadb，glance有本身的database
    
  • store backend：glance 本身并不存储 image，真正的 image 存放在 backend 中，glance 支持多种backend，可在配置文件glance-api.conf中定义
    
  
  

重要概念

• image：由glance管理的镜像文件，存放在glance的backend中，是instance运行的模板
  
• 虚拟机镜像文件：虚拟机instance启动盘所对应的文件（一样平常instance目录下disk文件）*
  
  
  
  • 创建虚拟机时，nova将image下载到本地作为虚拟机disk文件的backing file（仅第一次下载），下载的image存放 在path_to_nova/instances/_base目录下，nova.conf中可配置instance_path/image_cache_subdirectory_name
    
  • 创建虚拟机后，每个虚拟机会基于image拷贝出本身的disk镜像文件
    
  • 假如是利用Ceph作为nova、glance后端，则无需下载image和拷贝出disk镜像文件，而是在Ceph内部实现COW
    
    
    
    
    
    
    
  
  
• 查看镜像下令penstack image list
  
  
  
  
• 镜像格式和dashboard创建说明
  
  
  
  

计算范围Nova

组件和架构

• 组件和架构
  
  
  
  • nova-api：担当并相应用户对计算服务的API哀求，是Nova 服务对 外的唯一接口，会周期性访问数据库更新虚拟机信息。
    
  • nova-conductor：nova-compute 访问数据库的全部操作都由 nova-conductor完成（获取和更新数据库中instance的信息），避 免nova-compute 直接访问数据库，增加体系的安全性和伸缩性
    
  • nova-scheduler：负责nova的调治服务，创建虚拟机时决定虚拟机 在哪个nova-compute计算节点上启动
    
  • nova-compute：处理虚拟机相干的操作，利用driver架构，支持多 种虚拟化技术
    
  • nova-consoleauth：为vnc代理服务器提供token验证服务
    
  • nova-novncproxy：为浏览器和vncserver之间建立socket，console用来毗连到虚机的console接口，实现基于vnc的登录和操作
    
  • nova-cert：对接EC2-API的时候才利用，为euca-bundle-image提 供证书
    
  • database
    
  • message queue
    
  
  
• 查看nova服务列表下令：nova service-list
  
  
  
  

Nova Compute与Hypervisor

• nova通过driver架构支持多种Hypervisor
  
  
  
  
• 在nova.conf中可配置利用的compute_driver类型
  nova-compute定期向OpenStack报告计算节点的状态*，实现instance的生命周期管理
  
  
  
  
• 通过nova-compute和Hypervisor一起可实现对虚拟机的生命周期管理
  主要操作
  
  
  
  • launch/terminate：创建虚拟机、停止虚拟机（停止即删除*）
    
  • start/shutoff/reboot：虚拟机的开机、关机、重启操作，硬重启可以是soft/hard reboot
    
  • snapshot：创建快照，对虚拟机的disk镜像文件（不含云硬盘）进行全量备份，天生一个类型为snapshot的image生存在glance中，快照规复相当于通过snapshot image创建虚拟机
    
  • pause/resume：停息虚拟机，将虚拟机状态生存到宿主机内存中，resume的时候再从内存中读回 虚拟机状态继承运行。停息状态（状态为paused）的虚拟机可以毗连到console，但无法登录操作。
    
  • suspend/resume：挂起虚拟机，将虚拟机状态生存到宿主机硬盘中，resume的时候再从宿主机中 读回虚拟机状态继承运行。挂起状态（状态为suspended）的虚拟机无法毗连到console。
    
  • shelf/unshelf：为虚拟机创建一个快照并将快照的image文件生存在glance中，虚拟机状态变为 Shelved Offloaded，电源状态为shut down。unshelve相当于通过快照规复虚拟机。
    
  • lock/unlock：对被加锁的 instance 实行重启等改变状态的操作会提示操作不答应, 实行解锁操作后 规复正常。admin 角色的用户不受 lock 的影响，无论加锁与否都可以正常实行操作。
    
  • migrate/live migrate /evacuate：迁移操作只能在管理界面进行，在线迁移时不中断虚拟机运行。
    
  • resize：变更虚拟机配置，默认会关闭再启动虚拟机
    
  • rebuild：选择一个image镜像重修虚拟机，可用于虚拟机的规复
    
  • 其他操作：绑定/解绑定Floating IP、增加/删除虚拟网卡、编辑虚拟机信息、编辑安全组、console登录、查看日志等
    
  
  

Nova Conductor和Nova Scheduler

• Nova Conductor
  
  
  
  
• Nova Scheduler
  
  
  
  • Nova中的调治服务
    
  • 决定如何安排新创建的虚拟机（VM Placement）
    
    
    
    • 创建虚机的时候进行调治
      
    • 差别于DRS
      
    
    
  • 创建 Instance 时，用户会提出资源需求，比方 CPU、内存、磁盘各需要多少。OpenStack 将 这些需求定义在 flavor 中，用户只需要指定用哪个 flavor 就可以了。
    
  • Flavor 主要定义了 vCPU，RAM，Disk和 Metadata 这四类。 nova-scheduler 会按照 flavor 去选择合适的计算节点。
    
  • Filter scheduler 是 nova-scheduler 默认的调治器
    
    
    
    
  
  

Nova Scheduler：Filter Scheduler

• Filter Scheduler调治过程分为两步：
  
  
  
  • 通过过滤器（filter）选择满足条件的计算节点（运行 nova-compute）
    
  • 通过权重计算（weighting）选择在最优（权重值最大）的计算节点上创建 Instance
    
    
    
    
  
  

Nova Scheduler：Filter

• nova.conf 中的 scheduler_available_filters 选项用于配置 scheduler 可用的
  filter，默认是所有 nova 自带的 filter 都可以用于滤操作。
  
  
  
  
• nova.conf 中的 scheduler_default_filters 选项用于指定 scheduler 真正使 用的 filter
  
  
  
  
  
  
  • RetryFilter：过滤掉之前已经调治过的节点
    
  • AvailabilityZoneFilter：根据用户的选择，调治到所选的AZ中
    
  • RamFilter：将不能满足所选Flavor内存需求的计算节点过滤掉*
    
  • DiskFilter：将不能满足Flavor磁盘需求的计算节点过滤掉
    
  • ComputeFilter：只有nova-compute服务正常工作的计算节点才气©被2016调Unite度dStack Inc. All Ri
    
  
  

Nova Scheduler：weight

• 经过Filter 的过滤，nova-scheduler 选出了可以或许摆设 instance 的计算节点
  
• 最终选择哪个节点由 weight 来决定
  
  
  
  

Nova：相干概念

• Region：针对endpoint的最大概念，endpoint在一个region中是唯一的，region之间完全隔离，有本身 的计算/网络/存储资源，但可以共享Keystone和Horizon
  
• Availability zone：region内的再次划分，可以理解为一个故障域，AZ对用户可见，创建云主机时可选择 可用域
  
• Host aggregate：根据某一属性对硬件的划分，HA只对管理员可见，scheduler可根据参数实现到指定Host aggregate的调治
  
• Cell：用于大规模摆设时加强nova的横向扩展本领，每个cell有单独的MQ和DB
  

Nova：Availability Zone与Host Aggregate

Nova：Cell

• 什么是Cell
  
  
  
  • G版本引入的nova新内容
    
  • 加强横向扩展
    
  
  
• 如何工作
  
  
  
  • 每个Cell有单独的MQ与DB
    
  • 包罗nova-api外的所有nova进程
    
  
  
• 如何理解
  
  
  
  • Nova-cell类比nova-scheduler
    
  • 每个cell就是一个nova-compute
    
  
  
• 留意
  
  
  
  • Cell只针对Nova
    
  
  
• 用途
  
  
  
  • 进步集群扩展性
    
  • 在差别的cell之间进行信息同步和虚机调治
    
  • 一个region可以划分多个cell
    
  • 每个cell有单独的数据库和消息队列
    
  • 大规模集群解决方案
    
  
  

块存储Cinder

Openstack中的存储概念

• 存储概念
  
  
  
  • 临时块存储
    
    
    
    • 与虚拟机生命周期雷同
      
    • 作为虚机的本地文件体系
      
    • 虚机的操作体系盘
      
    • Nova管理
      
    
    
  • 持久块存储
    
    
    
    • 用户管理生命周期
      
    • 虚机外挂磁盘
      
    • 也可以作为虚机的体系盘
      
    
    
  • 对象存储
    
    
    
    • 用户管理生命周期
      
    • 单独访问接口
      
    • 生存文件
      
    
    
  
  

Cinder说明

• 块存储
  
• 卷（volume）
  
  
  
  • 可读写
    
  • 体系/扩展盘
    
  • 只能挂载到一个虚机
    
  • 状态与虚机无关
    
  
  
• 快照（snapshot）
  
  
  
  • 只读
    
  • 某个卷的某一时间点复制
    
  • 可以用来天生一个卷
    
  
  
• 备份（backup）
  
  
  
  • 卷的归档
    
  
  

架构与组件

• Cinder架构
  
  
  
  
• Cinder组件
  
  
  
  • cinder-api：担当api哀求，调用cinder-volume
    
  • cinder-scheduler：通过调治算法选择最合适的cinder-volume去创建volume
    
  • cinder-volume：管理volume的服务和volume的生命周期。与后端存储协调 工作，通过driver架构支持多种backend storage作为volume provider
    
  • cinder-backup：提供volume的备份服务。与后端现实提供备份空间的存储协 调工作，支持多种backup backend storage作为备份后端
    
  • backend storage：现实提供存储空间的存储设备/体系
    
  • backup storage backend：现实提供备份存储空间的存储设备/体系
    
  • database
    
  • message queue
    
  
  

Cinder scheduler：Filter

• Cinder中的调治服务
  
• 决定如何安排新创建的 volume
  
• 创建 volume 时，用户会提出资源需求，如存储容量、存储类型等， cinder scheduler 会按照 这些资源需求去选择合适的 cinder-volume。
  
• Filter scheduler 是 cinder-scheduler 默认的调治器
  
  
  
  
• Filter Scheduler调治过程分为两步：
  
  
  
  • 1.通过过滤器（filter）选择满足条件的 cinder-volume
    
  • 2.通过权重计算（weighting）选择通过最优（权重值最大）的 cinder-volume 创建 volume
    
  
  
• AvailabilityZoneFilter：根据用户的选择，调治到所选的AZ中
  
• CapacityFilter：将存储空间不满足 volume 创建需求的存储后端对应的 cinder-volume 过滤掉
  
• CapabilityFilter：差别的存储后端可以有差别的volume type，创建 volume 时可通过 volume type指定需要的Capability，通过filter过滤掉不满足 type 的 cinder-volume
  

对象存储服务Swift

Cinder scheduler：weight

• 经过Filter 的过滤，cinder-scheduler 选出了可以或许创建 volume 的 cinder- volume
  
• 最终选择哪个节点由 weight 来决定
  
• 默认的 weigher 是 CapacityWeigher，即基于容量来计算权重值
  

Cinder volume与后端存储

• cinder通过driver架构支持多种backend storage
  
  
  
  
• 在 cinder.conf 中可以配置利用的 driver 类型
  
  
  
  

Cinder volume与后端存储

• cinder-volume 为 volume provider 定义了统一的 driver 接口，volume provider 只需要实 现这些接口，就可以 driver 的情势即插即用到 OpenStack 中。在 marketplace 的 driver 列 表中可以查询到各厂商的 driver 信息。
  
• 官网地址：http://www.openstack.org/marketplace/drivers/
  
  
  
  

Cinder volume与后端存储

• 通过 cinder-volume 和 后端存储 一起可实现对 存储卷 的生命周期管理
  主要操作
  
  
  
  • Create volume：创建存储卷，可以创建空白卷或从镜像创建卷
    
  • Delete volume：删除存储卷，存储卷的生命周期不依靠于虚拟机
    
  • Attach volume：存储卷挂载到虚拟机，初次挂载后需要分区和格式
    
  • Detach volume：存储卷从虚拟机解挂载
    
  • Extend volume：存储卷扩容
    
  • Snapshot volume：存储卷做快照
    
  • Boot from volume：从存储卷启动虚拟机（虚拟机操作体系放在存储卷上）
    
  
  

Cinder 与 Nova 的配合

• 两个层面
  
  
  
  • 控制层面
    
  • 数据层面
    
  
  
• 控制和数据的分离，数据不用经过 cinder-volume
  

Cinder：Cinder backup

• 存储卷的备份
  
• 支持多种存储后端，可以在 cinder.conf 文件中配置
  
  
  
  • NFS
    
  • Ceph
    
  • Tivoli Storage Manager
    
  • Swift
    
  • GlusterFS
    
  
  

网络服务Neutron

Neutron：焦点概念

• Neutron 为整个 OpenStack 情况提供网络支持，包括二层交换，三层路由，负载均衡，安全组，防火墙 等。
  Neutron 提供了一个灵活的框架，无论是开源照旧贸易软件，都可以通过配置被用来实现这些功能。
  
• 二层交换（Switching）
  
  
  
  • Nova 的 instance 通过虚拟交换机毗连到虚拟二层网络
    
  • Neutron 支持多种虚拟交换机，包括 Linux 原生的 Linux Bridge 和 Open vSwitch
    
  • 支持 VLAN 网络和 VxLAN 网络
    
  
  
• 三层路由（Routing）
  
  
  
  • Instance 可以配置差别网段的 IP，Neutron 的 vRouter 实现 instance 跨网段通讯
    
  • vRouter 通过 IP forwarding，iptables 等技术来实现路由和 NAT
    
  
  
• 负载均衡（Load Balancing）
  
  
  
  • 负载均衡服务（LBaaS），提供将负载分发到多个 instance 的本领
    
  • LBaaS 支持多种负载均衡产品和方案，差别的实现以 Plugin 的情势集成到 Neutron，如今默认的 Plugin 是 HAProxy
    
  
  
• 安全组（Security Group）
  
  
  
  • 通过 iptables 限制收支 instance 的网络包
    
  
  
• 防火墙（Firewalling）
  
  
  
  • FWaaS，限制收支虚拟路由器的网络包，通过 iptables 实现或者 Plugin 的情势集成到Neutron
    
  
  
• Network（网络）
  一个隔离的二层广播域。Neutron 支持多种类型的 network，包括 local, flat, VLAN, VxLAN 和 GRE
  
  
  
  
• Subnet（子网）
  
  
  
  • 一个 IPv4 或者 IPv6 地址段，instance 的 IP 从 subnet 中分配。每个 subnet 需要定义 IP 地址的范围 和掩码
    
  • subnet 与 network 是 多对1 关系。同一个network 下的subnet 可以是差别的 IP 段，但不能重叠。差别 network下的subnet 的IP是可以重叠的
    
    
    
    
  
  
• Port（端口）
  
  
  
  • port 可以看做虚拟交换机上的一个端口。port 上定义 了 MAC 地址和 IP 地址，当 instance 的虚拟网卡 VIF
    
  • （Virtual Interface） 绑定到 port 时，port 会将 MAC 和 IP 分配给 VIF
    Port属于某个subnet，与subnet是多对1关系。
    
    
    
    
  
  

Neutron：组件和架构

• 组件和架构
  
  
  
  • neutron server：担当api哀求，调用 plugin处理哀求
    
  • neutron plugin：处理 neutron server 发来的哀求，维护网络逻辑状态，并调用 agent 处理哀求（core plugin， service plugin）
    
  • neutron agent：处理 plugin 的哀求，负责在 network provider 上真正实现各种网络功能（L2 agent, L3 agent, DHCP agent）
    
  • network provider：现实提供网络服务的虚拟或物理网络 设备，如Linux Bridge、Open vSwitch或者网络厂商的设 备
    
  • database
    
  • message queue
    
  
  
• 查看neutron下令neutron agent-list
  
  
  
  

Neutron：plugin

• plugin 按照功能分为两类： core plugin 和 service plugin。core plugin 维护 Neutron 的 netowork, subnet 和 port 相干资源的信息，与 core plugin 对应的 agent 包括 linux bridge, Open
  vSwitch 等； service plugin 提供 routing, firewall, load balance 等服务，也有相应的 agent。
  
  
  
  
• plugin 的一个主要工作是在数据库中维护 Neutron 网络的状态信息，以前的 core-plugin 架构带来一个题目，所有 network provider 的 plugin 都要编写一套类似的数据库访问代码，绝大部代码是重复的。而且无法同时利用多种 network provider
  
• Neutron 在 Havana 版本实现了一个 ML2（Modular Layer 2）plugin，对 plugin 的功能进行抽象和封装，各种 network provider 无需开辟本身的 plugin，只需要针对 ML2 开辟相应的 driver 就可以了。ML2实现二层网络拓扑与底层实现的解耦
  

Neutron：plugin 和 agent

• neutron.conf
  
  
  
  
• ml2_conf.ini
  
  
  
  
• L2 agent
  
  
  
  • Linux bridge
    
  • Open vSwitch
    
  • ……
    
  
  
• L3 agent
  
  
  
  • Router
    
  
  
• DHCP agent
  
• Service agent
  
  
  
  • Load Balance
    
  • Firewall
    
  • VPN
    
  • ……
    
    
    
    
    
    
    
  
  

常见组网：Linux Bridge

Linux Bridge：bridge 和 tap

Router namespace

常见组网：Open vSwitch

Swift：体系架构

• 访问层，负责处理用户的哀求和用户身份的认证
  
  
  
  • Proxy server：对外提供对象服务RestFul API，可横向扩展，一方面 转发认证服务器进行用户信息认证，一方面将哀求转发至相应的账户、 容器或者对象服务；
    
  • Authentication Server：验证访问用户的身份信息，并获得一个对 象访问令牌（Token），在一定的时间内会不停有效
    
  
  
• 存储层，负责对象数据的现实存储
  
  
  
  • 存储层的物理层次划分：region、zone、storage node、device、 partition
    
  • 每个storage node上存储对象的逻辑层次划分：account、container、object
    
  • 每个逻辑层次对应运行在storage node上的一种服务：account server、container server、 object server
    
  
  
• Swift通过 Ring 来实现对象与真正的物理存储位置的映射
  
• Swift通过 Updater、Replicator、Auditor 这三种服务来保 证数据一致性
  
• 每个对象有一定命量的副本（replica，默认为3个），每个副 本存放在差别的zone中，对象的副本是通过partition的副本实现的，即，Swift管理副本的粒度是partition而非单个对象
  
• 存储层的物理层次划分：
  
  
  
  • Region：地理上相互隔离的区域
    
  • Zone：region内部，硬件上的隔离，一个zone可以映射为一个硬盘、一台主机或一个机柜。通常可理解为一个zone 代表一组独立的相互隔离的storage node
    
  • Storage node：存储对象数据的物理节点
    
  • Device：可理解为存储节点上的磁盘
    
  • Partition：device上的文件体系中的目录
    
  
  
• 存储对象的逻辑层次划分：
  
  
  
  • Account：和个人账户不是一个概念，可理解为租户，用来做顶层的隔离机制，可以被多个个人账户所共同利用
    
  • Container：代表封装一组对象，类似文件夹或目录，container是扁平的，不能嵌套
    
    
    
    
  • Object：对象是叶节点，由元数据和内容两部分组成（对象可以有虚拟的文件层级pseudo-folder）
    
  
  
• Proxy Server 运行在 Proxy Node上，接收用户HTTP哀求
  
• 哀求路由到相应的Controller：AccountController、ContainerController、ObjectController
  
• Controller从对应的 Ring 文件中获取哀求数据所在的存储 节点Storage node，然后再将哀求转发给该节点上的相应Server：AccountServer、ContainerServer、ObjectServer，最终进行具体的操作
  
  
  
  • Object server：提供对象元数据和内容服务，每个对象的内容会 以文件的情势存储在文件体系中，元数据会作为文件属性来存储，需要采用支持扩展属性的文件体系（如XFS）
    
  • Container server：提供容器元数据和统计信息，并维护所含对 象列表的服务，每个容器的信息也存储在一个 SQLite 数据库中
    
  • Account server：提供账户元数据和统计信息，并维护所含容器
    列表的服务，每个账户的信息被存储在一个 SQLite 数据库中
    
  
  

Swift：Ring

• Ring：Swift 通过 Ring 来实现物理节点的管理，包括记录对象与物理存储位置间的映射， 物理节点的添加和删除等。
  
  
  
  
• Ring的数据布局，包括是三种重要信息：
  
  
  
  • 设备表：对所有 device 编号，设备表中每一项对应一个device，记录device的各种信息
    
  • 设备查询表：存储 Partition 的各个副本与具体 device 的映射信息
    
  • Partition移位值：表如今哈希之后将Object名字二进制移位的位数
    
    
    
    
  
  
• 存储对象与物理位置间的映射：
  
  
  
  • 映射分为两层，1） 对象到Partition； 2）Partition到存储节点（device）
    
  • 1）对象到Partition：通过哈希函数和二进制位移操作计算对象到虚拟空间Partition的映射（可将 对象均匀分布到虚拟空间的Partition上）
    
  • 2） Partition到存储节点：通过设备查询表完成
    
    
    
    
  
  
• 物理节点的添加和删除：
  添加或者删除物理节点（device）后，需要实行 swift-ring-builder 的 rebalance 下令重新平衡数 据。Ring rebalance 过程是天生了差别的 Ring 文件，更新了设备表和设备查询表，更新
  Partition 和 device 之间的映射关系。最终 Partition 的移动是由 Replicator 来现实完成。
  

Swift：数据一致性

• 分布式体系CAP（Consistency，Availability，Partition Tolerance）理论，无法同时满足 3 个方面，Swift 放弃严酷一致性而采用最终一致性模子（Eventual Consistency），来达 到高可用性和无穷水平扩展本领。
  
• N：数据的副本总数；W：写操作被确认担当的副本数量；R：读操作的副本数量
  
• Swift 采用比较折中的战略，写操作需要满足至少一半以上成功 W >N/2，再保证读操作与 写操作的副本集合至少产生一个交集，即 R+W>N。
  
• Swift 默认配置是 N=3，W=2>N/2，R=1 或 2
  
  
  
  • N=3 每个对象会存在 3 个副本，这些副本会尽量被存储在差别区域的节点上
    
  • W=2 表现至少需要更新 2 个副本才算写成功
    
  • 当 R=1 时意味着某一个读操作成功便立刻返回，此种情况下大概会读取到旧版本；当 R=2 时，需 要通过在读操作哀求头中增加 x-newest=true 参数来同时读取 2 个副本的元数据信息，然后比较 时间戳来确定哪个是最新版本；假如数据出现了不一致，后台服务进程会在一定时间窗口内通过检 测和复制协议来完成数据同步，从而保证达到最终一致性。
    
  
  
• Swift通过三种服务来保证数据一致性：
  
  
  
  • Auditor：检查 object，container 和 account 的完备性，假如发现比特级的错误，文件将 被隔离，并复制其他的副本以覆盖本地损坏的副本（现实的复制工作由replicator完成）； 其他类型的错误会被记录到日志中
    
  • Updater：当 object 或 container 由于高负载的缘故起因而无法立即更新时，任务将会被序列 化到在本地文件体系中进行列队，以便服务规复后进行异步更新
    
  • Replicator：检测本地节点的分区副本和长途副本是否一致，发现不一致时会将过时副本更 新为最新版本；另外一个任务是负责并将被标记为删除的数据真正从物理介质上删除。
    
  
  

Swift：扩展

• Restful API：GET/PUT/POST/DELETE/HEAD
  
  
  
  
• Storage polices：
  
  
  
  • 默认是replication副本的方式，可以采用Erasure Coding纠删码的方式。每个 container可以关联一个storage policy并应用到container中的所有object
    
  • Storage policy和object ring之间通过storage policy的索引号来一一映射
    
    
    
    
  
  

编排服务Heat

简介

• 什么Heat
  
  
  
  • 
    
    • Heat 是一套业务流程平台，旨在资助用户更轻松地配置以 OpenStack 为基础的云体系。利用Heat应用步伐，开辟职员可以或许在步伐中利用模板以实现资源的自动化摆设。Heat可以或许启动应用、创建虚拟机并自动处理整个流程。它还拥有精彩的跨平台兼容性，可以或许与 Amazon Web Services 业务流程平台 CloudFormation 相对接——这意味着用户完全可以将 AWS 模板引入 OpenStack 情况当中。
      
    
    
  • 
    
    • Heat 是 OpenStack 提供的自动编排功能的组件，基于形貌性的模板，来编排复合云应用步伐。
      
    
    
  
  
• 为什么需要Heat
  
  
  
  • 
    
    • 更快更有效的管理 OpenStack 的资源：云平台体系在相对比较稳固的情况下，管理成本渐渐酿成主要的解决题目。云上自动化本领是一个云平台的刚需，可以有效降低维护难度。Heat 采用了模板方式来筹划或者定义编排，为方便用户利用，Heat 还提供了大量的模板例子，利用户可以或许方便地得到想要的编排。
      
    
    
  • 
    
    • 更小的研发成本：引入 Heat，对于不相识 OpenStack 的研发者来说，可以更快的接入现有的业务体系。开辟者更关心的是授权认证和对虚拟资源的增编削，而对于底层的状态并不用太多相识。
      
    
    
  
  
• 概念
  
  
  
  • 
    
    • 堆栈（stack）：管理资源的集合。单个模板中定义的实例化资源的集合，是 Heat 管理应用步伐的逻辑单位，往往对应一个应用步伐。
      
    
    
  • 
    
    • 模板（template）：如何利用代码定义和形貌堆栈。形貌了所有组件资源以及组件资源之间的关系，是 Heat 的焦点。
      
    
    
  • 
    
    • 资源（resource）：将在编排期间创建或修改的对象。资源可以是网络、路由器、子网、实例、卷、浮动IP、安全组等。
      
    
    
  • 
    
    • 参数（parameters）：heat模板中的顶级key，定义在创建或更新 stack 时可以传递哪些数据来定制模板。
      
    
    
  • 
    
    • 参数组（parameter_groups）：用于指定如何对输入参数进行分组，以及提供参数的序次。
      
    
    
  • 
    
    • 输出（outputs）：heat模板中的顶级key，定义实例化后 stack 将返回的数据。
      
    
    
  
  

架构

• 焦点架构
  
  
  
  
  
  
  • 
    
    • heat command-line client：CLI通过与 heat-api 通讯，来调用 API 实现相干功能。终端开辟者可以直接利用编排 REST API。
      
    
    
  • 
    
    • heat-api：实现 OpenStack 原生支持的 REST API。该组件通过把 API 哀求经由 AMQP 传送给 Heat engine 来处理 API 哀求。
      
    
    
  • 
    
    • heat-api-cfn：提供与 AWS CloudFormation 兼容的、AWS 风格的查询 API，处理哀求并通过 AMQP 将它们发送到 heat-engine。
      
    
    
  • 
    
    • heat-engine：实行模板内容，最终完成应用体系的创建和摆设，并把实行结果返回给 API 调用者。
      
    
    
  • 
    
    • heat-cfntools：完成虚拟机实例内部的操作配置任务，需要单独下载。
      
    
    
  
  

工作流程

• 
  
  • 用户在 Horizon 中或者下令行中提交包罗模板和参数输入的哀求
    
  
  
• 
  
  • Horizon 或者下令行工具会将接收到的哀求转化为 REST 格式的 API 调用 Heat-api 或者是 Heat-api-cfn。
    
  
  
• 
  
  • Heat-api 和 Heat-api-cfn 会验证模板的精确性，然后通过 AMQP 异步传递给 Heat Engine 来处理哀求。
    
  
  
• 
  
  • Heat Engine 接收到哀求后，会把哀求解析为各种类型的资源，每种资源都对应 OpenStack 别的的服务客户端，然后通过发送 REST 的哀求给别的服务。
    
  
  
• 
  
  • Heat Engine 在这里的作用分为三层： 第一层处理 Heat 层面的哀求，就是根据模板和输入参数来创建 Stack，这里的 Stack 是由各种资源组合而成。 第二层解析 Stack 里各种资源的依靠关系，Stack 和嵌套 Stack 的关系。第三层就是根据解析出来的关系，依次调用各种服务客户段来创建各种资源。
    
  
  

模板

• 概念：Heat 模板全称为heat orchestration template，简称为HOT。
  
• 模板详解
  1.典范 Heat 模板布局
  

1. heat_template_version: --             ### HOT版本
2. description:                                  ### 说明
3.    # a description of the template
5. parameter_groups:                             ### 指定参数顺序
6. - label: <human-readable label of parameter group>
7.    description: <description of the parameter group>
8.    parameters:
9.    - <param name>
10.    - <param name>
12. parameters:                                   ### 传递的参数
13.    <param name>:                               ### 参数名
14.      type: <string | number | json | comma_delimited_list | boolean>  ### 参数类型
15.      label: <human-readable name of the parameter>  ### 标签
16.      description: <description of the parameter>
17.      default: <default value for parameter>
18.      hidden: <true | false>                    ### 是否隐藏
19.      constraints:                              ### 已有的内置参数：OS::stack_name、OS::stack_id、OS::project_id
20.        <parameter constraints>
21.      immutable: <true | false>
23. resources:                                  ### 资源对象
24.    <resource ID>:                            ### 资源的ID
25.      type: <resource type>                   ### 资源的类型
26.      properties:                             ### 资源的属性
27.        <property name>: <property value>
28.      metadata:                               ### 资源的元数据
29.        <resource specific metadata>
30.      depends_on: <resource ID or list of ID>
31.      update_policy: <update policy>
32.      deletion_policy: <deletion policy>
34. outputs:                                    ### 返回值
35.    <parameter name>:                         ### 参数名
36.      description: <description>              ### 说明
37.      value: <parameter value>                ### 输出值

复制代码

例子

1. heat_temp_version：--
2. Description: AWS::CloudWatch::Alarm using Ceilometer.
3. parameters:
4.    user_name:
5.      type: string
6.      label: User Name
7.      description: User name to be configured for the application
8.    port_number:
9.      type: number
10.      label: Port Number
11.      description: Port number to be configured for the web server
13. resources:
14.    my_instance:
15.      type: OS::Nova::Server
16.      properties:
17.        flavor: m1.small
18.        image: F18-x86_64-cfntools
20. outputs:
21.    instance_ip:
22.      description: IP address of the deployed compute instance
23.      value: { get_attr: [my_instance, first_address] }

复制代码

模板内部函数

• 
  
  • get_attr：获取所创建资源的属性
    
  
  

1. 语法
2. get_attr:
3.    - <resource name>   ### 必须是模板 resouce 段中指定的资源。
4.    - <attribute name>  ### 要获取的属性，如果属性对应的值是list 或map， 则可以指定key/index来获取具体的值。
5.    - <key/index > (optional)
6.    - <key/index > (optional)
7.    - ...
9. 示例
10. resources:
11.    my_instance:
12.      type: OS::Nova::Server
13. # ...
15. outputs:
16.    instance_ip:
17.      description: IP address of the deployed compute instance
18.      value: { get_attr: [my_instance, first_address] }
19.    instance_private_ip:
20.      description: Private IP address of the deployed compute instance
21.      value: { get_attr: [my_instance, networks, private, ] }

复制代码

• 
  
  • get_file：获取文件的内容
    
  
  

1. 语法
2. get_file: <content key>
4. 示例
5. resources:
6.    my_instance:
7.      type: OS::Nova::Server
8.      properties:
9.        # general properties ...
10.        user_data:
11.          get_file: my_instance_user_data.sh
12.    my_other_instance:
13.      type: OS::Nova::Server
14.      properties:
15.        # general properties ...
16.        user_data:
17.          get_file: http://example.com/my_other_instance_user_data.sh

复制代码

• 
  
  • get_param：引用模板中指定的参数
    
  
  

1. 语法
2. get_param:
3.   - <parameter name>
4.   - <key/index 1> (optional)
5.   - <key/index 2> (optional)
6.   - ...
8. 示例
9. parameters:
10.     instance_type:
11.      type: string
12.      label: Instance Type
13.      description: Instance type to be used.
14.    server_data:
15.      type: json
17. resources:
18.    my_instance:
19.      type: OS::Nova::Server
20.      properties:
21.        flavor: { get_param: instance_type}
22.        metadata: { get_param: [ server_data, metadata ] }
23.        key_name: { get_param: [ server_data, keys, 0 ] }
24. 输出
26.    {"instance_type": "m1.tiny",
27.    {"server_data": {"metadata": {"foo": "bar"},"keys": ["a_key","other_key"]}}}

复制代码

• 
  
  • get_resource：获取模板中指定的资源
    
  
  

1. 语法
2. get_resource: <resource ID>
4. 示例
5. resources:
6.    instance_port:
7.      type: OS::Neutron::Port
8.      properties: ...
10.    instance:
11.      type: OS::Nova::Server
12.      properties:
13.        ...
14.        networks:
15.          port: { get_resource: instance_port }

复制代码

• 
  
  • list_join：利用指定的分隔符将一个list中的字符串合成一个字符串
    
  
  

1. 语法
2. list_join:
3. - <delimiter>
4. - <list to join>
6. 示例输出：one，two，three
7. list_join: [', ', ['one', 'two', 'and three']]

复制代码

• 
  
  • digest：在指定的值上利用algorithm
    
  
  

1. 语法
2. digest:
3.    - <algorithm>  ### 可用的值是hashlib(md5, sha1, sha224, sha256, sha384, and sha512) 或openssl的相关值
4.    - <value>
6. 示例
7. # from a user supplied parameter
8. pwd_hash: { digest: ['sha512', { get_param: raw_password }] }

复制代码

• 
  
  • repeat：迭代fore_each中的列表，按照template的格式天生一个list
    
  
  

1. 语法
2. repeat:
3.    template:
4.      <template>
5.    for_each:
6.      <var>: <list>
8. 示例
9. parameters:
10.    ports:
11.      type: comma_delimited_list
12.      label: ports
13.      default: "80,443,8080"
14.    protocols:
15.      type: comma_delimited_list
16.      label: protocols
17.      default: "tcp,udp"
19. resources:
20.    security_group:
21.      type: OS::Neutron::SecurityGroup
22.      properties:
23.        name: web_server_security_group
24.        rules:
25.          repeat:
26.            for_each:
27.              <%port%>: { get_param: ports }
28.              <%protocol%>: { get_param: protocols }
29.            template:
30.              protocol: <%protocol%>
31.              port_range_min: <%port%>
33. 结果
34. [{‘protocal’:tpc, ‘prot_range_min’:},
36. {‘protocal’:tpc, ‘prot_range_min’:},
38. {‘protocal’:tpc, ‘prot_range_min’:},
40. {‘protocal’:udp, ‘prot_range_min’:},
42. {‘protocal’:udp, ‘prot_range_min’:},
44. {‘protocal’:udp, ‘prot_range_min’:}]

复制代码

• 
  
  • str_replace：利用params中的值更换template中的占位符，从而构造一个新的字符串
    
  
  

1. 语法
2. str_replace:
3.    template: <template string>
4.    params: <parameter mappings>
6. 示例
7. resources:
8.    my_instance:
9.      type: OS::Nova::Server
10.      # general metadata and properties ...
12. outputs:
13.    Login_URL:
14.      description: The URL to log into the deployed application
15.      value:
16.        str_replace:
17.          template: http://host/MyApplication
18.          params:
19.            host: { get_attr: [ my_instance, first_address ] }

复制代码

• 
  
  • str_split：将一个字符串按照分隔符分隔成一个list
    
  
  

1. 语法
2. str_split:
3.    - ','
4.    - string,to,split
6. 示例
7. str_split: [',', 'string,to,split']
9. 结果
10. ['string', 'to', 'split']

复制代码

常用操作

• 一、栈、资源、模板管理
  
  
  
  
• 二、软件、快照管理
  
  
  
  

计量服务 Ceilometer

简介

配景

• 为什么要有Ceilometer
  
  
  
  • 
    
    • 通常云的计算层次
      
         
    
    
    
    • 
      
      • 计量 （Metering）： 收集资源的利用数据，其数据信息主要包括：利用对象（what）, 利用者（who）, 利用时间（when）和 用量（how much）。
        
      
      
    • 
      
      • 计费 （Rating）：将资源利用数据按照商务规则转化为可计费项目并计算费用。
        
      
      
    • 
      
      • 结算 （Billing）：收钱开票
        
      
      
    
    
  • 
    
    • Ceilometer 的目的是计量（Metering） 方面，为上层的计费、结算或者监控应用提供统一的资源利用数据收集功能。
      
    
    
  
  
• 历史
  
  
  
  • 
    
    • 项目始于2012年四五月份，10月份发布第一个版本，实现对一些重要数据的计量，包括Compute, Network, Memory, CPU, Image, Volume等，而且提供了REST API。
      
    
    
  • 
    
    • 2013年作为OpenStack发行版的计量计费功能的项目，后来逐步发展增加了部分监控收罗和告警等功能。
      
    
    
  • 
    
    • 但是由于种种缘故起因，Ceilometer项目在Openstack中已经处于一种消灭的状态，基本没有什么新的特性开辟了，原本该项目的PTL也另起炉灶开始在做Gnocchi项目(ceilometer的后端存储体系)。
      
    
    
  • 
    
    • 固然该项目已经没有前几年活跃，但是照旧在许多公有云场景中有比较多的应用，而生产情况中，大概许多公司还用的是M、N版本。
      
    
    
  
  

概念

• 
  
  • Meter
    
     
  
  
  
  • 
    
    • 概念：资源利用的某些测量值(计量项，监控项)，如内存占用、网络IO、磁盘IO等。
      
    
    
  • 
    
    • 属性：名称（name）、单位 （unit）、类型 （cumulative：累计值；delta：变革值；gauge：离散或者颠簸值）以及对应的资源属性等。
      
    
    
  
  
• 
  
  • Sample
    
     
  
  
  
  • 
    
    • 概念：每个收罗时间点上meter对应的值（某时候某个 resource 的某个 meter 的值），收集数据具偶然间隔断。
      
    
    
  • 
    
    • 属性：测量值（meter）、采样时间（timestampe）和采样值（Volume）。
      
    
    
  
  
• 
  
  • Statistics：某个周期内（Period）的Samples聚合值，包括计数（Count）、最大（Max）、最小（Min）、平均 （Avg）、求和（Sum）等
    
  
  
• 
  
  • Resource：被监控的资源对象，如虚拟机、磁盘等
    
    
    
    
  
  
• 
  
  • Alarm
    
     
  
  
  
  • 
    
    • 概念：告警机制，可以通过阈值或者组合条件告警，并设置告警时触发的action，但是相对ceilometer是独立的一块，只是放在了ceilometer的代码树里面。
      
    
    
  • 
    
    • 类型
      
         
    
    
    
    • 
      
      • 阈值告警（Threshold Alarm）：根据一个监控项的阈值去判定Alarm的状态，它包括几个要素：
        
            
      
      
      
      • 
        
        • 一个静态阈值和比较方法 （a static threshold value & comparison operator）
          
        
        
      • 
        
        • 指定的 meter statistic （against which a selected meter statistic is compared）
          
        
        
      • 
        
        • 比较的时间窗 （over an evaluation window of configurable length into the recent past.）
          
        
        
      
      
    • 
      
      • 组合告警（Combination Alarm）：根据多个监控项建立一个Alarm，多个alarm之间是or/and的关系。
        
      
      
    
    
  • 
    
    • 属性
      
         
    
    
    
    • 
      
      • name: 告警名称
        
      
      
    • 
      
      • meter-name：meter 名称
        
      
      
    • 
      
      • threshold: 阈值
        
      
      
    • 
      
      • comparison_operator: 比较方式，有6个可选：lt, le, eq, ne, ge, gt，默认是eq
        
      
      
    • 
      
      • statistic: 比较方式，有5种可选：max, min, avg, sum, count，默认是avg
        
      
      
    • 
      
      • period: 获取该监控指标的监控数据的时间周期
        
      
      
    • 
      
      • evaluation_periods：统计次数
        
      
      
    • 
      
      • alarm-action：告警产生后的动作
        
      
      
    
    
  • 
    
    • Action（动作）
      
         
    
    
    
    • 
      
      • ‘log://’：Alarm 被写入 Log 文件
        
      
      
    • 
      
      • Webhook URL： 这是一个 HTTP(S) endpoint 的URL，比方 ‘http://130.56.250.199:8080/alarm/instances_TOO_MANY’。Alarm 的内容会以 JSON 的格式被 POST 到该URL 中。
        
      
      
    
    
  
  

组件

• 
  
  • 控制节点
    
     
  
  
  
  • 
    
    • Central Agent： 调用OpenStack别的组件api收罗指标
      
    
    
  • 
    
    • Notification Agent：接收别的组件自动上报的关照消息
      
    
    
  • 
    
    • Collector：基于AMQP接收消息，并记录到DataStore
      
    
    
  • 
    
    • API：运行在管理节点，提供接口访问Data Store
      
    
    
  
  
• 
  
  • 计算节点
    
     
  
  
  
  • 
    
    • Compute Agent：收罗本节点性能指标
      
    
    
  
  

数据处理

数据收集

• 
  
  • Poller方式
    
     
  
  
  
  • 
    
    • Compute agent （ceilometer-agent-compute）运行在每个 compute 节点上，以轮询的方式通过调用 Image 的 driver 来获取资源利用统计数据。
      
    
    
  • 
    
    • Central agent （ceilometer-agent-central）运行在 management server 上，以轮询的方式通过调用 OpenStack 各个组件（包括 Nova、Cinder、Glance、Neutron、Swift 等）的 API 收集资源利用统计数据。
      
    
    
  
  
• 
  
  • Notificaiton方式
    
    
    
    
  
  

数据处理

• 
  
  • Pipeline（处理器）
    
    
    
    
     
  
  
  
  • 
    
    • Meters 数据的处理利用 Pipeline 的方式，即Metes 数据依次经过（零个或者多个） Transformer 和 （一个或者多个）Publisher 处理，最后达到（一个或者多个）Receiver。其中Recivers 包括 Ceilometer Collector 和 外部体系。
      
    
    
  • 
    
    • Ceilometer 根据配置文件 /etc/ceilometer/pipeline.yaml 来配置 meters 所利用的 transformers 和 publishers。以 cpu meter 为例：
      
    
    
  
  

1. sources: A source is a producer of samples
2. ......
3.    - name: cpu_source
4.      interval: 600  ## Poller 获取 cpu samples 的间隔为 10 分钟
5.      meters:
6.          - "cpu"
7.      sinks:
8.          - cpu_sink
10. ......
11. sinks: A sink on the other hand is a chain of handlers of samples
12. ......
13.    - name: cpu_sink
14.      transformers:  ## 转换器
15.        - name: "rate_of_change"
16.          parameters:
17.                  target:
18.                      name: "cpu_util"
19.                      unit: "%"
20.                      type: "gauge"
21.                      scale: "100.0 / (10**9 * (resource_metadata.cpu_number or1))"
22.       publishers:  ## 分发器
23.           - notifier://

复制代码

• 
  
  • Transformer （转换器）
    
     
  
  
  
  • 
    
    • unit_conversion：单位转换器，比如温度从°F 转换成°C
      
    
    
  • 
    
    • rate_of_change:：计算方式转换器，比如根据一定的计算规则来转换一个sample
      
    
    
  • 
    
    • accumulator：累计器，如下图所示
      
      
      
      
    
    
  
  
• 
  
  • Publisher（分发器）
    
    
    
    
    
    
    
  
  

数据生存

• 
  
  • Ceilometer Collector 从 AMQP 接收到数据后，会原封不动地通过一个或者多个分发器（dispatchers）将它生存到指定位置。如今它支持的分发器：
    
     
  
  
  
  • 
    
    • 文件分发器：生存到文件 - 添加配置项dispatcher = file 和 [dispatcher_file] 部分的配置项
      
    
    
  • 
    
    • HTTP 分发器：生存到外部的 HTTP target - 添加配置项 dispatcher = http
      
    
    
  • 
    
    • 数据库分发器：生存到数据库 - 添加配置项 dispatcher = database。
      
      
      
      
      
      
      
    
    
  
  
• 
  
  • Ceilometer 支持同时配置多个分发器，将数据生存到多个目的位置。比如在 ceilometer.conf 中做如下配置使得同时利用 file 和 database dispatcher：
    
  
  

1. [DEFAULT]
2. dispatcher = database
3. dispatcher = file
5. [dispatcher_file]
6. backup_count = 5
7. file_path = /var/log/ceilometer/ceilometer-samples
8. max_bytes = 100000

复制代码

数据访问

• 
  
  • 外部体系通过 ceilometer-api 模块提供的 Ceilometer REST API 来访问生存在数据库中的数据。API 有 V1 和 V2 两个版本，如今利用的是 V2.
    
    
    
    
  
  

告警

• 
  
  • 架构
    
     
  
  
  
  • 
    
    • ceilometer-alarm-evaluator 利用 Ceilometer REST API 获取 statistics 数据
      
    
    
  • 
    
    • ceilometer-alarm-evaluator 天生 alarm 数据， 并通过 AMQP 发给 ceilometer-alarm-notifer
      
    
    
  • 
    
    • ceilometer-alarm-notifer 会通过指定方式把 alarm 发出去。
      
      
      
      
    
    
  
  
• 
  
  • Heat 和 Ceilometer 通过 Ceilometer Alarm 进行交互来实现 Instance auto-scaling
    
    
    
    
    
    
    
  
  

架构

焦点架构

京东对 Ceilometer 的优化 （摘自京东架构师在2015年初OpenStack meetup 上的材料）

常用操作

OpenStack创建VM，服务间交互示例

• 提问：创建一个VM需要些什么资源？
  在OpenStack中创建虚拟机实例，资源需求和物理PC类似。
  
• OpenStack创建VM，服务间交互示比方图
  
  
  
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。