NameNodeは、inode（ファイルとディレクトリ）、ファイルブロック、Datanodeハートビートの数、HDFS RPCクライアントリクエストの数からなるメタデータオーバーヘッドのために、スケーラビリティの限界があります。一般的な解決策は、ファイルシステムをより小さなサブクラスタに分割し HDFSフェデレーション、フェデレーションビューを提供することです ViewFs。問題は、サブクラスタの分割（例えば、名前空間パーティション）をどのように維持するかです。これは、ユーザーが複数のサブクラスタに接続し、フォルダ/ファイルの割り当てを管理することを余儀なくさせます。
このパーティション化されたフェデレーションへの自然な拡張は、名前空間をフェデレーションする役割を担うソフトウェアのレイヤーを追加することです。この追加レイヤーにより、ユーザーは任意のサブクラスタに透過的にアクセスでき、サブクラスタは独自のブロックプールを独立して管理でき、後でサブクラスタ間でのデータの再バランスが可能になります（詳細については、HDFS-13123を参照）。RBFのサブクラスタは、独立したHDFSクラスタである必要はありません。通常のフェデレーションクラスタ（複数のブロックプールを持つ）またはフェデレーションと独立したクラスタを組み合わせたクラスタも許可されます。これらの目標を達成するために、フェデレーションレイヤーはブロックアクセスを適切なサブクラスタに転送し、名前空間の状態を維持し、データ再バランスのメカニズムを提供します。このレイヤーは、スケーラブルで、高可用性で、フォールトトレラントである必要があります。
このフェデレーションレイヤーは、複数のコンポーネントで構成されています。NameNodeと同じインターフェースを持ち、ステートストアからのground-truth情報に基づいてクライアントリクエストを正しいサブクラスタに転送するルーターコンポーネント。ステートストアは、リモートマウントテーブル（ViewFsと同様ですが、クライアント間で共有される）と、サブクラスタに関する利用状況（負荷/容量）情報を組み合わせたものです。このアプローチは、YARNフェデレーションと同じアーキテクチャです。
最も単純な構成では、各NameNodeマシンにルーターを展開します。ルーターはローカルNameNodeとその状態を監視し、ステートストアにハートビートを送信します。ルーターはローカルNameNodeを監視し、その状態をステートストアにハートビートします。通常のDFSクライアントがフェデレーションされたファイルシステム内のファイルにアクセスするためにルーターのいずれかに接続すると、ルーターはステートストアのマウントテーブル（つまり、ローカルキャッシュ）をチェックして、どのサブクラスタにファイルが含まれているかを調べます。次に、ステートストアのメンバーシップテーブル（つまり、ローカルキャッシュ）で、サブクラスタを担当するNameNodeをチェックします。正しいNameNodeを特定した後、ルーターはリクエストをプロキシします。クライアントはDatanodeに直接アクセスします。
システムには、ソフトステートを持つ複数のルーターが存在できます。各ルーターには2つの役割があります。
ルーターはクライアントリクエストを受け取ると、ステートストアで正しいサブクラスタをチェックし、そのサブクラスタのアクティブなNameNodeにリクエストを転送します。NameNodeからの応答は、逆方向に流れます。ルーターはステートレスであり、ロードバランサの背後にあることができます。ヘルスチェックのために、/isActiveエンドポイントをヘルスプローブとして使用できます（例：http://ROUTER_HOSTNAME:ROUTER_PORT/isActive）。パフォーマンスのために、ルーターはリモートマウントテーブルエントリとサブクラスタの状態もキャッシュします。変更がすべてのルーターに伝播されていることを確認するために、各ルーターはステートストアに状態のハートビートを送信します。
ルーターとステートストア間の通信はキャッシュされます（新鮮さを保つために時間制限付きの有効期限付き）。これにより、システムのパフォーマンスが向上します。
ルーターは定期的にステートストアに状態のハートビートを送信します。
この役割の場合、ルーターは定期的にNameNode（通常は同じサーバー上）の状態をチェックし、その高可用性（HA）状態と負荷/スペースの状態をステートストアに報告します。これはオプションの役割であり、ルーターは任意のサブクラスタから独立している可能性があることに注意してください。NameNode HAのパフォーマンスのために、ルーターはステートストアの高可用性状態情報を使用して、アクティブである可能性が最も高いNameNodeにリクエストを転送します。このサービスは、操作を簡素化するためにNameNode自体に組み込むことができます。
ルーターは、複数のレベルで障害が発生した場合でも動作します。
フェデレーションインターフェースHA：ルーターはステートレスであり、メタデータ操作はNameNodeでアトミックです。ルーターが使用できなくなると、任意のルーターが引き継ぐことができます。クライアントは、フェデレーション内のすべてのルーターをエンドポイントとして、DFS HAクライアント（例：ConfiguredFailoverProviderまたはRequestHedgingProxyProvider）を設定します。
ステートストアが使用できない場合：ルーターがステートストアに接続できない場合、セーフモード状態になり、リクエストの処理ができなくなります。クライアントは、セーフモードのルーターをスタンバイNameNodeとして扱い、別のルーターを試行します。ルーターのセーフモードを手動で管理する方法があります。
セーフモード状態は、次のコマンドを使用して管理できます。
[hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -safemode enter | leave | get
NameNodeハートビートHA：高可用性と柔軟性のために、複数のルーターが同じNameNodeを監視し、ステートストアに情報をハートビートすることができます。これにより、ルーターが失敗した場合でも、クライアントが古い情報に耐性を持つようになります。ステートストア内のNameNode情報の競合は、各ルーターによってクォーラムを介して解決されます。
NameNodeが使用できない場合：ルーターがアクティブなNameNodeに接続できない場合、サブクラスタ内の他のNameNodeを試行します。最初にスタンバイとして報告されたものを試行し、次に使用できないものを試行します。ルーターがどのNameNodeにも到達できない場合、例外をスローします。
期限切れのNameNode：ハートビート間隔の倍数でステートストアにNameNodeハートビートが記録されていない場合、監視ルーターはNameNodeが期限切れであることを記録し、どのルーターもアクセスしようとしません。その後、NameNodeに対して更新されたハートビートが記録されると、監視ルーターはNameNodeを期限切れの状態から復元します。
ユーザーと管理者と対話するために、ルーターは複数のインターフェースを公開します。
RPC：ルーターRPCは、クライアントがHDFSと対話するために使用する最も一般的なインターフェースを実装します。現在の実装は、プレーンMapReduce、Spark、Hive（Tez、Spark、MapReduce上）で記述された分析ワークロードを使用してテストされています。スナップショット、暗号化、階層型ストレージなどの高度な機能は、今後のバージョンに残されています。実装されていないすべての機能は、例外をスローします。
管理：管理者は、クラスタから情報を照会し、RPCを介してマウントテーブルからエントリを追加/削除できます。このインターフェースは、コマンドラインからも公開され、フェデレーションから情報を取得および変更できます。
Web UI：ルーターは、現在のNameNode UIを模倣した、フェデレーションの状態を視覚化するWeb UIを公開します。マウントテーブルに関する情報、各サブクラスタのメンバーシップ情報、ルーターの状態を表示します。
WebHDFS: Routerは、RPCインターフェースに加えて、HDFS RESTインターフェース（WebHDFS）も提供します。
JMX: NameNodeを模倣したメトリクスをJMXを介して公開します。これは、Web UIがクラスタの状態を取得するために使用されます。
Routerベースのフェデレーションでは、一部の操作は利用できません。Routerはそれらの操作に対して例外をスローします。ユーザーが遭遇する可能性のある例を以下に示します。
フェデレーションは、マウントテーブルレベルでグローバルクォータをサポートし、制御します。パフォーマンス上の理由から、Routerはクォータ使用状況をキャッシュし、定期的に更新します。これらのクォータ使用状況値は、RouterRPCSeverで呼び出される各WRITE RPC呼び出し中にクォータ検証に使用されます。クォータの詳細については、HDFSクォータガイドを参照してください。
注：グローバルクォータが有効になっている場合、Router管理サーバーがグローバルクォータでサブクラスタのクォータを上書きするため、サブクラスタのクォータを直接設定またはクリアすることはお勧めしません。
(論理的には集中化されているが、物理的には分散されている)状態ストアは、以下を維持します。
状態ストアのバックエンドはプラグイン可能です。バックエンド実装のフォールトトレランスを活用します。状態ストアに格納される主要な情報とその実装
メンバーシップ：メンバーシップ情報は、フェデレーション内のNameNodeの状態をエンコードします。これには、ストレージ容量やノード数などのサブクラスタに関する情報が含まれます。Routerは、1つ以上のNameNodeに関するこの情報を定期的にハートビートします。複数のRouterが単一のNameNodeを監視できるため、各Routerからのハートビートが保存されます。Routerは、状態ストアからこの情報をクエリする際に、データのクォーラムを適用します。Routerは、特定のしきい値（例：10個のRouterハートビート期間）よりも古いエントリを破棄します。
マウントテーブル：このテーブルは、フォルダとサブクラスタのマッピングをホストします。これは、フェデレーションフォルダ、宛先サブクラスタ、およびそのフォルダ内のパスを指定するViewFsのマウントテーブルに似ています。
Routerは、HDFSの現在のセキュリティモデルと同様のセキュリティをサポートしています。この機能は、RPCベースの呼び出しとWebベースの呼び出しの両方で使用できます。基盤となるセキュアなHDFSクラスタへのプロキシ機能があります。
NameNodeと同様に、Routerに接続するクライアントのKerberosベース認証とトークンベース認証の両方をサポートしています。Routerは内部的に、この機能をサポートするためにcore-site.xmlとhdfs-site.xmlの既存のセキュリティ関連の設定に依存しています。それに加えて、Routerは独自のキータブとプリンシパルで構成する必要があります。
トークンベースの認証の場合、Routerは、ダウンストリームのNameNodeと通信せずに、アップストリームのクライアントに委任トークンを発行します。Routerは、アップストリームの実際のユーザーに代わって、ダウンストリームのNameNodeに安全にプロキシするために、独自の資格情報を使用します。Routerのプリンシパルは、すべてのセキュアなダウンストリームNameNodeでスーパーユーザーとして構成する必要があります。NameNodeのプロキシユーザーの構成についてはこちらを参照してください。それに加えて、Routerデーモンを所有するユーザーは、NameNodeプロセス自体と同じIDで構成する必要があります。こちらで詳細を参照してください。Routerは、状態ストアに依存して、すべてのRouter間でトークンを配布します。ユーザーは、提供されているデフォルトの実装に加えて、トークン管理のための状態ストアの独自の実装をプラグインできます。デフォルトの実装は、トークン管理にZooKeeperに依存しています。大規模なRouter/ZooKeeperクラスタは数百万のトークンを保持する可能性があるため、ZooKeeperクライアントが依存するjute.maxbufferシステムプロパティは、Routerデーモンで適切に構成する必要があります。
この機能の詳細については、Apache JIRAチケットHDFS-13532を参照してください。
デフォルトでは、Routerはリクエストを受け入れ、ローカルマシンのNameNodeを監視する準備ができています。dfs.federation.router.store.driver.classを設定して、状態ストアのエンドポイントを知る必要があります。その他のオプションについては、hdfs-rbf-default.xmlに記載されています。
Routerが構成されたら、起動できます。
[hdfs]$ $HADOOP_PREFIX/bin/hdfs --daemon start dfsrouter
そして停止するには
[hdfs]$ $HADOOP_PREFIX/bin/hdfs --daemon stop dfsrouter
マウントテーブルのエントリは、ViewFsのものとほぼ同じです。管理を簡素化するための良い方法は、フェデレーション名前空間を宛先名前空間と同じ名前で命名することです。たとえば、フェデレーション名前空間に/data/app1をマウントする場合、宛先名前空間と同じ名前を持つことをお勧めします。
フェデレーション管理ツールは、マウントテーブルの管理をサポートしています。たとえば、3つのマウントポイントを作成して一覧表示するには
[hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -add /tmp ns1 /tmp [hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -add /data/app1 ns2 /data/app1 [hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -add /data/app2 ns3 /data/app2 [hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -ls
書き込みを許可しないマウントポイントもサポートしています。
[hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -add /readonly ns1 / -readonly
マウントポイントが設定されていない場合、Routerはそれをデフォルトの名前空間dfs.federation.router.default.nameserviceIdにマップします。
マウントテーブルにはUNIXのようなパーミッションがあり、どのユーザーとグループがマウントポイントにアクセスできるかを制限します。書き込みパーミッションにより、ユーザーはマウントポイントを追加、更新、または削除できます。読み取りパーミッションにより、ユーザーはマウントポイントを一覧表示できます。実行パーミッションは使用されません。
マウントテーブルのパーミッションは、次のコマンドで設定できます。
[hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -add /tmp ns1 /tmp -owner root -group supergroup -mode 0755
オプションのモードは、マウントテーブルのUNIXスタイルのパーミッションです。パーミッションは8進数で指定されます（例：0755）。デフォルトでは、これは0755に設定されています。
Routerベースのフェデレーションは、マウントテーブルレベルでグローバルクォータをサポートしています。マウントテーブルのエントリは複数のサブクラスタにまたがる可能性があり、グローバルクォータはこれらのサブクラスタ全体でカウントされます。
フェデレーション管理ツールは、指定されたマウントテーブルエントリのクォータの設定をサポートしています。
[hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -setQuota /path -nsQuota 100 -ssQuota 1024
上記のコマンドは、パスに最大100個のファイル/ディレクトリを許可し、最大1024バイトのストレージ容量を使用することを意味します。ssQuotaのパラメータは、複数のサイズ単位のサフィックスをサポートします（例：1kは1KB、5mは5MB）。サフィックスを指定しない場合は、バイトと見なされます。
指定されたマウントテーブルエントリのストレージタイプのクォータを設定します。
[hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -setStorageTypeQuota <path> -storageType <storage type>
指定されたマウントテーブルエントリのクォータを削除します。
[hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -clrQuota <path>
指定されたマウントテーブルエントリのストレージタイプのクォータを削除します。
[hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -clrStorageTypeQuota <path>
lsコマンドは、各マウントテーブルエントリについて以下の情報を表示します。
Source Destinations Owner Group Mode Quota/Usage /path ns0->/path root supergroup rwxr-xr-x [NsQuota: 50/0, SsQuota: 100 B/0 B]
マウントテーブルキャッシュは定期的に更新されますが、refreshコマンドを実行することで更新することもできます。
[hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -refresh
上記のコマンドは、接続されているRouterのキャッシュを更新します。マウントテーブル更新サービスが有効になっている場合、サービスは常にキャッシュを更新するため、このコマンドは冗長です。
マウントポイントは、複数のサブクラスタのマッピングもサポートしています。たとえば、サブクラスタns1とns2にファイルを格納するマウントポイントを作成するには。
[hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -add /data ns1,ns2 /data -order SPACE
/dataを一覧表示すると、両方のサブクラスタ内のすべてのフォルダとファイルが表示されます。新しいファイル/フォルダを作成する場所を決定するために、orderパラメータを使用します。現在、次のメソッドをサポートしています。
ハッシュベースのアプローチの違いは、HASHでは、フォルダ内のすべてのファイル/フォルダが同じサブクラスタに属することになるのに対し、HASH_ALLでは、マウントポイント下のすべてのファイルが分散されることです。たとえば、/data/hashにHASHマウントポイントがあると仮定すると、/data/hash/folder0の下のファイルとフォルダはすべて同じサブクラスタにあります。一方、/data/hash_allのHASH_ALLマウントポイントは、そのマウントポイントのすべてのサブクラスタに/data/hash_all/folder0の下のファイルを分散します（サブフォルダはすべてのサブクラスタに作成されます）。
RANDOMは、異なるサブクラスタからのデータの読み取りと書き込みに使用できます。このアプローチの一般的な用途は、複数のサブクラスタに同じデータを持ち、サブクラスタ間で読み取りを分散することです。たとえば、何千ものコンテナが同じデータ（例：ライブラリ）を読み取る必要がある場合、RANDOMを使用して、いずれかのサブクラスタからデータを読み取ることができます。
どのサブクラスタにファイルが含まれているかを判断するには
[hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -getDestination /user/user1/file.txt
サブクラスタ間でのデータの一貫性は、Routerによって保証されません。デフォルトでは、1つのサブクラスタが使用できない場合、そのサブクラスタを対象とする書き込みは失敗する可能性があります。別のサブクラスタに書き込むことを許可するには、マウントポイントをフォールトトレラントにすることができます。
[hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -add /data ns1,ns2 /data -order HASH_ALL -faulttolerant
これにより、複数のサブクラスタにファイルが書き込まれたり、フォルダが1つ不足したりする可能性があることに注意してください。これらの不整合の可能性を認識し、このfaulttolerantアプローチを回復力のあるパスに適用する必要があります。これの例としては、ほとんどの場合サブフォルダに一度だけ書き込む/app-logsフォルダがあります。
NameService（サブクラスタ）へのアクセスを阻止するには、フェデレーションから無効化できます。たとえば、ns1を無効化し、一覧表示し、再度有効化できます。
[hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -nameservice disable ns1 [hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -getDisabledNameservices [hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -nameservice enable ns1
これは、サブクラスタのデコミッション時や、1つのサブクラスタが誤動作している場合（例：パフォーマンス低下や使用不可）に役立ちます。
<host:ipc_port>で<key>によって指定されたリソースのランタイム更新をトリガーします。たとえば、ホワイトリストチェックを有効にするには、Routerサーバーを再起動するのではなく、更新コマンドを送信するだけで済みます。
[hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -refreshRouterArgs <host:ipc_port> <key> [arg1..argn]
Routerの現在の状態を診断するには、dumpStateコマンドを使用できます。これは、状態ストアのレコードのテキストダンプを生成します。状態ストアを見つけて読み取るために構成を使用するため、多くの場合、Routerが実行されているマシンを使用するのが最も簡単です。このコマンドはローカルで実行されるため、このコマンドを使用するためにRouterを起動する必要はありません。
[hdfs]$ $HADOOP_HOME/bin/hdfs dfsrouteradmin -dumpState
クライアントがフェデレーション名前空間を使用するには、Routerを指す新しい名前空間を作成する必要があります。たとえば、4つの名前空間ns0、ns1、ns2、ns3を持つクラスタは、2つのRouterを指すns-fedという新しい名前空間をhdfs-site.xmlに追加できます。
<configuration>
<property>
<name>dfs.nameservices</name>
<value>ns0,ns1,ns2,ns3,ns-fed</value>
</property>
<property>
<name>dfs.ha.namenodes.ns-fed</name>
<value>r1,r2</value>
</property>
<property>
<name>dfs.namenode.rpc-address.ns-fed.r1</name>
<value>router1:rpc-port</value>
</property>
<property>
<name>dfs.namenode.rpc-address.ns-fed.r2</name>
<value>router2:rpc-port</value>
</property>
<property>
<name>dfs.client.failover.proxy.provider.ns-fed</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
<property>
<name>dfs.client.failover.random.order</name>
<value>true</value>
</property>
</configuration>
dfs.client.failover.random.orderをtrueに設定すると、Router間で負荷を均等に分散できます。
この設定により、ユーザーは通常の名前空間としてns-fedと対話できます。
$ $HADOOP_HOME/bin/hdfs dfs -ls hdfs://ns-fed/ /tmp /data
このフェデレーション名前空間は、fs.defaultFSを使用してcore-site.xmlでデフォルトの名前空間として設定することもできます。
システムでデータ局所性をサポートするには、ユーザーのクライアントIPアドレスを提供するためにRouterを信頼するようにNameNodeを構成する必要があります。dfs.namenode.ip-proxy-usersは、呼び出し元コンテキストを介してクライアントIPアドレスを提供することを許可されているユーザーのカンマ区切りのリストを定義します。
<configuration>
<property>
<name>dfs.namenode.ip-proxy-users</name>
<value>hdfs</value>
</property>
</configuration>
Routerベースのフェデレーションの設定は、hdfs-rbf-site.xmlに追加できます。主なオプションについては、hdfs-rbf-default.xmlに記載されています。設定値については、このセクションで説明します。
クライアントからの接続を受け取るRPCサーバー。
| プロパティ | デフォルト値 | 説明 |
|---|---|---|
| dfs.federation.router.default.nameserviceId | 監視対象のデフォルトサブクラスタのNameservice ID。 | |
| dfs.federation.router.rpc.enable | true |
trueの場合、ルーターでクライアントのリクエストを処理するRPCサービスが有効になります。 |
| dfs.federation.router.rpc-address | 0.0.0.0:8888 | すべてクライアントのリクエストを処理するRPCアドレス。 |
| dfs.federation.router.rpc-bind-host | 0.0.0.0 | RPCサーバーがバインドする実際のアドレス。 |
| dfs.federation.router.handler.count | 10 | ルーターがクライアントからのRPCリクエストを処理するためのサーバースレッド数。 |
| dfs.federation.router.handler.queue.size | 100 | ハンドラーがクライアントからのRPCリクエストを処理するためのキューのサイズ。 |
| dfs.federation.router.reader.count | 1 | ルーターがクライアントからのRPCリクエストを処理するためのリーダー数。 |
| dfs.federation.router.reader.queue.size | 100 | リーダーがクライアントからのRPCリクエストを処理するためのキューのサイズ。 |
ルーターはクライアントのリクエストをNameNodeに転送します。接続プールを使用することで、接続作成のレイテンシを削減します。
| プロパティ | デフォルト値 | 説明 |
|---|---|---|
| dfs.federation.router.connection.pool-size | 1 | ルーターからNameNodeへの接続プールのサイズ。 |
| dfs.federation.router.connection.clean.ms | 10000 | 接続プールから未使用の接続を削除するかどうかを確認する時間間隔（ミリ秒）。 |
| dfs.federation.router.connection.pool.clean.ms | 60000 | 接続マネージャーが未使用の接続プールを削除するかどうかを確認する時間間隔（ミリ秒）。 |
マウントテーブルを管理する管理サーバー。
| プロパティ | デフォルト値 | 説明 |
|---|---|---|
| dfs.federation.router.admin.enable | true |
trueの場合、ルーターで管理リクエストを処理するRPC管理サービスが有効になります。 |
| dfs.federation.router.admin-address | 0.0.0.0:8111 | 管理リクエストを処理するRPCアドレス。 |
| dfs.federation.router.admin-bind-host | 0.0.0.0 | RPC管理サーバーがバインドする実際のアドレス。 |
| dfs.federation.router.admin.handler.count | 1 | ルーターが管理者からのRPCリクエストを処理するためのサーバースレッド数。 |
クライアントにWeb UIとHDFS RESTインターフェース(WebHDFS)を提供するHTTPサーバー。デフォルトのURLは“http://router_host:50071”です。
| プロパティ | デフォルト値 | 説明 |
|---|---|---|
| dfs.federation.router.http.enable | true |
trueの場合、ルーターでクライアントのリクエストを処理するHTTPサービスが有効になります。 |
| dfs.federation.router.http-address | 0.0.0.0:50071 | ルーターへのWebリクエストを処理するHTTPアドレス。 |
| dfs.federation.router.http-bind-host | 0.0.0.0 | HTTPサーバーがバインドする実際のアドレス。 |
| dfs.federation.router.https-address | 0.0.0.0:50072 | ルーターへのWebリクエストを処理するHTTPSアドレス。 |
| dfs.federation.router.https-bind-host | 0.0.0.0 | HTTPSサーバーがバインドする実際のアドレス。 |
ステートストアとルーターの内部キャッシングへの接続。
| プロパティ | デフォルト値 | 説明 |
|---|---|---|
| dfs.federation.router.store.enable | true |
trueの場合、ルーターはステートストアに接続します。 |
| dfs.federation.router.store.serializer | org.apache.hadoop.hdfs.server.federation.store.driver.impl.StateStoreSerializerPBImpl |
ステートストアのレコードをシリアライズするクラス。 |
| dfs.federation.router.store.driver.class | org.apache.hadoop.hdfs.server.federation.store.driver.impl.StateStoreZooKeeperImpl |
ステートストアを実装するクラス。 |
| dfs.federation.router.store.connection.test | 60000 | ステートストアへの接続を確認する頻度（ミリ秒）。 |
| dfs.federation.router.cache.ttl | 60000 | ステートストアのキャッシュを更新する頻度（ミリ秒）。 |
| dfs.federation.router.store.membership.expiration | 300000 | メンバーシップレコードの有効期限（ミリ秒）。 |
| dfs.federation.router.mount-table.cache.update | false | trueの場合、すべてのルーターについて、マウントテーブルのエントリが追加、変更、または削除されるたびに、マウントテーブルのキャッシュが更新されます。 |
| dfs.federation.router.mount-table.cache.update.timeout | 1m | すべてのルーターがマウントテーブルのキャッシュ更新を完了するまで待機する最大時間。 |
| dfs.federation.router.mount-table.cache.update.client.max.time | 5m | RouterClient接続をキャッシュできる最大時間。 |
クライアントのリクエストを正しいサブクラスタに転送します。
| プロパティ | デフォルト値 | 説明 |
|---|---|---|
| dfs.federation.router.file.resolver.client.class | org.apache.hadoop.hdfs.server.federation.resolver.MountTableResolver |
ファイルをサブクラスタに解決するクラス。マウントポイントに複数のサブクラスタを有効にするには、org.apache.hadoop.hdfs.server.federation.resolver.MultipleDestinationMountTableResolverに設定します。 |
| dfs.federation.router.namenode.resolver.client.class | org.apache.hadoop.hdfs.server.federation.resolver.MembershipNamenodeResolver |
サブクラスタのNameNodeを解決するクラス。 |
クライアントのリクエストを転送するために、サブクラスタ内のNameNodeを監視します。
| プロパティ | デフォルト値 | 説明 |
|---|---|---|
| dfs.federation.router.heartbeat.enable | true |
trueの場合、ルーターは定期的にステートストアに状態をハートビートします。 |
| dfs.federation.router.namenode.heartbeat.enable | trueの場合、ルーターはNameNodeのハートビートを取得し、ステートストアに送信します。明示的に指定されていない場合、dfs.federation.router.heartbeat.enableと同じ値になります。 | |
| dfs.federation.router.heartbeat.interval | 5000 | ルーターがステートストアにハートビートを送信する頻度（ミリ秒）。 |
| dfs.federation.router.monitor.namenode | 監視およびハートビートを送信するNameNodeの識別子。 | |
| dfs.federation.router.monitor.localnamenode.enable | true |
trueの場合、ルーターはローカルマシンのNameNodeを監視します。 |
注：dfs.federation.router.monitor.localnamenode.enableが有効になっている場合は、dfs.nameservice.idの設定が推奨されます。これにより、ルーターはローカルノードを直接検出できます。そうでない場合、ルーターはNameNodeのRPCアドレスとローカルノードのアドレスを照合してNameservice IDを検出します。複数のアドレスが一致する場合、ルーターの起動に失敗します。さらに、ローカルノードがHAモードの場合は、dfs.ha.namenode.idの設定が推奨されます。
フェデレーションでサポートされるグローバルクォータ。
| プロパティ | デフォルト値 | 説明 |
|---|---|---|
| dfs.federation.router.quota.enable | false |
trueの場合、ルーターでクォータシステムが有効になります。その場合、ルーター管理サーバーがサブクラスタのクォータをグローバルクォータで上書きするため、サブクラスタのクォータを直接設定またはクリアすることは推奨されません。 |
| dfs.federation.router.quota-cache.update.interval | 60s | ルーターがクォータキャッシュを更新する頻度。この設定では、複数の時間単位のサフィックスがサポートされます。サフィックスを指定しない場合、ミリ秒が想定されます。 |
フェデレーションでサポートされるKerberosと委任トークン。
| プロパティ | デフォルト値 | 説明 |
|---|---|---|
| dfs.federation.router.keytab.file | ルーターがサービスプリンシパルとしてログインするために使用するkeytabファイル。プリンシパル名は「dfs.federation.router.kerberos.principal」で設定されます。 | |
| dfs.federation.router.kerberos.principal | ルーターのサービスプリンシパル。通常はrouter/_HOST@REALM.TLDに設定されます。各ルーターは、起動時に_HOSTを独自の完全修飾ホスト名に置き換えます。_HOSTプレースホルダーを使用すると、HA設定内のすべてのルーターで同じ設定を使用できます。 | |
| dfs.federation.router.kerberos.principal.hostname | この設定ファイルを含むルーターのホスト名。マシンごとに異なります。デフォルトは現在のホスト名です。 | |
| dfs.federation.router.kerberos.internal.spnego.principal | ${dfs.web.authentication.kerberos.principal} |
Kerberosセキュリティが有効になっている場合、Web UI SPNEGO認証でルーターが使用するサーバープリンシパル。通常はHTTP/_HOST@REALM.TLDに設定されます。SPNEGOサーバープリンシパルは、慣例によりHTTP/プレフィックスで始まります。値が「*」の場合、Webサーバーはkeytabファイル「dfs.web.authentication.kerberos.keytab」に指定されているすべてのプリンシパルでログインを試みます。 |
| dfs.federation.router.secret.manager.class | org.apache.hadoop.hdfs.server.federation.router.security.token.ZKDelegationTokenSecretManagerImpl |
委任トークンにステートストアを実装するクラス。デフォルトの実装では、委任トークンの保存にバックエンドとしてZooKeeperを使用します。 |
ルーターとステートストアの統計情報は、メトリクス/JMXで公開されます。これらの情報は監視に非常に役立ちます。メトリクスの詳細については、RBFメトリクス、ルーターRPCメトリクス、およびステートストアメトリクスを参照してください。