前言

众所周知，在大规模分布式存储系统中，数据往往通过多副本的形式来保持其可用性。但是多副本如何进行位置放置又是一项值得深挖的领域。至少我们总不能将所有副本都放在一台机器这样的极端情况。对于副本数据的放置，其实涉及到的考量因素还是比较多的，副本放置过于分散化，网络traffic开销就打了，但是过于靠拢增加本地性读呢，冗余性又会受到影响，例如某个rack机器突然故障等等。这里我们将这类的问题称为Topology Awareness问题，本文我们来聊聊Ozone的Topology Awareness方面的内容。

HDFS的Topology Awareness

笔者第一次了解到Topology Awareness是在学习HDFS Block placement的时候，HDFS遵守3副本块按照，同rack，非同rack的三副本放置策略原则来达到数据高可用性的目的。这样的放置策略当然没有什么大的问题，它能容忍一台机器或一个rack不可用导致实际数据不可用的情况。

所以在这里，管理员配置什么样的topology规则就显得十分得重要了。我们可以使用最简单的规则，比如，用物理rack作为逻辑的topology位置rack。如果我们不配置任何的topology的规则，则所有机器的网络位置将会变成default-rack，default-rack并不是一个好的设置。

HDFS Topology的层级，距离定义问题

管理员根据集群节点的实际物理位置，给出对于topology location位置，这并不是难事。但问题来了，有的时候我们需要构建出更加复杂的topology结构，而不仅仅是data center–>rack—>node这样的三级结构。

比如说，我们还想在rack层再做一个group，变成4级结构，或者可能在group层上在做个别属性划分。目前HDFS的Topology还不支持5级层级，group层已经有对应的实现类。因此在layer层的自定义上，HDFS的Topology Awareness还没有达到足够灵活的程度。

/dc
|
/rackgroup
|
/rack
|
/node

另外一点，Topology多层级的划分一方面是为了表明各节点的物理归属位置的不同，还有一点是不同层级的distance不同。这个distance可理解为数据网络传输的开销，跨rack节点间的数据传输比同rack间的节点数据传输的慢，前者的distance就长一点。所以在这里，我们可以给不同layer直接定义不同的distance cost。比如/dc到/rack是2，/rack到/node是1。

在HDFS现有的Topology规则下，没有自定义distance cost的概念，不同layer间的距离是等价的，可以理解为都是1个单位长度。

为什么这里我们这么强调network distance cost的概念呢？因为这里会涉及到最近距离的数据read的问题。对于客户端的数据读操作来说，选择与其最近的节点去读数据显然是一种更优的策略方法。

Ozone同样作为数据存储系统，它在HDFS Topology Awareness以上提到的2点不足之处都做了进一步地完善和改进，使之变成了更加灵活的Topology Awareness。

Ozone的Topology Awareness的配置使用

Ozone的Topology Awareness的核心思想和HDFS 类似，同样基于的是同rack，不同rack的多副本放置策略。这里重点谈谈它的自定义layer和distance cost的设置。

相比于HDFS为了支持不同layer，通过定义新的实现子类这样略显笨重的方式，Ozone则定义了node schema的概念，来支持用户自定义的topology。

在一个node schema中，它包含了node的类型，这里的类型为以下3类：

ROOT(“Root”, NetConstants.INNER_NODE_COST_DEFAULT),
INNER_NODE(“InnerNode”, NetConstants.INNER_NODE_COST_DEFAULT),
LEAF_NODE(“Leaf”, NetConstants.NODE_COST_DEFAULT);

然后后面属性是其cost值。

然后这些被加载好的node schema被NodeSchemaManager以list的方式维护，按照深度顺序，从上往下。

这里schema的定义由外部传入的topology文件决定，以下为一份自定义的topology文件，深度为4，相当于HDFS的NetworkTopologyWithNodeGroup类。

