分布式系统中Topology(Rack) Awareness的实现思路
文章目录
前言
在分布式系统中，尤其是存储系统中，我们经常会看到类似“系统返回一个最近的数据”这样的句子”。当我们谈到一个数据“远近”的问题时，你可以说这是在谈数据locality的问题，但从更宏观的角度来看这个问题，它其实谈的是Topology Awareness（拓扑架构感知）的事情。本文笔者来简单聊聊这个话题，其实我们平时更多的是用另一个词–Rack-Awareness（机架感知）来指代这个问题。
为何要考虑Topology Awareness
其实在小规模，小体量集群环境中，是确实可以不用考虑拓扑结构感知的问题的。这里的结构可理解为是它的网络结构(/data center/rack/node)。但是当集群规模变大，甚至有了不同的数据中心，机房时，这里面就要考虑网络数据通信的问题。也就是我们需要开始重视这里面的网络结构的问题，总不能每天把机房带宽打满吧。基本原则是优先访问本地（可以同节点，rack，datacener）数据，尽可能避免远程数据传输。所以Topology Awareness要解决的就是这样的一个问题，避免的是一个resource消耗的问题。
Topology Awareness的一般实现思路
结合HDFS内部的NetworkTopology实现以及最近Ozone的Topology Awareness设计实现，笔者来简单概括下其中的设计思想，还是有很多通用的地方可以借鉴借鉴的。
Step1: Node Location赋予
节点的拓扑结构位置赋予是Topology Awareness的一个初始前提。一般情况下，我们会将节点实际的网络位置情况作为它的实际位置值，比如如下：
/data-center/rack/node
或者说有时我们还要在node前多加一层（比如交换机），
/data-center/rack/switch/node
每多一层级，相当于这个路径深度又深了一层。这其实是一个树结构，最后的节点为叶子节点，然后中间的节点更多的是一个逻辑上的角色节点。
当然，我们也可以手动赋值逻辑位置，不依赖于物理实际网络位置。通过外部脚本提供这层位置关系，目前Hadoop内部已经支持这个功能。
Step2: Topology的结构组织和距离计算
在上文已经提到过，整个Topology结构是一个树型结构，通过中间节点进行组织串联。在这个大型的树结构中，一般我们会分为两类节点：
- 叶子节点，实际物理节点
- 非叶子节点，包括树的根节点和所有中间节点都为此类型节点
然后这些节点会有一些公共属性：
- 孩子节点信息
- 位置信息
- 距离开销，指当前节点和其下孩子节点的“距离”
上面的距离开销属性值在后面计算最近节点时会起到关键的作用，我们可以用距离单元来对此赋值。
我们以下面一个例子来解释距离的开销的含义：
上图中直线中数字即距离开销，越往上，距离值越大实际意为网络传输开销越大。上图中比如node1和node2之间的距离为1+1=2，计算方式为2个节点递归往上找，找到最近公共祖先，然后计算这之间的距离开销和，即为2个节点间的距离值。
有了以上的结构组织方式和距离计算方式，节点间的数据本地性通信将会大大得到提升。同一机房优先于跨机房通信，同机房内，同机架优先于跨机架的。
Topology结构的自定义组织
以上的结构定义还能够实现得更为灵活，可用。我们完全可以在上面node节点前在加一层nodegroup层，然后也赋予一个距离值，如下图：
这其实就是我们对整个Topology的整体结构设计了。这可以作为一个topology的配置属性，由用户进行设置，包括以下几要素：
- 节点类型
- 所在树的深度
- 距离开销值
Step3: 最近节点的选择
当我们把整个Topology都完善好之后，那么我们如何来选择“最近”节点呢？这里的最近节点其实就是距离开销和最小的节点，物理意义即数据本地性更优先的节点。
一个能够想到的简单粗暴的办法，获取当前请求节点位置，然后和集群内的所有节点进行一个距离计算，然后按照距离值升序排列，选取第一个距离最短的。然后进行数据的读或者写。
以上这种方法虽说可行，但是效率并一定是最高的。在Hadoop中，它的做法是通过引入一个scope值来限定候选节点。候选节点必须是此scope范围内的，判断方法是通过位置前缀匹配是否符合。当然，也可以反着用，带上字符“~”前缀即是exclude排斥的意思。
以上内容来自于Hadoop内的Topology Awareness的实现思路，详细细节可参考下文链接地址。
引用
[1].https://docs.google.com/document/d/1HsZqlBcEmlezU6HriUaIOFE9SFdcBoaiz15Qt_ng0P8/edit
