openStack核心组件的工作流程

目录

openStack核心组件的工作流程

核心服务就是如果没有它，OpenStack 就跑不起来。很显然

  1. Nova 管理计算资源，是核心服务。
  2. Neutron 管理网络资源，是核心服务。
  3. Glance 为 VM 提供 OS 镜像，属于存储范畴，是核心服务。
  4. Cinder 提供块存储，VM怎么也得需要数据盘吧，是核心服务。你如果只是做测试，数据不需要落盘，也是可以不装Cinder的
  5. Keystone 认证服务，没它 OpenStack 转不起来，是核心服务。
  6. Horizon 大家都需要一个操作界面吧。

1. Keystone

作为openStack的基础服务，Keystone主要做下面这3件事情

  1. 管理用户及其权限
  2. 维护 OpenStack Services 的 Endpoint
  3. Authentication（认证）和 Authorization（鉴权）

要弄懂Keystone就得理解下面这些概念

  • User
  • Credentials
  • Authentication
  • Token
  • Project
  • Service
  • Endpoint
  • Role

1.1 User

User指代任何使用openStack的实体

可以是真正的用户，也可以是某个程序，openStack为每一个组件都会创建对应的用户，当User访问openStack时，Keystone会对其验证身份

1.2 Credentials

Credentials是User用来证明自己身份的信息

它可以是:

  1. 用户名/密码
  2. Token
  3. Api Key
  4. 其他高级方式

1.3 Authentication

Authentication是Keystone验证User身份的过程

User访问openStack时向Keystone提交用户名和密码形式的Credentials，Keystone验证通过后会给User签发一个Token作为后续访问的Credentials

1.4 Token

Token是由数字和字母组成的字符串，User成功Authentication后由Keystone分配给user

  1. Token用做访问Service的Credentials
  2. Service会通过keystone来验证Token的有效性
  3. Token的有效期默认为24小时

1.5 Project

Project用于将openStack的资源(计算，存储，网络)进行分组，隔离

根据openStack服务的对象不同，Project可以是一个客户、部门或者项目组

这里请注意：

  1. 资源的所有权是属于Project的，而不是User
  2. 每个User必须挂在Project里面才能访问该Project的资源(admin也不例外)，一个User可以属于多个Project
  3. admin相当于root用户，具有最高权限

1.6 Service

OpenStack 的 Service 包括 Compute (Nova)、Block Storage (Cinder)、Object Storage (Swift)、Image Service (Glance) 、Networking Service (Neutron) 等。

每个 Service 都会提供若干个 Endpoint，User 通过 Endpoint 访问资源和执行操作。

1.7 Endpoint

Endpoint是一个网络上可访问的地址，通常是一个URL，Service通过Endpoint来暴露自己的API

Keystone负责维护管理每个Service的Endpoint

1.8 Role

安全包含2个部分，一个是认证(Authentication)，另一个是鉴权(Authorization)

Authentication解决的是你是谁的问题

Authorization解决的是你能干什么的问题

Keystone是借助Role来实现Authorization的，也就是给Role定义好权限之后将Role绑定用User，那么User就拥有这个Role下定义的权限了

1.9 keystone综述

所以Keystone的工作流程就是这样的

  1. 用户提交自己的用户名/密码(也可以为其他方式)给到keystone
  2. keystone验证通过之后给用户返还一个Token
  3. 用户拿着这Token通过Endpoint去请求对应的服务
  4. 被请求的服务将用户的Token拿到之后交给Keystone验证是否有效，有效则继续后续的操作

这个就是keystone的工作流程了，所有的组件和用户都需要经过keystone，这也证实了openStack没有Keystone转不了的说法

2. glance

Glance为虚拟机提供镜像服务，这里不过多赘述组件的功能，glance有2个服务进程

  1. glance-api
  2. glance-registry
  3. backend

2.1 glance-api

glance-api 是系统后台运行的服务进程。 对外提供 REST API，响应 image 查询、获取和存储的调用。

glance-api 不会真正处理请求。

如果是与 image metadata（元数据）相关的操作，glance-api 会把请求转发给 glance-registry；

如果是与 image 自身存取相关的操作，glance-api 会把请求转发给该 image 的 store backend。

2.2 glance-registry

glance-registry 是系统后台运行的服务进程。负责处理和存取 image 的 metadata，例如 image 的大小和类型。

2.3 backend

glance本地并不存储image，真正的image存储是放在backend中的，默认是本地的文件系统

2.4 glance综述

当用户请求到达glance-api时，glance-api会将请求转发给对应的服务进程，如：当用户想要查询有哪些镜像存在时，glance-api就会将请求给到glance-registry处理，处理完成之后再由glance-api将结果返回给到用户，同样，存储的请求就会交给backend去处理，至于你存储到哪，glance-api是不管的，这个就是glance的工作流程

3. placement

这个组件以前集成在nova之中，现在独立出来了，他的作用的用来跟踪硬件的利用率，将收集到的数据提供给后续的nova使用，这个没啥多说的

4. nova

Compute Service, Nova 是 OpenStack 最核心的服务，负责维护和管理云环境的计算资源。OpenStack 作为 IaaS 的云操作系统，虚拟机生命周期管理也就是通过 Nova 来实现的。

