OpenStack-nova theory of knowledge
One, nova computing service
Computing service is one of the core services of openstack, responsible for maintaining and managing the computing resources of the cloud environment. It is codenamed nova in the openstack project
Nova itself does not provide any virtualization capabilities. It provides computing services. It uses different virtualization drivers to interact with the underlying Hypervisor (virtual machine manager). All computing instances (virtual servers) are lifecycled by Nova Scheduling management (start, suspend, stop deleting, etc.)
Nova needs the support of other services such as keystone, glance, neutron, cinder, and swif, and can be integrated with these services to implement encrypted disks, bare metal computing instances, etc.
Two, nova system architecture
DB: SQL database for data storage
API: Nova components used to receive HTTP requests, convert commands, and communicate with other components through message queues or HTTP
Scheduler: nova scheduler used to determine which computing node to host the computing instance
Network: nova network component that manages IP forwarding, bridge or virtual local area network
Compute: the nova computing component that manages the communication between the virtual machine manager and the virtual machine
Conductor: handle requests that require coordination (build virtual machine or adjust virtual machine size), or handle object conversion
Three, nova component introduction
1、API
API is the http interface for customers to access nova. It is implemented by the nova-api service. The nova-api service receives and responds to computing apI requests from end users. As the main interface for openstack external services, nova-api provides a centralized Query all API endpoints
All requests to nova are first processed by nova-api, and the API provides REST standard calling services for easy integration with third-party systems
End users will not directly redirect RESTful API requests, but use these APIs through the openstack command line, dashbord, and other components that need to be exchanged with nova
As long as the operations related to the life cycle of the virtual machine, nova-api can respond
nova-api performs the following processing on the received HTTP API request:
①Check whether the parameters passed in by the client are legal and valid
②Call other nova services to process client HTTP requests
③Format the returned results of other nova sub-services and return them to the client
nova-api is the only way to externally access and use various services provided by nova, and it is also the middle layer between the client and nova
2、Scheduler
Scheduler can be translated into a scheduler, implemented by the nova-scheduler service. It mainly solves the problem of how to choose which computing node to start an instance on. It can apply a variety of rules. If you consider memory usage, cpu load rate, and cpu architecture ( Intel/amd) and other factors, according to a certain algorithm, determine which computing server the virtual machine instance can run on. The nova-scheduler service will receive a request for a virtual machine instance from the queue and read the contents of the database. , Select the most suitable computing node from the available resource pool to ship a new virtual machine instance
When creating a virtual machine instance, the user will propose resource requirements, such as how much cpu, memory, and disk are needed. Openstack says that these requirements are defined in the instance type, and the user only needs to specify which instance type to use.
①Type of scheduler
Random scheduler: Randomly select from all nodes running nova-compute service normally
Filter scheduler: Select the best computing node according to the specified filter conditions and weights. Filter is also called filter
Scheduling process
Select the computing nodes that meet the conditions through the specified filter. For example, if the memory usage is less than 50%, you can use multiple filters to filter in sequence.
Perform weight calculation and sorting on the filtered host list, and select the optimal computing node to create a virtual machine instance
Cache scheduler: It can be regarded as a special type of random scheduler. On the basis of random scheduling, host resource information is cached in local memory, and then the latest host resource information is periodically obtained from the database through the background timing task.
② Classification of filters
When the filter scheduler needs to perform a scheduling operation, it will let the filter judge the computing node and return True or False
The scheduler_available_filters option is used to configure the available filters. By default, all nova filters can be used for filtering.
In addition, there is an option scheduler_default_filters to specify the filters actually used by the nova-scheduler service. The
filter scheduler will filter in the order in the list.
RetryFilter (retrial filter)
The main function is to filter out the nodes that have been scheduled before. For example, A, B, and C have passed the filtering, and A has the largest weight and is selected to perform the operation. For some reason, the operation fails on A. Nova-filter will re-execute the filtering operation, then A will be directly excluded by RetryFilter to avoid failure again
AvailabilityZoneFilter (availability zone filter)
In order to improve disaster tolerance and provide isolation services, computing nodes can be divided into different available areas. Openstack has an available area named nova by default, and all computing nodes are initially placed in the nova area. Users can create an available area of their own according to their needs. When creating an instance, you need to specify in which Availability Zone the instance will be deployed. When Nova-scheduler performs filtering operations, it will use AvailabilityZoneFilter to filter out computing nodes that do not belong to the specified availability zone
RamFilter (Memory Filter)
Schedule the creation of virtual machines based on the available memory to filter out the computing nodes that cannot meet the memory requirements of the instance type. However, in order to improve system resource utilization, Openstack allows the available memory of the computing node to exceed the actual memory size, and the extent of the excess is through nova .conf configuration file
ram_allocation_ratio parameter to control, the default value is 1.5
vim /etc/nova/nova.conf
ram_ allocation_ ratio=1 .5
DiskFilter (hard disk scheduler)
Schedule the creation of virtual machines based on the disk space, and filter out the computing nodes that cannot meet the type of disk requirements. Disks are also allowed to be oversized. The oversized value can be controlled by modifying the disk_allocation ratio parameter in nova.conf. The default value is 1.0
vim /etc/nova/nova.conf
disk_allcation_ratio=1.0
ComputeFilter (calculation filter)
#Ensure that only the nova-compute service is normal: working computing nodes can be scheduled by nova-scheduler, which is a required filter
ComputeCapablilitiesFilter (Compute Capability Filter)
#Filter according to the characteristics of the computing node, such as different nodes of x86_ 64 and ARM architecture, to instance
ImagePropertiesFilter (mirror property filter)
#Filter matching computing nodes according to the attributes of the selected mirror. Specify its attributes through metadata. If you want the image to only run on the KVM Hypervisor, you can specify it through the Hypervisor Type attribute.
ServerGroupAntiAffinityFilter (server group anti-affinity filter)
It is required to distribute the instances to different nodes as much as possible. For example, there are 3 instances s1, s2, s3, and 3 computing nodes A, B, and C. The specific operations are as follows:
Create a server group with anti-affinit policy
openstack server group create -policy antiaffinity group-1
Create three instances and put them into the group-1 server group
openstack server create -flavor m1.tiny -image cirros -hint group=group-1 s1
openstack server create -flavor m1.tiny -image cirros -hint group=group-1 s2
openstack server create -flavor m1.tiny -image cirros -hint group=group-1 s3
ServerGroupAffinityFilter (server group affinity filter)
Contrary to the anti-affinity filter, this filter tries to deploy instances to the same compute node
③weight (weight)
The nova-scheduler service can use multiple filters to filter sequentially. After filtering the nodes, the nodes that can deploy the instance are selected by calculating the weight.
All weights are located in the nova/scheduler/weights directory. The current default implementation is RAMweighter, which calculates the weight value according to the amount of free memory of the computing node. The more idle, the greater the weight, and the instance will be deployed to the computing node with the most free memory.
3、Compute
Nova-compute runs on the compute node_ and is responsible for managing the instances on the node. Usually a host runs a Nova-compute service, and on which available host an instance is deployed depends on the scheduling algorithm. The operation of OpenStack on the instance is finally submitted to Nova-compute for completion.
Nova-compute can be divided into two categories, one is to direct openstack to report the status of computing nodes, and the other is to implement instance lifecycle management.
Support multiple hypervisor virtual machine managers through Driver architecture
Face a variety of Hypervisorn nBva-compute defines a unified interface for these Hypervisors
Hypervisor only needs to implement these interfaces, you can plug and play into the OpenStack system in the form of Driver
Periodically report the status of compute nodes to OpenStack
Every once in a while, nova-compute will report the current resource usage of the compute node and the status of the nova-compute service.
nova-compute obtains this information through the Hypervisor driver
Realize the management of the life cycle of virtual machine instances
The most important operations of OpenStack on virtual machine instances are achieved through nova-compute.
Create, shut down, restart, suspend, resume, abort, resize, migrate, and snapshot.
Take instance creation as an example to illustrate the implementation process of nova-compute.
① Prepare resources for the instance.
②Create a mirror file of the instance.
③Create the XML definition file of the instance.
④ Create a virtual network and start the virtual machine.
4、Conductor
It is implemented by the nova-conductor module and aims to provide a layer of security for database access. Nova-conductor acts as an intermediary for the interaction between the nova-compute service and the database, avoiding direct access to the database that is created by the nova-compute service.
All operations of Nova-compute to access the database are changed to nova-conductor, nova-conductor acts as an agent for database operations, and nova-conductor is deployed on the control node
Nova-conductor helps to improve database access performance. Nova-compute can create multiple threads to use remote procedure call (RPC) to access nova-conductor.
In a large-scale openstack deployment environment, administrators can increase the number of nova-conductors to cope with the monthly increase in computing node access to the database
5、PlacementAPI
In the past, the management of resources was all undertaken by computing nodes. When calculating resource usage, we simply add up the resource conditions of all computing nodes. However, there are external resources in the system, and these resources are provided by external systems. Such as storage resources provided by ceph, nfs, etc. Faced with a variety of resource providers, administrators need a unified and simple management interface to count the resource usage in the system. This interface is PlacementAPl
PlacementAPI is implemented by the nova-placement-api service, which aims to track and record the directory and resource usage of resource providers. The types of resources consumed are tracked by category. Such as computing node class, shared storage pool class, IP address class, etc.
Fourth, the virtual machine instantiation process
Users can access the console of the virtual machine in a variety of ways
Nova-novncproxy daemon: access the running instance through vnc connection to provide a proxy, support browser novnc client
Nova-spicehtml5proxy daemon: access the running instance through spice connection to provide a proxy, support client based on html5 browser
Nova-xvpvncproxy daemon: access the running instance through vnc connection to provide a proxy, support openstack dedicated java client
Nova-consoleauth daemon: Responsible for providing user token authentication for accessing the virtual machine console. This service must be used in conjunction with the console agent. .
Five, console interface
First, the user (which can be an OpenStack end user or another program) executes the command provided by Nova Client to create a virtual machine
The nova-api service listens to HTTP requests from Nova Client, converts these requests into AMQP messages and then joins the
message queue. Calls the nova-conductor service through the message queue
After the nova-conductor service receives the virtual machine instantiation request message from the message queue, it performs some preparations
The nova-conductor service tells the nova-scheduler service to select a suitable computing node to create a virtual machine through the message queue. At this time, nova-scheduler will read the contents of the database
After the nova-conductor service obtains the appropriate information about the computing node from the nova-scheduler service, it notifies the nova-compute service to create a virtual machine through the message queue.
Six, nova deployment architecture
1. Architecture diagram of nova classic deployment mode
2. nova load balancing deployment mode architecture diagram
3. Nova's cell architecture
① Architecture diagram of cells v2
When the scale of the openstack nova cluster becomes larger, the database and message queue services will have bottlenecks. In order to improve horizontal expansion and distributed and large-scale deployment capabilities without increasing the complexity of database and message middleware, Nova introduced the Cell concept
Cell can be translated into unit. In order to support larger-scale deployments, openstack divides the large nova cluster into small units, each unit has its own message queue and database, which can solve the bottleneck problem caused by the increase in scale. In Cell, Keystone, Neutron, Cinder, Glance and other resources are shared
Database on the API node
Global information is stored in the nova_api database. These global data tables are migrated from the nova database, such as flavor (instance model), instance groups (instance groups), quota (quota)
The mode of the nova_cell0 database is the same as that of nova. The main purpose is when the instance scheduling fails, the information of the instance does not belong to any Cell, so it is stored in the nova_cell0 database.
②Single cell architecture diagram and multi-cell architecture diagram
Seven, nova metadata
The function of metadata is to inject metadata information into the virtual machine instance, and the instance gets its own metadata when it starts, and the cloud-init tool in the instance completes the personalized configuration work according to the metadata.
Openstack divides the metadata information obtained when cloud-init customizes the virtual machine instance configuration into two categories: metadata and user data
Metadata refers to structured data, which is injected into an instance in the form of key-value pairs, including some common attributes of the instance itself, such as host name, network configuration information (IP address and security group). SSH keys etc.
User data is unstructured data. It is injected through files or scripts. It supports multiple file formats, such as gzip, shell, cloud-init configuration files, etc., mainly including some commands and scripts, such as shell scripts.
Openstack divides the configuration information injection mechanism of metadata and user data into two types, one is the configuration driver mechanism, and the other is the metadata service mechanism.