Shulou(Shulou.com)06/03 Report--

Combing the Core components of getting started with OpenStack (2)-- A Preface to Nova

In the last article on ​, we talked about the Keystone project step by step from concept to principle, while this article aims to continue to introduce the Nova component project, one of the core components of OpenStack.

​ compared to the Keystone project, the Nova project is the earliest and most mature project as a large open source project OpenStack. From this level, it also reflects that the computing services provided by the Nova project are the core part of OpenStack from beginning to end. The author mentioned in the previous article that the three major resources provided and managed by the OpenStack open source project are computing, network and management. This is also the core part of cloud computing.

​ from the author's personal understanding and point of view, for OpenStack, its real soul (can be understood as the complexity of components in OpenStack, usage probability and failure probability, etc.) lies in the macro (here "macro means relative to the early version of the OpenStack platform") Nova (computing service) The second is the Neutron network service, which is the most complex compared to other services (this component will be described in detail in a later article). CEPH distributed storage is not included here, because CEPH itself can be considered as an independent large-scale project, its role is not only to replace the efficient distributed cluster storage of Swift (object Storage Service) in OpenStack, but also to combine and support with other technologies. However, no matter whether the OpenStack cloud platform is deployed in the experimental environment or the production environment, basically CEPH is selected as the distributed storage service. Of course, I would like to add here that if you want to deploy the OpenStack experimental environment, the hardware resources allocated to PC are still relatively high, including CPU, memory, storage (preferably SSD). The basic hardware resources allocated by the author are i79 generation CPU, 32G memory (three-tier cache reaches 9m) and 1T SSD M.2 interface solid state disk. The network is a household 100-megabit broadband. Of course, a high configuration may not be needed in the experimental environment, and some requirements can be relatively reduced. However, if you want to have a good sense of experience, it is better to have a high configuration, if you are the staff who decide to engage in this direction. You can buy a server to simulate the production environment, which is not recommended for beginners.

​ gossip will not be said any more, and then the author will introduce the Nova project from four aspects: an overview of its concept, main components, architectural patterns, and working principles.

I. Overview and Development of Nova 1.1 introduction to the concept of Nova

​ Nova project, as the core project of OpenStack, provides very important computing services. Although in the process of its development, some core components later became other core projects and services independently, the core status of Nova itself is also very high, because friends who understand the basic theory of OpenStack all know that OpenStack is an IaaS (infrastructure as a service) cloud computing service. Its core service resources are computing, storage and network, and computing services are in the first place. In the deployment of OpenStack cloud platform, it is through the Nova project to achieve its computing services.

There is a specific reason why the preface of ​ says that Nova project is one of the most core projects for OpenStack from a macro point of view. In the early version of OpenStack, the project was not planned at once, while the Nova project included storage and network in itself at the initial stage, as well as nova-volume and nova-network modules, that is, later independent Cinder (block storage service) and Neutron (network service).

1.2 the development process and specific functions of Nova

From the original intention of providing cloud providers with solutions to implement IaaS services, the ​ Nova project has been optimized and upgraded to focus on large-scale scalability, high availability, flexible services, and self-service. At the beginning of the establishment of the OpenStack project in 2010, the Nova project was mainly divided into three functional modules: Nova-Compute, Nova-volume and Nova-network. When the Folsom version of OpenStack was released in September 2012, the OpenStack community built the Cinder and Quantum projects separately from Nova-volume and Nova-network (later renamed the Neutron project for trademark reasons).

​ in summary, Nova is the core project that runs as a set of daemons on the Linux server. Of course, you also need to rely on other services to achieve the function, the following explanation will focus on the principles. Its specific functions are: responsible for managing the life cycle of the instance virtual machine, network management, storage volume management. Nova supports the creation of virtual machines, bare metal servers (through the use of ironic), and the usage limit of Nova computing resources is limited on a project-by-project basis.

​

II. The main components of Nova

Like Keystone, ​ Nova has its own functional modules. It is composed of service processes responsible for different functions. The service interface provided by Nova is REST API, and the communication between its internal component modules is based on RPC (remote procedure call) message delivery mechanism.

​, let's take a look at some of the main components that make up Nova:

2.1 Nova-API

​ Nova API service component. Receives and responds to an end user's request for a computed API call, and when it receives the request, it is usually forwarded to other components of the Nova for processing, such as Nova-scheduler.

​ follows specific policies and initializes most orchestration operations, such as creating instances.

