Yarn资源模型详解2

转载注明来自about云
本文链接： http://www.aboutyun.com/forum.php?mod=viewthread&tid=23796

【此篇与第一篇合并。替换为另外一篇】hadoop3.0扩展Yarn资源模型详解2：资源Profiles说明
http://www.aboutyun.com/forum.php?mod=viewthread&tid=23813


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


Resource类和DominantResourceCalculator
建议在Yarn的资源模型添加新的函数。
[mw_shl_code=bash,true]public static Resource newInstance(Map<ResourceTypeInformation, Long>resources)[/mw_shl_code]
弃用
[mw_shl_code=bash,true]public static Resource newInstance(int memory, int vcores)[/mw_shl_code]
ResourceTypeInformation类的定义是：
[mw_shl_code=bash,true]public class ResourceTypeInformation {
URI name&#894;
String units&#894;
ResourceTypes type&#894;
Boolean enabled&#894;
}[/mw_shl_code]


其中resource-types是可能资源类型的枚举（“countable”“是目前唯一支持的类型）。 另一个限制是“name”字段必须是唯一的。 name字段将作为标识符。 这是为了避免两个资源类型具有相同的名称但不同的单位或类型而导致混淆的情况。 “enabled””字段允许管理员轻松启用或禁用资源类型。 目前，“units”字段有两个目的：

1.它将在NM注册期间使用，以确保RM和NM使用相同的单元。
2.文档

ProtocolBuffers定义的相应改变是：
[mw_shl_code=bash,true]enum ResourceTypes {COUNTABLE = 0&#894;
}
message ResourceMapEntry {
string key = 1&#894;
int64 value = 2&#894;
string units = 3&#894;
ResourceTypes type = 4&#894;
}
message ResourceProto {
optional int32 memory = 1&#894;
optional int32 virtual_cores = 2&#894;
optional repeated ResourceMapEntry resource_value_map = 3&#894;
}[/mw_shl_code]
当NM向RM注册时，如果“resourcetypes.xml”中列出的资源类型与NM报告的资源（缺少资源类型，附加资源类型，不匹配单元，不匹配类型等）不匹配，则会引发异常 NM关闭。 应该注意的是，“noderesources.xml”没有“enabled”字段。 这是因为如果一个资源类型被启用或者不启用，那么它应该与NM无关。
存在的内存和CPU资源类型将分别映射到“yarn.io/memory”和“yarn.io/cpu”。 为了保持兼容性并确保功能没有丢失，“yarn.io/memory”和“yarn.io/cpu”将被指定为强制资源类型。 使用URI作为资源类型名称的决定是从Kubernetes派生的，它建议使用符合RFC 1123的域后跟“/”后，跟一个名称。

已经存在的Resource.newInstance(int memory, int vcores) 函数，将会改变切换为Resource.newInstance(Map<ResourceTypeInformation, Long>)函数。已经存在的getMemory(), setMemory(int memory), getVirtualCores(), setVirtualCores(int vCores) 函数。行为没有任何的变化，可以继续工作。在内部，这些调用将被映射为读/写“yarn.io/memory”和“yarn.io/cpu”元素。 Resource类中的hashCode函数将不得不进行修改，以考虑所有的资源类型。

DominantResourceCalculator将改变为执行具有在Map<ResourceTypeInformation, Long>中启用标志设置的每个资源类型的计算，而不是当前命名变量。

NodeStatusUpdaterImpl
今天，NMs将资源报告给NodeStatusUpdaterImpl中的RM。 一旦我们允许任意资源类型，NodeStatusUpdaterImpl将不得不读取“node-resources.xml”文件并报告在该文件中设置的资源值。

另外，可能会出现资源类型值的情况.需要访问节点资源（如/ proc文件系统）。 为了达到这个目的，我们需要修改NM来允许插件读取和处理这些信息。 目前，我们不打算为此增加支持。 但是，如果有强烈需求，必须加以支持，我们愿意接受。


添加或删除资源类型
由于新的配置文件和建议系统的结构方式，在添加或删除资源类型时，操作顺序非常重要。

当添加新的资源类型时，必须首先升级NM，然后再升级RM。 这就允许NM向RM注册而不会导致不匹配。

相反，在删除资源类型时，必须首先升级RM（删除资源类型），然后是NM。

RegisterApplicationMasterResponse
目前，我们在RegisterApplicationMasterResponse调度器中有一个字段resource_types可以被应用程序用来确定资源类型被RM用于调度。 但是，这个领域目前是一个枚举。我们建议弃用这个字段，并添加一个新的字段“scheduler_resource_types_info”，它将包含所有的信息为调度启用的资源类型。 建议的修改如下：
[mw_shl_code=bash,true]message RegisterApplicationMasterResponseProto {
optional ResourceProto maximumCapability = 1&#894;
optional bytes client_to_am_token_master_key = 2&#894;
repeated ApplicationACLMapProto application_ACLs = 3&#894;
repeated ContainerProto containers_from_previous_attempts = 4&#894;
optional string queue = 5&#894;
repeated NMTokenProto nm_tokens_from_previous_attempts = 6&#894;
// scheduer_resource_types is deprecated
repeated SchedulerResourceTypes scheduler_resource_types = 7&#894;
repeated ResourceMapEntry sceduler_resource_types_info = 8&#894;
}[/mw_shl_code]
将以下API添加到RegisterApplicationMasterResponse类：
[mw_shl_code=bash,true]public abstract Map<URI, ResourceTypeInformation>
getSchedulerResourceTypesInformation()&#894;
public abstract void setSchedulerResourceTypesInformation(Map<URI,
ResourceTypeInformation>)&#894;[/mw_shl_code]
我们建议弃用
[mw_shl_code=bash,true]public abstract EnumSet<SchedulerResourceTypes>
getSchedulerResourceTypes()&#894;[/mw_shl_code]
和
[mw_shl_code=bash,true]public abstract void
setSchedulerResourceTypes(EnumSet<SchedulerResourceTypes> types)&#894;[/mw_shl_code]
后续更新

big data