OpenStack Principle Summary

OpenStack has a lot of components and services, and different services will have different listening ports. Understanding how OpenStack Works and service ports is important for deeper learning about OpenStack.

Common services and ports for OpenStack

Computer Node Service

Virtual Machine Management: OPENSTAC If you are using a KVM virtual machine, the compute nodes will have QEMU-KVM to manage the virtual machines (there will be two processes). The default is to listen for VNC's 5900 and 59,012 ports.

Network: Use bridged network br0 to bridge to a local NIC (such as eth0).

Virtual machine save path:/var/lib/nova/instances/

[Email protected] ~]# tree/var/lib/nova/instances//var/lib/nova/instances/├──_base # Mirror │└──314553a43b925 8a9bee633340ba7b3ad50ee35bb├──compute_nodes├──d17934ec-689b-4553-81d3-ee2fa6cef912 #虚拟机实例 │├──console.log # console log,  And in the Web interface to see the same log │├──disk # Virtual Disk │├──disk.info # Virtual disk information, is actually a path │└──libvirt.xml # libvirt generated configuration XML file └── Locks├──nova-314553a43b9258a9bee633340ba7b3ad50ee35bb└──nova-storage-registry-lock

The ID here is the same as the virtual machine ID that is viewed on the control node through the OpenStack server list:

[[email protected] ~]# OpenStack Server list +--------------------------------------+-------+--------+-------------- --------+| ID | Name | Status | Networks |+--------------------------------------+-------+--------+----------------------+| d17934ec-689b-4553-81d3-ee2fa6cef912 | Demo1 | ACTIVE | public=172.16.10.102 |+--------------------------------------+-------+--------+----------------------+

Enter the disk, you will find that the size of the virtual disk is not our allocation of 1G, only 2.6M:

[[email protected] d17934ec-689b-4553-81d3-ee2fa6cef912]# ls-lhtotal 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 1 20:01 disk.info-rw-r--r--1 Nova Nova 2.6K Nov 2 17:53 libvirt.xml

Use file disk to view the information for this document:

# file Diskdisk:qemu QCOW Image (V3), has backing file (path/var/lib/nova/instances/_base/314553a43b9258a9bee633340ba7b 3ad5), 1073741824 bytes

Tell us the entity image saved in the/var/lib/nova/instances/_base/back-end file, and the changed file is saved in the disk file, and the original image will not be loaded again like disk.

Libvirt.xml is a dynamically generated file that shows the build information for the virtual machine, because the files here are dynamically generated after the virtual machine is started, so the configuration of the virtual machine cannot be altered even if it is modified.

Sshkey how the virtual machine is automatically passed in

In the instance of the virtual machine, the key value can be obtained by meta-data and this special IP:

$ Curl http://169.254.169.254/2009-04-04/meta-dataami-idami-launch-indexami-manifest-pathblock-device-mapping/ hostnameinstance-actioninstance-idinstance-typelocal-hostnamelocal-ipv4placement/ Public-hostnamepublic-ipv4public-keys/reservation-id

This special IP can be found through route tracking:

$ Curl http://169.254.169.254/2009-04-04/meta-data/local-ipv4172.16.10.102$ IP ro lidefault 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

The 172.16.10.100 here is the starting address for creating the network, but the automatically generated address here is the DHCP service. This IP is in the namespace:

[[Email protected] instances]# ip netns liqdhcp-ff609289-4b36-4294-80b8-5591d8196c42   (id: 0) [[email protected] instances]# ip netns exec  Qdhcp-ff609289-4b36-4294-80b8-5591d8196c42 ip ad li1: 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 forever2: [email protected]:  <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

The routing of DHCP and 169.254.169.254 is determined in the configuration file:

[[email protected] ~]# grep "Enable_isolated_metadata"/etc/neutron/dhcp_agent.ini enable_isolated_metadata = True

The 80 port is accessed by default via the Curl + URL, so a 80 port is enabled in the namespace:

