问题导读1.countable资源是指哪些？2.noncountable资源，本文列举了什么资源？3.标签是否为资源？4.如何实现扩展YARN资源模型？转载注明来自about云本文链接:
http://www.aboutyun.com/forum.php?mod=viewthread&tid=23794 概述当前Yarn支持各种资源类型：比如：disk( YARN2139),https://issues.apache.org/jira/browse/yarn-2139network( YARN2140),
https://issues.apache.org/jira/browse/YARN-2140 和HDFS bandwidth( YARN2681).https://issues.apache.org/jira/browse/YARN-2681本文档提出了将YARN资源模型扩展为更加灵活的模型，使其更容易添加新的countable类型的资源。它还考虑了“resource profiles”的相关方面，这些资源配置文件允许用户容易地指定它们需要的容器资源。当添加对新资源类型的支持时，有两个方面需要考虑调度和隔离。 本文档仅涉及调度方面。
背景在YARN中添加一个新的countable资源类型是一个相当复杂的过程。 需要进行大量的工作来修改ProtocolBuffers文件以及相应的Java源代码。 这必须通过修改 DominantResourceCalculator类添加对新资源类型的支持。 另外，许多不相关的测试用例都必须修改，因为他们使用了esource.newInstance（memory,，vcores)）函数。此外，大多数新的资源类型被视为相同，只是名称不同而已。 总而言之，需要修改37个源文件来增加对新磁盘资源类型的支持;而对于未来的资源类型，类似的（可能更大的）将不得不进行修改，而且大部分更改将与之前的更改相同， 唯一的区别是变量的名称。我们建议更改资源模型以支持可由群集管理员定义的任意、countable资源。 当我们谈到countable资源时，我们指的是资源的分配和释放是一个简单的减法和加法操作的资源类型。 我们不会在此版本的文档中涵盖专用资源，如端口【ports】或不可数量【noncountable】的资源（如标签）。 然而，我们的建议并没有排除增加对标签等资源类型的支持，这种工作可以作为未来工作的一部分来进行。
扩展YARN资源模型ResourceManager在我们提出的模型中，我们添加一个新的配置文件“resourcetypes.xml“，管理员可以使用它来添加新的资源类型。 ResourceManager（RM）“resource-types.xml”来确定启用调度的资源类型集合。 这些配置可以在yarn-site.xml配置，但是在一个单独的文件中指定它们可能会更清晰。 资源配置文件必须包含内存和vcore作为资源类型以防止功能的任何损失。 管理员可以添加任意新的资源类型，只要他们代表的资源是countable。resource-types.xml样例如下[XML] 纯文本查看 复制代码?
“yarn.io/memory”和“yarn.io/cpu”映射到YARN当前支持的现有内存和vcore资源类型。 资源名称与Kubernetes资源模型中的资源名称相似（链接位于参考部分）。NodeManager类似的，我们建议添加一个新的文件“nodere-sources.xml“，来指定节点的资源使用量。跟“resource-type.xml”类似，这些配置可以在yarn-site.xml文件中设置。但是在单独的文件中指定它们可能会更清晰。下面是node-resources.xml样例[XML] 纯文本查看 复制代码?
NodeStatusUpdaterImpl类将被修改为报告“noderesources.xml”文件中指定的所有资源的值，而不仅仅是当前的内存和CPUResource类和DominantResourceCalculator建议在Yarn的资源模型添加新的函数。[Bash shell] 纯文本查看 复制代码?
弃用[Bash shell] 纯文本查看 复制代码?
ResourceTypeInformation类的定义是：[Bash shell] 纯文本查看 复制代码?
其中resource-types是可能资源类型的枚举（“countable”“是目前唯一支持的类型）。 另一个限制是“name”字段必须是唯一的。 name字段将作为标识符。 这是为了避免两个资源类型具有相同的名称但不同的单位或类型而导致混淆的情况。 “enabled””字段允许管理员轻松启用或禁用资源类型。 目前，“units”字段有两个目的：1.它将在NM注册期间使用，以确保RM和NM使用相同的单元。2.文档ProtocolBuffers定义的相应改变是：[Bash shell] 纯文本查看 复制代码?
当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”，它将包含所有的信息为调度启用的资源类型。 建议的修改如下：[Bash shell] 纯文本查看 复制代码?
将以下API添加到RegisterApplicationMasterResponse类：[Bash shell] 纯文本查看 复制代码?
我们建议弃用[Bash shell] 纯文本查看 复制代码?
和[Bash shell] 纯文本查看 复制代码?
后续更新，转载请注明链接
http://www.aboutyun.com/forum.php?mod=viewthread&tid=23796
