openstack原理
主要就是openstack原理
一、openstack做了什么?
-
物理硬件--->>> 抽象成云资源---->>> 让用户按需申请使用
-
客户不需要关心服务器在哪里,硬盘在哪里,网络怎么通,只需要在web界面点一下
-
开一台云主机,配一个公网ip,挂载一个云硬盘
二、核心项目
- 共享服务组件
-
数据库服务(database service):Mariadb及Mongodb。
-
消息传输(Message Queues)::RabbitMQ
-
缓存(cache):Memcached
-
时间同步(time sync):ntp
-
存储(storge provider):ceph,GFS,LVM,ISICI等
-
高可用及负载均衡:pacemaker,HAproxy,keepalived,lvs
- 核心组件
-
认证服务
Keystone: 提供了其余所有组件的认证信息/令牌管理,创建,修改等等,使用mysql作为统一的数据库 -
镜像服务
Glance提供了对虚拟机部署的时候所能提供的镜像的管理,包含镜像的导入,格式,以及制作相应的模板 -
计算服务
nova负责维护和管理云计算的计算资源,维护和管理计算和网络 -
网络服务
neutron提供了对网络节点的网络拓扑管理,同时提供了neutron在horizon的管理面板 -
web界面服务
horizon提供了以web的形式对所有节点的所有服务的管理 -
块存储服务
cinder为运行实例提供稳定的数据块存储服务 -
对象存储
swift为glance提供镜像存储和卷备份服务 -
部署编排
heat提供了基于模版来实现云环境中资源的初始化,依赖关系处理,部署等基本操作,也可以解决自动收缩,负载均衡等高级特性。

三、组件详解
1、Keystone
1、作用
-
用户管理:验证身份的信息的合理性
-
认证服务:提供了其与所有组件的认证信息/令牌管理,创建,删除导尿管,用来专门的数据库来统一存放,以前是mysql,现在是mariadb
-
keystone是openstack用来进行身份验证以及高级授权的身份识别服务
2、概念

-
租户(project):个人或服务所拥有的资源集合,就相当于是阿里云上有不同的租户,有自己的项目,在一个Project(Tenant)中可以包含多个User,每一个User都会根据权限的划分来使用Project(Tenant)中的资源。 -
用户(user):访问openstack对象的,用户拥有的证书,且可能分配到一个或者多个租户,经过验证后,会为每一个单独的租户,提供一个特定的令牌 -
证书(Credentials):确认用户身份的凭证。可以是用户名和密码、用户名和API Key和Token。 -
令牌(token): 一个字符串表示,作为访问资源的令牌。Token包含了在指定范围和有效时间内可以被访问的资源,具有时效性 -
角色:就是一个权限,给user指定权限,拥有操作一些资源的资格,Keystone返回给User的Token包含了Role列表,被访问的Services会判断访问它的User和User提供的Token中所包含的Role -
policy用来控制User对Project中资源(包括Services)的操作权限。对于Keystone service来说,Policy就是一个JSON文件,默认是/etc/keystone/policy.json。 -
服务(service)openstack组件中的服务,nova,neutorn,glance等 -
Authentication确定用户身份的过程 -
endpoint通过网络访问和定位某个openstack中service的地址,通常是一个url-
admin url 管理员使用
-
internal url openstack组件之间使用
-
public url 外部访问,全局访问
-
3、工作原理

-
首先user向keystone提供自己的凭证(用户名/用户密码)
-
keystone根据user提供的凭证,从自己的数据库中进行身份和权限的检验,验证通过后,会返回一个user的一个token,endpoint
-
user得到授权后(token)和endpoint后,根据自身的权限操作openstack中资源
4、keystone在各个组件的作用

-
user通过命令或者api方式登录后,提供自己的凭证
-
keystone通过用户提供的凭证和自己的数据库进行检验,通过后,返回一个token(就是能操作什么),endpoint(访问服务的地址)
-
此后的话,用户就是拿这个token进行身份验证,其他组件会拿这个token与keystone进行检验,通过后,就能使用这个服务了
5、keystone常见的操作


