2.2.2 メンテナンスについて
Groupmaxの運転中は,データの状況が変化します。これに伴うディスクの圧迫やデータの分散で起こる性能低下を防ぐために,適切な方法によってGroupmax環境を維持する必要があります。また,ユーザの増減などによっては,変更されるユーザ情報を各サーバプログラムに正しく配布させる必要があります。
ここでは,Groupmaxのメンテナンスで,特に留意する項目をサーバプログラム別に説明します。なお,メンテナンスを実施する前に,環境のバックアップを実施することをお勧めします。
- <この項の構成>
- (1) Object Server/High-end Object Server
- (2) Address Server及び各サーバのユーザ情報
- (3) Mail Server
- (4) Document Manager
- (5) Workflow Server
- (6) Scheduler Server,Facilities Manager
- (7) Agent Server
- (8) Groupmax WWW
(1) Object Server/High-end Object Server
(a) データベースの再編成
- メンテナンスの概要
- データベースにオブジェクトの追加や削除をすると,データベースの配置の乱れが発生します。これを適切な配置にすることで,オブジェクトのアクセス性能が向上し,データベースのスペース効率が適切になります。データベースの再編成の概要を,図2-3に示します。
- 図2-3 データベースの再編成の概要
![[図データ]](figure/zu02030.gif)
- メンテナンス実施の概要
- まず,データベースの再編成での障害に備え,データベースの再編成前にデータベースのバックアップを取得します。
- 次に,Object Server又はHigh-end Object Serverをユティリティモードで起動させた状態で,データベースの再編成を実施します。
- なお,High-end Object Serverで,ジャーナル機能によってデータベースの回復運用を実施する場合,データベースの再編成後にも,データベースのバックアップを取得します。
(2) Address Server及び各サーバのユーザ情報
(a) 各サーバ用のユーザ情報への対応
- メンテナンスの概要
- Address Serverで変更したユーザの情報は,Mail Server,Workflow Server及びScheduler Serverでは個別に反映させる必要があります。また,マルチサーバ構成で各ユーザの使用するサーバを別のサーバに移す場合,各サーバで管理するユーザの資源を新しいサーバに移す必要があります。
- Address Serverでのユーザ情報の更新とは別に,必要に応じて各サーバで個別に反映させる必要がある情報を次に示します。
- 個人のメールボックス
- Workflowのユーザ情報及びユーザトレー内案件
- Schedulerのユーザ情報及びスケジュール情報
- Agentのエージェント情報
- ユーザ情報を移動するときの,各サーバへのユーザ情報の反映の概要を,図2-4に示します。
- 図2-4 各サーバへのユーザ情報の移動の概要
![[図データ]](figure/zu02040.gif)
- なお,このほか,E-Mailアドレス及びスケジュール機能でのユーザの登録情報については,Mail - SMTP及びScheduler Serverに反映する必要があります。反映には,自動的に反映する方法と手動で反映する方法とがあります。それぞれの反映方法については各マニュアルを参照してください。
- メンテナンス実施の概要
- 各情報をユーザ情報の変更後も継承させる場合のメンテナンスの処理概要を,次に説明します。なお,この処理は,Address Serverでのユーザ情報の変更を,GUIによる登録又はコマンドによる一括登録で実施した場合に必要となるのものです。ユーザ情報の変更をオプション機能のAddress - Assistで実施した場合,個人のメールボックスの移動及びWorkflowのユーザ情報及びユーザトレー内案件に関する処理は,自動的に実施されます。Address - Assistの概要については,マニュアル「Groupmax Address - Assist Version 6 システム管理者ガイド」を参照してください。
- 個人のメールボックス
個人のメールボックスに蓄積されたメールは,Address Serverでのユーザ情報の変更だけでは継承されません。ユーザ情報の変更前に変更ユーザのメールボックスのバックアップを取得し,変更後にリストアさせる必要があります。
- Workflowのユーザ情報及びユーザトレー内案件
Address Serverでのユーザ情報(所属組織やWorkflowサーバなど)の変更は,そのままではWorkflow Serverに引き継がれません。これをワークフローデータベースに反映させる必要があります。
- Schedulerのユーザ情報及びスケジュール情報
蓄積されたスケジュール情報は,ユーザ情報の変更だけでは継承されません。ユーザ情報の変更前のサーバから変更後のサーバに移動させ,変換コマンドを実行する必要があります。
- Agentのエージェント情報
移動や削除のあったユーザが作成したエージェント情報は,サーバ上に残ります。エージェント情報を移動前のサーバから削除し,移動後のサーバで再度定義する必要があります。
- なお,Workflow及びSchedulerについては,Address Serverでのユーザ情報更新から1時間経過(時間は変更できる)後,又はAddress Serverの再起動後に実施します。
- 各サーバの操作については,該当するサーバのマニュアルを参照してください。
(b) ユーザ情報の整合性の確保
- メンテナンスの概要
- システムがマルチサーバで構成されている場合,マスタ管理サーバで登録情報の追加,削除,及び変更したときに,各サーバに登録情報を自動的に配布します。このとき,回線障害が発生したり,相手サーバが起動されていなかったりすると,各サーバ間で登録情報の整合性が保たれないことがあります。ユーザ情報の整合性確保の概要について,図2-5に示します。
- 図2-5 ユーザ情報の整合性確保の概要
![[図データ]](figure/zu02050.gif)
- メンテナンス実施の概要
- Address Serverの運転席から,「登録情報の整合性確保」を実施します。
(3) Mail Server
メール機能及び掲示板機能では,システムを運転していくうちにメールや掲示板のデータが蓄積されます。これに伴うデータの管理として,それぞれ適切な方法でMail Server環境を維持する必要があります。作業の概要を次に説明します。
(a) 不要メールの削除
- メンテナンスの概要
- 個人,組織,回覧メールの送信・受信・保留メールボックス内のメールは,ユーザが削除しないかぎり,メールボックス内に残ります。このデータがサーバ内のデータ量を増加させます。このデータ量の増加を防ぐために,容量や時間を条件として滞留するメールを削除します。容量を基にした不要メールの削除の概要について,図2-6に示します。
- 図2-6 容量を基にした不要メールの削除の概要
![[図データ]](figure/zu02060.gif)
- メンテナンス実施の概要
- 不要メールを削除するには,次に示す三つの方法があります。
- 自動削除デーモンの起動による自動削除
- メール削除コマンドの実行
- クライアントからの定期的な削除
- 自動削除デーモンの起動による自動削除とメール削除コマンドの実行では,未読メールと回覧メールは削除の対象になりません。また,削除コマンドによって,期間を指定して削除することもできます。
- なお,不要メールの削除は,ユーザでのクライアント応答時間の短縮にも効果があります。したがって,ユーザに不要メールの定期的な削除を意識させることが大切です。
(b) 不要記事の削除
- メンテナンスの概要
- 掲示板上の記事は,登録者が登録時に掲示期限を指定できますが,該当する情報が不要になる時期を含めて,ユーザが掲示期限として指定する場合があります。このため,不要な記事が残った場合,掲示板ごとの記事数の上限値により有効な掲示ができなくなる場合があります。したがって,不要になった記事は適時削除する必要があります。
- メンテナンス実施の概要
- 掲示板の記事は,設定した有効期限を超えると自動的に削除されます。ただし,掲示期限に達していない記事を定期的に自動削除することはありません。Mail Serverコンソール画面への容量警告を示すメッセージが表示されたときに,掲示板上の記事で不要と判断されるものを,削除権限を持った掲示板管理者,ユーザが削除してください。
(c) 掲示板の整合性確保
- メンテナンスの概要
- 掲示板のレプリカ機能を適用した運用では,一部のサーバの停止などによって,マスタ掲示板とレプリカ掲示板の記事内容,又は数が異なることがあります。これによって,レプリカ掲示板を利用するユーザで,本来は参照できる記事が参照できなくなる場合があります。これを解決するため,レプリカ掲示板の情報をマスタ掲示板の情報に合せる必要があります。
- メンテナンス実施の概要
- Mail Serverの運転席から,「掲示板の整合性確保」を実施します。
(4) Document Manager
文書管理システムでは,システムを運転していくうちに文書データが蓄積されていきます。これに伴うデータの管理として,適切な方法でDocument Manager環境を維持する必要があります。作業の概要を次に説明します。
(a) 文書更新時の文書配布環境の維持
- メンテナンスの概要
- 文書配布を定義された文書や定義されたフォルダ下の文書は,文書配布機能によって,他のDocument Managerのサーバ環境に配布できます。しかし,配布処理中に配布先サーバが停止したり,通信回線の不調などで文書が正常に配布されなかったりする場合があります。この場合,本来参照できる文書が共通キャビネット下に見えない状態となり,これを解決する必要があります。文書配布の環境維持についての概要を,図2-7に示します。
- 図2-7 文書配布の環境維持についての概要
![[図データ]](figure/zu02070.gif)
- メンテナンス実施の概要
- 文書配布の運用では,次の順序に留意して作業します。
- 配布元サーバ上にあるエラーとなったエクスポートファイルを,ftpで配布先サーバに転送した後,インポート機能でインポートします。
- 文書配布状態管理を使用している場合,文書再配布機能ユティリティで再送します。
- 配布を確認するには,Document Manager管理者が各配布先へログインし,更新対象文書の日付がアップデートされているか確認します。
(5) Workflow Server
ワークフローのシステムで処理される案件は,自動的に削除されないため,運用の形態に合わせて削除する必要があります。次に,運用時の環境を維持するために実施する作業の概要を説明します。
(a) 完了ワークの削除
- メンテナンスの概要
- 案件の遷移や時間の経過によって,「シンク」ノードに到着した案件や,終了又はキャンセルされ,保存期間を過ぎた案件は,業務履歴としてサーバに保管されています。しかし,保存期間の経過や業務内容の文書管理への登録によって,案件としての情報は不要となります。このように履歴が不要となった案件は,適時削除する必要があります。完了ワークの削除の概要について,図2-8に示します。
- 図2-8 完了ワークの削除の概要
![[図データ]](figure/zu02080.gif)
- メンテナンス実施の概要
- シンクノードに到着して終了したワークと,終了又はキャンセルされたワークのうち,保存期間を過ぎたワークをワークフローデータベースから削除します。削除対象は,削除するワークの案件情報(ケース・文書・メモ)と,ワークの履歴情報(ワークヒストリ)です。
(6) Scheduler Server,Facilities Manager
通常のシステム環境では,スケジュール情報や施設予約情報が日々増加します。これに伴うディスクの圧迫や,組織改定によって発生する不要なスケジュールデータや施設情報を整理するために,それぞれ適切な方法によってScheduler Server,Facilities Manager環境を維持する必要があります。作業の概要を次に説明します。
(a) 不要スケジュールの削除
- メンテナンスの概要
- 人事異動や施設閉鎖などで存在しなくなったユーザや施設は,ユーザや施設が削除された後もサーバで管理されます。また,利用中のユーザも,過去の予定について継続して管理されますが,サーバへの情報の過度な蓄積を防ぐため,適時削除することが必要です。
- メンテナンス実施の概要
- 不要スケジュールの削除は,各サーバのコンフィグレーションに設定することで,自動で実施されます。削除対象とする情報については,次に示す二つの指定方法があり,運用に合わせて選択します。
- 明示的に年月を指定する。
- 削除処理を実施する時期からの相対的な日時を指定する。
- この指定はサーバごとにできますが,システムの統一を考えて全サーバで同じ設定にするのが一般的です。
- なお,削除に関する設定値は,ユーザのスケジュール情報及び施設の予約情報で共通の設定となります。
(b) 管理データの取得
- メンテナンスの概要
- 管理データ(ユーザ情報,セキュリティランク,はん用化データ,施設設備テーブル,施設管理情報)は各サーバに登録されていて,情報は全サーバで共通です。初めに情報を親サーバに登録してから,これを子サーバに反映させます。
- メンテナンス実施の概要
- 親サーバに登録された管理データは,定期的な子サーバへの配布を自動的に行うことができます。配布は,子サーバから親サーバへの要求があった時点で実施されます。親サーバの負荷集中を避けるため,それぞれの子サーバで設定する時刻をずらすことをお勧めします。なお,設定値はScheduler ServerとFacilities Managerで共有します。
(7) Agent Server
エージェント情報は,エージェント生成時のユーザの指定によって,稼働対象となるサーバ上に生成されます。このエージェント情報は,サーバ間で整合性が取れている必要があります。運用時に環境を維持するために実施する作業の概要について,次に説明します。
(a) 不要なエージェント情報の削除
- メンテナンスの概要
- 人事異動などで存在しなくなったユーザが削除された後も,そのユーザに関連するエージェント情報はサーバで管理されます。このような情報は,サーバに不要な情報が蓄積することを防ぐため,適時削除する必要があります。
- メンテナンス実施の概要
- サーバに残っている不要なエージェントを,運用コマンドで削除します。
(b) エージェント情報の整合性の確保
- メンテナンスの概要
- 稼働している複数のサーバのうちの1台がダウンした場合,プログラム間の情報の対応が取れなくなることがあります。このような場合,管理者は,Agent Server間のユーザ情報について整合性を確保する必要があります。 Agent Server間のユーザ情報の整合性確保の概要について,図2-9に示します。
- 図2-9 Agent Server間のユーザ情報の整合性確保の概要
![[図データ]](figure/zu02090.gif)
- メンテナンス実施の概要
- Agent Serverの整合性を確保する機能を実行することで,サーバ間の整合性を確保します。
(8) Groupmax WWW
Groupmax WWWを使用してWWWブラウザからGroupmaxを利用する場合,Webサーバ及びGroupmaxサーバの環境維持の作業のほかに,Groupmax WWWの環境を維持するための作業が必要になります。次に,Groupmax WWWでのメンテナンス作業の概要について説明します。
(a) 作業ワークファイルの削除
- メンテナンスの概要
- ユーザがWWWブラウザ環境からGroupmaxを利用している状態で,WWWブラウザのハングアップや通信回線の異常などが発生すると,Groupmax WWWインストールディレクトリ下のtmp¥Mailディレクトリ内に,作業ファイルが残ります。この作業ファイルを削除することで,不要なデータをGroupmax WWWが動作する環境から取り除きます。
- メンテナンス実施の概要
- 作業用の一時ファイルの格納を指定したディレクトリ下を,定期的に削除します。
(b) ユーザ資産の整理
- メンテナンスの概要
- ユーザの利用環境には,Groupmax WWWの操作環境として使用された,デスクトップのカスタマイズ情報,ローカル宛先台帳,及びスケジュール機能でのグループ情報を格納したファイルが存在します。これらの情報は,ユーザの利用環境の変更や登録削除によって,不要データとして残ります。この不要データを削除することで,Groupmax WWWの動作サーバ内の不要データが削除され,該当する環境に不要な情報が残ることを防止できます。
- メンテナンス実施の概要
- 不要となったデータファイルを,定期的に削除します。