Table of Contents
Hello everyone! You know that currently, we are discussing each component of OpenStack through series of Blogs. So today we are going to look at the overview and the architecture of the new component of the OpenStack which is Workflow (Mistral).
Therefore without wasting too much time, let’s start with what exactly Mistral is?
OpenStack Workflow Mistral:-
As the name is self-explanatory, which means Mistral is a workflow service, it is seen that a lot of businesses consists of several individual processes which are interrelated to each other through various steps which required to be carried out in a specific sequence within an allocated environment. Every user describes these processes as a group of assignments or tasks and their transformations.
Thus a description of these tasks and their transformations are created and uploaded to Mistral. Mistral will then pay attention towards the state management, setting right execution order, resemblance, coordination, and their usefulness.
Mistral can also offer adaptable scheduling for these processes or tasks thereby Mistral can execute the processes as per the particular schedule rather than executing it instantly. For example, if any process is scheduled for every Monday at 6:00pm, then Mistral will run that process as per the scheduled time.
As per the Mistral verbalism, this group of assignments or tasks and the interrelationship between them is referred to as Workflow.
Uses of Mistral: –
- Mistral can be used by a user for setting several processes that are to be executed at a specified time: –
In simple words, we can say that a user can use Mistral for task scheduling or process scheduling. These scheduled tasks are mostly executed inside a cloud. As discussed earlier, there are several processes such as running shell scripts or binaries according to the particular instances for convoking the REST APIs so that the REST APIs are also accessible in the cloud environment. There are some other tasks which are also connected to cloud management like, creating or ending instances.
Therefore it is important that multiple tasks can be grouped together in a single workflow and then executed them in a specified scheduled manner and Mistral will look after their corresponding execution in case if it is naturally possible and it will also look after the fault resistance. Mistral will also serve workflow monitoring capabilities or can manage workflow execution like a resume, stop, current status, statistics related to the errors and the stuff like that.
- Installing cloud environment:
Mistral can be used by a user for specifying the workflows required for installing cloud environments containing several Virtual Machines as well as multiple applications.
- Executing complex business processes: –
For executing complicated multi-phase business processes and also for making it fault resistant a user can make a request thereby if the execution of the process fails at any point on a particular node, in that case, any other active node present in the system can take on from there automatically and from that same point where that process failed starts to execute it.
Same as before, a user divides the business processes into a group of assignments and makes the Mistral manage them, with the implication that the Mistral will work as an administrator and finalizes what specific task must be started at a what time. Thereby Mistral returns back with “execution plan 1, data is here”. In this case, if one application fails to execute plan 1, then another active node will take over it and continue the process.
- Data crawling & presenting the report: –
Mistral can be used as a tool by a data analyst for data analysis. For instance, while preparing a report for example financial report, then the complete group of steps required for collecting and preparing the necessary report may be represented in the form of a graph associated with the Mistral processes. In other cases, Mistral ensures to provide fault resistance, scalability, and availability.
- Real time migration: –
When a specific event gets triggered upon from Ceilometer, a user can specify several processes for the Real-time migration of the virtual machine.
Explanation: –
Following major points are included in the central idea behind the Mistral service:
- Capabilities to communicate with customized workflow description.
- Mistral service may not itself perform the real execution process but this service may instead work as an administrator for different processes which actually performs the work of process execution and also provides back the notifications about the results of the process execution. In simple words, the process execution can be serial therefore allowing flexibility at the time of any particular domain handling and chances for making the Mistral service highly scalable as well as available.
- Mistral service supplies the concept of process action, which is a part of the logic to which a workflow process is connected with. For the convenience of the user, Mistral service offers an unconventional group of actions. Whereby, a user may create customized actions on the basis of the standard action set.
The architecture of Mistral:
We have already seen that Mistral is a workflow service and the major goal of the service is to support the ability to describe, run and manage processes and customized workflows instead of writing code.
Basic Facts:
Following are some of the basic facts related to the Mistral architecture that one must consider before learning about Mistral architecture:
- Workflow:
The workflow contains process/ processes defining which precise steps need to be taken at the time of executing a workflow.
- Task:
It is task which is accomplished inside a workflow description.
- Action:
Task done when a particular process is stimulated
Major components involved in composition of Mistral:
- Engine
- API Server
- Notifier
- Task Executors
- Persistence
- Scheduler
The architecture of mistral:
- Engine:
Workflows from the workflow queue are picked up by the Engine. It also manages and controls the flow of data during the execution of workflows. Engines also maintain the record of processes which are ready and place them accordingly in a process queue. Engines also transfer the data from process to process and also take care of condition transformations, etc.
2. API server:
The API server gives access to the REST API for operating and monitoring the execution of the workflow.
3. Notifier:
Once a task or a workflow completes execution, actions are released at specific points for instance, when the execution of the workflow is completed. The Notifier then directs the actions towards the arranged publishers. The Notifier can be constructed either to execute provincially on the workflow engine or may also be run as a server just like the distant executor server and hears for the actions.
When Notifier is executed as a distant server, it makes sure that the workflow engine immediately opens and restarts the work. The action or event publishers are customized plugins that can note down the actions or events into a webhook available over HTTP, or a listing in a log file, or a message to Zaqar, etc.
4. Task Executors: –
The task actions are executed by a task executor as well as it takes up the tasks present from the task queue, runs the events and notifies the results back to the engine.
5. Persistence: –
The workflow definitions, state of current execution and results of the past execution are stored in the Persistence.
6. Scheduler: –
A scheduler is one of the important components of the Mistral as it communicates with the engine and the executors. It also stores and runs behind schedule calls. Workflows events are activated by the Scheduler, for instance, frequent cron event.
Summary:-
In today’s blog we have gone through an overview of a Mistral and also saw the architecture of it. I think you find this information helpful. Please do not forget to leave a comment in the comment section below. Thank you for reading the blog! We’ll see you soon with another blog on another interesting topic!
People also read: –
