核心服务就是如果没有它,OpenStack 就跑不起来。很显然
作为openStack的基础服务,Keystone主要做下面这3件事情
要弄懂Keystone就得理解下面这些概念
User指代任何使用openStack的实体
可以是真正的用户,也可以是某个程序,openStack为每一个组件都会创建对应的用户,当User访问openStack时,Keystone会对其验证身份
Credentials是User用来证明自己身份的信息
它可以是:
Authentication是Keystone验证User身份的过程
User访问openStack时向Keystone提交用户名和密码形式的Credentials,Keystone验证通过后会给User签发一个Token作为后续访问的Credentials
Token是由数字和字母组成的字符串,User成功Authentication后由Keystone分配给user
Project用于将openStack的资源(计算,存储,网络)进行分组,隔离
根据openStack服务的对象不同,Project可以是一个客户、部门或者项目组
这里请注意:
OpenStack 的 Service 包括 Compute (Nova)、Block Storage (Cinder)、Object Storage (Swift)、Image Service (Glance) 、Networking Service (Neutron) 等。
每个 Service 都会提供若干个 Endpoint,User 通过 Endpoint 访问资源和执行操作。
Endpoint是一个网络上可访问的地址,通常是一个URL,Service通过Endpoint来暴露自己的API
Keystone负责维护管理每个Service的Endpoint
安全包含2个部分,一个是认证(Authentication),另一个是鉴权(Authorization)
Authentication解决的是你是谁的问题
Authorization解决的是你能干什么的问题
Keystone是借助Role来实现Authorization的,也就是给Role定义好权限之后将Role绑定用User,那么User就拥有这个Role下定义的权限了
所以Keystone的工作流程就是这样的
这个就是keystone的工作流程了,所有的组件和用户都需要经过keystone,这也证实了openStack没有Keystone转不了的说法
Glance为虚拟机提供镜像服务,这里不过多赘述组件的功能,glance有2个服务进程
glance-api 是系统后台运行的服务进程。 对外提供 REST API,响应 image 查询、获取和存储的调用。
glance-api 不会真正处理请求。
如果是与 image metadata(元数据)相关的操作,glance-api 会把请求转发给 glance-registry;
如果是与 image 自身存取相关的操作,glance-api 会把请求转发给该 image 的 store backend。
glance-registry 是系统后台运行的服务进程。负责处理和存取 image 的 metadata,例如 image 的大小和类型。
glance本地并不存储image,真正的image存储是放在backend中的,默认是本地的文件系统
当用户请求到达glance-api时,glance-api会将请求转发给对应的服务进程,如:当用户想要查询有哪些镜像存在时,glance-api就会将请求给到glance-registry处理,处理完成之后再由glance-api将结果返回给到用户,同样,存储的请求就会交给backend去处理,至于你存储到哪,glance-api是不管的,这个就是glance的工作流程
这个组件以前集成在nova之中,现在独立出来了,他的作用的用来跟踪硬件的利用率,将收集到的数据提供给后续的nova使用,这个没啥多说的
Compute Service, Nova 是 OpenStack 最核心的服务,负责维护和管理云环境的计算资源。OpenStack 作为 IaaS 的云操作系统,虚拟机生命周期管理也就是通过 Nova 来实现的。
nova有很多子组件,分别是
数据库和消息队列这也是nova所依赖的,但是他们俩并不是nova独享的。
与glance-api一样,只负责接受请求,不处理请求,只会将请求接受然后发布到消息队列当中
虚拟机调度服务,通过placement提供的各项数据再结合各种算法,打分机制来决定虚拟机最终运行在哪个计算节点上,并将消息通过消息队列发布出去
管理虚拟机的核心服务,运行在每个计算节点上,nova-compute是实际工作者,他会从消息队列中拿到nova-scheduler发布的消息,然后来创建虚拟机,每个虚拟机的状态都是需要写入数据库的,也就是说nova-compute需要经常更新数据库,但是nova-compute并不能直接操作数据库,为了安全考虑,由另外一个组件来操作数据库。
nova-compute 经常需要更新数据库,比如更新虚机的状态。
出于安全性和伸缩性的考虑,nova-compute 并不会直接访问数据库,而是将这个任务委托给 nova-conductor,为什么说为了安全考虑呢?我们不妨设想一下,现在集群内有100个计算节点,他们如果能够直接操作数据库的话,那么只有要其中的一台服务器被侵入,那么他是可以直接拿到数据库操作的权限的,这样做风险太大了,所以将更新数据库的操作交给了nova-conductor这个进程来处理
现在虚拟机创建好了,我们是不是需要使用虚拟机呢?假设现在网络不通,无法通过ssh或者RDP连接到虚拟机,那我们如何去管理呢?也就是通过nova-console为我们提供的控制台,nova-console是一个统称,并不是某一个服务。
它包含3种方式的控制台:
当有一个创建虚拟机的请求到达nova-api时,nova-api会将请求发送到消息队列,此时nova-scheduler从消息队列读取消息,然后选举一个最适合创建虚拟机的节点,然后将结果再通过消息队列发布出去,nova-compute从消息队列中读取到了消息之后开始干活,并将虚拟机的状态信息发布到消息队列,然后nova-conductor读取到了nova-compute发布的消息之后去操作数据库修改对应的数据
Neutron 为整个 OpenStack 环境提供网络支持,包括二层交换,三层路由,负载均衡,防火墙和 VPN 等。
Neutron 提供了一个灵活的框架,通过配置,无论是开源还是商业软件都可以被用来实现这些功能。
关于网络的话我们就不讨论他的工作流程了。我们来聊聊他的实现方式
neutron通过在每个节点上模拟一个软路由出来,跑在该节点上的虚拟机都接到这个软路由上,这样同节点的虚拟机网络就实现了互通,那不同节点之间呢?模拟出来的软路由也不能够直接跨主机通信吧,这个时候就需要借助到物理网卡了,我们配置neutron的时候,有一个配置是将某个网卡给neutron去使用的,所以,在同一节点内,所有的虚拟机都连接上这个软路由实现互联,不同节点之间通过配置的物理网卡来实现互联,这样一套操作下来,所有的网络就都能打通了。这也就是neutron的实现方式,但是neutron又提供了好种网络类型,接下来我们来一个个看
Neutron提供的网络有这几种:
local类型的网络与其他节点的网络隔离,也就是说local类型的网络只能够与跑在同一节点上的虚拟机进行通信,无法跨主机通信,这种网络是没有意义的,实验环境都没有太大的意义。
flat网络是无vlan tag的网络,能够与其他节点的虚拟机互联,但是无法实现隔离,如果集群内节点过多,那么相应的,广播域也就越大,这种类型的网络在local网络之上做到了与其他节点互联
这个网络类型就是网络里的Vlan,交换机可以通过不同的Vlan ID来实现隔离,可以这样去理解,Vlan就是在flat网络之上给每个人分一个组,只有在同一个组里面的虚拟机才可以互相访问,在不同的组就访问不到,这样就解决了flat网络的广播域过大的问题。最多可以支持4094个分组
VLAN有4096个ID,而VXLAN有1600万个ID。这也就意味着vxlan支持隔离更多的区域,但是vxlan是工作在三层的,使用upd协议进行传输,而vlan是一个二层的,由于需要进行封装和解封装操作,性能开销比VLAN高,但可以通过硬件卸载来优化性能。
gre 是与 vxlan 类似的一种 overlay 网络。主要区别在于使用 IP 包而非 UDP 进行封装。