Mentioned in a paper called “Datacenter needs an Operating System” published at the University Of California. The expectations in the paper were roughly rounded up to the following points:
- Sharing of Data & Resources.
- Programming Abstractions.
- Debugging & Monitoring.
Mesosphere DC/OS, as a datacenter os, does the following above things for the user. The actual feeling you get when you use DC/OS is similar to an Operating System like Linux or Windows you use at least that’s what it expects to.
We’re going to talk about DC/OS and how it does what it does. The basic functionalities offered by DC/OS can be tailored down to the following:
- Distributed Systems – DC/OS includes a group of nodes they are coordinated by Master nodes.
- Cluster Management – management of resources used by tasks.
- Container Platform – For containerized tasks multiple container platforms are supported.
- Operating System – to abstract hardware and software underlying and also to provide basic services the apps running. Also, there is a separation between User and Kernel Space.
We’re gonna explore some of the layers, nodes, tasks, & how the system starts up.
Nodes are the physical/ virtual machines glued together with the help of network to form a cluster. Each node in the cluster has IP – to – IP connectivity with every other node for better communication. Each node in the cluster is required to have DC/OS.
There are 3 types of nodes:
- Master Node.
- Private Agent Node.
- Public Agent Node.
It is required to have each category of the node to put in a particular firewall group to have protected access.
Working with other master nodes in the cluster and manages the cluster. Master Node contains the bulk of DC/OS components including the Mesos master process. Master nodes are placed in Protected Zone. Master nodes can be publicly accessible or in a network zone that restricts access to improve security. Using VPN or by restricting a particular range of IPs we can achieve that.
User tasks which are supplied either through the DC/OS GUI or CLI run at these nodes include a Mesos Agent process. The agent nodes also contain certain DC/OS components like Master Node. Agent nodes can be further sub-divided into two categories based on which firewall group belongs to.
Private Agent Node: They are not accessed from outside the cluster. These nodes are configured to allow undifferentiated access to resources by tasks. These tasks are not accessible from outside the cluster. They are put in the Private Zone.
Public Agent Node: Allows ingress from outside the cluster through the cluster infrastructure network. Resources are differentiated depending on the task demands. These nodes are put in the Public Zone.
High Availability & Reliability
For availability DC/OS allows multiple master nodes to communicate. Leader Election is one such feature that allows traffic to be routed to the current leader. DC/OS allows the Quorum principle to be followed for example: If there are 3 master nodes it allows 1 one of the master node to go off.
DC/OS runs many different workloads, which are composed of tasks. These tasks are scheduled by a built-in scheduler or by a scheduler service running on DC/OS. These tasks are then put on the Mesos engine for execution and they are called Mesos Tasks.
Now we will discuss the two main constituents of the Mesos Framework.
Mesos Framework = Scheduler + Mesos Engine
Mesos tasks are, prior to being supplied with resources, put into the queue waiting to be executed at the Mesos Engine. Also, it allows for task abstraction so that users need not create them or interact with them.
There are 2 type of scheduler available
- Marathon Scheduler: provides services (Apps and Pods), which run continuously and in parallel.
- Metronome Scheduler: provides jobs, which run immediately or on a defined schedule.
User- Space Schedulers
These schedulers can be installed as scheduler services on Marathon via Mesosphere universe or directly via Marathon.
example: Kafka Scheduler provides Kafka broker, which run as lifecycle managed Kafka Nodes.
Executors are what get your work done on the Mesos Engine.
Built-In Executors – Mesos built-in executors are available to all schedulers, but schedulers can also use their own executors.
- Command Executor – execute shell commands or Docker containers
- Default Executor (Mesos 1.1) – execute a group of shell commands or Docker containers
Distribution Process Management
In this section, we are going to talk about how all the jargon we talked about interacts when a task comes up. We, as DC/OS users, have the ability to specify the job through the DC/OS GUI or CLI. Let’s see what happens through the help of an interaction diagram:
At a high level, this interaction takes place between the DC/OS components when a user launches a process. Communication occurs between the different layers, such as the user interacting with the scheduler, and within a layer, for example, a master communicating with agents.
Let’s see how it is done step by step:
- the Client needs to know how to connect to the Scheduler to launch a process, for example via Mesos-DNS or DC/OS CLI.
- Mesos master sends resources to offer to Scheduler: the resource offers are based on cluster resources managed through agents and the DRF algorithm in Mesos master.
- Scheduler declines resource offers because no process requests from Clients are pending. As long as no clients have initiated a process, the scheduler will reject offers from the master.
- The client initiates process launch.
- Mesos master sends the resource offers.
- If resource offer matches the requirements the Scheduler has for the process, it accepts the offer and sends a
launchTaskrequest to Mesos master.
- Mesos master directs Mesos agents to launch tasks.
- Mesos agent launches tasks via Executor.
- Executor reports task status to Mesos agent.
- Mesos agent reports task status to Mesos master.
- Mesos master reports task status to the scheduler.
- Scheduler reports process status to the client.
That’s it, for now, folks, We’re gonna look under the hood and explore the various components in the next part.
2 thoughts on “DC/OS: The Architecture #15 min read”
Comments are closed.