OpenStack Universal Design Ideas-play 5 minutes a day OpenStack (25)

API front-end services

Each OpenStack component may contain several sub-services, which must have an API service that is responsible for receiving customer requests.

In Nova, for example, Nova-api as a unique window to the Nova component, exposing the capabilities that Nova can provide to customers. When customers need to perform VM-related operations, they can and only send REST requests to NOVA-API. Customers here include end users, command lines, and other OpenStack components.

The benefits of designing API front-end services are: 1. Provide a unified interface to the outside, hide implementation Details 2. The API provides REST standard invocation services for easy integration with third-party systems 3. High availability of APIs can be easily implemented by running multiple API service instances, such as running multiple NOVA-API processes

Scheduler Dispatch Service

For an operation, if more than one entity can complete the task, there is usually a scheduler responsible for picking out the most appropriate one from those entities to perform the operation.

In the previous example, Nova has multiple compute nodes. When a virtual machine needs to be created, Nova-scheduler chooses the most appropriate compute node to run the VM based on the resource usage of the compute node at the time.

The scheduling service is like a project manager in a development team, and when a new development task is received, the project manager assesses the difficulty of the task, the current workload and skill level of the team members, and assigns the task to the most appropriate developer.

In addition to the Nova, the Block service component Cinder also has a scheduler sub-service, which we will discuss in detail later.

Worker Work Services

The dispatch service just assigns tasks, and the worker work service is the real task.

In Nova, this Worker is Nova-compute. The functional partitioning of Scheduler and Worker makes OpenStack very easy to scale:

1. Increase compute nodes (increase Worker) when compute resources are insufficient to create a virtual machine

2. When the customer's request volume is too large to dispatch, you can increase the Scheduler

Driver Frame

OpenStack is an open infrastracture as a Service cloud operating system that supports the industry's best technologies. These technologies may be open source free, or it may be a commercial charge. This open architecture allows OpenStack to be technically advanced and competitive without creating a vendor lock-in (lock-in).

Where does this openness of OpenStack manifest itself? An important aspect is the adoption of a Driver-based framework.

For Nova, for example, OpenStack's compute nodes support multiple Hypervisor. Includes KVM, Hyper-V, VMWare, Xen, Docker, LXC and more.

Nova-compute defines a unified interface for these Hypervisor, Hypervisor can plug and play into OpenStack in the form of driver by simply implementing these interfaces. Here's the Nova driver architecture

In Nova-compute configuration file/etc/nova/nova.conf, the Compute_driver configuration item specifies which Hypervisor the compute node uses driver

In our environment, because it is KVM, we are configuring the Libvirt driver.

I wonder if you remember when we learned Glance: OpenStack supports multiple backend to store an image. It can be local file system, Cinder,ceph,swift and so on.

In fact, this is also a driver architecture. The new storage method can easily be added to the backend support list as long as the Glance definition specification is met.

We will also see the application of the driver framework in the back Cinder and Neutron.

Messaging Service

In the process of creating a virtual machine earlier, we saw that the call between the nova-* sub-services was heavily dependent on Messaging. Messaging is the backbone of the nova-* sub-service interaction.

Students who have not been exposed to distributed systems before may not understand why the API calls scheduler directly, or let Scheuler call Compute directly, rather than Messaging. Here are some explanations.

There are usually two kinds of calls between programs: synchronous calls and asynchronous invocations.

Synchronous invocation

The interface that the API calls Scheduler directly is the synchronous call. It is characterized by the need to wait until the API makes a request, until Scheduler completes the dispatch of the Compute and returns the result to the API before the API can continue to do the work behind it.

asynchronous invocation

The API calls Scheduler indirectly through Messaging is called asynchronously. The feature is that the API does not need to wait after the request, directly return, continue to do the work behind. Scheduler executes the dispatch operation after receiving the request from Messaging and sends the result to the API via Messaging after completion.

In a distributed system such as OpenStack, an asynchronous invocation is often used, with the benefit of:

1. Each sub-service sub-service does not need to know where other services are running, just send a message to Messaging to complete the call.

2. improve performance asynchronous calls allow callers to wait for the result to return. This allows you to continue to do more work and improve the overall throughput of your system.

3. increase the scalability of the service can be scaled as needed to enable more instances to process more requests, Improves usability while improving the scalability of the entire system. And this change does not affect other sub-services, which means that the change is transparent to others.

In the following sections, we can see the application of Messaging.

Database

OpenStack components need to maintain their own state information. For example, Nova has a virtual machine in the specification, state, and this information is maintained in the database. Each OpenStack component has its own database in MySQL.

Summary

Nova is the most important component in OpenStack and is also a typical component. Nova fully embodies the design ideas of OpenStack. Understanding this idea, and then learning the other OpenStack components can be extrapolate, clear and much easier.

We will also review these design ideas in the study of Cinder and Neutron later.

OpenStack Universal Design Ideas-play 5 minutes a day OpenStack (25)