专栏名称: About云
about云-为热爱云开发技术人员提供最全面的信息传播和服务平台
目录
相关文章推荐
51好读  ›  专栏  ›  About云

Hadoop3.0扩展Yarn资源模型详解2:资源Profiles说明

About云  · 公众号  ·  · 2018-01-18 07:42

正文

问题导读

1.Resource profiles解决了什么问题?
2.使用profile的好处是什么?
3.配置文件的简洁模式如何配置?




上一篇hadoop3.0扩展Yarn资源模型详解1
http://www.aboutyun.com/forum.php?mod=viewthread&tid=23794


由于YARN添加了对其他资源类型的支持,指定和配置Container的资源分配变得越来越麻烦。 我们建议resource-profiles作为一个解决方案,允许用户提交作业,以方便地指定他们所需要的资源。

对于每种资源类型,管理员必须在yarn-site.xml中指定最小和最大分配,最终导致yarn-site.xml中的许多最小和最大分配属性。

在memory和vcores的情况下,最小分配也作为分配计算的步骤。 虽然这适用于memory 和 vcores,但未来可能不适用于资源类型。

另外,最小分配也起着默认分配的作用可能适合memory和vcores,但可能不适合其他资源类型。


从最终用户的角度来看,当前模型意味着指定调度程序知道的每个资源,特别是如果最小分配不满足可能导致请求超额资源的需求(在用户不知道其确切数量的情况下)。 如果调度器添加新的资源类型(例如,打开cpu调度的内存调度集群),现在用户必须为他的job找出vCore的正确值,而这个job目前运行良好,这将变得特别麻烦。 Resource profiles解决此问题
从本质上讲,我们允许集群管理员设置一个配置文件(“resource-profiles.xml“),可以让他们创建特定资源配置文件的简写。 再次,像这些配置文件“resource-types.xml”和“node-resources.xml”可以指定为“yarn-site.xml”的一部分。 这样的文件的一个例子:

[XML] 纯文本查看 复制代码

?

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
< configuration >
< property >
< name >yarn.scheduler.profiles name >
< value >pf1,pf2,pf3,pf4,pf5,pf6 value >
property >
< property >
< name >yarn.scheduler.profile.pf1.name name >
< value >minimum value >
property >
< property >
< name >yarn.scheduler.profile.pf1.yarn.io/memory name >
< value >1024 value >
property >
< property >
< name >yarn.scheduler.profile.pf1.yarn.io/cpu name >
< value >1 value >
property >
< property >
< name >yarn.scheduler.profile.pf2.name name >
< value >maximum value >
property >
< property >
< name >yarn.scheduler.profile.pf2.yarn.io/memory name >
< value >8192 value >
property >
< property >
< name >yarn.scheduler.profile.pf2.yarn.io/cpu name >
< value >8 value >
property >
< property >
< name >yarn.scheduler.profile.pf3.name name >
< value >default value >
property >
< property >
< name >yarn.scheduler.profile.pf3.yarn.io/memory name >
< value >2048 value >
property >
< property >
< name >yarn.scheduler.profile.pf3.yarn.io/cpu name >
< value >2 value >
property >
< property >
< name >yarn.scheduler.profile.pf4.name name >
< value >small value >
property >
< property >
< name >yarn.scheduler.profile.pf4.yarn.io/memory name >
< value >1024 value >
property >
< property >
< name >yarn.scheduler.profile.pf4.yarn.io/cpu name >
< value >1 value >
property >
< property >
< name >yarn.scheduler.profile.pf5.name name >
< value >medium value >
property >
< property >
< name >yarn.scheduler.profile.pf5.yarn.io/memory name >
< value >3072 value >
property >
< property >
< name >yarn.scheduler.profile.pf5.yarn.io/cpu name >
< value >3 value >
property >
< property >
< name >yarn.scheduler.profile.pf6.name name >
< value >large value >
property >
< property >
< name >yarn.scheduler.profile.pf6.yarn.io/memory name >
< value >8192 value >
property >
< property >
< name >yarn.scheduler.profile.pf6.yarn.io/cpu name >
< value >8 value >
property >
configuration >

上面的文件格式有点繁琐。 这主要是由于YarnConfiguration类限制。 下面在“配置文件格式”一节中讨论了更易于理解的备用文件格式。

这个例子设置了3profiles “small”, “medium”, 和“large”.“minimum”,“maximum”和“default”是由YARN保留的配置文件,允许管理员为每个资源类型指定最小【minimum】,最大【maximum】和默认【default】的分配。

当用户提交作业时,他可以指定一个配置文件【profile】名称,而不是指定每个资源类型。 如果没有提到【profile】配置文件,则使用“默认”profile。

