文章轉載自：慧都控件網
http://www.evget.com
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集羣如何過渡到萬兆以太網節點成爲一個重要的考慮因素。
