3

HDFS Namenode に HA を提供するために Facebook が使用している AvatarNode ソリューションを見ると、NFS が使用される理由がわかりません。私が混乱しているのは、HA を実現するために、NFS がとにかく複製しなければならないことです。HA を実現するには、プライマリが NFS に書き込み、フラッシュする必要があります。プライマリとセカンダリの間のソケット チャネルを単純に開き、セカンダリ Namenode に同じ書き込みを実行してみませんか。(ほぼ) 同じ量のネットワーク トラフィックになり、同じレプリケーション セマンティクスを持つように見えます。

問題は、なぜこれが行われないのかということです。

理由の 1 つは、NFS が存在することであり、そのため、問題はおそらく実装が簡単である可能性があると思います。しかし、ストリーム インターフェイス (つまりファイル) に書き込まれるのと同じ情報を NFS に書き込む、プライマリとセカンダリの間で raw ソケット チャネルを使用する (明らかな) シンプルさを考えると、なぜこれが行われなかったのか頭を悩ませています。まだ完了しました。

確かに、NFS の使用を選択するのには、私の安楽分析では見落としている正当な理由があるに違いありません。

4

3 に答える 3

2

わかりませんが、これは非常に奇妙な選択のように思えます。他の理由は考えられませんが、何かを修正する任務を負ったチームが、他の用途に機能していた機能する NFS セットアップを持っていたという点で同意します。しかし、私の経験に基づいて、NFS はもう 1 つのシングルポイントで失敗すると考えており、このような場合には NFS を選択しません。

于 2012-06-14T18:36:53.280 に答える
1

興味深い質問です。AvatarNodes でこの投稿を見つけました: http://hadoopblog.blogspot.com/2010/02/hadoop-namenode-high-availability.html

AvatarNode を使用すると、名前ノードがダウンしたときのダウンタイムを最小限に抑え、1 分以内に新しい名前ノードでバックアップできるように思えます。

Hadoop のドキュメントから:

The term "secondary name-node" is somewhat misleading. It is not a name-node in the   
sense that data-nodes cannot connect to the secondary name-node, and in no event it can 
replace the primary name-node in case of its failure.

セカンダリ ネーム ノードはネーム ノードとして機能できないため、新しいネーム ノードの復旧または起動時に長時間のダウンタイムが発生する可能性があります。

AvatarNode は、セカンダリとプライマリの両方として機能し、VIP を切り替えるだけで迅速なフェイルオーバーを可能にします。

ソケットではなく NFS を使用する理由について、投稿には次のように書かれています

It is guaranteed that the Standby AvatarNode ingests all committed transactions because    
it reopens the edits log and consumes all transactions till the end of the file; this 
guarantee depends on the fact that NFS-v3 supports close-to-open cache coherency 
semantics.

これは、ネームノードがダウンしたときのデータ損失を最小限に抑え、HDFS 編集データとの一貫性を維持するための問題だと思います。クローズからオープンへの一貫性保証の詳細については、http: //nfs.sourceforge.net/#faq_a8を参照してください。

于 2012-06-13T23:51:05.017 に答える
0

ハル、これはあなたの質問に答えるかもしれません（特に「道を下る缶を蹴る」ビット）..

于 2012-06-18T21:42:26.327 に答える