问题导读
1.网络作为Yarn的资源,有什么好处?
2.Yarn是否只支持调度和强制执行“传出流量”?
3.Yarn是否支持入口流量?
4.DistributedShell是否可以让用户指定网络带宽?
5.hadoop3.0网络设计存在哪些已知的问题?
开始在学习之前,其实需要一定的基础,因为Yarn里面使用了Linux TC和Cgroup。其实这两个不是新鲜的概念,很多人已经通过他们控制Linux流量,而这里hadoop官方将他们应用于Yarn。
那么什么是TC?Linux 流量控制程序
什么是Cgroup?Cgroups 是 control groups 的缩写,是 Linux 内核提供的一种可以限制、记录、隔离进程组(process groups)所使用的物理资源(如:cpu,memory,IO等等)的机制。有了这些基本认识,更多大家可搜索,后面about云将会补充一些相关内容。下文帮助大家了解Yarn的网络设计
介绍
作为在YARN上允许多个工作负载的一部分,我们需要首先添加对网络的支持使Storm等应用程序能够在YARN上运行。 例如,Storm,往往是网络I / O限制。 对于Storm在YARN上更可预测的运行,我们需要能够指定和执行带宽限制。 另外,增加网络作为资源将会也帮助其他应用程序,如MapReduce和Tez以更可预测的方式运行。
Network作为资源
网络作为一种资源,有两个方面应用程序需要考虑-带宽和网络每秒ops。我们决定增加支持(出站)网络带宽作为资源。网络有两方面,带宽的sustained速率和burst率。 “sustained” 率是container能够发送出站流量,而不会因NM应用强制规则而受到限制。尽管如此,取决于整体网络利用率,container 可以允许以更高的 “burst”率。这个“burst”的速度是不能保证的。container 分配请求只能包含一个“sustained rate”.”的请求。与CPU类似,集群管理员将被允许在执行方面启用或禁用(“burst”)。
注意,我们只会支持调度和强制执行“传出流量”,这是由于流量管制的限制。 有关其他详细信息,请参阅下面的内容。
调度
考虑到只建模网络带宽的决定,调度变得简单,类似于内存和CPU。所有NMS将报告可用带宽(以兆位/秒)到RM。
Resource类将被修改为接受网络带宽(以mbit / sec为单位)作为构造函数的一部分。 我们建议将函数签名更改为以下内容
[Bash shell] 纯文本查看 复制代码
?
1
2
|
public static Resource newInstance(int memory, int vCores, int
outboundNetworkBandwidth)
|
Getter和setter函数将被添加到Resource类中。 一个新的repeated的领域资源将被添加到ResourceProto。
[Bash shell] 纯文本查看 复制代码
?
1
2
3
4
5
|
message ResourceProto {
optional int32 memory = 1;
optional int32 virtual_cores = 2;
optional int32 outbound_network_bandwidth = 3;
}
|
当调度决策时,考虑outboundNetworkBandwidth,DominantResourceCalculator将会被修改。以下配置选项将可用:
1.yarn.scheduler.enablenetworkscheduling配置设置启用或禁用网络作为资源,允许管理员在他们认为合适的时候启用它。 如果将此设置设置为关闭,则会导致节点上的网络带宽向RM报告,但为了调度而忽略。
2.yarn.scheduler.minimumallocationoutboundnetworkbandwidthmbit,yarn.scheduler.maximumallocationoutboundnetworkbandwidthmbit设置最小和最大出站网络带宽分配。这些默认值分别为1 mbit / sec和1000 mbit / sec。
机架感知
当涉及到网络作为一种资源时,在分配过程中还有一个额外的考虑。 一些应用程序将启动相互通信的containers。在这种情况下,最好在同一个机架内启动contains。 在机架间通信的情况下,可能无法保证容器所需的带宽。 在这种情况下,将容器分配给可用带宽最多的机架将是有益的。
调度程序可以采用以下策略;
1.如果这是分配的第一个容器,请将其分配到网络最高的机架上可用的带宽。
2.如果此应用程序的容器已经分配,尝试在已经有容器的机架上分配容器。 如果这些机架上没有容量,请找到最适合容器的机架(按拓扑结构)。 虽然这可能不会导致最佳表现,但我们认为这是第一步适合的。 这个政策可以在将来重新审视。
机架信息已经通过配置core-site.xml中net.topology.script.file.name的配置字段。建议是使用这些信息并使用上面列出的政策。
执行
概述
关于执行,本文件仅限于:
1)只支持linux
2)仅出口流量。
关于入口流量的说明
与出站流量不同,入站流量不是以与出站流量相同的方式进行分区或标记的(有关出站流量整形的详细信息,请参阅下文)。 入口qdisc不是有效的,我们不能像出口流量一样使用细粒度的过滤器和规则。 另外,当流量到达入口qdisc时,网络带宽已经被消耗。 在这个阶段,如果某种入口策略已经到位,那么就没有队列(也没有延迟机制)可用,而数据包只是被丢弃。 由于这些原因,入口流量支持暂时还不在范围之内。
支持出口流量是通过两个方面实现:net_cl Cgroup系统和Linux流量工具TC
net_cls 2 cgroup 子系统
net_cls cgroup子系统允许我们使用称为“classid”的32位类标识符来“标记”传出的数据包。这个classid是在文件net_cls.classid(位于挂载的cgroup目录下)中指定的。 这个classid的值标识一个流量“句柄”,随后可用于流量整形。 对于每个需要网络调节的YARN容器,生成一个classid并写入相应cgroup的classid文件。
流量整形使用tc3
一旦标记就绪,tc shell实用程序(Traffic Control的缩写)就可以用来指定与正在使用的classid相对应的流量整形规则。 HTB4(分级令牌缓冲区)classful qdisc用于实现基于类id的流量整形5。
配置选项
为了执行一些配置项将在NM上可用。
1.yarn.nodemanager.resource.network.interface管理员可以指定YARN使用的网络接口(以及正在运行的应用程序)。 流量整形规则应用于此接口。 如果可能的话,这是自动确定的,但在检测失败或未配置的情况下默认为eth0。
2.yarn.nodemanager.resource.network.outboundbandwidthmbit管理员可以在节点设置 yarn-site.xml有效带宽.如果可能,默认带宽将自动确定。如果无法确定,它将被设置为1000兆位/秒的除非被管理员在yarn-site文件中配置重写覆盖。此值连同为Yarn容器分配的带宽(见下文)用于确定在YARN容器中不运行的进程的可用(保证)出站网络带宽的数量。 有关更多信息,请参阅NM启动部分。
3.yarn.nodemanager.resource.network.outboundbandwidthyarnmbit管理员可以设置YARN containers最大的总的可用带宽,在yarn-site.xml文件中.如果没有指定,将会默认为yarn.nodemanager.resource.network.outboundbandwidthmbit的值
4.yarn.nodemanager.strictresourceusage这是一个现有的配置参数,允许管理员指定允许的用法是“弹性的”还是“严格的”。 如果没有启用严格的使用,每个YARN容器的网络带宽利用率被允许“burst’”达到yarn.nodemanager.resource.network.outboundbandwidthyarnmbi值
验证配置——默认值和非默认值
配置在启动期间被验证(RM / NM)。 根据启用了网络调度的部署YARN的群集,默认配置可能无效(例如,eth0可能不是从属节点上的有效接口,或配置的最大接口带宽不正确)。 在这种情况下,默认值或指定的配置参数是无效的,网管将记录一个错误,并启动失败。
NM启动
一旦配置被验证,在NM启动期间执行以下操作:
1.安装net_clcgroup子系统
2.对于正在使用的网络接口,应用以下tc操作:
a.添加一个HTB队列规则(qdisc)
[Bash shell] 纯文本查看 复制代码
?
1
|
tc qdisc add dev eth0 root handle 10: htb
|
b.对于队列规则添加一个顶层类
[Bash shell] 纯文本查看 复制代码
?
1
|
tc class add dev eth0 parent 10: classid 10:1 htb rate 1000mbit default 3
|
c.启用过滤器基于classid
[Bash shell] 纯文本查看 复制代码
?
1
|
tc filter add dev eth0 parent 10: protocol ip prio 10 handle 1: cgroup
|
现在附加两个类,一个用于容器容器的最大允许流量,另一个用于剩余的带宽(默认类3)。默认的类有一个允许ceil相应的接口maxbandwidth,允许它使用所有可用带宽,如果不使用的话。
[Bash shell] 纯文本查看 复制代码
?
1
2
|
tc class add dev eth0 parent 10:1 classid 10:2 htb rate 700mbit
tc class add dev eth0 parent 10:1 classid 10:3 htb rate 300mbit ceil 1000mbit
|
要执行TC操作,我们需要root权限。我们将修改containerexecutor.c允许此功能。
创建一个Ccgroup和分配一个classids到Container
创建一个cgroup(为net_cls子系统)为每一个容器,每个容器被分配一个唯一的(未使用的)classid,用于标记源自这个cgroup的数据包。 例如 :
[Bash shell] 纯文本查看 复制代码
?
1
2
3
|
mkdir
/cgroup/net_cls/container_1
echo
$PID >>
/cgroup/net_cls/container_1/tasks
echo
0x100007 >
/cgroup/net_cls/container_1/net_cls
.classid
|
该功能将作为CGroupsLCEResourceHandler类的一部分来实现。
将基于classid的流量整形规则应用于指定的接口
一旦对容器进行cgroup相关的更改,具有所需速率的类就需要应用于htb树。 这里使用的classid需要与写入net_class.classid文件的classid相同。 取决于是否启用了严格的强制执行,还配置了“ceil”突发速率:
[Bash shell] 纯文本查看 复制代码
?
1
|
tc class add dev eth0 parent 10: classid 10:7 htb rate 50mbit ceil 700mbi
|
如上所述,containerexecutor.c将修改以添加对此功能的支持。
资源本地化,Shuffle,,日志聚合,HDFS
NM提供的某些共享服务可能会消耗大量的网络带宽,如资源本地化,日志聚合和shuffle.。 由于这些服务是由NM本身提供的,所以我们不能对它们应用容器特定的限制。 同样的问题也适用于HDFS。
有两个潜在的解决方案(在Linux上)
1.在一个CGroup(和一个关联的tc规则)下运行一个新的NM 配置参数控制NM可用的带宽量。 由于这将限制可用于NM的带宽量(否则,其不可用),所以可能会导致性能下降。 在这种情况下,HDFS带宽利用率(例如服务远程读取)仍将不受限制。
2.在顶层HTB qdisc之下创建两个子层次结构.一个用于 YARN容器和一个用于其它每一个。 这将保证带宽的操作,如shuffle,,日志聚合,同时允许这些操作比保证的消耗更多的带宽,如果可用的话。 这种方法的意义在于,在YARN容器的高网络利用率的情况下,shuffle,对数聚集,HDFS读取(服务)可以被限制到较小的带宽量。 本文档的NM启动部分假设我们将使用这种方法。
一个更好的长期解决方案可能是在YARN容器中产生logaggregation和shuffle作为微服务,然后我们可以应用容器特定的限制,如本文所述。
其它
RM和NM将不得不进行修改以启用网络的计费(计费)。 此功能目前为内存和CPU启用。 为了列出可用/分配的网络带宽,还需要一些UI更改。
MapReduce, DistributedShell
MapReduce和DistributedShell都将被修改,将网络视为资源。 在MapReduce的情况下,将添加作业配置选项来设置map和reduce任务所需的网络带宽。 在分布式shell的情况下,将添加命令行选项以允许用户指定网络带宽。
已知的问题
1.目前的执行机制只有Linux。
2.在Linux上,目前的执行机制只支持出口的流量整形。 入口流量不能以相同的方式成形。 这意味着从YARN容器读取远程HDFS不会受到限制。 然而,HDFS写入会受到限制。
3.如果是多宿主环境,管理员将不得不明确地设置网络接口在NM配置。 如果这个接口设置不正确,结果会是执行可能不正确。
翻译:官网network文档,如有更好的理解或则建议,欢迎大家讨论
更多信息关于net_cls 和 classids,查阅:
https://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/secnet_cls.html
更多信息关于tc,查看
http://www.lartc.org/manpages/tc.txt
HTB和它的“borrowing”机制,详细介绍
http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm 和这里:
http://tldp.org/HOWTO/TrafficControlHOWTO/classfulqdiscs.html