To view ports:

[[email protected] instances]# ip netns exec  qdhcp-ff609289-4b36-4294-80b8-5591d8196c42 netstat -ntlpactive 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

The way to get this key in the mirror essentially executes the following command:

$ Curl Ssh-rsa aaaab3nzac1yc2eaaaadaqabaaabaqd0js4rti3mbxz3axkcqbg4gumg9xszihx07icft7lysbx8/ rypssypaioadv2tsd45fxcvszf5cmbdini6kyf0sxq04zu0acgllvxkv96i+gbdhizig1f3hte1oebcftngbaoavpsesu/uhrmt/jl9+ Jgyz78xl8trx1douzvhmyzdabfcva2zwekkjtwlhhzmsafkpslshhcr8wxnrxo91pg7ly4cgpr6joyzezr36cphjsas6zef4jgahmx8mqjevseyfikc6anao5 kg+9pwr1yknkxts78x6oct5e+1nmaeuyltnnrfbreb5y5u0gjipq0emiyfte20s0ughj+1 [email protected]

Similarly, get the host name in the same way:

$ Curl Http://169.254.169.254/2009-04-04/meta-data/hostnamedemo1.novalocal

In a custom image, it is not possible to get sshkey automatically, the official Cirros image is implemented by the Cloud-init, so when we upload the image ourselves, we can customize the script before starting the virtual machine, get the key and other initialization information, and do the same function.

Control node Service

Use the OpenStack Endpoint List command to view the current service registration information

MySQL: Providing data storage for each service

Services that require direct configuration of the database: Nova, NOVA-API, Glance, Keystone, neutron, cinder

RabbitMQ: Providing transport hubs for communication between services

Listening on port 5672, where 15672 and 5672 ports are RABBITMQ Web management ports and service ports, respectively

KeyStone: Provides authentication and service registration for communication between services

Keystone mainly through the HTTP request to complete the authentication function, Keystone-public use 5000 port, keystone-admin use 35357

Glance service provides image management and storage

Mirror path:/var/lib/glance/images/

Glance has two components: GLANCE-API, monitoring 9292 ports, glance-regestry, monitoring 9191 ports

NOVA provides compute resources for virtual machines such as CPU, memory, etc.

Nova-compute: Typically runs on compute nodes and manages different types of virtual machines by scheduling different virtual machine management tools. For example, KVM uses Libvirt to create a KVM virtual machine.

NOVA-API: Information interaction with other services with a service port of 8774

Novncproxy: As a proxy for VNC, listen for 6080 ports, connect to compute nodes and QEUM-KVM services (5900 ports)

Neutron: Providing network resources for virtual machines

The neutron service has a listening port of 9696.

Virtual Machine creation Process

1, the user in Dashboard Submit request Keystone authentication, get login token login.

2. Use dashboard to send a request to Nova-api to create a virtual machine using the HTTP protocol.

3, Nova-api accept the request, will use to obtain token to Keystone on the verification, confirm the request is legal.

4, Nova-api confirm the request is legitimate, the data that needs to be read and synchronized to the database, and the request to create a virtual machine into the message queue.

5. After Nova-schduler discovers the request of message queue, it obtains the data from the database, schedules and calculates the resources, confirms which node the virtual machine should be created, and then passes the information back to the message queue.

6, Nova-compute in the message queue to obtain this information, through the Nova-conductor middleware and database interaction, to obtain relevant information, and then request glance, Neutron, cinder to get the resources needed to create the virtual machine. In the process. Each time the Nova interacts with glance, Neutron, and cinder, it is necessary to verify that the request is valid on the Keystone.

7, when the image, network, storage and other resources are acquired, Nova-compute will call Libvirt (in the case of KVM) to create a virtual machine.

This article is from the "Trying" blog, make sure to keep this source http://tryingstuff.blog.51cto.com/4603492/1869029

OpenStack Principle Summary