2010年06月03日

NameNode の SPoF 対策

Hadoop の一番の問題は、NameNode が SPoF になっているところだと思います。
ただ、構成でなんとか障害に強いシステムにすることはできると思います。例えば、以下のような感じ。

dual_namenode.gif

NameNode として、ロードバランサを指定しておき、NameNode は hot stanby の NameNode の disk を NFS マウントさせておき、namespace と transaction log を local の disk と NFS でマウントしている disk に書き込んでおきます。
障害を自動検出し、問題がある場合は、hot stanby に自動的に切り替えます。
namespace と transaction log は stanby の disk にも書き込まれており、NameNode としてロードバランサを指定しているので、問題なくサービス提供ができるはずです。

ちなみに、namespace と transaction log を2つの disk に書き込むためには、dfs.name.dir に ,(カンマ)区切りでディレクトリを指定するだけです。
fs.default.name にロードバランサの URI を指定する必要もあります。

ラベル:Hadoop
posted by おちエン at 01:03| Comment(0) | NoSQL | このブログの読者になる | 更新情報をチェックする

2010年06月01日

HDFS での file create の流れ

HBase のwrite 処理」を post しましたが、HBase でデータを write すると、最終的には HDFS に保存されるので、HDFS の write 処理を知っておくこと必要があります。

ということで、今日は HDFS の file create の流れです。
図にすると以下のような感じ。
あくまでもこういうイメージというようなざっくりした感じでとらえてください。
hdfs_create.gif

client が HDFS にファイルを新規作成し、書き込もうとしています。 すぐさま、NameNode に通信して、というわけではなく、まずは local に temporary file として書きだします。その temporary file が HDFS のブロックサイズになるか、close() されるかしたときに初めて、NameNode にファイル作成が通知されます。
NameNode はファイル名を保存し、データブロックの割当を行い、ファイルを保存すべき DataNode とデータブロックを client に返します。
それを見て、client は指定された DataNode にデータを書き込みます。replication は、client から直接行われるわけではなく、1つ目の DataNode から別の DataNode へ、さらに必要な場合は、2番目の DataNode からさらに別の DataNode へデータが渡されることで行われます。これを Replication Pipelining と呼んでいるようです。

詳しくは、HDFS Architecture を参照してください。
ラベル:Hadoop
posted by おちエン at 02:11| Comment(0) | NoSQL | このブログの読者になる | 更新情報をチェックする

2010年05月31日

YCSB の論文にでてくる HBase の説明

YCSB とは、Yahoo! Cloud Servicing Benchmark のことで、Yahoo! Research が作った様々な cloud service、というとかなり曖昧ですが、NoSQL だけに限らず、sharded MySQL なども含めた storage の benchmark を行うためのツールです。

YCSB の論文では、実際に、
  • Cassandra
  • HBase
  • Yahoo! PNUTS
  • sharded MySQL
の benchmark を取っています。
論文自体は、 http://www.brianfrankcooper.net/pubs/ycsb.pdfから読めますが、HBase の説明について、ん?と思うところがありました。
具体的には "6.1 Experimental Setup" の以下の部分、
For Cassandra, sharded MySQL and PNUTS, all updates were synched to disk before returning to the client. HBase does not sync to disk, but relies on in-memory replication across multiple servers for durability; this increases write throughput and reduces latency, but can result in data loss on failure.
日本語に訳すと、
Cassandra, shared MySQL, PNUTS の場合、更新があった場合、client に処理を戻す前に disk に書き込みが行われる。しかし、HBase は disk に書き込みを行わない。永続性は、複数のサーバ間でメモリ内にreplica を持つことに頼っている。これにより、write のスループットは向上し、処理速度も速くなる。しかし、障害時にデータロスする可能性がある。
という感じ。

HBase の in-memory replication って何だよって感じなのですが。

この件について、HBase の Mailing List の投稿がありました。
http://www.mail-archive.com/hbase-user@hadoop.apache.org/msg10169.html

スレッドを読んでみると、「この表現は非常に誤解を与える」とか「部分的に間違い」があるとか言われています。
実際のところ、HBase の write については「HBaseのwrite処理」で書いた以上のことは行われていません。すなわち、
  1. HBase のデータは最初は memory に書かれる
  2. memory cache の大きさがしきい値に達すると HDFS に書かれる
  3. HDFS は当然 replication を行う
YSCB の論文の話は、がんばって説明すると、HDFS に書かれたからと言って、即、物理 disk に書かれるわけではない。なぜなら、実際に物理 disk に書かれる前に、kernel buffer に書かれるから。。。的な話になっていますが、かなりな屁理屈な気がしないでもないですね。

HBase で in-memory の replication が行われているわけではない と思っておいた方がよいでしょう。

ところで、この論文では write-ahead log(WAL)は無効にしているため、HBase の update の latency が非常に速くなっていますが、実際の運用では WAL を無効にすることはないでしょうから、この結果をそのまま信じることはできません。
あくまでも、YCSB の説明の一環で benchmark 例を出しているだけなので、実際に HBase と Cassandra を比べる場合は、実運用の設定で benchmark する必要があります。

ラベル:Hadoop HBase
posted by おちエン at 21:33| Comment(0) | NoSQL | このブログの読者になる | 更新情報をチェックする

2010年05月30日

HBaseのwrite処理

