【Hadoop】QJMベースHDFS高可用性シリーズ2-導入

公式ドキュメント翻訳、公式リンク.翻訳のレベルが限られており、学習を主としておりますので、ご了承とご意見をお願いいたします.転載は出典を明記してください!!!
前回発表した文章に続いて翻訳を続けます.今回は配置章から.
配置
構成の概要
連邦の構成と同様に、HAの構成は後方互換性があり、既存の単一Nameノード構成クラスタの構成を変更しないことができます.このように、クラスタのすべてのノードで同じ構成を使用できるように、新しい構成を設計し、このタイプのノードに基づいて異なるプロファイルを異なるマシンに配置する必要はありません.HDFS連邦機構のように、HAクラスタは、実際には複数のNameNodeからなる個別のHDFSインスタンスを識別するためにnameservice IDを再利用する.また、NameNode IDと呼ばれる新しい抽象がHAに加わる.クラスタ内の異なるNameNodeごとに異なるNameNode IDがあります.すべてのNameNodeが単一のプロファイルをサポートしている場合、関連する構成パラメータは、NameNode IDと同等の接尾辞としてnameservice IDを使用します.
構成の詳細
HANameNodeを構成するには、hdfs-siteにいくつかの構成項目を追加する必要があります.xmlプロファイルにあります.これらの構成の順序を設定することは重要ではありませんが、dfsについては重要です.nameservicesとdfs.ha.namenodesオプションで選択した値は重要です.[nameserviceID]は、後の構成項目のkeyを決定します.したがって、残りの構成項目を設定する前に、これらの値を決定します.

dfs.nameservices-新しいnameserviceの論理名このnameserviceは、myclusterなどの論理名を定義し、この構成項目の値はこの論理名です.この名前は任意に定義できます.これは、絶対HDFSパスとしてクラスタ内で構成および使用される認証コンポーネントに使用される.注記:HDFS連邦メカニズムが同時に使用されている場合、この構成は、カンマで分割された他のnameservices、HA、または他のリストを含むように設定されます.

dfs.nameservices
mycluster

dfs.ha.namenodes.[nameserviceID]-nameservice内の各Namenodeの一意のIDに対してカンマで区切られたNameNode IDリストを使用して構成されます.これは、クラスタ内のすべてのNameノードを決定するDataNodeです.たとえば、myclusterを使用してnameservice IDを定義し、それぞれのNameNode IDとしてnn 1とnn 2を使用できる場合は、

として構成されます.

dfs.ha.namenodes.mycluster
nn1,nn2

注:現在、nameserviceごとに最大2つのNameノードを構成できます.

dfs.namenode.rpc-address.[nameservice ID].[name node ID]-各Name NodeのRPCアドレスと傍受ポートは、前に構成したName Node IDの2つの構成について、フルアドレスとName NodeプロセスのIPCポートを設定します.注意は、2つの対立する構成項目です.例:

dfs.namenode.rpc-address.mycluster.nn1
machine1.example.com:8020


dfs.namenode.rpc-address.mycluster.nn2
machine2.example.com:8020

dfs.namenode.http-address.[nameservice ID].[name node ID]-各NameNodeのHTTPアドレスと傍受ポートは、前述のRPCアドレスと同様に、NameNodeのHTTPサービスのアドレスとポート番号を設定します.例:

dfs.namenode.http-address.mycluster.nn1
machine1.example.com:50070


dfs.namenode.http-address.mycluster.nn2
machine2.example.com:50070

注意:Hadoopがセキュリティ機能を使用している場合は、NameNodeごとにHTTPSを構成できます.

dfs.namenode.shared.edits.dir-JNs(NameNodeが読み取り/書き込みの編集レコードをJNsに格納する)グループを識別するURI JournalNodeは共有編集ストレージを提供し、Active NameNode書き込みがあり、Standby NameNodeが読み取り、Active NameNodeが更新したすべてのファイルシステムの変化を維持し、ここではすべてのJournalNodeアドレスのアドレス列を構成する.いくつかのJournalNodeアドレスを指定する必要がありますが、URI列は1つだけ構成されます.

qjournal://*host1:port1*;*host2:port2*;*host3:port3*/*journalId*

このnameserviceでは、このJournal IDは一意の識別子であり、単一のJournalNodeセットが連邦ネーミングシステムにストレージを提供することを可能にする.必須ではありませんが、journal IDにnameservice IDを再利用するのは良いアドバイスです.たとえば、このクラスタJournalNodeは「node 1.example.com」、「node 2.example.com」および「node 3.example.com」マシン上で実行され、nameservice IDは「mycluster」であり、次の値を使用して構成できます.JournalNodeのデフォルトポートは8485です.

dfs.namenode.shared.edits.dir
qjournal://node1.example.com:8485;node2.example.com:8485;node3.example.com:8485/mycluster

dfs.client.failover.proxy.provider.[nameserviceID]-HDFSクライアントはActive NameのJavaクラス構成Javaクラス名に連絡します.このクラスはDFSクライアントが使用し、どのNameノードが現在Activeであるかを決定するため、このNameノードは現在クライアント要求にサービスしています.現在のHadoopの唯一の実装はConfiguredFailoverProxyProviderであるため、これは自己決定を行わない限り使用されます.例:

dfs.client.failover.proxy.provider.mycluster
org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider

