client 向 Active NN 發送寫請求時，NN為這些數據分配DN地址，HDFS文件塊副本的放置對於系統整體的可靠性和性能有關鍵性影響。一個簡單但非優化的副本放置策略是，把副本分別放在不同機架，甚至不同IDC，這樣可以防止整個機架、甚至整個IDC崩潰帶來的錯誤，但是這樣文件寫必須在多個機架之 ...
client 向 Active NN 發送寫請求時，NN為這些數據分配DN地址，HDFS文件塊副本的放置對於系統整體的可靠性和性能有關鍵性影響。一個簡單但非優化的副本放置策略是，把副本分別放在不同機架，甚至不同IDC，這樣可以防止整個機架、甚至整個IDC崩潰帶來的錯誤，但是這樣文件寫必須在多個機架之間、甚至IDC之間傳輸，增加了副本寫的代價，是否有較優的方案來解決這個問題呢？
目錄：
- 常用策略
- 機架配置
- 分配原理
常用策略：
- hdfs 在預設配置下副本數是3個，通常的策略是：
- 第一個副本放在和Client相同機架的Node里（如果Client不在集群範圍，第一個Node是隨機選取不太滿或者不太忙的Node）
- 第二個副本放在與第一個Node不同的機架中的Node
- 第三個副本放在與第二個Node所在機架里不同的Node. 示例圖如下：
- 預設情況下，Hadoop機架感知是沒有啟用的,這時任何一臺 DN 機器，不管物理上是否屬於同一個機架，NN 都會預設將他們預設為在/default-rack下, 此時，就很容易出現之前提到的增添機架間網路負載的情況，如我們前面單節介紹基於 hdp2.4安裝的集群就沒指定rack, 如下圖所示。
機架配置：
- hdfs 的機架感知功能需要在NN機器的hadoop下 core-site.xml里配置net.topology.script.file.name選項,這個配置選項的value指定為一個可執行程式，通常為一個腳本，該腳本接受一個參數，輸出一個值
- 接受的參數通常為datanode機器的ip地址，而輸出的值通常為該ip地址對應的datanode所在的rackID
- Namenode啟動時，會判斷該配置選項是否為空，如果非空，則表示已經啟用機架感知的配置，此時namenode會根據配置尋找該腳本，併在接收到每一個datanode的heartbeat時，將該datanode的ip地址作為參數傳給該腳本運行，並將得到的輸出作為該datanode所屬的機架，保存到記憶體的一個map中
- 腳本的編寫，參見Hadoop官方給出的腳本：http://wiki.apache.org/hadoop/topology_rack_awareness_scripts
- 在 hdp2.4 安裝後的 hadoop 目錄下的配置文件中， 查看 hadoop的 core-site.xml 文件，已經設置了此選項，如下圖
- 查看 topology_script.py 腳本，裡面使用的文件是 topology_mappings.data，用vim編輯此文件，換成真實的網路拓撲，如下
[network_topology] hdp2=/rack1 192.168.2.2=/rack2 hdp3=/rack2 192.168.2.99=/rack1
-
手工修改配置文件，重啟服務後修改內容會被衝掉，所以用我們在 ambaria 上去修改，選擇 "host" -> "Action" -> "Selected hosts" -> "hosts" --> "set Rack" 修改每台host對應的rack, 保存修改，重啟因修改配置而受影響的組件服務，成功後示例如下，這時再去看 topology_mappings.data 的內容已經修改成功：
分配原理：
- 有了機架感知，NameNode就可以畫出下圖所示的datanode網路拓撲圖,
- 最底層是Hx是 datanode, 則H1的rackid=/D1/R1/H1，H1的parent是R1，R1的是D1，有了這些rackid信息就可以計算出任意兩台datanode之間的距離
distance(/D1/R1/H1,/D1/R1/H1)=0 相同的datanode distance(/D1/R1/H1,/D1/R1/H2)=2 同一rack下的不同datanode distance(/D1/R1/H1,/D1/R1/H4)=4 同一IDC下的不同datanode distance(/D1/R1/H1,/D2/R3/H7)=6 不同IDC下的datanode
-
寫文件時根據策略輸入 dn 節點列表，讀文件時按與client由近到遠距離返回 dn 列表
