KLab勉強会#3のメモ

KLab勉強会#3 のご案内
KLab勉強会#3 ストリーミング配信のお知らせ

DSASのネットワークブートについてと、Erlangについて。
以下、見聞きした内容ではなくて、自分の解釈をメモ。

ネットワークブート

HDD搭載ノード

自分の中での１番のポイントは、HDDを積んでいるノードの使い方。

  • HDDを搭載したノードが一定数いる
    • ルートファイルシステム以外にコンテンツを保持しないといけないノードがHDDを搭載している
  • HDDを搭載したノードの内の１台が「マスター」になっている
    • マスターにはスレーブが１台くっついている
    • スレーブになれるのはHDD搭載ノード
  • マスターはDHCP+TFTPサーバーを動かしている
  • HDDを搭載したノードは、マスターが落ちたときにマスターになれる
    • マスター以外のHDDは、ネットワークブート時に専用ツールで同期する（DBとかはたぶん別）
    • マスターとしてブートするときは、HDDから起動する
  • ネットワークブートするノード用のルートファイルシステムは、マスターのHDDに入っている（→他のHDD搭載ノードにもコピーされる）
  • Webアプリのコンテンツなどは、マスターのHDDに配備して、そこから他のHDD搭載ノードに同期する

HDDを搭載したノードの内の１台を、マスターとしてHDDから起動することで、ネットワークブートシステムの「最初の１台問題」（←勝手に命名）が解決されている。それからマスターの他にもHDD搭載ノードを用意して、マスターを冗長化している。マスターとマスター候補のHDDはいつでも同期しておくのがポイント。


IPアドレスの割り振り方

もう一つポイントは、IPアドレスの割り振り方と、「自分が誰であるか」の判定方法。


つまり、IPMIに割り振られたIPアドレスでノードの個体を識別する。IPアドレスはMACアドレスよりも分かりやすい！IPMIいいなーいいなー（笑
さらにDNSで逆引きして、IPアドレスをホスト名にするというのは驚いた。その手があったか！


わかりやすさ：ホスト名 > IPアドレス > MACアドレス


DNSサーバーは、あらかじめ冗長化した状態で立ち上げておけばOKだけど、ここでVIVERプロジェクト的に困るのは、DNSサーバーは自動構築できないというところ。うーむ。マスターにLAN内ノードの逆引き専用のDNSサーバーをやらせて、スレーブと共に浮動IPで冗長化するか。マスターはどうがんばっても人手で起動しないといけない（←最初の一台問題）、そこにMATRIXのような役割分担ファイルを置くのが妥当だと思う。最初のマスターを起動して、続いてスレーブを立ち上げてしまえば、後は自立できる。
↑これはIPアドレスベースでノードを識別する場合で、IPアドレスをどう振るかという問題が解決できたらの話。VIVER的にはそれは苦しいと思うので、DNSで逆引きするのではなくて、マスターがその時点で起動しているノードの数を把握して、新しいノードに役割を与えるような仕組みが必要かもしれない。


ルートファイルシステムの作り方

続いてのポイントは、ネットワークブートするノードのルートファイルシステムの作り方。

ルートファイルシステムを更新したいときは、まずネットワークブートしているノードをどれか１台選んで、そのノードに対してアップデートをかけるなりする。そうしたら、そのノードのルートファイルシステムを.tar.gzで固めて、マスターにアップする（そして同期する）。ネットワークブートの利点を遺憾なく発揮！
普通に動作している状態のまま.tar.gzで固めるので、何も考えずにやると/var/lockなどなどにロックファイルなどが残ってしまう。そのあたりはtarで固めるときに除外する。（どこを除外するかと言うのは難しいだろうなぁ）



ネットワークブートしてみよう

ここから宣伝になりますが（笑）、プレゼンテーションの中でも紹介されている、HTTPで.tar.gzをダウンロードしてネットワークブートする（ブートするところだけ）と言う仕組みは、VIVER CORE Serverを使えば簡単に構築できます。（HTTP+tar.gzの他にも、rsyncでルートファイルシステムダウンロードしたり、NFSを読み込み専用でマウントして書き込みはtmpfsへ！みたいなこともできますよー）
ネットワークブートをするにはDHCPサーバーとTFTPサーバーとカーネルとinitrdと…が必要だよーということに関しても、VIVER CORE Serverパッケージにほぼすべて入っています。PXEに対応したマシン（NICとBIOS）はどうしても必要ですが、最近のマシンなら大体使えます。テレパソ的なパソコンだとあえて無効化してあるかもしれませんが、ネットワークブートを試してみたいような方ならPXE対応マシンは既に持っているはずです（笑


詳しくは以下のエントリを。現時点での最新バージョンは、VIVER CORE Server 0.0.5です。


特にinitramfsをいじる場合は、VIVER COREをベースにすると良い感じです。


Erlang

今流行のユーザーランドスレッドを言語レベルでサポートしている関数型言語。
プロセス（Erlangでのプロセス）同士は、メッセージパッシングで通信することで、デッドロックを回避。Mutexロックは使わない。なるほど！（自分でコレを１からやろうとすると大変大変…）
プロセス同士はお互いに死活を監視することができて、プロセスが落ちたらメッセージが飛ぶようになっている。←ここのところもメッセージパッシング。


ちょっと気になったのは、カーネルとErlangのVM間でIOのやりとりがどうなっているのだろうか。ErlangのVMの上で動くプログラムからは、IOはメッセージパッシングで全部非同期にできるらしいのだけど、カーネルはすべてのIOで非同期IOをサポートしているわけでもない。たぶん、VM内では別にカーネルスレッドを立てたり、pollやepollなどなどを使っているのだと思う。
でもErlangがスバラシイのはネットワークを越えるときで（atom型！というのがそそられる）、ローカルでひたすら非同期IOをやりたいんだーというのは守備範囲外なんだと思う。…というわけでまた宣伝になりますが（笑）非同期IOと言えばlibpioなんてものもあります。


Mnesia

Erlangで作られたマルチマスターで使える分散オブジェクトDBMS。マルチマスターでトランザクションができる。これはすごい！
ちょっと確かではないのだけど、ノードを足していくと、レプリケーションの数が増えていくだけで、保存できる容量は増えないよう。（次期V-FIELDは容量もスケールアウトさせようとしているのでややこしい）
いわゆるところの分散トランザクションだと思うので、速度はあまり速くないと思う。でもデータベースとしてのセマンティクスを保とうとすると、分散トランザクションは必須。でもファイルシステムくらいのセマンティクスでいいなら（書き込み中にファイルを読み込むと何が出てくるか分からない、書き込みをミスったらデータが壊れる）、もっとずっと高速化できるはず。次期V-FIELDそこを目指す。


データをHDDに書き込んでいるときで、電源障害などでノードが全部落ちてしまったあと、ノードを再起動させると、分散DBが復活する（落ちてから書き込みが行われているときは別）、というのがすごいと思った。
というのは、ネットワークブートの最初の１台問題と同じで、自分が最初の１台のときに、自分が持っているデータは正しいのかそうでないのか判断するのは難しい。すべてのノードが同じデータを持っていれば問題ないか…そうでない場合は非常にややこしい。