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。