Mesos concept

Mesos Architecture

The diagram above shows the main components of Mesos. Mesos consists of a master daemon that manages the running of slave daemons on each cluster node, and mesos applications (also known as frameworks) that run tasks on these slaves.

Mesos master&slave First of all, Mesos is a distributed architecture. It is divided into Mesos master and Mesos slave, and slave and master have different responsibilities. From the source code of Mesos, it can be seen that Mesos is implemented more elegantly - it is a C++ code. There are a lot of keywords in the code called process, which is not a process in the traditional sense, but an abstract libprocess, and libprocess is its core library. If you have used Erlang's language before, you know that libprocess is actually an abstraction of Erlang's IO and communication model.

libprocess, also called process in Erlang, is actually a virtual process on the VM running Erlang. Its best feature is that messages are passed between different processes, it abstracts processes, and message passing is actually a library of events. Send a message to the process, the message is not directly sent to the process, but a process with a buffer in the middle.

The advantage of this is that it is especially suitable for distributed systems. The most commonly used method in the past is to monitor the network port. When a packet arrives, there is a module responsible for unpacking the packet. After unpacking a protocol, the protocol is sent to the next processing process. , this processing process may be an IO operation, may do other things, and then there are many IO blocks in it, and finally a response is constructed and passed to the client through a socket. This is the most commonly used way to write network programs, but there is a place for a large block on IO - the logic of subsequent processing depends on the logic of unpacking. If the processing logic is fast, but the unpacking logic is slow, it will slow down later, waiting for the unpacking.

Later, people thought of a way of IO processing, so that everything is separated, such as receiving a message from a certain port, there is a separate process, a thread or something else to handle the only request. This thread is very heavy, and then everyone invented some other things, such as a channel in golang and a process in Erlang. libprocess actually does the IO side of things, and Mesos makes heavy use of this model.

The bottom layer of ZookeeperMesos actually depends on Zookeeper, in order to ensure the eventual consistency of distributed storage. Some data is generated during the operation of Mesos, which will eventually fall on Zookeeper. Because Mesos has multiple masters, in order to meet the requirements of HA, as long as one master is alive, the entire service can be guaranteed.

protobufMesos selects the protobuf protocol in the communication. The advantage is that it is more popular, there are more libraries in each language, and the structured semantics are relatively strong, so Mesos chose protobuf internally.

Master uses Resource Offers to achieve cross-application fine-grained resource sharing, such as cpu, memory, disk, network, etc. The master decides how many resources to allocate to the framework according to a specified strategy, such as a fair sharing strategy, or a priority strategy. In order to support more diverse strategies, the master adopts a modular structure, so that new distribution modules can be easily added in the form of plug-ins.
The framework running on Mesos consists of two parts:
one is the scheduler, which obtains cluster resources by registering with the master.
The other is the executor process running on the slave node, which can execute the tasks of the framework. The Master decides how many resources to provide for each framework, and the framework's scheduler chooses which resources to provide. When the framework agrees to the provided resources, it sends the task to the slaves that provide the resources to run through the master.
An example of resource provision The following figure describes how a Framework runs a Task

event process through scheduling:
Slave1 reports to the Master that there are 4 CPUs and 4 GB of memory available The
Master sends a Resource Offer to Framework1 to describe how many resources are available to Slave1
FrameWork1 The FW Scheduler in the FW Scheduler will reply to the Master, I have two Tasks that need to run on Slave1, one Task needs <2 CPU, 1 GB memory="">, the other Task needs <1 CPU, 2 GB memory="">
Finally, the Master sends these Tasks to Slave1. Then, Slave1 still has 1 CPU and 1 GB of memory unused, so the allocation module can provide these resources to Framework2.
When Tasks are completed and there are new free resources, Resource Offer will continue to repeat this process. ,
When the thin interface provided by Mesos allows it to be extended and allows frameworks to participate relatively independently, a question will arise: How can the constraints of a framework be satisfied without Mesos being aware of these constraints?
For example, how does a framework get data localized without Mesos knowing which node stores the data needed by the framework? Mesos answers this question by simply pinning the framework's ability to reject offers. A framework will reject offers that do not meet its limit requirements and accept offers that meet its limit requirements.

In special cases, we find a simple strategy of delay scheduling, where the framework waits for a limit time to obtain nodes that store input data, and generates Closely optimized data points.

This article mainly shares the components and event flow of mesos. Next week will introduce the concept analysis and working principle of Mesos in detail. Stay tuned.