1台のマシンの性能劣化への対策（HBase）
taro_x
HBaseを使っていた際に、
1台のマシンの性能劣化で書き込み速度が大幅に劣化する問題が起こりました。
このような問題が設定で回避可能か、
ご教示いただけますでしょうか。
構成：
ZooKeeper用サーバ（ZooKeeper） 1台
Masterサーバ（NameNode, JobTracker, HBaseMaster） 1台
Slaveサーバ（DataNode, TaskTracker, HRegionServer） 6台
1台のSlaveサーバに発生した問題：
Slaveのうち1台だけ、
Masterからのpingの応答が、0.45ms ほどかかっていることを確認しました。
他のSlaveへのpingの応答は、0.15ms で、約3倍の時間がかかっている状態です。
原因は分かりませんが、サーバの初期不良？NICの問題？
かと思っています。
全体への影響：
この6台に対して、HBaseのテーブルへ、
100万レコード（カラム数7, 1レコードのサイズ1KB）
書き込んだ際に以下の時間がかかりました。
Slave 6台：2800秒
Slave 5台：199秒 （問題となったSlaveサーバを除いた場合）
pingの応答が3倍時間がかかるサーバがあった場合に、
クラスタ全体の性能が10倍以上劣化した状態です。
質問は以下の2点です。
1. 1台のサーバが、落ちるのではなく、性能が劣化するような事象が発生した場合に、
このような大幅な性能劣化が起こるのは、よくあることでしょうか？
このままでは運用で使う際に不安が残ります。
2. 1台のサーバの性能劣化が発生しても、全体に影響を与えないような設定をすることは可能でしょうか？
以上、よろしくお願いいたします。
Tatsuya Kawano
> 1. 1台のサーバが、落ちるのではなく、性能が劣化するような事象が発生した場合に、
> このような大幅な性能劣化が起こるのは、よくあることでしょうか？
HBaseでは、１台の性能劣化の影響が複数のサーバーに波及します。これは、HBaseのような強い一貫性（strong
consistency）を採用しているクラスタリングシステムでは避けられない問題です。一方で、全体として10倍の性能劣化が妥当かどうかは、今回問題が起こっているサーバーの性能劣化の度合いがわからない限り、なんともいえません。
HBaseでは書き込み時に、WAL（先行書き込みログ）をHDFSに書き込みます。設定にもよりますが、HDFSは、レプリカを、通常３台のData
Nodeに書き込みます。この書き込みは同期式に行われますので、書き込み関わる３台のData Nodeの応答時間は、一番遅いDeta
Nodeのものと同じになります。６台中３台に影響が出ますので、書き込みの２回に１回は、一番遅いData
Nodeの性能に引きずられることになります。
問題の起こっているサーバー向けのpingでは約３倍の時間がかかったとのことですが、HDFSの書き込みでは何倍の時間がかかるでしょうか？
pingのような数十バイトの小さなパケットなら３倍で済んでも、大きなパケットの通信では、ほとんどの通信に失敗して、数十倍の時間がかかっている可能性もあります。書き込みの２回に１回に影響が出ていると仮定すると、レプリカの書き込みに、19倍くらいの時間がかかっているのではないでしょうか？（0.5
* 1 + 0.5 * 19 = 10.0）
> 2. 1台のサーバの性能劣化が発生しても、全体に影響を与えないような設定をすることは可能でしょうか？
レプリカの配置を決めるのは（HBaseではなく）HDFSになります。が、HDFSでは、heterogeneousな環境に合わせた設定はできなかったと思います。（Map
Reduceなら簡単に調整できるのですが...。） HDFS互換の他の分散ファイルシステム（例 MapR
TechnologiesのLockless Storage
Service）でも、このような機能については、いまのところ聞いたことはありません。極端な性能劣化が判明した時点で、原因となっているノードを手動で停止させることが、現状では、最善の対応方法だと思います。
たつや
--
Tatsuya Kawano
Tokyo, Japan
Kazuki Ohta
/sbin/ifconfigの結果で、droppedパケットが大量に出ていたりしませんでしょうか？
その場合、私もCentOS5 + e1000e NIC環境で同じような問題が起こったことが有り、ネットワークドライバのアップグレードで解決しました。
> http://comments.gmane.org/gmane.comp.java.hadoop.hbase.user/17763
- K
2011/7/19 taro_x <taro...@gmail.com>:
--
--------------------------------------------------
Kazuki Ohta: http://kzk9.net/
CTO at Preferred Infrastructure: http://preferred.jp/
taro_x
> HBaseでは、１台の性能劣化の影響が複数のサーバーに波及します。これは、HBaseのような強い一貫性（strong
> consistency）を採用しているクラスタリングシステムでは避けられない問題です。
そうなのですか。
後でおっしゃっている通り、
「性能劣化が判明した時点で、原因となっているノードを手動で停止」
が最善の方法なのですね。
今回は、セットアップした段階から1つのサーバに問題があったようですが、
利用中に何らかの原因による性能劣化が起こった場合を考えて、
各サーバの状態監視が重要、と認識します。
> 問題の起こっているサーバー向けのpingでは約３倍の時間がかかったとのことですが、HDFSの書き込みでは何倍の時間がかかるでしょうか？
単体でのHDFS書き込みは行っていないのでわかりませんが、
問題のあるサーバを含んだ6台構成でHDFSの書き込みをした際、
レプリケーション数1とレプリケーション数3の時の差がかなり大きかったです。
「何割」ではなくて「何倍」よけいに時間がかかるレベルでした（手元に数字がないため曖昧ですみません）。
一旦問題のサーバは切り離して検証を進めているので、
問題のサーバに関して追加の調査は現在行っていませんが、
測定して何かわかったらまたご報告します。
落合雄介
On 7月19日, 午前11:10, Tatsuya Kawano <tatsuya6...@gmail.com> wrote:
> 落合さん、こんにちは。
>
> > 1. 1台のサーバが、落ちるのではなく、性能が劣化するような事象が発生した場合に、
> > このような大幅な性能劣化が起こるのは、よくあることでしょうか？
>
> HBaseでは、１台の性能劣化の影響が複数のサーバーに波及します。これは、HBaseのような強い一貫性（strong
> consistency）を採用しているクラスタリングシステムでは避けられない問題です。一方で、全体として10倍の性能劣化が妥当かどうかは、今回問題が起こっているサーバーの性能劣化の度合いがわからない限り、なんともいえません。
>
> HBaseでは書き込み時に、WAL（先行書き込みログ）をHDFSに書き込みます。設定にもよりますが、HDFSは、レプリカを、通常３台のData
> Nodeに書き込みます。この書き込みは同期式に行われますので、書き込み関わる３台のData Nodeの応答時間は、一番遅いDeta
> Nodeのものと同じになります。６台中３台に影響が出ますので、書き込みの２回に１回は、一番遅いData
> Nodeの性能に引きずられることになります。
>
> 問題の起こっているサーバー向けのpingでは約３倍の時間がかかったとのことですが、HDFSの書き込みでは何倍の時間がかかるでしょうか？
> pingのような数十バイトの小さなパケットなら３倍で済んでも、大きなパケットの通信では、ほとんどの通信に失敗して、数十倍の時間がかかっている可能性もあります。書き込みの２回に１回に影響が出ていると仮定すると、レプリカの書き込みに、19倍くらいの時間がかかっているのではないでしょうか？（0.5
> * 1 + 0.5 * 19 = 10.0）
>
> > 2. 1台のサーバの性能劣化が発生しても、全体に影響を与えないような設定をすることは可能でしょうか？
>
> レプリカの配置を決めるのは（HBaseではなく）HDFSになります。が、HDFSでは、heterogeneousな環境に合わせた設定はできなかったと思います。（Map
> Reduceなら簡単に調整できるのですが...。） HDFS互換の他の分散ファイルシステム（例 MapR
> TechnologiesのLockless Storage
> Service）でも、このような機能については、いまのところ聞いたことはありません。極端な性能劣化が判明した時点で、原因となっているノードを手動で停止させることが、現状では、最善の対応方法だと思います。
>
> たつや
>
> --
> Tatsuya Kawano
> Tokyo, Japan
>
taro_x
droppedパケットは出ていなかったようです。
また、
「ドライバが合わなくて、10baseで動作している可能性がある」
という話も聞いて、
別の者がethtool コマンドで確認したのですが、
1000baseTで動いているようでした。
一旦切り離して検証を進めていますが、
ネットワークドライバの問題かどうかも今後調べてみます。
ありがとうございました。
落合雄介
On 7月19日, 午後12:39, Kazuki Ohta <kazuki.o...@gmail.com> wrote:
> 落合さん
>
> /sbin/ifconfigの結果で、droppedパケットが大量に出ていたりしませんでしょうか？
> その場合、私もCentOS5 + e1000e NIC環境で同じような問題が起こったことが有り、ネットワークドライバのアップグレードで解決しました。
>
> >http://comments.gmane.org/gmane.comp.java.hadoop.hbase.user/17763
>
> - K
>