2、Glance
1、作用
-
glance是镜像服务,用来注册和登录和检索镜像
-
glance提供了一个rest api ,让用户能够查询镜像元数据和检索的实际的镜像
-
提供镜像服务,但是实际存储可以是nfs,本地存储,ceph的rbd,s3存储
-
提供了对虚拟机部署的时候所能提供的镜像的管理,包含了镜像的导入,格式,以及制作的模板
2、镜像的状态

-
Queued:初始化镜像状态,在镜像文件刚刚被创建,在glance数据库中已经保存了镜像标示符,但还没有上传至glance中,此时的glance对镜像数据没有任何描述,其存储空间为0; -
Saving:镜像的原始数据在上传中的一种过度状态,它产生在镜像数据上传至glance的过程中,一般来讲,glance收到一个image请求后,才将镜像上传给glance; -
Active:镜像成功上传完毕以后的一种状态,它表明glance中可用的镜像; -
Killed:镜像上传失败或者镜像文件不可读的情况下,glance将镜像状态设置成Killed; -
Deleted:镜像文件马上会被删除,只是当前glance这种仍然保留该镜像文件的相关信息和原始镜像数据; -
Pending_delete:镜像文件马上会被删除,镜像文件不能恢复。
3、磁盘格式
RAW:RAW即常说的裸格式,它其实就是没有格式,最大的特点就是简单,数据写入什么就是什么,不做任何修饰,所以再性能方面很不错,甚至不需要启动这个镜像的虚拟机,只需要文件挂载即可直接读写内部数据。并且由于RAW格式简单,因此RAW和其他格式之间的转换也更容易。在KVM的虚拟化环境下,有很多使用RAW格式的虚拟机。
QCOW2:它是QEMU的CopyOn Write特性的磁盘格式,主要特性是磁盘文件大小可以随着数据的增长而增长。譬如创建一个10GB的虚拟机,实际虚拟机内部只用了5GB,那么初始的qcow2磁盘文件大小就是5GB。与RAW相比,使用这种格式可以节省一部分空间资源。
VMDK:VMware创建的一个虚拟机磁盘格式,目前也是一个开放的通用格式,除了VMware自家的产品外,QEMU和VirtualBox也提供了对VMDK格式的支持。
4、容器格式
BARE:没有容器的一种镜像元数据格式。
OVF:开放虚拟化格式。
OVA:开放虚拟化设备格式。
AKI、ARI:Amazon公司的AWS所使用的镜像格式。

5、核心架构

glance-api:接收外部的请求的,然后通过其他的模块glacne-registry和image store实现了镜像的查找,获取,上传,删除等操作
glance-registry 和数据库进行交互,用于存储或获取镜像的元数据
Store Adapter:通过提供的存储接口来获取镜像,ceph的rbd,nfs,cinder,本地存储等等
database:Image的metadata会保持到database中,主要使用MySQL和SQLite
6、配置文件
-
glance-api.conf glance api的配置文件
-
Glance服务安装的日志和调试信息,例如:debug、日志文件路径log_file等参数。
-
Glance服务的API服务器的相关信息。例如:服务绑定的IP地址、端口bind_port等参数。
-
Registry服务的相关信息,例如:Registry服务的网络地址、监听的端口号、Glance与Registry间通信的协议等。
-
系统消息相关参数,该部分主要配置Glance与系统消息的收发,消息队列RabbitMQ的IP地址、监听端口等参数。
-
镜像后端存储的相关配置,一般情况下,glance-api.config中包含普通文件存储、Swfit、S3、RBD等较为常见的存储设备的信息配置。
-
-
glance-registry.conf:glance-registry服务配置文件,用户存储镜像有关的元数据。
-
glance-scrubber.conf:用于清理已删除的镜像的服务。
-
policy.json:镜像服务的访问控制。在这里,我们可以定义角色和策略,是OpenStack Glance中的安全特性。
6、创建镜像工作流程

7、常见的操作

3、Nova
1、概念
-
nova分为控制节点和计算节点
-
计算节点通过nova-compute进行虚拟机控制,通过libvirt调用kvm创建虚拟机,nova之间通信通过rabbitmq队列进行通信
-
nova位于openstack架构的中心,其他服务或者组件(glance,clinder,neutron)对其提供支持
2、作用
-
nova是openstack最核心的服务模块,负责管理和维护云计算环境的计算资源,负责整个云环境的虚拟机生命周期
-
nova是计算服务,负责维护和管理的网络和存储,提供计算服务
3、核心架构

