标签:openstack 原理
OpenStack有非常的多的组件和服务,不同的服务都会有不同的监听端口。了解openstack的工作原理和服务端口,对于更加深入的学习openstack非常重要。
OpenStack的常用服务和端口
计算机节点服务
虚拟机管理:openstac如果使用的是KVM虚拟机,则会在计算节点是有qemu-kvm来管理虚拟机(会有两个进程)。默认会监听VNC的5900和5901两个端口。
网络:使用桥接网络br0,桥接到本地的网卡上(如eth0).
虚拟机保存路径:/var/lib/nova/instances/
[root@node2 ~]# tree /var/lib/nova/instances/ /var/lib/nova/instances/ ├── _base # 镜像 │ └── 314553a43b9258a9bee633340ba7b3ad50ee35bb ├── compute_nodes ├── d17934ec-689b-4553-81d3-ee2fa6cef912 #虚拟机实例 │ ├── console.log # 控制台日志,和在Web界面看到的日志相同 │ ├── disk # 虚拟磁盘 │ ├── disk.info # 虚拟磁盘信息,其实就是一个路径 │ └── libvirt.xml # libvirt生成的配置xml文件 └── locks ├── nova-314553a43b9258a9bee633340ba7b3ad50ee35bb └── nova-storage-registry-lock
这里的ID和在控制节点上通过openstack server list所查看的虚拟机ID相同:
[root@node1 ~]# openstack server list +--------------------------------------+-------+--------+----------------------+ | ID | Name | Status | Networks | +--------------------------------------+-------+--------+----------------------+ | d17934ec-689b-4553-81d3-ee2fa6cef912 | demo1 | ACTIVE | public=172.16.10.102 | +--------------------------------------+-------+--------+----------------------+
进入磁盘,会发现虚拟磁盘的大小并不是我们分配的1G,只有2.6M:
[root@node2 d17934ec-689b-4553-81d3-ee2fa6cef912]# ls -lh total 2.6M -rw-rw---- 1 nova qemu 20K Nov 2 20:09 console.log -rw-r--r-- 1 qemu qemu 2.6M Nov 2 20:09 disk -rw-r--r-- 1 nova nova 79 Nov 1 20:01 disk.info -rw-r--r-- 1 nova nova 2.6K Nov 2 17:53 libvirt.xml
使用file disk 查看这个文件的信息:
# file disk disk: QEMU QCOW Image (v3), has backing file (path /var/lib/nova/instances/_base/314553a43b9258a9bee633340ba7b3ad5), 1073741824 bytes
告诉我们在/var/lib/nova/instances/_base/后端文件中保存的实体镜像,而在disk文件中保存的是变化的文件,原始镜像不会再次加载如disk.
libvirt.xml是动态生成文件,里面显示了虚拟机的构建信息,由于这里的文件是启动虚拟机后动态生成的,所以即使修改也无法改动虚拟机的配置。
SSHKEY如何自动会传入虚拟机
在虚拟机的实例中,可以通过meta-data和这个特殊的IP获取到key值:
$ curl http://169.254.169.254/2009-04-04/meta-data ami-id ami-launch-index ami-manifest-path block-device-mapping/ hostname instance-action instance-id instance-type local-hostname local-ipv4 placement/ public-hostname public-ipv4 public-keys/ reservation-id
可以通过路由追踪找到这个特殊的IP:
$ curl http://169.254.169.254/2009-04-04/meta-data/local-ipv4 172.16.10.102 $ ip ro li default via 172.16.0.1 dev eth0 169.254.169.254 via 172.16.10.100 dev eth0 172.16.0.0/16 dev eth0 src 172.16.10.102
这里的172.16.10.100为创建网络的起始地址,但是这里自动生成的地址为DHCP服务。这个IP是在命名空间中:
[root@node1 instances]# ip netns li qdhcp-ff609289-4b36-4294-80b8-5591d8196c42 (id: 0) [root@node1 instances]# ip netns exec qdhcp-ff609289-4b36-4294-80b8-5591d8196c42 ip ad li 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ns-48901cde-e3@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether fa:16:3e:95:71:9b brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 172.16.10.100/16 brd 172.16.255.255 scope global ns-48901cde-e3 valid_lft forever preferred_lft forever inet 169.254.169.254/16 brd 169.254.255.255 scope global ns-48901cde-e3 valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fe95:719b/64 scope link valid_lft forever preferred_lft forever
DHCP和169.254.169.254的路由是在配置文件中所确定的:
[root@node1 ~]# grep "enable_isolated_metadata" /etc/neutron/dhcp_agent.ini enable_isolated_metadata = True
而通过curl + URL的方式默认会访问80端口,所以在命名空间中一空启用一个80端口:
查看端口:
[root@node1 instances]# ip netns exec qdhcp-ff609289-4b36-4294-80b8-5591d8196c42 netstat -ntlp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3575/python2 tcp 0 0 172.16.10.100:53 0.0.0.0:* LISTEN 3566/dnsmasq tcp 0 0 169.254.169.254:53 0.0.0.0:* LISTEN 3566/dnsmasq tcp6 0 0 fe80::f816:3eff:fe95:53 :::* LISTEN 3566/dnsmasq
镜像中获取这个key的方式实质上是执行了下面的命令:
$ curl ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD0Js4RtI3MbxZ3axkcQbG4GUmG9xsZihX07icFT7 lySbX8/RYPSSYpaIOAdv2Tsd45FXCvszF5CmbDINI6kyf0sxq04ZU0ACgllvxKv96i+GBdhizIG1F3 Hte1OeBcftnGbAoavpseSU/uhRmT/jl9+JGyz78Xl8trx1dOuzvhMYzdAbFcVa2zWEKKJtWLhhZmSA FkpsLShHCR8WXNrXO91PG7Ly4CGpR6JoyzEzr36CPHJsaS6zef4jGaHmx8MQJeVseYfIKc6aNao5kg +9pWR1YKnkxtS78x6OCT5E+1NMaeuyltnNRFbReB5y5U0GJipQ0EmIYFTE20s0UGHJ+1 root@node1
同理,使用相同的方式获取主机名:
$ curl http://169.254.169.254/2009-04-04/meta-data/hostname demo1.novalocal
在自定义的镜像中,是无法自动获取sshkey的,官方提供的cirros镜像是通过自带的cloud-init实现的,所以当我们自己上传镜像时,可以在启动虚拟机前自定义脚本,获取key和其它初始化信息,完成相同的功能。
控制节点服务
使用 openstack endpoint list命令可以查看当前的服务注册信息
MySQL:为各个服务提供数据存储
需要直接配置数据库的服务:nova, nova-api, glance, keystone, neutron, cinder
RabbitMQ:为各个服务之间通信提供交通枢纽
监听端口5672,其中15672 和5672 端口分别为rabbitMQ的web管理端口和服务端口
KeyStone:为各个服务之间通信提供认证和服务注册
keystone主要通过http请求完成认证功能,keystone-public使用5000端口,keystone-admin使用35357
Glance服务提供镜像的管理和存储
镜像路径:/var/lib/glance/images/
glance有两个组件:glance-api,监听9292端口,glance-regestry,监听9191端口
Nova提供虚拟机的计算资源如CPU,内存等
Nova-compute: 一般运行在计算节点上,通过调度不同的虚拟机管理工具来管理不同类型的虚拟机。如KVM就使用libvirt来创建KVM虚拟机等。
Nova-api:与其它服务进行信息交互,服务端口为8774
novncproxy:作为vnc的代理,监听6080端口,在计算节点和qeum-kvm服务衔接(5900端口)
Neutron: 为虚拟机提供网络资源
neutron服务的监听端口为9696.
虚拟机创建流程
1、用户在Dashboard提交请求keystone认证,获取登录token登录.
2、使用Dashboard,使用http协议向nova-api发出创建虚拟机的请求。
3、Nova-api接受到请求之后,会使用获取token去keystone上进行验证,确认请求合法。
4、Nova-api确认请求合法后,将需要读取和同步的数据同步到数据库中,并将创建虚拟机的请求放入消息队列。
5、Nova-Schduler 发现消息队列的请求之后,会从数据库中获取数据,并对资源进行调度和计算,确认虚拟机应该创建在哪个节点,得到这些信息之后,会将这些信息传回给消息队列。
6、Nova-compute在消息队列中得到这些信息之后,会通过Nova-conductor中间件与数据库交互,获取相关信息,并依次请求Glance、Neutron、Cinder去获取创建虚拟机所需要的资源。在这个过程中。Nova每次和Glance、Neutron、Cinder的交互都需要去keystone上进行确认请求是否合法.
7、当镜像、网络、存储等资源都获取到后,Nova-compute 会调用libvirt(以KVM为例)去创建虚拟机。
本文出自 “Trying” 博客,请务必保留此出处http://tryingstuff.blog.51cto.com/4603492/1869029
标签:openstack 原理
原文地址:http://tryingstuff.blog.51cto.com/4603492/1869029