Linux Gazette ２００４年１０月投稿記事
目次
MEN A201SキャリアボードとMEN M37メザニンモジュール用
フレキシブルVME-PowerPC-Linuxデバイスドライバ
投稿者、Augusto Pereira：10/01/2004 - 05:57. 記事|開発者
要約
MEN-A201Sボードは、VMEバス上のユニバーサルI/OのためのM-モジュール・キャリアボードで、データ取得やプロセス制御などのアプリケーションに高い融通性を持たせる。４個までのM-モジュールに適合させることが出来る。MEN-M37は、16ビットの解像度を有する高速４－チャンネルアナログ出力(DAC)M-モジュールである。電流出力を別個に0.20mA出力として利用することが出来る。a201sドライバが、VMEバス及びモトローラPPC CPU上のkernel 2.2xのためのロード可能フレキシブルLinux モジュールとして実現されている。この文書は、a201sデバイスドライバの機能を説明する。
作者
A. Pereira, C. Olalla, J. Sánchez, G.R. Castro.
1. 緒言
a201s.o は、MENエレクトロニクス製造のキャリアボード
A201S とM-モジュール
M37の幾つかをサポートするため書かれたLinux PPC デバイスドライバである。M37モジュールは、キャリアボードの第一スロットに於かれる。ドライバを正しく働かせるには、VME アドレスでアクセスすることが出来るようにするためuniverse.o, esrfvme.o, hook.oドライバをロードする必要がある。
a201s デバイスドライバの主な特徴は：
－一つのチャンネルの値を設定する
－システムの電源を入れるとき、出力チャンネルが既知の値を持ち、これらの値は、実行時ではなくコンパイル時にsetinit.datと言うファイルにロードされる。必然的にドライバをコンパイル仕直すにはファイルsetinit.datをロード仕直す。
－チャンネル全部（４チャンネル）の値を同時に設定する。ドライバがsethome.datと言うファイルを読取ってチャンネル番号とそれに対応する値を入力する。
2. ドライバのロード
Linux kernelモジュールは、kernel部品になるよう別個に作られているので、kernelが走っている間に動的にロード、アンロードすることが出来る。
これはオブジェクトファイルa201s.oのような見掛けになるので、コマンドinsmod a201s.oを用いてロードされる。この操作がデバイスの初期化を働かせ、デバイスドライバに主な番号を与える。これは /proc/devices ファイルの中に見出すことが出来る。
ロードの後、ドライバモジュールを、プログラムが使用するデバイスファイルと関連させなければならない。これはコマンドmknod /dev/esrf/vme/a201s_00 c を用いておこなう。
a201s デバイスドライバについては、a201s.confと言う別のファイルのボード構成を入手するスクリプト startdrv により一度におこなわれる。このファイルは a201s VME ドライバの標準マッピングを含む。詳細に言うと、ボードはFDD00000で始まるVME標準A24/D16 アドレスで働く。モジュール毎に200バイトのメモリが必要で、別の第二M-モジュールがD0200から始まり、第三のM-モジュールがD0400に、最後のM-モジュールがD060に置かれる。
3. アンロード
kernelモジュールを動的にロードすることが出来るので、望みのときコマンド rmmod a201を用いてアンロードすることが出来る。モジュールは、その前にプロセス全部がクローズされているときだけ、アンロードされる。ドライバを使うアプリケーションが衝突するときは、ドライバモジュールのアンロードは出来ない。このときの最良の対策はシステムをブート仕直すか又はプロセスを殺すかである。
4. ドライバのレイアウト
ユーザ空間からコマンドinsmodを実行してメモリにロードされるとき、次のようなドライバの機能が幾つか使用される。
init_module
a201s_init
a201s_flexload
ドライバが働き始めると、外部プロセスがドライバを使いたいとき、以下の機能を用いる。
a201s_open using fd=open(“dev/esrf/vme/a201s_00”,O_RDWR)
a201s_ioctl using result=ioctl(fd,a201s_IOC_WRCHAN,&user_data)
a201s_release using close(fd)
rmmodを用いてドライバをアンロードしたいときは、ファンクションcleanup_moduleもまた呼び出す。
5. 特殊ファイル
Kernel は、特殊ファイルを用いてシステムパラメータ全部をセーブする。これらのうち幾つかは、デバイスドライバに関する情報の入手に大変役立つ。
/proc/devices：このファイルはシステムに搭載されているドライバ全部を示す
/proc/ioports：デバイスドライバが採用する全I/O領域
/proc/modules：ロード済みの全モジュール
/proc/version：現行kernel バージョン.
/var/log/messages：printk() 呼出を用いてkernelが送る全メッセージ
/var/log/syslog：最後のものに類似
6. ドライバへのアクセス
a201sがメモリ内で働き始めると、テスタ処理を実行してドライバが正しく働いているかを点検することが出来る。
テストプログラムはドライバに関し一つのデバイス、この場合は /dev/esrf/vme/a201s_00だけをコンフィギュアする。多くのボードの使用を必要とするときは、ドライバを変更してコンパイル仕直す必要がある。テスタを働かせるとき、一つのチャンネルへの書込やsetinit 又は sethomeファイルの使用などドライバの全機能を使用することが出来る。
7. a201sのコンパイル
ソースファイルは、
job_place_driver_7.tgz ファイルにある。これはMakefileをコンパイルして、a201s.o実行可能ドライバ、test_a201s.o ファイル及びそれをコンパイルするのにデバイスサーバを用いる a201slib.oファイルを作る。編集の正しいログは次でなければならない：
d253:/job_place/prueba/segfs/bliss/source/driver/linux/a201s# make clean
if test bin/ppc && test -d bin/ppc ; then rm -f bin/ppc/* ; fi
d253:/job_place/prueba/segfs/bliss/source/driver/linux/a201s# make
gcc -Wall -O -DLINUX -I./src -I../include/esrfvme -I../include/hook -c src/a201s.c -o bin/ppc/a201s.o
gcc -Wall -O -DLINUX -I./src -I../include/esrfvme -I../include/hook -o bin/ppc/test_a201s.o src/test_a201s.c
gcc -Wall -O -DLINUX -I./src -I../include/esrfvme -I../include/hook -c src/a201slib.c -o bin/ppc/a201slib.o
d253:/job_place/prueba/segfs/bliss/source/driver/linux/a201s#
ファイル
usr-a201s.zip をダウンロードし、サブディレクトリ/usr/local/binで自己スクリプトcrate.startupを走らせてて、ドライバがロードされる様子の例を見ることが出来る。/usr/local/driver/bin に置かれているファイルtest_a201s は、以前にロードされたファイルが管理される様子の例である。
8. 参考資料
Rubiny, Alessandro. Linux Device Driver. O'Reilly. 2001.
MEN M36 Linux デバイスドライバを用いて
VMEバスに16ビット-ADCを追加
要約
M36は、M-モジュールANSIメザニン規格に基づく。VMEバスシステム又は任意の型のスタンドアローンSBCにおいてI/O拡張として用いることが出来る。3U, 6Uその他のフォーマットにおける適切なM-モジュール・キャリヤカードが、MEMその他の製造社から手に入る。M36は16ビットアナログ入力(ADC)M-モジュールである。オンボードDC/DCコンバータを用いて別個の電源電圧を発生することが出来る。M-モジュール上でのサンプリングは完全に自動化されている。測定値はデュアルポートRAMで利用することが出来る。測定すべきチャンネルのシーケンスとモードもまた、デュアルポートRAMで定義することが出来る。取得時間は10μ秒以下である。入力信号調整は、小さいアダプタ－アナログ入力１６、シングルエンド－電流測定精度：±１％－最大電流：±25mA －電流最大目盛：±20mA, UA = ±1.25Vを用いておこなう。シングルエンド取得用なので、電流測定バージョンには、最大目盛：±20mA用に62.5-シャントが搭載されている。ソフトウエアを用いて選ぶ利得係数は,8でなければならない.men36ドライバは、kernel 2.2.x用にLinuxでロードすることの出来るモジュールとして実現された。この文書では、.men36デバイスドライバの機能を説明する。
作者：
A. Pereira、C. Olalla、J. Sánchez及びG.R. Castro。A. Pereira[1], C. Olalla[2], J. Sﾃ｡nchez[1] and G.R. Castro[2].
1. 緒言
Men36.o は、MENエレクトロニクス社で作る幾つかのキャリアボード
A201S と幾つかのM-モジュール
M36をサポートするため書かれたLinux PPCデバイスドライバである。M36モジュールは、キャリヤボードの第二スロットに置かれる。第一スロットにはM37モジュールがあるからである。ドライバを正しく働かせるには、VMEアドレスでアクセスすることが出来るようにするため universe.o, esrfvme.o 及び hook.o ドライバをロードする必要がある。
men36 デバイスドライバの主な特徴は、特定のチャンネル一つの値を読取ることである。
2. ドライバのロード
Linux kernel モジュールは、kernelを働かせ乍ら動的にロード、アンロードが出来るkernelの部品として作られている。
これはオブジェクトファイルmen36.oとして現れ、コマンドismod men36.oを用いてロードされる。この操作で、デバイスの初期化がおこなわれデバイスドライバに重要な番号を与える。これは /proc/devicesファイルの中に見出すことが出来る。ロードの後、ドライバモジュールを、ユーザプログラムで使用されるデバイスファイルと関連付けなければならない。これはコマンドmknod /dev/esrf/vme/men36_00 cを用いておこなう。
men36 デバイスドライバに関しては、スクリプトstardrvにより一度におこなわれる。これがmen36.confと言う別のファイルのボード構成を入手する。これにmen36 VMEドライバの標準マッピングが含まれている。詳しく言うと、ボードは、a201sキャリアボードのためFDD0 0000で始まるVME標準A24/D16アドレスで働く。各モジュールは200バイトのメモリを必要とするので、別の第二M-モジュールはD0200から始まり、第三M-モジュールはD0400に置かれ、最後のM-モジュールはD0600に置かれる。
3. アンロード.
kernelモジュールを動的にロードすることが出来るのの同様に、好きなときにコマンドrmmod men36を用いてアンロードすることが出来る。モジュールは、その前にプロセス全部がクローズされているときだけ、アンロードすることが出来る。ドライバを使用するアプリケーションが衝突するときは、ドライバモジュールをアンロードすることは出来ない。この場合の最善の対策はシステムを再度ブートすることである。
4. ドライバのレイアウト.
ユーザ空間からコマンドinsmodを実行してメモリにロードされるとき、次のようなドライバの機能が幾つか使用される。
init_module
men36_init
men36_flexload
一旦ドライバが働くと、外部プロセスがドライバを使用したいとき、次のファンクションが使用される：
men36_open using fd=open(“dev/esrf/vme/men36_00”,O_RDWR)
men36_ioctl using result=ioctl(fd,men36_IOC_RDCHAN,&user_data)
men36_release using close(fd)
rmmodを用いてドライバをアンロードしたいときは、ファンクションcleanup_moduleもまた呼出される。
5. 特殊ファイル
Kernel は、特殊ファイルを用いてシステムパラメータ全部をセーブする。これらのうち幾つかは、デバイスドライバに関する情報の入手に大変役立つ。
/proc/devices：このファイルはシステムに搭載されているドライバ全部を示す
/proc/ioports：デバイスドライバが採用する全I/O領域
/proc/modules：ロード済みの全モジュール
/proc/version：現行kernel バージョン.
/var/log/messages：printk() 呼出を用いてkernelが送る全メッセージ
/var/log/syslog：最後のものに類似
6. ドライバへのアクセス
men36がメモリ内で働き始めると、テスタ処理を実行してドライバが正しく働いているかを点検することが出来る。テストプログラムはドライバに関しデバイス一つだけ、この場合は /dev/esrf/vme/a201s_00、をコンフィギュアする。多くのm-モジュールの使用を必要とするときは、変更してドライバをコンパイル仕直す必要がある。ドライバにアクセスする別の可能性は、デバイスサーバmen36_DACを用いることである（これはライブラリmen36lib.oを用いて、men36ドライバを扱う）。
7. men36のコンパイル
ソースファイルは、
job_place_driver_7.tgz ファイルにある。これはMakefileをコンパイルして、men36.o 実行可能ドライバ、test_men36.o ファイル及びそれをコンパイルするのにデバイスサーバを用いる men36lib.oファイルを作る。編集の正しいログは次でなければならない：
d253:/job_place/prueba/segfs/bliss/source/driver/linux/men36# make clean
if test bin/ppc && test -d bin/ppc ; then rm -f bin/ppc/* ; fi
d253:/job_place/prueba/segfs/bliss/source/driver/linux/men36# make
gcc -Wall -O -DLINUX -I./src -I../include/esrfvme -I../include/hook -c src/men36.c -o bin/ppc/men36.o
gcc -Wall -O -DLINUX -I./src -I../include/esrfvme -I../include/hook -o bin/ppc/test_men36.o src/test_men36.c
gcc -Wall -O -DLINUX -I./src -I../include/esrfvme -I../include/hook -c src/men36lib.c -o bin/ppc/men36lib.o
d253:/job_place/prueba/segfs/bliss/source/driver/linux/men36#
ファイル
usr-m36.zip をダウンロードし、/usr/local/binにあるセルフスクリプトcrate.startupを走らせ、ドライバのロードされる様子の一例を見ることが出来る。/usr/local/driver/binにあるファイルtest_a201sは、以前にロードしたドライバを管理する様子の一例である。
8. 参考資料.
Rubiny, Alessandro. Linux Device Driver. O'Reilly. 2001.
迷惑Eメールとウイルス防御システム
投稿者、spamhippo ：10/01/2004 - 17:21. 一般|システム管理者|初心者
サニーベール、カリフォルニア－2004年10月1日発。Pathlink技術会社は本日、自社の強力なSpamHippo反迷惑メール、反ウイルスEメール防護システムの新規改良版を発表した。サーバーソフトウエアと販売用外注e-メールサービスの両方で入手することの出来るSpamHippoは、有用なメッセージを余り傷付けないで迷惑メールやウイルス汚染のe-メールを捕捉し撃退する。間違い易いブラックリストや頑丈なファイアウォールではなく迷惑メール捕捉論理(STL)を使用することにより、顧客特有の要求と組織としてのe-メール対策に合わせて、SpamHippoはe-メールの絶対的及び条件付き双方のオプションを提供する。
SpamHippo サーバーソフトウエアは、UNIXとLinuxに適合しており、任意のSendmail 及びProcmailインストレーションと容易に統合される。SpamHippo Eメールサービスには、SpamHippoソフトウエアの全機能に加えて、割当可能POPアカウントとウェブEメール・インターフェイス・オプションが含まれる。SpamHippo Eメールサービスは、インターネット登録ドメインのある組織なら何処でも利用することが出来る。顧客側にはハードウエアもソフトウエアも帯域幅も技術資源も一切不要である。
新規リリースの最重要点は、個別差出人確認警告、改良受取人識別管理、外部Eメールアカウント・メッセージ処理、管理的アカウント保持者巡回システムの強化、活動報告改良と統計報告の拡充、及び送信者待ち行列予告と処理である。
「SpamHippoは、過去六ヶ月大変な商業サービスをおこなって来た。これは顧客に良く知られておりE-メールアカウント保持者にセンセーションを巻き起こした。迷惑メールとウィルスを乗り越え、処理中に有用なE-メールを無くしないことに胸を躍らせない人はいない」と、Pathlink社営業部長アレッサンドロ氏は語る。
「E-メールアカウントと関連サービスに関する我が社の売上げが過去六ヶ月で24%増加した一方で、迷惑メールとウィルス問題に関する顧客のサポート要求は殆ど無くなった。資源を回収してもっと積極的な顧客サービスに向けることは良い事だ」と、SpamHippoを利用するポーターの一つNewsGuy社の技術サポートサービス部長チャップマン氏は語る。
無制限eメールアカウント・サーバライセンスは僅か$1,495で、一年中の電話とeメール技術サポートと無制限ソフトウエア更新を含む。ソフトウエア更新と技術サポートの二年目の費用は塚の$300だけである。V 2.02 は、サーバ上に2.0以上をインストールしている人のための無料ソフトウエア更新である。SpamHippo Eメールサービス顧客は常に、無料で更新サービスを受ける。
Pathlink 技術会社について：
創業以来20年になる。企業に多数のソフトウエア・アプリケーションと外注サービスを販売しておりインターネットでは有名である
詳しい情報は
Pathlink Technology Corporation
電話： 408-720-7620
ファックス：408-720-7630
最近の技術関係大ニュースはiSCSI である。iSCSI は、SAN構築用ファイバーチャンネルの代替品である。主な利点は、何もかもが、殆どのシステム管理者が知っているIPであることである。高価なファイバーチャンネルHBAや交換機は不要なので iSCSI SANは、ホームファンがある程度容易に構築することが出来る。
我が社では最近、サーバ購入の再検討を決定した。数年間標準ラックマウントサーバを購入して来たが、何よりディスク容量のためサーバを更新しているのに気付いた－ユーザがディスクスペースを食うので、我が社の主要管理ファイルサーバを２年毎位で更新している。我が社の仕事が拡大しており、メディアサーバが普及しているので、250G ファイルサーバでは昔ほど十分なスペースが無い。
今年難問にぶつかった。サーバの幾つかでスペースが足りなくなった上、現在利用可能なCPU能力以上を必要とする多数の新規プロジェクトが生まれた。オンラインで来る新たなサービスを扱うのに、既存サーバ用にファイバーチャンネルSANでも十分な新規サーバを購入することも出来る。基本的に、既存ボックスに利用することの出来る記憶量を拡充した上で十分な新規サーバを備える方法を全部乏しい予算の中で見付ける必要があった。どうするか？
利用可能な選択肢を研究して、最も突出していたのが iSCSIであった。我が社の環境はLinux/NetWare/Windows/AIX/Solaris の混合なので、全部に有効な対策を必要とした。我が社のファイルサーバはNetWareである。NetWareの優れたファイルパーミッションは、NASり共存しないので、ローカルにサーバに附着するディスクと見られる何かが良いと思われた。勿論、我が社のLinux マシンには全て最初から記憶管理があるので、新規の管理ツールを教える気はなかった。iSCSIはこれらOS全てをサポートする。Ciscoが、Unix 変種をサポートするSourceForge 上のオープンソース iSCSI イニシエータをリリースした。NetWareとWindowsの双方には iSCSI に関するベンダーサポートがある（NetWare 6.5 を推奨）。
iSCSI については、規格品のギガビットスイッチとネットワークカードを用いてギガビット・イーサネット・ネットワークを構築することが出来た。VLANなど、通常のあらゆる仕掛けを用いると、チャンネル結合も上手く働いて、必要に応じて出来るだけ多くの分離と冗長度を構築することが出来る。我が社のiSCSI 目標のためには、FalconStorのIPStor ソフトウエアを選んだ。凄いソフトウエアパケージは最新記憶管理を備えており、ベンダーに関わりなく常に持つ羽目になるSCSIやファイバーチャンネル・ディスクアについて使用することが出来る。クライアントは、FalconStor'の所有権SAN/IPプロトコル、産業用標準iSCSIプロトコル、ファイバーチャンネル又はそれらの任意の組合せを経由して接続することが出来る。これが提供する融通性が気に入った。今年NetAppから記憶装置を買って、来年は HP 又は IBMからの記憶装置で拡張することが出来る。さらに良いのは、コピイ、モニタ、スナップショットなどの機能を、そんな機能のない廉価な記憶装置アレーを使うことの出来る IPStorを用いて果たすことが出来た。我が社の環境には、 IPStor 用に使用されるデルPE1750 サーガに内在するUltra-320 SCSIと、ファイバーチャンネルを経由してIPStor サーバに接続されるnStorからのSATAアレーとの混合物を選んだ。このシステムの全体の容量は生のディスクで6.5 TB、ドライバ幾つかをRAIDパリティ専用にした後5.25 TB である。
我が社のサーバに関してはIBMのBladeサーバに注目した。これらはiSCSI用の組合せに完璧であると思われる－各サーバにはギガバイトの埋込NICが付いているので、４までサポートすることが出来る。個々のbladeは廉価なので、他より多いサーバが得られる一方で、これから拡充する計画の新規サービス全部と、ディスクスペースが不足してしまった現存ボックスとを扱うのに十分な記憶容量が与えられる。BladeCenterは4ギガバイトまでの交換モジュールをサポートするので、我が社のデータ接続に関する冗長も可能になる。IBMは10ギガバイト交換モジュールも計画しているので、帯域幅の心配は余りない。IBMは電力使用量と熱出力が、雑音まである在来のサーバより小さいと言っている。正直なところ、iSCSIはbladeを有効に使う技術だと思う。ファイバーチャンネルをBladeCenterに追加することは、シャーシの価格を殆ど２倍にする。
我が社の中心的ディストリビューションは SuSE Enterprise サーバである。 SuSE Enterprise サーバ9は、この計画を始めた時にリリースされたので、新しいディストリビューションを使うことに重点を置いた。SLES9では iSCSIブートをサポートしていないが、initrdに簡単な変更を加えるだけで全部が上手く行くことを見出した。我が社の環境では、BladeサーバにPXEブートしそのルートボリュームをiSCSIにマウントしている。これが良いのは、我が社のSANへのLinuxインストレーションが、どのbladeにも固有でないことだ－私のDHCPサーバとPXE構成の上で簡単な変更に失敗すると、サーバ全部をバックアップも復元も無しに新しいbladeに移動する。コピイ時間も無く、最も重要なのはデータ喪失の危険が無いことだ。同じことがハードウエア更新にもある－PXEを更新し、サーバをダウンして、もう一度新しいハードウエア上で数分以内に元に戻すことが出来る。
今、無料で完全に Linux iSCSI 目標を実現することが出来る、それはUMLからだと思う。新しいLinux ディストリビューションでは当たり前のinitiator又は Cisco/SourceForge initiatorで働く。テストシステムの設定は半日で終わる－コツを覚えるのに良い。最も難しかったのは、正しくinitrdすることだった。Linuxのブート処理を纏めるに慣れていない人には、initrdに気を付ける必要がある。現存のサーバを拡張するだけなら、これは勿論不要である。iSCSI ドライバをインストールするだけで済む。
役に立つリンク：
これにご興味があれば、iSCSIコンパチ initrd を行ってPXE処理について論じる。ここに幾つかの参考資料があるが、システムを働かせるのに十分な詳細を述べたものは何もない。SUSE固有の情報は、さらに入手が難しい。
10/02/2004 - 03:07.投稿
LINUXにおけるGISは、インドなどの国での開発に役立つ。
GRASS GISなどは、RS（衛星イメージを用いるリモートセンシング）とGS（地理情報システム）の能力の殆どを有する。今やコンピュータは無理なく変えるがRS及びGIS用の市販ソフトウエアをロードするのでは懐が傷む。
GIS はRS は、各種分野に役立てることが出来る。
堅実な農業経営、農作物と収穫計画、都市計画
地質学、考古学、人類学
初心者が
1. 無料 O/s
2. GRASS GIS その他の無料GIS 及びRS ソフトウエアのロード
3. 個別指導を受けて習熟するインドの例
を見出す開発途上国からのグループ
11月にGISの日がある。以下のリンクをチェックされたい。
1990年代初期の市販PC上で走るLinuxを用いる
Beowulf clustersの開発以来、パラレル計算は必需品となった。COTS（売れ残りの安物）マシンを使って、コンピュータのクラスタを構築し各種パラレルコードを走らせるのは容易い。勿論、多数の連続ジョブを走らせるのにも支障はない。
クラスタ（即ち高性能）計算には、クラスタアーキテクチャ、ネットワーク形式、パラレルコードの性質など、多くの側面がある。しかし、クラスタの重要成分は、ジョブ管理システムである。２，３台のマシンの「クラスタ」に関しては、各マシンの状態をチェックし特定ノードでジョブを走らせるのは（面白くはないが）可能である。しかしこれは、３台のマシンのロードをチェックし、ファイルをこちらのマシンからあちらのマシンにコピイすることを意味する。加えて、一人のユーザがマシン上のリソース全部を独占することもある。
ジョブ・サブミッション・ソフトウエアの役割は、提出、スケジュール作成、ジョブ追跡の仕事を単純化して自動化することである。利用出来るジョブ管理システムは幾つかあるが、ここでは
OpenPBS に集中する。これは、無料ダウンロードでも市販製品（追加サポート付き）でも両方で手に入る。無料で手に入るだけでなく、オープンソースでもある。その結果、コードを研究して自分のサイトの要件に適合させることが出来る。またOpenPBS APIへのインターフェイス
Python も得ることが出来る。この文書では、私の４台のマシンのクラスタへの
OpenPBS のインストールとコンフィギュレーションを述べる。
背景：上述のように、４ノードクラスタの設定を述べる。全ノードは時分割に分類されロードバランスのため規定値Cクラスタを用いる。これは、全く欲張っているが、インストレーションとコンフィギュレーションが進むにつれ事情が明らかになる。スケジュール管理システムの設定方法の詳細に入る前に、定義を幾つか指定し、後に引用するパスと変数をも設定する。
定義：PBSマニュアルは多数の用語を規定する。ここで必要な用語に入るだけにする。
・サーバ： サーバは、ジョブの待ち行列が走るマシンである。ジョブが提出されるマシンである。このマシンを、クラスタの中で唯一外界に接続されるマシンにするのが、良い習慣である。人々は外界からクラスタノードにアクセスすることは出来ない。だが、この点については、後にもう一度述べる。
・MOM： MOM とは、実行プログラムについて使用される用語である。実行プログラムは、計算ノードで実際にジョブを実行するプログラムである。（用語NOMは、与えられたノード上の全ジョブの母親であるとの事実から来る）s the term used for ・ノード： ノードは、ジョブを走らせる実際の物理的マシンである。これには一つ以上のCPUがある。代わりの用語は実行ホスト（execution host）である。OSの単一コピイを走らせるコンピュータは（CPUが多数あっても）単一ノードと見なされることに注意。一方、多数のOSのコピイを走らせるマシン（IBM SPなど）は多重ノードと見なされる。
・スケジューラ： これは、サーバマシン上で走り、どのノードにジョブを与えるかを決定するジョブを扱うプログラムである。OpenPBSには、自分の目的に適合するようスクリプトすることの出来るものを始めとして幾つかのスケジューラを与える。
・仮想プロセッサ：ノードが持つと宣言されるプロセッサの数。VPの数は、ぷつり的プロセッサの数より大きくなることがある。実際のノードではなく割当てられるものが、実質的に仮想プロセッサである。したがって、VPを３個持つと宣言されるノードは、３個までのジョブを受け入れることが出来る（下記を除く）。
・独占ノード：これらノードには唯一つのジョブが割当られる。ジョブを完了するまで、新しいジョブはこれらノード上では走ることが出来ない。クラスタノードとも言う。
・時分割ノード：この用語は、ホストが、VPの数に関わりなく複数のジョブを走らせることが出来ることを示すのに用いられる。このような場合、複数ジョブは既にこのようなノードに割当済みなので、仮想プロセッサを規定することは無意味である。
・ロードバランス： これは、スケジュール作成政策で、これによりジョブを複数の時分割ホストに分散して、結局各ホスト上のロードをバランスさせる。
パスと変数：この記事の目的では、何らかの変数上で決定する（ホスト名、ホームディレクトリなど）。
・サーバを zeusと呼ぶ。
・zeusのための内部インターフェイスは192.168.1.1となり、zeus1と呼ぶ。
・のーどはzeus2, zeus3 などと呼ぶ。
・変数は /usr/local/spool/pbsに設定する。
rcp かsshか？：PBS は、クラスタ内マシン間のファイル転送にrcpと
ssh の両方を用いる。しかし、我々のクラスタの一部（サーバ／ログインノード）が、外界に接続されているので、そのマシン上でrcpを使うのはハッカーに開放するようなものだ。したがってこの文書ではrcpオプションを無視して
ssh.だけを考える。完全に隔離された（即ち外界に接続されていない）クラスタでない限り、 r* サービスを走らせる用途はない。
設定：我々のクラスタ設定は、ノード３個とサーバ１台のマシンを含む。ノードは全部P4 1.5GHzで、60GBのハードディスクと256MBのRAMがある。サーバノードは PIII 733 MHz で 256 MB RAMと120GBハードディスクがある。資源を無駄にしたくないので、サーバマシンを計算ノードにも設定して全部で４っつの計算ノードを得た。４台のマシン全部に
RedHat 8.0をインストールした。ノードマシン３台を内部ネットワークに入れて(192.168.1.*）スイッチでサーバに接続する。サーバの内部インターフェイス(192.168.1.1) は、ノードマシン用のゲートウェイとして定義する。サーバ上に
ipchains を設定して、内部マシンが外界に接続出来るようにする。
以下のipchainコマンドをサーバ上の /etc/rc.d/rc.local に置く。
/sbin/modprobe ipchains
/sbin/sbin/ipchains -F forward
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -s 192.168.1.0/24 -j MASQ
/sbin/ipchains -A forward -i eth1 -j MASQ
echo 1 > /proc/sys/net/ipv4/ip_forward
サーバの内部インターフェイス用ゲートウェイは、外部インターフェイスに対して設定される。上述の
ipchains を改良して（
iptablesにして）一定のパケットだけが外に送られるようにするのは問題はない。だがこれは別の日に述べる。
次のステップは、ハードドライブ空間の使い方を決めることだ。ドライブのパーティション分割は、読者に任せる。しかし、ホーム (
/home) 空間については二つのことを考えなければならない。簡単な方法は、ノードをまたぐサーバ上に
NFS （又は自分が選ぶネットワークファイルシステム）を経由して
/home をインストールすることで、私はこの方法を採用した。しかし、ホーム空間を取付けたくないときは、
SSH を用いる全員のために
passwordless logins を確実に作成しなければならない。これは大変な苦労で、２名以上のユーザ又は二つ以上のノードがあるときは、実現不能になるほどの余分な仕事が必要になる。
/home ディレクトリをエキスポートするため、サーバ上の
/etc/exports に
/home 192.168.1.*(rw)
を追加して（ノードの番号付けは、 192.168.1.*）
exportfs -vr
を走らせる。
ノード上には、そのノード上にエキスポートされるディレクトリを取付ける必要がある。それにはノードマシン上で
mount zeus:/home /home -t nfs
を行う。各ノード上の /etc/fstab に以下の行を追加する必要がある：
zeus:/home /home nfs defaults 0 0
最後に、クラスタ上で走るプログラムを、ノード上にコピイするか又はノードがバイナリディレクトリをサーバから利用出来るようにして、ノード全部が利用出来ることを確認する。
コードのコンパイル：
OpenPBS パケージは、をRPM又はソースtarballの形で入手することが出来る。そのtarballを使ったので、これからそれを述べる。ソースへのアクセスを得るには、登録（無料）した後、ソースと文書およびメーリングリストにアクセスすることが出来る。
注記：gcc 3.2 は、OpenPBSをコンパイルすることが出来ないと思われる。それまでは、gcc 2.95 又はgcc 2.96が必要である。システム上に両方(即ち2.9x と3.2)があるときは、 /usr/bin/gccが参照するのが、2.95 又は2.96であることを確認する。
tarballを持っていると仮定する。それを同一ディレクトリ(say /root)に抽出する。ソースtarballには、サーバ用コード、スケジューラ、MOMを、数個のクライアントプログラムとGUIが含まれる。これら全部を各マシン上でコンパイルするか又は、必要な成分をコンパイルすることが出来る。我々の設定には、サーバマシン用に全部をコンパイルしたが、ノードマシン上ではGUIを飛ばした。
サーバマシンのためコンパイルするには、次のコンフィギュア・コマンドを用いる：
./configure --set-default-server=zeus --enable-syslog --with-scp \
--set-server-home=/usr/local/spool/pbs --enable-clients
これは
・初期値サーバ名をzeus（ドメインのないサーバマシンのホスト名）に設定する。
・ログやコンフィギュレーション・ファイルなどPBSの中身は、/usr/local/spool/pbsの下にある。マシン全部に同じことをするのが良い。また、各マシンに自分自身のPBSホームディレクトリを持たせるのを忘れないこと－即ち、サーバから取付けてはいけない。
・サーバマシンが実行ノードとしても働くことに決めたので、MOMもまた同様にコンパイルする
・システムは、PBSホームディレクトリと同時にsyslog (RedHat システムでは通常 /var/log/messages)に対してもログする。
・クライアント全部（qsub,qdel,pbsnodesなど）をコンパイルする。これいはGUIプログラムをも含み、これは
Tcl/Tk のコンパイルを必要とする。
・ファイル転送にはrcpではなくsshを使用する
コンフィギュアの後、
make && make install
をする。次にソースtarballを各ノードマシンにコピイし、次のコマンドを用いてコンフィギュアを走らせる：
./configure --disable-gui --disable-server --set-default-server=zeus1 \
--enable-syslog --with-scp --set-server-home=/usr/local/spool/pbs \
--enable-mom --enable-clients
このコンフィギュア・コマンドは
・PBS サーバのコンパイルを回避する
・GUI クライアントのコンパイルを回避する
・syslog へのログを有効にしrcpでなくscpの使用を有効にする
・別のスイッチはサーバに対するのと同じ意味である
前のように、コンフィギュア・スクリプトの後に次を行う、
make && make install
これで、プログラムとディレクトリが全部サーバとノードの上に設定される。次に、サーバ、実行ノード及びスケジューラをコンフィギュアする。
$logevent 0x1ff
$clienthost zeus1
$clienthost zeus.chem.psu.edu
$max_load 2.0
$ideal_load 1.0
$usecp zeus.chem.psu.edu:/home /home
マニュアルにはこの意味を詳細に述べてあるが、ここではMOMコンフィグにある各項目を一瞥する。
・$logevent：これは、MOMが行うべきログのレベルを示す
・$clienthost：このキイワードの値は、ジョブのスケジュール作成などMOMに連絡することの出来るクラスタの中のマシンを示す。我々の場合、MOMと連絡することの出来るマシンはサーバノードだけなので、そのサーバマシンの内部及び外部インターフェイスの名称を指定する (それぞれzeus1 とzeus.chem.psu.edu)。
・$ideal_load：このキイワードの値もまたスケジュール作成において役割を果たす負荷平均が$max_loadをまたぐと、MOMは、負荷平均がこの値以下になった後にのみ新規ジョブを受け付ける
・$usecp： これは、ここで述べる設定に取り重要なキイワードである。ジョブ完了の後、MOMは出力ファイルなどをを提供したホスト（今の場合はサーバzeus）にそれを返す。-with-scpを用いてコードをコンパイルするので、scpを使おうとする。しかし、 passwordless loginを設定していないときは、scpは機能しないので、出力ファイルは戻らない。
したがって、このキイワードは、MOMがファイルを転送しようとするホストが上述のホストに整合（整合規則はマニュアルに少し詳しく述べてある）するときは、cpを用いることを、MOMに命じる。我々のホームディレクトリはNFS経由で取付けられているので、これで構わない。規定のパスは、実行ノード上で /home の下にあるファイルはすべて、リモートホスト（即ち、この場合はzeus.chem.psu.edu）上の /home の下にコピイされる。
サーバのためFQDN を規定することが重要である。これは、サーバがgethostbyname() Cライブラリ呼出を用いてそのホスト名を入手し、それをMOMとの連絡に用いるからである。ホストとしてzeusだけを示すと、これはサーバの与えるホスト名と絶対に一致しないので、cpでなくscpを用いて頭を掻くことになる。また、ローカルマシン（即ち自分自身）にコピイしていることをMOMが検出すると、規定値としてcpを用いることにも注意。したがって、MOMをサーバマシン上ではしらせるときは、この行を省略することが出来る。
上で与える$max_load と $ideal_load の値は、我々のクラスタに特有のものである。値に細工をしたいことがある。コンフィギュレーション・ファイルを書いた後、
/usr/local/sbin/pbs_mom
を用いてMOMをスタートさせることが出来る。MOMはルートとしてスタートしなければならない。これはデーモンとなって、ルート優先権を無くする。フート仕直しの際にMOMが自動的に再スタートすることを確実にするには、それを必ず /etc/rc.d/rc.localから実行すること。
スケジューラの設定：スケジュール作成はジョブ管理システムの重要部分である。スケジュール作成方針の実行により、サーバーが短時間で終わるジョブを長時間かかるジョブの前に処理することが出来るようになる。また一日の一定時間に一定のジョブをするよう指定することが出来る。一般的に、サイト用のスケジューラは、どのジョブを何時何処で走らせるかを決定する。
OpenPBS には多数の各種スケジューラとスケジュール作成計画－規定値Ｃスケジューラ（Tclを用いて立案することが出来る）Tclベースのスケジューラ及びＣ類似の言語でプログラムすることの出来るBASLスケジューラ－が付いて来る。
Python ベースのスケジューラ (PBSには
Python interfaceが入用)及び
CLANを入手することも出来る。
OpenPBSサイトでは多数の既製スケジューラが手に入る。OpenPBSと一緒に来るスケジュール作成ツールを使って、自分のスケジュール作成方針を実施することも出来る。私は自分のスケジュール作成方針を実行するのに、ＣスケジューラとFIFO（先入れ先出し）政策を使った。
規定値スケジューラの特性には下記が含まれる
・与えられた待ち行列の中のジョブはすべて、別の待ち行列を検査するまでは、実行用と見なされる
・待ち行列は待ち行列優先度による順序で、待ち行列の中のジョブは要求cpu時間の順に並ぶ
・プライムタイムは午前 4:00から午後 5:30である
ＣスケジュールはFIFOで定義されることことに注意するのが重要である。この条件は待ち行列とサーバに当て嵌まる－サーバも待ち行列も本来FIFOなのだ。だが、どのジョブを何時走らせるかは、自分のスケジュール作成方針を実行して完全に決め直すことが出来る。
Ｃスケジューラを設定するにはファイル$PBS_HOME/sched_priv/sched_configを編集した。ロードバランシングが出来るようにするため次の行を追加した：
load_balancing: true ALL
このオプションにより、サーバから得られる時分割ホストのリストの間でロードバランスをすることが出来る。もっと多くのオプションを設定することが出来て、それらがジョブを何時どのように走らせるか、どの時間帯をプライムタイムにするか、優先度の高い待ち行列があるか、などを制御する。しかし、我々の目的には、ジョブがノードの中に分散されるだけでよい－負荷平均の低いノードが、負荷平均の高いシステムより前にジョブを受け取る。
スケジューラを構成した後、次を用いて（デーモンになる）スケジューラを起動した
/usr/local/sbin/pbs_sched
待ち行列サーバの設定：設定の最終段階は、サーバをスタートしてジョブを受け取る待ち行列を作ることだ。サーバは、利用出来る待ち行列の型及びジョブが要求するリソースの型にしたがって、ジョブを待ち行列に渡す。大型クラスタに関しては、一つ以上の待ち行列を設定することが出来る。短時間ジョブ用と長時間を要するジョブ用などである。各待ち行列には優先度を割り当てることが出来る。スケジューラは、どの待ち行列からのジョブを走らせるか決めるときにこれを検査する。さらに、フィーダ（又はルート決定）待ち行列をも設定することが出来る。そのジョブを実行待ち行列に送って、そこから実際のジョブを走らせる。待ち行列設定に関する詳細はマニュアルにある。
サーバ：最初にしなないのは、次でサーバを走らせることだ
/usr/local/sbin/pbs_server -t create
-tオプションは、サーバを初めて走らせる時だけ示す。この時点でサーバはアイドル状態、つまり、スケジューラに連絡もしないし、ジョブも走らせない状態にある。次のステップは、サーバと待ち行列の構成である。次を用いてinto active modeに設定する。
qmgr -c "set server scheduling=true"
サーバを構成するにはqmgrプログラムを用いる。このqmgrをコマンド行に入れると、qmgrプロンプトが出るので、そこからコマンドを入れる。次をおこなって、最初に待ち行列を作り続いてそれを規定値待ち行列にする
create queue qsar queue_type=execution
set server default_queue=qsar
これによりqsarと言う単一の実行待ち行列（即ち、そこからジョブが走る待ち行列）が出来る。規定値待ち行列をqsarに設定することにより、ジョブサブミッションスクリプトの中で待ち行列仕様を省略することが出来る。勿論、一つ以上の待ち行列を作ると、ジョブを渡すとき待ち行列を指定しなければならない。
これは、サーバと待ち行列を効率良く構成する。しかし、ユーザをクラスタ上に解き放つ前にもう少し設定するのが良い。私は次のコンフィギュレーションをサーバに用いる：
set server default_node=zeus2
set server acl_hosts=zeus.chem.psu.edu,ra.chem.psu.edu
set server acl_host_enable=true
set server managers=rajarshi@zeus.chem.psu.edu
set server query_other_jobs=true
各コマンドを一つ宛て見てみよう。
・set server default_node=zeus2 このコマンドは、ジョブサブミッションスクリプトでノードが指定されていないときは、 zeus2に送ることを規定する。私は、システムが負荷平衡するよう設定しているので、これはいつも当て嵌まるとは限らない。 zeus2の負荷は大きいことが多いからだ。
・set server acl_hosts=zeus.chem.psu.edu,ra.chem.psu.edu これはホスト名に基づくアクセス制御を設定する。指名されるホストだけがジョブの提出を許される。
・set server managers=rajarshi@zeus.chem.psu.edu これにより、ユーザはサーバと待ち行列設定を変更することが出来る。変更のためルートに行かなくて済むので、便利だ。
・set server query_other_jobs=true ユーザが一連のジョブを提出するとき、通常はqstatコマンドを使って自分のジョブの情況が分かるだけである。このオプションをtruueに設定すると、システム上で走るジョブ全ての情況を示すことが出来る。
待ち行列：次は待ち行列の構成である。重要なのは、規定値、最大及び最小リソースの設定である。ここでリソースとは、CPU時間とメモリを指す。我々のクラスタの場合、次を用いてCPU時間だけを設定した。：
set queue qsar resources_min.cput=1, resources_max.cput=240:00:00
set queue qsar resources_default.cput=120:00:00
set queue qsar enabled=true, started=true
初めの二つのコマンドは、ジョブに関する最大、最小及び規定値CPU時間を設定する。これらを、それぞれ１分、１０日及び５日に設定した。メモリを設定するには cput を cput 置き換えるだけで良い。全ての待ち行列コマンド(set queue)で待ち行列名を指定しなければならない。リソース(cput 又は mem) が設定されていないと、これは無限を意味する。最終行は待ち行列がジョブを受け入れることが出来、これらのジョブをスケジューラが処理して開始することが出来ることを命じる。
resources_min とresources_maxの値を与えて、ジョブ逃散を防止するのを推奨する。
set server resources_defaults.cput=1:00:00
set server resources_defaults.mem=4mb
によりサーバに resources_defaults 値を与えることも出来る。これらは、このサーバ上のあらゆる待ち行列でジョブが要求すること出来るリソースを制限する。これらは次の場合だけチェックされる。
１．ジョブがリソース限界を規定していないとき
２．待ち行列に規定のリソース限界がないとき
サーバ上でリソース (cput 又は mem)の最大限を設定することもまた可能である。この限界は、待ち行列上に対応する限界が設定されていないときだけチェックされる。
ノードの追加：最後のステップは、存在する実行ノードとその特性をサーバに知らせることである。ノードは次を用いて作る。
create node NODENAME ATTRIBUTE=value
ここで、nodenameは実行ノードのホスト名（FQDNと反対）を指す。設定することの出来るattributeが四つある：
・state これは、free, down 又は offlineのいずれかにすることが出来る
・properties これは、文字列又はコンマで離れた文字列で、ジョブに多数のノードが必要なときノードのグループ分けに用いることが出来る。
・type これは、クラスタ又は時分割に設定することが出来る。我々の場合は、実行ノード間の負荷平衡だけを望んでおり、一つ以上のジョブが一つのノード上で走ることがあるので、各ノードをtimeであるように設定した。.
・np これは、仮想プロセッサの数（任意の正の整数）に対する設定である。我々の場合は、この属性を設定する必要はない。
そこで
create node zeus2 ntype=time-shared,properties="fast,big"
をおこなって我々のクラスタ上にノードを作る。
set node attributes[+|-]=values
delete node NODENAME
を用いてノード設定の修正又はノード削除をおこなうことも出来る。
この時点で、待ち行列ろサーバが構成されるので、ジョブを取り上げてノードに配分することが出来る。大型のインストレーションでは、異なるリソース限界を持つ多数の待ち行列（長いジョブに一つ、短いジョブに一つなど）を設定することが出来る。待ち行列優先度を指定して、一つの待ち行列が別の待ち行列からのジョブより優先されるようにすることが出来る。詳細はマニュアルを参照されたい。
OpenPBSの使用：これでジョブ管理システムを立ち上がって走るので、ジョブを提出する。プログラム qsub を用いてジョブを提出することが出来る。コマンド行上で qsub に各種のオプションを規定することが出来るけれども、次を用いてジョブスクリプトを作って走らせのが楽である：
qsub JOBSCRIPT
ジョブスクリプトは
hereから入手することが出来る。.
ジョブを走らせたら、qstatを走らせてジョブの情況を見ることが出来る。走っているジョブを止めるにはqdelを用いる
追加読み物： OpenPBS に関する詳細全てを入手する最良の場所は、そのウエブサイト
OpenPBSである。
その他の役立つリンクは
最初の記事（
ISCSI記憶装置－万人のためのSAN）で、SANのためiSCSI を選ぶ理由を説明しiSCSI の技術的側面に簡単に触れた。今回は技術、限界、働き方など、iSCSI の技術的側面を述べる。
先ず用語から出発する
Initiator - iSCSIクライアント- 各クライアントマシンは通常一つのInitiator/を有する。
Target - iSCSI ホスト - 各Initiator は通常自分のTarget を有しTarget は通常Initiatorに接続するだけである。
Portal - iSCSI Targetをホストする実際のサーバ。portal は多数のTargetをホストすることが出来る。
Hardware Initiator - システムに付加されるカードで、SCSIコマンドをTCPパケットにラップする処理全てをおこなう。
Software Initiator - システムCPUを用いて上の課題を扱うソフトウエアプログラム。
iSCSI は TCP/IPを用いるので、システムの接続にどんなネットワーク輸送でも使用することが出来る。ホームDSL接続であっても－高性能は期待出来ないが－iSCSIを扱う能力がある。直接附着記憶装置又はファイバーチャンネルで同様の性能を得ようとすると、「実際の」サーバにはギガビット・イーサネットが必要なのが私の意見だ。現在ファイバーチャンネルは２Gbpsを超えるので、結合ギガビットリンクの対を用いて同等の性能を果たすことが出来る。10ギガビット・イーサネットの価格が下がり始めているので、近いうちにファイバーチャンネルをその予算内で走らせるのは間違いない。
前の記事で言ったように、ファイバーチャンネルSANを超えるiSCSIの最大の利点は、価格である。ギガビット交換機は最早余り高価でないので、殆どのネットワーク管理者が構成と設定に慣れている。ファイバーチャンネル交換機の価格を最高級Ciscoギガビット交換機と比べると、iSCSI費用の利点が極めて明らかである。私の環境ではCiscoとIBM ギガビット交換機を使って良い結果を得ている。私の記憶ネットワークにはVLANを使っていないけれども、これは確かに選択肢の一つで極めて良いセキュリティと操作性を得ることが出来る。
iSCSI SANを計画するとき、考えることが幾つかある。software initiatorがその仕事にシステムのCPUパワーを幾らか必要とするので、I/O要件が高くて負荷の大きいサーバは、余り良くない。TCPパケットの処理にもCPUパワーを取るが、殆どのサーバグレードNICはそれを外してネットワークカード自体の上のプロセッサに対し負荷する。一般的に、早いCPUがありサーバー型NICのある新しいシステムは、iSCSIに良い性能を示す－殆どのベンダーは1.0Ghz 以上のCPUを推奨する。沢山のI/Oがあって遅いシステムは、ハードウエアinitiator - Adaptecの方が適している。LSIロジックその他がこれらを作り、iSCSIネゴシエーションは全部システム立ち上げ前にハードウエアが扱うので、設定が楽である。ファイルサーバは、iSCSI ソフトウエア initiatorsの大きい候補である。一般的にこれらのCPUは余り沢山のことをしないので、負荷が増えるのは問題にならない。
目標達成の面では幾つか異なる進め方がある。特にNetAppは、数年間iSCSIをサポートして来ているので、それら製品の殆どはiSCSIである。私はNetAppの製品を使っていないが、彼等はLinux iSCSIの開発に極めて積極的なので、良いサポートが期待出来る。その記憶システムは他のベンダーにはない独特の設計で、その製品は良く考えられているると思われる。自分の環境に一体型対策が重要であるときは、NetAppが多分最良の進め方であろう。この点でiSCSIハードウエアをつくる別のベンダーは知らないが、ソフトウエアオプションは極めて少数利用することが出来る。
ソフトウエアiSCSI targetには、通常記憶装置に寛容との利点がある。これは私に取って大きいセールスポイントである－NetAppは素晴らしいハードウエア解決策を与えるが、将来が分からないし、記憶装置を別のベンダーから買いたいとの選択肢も残したい。商業的な面ではFalconStorが多分最も有名な記憶装置ベンダーで、優秀なiSCSIサポートを有する。NovellがNetWare 6.5 に iSCSI targetサポートを追加したので、NetWareサーバに接続することの出来る記憶装置ならどれでも共有することが出来る。FalconStorのIPStor製品は、複製、ミラー、スナップショット（手動と自動両方）などの他に、頻繁に使われるブロックを認識してそれらをRAM又は固定ディスクなどの高速I/Oデバイスにキャッシュすることの出来るHotZoneなど独特の特性を含む素晴らしい特性一式を備えている。IPStorの別の面白い特徴は仮想テープである。IPStorソフトウエアが既存バックアップソフトウエアに対してテープライブラリのようになり、自分のバックアップソフトウエアなしでディスクベースをバックアップをすることが出来る。ディスク容量がいっぱいになったとき実際のテープがおこなう負荷を軽くすると思う。
オープンソースの面では、幾つかのオプションがある。iSCSI targetサポートは、未だ若いが、急速に変わっている。沢山の人が使い始めるにつれ、段々良くなっている。Ardis TechnologiesがiSCSI targetを始めたが、プロジェクトは死んでしまった－2004年2月以降の更新はない。SourceForgeプロジェクト がArdis コードに基づいて
ここ で始まった－多分注目すべきプロジェクトであろう。私はEVMSの仲間がiSCSI targetモジュールをEVMSに含むと信じている。上述の製品の機能性多数をGPLのシステムに与えるだろうからだ。EVMS (Enterprise Volume Management System)を知らない人は
ここ のSourceForgeをチェックされたい。EVMSは、GUIをフロントにするLVMを与え、普通のLinuxファイルシステム全部のためのインターフェイスも有する。
ここ にも別のオープンソースiSCSI target プロジェクトがある。
そこでInitiatorがiSCSIボリュームを取付たいとき何が起こるかだ。普通のサンプルから始めよう。システムを立ち上げ、走らせそして追加記憶装置を取り付けて見る。
Initiatorは発見処理を開始する。これはbroadcastを用いるか又はInitiator上にDiscovery Addressを定義しておこなう。Initatorは、Initatorが接続することの出来るtarget（構成されているとき）を戻すpotalを「発見」する。各initiatorには独特のInitiator名がある。これは初期構成の間にInitatorシステム上に設定される。殆どのiSCSIドライバは、自動的にInitiator名を作ることが出来るが、そうでなければ人手で設定する。InitiatorはそれらがローカルSCSIディスクであるかのようにボリュームを追加する。これらにはSCSIアドレスが割当てられ、クライアントシステムに対しては別のSCSIバスのように現れる。覚えておくべきことは、Linuxデバイス命名システムが、問題を起こすことがあることである。ボリュームが同じ順序で発見されないときは、同一ドライバ名を持つとは限らないことがある（つまり、ある日 /dev/sda であったものが別の日に /dev/sdcになる）。だがLVM やEVMSなどのボリューム管理システムがこれらを十分に扱うので、これらのうち一つを使うことを強く推奨する。もしこれらが無いときは、最小限のボリュームを、正確なデバイスとパーティションを指定する代わりにラベルを用いて取付けなければならない。
LVM とEVMSを、クライアントシステム上の別のSCSIディスクであるかのように話したのに気付かれただろう。その通りなのだ。iSCSI はディスクをkernelに正常のSCSIのように表示するので、全ての仕掛け（ソフトウエアRAID、LVMなど）が通用する。前に述べなかった一つのことは、Initiatorが多数のtargetに接続することが出来ると言うことだ。これは、二つ以上のtargetに接続するinitiatorを持って、これらtargetから利用出来るようにしたボリュームの他にRAIDで梅雨を作って冗長度を持たせることが出来ることを意味する。Linux 上のiSCSI Initiatorは、自分自身の不具合をも扱うことが出来る。複数portalが同一デバイスへのアクセスも与えるので、エンタープライズレベルでの冗長度は、完全にオプションになる。
パート III は、オープンソースtarget とinitiatorを構成するステップと、ボリュームをシステムに取付けるステップの進め方になる。
Windows XP/2000 と Red Hat Fedora Core 2bのデュアルブート
インターネットをサーフしていて、Red Hat Fedora Core 2とWindows XP/2000デュアルブートに関する要望を見ることがある。以下にその方法を述べる：
1. 先ず Windows をインストールする
2. FC 2をインストールして /dev/hda7 (一例)にブートローダを置く
3. LBA32 を実行(ブートローダ・パーティションが 32 GB 以上であるときだけ、ハードドライブの最初から）
4. FC 2インストールを完了.
5. FC2 ディストリビューションセットからの第一CDから再度ロードする
6. "linux" プロンプトで
linux rescue
とタイプする。
7. ルートプロンプトが示されたとき、以下を打ち込む：
# chroot /mnt/sysimage
# cd /tmp
# df ?k (正しい環境にいることを確かめるためだけ）
# dd if=/dev/hda7 of=linux.bin bs=512 count=1
MS-DOS フォーマット済みのフロッピイをドライブに入れる
# mcopy linux.bin a:
# ^D
8. Windowsにブート.
9. コマンドプロンプトを示して、次を入力：
copy a:\linux.bin c:
10. boot.iniに次の行を追加：
C:\linix.bin=" Red Hat Fedora Core 2"
11. マシンを再ブートして、boot.iniメニューから "Red Hat Fedora Core 2" を選ぶ。これで、"NTLDR" がFC2ブートパーティションから最初の512 kbをロードする。
12. Grub メニューから所望のkernelを選び "Enter" を押す
投稿者、
akkumar ：10/13/2004 - 21:21. 記事| 開発者| 一般| ハウツー
CVSへの手軽な入門の積もりでこの記事を書いている。
先ず、CVSとは何か？
簡単に言うと、CVSはソース制御システムだ。
必要な理由は？
ソース制御に対しては自分のプロジェクトが良いソフトウエア工学設計の重点の一つである。
働き方は？
CVSサーバは一緒にスタートする必要がある。ソースコードで行うインクレメンタルな変更はすべてサーバ（CVSレポジトリと言う）に記憶されるので、後の時点で以前のバージョンに戻るのが楽になる。
CVSレポジトリは、「モジューる」の集合である。作業中のプロジェクトと「モジュール」との間のアナロジーをCVSサーバレポジトリに描くことが出来る。レポジトリにあるモジュールは、互いに無関係の別々の実体である。
この記事では、CVSシステム（サーバとクライアント）と、それの使用を開始するたもの基本的CVSコマンドを幾つか作る。CVSサーバのスタートのため、為す必要のある事項を示す。
CVS サーバ：
プロジェクト開始の前に、CVS管理者（この場合は我々）が、人々の作業するモジュールの名称を決定する。
レポジトリの作成：
第一段階はレポジトリの作成である。CVSレポジトリ作成には比較的自由空間の多いパーティションを選ぶ。経験則として、レポジトリは全体プロジェクトの2-3倍にも成長することがある。
そこで、レポジトリを持つ場所を－
/common/projects/.reposなどと定める。
CVSサーバに、このディレクトリがレポジトリであると知らせるには、これを初期化する必要がある。これは次のように 'cvs init' コマンドを用いておこなう。
/common/projects/.repos $ cvs -d /common/projects/.repos init
これで、何か簿記情報を含むディレクトリがCVSROOTの名で作られる。
/common/projects/.repos $ ls
CVSROOT
次のステップはモジュールの作成である
モジュールの作成：
モジュールはCVSレポジトリの中のディレクトリとしてあらわされる。そこで、新しいモジュール 'mod1' を作るとすると、次を行う必要がある。
/common/projects/.repos $ mkdir mod1
代わりに、クライアント側で 'cvs import' コマンドを用いてモジュールを作ることも出来る。
/common/projects/.repos $ ls
CVSROOT mod1
CVS クライアント：
サーバ側で必要な初期化を終えてから、作業を始めるには、次のステップをクライアント側で実行する。
モジュールのチェック：
クライアント側で、プロジェクト上の作業を始める前に、サーバから「モジュール」をチェエックする必要がある。ディレクトリ上で、作業をする場所、/my/home/workとする、を決めた後、次のように進める：
/my/home/work $ ls
/my/home/work $ cvs -d /common/projects/.repos co mod1
/my/home/work $ ls
mod1
全部が上手く働いたら、このプロセスがモジュールと同一名のディレクトリを作る。
ファイルの追加：
からのモジュールをチェックした後、作業を開始するには、それにファイルを追加する必要がある。
/my/home/work $ cd mod1
/my/home/work/mod1 $ touch myfile
これは、'myfile' と言う名の新しいファイルを作るため行う。代わりに、好みのテキストエディタを開いて、テキストファイルを作ることも出来る。
/my/home/work/mod1 $ cvs add myfile
これは、ファイル 'myfile' をCVSレポジトリに追加させる。
重要：ファイルは未だCVSレポジトリに追加されていない。変更するには、クライアントによる「委託」をCVSサーバに送る必要がある。すぐ後に分かる。
ファイルの削除：
追加してはいけないファイルを間違ってCVSレポジトリに追加したとする。どうするか？ 慌てないで次のようにCVSレポジトリから削除する。
/my/home/work/mod1 $ rm myfile
これはクライアント側からファイルを削除するたみ行う。
/my/home/work/mod1 $ cvs remove myfile
これは、'myfile' をCVSサーバレポジトリから削除させる。
重要：ファイルは未だ削除されていない。変更をするには、: クライアントによる「委託｝をCVSサーバに送る必要がある。
変更の委託：
ファイルに追加及び削除のマークした後、これらの変更はCVSサーバが委託する必要がある。これを行うには、コマンド 'cvs commit'.を用いることが出来る。
/my/home/work/mod1 $ cvs commit
委託は、変更を委託する間に入力しなければならない。そこで、上のコマンドが自分の好みのテキストエディタを開くので、このチェックイについて行った変更についてのコメントを入力する。い
注記：後でコードを見るため戻ったとき、自分の貴重な時間を節約するため意味のあるコメントを書くのが良い。「重要な変更」｛大きい修正」などのコメントを入力するのは、全くプロと言えない。
コードとレポジトリの同期：
一般的なプロジェクトにおいては、一人以上の人間が働いており、地理的にも相当離れていることがある。自分が寝る前にコードをチェックインし、（地方時の異なる）仲間が後でコードにチェックインしたと、すると、自分のクライアントコードは、どのようにして更新ソースコードを入手するだろうか？言い換えると、自分の作業中コードが、CVSサーバ上で利用することの出来る最新コードと同期を取るにはどうすればようだろうか？
この質問に対する答えは 'cvs update'にある。
CVS updateコマンドを出すと、君のマシン上のクライアントコードを実際に、サーガレポジ取りにあるものと同期する。
処理中に、データはサーバから君のマシンに転送されるが、ソースファイルの変更は、君のマシンからサーバには転送されない。そのためには、 'cvs commit'.を使用しなければならない。
/my/home/work/mod1 $ cvs update
更新：
ここで分かったことは、CVSに対するきわめて基礎的な入門である。CVSは、全く強力なツールで、それに関する本が幾冊かある。もちろん、マニュアルは詳細の知るのに最良の場所だ。
しかし、これらコマンド行オプションを全部覚えていると言えるだろうか？
これは大変良さそうだが、どこで手に入れるのか？
CVSを理解するには、プロジェクトの大小に関わりなく、ソース管理を良く理解しその必要性を認識しなければならない。結局、自分のソースファイルが間違いのため削除されたら、取り残されたくないだろう。それならばファイルのソース管理を始めるべきだ。
コレクションに基づくシステムオブジェクトの理解
Mono は、マイクロソフトに対するオープン代替案を実行する目的の新規開発用プラットホームである。高品質アプリケーションを作るため、新鮮で強力な方法を求める開発者に対し卓越した代案を提供する目的で、互換性と独自性の双方を備えるネットプロジェクトである。
ネットフレームワーク、従ってMonoプロジェクト、に対する最新の追加の一部として、 Genericsと言う新機能が含まれる。Generics は、これを用いるとパラメータ化の型－つまりタイプ定義のクラス／構造体－を定義することの出来るメカニズムである。この機能を用いて、ボックス、アンボックス、及びコンパイル時のタイプチェックを省いてコレクションとデータ構造体のスピードアップを計ることが出来る。
このパート１では、コレクションに基づくシステムオブジェクトについて一般的なことを説明する（System.Collectionsの中のコレクションは、この種のコレクションの完全な実例である）。小さい例
実習で学ぶ程良いものはない。したがって、この新機能との触れ合いは小さい例を書くことから始める。
まず、現在のシステムを用いてスタックを定義する。これはSystem.Object をコレクションの定義の基本型として用いる（System.Collectionsの一部であるクラスは全部こうして実行される）。このとき、次のスタック実行を想像する。
using System;
public class Stack {
int capacity;
object [] contents;
public Stack (int capacity)
{
contents = new object [capacity];
}
public void Push (object o)
{
contents [capacity] = o;
capacity++;
}
public object Pop ()
{
capacity--;
return contents [capacity];
}
}
殆どの開発者が知っているように、Stack とはLINO（後入れ先出し）型の構造体で、最後に追加されたオブジェクトが最初に追い出される。追加の目的でPush ()メソッドを用いる一方、追い出しには Pop () を選ぶ。Push () メソッドでは、キャパシティカウンタを一つ増やして新しいオブジェクトをオブジェクトのアレーに割り当てる。Pop () メソッドは逆を行い、キャパシティカウンタを一つ減らして、最後のオブジェクトを戻す。
オブジェクトのアレーに関するオーバーフローチェックcontents[] は、この例を単純にするため明確に無視した。さらに、System.Collections.Stack クラスは使用していない。この教材ではトイ Stack の実行が役立つからである。
セーブし、Mono C# コンパイラmcsを用い、ライブラリを作る必要があるので、-t:library オプションを渡してコンパイルする。ここでコンパイルすると .dll ファイルが出来る。そこで今実行したStack クラスを用いる。以下のコードをタイプするかコピイする：
using System;
public class Tester {
static void Main ()
{
Stack stack = new Stack (16);
for (int i = 0; i < 10; i++)
stack.Push (i);
//
// Finally add a string
//
stack.Push ("Hello Mono!");
//
// And get the contents!
//
for (int i = 0; i < 11; i++)
Console.WriteLine (stack.Pop ());
}
}
ここでもまた、Mono C# コンパイラを用いてコンパイルする。今回は -r:MyLib.dll オプションを渡す。ここでMyLib.dll は、前に作ったライブラリをあらわす。これが我々のスタック実現を含む。次いで、Mono JIT又は、プラットホームにJITがないときはMonoインタプリータを用い、最初の場合は monoを、二番目の場合は mint を使用して実行する。以下が表示される筈：
Hello Mono!
9
8
7
6
5
4
3
2
1
0
舞台裏
要素はスタックの中に逆順でポップされた（LIFO型）。このサンプルに基づいて、次の事項を述べるのが重要である。
・変数型 object はSystem.Objectの別名である。
・System.Object は、Net/Mono標準により定義されるタイプ階層の第一タイプである。
・スタックはSystem.Objectのアレーを用いて内容を記憶するので、任意のタイプを記憶することが出来る。
また、前述の密接な関係がある。
・値によるタイプと参照によるタイプがある。値によるタイプは宣言されるコードのブロックの中にあり、参照のものは何回も存在することが出来る。
・値タイプをシステムオブジェクト変数に転換するとき、boxingと言うプロセスが起こり、逆にシステムオブジェクト変数が元のタイプに戻るとき unboxingと言う処理が起こる。
・スタックはシステムのアレーを用いてその内容を記憶するので、記憶されるいずれのタイプもboxしなければならない。
実際には、もっと意味がある。第一に、値タイプー単純変数すべて： int, long, float, char, enum ..－は、boxされる。その値を含む変数は Heapに記憶される。このときの Heapは、タイプを参照で割り当てるメモリ部分で、コード範囲のブロックに従属しないメモリ領域である。このことにより、それらが作られたメソッドの実行が終わったときでも参照オブジェクトは生き残ることが出来る。しかし、heap内で割り当てられるオブジェクトは、スタック内で割り当てられるもの－スタック内ではあらゆるタイプが割り当てられる－より高価で、メソッドが終了すると消え去る。
スタックを値タイプ変数の記憶に使うか参照変数の記憶に使うかは重要ではない。確かに、この機構を用いて－例で起こったように－異なる型の変数を持つことが出来る。だが、doubleなどだけを記憶するスタックを持ちたいときはどうだろう。boxing と unboxingが必要だろうか？
最悪、スタックを使ってその中に記憶されるデータを用いようとすると、ランタイムに実行しチェックされて、不具合の可能性のあるcastをしなければならない。例えば、スタックにintだけを割り当てて、そのうち二つを加算のため入手すると考えると、次のようなコードが考えられる：
stack.Push (8);
stack.Push (7);
...
int add = stack.Pop () + stack.Pop ();
悪い話がある：これは出来ない。これらを望みのタイプ（この例ではint）にcastしなければならない。その結果は次のようになる：
stack.Push (8);
stack.Push (7);
...
int add = (int) stack.Pop () + (int) stack.Pop ();
この方が良いと思われるだろうか？
まとめ
コレクションに基づくSystem.Object 値は、この例では簡単になり得るけれども、場合に依っては、castが必要になり不具合になる場所が現れる。また、値タイプ (int, long, double, float, char, enum, ...)で用いるときの労力が大きくなる。
参考資料
