[Editor's note] Role is a very important concept in Mesos. Mesos defines the strategy for resource allocation among multiple frameworks around it. Before Mesos 0.26, the operator of the Mesos cluster can specify the Roles supported by Mesos by specifying the –roles parameter. A framework can only join the Mesos cluster through the roles supported by Mesos and receive the Resource Offer sent by Mesos. If a new framework needs to be added later, when the cluster operator needs to add a new role for it, he must restart all Mesos Master nodes to modify the --roles parameter, which is actually in the actual production environment. It is not desirable. In order to solve this problem, Mesos introduced the new feature Implicit Roles in version 0.27 to solve this problem.
Mesos Roles
Before introducing Implicit Roles, let's take a brief look at the role of Role in Mesos. In Mesos, roles are mainly used to configure resources between framework groups, that is, roles provide resource isolation between multiple tenants, and frameworks registered with the same role belong to one tenant. There are mainly the following cases related to role in Mesos:
1. Static allocation of resources. It means that when the Mesos agent starts, you can assign some resources to certain roles, or assign all resources to a certain role at one time. Then Mesos Allocator will allocate the resources on this agent to all frameworks registered under this role according to the DRF algorithm.
2. Dynamic allocation of resources. During the runtime of Mesos, the operator of the cluster can allocate some resources to some roles through HTTP endpoints.
3.Quota configuration. For example, a cluster operator can configure quota for a role to limit the number of resources used by all frameworks registered under this role, or configure quota to ensure at least how many resources are available for all frameworks registered under a role.
4.Weight configuration. Different weights can be set for different roles to modify the priority of resource allocation between them.
5. Configure the disk group. A persistent volume can be created for a role, so that frameworks that do not belong to this role can be isolated from using this storage resource.
Implicit Roles Past and Present
Before introducing Implicit Roles, let's take a look at its background. In order to support the issue of dynamically configuring roles during the runtime of the Mesos data center, the community started with the idea of introducing a new endpoint to support dynamic roles, allowing cluster operators to dynamically configure roles at runtime. The author of this article, as the proposal owner, briefly introduces the general design:
The endpoint looks like this:
$ curl -d JsonMessageBody –X POST http://<master-ip>:<port>/rolesFor example, if we want to add a role to the newly added framework, we can use the following
JsonMessageBody：
{
"name" : "sales",
"weight" : 2.0
}The weight parameter is optional, it indicates the priority of resource allocation for role1. If it is not specified in the above HTTP request, the system will use the default value (1.0). In the following chapters, we will discuss the weight-related features. To introduce, not much to explain here.
One of the main reasons why the community did not adopt this design was that it introduced a new endpoint, which was too cumbersome for cluster operators to operate, and did not have the simple design of Implicit Roles. If any reader is interested in Dynamic Roles, you can refer to the detailed design of this proposal:
https://docs.google.com/document/d/1OIgceqpsjV3-_LGF83IMAFnrh1Ea3Zc16w9kWWPpUj4/edit#
Implicit Role is literally an implied role, and its main idea is that the Mesos cluster operator will not need to configure a valid role list for the Mesos cluster, all possible roles (character set supported by role, length range) are allowed. Therefore, whether a new framework can use this role (such as sales) to register will mainly depend on the configuration of Mesos ACLs, and Mesos will not additionally verify whether this role is valid. That is to say, if a Mesos cluster is not configured with any ACLs, the framework can use any (note: but must be the character set and length supported by the role) role to register.
Summary of Implicit Roles Practice Issues
From the above introduction, I think everyone has a general understanding of Implicit Roles, but there are also many problems. From my personal understanding, if you want to use this new feature in practice, you need to pay attention to the problem :
Compatibility issues
As a rapidly evolving open source product, although Mesos has not yet reached a relatively stable version (V1.0), it has been applied to the production environment of many enterprises (such as foreign twitter, airbnb, Apple's siri, etc., domestic iQiyi, Douban, etc.), so when making major improvements to an important feature, we need to consider compatibility issues.
As mentioned above, before Implicit Roles was implemented, the operator of the Mesos cluster used the –roles parameter to configure the supported roles list when the Mesos Master started. The upper-layer framework can only use these roles to register Mesos. Implicit Roles is designed to take into account backward compatibility issues, it is implemented in two stages:
1. In the first stage, that is, in Mesos 0.27 version, Implicit Roles takes effect only when the Mesos cluster operator does not specify –roles when starting the Mesos Master. That is to say, this new feature in version 0.27 only changes the behavior of Mesos when the –roles parameter is not specified. If a static role list is specified when the Mesos Master starts, the Mesos cluster still maintains the original the behavior of. For further understanding take an example:
If you now have version 0.27 installed, but you specified --roles when starting the Mesos Master:
\# ./bin/mesos-master.sh --ip=127.0.0.1 --work_dir=/var/lib/mesos --roles="sales,enginers"Then Implicit Roles is disabled, and the upper-layer framework can still only use sales, engineers or the default role (*) to register to the Mesos cluster. At this time, the behaviors related to roles are the same as those before 0.26. For example, the cluster operator still cannot Reserve resources, configure quota, etc. for roles that are not supported in Mesos (that is, roles other than sales and engineers).
2. The second stage: that is, after a depreciation cycle, the devaluation cycle of Mesos is generally about 6 months. According to the cycle of Mesos release, about Mesos version 0.33, the –roles parameter will be discarded. If this parameter is specified when starting the Mesos master at that time, the Mesos master will fail to start, telling you that this parameter is not supported.
To sum up: that is, after Mesos 0.27 version, Mesos no longer recommends using the –roles parameter when starting the Mesos master. It is recommended to use the new feature of Implicit roles.
The issue of fairness in resource allocation
After reading the detailed explanation of Implicit Roles above, I think a direct question for everyone is that if the framework is allowed to register Mesos with any role, will it affect the fairness of Mesos for resource allocation? Will a bad citizen maliciously use more resources by registering multiple roles? People who know Mesos resource allocation may know that Mesos uses DRF allocator by default, which allocates resources between roles in a relatively fair principle. If a new role is added, it will inevitably affect the existing resource allocation pattern. . This problem of Implicit Roles is solved by Authentication and Authorization of Mesos.
The operator of the Mesos cluster can configure Authentication to ensure that only trusted frameworks can access the Mesos cluster. The current Authentication is mainly used in the following three aspects:
1. Require certification when farmeworks is registered.
2. Require computing node slaves to authenticate during registration.
3. Require cluster operators to authenticate when accessing the Mesos cluster using certain HTTP endpoints.
Authentication is not activated by default. The operator can activate Authentication by specifying the --authenticate, --authenticate_http and --credentials parameters when starting the Mesos Master. In this way, the Mesos cluster can avoid illegal frameworks to register the Mesos cluster. --credentials specifies a JSON-formatted file, for example:
{
"credentials": [
{
"principals": "swarm",
"secret": "passw0rd"
}
]
}In addition, Mesos cluster operators can configure Authorization to prevent the framework from registering with an invalid role. Mesos Authorization is implemented through ACLs (Access Control Lists). Each ACL specifies a subject (Subject) to indicate what operations (Actions) it can do to certain objects (Object). It is a configuration file in JSON format, for example:
{
"register_frameworks": [
{
"principals": {
"values": ["swarm"]
},
"roles": {
"values": ["docker-compose", "docker-client"]
}
}
]
} The above configuration means that only the framework whose principal is swarm can register the Mesos cluster, and it can only use docker-compose and docker-client as its roles. In this way, the upper-level framework can be prevented from registering with an illegal role.
In summary, in fact, in the actual production environment, the feature of Implicit Roles must be used in conjunction with the Authentication and Authorization of Mesos.
Impact of Implicit Roles on other endpoints
According to the understanding of traditional design, since role is an important entity of Mesos, Mesos
defines the rules for sharing resources between frameworks around it, so as the operator of the Mesos cluster, he/she should first create this in the Mesos cluster. role, and then configure weight, static/dynamic reservation, quota, create persist volume, etc. for this role, and then the framework can use this role and use the resources of the cluster according to the rules defined for it.
The design of Implicit Roles breaks this tradition, that is, it does not emphasize the order of operations above. That is to say, the operator of the cluster can set weight, reserve resources, set quota, etc. for a role that does not exist. Before Mesos 0.26, if you tried to operate on a role that didn't exist, it would fail. The endpoints affected by this behavior change are:
•/master/create-volumes //Create persistent volume for Role.
•/master/quota //Configure quota for Role
•/master/reserve //Reserve resources for Role
•/master/weights //Configure weight for a Role, This feature will be released in Mesos 0.28.
future outlook
In the current version 0.27 of Mesos, many configurations are not supported to be modified at runtime, such as Authentication, Authorization, Framework Meta information, and Agent configuration information. In the long run, as the next-generation data center operating system, Mesos must support dynamic configuration of both Master and Agent nodes at runtime. For example, it is possible to dynamically modify the Master/Agent commands while the Master/Agent is running. Line parameters; you can modify its Meta information, etc. when the Framework is running. Please pay attention to this year's Mesos Conference, there will be a special topic to introduce the dynamic configuration of Mesos.
As the main contribution organization of the Mesos community, the IBM Platform DCOS Team, combined with its rich practical experience in resource scheduling, integrates its own resource scheduling component EGO with Mesos, providing more scheduling strategies for the Mesos upper framework, as well as a centralized The Mesos cluster operator can configure the Global Resource Plan through this interface, which improves the experience of end users using Mesos.
http://geek.csdn.net/news/detail/59734