2.2 Nova-API-Metadata

​ Nova API service component. Nova-API-Metadata services are primarily used to receive metadata requests from instances.

2.3 Nova-Compute

​ Nova core service components. Nova-Compute is a worker process that creates and terminates instances through Hypervisor API (Hypervisor will be covered in a later architecture). Earlier, the author mentioned in the process of introducing the types of OpenStack nodes, but at that time, taking into account the degree of understanding, did not elaborate. Here is a detailed explanation.

​ when we deploy OpenStack computing services, we usually choose to deploy Nova-Compute separately on a physical server that supports virtualization, which we call a compute node. Common Hypervisor API includes Libvirt API that supports KVM/QEMU virtualization engine, XenAPI for XenServer / XCP virtualization engine, and VMware API that supports VMware virtualization engine. In general, OpenStack uses the KVM virtualization engine by default, so Libvirt API is the most commonly used in Nova-Compute.

​ in short, the main function of Nova-Compute is to receive requests from message queues and then execute the corresponding system commands. For example, start the KVM instance and update its status in the database.

2.4 Nova-Scheduler

​ Nova core service components. It is mainly responsible for getting virtual machine instance requests from the queue and determining which compute node host it is running on. It adopts the algorithm of filtering compute nodes, that is, filtering according to the parameters such as CPU, memory and disk of computing nodes. You can also specify the filtering algorithm by customizing and editing the nova.conf file.

2.5 Nova-Conductor

​ Nova core service components. The main purpose of Nova-Conductor is to enable interaction between Nova-Compute services and databases (cloud databases). In other words, with Nova-Conductor, in actual operation, it eliminates the direct access of Nova-Compute services to the cloud database, but realizes the access to the database through Nova-Conductor.

​ in addition, this component supports horizontal scaling to multiple nodes to run at the same time (Nova is deployed as Cell when scaling horizontally), but it cannot be deployed to the compute node running Nova-Compute, otherwise the isolation between Nova-Compute and database cannot be achieved.

2.6 Nova-Cert

​ Nova core service components. Nova-Cert is a server waiting process that mainly provides services for Nova Cert based on X509 certification.

2.6 Nova-NoVNCproxy

​ is a virtual machine console service. The main purpose is to provide proxies for accessing running instances over VNC connections. Support for browser-based NoVNC clients.

2.7 Nova-Spicehtml5proxy

​ is a virtual machine console service. Primarily provides proxies for accessing running instances over SPICE connections. Support for browser-based HTML5 clients. Spice is one of the main components of Redhat open source virtualized desktops, which can provide exactly the same end-user experience as physical desktops. The virtual machine desktop access method used by Open-Stack official documents is NoVNC by default. If you need to enable SPICE protocol, you need to disable NoVNC.

2.8 QUEUE

Core components other than ​ Nova. The center of message exchange and delivery between component processes, generally implemented in RabbitMQ.

2.9 Datebase

Core components other than ​ Nova. Stores the creation-time and runtime state of objects in the infrastructure, including:

Available instance types; instances in use; available networks; projects.

​ theoretically, OpenStack Compute can support any database supported by SQLAlchemy. Common databases are SQLite3,MySQL,MariaDB and PostgreSQL for testing and development work.

​ warm Tip: for beginners to understand Nova components, the key point is to understand the previous 6 components.

III. Architecture understanding of Nova 3.1 carding of Nova logical architecture diagram

The last two sections of ​ mainly introduce the conceptual role and composition of the Nova project. This section takes a look at the relationship between these components, that is, the logical architecture diagram of Nova.

​ the architecture diagram represents the computing services provided by OpenStack, which are supported by various functional component modules of the Nova project.

Most of the components of ​ are introduced in the previous section. Among them, nova-consoleauth is also a virtual machine console service, which mainly provides authentication and authorization services for virtual machine console connections. Do not confuse it with nova-console in the upper right corner. Nova-console is a XenAPI-style console service that is almost no longer used for most VNC agent software.

​ may be confused by the Hypervisor in the lower right corner of the image above. Like the Cell mentioned above, it is impossible to explain the two clearly in a few words. The author mainly explains its role here.

​ Hypervisor is the software layer running between the physical server and the operating system, which mainly dispatches the requests of the client system for the use of shared physical hardware resources. It is the foundation of virtualization and the core foundation of cloud computing. So the above Nova-Compute components rely on the call of Hypervisor API to create and terminate the instance.