这种模式的好处是,如果管理员决定启用新的资源类型,用户将不需要更新他们所有的job,管理员应该能够配置更好的profile.。 它还使得用户更容易请求资源;他们(希望)最终将在分配上做出更好的决定,因为在各种云平台上部署实例时,它们用于指定profile名称。 当我们添加对网络和磁盘作为资源类型的支持时,这变得特别有用,用户可能难以指定确切的需求。

该模型最终将所有资源分配相关配置收集到单个文件中,从而更易于管理。

如果用户除了profile,之外还为内存和/或CPU指定分配,那么这被看作是覆盖。 在以上详述的配置文件示例的情况下,并且使用分布式shell作为示例应用程序时,“—container_memory 3072 —container_profile small”表示您希望分配具有3072MB和1个vCore的container。 这也意味着指定memory和/或vcores的现有作业在memory和/或vcores的分配中应该看不到变化。 这种重写行为将只允许memory和CPU来保存现有的行为。 具体来说,我们建议如果一个应用程序执行以下操作:

[Bash shell] 纯文本查看 复制代码

?

1
2
3
4
5
6
7
8
ResourceRequest remoteRequest = ResourceRequest.newInstance(priority, hostname , capability, numContainers);
Map overrides = new HashMap<>();
ResourceMapEntry value =ResourceMapEntry.newInstance(“yarn.io /memory ”, 16 * 1024, “MB”,ResourceType.COUNTABLE);
overrides.put(new URI(“yarn.io /memory ”, entry));
Resource profileCapabilitiesOverrides =Resource.newInstance(overrides);
// targetProfile is the name of the profileProfileCapability capability =ProfileCapability.newInstance(targetProfile,
profileCapabilitiesOverrides);
remoteRequest.setProfileCapability(capability);



那么RM分配的最终能力将是配置文件中指定的资源,除了分配的内存将是16GB。 但是,如果应用程序不能同时使用capabilities和配置文件模型。 如上所述,覆盖将只允许内存和CPU。 我们还提出了一个配置标志来启用/禁用【enable/disable】覆盖(默认设置为启用覆盖),使用管理员可以关闭覆盖行为。
YARN的变化主要是ResourceRequestProto

[Bash shell] 纯文本查看 复制代码

?

01
02
03
04
05
06
07
08
09
10
11
12
13
14
message ProfileCapabilityProto {
string profile = 1;
ResourceProto profileCapabilityOverride = 2;
}
message ResourceRequestProto {
optional PriorityProto priority = 1;
optional string resource_name = 2;
optional ResourceProto capability = 3;
optional int32 num_containers = 4;
optional bool relax_locality = 5 [default = true
optional string node_label_expression = 6;
ProfileCapabilityProto string profile = 7;
}



还建议更改RegisterApplicationMasterResponse:

[Bash shell] 纯文本查看 复制代码

?

01
02
03
04
05
06
07
08
09
10
message RegisterApplicationMasterResponseProto {
optional ResourceProto maximumCapability = 1;
optional bytes client_to_am_token_master_key = 2;
repeated ApplicationACLMapProto application_ACLs = 3;
repeated ContainerProto containers_from_previous_attempts = 4;
optional string queue = 5;
repeated NMTokenProto nm_tokens_from_previous_attempts = 6;
repeated SchedulerResourceTypes scheduler_resource_types = 7;
optional ResourceProfilesProto resource_profiles = 8;
}


resourceprofilesproto定义在“Resource profiles API”部分。
当一个新的请求进入时,ApplicationMasterService查找注册profiles,,并使用profile中的设置来设置最终请求值。 这是在allocate(AllocateRequest request)函数本身完成的。 在进行完整性检查之前,在ResourceRequest中设置capability以考虑指定的配置文件【profiles】。 因此,我们不会预见对调度程序代码的其他方面的更改。

ClientRMService中必须执行类似的更改,以允许启动ApplicationMasters时使用配置文件【profiles】

Resource profiles API

为了让YARN客户端和应用程序masters知道可用配置文件列表,我们需要在RM中提供一个API。 建议添加以下API

[Bash shell] 纯文本查看 复制代码

?

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
Protocol Buffers
message ResourceProfileEntry {
string name = 1;
repeated ResourceProto resources = 2;
}
message ResourceProfilesProto {
repeated ResourceProfileEntry resource_profiles_map = 3;
}
RPC
class GetResourceProfilesRequest {
// empty class
}
class GetResourceProfilesResponse {
public Map > getAllResourceProfiles();






请到「今天看啥」查看全文