nova有很多子组件，分别是

  1. nova-api
  2. nova-scheduler
  3. nova-compute
  4. nova-conductor
  5. nova-console

数据库和消息队列这也是nova所依赖的，但是他们俩并不是nova独享的。

4.1 nova-api

与glance-api一样，只负责接受请求，不处理请求，只会将请求接受然后发布到消息队列当中

4.2 nova-scheduler

虚拟机调度服务，通过placement提供的各项数据再结合各种算法，打分机制来决定虚拟机最终运行在哪个计算节点上，并将消息通过消息队列发布出去

4.3 nova-compute

管理虚拟机的核心服务，运行在每个计算节点上，nova-compute是实际工作者，他会从消息队列中拿到nova-scheduler发布的消息，然后来创建虚拟机，每个虚拟机的状态都是需要写入数据库的，也就是说nova-compute需要经常更新数据库，但是nova-compute并不能直接操作数据库，为了安全考虑，由另外一个组件来操作数据库。

4.4 nova-conductor

nova-compute 经常需要更新数据库，比如更新虚机的状态。
出于安全性和伸缩性的考虑，nova-compute 并不会直接访问数据库，而是将这个任务委托给 nova-conductor，为什么说为了安全考虑呢？我们不妨设想一下，现在集群内有100个计算节点，他们如果能够直接操作数据库的话，那么只有要其中的一台服务器被侵入，那么他是可以直接拿到数据库操作的权限的，这样做风险太大了，所以将更新数据库的操作交给了nova-conductor这个进程来处理

4.5 nova-console

现在虚拟机创建好了，我们是不是需要使用虚拟机呢？假设现在网络不通，无法通过ssh或者RDP连接到虚拟机，那我们如何去管理呢？也就是通过nova-console为我们提供的控制台，nova-console是一个统称，并不是某一个服务。

它包含3种方式的控制台：

  1. nova-novncproxy，基于 Web 浏览器的VNC 访问
  2. nova-spicehtml5proxy，基于HTML5 浏览器的 SPICE 访问
  3. nova-xvpnvncproxy，基于 Java 客户端的 VNC 访问

4.6 nova综述

当有一个创建虚拟机的请求到达nova-api时，nova-api会将请求发送到消息队列，此时nova-scheduler从消息队列读取消息，然后选举一个最适合创建虚拟机的节点，然后将结果再通过消息队列发布出去，nova-compute从消息队列中读取到了消息之后开始干活，并将虚拟机的状态信息发布到消息队列，然后nova-conductor读取到了nova-compute发布的消息之后去操作数据库修改对应的数据

5. Neutron

Neutron 为整个 OpenStack 环境提供网络支持，包括二层交换，三层路由，负载均衡，防火墙和 VPN 等。

Neutron 提供了一个灵活的框架，通过配置，无论是开源还是商业软件都可以被用来实现这些功能。

关于网络的话我们就不讨论他的工作流程了。我们来聊聊他的实现方式

5.1 网络的实现方式

neutron通过在每个节点上模拟一个软路由出来，跑在该节点上的虚拟机都接到这个软路由上，这样同节点的虚拟机网络就实现了互通，那不同节点之间呢？模拟出来的软路由也不能够直接跨主机通信吧，这个时候就需要借助到物理网卡了，我们配置neutron的时候，有一个配置是将某个网卡给neutron去使用的，所以，在同一节点内，所有的虚拟机都连接上这个软路由实现互联，不同节点之间通过配置的物理网卡来实现互联，这样一套操作下来，所有的网络就都能打通了。这也就是neutron的实现方式，但是neutron又提供了好种网络类型，接下来我们来一个个看

Neutron提供的网络有这几种：

5.1 local

local类型的网络与其他节点的网络隔离，也就是说local类型的网络只能够与跑在同一节点上的虚拟机进行通信，无法跨主机通信，这种网络是没有意义的，实验环境都没有太大的意义。

5.2 flat

flat网络是无vlan tag的网络，能够与其他节点的虚拟机互联，但是无法实现隔离，如果集群内节点过多，那么相应的，广播域也就越大，这种类型的网络在local网络之上做到了与其他节点互联

5.3 vlan

这个网络类型就是网络里的Vlan，交换机可以通过不同的Vlan ID来实现隔离，可以这样去理解，Vlan就是在flat网络之上给每个人分一个组，只有在同一个组里面的虚拟机才可以互相访问，在不同的组就访问不到，这样就解决了flat网络的广播域过大的问题。最多可以支持4094个分组

5.4 vxlan

VLAN有4096个ID，而VXLAN有1600万个ID。这也就意味着vxlan支持隔离更多的区域，但是vxlan是工作在三层的，使用upd协议进行传输，而vlan是一个二层的，由于需要进行封装和解封装操作，性能开销比VLAN高，但可以通过硬件卸载来优化性能。

5.5 GRE

gre 是与 vxlan 类似的一种 overlay 网络。主要区别在于使用 IP 包而非 UDP 进行封装。

posted @ 2024-07-16 19:13  FuShudi  阅读(183)  评论(0)  编辑  收藏  举报