Home > 日記 > 日記2013前期 Archive

日記2013前期 Archive

CDH4でOS再起動をすると実質的にプロセスの強制終了になる件について

英語でチケットを書く元気が今ないので、日本語でメモ。最終的には私が見つけたわけではないけど。

Cent6.3での話です。

今のCDH4系のinitスクリプトだと、OS再起動時や終了時にHadoop関連プロセス(NameNode, DataNode, JobTracker, TaskTracker, 2NN等)が正しく正常終了できないという・・。rebootとか叩いた日にはプロセスは正常終了しません・・。

Redhat系の場合、再起動はランレベルが6なわけで、例えばDataNodeの場合は以下のようになっています。

hadoop-hdfs-datanode    0:off   1:off   2:off   3:on    4:on    5:on    6:off

/etc/rc.d/rc を見ると以下となっています。 

# First, run the KILL scripts.
for i in /etc/rc$runlevel.d/K* ; do

        # Check if the subsystem is already up.
        subsys=${i#/etc/rc$runlevel.d/K??}
        [ -f /var/lock/subsys/$subsys -o -f /var/lock/subsys/$subsys.init ] || continue
        check_runlevel "$i" || continue

        # Bring the subsystem down.
        [ -n "$UPSTART" ] && initctl emit --quiet stopping JOB=$subsys
        $i stop
        [ -n "$UPSTART" ] && initctl emit --quiet stopped JOB=$subsys
done

/var/lock/subsys/hadoop-hdfs-datanode というロックファイルが作られていれば、OS停止時にプロセスの停止をしてくれます。(shutdown や reboot した時にズラーーーッと緑の文字で OK OK OKって出てきますね)

DataNodeの場合は、chkconfig --add した時に以下のファイルが作られます。 

/etc/rc.d/init.d/hadoop-hdfs-datanode
/etc/rc.d/rc0.d/K15hadoop-hdfs-datanode
/etc/rc.d/rc1.d/K15hadoop-hdfs-datanode
/etc/rc.d/rc2.d/K15hadoop-hdfs-datanode
/etc/rc.d/rc3.d/S85hadoop-hdfs-datanode
/etc/rc.d/rc4.d/S85hadoop-hdfs-datanode
/etc/rc.d/rc5.d/S85hadoop-hdfs-datanode
/etc/rc.d/rc6.d/K15hadoop-hdfs-datanode

これは /etc/rc.d/init.d/hadoop-hdfs-datanode のコメントに、以下の記述があるからです。

# Starts a Hadoop datanode
#
# chkconfig: 345 85 15
# description: Hadoop datanode
#
### BEGIN INIT INFO
# Provides:          hadoop-hdfs-datanode
# Short-Description: Hadoop datanode
# Default-Start:     3 4 5
# Default-Stop:      0 1 2 6
# Required-Start:    $syslog $remote_fs
# Required-Stop:     $syslog $remote_fs
# Should-Start:
# Should-Stop:
### END INIT INFO

こーいうコメントを拾って設定しているなんて知りませんでした・・。 

datanodeのinitスクリプト、肝心のLOCKファイルは・・ 

LOCKDIR="/var/lock/subsys"
LOCKFILE="$LOCKDIR/hadoop-datanode"
....
[ $RETVAL -eq $RETVAL_SUCCESS ] && touch $LOCKFILE

う、うん・・。ファイル名が違うね。これは hadoop-hdfs-datanode じゃないとダメだよね・・。直したらOS停止時にもきちんとSTOP処理が呼ばれるようになりました。
CDH4のプロセス全部に当てはまるので、注意が必要です。(ただし、HBaseとかは入れてないので見てない)

Fluentd Casual Talksに参加して意識がちょっと高まったのでArangoDBのPluginを書いてみた

なんかタイトルがラノベっぽい。

Fluentd Casual Talks #2 に参加してきたので、その感想でも。

-- 感想 --

JRの駅からヒカリエに行く方法がわからず、20分ほどうろうろして最終的に駅員さんに聞きました。くやしくなんかないもん。(震え声)

just_do_neet さんの運用の話は、とても良かったです。とりあえず入れてみて、それっぽく動いている。ハッピー。 というわけでもなく、きちんと検証したんだなーという感じが特に。駆け足だったので、ちゃんと追えていないけど・・(´・ω・`)

そしてangostura11さんがStreamに対してクエリを発行できるものを発表されていて、それってかなり便利なんじゃ。。でもJavaかぁーとか思ったり、Spring_MTさんの話でFluentdがテスト用のドライバを用意しているという事を知り、じゃぁテスト書くの楽なのかもとか思って、会場の後ろの方でpluginをこそこそと書き始めていました。

他の発表者の方も、短い時間でテンポ良くしゃべっていて、一部の内容は理解できなかったけど、タメになったなぁという感じです。

それはそうと、oza_x86さんのデスクトップ(?)にHADOOPのパッチが沢山置いてあったのが一番気になりました(;゜ロ゜)

-- 感想終わり --

--  次は Fluentd について思っていること  --

もうあちこちで言われているので、わざわざ書く必要もないかもですが、個人的にFluentdの良いところというのは、再送処理を現実的な範囲でそれなりに担保してくれるという事と、in_tailプラグインの存在だと思っています。

Webの例なんかはあちこちに出ているので、他の・・例えば400台くらいのゲームサーバがあったとして(昔CEDECで発表されていたの、これくらいでしたよね)、それのログはローカルDISKに書き込むか、専用のログサーバに転送するか、もしくはその両方を行うとかやると思います。ここまでかっちりと作ってあるものなら、まぁ別にそれなりに動きますが、時としてローカルDiskにのみログを出力しているものがあります。

ちなみに、(自分が知っている範囲で言うと)オンラインゲーム(ソーシャルゲームじゃないよ)のログというのは、ユーザー比率的にWebのログよりも圧倒的に多く、ちょっと追加しようものなら、ものすごい勢いでDiskを食いつぶしていきます。

話はそれましたが、まぁとにかくローカルDiskに書き込むケースが多いわけです。で、これを何かしらの方法で集約するか、もしくはその各ホスト上で直接分散検索をしたりするわけです。これで困る点はホストが壊れて代替機に振り替えた場合、そのホストにあるログが・・・ という問題があるわけです。集約するにしても、バッチ処理的に吸い上げるとスパイクな負荷がかかります。まぁこれもあちこちで言われている話なので言うまでもないですね。

で、in_tailの何がすばらしいかというと、既に作ってあるアプリケーションに対して何も変更を行うことなく、外部プロセスでStreamで他所の場所に集約できるという点です。 これ、かなり嬉しかったです。昨年のCEDECで国民的ゲームのデータベースの発表をした人も、in_tail イイね!と話した記憶があります。

そんなわけで、 in_tail を標準のpluginで入れているのは実は凄く素晴らしい事なんだと思っているわけです。
(当たり前すぎるのか言及している人を見かけない・・(´・ω・`))

