HDFS実験の1つ:ラックセンシング
5835 ワード
1:背景
デフォルトでは、hadoopのreplicationは3で、3つのコピーの保存ポリシーは次のとおりです.最初のblockコピーは、clientが存在するdatanodeに配置されます(clientがクラスタの範囲内でない場合、最初のnodeはランダムに選択されます). の2番目のコピーは、1番目のノードとは異なるラックのdatanodeに配置されます(ランダムに選択). の3番目のコピーは、2番目のコピーが存在するノードと同じラックの別のノードに配置されます. さらに多くのコピーがあれば、クラスタのdatanodeにランダムに配置されます. 保存ポリシー概略図
このようなポリシーは、blockが属するファイルへのアクセスが本rackの下で優先的に見つかることを保証し、rack全体に異常が発生した場合、別のrackでblockのコピーを見つけることもできる.これにより、データの許容誤差を同時に達成するのに十分な効率が得られます.
しかし、hadoopのラックへの感知は、本格的な知能感知ではなく、hadoopのどのマシンがどのrackに属するかを人為的に知らせる必要があり、hadoopのnamenodeが初期化を開始すると、これらのマシンとrackの対応情報がメモリに保存され、書き込み操作時にdatanodeリストを割り当てる際にdatanodeを選択する根拠となる.
2:実験環境
3:構成
ラックセンシングを有効にするには、まずcore-siteを構成する.xml
topology.script.file.name
/app/hadoop/hadoop220/etc/hadoop/RackAware.py
そして/app/hadoop/hadoop 220/etc/hadoop/RackAwareを作成する.py
#!/usr/bin/python#-*-coding:UTF-8 -*-import sysrack = {"product201":"rack1", "product202":"rack1", "product203":"rack1", "product204":"rack2", "product211":"rack2", "product212":"rack2", "product213":"rack3", "product214":"rack3", "192.168.100.201":"rack1", "192.168.100.202":"rack1", "192.168.100.203":"rack1", "192.168.100.204":"rack2", "192.168.100.211":"rack2", "192.168.100.212":"rack2", "192.168.100.213":"rack3", "192.168.100.214":"rack3", }if __name__=="__main__": print "/"+ rack.get(sys.argv[1],"rack0")
注意、hadoopはIPを使用するところもあればhostnameを使用してdatanodeを表すところもあるので、rack情報を正しく解析できるようにIPとホストのrack対応関係をスクリプト配列に書くことが望ましい.筆者は最初はホスト名とrackの対応関係だけを書いていたが,数回起動してもrack 0に解析し,最後にIPとrackの対応関係も追加すると起動時に正常に解析できるようになった.
また、
chmod +x RackAware.py
付与/app/hadoop/hadoop 220/etc/hadoop/RackAware.py実行権限.
起動後、namenodeのログファイルを表示できます.次のようなログがあるはずです.
2014-03-24 21:20:54,454 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node:/rack1/192.168.100.202:50010
...
2014-03-24 21:20:53,899 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node:/rack2/192.168.100.211:50010
4:実験1
クラスタ内のクライアントは、product 201でファイルをアップロードするなどのファイルをアップロードする
/app/
jdk-7u21-linux-x64.rpmを確認し、blockの分布を確認します.
[hadoop@product201 hadoop220]$ bin/hdfs dfs -mkdir/test
[hadoop@product201 hadoop220]$ bin/hdfs dfs -put/app/jdk-7u21-linux-x64.rpm/test/
[hadoop@product201 hadoop220]$ bin/hdfs fsck/test/jdk-7u21-linux-x64.rpm -files -blocks -locations -racks
結果を返します.
14/03/24 21:50:52 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
Connecting to namenode via http://product201:50070
FSCK started by hadoop (auth:SIMPLE) from/192.168.100.201 for path/test/jdk-7u21-linux-x64.rpm at Mon Mar 24 21:50:53 CST 2014
/test/jdk-7u21-linux-x64.rpm 85388149 bytes, 1 block(s): OK
0. BP-1378383016-192.168.100.201-1395667074626:blk_1073741825_1001 len=85388149 repl=3
[/rack1/192.168.100.201:50010,/rack3/192.168.100.213:50010,/rack3/192.168.100.214:50010]
Status: HEALTHY
Total size:
85388149 B
Total dirs:
0
Total files:
1
Total symlinks:
0
Total blocks (validated):
1 (avg. block size 85388149 B)
Minimally replicated blocks:
1 (100.0 %)
Over-replicated blocks:
0 (0.0 %)
Under-replicated blocks:
0 (0.0 %)
Mis-replicated blocks:
0 (0.0 %)
Default replication factor:
3
Average block replication:
3.0
Corrupt blocks:
0
Missing replicas:
0 (0.0 %)
Number of data-nodes:
8
Number of racks:
3
FSCK ended at Mon Mar 24 21:50:53 CST 2014 in 4 milliseconds
次のことがわかります.
最初のblockコピーはclientがいるdatanodeに置いてあります.
2番目のコピーは、1番目のノードとは異なるラックのdatanodeに配置されます(ランダムに選択).
3番目のレプリカは、2番目のレプリカが存在するノードと同じラックの別のノードに配置されます.
5:実験2
クラスタ外クライアントでファイルをアップロードする、例えばクラスタ外クライアントwyyでファイルをアップロードする
/app/hadoop2lib/hadoop-hdfs-2.2.0.jar
を選択し、blockの分布を確認します.
hadoop@wyy:/app/hadoop/hadoop220$ bin/hdfs dfs -put/app/hadoop2lib/hadoop-hdfs-2.2.0.jar/test
hadoop@wyy:/app/hadoop/hadoop220$ bin/hdfs fsck/test/hadoop-hdfs-2.2.0.jar -files -blocks -locations -racks
結果を返します.
Connecting to namenode via http://product201:50070
FSCK started by hadoop (auth:SIMPLE) from/192.168.100.111 for path/test/hadoop-hdfs-2.2.0.jar at Mon Mar 24 22:08:15 CST 2014
/test/hadoop-hdfs-2.2.0.jar 5242291 bytes, 1 block(s): OK
0. BP-1378383016-192.168.100.201-1395667074626:blk_1073741826_1002 len=5242291 repl=3
[/rack2/192.168.100.212:50010,/rack1/192.168.100.203:50010,/rack1/192.168.100.201:50010]
Status: HEALTHY
Total size:
5242291 B
Total dirs:
0
Total files:
1
Total symlinks:
0
Total blocks (validated):
1 (avg. block size 5242291 B)
Minimally replicated blocks:
1 (100.0 %)
Over-replicated blocks:
0 (0.0 %)
Under-replicated blocks:
0 (0.0 %)
Mis-replicated blocks:
0 (0.0 %)
Default replication factor:
3
Average block replication:
3.0
Corrupt blocks:
0
Missing replicas:
0 (0.0 %)
Number of data-nodes:
8
Number of racks:
3
FSCK ended at Mon Mar 24 22:08:15 CST 2014 in 4 milliseconds
次のことがわかります.
最初のblockコピーはランダムなdatanodeに置かれています.
2番目のコピーは、1番目のノードとは異なるラックのdatanodeに配置されます(ランダムに選択).
3番目のレプリカは、2番目のレプリカが存在するノードと同じラックの別のノードに配置されます.
もちろん,このランダムも真のランダムではなく,負荷等化を考慮したランダムである.複数回実験した結果,負荷の少ないdatanode書き込みを優先することが分かった.
デフォルトでは、hadoopのreplicationは3で、3つのコピーの保存ポリシーは次のとおりです.
このようなポリシーは、blockが属するファイルへのアクセスが本rackの下で優先的に見つかることを保証し、rack全体に異常が発生した場合、別のrackでblockのコピーを見つけることもできる.これにより、データの許容誤差を同時に達成するのに十分な効率が得られます.
しかし、hadoopのラックへの感知は、本格的な知能感知ではなく、hadoopのどのマシンがどのrackに属するかを人為的に知らせる必要があり、hadoopのnamenodeが初期化を開始すると、これらのマシンとrackの対応情報がメモリに保存され、書き込み操作時にdatanodeリストを割り当てる際にdatanodeを選択する根拠となる.
2:実験環境
3:構成
ラックセンシングを有効にするには、まずcore-siteを構成する.xml
topology.script.file.name
/app/hadoop/hadoop220/etc/hadoop/RackAware.py
そして/app/hadoop/hadoop 220/etc/hadoop/RackAwareを作成する.py
#!/usr/bin/python#-*-coding:UTF-8 -*-import sysrack = {"product201":"rack1", "product202":"rack1", "product203":"rack1", "product204":"rack2", "product211":"rack2", "product212":"rack2", "product213":"rack3", "product214":"rack3", "192.168.100.201":"rack1", "192.168.100.202":"rack1", "192.168.100.203":"rack1", "192.168.100.204":"rack2", "192.168.100.211":"rack2", "192.168.100.212":"rack2", "192.168.100.213":"rack3", "192.168.100.214":"rack3", }if __name__=="__main__": print "/"+ rack.get(sys.argv[1],"rack0")
注意、hadoopはIPを使用するところもあればhostnameを使用してdatanodeを表すところもあるので、rack情報を正しく解析できるようにIPとホストのrack対応関係をスクリプト配列に書くことが望ましい.筆者は最初はホスト名とrackの対応関係だけを書いていたが,数回起動してもrack 0に解析し,最後にIPとrackの対応関係も追加すると起動時に正常に解析できるようになった.
また、
chmod +x RackAware.py
付与/app/hadoop/hadoop 220/etc/hadoop/RackAware.py実行権限.
起動後、namenodeのログファイルを表示できます.次のようなログがあるはずです.
2014-03-24 21:20:54,454 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node:/rack1/192.168.100.202:50010
...
2014-03-24 21:20:53,899 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node:/rack2/192.168.100.211:50010
4:実験1
クラスタ内のクライアントは、product 201でファイルをアップロードするなどのファイルをアップロードする
/app/
jdk-7u21-linux-x64.rpmを確認し、blockの分布を確認します.
[hadoop@product201 hadoop220]$ bin/hdfs dfs -mkdir/test
[hadoop@product201 hadoop220]$ bin/hdfs dfs -put/app/jdk-7u21-linux-x64.rpm/test/
[hadoop@product201 hadoop220]$ bin/hdfs fsck/test/jdk-7u21-linux-x64.rpm -files -blocks -locations -racks
結果を返します.
14/03/24 21:50:52 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
Connecting to namenode via http://product201:50070
FSCK started by hadoop (auth:SIMPLE) from/192.168.100.201 for path/test/jdk-7u21-linux-x64.rpm at Mon Mar 24 21:50:53 CST 2014
/test/jdk-7u21-linux-x64.rpm 85388149 bytes, 1 block(s): OK
0. BP-1378383016-192.168.100.201-1395667074626:blk_1073741825_1001 len=85388149 repl=3
[/rack1/192.168.100.201:50010,/rack3/192.168.100.213:50010,/rack3/192.168.100.214:50010]
Status: HEALTHY
Total size:
85388149 B
Total dirs:
0
Total files:
1
Total symlinks:
0
Total blocks (validated):
1 (avg. block size 85388149 B)
Minimally replicated blocks:
1 (100.0 %)
Over-replicated blocks:
0 (0.0 %)
Under-replicated blocks:
0 (0.0 %)
Mis-replicated blocks:
0 (0.0 %)
Default replication factor:
3
Average block replication:
3.0
Corrupt blocks:
0
Missing replicas:
0 (0.0 %)
Number of data-nodes:
8
Number of racks:
3
FSCK ended at Mon Mar 24 21:50:53 CST 2014 in 4 milliseconds
次のことがわかります.
最初のblockコピーはclientがいるdatanodeに置いてあります.
2番目のコピーは、1番目のノードとは異なるラックのdatanodeに配置されます(ランダムに選択).
3番目のレプリカは、2番目のレプリカが存在するノードと同じラックの別のノードに配置されます.
5:実験2
クラスタ外クライアントでファイルをアップロードする、例えばクラスタ外クライアントwyyでファイルをアップロードする
/app/hadoop2lib/hadoop-hdfs-2.2.0.jar
を選択し、blockの分布を確認します.
hadoop@wyy:/app/hadoop/hadoop220$ bin/hdfs dfs -put/app/hadoop2lib/hadoop-hdfs-2.2.0.jar/test
hadoop@wyy:/app/hadoop/hadoop220$ bin/hdfs fsck/test/hadoop-hdfs-2.2.0.jar -files -blocks -locations -racks
結果を返します.
Connecting to namenode via http://product201:50070
FSCK started by hadoop (auth:SIMPLE) from/192.168.100.111 for path/test/hadoop-hdfs-2.2.0.jar at Mon Mar 24 22:08:15 CST 2014
/test/hadoop-hdfs-2.2.0.jar 5242291 bytes, 1 block(s): OK
0. BP-1378383016-192.168.100.201-1395667074626:blk_1073741826_1002 len=5242291 repl=3
[/rack2/192.168.100.212:50010,/rack1/192.168.100.203:50010,/rack1/192.168.100.201:50010]
Status: HEALTHY
Total size:
5242291 B
Total dirs:
0
Total files:
1
Total symlinks:
0
Total blocks (validated):
1 (avg. block size 5242291 B)
Minimally replicated blocks:
1 (100.0 %)
Over-replicated blocks:
0 (0.0 %)
Under-replicated blocks:
0 (0.0 %)
Mis-replicated blocks:
0 (0.0 %)
Default replication factor:
3
Average block replication:
3.0
Corrupt blocks:
0
Missing replicas:
0 (0.0 %)
Number of data-nodes:
8
Number of racks:
3
FSCK ended at Mon Mar 24 22:08:15 CST 2014 in 4 milliseconds
次のことがわかります.
最初のblockコピーはランダムなdatanodeに置かれています.
2番目のコピーは、1番目のノードとは異なるラックのdatanodeに配置されます(ランダムに選択).
3番目のレプリカは、2番目のレプリカが存在するノードと同じラックの別のノードに配置されます.
もちろん,このランダムも真のランダムではなく,負荷等化を考慮したランダムである.複数回実験した結果,負荷の少ないdatanode書き込みを優先することが分かった.