RUNESの目指すところ

VIVER

現在次期VIVERを書いています。1ヶ月あればできる予定。

  • メディア優先順位付きディスクイメージ発見

　ディスクイメージを探すとき、すべてのメディアから探すので、CDからディスクイメージをコピーしておくだけでHDDからでもブートできるのですが、CDとHDDの両方にディスクイメージがあったときに、どちらから起動するか分からない。というわけでメディアのタイプ（HDD、CD/DVD、フラッシュメモリ、内蔵、外付け、ファイルシステムタイプ、接続方式）を自動判別し、より速そうなデバイスを使う機能。ユーザーからの指定もこれらの情報を使って指定する。（bootmedia=usb,flashとかbootmedia=ntfs,hddとか。基本は自動判別）半分実装完了。

　今、ディスクからのブートはGRUBで、ネットワークブートはSYSLINUXになっているのですが、これはわかりにくい。ブートパラメータの指定はSYSLINUXの方がやりやすいけど、GRUBは矢印キーで選択ができる。GRUBに統一しようと思ったら、GRUBはネットワークブートで使えない（普通は使えるけどVIVERの性格上使えない）ことが判明してしまったので今のようになっています。たぶんSYSLINUXに統一します。（GRUB 2かも？）

  • ハードウェア自動検出ツール２

　検出精度がさらに上がります。

  • initramfs

　initrdからinitramfsになります。もしかしたらファイルサイズの関係で実現できないかも。

  • RAID対応

　たぶんBIOSベース系RAIDとソフトウェアRAIDに対応します。ただしBIOSベース系はLinuxの対応状況に完全に依存し、ソフトウェアRAIDは構築済みのものに限ります。USBメモリ４本でRAIDとか、ははー。

　cow溢れ問題が深刻＆aufsが非常に良いので、aufsに変更します。差分がファイルシステムレベルになってSquashfsが直に使えるので、ディスクイメージのサイズも少し小さくなります。Squashfsの圧縮アルゴリズムはdeflateでいきます。






で、本題はRUNES。


現状のRUNESは、起動時にプラグインを起動して終わりなので、起動後の処理はすべてプラグインの責任になっています。


起動後にNFSサーバーを動かしたり、最初のコンピュータのIPアドレスを変えたりという作業は、すべてプラグインが独自にサポートするか、手作業でなければなりません。
当然、起動後になって他のホストから通信を受け取って処理したい、ということもプラグインが独自にサポートしなければならないため、そういったプラグインの開発は困難です。


他のホストからの通信を受け取れると何が嬉しいかというと、NFSサーバープラグインが別のホストのNFSクライアントプラグインからメッセージを受け取ったときに自分のIPアドレスとexportしているパスを返すとか、サービスの発見→設定が可能になる。


さらに、当然自ホストからのメッセージも受け取れるので、↓のようなシナリオが考えられる

1. 最初のコンピュータ起動
2. DHCPでアドレスの割り当てができなかった
3. ユーザーが自ホストのIPアドレス設定プラグインに、「***というIPを設定せよ」とメッセージを送る
4. IPアドレス設定プラグインは、RUNESメッセージバスに、「IPアドレスが変わった」とメッセージを投げる
5. DHCPサーバー設定プラグインがメッセージを受け取り、DHCPサーバーを再起動
6. V-FIELD起動プラグインがメッセージを受け取り、V-FIELDを再起動
…

1. 全ホストに「LDAPでパスワード管理しているサーバーはいないか？」と聞く
2.a. 「管理しているよ」という応答帰ってきたら、nsswitchを変更
2.b. 応答が一つも帰ってこなかったら、自分がLDPAを起動

1. 「NFSサーバーやってます」というメッセージを受け取ったら、自動的にマウントするプラグイン
2. 起動時にNFSサーバーを起動し、「NFSサーバーやってます」というメッセージを全ホストに投げる
3. 「NFSサーバー起動せよ」というメッセージを受け取ったらNFSサーバーを起動し、「NFSサーバーやってます」というメッセージを全ホストに投げる。「NFSサーバー起動せよ」を投げるのはユーザーだったり、他のプラグインだったり。

メッセージは確実に届かないとプラグインの設計がやりにくいので、信頼性がないといけない。
というわけで、「メッセージの送受」と「信頼性の高いマルチキャスト」をRUNESでサポートしたい。





続いて、プラグインをオブジェクト指向言語で言うところのクラスに見立てて、クラス変数をサポートするのと、ノード間の排他処理をサポート。そしてノードのダウンをプラグインに通知する機能。

1. 最初のコンピュータ起動
2. DHCPサーバープラグインで、IPリース情報をクラス変数に入れておく。自分のIPアドレスも入れる。このとき排他処理もやる
3. 後発のコンピュータでもDHCPサーバープラグインを起動。他のホストのIPアドレスが入っているので、実際にはDHCPサーバーを起動しない
4. 最初のコンピュータがダウン！
5. 全ホストの全プラグインに、最初のコンピュータが落ちたことがRUNESから通知される
6. a. DHCPサーバープラグインは、クラス変数をロックし、もしまだ最初のコンピュータのIPアドレスが入っていたら、クラス変数内のIPリース情報を引き継いで自分がDHCPサーバーを起動する。
6. b. ロックが取得できたときには最初のコンピュータのIPアドレスがもう入っていなかったら、待機を続ける
…
…以下、何度でもフェイルオーバー

別にDHCPサーバーである必要はなくて、どんなサービスでも、排他処理ができる ＋ 落ちる前の状態をクラス変数に入れておいて後で引き継げる の２つで、フェイルオーバーが非常に簡単にできるようになる。ただ「落ちる前の状態」のサイズが大きいと、常日頃の保持が大変になるので、そこはV-FIELD的な分散保持ができれば完璧。…要するにV-FIELDに書き込みサポートを追加すれば完璧なんですが。