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

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

而经过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命令能够查看当前的服务注册信息，此处所说的控制节点，通常指安装消息队列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服务提供任何种类备份卷到一个备份存储提供者。

虚拟机建立流程

一、用户在Dashboard提交请求keystone认证，获取登陆token登陆.

二、使用Dashboard，使用http协议向nova-api发出建立虚拟机的请求。

三、Nova-api接受到请求以后，会使用获取token去keystone上进行验证，确认请求合法。

四、Nova-api确认请求合法后，将须要读取和同步的数据同步到数据库中，并将建立虚拟机的请求放入消息队列。

五、Nova-Schduler 发现消息队列的请求以后，会从数据库中获取数据，并对资源进行调度和计算，确认虚拟机应该建立在哪一个节点，获得这些信息以后，会将这些信息传回给消息队列。

六、Nova-compute在消息队列中获得这些信息以后，会经过Nova-conductor中间件与数据库交互，获取相关信息，并依次请求Glance、Neutron、Cinder去获取建立虚拟机所须要的资源。在这个过程当中。Nova每次和Glance、Neutron、Cinder的交互都须要去keystone上进行确认请求是否合法.

七、当镜像、网络、存储等资源都获取到后，Nova-compute 会调用libvirt（以KVM为例）去建立虚拟机。

故障处理：

一、查看日志报错信息，通常只需查看ERROR信息便可。

二、时间必须同步。

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

四、查看服务端口和服务状态：

openstack compute service list
openstack network agent list

高可用与负载均衡：

一、通常对控制节点使用haproxy作负载均衡。

二、若是要作高可用，可使用keepalived。

三、对数据库和RabbitMQ作集群。

四、底层存储能够采用分布式存储，如Ceph。