hadoop的Rack Awareness
Hadoop还拥有“Rack Awareness”的理念。作为Hadoop的管理员，你可以在集群中自行的定义从节点的机架数量。但是为什么这样做会给你带来麻烦呢?两个关键的原因是：数据损失预防及网络性能。别忘了，为了防止数据丢失，每块数据都会拷贝在多个机器上。假如同一块数据的多个拷贝都在同一个机架上，而恰巧的是这个机架出现了故障，那么这带来的绝对是一团糟。为了阻止这样的事情发生，则必须有人知道数据节点的位置，并根据实际情况在集群中作出明智的位置分配。这个人就是名称节点。
假使通个机架中两台机器对比不同机架的两台机器会有更多的带宽更低的延时。大部分情况下这是真实存在的。机架转换的上行带宽一般都低于其下行带宽。此外，机架内的通信的延时一般都低于跨机架的(也不是全部)。那么假如Hadoop能实现“Rack Awareness”的理念，那么在集群性能上无疑会有着显著的提升!是的，它真的做到了!太棒了，对不对?
但是扫兴的事情发生了，首次使用你必须手动的去定义它。不断的优化，保持信息的准确。假如机架转换能够自动的给名称节点提供它的数据节点列表，这样又完美了?或者反过来，数据节点可以自行的告知名称节点他们所连接的机架转换，这样也的话也同样完美。
在括补结构中网络中，假如能知道名称节点可以通过OpenFlow控制器查询到节点的位置，那无疑是更加令人兴奋的。
准备HDFS写入
现在Client已经把File.txt分块并做好了向集群中加载的准备，下面先从Block A开始。Client向名称节点发出写File.txt的请求，从名称节点处获得通行证，然后得到每块数据目标数据节点的列表。名称节点使用自己的 Rack Awareness数据来改变数据节点提供列表。核心规则就是对于每块数据3份拷贝，总有两份存在同一个机架上，另外一份则必须放到另一个机架上。所以给 Client的列表都必须遵从这个规则。
在Client将File.txt的“Block A”部分写入集群之前，Client还期待知道所有的目标数据节点是否已准备就绪。它将取出列表中给Block A准备的第一个数据节点，打开TCP 50010协议，并告诉数据节点，注意!准备好接收1块数据，这里还有一份列表包括了数据节点5和数据节点6，确保他们同样已准备就绪。然后再由1传达到 5，接着5传达到6。
数据节点将从同样的TCP通道中响应上一级的命令，只到Client收到原始数据节点1发送的的“就绪”。只到此刻，Client才真正的准备在集群中加载数据块。
HDFS载入通道
当数据块写入集群后，3个(当然数据节点个数参照上文的设置)数据节点将打开一个同步通道。这就意味着，当一个数据节点接收到数据后，它同时将在通道中给下一个数据节点送上一份拷贝。
这里同样是一个借助Rack Awareness数据提升集群性能的例子。注意到没有，第二个和第三个数据节点运输在同一个机架中，这样他们之间的传输就获得了高带宽和低延时。只到这个数据块被成功的写入3个节点中，下一个就才会开始。
HDFS通道载入成功
当3个节点都成功的接收到数据块后，他们将给名称节点发送个“Block Received”报告。并向通道返回“Success”消息，然后关闭TCP回话。Client收到成功接收的消息后会报告给名称节点数据已成功接收。名称节点将会更新它元数据中的节点位置信息。Client将会开启下一个数据块的处理通道，只到所有的数据块都写入数据节点。
Hadoop会使用大量的网络带宽和存储。我们将代表性的处理一些TB级别的文件。使用Hadoop的默认配置，每个文件都会被复制三份。也就是1TB的文件将耗费3TB的网络传输及3TB的磁盘空间。
Client写入跨度集群
每个块的复制管道完成后的文件被成功写入到集群。如预期的文件被散布在整个集群的机器，每台机器有一个相对较小的部分数据。个文件的块数越多，更多的机器的数据有可能传播。更多的CPU核心和磁盘驱动器，意味着数据能得到更多的并行处理能力和更快的结果。这是建造大型的、宽的集群的背后的动机，为了数据处理更多、更快。当机器数增加和集群增宽时，我们的网络需要进行适当的扩展。
扩展集群的另一种方法是深入。就是在你的机器扩展更多个磁盘驱动器和更多的CPU核心，而不是增加机器的数量。在扩展深度上，你把自己的注意力集中在用较少的机器来满足更多的网络I/O需求上。在这个模型中，你的Hadoop集群如何过渡到万兆以太网节点成为一个重要的考虑因素。
