OpenStack 原理小结

简介:

OpenStack有非常的多的组件和服务,不同的服务都会有不同的监听端口。了解openstack的工作原理和服务端口,对于更加深入的学习openstack非常重要。


OpenStack的常用服务和端口


计算机节点服务

虚拟机管理:openstac如果使用的是KVM虚拟机,则会在计算节点是有qemu-kvm来管理虚拟机(会有两个进程)。默认会监听VNC的5900和5901两个端口。

网络:使用桥接网络br0,桥接到本地的网卡上(如eth0).

虚拟机保存路径:/var/lib/nova/instances/

1
2
3
4
5
6
7
8
9
10
11
12
13
[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相同:

1
2
3
4
5
6
[root@node1 ~] # openstack server list    
+--------------------------------------+-------+--------+----------------------+
| ID                                   | Name  | Status | Networks             |
+--------------------------------------+-------+--------+----------------------+
| d17934ec-689b-4553-81d3-ee2fa6cef912 | demo1 | ACTIVE | public=172.16.10.102 |
+--------------------------------------+-------+--------+----------------------+

进入磁盘,会发现虚拟磁盘的大小并不是我们分配的1G,只有2.6M:

1
2
3
4
5
6
[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 查看这个文件的信息:

1
2
3
4
# 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值:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ 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:

1
2
3
4
5
6
$ 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是在命名空间中:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[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的路由是在配置文件中所确定的:

1
2
[root@node1 ~] # grep "enable_isolated_metadata" /etc/neutron/dhcp_agent.ini    
enable_isolated_metadata = True

通过btctl  show 命令可以看到Linux主机中的网络桥接状态。使用route 命令,查看当前的路由信息,可以发现169.254.169.254的路由走向。

而通过curl + URL的方式默认会访问80端口,所以在命名空间中一空启用一个80端口:

查看端口:

1
2
3
4
5
6
7
[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的方式实质上是执行了下面的命令:

1
2
3
4
5
6
7
$ curl 
  
ssh -rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD0Js4RtI3MbxZ3axkcQbG4GUmG9xsZihX07icFT7
lySbX8 /RYPSSYpaIOAdv2Tsd45FXCvszF5CmbDINI6kyf0sxq04ZU0ACgllvxKv96i +GBdhizIG1F3
Hte1OeBcftnGbAoavpseSU /uhRmT/jl9 +JGyz78Xl8trx1dOuzvhMYzdAbFcVa2zWEKKJtWLhhZmSA
FkpsLShHCR8WXNrXO91PG7Ly4CGpR6JoyzEzr36CPHJsaS6zef4jGaHmx8MQJeVseYfIKc6aNao5kg
+9pWR1YKnkxtS78x6OCT5E+1NMaeuyltnNRFbReB5y5U0GJipQ0EmIYFTE20s0UGHJ+1 root@node1

同理,使用相同的方式获取主机名:

1
2
$ curl http: //169 .254.169.254 /2009-04-04/meta-data/hostname
demo1.novalocal

在自定义的镜像中,是无法自动获取sshkey的,官方提供的cirros镜像是通过自带的cloud-init实现的,所以当我们自己上传镜像时,可以在启动虚拟机前自定义脚本,获取key和其它初始化信息,完成相同的功能。


控制节点服务

使用 openstack endpoint list命令可以查看当前的服务注册信息,此处所说的控制节点,一般指安装消息队列RabbitMQ的节点。


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.


Cinder: 为虚拟机提供存储(云硬盘)

cinder-api:接受API请求,并将其路由到``cinder-volume``执行,默认端口为8776。

ccinder-volume:与块存储服务和例如``cinder-scheduler``的进程进行直接交互。它也可以与这些进程通过一个消息队列进行交互。


cinder-scheduler:选择最优存储提供节点来创建卷。其与``nova-scheduler``组件类似。

cinder-backup daemon:cinder-backup服务提供任何种类备份卷到一个备份存储提供者。



虚拟机创建流程


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为例)去创建虚拟机。


故障处理:

1、查看日志报错信息,一般只需查看ERROR信息即可。

2、时间必须同步。

3、创建虚拟机出错,需要确认计算节点是否有足够的资源,这个在日志中也能体现。

4、查看服务端口和服务状态:

1
2
openstack compute service list
openstack network agent list


高可用与负载均衡:

1、一般对控制节点使用haproxy做负载均衡。

2、如果要做高可用,可以使用keepalived。

3、对数据库和RabbitMQ做集群。

4、底层存储可以采用分布式存储,如Ceph。


 本文转自 酥心糖 51CTO博客,原文链接:http://blog.51cto.com/tryingstuff/1869029



相关文章
|
11月前
|
云计算 虚拟化 开发者
Openstack架构构建及详解(4)--Nova组件
Openstack架构构建及详解(4)--Nova组件
417 0
|
负载均衡 安全 Linux
openstack 网络Neutron知识点《openstack》
本人cdsn账号 https://liuyunshengsir.blog.csdn.net/article/details/124927149
694 1
openstack 网络Neutron知识点《openstack》