はじめに
OpenBlocksシリーズには、発売以来の特徴として壊れにくさがあります。これには、たとえばファンレスであるとか電解コンデンサを使用しないなどのハードウェア設計上の理由がありますが、このほかにも使い方からのアプローチとして、SSDなどのストレージを使用せずにシステムを構築できる点も大きな理由となっています。
搭載するソフトウェアの容量が少なかったり、アプライアンスのようにあらかじめ用途が限定されている場合には、ストレージの故障に関する想定が不要になりますので、より堅牢なシステムを構築できます。今回はストレージを使用しないディスクレスシステムの構築方法や、そのメリット・デメリット、しくみなどを紹介します。
フラッシュROMで実現するディスクレスシステム
OpenBlocksシリーズのディスクレスシステムは、基板上にある128MBのフラッシュROM(NOR型)と1GBのメインメモリの組み合わせによって実現しています(図1)。Linuxが起動すると、メインメモリの一部をRAMディスクとして確保し、あらかじめフラッシュROMに保存してある構築済みのシステム内容をそのRAMディスク上に書き戻すことで環境を復元しています。メインメモリとフラッシュROMの関係を表したものが図2です。図中の丸数字は、フラッシュROMからの展開が行われる順序です。
なお、SSDなどのストレージを併用する場合は、図2のRAMディスク(2)の部分がストレージに置き換わります。この場合、RAMディスクのように起動のたびに初期化・再設定されるわけではないため、フラッシュROMからのユーザエリアの書き戻し(図2の②と③)は行われません。
ディスクレスのメリット
ディスクレスシステムの大きなメリットは、ストレージを使用しないことで故障要因を排除できることです。信頼性が向上し、普及が進んだことで、価格面でも導入しやすくなったSSDが搭載可能ですが、SSDにはNAND型メモリを使用したストレージの特性上、書き換え寿命を無視するわけにはいきません。ディスクレスシステムはこの懸念を排除できるので、導入後の不具合発生の可能性が低減できることが期待できます。
また、RAMディスクは起動のたびに初期化・再設定されるため、突然の電源断にも強くなります。ストレージを使用している場合に電源断が発生してしまうと、ファイルシステムの破損が起こり、正常に起動しなくなることもあります(※)。
ディスクレスのデメリット
一方、ディスクレスシステムではソフトウェアやデータなどの保存領域が限られることが懸念事項となります。ディスクレスの場合、圧縮した追加ソフトウェアやデータを図2のユーザエリア(2)に保存します。圧縮効率はデータによってまちまちですが、おおよそ領域の2~3倍程度の容量が保存可能です。つまり、100~150MB程度といったところになりますが、DNS/DHCPなどのインフラ系やWeb、Proxyなどのいずれかのサーバに加えてRuby/Perlといったインタプリタなど、実用的な構成が保存できます。用途を絞れば十分に利用可能です。
ただし、ログの蓄積には不向きなため、対策が必要です。フラッシュROMの領域に余裕があったとしても、フラッシュROMは書き込み速度が遅いため頻繁な書き換えには向きません。ログなどの蓄積が必要な場合には、別サーバへの転送を考える必要があるでしょう。
ディスクレスシステムの活用方法
ディスクレスシステムは特殊な運用が必要と思われるかもしれませんが、実際に使用する場合にはあまり気にすることはありません。フラッシュROMを操作するための専用のコマンドが用意されているので、それを適切なタイミングで実行すればよいだけです。システム構築は、通常のDebianの流儀のとおりに操作すれば問題ありません。専用コマンドについては、代表的な使い方を紹介したいと思います。
システム構築後の保存──その1
システムを構築し、環境ができあがってきたら、それをフラッシュROMに保存する必要があります。実行は図3のとおりです。このコマンドでは、/.rw全体を図2のユーザエリア(2)に保存したあと、/.rw/etcを図2のユーザエリア(1)に保存します。ユーザエリアの全領域に保存を行う場合、およそ6分30秒程度はかかります。書き込み速度が遅いデバイスなので、気長にお待ちください。
システム構築後の保存──その2
前項の保存操作のうち、/.rw/etcを図2のユーザエリア(1)に保存する操作のみを行う場合は図4のとおりに実行します。図3が大文字の「S」、図4が小文字の「s」であることに注意してください。
前述のとおり、フラッシュROMへの保存処理は非常に時間がかかります。フラッシュROMのしくみ上、変更差分だけを保存することはできません。毎回全領域を書き換えることになると、そのたびに6分30秒程度の時間がかかってしまいますので、これを避けるために、変更個所が/etc以下のみであるとわかっている場合は、小文字の「s」を利用することで比較的短時間に保存処理を完了させることができます。
バックアップの方法
OpenBlocksシリーズは通常のサーバと異なり、OSのベース部分がフラッシュROM上のファームウェアに格納されたRAMディスクイメージで動作し、その後の変更差分が/.rw以下に集約されていくため、バックアップは非常に手軽です。ベースとなるファームウェアバージョンを記録し、その後は/.rw以下を定期的に保存しておけば、元の環境を簡単に復元できます。
実行方法は図5のとおりです。あらかじめボリュームラベルに「DEB_CONFIG」と設定し、ext4/ext3/vfatのいずれかでフォーマットしたUSBメモリなどのストレージを接続しておいてください。実行後はuserland.tgzという名前でファイルができあがります。
リストアの方法
前述のバックアップが済んでいれば、リストアは非常に手軽に実行できます。バックアップの保存先として利用したUSBメモリなどのストレージを接続し、電源をONにするだけです。起動処理の中でストレージを見つけ出し、/.rw以下に復元して起動してきます。このしくみを応用すれば、同じ設定のOpenBlocksを複数台構築することも容易です。
初期設定での起動
OpenBlocksは図2のとおり、/(ルート)領域はファームウェアに含まれるinitrdを展開して作成しています。initrdは、debootstrapコマンドで構築したDebianとしての必要最小限の環境が入っており、ユーザエリアをいくら書き換えようとも/(ルート)領域は不変のままです。つまり、通常はユーザエリアを展開することで環境を復元していますが、ユーザエリアの展開を行わなければ、いつでも初期設定で起動させることができます。
このようにユーザエリアの展開を抑制したい場合は、電源ONのタイミングで本体前面のINITスイッチを数秒間押し続けてください。また、このときにリストア機能を併用すれば、USBメモリを使って構築済みの環境を手軽に切り替えることもできます。
OpenBlocksシリーズ独自のしくみ
ここまで解説した内容は、Debianの標準機能にはなく、当社製品にDebianを搭載するにあたって独自に付け加えた機能です。変更内容は表1のとおりですが、本製品の理解を深めていただくため、おもなところを紹介します。
表1 ぷらっとホーム製品でのDebianの変更内容
| ファイル | 用途・目的 |
追加 | /etc/init.d/openblocks-setup | RAMディスクの確保やSSDのマウントなどの初期設定を実施 |
/usr/sbin/flashcfg | フラッシュROMへの保存やフラッシュROMの初期化などの動作に関わる操作を実行 |
/usr/sbin/flashcfg-debian | 上記スクリプトの中で一部の機能を担当する外部コマンド |
/etc/default/openblocks | /etc/init.d/openblocks-setupおよび/usr/sbin/flashcfgが参照する設定ファイル |
/usr/sbin/runled | 本体全面のLEDの表示制御を行うため、デーモンとして起動 |
/usr/sbin/pshd | 本体前面のINITボタンが押下されたときの制御を行うため、デーモンとして起動 |
変更 | /etc/init.d/umountfs | RMAディスクの解放やSSDのアンマウントを実施 |
削除 | /usr/share/locale以下のja以外のロケールデータ | ファームウェアの容量削減のため |
/usr/share/doc以下のドキュメント | 同上(copyrightファイルは残している) |
/etc/udev/rules.d/70-persistent-net.rules | /etc/init.d/openblocks-setupの中で起動のつど削除。設定済みのストレージを別の個体に搭載した場合に、ネットワークインターフェース名が変更されないようにするための処置 |
/.rwディレクトリ
ここまで/.rwディレクトリが何度か出てきましたが、ここはOpenBlocksを利用するうえで特徴的な部分です。/.rwはRAMディスクまたはボリュームラベルに「DEBIAN」を設定したストレージがマウントされて利用されます。/.rw以下にはusrやetcなどのディレクトリが作成されており、/usrや/etcにはunionfsを利用して/.rw/usrや/.rw/etcを上から被せた状態になっています。このしくみにより、OpenBlocks上に追加・作成したデータはすべて/.rw以下に集約されます。unionfsはLiveCD/DVDやNFSルートの環境でよく利用され、リードオンリーのベースディレクトリに、リードライト可能な別のディレクトリを被せることができます。
起動時のマウント
起動時のマウントは、/etc/init.d/openblocks-setupが実行します。大まかな流れは、
- ① /.rw用ストレージの有無のチェック
- ② ストレージまたはRAMディスク(tmpfs)のマウント
- ③ RAMディスクをマウントした場合はフラッシュROMのユーザエリアを展開
- ④ unionfsによるマウントの実行
となります。その他、適当なタイミングでユーザエリアの展開やリストア、スクリプト実行なども、このスクリプトの中で処理しています。マウント処理も含めた、電源ONからログインプロンプトまでの流れは図6のとおりです。太枠の個所がOpenBlocksのための追加部分です。
flashcfgコマンド
flashcfgコマンドは、前述のとおり、/.rw以下の変更差分をフラッシュROMに保存するために使用します。その他にもバックアップの実行やユーザエリアの初期化などの機能を持ちます。
OpenBlocksのカスタマイズ
標準でインストールされているDebianは、これまで紹介したとおりの内容となっていますが、もちろん用途や環境に合わせたカスタマイズも可能です。カスタマイズのためのポイントをいくつか紹介します(詳細は当社Webサイトで技術情報を公開しています)。
開発環境
ファームウェア開発のための環境は、OpenBlocksの実機と、必要に応じてクロスコンパイル環境としてx86アーキテクチャのDebianがあると便利です。
クロスコンパイル環境は、DebianのサブプロジェクトであるEmdebianが提供するクロスコンパイラを加えることで容易に構築できます。x86のDebian 6.0をインストールしたあと、図7の手順で必要なパッケージを導入できます。DebianのWikiサイトの情報も参考にしてください。
RAMディスクイメージの作成
ファームウェアは、Linuxカーネルとinitrd形式のRAMディスクイメージを結合して作成します。RAMディスクイメージの中身はdebootstrapコマンドを使用して構築しますが、このときはOpenBlocksの実機が必要です。debootstrapのパラメータでも導入するパッケージは調整可能ですが、細かな調整はchrootしてからの操作が必要となる場合もあります。
debootstrapの実行例は、図8のとおりです。debootstrapによるDebianの最小限の環境の構築から、RAMディスクイメージの空ファイルの作成、中身のコピーなどを実行しています。RAMディスクイメージの空ファイルの作成では、あえてext2ファイルシステムでフォーマットしています。これは、そもそも起動のつどRAMディスクを初期化するのでジャーナリングが不要であることと、メタデータ記録のためにRAMディスクイメージの領域が消費されるのを防ぐためです。
RAMディスクサイズの調整
SO-DIMMの追加を前提とした場合には、/.rwのRAMディスクのサイズを標準の384MBから増加させることで、より多数のパッケージを利用した環境が構築できます。変更を行う場合は、RAMディスクイメージ内のetc/default/openblocks(リスト1)にある「RW_TMPFS_SIZE」を希望の内容に変更します。
またこのような場合は、/.rwの保存先としてフラッシュROMの代わりにSSDを用いたり、フラッシュROM内のJavaが格納されている領域もユーザエリアとして使用する、といったカスタマイズも考えられます。
初期設定の変更
他拠点にほぼ同じ設定で設置するような場合には、初期設定値をあらかじめ変えておくのも便利です。INITスイッチを利用した初期設定での起動を行っても、あらかじめシステム構築済みの状態になっていれば、設置場所に合わせた設定変更を簡単に済ませることもできます。
まとめ
OpenBlocksでは、フラッシュROMの特徴を活かすことで、IAサーバでは難しいディスクレスシステムも手軽に構築できます。これにより、不具合発生の可能性が低い、より安全なシステムを構築できることがおわかりいただけたかと思います。またカスタマイズも可能ですので、ぜひさまざまなアイデアを盛り込んで活用していただければと思います。