Tetsu's TexT 3/4

目次　　（現在地は"サーバーシステムについて"です）

序文　（システム図形モデル有り）
クライアントシステムについて
 サーバーシステムについて
 TOP

内容

・サーバーシステム
　クライアントシステムの項では共通仕様があったが、サーバーに関してはおよそバラバラである。ので、共通仕様は述べない。

　1-個別仕様
　・Aチーム対応サーバー
　　Apple PowerMacintosh 7100/80AV
　　CPU：PowerPC601/60Mhz
　　メモリ：48MB
　　HDD容量：320MB
　　Built-in EitherNet
　　OS：MacOS 7.6.1
　　サーバーソフトウェア：MacHTTP2.2
　・Bチーム対応サーバー
　　Apple PowerBook3400/240
　　CPU：PowerPC603ev/240Mhz
　　メモリ：150MB
　　HDD容量：2.7GB
　　Built-in EitherNet
　　OS：MacOS 8.1
　　サーバーソフトウェア：MacHTTP2.2
　・Cチーム対応サーバー
　　Apple PowerBook1400C/166
　　CPU：PowerPC603ev/166Mhz
　　メモリ：48MB
　　HDD容量：1.3MB
　　ASANTE FriendlyNetPCcard
　　OS：MacOS 8.1
　　サーバーソフトウェア：MacHTTP2.2
　・Dチーム対応サーバー
　　Apple PowerMacintosh 7200/120
　　CPU：PowerPC601/120Mhz
　　メモリ：48MB
　　HDD容量：1.2GB
　　仮想メモリ：ON-理論値48MB
　　Built-in EitherNet
　　OS：MacOS 7.6.1
　　サーバーソフトウェア：MacHTTP2.2
　・コントロールサーバー
　　Apple PowerMacintosh G3/MT300
　　CPU：PowerPC750/300Mhz
　　メモリ：320MB
　　HDD容量：8GB
　　Built-in EitherNet
　　OS：MacOS 8.1
　　サーバーソフトウェア：WebSTAR2.0J

　2-実験時の動作状況、そして問題と対策
　実験開始と同時にCチーム用に用意していたパワーブック転用のサーバーがダウン。原因は追及できていないが、そもそもSCSIポートの不安定性のためにバックアップ＆初期化ができていなかったこと、並びに機材を手渡されてからの時間が根本的に不足していたこの機材を、既存のままセットアップしたことから起こるシステムの不安定が原因と考えられる。パワーブックとASANTEのPCカードの動作状況についてはすでに洋洋館デジタルスクエアならびに[connoisseur]のテストサーバーでの例などで明らかに動作が確認されているだけに、借り主のシステムのカスタマイズが悪影響を及ぼしたケースだと容易に推測できる。この動作不良のために、Cチーム用のサーバーであるパワーブックは単に各サーバー更新時の動作確認にのみ用い、サーバーとしての用途をはずれた。このケースなどは、いかにシステムからシステム設計者の手で確実に、安定するシステムが構築されることの重要性を物語っている。実験が遅れたことの理由には機材の根本的な手直しにどのくらい時間がかかるか前もって一週間前には手配しておく必要があるとシステム設計者はあらかじめ予測した。それが実行されなかったことによるトラブルであることは明白である。結局の所クライアントマシンの準備と同じ所でミスがあったわけである。確かに、システムの設計をその方面に知識の深いものでまかなっていこうという気持ちはわかる。しかし、だからといってマネジメントする人間および少なくとも実験を主催する側は何がトラブルにつながるか理解するだけの勉強は怠ってはならない。
　実験時において、結局の所過負荷によりダウンしたマシンはPowerMacintosh7100/80AVとPowerMacintosh7200/120の２台のみであった。それぞれのリブート回数は前者が1回、後者が2回である。また、PowerBook3400/240に関しては、一度動作が鈍いというクライアントからの要望でソフトウェア的にリブートをかけたが、その他に至っては一度のリブートも要としなかった。これはサーバーソフトウェアにより安定性に大きな能力の違いがあることがまず第一の理由として考えられる。次に、搭載メモリ容量の問題があげられるだろう。MacHTTPに関しては、当初予定していたサーバーソフトウェアを当日実験直前にさしかえるという事態下での運用であったため、その原理的な部分に関しては今回追求できていないが、おそらく空きメモリもしくはアプリケーション割り当てメモリの中にどんどんゴミがたまっていく構造になっているのではないか、故にある程度のアクセスがたまればサーバーがダウンするという結果につながっていたのではないか、と想像される。しかし、これは問題のあった二機とほぼ問題のなかった二機との間にひとつ桁の違う搭載メモリの格差があったことを考えると、一概には言えなくなる。そもそもマックベースのサーバーが故、マッキントッシュのファイル管理システムやメモリ管理システムの元での運用は必然となり、従来重々語られてきたマッキントッシュのメモリ管理の不合理性が生み出した産物であったとも充分に考えられる。CPU性能に関しては、殊にCPUのマシンパワーを必要とするコンテンツはなく、CPUの過負荷による問題があったとは想像できない。ただ、どうしても莫大な数のコンピュータがぶら下がって過密状態にある立命館大学の中にサーバーを設けたことによるネットワークトラフィックの問題があったともいえ、サーバーの動作状況に関しては理由が多分に複合的に考えられる。システム管理者はマッキントッシュベースのサーバー運用しか考えられない選択肢の中では、やはりマッキントッシュのメモリ管理機能の甘さを原因として最有力視している。デバッガ、ネットワークトラフィック検査機等の容易がなかったため、この件に関しては明確な原因を究明することはできない。あとはコンテンツの部品点数の多さがサーバーに一時的に大きな負荷をかけることがあったことは特記しておかなければならないが、今回のように１対１対応で負荷分散をはかるという考えも、機材がすべて優秀なものであれば問題はなかったが、結局の所半ば無理強いして[connoisseur]の機材を貸出するぐらいであれば、いっそもっとスリム化してkkf1fs01（立命館大学衣笠ファイルサーバー）に繰り返し大量に読み込まれるコンテンツは読みにいかせるなど、などのコンテンツ設計をするほうが合理的であったかもしれないとの思いは残る。ただ、マッキントッシュベースのサーバではアップルトークを経由してファイル共有機能を使用することにより、各サーバーのコンテンツをコントロールようのマシンで一元管理することが可能であり、このためにこちらの方向性を策定したという理由はある。

Back to outline