Earlier I had shared an article with the steps to configure ceph storage cluster in OpenStack. Now let me give you some brief overview on the nova compute architecture and how all the services within nova compute communicate with each other. What is the role of each service under nova compute? What is the role of nova-api, nova-scheduler, nova-console, nova-conductor, nova-console-auth, nova-compute service in OpenStack?

Understanding nova compute architecture in Openstack (with flow chart)

 

Understanding nova compute architecture (Flow Chart)

The compute service consists of various services and daemons including the nova-api service, which accepts the API requests and forwards them to the other components of the service.

 

The following diagram shows how various processes and daemons work together to form the compute service (Nova) and interlink between them:

nova compute architecture

 

Understanding nova compute services

Below are the list of services which are part of nova compute service:

 

nova-api service

  • All services in OpenStack have at least one API process that accepts and responds to end user API calls, pre-processes them, and passes the request to the appropriate process within the service.
  • For the OpenStack compute service, we have the nova-api service, which listens and responds to the end user compute API calls. The nova-api service takes care of initiating most orchestration activities, such as provisioning new virtual machines.

 

nova-api-metadata service

  • The metadata service delivers the instance-specific data to the virtual machine instances. The instance-specific data includes hostname, instance-id, ssh-keys, and so on. The virtual machine accesses the metadata service via the special IP address at http://169.254.169.254.

 

nova-compute service

  • Underneath, the entire lifecycle of the virtual machine is managed by the hypervisors. Whenever the end user submits the instance creation API call to the nova-api service, the nova-api service processes it and passes the request to the nova-compute service. The nova-compute service processes the nova-api call for new instance creation and triggers the appropriate API request for virtual machine creation in a way that the underlying hypervisor can understand.
  • For example, if we choose to use the KVM hypervisor in the OpenStack setup, when the end user submits the virtual machine creation request via the OpenStack dashboard, the nova-api calls will get sent to the nova-api service. The nova-api service will pass the APIs for instance creation to the nova-compute service. The nova-compute service knows what API the underlying KVM hypervisor will support. Now, pointing to the underlying KVM hypervisor, the nova-compute will trigger the libvirt-api for virtual machine creation. Then, the KVM hypervisor processes the libvirt-api request and creates a new virtual machine.
  • OpenStack has the flexibility to use multi-hypervisor environments in the same setup, that is, we could configure different hypervisors like KVM and VMware in the same OpenStack setup. The nova-compute service will take care of triggering the suitable APIs for the hypervisors to manage the virtual machine lifecycle.

 

nova-scheduler service

  • When we have more than one compute node in your OpenStack environment, the nova-scheduler service will take care of determining where the new virtual machine will provision. Based on the various resource filters, such as RAM/CPU/Disk/Availability Zone, the nova-scheduler will filter the suitable compute host for the new instance:

nova compute architecture

nova-conductor module

  • The nova-compute service running on the compute host has no direct access to the database because if one of your compute nodes is compromised, then the attacker has (almost) full access to the database. With the nova-conductor daemon, the compromised node cannot access the database directly, and all the communication can only go through the nova-conductor daemon. So, the compromised node is now limited to the extent that the conductor APIs allow it.
  • The nova-conductor module should not be deployed on any compute nodes, or else the purpose of removing direct database access for the nova-compute will become invalid.

 

nova-consoleauth daemon

The nova-consoleauth daemon takes care of authorizing the tokens for the end users, to access a remote console of the guest virtual machines provided by the following control proxies:

  • The nova-novncproxy daemon provides a proxy for accessing running instances through a VNC connection.
  • The nova-spicehtml5proxy daemon provides a proxy through a SPICE connection

 

nova-cert module

  • Used to generate X509 certificates for euca-bundle-image, and only needed for the EC2 API.

 

The queue (AMQP message broker)

  • Usually, the AMQP message queue is implemented with RabbitMQ or ZeroMQ. In OpenStack, an AMQP message broker is used for all communication between the processes and daemons of one service. However, the communication between the two different services in OpenStack uses service endpoints.
  • For example, the nova-api and nova-scheduler will communicate through the AMQP message broker. However, the communication between the nova-api service and cinder-api service will carry through the service endpoints.

 

Database

  • Most of the OpenStack services use an SQL database to store the build-time, and run-time states for a cloud infrastructure, such as instance status, networks, projects, and the list goes on. In short, we could say the database is the brain of OpenStack.
  • The most tested and preferable databases to use in OpenStack are MySQL, MariaDB, and PostgreSQL.

 

Lastly I hope this article on understanding nova compute architecture on OpenStack was helpful. So, let me know your suggestions and feedback using the comment section.

 

References:
OpenStack Bootcamp

 

Leave a Reply

Your email address will not be published. Required fields are marked *