4、组件
nova-api 实现了restful api功能,是外部访问nova的唯一途径,接收外部请求并通过队列将请求发送给其他服务组件,
nova-scheduler 决策虚拟机创建在哪个主机(计算节点上),决策一个虚拟机应该调度到哪一个物理节点
- 过滤,过滤出可以创建虚拟机的主机,符合条件的筛选出一组出来

- 计算权值,根据权重大小进行分配,默认根据资源可用空间进行权重排序,选出最优解的主机

nova-compute 负责虚拟机的生命周期管理,创建,终止的工作后台程序为hypervisor api

nova-conductor 计算节点访问数据的中间件,nova-compute服务和数据库之间的中间件,消除了对云数据库的直接访问
nova-api-metadata 从实例中接收元数据请求
nova-placement-api 跟踪每个计算提供者的仓库和使用情况
5、工作流程
Nova创建虚拟机的过程中,会与Keystone、Glance、Cinder、Neutron等组件联动

Nova创建虚拟机的过程:
-
通过Web界面或命令行通过RESTful API向keystone获取认证信息。
-
keystone通过用户请求认证信息,并生成auth-token返回给对应的认证请求。
-
界面或命令行通过RESTful API向nova-api发送一个boot instance的请求(携带- auth-token)。
-
nova-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的信息调用配置的虚拟化驱动来创建虚拟机。
6、nova常见的操作


4、Neutron
概述
-
传统的网络管理方式很大程度上依赖于管理员手工配置和维护各种网络硬件设备;而云环境下的网络已经变得非常复杂,特别是在多租户的场景里,用户随时都可能需要创建、修改和删除网络,此时网络的连通性和隔离就不能通过手工配置来保证了。
-
如何快速响应业务的需求,这无疑对网络管理提出了更高的要求。传统的网络管理方式已经很难胜任这项工作,而"软件定义网络(Software-defined networking,SDN)"所具有的灵活性和自动化优势使其成为云时代网络管理的主流。
-
Neutron的设计目标是实现"网络即服务(Networking as a Service)"。为了达到这一目标,在设计上遵从了基于SDN实现网络虚拟化的原则,充分利用了Linux系统上的各种网络虚拟化技术。
-
最开始在OpenStack负责网络的组件叫做 Quantum,后面从nova体系中分离出来,独立成Neutron项目
基本概念
network是一个隔离的二层广播域,neutron支持多种类型的network,包括local,flat,vlan,vxlan和gre
local网络与其他节点网络和节点隔离,local网络中的实例只能与位于同一节点上的实例通信,主要用于单机测试

flat网络是一个无vlan tag的网络,要求宿主机的物理网卡与linux bridge连接,flat网络中的实例能与位于同一网络的实例进行通信,可以跨多个节点进行通信

如果需要创建多个flat网络,就需要准备多个物理网卡,每一个flat独占一个物理网卡

因为flat网络与物理网卡一一对应,需要指明flat网络与物理网卡的对应关系
在[m2_type_flat] 中通过flat_networks定义一个网络,label为"default"
在 [linux_bridge] 中通过 physical_interface_mappings 指明 default 对应的物理网卡为 eth1
vlan网络是具有tag 的网络,是一个二层的广播域,同一个vlan中的实例可以通信,不同vlan之间通过router通信,vlan网络可以跨节点,应用最广泛的网络类型

三个 Instance 通过 TAP 设备连接到名为 "brqXXXX" Linux Bridge。
在物理网卡 eth1 上创建了 eth1.100 的 VLAN Interface,eth1.100 连接到 brqXXXX。
Instance 通过 eth1.100 发送到 eth1 的数据包就会打上 VLAN100 的 Tag。
如果再创建一个 VLAN Network 101,eth1上会相应的创建 VLAN Interface eth1.101,并且连接到新的 Linux Bridge "brqYYYY"。每个 VLAN Network 有自己的 Bridge,从而也就实现了基于 VLAN 的隔离。

因为物理网卡eth1上面可以走多个VLAN的数据,那么物理交换机上与eth1相连的Port要设置成trunk模式,而不是access模式。
那么,不同的VLAN设备怎么样才可以通信呢?那就需要Router来提供数据转发服务,如下图。
不同节点上的实例,可以通过路由器来实现通信

