OpenStack--T版基础知识(持续更新)!
Posted handsomeboy-东
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了OpenStack--T版基础知识(持续更新)!相关的知识,希望对你有一定的参考价值。
OpenStack
OpenStack
OpenStack概述
它是NASA(美国航空航天局)和Rackspace共同发起以Apache许可证授权的自由软件和开源项目,为公有云及私有云的建设和管理提供软件的开源项目,覆盖了网络、虚拟化、操作系统、服务器等各个方面
云计算服务类型
- LaaS(基础架构即服务): 提供底层IT基础基础设施服务,包括处理能力、存储空间、网络资源等,面向对象一般是IT管理人员
- PaaS(平台即服务):把安装好开发环境的系统平台作为一种服务通过互联网提供给用户,面向对象一般是开发人员
- SaaS(软件即服务):直接通过互联网为用户提供软件和应用程序等服务,面向对象一般是普通用户
OpenStack服务
服务 | 项目名称 | 概述 |
---|---|---|
compute(计算) | Nova | 负责实例生命周期的管理,计算资源的单位 |
network(网络) | Neutron | 负责虚拟网络的管理,为实例创建网络的拓扑结构 |
idenity(认证) | Keystone | 对用户、租户和角色、服务进行认证和授权 |
Dashboard(控制面板) | Horizon | 提供一个Web管理界面,和OpenStack底层服务进行交互 |
Image Service(镜像) | Glance | 提供虚拟机镜像模板的注册与管理 |
Block Storage (快存储) | Cinder | 负责为运行实例提供持久的块存储设备 |
Object Storage(对象存储) | Swift | 为OpenStack提供基于云的弹性存储,支持群集无单点故障 |
Telemetry(计量) | Ceilometer | 用于度量、监控和控制数据资源的集中来源,为OpenStack用户提供记账途径 |
keystone认证
keystone(OpenStack Identity Service)时OpenStack中的一个独立的提供安全认证的模块,主要辅助openstack用户的身份认证、令牌管理、提供访问资源的服务目录、以及基于用户角色的访问控制
主要功能:
- 身份认证:令牌的发放和校验
- 用户授权:授予用户在一个服务中所拥有的权限
- 用户管理:管理用户账户
- 服务目录:提供可用服务的API端点
Glance镜像服务
glance是OpenStack中的镜像服务,它具有对镜像上传、检索、管理和存储等多种功能
主要功能:
- 查询和获取镜像的元数据和镜像本身
- 注册和上传虚拟机镜像,包括镜像的创建、上传、下载和管理
- 维护镜像信息,包括元数据和镜像本身
- 支持多种方式存储镜像,包括普通的文件系统、Swift、Amazon S3等
- 对虚拟机实例执行创建快照命令来创建新的镜像,或者备份虚拟机的状态
镜像状态
(1)镜像只是上传到glance到可以被glance管理
- queued:这是一种初始化状态,镜像文件刚被创建,在Glance数据库只有其元数据,镜像数据还没有上传至数据库中
- saving:是镜像的原始数据在上传到数据库中的一种过渡状态,表示正在上传镜像
- uploading:指示已进行导八 数BE外种上传的方法)saving状态会执行PUT/file,这是另外一种上传的方法)
- importing:指示已经完成导入调用,但是镜像还未准备好使用
(2)在使用过程中可能呈现的状态
- active:表示当镜像数据成功上传完毕,成为Glance中可用的镜像
- deactivated:表示任何非管理员用户都无权访问镜像数据,禁止下载镜像,也禁止镜像导出和镜像克隆之类的操作
- killed:表示镜像上传过程中发生错误,镜像不可读
- deleted:镜像将在不久后被自动删除,该镜像不可再用,但是目前Glance仍然保留该镜像的相关信息和原始数据
- pending_delete:与deleted相似,Glance还没有清除镜像数据,但处于该状态的镜像不可恢复
Nova计算服务
Nova是openstack最核心的服务之一,它辅助维护和管理云环境的减少资源,负责实例生命周期的管,它需要keystone、glance、neutron、conderheswift等其它服务的支持,能与这些服务集成
Nova系统架构
- DB:用于数据存储的sql数据库
- API:用于接受HTTP请求、转换命令、通过消息队列或HTTP与其他组件通信的nova组件,也作为openstack对外服务的接口
- Scheduler:用于选择哪台计算节点承载计算实例的nova调度器,选择方式有预选(先排除不符合需求的),优选(选择更符合需求的)
- Network:管理IP转发、网桥或虚拟居于玩点的nova网络组件
- Compute:管理虚拟机管理器与虚拟机之间通信的nova计算组件
- Conductor:控制器,出来需要协调的请求,或者出来对象转换
Nova-scheduler
调度器类型
- 随机调度器;从所有正常运行的nova-compute服务点的节点中随机选择
- 过滤调度器:根据指定的过滤条件以及权重选择最佳的计算节点,又称为筛选器
- 缓存调度器:在随即调度的基础上将主机资源信息缓存在本地内存中,然后通过后台的定时任务定时从数据库中获取最新的主机资源信息
过滤调度器(除了下面还有内存、硬盘、计算、计算能力、镜像属性等过滤器)
- RetryFilter(再审过滤器):主要作用是过滤掉之前已经调度过的节点。如A、B、C都通过了过滤,A权重最大被选中执行操作,由于某种原因,操作在A上失败了。Nova-filter将重新执行过滤操作,那么此时A就被会RetryFilter直接排除,以免再次失败
- AvailabilityZoneFilter(可用去过滤器):为提高容灾性并提供隔离服务,可以将计算节点划分到不同的可用区域中。Openstack默认有一个命名为nova的可用区域,所有的计算节点初始是放在nova区域中的。用户可以根据需要创建自己的一个可用区域。创建实例时,需要指定将实例部署在哪个可用区域中。Nova-scheduler执行过滤操作时,会使用AvailabilityZoneFilter不属于指定可用区域计算节点过滤掉
Nova-Compute
- Nova-compute在计算节点上运行,负责管理节点上的实例。通常一个主机运行一个Nova-compute服务,一个实例部署在哪个可用的主机上取决于调度算法。OpenStack对实例的操作,最后都是提交给Nova-compute来完成。
- Nova-compute可分为两类,一类是定向openstack报告计算节点的状态,另一类是实现实例生命周期的管理
Nova-conductor
- 由nova-condactor模块实现,旨在为数据库的访问提供一层安全保障。Nova-conductor作为nova-
compute服务与数据库之间交互的中介,避免了直接访问由nova-compute服务创建对接数据库。 - Nova-compute访问数据库的全部操作都改到nova-conductor中,nova-conductor作为对数据库操作的一个代理,而且nova-conductor是部署在控制节点上的。
- Nova-conductor有助于提高数据库的访问性能,nova-compute可以创建多个线程使用远程过程调用(RPC)访问nova-conductor。
- 在一个大规模的openstack部署环境里,管理员可以通过增加nova-conductor的数量来应付日益增长的计算节点对数据库的访问量。
Nova-placementAPI
- 面对多种多样的资源提供者(如ceph、nfs等提供的存储资源等),管理员需要统一的、简单的管理接口来统计系统中资源使用情况,这个接口就是PlacementAPI。
- PlacementAPI由nova-placement-api服务来实现,旨在追踪记录资源提供者的目录和资源使用情况。
- 被消费的资源类型是按类进行跟踪的。如计算节点类.共享存储池类、IP地址类等。
Nova-Cell架构
- 当openstack-nova集群的规模变大时,数据库和消息队列服务就会出现瓶颈问题。Nova为提高水平扩展及分布式、大规模的部署能力,同时又不增加数据库和消息中间件的复杂度,引入了Cell概念。
- Cell可译为单元。为支持更大规模的部署,openstack较大的nova集群分成小的单元,每个单元都有自己的消息队列和数据库,可以解决规模增大时引起的瓶颈问题。在Cell中,Keystone、Neutron、Cinder、Glance等资源是共享的。
Neutron网络
Neutron为整个openstack环境提供软件定义网络支持,主要功能包括二层交换、三层路由、防火墙、VPN,以及负载均衡等。Neutron在由其他openstack服务(如nova)管理的网络接口设备(如虚拟网卡)之间提供网络连接即服务。
Neutron网络结构
- 一个简化的典型的Neutron网络结构如图所示,包括一个外部网络、一个内部网络和一个路由器。
- 外部网络负责连接OpenStack项目之外的网络环境,又称公共网络。与其他网络不同,它不仅仅是一个虚拟网络,更重要的是,它表示OpenStack网络能被外部物理网络接入并访问。外部网络可能是企业的局域(Intranet),也可能是互联网(Ilnternet),这类网络并不是由Neutron直接管理。
- 内部网络完全由软件定义,又称私有网络。它是虚拟机实例所在的网络,能够直接连接到虚拟机。项目用户可以创建自己的内部网络。默认情况下,项目之间的内部网络是相互隔离的,不能共享。该网络由Neutron直接配置与管理。
- 路由器用于将内部网络与外部网络连接起来,因此,要使虚拟机访问外部网络,必须创建一个路由器。
- Neutron需要实现的主要是内部网络和路由器。内部网络是对二层(L2)网络的抽象,模拟物理网络的二层局域网,对于项目来说,它是私有的。路由器则是对三层(L3)网络的抽象,模拟物理路由器,为用户提供路由、NAT等服务。
网络拓扑类型
- local(测试用):Local网络与其他网络和节点隔离。该网络中的虚拟机实例只能与位于同一节点上同一网络的虚拟机实例通信,实际意义不大,主要用于测试环境。位于同一Local网络的实例之间可以通信,位于不同Local网络的示例之间无法通信。一个Local网络只能位于同一个物理节点上,无法跨节点部署。
- Flat:Flat是一种简单的扁平网络拓扑,所有的虚拟机实例都连接在同一网络中,能与位于同一网络的实例进行通信,并且可以跨多个节点。这种网络不使用VLAN,没有对数据包打VLAN标签,无法进行网络隔离。Flat是基于不使用VLAN的物理网络实施的虚拟网络。每个物理网络最多只能实现一个虚拟网络。
- vlan:VLAN是支持802.1q协议的虚拟局域网,使用VLAN标签标记数据包,实现网络隔离。同一VLAN网络中的实例可以通信,不同VLAN网络中的实例只能通过路由器来通信。VLAN网络可以跨节点,是应用最广泛的网络拓扑类型之一。
- VXLAN(虚拟扩展局域网:可以看作是VLAN的一种扩展,相比于VLAN,它有更大的扩展性和灵活性,是目前支持大规模多租房网络环境的解决方案。由于VLAN包头部限长是12位,导致VLAN的数量限制是4096 (2^12)个,不能满足网络空间日益增长的需求。目前VXLAN的封包头部有24位用作VXLAN标识符(VNID)来区分VXLAN网段,最多可以支持16777216 (2^24)个网段。VXLAN使用STP防止环路,导致一半的网络路径被阻断。VXLAN的数据包是封装到UDP通过三层传输和转发的,可以完整地利用三层路由,能克服VLAN和物理网络基础设施的限制,更好地利用已有的网络路径。
- GRE:GRE(通用路由封装)是用一种网络层协议去封装另一种网络层协议的隧道技术。GRE的隧道由两端的源IP地址和目的IP地址定义,它允许用户使用IP封装IP等协议,并支持全部的路由协议。在OpenStack环境中使用GRE意味着“IP over lP”, GRE与VXLAN的主要区别在于,它是使用IP包而非UDP进行封装的。
网络基础服务
- Neutron遵循OpenStack的设计原则,采用开放性架构,通过插件、代理与网络提供者的配合来实现各种网络功能。
- 插件是Neutron的一种API的后端实现,目的是增强扩展性。插件按照功能可以分为Core Plugin和Service Plugin两种类型。Core Plugin提供基础二层虚拟网络支持,实现网络、子网和端口等核心资源抽象。Service Plugin是指Core Plugin之外的其他插件,提供路由器、防火墙、安全组、负载均衡等服务支持。从H版开始,Neutron提供一个名为L3Router Service Plugin的插件支持路由服务。
- 插件的调用由neutron-server的Core Plugin API和Extension Plugin API调用,用于确定具体的网络功能,即要配置什么样的网络。
- 工作流程:插件处理neutron-server发来的请求,主要职责是在数据库中维护Neutron网络的状态信息(更新Neutron数据库),通知相应的代理实现具体的网络功能。每一个插件支持一组API资源并完成特定的操作,这些操作最终由插件通过RPC调用相应的代理来完成。 代理处理插件转来的请求,负责在网络提供者上真正实现各种网络功能。代理使用物理网络设备或虚拟化技术完成实际的操作任务,如用于路由器具体操作的L3代理。
ML2插件
- Neutron可以通过开发不同的插件和代理来支持不同的网络技术,这是一种相当开放的架构。不过随着所支持的网络提供者种类的增加,开发人员发现了两个突出的问题。一个问题是多种网络提供者无法共存。Core Plugin负责管理和维护Neutron二层虚拟网络的状态信息,一个Neutron网络只能由一个插件管理,而Core Plugin插件与相应的代理是一一对应的。如果选择Linux Bridge插件,则只能选择Linux Bridge代理,必须在OpenStack的所有节点上使用Linux Bridge插件,则只能选择Linux Bridge代理,必须在OpenStackR的所有节点上使用Linux Bridge作为虚拟交换机。另一个问题是开发新的插件的工作量太大,而所有传统的Core Plugin之间存在大量反复代码。
- 为解决这两个问题,从OpenStack的H版开始,Neutron实现了一个插件ML2,旨在取代所有的Core Plugin,允许在OpenStack网络中同时使用多种二层网络技术,不同的节点可以使用不同的网络实现机制。ML2能够与现有的代理无缝集成,以前使用的代理无须变更,只需将传统的Core Plugin替换成ML2。ML2使得对新的网络技术的支持更为简单,无须从头开发Core Plugin,只需要开发相应的机制驱动,大大减少编写和的代码。
Open vSwitch
- 开放虚拟交换机(Open vSwitch)是与硬件交换机具备相同特性,可在不同虚拟平台之间移植,具有产品级质量的虚拟交换机,适合在生产环境中部署。
- 交换设备的虚拟化对虚拟网络来说至关重要。在传统的数据中心,管理员可以对物理交换机进行配置,控制服务器的网络接入,实现网络隔离、流量监控、QoS配置、流量优化等目标。在云环境中,采用Open vSwitch技术的虚拟交换机可使虚拟网络的管理、网络状态和流量的监控得以轻松实现。
- Open Switch在云环境中的虚拟化平台上实现分布式虚拟交换机,可以将不同主机上的Ope vSwitch交换机连接起来,形成一个大规模的虚拟网络。
OpenStack优势
- 控制性:完全开源的平台,提供API接口,方便与第三方技术集成
- 兼容性:OpenStack兼容其他公有云,方便用户进行数据迁移
- 可拓展性:模块化设计,可以通过横向拓展,增加节点、添加资源
- 灵活性:根据自己的需要简历相应基础设施、增加集群规模
- 行业标准:众多IT领军企业已经加入到OpenStack项目
OpenStack架构
设计基本原则
- 按照不同的功能和通用性划分不同的项目,拆分子系统
- 按照逻辑计划、规范子系统之间的通信(mq)
- 通过分层设计整个系统架构
- 不同的功能子系统间提供同一的API接口
OpenStack逻辑架构
- OpenStack包括若干个称为OpenStack服务的独立组件,所有服务都通过一个公共身份服务进行身份验证(keystone),除了那些需要关了权限的命令,每个服务之间都可通过公共API进行交互
- 每个OpenStack服务由若干组件组成,包含多个进程,所有服务只是有一个API进程,用于侦听API请求,对这些请求进行预处理,并将它们传送到该服务的其他组件,除了认证服务,实际工作都是由具体的进程完成的
- 每个服务端进程之间的通信,是使用AMQP消息代理,服务的状态存储在数据库中
OpenStack组件通信关系
- 基于AMQP协议地通信:用于每个项目内部各个组件之间地通信
- 基于SQL地通信:用于各个项目内部地通信
- 基于HTTP协议进行通信:通过各项目地API简历地通信关系
- 通过Native API实现通信:OpenStack各组件和第三方软硬件之间的通信
以上是关于OpenStack--T版基础知识(持续更新)!的主要内容,如果未能解决你的问题,请参考以下文章
浅谈OpenStack T版服务组件--Neutron计算服务(#^.^#) 持续更新中
浅谈OpenStack T版服务组件--Nova计算服务(#^.^#)(持续更新~~~)
浅谈OpenStack T版服务组件--Glance镜像服务(#^.^#)(持续更新~~~)
使用kolla-ansible部署多节点OpenStack(T版)及对接Ceph