dfs.ha.fencing.methods-スクリプトまたはJavaクラスのリスト.フェイルオーバの間、このActive Nameノードに使用されます.理想的な状態のシステムでは、任意の時点で存在し、1つのNameノードのみがActive状態である.重要なことは、QJMを使用していた場合、JNsへの書き込みが許可されるNameNodeは常に1つしかなかったため、脳クラック現象によるファイルシステムメタデータの破ループは不可能であった.ただし、フェイルオーバが発生した場合、元のActive Nameノードからクライアントへのリードリクエストサービスは、Nameノードが停止するまでJNsへの書き込みが試みられていたため、古い可能性があります.このため、QJMを使用する場合も、いくつかのfencingメソッドを構成する必要があります.しかしながら、fencingメカニズムの失敗イベントでは、システムの可用性が向上する.fencingメソッドを構成する最も賢明なのは、fencingメソッドのリストが最後に正常に戻ったことを確認することです.注意実際のfencingメソッドが選択されていない場合は、「shell(/bin/true)」などの設定も設定する必要があります.fencingメソッドは、リターンで分割されたリストを構成し、fencingが正常に戻るまで順次実行されます.hadoopはshellとsshfenceの2つの方法を提供します.カスタムfencingメソッドの実装についてはorgを参照.apache.hadoop.ha.NodeFencerクラス.1)sshfence-SSHはActive Nameノードに、そしてkillはこのプロセスsshfenceオプションSSHをターゲットノードに落とし、fuserを使用してTCPポートで傍受するサービスプロセスを殺す.このfencingオプションを動作させるためには、パスワードなしでSSHをターゲットノードにする必要があります.したがって、dfsを構成する必要がある.ha.fencing.ssh.private-key-filesプロファイルアイテム、カンマで区切られたSSH秘密鍵ファイルのリスト.例:

dfs.ha.fencing.methods
sshfence



dfs.ha.fencing.ssh.private-key-files
/home/exampleuser/.ssh/id_rsa

オプションとして、SSHを実行するために非標準のユーザー名とポートを構成するか、タイムアウト、単位msを構成することができます.SSHについては,fencingメソッドが時代遅れになると失敗とみなされる.次のように構成されています.

dfs.ha.fencing.methods
sshfence([[username][:port]])


dfs.ha.fencing.ssh.connect-timeout
30000

2)shell-shellスクリプトを実行し、fenceというActive Name Node Shell fencingメソッドは任意のshellスクリプトを実行し、以下のように構成されています.

dfs.ha.fencing.methods
shell(/path/to/my/script.sh arg1 arg2 ...)

「(」と「)」の文字列はbash shellに直接渡され、閉じたカッコは含まれません.shellコマンドは、現在のHadoop構成をすべて含む環境で実行され、構成キーを使用するときに''が使用されます.'.'を置換します.また、次の変数は、ターゲットマシンを参照してfencingを実行します.
変数名
説明
$target_host
fencingされたノードホスト名
$target_port
fencingされたノードのIPCポート
$target_address
上記の2つの変数を含みます.host:portなどです.
$target_nameserviceid
fencingされたNNのnameservice ID
$target_namenodeid
fencingされたNNのnamenode ID
これらの環境変数はshellコマンド自体の置換も使用できます.例:

dfs.ha.fencing.methods
shell(/path/to/my/script.sh --nameservice=$target_nameserviceid $target_host:$target_port)

shellコマンドが終了コード0を返すと、fencingは成功したと判断されます.他の終了コードが返されると、このfencingは成功せず、リスト内の次のfencingが実行されます.注意:fencingメソッドではタイムアウトは発生しません.タイムアウトが必要な場合は、shellスクリプトで実装する必要があります(たとえば、サブshellによって親プロセスを殺す秒数).

fs.defaultFS-指定されていない場合、Hadoop FSクライアントが使用するデフォルトパスプレフィックスはオプションで、HA論理URIを使用してデフォルトのHadoopクライアントパスを構成できます.たとえば、「mycluster」で定義したnameservice IDは、HDFSパス認証部の値として定義されています.core-site.xmlファイルには、

などの形があります.

fs.defaultFS
hdfs://mycluster

dfs.journalnode.edits.dir-JournalNodeプロセスは、そのローカルステータスのパスを格納します.これはJournalNodeノードマシン上の絶対パスです.編集ログと他のローカルステータスは、このパスに格納されます.単一のパスを構成として使用できます.これらのデータの冗長性はソグJNによって提供されるか、このディレクトリをローカルのRAID上に配置する.例:

dfs.journalnode.edits.dir
/path/to/journal/node/local/data

導入の詳細
必要なすべての構成項目を準備した後、JournalNodeデーモンプロセスを開始する必要があります.hadoop-daemonを使用します.sh start journalnodeコマンドが起動し、関連する各マシンのプロセスの起動が完了するのを待つ.JournalNodeの起動が完了すると、ディスク上の2つのNameNodeの同期メタデータを初期化する必要があります.

新しいHDFSクラスタを設定する場合は、まずNameNodesの1つで次のコマンドを実行する必要があります:

hdfs namenode -format

NameNodeがフォーマットされている場合、またはHA以外のクラスタをHAクラスタに変換する場合は、既存のNameNodeメタデータを他の非フォーマットのNameNodeにコピーする必要があります.フォーマットされていないNameNodeで次のコマンドを実行します.

hdfs namenode -bootstrapStandby

このコマンドを実行して、JN(構成としてdfs.namenode.shared.edits.dir)が2つのNameNode起動をサポートする十分な編集レコードトランザクションを含むことを確認します.

HA以外のNameNodeをHAのNameNodeに変換する場合は、次のコマンドを実行する必要があります:

hdfs namenode -initializeSharedEdits

このコマンドは、ローカルNameNode編集レコードディレクトリからJNが使用する編集レコードデータを初期化します.2つのHAのNameNodeを起動できるようになりました.一般的なNameNodeを起動するようになりました.各NameNodeのWebページには、設定されたHTTPアドレスから個別にアクセスできます.コンフィギュレーション・アドレスにはNameNodeのHAステータス('active'または'standby')が表示されます.HAのNameNode初期状態はいつでもStandbyです.