OpenStack Nova

OpenStack Nova

Brief introduction

OpenStack Nova is responsible for the maintenance and management of cloud computing resources of
Nova group as a daemon thread to provide services on an existing Linux server
Nova by multiple server processes, each process perform different functions
user-oriented interface is REST API , while Nova internal components communicate via message passing RPC

The following additional services needed to achieve the basic functions:

  • Keystone: provide authentication (identity and authentication) for all OpenStack services
  • Glance: providing image repository calculates (compute image repository), calculated by the calculation examples all start image
  • Neutron: responsible for configuring the connection to the calculation example when the virtual or physical network
  • Placement: tracking the cloud list of available resources and to help select when creating a virtual machine resource provider

Nova includes the following components:

API

nova-api as the only external components window Nova, Nova expose functionality that can be provided to customers. When a customer needs to perform operations related to virtual machines, and can only send REST requests to nova-api

nova-api service

Receiving and responding to end user of the API call

nova-api-metadata service

Receiving a request from a data source instances
are usually used only in multi-master mode attached nova-network service

compute core

nova-compute service

Virtual machine management core services, and virtual machine life-cycle management by calling Hypervisor API

nova-scheduler service

Scheduling service virtual machine, the virtual machine instance acquisition request from the queue, and determines that it is running on a computing node which

nova-conductor module

Interaction between mediation nova-compute service and database, make nova-compute service does not directly access to the cloud database
it should not be deployed on the run nova-compute service node

console interface

nova-console

Users can access the virtual machine console in several ways:
Nova-novncproxy, Web-based browser VNC access
nova-spicehtml5proxy, SPICE HTML5 browser-based access
nova-xvpnvncproxy, VNC Java-based access to end customers

nova-consoleauth daemon

Responsible for the virtual machine console access request Token authentication
must run this service for the console agent to take effect

Database

SQL database

Most cloud storage infrastructure to build and run the state, including:

  • Examples of the available types (Available instance types)
  • Examples (Instances in use) are being used
  • Available network (Available networks)
  • Project (Projects)

Message queue

The queue

For passing messages between daemons

A typical deployment Nova

Way to transfer information between key components and their Nova

Communication system

REST API server processes the request, usually it involves the database read / write, optionally sends RPC messages to other Nova service, and generating a response to the call REST.
RPC messaging is accomplished by oslo.messaging library, which is on a message queue abstract
most of the major components nova can run on multiple servers, and there is a message listener's RPC manager. One exception is the nova-compute, a process in which it is being run on virtual machines managed by hypervisor (except when using VMware or Ironic driver). Administrators can also choose to perform tasks on a regular basis.

database

Nova also be used between all the components (logically) centralized database shared. However, in order to ensure that the control plane can still be upgraded a previous version of nova-compute communicate with running, you can access the database through an object layer. Thus nova-compute the DB proxy request to the central manager nova-conductor called by RPC, instead of directly sending a request to the database

Creating the Process Virtual Machine

Nova can better understand how the various sub-services work together by creating a virtual machine core processes

  1. Customer (end-user can be OpenStack, may also be other programs) to API (nova-api) sends a request: "Create a virtual machine"
  2. API request to do some necessary treatment, sent a message to the Messaging (RabbitMQ): "Let Scheduler to create a virtual machine"
  3. Scheduler (nova-scheduler) obtained from Messaging API message sent to it, and then performing a scheduling algorithm, node A is selected from a plurality of computing nodes
  4. Scheduler sends a message to the Messaging: "Creating the virtual machines on computing node A"
  5. Computing node A Compute (nova-compute) to obtain from the Scheduler Messaging message sent to it, and then starts the virtual machine on the local node Hypervisor
  6. In the process of the virtual machine created, Compute If you need to query or update the database information, will be the Conductor (nova-conductor) to send a message, Conductor is responsible for database access through Messaging

Guess you like

Origin www.cnblogs.com/dbf-/p/11531854.html