<?xml version="1.0"?>
<configuration>
    <layoutversion>1</layoutversion>
    <layers>
        <layer id="datacenter">
            <prefix></prefix>
            <cost>1</cost>
            <type>Root</type>
        </layer>
        <layer id="rack">
            <prefix>rack</prefix>
            <cost>1</cost>
            <type>InnerNode</type>
            <default>/default-rack</default>
        </layer>
        <layer id="node">
            <prefix></prefix>
            <cost>0</cost>
            <type>Leaf</type>
        </layer>
    </layers>
    <topology>
        <path>/datacenter/rack/node</path>
        <!-- When this field is true, each InnerNode layer should has its prefix defined with not empty value,
         otherwise the content is not valid. Default value is false.
         -->
        <enforceprefix>false</enforceprefix>
    </topology>
</configuration>

然后我们再配上topology mapping，用来指定各节点的topology 位置，按照上述的schema模式，layer层深度为4。上面cost的配置取决于实际物理cost开销，进行配置。

 hostrack file:
 xx(lyq-s2xx)    /dc1/rack1
 xx(lyq-s4xx)    /dc1/rack2
 xx(lyq-s3xx)    /dc2/rack1
 xx(lyq-s1xx)    /dc2/rack2

这里的dc相当于rack上的group。然后配置上Ozone topology相关配置项，

<property>
   <name>ozone.scm.network.topology.schema.file</name>
   <value>/home/hdfs/apache/ozone/etc/hadoop/ozone-topology-default.xml</value>
</property>

<property>
  <name>net.topology.node.switch.mapping.impl</name>
  <value>org.apache.hadoop.net.ScriptBasedMapping</value>
</property>

<property>
  <name>net.topology.script.file.name</name>
  <value>/home/hdfs/apache/ozone/etc/hadoop/topology.py</value>
</property>

python解析脚本，

import sys
import os
import pwd
sys.argv.pop(0)
rack_dic = {}
try:
   with open("/home/hdfs/apache/ozone/etc/hadoop/hostrack") as f:
        for line in f:
           (key, val) = line.split()
           rack_dic[key] = val
   for ip in sys.argv:
        print '{0}'.format(rack_dic[ip])
except Exception,e:
    print "/default-rack"

配置完毕后，我们进行scm的重启，然后执行命令printTopology的命令，我们可以看到各个节点已经加载了最新的topology位置，

[hdfs@lyq hadoop]$ ~/apache/ozone/bin/ozone scmcli printTopology
State = HEALTHY
 xx(lyq-s2xx)    /dc1/rack1
 xx(lyq-s4xx)    /dc1/rack2
 xx(lyq-s3xx)    /dc2/rack1
 xx(lyq-s1xx)    /dc2/rack2

倘若用户传入了一个层级不对的topology mapping，将会导致类似如下的节点注册错误，

2019-12-18 07:56:58,579 WARN org.apache.hadoop.ipc.Server: IPC Server handler 1 on 9861, call Call#9916 Retry#0 org.apache.hadoop.ozone.protocol.StorageContainerDatanodeProtocol.submitRequest from xx.xx.xx.xx:40568
org.apache.hadoop.hdds.scm.net.NetworkTopology$InvalidTopologyException: Failed to add /dc2/rack2/0d98dfab-9d34-46c3-93fd-6b64b65ff543: Its path depth is not 3
	at org.apache.hadoop.hdds.scm.net.NetworkTopologyImpl.add(NetworkTopologyImpl.java:100)
	at org.apache.hadoop.hdds.scm.node.SCMNodeManager.register(SCMNodeManager.java:263)
	at org.apache.hadoop.hdds.scm.server.SCMDatanodeProtocolServer.register(SCMDatanodeProtocolServer.java:225)
	at org.apache.hadoop.ozone.protocolPB.StorageContainerDatanodeProtocolServerSideTranslatorPB.register(StorageContainerDatanodeProtocolServerSideTranslatorPB.java:69)
	at org.apache.hadoop.ozone.protocolPB.StorageContainerDatanodeProtocolServerSideTranslatorPB.processMessage(StorageContainerDatanodeProtocolServerSideTranslatorPB.java:104)
	at org.apache.hadoop.hdds.server.OzoneProtocolMessageDispatcher.processRequest(OzoneProtocolMessageDispatcher.java:72)
	at org.apache.hadoop.ozone.protocolPB.StorageContainerDatanodeProtocolServerSideTranslatorPB.submitRequest(StorageContainerDatanodeProtocolServerSideTranslatorPB.java:77)