subnet 是一个地址段,实例的ip从subnet中分配,每个subnet需要定义ip地址的范围和掩码,就相当于是创建了一个交换机
- network与subnet是1对多的关系,同一个network的subnet可以是不同的ip段
network A
subnet A-a: 10.10.1.0/24 {"start":"10.10.1.1","end":"10.10.1.50"}
subnet A-b: 10.10.2.0/24 {"start":"10.10.2.1","end":"10.10.2.50"}
Network Namespace:是一种网络隔离机制,通过网络命名空间的每个Router都有自己独立的路由表
-
如果两个 Subnet 是通过同一个 Router 路由,根据 Router 的配置,只有指定的一个 Subnet 可被路由。
-
如果两个 Subnet 是通过不同 Router 路由,因为 Router 的路由表是独立的,所以两个 Subnet 都可以被路由。
port 是虚拟交换机上的一个端口,定义了mac地址和ip地址,当实例的虚拟网卡绑定到port时,port会将mac和ip分配给实例网卡
neutron功能
-
neutron为整个openstack环境提供网络支持,包括二层路由,三层路由,负载均衡,防火墙,vpn等
-
二层交换switch(L2)
-
nova的实例使用过虚拟交换机连接到虚拟二层网络,neutron支持多种虚拟机交换机,包括原生的linux bridge和open vswitch(ovs)是一个开源的虚拟交换机
-
利用linux brige和ovs,除了可以创建传统的vlan网络,还可以创建基于隧道技术的overlay网络,比如vxlan和gre(linux bridge不能实现gre,目前支持的是vxlan)
-
二层就是依靠mac地址的,交换机,内部通信的
-
-
三层路由(涉及到ip的转发,SNAT,DNAT) Route(L3)
-
创建的虚拟机可以是不同的网段的,neutron的虚拟路由器能实现实例之间的跨网段通信,无非就是通过这个ip forward和iptables实现路由和NAT
-
创建一个路由器会有一个单独的命名的空间创建出来,就是一个可以配置的 就是一个三层的L3的抽象,模拟物理的路由器,为用户提供一个路由,NAT,在openstack中,不同的子网需要路由器,网络和外部之间通信更加的需要路由器
-
neutron提供虚拟路由器,也支持物理路由器(提供相应的ip路由表,实现宿主机之间的互相通信),2个隔离的vlan网络之间需要通信的话,就需要物理的路由器,物理路由器提供ip路由表,确保2个ip子网之间的通信,虚拟路由器上面设置2个接口,分别是2个不同vlan下面虚拟机的网关地址;数据包通过vlan A中物理网卡到达路由器的时候,物理路由器转发到vlan B中的物理网卡,实现访问vlan B中的虚拟机
-
三层就是需要路由器,将内部网络和外部网络实现通信,实现虚拟机访问外网

-
核心架构

详解
neutron server 对外提供openstack网络api,接收请求,并调用plugin处理请求
plugin: 处理neutron server 发来的请求,维护openstack逻辑网络状态,并调用agent处理请求
network provider:提供网络服务的虚拟或物理的网络设备,例如linux bridge, open vswitch或者其他支持neutron的物理交换机
queue:neutron server,plugin,agent 之间通过messaging queue 通信和调用
databse: 存放openstack的网络状态信息,包括了network,subnet,port,router
neutron组件详解
neutron-server详解

coer-api: 对外提供管理network,subnet,port,restful api
extension api: 对外提供router,load balance,firewall 等资源的restful api
common service: 认证和校验api请求
neutron core:neutron server的核心处理程序,通过调用plugin处理请求
core plugin api:定义了core plugin的抽象功能集合,neutron core通过api调用相应的core plugin
extension plugin api: 定义了service plugin的抽象功能集合,neutron core 通过api调用service plugin
core plugin 实现了core plugin api,在数据库中维护network,subnet,port的状态,并负责调用相应的agent 在network provider上执行相关的操作
service plugin 实现了extension plugin api在数据库中维护 Router,Load Balance,Security Group 等资源的状态,并调用相应的 Agent 在 Network Provider 上执行相关的操作,例如创建 Router
ml2-core详解