HBase の write 処理を調べてみました。
HBase は HDFS を使用しているため、最終的にデータは HDFS 上に保存されます。物理 disk で考えると、Hadoop が分散システムで構築されている場合、複数のサーバの物理的な disk に保存されることになります。

ただし、HBase は memory cache を持つため、write を行えばすぐにデータが物理 disk に書きこまれるわけではありません。
write のデフォルトの動作は、
  1. write-ahead log が書き込まれる
  2. メモリにデータが書き込まれる
となっています。
hbase_write.gif

write-ahead log は HDFS 上に書きこまれるため、すぐに disk に書きこまれることになります。
メモリに書き込まれたデータは、memory cache がある程度のサイズにならないと、HDFS に書きこまれません。
memory cache がしきい値を超えると、メモリにあるデータが HDFS 上に書き込まれます。

こういう仕組みのため、read の場合は、当然、memory 上のデータと HDFS 上のデータ、すなわち、物理 disk のデータ、を調べる必要が生じます。

write 時に write-ahead log を書きこまないようにすることもできるようです。そのようにプログラムを書くと、write はメモリに書き込むだけで十分なので、latency(処理時間)は相当小さくなります。
write-ahead log を書きこむ理由は、障害時の復旧のためなので、通常の運用で write-ahead.log を書かないというようなことはすべきではないでしょう。
ただ、Map/Reduce で HBase に書きだしたりする場合、write-ahead log の書き込みが latency に影響を与えるため、そういう場合は off にするようなこともあるでしょうというようなことがどこかに書いてありました。

write-ahead log を off にするためには、Put::setWriteToWAL(false)を使うようです。

ラベル:Hadoop HBase
posted by おちエン at 19:59| Comment(0) | NoSQL | このブログの読者になる | 更新情報をチェックする

HBase と CAP Theorem

分散システムで必ず話に出てくるのが、"CAP Theorem" らしいです。
CAP Theorem 自体は簡単な話で、「CAP のすべてを満たすことはできず、最大2つしか満たせない」というもの。

この意味自体は理解できたのですが、なんとなくしっくりできない部分があったのですが、その原因がやっとわかりました。
原因は2つあって、
  • CAP それぞれの定義がドキュメントによって様々ある
  • CAP のそれぞれについて考えてしまう
という点です。
この点に注意しながら、HBase の CAP について書こうと思います。

そもそも、CAP のそれぞれの定義は、C は Consistency で「データの整合性」という意味です。データが書かれた後、そのデータを読んだ場合、最新のデータが得られる場合、consistency のあるシステムだと言えます。
たとえば、replication を行っていて、write は master を、read は replica(slave) を見るシステムの場合、master に書きこんでから、replication が行われるまでのタイムラグが原因で、最新のデータが得られない場合があります。また、最近流行りの NoSQL なシステムは、eventually consistency などを謳ったものが数多くありますが、こういうシステムも同様に consistency を犠牲にしています。

A は Availability で「可用性」という意味です。1つのサーバ(node)に障害が起こっても read/write が可能であれば、availability があるシステムだと言えます。例えば、RDB で write に使用される master が1台しかない場合、その1台が落ちるとサービスを提供できなくなります。そういうシステムは、availability がないシステムです。Dual-Master にすれば、言うまでもなく availability は上がります。

P は Partition Toleranceで、サイトによってまちまちなのですが、「ネットワーク障害などによる message loss に対する耐性」を意味しています。replication を行っているシステムは、master から slave への通信が切れれば、どうしようもなくなるので、Partition Tolerance がないと言えます。

あるシステムに対して、CAP それぞれに対してどうなっているか考えると(たぶん)意味不明になります。
そもそも、CAP theorem 自体、これらのうち、多くても2つしか満たせないよという話なので、システムの特徴を見て、最終的に AP だ、CP だと判断するのが良いと思います。

HBase は、あるデータに対して、1つの HRegionServer が担当します。read も write もその HRegionServer を通して行われます。したがって、consistency は極めて高いですが、その HRegionServer が落ちるとサービスを提供できなくなるので、availability を犠牲にしていると言えます。また、HBase レベルで replication は行っていないため、ネットワーク障害うんぬんは関係ありません。したがって、HBase は CP のシステムということができます。

ただし、HBase は HDFS 上で稼働しており、実際にデータはいくつかのnode に書き込まれます。したがって、ある HRegionServer が落ちたからと言って、データが失われるというわけではありません。
実際、HRegionServer が死ぬと、HBaseMaster が region を他の HRegionServer に再割当を行います。再割当が行われる間は、死んだ HRegionServer に割り当てられていたデータ(region)のアクセスはできませんが、再割当後、アクセスできるようになります。
したがって、HBase の availability は完璧ではありませんが、自動的に復旧することである程度の availability は提供できていると言えます。

HBase においてはネットワーク障害は気にしなくて良いと書きましたが、ネットワーク障害が起こった場合、HDFS がデータを replication できなくなり、その状態で、この node も落ちるとデータは失われてしまうという危険性はあります。

もう1つ重要なのは、Hadoop の Namenode は SPoF なので、Namenode が死ぬと HBase 自体も利用不可能になる危険性があります。

したがって、HBase をフォントサイズで表現すると CAP な感じでしょう。
ラベル:Hadoop HBase
posted by おちエン at 06:50| Comment(0) | NoSQL | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。