​ and cell, this function module is mainly to solve the cluster bottleneck problem in the process of large-scale Nova computing node deployment, which involves the difference between traditional cluster architecture and cloud computing architecture. Interested friends can consult the information. The problem is that the performance of the shared message queuing system is greatly reduced in large-scale computing node deployment clusters (hundreds, more than 500). With the Cell module, the foundation has the ability to support horizontal expansion and large-scale deployment of OpenStack computing nodes. This paper does not focus on again, and the specific principle and implementation process of Cell are not introduced in detail here.

​ in addition, through the architecture logic diagram, we can find that when Nova passes through the corresponding services, the communication between the various component services is realized through QUEUE, and the general default is RabbitMQ. In fact, through the previous articles, it is not difficult to find some rules (personal understanding or discovery). In OpenStack, in most cases, communication generally defaults to message queuing, the database defaults to Mariadb database, and the calling interface is generally based on REST-style RESTful API.

The figure above in ​ is just an architectural diagram of the Nova project itself, so what is the architecture of Nova and other services? In fact, the example given in the previous article when describing the Keystone work response process includes the service capabilities provided by Nova. There is not much description here.

​ is interspersed with some of the structures and components of the Cinder and Neutron projects to illustrate the logical architecture between Nova and both.

3.2 logical architecture between Nova, Cinder and Neutron

Why does ​ give the logical architecture of these three here? On the one hand, it is to deepen the understanding of Nova and the relationship between it and some other projects, such as the way of communication, etc., on the other hand, it is the development of Nova. As mentioned earlier, in the original OpenStack project, Nova includes block storage and network, but now they are separated into two projects, corresponding to OpenStack Block Service and OpenStack Networking services.

It doesn't matter if ​ is not familiar with Cinder and Neutron components. Here you can mainly understand the meaning of the three dotted lines in the figure above. The fourth section will briefly describe the working principle of Nova through a case study.

Among the ​, the top dotted line represents the communication relationship between Nova-Compute and the network service Neutron-server. Neutron-server is the OpenStack network service that provides the corresponding API as the entrance to Neutron, which means that Nova needs to use the network services provided by Neutron to provide services for the communication between virtual machine instances and between virtual machine instances and the external network.

The two dotted lines below the ​ represent the communication mode between the Nova service and the block storage service, with interfaces provided by volume and scheduler in the cinder, which means that Nova needs to use the Cinder service to provide the block storage service as the disk of the virtual machine instance. Later, the author will continue to update the articles on each core project, will introduce in detail the relevant knowledge of Cinder and other projects such as the Neutron project.

​

Warm Tip: AMPQ: advanced message queuing protocol, which can be understood as a communication protocol.

Fourth, the working principle of Nova

​ in fact, the above also more or less related to the workflow of Nova and some principles, here through a case combined with the diagram to explain the understanding of the internal working mechanism of Nova.

​ assumes that users need to create a virtual machine, so the services provided by other projects involved here are skipped as far as possible, which is easy to understand:

After obtaining authentication through the console (or other means such as the command line), the user sends a request "Please create a virtual machine instance for me" to the Nova-api in the Nova service. After receiving the request, the Nova-api authenticates, then carries on the necessary processing, and then stores the message creating the virtual machine instance in the queue. Nova-scheduler receives the message from the message queue, starts scheduling, selects a node from many compute nodes, and stores the information of "allow virtual machine instances to be created on compute node 1" in the queue; after the Nova-compute of compute node 1 obtains this information, it starts to create virtual machines on its own nodes. While creating a virtual machine, the computing node can send a message querying the information of the database to the Nova-Conductor through the message queue. After receiving this information, Conductor will visit the database and give a response message.

​ uses the above case to sort out the relationship between the components of Nova while understanding its internal working principle.

However, during the operation of the actual OpenStack system, the Nova computing service needs to interact with other services, such as the identification and authentication process of identity permissions by interacting with the authentication and authorization service Keystone, and providing the system image for the instance through OpenStack's mirror service Glance, while users and cloud administrators interact with Nova through OpenStack's control panel service Horizon, and so on.

5. Summary of Nova theory

​ this paper mainly introduces the concept overview and development process of Nova project, introduces in detail the concept and function of core components in Nova, gives the logical architecture diagram of Nova itself and its logical architecture relationship with block storage service and network service, and finally introduces the working principle and working process of Nova through a simple case.

​

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.