現在のデフォルトのHDFSブロック配置ポリシーは、ブロックの3つのレプリカが少なくとも2つのラックに配置されることを保証します。具体的には、ライトパイプライン中に、1つのレプリカが1つのラックに、他の2つのレプリカが別のラックに配置されます。これは、ラックの多様性とライトパイプラインの効率のバランスが取れた妥協案です。後続のロードバランシングやマシンのメンバーシップの変更により、ブロックの3つのレプリカが3つの異なるラックに分散される可能性があることに注意してください。したがって、異なるラックにある任意の3つのデータノードが、ブロックの3つのレプリカを格納できます。
ただし、デフォルトの配置ポリシーは、データノードのローリングアップグレードの実行方法に影響を与えます。HDFSローリングアップグレードドキュメントでは、データノードをダウンタイムなしでローリング方式でアップグレードする方法について説明しています。異なるラックにある任意の3つのデータノードがブロックのすべてのレプリカを格納できるため、データの可用性と読み書き操作への影響を最小限に抑えるために、データノードを一度に1つずつ順次再起動することが重要です。一度に1つのラックをアップグレードすることもできますが、アップグレード中に別のラックでマシンの障害が発生した場合、データの可用性が損なわれる可能性が高まります。
この順次データノードローリングアップグレード戦略の副作用は、大規模クラスタのアップグレード時間が長くなることです。
ローリングアップグレードにおけるブロック配置ポリシーの制限に対処するために、新しいブロック配置ポリシーを介して、アップグレードドメインの概念がHDFSに追加されました。このアイデアは、既存のラックベースのグループ化に加えて、アップグレードドメインと呼ばれる新しい次元でデータノードをグループ化することです。たとえば、任意のラックの最初の位置にあるすべてのデータノードをアップグレードドメインud_01に、2番目の位置にあるノードをアップグレードドメインud_02に割り当てることができます。
NameNodeは、デフォルトのブロック配置ポリシーに加えて、任意のカスタムブロック配置をサポートするためにBlockPlacementPolicyインターフェースを提供します。このインターフェースに基づいた新しいアップグレードドメインブロック配置ポリシーは、HDFSで使用できます。これにより、特定のブロックのレプリカが異なるアップグレードドメインのマシン間で確実に分散されます。デフォルトでは、特定のブロックの3つのレプリカは3つの異なるアップグレードドメインに配置されます。これは、特定のアップグレードドメインに属するすべてのデータノードが、任意のブロックのレプリカを1つ以上格納しないことを意味します。
アップグレードドメインブロック配置ポリシーが有効になっていると、データの可用性に影響を与えることなく、1つのアップグレードドメインに属するすべてのデータノードを同時にアップグレードできます。1つのアップグレードドメインのアップグレードが完了してから、すべてのアップグレードドメインがアップグレードされるまで、次のアップグレードドメインに移動します。このような手順により、特定のブロックの2つのレプリカが同時にアップグレードされることはありません。つまり、大規模クラスタでは多くのマシンを同時にアップグレードできます。また、クラスタが拡大し続けるにつれて、新しいマシンが既存のアップグレードドメインに追加されますが、アップグレードの並列処理には影響しません。
デフォルトのブロック配置ポリシーを使用する既存のクラスタの場合、新しいアップグレードドメインブロック配置ポリシーに切り替えた後、新しく作成されたブロックは新しいポリシーに準拠します。古いポリシーに基づいて割り当てられた古いブロックは、新しいポリシーに移行する必要があります。使用できる移行ツールがあります。詳細はHDFS-8789を参照してください。
クラスタでアップグレードドメインを有効にするには、次の手順に従ってください。
データノードがアップグレードドメインIDにどのようにマップされるかは、管理者によって定義され、クラスタレイアウトに固有です。マシンのラック位置をそのアップグレードドメインIDとして使用することが一般的です。
ホスト名からそのアップグレードドメインIDへのマッピングを構成するには、hdfs-default.xmlで説明されているように、次のプロパティを設定することで、JSONベースのホスト構成ファイルを使用する必要があります。
| 設定 | 値 |
|---|---|
dfs.namenode.hosts.provider.classname |
org.apache.hadoop.hdfs.server.blockmanagement.CombinedHostFileManager |
dfs.hosts |
JSONホストファイルのパス |
JSONホストファイルは、すべてのホストのプロパティを定義します。次の例では、2つのラックに4つのデータノードがあり、ラック位置01のマシンはアップグレードドメイン01に、ラック位置02のマシンはアップグレードドメイン02に属します。
[
{
"hostName": "dcArackA01",
"upgradeDomain": "01"
},
{
"hostName": "dcArackA02",
"upgradeDomain": "02"
},
{
"hostName": "dcArackB01",
"upgradeDomain": "01"
},
{
"hostName": "dcArackB02",
"upgradeDomain": "02"
}
]
各データノードにアップグレードドメインIDが割り当てられた後、次の手順は、hdfs-default.xmlで説明されているように、次の構成を使用してアップグレードドメインブロック配置ポリシーを有効にすることです。
| 設定 | 値 |
|---|---|
dfs.block.replicator.classname |
org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicyWithUpgradeDomain |
NameNodeを再起動すると、新しいポリシーが新しいブロックの割り当てに使用されます。
既存のクラスタのブロック配置ポリシーを変更する場合は、ブロック配置ポリシーの変更前に割り当てられたブロックが新しいブロック配置ポリシーに準拠していることを確認する必要があります。
HDFS-8789は、クライアント側の移行ツールの最初のドラフトパッチを提供します。ツールがコミットされた後、ツールの使用方法について説明します。
クラスタ管理中に、新しい構成、新しいHadoopリリース、またはJVMバージョンなどを取得するために、データノードを再起動する必要がある場合があります。アップグレードドメインが有効になり、クラスタ上のすべてのブロックが新しいポリシーに準拠している場合、一度に1つのアップグレードドメインで、バッチでデータノードを再起動できます。手動プロセスか自動化プロセスかにかかわらず、手順は次のとおりです。
アップグレードドメインは、NameNodeのJMXの一部です。HDFSCommands.htmlで説明されているように、次のコマンドを使用してアップグレードドメインを確認することもできます。
dfsadminを使用して、クラスタレベルでアップグレードドメインを確認します。
hdfs dfsadmin -report
fsckを使用して、特定のパスにデータを格納するデータノードのアップグレードドメインを確認します。
hdfs fsck <path> -files -blocks -upgradedomains