ＭＵＭＰＳによる分散・統合化システム Intergrated Distribution System Using MUMPS
野口 弘＊， 古林 榮次郎， 寺村 昌文 Hiroshi Noguchi,Eijirou Kobayashi,Masafumi Teramura
大阪府立羽曳野病院 情報企画室 Osaka Prefectural Habikino Hospital
［はじめに］
メインフレームからクライアント・サーバ（Ｃ／Ｓ）システムへの再構築を、 全社的に踏み切るユーザも増えてきたが、一貫したシステムデザインを無視し たシステムでは、予想に反して効率が上がらない事例も報告されている。これ は、無条件にホストの業務をＣ／Ｓシステムに切り出したり、全体構成を熟考せず、とにかくシステム化で きる部分からシステム化した個別システムを統合化しようとした結果である。
我々は、Ｃ／Ｓシステムに潜む問題を検討しつつ、下記の点に注意してＣ／ Ｓシステムとは異なった、分散統合化システムをＭＵＭＰＳを用いて構築したので報告する。
1.１台のプロセッサのダウンでも使用できなくなるシステムはシステムとはいえない。
2.レスポンスの遅いコンピュータはコンピュータとはいえない。
3.ＣＰＵ Ｐｏｗｅｒ等の資源を有効利用しないシステムは良いシステムとはいえない。
［概要］
大阪府立羽曳野病院では、１９９４年１月１日よりＤＥＣ７６１０ ２台を 中核とし、Ｄｏｓ／Ｖ パソコン２３８台を端末とする第４期システムを構築した。
本院のシステムでは、２４時間運転を基本としており、いかなる場合にもシ ステムを長時間停止することは不可能である。したがって、ＤＥＣ７６１０の システムはクラスター構成をとり、ディスクのシャドウイングはもとより日時 のバックアップ中にもディスクを二重化する構成をとっている。中核システム の他には、単独でも業務のＭＵＭＰＳ環境を実行可能なＡＸＰ３６００システ ム（データベースは本体と同一容量で冗長なし）及び容量は少ないがほぼ同一 環境を再現できるテスト用システムＡＸＰ３４００がある。
［Ｃ／Ｓシステムと負荷分散］
Ｃ／Ｓシステムではデータベースへのアクセスはサーバに一極集中化し、た とえＳＭＰ（Ｓｙｍｍｅｔｒｉｃａｌ ｍｕｌｔｉｐｒｏｃｅｓｓｏｒ）のプ ロセッサ数を増加したとしても、コストパフォーマンスは低下してしまう。ま たプロセッサ数を増加しても処理能力はリニアに増加せず、極端な場合には処 理能力が変化しない例もみられる。ＳＭＰのプロセッサ数は、効率を考えると ４つが限度という報告もみられる。
最近はＯｒａｃｌｅでも複数台のサーバを、クラスタ構成で使用する場合に 対応したＰａｒａｌｌｅｌ Ｑｕｅｒｙを発表し、ネットワーク接続による多重化した サーバで、並列ＤＢＭＳで効率化を計ろうとしている。しかしＣ／Ｓシステム のサーバの多重化は、一般的にＳＭＰのプロセッサの数を増加させるよりも効 率が悪くなる結果が出ている。これはＣ／Ｓシステムのネットワークが通常１ ０Ｍｂ／Ｓのイーサネット使用していることに起因している。
当院のシステムではクラスタ結合された２台のＤＥＣ７６１０がサーバとし て機能し、４台のプロセッサは、１００Ｍｂ／ｓのＦＤＤＩで直接ＣＰＵ接続 されている。
通常はデータベースもアプリケーションも、２台のＤＥＣ７６１０システム ですべて実行され、ＡＸＰ３６００などは中核システムのバージョン・アップ 時などは代替システムとして機能し、平常時は中核システムのウォーム・スタ ンバイのシステムとして待機しつつ、オンライン業務に影響を与えるバッチ処 理の負荷分散システムとして機能するように設計されている。
一般に複数のプロセッサで構築されたシステムは、ＣＰＵの負荷がどうして もオンライン系中心となる１台に集中しがちであり、各プロセッサに接続され る端末数も拡張・追加に伴ってアンバランスになりがちである。さらに代替シ ステムはウォーム・スタンバイで、通常はＣＰＵ負荷０の状態で有効利用がな されていない例が多くみられる。
今回我々が開発した分散・統合化システムは、ＣＰＵのＬｏａｄ Ｂａｌｌ ａｎｃｅを無駄なく有効に活用し、各アプリケーションに最適なＭｉｇｒａｔ ｉｏｎ ＳＹＳＴＥＭ実現するものである。さらにこれらのコントロールはす べてＭＵＭＰＳで行い、ユーザは自分が今どのプロセッサで実行し、どのシス テムのデータベースを使用しているか意識することなく業務を実行できる。 ＭＵＭＰＳのＤＤＰは、一般のＤＢＭＳで使用されているシェアド・ナッシ ング方式のようにデータベースを、プロセスを実行しているシステムにコピー する必要がない。そして並列ＤＢＭＳのシェアド・ディスク方式に必要なＤＬ Ｍ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｌｏｃｋ Ｍａｎａｇｅｒ）等を、各プロセッ サに搭載する必要はなく各プロセッサがデータベースの排他制限やコヒーレン ス制御を行うので、ネットワークに負荷をかけない。
［システムのＭｉｇｒａｔｉｏｎの方法］
システムの切り替えの方法は、メニューより業務が選択された時点でその業 務が実行されるべきプロセッサがメニューテーブルより決定される。指定のプ ロセッサが立ち上がっていることを事前にＤＤＰ管理テーブルによってチェッ クし現在のプロセスをスリープ状態にして、指定プロセッサにリモート・ログ インする。相手プロセスで起動されたプロセスは、自動的に指定された業務ア プリケーションを実行する。業務が終了するとリモート・ログインによって起 動されたプロセスは終了し、もとのスリープ状態のプロセスに戻って業務を再 開する。もしリモート・ログインされるべきプロセッサが立ち上がっていない ときは、自動的に現在のプロセッサで業務を実行する。
以上のように各アプリケーションは、渡り鳥のようにプロセッサ間を移動し、 最適の環境で業務を実行する。例えばデータベースへのアクセスが主となる業 務はそのデータベースを擁しているプロセッサに、データベースへのアクセス は少ないがＣＰＵ資源を大幅に使用するバッチ処理はオンライン業務に影響を 与えないウォーム・スタンバイのプロセッサへＭｉｇｒａｔｅする。これらの コントロール情報はＭＵＭＰＳグローバルのメニューテーブルに登録されてお り、プロセッサの指定は瞬時に変更可能である。これらの処理は、ユーザの手 を全く煩わせず、通常通りメニューの番号選択するだけでよく、たとえリモー ト・ログインするプロセッサがダウンしていても、ユーザには全く気づかれず に業務を続行することが可能である。
しかしアプリケーションを状況に応じてどのプロセッサでも稼働できるよう にするには、グローバルのジャーナリングのように、日々変更されたアプリケ ーションプログラムを管理・記録し、自動的に全プロセッサに配送するトゥー ルが必要である。したがって我々は、ルーチンの自動デリバリィ・ユーティリ ティも同時に開発した。
［まとめ］
ＭＵＭＰＳによる分散・統合化システムを使用することにより、
1.各プロセッサの負荷分散を簡単にコントロールできる。
2.３台の主要プロセッサのうち、どの２台がダウンしてもシステム全体の稼働に支障は
3.ない（レスポンスは当然低下するが）。
4.このシステムを利用することにより、従来ウォーム・スタンバイのシステムも有効に利用でき無駄がなくなった。
今後は、ＣＰＵの負荷を自動モニターし、自動的に起動プロセッサを選択す る管理システムも検討したい。
［参考文献］
（１）中村 正弘 ＵＮＩＸサーバのクラスタ接続がシステム性能の向上策に浮上
日経エレクトロニクス Ｎｏ．６３７ Ｐ．１３０ １９９５
（２）川上 潤司 破綻なきＣ／Ｓ開発
日経コンピュータ Ｎｏ．３７０ Ｐ．１１６ １９９５