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集群如何過渡到萬兆以太網節點成為一個重要的考慮因素。

來源：CSDN