neutron可以通过开发不同的plugin和agent支持不同的网络技术,但是随着network provider数量的增加,开发人员发现2个突出的问题
-
只能在 OpenStack 中使用一种 Core Plugin,多种 Network Provider 无法共存。只使用一个 Core Plugin 本身没有问题。但问题在于传统的 Core Plugin 与 Core Plugin agent 是一一对应的。也就是说,如果选择了 Linux Bridge Plugin,那么 Linux Bridge agent 将是唯一选择,就必须在 OpenStack 的所有节点上使用 Linux Bridge 作为虚拟交换机(即 network provider)。
-
不同 Plugin 之间存在大量重复代码,开发新的 Plugin 工作量大。所有传统的 Core Plugin 都需要编写大量重复和类似的数据库访问的代码,大大增加了 Plugin 开发和维护的工作量。
moduler layer(ML2): 是neutron在 Havana 版本实现的一个新的 Core Plugin,用于替代原有的 Linux Bridge Plugin 和 Open vSwitch Plugin。作为新一代的 Core Plugin,提供了一个框架,允许在 OpenStack 网络中同时使用多种 Layer 2 网络技术,不同的节点可以使用不同的网络实现机制
-
ML2 对两层网络进行抽象和建模,引入了 type driver 和 mechansim driver。type driver 负责维护网络类型的状态,执行验证,创建网络等。
-
Type Driver:Neutron 支持的每一种网络类型都有一个对应的 ML2 type driver。type driver 负责维护网络类型的状态,执行验证,创建网络等。ML2 支持的网络类型包括 ML2 支持的网络类型包括 Local, Flat, VLAN, VxLAN 和 GRE。
-
Mechanism Driver:Neutron 支持的每一个网络机制都有一个对应的 ML2 mechansim driver。mechanism driver 负责获取由 type driver 维护的网络状态,并确保在相应的网络设备上(物理或虚拟)上正确实现这些状态。
-
Agent-based类型:包括 Linux Bridge,Open vSwitch 等
-
Controller-based类型:包括 OpenDaylight,VMware NSX 等
-
基于物理交换机:包括 Cisco Nexus,Arista,Mellanox 等
-
service-plugin/agent详解

core plugin和agent负责管理核心的实体:net,subnet,port,而对于更高级的网络服务,则由service plugin/agent管理
service plugin 以及agent提供更丰富的扩展功能,包括路由,load balance,firewall等
dhcp dhcp agent 通过dnsmasq为instance提供dhcp服务
routing L3 agent可以为project(租户)创建router,提供neutron subnet之间的路由服务,路由功能默认通过iptables实现
firewall: L3 agent可以在router上Router 上配置防火墙策略,提供网络安全防护。另一个与安全相关的功能是 Security Group,也是通过 IPtables 实现。Firewall 与 Security Group 的区别在于:
- Firewall :安全策略位于 Router,保护的是某个 Project 的所有 network。
- Security Group:安全策略位于 instance,保护的是单个 instance。
补充
创建路由器的时候,会有一个命名空间的创建的
命名空间是三层才会出现的
创建网络这些都是二层的,也就是创建交换机这些
命名空间有
-
内网口,外网口
-
iptables 实现SNAT,DNAT
-
路由表信息
-
所有虚拟机上网、访问外网,全部走这个命名空间
还有一个注意的点就是,开启dhcp的话,也会有一个命名空间,主要租用就是分配ip地址
ip netns 查看
常见的操作

neutron的配置文件详解
物理环境:
vlan A
vlan B
分别创建虚拟机,不同的vlan如果想要实现访问的
需要路由器,并且网关都配置在路由器上面,这样就能实现不同vlan之间的通信,且接口应该也是需要配置的吧
你好
flat模式
网段与宿主机的网段保持一致即可
虚拟路由器的话,就是会创建一个命名空间
后面的实验就是glance对接ceph
glance是一个提供存储镜像的服务,后端存储可以是nfs,本地存储,ceph的rbd,s3
晚上的话就是,glance对接ceph,将上传的镜像存储到ceph的rbd存储池中
面试的准备
openstack中Keystone相关的操作,也写一个博客
回去还有python视频

浙公网安备 33010602011771号