[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[orca-users:02611] Re: woody 版の二重化について

川崎医療福祉大学 国方です
> よく僕のHPを見てください。
> どこに、従のglclientの設定が書いてありますか？

 書いてはいらっしゃいませんね。

> > 通常運用時従サーバーのjma-receipt（サーバー）部分はまったく使用されてい
ない
> > のでは？
> > と考えるのですが。
>
> 使用しないのです。
> > またこれであれば万が一主サーバーがこけた場合。
> > すぐに主従を入れ替えて作業するのは可能ですが。
>
> それが、重要なのです。
> 生越さん的書き方をすると、主のマシンのハードディスクに
> コーヒーをぶちまけた時、すぐに仕事ができる設定です。
> > http://arcangel.cside21.com/orca/2db_2.html
>
> の中の、僕の設定となってる図は、ORCA-HPにある設定図で、
> 僕が、昨日説明した説明では、ありません。

 設定的に上記のHPの一番上の設定になっていますね？
 一番上の図はORCAーHPから直接引用したものです。

八木先生のおっしゃり方と主サーバは停止し、従サーバーのみの1台運用状態である
と判断します。

しかし、設定方法をみますと、従サーバーは存在しないコンピューター（障害が発生
している主サーバー）
のpostgreSQLにアクセスをしているのではないか思うのですが？

 自分としてはそこが矛盾点ではないかと言っているのです。

実際ORCA-HPでも以前からのPotatoの説明では相互に設定するようになっていた部分
が
Woodyの設定例では主→従のみのデータルートに変更されています。

 今回HPの方で考察させていただいたのは、空いているリソース部分を空けることに
より
 コンピュータの負荷を減らし。従サーバーの安定性を向上するためと、
 人為的なミスによる従サーバーへの誤入力を防ぐためです。

使用しないとはいえjma-receiptが起動している状態では、従サーバーからDBに書き
込む可能性が0になるというわけではありません
八木先生の利用形態だとしても、従サーバーを停止して置きましたら従クライアント
自体起動しないのでミスによる書き込みも多少減ると思います。

 また、八木先生がおっしゃるバックアップサーバを作るのであればjma-receipt含め
 何も動作させないpostgresqlのみ動作するマシンを用意するべきではないかと思い
ます。
 使わないとはいえ外部から容易にアクセスできるのはバックアップサーバにはなら
ないと思います。

jma-receiptの動作していない状態であれば上記の状態にかなり近いものになると思
います。
jma-receiptの動作していない状態であればクライアントの設定をしていても
jma-clientは起動しません。
ですので、従サーバーから主サーバーに入力するの事に問題があるとはおもえませ
ん。

人が操作しているということ時点で障害頻度が上がるというのであれば主サーバーと
従サーバが連動しているので
どちらかが正常運用されており問題はないはずです。
両方同時にダウンすることは、主サーバー障害時に従サーバーから入力中に再度障害
発生するのとあまり変わりません。

上記のことを考え従サーバーでは
 postgresqlで主サーバーのデータをミラーリングする。
 glclientは主サーバーのjma-receiptへアクセスする。(入力端末が必要であれば。)

 jma-receiptはインストールおよび、スタンドアロンでの動作を確認、jma-receipt
を停止しておく
 必要時のみサーバを起動することにより、主サーバー障害発生時には従サーバー
jma-receiptを利用する
 という運用形態が最適だと判断しました。

ORCAーHPを批判するわけではありませんが。
HP公開されている設定方やインストールほうは簡単にインストール運用できるように
するためもありシステム設計てきにみると
多くの矛盾点が含まれているとおもいます。
インストール方法のページで紹介されているパッケージ
task-jma-receipt
というものはスタンドアロン動作を目的にパッケージングされていると思います。
パッケージングリストをみていると
task-jma-client
task-jma-server
が存在し、利用形態別にパッケージが分けられているのを確認しました。

実際にいろいろな方法で導入してみましたが、task-jma-receiptで導入すると
大きくx-window-system pgsql jma-receipt jma-client がインストールされます。
またデーモンとして起動するものも多くあるので無駄なリソースを消費していると感
じました

純粋なクライアントであればpgsqlもjma-receiptも必要ありませんし、
純粋太サーバだけを構築したいのであればjma-client x-window-systemをインストー
ルする必要もありません。

実際に
task-jma-clientではpgsql jma-receiptを必要としませんし、
task-jma-serverでもx-window-system jma-clientを必要としていません

利用形態によってパッケージを選択する必要があるのに、
ORCA-HPのインストール方法にこれに対する記述が無いのは問題ではないかと考えま
す。

 以前このMLでも言われていましたが、要らないものは入れないというほど最大のセ
キュリティホール対策はないと思います。

今回卒論でORCAに着目させていただいて、実際に導入、運用させていただき、
またMLのなかでも多くの先生がたの意見を聞かせていただいているうちに
ここはおかしいのではないか？と思う点があったので意見させていただいています。
八木先生のように率先してHPを開かれ導入期などをかかれている方がいらっしゃるの
で
試行錯誤されているのを吸収し、また矛盾点をふまえてORCAを良いものとしていきた
いと思い意見させていただいています。



> 僕が言ってるのは、従のglclientを、従のサーバーにつないで
> おいて、それを使わないと言ってるのです。
> まさか、ORCAを４台（クライアントマシン２台＋サーバーマシン２台）で
> 使おうと考えているのではないでしょうね。

現在はサーバー2台 クライアント 2台でテスト運用しています。
うちの場合は診療所でありませんので入力数が少ないですし
実際の運用とは違ってくるとは思いますが、
３〜4人が同時にORCAを動作させる必要があるのでこうしています

現在の構成は
Debian 主サーバー + クライアント
Debian クライアント
windows クライアント(ASTEC-X使用 Debian クライアントに接続)

Linuxとは元来マルチユーザーマルチタスクOSですので1台で2人がログインしそれぞ
れがクライアントが起動しているというのは問題にはなりません。

現在は複数で使用するためリソース使いたくないため二重化は停止しクライアントと
して使用しています。
バックアップはHPのほうで紹介してありますがcrondにより別のHDDに数日分自動的に
行っています。

> クライアントが必要なら、他に作ればいいことです。
> 主のマシンのHDDにコーヒーをかけてみてください。
> glclientだけが生き残りますか？

内の環境では上記のとおり複数のクライアントが存在しているのと、
サーバーとクライアントを完全に分けたいという八木先生の意見ですと
クライアントだけの構成のもののアクセス方も必要になりますので”例”として書い
たつもりです。



+------
    川崎医療福祉大学 医療技術学部
            医療情報学科　田中ゼミ
                                            国方隆良
                             担当教員　田中昌昭
                       http://arcangel.cside21.com/orca/
                                                  -----+