-- Pluginを作ってみた話 --

話を聞いて、まぁ私もPluginを書いてみるかと思うわけですが、実際に書いてみると、コピペをしない場合は最終的にソースを見る羽目になるわけです。

例えば、テストを書くにしてもドキュメントを見ると、out_fileのテストを参考にしなって書いてあるし、何を継承するかとか、親クラスは何のパラメータを持っているのかとか、ソースを見ないと分からない(分かりづらい)わけで。こんなパラメータ合ったんだとか (例えば num_threads なんかは一部のTwitterと一部のBlogにちょろっと出てくるくらいです)、新しい発見があって、fluentdに限って言えば、pluginを1回書いた方が理解が深まるなと思いました。

その肝心のpluginの作り方ですが、pluginを○時間で書いたとかいう話をPlugin製作者が言ってますが、実際そーいうレベルの時間で書くことができました。outputプラグインに関しては、驚くほど抽象化されているので、やりたい事だけをペイッと書くだけです。めんどくさい処理はMixinで提供されいるので、楽ちんです。ただ、存在を見つけるのに時間がかかりました・・(´・ω・`) このドキュメントに載っていないので、複数のPluginのソースを参考にして、fluentdやpluginのソースを検索しまくりでした。

テストもドライバが用意されているので、TDDで書くことができます。

-- fluent-plugin-arango について --

そんなわけで、ArangoDBに書き込むためのpluginを書いてみました。ソースはこちらに、Gemはこちらにあります。 ArangoDBは最新版ではbulk_importを持っているのですが、rubyのclientであるashikawa-coreがまだサポートしていないので、1件ずつ書いています。
(そういえば、Collection勝手に作るから、wait_syncのパラメータが必要かも)

使い方はこんな感じです。

<match access.**>
  type arango
  collection ut_col
  scheme http
  host localhost
  port 8529
</match>

BufferedOutputを継承し、SetTimeKeyMixin, SetTagKeyMixinをincludeしているので、それらのパラメータも指定する事ができます。 詳しくはREADMEに記載しています。

実際にArangoDBのWebUIから確認をすると、データが入っています。

何かまずい点をみつけたら、ご指摘いただけると嬉しいです。

Fluentdに負荷をかけるクライアントを作った

Fluentdに負荷をかけたいなと思いまして・・。
前回作ったapache-loggenを使っても良いのですが、あれだと一度diskに出力する事になるし、Rubyなので複数コアがあるホストだと何プロセスも起動するのは嫌だなーと。

というわけで、今回はマルチプロセスで直接Fluentdにmsgpack形式のデータを投げるものを作ってみました。
in_forwardで受け付ける形式は何個かあるみたいですが、今回は以下の形式のものを。

[ tag, [time, rec], [time, rec], [time, rec], ... ]
rec = { ... }

実際の実行画面のキャプチャです。

 

なんか、ほとんどマスクしちゃってますね(´・ω・)
parallelでforkするので複数コアを活用します。情報はUNIXSocketで親プロセスへ集めて表示はCursesを使っています。それぞれの子プロセスの情報とそれぞれを集計した情報を出力しています。

灰色でマスクしているところには設定が表示されています。上記の画面では、毎秒10リクエスト、1リクエストで50レコード、つまり毎秒500レコード。それを4プロセスで送りつけているので、毎秒2000レコードの負荷をかけているものになります。全開でまわせば、L社の初期の流量くらいは出せると思います。

使い方はこんな感じ。

$ ruby load.rb --help
Usage: load [options]
        --host         負荷をかけるFluentdのホスト名。  デフォルトはlocalhost。
        --port         負荷をかけるFluentdのポート番号。デフォルトは24224。
        --rate=RATE    1秒間に送信するリクエスト数。デフォルトは制限無し。
        --num=NUM      1回のリクエストで送信するレコード数。デフォルトは1。
                       いわゆるArrayの要素数。
        --thnum=THNUM  負荷をかけるプロセスの数。デフォルトは1。
        --mode=MODE    ログの形式を指定する。これは会社依存のオプションなので詳細は無し。
        --fixed-time   ダミーログの時間を元ファイルの時間のまま送る場合に指定する。
                       指定しなければ現在の時間に直して送信される。
                       (これも会社依存のオプション)

ログを生成する部分は apache-loggen を使って、apacheのログではなく アプリの実際のログを元に生成しています。なので、このままでは公開はできないのですが、ここを除去すれば問題ないので気が向いたらやろうかなと・・。

気が向いたら・・。

 

SELinuxがSSHの公開鍵認証を邪魔する!

CentOS6.3でSSHの公開鍵認証、パーミッションの設定大丈夫なのになんでログインできないのかなーと思ったら、SELinuxが原因でした。

ぐぐると、SELinuxをoffにする設定が多いのですが、せっかくなのでSELinuxの設定をどうすれば良いのか試してみた。

setsebool allow_ssh_keysign=on
setsebool ssh_sysadm_login=on
restorecon -R -v /root/.ssh

rootの場合は、こんな感じで良いらしい。
上2行だけだとダメだったので3行目も追加(´・ω・`)

(追記) 3行目だけで良いらしいです。なので以下だけでできるっぽい。

restorecon -R -v /root/.ssh

SELinuxわからんぷい。
※SELinuxをdisっているわけではありません!

こちらに詳細があります http://2done.org/index.php?id=76

 

Hiveのロゴについての豆知識

hcj2013wお疲れ様でした。
Ust録画や講演資料は殆ど公開されているようです。

特別企画として、NHNのなんとかモリスさんという方と、TreasureDataのりぴーなんとかさんという方がClouderaをスポンサーにつけてHiveTシャツを作ったそうで、私も1着いただきました。懇親会でHiveの愛を語ると戴けるという体を取っていたのですが、私はキーノートの前に戴いてしまったので、ここでHiveの愛を語ってみようと思います。

Continue reading

Home > 日記 > 日記2013前期 Archive

Search
Feeds

Return to page top