Redbooks Wiki:Lotus Domino 管理の 適化

1

2

目次 第 1 章はじめに..................................................................................................................... 9 

1.1. 文書 ........................................................................................................................... 9 1.1.1.文書の内容 .......................................................................................................... 9 1.1.2.サーバーの 詳細 ............................................................................................... 10 1.1.3.アーキテクチャーの概要.................................................................................... 10 1.1.4.セキュリティ標準 ................................................................................................ 15 1.1.5.バックアップ標準 ................................................................................................ 15 1.1.6.命名規則 ............................................................................................................ 16 1.1.7.エンド・ ユーザーに 対する 指示....................................................................... 18 1.1.8. 結論 ................................................................................................................... 19 

1.2. 日次、週次、および月次チェックリスト.................................................................... 20 1.2.1.一般的な 推奨事項 ........................................................................................... 20 1.2.2. アクション........................................................................................................... 21 1.2.3. 結論 ................................................................................................................... 24 

1.3. セキュリティ・チェックリスト ..................................................................................... 25 1.3.1 その他の 参照先 ............................................................................................... 26 

1.4. Domino の認証オプション .................................................................................... 27 1.4.1 Domino の 認証 オプションの選択 ................................................................. 27 1.4.2. SmartCard (1)................................................................................................. 28 1.4.3. Lotus Notes と HTTP パスワード の同期 (3) ............................................ 29 1.4.4. LDAP (4 と 5)................................................................................................... 29 1.4.5. SPNEGO (6) .................................................................................................... 29 1.4.6.Lotus Notes および オペレーティング・システム シングル・サイン・ オン (7)...................................................................................................................................... 30 1.4.7.Tivoli Directory Integrator (9)...................................................................... 31 1.4.8.追加の リソース ................................................................................................. 31 

1.5. エージェントと Domino 管理者............................................................................. 32 1.5.1.エージェントの トリガー ...................................................................................... 32 1.5.2.サーバー上で 実行が スケジュールされているエージェントの判別 ............... 33 1.5.3.エージェントの実行に影響を与えるマネージャー設定..................................... 33 1.5.4. 全文検索 と エージェント .................................................................................. 34 1.5.5. 新しい エージェント と アプリケーション の パフォーマンスに対する 影響 .... 35 1.5.6. Agent Manager に 伴う 問題 の トラブルシューティング ............................ 35 1.5.7. エージェント の 作成......................................................................................... 36 

1.6. Domino ドメインの拡張 ........................................................................................ 37 1.6.1. 新しい サーバー の 登録 と 保護 .................................................................... 37 1.6.2. 重要な データベースの 複製 ........................................................................... 38 1.6.3. メール・ルーティング ......................................................................................... 40 1.6.4. 複数の サーバーのモニターおよび管理 ......................................................... 41 1.6.5.クラスタリング..................................................................................................... 41 

1.7. 設計、複製およびリリース混在 設計の頻繁なやり直しの回避 ........................... 43 1.7.1. 問題の説明 ....................................................................................................... 43 

3

1.7.2.問題の防止 ........................................................................................................ 43 1.7.3. 混在環境での混合クラスター の取り扱い ....................................................... 45 

1.8. 定期保守のベスト・プラクティス ............................................................................. 46 1.8.1.Fixup および トランザクション・ロギング .......................................................... 46 1.8.2. 定期保守 ........................................................................................................... 46 1.8.3. データベース破損 ............................................................................................. 47 1.8.4. ハード ・ディスクのフラグメント化 ..................................................................... 47 

1.9. モバイル・アクセス .................................................................................................. 48 1.9.1.Traveler............................................................................................................. 48 1.9.2.BlackBerry ....................................................................................................... 50 1.9.3. Lotus iNotes Ultra-Lite ................................................................................ 52 1.9.4. IMAP/POP ....................................................................................................... 54 

第 2 章  ユーザーとクライアントの管理 ......................................................................... 56 2.1. Lotus Notes クライアント管理の 適化のヒント ................................................ 56 

2.1.1. クライアント/ユーザー管理の全般的なヒント................................................... 56 2.1.2. 近使用した連絡先 ........................................................................................ 57 2.1.3. ローカル・ レプリカ ............................................................................................ 57 2.1.4.Smart Upgrade................................................................................................ 58 

2.2. ユーザーの受信ボックスの管理............................................................................ 60 2.2.1. 受信ボックスのクリーンアップを使用したメール・ファイルのサイズ管理 ....... 60 2.2.2. 制限値の適用オプション .................................................................................. 61 2.2.3. DAOS 有効な 場合の制限値.......................................................................... 61 2.2.4. ローカル レプリカ 上での 制限値の実施......................................................... 62 

2.3. ポリシー................................................................................................................... 62 2.3.1. ポリシーの紹介................................................................................................. 62 2.3.2. ポリシーを使用したセキュリティ標準化と環境の簡略化 ................................ 63 

第 3 章  効果的なサーバー管理 .................................................................................... 68 3.1. モニター .................................................................................................................... 68 

3.1.1.モニター・オプション ........................................................................................... 68 3.1.2.モニターの対象 .................................................................................................. 69 3.1.3.Domino のプロファイルのモニター.................................................................. 69 3.1.4.Domino イベントの モニター ............................................................................ 79 3.1.5.詳細 情報 ........................................................................................................... 83 

3.2. メール転送 ............................................................................................................... 84 3.2.1.スパムの管理..................................................................................................... 84 3.2.2.メール転送と複数のディレクトリー .................................................................... 85 3.2.3.ジャーナリング.................................................................................................... 86 3.2.4. 不在通知 ........................................................................................................... 89 3.2.5. クラスター環境でのメール転送 ........................................................................ 89 

3.3. 大量メール送信 ...................................................................................................... 92 3.3.1. 大量メール送信の問題 .................................................................................... 92 3.3.2.大量メール送信の解決策.................................................................................. 92 3.3.3.結論 .................................................................................................................... 98 

3.4. 複数のディレクトリー .............................................................................................. 98 

4

3.4.1.要約ディレクトリー・カタログ、拡張ディレクトリー・カタログまたはディレクト

リー・アシスタンス ........................................................................................................ 98 3.4.2.ヒント ................................................................................................................... 99 

3.5. サーバー・クラスタリング・オプション .................................................................... 100 3.5.1. 単純化 ............................................................................................................. 100 3.5.2. Domino 部分の冗長化 ................................................................................. 101 3.5.3.Domino クラスター ......................................................................................... 102 3.5.4.OS クラスター .................................................................................................. 105 3.5.5.Internet Cluster Manager (ICM) ................................................................ 106 3.5.6.iNotes の高可用性構成 ................................................................................. 107 3.5.7.IMAP フェイルオーバー (Domino 8.5 の新機能) ........................................ 107 3.5.8.Lotus Traveler サーバーの高可用性 .......................................................... 108 3.5.9.ロード・ バランサー .......................................................................................... 108 3.5.10. ソフトウェア・プロキシー (IBM HTTP、nGinx、など) ................................. 109 3.5.11. Sametime および QuickR の高可用性 .................................................... 109 3.5.12.ディザスター・リカバリー・プラン.................................................................... 110 

3.6. トランザクション・ロギング ..................................................................................... 110 3.6.1. 8.5.x サーバーのトランザクション ロギング の一般的な推奨事項.............. 111 3.6.2.トランザクション・ ロギング のヒント ................................................................ 111 3.6.3.Domino 8.5.x サーバーの NOTES.INI 推奨事項....................................... 111 3.6.4.Domino 8.5.x および ODS 51 の更新........................................................ 112 

3.7. Domino Attachment Object Service (DAOS)............................................. 113 3.8. Domino の索引作成の管理 ............................................................................... 115 

3.8.1.ビュー索引........................................................................................................ 115 3.8.2.全文検索 .......................................................................................................... 116 3.8.3.ドメインの 索引................................................................................................. 121 

3.9. Domino 環境のバックアップ............................................................................... 121 3.9.1.バックアップの 基本 ......................................................................................... 122 3.9.2.バックアップ方式 .............................................................................................. 122 3.9.3.バックアップ・ ソフトウェア................................................................................ 126 3.9.4. バックアップ の 対象....................................................................................... 127 3.9.5. バックアップ手順............................................................................................. 129 3.9.6. バックアップ・スクリプト ................................................................................... 130 3.9.7. 推奨事項 ......................................................................................................... 132 3.9.8. まとめ .............................................................................................................. 132 3.9.9. 参照情報 ......................................................................................................... 132 

3.10. リストア ................................................................................................................. 133 3.10.1. ディザスター・リカバリー ............................................................................... 134 3.10.2.  静的 ファイルの リカバリー...................................................................... 134 3.10.3.  Domino データ・ ファイルの リカバリー ................................................. 134 

3.11 IBM i で削除された文書をリストアする手順 ...................................................... 140 3.11.1. オペレーティング・システム・タイプのバックアップのリストア手順 .............. 141 3.11.2. BRMS のフルバックアップのリストア手順 .................................................. 142 3.11.3. BRMS の増分バックアップのリストア手順 ................................................. 144 3.11.4. その他のリソース.......................................................................................... 145 

5

3.12.Domino HTTP サーバー.................................................................................... 146 3.12.1. 一般的なサーバー 構成............................................................................... 146 3.12.2. iNotes........................................................................................................... 146 3.12.3.トラブルシューティング と チューニング ........................................................ 146 3.12.4.その他の参照先 ............................................................................................ 147 3.12.5. ヒント.............................................................................................................. 147 

3.13.Domino HTTP サーバーのセキュリティ............................................................ 148 3.13.1. サーバー・アクセス ....................................................................................... 148 3.13.2. ユーザーのセキュリティと認証..................................................................... 150 3.13.3. データベースのセキュリティ ......................................................................... 151 3.13.4. ファイルシステムのセキュリティ ................................................................... 155 

3.14.Lotus iNotes ユーザー向けのリダイレクト・アプリケーションの設定.............. 156 3.14.1. iNotes リダイレクト・アプリケーションの作成 ............................................. 156 3.14.2. iNotes リダイレクト・アプリケーションの構成 ............................................. 157 3.14.3. ホーム・ページとしての iNotes リダイレクト・アプリケーションの構成 ...... 162 

3.15.Lotus iNotes の保護.......................................................................................... 164 3.15.1. iNotes と Notes の ID ファイル.................................................................. 164 3.15.2. Active X コントロール ................................................................................. 164 3.15.3. ブラウザー・キャッシュ管理.......................................................................... 165 3.15.4. オフライン・データベースの暗号化 .............................................................. 166 3.15.5. S/MIME......................................................................................................... 167 

第 4 章  環境のチューニング ........................................................................................ 168 4.1. 正常性確認. ........................................................................................................... 168 

4.1.1. 正常性確認の概略チェックリスト ................................................................... 168 4.1.2. 正常性確認の実行 ......................................................................................... 169 

4.2. Document Configuration Tuner (DCT)........................................................ 178 4.3. パフォーマンス・ベースラインの確立................................................................... 179 

4.3.1.推奨されるメトリック ......................................................................................... 180 4.3.2. Domino 統計の収集 ..................................................................................... 181 4.3.3.レポート・データベース..................................................................................... 181 

4.4. Domino のチューニングのヒント (全プラットフォーム) ...................................... 182 4.4.1.ビュー索引更新................................................................................................ 182 4.4.2. 特定のデータベースに対するトランザクション・ロギングの無効化 .............. 183 4.4.3.複製 .................................................................................................................. 183 4.4.4. 内部キャッシュ ................................................................................................ 185 4.4.5. 複数のメール・ボックス................................................................................... 187 4.4.6. サーバー・ベースのメール・ルール に関するヒント....................................... 187 4.4.7. ユーザー・セッションのチューニング .............................................................. 187 4.4.8.Domino Configuration Tuner (DCT) ........................................................ 188 

4.5. 仮想化環境のチューニング ................................................................................. 188 4.5.1. 仮想化の長所と短所 ...................................................................................... 188 4.5.2.静的リソース .................................................................................................... 189 4.5.3.ゲスト VM に関するベスト・プラクティス ......................................................... 189 

4.6. Windows 上の Domino のヒント ...................................................................... 191 4.6.1.システム・ページ・プール ................................................................................. 191 

6

4.6.2.Windows サーバーに関するその他のチューニングのヒント ....................... 192 4.6.3 その他の 参照先 ............................................................................................. 192 

4.7. Linux 上の Domino のヒント ............................................................................. 192 4.7.1.サーバーリソースのモニター........................................................................... 192 4.7.2.オペレーティング・システムの制限.................................................................. 192 4.7.3.Linux サービス ............................................................................................... 193 4.7.4.TuneKrnl......................................................................................................... 193 4.7.5. トラブルシューティングとデバッグのヒント ..................................................... 193 4.7.6. AIX 上の Domino サーバーでの並列 I/O とダイレクト I/O の 無効化 ...... 194 4.7.7. AIX 上の Domino での Java のチューニング ............................................ 194 4.7.8. AIX 用の Perfpmr ......................................................................................... 194 

4.8. IBM i 上の Domino のヒント .............................................................................. 194 4.8.1. 概要 ................................................................................................................. 194 4.8.2. パフォーマンス ................................................................................................ 195 

4.9. Domino HTTP サーバーのチューニングのヒント ............................................. 198 4.9.1.HTTP サーバー・スレッド ................................................................................ 198 4.9.2.HTTP リクエスト............................................................................................... 199 4.9.3.JVM のヒープ .................................................................................................. 199 4.9.4. データベースのパフォーマンス ...................................................................... 200 

7

0.1 前書き

注：この PDF 文書は、掲載元 URL にある『Optimizing Lotus Domino Administration』の wiki のテキストをそのまま記載したものです。 新の更新については、

必ず wiki バージョンを参照してください。

この IBM Redbooks wiki では、Lotus Domino 管理の 適化方法に関する情報を提供します。

も重点を置いているのは、Lotus Domino 管理者の貴重な時間を 大限に活用する方法に

ついて、管理者に情報を提供することです。

Lotus Domino 環境の 適化は、サーバーやクライアントの特定の構成パラメーターをどう設

定するかの問題というよりも、その環境における特定のニーズにどう対処していくかという概

念的なアプローチです。

この Redbooks wiki では、 適化されたスマートな Lotus Domino 環境がどのようなもので

あるかについて、執筆者陣の経験と業界のベスト・プラクティスを共有し、円滑で 適化され

た Domino 環境を確保するために実行すべきチェックリストとステップも紹介しています。 ここに記載されているアイデアや概念の説明はあくまで初歩的なものであり、すべてを網羅して

いるわけではありません。記載されているトピックに関して詳細に説明している既存の wiki の記

事、Technote、ホワイト・ペーパーなどがある場合は、参照先のリンクを掲載しています。

このwikiの使用法

この Redbooks wiki の各記事は、独立して使用できるようになっています。ただし、各記事の一

番上にある「目次」リンクをクリックすることにより、目次に戻ってシリーズ内のすべての記事にア

クセスすることができます。

0.2 執筆者について

本書は、世界各地から参加しているスペシャリストのチームによって作成されました。

Paul Band は、英国の IBM Software Services for Lotus の認定 IT スペシャリストです

。彼は、 初に R4.6 の Domino 開発に携わって以来、IBM で 10 年にわたって Lotus ソフトウェアを扱う仕事をしています。Paul はこれまで、お客様の問題のトラブルシュー

ティングからグローバルなエンタープライズ・コラボレーション環境の設計まで、数え切れ

ないほどのお客様に携わってきました。Paul は空き時間があると、ゴルフのスイングの

練習をしています。

Thomas Hampel は、IBM Germany に勤務する IT アーキテクトです。彼の主な重点

分野はマイグレーション・プロジェクト、パフォーマンス、および IBM のアウトソーシングを

利用するお客様向けのデリバリー・サービス・アーキテクチャーです。彼はバージョン 3 以来ずっと Lotus Domino に携わっており、8.5 までの各種バージョンにおいて IBM から認定された Lotus の上級開発者兼上級管理者です。また、彼は IBM 認定上級セキュ

リティ・プロフェッショナルでもあります。

Amy Hoerle は、Lotus Support Center のアドバイザリー・ソフトウェア・エンジニアで

す。彼女は IBM i オペレーティング・システムで実行される Lotus 製品に重点を置いて

おり、この分野に 10 年以上の経験があります。また、彼女は COMMON, A Users Group の年次会合で頻繁にプレゼンターを務めています。オフタイムには、子育てや

子供の学校でのボランティア活動、読書、ガーデニングなどをして過ごしています。

Gladstone Lang は、ブラジル、サンパウロ州の Hortolandia で ITD/SSO に勤務する IT スペシャリストです。彼は E メールおよびコラボレーション・サービス事業部門の顧客

担当部門で、Lotus 製品を扱う 1 人です。2004 年に IBM に入社するまでは、IBM Client and Training Center の 1 つに勤務していました。

Vladislav Tatarincev は、CYONE (www.cyone.eu) のテクニカル・ディレクター兼共同

所有者です。彼はラトビア大学でコンピューター・サイエンスの修士号を取得しています。

Domino にはリリース 4.5 から 10 年以上携わっています。彼は IBM 認定セキュリティ・

プロフェッショナルでもあります。Vladislav は、Domino 対応の多数のフリーウェア・ツー

ルの作者です。彼が Lotus Domino で主に重点を置いている分野は、パフォーマンス、

Traveler、セキュリティです。趣味は、ダイビング、シャーク・ダイビング、沈船ダイビング、

水中考古学、オートバイなどです。

Wei-Dong Zhu (Jackie) は、International Technical Support Organization のエンタ

ープライズ・コンテンツ管理プロジェクト・リーダーです。彼女は、C、C++、Java、および Lotus Notes スクリプトを使用した会計、イメージ・ワークフロー処理、デジタル・メディア

配信などのソフトウェア開発を 10 年以上経験しています。Jackie は、南カリフォルニア

大学でコンピューター・サイエンスの修士号を取得しています。IBM Content Manager の認定ソリューション・デザイナーであり、多くの ECM Redbook および Lotus Domino Redbooks wiki プロジェクトをリーダーとして管理してきました。

8

9

第 1 章 はじめに

1.1. 文書

何百ものデータベース、アプリケーション、サーバーのマイグレーションを必要とするプロジェクト

や新規のお客様にこれまで何回携わってきたでしょうか。 初は、すべてが、しかも必ず正確に

文書化されているだろうと考えます。しかし、プロジェクトの作業が始まると、既存の文書には必

要なことや期待していることが記載されていないことがわかってきます。この記事では、Lotus Domino 環境を適切に文書化する方法と、企業の規模に基づいてどのような文書を保持する必

要があるかについて説明します。この記事は、使用している環境や資産の文書化を開始する際

の貴重なリソースとなり、また、現在の文書の評価にも役立ちます。 始める前に、既存の文書に関して考慮するべき課題を次にいくつか示します。

• 文書はどこに保存していますか? 「すべて」の文書に定義済みの場所がありますか? • 誰か他人の環境を継承したことはありますか? その場合、この環境に関する文書は 新

であると言われていますか?

文書は現在または次の管理者や技術プロジェクト・マネージャーが環境をすばやく理解するの

に役立ちます。そして、適切に構成された 新の文書は環境の継続と成長にも役立ちます。

どのような文書を作成し、どのような情報を文書化するべきかについて考えてみましょう。

1.1.1.文書の内容

どうしたら良い文書になるでしょうか?どんな場合でも、サーバーとホスト名の数を一覧するだ

けでは決して十分とは言えません。 十分に文書化された環境であれば、効率的に問題を特定でき、チケットをより早く解決して、

そのボトルネックを容易に見つけ出すことができます。 次の表は、文書の一部とするべき情報の種類、およびその文書タイプに 適なインプリメンテーション・サイズを示したものです。

文書の内容 小規模 中規模 大規模

サーバーの詳細 + +++ +++

アーキテクチャーの概要 + ++ +++

命名規則 (+) ++ +++

エンド・ユーザーに対する指示 (+) ++ +++

10

1.1.2.サーバーの 詳細

初の基本的な文書とは、サーバーの設定を記述したものです。Domino Directory はサー

バー設定のオンライン文書として誤解されることがよくあります。Domino Directory は、はるか

に詳しい文書です。例えば環境に不慣れなユーザーは、Domino Directory によってビルディン

グ・ブロックを理解することができます。

サーバー設定は、不整合などの落とし穴を、それらが問題となる前に明らかにすることができ

るため、アップグレード・プロジェクトには不可欠です。

使用している環境の論理 Lotus Domino サーバーごとに、以下のような (ただし、これらに限

定されない) 設定要素を詳しく記述する必要があります。

• サーバー名と IP アドレス • ハードウェアやオペレーティング・システムなどのプラットフォームの詳細 • フィックス・パックやホット・フィックスがインストールされている Lotus Domino のバージョン • その他の Lotus 製品 (その製品名、バージョン、パッチ・レベル) • 3 インストールされたサード・パーティー・ソフトウェア (ライセンスの詳細、インストール

の指示に関する情報、およびインストール・パッケージにアクセスする方法)

文書のこの部分については、サーバー名を 1 次キーとして使用することをお勧めします。例え

ば、現在のサーバー設定の詳細を追跡するサーバーごとに 1 つの文書を作成するなどです。

これによって、作成された文書は文書の他の部分で参照できるようになります。

Notes アプリケーションがこの種の情報に 適な選択であるのはこのためです。情

報の相互参照には文書のリンクを使用できます。

1.1.3.アーキテクチャーの概要

アーキテクチャー概要図は、サーバー、クラスター、およびそれらの相互接続の概要を図形

で示したものです。Lotus Domino サーバー、およびメールや SMTP 接続の複製といったそ

れらの論理通信パス方法を中心としています。

アーキテクチャー概要図の主な目的は、管理者が作業する環境の概要をシンプルかつ簡潔に、

わかりやすく伝えることです。 • この図は環境の一覧であり、1 枚の用紙よりもはるかに大きくなる可能性があります。

図には、以下を含める必要があります。

• Lotus Domino Server とそれらの名前、主な用途タイプ、およびクラスター・メン

バーシップ (該当する場合) • メール配信の接続 • 複製パス

「Pull のみ」などの一方向接続については、矢印を使用してデータ・フローの方向を示します。

• インバウンド/アウトバウンド SMTP 接続 • ODBC などのサード・パーティー送受信接続やその他のタイプの送受信接続 • Domino が通信する主要な非 Domino システム

11

アーキテクチャー概要図を作成するときの注意事項は以下のとおりです。

• 同じ図面に情報を詰め込めすぎないようにします。 この段階では細部まで詳しくというので

はなく概念を理解することが重要です。Domino レベルに焦点を当て、ハードウェアやオペ

レーティング・システム、パッチ・レベルなどの詳細は無視します。 • 省略語は、凡例などで説明しない限り使用しません。この概要の作成時には、他人が簡単

に理解できることを確認します。特に複雑な環境については、この概要を作成した本人でも

細部をすべて覚えていない可能性があるため、このわかり易さが文書化を成功させる重要

な要素です。 • アプリケーション開発チームと協業してサード・パーティーの接続を把握します。 管理者は

開発者がこれまでに何を行ったを知らない可能性はかなりあります。インフラストラクチャー

に変更を適用した場合に問題が発生しないよう、これらの相互接続を十分に把握すること

が不可欠です。 • 接続タイプごとに別の色を使うなどして、接続のタイプを説明するようにします。 図面内に

は詳細に関する凡例を含めます。 この凡例の例を次に示します。

インフラストラクチャーの変更ができるだけ早く図面に反映されるようにして、概要を常に更新し

ておきます。文書をインプリメンテーション変更の一部として更新することが 適な方法です。

アーキテクチャー概要図を作成するツールと方法

図面はいずれのベクター指向のグラフィック・ソフトウェアでも作成できます。CAD ソフトウェア

や単純なビットマップ指向のグラフィック・ソフトウェアでも可能です。市販のソフトウェア製品か

らフリーウェアのアプリケーションまで、市場には各種さまざまなソフトウェア製品が出回ってい

ます。どの製品を選択するかは利用者にかかっています。必ずその用途を理解し、ライセンス

の詳細に満足できるようにしてください。

以下に、無償アプリケーションの例を示します。

• Dia • yED

ソフトウェアを選択したら、次の方法で図面を作成します。

1. Lotus Domino ドメインの概要を作成し、これらの接続方法を要約します。この 初の

手順については、ドメインは雲の形のアイコンなどで表現できます。

各ドメインの複製トポロジーを調べることで、ドメイン内の複製トポロジーをレビューします。こ

の情報は、以下の画像に示すとおり「複製\複製トポロジー」タブ内の Lotus Domino Administrator クライアントから取得できます。

図 1

注:Domino Administrator クライアントは、この情報をマップ・タスクを実行している Domino サーバーから取得します。 このタスクは、Domino サーバー上では自動的に起

動しません。マップ・タスクを有効にする方法について詳しくは、『Lotus Domino Administrator ヘルプ』を参照してください (developerWorks / Lotus Domino

documentation)。

• 各ドメインの管理サーバーを追加し、複製パスを進めます。 このプロセスの 後に、ドメインのサーバーがすべて追加されたことを確認します。

例

次の例は、単純なアーキテクチャー概要図がどのようになるかを示したものです。

図 2

12

13

標準

大規模な組織では特に、企業全体に適用される標準を説明することが重要です。これらの標準

は、環境の一つ一つ細かいところに適用でき、例えばオペレーティング・システムの標準などは、

社内の他者によって既に定義されていることもあります。規定がない場合であっても、簡潔なが

ら効率的なソフトウェア標準を定義して、共通の目標に向かって同僚とともに取り組む機会を作

ることをお勧めします。

ハードウェア標準 ハードウェアの種類とサイズ、およびその用途を文書化することから始めます。

Domino の視点から、まずサーバーのクラスを定義します。ここでは、登録されているユー

ザーまたはユーザー・アクセス、ロケーション・サイズ、サーバーのメイン・タスクなどに従っ

てサーバーの利便性を優先させます。

例えば企業 A では、設計者が以下を定義しています。

• 小規模なサーバーでは、小規模なロケーションに対して 150 人以下のユーザーまたはホス

ト・アプリケーションとする ( 大ユーザー数は 150 人)。 • 中間サーバーは管理/アプリケーション・ハブとして機能でき、登録済みユーザーまたはホ

スト・アプリケーションが 1000 以下とする (同時ユーザー数は 1000 人以下)。 • 大規模なサーバーの登録ユーザーまたはホスト・アプリケーションは 3000 人以下とする

(同時ユーザー数は 3000 人以下とする)。 これらはインフラストラクチャー・サーバー (中央 SMTP ゲートウェイなど) のパフォーマンス向上にも効果があります。

次の段階では、上記のサーバー・クラスごとに以下を定義します。

• サーバー・パラメーター:ここでは、サーバーの設定をどのようにするか、CPU の種類と量、

サーバーのメモリーはどのくらいにするかなど、サーバー・クラスのベースを定義します。 • ハード・ディスクのレイアウト:ここでは、サーバーのハード・ディスクをどのように構成されて

いるか、または構成すべきか、オペレーティング・システムをインストールする場所、バイナ

リを置く場所、およびデータが設定される場所を定義します。 また、各種サーバー・クラスに

従って使用する、または使用しているディスクの種類も定義する必要があります。

ベンダーはサーバー・ハードウェア・モジュールを頻繁に変更するため注意してください。より

強力な新規サーバーが提供され、古いサーバーが使用できなくなることもあります。そのため、

新しい Domino 管理者にとって、または Domino そのものに不慣れなユーザーに関しては、

ハードウェア標準は大まかなガイダンスと見なす必要があります。ハードウェア標準は 1 年単

位で更新し、小規模な調整について積極的にアイデア (例えばより強力な CPU が利用できる

ようになったならばそれを使用するなど) を出し合うようにします。 注:Domino はかなり I/O を集中的に使用するアプリケーションです。 サーバー・モデル

の選択時には、 適なパフォーマンスを得るために、 善の I/O スループットを持つシス

テムを選択してください。

14

ソフトウェア標準 ソフトウェア標準は環境の文書化において重要な部分です。各サーバー・クラスに従って

何をサーバー・オペレーティング・システムにするかを決定します。この場合もやはり、

サーバー・クラスを正しく決定すると、その後のすべてのことが容易になることがわかりま

す。

以下は、文書化に役立つ推奨ソフトウェア標準を示したものです。

• オペレーティング・システム (OS):製品の要件に従って、OS バージョンは何にするか、

どのサービス・パックをインストールする必要があるかを決定します。 • ウィルス対策ソフトウェア:ウィルス対策ソフトウェアの場合、OS 用のウィルス対策ソフト

ウェアと Lotus Domino 用のウィルス対策ソフトウェアを区別する必要があります。 • OS レベルのウィルス対策ソフトウェア:ソフトウェアのバージョン、適用したパッチ・レベ

ル、ウィルス・パターン・ファイルの更新方法 (更新の頻度)、および OS のウィルス対策ソフトウェアで無視するファイルも記述します。

• Lotus Domino レベルのウィルス対策ソフトウェア:ソフトウェアのバージョン、適用したパッ

チ・レベル、ウィルス・パターン・ファイルの更新方法 (更新の頻度) を記述します。 • Lotus Domino サーバー:Lotus Domino Server のバージョンとそれぞれのサブソフトウェ

ア要件に従って適用したフィックスパックを記述します。どの製品にも、推奨される Lotus Domino Server バージョンがあり、指定のフィックスパックを適用しておくことは、非常に重

要です。同様に、Lotus Domino Server のバイナリ・フォルダーとデータ・フォルダーの命名

規則を記載します。 • バックアップ・ソフトウェア:これは難しい領域です。大企業では多くの場合、Domino 管理

者とバックアップ管理者が協力して作業しているとは限りません。適切なバックアップ標準

を設け、ポリシーを適切に定義することは、どの環境においても非常に重要です。 • Domino サーバーのバックアップ・ツールおよびポリシー:対象範囲と Domino サーバー

のバックアップを行うとき (日次、週次、月次) と、種類 (差分、完全、トランザクション・ロ

グ・アーカイビングを使用するかどうか) を記述します。 • OS バックアップ・ツールとポリシー:対象範囲と OS バックアップを行うとき (日次、週次、

月次)とそれぞれの種類 (差分、完全) を記述します。 • 特殊なバックアップ:Lotus Domino Serverバックアップに関して、長い保有期間や特殊

な作業を必要とするなど、企業で何らかの取り決めがある場合は、ここに記載する必

要があります。 • 環境の監視:環境をどのように監視するのかについて記述します (使用するツール、OS

レベルと Lotus Domino Server レベルのどちらで監視するのかなど)。 • サーバー・レポート:オペレーティング・システム固有のデータのレポートと、Domino 固有

のデータのレポートを区別する必要があります。この資料では、Domino 関連のレポート

のみを対象とします。 • OS 設定:すべての Domino サーバーで必須の OS 設定を記載します。安定したセキュア

な環境をサポートし、サポート労力を 小化するには、こうした必須の設定が必要です。

OS のどの設定をどのように指定するか (ドライブ文字、ボリューム名、Windows 更新プログ

ラムを自動で行うかどうか、ネットワーク・カードの命名規則、OS チューニングのレジスト

リー・キーなど) を記述します。

• ドライブのインデックス作成:(各ドライブの) Lotus 推奨事項によりオプションをオフにしてい

る場合や、コントロール・パネルで (すべてのディスク・ドライブを対象とする) サービスをオフにしている場合。

15

• システム・ページ・ファイル:システムのファイル・ページがどのように設定されているかを

記載します。 • 時間設定:すべての Domino サーバー間で円滑なメール転送および複製が行われるよう

にするには、サーバーが正しい時刻に設定されていることが重要です。 • タイム・ゾーン:オペレーティング・システムのタイム・ゾーンはサーバーの物理的な場所に

従って正しい値に設定されている必要があります。さらに「自動的に夏時間の調整をする」

設定を有効に設定し、Domino サーバーが OS のタイム・ゾーン設定を使用するように指

定する必要があります。 • 地域の設定:Windows OS 環境で作業する際は、サーバーの地域の設定をどのよう

に指定するかを記述します。

小規模な環境の場合は、すべての情報を記述しなくてもかまいません。複数の管理者がいて、

チームが異なるタイム・ゾーンで作業しているような大規模かつ成長過程にある環境では、共通

設定を示すことには明らかに利点があります。

1.1.4.セキュリティ標準

文書化において重要な要素のひとつが、環境内のセキュリティ標準の記述です。 この情報は災害時に必要不可欠となるだけでなく、何が許可されていて、何が禁止されてい

るのかをはっきりさせる役割もあります。

• 各種役割と、各役割の制限事項を記述します。

例: ユーザー管理者、データベース管理者、アプリケーション開発者 • サーバーのセキュリティ・タブをどのように設定する必要があるかなど、サーバーで定義

されているアクセス・レベル。 この内容の一部は命名規則に記載されているため、ここでは命名方法よりも概念に重点を置く必要があります。

• 企業ポリシーとして定義された、環境内の制限事項とアクセス許可 エージェントを実行できるのは誰か、アプリケーションの署名できるのは誰か、ライブラリーのスクリプトを作成できるのは誰かなどを考えます。この作業を実行するために定義された特定の役割はありますか?

• ユーザー ID およびパスワードの処理方法、格納場所、担当 (役割)。 • アクセス拒否グループの処理方法 • 主要システムのバックアップ・コピー (cert.id、server.id、administrator id など) ファイル

の場所、緊急時にそれらにアクセスできるユーザー

上記に記載した考慮事項がすべてではない点にご注意ください。環境に応じて、その他の要素

が必要になる場合もあるため、資料のこの章は定期的に更新するようにしてください。

1.1.5.バックアップ標準

資料には、環境をバックアップする方法やユーザーがリストアできるものなどについての説明

も含める必要があります。これには、以下を含める必要があります。

• バックアップをどれぐらいの期間保持するかについての企業のルールを示したバックアップ・

ポリシー • "What"、どのような情報をどれぐらいの頻度でバックアップするかについて説明します。こ

こでは、オペレーティング・システムなどその他の要素よりも Domino のデータに重点を置く必要があります。

• "When"、バックアップ・ジョブがいつ開始されるのか、また、バックアップ期間はいつまでか

を示します。 • "Where"、1 台のサーバーがすべてのサーバーのデータをバックアップするなど、バックアッ

プ概念においてどのサーバーがどの役割を果たすのかを説明します。

16

• "How"、使用するバックアップ・ソフトウェアが何か、それがどこにインストールされているか

を説明します。 • リストア・プロセスとリストアが利用できるようになるまでにかかる推定時間を詳述します。

Domino のバックアップ概念の詳細については、『Backup a Lotus Domino Environment』の章

を参照してください。

1.1.6.命名規則

命名規則があると、環境を新しく使い始めた人々でも要素の拡張または変更をしながら一貫性

を維持する方法を理解できます。以下の一覧は、命名規則が適用される Lotus Domino 環境

の構成の詳細を示しています。

• サーバー名

例えば、いつどのような種類のサーバー名を使用するかを定義します。 前の例では、企業 B は CCNNNNXXX という名前を使用していました。CC は ISO の国

コード、NNNN はサーバーの種類 (MAIL、HUB、APPL など)、XXX は種類ごとの連続し

たサーバー番号を表しています。 • ドメイン名。 • クラスター名。 • Domino で名前を付けたネットワーク。 • アクセス制御リスト。 • ディレクトリー名。

例えば、Domino サーバーのディレクトリー構造と、どの種類のアプリケーションをどこに格納するかについて説明します。 注：システム・データベース、ユーザーの Mail データベース、メール受信データベース、およびアプリケーション・データベースのサーバー・ディレクトリー (フォルダー) 名に関する企業標準について記載する必要があります。

• ファイル名。 例えば、重複しないファイル命名方法について定義します。 Domino 側でのファイル命名規則として企業が使用している命名規則を記述します。対象

とする命名規則には、ユーザーのメール・データベース、共通の Domino アプリケーショ

ン・データベース、デフォルト・テンプレートに基づく Domino アプリケーションなどがありま

す。 • グループ名。

Domino 環境で使用されるグループに対して企業で使用される命名規則を記述します。 Domino の標準に従ってグループを定義するようにします。多目的用、アクセス制御リスト

専用、メール専用、サーバー専用、および拒否リスト専用のグループにします。 また、使用できる文字と使用できない文字を明確に定義します。

• 部屋とリソース。 詳細については、Technote 1251010 を参照してください。

• ユーザー名。 ユーザー名の命名規則に対して企業で使用される命名規則を記述します。環境で使用されているものすべてを含めます。例えば、 姓、名前、氏名、省略形、インターネット・アドレス、その他企業で使用されているユーザーに関連する重要なフィールド 例:使用できる文字、ミドル・イニシャルをいつどのように使用するかなど。

• 電子メール・アドレス。 例えば、ユーザーが任意のアドレスを選択できる場合や、組織内で制限がある場合に、電子メール・アドレスをどのように決定するか。

17

• エージェント署名者名 エージェントの署名または実行に特定の ID を使用する場合、それに使用する構文について説明します。

注:上記に示した各項目には IBM Lotus によって定義された制限事項があります。詳しく

は、Technote 1091216 を参照してください。

アクセス制御リスト

資料のこの部分には、データベースのアクセス制御リスト (ACL) に関する情報を含めます。

ACL はデータベース所有者が個人やグループの Notes データベースに対する権利を決定す

るための柔軟性のあるメカニズムを提供します。データベースのバージョン (レプリカ) で指定さ

れた ACL を各サーバーが適用するという点では、データベースの ACL はサーバー固有です。 ACL の記述では、企業のデフォルト・テンプレート ACL がどのように設定されているか、また、

システム・データベースの ACL がどのように設定されているかについて説明します。 こうした情報により、標準化レベルを改善し、監視される環境を調整することができます。 ACL の設定について説明するにあたり、記載方法として以下の提案事項を参考にしてください。

• 基本的な ACL のルールを定義します。例えば、すべてのアプリケーションに存在

する必要がある ACL エントリーまたはすべてのメール・ファイルに存在する必要がある ACL エントリーを定義します。 これは、すべてのデータベース ACL に含める必要があるすべてのグループおよび ID にすることができます。通常これらは、IT 管理者に関連するグループや、Domino 管理プロセス・サーバー、サーバー・バックアップなどの管理サーバー・グループです。

• 調査中のデータベース。ほとんどの企業では、法務部門が何らかの訴訟プロセスの一環として任意のデータベースへのアクセスを求める場合があります。 このシナリオで標準を作成および文書化します。

• ご使用の環境における Domino System データベースの ACL の外観を定義します。 以下のシステム・データベースからそのアクセス権と役割を持つすべての ACL エントリーを組み込みます。 names.nsf、admin4.nsf、catalog.nsf、log.nsf、certlog.nsf、events4.nsf、ddm.nsf、domlog.nsf、domcfg.nsf、busytime.nsf / clubusy.nsf、report.nsf、statrep.nsf、mail.box / mailX.box (X は、1 から n の番号を表します。この番号は 構 成 文 書 に 設 定 さ れ て い る mail.box の 量 に よ っ て 異 な り ま す ) 、 statmail.nsf 、mtstore.nsf、および da-CC.nsf (CC は、企業の国コードまたはサイト・コードで使用され

る命名規則を表します)。

文書の命名規則に使用されるフォーマット

文書の命名規則に使用するフォーマットは、いずれのフォーマットでも問題ありませんが、文

書の当該部分は全員が使用できるようにすることが重要になります。その部分は、単純で容

易にアクセスできるようにして、バージョン管理する必要があります。

それを実現するために、いつくかのオプションがあります。以下に一部の例を示します。

• Notes アプリケーションに保存します (例えば、すべてのユーザーが読者アクセス権を持つ

ディスカッション・データベースなど)。 • ファイルベースの文書 (PDF など) を作成して、それを Lotus Quickr やその他の既存

の文書管理システムに保存します。

18

• 社内 Web ページ。ここで、ユーザーは Web ブラウザーを使用して情報にアクセスでき

ます。

別の方法もあります。お好みの方法を使用してください。繰り返しになりますが、文書

を必要とするすべてのユーザーが結果にアクセスできるようにしてください。

命名規則を記述する際は、以下の推奨事項に留意してください。

• Domino を小規模に実装する場合、サーバーおよびドメインの数は比較的一定であるた

め、命名規則を定義する必要性はほとんどありません。ただし、将来大きくする場合に備

えて、命名規則の一部を定義しておくと役立つ場合があります。 • 大規模な Domino 環境内では、企業の命名規則が定義されているか、管理者のチームで

正確なルールまたは制限を示すように定義する必要があります。そのため、命名規則には

前述のすべての要素を含める必要があります。 • 特に、大規模な環境では、ユーザー同士で特定の命名規則が定義された理由を質問でき

るディスカッション・フォーラムを提供して、ユーザーや IT 担当者が命名規則を改善できる

ようにしてください。回答は他のユーザーからもアクセスできるようにしておき、ユーザーか

ら変更提案も公平に対処してください。

1.1.7.エンド・ ユーザーに 対する 指示

ヘルプ・デスク・チケットおよびサービス要求の数を削減するために、エンド・ユーザーごとに完

全に異なる種類の文書を提供する必要があります。ほとんどのユーザーは、詳細なサーバー

の構成やその複製パスについて知る必要はありません。その代わりに、標準的な要求を効率

的に管理する方法に関するガイダンスを求めています。通常、エンド・ユーザーが求めるもの

は、「新しいユーザー ID 要求をリセットする方法」や「パスワードをリセットする方法」などの一

般的な処理の説明です。

そのような処理は無限にあります。サポート・スタッフが同じ質問に何度も回答しなくてもよいよ

うに、無駄な時間を削減するよう常に心がけてください。

文書の当該部分は、組織の新参者が 初に参照するものの 1 つであることを考慮に入れてく

ださい。その目的は、自己サポート・プラットフォームやエンド・ユーザーのガイダンスの形式に

使用することです。

• 処理の説明 • 「仮想」シナリオ • 背景情報および相互参照 (命名規則など) • ヘルプ・デスクの電話番号

また、以下の推奨事項にも留意してください。

• 第 1 段階のヘルプ・デスク情報も含めます (チケットの入手経路やセルフ・サービス・ポー

タルへの到達方法など)。 • エンド・ユーザーへの指示と研修資料とを混在させないでください。Lotus Notes の初心者

用の優良な参考資料は他にもあります。独自の研修資料を作成する必要はありません。 詳細については、以下を参照してください。

• Lotus Education • Multimedia Library for Lotus® Software

19

• 使用する言語を定義します。 企業および地域の配布によっては、すべてのユーザーが英語を理解しているとは限りません。言語は、(管理者が使用したいものではではなく) ユーザーが もよく理解できるものを定義します。

• 必要に応じて、文書の当該部分を拡張します。 特定の領域で質問や要求の量が増加した場合、必要に応じて、その説明および相互参照を追加します。

• 新しい処理の概要についてやり取りするために、ユーザーに大量のメールを送付しないでく

ださい。 その代わりに、文書の当該部分に処理の説明を置き、個々のエントリーへのリンクを送信してユーザーに参照させます。

エンド・ユーザーへの説明の記述に使用するフォーマット

情報を提供するにはさまざまな方法がありますが、すべての方法が必要な機能を提供している

わけではありません。

• 単純なアクセス。

例えば、Web ブラウザーや Lotus Notes クライアントを介したアクセスなど • より広範なユーザーに配信可能であること。 • 問題が発生してもアクセス可能であること。例えば、ユーザーのデスクトップへのローカル

保存など。

推奨できる方法の 1 つは、ヘルプ・テンプレートに基づいて新しい Lotus Domino アプリ

ケーションをセットアップすることです。Technote 1164526 にその方法が示されてい

ます。

処理の説明は変更される場合があるので注意してください。特に、大規模な組織では、国、地

域、事業単位、または部門間などでも処理が異なるため、カテゴリー化は容易ではありません。

1.1.8. 結論

適に文書化されている環境では、いかなるインフラストラクチャーの変更や緊急事態が発生

しても、より効率的かつ専門的に対処することができます。文書は固定ではないということを理

解することが重要です。文書は環境と共に存続し、その価値を保つために定期的に更新する

必要があります。

1.2. 日次、週次、および月次チェックリスト

一般的に Lotus 製品は円滑に稼働します。継続的に円滑な稼働を保証するために、管理者は

問題発生時にそれを分析できる適切なツールのセットを用意しておく必要があります。この記事

では、管理者が効率性の向上およびシステムの 適化のために実行できる考慮事項および推

奨事項について説明します。

1.2.1.一般的な 推奨事項

一般的な推奨事項として、管理者は常に Domino の領域の 新情報を取得し、システム・パ

フォーマンスを分析する方法を理解して、サーバーがクラッシュしたときにトラブルシューティン

グできるようにしておく必要があります。

知識 非常に基本的な要素の 1 つは、環境の機能について理解すること、バグや問題について理

解すること、およびシステム機能を向上させるための実用的な方法を理解することです。環境

を 適化するには、継続的な改善と斬新なアイティアが必要です。ただし、斬新なアイデアは

必ずしも書物に書き下ろされているわけではありません。そのため、常に 新情報を追跡して

ください。管理者が 新情報の追跡するのに役立ついくつかのヒントを以下に示します。

• IBM サポート・ポータル内の「My Notifications」に登録します。

「My Notifications」により、電子メール、カスタム Web ページ、および RSS フィードを介して、毎日または毎週通知を受信できます。これらのカスタマイズ可能な通信では、出版物、ヒント、技術注記、製品フラッシュ (警告)、ダウンロード、ドライバーなどの重要なニュース、新規または更新されたサポート・コンテンツを含めることができます。ツールを使用すると、サポートのニーズに合わせて、注目する製品や使用可能な配信方法をカスタマイズしたりカテゴリー化することができます。IBM Software Support / Subscribe to My Notifications support content upgrade

図 3

早期の頃から Lotus Domino 管理者は相互に協力し合って、 情報、ベスト・プラクティス、ヒントなどを交換していました。重要な要素の 1 つは、コミュニティー

と知識を共有するということです。そのため、 大の情報源はコミュニティーそのものになります。

このような貴重な情報は以下のように利用します。

• IBM Developerworks Lotus Community に登録して、Lotus ソフトウェア製品や開

発者の戦略に関する情報を閲覧します。 Lotus ソフトウェアに注目している IBM の従業員から Lotus Blogs が提供されています。developerWorks / Community & forums

• 製品のディスカッション・フォーラムに積極的に参加してください。 躊躇なく質問して、他のユーザーからの質問に気兼ねなく回答してください。 developerWorks / Community & forums

• Domino コミュニティーに投稿されたブログを閲覧します。 下記のサイトは、さまざまな Lotus コミュニティーからブログの投稿を統合しているため、

20

21

取りかかりには 適です。Lotus Notes クライアントに組み込まれている RSS フィード・リーダーを使用すると、 新情報を追跡できます。 PLANET LOTUS

• コミュニティー・ミーティングやラウンド・テーブルに参加して、地域の他の Domino 管理者と連絡を取ります。

• Lotus 製品の経験に関するブログやポストを設定します。自身のブログを以下のサイトに

登録して、コミュニティーでフィードバックの提供を促進します。 PLANET LOTUS

パフォーマンス パフォーマンス関連の問題を解決することは、単純なタスクではありません。通常、この種の問

題はすぐに表面化するものではありません。多くの場合、時間の経過と共に進展する現象にな

ります。そのため、パフォーマンス分析では Lotus Domino エコシステムの外部に潜在する可

能性のある根本的な原因についても考慮する必要があります。 さまざまなツールや手法は、注目するさまざまなプラットフォームや領域に適用できます。IBM では、パフォーマンスのベスト・プラクティスに関する詳細な記事を提供しています。プラット

フォームで必要なツールの情報を取得するには、以下を参照してください。

• Technote 7008849

サーバー・クラッシュ分析 サーバー・クラッシュのトラブルシューティングを行う際に、以下のツールを使用できます。そ

れぞれの機能や使用方法をよく理解してください。

• サーバーとクライアントの問題を分析するには、クラッシュの発生時に Lotus で作成され

た NSD ファイルを詳細に調べる必要がある場合があります。デフォルトでは、それらの

ファイルはクライアントまたはサーバーの Data ディレクトリー内に保存されます。管理者

は自動診断データベースをセットアップして、中央のデータベースで NSD ファイルを収集

できます。そうすることで、それらのファイルに即座にアクセスしやすくなります。 詳しくは、

以下を参照してください。 • Technote 1085850 に、この自動診断データベースの設定方法が説明されています。 • Technote 1272213 から、このユーティリティーの 新バージョンを入手できます。 • IBM Support Assistant は、IBM のさまざまなソフトウェア製品に関する問題の回答や

解決法を検索できるデスクトップ・ソフトウェアです。これは、Domino だけでなく、さまざまな IBM 製品をサポートしています。

• Lotus Notes Diagnostic (Technote 4019151 参照) は、NSD ファイルの分析、既知の

問題の検索、および問題に対して考えられる解決案の収集が可能な Lotus Notes アプ

リケーションです。 1.2.2. アクション

管理者がスムーズな Domino 操作を維持し、サーバーの安定性、パフォーマンス、およ

びセキュリティを 適化できるように、日次、週次、および月次のさまざまなタスクを実行

することをお勧めします。 このセクションで以下に概要を示しているアクションは、一般的なベスト・プラクティスを表してい

ますが、通常はスケジュールに従って実行される圧縮タスクや修復タスクなどの保守管理アク

ティビティーは含まれていません。Domino 環境を正常に保つために管理者が実行する必要

があることに焦点を合わせています。

22

個々のアクションは環境によって異なるため、これは一体化された完全なリストではありません。

説明されているアクションを実行したときに、予測したとおりの結果ではなかった場合、未検出

の問題がある可能性があるため、管理者はさらに調査する必要があります。一方、すべてのア

クションが、深刻な対応や緊急の対応を必要としているわけではありません。このため、詳細を

調査しない場合は、少なくとも異常な内容を、イベントが発生した日時にコメントまたは説明を付

けて、文書化することを強くお勧めします。 アクションは自動化でき、既存のモニター・ソリューションに組み込むことさえできます。この場

合、タスクは、「機能の確認」を行うタスクと見なされます。 時間は貴重であり、効率性について理解するために、管理者は再発しているアクションとアク

ティビティー、およびその実行にかかっている時間を文書化することをお勧めします。一定期

間後、報告された時間を確認して、例えば、小さな複数のタスクが管理者の時間を取っている

場面を特定する必要があります。そのうえで、環境を 適化するために、そのようなタスクま

たはアクションを何らかの方法で自動化できないかを評価します。

日次アクション 次のリストは、サーバーのランタイム、パフォーマンス、およびセキュリティを 適化する

ために管理者が実行する必要のある日次アクションを示しています。

• Domino ドメイン・モニター・データベース (DDM) で報告された問題の確認と解決。

示される問題のタイプと数は、使用している DDM 構成によって異なります。 • サーバー・クラッシュがあったかどうかの確認。

問題がある場合は、前述の一般的な推奨事項のセクションで示しているツールを使用して NSD ファイルを分析することによって、根本的原因を見つけます。

• 使用可能なディスク空き容量の確認。 この日次確認は、適切に構成された Domino ドメイン・モニター・データベース (DDM) にイ

ベントを作成することによって、自動化できます。 • 日次バックアップ・ジョブが正常に実行されたことの確認。

このアクションを実行する方法は、現在の環境で使用しているバックアップ・ソフトウェアによって異なります。バックアップ・ソフトウェアのすべてのベンダーが、管理者が確認できるログ・ファイルを提供しています。ベンダーによっては、メールなどの通知方法を使用して、成功と失敗の報告を受けることができます。

• ウィルス対策ソフトウェアが正常に実行されているかどうか、およびパターンが 新であるか

どうかの確認。 この確認アクションに、オペレーティング・システムのウィルス対策ソフトウェアも含めることを忘れないでください。オペレーティング・システムのウィルス対策ソフトウェアは、Domino サーバーのウィルス対策ソフトウェアと同じだけ重要なためです。

• サーバーの複製ログを確認することによる複製の問題のチェック。 このアクションにかかる時間は、DDM に失敗のみを報告する DDM 複製エラー・モニターを設定することによって、 小限に抑えることができます。

• メール配信キューの確認によるメール配信のモニター。 • サーバー上の主な統計値の確認および数日前の値との比較。

1 分間当たりの 多トランザクション数の場合、この機能は基になるハードウェアに依存しているため、固定制限値は指定できません。時間の経過とともに、ワークロードが問題になる状況を把握し、ワークロードのバランスを取る方法がわかるようになります。

日次確認の場合は、以下の統計に焦点を合わせます。

• Server.trans.PerMinute.peak (1 分間あたりの 多サーバー・トランザクション) • Replica.cluster.WorkQueueDepth.avg (クラスター内複製ワーク・キュー長さ平均) • Replica.cluster.WorkQueueDepth.Max (クラスター内複製ワーク・キュー 大長)

23

注:リストは完全でない場合があります。使用している環境によっては、これらのアクション以外

のアクションを適用する場合や、これらのアクションのうち適用しないものがある場合があります。

例えば、管理者によるアクションの個別管理が必要になるサード・パーティー製ツール、または

管理者が前述のタスクの一部を自動的に実行できるようにするサード・パーティー製ツールを使

用する場合などです。

週次アクション 日次アクションに加えて、管理者は、以下の週次アクションを実行する必要があります。前週

の確認をするために、週の初めに実行することをお勧めします。

• 管理要求データベースのモニター (Admin4.nsf)。

「日付別エラー (Errors by Date)」ビューおよび「承認要求 (Individual approval required)」ビューを確認して、適切な措置を施します。

• Domino サーバーの統計と統計の傾向の確認。特に、ワークロード 大値を検索して、それらの値を文書化します。 ログ・ファイルの詳細な確認で説明のつかない 大値が見つかった場合は、処置を施し、環境内でワークロードのバランスを取るためのオプションを検討します。 詳しくは、Technote 7009310 を参照してください。

• サーバーのクリーンアップ、およびサーバーでは不要になった復元 NSF ファイルの削除。 通常、復元ファイルは、例えば 7 日間など、一定期間のみ保持する必要があり、この期間が経った後は、復元ファイルをディスクから削除できます。

繰り返しますが、環境によっては、追加アクションが適用される場合があります。

月次アクション 週次アクションに加えて、管理者は以下のアクションを月次で実行する必要があります。

• Domino サーバーのメモリー使用量のモニター、およびパフォーマンス上の問題を回避す

るために Domino サーバーに十分なメモリーを割り当てる措置の実行。必要なメモリー

総量は、Domino サーバーだけではなく、それ以外の要素によっても異なります。別にメ

モリーを消費するオペレーティング・システム・レベルのサード・パーティー製ツールも考

慮に入れる必要があります。 • 環境に影響を与える新規リリースまたはパッチの確認。

前述の「一般的な推奨事項」で説明したメーリング・リストに登録します。 • インフラストラクチャーに変更が適用された場合の、現在の環境を反映するための文書の

更新。 • 環境内のすべてのサーバーに対する Lotus Domino Configuration Tuner の実行およ

び DCT からの推奨事項の確認。 • Certlog.nsf に期限切れの証明書および ID ファイルがないかどうかの確認。

必要に応じて、Technote 1326765 に説明されている証明書更新プロセスを開始します。 • フラグメント化されたディスクによってサーバー・パフォーマンスが低下する可能性が

あるため、サーバー・ディスクのフラグメント化の確認。 注:サーバーでデフラグ・ツールを実行できますが、データの損傷を避けるため、Lotus Domino を停止する必要があります。 詳しくは、Technote 1464021 を参照してください。

• 前月にレポートされた問題がある場合は、その確認。問題を徹底的に調査し、根本的な原因

を見つけて解決します。

24

• Domino Web サーバーの場合、Web サーバー要求のモニター。 Domino HTTP ログを使用して作業する場合、以下の Technote が役に立つことがあります。

• Technote 1161104 – How to reduce the size of Domino Web Server Log (domlog.nsf)

前述のとおり、リストは完全でない場合があります。使用しているインフラストラクチャーに

よって、フォーカスが異なり、他のアクションが適用される場合があります。

年次アクション 月次アクションに加えて、管理者は以下のアクションを毎四半期、または毎年実行する必要が

あります。

• 有効な復旧データを確保するための、テープ・バックアップ復元テストの実行。

バックアップ・ログの確認とエラーに対する処置だけではありません。例えば、何らかの理由でバックアップ・メディアが破損したり空であるために実行できない復元ほど始末の悪いことはありません。毎四半期や毎年など、時折サーバー全体を復元することによって、バックアップを確認する必要があります。 実稼働環境に対する影響を避けるために、復元を分離サーバーで実行することができます。

• 文書の更新。 インフラストラクチャーに変更が適用された場合は常に、または少なくともわずかに遅れるだけで、文書を更新することをお勧めします。重要な部分が正常であることを確認するために、毎四半期または毎年の更新をお勧めします。 環境の規模が大きければ大きいほど、管理者はこのタスクをより頻繁にスケジュールする必要があります。

• 使用している環境におけるサーバーの正常性の確認。 このトピックについて詳しくは、Technote 1432995 の IBM OpenMic Call 「Lotus Domino サーバーの正常性確認」を参照してください。

1.2.3. 結論

この記事では、日次、週次、月次、毎四半期、および年次で実行する必要のある一連のアク

ションについて説明しました。これらは、アクションの完全なリストではありません。使用してい

る特定の環境に応じて、定期的に実行するアクションの独自のリストを用意し、Domino がス

ムーズに動作して、システム・パフォーマンスが 適化されるようにしてください。

1.3. セキュリティ・チェックリスト

80 ～ 90% の脅威が現在の従業員または元従業員によってもたらされているとの推定もあり

ます。この記事では、環境をセキュアに保持するために管理者が定期的に実行する必要のあ

るアクティビティーについて説明します。サーバー・セキュリティは、サーバーの物理セキュリ

ティ (サーバー・ルーム)、オペレーティング・システム (OS) 管理者から OS へのアクセス、対

象マシンで実行されるサービスなど、さまざまな領域で構成されています。サーバーのセキュリ

ティ・レベルは、チェーン内で も弱いノードで定義されます。 以下のチェック・リストは、セキュリティの観点から見てサーバーを正常に保持するために定

期的に確認する必要のある事項を示しています。

• 構成文書でライセンス・トラッキングを有効にすることによって、不要なアカウントがない

かどうか確認します。中小規模の環境では、6 カ月ごとに確認してください。大規模の

環境では、毎四半期確認してください。統計によると、大規模の環境では約 10% のア

カウントが使用されていなかったり、適切に削除されていなかったりします。詳しくは、

『License Tracking』を参照してください。 • すべてのデータベースに対してACL 解析を実行します。デフォルトがマネージャーや設

計者であるような、高いデフォルト・アクセス許可が存在しないことを確認します。また、

サーバーがインターネットからアクセス可能な場合、すべてのデータベースに Anonymous エントリーが存在することを確認します。注：Catalog.nsf にはすべての

データベースが含まれていない場合があります。Catalog.nsf には、存在するエント

リーが表示されます。Catalog.nsf には、Anonymous エントリーが存在しないというこ

とは表示されません。簡単な LotusScript エージェントを書いて ACL を確認するか、

Domino Administrator クライアントを使用して大量の ACL 更新を実行することができ

ます。

• サーバーの notes.ini パラメーターで LOG_USERSESSION=2 を有効にすると、Domino サーバーにアクセスするユーザーの PC の IP アドレスがログに記録されるようになるため、

これの使用を検討します。

• Domino Web サーバーが要求をロギングしていることを確認します。ログ結果から一

部のリソースをフィルタリングすることができます。詳しくは、『License Tracking』 を参

照してください。 • Domino Web サーバーのログで攻撃を確認し、Web サイトに対して総当たりパ

スワード攻撃を受けていないか調べます。 • サーバーに対して HTTP アクセスを許可している場合、パスワードがネットワーク上をプ

レーン・キストで送信されないようにするために、認証用の SSL をデプロイすることを検討します。

• 新しいチケットについて、DDM データベースを毎日確認します。 Lotus ドメイン・モニターのセキュリティ調査を使用可能にすることを検討します。 詳しくは、『セキュリティ調査』 を参照してください。

• USER.ID ファイルが添付された個人レコードがないことを確認します。スケジュールされ

たスクリプトを実行して、これを確認できます。スクリプトは、添付されている USER.ID ファ

イルを検出した場合、管理者に通知します。多くの組織は、デフォルトの開始パスワードを

使用しています。パスワード・チェックが有効になっていない場合、USER.ID ファイルの古

いコピーが悪用される恐れがあります。 • アクセス拒否グループが更新されていて、サーバー文書に取り込まれているかどうかを確

認します。 • 不必要なタスクがサーバー上で実行されていないことを確認します。例えば、

Anonymous アクセスが可能な公開されているサーバー上で LDAP が実行されている

場合があります。 • 必要なポートのみがオープンされていることを確認します。ファイアウォールの管理者に、ど

のポートが外部 (インターネット) からアクセス可能かを尋ねます。必要なポートのみがオー

プンされていることを確認します。ポートが必要なくなった場合、Domino 上で、ファイア

25

ウォールのレベルでそのポートをクローズします。オープンされているすべてのポートは、

システムへの侵入経路になる可能性があります。 • サード・パーティーのソフトウェアを使用して脆弱性スキャンを実施することを計画する場

合、就業時間外に行うようにします。このシステムの責任者となっている管理者に、テス

トの実施予定日時を通知します。

• 情報の窃盗に備えて確認します。 無許可でデータにアクセスしている者がいないかを確認

できる、サード・パーティーのソリューションがあります。情報の窃盗から保護することがで

きる、データ漏えい防止システムがあります。 • Domino サーバーのインターネット・パスワード・ロック機能が有効に設定されていること

を確認します。 誰かがサーバーに対して総当たり攻撃を仕掛けている場合、それをイン

ターネット・ロックアウト・データベースで確認できます。詳しくは、『Lotus Domino Web サーバーを安全に: 新しいインターネット･ロックアウト機能について』 を参照してください。

• より強力で複雑なパスワードの実装を検討します。これは、段階的に行います。 ユーザーのパスワードがポリシーに準拠していない場合、ユーザーはパスワードを変更

するよう求められます。ユーザーがパスワード変更手続きをキャンセルした場合、Lotus Notes は、現在のパスワードがポリシーに準拠していないためにクライアントがクローズ

されることをユーザーに知らせます。 • サーバーのセキュリティ・タブを確認します。誰が全アクセス権限管理モードを有効にでき

るかを確認します。このモードでは、サーバーのオペレーティング・システムへのアクセス権

限を持つスクリプトに署名することなどが可能です。全アクセス権限管理の有効化につい

て、他者または特別なメールボックスに通知できるようにします。詳しくは、Technote

1197579 を参照してください。

セキュリティはシステム・パフォーマンスとユーザー操作に影響を及ぼす場合があるということに、

留意してください。環境のセキュリティが強化されると、ユーザーはデータにアクセスして作業す

ることが難しくなります。ビジネスの所有者が必要とするセキュリティ・レベルとユーザーの快適

性との間のバランスを見いだす必要があります。

1.3.1 その他の 参照先

その他の参考資料については、以下を参照してください。

• Lotus Security Handbook • Security Considerations in Notes and Domino 7: Making Great Security Easier to

Implement

26

1.4. Domino の認証オプション

この記事では、Domino の認証オプションについて、どのオプションがご使用の環境に 適

か判断するのに役立つように説明します。

1.4.1 Domino の 認証 オプションの選択

Lotus Notes は、従来より認証に USER.ID ファイルを使用しています。リリース 8.5.x では、認

証に関するいくつか新しいオプションが追加されたのに加えて、ID 管理に要する時間を大幅に

削減する優れた機能、すなわち ID ボールトが追加されました。この他に、 SmartCard を使用

する認証オプションがあります。

以下のフローチャートは、どの Domino 認証オプションがご使用の環境に 適か理解するのに

役立ちます。

図 4

フローチャート内に番号付きで示した各認証オプションは、以下のセクションで説明され

ます。

27

28

1.4.2. SmartCard (1)

SmartCard は、Lotus Notes のアクセス権限に高いセキュリティを提供します。標準的な Lotus Notes の USER.ID ファイルを SmartCard に格納し、PIN 番号で保護することができま

す。Lotus Notes にログインするたびに PIN 番号の入力が必要になり、それによって SmartCard は保護された USER.ID ファイルのロックを解除できます。同様に、SartCard を使

用して SERVER.ID ファイルを保護することもできます。その場合、サーバーを始動するたびに、

SERVER.ID ファイルのロックを解除するために PIN 番号を入力する必要があります。

Lotus Notes の ID に SmartCard を使用することに決めた場合、SmartCard を使用するため

の Lotus Notes/Domino の構成方法を知る必要があります。SmartCard のユーザーには別

のポリシーが必要となる場合があることに留意してください。これは、定期的なパスワード変更

などのいくつかのオプションが、SmartCard の保護された USER.ID ファイルに適用できないた

めです。

詳しくは、以下の記事を参照してください。

• Enabling Smartcards for Notes login • Lotus Notes ログインに対して Smartcard を有効にする

• == シングル・サイン・オン (2) == 多くの Demino Web サーバーが存在する場合、LTPAToken に基づいてシングル・サイン・オン (SSO) を使用することができます。 ユーザーが 初のサーバーに接続して認証を受けるときに、ブラウザーはシークレット・チケット (トークン) を受信してブラウザーに格納します。新しいサーバーの認証を受ける必要がある場合、

ブラウザーはこのチケットをそのサーバー (ドメイン内のサーバーに限ります) に渡します。これ

によって、新たにパスワード入力を促されることなく認証されます。例えば 5 台のサーバー (3 台はクラスター内のメール・サーバー、2 台は内部アプリケーション・サーバーと外部アプリケー

ション・サーバー) があると仮定します。 この場合、SSO を使用しなければ、各サーバーに対して何度もパスワードを入力する必要があ

ります。しかし、LTPAToken による SSO を使用すれば 1 回のログインで済みます。 サーバーを構成するときに注意が必要です。インターネット・サイトを使用している場合は、1 つの LTPAToken 定義を使用します。インターネット・サイトを使用していない場合は、別の文書に格納された別の LTPAToken を使用することができます。ビュー ($WebSSOConfigs) で複製された文書を確認し、すべてのサーバーについてインターネット・サイトの文書を使用しているかいないかを確認することをお勧めします。 これによって、SSO のデプロイに要する時間を省くことができます。後から、Instant Messaging (Sametime Entry) またはSametime Meeting Server のデプロイ中に LTPA SSO を使用することもできます。例えば、Lotus Notes に組み込まれている Sametime クラ

イアントを構成して、SSO トークンを使用して Sametime にログインするようにできます。こ

れによって、Lotus Note ユーザーが Lotus Sametime にログインするために HTTP パス

ワードを入力する必要性をなくすことができます。

詳しくは、以下の記事を参照してください。

• Can Sametime work with Internet Sites enabled? (Technote 1157740 参照) • 01. Configuring Single Sign-On between Lotus Quickr and Lotus Sametime

1.4.3. Lotus Notes と HTTP パスワード の同期 (3)

Lotus Notes は、ユーザーが Lotus Note と同じパスワードを HTTP パスワードに設定するオ

プションを提供しています。同じパスワードを設定するメリットは、ユーザーが覚えるパスワード

が 1 つ減ることです。2 つのシステム (Lotus Notes と HTTP アクセス) で同じパスワードを使

用すると、HTTP パスワードの設定にかかる時間が不要になります。セキュリティ設定で設定し、

それを Domino ポリシーに追加すれば、後は自動的に処理されます。ユーザーは、必要に応じ

て HTTP パスワードを変更する要求を依頼できます。 Lotus Notes パスワードと HTTP パスワードとの同期は、ユーザーにとって認証を簡単にする

初のステップになります。また、ヘルプ・デスクの呼び出し回数を減らすことにも役立ちます。

Lotus Notes と HTTP の同期は、リリース 6.x、6.5、7.x、8.x、8.5 で使用可能です。

詳しくは、Lotus Note パスワードと HTTP パスワードの同期を可能にするためのセキュリティ

設定のヘルプを参照してください。

なお、パスワードの同期は、共有ログインとは連携しません。

1.4.4. LDAP (4 と 5)

Lotus Domino ユーザーは、NAMES.NSF、すなわち Domino ディレクトリーに登録されていま

す。システムをもう 1 つ配置する場合、環境内で、1 人のユーザーに対して複数のユーザー・ア

カウントを維持する必要性が生じる場合があります。各システムでのユーザーとパスワードの

管理は、費用がかかる作業です。LDAP プロトコルと連携して、Lotus Domino サーバーを使用

して他のユーザーを認証することができます。 他のシステムは、LDAP 認証を行うために、Domino ユーザーを使用することができます。この方法のメリットは、パスワード変更や新規ユーザーの追加などの何らかの変更があった場合、認証に Domino を使用しているすべてのシステムが自動的に変更を反映し、参照するということです。別のシステムのユーザーの登録や削除は不要です。

詳しくは、IBM インフォメーション・センターの『LDAP 機能を計画する』を参照してください。

1.4.5. SPNEGO (6)

Lotus Domino 8.5.1 では、新しいユーザー認証方法が導入されました。ユーザーは自分の Windows の証明書を使用して、Domino Web サーバーから認証を受けることができます。

SPNEGO 認証のメリットは、ユーザーがパスワード入力を求められないということです。調査に

よると、システムのパスワード管理はかなり高価です。ユーザーが持つ必要のあるパスワードの

数を減らすことは、ヘルプ・デスクの呼び出し回数を減らすことに役立ちます。 現在 Lotus Notes の 8.5.x 以前のリリースを使用しており、アップグレードを計画している場

合は、シングル・サイン・オン・サービスから 8.5 へのマイグレーションをご検討ください。このソ

リューションはパスワードを同期化する必要がないため共有ログインを使用することができ、こ

れは管理者にとって管理が容易となります。

SPNEGO は、Simple and Protected GSSAPI Negotiation Mechanism .(SPNEGO) を意味

します。クライアントのブラウザーとサーバーはネゴシエーションすることができ、サーバーはど

のユーザーがシステムにアクセスしようとしているのかに関する情報を Windows Active Directory から取得することができます。このようにして、サーバーは Windows ユーザーを Domino ユーザーにマップします。SPNEGO 認証を Microsoft Quickr、Sametime などの製品

に追加することを検討している場合は、IBM コンサルタントに相談してください。SPNEGO のデ

プロイを決定する前に、Windows Active Directory および Domino のバージョンについての要

件を確認してください。

29

詳細については、以下を参照してください。

• Deploying Windows single sign-on for Web clients (SPNEGO) in an existing Domino

environment • Domino Authentication Options

1.4.6.Lotus Notes および オペレーティング・システム シングル・サイン・ オン (7)

8.5.x 以前の Lotus Notes では、ユーザーが Lotus Notes のパスワードを入力しなくてもよ

いオプションが提供されていました。Lotus Notes シングル・サイン・オン・サービスによって Lotus Notes と Windows オペレーティング・システムの間の同期が取られていました。 現在 Lotus Notes の 8.5.x 以前のリリースを使用しており、アップグレードを計画している

場合は、シングル・サイン・オン・サービスから共有ログインへのマイグレーションをご検討く

ださい。このソリューションはパスワードを同期化する必要がないため、これは管理者にとっ

て管理が容易となります。

詳細については、以下を参照してください。

Technote 1208829

==共有ログイン (8)== Notes 共有ログイン (NSL) はリリース 8.5 で導入された機能です。これを使用すると Windows 資格情報を使用して Lotus Notes ID をアンロックすることができます。ユーザーが Windows オペレーティング・システムにログインすると、 Windows の特殊なサービスが Lotus Notes USER.ID のアンロックを担当し、パスワードを入力せずに Lotus Notes にログインする

ことができます。ユーザーが自分のパスワードを忘れた場合は、Windows ドメインのパスワー

ドをリセットする必要があります。リリース 8.5 の Lotus Notes セキュリティ・ポリシー設定には、

ユーザーに対して共有ログインを通知し、有効にする方法に関してのオプションがあります。

Lotus Notes と HTTP パスワードの同期化が既に有効に設定されており、後から共有ログイン

を有効にした場合、ユーザーは HTTP パスワードを別々に管理する必要があります。必要に

応じて、一部のユーザーに対しては、Lotus Notes クライアントのセキュリティ・プリファレンス (デフォルトではグレー表示) で共有ログインを有効にすることができます。

図 5

30

ヒント:共有ログインとリリース 6.x-7.x のシングル・サイン・オンを混在させないでください。古い

バージョンの Lotus Notes のシングル・サイン・オンでは、Lotus Notes のパスワードと Windows のパスワードの同期を取っていました。8.5 の共有ログインでは同期を取る必要があ

りません。 Windows の特殊なサービスによってユーザーの USER.ID がアンロックされます。

オペレーティング・システムのシングル・サイン・オンを使用していた環境からアップグレードする

場合は、共有ログイン機能に移行することをお勧めします。オペレーティング・システムのシング

ル・サイン・オンは後方互換性のためのものです。

詳細については、以下を参照してください。 Lotus Notes 共有ログインを利用して、パスワードを求めるプロンプトが出ないようにする

1.4.7.Tivoli Directory Integrator (9)

Lotus Domino 8.5.x を購入されたユーザーは Tivoli Directory

Integrator を使用して Domino とデータの同期を取る権利があります。詳しくは、TDI の資格 を参照してください。

Domino とデータの同期を取るために Tivoli Directory Integrator (TDI) が使用されている場合

は、追加のライセンスを購入する必要はありません。Domino 以外のデータと同期を取るために TDI が使用されている場合は、追加のライセンスを購入する必要があります。

TDI を使用するさまざまなシステムの統合およびデータの同期化が可能となります。例えば、

Lotus Domino ディレクトリーと Windows Active ディレクトリーを統合するだけでなく、テキス

ト・ファイルあるいは CSV ファイルとの間でユーザーをエクスポートまたはインポートできます。

TDI は非常に強力なツールです。これを使用開始する前にそのアーキテクチャーについて学習

する必要があります。

1.4.8.追加の リソース

詳細については、以下を参照してください。

• Robust Data Synchronization with IBM Tivoli Directory Integrator

• Home page of TDI Users community オンライン・トレーニングおよびチュートリアル の資料はここで見つけられます。

• Lotus Domino integration page

• Tivoli Directory Integrator - integration with Lotus Domino

31

32

1.5. エージェントと Domino 管理者

エージェントは、管理者が書き込みや処理を行うためのものであると考えることができます。し

かし、すべての Domino 管理者がエージェントに関して知っておくべきことは多数あります。この

記事は、エージェントのトリガーを設定する方法、サーバー上で実行がスケジュールされている

エージェントを判別する方法、全文検索とエージェント、エージェントのパフォーマンスの影響、

およびエージェントの作成方法など、これらのエージェントに関連する一連のトピックについて説

明します。

1.5.1.エージェントの トリガー

エージェントはさまざまな方法でトリガーを設定することができ、またエージェント・マネージャー、

サーバーおよび http などを含む多くのサーバー・タスクの下で実行することもできます。エー

ジェントが作成されると、開発者はそのエージェントの実行方法について選択できます。エージェ

ントは、アクション・メニューからの選択、メール・メッセージの配信前後、あるいは作成された文

書からの呼び出しなどのイベントをトリガーとすることができます。エージェントの影響について

認識できるようにしておくためには、どのタスクの下でエージェントが実行されるのか理解してお

くことが重要です。サーバー上で CPU の使用率が突然増加した場合に、潜在的な原因となっ

ているエージェントを容易に識別したり除去できるようにしておく必要があります。トリガーのリス

トは次のとおりです。

• スケジュール: このタイプのエージェントは、サーバー上で開発者が定義したスケ

ジュールによって実行されます。エージェントは、1 日に複数回、毎週あるいは毎月実

行といった指定が可能です。

• アクション・メニューの選択: このタイプのエージェントの実行については、ユーザーが Lotus

Notes クライアントの「アクション」メニューからエージェントを選択する必要があります。この

方法でエージェントが実行されると、エージェントのコーディング方法に応じてコードはクライ

アント・タスクまたはサーバー・タスクのいずれかで実行されます。Domino 管理者は、この

方法でトリガーされたエージェントのログを取得したり、エージェントのリストを表示したりし

ません。

• エージェント・リストの選択: このタイプのエージェントのトリガーは、他のエージェントによっ

て呼び出されるか、または (開発途中の場合などで) デザイナー・クライアントからのみ実行

されます。これらのエージェントは、デザイナー・クライアントで、またはエージェントを呼び出

したサーバー・タスク内で実行されます。

• 新規メールの受信前: このタイプのエージェントは、メッセージがメールまたはアプリケーショ

ン・データベースの受信ボックスに書き込まれる前に直ちにルーター・タスクによってトリ

ガーされます。このタイプのエージェントは、ルーター・タスクの下で実行されます。

• 新規メールの受信後: このタイプのエージェントは、メッセージがメールまたはアプリケー

ション・データベースの受信ボックスに書き込まれた後に新規メール・メッセージによってト

リガーされます。メッセージが配信された後、エージェントは 2 分以内に実行されるようス

ケジュールされます。このタイプのエージェントはエージェント・マネージャー・タスクによっ

て制御されます。これによって、複数のメール・メッセージが短い時間内にデータベースに

書き込まれる場合、サーバーはこれらの新規メール・メッセージの処理を、短時間内に複

数回実行するのではなく 1 回で処理することができます。

• 文書が作成または更新された後: 新規文書が作成または更新された後、エージェントが

実行されます。エージェントは、文書が作成または更新された後でエージェント・マネー

ジャー・タスクの下でスケジュールされたエージェントとして実行されますが、30 分より後

になることはありません (サーバーの負荷により異なります)。

1.5.2.サーバー上で 実行が スケジュールされているエージェントの判別

Domino Administrator クライアントには、サーバー上で実行がスケジュールされているエー

ジェントを判別する簡単な方法が提供されています。図 6 では、実行がスケジュールされてい

る 5 つのエージェントがあるのがわかります。エージェントにはトリガーのタイプによって名前が

付けられています。ご覧になるとわかるように、エージェント・マネージャー・タスクによって実行

されるエージェントのみがリストされています。スケジュールされている次回の実行時刻は、

「Next」列の下ですぐにわかるようになっています。カーソルをスケジュールの上に合わせると、

サーバーはそのエージェントのスケジュールに関する情報を表示します。「サーバー上でスケ

ジュールされているエージェント (A Scheduled Agent on a Server )」は 60 分ごとに実行され

るよう設定されています。 「文書が作成または更新された後 (図 6: An After documents are created)」または「新規メー

ルの受信後 (図 6: An After New Mail Arrives)」エージェントの吹き出し (ホバー) には、別の

トリガーによってスケジュールされることを示す「実行されないエージェント (Agent will not run)」のリストが表示されます。

図 6

1.5.3.エージェントの実行に影響を与えるマネージャー設定

サーバー上で随時実行できるエージェントの数およびエージェントを実行できる時間を決定す

るいくつかの設定があります。これらの設定は、下の図 7 に示されているサーバー文書の

「サーバー・タスク (Server Tasks)」の「エージェント・マネージャー (Agent Manager)」タブに

表示されています。例えば、デフォルトでは、日中に同時に実行できるエージェントは 1 つの

みで、夜間には同時に 2 つのエージェントを実行できるようになっています。ご使用の環境で

処理する必要のあるエージェントの数に応じて、この数字を増やすことができます。

同時に実行するエージェントの数を増やす必要がありますか? 前述のセクションでは、実行が

スケジュールされているエージェントを判別する方法について説明しました。以前にこれらの

エージェントの多くが実行をスケジュールされており、これらが文書の更新またはメール・メッ

セージによってトリガーされるエージェントではない場合、エージェント・マネージャー・タスクは継

続中のままにはならないため、日中・夜間または両方の 大同時エージェント・パラメーターを

増やすことを検討できます。検討する必要のあるその他のパラメーターは、 大 LotusScript/Java 実行時間です。処理に 10 分以上かかっているエージェントがある場合、この

33

パラメーターを変更する必要があります。そうしないと、エージェントは処理が完了する前にエー

ジェント・マネージャー・タスクによって停止されてしまうからです。この設定は永続的なループに

対する安全な予防措置であり、1 つのエージェントが他のすべてのエージェントの実行を妨げる

ことのないようにできます。

図 7

1.5.4. 全文検索 と エージェント

エージェントは、情報を検索してから、アクションを実行するという動作を何回も繰り返さなけ

ればならない場合があります。 全文検索は、全文索引が保持されていない場合にリソースが

大量に消費される処理です。詳細については、「3.8 Domino の索引作成の管理」を参照して

ください。エージェントが全文索引を使用しないアプリケーションに対して全文検索を実行して

いるかどうかを判断するには、サーバー・ログで次のようなメッセージを探す必要があります。

Warning: Agent is performing full text operations on database 'application/application1.nsf' which is not full text indexed.しかし、これは非効率な作業です。

ログ分析ツールを使用すれば、もっと簡単に判断できます。ログ分析ツールにアクセスするに

は、Domino Administration クライアントの「Server...」→「Analysis」タブに移動します。 図 8 に示すように、右側のパネルで、「Tools」→「Analyze」→「Log...」 を選択します。

図 8

この時点で、「Log Analysis」ウィンドウが表示されるはずです。このウィンドウで、「Words」

タブをクリックして検索する文字列を入力できます。この場合は、図 9 に示すように、単語の

34

inefficient を入力してから「OK」をクリックすると、検索が開始されます。

図 9

検索が終了したら、 「Log Analysis Results」を確認します。 下の図 10 は、望ましい検索結果

の「No matching entries found (一致するエントリーが見つかりませんでした)」を示しています。

図 10

1.5.5. 新しい エージェント と アプリケーション の パフォーマンスに対する 影響

新しいアプリケーションまたはエージェントを環境に追加する前に、パフォーマンスのベースラ

インを設定しておくことをお勧めします。これは、アプリケーションまたはエージェントの環境に

対する影響を判断するときに役立ちます。詳細については、「4.3 パフォーマンス・ベースラインの

設定」を参照してください。

1.5.6. Agent Manager に 伴う 問題 の トラブルシューティング

トラブルシューティングについては、Technote 7002851 を参照してください。

35

36

1.5.7. エージェント の 作成

Domino システム管理に慣れてきたら、アプリケーションの自動処理または自動作成に移行

できます。LotusScript を始める場合は、Domino Designer ヘルプで LotusScript の学習 や Technote 7010056 を参照してください。その他のリソースは、Lotus Notes and Domino Application development wiki で見つけることができます。

1.6. Domino ドメインの拡張

将来的に、Domino ドメインの拡張が必要になる可能性があります。Sametime サーバーまた

は Traveler サーバーをドメインに追加したり、新しいメール・サーバーを追加することによって、

初めて単一サーバー環境から複数サーバー環境に移行する場合は、環境のスムーズな運用を

妨げないようにする必要があります。ここでは、ドメインの拡張プロセスについて説明します。

1.6.1. 新しい サーバー の 登録 と 保護

Domino ドメインに新しいサーバーを追加する場合の 初の手順は、新しいサーバーの登録

です。 ユーザーの登録と同様に、この登録プロセスにより、新しいサーバーに関するサーバー

文書とサーバー ID ファイルが作成されます。 また、この登録プロセスでは、サーバー名が自

動的に LocalDomainServers グループ (存在する場合) に追加されます。 この時点で、新しい

サーバーに適切な権限を設定するようにサーバー文書を変更できます。 図 11 に示す例では、サーバー管理者が定義され、「Sign or run unrestricted methods and operations (制限なしで署名または実行)」の programmability 制限が免除されています。サー

バー・アクセス・セクションでは、データベースとレプリカの作成が管理者に限定され、

Terminations グループはアクセスが拒否されています。これで、新しいサーバー用に使用するプ

ラットフォームに適切な設定ウィザード を使用して、このサーバーを設定する準備ができました。

図 11

37

1.6.2. 重要な データベースの 複製

複数サーバー環境では、names.nsf と admin4.nsf の 2 つのデータベースをサーバー間で複製

する必要があります。システム管理プロセスを正しく機能させるためにはこの複製が非常に重要

です。Domino サーバーが 10 台以下の小規模企業では、図 12 に示すようなシステム管理サー

バーからの push/pull 複製が一般的です。複製は、接続文書を通してスケジュールされます。 例では、 Server1/Company A と Server2/Company A が接続されています。

「Replication/Routing (複製/配信)」タブの複製タイプは、データベースに加えられた変更がお互

いのサーバー間でやり取りされる「Pull Push」になっています。 「Files/Directory paths to replicate (複製するデータベースのディレクトリ/ファイル名)」が names.nsf および admin4.nsf として定義されているため、これらのデータベースだけが複製されます。 後に、「Schedule」タ

ブでは、複製が毎日 20 分間隔で実行されるように設定されています。

図 12

より大規模な Domino デプロイメント用のサンプル複製トポロジーや adminp の基礎を含むシステ

ム管理プロセスの詳細については、Technote 7009315 を参照してください。 複製の競合を避け、

adminp タスクの適切な処理を保証するには、Domino ディレクトリー (names.nsf) で、ドメイン内

の全 Domino サーバーのシステム管理サーバーと同じサーバーを指定する必要があることに注意

してください。 実際には、これをすべてのアプリケーションに拡張できます。ドメイン内のすべてのデータベースを

ドメイン内の 1 台のサーバーで管理しなくなった場合でも、すべてのアプリケーション・レプリカが

同じシステム管理サーバーを使用する必要があります。

names.nsf と admin4.nsf だけを複製する必要がありますが、すべてのデータベースをサーバー

間で複製するようにも選択できます。この場合は、ほぼすべてのテンプレートがサーバー間で複

製されることに注意してください。詳細については、Domino wiki の「Domino Template Replication」を参照してください。ほとんどの場合、この資料だけで十分ですが、複数のリリース

環境が存在し、その設計を 新リリースに統一したくない場合は、

「7.5_Design_replication_and_mixed_releases__avoiding_design_ping-pong 」で詳細を確

認してください。

38

上の図 2 は、おそらく、 も一般的でシンプルな複製設定の例を示しています。全社規模の Domino 展開を実施する場合に、スケジュールを 適化する方法を以下に示します。

• 時間間隔ではなく、特定の時刻をスケジュールに設定する。 • 複製時間の上限を設定する。 • 定期保守期間のデータベースの複製は避ける。 • タイムゾーンを考慮する。 • 業務が も忙しい時間帯に大量の更新を Domino ディレクトリーに転送しないようにする

(特に、ユーザー数が 10 万人以上の大企業や大規模ディレクトリーの場合に重要)。

時刻の使用と、時間範囲と反復間隔の設定にはどのような違いがあるのでしょうか。反復間隔

を使用した複製は、必ずしも同じ時刻に実行されないという違いがあります。これは、反復間

隔が複製の完了時点から開始されるためです。つまり、 初の複製が 12:00 に開始され、15 わかったとすると、次の複製は 12:20 ではなく、12:35 に開始されます。特定の開始時刻を設

定する場合は、複製が開始される正確な時刻を把握できるため、複製のトラブルシューティン

グが容易になります。前の複製が完了するまで次の複製イベントが開始されないようにするに

は、複製時間の上限を設定します。一部のデータベースに対して頻繁に複製を実行する場合

は、反復間隔を使用する方がずっと簡単です。

これらの要点を検証するために、Company A が、事業をグローバルに展開して、 近、リオデ

ジャネイロにサーバー・グループを追加したとします。 現在、この会社には、Server Group US と Server Group Brazil の 2 つのサーバー・グループがあります。 彼らは、names.nsf、admin4.nsf、およびメール・ファイルを 60 分間隔で複製することにしました。AM 12:00 にバッ

クアップを、AM 1:00 に design タスクを、AM 2:00 に updall タスクを実行します。また、毎週土

曜日の AM 4:00 ～ AM 7:00 にすべてのデータベースの圧縮を実行します。これらのサーバー

が EST タイムゾーンと BRST タイムゾーンに設置されていると仮定して、ビジネス要件を満た

し、保守時間帯を避ける複製トポロジーを構築するにはどうしたらいいでしょうか。

EST 時間 BRST 時間 コメント

毎日 AM 12:00 ～ AM 3:00

毎日 AM 3:00 ～ AM 6:00 米国サーバーの夜間保守時間帯

土曜日の AM 4:00 ～ AM 7:00

土曜日の AM 7:00 ～ AM 10:00

米国サーバーの圧縮時間帯

毎日 AM 9:00 ～ AM 12:00

毎日 AM 12:00 ～ AM 3:00 ブラジル・サーバーの夜間保

守時間帯

土曜日の AM 1:00 ～ AM 4:00

土曜日の AM 4:00 ～ AM 7:00 ブラジル・サーバーの圧縮時間

帯

複製を開始するサーバーによって、大量の複製イベントのスケジューリングを避けるべき時間

帯は容易に特定できます。Server 1 が EST タイムゾーンに設置されているとすると、下の図

のような接続文書を作成できます。

39

図 13

このように接続文書を作成することにより、土曜日以外の曜日の両サーバーの保守時間帯と

タイムゾーンを満たすことができます。その後で、土曜日用の別の文書を作成できます。下の

図に、ブラジルに設置された Server 2 から Server Group US 間の土曜日の設定例を示しま

す。

図 14

1.6.3. メール・ルーティング

必要に応じて、Domino ドメイン内のすべてのサーバーでメール交換が可能なように設定する

ことができます。すべての Domino サーバーが同じ Notes 名前付きネットワーク (NNN) 内に

存在する場合は、サーバー間のメールのルーティング方法が自動的に認識されます。すべて

のサーバーが同じ NNN 内に存在しない場合は、server1 to server2 と server2 to server1 という 2 つの接続文書を作成する必要があります。

Notes 名前付きネットワークとは何でしょうか。NNN は、サーバーを物理ネットワークに基づい

て論理的にグループ分けする方法です。 図 15 に示すように、これは、サーバー文書内の

「Ports (ポート)」「Notes Network Ports (Notes ネットワークポート)」タブにある「Notes Network」パラメーターで定義されます。デフォルトで、Domino ドメイン内の 初のサーバーが Network1 という名前のネットワークに設定され、その他のサーバーが TCPIP Network に設定

されます。したがって、サーバーに対する値を選択するか、必要に応じてネットワーク・トポロ

ジーに基づいて一致するネットワーク名を設定する必要があります。

40

図 15

2 台の Domino Server 間でメールを送信するためには、サーバーはメールの送信先を知り、

リモート・ロケーションに接続することができる必要があります。NNN または接続文書を正しく

構成した場合、 初の要件は満たされています。2 番目の要件では、ネットワーク管理者との

密接な仕事上の関係が必要です。Domino Server はメール送信または複製を行うときにポー

ト 1352 を介して Notes リモート・プロシージャー・コール (NRPC) プロトコルを使用します。

Domino Server 間にファイアウォールが構築されている場合は、メールを正しくやり取りする

ためにポート 1352 が両方向に開いていることを確認する必要があります。

1.6.4. 複数の サーバーのモニターおよび管理

ログまたは Domino コンソールを手動でモニターすることは、単一サーバー環境では非常に簡

単なタスクです。より多くのサーバーを環境に追加するにつれて、このタスクは次第に難しくなり

ます。Domino はこのタスクを容易にするために複数のツールを提供しているため、これらの

ツールを使用して新規サーバーをこの環境に追加することが重要です。モニターとアラートの構

成については、3.1 モニターに説明します。

簡単なチェックリストを以下に示します。

• 新規サーバーを DDM 階層に追加します。 • このためにグローバル構成文書を使用しない場合は、新規サーバーのために診

断収集を構成します。 • 新規サーバーのための統計収集文書を構成します。

1.6.5.クラスタリング

Domino ドメインを拡張する他の一般的な理由は、ユーザーに高可用性を提供できるようにす

ることです。今日まで、システムが今から時間が終わるまで稼働していることを保証する、また

は保証することができるハードウェアやソフトウェアはありません。このため、Domino Server はある時点で停止することがあります。サーバーが定期保守、アップグレードまたは自然災害

のために停止するかどうかにかかわらず、Domino アプリケーション・クラスタリングは簡単に

構成および使用することができ、ユーザーに高可用性を提供することができます。

新規 Domino Administrator の重要なクラスタリング概念は、以下のとおりです。

• Domino クラスタリングはアプリケーション・レベル・クラスタリングです。

41

42

• フェイルオーバーは、Lotus Notes クライアントに限定されます。iNotes にアクセスするブラウザーは、追加のインフラストラクチャーがなければ、クラスター・サーバーに自動的にはフェイルオーバーされません。

• Domino クラスタリングを使用してメールを別のサーバーに送信することができます。 詳しくは、3.2 メール転送を参照してください。

• リソース予約データベースなどの他のアプリケーションは、 ネイティブに使用可能な Domino クラスタリングを使用してクラスター化することができます。

• Traveler サーバーはクラスター化することはできません 。(Clustering and failover)

クラスタリングについて詳しくは、記事「Understanding IBM Lotus Domino Server clustering」 および 3.5 サーバー・クラスタリング・オプションを参照してください。

43

1.7. 設計、複製およびリリース混在: 設計の頻繁なやり直しの回

避

環境に複数の Domino Server がありますか。複数の日、週または月にわたって Domino Server をアップグレードしますか。そうである場合は、design タスクおよび複製によりデータ

ベースの設計が毎日変更されている問題を防止するために使用可能なオプションを考慮する必

要があります。この記事では設計の頻繁なやり直しシナリオを防止する方法について説明しま

す。

1.7.1. 問題の説明

サーバーが「設計の頻繁なやり直し」を行っていることを知ることができるいくつかの方法があり

ます。design タスクが実行される毎夜にすべてのデータベースが更新されていることにログで

気がつきます。ある日メール・データベースがアップグレードされましたが、翌日にはメール・

ファイルがアップグレードされていないことにユーザーが気付きました。Replica タスクが通常よ

り多いデータを複製していることに気付きました。

この動作の原因は何ですか。それは複製と design タスクを組み合わせたものです。デフォルト

では、design タスクは午前 1 時にサーバー上で実行されます。デフォルトでは、

ServerTasksAt1=catalog, design という行が各サーバーの NOTES.INI にあります。design タスクが実行されると、テンプレートの設計要素の日付と時刻がデータベースの設計要素と比

較されます。不一致がある場合は、design タスクにより既存の設計要素がテンプレートの設計

要素と置き換えられます。 Domino Server をアップグレードすると、データベースに 新の更新とフィックスが適用される

ので、これは重要です。Domino Server を 8.5.1 サーバーから 8.5.2 にアップグレードしたと仮

定します。 以下の一連のイベントが発生することがあります。

1 日目: Domino 8.5.2 サーバーは、すべてのメール・フィックスとシステム・アプリケーション・

データベースの設計を 新の 8.5.2 更新でアップグレードします。サーバー間の次の複製イベ

ントのときに、8.5.2 設計は 8.5.1 サーバーに存在する Replica データベースに複製されます。

2 日目: Domino 8.5.1 サーバーは、テンプレートのコピーに保存された設計要素のコピーを

使用してすべてのデータベースの設計を更新します。サーバー間の次の複製イベントのとき

に、8.5.1 は 8.5.2 サーバーに存在する Replica データベースに設計を複製します。

サイクルが再開され、Domino 8.5.2 サーバーは設計をアップグレードします。

1.7.2.問題の防止

設計の頻繁なやり直しの発生を防止する方法にはいくつかあります。

• サーバー間のテンプレートの複製 • design タスクの制限 • 一部のサーバーからのテンプレートの削除 • 選択的な複製

44

サーバー間のテンプレートの複製 多くのテンプレートはリリース間で同じ Replica ID を持っています。テンプレートをユーザーの

環境で複製できるようにした場合は、 新の設計がサーバー間で共通するテンプレートに複

製されます。詳しくは、「Domino Template Replication」という Domino wiki の記事を参照し

てください。 このシナリオでは、design タスクが実行されるときにすべてのサーバーが同じ設

計要素を持つので、データベースが既に更新済みであることを認識し、そのためデータベース

を再度更新することはありません。

design タスクの制限 デフォルトでは、すべての Domino Server が午前 1 時に design タスクを実行します。ある期

間にリリース混在環境で実行する必要があり、テンプレートを複製しない場合は、サーバー構成

を変更し、ドメイン内の 1 つ以上のサーバー上で design タスクを実行しないようにすることが

できます。design タスクはサーバーの NOTES.INI ファイル内の ServerTasksAt1=catalog, design エントリーにより午前 1 時に開始されます。 Domino コンソールで以下のコマンドを入

力することにより design タスクを削除することができます。

set config ServerTasksAt1=catalog

すべてのサーバーをアップグレードしたら、“set config” コマンドを再び使用して design タスク

を簡単に再び有効にすることができます。

set config ServerTasksAt1=catalog,design.

一部のサーバーからのテンプレートの削除 テンプレートがサーバー上に存在しない場合、design タスクはデータベースの設計を更新することはでき

ません。 上記のシナリオでは、管理者は 8.5.1 サーバーからテンプレートを削除することができます。 後で、サーバー・アップグレードの一部として、テンプレートは Domino Server データ・ディレ

クトリーにコピーされます。これらのファイルを複製するようにクライアントまたはサーバーを構

成した場合は、テンプレートを削除すると、サーバーのパフォーマンスの問題が生じることがあ

ります。テンプレートの削除によるパフォーマンスへの影響について詳しくは、技術情報 Technote 1299812 および Technote 1426125 を参照してください。

選択的な複製 Domino データベースとアプリケーションを複製するときに、どちらのデータを複製できるかを制

御します。例えば、データベースのごく一部のみを複製する場合は、設計要素の複製を一時的

に無効にすることができます。これは図 16 に示すようにデータベースの複製設定で行うことが

できます。

図 16 1.7.3. 混在環境での混合クラスター の取り扱い

この記事で説明したアプローチは Replica サーバーで非常に有効ですが、クラスター化サー

バーでは有効でない場合があります。これは、クラスター・レプリケーターは常に設計要素を複

製するからです。設計が古いサーバーに戻るのを防止する も簡単な方法は、クラスターのい

ずれのサーバーでも design タスクを実行しないようにすることです。しかし、新しい設計がなけ

れば、新しい機能を使用することはできません。また、nsf や admin4.nsf という名前などのシス

テム・データベースは下位互換性があるので、新しい設計は以前のサーバーでも有効に機能し

ます。このような複雑さのために、クラスター化サーバーは同時にまたは短い時間内にアップグ

レードするのが 良の方法です。

45

46

1.8. 定期保守のベスト・プラクティス

毎週の保守計画を作成することは、Domino Server の正常性を維持するために極めて重要な

部分です。Domino は Domino Directory 内のプログラム文書を使用して保守タスクをスケ

ジュールするための簡単な方法を提供します。この記事では、定期保守のためのベスト・プラク

ティスを提供します。

1.8.1.Fixup および トランザクション・ロギング

トランザクション・ロギングの利点の 1 つは、障害 (サーバー障害、電源障害、ハードウェア障

害など) が発生した後にサーバーを再起動する場合、ユーザーがアクセスする前にログ・デー

タベースで整合性チェックを行う必要はないことです。トランザクション・ロギングをセットアップし

た後、データベースを整合状態に戻すために fixup は必要でないか、使用されません。

このため、トランザクション・ロギング・サーバーでは、fixup タスクを定期的に実行するように

スケジュールしないでください。

1.8.2. 定期保守

Domino Directory の定期保守は、サーバーの正常性を維持し、パフォーマンスを 適化する

ために不可欠です。管理者は以下のヒントを開始点として使用して、環境に適した保守スケ

ジュールを作成することができます。

Technote 1248830 は簡単な要約を提供します。

Windows サーバーの毎週のリブート

多くのお客様はメモリー・リークを防止するために毎月のスケジュールで Windows サーバーを

リブートします。

データベースのホワイト・スペースの回復 文書と添付ファイルをデータベースから削除する場合、Domino は直ちにファイル・サイズを減

らすのではなく、未使用スペースを再利用しようとします。場合によっては、Domino はスペー

スを再利用することができないか、フラグメント化のために、データベースを圧縮するまでス

ペースを有効に再利用することができません。

以下のコマンドは、プログラム・ドキュメントを使用して、週末に実行するようにスケジュールでき

ます。 • compact -b -s 10 (アーカイブ・トランザクション・ロギング有効) • compact -B -s 10 (循環トランザクション・ロギングまたはアーカイブ・トランザクション・ロギン

グ無効)

上記コマンドを使用すると、空白が 10% を超えているデータベースが圧縮されます。-b または -B は、サーバーがインプレース圧縮を実行することを意味します。b (小文字) スイッチは、新し

い DBIID をデータベースに割り当てないように、トランザクション・ログとともに使用する必要が

あります。

47

注：8.5.2 で新規の compact -ODS 引数は、現在の ODS が目的のデフォルト ODS より少な

い場合のみコピー・スタイル圧縮を実行します。 これは、圧縮を実行して新機能 (文書データの

圧縮など) を実装する必要がある場合、便利です。

圧縮管理要求データベース 以下のコマンドは、プログラム・ドキュメントを使用して、週末に実行するようにスケジュールでき

ます。

• compact admin4.nsf -c -t

上記コマンドによって、コピー・スタイル圧縮が実行されますこれは、データベース破損を解決

できるため、便利です (新しい DBIID が割り当てられます)。-t 引数は、そのシステム・データ

ベースのトランザクション・ロギングを無効にします。

注:新しい DBIID がデータベースに割り当てられた場合、できるだけ早くデータベースのフル・

バックアップを実行する必要があります。 これは、古いトランザクション・ログは、そのデータ

ベースでリストアできなくなるためです。データベース DBIID について詳しくは、Technote 7009309 を参照してください。¬

1.8.3. データベース破損

毎週の保守スケジュールの一部として fixup や updall を実行する必要はありません。fixup は、

データベース破損の疑いがある場合のみ実行する必要があります。updall は、デフォルトで毎

晩実行されます。引数を指定して updall を実行する必要があるのは、ビューの破壊または

ビュー内の別の問題の疑いがある場合のみです。

データベース破損を検出した場合、まず compact -c を実行します。ビュー索引が破壊された

場合、updall -r –t を実行します。データベース内の破損を 小化するには、Database Corruption Troubleshooting Guide に追加の 推奨が記載されています。

1.8.4. ハード ・ディスクのフラグメント化

SAN または RAID-5 ベースの Domino のデータ量は、フラグメント化の影響を受ける可能性が

あります。ハード・ディスクは、サーバーの中で も遅いコンポーネントです。ファイルのフラグメ

ント化を管理すると、パフォーマンスの維持に役立つ可能性があります。Hard disk fragmentation Notes/Domino wiki の記事にハード・ディスクのフラグメント化の詳細および Domino サーバーへの影響が説明されています。

注：ファイルのフラグメント化は、ワークステーションにも影響します。 通常の O/S のデフラ

グは、ユーザーのクライアント・マシンのディスク・パフォーマンスの維持にも役立ちます。

1.9. モバイル・アクセス

モバイル・アクセスの場合、さまざまなデバイス・タイプに対して異なるオプションがあります。

この記事では、モバイル・アクセスに使用可能なさまざまなオプションおよびソリューションに

ついて説明します。

以下の表にサポートされるデバイス・タイプおよびそれぞれで使用可能な機能を要約します。

デバイス・タイプ Traveler BES Server POP/IMAP iNotes Ultra Lite

Blackberry X

iPhone/iPad/iPod X X X

Android X X

Windows Mobile X

1.9.1.Traveler

Lotus Traveler は、Lotus Notes ライセンスに含まれているプッシュ・メール・ソリューションで

す。これは、Lotus Notes 8.x または Lotus Notes.8.5.x を購入済みの場合、追加費用なし

で利用できます。

別のサーバーで Traveler を実行することをお勧めします。Traveler は、Domino サーバー

上にインストールする必要があります。これは、拡張製品 (Domino 上にインストールされた

製品/コンポーネント) と呼ばれます。インストールする Lotus Traveler のバージョンは、ご使

用のサーバーが現在実行しているLotus Domino のバージョンによって異なります。ソフト

ウェア要件を確認し、どのバージョンが目的の Traveler のバージョンでサポートされるかを

確認します (例えば、Lotus Traveler 8.5.2 は Lotus Domino 8.5.2 のみにインストールでき

ます)。Traveler に関する追加情報は、以下のリンクにあります。 Lotus Notes Traveler

Lotus Traveler は、Windows Mobile、Nokia Symbian、Apple iPod/iPhone/iPad をサポートします。Android 電話のサポートは、8.5.2 のフィックスパック 1 で追加されま

す。

Lotus Traveler をデプロイするには、以下の手順を実行する必要があります。

1. Lotus Domino 上に Lotus Traveler をインストールします。 2. モバイル電話に Traveler クライアントを配布します (これらは、Traveler ホームページ

からダウンロード、またはリモートで配布できます)。

Traveler サーバーのインストール

Lotus Traveler サーバーは、Windows 32、Windows 64 および Linux OS でサポートされてい

ます。Linux OS のサポートは、リリース 8.5.2 で追加されました。

Lotus Notes Traveler のシステム要件は、以下のリンクにあります。 Index of system requirements for Notes, Domino, Domino Administrator, Domino Designer & Notes Traveler

インストールを開始する前に以下のことを確認します。

• Domino Servlet Manager が有効になっている。 これを行うには、Traveler サーバー

48

49

のサーバー・ドキュメント、 「Internet Protocols」 -> 「Domino WEB Engine」 タブ

を開きます。「Java Servlets」を「Domino servlet manager」に設定します。

• Lotus Traveler サーバーが、LocalDomainServers グループに含まれており、このサー

バーがすべてのメール・ファイルに対する管理アクセス権を持っていることを確認します。 • ご使用の Traveler サーバーが DMZ にある場合、構成ディレクトリーを有効にします。

構成を使用するとき、Domino Directory が他のすべての情報として構成ファイルのみを

含むディレクトリーのみが names.nsf. のフル・コピーを持っているその他のサーバーか

らの要求を受けます。 • サーバーに SSL 認証を備えることをお勧めします。 こうすることにより、ご使用のサー

バーのセキュリティが向上します。HTTPS 接続を使用すると、電話からサーバーにパス

ワードを送信するときに、誰もインターセプト (ネットワーク・トラフィックをリッスン) できなく

なります。標準の HTTP 接続では、パスワードは、プレーン・テキストで送信されます。 • 8.5.2 より前のバージョンの Traveler は、2 つのポート (AutoSync 用とデータ伝送用) を

使用しています。 8.5.2 では、HTTP ポートまたは HTTPS ポートでの通信のみです。

Lotus Notes Traveler をインストールする前に確認することに関する詳細かつ更新された情報に

ついては、以下のリンクの情報を確認してください。 Before you install

Traveler サーバーを Windows と Linux の両方にインストールすることは非常に簡単です。

Windows では LotusTraveler セットアップ・ファイルが起動され、インストールするものを選

択します (下記オプション参照)。Linux では、Traveler のインストールは、グラフィカル・モード

を介してまたはサイレント・インストールの 2 つの方法で実行できます。サイレント・インストー

ルは、一部のシステムにはないグラフィカル・モードを必要にしないため、こちらが優先される

メソッドです。サイレント・インストール応答ファイルを構成して、サイレント・インストール・ス

イッチを指定してインストールを実行するだけです。

• クライアント (Nokia/Windows mobile/Apple のイメージのみをインストールします)。 • サーバーのみ (サーバー部のみをインストールします。クライアントはインストールしません)。 • 両方 (推奨オプション) – 両方のオプション (サーバーとクライアント) をインストールします。

Traveler のインストール・ウィザード終了後、インストール・ウィザードの 後の画面に

注意してください。インストールが正常に完了したことを確認します。

Lotus Traveler は、登録されたデバイスの情報を lotustraveler.nsf データベースに格納しま

す。デバイス・ドキュメントをこのアプリケーションから削除しないでください。Lotus Traveler はコンソール・コマンドを使用してのみ管理できます¬。

トラブルシューティング 携帯端末に問題がある場合、1 人のユーザーの問題か、すべてのユーザーの問題かを確認し

てください。こうすることにより、デバイスのソリューションを検索するか、サーバーのソリューショ

ンを検索するかがわかります。

も多い問題は、autosync が動作していないことです。ほとんどの場合、携帯端末を再起動す

ると、この問題は解決されます。

1 人のユーザーのみの問題の場合、Web ブラウザーを使用してこのユーザーの証明情報で Traveler サーバーにログインします。問題を調査するにつれ、助けになる重要な追加情報が見

つかる場合があります。

Lotus Traveler コンソール・コマンドを使用して、このデバイス/ユーザーのログを追加

できます。問題が解決されたら、忘れずにロギングを無効にします。これが有効だと、

50

デバッグ XML ファイルがサーバーに生成され、ディスク・スペースを消費します。

サーバー全体が機能しない場合、JAVA エラーのコンソールを検索し、IBM サポートからソ

リューションを検索します。Traveler を再インストールするという方法もあります。再インストー

ルには多くの時間はかかりません。また、問題を修正でき、失った Traveler のコンポーネント

も修復できます。

トラブルシューティングについて詳しくは下記の参照をご覧ください。

• Administering Lotus Notes Traveler 8.5.2 / Server troubleshooting • Using Lotus Notes Traveler 8.5.2 / Troubleshooting, known limitations, and

restrictions: LNT8521 • Technote 1450615

Lotus Traveler コンソール・コマンドについて詳しくは下記のリンクをご覧ください。 Administering Lotus Notes Traveler 8.5.2 / Console commands

1.9.2.BlackBerry

Domino および BES の情報を探している場合、Domino Release/Server OS および BES を示す以下の表を参照してください。 BlackBerry® Enterprise Server for IBM® Lotus® Domino® Compatibility Matrix

Blackberry Enterprise Server をインストールする前の Domino Server の Windows サーバーへのインストール Domino Server のインストールは、Blackberry Enterprise Server をインストールするサーバー

で行うことをお勧めします。このインストールを行うと管理が簡単になります。

このインストールは、下記に示すように、通常の Domino のインストールに従います。

1. 新しいサーバーのサーバー・ドキュメントが作成済みで、Domino Directory に存在するかどう

か確認します。 2. Domino サーバーの作成の準備をし、Server ID ファイル、Domino サーバー実行ファイル、

および Domino システム・ファイルをサーバー上の一時的な場所に置きます。 3. 自己解凍インストール実行ファイルを実行し、プロンプト表示される質問に回答して

Domino サーバー・コードをインストールします。 4. 一時的な場所から恒久的な場所にファイルをコピーまたは移動します。 5. コマンド・プロンプトを開いて、システム・ファイルで圧縮を実行します。ncompact - D

filename.nsf を使用します (詳細は圧縮オプション)。 6. サーバー・プログラム・アイコンをダブルクリックし、プロンプト表示される質問に回答して

Domino サーバーを構成します。 7. Domino サーバー・プログラム・アイコンをクリックして、サーバーを初めて起動します。

サーバーは、BES をインストールする準備ができています。

51

環境の準備

環境を準備するには、以下の手順を実行します (これは今後の問題の防止に役立ちます)。

• Domino Server が Domino Directory の LocalDomainServer グループのメンバーかどう

かおよび Adminp が実行中かどうか確認します。admin4.nsf を開きます。 • サーバーが同一環境内にある他のサーバーにアクセスできるかどうかを確認します。 • BlackBerry Enterprise Server のセットアップ・アプリケーションが Domino の環境変数に

アクセスできるかどうかを、NOTES.INI ファイルで調べます。 • リモートの DB2 またはSQL Server にアクセスできることを確認します。このステップは、

SQL 環境または DB2 環境での認証に Blackberry Manager を使用するように選択した場合に実行する必要があります。

確認するには、「CMD」と入力してから「telnet 1433」と入力します。接続していれば、カーソル

が点滅します。カーソルが点滅している場合は、サーバーに接続できるため、コマンド・プロンプ

トを閉じます。

Blackberry Enterprise Server のインストール後の作業 BES のインストール完了後に、Domino が正常に稼働していることを確認するには、「

Message sent to handheld」、「OTAFM」、「OTAC」などのメッセージが表示されていないか、

コンソールで確認します。これらのメッセージは、サーバーから環境にメッセージが流れている

ことを示します。

メッセージの配信後にBlackberry Controller を始動します。これによって、サーバー上で nbes および domino が再始動する原因となるサイレント・クラッシュが防止されます。

ディスパッチャーが起動しない場合は、SQL 環境またはDB2 環境を調べる必要があります。

ほとんどの場合、問題の原因は BES とサーバーの接続にあります。

SQL/DB2 を保持している SQL マシンのリサイクルを実行することが必要になる場合もあり

ます。NBES は、BES for Domino を始動するDomino タスクに関連しています。Domino コンソールで「load nbes」コマンドを使用して始動したものを終了するには、Domino コン

ソールで「tell nbes quit」コマンドを使用します。

Blackberry Controller は、サーバーがユーザーを初期化しているときに停止できます。始動

するのは、すべてのユーザーが初期化され、メールが正常に流れるようになってからにする必

要があります。停止/始動はいつ行っても、サイレント・クラッシュ (予期しないリブート) を防止

できます。

問題のあるBlackberry 状態データベースの検索 Blackberry サーバーがクラッシュした場合、エンド・ユーザーの Blackberry 状態データベース

に原因があることが多くあります。問題のある場所を見つけるには、以下の手順を実行します。

• コンソールのログ・ファイルから、問題のスレッドID を見つけます。

[1114:000D-1384] Thread=[1114:000D-1384] Stack base=0x07110090, Stack size = 12068 bytes PANIC: LookupHandle: null handle

52

• NSD で「FATAL」を検索して、確認すべき問題のスレッド ID を見つけます。 • クラッシュが複数回発生した場合は、問題の原因となっているのが同じファイルであるこ

とを確認するために、複数のNSD をチェックすることもできます。

FATAL THREAD with PARAMETER DATA 12/143 [ nserver: 1114: 1384]

• NSD で「Open Databases」を検索して、問題のスレッド ID が記述されたファイルを探し

ます。 [Domino のインストール・ディレクトリー]\data\BES\state\123456789.nsf Version = 43.0 SizeLimit = 0, WarningThreshold = 0 ReplicaID = 0x87256f00:0x004b5bba bContQueue = NSFPool [ 000f6545] Offline = No DeleteInProgress = No FDGHandle = 0xf0240409, RefCnt = 1, Dirty = N DB Sem = (FRWSEM:0x0244) state=-1, waiters=0, refcnt=1, nlrdrs=0 Writer=[ nserver: 1114: 1384] SemContQueue ( RWSEM:#0:0x029d) rdcnt=-1, refcnt=1 Writer=[ nserver: 1114: 1384], n=0, wcnt=0, Users=-1, Owner=[ nserver: 1114: 1384] By: [ nserver: 1114: 000d] DBH= 154, User=CN=COMPANY/NEWORG

• NSD から入手した情報により、サーバーがクラッシュした原因が123456789.nsf ファイ

ルであることがわかります。

問題のあるBlackberry 状態データベースの修正

問題のあるデータベースは、以下のオプションのいずれかを実行することによって修正で

きます (ご自分の環境に適用できるオプションがどれであるかを判断する必要がありま

す)。

• 問題のある.NSF ファイルを削除するか、または名前変更して、再作成する。 • Domino コンソールを使用し、DB に対して保守 (fixup、compact、または updall) を実

行する。

詳しくは、下記の RIM Web サイトに記載されている「Tips and Tricks」を参照してください。 BlackBerry / Tips and Tricks

1.9.3. Lotus iNotes Ultra-Lite

Lotus iNotes Ulta-Lite はモバイル・デバイス向けのものであり、旧来のPC ブラウザーとともに

使用することもできます。参考資料は、Technote 1315871 にアクセスしてください。

Lotus iNotes が稼働するクライアント・オペレーティング・システムは以下のとおりです。

• Microsoft Windows XP Professional および Microsoft Windows Vista の Business Edition と Enterprise Edition で、ブラウザーには Internet Explorer または Mozilla Firefox を使用

• Novell SUSE Linux Enterprise Desktop 10 で、ブラウザーには Mozilla Firefox を使用

• RedHat Enterprise Linux Desktop 5.2 で、ブラウザーには Mozilla Firefox を使用

• Macintosh OS X 10.5 で、ブラウザーにはMozilla Firefox および Safari 3.1.x を使用

• Apple iPhone およびiPod Touch ファームウェアのバージョン 1.1.4 以降 (ウルトラライト・

モード用)

Web ブラウザーを使用するデバイスでメールを構成または使用可能にするという、移動

性に対する要求が高まっています。iNotes を使用可能にする際には、以下の設定が使

用可能/構成済みになっていることを確認します。

• エンド・ユーザーのメール・ファイル:

ACL to Anonymous=No Access ACL Advanced tab = Maximum Internet access to Editor.

• サーバーのアドレス帳: Domino 851 以上に設定する必要があります

• Forms85.nsf ファイル サーバーの iNotes ディレクトリーに配置されている唯一の Formsxx.nsf にする必要があります。 そのようにしていないと、ブラウザーで開いたときにエンド・ユーザーの問題が発生する可能性があります。古い Formsxx.nsf がリストされていたら、古いインストールから忘れずに除去してください。

図 17

• (古いファイルの除去など) FormsXX に変更を行う場合には、サーバーに HTTP を再

ロード (restart task http) する必要があります。このコマンドを実行しないと、インター

ネット・ブラウザーでメール・ファイルを開こうとしたときに「読み取り専用」というエラーが

返されます。

• ディレクトリー・アシスタント・ファイル

これは、使用可能な 新テンプレート上に置いてある必要があります。

• SSL の設定:

必要なファイル (.kyr ファイルと.sth ファイル) を Domino Data ディレクトリーにコピーすることによって、SSL 証明書をインストールします。 ご使用のサーバーのサーバー文書を開いて、「Configuration（設定）」 -> 「Servers（サーバー）」 -> 「All Servers（すべてのサーバー）」 -> ご使用のサーバー -> 「Ports（ポート）」 -> 「Internet Ports（インターネットポート）」タブに進み、SSL キー・ファイル名

を入力します。SSL ポートが使用可能になっていることも確認してください。

• HTTP Config

• このサーバーで使用されるホスト名および IP アドレス、またはそのいずれかを定

義します。 そのためには、アドレス帳を開いて、「Configuration（設定）」 -> 「Servers（サーバー）」 -> 「All Servers（すべてのサーバー）」 -> ご使用のサー

バー -> 「Internet Protocols（インターネットプロトコル）」 ->「HTTP」に進みます。 「Bind to host name（ホスト名へのバインド）」フィールドにenabled（有効）を設定

53

し、「Hostname(s)（ホスト名）」フィールドに、ご使用のサーバーの適切なホスト名

および IP アドレス、またはそのいずれかを設定します。 • サーバーにホーム URL を設定します。詳しくは、『3.14 Lotus iNotes ユーザー

のリダイレクト・アプリケーションの設定』を参照してください。以下に例を示します。 https://yourservername/homepage.nsf?Open

• Domino サーバーの妨げになるような、他の http タスクを、オペレーティング・シ

ステムが実行していないことを確認します。 実行している場合は、そのタスクを無

効にしてから Domino の http サーバーを使用可能にします。この操作を行わな

いと、Domino はポート 80/443 を使用できなくなります。

• HTTP と SSL が適切に動作していることの確認: Domino Administrator クライアントを介して、アクティブなタスクをレビューします。

HTTP タスクが実行中であることを確認します。 SSL 接続が使用中であることを確認するには、 http://使用しているサーバーのアドレス という構文を使用してサーバーにアクセスし、ブラウザーの 下部に小さな

ロックが表示されていることを確認します。

図 18

詳しくは、Lotus iNotes ウルトラライトモードを参照してください。

1.9.4. IMAP/POP

IMAP の概要

メッセージの見出しと送信者だけを表示してから、メールをダウンロードするか判断することが

できます。サーバー上にフォルダーまたはメールボックスを作成して操作したり、メッセージを

削除したり、メッセージの一部または全体を検索することもできます。

Domino IMAP のユーザーができる操作は以下のとおりです。

• IMAP サービスを実行しているサーバーからメッセージを複製して、エンド・ユーザーの

ローカル・レプリカに保管する。 • サーバーからメッセージに直接アクセスする (メッセージを 初にダウンロードした POP3

ユーザーとは別)。

POP3 の概要

Post Office Protocol 3 (POP3) は、旧式であまり高度でない E メール・プロトコルです。メー

ルを読むと、そのすべてがコンピューターに直ちにダウンロードされ、サーバー上には残らな

くなります。これは、ハードウェアの障害、ウィルス、またはユーザーの好みにより、サーバー

上または別のコンピューター上にあるメールボックスにアクセスしたい場合に問題となる可能

性があります。

54

55

プロトコルとしては、POP3 でなく IMAP を使用することをお勧めします。それは、両方のプ

ロトコルを有効にした場合、Domino を実行しているサーバーのパフォーマンスが低下する

可能性があるためです。その他に考慮すべき点としては、以下のようなものがあります。

• POP3 を使用する場合は、エンド・ユーザーのコンピューターに対して強制的に、サー

バーに接続させ、Push/Pull を開始してメッセージをエンド・ユーザーのコンピューターに

送信させます。 • IMAP を使用する場合は、エンド・ユーザーがローカル・レプリカとサーバーを同期化する対

象は新規メッセージのみです。これによって、サーバーが長時間にわたって同期モードと

なってサーバーの CPU が消費される事態が避けられます。 • 他に検討を要する点としては、CPU に問題が発生しないようにするために、メッセージは

MIME で保管するということが挙げられます。

パフォーマンスについて詳しくは、以下にアクセスしてください。

• Technote 1240413 • POP3 ユーザーのユーザー文書を設定する • メールファイルへの IMAP アクセスを準備する

56

第 2 章 ユーザーとクライアントの管理

2.1. Lotus Notes クライアント管理の 適化のヒント

Domino 管理者としては、ユーザーが生産的に作業できて満足してもらうには、Lotus Notes クライアントが適切に動作していることが必要です。パフォーマンスを 適にし、 新の情報を伝

えるようにクライアントを構成しておくことが重要です。これらの目標を達成するために役立つ

ツールが数多く用意されています。この記事では、これらの機能を紹介し、これらのトピックに関

する 適の文書を参照できるような情報を提供します。

2.1.1. クライアント/ユーザー管理の全般的なヒント

• インストールに際して使用可能なオプションについて理解しておきます。 クライアントを、

手動でインストールするか、または自動的にデプロイする必要があります。詳しくは、

Domino wiki の記事『Notes Client Deployment』または IBM Redpaper 『Distributing Notes Clients Automatically』を参照してください。Lotus Notes のインストールをカスタ

マイズすることもできます。『Roadmap: Customizing your Notes client installation』を

参照してください。

• Lotus Notes は極めて強力なソフトウェアですが、その機能の多くについて使用方法を認

識していないユーザー、またはそうした機能が存在していること自体に気付いていない

ユーザーも多いようです。この問題は、エンド・ユーザーへのトレーニングで解決します。

サード・パーティー・ベンダー、YouTube などのソースからの無料ビデオ、または IBM Multimedia Library を使用することで、多くのオプションを利用できます。また、Domino wiki には、Learning Lotus Notes clients に関する各種ビデオが用意されています。

• バージョン 8.0 から、"Basic" クライアントの概念が導入されました。Standard クライアン

トは Eclipse ベースであり、前のバージョンの Lotus Notes Client からフットプリントが増

しています。詳しくは、Technote 1264877 を参照してください。

• どのようなクライアント・タイプを使用するか、どの機能が利用可能かを理解しようとすると、

混乱することがあります。Domino wiki には、この作業をわかりやすくするために、Feature comparison between Lotus Notes Traveler 8.5, Lotus iNotes 8.5, Lotus Notes 8.5 Standard, and Lotus Notes 8.5 Basic Configuration が提供されています。

• Domino Smart Upgrade 機能を使用すると、クライアントの更新が簡略化されます。Smart

Upgrade を使用することで、メンテナンス・リリースやフィックス・パックなどのパッチをインス

トールすることができます。詳しくは、後述の Smart Upgrade に関するトピックを参照してく

ださい。

• クライアントについて理解します。自社で現在も使用されているクライアントのバージョンを

ご存知ですか。わからない場合は、ライセンス・トラッキング 機能を使用することで、その

答えが得られます。

• ユーザーが各自のメール・ファイルに対する編集者のアクセス権のみ持っていることを確認

します。これは、ユーザーが ACL 許可を変更したり、他のアクセス権を取得したりするのを

防ぐだけでなく、ユーザーが誤って自分のメール・ファイルを削除しないようにするうえで重

要です。ACL のアクセス・レベルに関する情報については、InfoCenter を参照してください。

57

ただし、編集者のアクセス権であっても、ユーザーは、メールおよびカレンダー機能におけ

る 委任 機能を使用できます。 また、ユーザーにサーバー上のメール・ファイルに対する編

集者のアクセス権を付与することで、ユーザーが自分のメール・ファイルに全文索引を作成

するのを防ぎます。この対応は、環境内のすべての全文索引が、サーバーへの影響が

小限になる方法で作成されるようにするために推奨されます。

• アプリケーションのロールアウトを自動化できることをご存知でしたか。まだアプリケー

ションのリンクをユーザーに送信したり、リモート・ユーザーのローカル・レプリカを手作

業で作成している場合は、より簡単な方法があります。ポリシーを使用することで、ブッ

クマークを追加したり、データベースが自動的にクライアントに複製されるようにすること

ができます。詳しくは、「2.3 ポリシー 」を参照してください

• 未読マークの処理は、わかりにくいことがあります例えば、未読マークはテーブルに格納さ

れることをご存知ですか。また、未読マークはユーザーに固有であり、複製できないことは

ご存知ですか。未読マークの機能および利用可能なオプションについては、Technote 1140018 を参照してください。

• ローカル・レプリカとモバイル・ディレクトリー・カタログを使用すると、ユーザーによるオフライ

ンでのメールの送信やディレクトリー検索の実行を許可することができます。詳しくは、ローカ

ル・レプリカに関する後述の説明と、この wiki の「3.4 複数のディレクトリー」を参照してくださ

い。

• ユーザーに影響を及ぼすクライアントの問題を認識しますそのためには、自動診断データ

収集 (ADC) 機能を必要に応じて設定します。ADC を使用すると、Lotus Notes Client がクラッシュした場合でも、NSD などの関連する診断データが、Domino Server の障害復旧

用のデータベースに送信されるため、確認することができます。これにより、クラッシュを簡

単に監視して、分類することが可能です。詳しくは、Technote 1085850 を参照してください

。

• 保守タスク (fixup、updall、compact) を Lotus Notes Client で実行できます。これらの

タスクは、クライアントの実行可能ディレクトリー内にあり、名前が "n" で始まります (例: nfixup.exe、ncompact.exe、nupdall.exe)。これらのスイッチは、サーバーの場合と同じ

です。

2.1.2. 近使用した連絡先

Lotus Notes Client バージョン 8 から、 近使用した連絡先の概念が導入されました。 近

使用した連絡先を使用すると、メールの送信/交換相手が、自動的に " 近使用した連絡先" リストに追加されます。また、 近使用した連絡先の他に、アドレスの入力補完機能も拡張さ

れました。アドレスの入力補完機能は、メッセージの宛先を入力するときに、より頻繁に使う

連絡先がリストの先頭となる順序で結果が提供されます。 この機能は、便利で時間の節約になる場合もありますが、いくつかの短所も考えられます。例え

ば、メールを交換した相手が新しい電子メール・アドレスを取得した場合、新しいエントリーが

近使用した連絡先リストに追加されますが、古いアドレスもそのまま残ります。このため、アドレ

スの入力補完機能を使用するときに困る場合があります。古いアドレスに電子メールを送信しな

いようにするには、古いアドレスを削除してください。 近使用した連絡先の機能と、この機能を

無効にする方法の詳細は、 近使用した連絡先に関する FAQ のページを参照してください。

2.1.3. ローカル・ レプリカ

メールへのアクセスにローカル・レプリカを使用することが、ここ何年かでより一般的な選択肢と

なりました。その理由は、クライアントがローカル・レプリカとディレクトリー・カタログで適切に設

58

定されることによって、ユーザーがどこからでもオンラインまたはオフラインで各自のメールにア

クセスできるようになることを考えると、簡単に理解できます。また、ローカル・レプリカを使用し

て作業するユーザーの場合、サーバー上のメールに直接アクセスするユーザーと比べて、処

理に必要なサーバーのメモリーと CPU の消費が抑えられます。その結果、サーバー・ベース

のメール・ファイルからローカルのメール・ファイルに移行する場合に、より多くのユーザーを

サーバーに追加したり、アップグレードを延期したりすることができます。この説明を聞くとすぐ、

"クライアントごとに設定するのはめんどうだ"、"ユーザーは、新しいメールをすぐ確認できない

ことに不満を言うだろう"、"ローカルにメールが複製されると、PC やラップトップが盗難に遭った

場合に、そのデータを誰かに読まれる可能性があり、セキュリティ・リスクにつながる" といった

ことが思い浮かぶでしょう。

しかし、心配はいりません。Domino 8.5 は、これらの懸念を解消します。デスクトップ・ポリ

シーを使用することで、ローカル・レプリカのデプロイ、デフォルトの複製スケジュールの設定、

確実なデータの暗号化を、クライアント上で自動的に行うことができます。さらに、Domino 8.5.2 では、管理対象メール・レプリカという機能によって、ローカル・レプリカが機能拡張され

ています。管理対象メール・レプリカ機能を使用すると、以下のことが可能になります。

• 何らかの理由でレプリカが利用できない場合、ユーザーは自動的にサーバーにリダイレ

クトされます。 • すべてのメールがクライアントに複製される必要はありません。また、メールを "オンデマンド"

でサーバーから取得することもできます。 • メッセージの受信と同時に複製が行われるようにすることができます。

管理対象メール・レプリカ機能を有効にするだけで、ローカル・レプリカを使用する短所が解消

されます。サーバー・ベースのメール・ファイルの使用と比較したローカル・レプリカや管理対

象レプリカの使用に関する詳細は、次の記事を参照してください。 IBM Lotus Notes and Domino 8.x local mail replicas: Advantages, considerations, and best practices

管理対象メール・レプリカに関する詳細は、次の記事を参照してください。Technote 1437957 Managed Mail Replica:Use Mail free of network delays and server outages

2.1.4.Smart Upgrade

Smart Upgrade は、ユーザーにクライアントを 新のリリースに更新して、インストールを実行

するように通知するプロセスです。Smart Upgrade の使用について学習する際に、見落としが

ちな重要ポイントが 1 つあります。ポリシーは、(推奨されてはいますが) Smart Upgrade を使

用するうえで必須ではありません (Technote 1110051 参照) 。 この点を、Smart Upgrade の学習とインプリメントにおいて念頭に置くことで、管理者の準備が整う前にユーザーのアップグ

レードが行われることによる問題を回避することができます。

Smart Upgrade を使用するための前提条件は、次のとおりです。

• Lotus Notes Client (version 6 以上) がインストール済みであること • Domino Server への接続性 • Smart Upgrade データベース • Smart Upgrade データベースがサーバー設定文書で定義済みであること

詳しくは、次の記事を参照してください。

59

• Understanding Lotus Notes Smart Upgrade • Notes Client Deployment • Smart Update アプリケーションを作成する • How to deploy non-versioned patches via SmartUpgrade

60

2.2. ユーザーの受信ボックスの管理

メール・ファイルの受信ボックスに含まれるドキュメントの数が多くなると、Domino メール・サー

バーに余計な処理が発生します。新しいメールが追加された場合や古いメールが削除された

場合、更新タスクは、ビュー索引内のソート順を維持するために、より多くの処理を実行しなけ

ればなりません。大規模な組織における数百または数千ものメール・ファイルの累積的な影響

を考えたとき、受信ボックスの管理が、環境のパフォーマンスと安定性の維持における重要な

要素となります。

ここでは、メール・ファイルの増え続けるサイズを管理する方法に関して、いくつかのヒント

を管理者向けに提供します。

2.2.1. 受信ボックスのクリーンアップを使用したメール・ファイルのサイズ管

理

受信ボックスのクリーンアップ機能は、メール・ファイル内のユーザーの受信ボックスのサイズを

削減することによって、サーバーのパフォーマンスを向上することを目的としています。これには、

$Inboxのビュー索引のサイズを削減する効果があるだけでなく、更新タスクが実行しなければ

ならない処理の量を削減する効果もあります。

受信ボックスのクリーンアップ機能を有効にすると、管理プロセスが、各ユーザーのホーム・

メール・サーバーで受信ボックスの保守エージェントを定期的に実行します。受信ボックスの保

守エージェントは、メール・テンプレート MAIL8x.NTF にあります。このエージェントは、管理者

がサーバー文書またはメール・ポリシー設定文書に定義した設定に基づいて、受信ボックスか

らドキュメントを削除します。ただし、これらのドキュメントは、メール・ファイル内に保存されたま

まなので、すべての文書ビューからアクセスすることができます。

受信ボックスのクリーンアップ機能を有効にするには、2 通りの方法があり、いずれも Domino Directory (names.nsf) に含まれています。1 つ目は、サーバー文書です (「Server Tasks」 -> 「Administration Process」タブ)。2 つ目は、メール・ポリシー文書です (「Mail」 -> 「Basics」

タブ)。サーバー文書に指定されている各設定は、メール・ポリシー設定文書内の受信ボックス

の保守の各設定に優先します。そのため、管理者は、次の方針に基づいて 1 つの方法のみ選

択してください。

• 目的: 受信ボックスのクリーンアップをメール・サーバーでグローバルに実施する

(サーバー文書を使用) • 目的: 受信ボックスのクリーンアップを一部のユーザーまたはグループに対して選択的に実

施する(ポリシー文書を使用)

詳しくは、IBM Lotus Domino Administrator Information Center の『Using Inbox Maintenance to manage mail file size』を参照してください。

• Technote 1268166

61

2.2.2. 制限値の適用オプション

初心者向けのガイドについては、『Understanding Quotas for IBM Lotus Domino Mail Databases』を参照してください。

管理者はメール・ファイル制限値を実施する（またはしない）ために利用可能な多数のオプショ

ンを持っています。利用可能なオプションは、実施の強度において異なり、管理者が組織のポ

リシーを導入するのに役立ちます。管理者は、警告レベルと 大レベルの 2 つのしきい値、お

よび 大レベルを実施するか否かを設定できます。メール・ファイル・サイズ制限値を超過しそ

うであることを通知する早期の警告がユーザーの受信箱に送信されます。

管理者は、制限値実施の 3 つのオプションを持っています。これらのオプションは、図 1 で概説されおり、メール・ルーターが制限値を超過したユーザー宛てのメールをどのように扱う

かを説明しています。

制限値超過 の実施

説明

常に配信 制限値がメール・ルーターにより実施されない場合、これを使用します。

これはデフォルト設定です。

発信者に 配信しない

新しいメッセージが送信者に送信されず、戻ってきません。送信者は、

受信者のメール・ファイルがいっぱいだったため、メッセージが送信され

なかったことを通知されます。

メールを保持して、再

試行 新しいメッセージは mail.box に保持されます。動作を向上させるために

追加のオプションを設定する必要があります。大きいサイズのメッセージ

を長期間保持する場合、管理者はこの設定を使用すると、非常に大きな mail.box サイズになることに留意する必要があります。

詳しくは、IBM Lotus Domino Administrator Information Center にある、ルーターの制限値管理

の設定を参照してください。

2.2.3. DAOS 有効な 場合の制限値

構成済みのメール制限値または警告限界しきい値に従うかどうかを決定するために、メール・

ファイルのサイズを計算する際、サーバーは各ユーザーが添付ファイルの全体を所有してい

るものとして、DAOS を使用して、保存された添付ファイルを扱います。したがって、送信され

た全メッセージの添付ファイルの完全なサイズがメール・ファイル制限値のために計算されま

す。同様に、ユーザーがメッセージを削除する際、メッセージの完全なサイズがメール・ファイ

ル制限値から削除されます。

したがって、添付ファイル統合を使用するメール・データベースの実際のファイル・サイズは、

必ずしもその論理サイズを表しているわけではありません。例えば、ユーザーのメール・ファイ

ルの物理サイズがわずか 65MB でも、制限値の限界値である 100MB を超える可能性があ

ります。Technote 1405456 で DAOS がメール制限値によりどのように機能するかが説明さ

れています。

初期バージョンの Domino に慣れている管理者は、Domino Administrator の「Files」タブで

「Space Used（使用済みのスペース）」列を表示することができたかもしれません。 「Space Used（使用済みのスペース）」列は、空白のスペースではなく NSF ファイル内に保存された実

際のデータ量を示していました。Domino 8.5 が「Space Used（使用済みのスペース）」列が表

示される 後のバージョンです。詳細については、DAOS and The Space Used Column の wiki の記事をお読みください。

2.2.4. ローカル レプリカ 上での 制限値の実施

サーバーベースのレプリカで制限値が設定された場合、制限値はデフォルトではローカル・レ

プリカで実施されず、また制限値の警告通知も表示されません。管理者は、ユーザーがローカ

ル・レプリカ上で新しいメールのメッセージかカレンダーの招集を作成しようとするとき、制限値

の警告が表示されるように環境を構成できます。

Technote 1247798 でこの機能を実施する ための包括的な手順を案内しています。

2.3. ポリシー

Domino ポリシーをもう調べてみましたか？まだでしたら、お客様はまだポリシーがいかに強

力かを確認していません。ポリシーを使用するための多数の理由と数多くのポリシーの種類

があるため、お客様は、どのようにしてポリシーを開始すべきか疑問に思っているかもしれま

せん。

2.3.1. ポリシーの紹介

ポリシー文書の目的は、設定をユーザーに「割り当てる」ことです。「Registration (登録)」、

「Setup （セットアップ）」、「Desktop （デスクトップ）」、「Security （セキュリティ）」を含む Domino 8.5.x. で利用可能な多数の設定タイプがあります。各設定タイプのリストおよび定義

については、Domino Infocenter ポリシー のトピックを参照してください。

下記の 2 種類のポリシーがあります。

• 明示的 • 組織的

組織的ポリシーは、組織全体または組織単位に適用されるポリシーです。 例えば、お客様が架

空のソフトウェア会社の A 社に勤務している場合、お客様のユーザー名は User One/IT/Company A になる可能性があります。この例では、お客様は */IT/Company A か */Company A の組織的ポリシーを作成できます。

図 19

62

明示的ポリシーは、ユーザーに明示的に適用されるポリシーです。 これは、ユーザーの個人文

書内にポリシーが定義されているか、ポリシーがポリシー文書内でユーザーに割り当てられて

いることを意味している可能性があります。ポリシーをポリシー文書内でユーザーやグループに

割り当てる場合、ポリシーは動的ポリシーであると見なされます。動的ポリシーの詳細について

は、Domino wiki の記事「How the new Dynamic Group Policies can reduce your administration workload」を参照してください。 ポリシーの割り当ての詳細については、

Domino Administrator のヘルブ・トピック『ポリシーを計画して割り当てる』を参照してください。

図 20

2.3.2. ポリシーを使用したセキュリティ標準化と環境の簡略化

解決する必要がある問題 ポリシーの回答

下記のような企業のセキュリティ標準を実施する · x 日ごとにパスワードを変更 · パスワード 小長

組織のセキュリティ・ポリシー

デフォルトのパスワードとともにネットワーク・ドライブ

上に Notes.id ファイルが保存されていることによるセ

キュリティ・リスク

セキュア ID ファイルの保存のために割り

当てられた ID ボールトのある組織のセ

キュリティ・ポリシー

デフォルトで以下のようなお気に入りのカレンダー機能を有効にする。 · 新しい未処理のカレンダー、およびカレンダー内の文書の表示 · キャンセルされたミーティングをカレンダー内にキャンセルとして自動的に表示 · カレンダーに予約を追加したとき、衝突する予約がないか自動的に確認

組織のメール・ポリシー

全ユーザー用にサーバー側でのアーカイブを構成 組織のアーカイブ・ポリシー

新しいユーザーの登録の際は、全管理者が一貫した設定を使用するようにする

組織の登録ポリシー

ポリシーを使用して、多数の一般的な問題を容易に解決することができます。

63

64

自分のセールス・チームにローカルで新しい販売アプリケーションを複製する。

セールス・チームに割り当てられた動的デスクトップ・ポリシー。

すべての新規 Lotus Notes インストール用のデフォルト

設定を構成する 組織の設定ポリシー

モバイル・ユーザー向けのデフォルト設定を定義する ユーザーが Traveler によりサポートされる新し

い携帯機器を購入したとき、ユーザーに割り当

てられる動的 Traveler ポリシー クライアントがアップグレードしたとき、自動的にメール・

ファイルの設計をアップグレードする。 組織のデスクトップ・ポリシー

クライアントでリモート・ユーザー向けの NOTES.INI パラメーターを設定する

明示的デスクトップ・ポリシー

リストはまだまだ続きます。ポリシーは Domino の管理者にとって、親友にもなれば、 大

の頭痛の種にもなります。以下はポリシーのロールアウトを成功させるのに役立つ定義とヒ

ントです。

• 初にテストしてください。 新しい組織のポリシーをロールアウトする前に、明示的ポリ

シーを作成し、それを小グループのユーザーに割り当てます。順調に進んだら、残りの従

業員のための組織または組織単位のポリシーを作成します。

• 自分の組織の構造に基づいたポリシーを作成します。 マネージャー、従業員、および請

負業者のポリシーの実施は、あまりにも曖昧であるため、ほとんどの場合機能しません。

• 個人文書内に明示的に割り当てるのではなく、グループを介して、またはポリシー文書、

ポリシー割り当てタブ内で個々にポリシーを割り当てます。 個人文書内にポリシーを割

り当てると、時間がかかり、管理が難しくなります。

• エグゼクティブが必要とする場合、例外ポリシーを作成します。 ポリシーを特定するのに役

立つ詳細な説明を必ず含めます。また、読者のリストを使用して、一般ユーザーからグ

ループ文書を隠すことを推奨します。グループ文書の非表示設定の詳細については、大量

メール送信記事の文書のグループ化のためのアクセスの制限のセクションを参照してくだ

さい。

• 初にポリシーを学習するとき、使用言語が混乱している場合があります。 例えば、「組織

のセキュリティ・ポリシー」を作成するオプションはありません。このことは実際何を意味して

いるでしょうか？ポリシー・タイプが組織的の場合、ポリシー名は自分の組織に一致します。

例えば、*/organization では、図 21 に示すようにセキュリティ設定文書が適用されます。

図 21

• 「デスクトップ・ポリシー」がすべての場所の文書に適用されます。 特定の設定を単

一の場所に適用したい場合のみ、この変更を手動で行う必要があります。

• ポリシーには「元に戻す」機能がありません。 ポリシーが適用された場合、ポリシーを変更

して、新しい値を適用することはできますが、「元の値に戻す」という選択はありません。

• ポリシーを使用して、レプリカ・データベースやブックマークをクライアントにプッシュする場

合、ポリシーからデータベースのエントリーを取り除くことなしに、サーバー上のデータベー

スを削除することは絶対に行わないでください。 データベースまたはテンプレートを削除す

るときは、図 22 に示すように存在しないデータベースを指すポリシーの問題を防ぐために、

セーフティー・ネットとして必ずデータベースのリダイレクトを作成します。

65

図 22

• 環境について理解します。 ポリシーは、使用されているクライアントのバージョンにより、

異なる動作をします。これは、多数の新しい機能が後期のクライアントのバージョンで利

用可能になったとき、予想されています。クライアントがロールアウトしたい機能をサポー

トできることを確かめてください。

• ポリシーは多数のプロセスにより実施される場合があります。 アーカイブのポリシーは、

compact –a または compact –A の実行時に使用されます。メール・ポリシーは、12 時間

ごとに管理プロセス（adminp）によりロールアウトされるか、tell adminp process mailpolicy コマンドにより即座にロールアウトされます。 設定ポリシーは、 初のクライア

ントの設定中に読まれ、使用されます。残りのポリシー設定の種類は、Lotus Notes クライ

アントの動的クライアント構成（dcc）により実施されます。クライアントのステータス・バーに

「Notes configuration settings have been refreshed (Lotus Notes 構成設定が更新され

ました)」というエントリーが表示されていれば、特定の dcc が実行されていることを確認で

きます。

• ポリシーはユーザーの「Contacts」データベース（names.nsf）内に保存されます。 この

データベースは、ポリシーを使用する際の問題を防ぐために、 新の設計を使用する必

要があります。

• iNotes 内で設定を管理するためにデスクトップ・ポリシーを使用するときは、 メール・ポリ

シー (Technote 1321866 参照) を持つ必要もあります これは、デスクトップ・ポリシーか

ら iNotes プロフィール文書を更新するのが adminp タスクのジョブであり、adminp がそ

のプロセスを実行するのは、メール・ポリシーが存在しているときのみであることが原因で

す。これは、デスクトップ・ポリシーから iNotes プロフィール文書を更新するのが adminp タスクのジョブであり、adminp がそのプロセスを実行するのは、メール・ポリシーが存在し

ているときのみであることが原因です。

• 設定文書内で初期値の設定の値を適用する方法を使用する際、設定する値は、ポリ

シーが 初に保存されたとき、またポリシーが変更されるか保存されたとき常に、クライ

アントにプッシュされます。

• ポリシーの署名は重要です。 ポリシーは、適切な権限と有効なキーを持つ管理者により

署名されたときのみ、適用および使用されます。そのため、管理 ID が有効期限切れにな

66

る前、または管理者が退職する前に、一般的な管理アカウントを使用してポリシーに署名

するか、ポリシーを破棄することを推奨します。図 23 に示すように Domino Administrator クライアント内のポリシーおよび設定のビューを使用して、ポリシーの署名

者および設定文書を確認します。ポリシーまたは設定文書を編集モードにして、それを保

存することにより、署名はお客様の署名で更新されます。

図 23

さまざまなポリシーの設定の詳細な説明および例については、Technote 7010310 を参

照するか、Domino Policies Demystified blog を確認してください。

67

68

第 3 章 効果的なサーバー管理

3.1. モニター

Domino 環境のモニターとは、環境とそのプロセス、およびそこに含まれる個々のタスクの反

復的かつ系統的な収集および管理を意味します。モニターの主な機能は、システムまたは環

境の特定のパラメーターが定義されている限度を超えているかどうかを確認し、アラートなど、

定義された方法で対処することです。

Domino は高度に構成可能な特性を持ち、さまざまなタスクを実行できるため、この記事では、

Domino 環境の も一般的なコンポーネントを対象とするモニター戦略を定義することを目的と

します。このモニター戦略は、ベースラインとして扱われ、ご使用の固有の Domino 環境に対

応するためには、さらにカスタマイズが必要となります。

3.1.1.モニター・オプション

すべてのお客様に対して、同一のソリューション、または同一のツールをお勧めするものでは

ありません。大規模な Domino実装や使用率の高い Domino には、当然、規模の小さい Domino 環境とは異なる要件があります。

IBM では、次のモニター・オプションを用意しています。

• サーバー・モニター

これは、Lotus Domino Administrator クライアントに組み込まれている基本的なモニター・オプションです。小規模な環境に、あるいは次のいずれかのソリューションの追加モニターとして適しています。

• Domino ドメイン・モニター (DDM) これは、Lotus Domino に組み込まれ、デフォルトで使用可能なサーバー機能です。ランタイムの問題の検出、把握、および対応に適しています。 DDM プローブはイベントを記録します。管理者は記録されているイベントを確認する必要があります。イベント生成プログラムとイベント・ハンドラーを、統計収集とともに 使用して、Domino 環境を監視できます。これらの扱い方については、以下を参照してください。 Domino 6 monitoring and statistics

• IBM Tivoli ITCAM for Applications これは、エンタープライズ・クラスのモニター・ソリューションの一部であり、非常にスケーラブルで、Lotus Domino 単独の場合よりはるかに多くのモニターが可能です。 この機能は、エージェントベースでもエージェントを使用しなくてもデプロイできます。これはサーバー、メール・ルーティング、複製、カレンダー、データベース、クラスターなど、Lotus Domino の主要コンポーネントのパフォーマンス・モニターに焦点を絞ったベスト・プラクティス・モデルを活用します。より高度な Domino 管理機能が、IntelliWatch で利用可能です。Tivoli Composite Application Manager for Applications / One integrated solution to manage a broad set of applications and application instructures

• IBM Tivoli Intelliwatch Pinnacle for Distributed Systems これには、問題の自動検出および修正、システム規模の製品構成オプション、カスタムのレポート機能、フォールト・リカバリーなどが含まれます。詳細については、以下を参照してください。 Tivoli IntelliWatch Pinnacle for Distributed Systems / Automate the management of your Lotus Domino environment

69

他にも、ここにリストされていない使用可能なサード・パーティーのソリューションもあります。

3.1.2.モニターの対象

モニター対象を Lotus Domino 自体というアプリケーションに限定してしまうのではなく、その

他多くのコンポーネントもモニターし、それらの動作を確認して、まったく異なる領域で生じた問

題の分析に時間をかかないようにする必要があります。

次のリストに、モニターする必要のある要素の概要を示します。

• ネットワーク (LAN / WAN) • プラットフォーム (ハードウェア、オペレーティング・システム) • ストレージおよびバックアップ環境 • アプリケーションとそのコンポーネント

この記事では、この 後の部分の「アプリケーション」、ここでは Lotus Domino に焦点を当てま

す。

3.1.3.Domino のプロファイルのモニター

参照しやすいように、さまざまなモニター・プロファイルを 1 つの環境内に定義します。このよう

にしてモニターをグループ化することにより、Domino 環境内の特定のサーバー構成または機

能に適用可能なプロファイルを作成できます。

次のサーバーの役割を例とします。

• 汎用 Domino サーバー – すべての Domino サーバーに適用。 • メール・サーバー - エンド・ユーザーのメールボックスをホストするサーバー。 • Web サーバー – Web サイト (HTTP サービス) をホストするサーバー。 • クラスター・サーバー – クラスター・サービスを提供するサーバー。 • 特殊アプリケーション・サーバー - 追加サービスを提供するサーバー。

ご使用の環境のニーズに基づいて追加プロファイルを定義できます。追加サーバー・プロファイ

ルを文書化し、いつ、どのモニター・プロファイルを使用するかという定義を含めるようにします。

アクション イベントや問題の発生時にアクションを実行しなければ、モニター自体は無意味です。これら

のアクションは、応答レベルごとでも、イベントごとでも、詳細に定義できます。 も重要また

は便利なアクションは、企業の環境によって異なります。

小規模な Lotus Domino 実装では、管理者に後でアクションを実行するようにメールするだけ

で十分な場合もあります。大規模な環境では、年中無休のモニターおよびアラートをサポートす

るソリューションが必要な場合もあります。このシナリオでは、Lotus Domino のモニター結果を

企業規模のモニター・システムまたはヘルプ・デスク・システムに統合する必要が生じることも多

くあります。

アクションは、環境のサイズや、アラートまたはチケット管理のためのシステムの可用性など、

さまざまな要因によって異なります。

Lotus Domino は、例えばカスタムのヘルプ・デスク・アプリケーションでヘルプ・デスク・チケッ

トを自動的に開くなどのため、サード・パーティー・システムへのカスタムの統合の構築にも使

用できる数多くの通知アクションをサポートします。

図 24 に、イベント・ハンドラー・メソッドを示します。

図 24

Tivoli Enterprise Console がすでに使用可能な場合は、このコンソールへのイベントの転送

をお勧めします。中規模および大規模の Lotus Domino インストールの場合、ほとんどこれに

該当します。

ヒント:携帯電話アラート 携帯電話アラートを受信するため、一部のプロバイダーがサポートしている特殊な携帯電話

構成があります。プロバイダーには、電子メール・メッセージをテキスト・メッセージ (SMS) とし

て電話に転送するように要求できます。これにより、クリティカルなイベントが発生した場合、

SMS を介して管理者に通知することが可能となります。適切に構成されていれば、携帯電話

は SMS 形式で電子メール・メッセージを受信することができます。電子メールは、プロバイ

ダーが定義した特定の電子メール・アドレスおよびドメイン名に宛先を指定する必要がありま

す。

ほとんどの場合、これは、携帯電話番号の後にプロバイダーのゲートウェイ・ドメイン名が続い

たものです。例えば、0123456789.. のようになります。この構成を有効にする方法について詳

しくは、携帯電話事業者にお尋ねください。これにより電話料金に追加費用が加算される場合

があります。

同じイベントについて複数の人に通知するには、Domino ディレクトリーにこれらの特殊電子メー

ルアドレスのリストを含むグループ (“AdminAlert-HTTPServers” など) を作成します。

70

応答レベルの重大度レベルへのマッピング この記事で後述する構成の詳細についての理解を深めるため、応答レベルをヘルプ・デス

ク・システムで広く使用される重大度レベルにマップします。

応答

レベル 重大度

レベル 説明

該当なし 重大度 1 も高いレベルの注意が必要です。ビジネスへの重大な影響が予測されます。

致命的 重大度 2 高いレベルの注意が必要です。システムは機能していますが、何もアクションが実行されない場合、サービスの中断につながる可能性があります。

クリティカル 重大度 3 Domino 管理者の注意が必要です。タイムリーに処理さ

れない場合、問題が大きくなる可能性があります。

警告 重大度 4 管理者の注意が必要ですが、緊急を要するものではありません。

リセット 該当なし 以前の重要度は、すでに安定しています。

71

プロファイル:汎用 デフォルトのモニター・プロファイルは、指定された役割かどうかに関係なく、すべての Domino サーバーに適用されます。

一般に、モニターがサーバー機能に影響を与えるほどに重要でクリティカルであると見なされ

る場合、モニター間隔は 5 分または 10 分に設定できます。その他の場合、間隔は 1 時間が

一般的です。

モニター名 応答レベル トリガー 詳細および 間隔

メール・プローブ 警告 (高) タイムアウト時 メール送信モニ

ター・プローブ

送信間隔 10 分

タイムアウトしきい

値:10 分

サーバーの可用性 致命的 (非クラス

ター化サーバー)

クリティカル (クラス

ター化サーバー)

リセット

使用不可能

使用可能

TCP イベント モニター

5 分ごと

タスク「adminp」 致命的

リセット

使用不可に なったとき

使用可能に なったとき

タスク・ステータス モニター

間隔:毎時

タスク「event」 致命的

リセット

使用不可に なったとき

使用可能に なったとき

タスク・ステータス モニター

間隔:10 分ごと

汎用 Domino サーバー・プロファイルには、次のモニターが含まれます。

72

73

タスク「amgr」 致命的

リセット

使用不可に なったとき

使用可能に なったとき

タスク・ステータス モニター

間隔:10 分ごと

タスク「stats」 障害

リセット

使用不可に なったとき

使用可能に なったとき

タスク・ステータス モニター

間隔:10 分ごと

タスク「update」 致命的

リセット

使用不可に なったとき

使用可能に なったとき

タスク・ステータス モニター

間隔:10 分ごと

タスク「outer」 致命的

リセット

使用不可に なったとき

使用可能に なったとき

タスク・ステータス モニター

間隔:10 分ごと

タスク「replica」 致命的

リセット

使用不可に なったとき

使用可能に なったとき

タスク・ステータス モニター

間隔:10 分ごと

タスク「DAOSMgr」 致命的 使用不可に なったとき

タスク・ステータス モニター

間隔:10 分ごと

タスク「MTC」 致命的

リセット

使用不可に なったとき

使用可能に なったとき

タスク・ステータス モニター

間隔:10 分ごと

Domino 統計 「Replica.Failed」

警告

障害

10 増加

10 増加

統計イベント 生成プログラム

間隔:毎時

Domino 統計 「Server.Sessions.Dropp ed」

警告

障害

50 増加

100 増加

統計イベント 生成プログラム

間隔: 毎時

74

Domino 統計 「Server.Users」

警告

障害

X を超過

Y を超過

統計イベント 生成プログラム (サーバーの規模に

よって X または Y)

間隔:毎時

Domino 統計 「Agent.Hourly.Unsucces sfulRuns」

警告 0 を 超過

統計イベント 生成プログラム

間隔:毎時

詳細はTechnote 1232603 を参照

Domino 統計 「Agent.Daily.Unsuccessf ulRuns」

警告 0 を 超過

統計イベント 生成プログラム

間隔:日次

詳細はTechnote 1232603 を参照

ACL 変更 (names.nsf)

警告 (高) ACL 変更時

データベース・イベン

ト生成プログラム・モ

ニター ACL 変更

ファイル名: names.nsf

サーバー:範囲内のすべての Domino サーバー

ACL 変更 (Admin4.nsf)

警告 (高) ACL 変更時

データベース・イベン

ト生成プログラム・モ

ニター ACL 変更

ファイル名: admin4.nsf

サーバー:範囲内のすべての Domino サーバー

プロファイル:メール・サーバー 次のモニターは、メール・サーバーとして指定されたすべての Domino サーバーに適用されます。

• 汎用のモニター・プロファイル

モニター名 応答 レベル

トリガー 詳細および間隔

タスク「calconn」 致命的

リセット

使用不可に なったとき

使用可能に なったとき

タスク・ステータス モニター

間隔:10 分ごと

タスク「sched」 致命的

リセット

使用不可に なったとき

使用可能に なったとき

タスク・ステータス モニター

間隔:10 分ごと

Domino 統計 「Mail.Dead」

警告

障害

リセット

X を超過

Y を超過

X 未満に減少

統計イベント 生成プログラム

間隔:毎時

環境の規模によって X または Y

Domino 統計 「Mail.Waiting」

警告

致命的

X を超過

Y を超過

統計イベント 生成プログラム

間隔:10 分ごと

環境の規模によって X または Y

Domino 統計 「Mail.Trans..Failures」

警告

致命的

リセット

100 を超過

500 を超過

X 未満に減少

統計イベント 生成プログラム

間隔: 毎時

環境の規模によって X または Y

さらに、次のモニターが推奨されます。

プロファイル: Web サーバー 次のモニターは、Web サーバーとして指定されたすべての Domino サーバーに適用されます。

• 汎用のモニター・プロファイル • Domino メール・サーバー・モニターのプロファイル (必要な場合)

75

モニター名 応答 レベル

トリガー 詳細および間隔

タスク「http」 致命的

リセット

使用不可になったと

き 使用可能になったと

き

タスク・ステータス・モニター

間隔: 10 分ごと

Domino 統計 「HTTP.PeakConnections」

警告

障害

X を超過

Y を超過

統計イベント生成プログラム (サーバーのサイズによって X または Y)

間隔: 60 分ごと

詳細はTechnote 1232603 を参照

Domino 統計 「Domino.Threads.Active.Peak」

警告

障害

X を超過

Y を超過

統計イベント生成プログラム (サーバーのサイズによって X または Y)

間隔: 60 分ごと

詳細はTechnote 1232603 を参照

さらに、次のモニター・プロファイルを追加する必要があります。

プロファイル: Domino クラスター Domino クラスターとして構成された Domino Server には、基本プロファイルに加えて、次の Domino クラスター・サーバー・モニター・プロファイルを適用する必要があります。

• 汎用のモニター・プロファイル • Domino メール・サーバー・モニターのプロファイル (必要な場合)

モニター名 応答レベル トリガー 詳細および間隔

タスク「clrepl」 致命的

リセット

使用不可になっ

たとき

使用可能になった

とき

タスク・ステータス・モニター

間隔: 10 分ごと

さらに、次のモニター・プロファイルを追加する必要があります。

76

77

タスク「cldbdir」 致命的

リセット

使用不可になっ

たとき

使用可能になった

とき

タスク・ステータス・モニ

ター

間隔: 10 分ごと

Domino 統計

「Replica.Cluster.Failed」 クリティカル

リセット

1

<1

統計イベント生成プログラ

ム

間隔: 60 分ごと

詳細は Technote 1232603 を参照

Domino 統計 「Server.Cluster.OpenRedirects.LoadBalanceByPath.Unsuccessful」

警告

クリティカル

致命的

リセット

1

5

10

<1

統計イベント生成プログラ

ム

間隔: 60 分ごと

詳細は Technote 1232603 を参照

Domino 統計 「Server.Cluster.OpenRedirects.LoadBalance. Unsuccessful」

警告

クリティカル

致命的

リセット

1

5

10

<1

統計イベント生成プログラ

ム (サーバーのサイズによって X または Y)

間隔: 60 分ごと

78

詳細は Technote 1232603 を参照

Domino 統計 「Server.Cluster.OpenRedirects\-.FailoverByPat h.Unsuccessful」

警告

クリティカル

致命的

リセット

1

5

10

<1

統計イベント生成プログラ

ム

間隔: 60 分ごと

詳細は Technote 1232603 を参照

Domino 統計 「Server.Cluster.OpenRedirects.Failover.Unsuccessful」

警告

クリティカル

致命的

リセット

1

5

10

<1

統計イベント生成プログラ

ム

間隔: 60 分ごと

詳細は Technote 1232603 を参照

Replica.Cluster.WorkQueueDepth.Avg

警告 500

統計イベント生成プログラ

ム

間隔: 60 分ごと

詳細は Technote 1232603 を参照

モニター・プロファイルの文書化の例

サーバー名 汎用 メール ハブ Web クラスター カスタム アプリケーショ

ン

ServerA/ITSO 使用可能 使用可能 使用可能

ServerB/ITSO 使用可能 使用可能

SametimeA/ITSO 使用可能

3.1.4.Domino イベントの モニター

上記のプロファイルはさまざまなモニター・システムに実装できますが、Domino Monitoring Configuration (events4.nsf) データベースから Lotus Domino イベントをモニ

ターすることが可能です。

表示される情報が多くなりすぎないように、管理者は次の表の定義に沿って、「致命的」、「障

害」、または「警告 (高)」に定義されているすべての Domino イベントをモニターする必要があ

ります。各イベント・タイプでは、各メッセージが重大度レベルによってさらに分類されます。

Lotus Domino サーバーでは、これらの重大度レベルを次のように定義しています。

重大度 レベル

応答 レベル

意味

致命的 致命的 システム・クラッシュの危険性が非常に高い。

障害 クリティカル システム・クラッシュには至らない重大な障害。

警告 (高)

警告 介入を必要とする機能喪失。

警告 (低)

該当なし パフォーマンスの低下。

正常 該当なし ステータス・メッセージ。

すべての 該当なし 上記のメッセージすべて。

79

良の成果を得るために、次のデフォルト設定を変更できます。

デフォルト設定の変更内容は、Lotus Domino のバージョン・アップグレード後に再適用できるよう

に、必ず文書化しておいてください。

値 テキスト 元のイベント

重大度 新しいイベン

ト重大度 原因

0x02CC データベースを圧

縮中です。使用の

前に圧縮を終了す

る必要がありま

す。

警告 (低)

正常 データベースを圧縮中で

す。使用の前に圧縮を終

了する必要があります。

0x0EA2 リカバリー・マネー

ジャー: 新しい DBIID の割り当て (メディア・リカバ

リー用に新しい

バックアップが必

要)

警告 (低)

正常 バックアップ・ソフトウェアで、このアプリケーションの新しいフル・バックアップを取得する必要があります。

0x0EA8 Recovery Manager: Restart Recovery complete. (%d/%d databases needed full/partial recovery)

警告 (低)

正常 サーバーの再起動 が完了

したことを示しているだけ

です。

0x0F13 データベースは現

在別のプロセスに

よって索引付けさ

れています。

警告 (低)

正常 単なる通知です。

0x0F3B Full Text Error (FTG): Exceeded max configured index size while indexing document NT%08lx in database index %p

警告 (高)

正常 大容量の添付ファイルに

全文索引を作成すること

はないので、このエラーは

正常です。

0x1104 受信者のユー

ザー名が固有で

はありません。Domino Directory 内に複

数の一致が見つ

かりました。

障害 正常 受信者は送信者によって

選択されるため、オフライ

ン送信時、またはクライア

ントによって検証されない E メール・アドレスへの送

信時には、何も対処できま

せん。

80

81

0x1105 Domino Directory にリ

ストされていな

いユーザーで

す

警告 (低)

正常 「SendTo」フィールドに間

違った名前を書き込んだ

ために障害が発生してい

ます。

0x1149 データベースの

メール・ルールを

登録中にエラー

が発生しました

警告 (高)

正常 ルールはユーザーが制

御します。毎回このエラー

を修正することはできま

せん。また、サーバーに

は影響ありません。

0x131B データベースの作成

警告 (低)

正常 単なる通知です。

0x131C データベースの削除

警告 (低)

正常 単なる通知です。

0x1321 サーバーへのアク

セスを試みました

が、拒否されまし

た

警告 (低)

正常 以前にはアクセスできた

などの理由で、多くの

ユーザーが、管理サー

バーやアクセス制限され

ているサーバーにアクセ

スを試みている可能性が

あります。

0x1323 ATTEMPT TO ACCESS DATABASE %p by %A was denied

警告 (高)

正常 正常 (ユーザーがカレン

ダーの詳細を表示しようと

したが、 パブリック・アクセス以上の権限を持っていない場合など)

0x1357 Failing over from %A for replica id %h, directing open to %A

警告 (低)

正常 ユーザーがクラスター・

サーバーにリダイレクトさ

れたことを示す通知で

す。

0x135C フェイルオーバー

して、リダイレクト

しています

警告 (低)

正常 ユーザーがクラスター・

サーバーにリダイレクトさ

れたことを示す通知で

す。

0x135E フェイルオーバー

をリダイレクトでき

ません

警告 (低)

正常 デ ー タ ベ ー ス を ク ラ ス

ター・サーバーにリダイレ

クトできなかったことを示

す通知です。 0x138C 現在は操作を実

行できません。

データベースの圧

縮処理中です。

警告 (低)

正常 圧縮中の正常なメッセージ

82

x1519 DDM レポート文

書 (NoteID 0x) を開くことができま

せんでした。

警告 (高)

正常 DDM レポートが手動で

削除された後、別のエ

ラー・インスタンスがログ

に記録されると、このエ

ラーが表示されます。

0x1614 レプリケータ

は %p を %p から初期化できま

せんでした。

障害 正常 レプリカ・スタブが作

成されるたびに発生

する障害です。

0x19FC アカウントがロック

されています。シス

テム管理者に確認

してリセットしてくだ

さい。

警告 (低)

正常 時間が経てば多くのユー

ザーがパスワードを忘れ

ます。これはユーザー自

身に解決してもらう問題

だと考えています。

0x330A 索引作成された

文書 ( バイト) 警告 (低)

正常 索引作成は正常です。

0x9AC0 LDAP サーバー:警告:バインド要求

時に無効な証明書

が指定されました。DN:

警告 (低)

正常 正常な動作です。Technote 1219847 を参照。

0x331A データベースは削

除用にマークさ

れ、削除されまし

た。

警告 (低)

正常 単なる通知です。

0x3320 管理プロセス:管理

サーバーとして指

定するデータベー

スの ACL には表

示されません

警告 (低)

正常 AdminP プロセスは正常です。

0x3327 管理サーバーとして

指定するデータベー

スの「Readers」ま

たは「Authors」

フィールドには表示

されません

警告 (低)

正常 AdminP プロセスは正常

です。

83

0x3346 データベースのトラン

ザクションがログ記

録されました。メディ

ア・リカバリー用にフ

ル・バックアップを実

行する必要がありま

す。

障害 正常 バックアップ・ソフトウェアで、このアプリケーションの新しいフル・バックアップを取得する必要があります。

0x336D ルーター:メッセー

ジに受信者が含ま

れていません

警告 (高)

正常 メッセージに受信者が指

定されていない場合の通

知。

0x33C4 読み込まれていない

データベースのリス

トには表示されませ

ん

.

警告 (低)

正常 AdminP プロセスは正常

です。

0x33E3 管理プロセス:管理

サーバーとして指定

するデータベースの

設計エレメントには

表示されません

警告 (高)

正常 AdminP プロセスは正常

です。

0x3032 指定した言語のすべ

てが設計テンプレー

トにはありませんでし

た

正常 警告 (高)

このエラーは処理する必

要があります。そうでなけ

れば、データベースの設

計更新に失敗します。

3.1.5.詳細 情報

DDM の使用方法と構成方法について詳しくは、次の Technote および IBM Redpaper を参照してください。

• Technote 7009312 • Lotus Domino Domain Monitoring

84

3.2. メール転送

Lotus Domino を使用している大部分の企業では、サーバーを使用してメールを転送します。こ

の記事では、Domino によるメール転送の概念を簡単に紹介し、Domono のメール環境の管理

方法に関して詳しく説明します。すでに数多くの優れたリソースが提供されているため、この記

事にはこうしたリソースへの参照も用意されています。

メール転送に必要なタスク、データベース、テンプレートの説明については、『Lotus Domino メー

ルサーバーとメール配信』を参照してください。

3.2.1.スパムの管理

Domino 管理者にとって も一般的な懸念事項はスパムへの対処法です。使用可能なリソー

スやオプションが多数用意されています。Domino サーバーの構成で使用可能なオプションに

ついては、「Controlling spam: Advanced SMTP settings in Lotus Domino」および

「Understanding SMTP authentication and securing your IBM Lotus Domino 8 server from spam」の各記事を参照してください。

SMTP の設定に加えて、サーバー・ベースのメール・ルールも作成し、メールをフィルターにか

かてください。メール・ルール作成の詳細については、Domino Infocenter のトピック「ルールに

基づいて新しいメールを振り分ける」を参照してください。

多くの企業では、Domino のセキュリティ機能に加えて、スパム・フィルタリングのサービスやソ

フトウェアを使用しています。Lotus Protector for Mail Security はその一例です。サード・パー

ティーのスパム・フィルタリング・サービスを使用している場合は、ベンダーから送信されたメー

ルのみを受け入れるようにサーバーを構成しなければならない場合があります。SMTP のインバウンド接続制御を使用すると、簡単にこれに対応できます。そのためには、ベンダーが使用し

ているホスト、IP アドレス、または IP 範囲のリストを入手する必要があります。その後、「次の SMTP インターネットホスト名/IP アドレスからの接続を拒否:」フィールドで、これらのエントリー

と内部ホストを定義することができます。この設定は、設定文書の「ルーター/SMTP」•「制限と制

御」•「SMTP インバウンド制御」タブにあります。図 25 に示す例では、インバウンド SMTP メー

ル接続を許可された IP 範囲、IP アドレス、一般ホスト名、および内部プライベート・ネットワーク

範囲が表示されています。ホスト名は名前の 後のみ一致している必要があるため、この場合

は server1.YourVendorDomain.com と server1.mail.YourVendorDomain.com の両方が Domino サーバーへのアクセスを許可されます。Domino サーバーを介してメールを転送する

可能性のあるアプリケーションやハードウェア (プリンターやコピー機など) が他にもある場合は、

内部のインバウンド接続を検討することが重要です。

図 25

送信メッセージ・チェックを実施している企業でも、同様にインバウンドのチェックは重要です。

すべてのアウトバウンド・メールをスキャンしてベンダーによるスパムの可能性がないかを確

認する必要がある場合は、ベンダーをアウトバウンド・リレー・サーバーとして構成すれば、簡

単に対応することができます。「ローカルインターネットドメインから送信されるメールのリレー

ホスト:」フィールドは、サーバー設定文書の「ルーター/SMTP 基本」タブにあります。図 26 では、リレー・ホストは Server.YourVendorDomain.com に設定されています。IP アドレスを指

定する場合は、大括弧で囲む必要があるので注意してください。また、このフィールドには 1 つの値しか指定できません。リレー・サーバーに障害が起きるとすべてのアウトバウンド・メー

ルの転送ができなくなるため、リレー・サーバーを構成する際は注意してください。

図 26

3.2.2.メール転送と複数のディレクトリー

メール転送の具体的な作業に関して頻繁に取り上げられるトピックに、複数ディレクトリーの使

用があります。顧客やベンダーへのメール・アドレッシングに使用される連絡先を格納した 2 次ディレクトリーが必要な場合などが該当します。サーバーに接続していないときにアドレス検索

を行う方法が欲しいとユーザーから求められる場合もあります。また、サーバーが 2 次ディレク

トリーでメール・アドレスの検索をしないようにしなければならない場合も考えられます。Domino は、このような目標をすべて達成する手段を備えています。これには、ディレクトリー・アシスタン

ト、拡張ディレクトリー・カタログ、モバイル・ディレクトリー・カタログを使用します。 詳細については、「3.4 複数のディレクトリー」を参照してください。

85

3.2.3.ジャーナリング

メール・ジャーナリングを使用すると、管理者はメッセージが Domino サーバーを経由して転送される

ときに、特定またはすべてのメッセージのコピーを保持しておくことができます。この機能はセキュリティ

面で重要な意味を持ち、係争中の訴訟を抱える企業で必要になる場合もあります。メール・ジャーナリ

ングは、設定文書で指定する設定とメール・ルールの組み合わせで構成します。メール・ジャーナリン

グの設定にアクセスするには、設定文書を開き、「ルーター/SMTP」•「詳細」•「ジャーナリング」タブにア

クセスします。図 27 を参照してください。

図 27

一部のフィールドは一見すれば内容がわかりますが、ジャーナルへのアクセス権限とジャーナルの

使いやすさを左右する設定もあります。ジャーナリングには、次の 2 つの方法を使用できます。

ローカル・データベースへコピー メール受信データベースへ送信

デフォルトの方式は「ローカル・データベースへのコピー」です。このオプションを選択すると、「ユー

ザーの代理として暗号化:」フィールドで選択されたユーザーについては、データが自動的に暗号化さ

れます。ただし、「フィールド暗号化除外リスト:」フィールドのリストに含まれるフィールドは暗号化されま

せん。

2 番目の方法として、メール受信データベースへの送信があります。2 つの選択肢はどう違うので

しょうか。メール受信データベースを使用する長所は、複数のサーバーが同じデータベースにジャー

ナルを送信できることです。短所は、暗号化とデータベースのロールオーバーが実行されないため

に、管理者がこれらに対応しなければならないという点です。

メール受信データベースの管理ツールがある場合を除いて、デフォルトのオプションである「ローカ

ル・データベースへのコピー」の使用をお勧めします。

データベースの管理オプションは、もう少し簡単です。新しいジャーナルは、サイズまたは日付に基づ

いて作成できます。デフォルトでは、新しいジャーナルは毎日作成されます。現在のジャーナルは、午

前 0 時前後に mjmmddyyyy.nsf (mj11302010.nsf など) という名前に変更されます。ジャーナルの

タブの「基本」セクションにある 後のフィールドは、「ジャーナル受信者:」です。この設定を有効にす

るかどうかに関係なく、メッセージの宛先、CC、BCC の各フィールドに選択された元の値を確認する

ことができます。しかし、場合によっては、値がグループの場合があります。

86

デフォルトでは、ジャーナルにはグループ名のみが表示されます。では、グループのメンバーは誰

だったのでしょうか。内容は変わる可能性があります。メッセージの実際の受信者がすべて表示され

るようにするには、「ジャーナル受信者:」を「有効」に設定する必要があります。

ジャーナリングされたメッセージをサーバーで管理されるローカル・データベースにコピーする

方式を選択したと仮定した場合、フィールド暗号化除外リストを変更するかどうかや、暗号化に

使用するユーザーの決定は、多少複雑になります。選択する値によって、「ユーザーの代理と

して暗号化:」フィールドのリストに含まれる ID 以外でジャーナルにアクセスしたユーザーに表

示されるデータや、全文索引に含めることのできるデータが変わってきます。全文索引は Domino サーバーによって構築されるため、全文索引に含めることのできるデータは Domino サーバーが読み取れるデータだけになります。 次の表は、企業の要件に合った適切なジャーナリング構成を見つける際に役立ちます。

要件 構成の詳細

データへの全

アクセス権限

を持つユー

ザーを 1 ～ 2 人に制限して

データを保護

する必要があ

る。メッセージ

の件名、本

文、受信者を

暗号化する必

要がある。

メッセージの

件名と本文の

全文検索は

不要。

これはデフォルトの構成です。これらの要件を満たすには、新規ユーザーを登録し、このフィール

ドにそのユーザーを指定します。例えば、架空のソフトウェア会社 A で、Mail Journaling/Administration/Company A という名前のユーザーを作成したとします。その後、この

ユーザーをメール・ジャーナルの ACL に追加し、ユーザー文書にリーダー・リストを含めて、この

人物が一般ユーザーに公開されないようにします。 その後、この権限を持つ、会社で指名されたユーザーだけで ID ファイルとパスワードを共有し、アクセスができるようにします。デフォルトのフィールド暗号化除外リストに基づいて、ジャーナルに対する読者権限のある人物であれば、図 4 のように、メッセージの送信日と元の送信者だけを読み取ることができます。Mail Journaling/Administration/Company A の ID でこのメッセージを開くと、メッセージ全体が表示されます。

セキュリティの要件によっては、この ID をプライベートな組織単位の中で作成して、使用される ID の保護をさらに強化したり、メール・ジャーナルへのアクセスが許可された管理者だけにパスワー

ド・リセット権限を与えたりしなければならない場合があります。ID ボールトの使用方法の詳細に

ついては、「ID Vault」を参照してください。

メール・ジャー

ナル・アプリ

ケーションに

対して読者以

上のアクセス

権限を持つす

べてのユー

ザーが、

ジャーナル内

のすべての

メッセージを

表示できる必

要がある。

これらの要件を満たすには、「ユーザーの代理として暗号化:」フィールドをブランクにして、暗号

化を無効にする必要があります。これで、図 5 のようにメッセージ全体が表示され、データへのア

クセスはメール・ジャーナルの ACL で制御されるようになります

87

ジャーナルにアクセスするユーザーは、すべての E メールの件名と本文に全文検索を実行できる必要がある。

メール・ジャーナ

ル・アプリケー

ションに対して読

者以上のアクセ

ス権限を持つす

べてのユーザー

が、ジャーナル

内のすべての

メッセージの日

付、送信者、受

信者、件名を表

示できる必要が

ある。メッセージ

の本文は、適切

な ID ファイルに

よってアクセスさ

れる場合以外は

非表示のままと

する。

受信者、送信

者、件名の検索

に全文検索を使

用できる必要が

ある。

これらの要件を満たすには、新規ユーザーを登録し、このフィールドにそのユーザーを指定しま

す。例えば、架空のソフトウェア会社 A で、Mail Journaling/Administration/Company A とい

う名前のユーザーを作成したとします。その後、このユーザーをメール・ジャーナルの ACL に追加し、個人文書にリーダー・リストを含めて、この人物が一般ユーザーに公開されないように

します。その後、この権限を持つ、会社で指名されたユーザーだけで ID ファイルとパスワード

を共有し、アクセスができるようにします。フィールド暗号化除外リストを変更し、SendTo、

CopyTo、BlindCopyTo、および Subject フィールドを含める必要があります。終了すると、図 6 に示すように、ジャーナルに対してリーダー権限を持つユーザーは、これらの新しいフィール

ドの読み取りのみができるようになります。Mail Journaling/Administration/Company A の ID でメッセージを開いた場合は、図 6 に示すようにメッセージ全体が表示されます。

メール・ジャーナ

リングは、これ

まで暗号化を使

用して実行され

てきた。 新たな要件や訴

訟では、特定の

メール・ジャーナ

ルを確認のため

に送信することが

要求される。

必要に応じて、エージェントを使用してジャーナルの文書を復号化することができます。詳しくは、Technote 1089495 を参照してください。

88

89

現在、ジャー

ナルによって

は、データ暗

号化の解除

が必要になる

ものがある。

ジャーナリングの notes.ini パラメーターは以下のとおりです。

JournalLimitForwardToAdmins

JournalLimitForwardToMailAddress

JournalLimitForwardToDomain

JournalLimitForwardToSendCopyTo

3.2.4. 不在通知

Domino バージョン 8.0 から、Domino の不在通知には 2 つの方法があります。エージェントに

よって管理される方法と、ルーター・タスクによって管理される方法です。ルーター・タスクによる

方法には、エージェントによる方法よりも多くの利点があります。このトピックについては、「The IBM Lotus Notes and Domino Out of Office service: Best practices.」を参照してください。

3.2.5. クラスター環境でのメール転送

クラスター環境では、プライマリー・サーバーがダウンした場合、ダウンしたサーバー上のユー

ザーに送信されたメールは、そのクラスターの相手側サーバーに送信される必要があります。

これを機能させるためには、いくつかの構成を設定する必要があります。第 1 に、各メール・

ファイルのレプリカがクラスター内の別のサーバーに存在している必要があります。

第 2 に、クラスターのメール・フェイルオーバーが、クラスター内のすべてのサーバーおよびメー

ルをサーバーに直接送信する Domino サーバーの設定文書で有効になっている必要がありま

す。クラスター・フェイルオーバーの設定は、「ルーター/SMTP」 「詳細」 「コントロール」タブで確

認できます。図 28 に示すように、クラスター・フェイルオーバーの設定は「 終ホップのみ有効」

に設定する必要があります。「Enabled for all transfers in this domain (このドメインの転送すべてに有効)」の設定も使用できますが、この設定でメール転送のループが発生しないように注

意してください。これらの違いは何でしょうか。ハブ・サーバーがダウンした場合にすべての転送

をフェイルオーバーできるようにしておくと、メールは別のハブ・サーバーにリダイレクトできます。

この設定は、エンタープライズ規模の展開でのみ使用します。管理者は、どちらのサーバーでも

目的の宛先にメールを送信できるようにし、代替のハブでメールが足止めされる問題が発生し

ないようにする必要があります。

図 28

クラスターのフェイルオーバー・パラメーターは、Domino の一連のリリースでは notes.ini パラ

メーターを使用して構成されてきました。環境を継承した場合は、不適切な設定によって問題が

生じないように、MailClusterFailover が notes.ini に指定されていないか 1 に設定されている

ことを確認する必要があります。 コンソール・コマンド show config mail* を使用して、出力を確認します。図 8 の例に示すよう

に、MailClusterFailover が出力されないことが必要です。これが出力される場合は、notes.ini または設定文書内でnotes.ini 設定が手動で定義されているので、それを削除する必要があり

ます。

> show config mail*

MAILSERVER=CN=server1/O=Company A MAILTYPE=0

図 8: show config mail* の例

クラスター・フェイルオーバーを機能させるために必要な次の構成は、cluster.ncf を追加する

ことです。cluster.ncf ファイル(Technote 1087756 参照) は、既知のすべてのクラスターとク

ラスター・メンバーのリストを含むテキスト・ファイルです。 クラスター・メンバーであるサー

バーに接続すると、このファイルが自動的に追加されます。エンタープライズ規模の環境では、

デフォルトのキャッシュ・サイズが小さすぎるため、フェイルオーバーが妨げられます。詳しく

は、Technote 1102957 を参照してください。

メールのクラスター・フェイルオーバーを機能させるために必要な 後の構成は、クラスター・

データベース・ディレクトリー (cldbdir.nsf) を完備することです。クラスター・データベース・ディレ

クトリーには、クラスター内のすべてのレプリカ・データベースのリストが含まれています。管理

者は、データベースのクラスターのレプリケーションを無効にすることできます。クラスター・デー

タベース・ディレクトリーでデータベースにサービス休止の表示がある場合は、クラスター・フェイ

ルオーバーは発生しません。以下の図 29 では、mail\utwo.nsf が server1 で無効になっている

ことがわかります。

90

図 29

後に、ルーター・タスクがメールをクラスター・サーバーに正しく送信しない理由がわからな

い場合は、RouterDebugClusterFailover¬=1 を設定することにより、デバッグのロギングを

追加で有効にできます。

この設定は動的であり、set config routerdebugclusterfailover=1 などの set config コマ

ンドを使用して、有効または無効にできます。クラスター・フェイルオーバーが正常に機能して

いる例を以下に示します。

サーバー Server2/Company A への接続エラー:サーバーが応答していません。サー

バーがダウンしているか、ネットワークに問題がある可能性があります。この問題が続く

場合は、システム管理者に連絡してください。 ルーター:ドメイン COMPANY A のサーバー server2/Company A のクラスター・フェイル

オーバーを開始しています。メール・ファイル mail\uthree ルーター:クラスター・フェイルオーバーでクラスター MailCluster のサーバー

server2/Company A が検出されました ルーター:クラスター・フェイルオーバーで検出されたサーバー SERVER1/COMPANY

A は、クラスター MailCluster のサーバー server2/Company A のクラスター・メイトです

ルーター:クラスター・フェイルオーバーでフェイルオーバー・レプリカ mail\uthree.nsf が検出されました

ルーター:メール転送を server2/Company A から [$LocalDelivery] にフェイルオーバーしています。メール・ファイル mail\uthree.nsf

ルーター:メッセージ 005758B8 が User Three/Company A に送信されました

レプリカが存在しない場合やレプリカにサービス休止の表示がある場合は、次のメッセージ

が表示されます。

ルーター:クラスター・フェイルオーバーでは、Server2/Company A mail/uthree の Rep ID

を使用してサーバーを検出できませんでした。サーバーへのパスが見つかりません ネット

ワーク接続が機能していることを確認してください。接続が機能している場合は、「プリファ

レンス」 - 「Notes Ports (Notes ポート)」を開き、「Trace (追跡)」をクリックしてデバッグし

ます

91

92

3.3. 大量メール送信

大量メール送信は、多数のユーザー宛てのメール・メッセージです。四半期ごとに全従業員宛

てに送信される従業員ニュースレターや全顧客宛ての販売カタログなどがあります。いずれに

せよ、これは、サーバー上での通常のメール送信に影響を与える可能性がある大規模な受信

者リストを備えたメッセージです。

3.3.1. 大量メール送信の問題

Domino サーバーがメールを配信する場合、その大半は、「先入れ先出し」ベースで行われま

す。これは、複数のメール・メッセージを所定の期間に送信できるマルチスレッド処理でもあり

ます。大きなメール・メッセージが受信されると、Domino サーバーのルーター・タスクでは、そ

のメッセージを送信するために可能な限り多くのスレッドを使用します。これは、Domino がメッセージを受信者全員にできる限りすばやく送信する点では良い方法ですが、処理の面で

は、ルーターが「停止」しているように見える場合があります。このような場合、ルーターがそ

のメッセージに対する処理を実行している間は、ルーター・タスクが CPU とメモリーを使用し、

新規のメールすべてが mail.box ファイルに留まり続けることがわかります。メッセージの受信

者数が多い場合は、サーバーにアクセスする際に速度の低下が見られる場合があります。 これは、ルーターが受信者リストを解析し、どのメッセージをローカルに送信するのかを決定する際に発生します。この手順は、通常、「名前検索」手順と呼ばれており、Domino ディレクトリー (namaes.nsf) での $users ビューを短期間ロックします。 $users ビューはサーバーへのユーザー認証でも必要なので、このような検索を実行すると、エンド・ユーザーに対してわずかな遅れが生じる可能性があります。

3.3.2.大量メール送信の解決策

サーバー上での大量メール送信のパフォーマンスを 適化する方法は、多数あります。これは、

メッセージ送信の影響を決定する要因が多数あるからです。この要因には、グループ・サイズ、

受信者の指定方法、メッセージの送信方法、グループにアクセスできるユーザーの指定、ルー

ター構成などがあります。

サブ・グループの使用 簡単な方法の一つとして、非常に大規模なグループを複数のサブ・グループに分割するという

ものがあります。例えば、ソフトウェア企業 A 社では、全顧客に対して毎月技術的なヒントを送

信しているとします。彼らは Product B Customers というグループを作成しています。このグ

ループには、Product B Customers A-K、Product B Customers L-Q および Product B Customers R-Z という複数のサブ・グループがあります。複数のサブ・グループを含むグルー

プにメッセージを送信するのは、1 つの大きなグループにメッセージを送信するよりも効率的で

す。これは、ルーターが各ユーザーへのメッセージ送信を準備する際に実行するメッセージ解

析方法の違いによるものです。各サブ・グループにメッセージを送信することが優れた方法であ

るとしても、これはユーザー側でより多くの作業が必要となるため、大半のユーザーはこの案を

拒否します。

メール・アドレッシングの適切な使用 「to」、「cc」、または「bcc」の各フィールドでグループへの大量メール送信を指定している状況を

検討します。「to」フィールドまたは「cc」フィールドで大規模なグループを指定している場合、

ルーター・タスクでは、「bcc」フィールドで同様の指定をしている場合とは異なる方法でメッセー

ジが処理されます。bcc リストを処理する場合は、ルーターが受信者ごとに一意のメッセージの

コピーを作成します。これは非常に負荷の重い処理です。「to」フィールドまたは「cc」フィールド

を適宜使用するか、Disable_BCC_group_expansion=1 に設定することで、このオーバーヘッ

ドを削減できます。Disable_BCC_group_expansion を設定すると、この一意のコピー処理の

発生を防ぐことができます。ただし、その結果として、ユーザーがメッセージを受信する際に 「to」、「cc」、または「bcc」の各フィールドにユーザー名や電子メール・アドレスが表示されなくな

ります。 パラメーターについて詳しくは、Technote 1089346 を参照してください。

低優先度の使用 大量メールを送信する場合、実動メール・サーバーを使用しない、または繁忙時間帯に大量

メール送信をしないという方法も考えられます。大量送信に特定のアカウントを使用する場合、

そのアカウントのメール・サーバーとして管理サーバーを選択すると、ユーザーには問題が発

生しない単純なソリューションが実現します。 一方、サーバーが 1 台のみの場合、または大量メール送信が必要なユーザーが多数いる

場合、大量メールを低優先度のメッセージとして送信する方法があります。これにより、メー

ルはサーバーの使用量が少ない時間帯に送信されるようになります。

低優先度でメッセージを送信するには次の手順を実行します。メッセージを作成するときに「配

信オプション」を選択します。 そこで、図 30 で示すように「優先順位:」を「低」に設定します。

図 30

大量メールを強制的にサーバーの空き時間帯に送信するようにするには、2 つのアクションが

必要です。1 つは低優先度メール・ルーティングの時刻を定義することで、もう 1 つは、ユー

ザーが大量メールを低優先度として送信する場合にのみ大量メールが許可されるようにルール

を構成することです。デフォルトで「低優先度メールの配信時間帯:」は午前 0:00 から午前 6:00 の時間帯に設定されています。この範囲はご使用の環境に 適な時間に変更できます。変更

は、図 31 で示されるように設定文書で「ルーター/SMTP」、「制限と制御」、「転送制御」タブの

順に選択して行います。

93

図 31

バックアップのためにサーバーを毎晩停止する場合は、その時間帯がメールのルーティング時

刻と重ならないようにします。また、サーバーでメッセージ優先順位機能を無効にしていないこと

も確認する必要があります。「メールの重要度を無視する:」設定は、図 32 に示されるように設

定文書で「ルーター/SMTP」、「詳細」、「コントロール」タブの順に選択すると表示されます。

図 32

次のステップは、サーバー・ベースのメール・ルールを構成し、低優先度で送信されるように大

量メールと見なすべき対象を定義することです。サーバー・ベースのメール・ルールは、

Domino サーバーで送受信するすべてのメールに影響を及ぼします。このため、値を低く設定

すると、多数のユーザーに送信されてくる着信メールが拒否される可能性があります。図 33 に示す例では、受信者が 50 人を超える低優先度メッセージではないあらゆるメッセージが拒

否されます。ユーザーは、ポリシーにより、メッセージが拒否されたことを示す「送信エラーレ

ポート」を受信します。

94

図 33

グループ文書へのアクセス制限

グループ文書へのアクセスを制限することも、組織内で大量メールを送信できるユーザーを制

限する効果的な方法になります。リーダー・リストは、Domino データベース内に保存されるあら

ゆる文書 (グループ文書を含む) に配置できます。文書でリーダーのリストを作成するには、文

書で右クリックして「Document Properties (文書のプロパティー)」を選択します。 「security (セキュリティ)」タブで、「読者以上すべて」の横のチェックを外します。図 34 に示されるように、

リスト内の名前の横にチェックが付いたユーザーまたはグループのみが文書にアクセスできる

ようになります。リーダー・リストを使用する場合、グループおよびグループ変更がドメイン全体

に複製されるように LocalDomainServers グループにチェックを付けることが重要です。

LocalDomainAdmins グループも含めることをお勧めします。リーダー・リストには「undo (取り

消し)」がありません。文書がロックされた状態でその文書にアクセスできる唯一の担当者が退

社してしまうと、文書をロック解除する方法も見る方法もなくなります。

したがって、リーダー・リストで LocalDomainAdmins グループまたはその他のグループを適

宜選択して自衛することは重要です。

95

図 34

グループ文書の場合、リーダー・リストで指定されていないユーザーは、Lotus Notes からも iNotes のクライアントからもメッセージをグループに送信できません。無許可のユーザーが POP または IMAP のクライアントを使用してメッセージ送信を試行すると、「Not authorized to send mail to this user or group」のエラーで「送信エラーレポート」を受信します。

サーバー構成 Domino サーバーのさらなるチューニングに使用できるほか、大量メールに伴うサーバー

の問題防止に使用できる多数の NOTES.INI パラメーターがあります。これには、

RouterMaxConcurrentDeliverySize、RouterMaxEffectiveSize、

RouterMaxEffectiveSizeIncAttach などがあります。

RouterMaxConcurrentDeliverySize (Technote 1108351 参照) では、指定されたサイズ (バイト) よりもメッセージが大きい場合、ルーターは一度にメッセージの 1 つのコピーのみを

開くことができます。 この設定により、大容量の添付があり複数ユーザーに送信されるメッ

セージの場合、パフォーマンスが改善されます。大容量の添付があるメッセージの場合、すべ

ての受信者に到着するまでにわずかな遅れが発生しますが、メッセージは送信されます。こ

のパラメーターに適切なサイズは、ご使用の環境により異なります。多数のお客様が有効な

開始値として 1048576 (1 メガバイト) を使用しています。

RouterMaxEffectiveSize では、キロバイトで指定した有効なメッセージ・サイズよりも、送信し

ようとしているメッセージが大きい場合、送信エラー通知がユーザーに送信されます。 メッセー

ジの有効サイズは、メッセージ・サイズに受信者の合計数を乗じて計算します (有効サイズ = メッセージ・サイズ (キロバイト) * 受信者数)。この計算に使用されるメッセージ・サイズには、

RouterMaxEffectiveSizeIncAttach =1 を設定した場合を除いて添付のサイズが含まれてい

ません。この値の設定方法は、計算に添付を含めるかどうかによって決まります。 RouterMaxEffectiveSize は、構成設定文書 (図 35) またはサイズをベースに構成されるルー

ル (図 36) で構成できる 大メッセージ・サイズ・パラメーターと同等です。相違点は、 大メッ

セージ・サイズまたはサーバー・ベースのメール・ルールを使用する場合、受信者数が考慮され

ないことです。

96

図 35

図 36

97

98

ルーター・タスクからの作業の振り替え 大量メール処理で取りうる 後の方法は、作業をルーター・タスクから別のタスクに振り替える

方法を探すことです。これは、メッセージを送信するエージェントを開発することで行います。こ

のエージェントでは、メッセージ送信を少数ユーザーのグループに分割すること、メッセージを

後から送信するようにキューに入れること、または本章で説明するその他の方法のいずれか

を使用することができます。また、サーバー・パフォーマンスに影響を与えずに大量メールの

管理および作成を行う、多数のサード・パーティーのツールがあります。

3.3.3.結論

ここまで、Domino 環境で大量メールを管理できる多数の方法を見てきました。オプションに

はユーザーの研修が必要なものもあれば、不要なものもあります。これで、使用可能な多数

のオプションを理解したので、ビジネスに 適な選択肢となるオプション・セットを決定できま

す。

3.4. 複数のディレクトリー

Domino 管理者は、Domino 環境で複数のディレクトリーの統合を求められることがあります。

これは、顧客やベンダーを追跡するための単純なアドレス帳の作成に始まり、2 つの Domino 環境を統合して環境にシングル・サインオン (SSO) を構成するような複雑な作業まで多岐にわ

たります。Domino の認証オプションについて詳しくは、『1.4 Domino 認証オプション.』を参照

してください。別のディレクトリーのユーザーが Web (Web 認証) 経由でサーバーにアクセスで

きる方法を目指すこともできます。本章では、ご使用の環境で 2 次ディレクトリーを構成するた

めの概要を説明します。

使用可能な機能のリストについては、ヘルプ資料「Comparison of directory catalogs

and directory assistance」を参照してください。

初の 2 次ディレクトリーを作成する場合、Domino ディレクトリー (pubnames.ntf) テンプ

レートを使用する必要があります。これは、ディレクトリー・アシスタンスおよびディレクトリー・

カタログで個人アドレス帳を使用することが推奨されないためです。ディレクトリーが作成され

て取り込まれると、ユーザー向けに 2 次ディレクトリーへのアクセスの構成を開始できます。

複数の Domino サーバーが環境にある場合、2 次ディレクトリーにアクセスが必要な各サー

バーでは、ローカルで使用する 2 次ディレクトリーのレプリカが必要です。

3.4.1.要約ディレクトリー・カタログ、拡張ディレクトリー・カタログまたはディ

レクトリー・アシスタンス

ディレクトリー・アシスタンスまたはディレクトリー・カタログの調査が必要かどうかの確認、およ

び実装に必要なステップの概要を確認するには、下記の図 37 を参照してください。手順に関

する情報は、図の中の各エントリーをクリックすると表示できます。

図 37 3.4.2.ヒント

初の 2 次ディレクトリーまたは 2 次カタログを作成する場合は、次の点にも留意する必

要があります。

ディレクトリーは Domino ディレクトリー (pubnames.ntf) テンプレートを使用して作成する必要

があります。 要約ディレクトリー・カタログはサーバーで使用してはならず、グループ許可には使用でき

ません。例えば、要約カタログに記述したグループは、ACL でアプリケーションへのアクセ

ス権限を付与する操作には使用できませんが、ディレクトリー・アシスタンス経由で参照さ

れる拡張ディレクトリー・カタログまたは 2 次アドレス帳はグループ許可に使用できます。

99

Domino サーバーで現在使用中の 2 次ディレクトリーがあるかどうかを判断するには、

Domino コンソール・コマンド show xdir を入力します。 サーバーは必ず、あらゆる 2 次ディレクトリーのローカル・レプリカにアクセス可能であること

が必要です。 サーバーがファイル名をローカルで確認できるようにするには、図 38 に示され

るように、実際のサーバー名の代わりに * を使用します。

図 38

3.5. サーバー・クラスタリング・オプション

この記事では、Domino のアップタイムを改善する方法について説明します。Domino のアップ

タイムはさまざまな方法で改善できます。1 つ目の方法としては、すべてのコンポーネントを冗長

にする方法があります。2 つ目の方法としては、インフラストラクチャーを単純にする方法があり

ます。もちろん、単純にする方がよいです。インフラストラクチャーが単純でクリアな場合、より効

率的に動作します。この記事では、Domino コンポーネントについてのみ説明します。冗長電源、

冷却装置、ネットワーク、HDD など、Domino よりも下の層に配置される、その他のコンポーネ

ントについても冗長にする必要があります。

3.5.1. 単純化

経験から言えることは、Domino の構成を混在させないということです。例えば、メール・クラス

ターがある場合、メールのみをユーザーに提供します。アプリケーションや Web、その他、Lotus Quickr、Traveler、Sametime などこのサーバーに配置しないでください。これらの種類の製品

は、別のサーバーを使用する必要があります。また Domino 上には、アドオン製品を 1 つのみ

配置できます。アドオン製品を別のサーバーで使用する場合でも、そのサーバー上にそれらす

べてを一緒に配置しないでください。

Traveler を別のサーバーに配置させる利点としては、セキュリティの向上があります。これは、

Traveler のみを DMZ ゾーンに配置できるためです。何者かにハッキングされた場合でも、それ

は空のサーバーということになります。他のサーバーが危険にさらされることはありません。すべ

てのデータベースとアプリケーションは他のサーバーに配置されており、インターネットからは利

用できないからです。Sametime Entry を使用してユーザーが互いにチャットで会話できるように

したり、Sametime をテレビ会議で使用したりする場合も同様に、別立てのサーバーに配置する

必要があります。これによって、サーバーとサービスの相互依存性が低くなります。

ヒント：これら製品が、Domino のすべてのパッチ・レベルで動作するとは限りません。 例えば、

メール環境のフィックスが、同じマシンで実行している Microsoft Quickr サーバーと互換性がな

い場合があります。実稼働環境にアップグレードする前に、まずクローンを作成し、適切に動作す

ることをテストしてください。

100

3.5.2. Domino 部分の冗長化

Domino にアクセスするユーザーとシステムに対してサービスの可用性を向上させる方法には、

さまざまなアプローチがあります。この目的を実現する方法は、ユーザーとアプリケーションが Domino にアクセスする方法によって異なります。

サーバーの可用性は測定可能でしょうか。可能です。 この計算には、計画ダウン時間と計画

外ダウン時間の 2 つの要因があります。計画ダウン時間とは、サーバーが利用できないこと

が事前に予告され計画されていることで、ユーザーに影響しません。例えば、業務時間外で新

しいバージョンの Domino を配置したり、オペレーティング・システムにパッチを適用したりする

ことを予定する場合があります。誰もサーバーが停止していることに気がつきません。作業が

完了したら、サーバーをオンラインに戻します。一方で、通常の業務時間内に電源障害が発生

した場合や、オペレーティング・システムや Domino がクラッシュした場合には、計画外ダウン

時間になります。この時間中、ユーザーはメールの送受信やデータベースのアクセスができま

せん。ヘルプ・デスクに電話して、サポート依頼を登録します。この計画外ダウン時間により、

ユーザーの作業は影響を受けます。

Domino 環境のサイズ (小規模、中規模、または大規模) に応じて、Domino の計画外ダウン

時間の短縮に使用できるさまざまなアプローチを、次の表に示します。

アプローチ 小規模 中規模 大規模 備考

Domino クラスター + +++ +++++ Lotus Notes ユーザーに

対してフェイルオーバー

がシームレスに行われま

す。

注 #1 注 #2

OS クラスター +++ ++ + 注 #3 注 #4

ICM (Internet Cluster Manager)

++ ++ +++

ハードウェア型ロード・バランサー

+ ++ +++

POP3/IMAP/HTTP プロキシー

+ + +

101

次のフローチャートは、ご使用の環境でシステム・ダウン時間の短縮化を図る上で

の 適なアプローチを示しています。

図 39

注：

#1. サーバーごとに、Enterprise ライセンスまたは Utility ライセンスが必要です。

#2. フェイルオーバー用データベース・アダプテーションが必要です。 すべてのデータ (Domino Administrator により決定) は、クラスター内のサーバーに複製されます。1 つの

サーバーでデータが破損し、整合性チェック (fixup) 中に削除されると、そのデータはもう一

方のサーバーから自動的に復元 (複製) されます。1 つのサーバーでデータが削除されると、

そのデータはもう一方のサーバーからも同様に削除されます。

#3. ユーザー数が 1000 人未満の組織の場合、Domino Express ライセンスを使用できます。

#4. 2 つのサーバーで 1 台のディスクを使用して、データを格納します。 そのため、1 つの

サーバーがダウンすると、もう一方のサーバーは同じデータを使用して稼働します。データが

破損している場合、両方のサーバーは破損データで処理を行います。各サーバーは同じデー

タを使用します。

この記事の残りの部分では、Domino サーバーのダウン時間を短縮する方法についてさ

まざまなアプローチを使用して説明します。

3.5.3.Domino クラスター

小規模： ● 中規模： ●●● 大規模： ●●●●● 組織のサイズが中規模または大規模の場合や、Domino でダウン時間が許容できない場合は、このアプローチを選択してください。

102

図 40

Domino クラスターとは複数のサーバーのあるグループであり、Domino アプリケーション・レ

ベルでフェイルオーバーが実現されます。フェイルオーバーとは、1 次サーバーが応答しない

場合や、過負荷状態になった場合に、あるサーバーから別のサーバーに、Lotus Notes クライ

アントがリダイレクトされるプロセスのことです。フェイルオーバーの利点は、ユーザーが引き

続きクリティカルなリソースにアクセスできることです。 新バージョンの Domino では、ユー

ザーはエラー・メッセージを受信しないため、ユーザーに対して透過的にフェイルオーバーが

行われます。

Domino クラスターの場合、クラスター・データベースのデータベース・レプリカは、別の

サーバーに配置されます。クラスターにより、フェイルオーバーだけでなくロード・バランシン

グも実現されます。過負荷状態のサーバーは、負荷の高くない別のサーバーにユーザー

の処理を渡すことができます。

一般的に、オペレーティング・システムのクラスターには、アクティブ-アクティブ型とアクティブ-パッシブ型の 2 種類があります。アクティブ-アクティブ型のクラスターの場合、すべてのサー

バーは利用可能で、ユーザーの要求を同時に処理します。アクティブ-パッシブ型のクラスター

の場合、1 つのサーバー (アクティブなサーバー) がユーザーの要求を処理し、もう一方のサー

バー (受動状態のサーバー) は待機状態になり、ユーザーの要求を処理しません。アクティブ・

サーバーがダウンすると、パッシブ・サーバーがそれを検知して、自らがアクティブ・サーバーと

なり、ユーザーに対してサービスを提供します。

Domino クラスタリングでは、クラスターに含まれるサーバーごとにライセンスが必要です。ラ

イセンスは、IBM または IBM ビジネス・パートナーから購入する必要があります。そのため、

このソリューションでは、追加のライセンス費用が発生します。一部のデータベースではクラス

タリングとフェイルオーバーを自動的にサポートしています。それ以外のデータベース (社内

で開発されたデータベースなど) の場合、デフォルトではクラスタリングがサポートされていな

いため、クラスタリングをサポートするようにプログラミングする必要があります。

IBM が提供している一部のデータベースでは、クラスタリングをサポートしています。例えば、

Mail Database です。Designer のヘルプには、データベースをクラスターで動作させる際に役

立つ LotusScript 関数がリストされています。例えば、Database.Open は一般的なデータベー

ス・オープン関数ですが、Database.OpenWithFailover はそのクラスター版になります。

103

104

Database.OpenWithFailover は、データベースのオープンを試行します。データベースが利用

できないと、別のサーバーに自動的にフェイルオーバーします。データベースでクラスター・モー

ドのサポートを有効にすることは、ある関数を別の関数に置換することではありません。開発者

が解決する必要のある課題はさまざまです。例えば、2 つの文書が別々のサーバーで同時に

変更される場合があります。

競合の保管を防止するには、文書のロックを検討する必要があります。エージェントもまた、ク

ラスター環境で検討対象となる課題です。Domino では「新規メールの受信後」エージェントの

フェイルオーバーはサポートされていますが、スケジュールされているエージェントのフェイル

オーバーはサポートされていません。

次の技法を使用すると、スケジュールされているエージェントをクラスター環境で動作する

ように解決できます。 マスターとなるエージェント、マスター以外のエージェント (スレーブ・エージェント) をすべてトリ

ガーするエージェントを 1 つ用意します。このマスター・エージェントは「すべてのサーバー」でス

ケジュールされるエージェントです。クラスターの、すべてのノードで X 分ごとに実行されます。

このエージェントが、実際にすべてのサーバーで同時に実行しないようにするために、 初にど

こか 1 つのサーバーのみでエージェントが実行される必要があります。さらに、このサーバーが

ダウンした場合は、エージェントを他のノードで実行する必要があります。 このマスター・エージェントが存在するデータベースの中に、プロフィール文書を作成して、2 つのフィールド、PrimaryServer と TimeStamp を指定してください。PrimaryServer は、他のす

べてのエージェントをトリガーするマスター・エージェントを実行するサーバーの名前です。マス

ター・エージェントは 1 つのサーバーで正常に実行されると、プロフィール文書内の TimeStamp フィールドをタイム・スタンプで更新します。このプロフィール文書は、クラスター・レ

プリケーションを通じて他のサーバーに複製されます。他のサーバー上のマスター・エージェン

トは、 新のタイム・スタンプがあるかどうかを調べて、ある場合は、1 次サーバーのマスター・

エージェントがすでに動作していると認識して、エージェントの実行を終了します。もし、NOW() と 新のタイム・スタンプとの時間の差が大きい場合、1 次サーバーがダウンしたものと判断し、

マスター・エージェントから、他のエージェントをすべてトリガーします。

Dominoクラスターの各ノードは、異なる建物や都市、国に配置できます。Dominoには地理分

散クラスタリングのオプションも用意されています。火災が発生した場合や、その建物内で稼働

できない場合は、別の場所からすべての情報を入手できます。

まとめ Domino クラスタリングは、Lotus Notes ユーザーに対して高可用性を実現する 適な方法

です。 新バージョンの Domino ではフェイルオーバーはシームレスに行われます。それ以

外のバージョンでは、別のサーバーにリダイレクトするプロンプトが表示されます。さまざまな

オペレーティング・システムの上に Domino クラスターを構築できます。ご使用のアプリケー

ションをクラスター対応にできない場合、オペレーティング・システムのクラスターなど、他のソ

リューションを選択できます。

その他の関連リソース 詳細については、以下を参照してください。

• 「Understanding IBM Lotus Domino server clustering」 • 「Lotus Domino R5 Clustering with IBM eServer xSeries and Netfinity

Servers」

3.5.4.OS クラスター

小規模： ●●●● 中規模： ●●● 大規模： ●

図 41

クラスターの 1 つのタイプとして、オペレーティング・システム (OS) クラスターがあります。2 つ以上のサーバーで構成し、Domino プロセスはその中の 1 つのサーバー上のみで実行されま

す。サーバーを切り替える必要がある場合、またはハードウェア障害が生じた場合には、別の

サーバー上で Domino プロセスを開始します。どちらのケースでも、サーバーはまったく同じ SERVER.ID と IP アドレスで実行されます。Domino クラスターの場合は、別々の名前を持ち

ます。

もし、サーバー A が稼働しているときに、何らかの保守を行う必要がある場合には、別のサー

バーに制御権が移るコマンドを発行します。その後、制御権が移った別のノードで、同じサー

バー A として再開されます。 初のサーバーから次のサーバーへ切り替わるとき、ユーザーは

若干の遅延を感じるかもしれません。

ほとんどすべてのオペレーティング・システムは、OS クラスターを構築するオプションを提供し

ています。これには、追加ライセンスが必要になる場合があります。例えば、Linux 上では Heartbeat デーモンが、Linux OS ベース上にクラスターを構築するソリューションを提供します。

このデーモンの構成では、モニターすべきノードとプロセスを定義します。サーバーが停止する

と、次のノードが制御権を取得し、Domino データが配置された共有ディスクをマップして、

Domino サーバーを開始します。OS クラスター化された Domino サーバーは、エンド・ユー

ザーからは同じ名前と同じ IP アドレスを持つように見えます。よって、Domino にホスト名で接

105

続する POP3/IMAP/LDAP/HTTP などのシステムは、常に正常にサーバーにアクセスできます。

社内のユーザー数が 1000 未満である場合、OS クラスター用の Domino Express ライセンス

が使用できます。Express ライセンスは、ユーザー数が 1000 未満で Domino クラスタリング

が使用できないことが制限であり、この観点から、比較的安価に Domino の高可用性を利用で

きます。

OS クラスターを使用する場合には、リリース 8.x および 8.5.x 以降の データベースを開いた

ままでも自動でサーバー先が切り替わるフェイルオーバー機能を、Lotus Notes クライアント

から利用できません。データベースを開いた状態でサーバーがダウンした場合、ユーザーは

一度データベースをクローズして、再度、データベースを開く必要があります。

OS クラスターは、Domino クラスターと併用することができ、サポートされている構成で

す。

3.5.5.Internet Cluster Manager (ICM)

図 42

前述のセクションで、Domino サーバー全体の高可用性について説明しました。リリース 5.x 以降では、高可用性オプションの Internet Cluster Manager (ICM とも呼ばれる) を使用できます。

ICM とは、iNotes やイントラネット、会社のホームページにアクセスする WEB クライアントに対

し、フェイルオーバーを提供する機能のことです。ICM は、Domino サーバーにロードする追加

タスクとなっています。すでに稼働している Domino クラスターがある場合、ICM の構成は極め

て簡単です。ICM は Domino クラスターに追加して使う機能であり、Domino クラスターと一緒

に機能します。

ICM の Domino 構成においては、Domino 環境に多くのクラスターがある場合には、ICM がどの Domino クラスターを監視するかを定義します。ICM とは、ディスパッチャーのようなリダ

106

107

イレクトの役割を担うものです。新しい HTTP 要求がくると、ICM はクラスター内のどのサー

バーが使用可能かを把握し、使用可能なサーバーにユーザーをリダイレクトします。サーバー

が停止すると ICM がそれを探知し、後続の新しい要求を別の使用可能なサーバーに転送し

ます。ICMは、ある一定の間隔で、Domino に ping コマンドを送信して、クラスター内の使用

可能なサーバーをチェックし、新しい要求を受けると、稼働中のサーバーに送信します。

ICM の実効的なシナリオ mail1.company.com と mail2.company.com という 2 つのメール・サーバーがあるとします。

ICM は、webmail.company.com で要求を listen しています。ユーザーが webmail.company.com のアドレスを入力すると、この要求は ICM に転送されます。ICM は稼働中のサーバーをすでに把握しているため、そのユーザー・リダイレクト要求を送信します。

ユーザーのブラウザーの URL が mail1.company.com または mail2.company.com に変更

され、ユーザーに認証が求められます。

既存の Domino サーバーとは別のサーバーで ICM を実行することを推奨します。過負荷の

サーバーで ICM が実行された場合に、このサーバーが使用不能になり、ICM にアクセスでき

なくなる可能性があり、ICM がクライアントの要求をリダイレクトしません。ICM が別のマシンで

実行されている場合には、リダイレクト情報がクライアントに送信されます。ICM により、予定外

のダウン時間が短くなります。

ICM が停止した場合には、どうなるでしょうか クラスターは稼働しますが、ユーザーはリダイレクトされません。ICM の可用性を向上させた

い場合には、複数の ICM サーバーを用意して、1 つのホストに複数の IP アドレスを割り当て

ることができます。そうすれば、ICM のフェイルオーバーが DNS/OS レベルで行われます。こ

のアプローチにより、高いレベルの ICM の可用性を確保できます。

複数の Web サーバー間でのシングル・サインオン実装は、ユーザーにとってメリットがあります。

メール・サーバー間で LTPA トークンを共有すると、URL が mail1.company.com から mail2.company.com に変更されても、追加のログイン画面が表示されることはありません。つ

まり、ユーザーがメールを閲覧しているときにメール・サーバーが停止した場合 webmail.company.com ホストに再度アクセスしても、シングル・サインオンが実装されていると、

ユーザーは、再度ログイン・フォームに入力することなく継続してメールを閲覧できます。

3.5.6.iNotes の高可用性構成

iNotes の高可用性構成については、以下を参照してください。 iNotes High Availability Configuration

3.5.7.IMAP フェイルオーバー (Domino 8.5 の新機能)

リリース 8.5.2 の Domino に IMAP ユーザー向けの新機能が追加されました。IMAP ユー

ザーが別のサーバーにフェイルオーバーできるようになり、IMAP クライアントの紛らわしさがな

くなりました。IMAP ユーザー数が多い場合には、この機能によりメリットを得られます。Domino クラスター・サーバーで IMAP を構成するには、追加手順が必要です。詳しくは、Technote 1429885 または 8.5.2 Administrator のヘルプを参照してください。1 つのホストへの複数 IP アドレスの割り当て、またはソフトウェア・プロキシーを併用することにより、IMAP ユーザーを使

用可能なサーバー間でリダイレクトします。

詳細については、以下を参照してください。 Technote 1429885

3.5.8.Lotus Traveler サーバーの高可用性

現時点で Lotus Traveler には、ネイティブ・クラスタリングのオプションはありません。Lotus Traveler サポートの強化が予定されています。それでも、多数の Traveler サーバーを構築す

ることはできます。ユーザーが手動でサーバーの IP アドレスを変更すれば、Traveler クライ

アントはデータの完全な同期を実行できますが、これは長い時間と大量のトラフィックを費やす

作業です。これは、Traveler サーバーの設計に起因します。

クラスターで Traveler を使用できるようにする 善のソリューションの 1 つは、Traveler を OS クラスターに追加する方法かアクティブ-パッシブ・モードで動作するプロキシー・サーバーを使

用する方法です。 以下の関連トピックを参照してください。

「クラスタ化とフェイルオーバー」

3.5.9.ロード・ バランサー

図 43

サーバーの可用性を向上させるもう 1 つのオプションが、ロード・バランサーです。ロード・バラン

サーは、ターゲット・サーバーが使用可能かどうかをチェックできるハードウェア・デバイス、また

はソフトウェアです。 新しい要求が着信すると、要求を使用可能なサーバーの 1 つにリダイレクトします。ハードウェ

アの負荷分散は、サーバー間で POP3/IMAP/SMTP ユーザーをクラスタリングするために使

用できます。

POP3/IMAP/LDAP/SMTP プロトコルのフェイルオーバーに加え、Domino サーバー間で Lotus ユーザーを切り替えるためにロード・バランサーを使用することもできます。Lotus Notes

108

と IP-Sprayer (ロード・バランサー) を併用する場合には、Technote 1233210 に記載されてい

るパラメーターを追加する必要があります。 このパラメーターは、ポリシー/デスクトップの設定を利用して実装できます。

3.5.10. ソフトウェア・プロキシー (IBM HTTP、nGinx、など)

図 44

プロキシー・サーバーのように動作して、データを要求する先のサーバーの自動的なフェイル

オーバーを実行できるソフトウェア・プログラムがあります。IBM HTTP などの一部のソリュー

ションは、HTTP/HTTPS プロトコルのフェイルオーバー (リバース・プロキシー) を提供できま

す。例えば NGINX などの他の一部のソリューションは SMTP、POP3、IMAP、HTTP に対応

します。さまざまなベンダーがあり、プロトコルという観点からすると、すべてのプロキシー機能

が異なります。HTTP のみのフェイルオーバーが必要なのか、SMTP、POP3 などの追加プロ

トコルのフェイルオーバーが必要なのかといった必要性に応じて、使用するソリューションを選

択できます。

3.5.11. Sametime および QuickR の高可用性

Sametime および QuickR サーバーもクラスター化が可能です。これらのリソースが重要で

ある場合には、Lotus Sametime または Lotus QuickR のユーザーに高可用性を提供する

クラスタリングを実装してください。Lotus Sametime および Lotus QuickR のクラスターを

実装する方法については、以下のリンクを参照してください。

Technote 1248809

109

110

3.5.12.ディザスター・リカバリー・プラン

このセクションは、OS/ハードウェアの障害が発生している場合の Domino リカバリーについて

取り上げます。リカバリー・プランとは、サーバーのリストア時に実施すべき一連のアクションお

よび責務を定義した文書です。テスト・リカバリーとは、新しいバックアップ・ソリューションを実装

した後に実行すべき手順です。これに加え、テスト・リカバリーを毎年繰り返し実施して、その環

境で行われた変更がバックアップ・ポリシーに反映されていることを確かめる必要があります。

テスト・リカバリーは、バックアップ手順についてすべてが適切であることを示します。テスト・リカ

バリーは、バックアップ・チームが参加せずに進める必要があります。そのため、追加 (フル) バックアップ・コピーを用意することはありません。テスト・ケースで遭遇する問題を理解し、今後

の問題を回避することが、この手順の目的です。

実稼働環境に新しいサーバーを配置するときには、このサーバーが日常のバックアップ手順に

含まれるようにする必要があります。いつリカバリーが必要になるか、あるいはどのデータが必

要になるかは誰にもわかりません。そのデータは、1つのテキストまたは構成ファイル、あるいは

単独のメール・ファイル、アプリケーションの一部のデータベースまたはサーバー全体のデータ

ベースになることもあります。使用中のDomino 環境のリカバリー・プランを立てておくことは不

可欠です。また、そのプランを文書化しておく必要があります。休暇旅行に出かけようとするとき

のように、問題が起こる可能性があることはわかっています。携帯電話に緊急電話をもらいたく

はないものです。作成された文書に従って、同僚もリカバリーを実行できなければなりません。

リストアすべきデータ、リストア方法、その順序、導入場所、IP アドレス、および電話番号を記述

してください。記述された文書は常に 新にしておく必要があります。また、必ず印刷してすぐ出

せる場所に保管してください。この文書は電子フォーマットだけでは保管しないでください。シス

テムがダウンした場合、その文書を読むことができなくなってしまいます。

サーバー全体のリカバリー・テストを実施するようにしてください。別のテスト用サーバーでテス

トを実施してください。必ず IP が分離しているサーバー上でリストアを実施してください。そうす

れば、そのサーバーがスタートしたときに、別の本番サーバーを複製しません。一度フル･リカ

バリーを実行しておけば、実際の場面で、同様のリストアをさらにスムースに迅速に実行できま

す。十分に時間をかかて、実行したステップを文書に記述してください。実際に実行するときに

は、初めて実施したときより少なくとも数倍速くできます。リカバリーをテストします。その時、現

在のバックアップ・プランで間違って文書化した個所を探し、それに注目してください。例え

ば、.nsf ファイルを Domino 固有のバックアップ・ソリューションでバックアップを行い、Domino DATA フォルダ以外のすべてのファイルを OS バックアップ・ソリューションでバックアップします。 この場合、cert.id, server.id, notes.ini などいくつかの重要なファイルがバックアップに含まれない場合があります。リカバリー・テストによって、そのバックアップ・ソリューションおよび方法がすべて問題ないことが確認されます。

リカバリー・プランでは、リストアの順序を記述してください。どのような方法でサーバー全体を

リストアするのか、あるメール・ファイルを、もしくはひとつの文書をリストアするかを記述します

（ロケーションを切り替える、あるいはコピーペーストする、等）。

3.6. トランザクション・ロギング

トランザクション・ロギングは、Domino サーバー上で発生するトランザクションのリアルタイム・

ログです。初めてトランザクション・ロギングを開始する場合、Technote 7009309 を参照してく

ださい。

111

3.6.1. 8.5.x サーバーのトランザクション ロギング の一般的な推奨事項

Domino version 8.5.x でトランザクション・ロギングを行う場合、初めにトランザクション・ロギン

グのタイプを決める必要があります。トランザクション・ログの管理するバックアップ・ユーティリ

ティーを使用する場合、またはポイント・イン・タイム・リカバリーが必要な場合、アーカイブ型の

ロギングを使用してください。

アーカイブ・ログは Domino によって自動的にはクリーンアップされないことに注意してください。

アーカイブ型ロギングを使った場合には、バックアップ・ユーティリティーを使用して古いログを

クリーンアップし、使用可能なディスクすべてが古いログで一杯にならないようにする必要があ

ります。バックアップ・ユーティリティーを使用してアーカイブ・ログを管理しない場合、またはポ

イント・イン・タイム・リカバリーを行わない場合は、周期型ロギングを選択してください。 周期ログの 大サイズは 4GB であり、Domino の 小構成以外のすべての場合の推奨値で

す。

ログ・ディレクトリーの設置場所は、長年にわたって混乱の原因の一つとなっています。ログ・

ディレクトリーを設置してはいけない場所を述べた方が簡単でしょう。ログ・ディレクトリーは Domino データ・ディレクトリーと同じ物理ディスクには置かないでください。これは、RAID ディ

スク・アレイ (IBM i など) を使用する場合は、データ・ディレクトリー内にログ・ディレクトリーを

置くことができることを意味します。詳細については、Technote 7009309 を参照してください。 3.6.2.トランザクション・ ロギング のヒント

トランザクション・ロギングで問題を起こさないために、Domino 管理者すべてが知っておくべ

き事項があります。

• Domino は、トランザクション・ログ・ファイルへの書き込みアクセス権を常に持つ必要が

あるので、トランザクション・ログ・ディレクトリーではアンチ・ウィルスを実行しないでくださ

い。 • トランザクション・ログは、DBIID を使用してデータベースの変更を追跡します。したがっ

て、同じ DBIID を持つ複数の .nsf ファイルを持つことはできません。Lotus Notes クライ

アントおよび Domino サーバーではこれは決して起こりません。しかし、ファイルの移動

中などに、OS レベルでファイル・コピーやファイル・リストアを行った場合に、誤って DBIID を複製することのないようにしてください。OS レベルでのファイルのコピーやリス

トアが必要な場合、簡単な回避方法として、コピーやリストアを実行する前に使用中のデ

ータベースで修正プログラムまたはコピー型圧縮を実行して DBIID を変更します。 • トランザクション・ログに問題があった場合、IBM_TECHNICAL_SUPPORT ディレクトリー

にあるログ・ファイル、コンソール・ログおよびすべての logasio*.txt ファイルのコピーを常

に保持してください。その情報がないと、Lotus サポートは問題の原因判別を支援できない

場合があります。 • システム・データベースのトランザクション・ロギングを有効にすべきかを決定するためには、

DAOS Best Practices の記事の表を参照してください。

3.6.3.Domino 8.5.x サーバーのNOTES.INI 推奨事項

トランザクション・ロギング構成を 適化に役立てるように、Domino サーバーに設定する際に

知っておくべき NOTES.INI パラメーターがいくつかあります。

112

NSF_DONT_LOG_MAILBOX_BODY=1: この設定によって、mail.box ファイル内のメッセー

ジ・ログで、メッセージ本文はログされないようにします。mail.box ファイルは非常に頻繁に使用

されるので、このパラメーターにより、mail.box ファイルのパフォーマンスおよびスループットを

改善することができます。メール・ボックスがトランザクションのログを取っていると、メッセージは

メール・ボックス・ファイルにあるものをログするのではなく、メッセージが配送された瞬間にログ

されます。

RM_NO_LOG_LARGE_OBJECTS=1: サーバーの mail.box ファイルに格納された1MB を越える添付ファイルはトランザクションのログに記録されません。これによって、サイズの大き

なメッセージのメール配信の効率を高めることができます。

Schedule_DisableTXNLogging=1: この設定により、スケジュール用データベース (busytime.nsf または clubusy.msf)のトランザクション・ログが無効になります。

3.6.4.Domino 8.5.x および ODS 51 の更新

Domino 8.5 および ODS レベル 51 から開始するときには、ログ圧縮は有効になっていませ

ん。トランザクション・ロギングでは、データベースと同じフォーマットでデータが格納されます。

そのデータがすでに圧縮されている場合、トランザクション・ログの中で圧縮されます。その

データが圧縮されていない場合、トランザクション・ログの中で圧縮されません。どのデータが

ここでは対象になるでしょうか。それはデータ・ドキュメント、設計ドキュメント、あるいは添付

ファイルです。

パフォーマンスの理由から (多くの場合 system z および IBM i systems) トランザクション・ログ

を圧縮し、データは圧縮したくない場合があります。 この場合には、それを実現する NOTES.INI の設定は2つあります。

• NSF_COMPRESS_TXN_LOGS - トランザクション・ログ内の設計ドキュメントおよびデー

タ・ドキュメントの両方を圧縮します。 • NSF_ENABLE_LZ1_TXN_LOGS - LZ1 アルゴリズムを使用してトランザクション・

ログ内に格納された添付ファイルを圧縮します。その時、Domino データベース内で

圧縮されて格納されたかは関係なく行われます。

添付ファイルの LZ1 圧縮の有効化

使用中の環境で LZ1 圧縮を有効にするためには、Lotus Domino Administrator クライアント

を開き、サーバーに接続し、「Files」タブを選択します。右のパネル上で、「Advanced Properties」を選択します。以下の図 1 に示すように「Use LZ1 Compression…」を有効に

するオプションを選択し、「OK」を選択して適用します。

このオプションを設定後、その期間中 LZ1 圧縮は新規添付ファイルすべに対して機能します

が、これを有効にする前のすべての添付ファイルはそのまま (圧縮なし) です。既存の添付

ファイルを LZ1 圧縮に変換するためには、 -ZU パラメーターを付けて圧縮タスクを実行して

ください。

設計ドキュメントの圧縮の有効化

Lotus Domino Administrator クライアントを開き、サーバーに接続し、「Files」タブを選択しま

す。右のパネル上で、「Advanced Properties」を選択します。以下の図１の示すように、

「データベース設計を圧縮」を有効にするオプションを選択し、「OK」を選択して適用します。設

計ドキュメントを圧縮するために、コピー型圧縮をこの時点でそのデータベース上で実行する必

要があります。

ドキュメント・データの圧縮の有効化

Lotus Domino Administrator クライアントを開き、サーバーに接続し、「Files」タブを選択しま

す。右のパネル上で、「Advanced Properties」を選択します。以下の図 45 に示すように、

「文書データを圧縮」を有効にするオプションを選択し、「OK」を選択して適用します。既存のド

キュメントを圧縮するには、コピー型圧縮をデータベース上で実行する必要があります。

図 45

3.7. Domino Attachment Object Service (DAOS)

Domino Attachment and Object Service (DAOS) は、Domino 8.5 で新たに導入された機能

です。DAOS は同じ Domino サーバー上のデータベース間で同一の添付ファイルを共用する

仕組みです。DAOS を構成することによって、単独の完全な添付ファイルはデータベース内に

格納されることはなくなり、ディスク上の添付ファイルを参照するドキュメントとともに、ファイル・

システムに添付ファイルが 1 つだけ格納されます。DAOS の添付ファイルの生成、取得は、す

113

べてのユーザー機能を含め、すべてのトランザクションに対して透過的に行われるように実装

されています。DAOS のメリットは、ファイル・サイズの削減にあります。すべの DOMINO デー

タベースで DAOS を適用可能です。

DAOS アーキテクチャーについては、以下を参照してください。

IBM Lotus Domino going green: The new Lotus Domino attachment and object service

以下のフローチャートによって、DAOS をデプロイする場合の指針を示してい

ます。

図 46

DAOS の構成方法および効果の評価方法については、さまざまな Technote および

記事を入手できます。

サーバーごとにこれが必要かどうかをどのように確認しますか。Traveler 上で有効化する必

要がありますか。いいえ。数百ギガバイトのデータをホスティングする企業のクラスター・サー

バーで有効化する必要がありますか。そのとおりです。

114

DAOS をサーバー上で使用すると、追加のタスクがサーバー上で実行されます。DAOS では、NSF ファイル以外にも .NLO ファイルをバックアップする必要があるため、バックアップ

手順の変更も必要になります。

DAOS は 8.5.0 に導入されていますが、念のため、DAOS を実装する前に DAOS に 適

な環境として推奨されているバージョンの Domino で作業していることを確認する必要があ

ります。 また、「共有メール」を使用している場合には無効化する必要があります。ガイドラインとして上

記のフローチャートを参照してください。就業時間中には DAOS Estimator を実行しないでくだ

さい。就業時間後に DAOS Estimator を実行してください。

また、DDM (Domino ドメイン・モニター) を使用して DAOS をモニターすることも可能です。

次の参照先には、DAOS の構成と管理の要件が示されています。

• Technote 4021920

• Technote 1411563

• IBM Lotus Domino going green: The new Lotus Domino attachment and object service

• Achieving ultimate storage and server cost savings with DAOS in IBM Lotus Notes and Lotus Domino 8.5

• DAOS Backup and Restore

3.8. Domino の索引作成の管理

索引がないと、検索するデータの検出が非常に困難になります。Lotus Domino を使用する場

合には、ビュー索引、データベースの全文索引、およびドメイン索引の 3 種類の索引を使用で

きます。また、Domino 索引の作成には update、updall、chronos、kvoop および domidx など

複数のタスクが含まれます。 Domino の管理を初めてするときには、これは対応が困難な場合があります。この説明では、

Domino の索引作成の開始と管理に必要な情報を記載します。

3.8.1.ビュー索引

ビュー索引とは何でしょうか。Domino データベースを開くたびに、ビュー索引に基づいた情報

が表示されます。メール・ファイルの受信箱、個人フォルダ、またはカスタム・アプリケーションの

ビューで検索できますが、データが表示される方法や 新の更新が表示されるかどうかは

ビュー索引によって決まります。ビュー索引は Domino データベース内に格納されているため、

ビュー索引の有無、 新のものかどうか、または索引のサイズについて疑問が生じることがあ

ります。Domino Administrator には、その情報について簡単に確認できるツールが用意され

ています。そのツールにアクセスするには、Domino Administrator クライアントの「Files (ファ

イル)」タブに移動して、確認するデータベースを右クリックします。次に、図 47 に示されている

ように「ビューの管理」を選択します。

115

図 47

「データベースビューの管理」ウィンドウで、それぞれの各ビュー索引、索引のサイズ、ビュー

の作成者、 新表示間隔、廃棄間隔、およびビューを表示する Note ID を確認できます。図 48 では、一般的なメール・ファイルのビューを確認できます。

図 48 ビュー索引の使用法と格納場所を理解すると、次にビュー索引を更新する方法と対応するタ

スクについての情報が必要になることがあります。この情報については、Domino 管理のヘ

ルプ・トピック「インデクサタスク: Update および Updall」と「ビューの更新や再構築を行うキー

ボードショートカット」を参照してください。

3.8.2.全文検索

全文索引とは、Domino データベース内の検索で使用するように設計された索引です。全文索

引には文書内の単語のみが含まれている場合もあれば、サポートされているさまざまな添付タ

イプのファイル内のテキストがオプションで含まれる場合もあります。全文索引は、.ft フォルダ

内のアプリケーション外で作成され、保存されます。メール・データベースに全文索引があるか

どうかは、図 49 に示されるように検索バーの上に表示されたアイコンで容易に確認できます。

116

図 49

全文索引を作成する際には、更新頻度、添付の読み取りの有無や索引に含めるかどうかなど

を選択する必要があります。デフォルトでは、添付の索引作成はオフになっていますが、デフォ

ルトの更新頻度は、図 4 に示すように、索引の作成に使用される方法に応じて異なります。図 50 に示された「索引なし」をクリックしてメール・ファイル内から索引を作成する方法をユーザー

が選択すると、作成する索引の更新頻度は「即時」となります。これは、通常大半のアプリケー

ションでは推奨されていません。 Domino Administrator から索引を作成する場合、デフォルトは、大半のアプリケーションで推奨されている、毎日の更新です。

また、添付の索引作成の表現も異なります。 も完全な添付の索引作成は、kvoop タスクに

よって実行されるバイナリー索引作成です。このタスクでは、添付ファイルの読み取り用の

KeyView テクノロジー (Technote 7017002 参照) が実装されます。このタイプの索引作成は、

Domino Administrator クライアントでは詳細検索と呼ばれ、データベース・プロパティー「全文索引の作成」パネルでは変換フィルターと呼ばれています。

追加オプションにより、索引作成の暗号化フィールド、文章や段落の区切り、および大文字小文

字区別の検索を追加できます。通常、アプリケーションに応じて必要とされる少数のオプション

のみ使用して索引を作成し、全文索引のサイズを 小限に抑えることが 善の方法です。

図 50 データベースに全文索引がある場合、良い点と悪い点があります。全文索引を作成して保守す

るには、システムに追加のリソースが必要となります。しかし、データベースに全文索引が作成

されていない場合に検索を実行すると、一時索引が作成され、破棄されます。この操作を何度も

実行する場合には、永続全文索引を作成する方が効率的です。エージェントが全文検索を実行

した場合に全文索引がデータベースに作成されていないと、以下のメッセージがサーバーにより

ロギングされて全文索引の作成を勧められます。「Warning: Agent is performing full text operations on database 'mail/database.NSF' which is not full text indexed. This is extremely inefficient. (警告: エージェントは全文索引が作成されていないデータベース「mail/database.NSF」で全文操作を実行しています。この操作は非常に非効率的です。)」 一時的な全文索引を構築して維持するのはコストがかかるため、Domino Administrators では

117

118

索引の作成者、頻度、全文索引作成の対象を制御するさまざまなオプションを使用できます。

オプションについては、次の表を参照してください。

シナリオ 詳細 長所/短所

すべてのユーザー

は、自分が選択し

た更新間隔で全文

索引の作成を許可

されています。

索引を作成するために、ユーザーは

データベースに対して少なくとも設計者

のアクセス権限を持っている必要があり

ます。ユーザーはアプリケーション・プロ

パティー内の、「Full Text (全文)」タブ

に索引を作成できます。

長所:管理者の介入を

必要としません。

短所:これはベスト・プ

ラクティスではありませ

ん。メール・ファイルの ACL では、 高のアク

セス権である編集者の

設定をお勧めします。

短所:ユーザーは、大容

量のメール・ファイルで

「自動」または「即時」の

更新頻度で索引を作成

できます。これは、サー

バー全体のパフォーマン

スに影響を与える恐れが

あります。

Domino Administrator クラ

イアントを使用して

管理者が作成した

場合を除いて、全

文索引の作成は

許可されていませ

ん。

管理者がユーザー独自の全文索引の

作成を防止するには、サーバー上で

「UPDATE_NO_FULLTEXT=1」 を「NOTES.INI」に設定します。この設定

では、次のようになります(Technote 1092096 参照)。

現在の全文索引が更新し続けられます。 管理者は Domino Administrator クライ

アントから新規の全文索引を作成できます。

ユーザーは全文索引を作成できません。

長所:管理者は全文索引

を作成するタイミングと使

用する更新頻度を完全に

制御できます。 長所:全文索引付きの

メール・ファイルに「自

動」更新または「即時」

更新を設定することで発

生するパフォーマンスの

問題を防止できます。

短所:ユーザーが以前に

全文索引を作成すること

が可能だった場合には、

混乱が生じる可能性が

あります。

システム上の使用

可能なディスク・ス

ペースが少ないの

で、使用しない索

引を削除してス

ペースを確保しま

す。

デフォルトでは、ビュー索引は 45 日間アク

セスがないと消去されます。この期間を短

縮するには、サーバーの NOTES.INI ファ

イルでDEFAULT_INDEX_LIFETIME_DA YS=<# of days> を設定します。

長所:使用されていない

索引が占めるディスク・

スペースは、開放されて

再利用できます。

短所:低すぎる値を設定

した場合、ビューを以前

よりも頻繁に再構築する

必要が出て、パフォーマ

ンスにマイナス影響を及

ぼす可能性があります。

119

サーバー上で一時

索引が許可されて

いません。データ

ベース/アプリケー

ションを検索する

必要がある場合に

は、全文索引を作

成する必要があり

ます。

管理者は、FT_FLY_INDEX_OFF=1 を設定して、すべての一時索引の作成と削

除を防止できます(Technote 1161983 参照)。

長所:ユーザーが全文検

索を実行するたびに一

時索引を作成したり削除

せずに、全文索引を維

持してサーバー・リソー

スを確保します。

短所:データベースの検

索が一度だけ必要な場

合には、手動で全文索

引を作成および削除す

る必要があります。

特定のアプリ

ケーションで一

時索引の作成

が禁止されてい

ます。

ODS バージョン 48 以上では、「単純検索

を許可しない」という名前のデータベース・

プロパティーを設定できます。このプロパ

ティーが選択されていると、データベースに

は全文索引は含まれず、 ユーザーは「Application must be full text indexed before search is allowed. (検索が許可される前に全文索引を作成する必要があります)」というメッセージの全文検索を試行します。

長所: 一時全文索引の

作成によるサーバーの

オーバーヘッドを回避で

きます。ただし、すべて

のデータベースでオー

バーヘッドを回避できる

わけではありません。

短所:ユーザーが全文検

索の実施を望む場合に

は、ヘルプ・デスクの助

けが必要となることがあ

ります。

添付ファイルまた

は添付タイプの

全文索引を強制

または禁止した

い。

管理者は、いくつかの方法を使って添付

ファイルの全文索引を管理できます。

すべての添付ファイルの索引付けを無効に

するには、FT_Index_attachments=2に設

定します。

すべての添付ファイルに全文索引を強

制するには、FT_Index_attachments=1に設定します。

添付ファイルの特定のタイプを索引付けか

ら除外するには、FT_INDEX_IGNORE_ATTCHMENT_TY PES=<コンマで区切られたファイル・タイプのリスト

長所: 管理者は、サー

バー上のすべての添

付ファイルを標準に設

定できます。

長所: 添付ファイルの索

引付けは簡単に無効に

することが可能で、それ

により全文索引のサイ

ズや索引の構築や維持

に必要なシステム・リ

ソースを小さくできます。

短所: 添付ファイルの

索引付けを使用する

かどうかを判断するた

めの条件が異なるアプ

リケーション間では対

応できません。

120

バイナリー添付

ファイルの索引付

けを無効にしたい (kvoop プロセ

ス)。

FT_BINARY_FILTER_OFF=1に設定する

ことにより、管理者はバイナリー添付ファイ

ルの索引付けプロセス、別名、keyviewフィ

ルターが索引付けを行わないようにできま

す。

長所: サーバーで

kvoop プロセスが稼

働しないように簡単に

できます。

短所: Domino バージョ

ン 8.5.0 および 8.5.1 (SPR JSTN825PAV) では機能しません。

アプリケーション

を検索して、検索

結果の文書を開

いて内容を確認

するとき、添付

ファイル付きの文

書が開くのが添

付ファイルのない

文書より遅く感じ

られる。

検索結果の文書が開かれるとき、Dominoは検索で見つかったすべての検索ワードを

強調表示にします。また Domino は添付

ファイルを検索文字列で検索して、添付ファ

イルを強調表示すべきかどうかを判定しま

す。

長所: 検索後に文書を

開くと、ユーザーにとっ

ては体感応答時間が

短縮され、サーバーに

は必要とされるリソー

スが抑えられます。

このような検索を禁止し添付ファイルが強

調表示されないようにするには、サーバーの

notes.iniファイルで

FT_LIMIT_HIGHLIGHT_FILTER¬=1に設

定します。

短所: 添付ファイルが強

調表示されてないため、

サーバーの検索結果に

添付ファイルが含まれて

いることにユーザーが気

付かない可能性がありま

す。

索引付けプロセ

スで作成され使

用される一時ファ

イルは、データ・

ディレクトリーの

外に作られること

が望ましい。

索引付けプロセス中、サーバーによる一時

ファイル (Technote 1088574 参照) の作成および操作が必要となることが

あります。 一時ファイルを保存する

場所のパスは、サーバーの notes.ini ファイルの view_rebuild_dir=<目的の

ディレクトリーへの完全パスで指定できます。完全パスで指定できます (Technote 1090462 参照)。

長所: データ・ディレクト

リー内のファイル数が少

なくなればなるほど、

サーバーの効率性がさ

らに高まります。

短所:管理者は、サー

バーが所定の保管場所

を使用できるように、ファ

イルのある場所に常に注

意を払う必要がありま

す。

121

Chronos タス

クを一時的に

無効にしたい。

Chronos は、次のように設定することで無効

にできます (Technote 1099160 参照)。 Debug_Disable_Chronos=1

長所: トラブルシュー

ティングに必要となるこ

とがあります。また、

chronos の有無による

システム・パフォーマン

スの比較のためにも使

用できます。

短所: Chronos はビュー

および全文索引を毎時

間更新するために必要

です。 chronos を無効にした場合、ビューおよび索引は夜間に updall プロセスが実行されるまで更新されません。

3.8.3.ドメインの 索引

ドメイン索引は、複数の Domino アプリケーションまたはデータベースにまたがる全文索引で

す。 domidx タスクは、ドメイン索引を構築および保守する役割を担っています。ドメイン索引

は、監査員が特定のデータについて組織全体を検索する必要があるような法的状況におい

て特に有用です。ドメイン索引のプランニングおよび作成については、Domino 5 以降引き続

き Domino 8.5.x まで関連する説明、 「Domino R5: Domain Search」 またはDomino Administrator のヘルブ・トピック 「ドメイン索引を計画する」、または「Key points to consider when creating a domain index」の wiki の説明を参照してください。

3.9. Domino 環境のバックアップ Lotus Domino は従来のファイル・サーバーとは異なるデータベース・システムです。ファイ

ル・サーバーのユーザーは主に営業時間中にファイルにアクセスするため、管理者は営業時

間外にバックアップを実行することになります。 Lotus Domino サーバーは、そうする代わりに、どのユーザーもメール・ファイルまたはアプリ

ケーションにアクセスしていない場合、常にアクティブにデータベースにアクセスします。NSF ファイルは常にアクセス中 (使用中) であるため、ほとんどのオペレーティング・システム・バッ

クアップ・ソフトウェア製品は NSF ファイルをスキップします。こうした状況はファイル・サー

バーには容認できても、Dominoサーバーには許容できません。

この章では、Lotus Domino サーバーを効率的にバックアップするとともに、バックアップ・デー

タ・リストア時の頭痛のタネを事前に摘むための、特別なテクノロジーと方式について説明しま

す。ここでは、できるだけ早く Lotus Domino の機能を回復し重要なデータを復元するための

信頼できるバックアップ計画をどのように策定すべきかについての情報を提供します。

期待される結果を明確にするため、この記事ではバックアップの主目的を災害時のサーバーの

回復とサーバー内のデータの復元に設定します。ここでのバックアップをアーカイブによるバック

アップと混同しないでください。これらは完全に別のトピックとなります。

3.9.1.バックアップの 基本

先にも述べたように、Lotus Domino サーバーのバックアップの手順はファイル・サーバーと異な

ります。Domino には開いた状態の多数のファイルがあり、たとえアクセスするユーザーがいな

くても開いた状態のファイルに対するバックアップ動作を実行するためです。

開いた状態のファイルを想定していない通常のバックアップ・ソフトウェアの使用には危険が伴

います。こうしたソフトウェアは Domino がアクセスしようとしているファイルをロックされたファイ

ルとして通知する可能性があります。これは、Domino のエラー「このデータベースは現在、他

の誰かによって使用されています…」の原因となります。

要約すれば以下の問題があります。

• バックアップ・ソフトウェアと Domino が同じファイルへのアクセスを同時に要求する。 その

ため適切に制御されない場合、データが破損することがある。 • ダウン時間

一般的に Lotus Domino の効率的バックアップには、いくつかの有効な方式、ツールお

よび機能があります。

Domino 用のバックアップ・ソリューションは、Domino データ (添付ファイルを含む) および

Domino サーバーのプログラム・ファイルのみを対象としてバックアップを行います。オペレー

ティング・システムのバックアップおよびリストア・ソリューションは当説明の対象範囲外です。

その説明はオペレーティング・システム・レベルのバックアップの範囲と見なされます。

3.9.2.バックアップ方式

この説明では、Lotus Domino に固有のバックアップ方式について解説します。ただし、すべ

ての概念があらゆる環境に適合するものではありません。ここでは環境のサイズが増大を続

け、ダウン時間の削減および機能強化の要求が変化するものと仮定します。

以下の表は環境のサイズに応じてどの方式を適用すべきかを提案するものです。 方式 少規模 中規模 大規模

オフライン・バックアップ +++ +

クラスタリング / シャドー.

バックアップ ++ +

+

オープン・ファイル・バックアッ

プ + +

+

Dominoアプリケーション レベル・バックアップ

+ +++

+++

複製 (~)

オフライン・バックアップ 先にも述べたように、Lotus Domino データベースは Domino が NSF ファイルにアクセ

スし続けるため簡易なファイル・バックアップ・ソフトウェアではバックアップできません。

122

123

オフライン・バックアップとは、バックアップを開始する前に Lotus Domino サーバーをシャットダ

ウンし、バックアップが完了してから再始動することを意味します。このアクションでは、データ

ベース・ファイルは必ず未使用になります。当然、この方法ではサーバーがダウン時間に入るた

め、すべての環境に対して推奨できるものではありません。

ダウン時間が許容可能な小規模環境では、この戦略は特別なバックアップ・ソフトウェアな

しにデータをバックアップできる考慮すべき選択肢となります。すでにお持ちのオペレーティ

ング・システム用の単純なバックアップ・ソフトウェアでも代用品としても十分に役立ちます。

Lotus Domino サーバーのシャットダウンを自動化するには、管理者がオペレーティング・シス

テム・レベルでスクリプトを使用してバックアップ開始前にシャットダウンを開始するようにスケ

ジュール指定する必要があります。一部のバックアップ・ソフトウェアでは、バックアップ・ジョブ

の一環として、一般に前処理または後処理と呼ばれるオペレーティング・システム・コマンドも実

行できます。 Microsoft Windows 上で実行される Domino サーバーでは以下のコマンドを使用できます。

バックアップ開始前 net stop “Lotus Domino server”

バックアップ完了後 net start “Lotus Domino server”

この方法は以下の場合に使用します。

• ビジネス上、サーバーの数時間のダウン時間が許容される。 • Domino 用の認定バックアップ・ソフトウェアが利用できない。

注：

• ポイント・イン・タイム・リストアが必要な場合は、オフライン・バックアップ方式は使用でき

ません。 ポイント・イン・タイム・リストアは、Lotus Domino の機能の一つであるアーカ

イブ・トランザクション・ロギングと組み合わされたアプリケーション・レベルのバックアッ

プでのみ可能です。 • バックアップ・プロセス中、Domino サーバーは停止します。 バックアップ・ジョブが中

断した場合、手動による介入がない限り Lotus Domino は始動しません。 • バックアップしたバックアップ・セットは同一マシンには保存できません。 災害時に

は、必ずしもすべてのデータを復元できないことがあります。

オープン・ファイル・バックアップ ダウン時間が許容できない場合、Domino サーバー上の開いたファイルをバックアップする機

能を備えた企業向けの特殊なソフトウェア・パッケージの使用が適切 (ただし高価) な方法となり

ます。このタイプのソフトウェアは、ネットワーク上のすべての Domino サーバーをオフラインに

することなく一個所でまとめてバックアップできます。

開いたファイルをバックアップするための特殊な技術がバックアップ・ソフトウェアに使用されて

いないため、この方法は特別な Domino 認定ソフトウェアを必要としません。

この方法は以下の場合に使用します。

• Dominoサーバーがトランザクション・ロギングを使用していない。 • ダウン時間は許容できないが、Domino認定のバックアップ・ソフトウェアを使用するこ

ともできない。 特定の時点で Domino データをリストアする必要がない。 リストアする場合は、トランザ

クション・ログを含むアプリケーション・レベルのバックアップが必要です。

124

Domino アプリケーション・レベル・バックアップ この方法はおそらく も一般的な Lotus Domino Server のバックアップ方法であり、Lotus Domino Backup API の使用を認定されたソフトウェアによってオペレーティング・システムと Domino データが別々にバックアップされます。

アプリケーション・レベルのバックアップにオペレーティング・システム・ファイルは含まれない

ため、同一のサーバーに 2 つのバックアップ・システムをインプリメントする必要があります。

• 1 つはオペレーティング・システムとそのデータをバックアップするためのシステムです。 • もう 1 つはアプリケーション・レベルのバックアップ・システムで、認定バックアップ・ソ

フトウェアを使用する Lotus Domino です。

標準 Notes® データベース (NSF) では、添付ファイルは NSF ファイル内に保存され、データ

ベース自体が独立しています。つまり、標準 Notes データベースのバックアップに必要なのは NSF ファイル自体のバックアップのみです。Lotus Domino 8.5 からは DAOS という新機能が

導入され、DAOS を適用した NSF ファイルにはすべてのデータが含まれなくなりました。代わり

に、NSF ファイルには、*.NLO タイプのファイルに別途保存されている添付ファイルの内容への

参照のみが含まれています。

そのため、NSF のみのバックアップでは不十分になりました。同様に NLO データもバック

アップする必要があります。詳しくは、Technote 1358548 を参照してください。

注：

• 重要なデータは Lotus Domino プログラム・ディレクトリー内に保存されていることを忘れな

いでください。例えば、NOTES.INI および Server.ID は定期的にバックアップする必要があ

ります。

トランザクション・ログ・バックアップ トランザクション・ログ・バックアップは、実際には計画そのものではありません。Domino アプリケーション・レベル・バックアップの拡張であるトランザクション・ログ・バックアップの利点

を享受するには、管理者は Lotus Domino との連携を認定されたソフトウェアでリストアを実

行する必要があります。

トランザクション・ロギングは、データベースの変更を収集して順番にトランザクション・ログへ書

き込む処理であり、別のディスク・ドライブ (単なるパーティションではなく) で行う必要がありま

す。Domino はトランザクション・ログ・ファイルをこのドライブに作成し、サードパーティーのバッ

クアップ・ソフトウェアが API を使用してバックアップするまでファイルを削除しません。Notes データベースに書き込む前にまずトランザクション・ログの処理を行うことで、トランザクション・ロ

ギングはパフォーマンスを向上させ、データベースのデータの整合性を確保します。

Domino のトランザクション・ログは、「循環」モードと「アーカイブ」モードの 2 つのモードで構成で

きます。

• アーカイブ・モード – トランザクション・ログ (*.txn) は必ず、IBM Tivoli Storage Manager

for Mail または Data Protection for Lotus Domino などの認定 Domino バックアップ・ソ

フトウェアでバックアップしてください。 バックアップを取らないと、ログ・ファイルが増大し続

け、トランザクション・ログ・ディスク・ドライブに空き容量がなくなりサーバーがクラッシュして

しまいます。バックアップをしなくても、 低 24 時間のタイムフレームはサポート可能なディ

スク・スペースが十分にあることを確認してください。

125

• 循環モード – 構成可能な固定のディスク・スペースを使用してサーバーのパフォーマンス

を向上します。 データベースのポイント・イン・タイム・リストアは提供しません。このモード

では、バックアップを取った時点の状態にのみデータベースをリストアすることができます。

トランザクション・ロギングの詳細については、以下の文書を参照してください。

• Technote 7003543 • IBM Infocenter 記事「Lotus Domino Server でのトランザクションログを設定する」 • Technote 7009309

複製 おそらく も非効率的なデータのバックアップ方法である複製では、重要なデータベースを異

なるサーバー間で複製するように管理者が Lotus Domino を設定して、情報のライブ・バック

アップをどこか別の場所で実行できるようにします。

この方法は次の理由から綿密な計画が要求されます。

• 削除された文書は複製可能であり、複製されます。 誤って削除された文書はリストアできま

せん。削除を複製しないようにデータベースを構成できます。これは膨大な管理オーバー

ヘッドを追加します。さらに、すべてのデータベースで許容可能ではないかもしれません。 • 設計エレメントは複製可能であり、複製されます。 これは設計およびデータの破壊の

原因となり、バックアップが無用になってしまう場合もあります。 • サーバー自体に対してローカルな重要ファイルは複製されません。 例えば、NOTES.INI

および Server ID ファイルは複製されずにバックアップされます。サーバーのデータ・ドライブに障害が発生した場合にファイルのバックアップがないと、システム障害が発生します。

絶対にデータベースのバックアップ方法として複製だけに頼らないでください。損傷した、また

は誤って変更されたデータベースが複製される可能性があり、その場合に頼りにできるのは

サーバーのバックアップ・テープからデータベースを回復する方法だけです。この方法に意義

を持たせるには、他のバックアップ概念と組み合わせる必要があります。

クラスター、シャドー・コピー、およびシャドー・バックアップ このバックアップ計画は複製バックアップとオフライン・バックアップを混合したものです。 想定：両方のサーバーが同じデータをホストしていて定期的に複製する、または同じ Domino クラスターの一部である (以下の例を参照) とします。

就業時間内は両方のサーバーがアクティブで、ユーザーは両方のインスタンスで作業可能

です。就業時間外はサーバー B がオフラインになり、前述のオフライン・バックアップ方法を

使ってバックアップされます。 バックアップ処理中は、サーバー B はダウンしています。この間も、ユーザーは同じクラスター

の一部であるサーバー A にアクセスできます。ユーザーは作業を続けることができ、サーバー B が稼働状態に戻ると変更がサーバー B に複製されます。

図 51

この計画の課題は、両方のサーバーを常に同期させる点です。なぜなら、サーバー A で作成

されたデータベースのすべてについて自動的にサーバー B にレプリカが作成されるわけでは

ないからです。さらに、すべてのデータを 1 つのサーバーからもう 1 つのサーバーに正常に

複製しなければならず、これは例えばサーバーがメンバーではないリーダー名フィールドをア

プリケーションで使用する場合は成功しません。

同様の計画が使用される Enterprise Storage Systems ではより高度な追加オプションが提供

されます。 初に、オンライン・データが専用ストレージ・プールにミラーリングされます。バック

アップを実行している間は、フラッシュ・コピー処理が中断されます。この技術および異なるベン

ダーのオプションの説明は、この記事では取り上げていません。詳細については、ストレージ担

当者にお尋ねください。

注：

• Lotus Domino は現在 Microsoft Volume Shadow コピーをサポートしていません。

詳細については、Technote 1196479 を参照してください。

• Domino クラスタリングの動作を理解するには、旧版ですが有効な次の IBM Redbooks 文書を参照してください。 Lotus Domino R5 Clustering with IBM eServer xSeries and Netfinity Servers

3.9.3.バックアップ・ ソフトウェア

Domino サーバーに使用するバックアップ・ソフトウェアは、現在の環境のバックアップ・イン

フラストラクチャー・バックエンドによって異なります。Lotus Domino 向けのさまざまな認定

バックアップ製品が市販されていますが、この記事では次の IBM 製品について重点的に

説明します。

• IBM Tivoli Storage Manager • Tivoli Storage Manager for Mail (以下「TDP」と表記) トランザクション・ログを含む

Lotus Domino データのバックアップについて認定されています。

Lotus Domino のアプリケーション・レベルのバックアップを実行するには、次のコンポーネン

トが必要です。

• IBM Tivoli Storage Manager Server (TSM server) • DAOS を含む静的データ・バックアップおよびリストア用のIBM Tivoli Storage Manager

Agent (TSM クライアント) • TSM for Mail – Data Protection for Lotus Domino (TDP) 5.5.2.1. 以下の説明を参

照してください。

126

127

IBM Tivoli Storage Manager for Mail - Data Protection for Lotus Domino (TDP) TDP は、Domino データベースおよびトランザクション・ログ・ファイルのオンライン・バックアッ

プ (つまり Domino サーバーを停止する必要がないバックアップ) を行うための機能を提供し

ます。TDP はデータベース (*.ns*)、テンプレート (*.ntf)、およびログ・ファイル (*.txn) に対して

のみ機能します。TDP はデータのリストアも処理します。TDP は TSM アプリケーション・プロ

グラム・インターフェースである TSM クライアントを経由して TSM サーバーと通信します。

Domono サーバーとの通信には、TDP は Lotus Domino API を使用します。 TDP の操作には、コマンド・ライン・インターフェース、GUI、Tivoli Manager for Domino との統合などいくつかの方法があります。

TDP のシステム要件の詳細については、次の Technote 1297052 を参照してください。

注： TDP には Domino サーバーのディザスター・リカバリー機能はありません。プログラム・ファイ

ルではなくデータのみをバックアップするためです。ディザスター・リカバリーをサポートするに

は、TDP を TSM クライアントと組み合わせて使用する必要があります。

TDP および Domino Server タスクとの相互依存 トランザクション・ロギングが有効になっている Domino サーバーでは、Domino がデータ

ベース・インスタンス ID (DBIID) を各 Domino データベースに割り当てます。Domino がトラ

ンザクションをトランザクション・ログ・ファイルに記録すると、DBIID が含まれます。リストア中、

Domino は DBIID を使ってトランザクションとデータベースを照合します。レプリカ ID と DBIID は無関係です。

データベースの保守管理アクティビティーは 2 つあります。

• COMPACT ("-b" 以外のすべてのスイッチ) • FIXUP では Domino サーバーが新しい DBIID をデータベースに割り当てます。

この時点から、すべての新規トランザクションは新規 DBIID を使ってトランザクション・ログ・

ファイルに記録されます。ところが、古いトランザクションには古い DBIID が割り当てられてい

るので、データベースの新しい DBIID と一致しなくなります。その結果、Domino は古いトラン

ザクションをデータベースにリストアできません。このシナリオでは、TDP を使ってこのデータ

ベースの新規バックアップを作る必要があります。これは TDP バックアップの増分タイプで行

います。

3.9.4. バックアップ の 対象

次の表は Domino バックアップの対象とする必要のあるデータを示しています。 こ

のリストには、オペレーティング・システムによって異なるオペレーティング・システ

ム・ファイルは含まれていません。

# データ 説明 バックアップ・

ユーティリティー

1 プログラム・コード

Domino プログラム・コードのバックアッ

プ

\*.*

TSM クライア

ントなどの

ファイル・バッ

クアップ

128

2 静的データ すべてのサブディレクトリーおよびディレクトリー・リンクを含む Domino データ・ディレクトリーのバックアップ

ファイル・バックアップ

\*.*

次のファイルおよびディレクトリーは除

外する必要があります。:

o .ntf (テンプレート) o .ns* (データベース) o .ntf (メールボックス、SMTP

メールボックス) o .txn (トランザクション・ログ・ファ

イル) o .txn.dad (トランザクション・ロ

グ・ファイル) o .ft\ (全文検索ディレクトリー) o .tmp (Domino データ・ディレク

トリー内の一時ファイル)

TSM クライアン

トなど

3 増分バックアップ 新規 Domino データベース、トランザク

ション・ロギングの対象外データベース、

および FIXUP または COMPACT プロ

グラム文書によって変更されたデータ

ベースのバックアップ

増分 l オプショ

ンを使用した TDP などの認

定 Domino バックアップ・

ユーティリ

ティー

4 Domino デー

タベース・バッ

クアップ

システム・データベース、テンプレート、メール・ファイル、およびアプリケーション・データベースのバックアップ

選択 (フル・

バックアップ) を使用した TDP などの認

定 Domino バックアップ・

ユーティリ

ティー

5 トランザクション・

ログ・バックアッ

プ

トランザクション・ログ・ファイルのバック

アップ

「アーカイブ」タイプのトランザクション・

ログ・ファイルを日次で複数回 (2 時間

ごと)。「循環」タイプのトランザクション・

ログはバックアップしない

アーカイブ・ロ

グ・オプションを

使用した TDP などの認定 Domino バック

アップ・ユーティ

リティー

6 DAOS データ DAOS ドライブにある DAOS データの

バックアップ

週次および月次のフル・バックアップ

TSM クライア

ントなどの

ファイル・バッ

クアップ

129

3.9.5. バックアップ手順

Domino 認定バックアップ・ソフトウェアでは、次のバックアップを実行できます。

• フル・バックアップ • 増分バックアップ • 選択バックアップ • アーカイブ・ログ

アプリケーション･レベルでのバックアップとは別に、下位レベルで実行されるバック

アップ・タイプもあります。

• DAOS バックアップ

これらのバックアップについては、次のセクションで説明します。

フル・バックアップ フル・バックアップとは、Domino 認定バックアップ・ソフトウェアを使用してバックアップを

行う、すべてのファイルを含むバックアップです。Domino 認定バックアップ・ソフトウェア

では、ファイル・ベースのフル・バックアップとは異なり、Domino がオンラインの間に Domino ファイルをバックアップできます。

増分バックアップ 少なくとも次のいずれかの条件が満たされている場合に実行される、TDP を介した完

全なデータベースのオンライン・バックアップです。

• ルール (インクルード・エクスクルード・リスト) によりデータベースがバックアップ対象から除

外されていない。 • データベースでトランザクション・ロギングの使用が有効になっており、DBIID が変更され

ている。 すべてのデータベース・トランザクションで、サーバーのデータベースごとに固有

な DBIID がキーとして使用されています。トランザクション・ログのリカバリーが可能になる

ように、ログ内のトランザクションの DBIID はデータベースの DBIID と一致しています。修

正の実行 または圧縮タスクによって DBIID が変更されます。DBIID は、圧縮を「-b」オプションを使用

して開始 (インプレース圧縮) した場合のみ変更されません。

• データベースがトランザクション・ロギングの対象でなく、 後のバックアップ以降変更され

ている。 データベース自体またはアクセス制御リストの変更は、そのデータべースのバッ

クアップを決定するために使用されます。 • 新規データベースか、バックアップ･リストに追加されたばかりのデータベースである。

重要: TDP の増分バックアップ機能を、更新日やファイル時刻の変更時にバックアップを行う TSM クライアントの増分バックアップに有効なルールと混同しないでください。 TDP では、上

記のいずれかの条件と一致するすべてのデータベースをバックアップします。TDP の増分バッ

クアップおよび選択バックアップはいずれもフル・バックアップです。これはいずれのバックアッ

プ操作でも、完全なデータベースが保存されることを意味します。

選択バックアップ 選択バックアップでは、バックアップ対象のデータを Domino のデータ・プールから選択します。

130

この機能は、TDP を使用してバックアップできるすべてのファイルをバックアップするために使

用します。クラスター・メンバーのメール・ファイルは除外します。これによって容量を節約でき

ます。

アーカイブ・ログ TDP のアーカイブ・ログでは、記録されたトランザクション・ログ・ファイルを TSM サーバーに

保存して、Domino サーバーがこれらのファイルに割り当てられた容量を再利用できるように

します。Domino サーバーでトランザクション・ロギングのアーカイブが有効になっている場合、

アーカイブ・ログ・コマンドを使用できます。記録されたトランザクション・ログ・ファイルは、トラ

ンザクション・ログのストレージ・スペースがいっぱいになり、Domino サーバーを停止してしま

わない程度に頻繁にアーカイブする必要があります。 TSM サーバーに保存されているトランザクション・ログ・ファイルは、データベース・リカバリーの必要に応じて自動的にリストアされます。

トランザクション・ログ・ファイルのアーカイブは、リカバリーの実行にこれらのログ・ファイル

を必要とするデータベース・バックアップが存在する限り、TSM サーバーに保持されます。

上記のすべてのバックアップ手順は、コマンド・ライン・スクリプトを使用して自動的に

実行できます。

DAOS バックアップ

DAOS バックアップは、TDP のフル・バックアップ・スケジュールに従って実行されます (週次および月次ベース)。データは、Domino のバックアップに使用される管理クラスに書き込

まれる必要があり、そのため保存期間は同じになります。DAOS バックアップは TSM クラ

イアントを使用して実行する必要があるため、変更されたファイルのみがバックアップされま

す (従って、増分になります)。

DAOS のバックアップとリカバリーの詳細については、次の Technote 7015114 を参照してくだ

さい。

3.9.6. バックアップ・スクリプト

このセクションでは、12 カ月間 Domino データをリストア可能にする必要がある環境のバック

アップ・スケジュール例について説明します。

次の表には、さまざまなファイル・タイプをバックアップする手順を、データの保存期間、スク

リプト名、Domino サーバーでのスクリプトの汎用スケジュール設定とともに示します。

# データ パターン 保存期間 スクリプト / スケジュー

ル

1

プログラム・コ

ード

Domino プログラム・コー

ド

*.*

3 日

OS の日次での増分 TSM バックアップに

含まれます

131

2

静的データ

静的 Domino データ・

ファイル、サブディレク

トリーおよびディレクト

リー・リンクを含む Domino データ・ディレ

クトリー

\*.* 次は除外します

o .ntf o .ns* o .box o .txn

o .txn.dad o .ft\

3 日

OS の日次での増分 TSM バックアップに

含まれます

3 増分バックアップ Domino データ・ファイ

ル

30 日 incremental.cmd

/日次

4

Domino データ

ベース・バック

アップ

Domino データ・ファイル

6 週

dombackupWK.cmd /

週次 (各月の 後の

週末は除きます)

5

Domino データ

ベース・バック

アップ

Domino データ・ファイ

ル

12 カ月

dombackupMT.cmd /

週次 (各月の 後

の週末)

6

トランザクション・ログ・バックアップ

トランザクション・ログ・ファイル

30 日

archivelog.cmd /

日次または 1 日に複

数回 (2 時間ごと)

7

DAOS 週次

バックアップ DAOS ファイル

6 週

dombackupWK.cmd /

8

DAOS 週次

バックアップ

DAOS ファイル

12 カ月

dombackupMT.cmd /

週次 (各月の 後

の週末)

132

9

バックアップ・ファイル

なし。このコマンドは、

TMS サーバー上の *.txn を非アクティブに

します。

inactivatelogs.cmd /

週次で dombackupWK.cmd に含まれます /

週次

手順 6 から 9 は、トランザクション・ロギングのアーカイブが有効な Domino サーバーでのみ有効であることに注意してください

3.9.7. 推奨事項

あらゆる環境に役立つヒントを以下に示します。

• バックアップがいつどのような頻度で実行されるかをエンド・ユーザーが把握できるよう、

バックアップ標準を公開します。 • リカバリー・データが有効であることを確認するため、バックアップ・リストア・テストを実行しま

す。 • どのデータをどのくらいの期間保存するかを定義し、その後、どのようなことが起こる

か慎重に精査します。 も古いバックアップはリストアできる必要があります。(アーカイブ・バージョンとして機能する) 年次でのバックアップを実行する意味があるか評価します。このバックアップは安全な場所に保存します。

• バックアップ環境を適正にモニターし、エラーがあった場合は迅速に対処します。 エラーによってリストアが不可能であった場合は、その状況を文書化します。

• 消費したバックアップ・リソースをエンドユーザーにチャージバックできるような方法を策定します。 このようにすれば、ユーザーが適切なバックアップ・インフラストラクチャーにかかるコストを理解できるようになります。

• Domino の下位にあるオペレーティング・システム、およびテープ・ロボットとそのスケ

ジュールなどのバックアップのバックエンドを含むバックアップ環境を広義に理解します。 • 他のチームとコラボレーションします。 Domino プラットフォームおよびバックアップの実

行方法に精通していない他のユーザーと知識を共有します。

3.9.8. まとめ

Lotus Domino でバックアップを実行するには、SQL データベースなど、他のアプリケーション・

システムと同様な要件を満たす必要があります。バックアップの も効率的な構想には、環境

および提供されているバックアップ・インフラストラクチャー (存在する場合) の規模を考慮する

必要があります。

3.9.9. 参照情報

この記事内の情報は、次の文書に基づいています。

• Technote 7009311 • Technote 1358548 • Lotus Domino Server をバックアップする • Technote 1196479

• Technote 1095238 • IBM Redpaper 「Choosing the right backup strategy for Domino 6 for iSeries」 • IBM InfoCenter 「IBM Tivoli Storage Manager for Mail – Data Protection for Lotus

Domino」

3.10. リストア

Lotus Domino 環境には、さまざまなリストアのシナリオがあります。

• フル・システムのリストア – ハードウェア全体またはサイト全体で障害が発生した場合

などのディザスター・リカバリーに必要です。 • 1 つ以上のデータベースのリストア - 1 つ以上の既存のデータベースを置き換えます。 • データベース内の 1 つ以上の文書のリストア

一般に、データのリストア技術はシナリオによって異なります。また、サーバー・タイプや使用

可能なバックアップも重要になります。 異なるデータ・タイプと、そのリストア・プロセスに必要なツールを以下の表に示します。

データ・タイプ ユーティリティー

プログラム・ファイル TSM クライアントなどのファイル・バックアップ・ソフト

ウェア

133

静的な Domino データ・ファイル TSM クライアントなどのファイル・バックアップ・ソフト

ウェア

Domino データ・ファイル TDP などの認定 Domino バックアップ・ユーティリ

ティー

上記の表に加えて、トランザクション・ロギングが有効な Domino サーバーには以下が必

要です。

データ・タイプ ユーティリティー

トランザクション・ログ・ファイル TDP などの認定 Domino バックアップ・ユーティリティー

DAOS データ TSM クライアントなどのファイル・バックアップ・ソフトウェ

ア

DAOS が有効な場合のトランザクション・ログには、DAOS ストレージ・ディレクトリーを

バックアップするためのツールが別途必要になります。DAOS は添付ファイルをデータ

ベース・ファイルとは別に格納します。そのため、従来のバックアップでは添付ファイルが

バックアップされず、製品がリストアされます。

トランザクション・ログ・ファイルのバックアップおよびリストアには、Domino 外部の製品が使

用されます。トランザクション・ロギングが無効な場合は、DAOS および NSF はフラット・ファ

イルとして復元できます。

リストア・プロセスは、以下の 3 つの部分に識別できます。

• ディザスター・リカバリー • 静的ファイルのリカバリー • Domino データ・ファイルのリカバリー

134

3.10.1. ディザスター・リカバリー

このプロセスでは、すべてのファイルおよびディレクトリーをリカバリーすることによって Domino サーバー全体をリストアします。このプロセスを実行するための前提条件として、すべ

てのレジストリーおよび構成設定を含む、完全にリカバリーされたオペレーティング・システムが

必要です。

ディザスター・リカバリーの 1 つのシナリオは、必要 小限のリストアを実行すること、つまり

空のハードウェア上にすべてのソフトウェアをリカバリーすることです。ここでは、以前のとお

り完全に機能するようにオペレーティング・システムをリストアすることが重要な課題になりま

す。使用する方法はサーバーのオペレーティング・システムおよび構成によって異なります。

詳しい手順については、オペレーティング・システム・ベンダーおよびバックアップ・ソフトウェ

ア・ベンダーにお尋ねください。

ハードウェア障害などの問題が原因で元のサーバーをオンラインに戻せない場合は、Lotus Domino を別のハードウェアにリストアすることを検討してください。Domino 自体は、必ずしも

同じオペレーティング・システムまたは同じハードウェアを使用する必要はありません。

Lotus Domino を移動するには、いくつかの点に留意する必要があります。Technote 1464076 に、Lotus Domino サーバーをハードウェア間で移動する方法が説明されています。

以前と異なるハードウェア上にサーバーを再構築するディザスター・リカバリーも同様の考え

方で行えます。

オペレーティング・システムおよびインストールされたオペレーティング・システム・アプリケー

ションをリカバリーしたら、直ちに Lotus Domino をリストアします。これを実行するためにディ

ザスター・リカバリーで使用するツールおよびプロセスについて、次の 2 つのシナリオで説明し

ます。

3.10.2. 静的 ファイルの リカバリー

静的ファイルとは、Domino のプログラム・ファイルと、Domino データベースやテンプレート

を除く Domino データのファイルを指します。この例では、TSM クライアントを使用してこれ

らのファイルをリストアします。

バックアップ内に保持されていれば、特定の日付から 新のバックアップまたはファイルをリス

トアすることが可能です。このリストア・プロセスは、ファイル・サーバーからファイルをリストアす

る方法と同じです。

Domino ではプログラム・ディレクトリー内の一部のファイルを常に使用しているため、静的な Domino ファイルをリストアする場合は、静的ファイルをリストアする前に Domino をシャットダ

ウンすることを検討してください。

3.10.3. Domino データ・ ファイルの リカバリー

ある時点の特定のデータベース (.nsf ファイル) をバックアップ環境からリストアするなど、

ユーザーから個別にリストアを要求されることがあります。 ユーザーは通常、以前と同じよ

うにデータにアクセスできることを望みます。

135

データをリストアするには、以下のいずれかの方法を実行できます。

• スタンドアロン - (現行のアプリケーションとは別個に、) スタンドアロン・アプリケーションの

形式でリストアを提供します。これをユーザーからアクセス可能にします。ユーザーは個々の Notes 文書を検索してリストアする必要があります。

• マージ – 現在のデータとリストアしたデータをマージすることによって、データを実稼働環境にリストアします。

• 置換 – 現行のアプリケーションをバックアップから取得した .nsf ファイルで完全に置き換

えます。

これらのオプションについては、以下のセクションで説明します。

スタンドアロン・リストア スタンドアロン・リストアでは、ユーザーは、実稼働環境のデータに影響を与えることなくリスト

アしたデータにアクセスできます。

これは一見シンプルな方法に思われますが、リストアしたデータベースについて管理者が留

意するべき課題がいくつかあります。

• リストアしたデータベースと実稼働環境のデータベースの機能に違いはありません。 • 明示的に無効にされていない限り、スケジュールされたバックグラウンド・エージェントが

リストアしたデータベースで実行されます。 • 同じ ACL が設定されているため、このファイルへのユーザー・アクセスが直ちに許可さ

れます (許可しないよう構成されている場合を除く)。

• リストアしたデータベースは複製可能です (複製できないよう構成されている場合を除く)。

この例では、Domino データ･ファイルのリストアに TDP/TSM を使用します。トランザクション・

ロギングがアーカイブ・モードで有効になっていない Lotus Domino サーバーでは、指定され

た 1 つ以上のファイルが TDP によって TSM サーバーからリカバリーされます。

通常、このリストア・プロセス (TDP/TSM) によってリストアしたデータベースでは複製が自動

的に無効になるため、ファイルがバックアップされたサーバーにリストアすることは好まれる方

法の 1 つです。しかし、古いサーバーで電源がオフになっているなど、これを実行できない場

合があります。

Domino データ・ファイルのリカバリーでは、以下の 3 段階のプロセスを実行します。

1. 1 つ以上のデータ・ファイルをリストアします。それぞれのファイルは、別の名前で異なる

ディレクトリーまたはサーバーにリストアできます。(図 1 を参照してください)。Domino データ・ファイルのリストアは、 新のバージョンや特定の日付を対象に実行できます。

2. Domino データ・ファイルをアクティブ化します。この機能により、リストアしたデータベースが

オンラインになり、Domino サーバーで使用可能になります。オプションで、トランザクショ

ン・ログからトランザクションを適用してデータベースを更新できます。特定の時点までのト

ランザクションを適用することも、トランザクション・ログに記録されている 新の変更を適用

することもできます。アーカイブを行うロギングが有効な場合は、Lotus Domino の TDP により、アーカイブされたトランザクション・ログ・ファイルが必要に応じて自動的にリストアされ

ます。 3. トランザクション・ログのリストアが終了して Domino データベースのリストアが完了すると、

TDP により、リストアを完了するためにリストアする必要のある DAOS ファイルのリスト

が提供されます。DAOS ファイルのリストアには、TSM クライアントを使用します。

TDP は Domino データ・ファイルをデータベース・レベルでリストアします。単一の文書をリス

トアするには、データベース全体をリストアする必要があります。その後、Notes クライアント

を使用して目的の文書を元のデータベースにコピーできます。

単一データベースのリストアの実行 一般的に見られる誤りを回避して、 も効率的なリストアの方法および対象を定義するための

ヒントを図 52 のフローチャートに示します。

注: このフローチャートは参考にのみ使用してください。ご使用の環境にそのまま適用しないで

ください。環境はそれぞれ固有であり、ここに記載していないその他の考慮事項が数多く存在

します。

図 52

136

項目 説明と考慮事項

1 リストアするデータベースは暗号化されていますか。 詳細は、データベースのプロパティーおよび暗号化設定を確認してください。

2 バックアップを実行したサーバーで DAOS が有効になっている、または以前有効

になっていましたか。 サーバー文書の DAOS タブで詳細を確認してください。

3 バックアップを実行したサーバーで DAOS 暗号化が有効になっている、または以前有効になっていましたか。 注: DAOS オブジェクト (*.NLO ファイル) を暗号化しないよう明示的にサーバーを構成していない限り、DAOS 暗号化はデフォルトで有効になります。これは、 リストアを実行したサーバーとは別のサーバーへのリストアを可能にする場合に有益です。

4 この場合は、バックアップを実行したサーバーにデータベースをリストアする必要

があります。サーバー ID は同じ必要があります。これは、そのサーバー ID を使

用してデータベース自体またはその DAOS オブジェクトが暗号化されているため

です。別のサーバーにリストアすることはできません。

5 データベースは元のサーバーにリストアする方がより効率的ですが、 企業ポリシーによって専用のリストア・サーバーを使用するよう要求される場合もあります。 このシナリオでは、必要に応じて、このデータベースを別のサーバーにリストアすることが可能です。

6 バックアップおよびリストア・ソフトウェアを使用して、Domino NSF ファイルをリストアします。処理を続行する前に、以下の項目をすべて確認してください。

• レプリカ ID を変更している。バックアップ・ソフトウェアによっては、リストア・プロセス

の過程で実行できます。それ以外の場合は手動で実行する必要があります。 • レプリケーションを無効にしている。バックアップ・ソフトウェアによっては、リストア・

プロセスの過程で実行できます。それ以外の場合は、Technote 1094568 を参照してください。

• スケジュール・エージェントを無効にしている。リストアしたファイルのデータベース・プロパティーで対象のチェック・ボックスを有効にします。

• (オプション) リストアしたファイルの ACL を変更して、要求者のみがアクセス

できるようにしている。

137

138

7 DAOS オブジェクトをリストアします。詳細な手順については、DominoWiki の記

事 「Restoring DAOS objects」 を参照してください。

8 リストアしたデータベースを開いて (あるいはユーザーに開くよう要求して)、目的の文書をリストアします。

9 リストアしたデータベースが不要になった場合は、それらをサーバーから削除します。

リストアの実稼働環境へのマージ 上記の方法でデータベースをリストアすると、現行アプリケーションの実働データに、リストアし

たデータをマージしようと考えるようになります。

しかし、リストアしたデータを実動データにマージする方法は明らかにお勧めできません。これ

は、実動データ上で削除した文書の削除スタブが残るためです。そのために、リストアした文

書を同じデータベース上に複製しても、削除された文書はリストアされません。

これらの削除スタブを削除することはできますが、同じデータベースのレプリカが、例えばユー

ザーのデスクトップにあると、そちらにも削除スタブが存在しています。Technote 1467825 の説明に従って削除スタブを削除しても、他のレプリカにある削除スタブは削除されません。結

果: 複製の履歴をクリアすると、もう一度削除が実行されます。

リストアしたデータによる実動データベースの置換 実動の電子メール・ファイルやアプリケーション・データベースを、リストアしたバージョンの同じ

ファイルで置き換える必要がある場合、実動データベースを削除したうえで、単一データベー

スのリストアの実行 (上記を参照) によりリストアした .nsf ファイルを元のフォルダに同じファイ

ル名で保存することは、当然のことながら可能です。

しかし、以下の条件ではこの方法は機能しません。

• Domino システム・データベースをリストアする場合。これらのファイルは Domino で使

用されており、ドメインの中で整合性を維持するには多くの場合、レプリカ ID を必要とし

ます。技術的な面について詳しくは、Technote 1099635 を参照してください。 • リストア・プロセスの過程でレプリカ ID を変更したが、カスタム・アプリケーションの中に

特定のレプリカ ID を使用することを必要とするものがある場合 (これはアプリケーション

の仕様として望ましくありません)。目的に従ってレプリカ ID を変更する前に、変更による

影響を繰り返し検討してください。以前にこのファイルのレプリカを取得しているユーザー

がいると、そのユーザーは、本来は存在するべきではない変更内容など、以前の古い内

容をサーバーに複製することになります。

実動データベースをリストアに置き換える場合は、そのリストアしたバージョンの別のレプリカを

使用して評価します。こうすることで、古い内容や変更した内容がリストアに複製される状況を

防止できます。

139

リストア・プロセスの 適化 サーバーの可用性とユーザーの満足度を実現できるように 適化したリストア・プロセスは、半

自動化プロセスとして実行する次のようなプロセスです。

• .nsf ファイルのリストア先として Domino Data ディレクトリー外部の場所を指定します。

こうすることで、このファイルが他のサーバーと複製されることはなくなります。 • サーバー側のスケジュール・エージェントは、Domino Data ディレクトリー外部のこのパ

スからデータベースを開き、DB プロパティー「Disable background agents in this file (バックグラウンドエージェント不可)」を設定します。 このようなエージェントのソース・コードが Technote 1380020 にあります。代替策として、

Technote 1201461 の 後にある説明に従って、スケジュール・エージェントをすべて無

効にする方法もあります。 • オンラインでデータベースを元に戻し、同時にレプリカ ID を変更するには、

Domino サーバー・コマンド「Cluster Copy」を使用します。例えば、次のように入力します。 > CL COPY C:\Restore\Filename.nsf RESTORE\filename.nsf このコマンドを実行すると、データベース「C:\Restore\Filename.nsf」の複製ではない

コピーが、Domino Data ディレクトリーの下位にある新しい場所に

「Restore\filename.nsf」として作成されます。 このコマンドとその使用方法について詳しくは、この DominoWiki の記事を参照してください。注: このコマンドを使用するには、NOTES.INI で変数 CLUSTER_ADMIN_ON を 1 に設定する必要があります。

• 必要に応じて ACL を変更します。

推奨事項 一般的に、リストアを実行するときは、次の推奨事項に留意する必要があります。

• リストアに専用のサーバーを使用する場合は、次の Domino Wiki の記事に従って

DAOS 暗号化を無効にすることを検討します。 Deciding on encryption for NLO files

• 緊急リストア手順を定め、定期的にテストします。 • カスタム開発された Domino アプリケーションをリストアする場合は、そのアプリケー

ションの開発者に問い合わせて、アプリケーションのロジックに影響を与えずに個々

の文書をリストアできる方法を具体的に確認しておきます。 • リストアの実行時点が明確にわかるような固有のファイル名の使用を検討します。

例えば、「Restore\2010-11-02\filename2009-12-01.nsf」として、ファイル filename.nsf が、

2009 年 12 月 1 日時点の内容で 2010 年 11 月 2 日にリストアされたことがわかるように

します。 ファイルとフォルダの命名方法は自由ですが、その方法で指定した名前は以降の

クリーンアップ・スクリプトで使用するので、一貫性のある方法を採用するようにします。 • リストアしたファイルのうち、不要になったものは削除します。

一定の基準ですべてのリストアを削除する場合は、小規模なスクリプトを使用して削除操作を自動化できます。例えば、適用後 7 日を経過したリストアが自動的に削除されるようにします。

• クラスター管理のコマンド・ライン・オプションが有効になるように Domino サーバーを構成します。 詳しくは、この Domino Wiki の記事を参照してください。

140

3.11 IBM i で削除された文書をリストアする手順

この記事では、Domino アプリケーションまたは Domino データベースで誤って削除した文書

をリカバリーする方法について説明します。

文書を削除する前にデータベースのコピーをリストアしていることを前提とします。リストアし

たデータベースはサーバー上に置かれ、ユーザーはアプリケーションのリストアしたコピーに

アクセスして文書をコピーし、既存のデータベースにその文書を貼り付けて戻します。

このタイプのリストアを実行する際は、次のような検討事項があります。

• DBIID: DBIID が同じ 2 つのデータベースが 1 つのサーバー上に存在しないようにしま

す。同じ DBIID を持つデータベースが複数存在すると、トランザクション・ログが破損す

る可能性があります。 • 複製: リストアしたデータベースは複製できないようにする必要があります。

そのためには、このデータベースにはアクセスできないようにするか、リストア・プロセスでデータベースのレプリカ ID が必ず変更されるようにします。

• スケジュール・エージェント: 通常はこのサーバー上で実行されるスケジュール・エージェントが、リストアするアプリケーションに存在する場合は、リストア・プロセスの過程でこのエージェントを無効にして、この一時ファイル上でエージェントが実行されないようにします。

実行した保存のタイプに応じてリストアの要件や制限が異なるので、以下の図 53 とそれに続く

説明では、これらの要因をすべて考慮してリストア・プロセスを扱っています。詳しい手順と使用

するコマンドは、この図に続く該当のセクションで取り上げています。

図 53

3.11.1. オペレーティング・システム・タイプのバックアップのリストア手順

1. データベースまたはアプリケーションの前回の保存内容から該当のテープを収集します。 2. データ・ディレクトリー外部のフォルダにデータベースをリストアします。

リストア用のディレクトリーを作成していない場合は、この段階で作成します。以下に例を示しま

す。 CRTDIR '/Restore' この新しいフォルダにデータベースをリストアします。以下に例を示します。 RST DEV('/qsys.lib/tap01.devd') OBJ(('/notes/data/mail/mailfile.nsf' *INCLUDE '/restore/mailfile.nsf')) QNOTES ユーザーのプロファイルがこのディレクトリーとオブジェクトにアクセスできるよう

に権限を設定します。以下に例を示します。 CHGOWN OBJ('/Restore') NEWOWN(QNOTES) SUBTREE(*ALL)

3. (オプション) スケジュール・エージェントがこのデータベース上で実行されないように無効にする

エージェントを使用します。Domino Data ディレクトリー外部のこのパスからデータベースを開

き、DB プロパティー「Disable background agents in this file (バックグラウンド・エージェント

不可)」を設定します。 このようなエージェントのソース・コードが Technote 1380020 にありま

す。代替策として、Technote 1201461 の 後にある説明に従って、スケジュールされたエー

141

142

ジェントを単にすべて無効にする方法もあります。 4. サーバーのデータ・ディレクトリーにリストア・フォルダを作成します。Domino Administrator で「

Files (ファイル)」タブに移動します。右側のパネルで「Folder (フォルダ)」、「New... (新規

(N)...)」の順に選択します。作成したフォルダに Restore などの任意の名前を付けます。 5. CL Copy コマンドを使用して、データ・ディレクトリーの中の Restore フォルダにデータベー

スをコピーします。CL Copy コマンドを使用すると、データベースをサーバーに置いたときに必ず新しい DBIID とレプリカ ID がそのデータベースに割り当てられます。発行する Domino コンソール・コマンドは次のとおりです。 set config CLUSTER_ADMIN_ON=1 これにより、CL Copy コマンドが使用できるようになります。 CL COPY /restore/mailfile.nsf restore/mailfile.nsf

初のエントリーは、完全パスで指定したソース・データベース、2 番目のエントリーは、デー

タ・ディレクトリーを基準とする相対パスで指定したコピー先です。 6. fixup を実行して、リストアしたデータベースと DAOS リンクの整合性を検証します。以下

に例を示します。 load fixup -j restore/mailfile.nsf 注: 8.5.1 FP2、8.5.2、またはそれ以降のバージョンを実行して同じサーバーにリストアする場

合は、fixup による検証を省略してもかまいません (SPR DROO7YXTC3 を参照)。別のサー

バーにリストアする場合は、fixup プロセスが重要になります。これは、データベースの文書に

保存されている .nlo ファイルのヒントを更新するために fixup プロセスが必要であるからです。 7. 必要な文書をコピーして、既存のデータベースに貼り付けます。 .nlo ファイルが見つからない

エラーが発生した場合は、ddm.nsf にポストされたエラー・メッセージでそのファイル名を知る

ことができます。また、listnlo コマンドを使用して、リストアする必要がある .nlo ファイルのリス

トを作成することもできます。以下に例を示します。 tell daosmgr listnlo -o missing_nlo_files.txt MISSING restore/mailfile.nsf

8. 上記の listnlo コマンドの出力を確認して、そのリストにあるファイルをすべてリストアします。こ

の出力には、同じファイルが複数回記述されていることがあります。個々の記述は、見つから

ない添付ファイルを記述しています。リストアの構文は手順 2 と同じです。以下に例を示しま

す。 RST DEV('/qsys.lib/tap01.devd') OBJ(('/notes/DAOS/0001/AAC48E7FC07B6CC71ADD186896DC4F48509F165801A8 702F.nlo'))

9. リストアしたデータベースを削除してクリーンアップします。Domino Administrator の「Files (新規(N)...)」タブで「Delete Database (データベースの削除)」右クリック・メニュー・オプ

ションを使用して、データ・ディレクトリーにあるコピーを削除します。データ・ディレクトリー

外部にあるファイルを削除するには、次のコマンドを使用します。 RMVLNK OBJLNK('/restore/mailfile.nsf') リストア・ディレクトリーは、再使用を考慮して残しておくことができますが、削除してもかまいません。

3.11.2. BRMS のフルバックアップのリストア手順

1. Domino サーバーの前回の保存内容から該当のテープを収集します。 2. サーバーのデータ・ディレクトリーにリストア・フォルダを作成します。Domino Administrator

で「Files (ファイル)」タブに移動します。右側のパネルで「Folder (フォルダ)」、「New... (新規(N)...)」の順に選択します。作成したフォルダに Restore などの任意の名前を付けます。

3. すべてのユーザーとサーバーがこのディレクトリーにアクセスできないようにディレクトリーの ACL を設定します。 これにより、複製ができなくなるので、この新しくリストアされたデータベースには削除処理

が伝搬されなくなります。この機能を有効にするには、NOTES.INI で enable_acl_files=1 を設定する必要があります。これを行うには、Domino コンソール・コマンドの set config enable_acl_files=1 を入力します。続いて、Domino Administrator の「Files (ファイル)」タブに戻って、そのフォルダを右クリックし、「Manage Directory ACL (ディレクトリー ACL

の管理)」を選択します。ここで、図 54 に示すように、管理者のみがそのディレクトリーにア

クセスでき、他のユーザーやサーバーはアクセスできないように選択します。

図 54

4. RSTBRM、WRKLNKBRM、WRKMEDIBRM、または System i Navigator を使用して、

データベースをリストア・フォルダにリストアします。次に、RSTBRM を使用した例を示しま

す。 RSTBRM DEV(*MEDCLS) OBJ(('/server1/data/mail/mailfile.nsf' *INCLUDE '/server1/data/restore/mailfile.nsf'))

5. CL Copy、エージェント、または Antrid などのサード・パーティー製ユーティリティーを

使用して、リストアされたデータベースのレプリカ ID を変更します。 レプリカ ID の変

更方法については、Technote 1094568 を参照してください。次に、 CL Copy を使用

した例を示します。 set config CLUSTER_ADMIN_ON=1 これにより、CL Copy コマンドが使用できるようになります。 CL COPY /restore/mailfile.nsf restore/mailfile.nsf

初のエントリーは、完全パスで指定したソース・データベース、2 番目のエントリーは、

データ・ディレクトリーを基準とする相対パスで指定したコピー先です。 Domino Administrator の「Files (ファイル)」タブにある「Delete Database (データベースの

削除)」右クリック・メニュー・オプションを使用して、元のレプリカ ID を持つデータベースのコ

ピーを削除します。 6. (オプション) リストアされたデータベース内のすべてのスケジュール・エージェントを手動で、

またはエージェントを介して無効にします。データベースを開いて、DB プロパティーの

「Disable background agents in this file (バックグラウンド・エージェント不可)」を設定しま

す。このようなエージェントのソース・コードが Technote 1380020 にあります。代替策とし

て、Technote 1201461 の 後にある説明に従って、スケジュール・エージェントをすべて

無効にする方法もあります。 7. ディレクトリー ACL を削除します。これを行うには、Domino Administrator の「Files (ファ

イル)」タブに戻って、そのフォルダを右クリックし、「Manage Directory ACL (ディレクトリ ACL の管理)」を選択します。ここで、「Who should be able to access this directory (この

ディレクトリーにアクセスできるユーザー)」リストからすべてのエントリーを削除します。 8. fixup を実行して、リストアしたデータベースと DAOS リンクの整合性を検証します。例：

load fixup -j restore/mailfile2.nsf

注: 8.5.1 FP2、8.5.2、またはそれ以降のバージョンを実行して同じサーバーにリストアす

る場合は、fixup による検証を省略してもかまいません (SPR DROO7YXTC3 を参照)。

143

144

別のサーバーにリストアする場合は、fixup プロセスが重要になります。これは、データ

ベースの文書に保存されている .nlo ファイルのヒントを更新するために fixup プロセスが

必要であるからです。

9. 必要な文書をコピーして、既存のデータベースに貼り付けます。.nlo ファイルが見つからな

いというエラーが発生した場合は、ddm.nsf にポストされたエラー・メッセージでそのファイ

ル名を知ることができます。また、listnlo コマンドを使用して、リストアする必要がある .nlo ファイルのリストを作成することもできます。例： tell daosmgr listnlo -o missing_nlo_files.txt MISSING restore/mailfile2.nsf

10. 上記の listnlo コマンドの出力を確認して、そのリストにあるファイルをすべてリストアしま

す。この出力には、同じファイルが複数回記述されていることがあります。個々の記述の

それぞれは、見つからない添付ファイルを記述しています。 リストアの構文は手順 2 と同じです。以下に例を示します。 RST DEV('/qsys.lib/tap01.devd') OBJ(('/notes/DAOS/0001/AAC48E7FC07B6CC71ADD186896DC4F48509F165801 A8702F.nlo'))

11. リストアされたデータベースを削除することにより、クリーンアップします。Domino Administrator の「Files (ファイル)」タブで「Delete Database (データベースの削

除)」右クリック・メニュー・オプションを使用して、データ・ディレクトリーにあるコピー

を削除します。

3.11.3. BRMS の増分バックアップのリストア手順

1. 目的のリストア日より前の 新のフルバックアップおよびそのフルバックアップから Domino サーバーで目的とするリストア日までのすべての増分のテープをサーバーの保存から収集

します。 2. 後の保存から現在までの間のある時点にリカバリーする場合は、ここで増分

(トランザクション・ログのみ) 保存を実行します。 3. サーバーのデータ・ディレクトリーにリストア・フォルダを作成します。Domino

Administrator で、「Files (ファイル)」タブに移動します。右側のパネルで「Folder (フォルダ)」、「New... (新規(N)...)」の順に選択します。作成したフォルダに Restore などの任意の名前を付けます。

4. 以下のコマンドを使用して、リストア中にレプリカ ID を強制的に変更するための必須データ領域 を作成します。 CRTDTAARA DTAARA(QUSRNOTES/QNNIDIFFID) TYPE(*CHAR) LEN(1) このデータ領域は QNOTES が所有する必要があります。以下のコマンドを使用して所

有者を設定します。 CHGOBJOWN QUSRNOTES/QNNIDIFFID *DTAARA NEWOWN(QNOTES)

5. RSTBRM、WRKLNKBRM、WRKMEDIBRM、または System i Navigator を使用して、

データベースをリストア・フォルダにリストアします。次に、RSTBRM を使用した例を示しま

す。 STBRM DEV(*MEDCLS) OBJ(('/server1/data/mail/mailfile.nsf' *INCLUDE '/server1/data/restore/mailfile.nsf'))

6. (オプション) リストアされたデータベース内のすべてのスケジュール・エージェントを手動で、

またはエージェントを介して無効にします。サーバー側のスケジュールされたエージェントが、

このパスからデータベースを開いて、DB プロパティー「Disable background agents in this file (バックグラウンド・エージェント不可)」を設定します。このようなエージェントのソース・

コードが Technote 1380020 にあります。代替策として、Technote 1201461 の 後にある

説明に従って、スケジュールされたエージェントを単にすべて無効にする方法もあります。 7. fixup を実行して、リストアしたデータベースと DAOS リンクの整合性を検証します。例：

load fixup -j restore/mailfile.nsf

145

注: 8.5.1 FP2、8.5.2、またはそれ以降のバージョンを実行して同じサーバーにリストアす

る場合は、fixup による検証を省略してもかまいません (SPR DROO7YXTC3 を参照)。 別のサーバーにリストアする場合は、fixup プロセスが重要になります。これは、データ

ベースの文書に保存されている .nlo ファイルのヒントを更新するために fixup プロセスが

必要であるからです。 8. 必要な文書をコピーして、既存のデータベースに貼り付けます。.nlo ファイルが見つからな

いというエラーが発生した場合は、ddm.nsf にポストされたエラー・メッセージでそのファイ

ル名を知ることができます。また、listnlo コマンドを使用して、リストアする必要がある .nlo ファイルのリストを作成することもできます。

例： tell daosmgr listnlo -o missing_nlo_files.txt MISSING restore/mailfile.nsf

9. 上記の listnlo コマンドの出力を確認して、そのリストにあるファイルをすべてリストアします。

この出力には、同じファイルが複数回記述されていることがあります。個々の記述は、見つ

からない添付ファイルを記述しています。リストアの構文は手順 2 と同じです。以下に例を示

します。RST DEV('/qsys.lib/tap01.devd') OBJ(('/notes/DAOS/0001/AAC48E7FC07B6CC71ADD186896DC4F48509F165801A 8702F.nlo'))

10. リストアしたデータベースを削除してクリーンアップします。Domino Administrator の「Files (ファイル)」タブで「Delete Database (データベースの削除)」右クリック・メニュー・オプション

を使用して、データ・ディレクトリーにあるコピーを削除します。

3.11.4. その他のリソース

• Technote 1092419 • Technote 1420013 • Backup Recovery and Media Services (BRMS for IBMi)

3.12.Domino HTTP サーバー

Domino は単なるメール・サーバーではありません。高性能な Web サーバーとしても機能でき

ます。サーバーで文書が自動的に HTML に変換されるので、作業や設定なしで、Domino サーバー上の任意の文書を Lotus Notes クライアントまたはブラウザーに表示できます。

Domino 管理者は、Web 上で Domino サーバーを効率的に管理できます。 この記事では、Domino Web サーバーの構成に関する情報への参照先を提供します。

3.12.1. 一般的なサーバー 構成

Domino サーバーでの作業に着手する場合や既存の Domino ドメインに対する管理責任

を引き継ぐ場合は、いくつかの基本的な概念を理解しておく必要があります。

• Domino HTTP Server Security • Building Web applications in Domino 6: A tutorial on Web site addressing • Building Web applications in Domino 6: Accessing and protecting the file system • Building Web applications in Domino 6: Web site rules

3.12.2. iNotes

Lotus iNotes は、Web ブラウザーを介して Domino メールにアクセスするための非常に強力

な手段です。 iNotes ユーザーの設定と管理を容易にするために Domino 管理者が利用できる

リソースが数多く存在します。

Lotus iNotes の基礎

• Setting Up a Redirection Application for Lotus iNotes Users • Securing Lotus iNotes

• Technote 1216004 • Lotus iNotes Notes.ini Task Table

• The basics of iNotes customization

• Knowledge Collection: Directory Assistance and Lotus iNotes/Domino Web Access(DWA)

Lotus iNotes の管理

• Lotus iNotes: How to add simple widgets outline entries • Changes to the Lotus iNotes type-ahead feature in 8.5.1

iNotes と Sametime

• Sametime を使用して Lotus iNotes を設定する • Technote 1421160

3.12.3.トラブルシューティング と チューニング

• Tuning Tips for the Domino HTTP Server

• Troubleshooting Lotus Domino hangs and crashes • Lotus Notes/Domino 問題判別ガイド

146

• Technote 1464501

• Technote 1467174

• Technote 1463202

3.12.4.その他の参照先

Web サーバーとしての Domino の使用方法に習熟すると、それをより多くのアプリケーション

や新しいアプリケーションに応用できるようになります。ここでは、そのような応用の着手で役

に立つ参照先を紹介します。

• XPages

• Building Domino Web Applications

3.12.5. ヒント

• インターネット・サイト: IP アドレスとホスト名を使用してください。 これは、バージョン

8.5.1 以前の Sametime ではサポートされません。 • SSO: LTPAToken の名前を変更しないでください。

147

148

3.13.Domino HTTP サーバーのセキュリティ

Lotus Notes クライアントで使用するために Domino データを保護している場合、そのデータは

ブラウザー経由のアクセスからも保護されます。ただし、Domino Web サーバー (http タスク) を有効にした後で、考慮すべきことがいくつかあります。この記事では、Domino を初めて使用

する管理者が Domino サーバーにインターネットへのアクセスを許可する状況を考慮して、基

本的なセキュリティに関する推奨事項と概念について説明します。ここでは、サーバー・アクセ

スの設定を適用する方法や匿名アクセスの制御方法だけでなく、インターネット・パスワードの

ロックアウトや SSL などに関する有益なリソースも紹介します。

3.13.1. サーバー・アクセス

HTTP サーバーでは、データベースのアクセス制御リストだけでなく、読者フィールドや作成者

フィールドなどへの文書アクセスも考慮されます。HTTP 経由で認証する場合、Lotus Notes 認証 (ユーザー ID ファイル) は不要です。シングル・サインオン (SSO) を使用しているユー

ザーがブラウザー経由で Domino 情報にアクセスするには、インターネット・パスワードまたは

トークンを記述した有効なユーザー文書を持っている必要があります。また、サーバーへのア

クセス許可も必要です。デフォルトでは、Domino ディレクトリーで指定されたすべてのユー

ザーが HTTP 経由で Domino サーバーにアクセスできますが、これはサーバー・アクセスの

設定で制御できます。具体的には、図 55 に示すように、サーバー文書の「Security (セキュリ

ティ)」タブで、Domino サーバーにアクセス可能なユーザーを定義できます。

図 55

デフォルトでは、これらの設定は HTTP で考慮されません。これらの設定が HTTP で考慮され

るようにするには、図 56 に示すように、サーバー文書で「Ports (ポート...)」、「Internet Ports… (インターネットポート...)」、「Web」タブの順に選択して、「Enforce server access

settings (サーバーアクセス設定を実施:)」を「Yes (はい)」に設定します。サーバーへの匿名

アクセスを許可するかどうかも選択できます。

149

図 56 3.13.2. ユーザーのセキュリティと認証

ユーザーとそのパスワードを保護するために、Domino は「インターネット・パスワードのロック

アウト」機能を備えています。これにより、ログインの試みが特定の回数失敗したユーザーをシ

ステムから「ロックアウト」できます。インターネット・パスワードのロックアウトについて詳しくは、

「Securing an IBM Lotus Domino Web server: Using the new Internet lockout feature」の

記事を参照してください。

Domino サーバーでは、ユーザー名とパスワードが 2 日間キャッシュされます。そのため、イ

ンターネット・パスワードを変更すると、古いパスワードと新しいパスワードの両方が受け入れ

られる期間が発生します。この状況が組織で受け入れられない場合は、NOTES.INI 設定の

「HTTP_Pwd_Change_Cache_Hours=<# of hours>」(Technote 1084375 参照) を使用し

てキャッシュを制御できます。HTTP タスクを再起動すると、キャッシュが再構築されるため、

HTTP_Pwd_Change_Cache_Hours で指定した時間に関係なく、古いパスワードはサー

150

151

バーで受け入れられなくなります。複数の Web サーバーを使用している場合は、レプリケー

ション・トポロジーにより、新しいパスワードが環境全体に複製されるまで一定の時間がかか

る場合があることも考慮する必要があります。

ディレクトリー (names.nsf) 内で直接定義していないユーザーに Web 上のデータへのアク

セスを許可することが必要になる場合があります。または、全社的に使用するユーザー・

ディレクトリーを既に設定している場合もあります。Domino は、この機能をディレクトリー・

アシスタンス を通して提供しています。ディレクトリー・アシスタンスについて詳しくは、

Technote 1169669 または「3.4 複数のディレクトリー」を参照してください。

Domino は複数の認証タイプを備えています。セッション認証を有効にすることにより、シング

ル・サーバー・レベルとマルチサーバー・レベルの両方でユーザーに提示されるログイン・プロ

ンプトの数を 小化できます。ここで、認証とシングル・サインオン (SSO) に関連するリソース

をいくつか紹介します。

• インターネット/イントラネットクライアントの名前とパスワードによる認証 • Lotus iNotes で領域文書を使用する • Webserver Authentication Troubleshooting • Session-based authentication (single sign-on) • Technote 1265362 • Deploying Windows single sign-on for Web clients (SPNEGO) in an existing Domino

environment • DWA with Sametime integration • Technote 7003063 • Technote 1158269

3.13.3. データベースのセキュリティ

データベースのセキュリティを検討する過程で、多くの Domino 管理者が抱く疑問がいくつか

あります。例えば、匿名ユーザーはデータにアクセスできるのか、このデータに対して SSL アクセスを強制する方法はあるのか、データベースを開いたときに表示するページを制御するに

はどうするか、特定のデータベースがブラウザーに表示されないようにすることはできるのか、

といったものが考えられます。ここでは、これらの疑問に対する回答について説明します。

Domino データに対する匿名アクセス Domino では、HTTP、DIIOP、POP3、IMAP などの Web ベースのプロトコルを使用したアク

セス時のデータベースの保護を強化するために、データベースのアクセス制御リスト (ACL) に新しいセキュリティ・レベルが追加されています。HTTP タスクを実行するサーバー上に配置し

たすべての Domino データベースの ACL に匿名エントリー (anonymous) を設定する必要が

あります。上の図 2 に示すように、サーバー・レベルで匿名アクセスを無効にすることもできま

すが、サーバー上の各データベースの ACL に匿名エントリーを追加することが 良の方法で

す。ACL 内に匿名エントリーが存在しない場合は、「デフォルト」のアクセス権が匿名ユーザー

に付与されます。特に、メール・データベースの場合は、カレンダーに対する読み取りアクセス

権を全員に許可または委任しているユーザーが多いことから、共用カレンダー文書には匿名

ユーザーがアクセスできないようにする必要があるので、匿名エントリー (anonymous) の追加

が重要です。

インターネット経由でデータにアクセスする場合は、 大の権限値を設定することもできます。例

えば、Web からアプリケーションへのアクセスを許可する一方、そのデータの編集を禁止する場

合は、「Maximum Internet name & password (Web ユーザーによるアクセスの上限)」を

「reader (読者)」に設定します。これは、Web ベースのプロトコルを使用して Domino データ

ベースにアクセスする場合は、データベースの ACL に設定されたアクセス権に関係なく、読者

アクセス権のみが付与されることを意味します。メール・ファイルに推奨されている「Maximum

Internet name & password (Web ユーザーによるアクセスの上限)」設定は「editor (編集

者)」です。

Domino Administrator クライアントでは、複数のデータベースの ACL を簡単に一括変更でき

ます。例えば、メール・ディレクトリー内の全ファイルの ACL を変更するには、そのフォルダを右

クリックして、「Access Control (アクセス制御)」、「Manage… (管理...)」の順に選択します。こ

れで「Manage Multiple ACLs (複数 ACL の管理)」ウィンドウが表示されます。このウィンドウ

の上部で、変更されるデータベースの数を確認できます。ここで、「Add… (追加(A)...)」ボタン

を使用して、匿名のアクセス・レベルを「No Access (アクセスなし)」に設定します。この追加を

実行すると、図 57 に示すように、「Apply these changes to all X databases (4 データベース

に変更を反映(Y))」に「anonymous (匿名)」が表示されます。

図 57

152

続いて、図 58 に示すように、「Advanced (詳細)」タブを選択して、「Maximum Internet name & password (Web ユーザーによるアクセスの上限)」設定を「Editor (編集者)」に変更します。

図 58

「OK」をクリックすると、選択したデータベースのうち、管理者が変更権限を持っているデータ

ベースの ACL、またはフルアクセス・アドミニストレーターの権限を使用している場合はすべて

のデータベースの ACL を変更します。変更が完了すると、図 5 に示すように、プロセスが正

常に終了したかどうか、およびエラーが発生したかどうかが報告されます。

図5

既に匿名用のエントリーが設定されているデータベースでもエラーとして報告されることがある

点を認識しておくことが重要です。ログまたはステータス・バーを確認すれば、エラーの原因を特

定できます。図 59 を参照してください。

図 59

153

上記のエラーが発生した場合は、再度、ツールを実行して「変更(M)」を指定すると、このような匿

名エントリーを変更できます。このように、個々のデータベースを確認しなくても、すべてのデータ

ベースを確実に「no access (アクセス なし)」に設定できます。

Domino データに対する SSL アクセス 管理者はサーバー・レベルで SSL アクセスを強制できます。SSL の設定方法について詳しく

は、Technote 1467894 または Redbooks 発行の「Domino Certification Authority and SSL Certificates」を参照してください。ただし、ほとんどの会社に、SSL で保護する必要のない共

用データと保護する必要のある機密データが存在します。両方の要件を満たすためには、

データベース・レベルで SSL 接続を強制する必要があります。サーバー・レベルで SSL を強

制する場合は、図 60 に示すように、「TCP/IP port status (TCP/IP ポートステータス)」を

「Redirect to SSL (SSL へリダイレクト)」に設定するだけで済みます。

図 60

データベース・レベルで SSL を強制するには、データベース・プロパティー「Require SSL connection (SSL 接続の要求)」を設定する必要があります。図 61 に示すように、この設定は

「basics (基本設定)」タブにあります。このプロパティーが有効になっている場合は、ユーザーが SSL を使用せずにデータベースにアクセスしようとすると、セキュリティで保護された接続に自動

的にリダイレクトされます。メール・ファイルにこのフィールドを設定する場合は、iNotes リダイレ

クト・アプリケーションを使用して、ユーザーにセキュリティで保護された接続経由でメール・ファイ

ルを参照させる方法をお勧めします。このようにしないと、メール・ファイルと forms85.nsf 間の

接続タイプが異なることから、メールを正しくロードできない可能性があります。iNotes に正しく

表示するには、Forms85.nsf へのアクセス権が必要です。

154

図 61

SSL について詳しくは、Technote 1218820 を参照してください。

その他のデータベース・プロパティー この他にも、次のような Web 経由のデータベース・アクセスに影響を与えるデータベース・プロ

パティーがあります。

• Use JavaScript when generating pages (ページ生成時に JavaScript を使用) • Web アプリケーションのフォームやビューへのアクセスを防止する • 拡張 HTML の生成を有効にする • アプリケーション起動プロパティを設定する

3.13.4. ファイルシステムのセキュリティ

Domino サーバーのデータ・ディレクトリーに機密データまたは Web アプリケーションの構成要

素が保存されていることがあります。その場合は、Domino サーバーからそれらのデータにアク

セスでき、同様にユーザーもブラウザーを使用してアクセスできます。ファイルが安全であること

を確認するには、「Building Web applications in Domino 6: Accessing and protecting the file system」という記事を参照してください。この記事内容は Domino 8.5x の環境でも同様です。

155

3.14.Lotus iNotes ユーザー向けのリダイレクト・アプリケー

ションの設定

現在 Lotus iNotes を使用しているか、使用することを検討しているのであれば、リダイレクト・

アプリケーションの問題がおそらく重要になります。Domino には、ユーザーがユーザー ID とパスワードを入力してメールにルーティングされるように、リダイレクト・アプリケーションが用意

されています。この記事では、iNotes リダイレクト・データベースを作成し、Web サイトのデ

フォルトのホーム・ページを作成する際に必要な手順について説明します。

このアプリケーションを作成し実装するプロセスを理解するうえで役に立つように、簡単なケー

ス・スタディーと架空のソフトウェア会社 A 社を取り上げます。A 社の経営陣は、すべての社内

ユーザーに iNotes を展開することを決定しました。A 社が目指していることは、ユーザーが mail.companya.com の URL を入力し、次にユーザー ID とパスワードを入力するとそれぞれ

のメールに直接アクセスできるようにすることです。この要求を実現するために Domino 管理

者が実行する手順を以下に示します。

3.14.1. iNotes リダイレクト・アプリケーションの作成

初の手順は iNotes リダイレクト・アプリケーションの作成です。これは、Lotus Notes また

は Domino Administrator クライアントから行うことができます (「File (ファイル)」、

「Application (アプリケーション)」、「New (新規)」の順に選択)。 リダイレクト・アプリケーショ

ンを作成するときには、 初にタイトルとファイル名を入力します。次に図 62 に示すように IBM Lotus iNotes Redirect テンプレートに基づいてアプリケーションを作成します。

図 62

156

3.14.2. iNotes リダイレクト・アプリケーションの構成

リダイレクト・アプリケーションを作成するとセットアップ・ボタンが表示されます。これをクリック

して構成を開始できます。クリックすると、図 63 に示す 4 つのオプションが表示されます。

図 63

「Server Settings (サーバー設定)」

構成を開始するには、「Server Settings (サーバー設定)」をクリックします。 初の選択

項目は、「Redirection Type (リダイレクト・タイプ)」です。ここで選択する値は、環境によっ

て異なります。以下の表を使用して、リダイレクト・タイプとそれに関連する設定に適切な

値を選択してください。A 社の例では、companya.com の TCP/IP ドメインでリダイレクト・

タイプ Mail Server を使用しています。A 社はメール・ファイル向けにプロキシー・サー

バーや特定のフォルダを使用しないので、これらの設定は空白のままになります。

シナリオ 設定

複数のサーバーが iNotes を実行しており、

ホーム・メール・サーバーに保管されている

メール・ファイルにユーザーをリダイレクトする

必要があります。

• リダイレクト・タイプ Mail Server • メール・サーバーの正しい TCP/IP ドメイン

を指定する必要があります。例えば、companya.com とします。

複数のサーバーが iNotes を実行しています

が、すべてのメール・ファイルは DMZ に設置さ

れている 1 つのサーバーに複製されます。 この DMZ サーバーの iNotes と呼ばれるフォル

ダにあるメール・ファイルのコピーに、すべての

ユーザーをリダイレクトする必要があります。

• リダイレクト・タイプ Fixed • 使用するサーバー名を DMZ サーバーのホ

スト名に設定する必要があります。例えば、dmz.companya.com とします。

• 強制パスは iNotes に設定する必要がありま

す。

複数のメール・サーバーおよびメール・ファイル

のレプリカ・コピーによる環境。ユーザーが現在

接続しているサーバー上に保管されているメー

ル・ファイルのレプリカ・コピーに、そのユーザー

をリダイレクトする必要があります。

• リダイレクト・タイプ Dynamic

シングル・メール・サーバー環境。このサーバー上のメール・ファイルにユーザーをリダイレクトする必要があります。

• この環境では、どのリダイレクト・タイプも使用できます。

リダイレクト・データベースがアプリケーション・

サーバー上に存在しますが、適切なメール・

サーバーにユーザーをリダイレクトする必要が

あります。

• リダイレクト・タイプ Mail Server • メール・サーバーの正しいドメインを指定する

必要があります。例えば、companya.com とします。

次に決定すべき事項は SSL です。A 社は、サイン・イン時に SSL を強制しますが、メールにア

クセスするときには SSL 接続を使用しないことにしています。 このため、「Do you wish to force SSL for the entire session? (セッション全体に SSL を適用し

ますか?)」を「No (いいえ)」に設定しましたが、「Do you wish to force SSL only on authentication (認証にのみ SSL を適用しますか?)」は「Yes (はい)」に設定しています。ここに

157

示す例では、デフォルトの SSL ポート 443 を使用し、その設定は変更していません。図 64 に A 社が選択したすべてのサーバー設定を示します。認証および iNotes アクセスで SSL が使用さ

れていることを確認する必要がある場合は、「Do you wish to force SSL for the entire session (セッション全体に SSL を適用しますか?)」パラメーターを「Yes (はい)」に変更します。

図 64

158

「UI Setup (UI セットアップ)」

構成する次のグループの設定は、「UI Setup (UI セットアップ)」です。ほとんどの UI 設定は、

説明が不要なくらいわかりやすくなっています。図 65 に示す例では、A 社は標準リダイレクト・

ページに会社のロゴを表示するようにしています。ユーザーがログイン・オプションを変更でき

るようにリダイレクト画面が 4 秒間表示されます。ここでは「Enable Personal Options (パーソ

ナルオプションを有効にしますか?)」と「Enable Login Options (ログインオプションを有効にし

ますか?)」の設定例を示します。

図 65

159

ブラウザーを使用してリダイレクト・データベースにアクセスすると、図 66 に示すような画面が 4 秒間表示されます。A 社は Lotus iNotes ロゴではなく会社のロゴを表示することにしている

ので、この例では会社のロゴが表示されます。

図 66

「Enable Personal Options (パーソナルオプションを有効にしますか?)」設定で「Yes (はい)」を選

択した場合は、図 5 のように「Personal Options (パーソナルオプション)」リンクが表示されます。

ユーザーがこのオプションを選択すると、図 6 に示す画面が表示されます。ユーザーがログイン・

オプションを変更できるようにするには、「Enable Login Options (ログインオプションを有効にしま

すか?)」を「Yes (はい)」に設定し、「Enable Personal Options (パーソナルオプションを有効にしま

すか?)」を「Yes (はい)」に設定する必要があります。「Personal Options(パーソナルオプション)」画面には、「Alternative Mail File Display Name (代替メールファイル表示名)」と「Default View (デフォルトビュー)」の 2 つのパラメーターが表示されます。代替のメール・ファイル表示名を使用し

て別のユーザー名を入力できます。図 67 では User One がログインし、パーソナル・オプションを

変更することを選択しています。User One が User Two のメールにアクセスする場合は、User One が「Alternative Mail File Display Name (代替メールファイル表示名)」フィールドに「User Two」と入力すると、リダイレクトが完了した後で User One のメール・ファイルではなく User Two のメール・ファイルが表示されます。「Default View (デフォルトビュー)」パラメーターを使用して、別

の iNotes 形式またはホーム・ページに切り替えることができます。ここでは、User One は「Full mode (フルモード)」を使用することを選択しています。ここで選択したオプションは記憶され、ユー

ザーが次回にログインするときに使用されます。

160

図 67

「Ultra-light/Mobile Settings (ウルトラライト/モバイル設定)」 iNotes リダイレト・データベースの「Ultra-light/Mobile Settings (ウルトラライト/モバイル設定)」構

成は非常に簡単です。ウルトラライト・モードをユーザーが選択できるようにするかどうか、およびウ

ルトラライト・モード・インターフェースに自動的にリダイレクトするモバイル・デバイスを指定できま

す。A 社では iNotes のウルトラライトを展開しているので、図 68 に示すようにこの設定を有効にし

ます。

図 68

「Application Setup (アプリケーション セットアップ)」 ここまでの設定を正しく選択した後、 後の手順として、iNotes リダイレクト・アプリケーションの

「Application Setup (アプリケーション セットアップ)」オプションにアクセスします。 「Click to Auto Set ACL Settings (ACL 設定の自動設定ボタン)」をクリックして、リダイレクト・アプリケーションの ACL を正しく構成します (図 69 を参照)。

図 69 ACL を適切に構成すると、図 70 に示すように変更内容を確認するメッセージが表示されま

す。

161

図 70

これで iNotes リダイレクト・アプリケーションを使用できるようになりました。

3.14.3. ホーム・ページとしての iNotes リダイレクト・アプリケーションの構成

構成した iNotes リダイレクト・アプリケーションをメール・サーバーのデフォルトのホーム・ページにする

ことができます。そのためには、サーバーのサーバー文書またはインターネット・サイト文書 (環境でイ

ンターネット・サイトを使用する場合) のデフォルトのホーム・ページ設定を変更する必要があります。

サーバー文書のデフォルトのホーム・ページの設定 インターネット・サイトを使用しない場合は、サーバー文書でデフォルトのホーム・ページを設定

する必要があります。Domino Administrator クライアントのサーバー文書にアクセスするには、

「Configuration (設定)」タブに移動します。 このタブから「Server (サーバー)」、「All Server Documents (すべてのサーバー文書)」の順に選択します。次に適切なサーバーの文書を開く

ことができます。これを行うには、「Internet Protocols... (インターネットプロトコル...)」、「HTTP (HTP)」タブの順にアクセスします。 ホーム URL を /<リダイレクト・アプリケーションの名前>?Open に設定します。A 社の場合、この値は iNotesredirect.nsf?Open となります。

図 71

インターネット・サイト文書におけるデフォルトのホーム・ページの設定

インターネット・サイト文書を使用する場合は、各サイトは独自のホーム URL を持ちます。この

ため、ホーム URL はインターネット・サイト文書内に定義する必要があります。Domino Administrator クライアントのインターネット・サイト文書にアクセスするには、「Configuration (設定)」タブに移動します。このタブから「Web (Web)」、「Internet Sites (インターネット・サイ

ト)」の順に選択します。 サイト文書内で、「Configuration (設定)」タブにアクセスして、ホーム URL を定義します。例えば、ホーム URL を /iNotesRedirect.nsf?Open に設定します。

162

図 72

iNotes リダイレクト・アプリケーションを実装して、サーバーのデフォルトのホーム・ページに設

定するのは、このように非常に簡単です。

163

3.15.Lotus iNotes の保護

iNotes に固有のセキュリティ事項がいくつかあります。例えば、Notes ID ファイル、ブラウザー

のキャッシュ管理、オフライン・データベースの暗号化、暗号化メール (S/MIME) です。この記

事では、これらのトピックを取り上げ、その重要な点について説明します。

3.15.1. iNotes と Notes の ID ファイル

Lotus iNotes を使用する場合、認証のために ID ファイルは必要ありません。ただし、iNotes へのオフライン・アクセス、メッセージの再呼び出し、暗号化されたメール (S/MIME) の送受信など、

ID ファイルを必要とする機能がいくつか存在します。ID ファイルは、ユーザー登録時にユーザー

のメール・ファイルに自動的に保存できます。バージョン 8.5.1 から、Domino の ID ボールト機

能を使用して、ID ファイルに保存したパスワードを同期化できるようになりました。ID ファイルが

メール・ファイルに保存されているかどうかは、図 73 に示すように、iNotes 内のセキュリティ・プ

リファレンスにアクセスすることで簡単に確認できます。

図 73

パスワードの同期化とカスタム・パスワード・ポリシーの適用について詳しくは、次の記事を参

照してください。

• Technote 1229478 • How to implement a Custom Password Policy for iNotes Users

3.15.2. Active X コントロール

ActiveX コントロールによって、Internet Explorer ブラウザーを介してインターネット上で動作

する分散アプリケーションを作成することができます。Domino 8.5.x では、ActiveX コントロー

ルを介して実装する iNotes 機能がいくつか存在します。例えば、添付ファイルのドラッグ・アン

ド・ドロップ機能、ファイルのアップロード/ダウンロード時の複数ファイルの選択機能、ブラウ

ザー・キャッシュのクリーンアップ機能があります。

ActiveX コントロールをインストールするには、使用するワークステーションに対する管理者権

限またはパワー・ユーザー権限が必要です。ブラウザーへの ActiveX コントロールのインス

トールを許可する必要もあります。管理者は、図 74 に示すようにサーバー設定文書内で、ま

たは特定のユーザーに対してはメール・ポリシーで、これらのコントロールをサーバー・レベル

164

で有効または無効にすることで、その使用を制御できます。

図 74 3.15.3. ブラウザー・キャッシュ管理

ブラウザー・キャッシュ管理とは、ユーザーが iNotes にアクセスしていたときに PC に保存さ

れた一時ファイルのうち、iNotes を終了した後でクリーンアップするものを定義することです。

詳しくは、次の記事を参照してください。

Technote 1239768

ブラウザー・キャッシュ管理のよくある質問:

質問: ブラウザー・キャッシュ管理機能を有効にせずに iNotes からログアウトすると、どうなり

ますか。 回答: ブラウザー・キャッシュ管理機能が有効かどうかに関係なく、ログアウトをクリックすると、ブラウザー・キャッシュはクリアされます。ブラウザー・キャッシュ管理の利点は、ログアウトをクリックしなくてもブラウザー・キャッシュがクリアされることです。例えば、ブラウザーを閉じるだけで、ブラウザー・キャッシュはクリアされます。

質問: ブラウザー・キャッシュ管理の自動インストール後にブラウザーを強制的に再起動す

る方法はありますか。 回答: iNotes は Web ベースのアプリケーションなので、ブラウザーの制約に準拠する必要が

165

あります。 iNotes によってブラウザーを強制的に閉じることはできません。

質問: ブラウザー・ウィンドウを閉じたときに実行される履歴のクリアとはどういう意味ですか。

回答: Web ブラウザーで使用可能な一時ファイルのクリアという意味です。 一時ファイルが該

当するディレクトリーから削除されます。キャッシュ削除レベルを設定することで、すべての

キャッシュ・エントリーの削除や、ユーザーのメール・ファイルに関連するキャッシュ・エントリー

のみの削除などを指定できます。iNotes は Web アプリケーションなので、実行可能なことと不

可能なことに対する制約があります。ブラウザー・キャッシュをクリアすると、これらのファイル

がディレクトリーから削除されます。これは、手作業で Windows エクスプローラーからディレク

トリを参照してファイルを削除する操作と同じです。 iNotes のパフォーマンス向上を図るために、ハード・ドライブに保存されるのは設計データのみ

であり、添付ファイルを除くユーザーのデータは保存されないことに注意が重要です。

質問: 添付ファイルを読み取るだけで添付を解除すると、どのように処理されますか。ハー

ド・ドライブからどのように削除されますか。 回答: 同じ手順が適用されます。ファイルの場所を参照して手動で削除する場合と同じように、

ファイルは削除されます。

3.15.4. オフライン・データベースの暗号化

iNotes の非常に優れた点の 1 つは、インターネットでサーバーにアクセス可能であれば、どこ

からでも簡単にメールにアクセスできることです。Lotus iNotes では、ユーザーが自分のメール

にオフライン接続することもできます (DOLS が必要)。ユーザーがオフライン・サブスクリプショ

ンを構成すると、メール・ファイルのローカル・コピーが作成されます。共有されているコンピュー

ターを使用できる環境では、このことは懸念材料になる可能性があります。この懸念を 小限

にする 1 つの方法は、ユーザーがオフラインにするときにメール・ファイルを強制的に暗号化す

ることです。これはサーバーの構成文書で簡単に設定できます。図 75 に示した例では、

Domino 管理者が中程度の暗号化の使用を指定しており、ユーザーがこの設定を変更するこ

とはできません。

図 75

166

3.15.5. S/MIME

Lotus iNotes は、セキュアな MIME (S/MIME) を使用した暗号化メッセージの送受信を完全

にサポートしています。この機能には 2 つの要件があります。まず、ユーザーはセキュア

な接続 (SSL) (Technote 1268695) を経由してメールにアクセスする必要があります。2 番目に、Lotus Notes の ID ファイルをメール・ファイル内に保存する必要があります

。iNotes でセキュアなメッセージを送信する方法は、非常に単純です。上記の要件を満たして

いれば、メッセージを送信する前に、ユーザーが「Encrypt (暗号化)」オプションを選択するだ

けです。

図 76

セキュアなメッセージの受信者の ID ファイルがその受信者のメール・ファイルに保存されて

いない場合、図 77 に示すような警告メッセージが表示されます。

図 77

ここに示すように、このエラー・メッセージでは、メッセージ本文が暗号化されていることが通知さ

れます。 この点を理解しておくことは管理者とユーザーにとって非常に重要です。メッセージの件名は暗

号化されないので、機密情報はすべてメッセージ本文に記述する必要があります。

167

168

第4 章 環境のチューニング

4.1. 正常性確認.

正常性確認の目的は、Domino サーバー構成と必要な基本サービス (ハードウェア・リソース、

ディスク、ネットワークなど) を適切な範囲で詳しく分析することです。詳細な正常性確認は、ベ

スト・プラクティスを適用できる部分の特定を目的としています。これは、Domino によって提供

される情報の整合性、可用性、機密性を脅かす脆弱性を明らかにすることにもなります。

この記事では、管理者が正常性確認の実行を開始するために役立つチェックリストを提示

します。さらに、いくつか特定のポイントについて、深く掘り下げていきます。

正常性確認は次の 3 つの重要な要素で構成されます。 1. 入力 (ハードウェア構成およびソフトウェア構成のレビューによって収集) 2. 分析 (使用する Domino 環境のコンテキストに沿って、入力内容をレビュー) 3. 推奨 (分析フェーズから特定されたアクション)

4.1.1. 正常性確認の概略チェックリスト

以下の点をすべて実行すると、総合的な正常性確認を実行したことになります。

1. サーバー・ハードウェアの検査 2. サーバー構成の検査 3. Domino メール・ルーティングの検査 4. SMTP メール・ルーティングの検査 5. Domino レプリケーションの検査 6. ディレクトリ・サービスの検査 7. Domino クラスタリングの検査 8. コア・データベース (names、admin4、events4) の Domino セキュリティの検査 9. Domino サーバー・トポロジーの検査 10. NOTES.INI ファイルの検査 11. サーバー・ログの検査 12. サーバー統計の検査 13. サーバー文書の検査 14. 接続文書の検査 15. サーバー構成文書の検査 16. プログラム文書の検査 17. アクティブなサーバー・タスクの検査 18. 災害復旧手順に関するレポート 19. バックアップ手順に関するレポート 20. データベース数とサイズに関するレポート 21. データベース・アクティビティーに関するレポート 22. エージェントとランタイムに関するレポート

169

4.1.2. 正常性確認の実行

正常性確認は、単純に環境を確認するだけのものではありません。適切な正常性確認を行う

には、検出内容を文書化してチームや上層部にレビューを依頼する必要があります。これは使

用する環境の正常性を追跡することにもなります。本書の残りの部分全体を通して、確認の実

行手順だけでなく、レポートに記述するデータの内容についても説明します。

環境の概要図 正常性確認の何らかのコンテキストを示すためには、アーキテクチャーの概要図を扱うことが

有効です。この概要図は、Domino 環境の主要な構成要素を読み手が理解するうえで効果的

です。

この概要図では、次のような情報を簡潔に説明します。

• Domino サーバーの数と物理的な場所 • IP アドレス/ホスト名 • Domino クラスター • 環境にアクセスするクライアント・タイプ • ネットワーク環境 • (インターネットからの) 外部アクセス • メール・ルーティング・トポロジー • レプリケーション・トポロジー

現在のクライアント環境 このセクションでは、環境によって提供されるユーザー基盤の状況を把握します。ユーザーの

およその数とアクセス方法 (Notes クライアント、ブラウザー、モバイル・デバイスなど) につい

て記述します。使用されているクライアント・タイプが不明な場合、Domino Directory 内の個人

文書には、サーバーへのアクセスに使用されている Notes クライアント・バージョンのリストを

記述することが普通です。 この情報は、「Administration (管理)」タブに保存されます。ライセンス・トラッキング機能を有効

にすることで、この情報を簡単に確認することもできます。

Domino サーバー・ビルド 正常性確認のこのセクションは、インベントリーとよく似ています。環境内の Domino サーバー

が、その役割、ホスト・オペレーティング・システム、バージョン (ホット・フィックスを含む) と共に

一覧表示されます。

複数のバージョンが混在する環境の場合は、(特にメンバー間で) 注意が必要です。ベスト・

プラクティスとしては、クラスター・メンバーをすべて同じ Domino バージョン (8.5.2 など) に揃えることをお勧めします。

ハードウェア

正常性確認では、現在使用しているハードウェアの概要を扱う必要があります。十分な

時間をかけて主要なシステム・リソースをモニターします。システムのモニターには数週

間から数カ月かけるようにしてください。 こうすることで不規則な変化をすべて平均化できます。リソース使用量に関するレポートにより、次の 3 つの利点が得られます。

• 定常状態のリソース使用量のベースラインを確定する。

• サービスに悪影響を及ぼす可能性のあるリソース使用量のスパイクのパターンの特定に役立つ。

• 追加ハードウェアまたはサーバーの移行が必要となる時期を計画するのに役立つ。

このような運用ツールは便利です。 低でも、次の属性を測定する必要があります。

• CPU 使用率の合計 • メモリー (RAM) 使用率の合計 • ディスク・キューの平均長さ • ネットワーク使用率

使用されるツールおよび正確な統計は、プラットフォームにより多少異なります。以下に、

Windows Performance Monitor (Perfmon.exe) を使用した例を示します。

図 78 は、上記のリソースの観点から健全なサーバーを示しています。CPU 使用率は、一般的に低く、スパイクがビジーな期間の 50% 程度を超えることはありません。 モニター期間を通して、多くの空きメモリーがあります。ディスク・キューの平均長さは、時折発生

するスパイクを除き、通常は 2 未満です。

図 78:健全なサーバー

170

図 79 は、CPU の 大容量に到達し、使用可能なメモリーのほとんどを使用している (大 70%) サーバーを示します。

図 79:ピークが CPU の 大容量に到達

図 80 は、ディスク・キューの平均値が非常に高く、ピークが 80 に達しているサーバーを示しま

す。

図 80:非常に高い値のディスク・キューの平均長さ

171

172

ディスク・サブシステム

ディスク・サブシステムは、Domino サーバー構成の主要なコンポーネントです。ファイル

の場所、RAID のレベル、空きスペースなど、さまざまな要素を見落とさないようにする必

要があります。

ディスク・レイアウト

ベスト・プラクティスとしては、次のコンポーネントに対して、個別のディスク・ボリューム (個別

スピンドル) を用意することをお勧めします。

1. オペレーティング・システム 2. Domino バイナリー (プログラム・コード) 3. Domino データ・ディレクトリー 4. DAOS リポジトリー 5. トランザクション・ログ・ドライブ 6. ビュー再構築ドライブ 7. スワップ・ドライブ

注: IBM i では、オペレーティング・システムは、単一レベルのストレージ機能により、ドライブ

を自動で管理します。オペレーティング・システムとすべての Domino コンポーネントは、副次

的なパフォーマンスの悪影響を受けることなく、プライマリー補助ストレージ・プール (ASP) に置くことができます。プライマリー ASP の使用は、このプラットフォームに対する、デフォルト

の推奨構成です。

空きスペース

ファイルのフラグメント化の量を削減するには、大まかに、少なくとも 20% の空きディスク・ス

ペースを維持します。通常、システムのディスク・スペースが不足すると、パフォーマンスは低下

します。使用可能なスペースがなくなると、サーバー・クラッシュまたはパニックに陥る可能性が

あります。

RAID レベル

OS/ソフトウェア・レベルでの RAID はお勧めしません。実稼働環境の Domino サーバーでは、

ハードウェアベースの RAID コントローラーを使用する必要があります。各 RAID レベルから

得られるディスク IO パフォーマンス、冗長性、および使用可能なディスク・スペースの間には、

常に到達すべきバランスがあります。図 4 に、各 Domino コンポーネントに 適な RAID レベ

ルを示します。

注: IBM i/5 では、すべてのボリュームに対し、RAID レベル 5 または 6 が適しています。

Domino コンポーネント Windows/Linux/AIX

オペレーティング・システム RAID 1

Domino バイナリー RAID 1

Domino データ RAID 10 または RAID 5

DAOS リポジトリー RAID 5

トランザクション・ログ RAID 1 または RAID 10

ビュー再構築一時ファイル RAID 1

O/S スワップ・ドライブ RAID 1

図4:RAID レベル

さらに、トランザクション・ログ・ドライブ専用の個別の RAID コントローラーを使用する

ことがベスト・プラクティスとなります。

ビュー再構築ドライブ

ビュー索引の再構築の実行に使用される一時ファイルの格納に、RAID 1 アレイを割り当てま

す。これにより、特に多くのユーザーが 初に受信ボックスを開くビジーな時間におけるパ

フォーマンスを向上させることができます。Technote 1090462 には、詳細な手順が記載されて

います。 再構築ドライブは、2 つの専用のソリッド・ステート・ディスク・ドライブまたは物理ディス

ク・ドライブで構成された専用の RAID 1 アレイを使用するよう構成することをお勧めします。

注: IBM i/5 の場合、ビュー再構築ディレクトリーはプライマリー ASP にある可能性がありま

すが、パフォーマンスを向上させるため、サーバーのデータ・ディレクトリーの外側に配置する

こともできます。

トランザクション・ロギング

正常性確認の際、トランザクション・ロギング構成の確認を行う必要があります。ほとんどの場

合、トランザクション・ロギングはその恩恵を受けられるよう、支障なく有効にすることができま

す。トランザクション・ロギングのベスト・プラクティスの優れたガイドが、以下に用意されていま

す。Technote 7009309.

トランザクション・ロギング構成は、いくつかの要因により異なります。この要因には、下記が含

まれます。

• 使用可能なサーバー・ディスク・レイアウト • 使用可能なディスク・スペース • Domino サーバーの使用状況 (Sametime サーバーかメール・サーバーかなど) • バックアップ戦略のタイプおよびバックアップ・ツールの可用性

このトピックについては、この wiki の『トランザクション・ロギング』セクションで詳細に説明します。

サーバーの NOTES.INI

NOTES.INI の正常性を判断するには、以下について検討します。

• サーバーの NOTES.INI 構成ファイルには、デフォルトの動作を変更し、サーバーの調整

に使用できる設定が含まれます。 NOTES.INI を変更する際には、注意が必要です。必

ずバックアップを取り、変更管理プロセス内のすべての変更を文書化します。

• NOTES.INI ファイルを直接変更することは、ミスにつながる可能性があります。 過失によ

る変更または誤った変更により、Domino または Notes が予想外に実行される可能性が

あります。したがって、サーバー構成文書の NOTES.INI パラメーターを設定するか、set config コンソール・コマンドを使用する方が安全です。

• テキスト比較ツールは、NOTES.INI ファイルの違いを強調表示するのに便利です。サー

バーの役割 (メール、ハブ、アプリケーション・サーバーなど) を越え、特にクラスター・メン

バー間にわたる整合性を探します。

• IBM Lotus Notes and Domino wiki は、現在の NOTES.INI パラメーターとその使用方法

173

について理解するのに適しています。

• NOTES.INI ファイルは、以前の Domino リリースからのアップグレードを経たサーバーの、

古くなったパラメーターを含んでいる傾向があります。NOTES.INI パラメーターは、その機

能が (サーバー構成文書、またはサーバー文書自体の) UI 設定に取って代わられ、一般的

に古くなっています。

一例として MAILCLUSTERFAILOVER=1 が挙げられます。このパラメーターは、Domino R5 ではサーバー構成文書の「Router/SMTP (ルーター/SMTP)」タブの設定に取って代わら

れました。NOTES.INI パラメーターは、構成文書の設定を上書きしませんが、その設定が実

際とは異なる場合に、管理者にそれについて考えさせることができます。

• Domino 7 で廃止されている NOTES.INI パラメーターについては、Technote 1207338 を

参照してください。 • Domino 8 で廃止されている NOTES.INI パラメーターについては、Technote 1327806 を

参照してください。

冗長なタスク ServerTasks パラメーターは、Domino サーバーの起動時に自動的に開始されるタスクを指定

します。これらのタスクはメモリーおよび CPU を使用するため、サーバーの役割に必要なタス

クのみが含まれるようにすることが重要です。冗長なタスクの例としては、Sametime コミュニ

ティー・サーバーで実行される Rooms & Resource Manager (RNRMGR) や、管理サーバー

で実行される SMTP が挙げられます。正常性確認の一環として、実行されているすべてのタス

クが、現在の環境でも必要であることを確認する必要があります。

Domino Configuration Tuner 簡単に言うと、DCT はサーバー構成を調べ、これらを広範なベスト・プラクティス・ルールの

セットと比較します。これにより、管理者は迅速かつ容易に Domino ドメイン全体を分析し、問

題を引き起こすと認識されているパラメーターを特定することができます。

DCT については、『4.2 Document Configuration Tuner (DCT)』 でさらに深く説明します。

正常性確認の一環として、DCT ツールを使用し、その結果と推奨アクションを文書化する必

要があります。

データベース・サイズ 電子メールの利便性と汎用性により、これは増大する一方のファイル・キャビネット (または屋根裏部屋) のようになっています。大きなメール・ファイル、特に多数の文書を含

むものは、いくつかの点で悪影響を及ぼします。以下に例を示します。

• 特に複数のサーバーに複製される場合、急速にサーバーのディスク・スペースを消

費します。 • データベースのビュー索引は、より多くのディスク・スペースおよびより多くの CPU 時

間を消費し、更新により多くの時間がかかります。 • 受信ボックス (およびその他のフォルダ) は、更新およびオープンにより多くの時間を必要と

します。 • 全文索引は増大し、維持するためにより多くのサーバー・リソースを必要とします。 • バックアップやリストアが完了するまでにより多くの時間がかかります。 • 古い文書を保持することは、文書リテンション・ポリシーに違反する場合があります。 • 大量の大きなファイルを同時に開くと、特に Windows では、サーバー・リソース

を使い果たす可能性があります。

174

大きな Domino メール・ファイルについては、「How Large Databases Uniquely Affect IBM Lotus Domino Server Performance」というペーパーを参照してください。

Domino 管理者は、ユーザーのメール・ファイルのサイズを制御するためのさまざまなオプショ

ンを使用することができます。まず、データベース・サイズの制限値があり、その制限値を超え

るメール・ファイルからのメール配信を控える機能があります。さらに、ルーターが配信できる

個々のメッセージのサイズを制限することができます。他の場所で説明されているその他の高

度なデータベース・プロパティー (圧縮など) も、データベース全体のサイズの削減に効果的で

す。

これらのトピックについては、『2.2 ユーザーの受信ボックスの管理』で詳細に説明しています。

高のパフォーマンスを得るには、受信ボックスの文書をできるだけ少なく保ちます。大まか

に、文書数が 1000 を超えるのは過剰です。受信ボックスの保守機能を有効にして定期的に

実行すると、ユーザーの受信ボックスから別のフォルダに文書を移動することができます。

ポートおよびネットワーク構成

正常性確認の一環として、ご使用のサーバーで定義されているポートを含む、ネットワーク構

成を確認する必要があります。以下に、正常性確認の一環として検討および文書化を行う際

のヒントをリストします。

• Domino サーバーのポート構成は、NOTES.INI のパラメーターで定義されます。Ports パ

ラメーターには、サーバーで定義されている有効なすべてのポートを含める必要がありま

す。 初にリストされているポートが、クラスター通信で使用されるポートとなるため、リス

トの順序も重要です。

• ポートの圧縮により、宛先に送信される前にネットワーク・トラフィックを圧縮することがで

きます。これは、別の Domino サーバーや Lotus Notes クライアントの場合もあります。

管理クライアント (「Server (サーバー)」 -> 「Status (ステータス)」タブの「Tools (ツー

ル)」 -> 「Ports (ポート)」 -> 「Setup (設定)」) を使用して、ポートの圧縮を有効または無

効にします。ご使用のネットワーク・スイッチおよびルーターでトラフィックが既に自動的に

圧縮されている場合、トラフィックの圧縮および解凍にかかわる CPU オーバーヘッドがあ

るため、ポートの圧縮を有効化しないでください。

• ベスト・プラクティスでは、Domino クラスタリングに対して専用の NIC および専用の高速

ネットワークを用意して、スループットを 高速にすることが示されています。 クラスターの

複製に専用ネットワークを使用すると、クラスターのプローブと複製のネットワーク・トラフィッ

クがユーザー・アクセス LAN から軽減され、クライアントのクラスター・サーバーとの残りの

通信帯域幅がより多くなります。これにより、ネットワーク障害の場合にある程度の冗長性

も備わります。詳細については、Technote 1154031 を参照してください。

図 6 は、Server_Cluster_Default_Port パラメーター・セットを持つ、クラスター・メンバーの

サーバー NOTES.INI からの抜粋です。 この構成では、クラスターの複製 (clrepl) のタスク

でのみこの定義済みポートが使用されます。 このポートが故障した場合、clrepl タスクは他

のポートにフェイルオーバーしません。

Ports=TCPIP_CLU,TCPIP TCPIP=TCP, 0, 15, 0,,32 SERVER_CLUSTER_DEFAULT_PORT=TCPIP_CLU TCPIP_CLU_TCPIPADDRESS=0,10.172.99.134:1352 TCPIP_TCPIPADDRESS=0,10.172.99.100:1352

図 6: NOTES.INI からのクラスター構成の抜粋

175

176

• Server_Cluster_Auxiliary_Ports NOTES.INI パラメーターは、

Server_Cluster_Default_Port= パラメーターの使用時でも、他の使用可能なポート

に対するクラスター複製のフェイルオーバーを許可します。

Server_Cluster_Auxiliary_Ports NOTES.INI パラメーターの使用については、

Technote 1259288 に記載されています。 この場合、次のようにパラメーターを追加

します。

Server_Cluster_Auxiliary_Ports=TCPIP

• すべてのサーバーで、潜在的なネットワーク・パフォーマンスの問題を回避するため、

サーバーが取り付けられたスイッチとして同じ回線速度と duplex オプションを使用するよ

うに構成済みであることを確認します。

複製トポロジー

正常性確認の一環として、ご使用の複製トポロジーの確認および分析を行う必要があります。

次の事項を検討してください。

• ハブおよびスポークのトポロジーを使用している場合、ベスト・プラクティスはハブから複製

を開始することです。これは、スポーク・サーバーで使用可能なリソースの量をサーバー・ク

ライアントの要求に対して 大化するために行われます。

• ベスト・プラクティスは、レプリケーター・タスクの数を、ハブが複製するスポーク・サーバー

の数と等しくします。 ただし、サーバーに高負荷がかかることを防ぐために、レプリケーター

は 20 を超えないようにする必要があります。複製するサーバーがハブ・サーバーではな

い場合、推奨されるレプリケーターの数はサーバー上のプロセッサーの数と等しくする必要

があります。

• 現在、どのくらいの頻度で複製していますか。 1 つの複製イベントは次のイベントが開始

される前に完了していますか。

• ご使用の環境で変更を完全に伝播するまでにどのくらいの時間がかかりますか。そのタイ

ミングは許容されますか。業務上の条件がありますか。または、要件は変更されています

か。

メール配信

正常性確認の一環として、ご使用のメール配信トポロジーの確認および分析を行う必要があり

ます。次の事項を検討してください。

• 各 Domino サーバー上のメール・ボックスの数を確認します。 この設定は、設定文書の

「Router SMTP Basics (ルーター/SMTP 基本)」タブに記載されています。『サーバーに配

置する MAIL.BOX データベース数を決定する』のガイドラインに従って、メール・ボックスの

適な数を確認します。

• ご使用の環境では、現在スパムは制御されていますか。ご使用の SMTP インバウンド制御

を変更したり、サード・パーティーのサービスや製品を使用してご使用の環境でスパムの管

理を向上させることを検討する必要がありますか。

• メール・ボックスに配信不能メールがたまっていますか。

177

サーバーのセキュリティ

完全な正常性確認では、セキュリティも検討する必要があります。ヒントをいくつか示します。す

べてのリストについては、『1.3 セキュリティ・チェックリスト』を参照してください。

• サーバー文書の「Security (セキュリティ)」タブには、サーバー・アクセスと権限を制御す

るフィールドが含まれています。組織では、タスクを実行するのに必要な 小限のアクセ

ス権限のみ担当者に付与されるように制御する必要があります。例えば、データベース

管理者には Domino ドメインへのフルアドミニストレーターは必要ありません。

• ユーザー ID およびサーバー ID を Domino ディレクトリーの対応文書に添付できますが、

ベスト・プラクティスはそれらの ID を NAMES.NSF の外部で安全に保管し、認証局

(Technote 7006424 参照) や ID ボールトなどの機能を使用することです。

• Domino ディレクトリーへのデフォルトの ACL アクセス権を付与するのではなく、管理者は「Default (デフォルト)」を「No Access (アクセスなし)」に設定してから、適切な認証者のみに付与できます。次に例を示します。

「*/ORG」を「Reader (読者)」にします。

ディレクトリー・アシスタント

正常性確認の一環として、ディレクトリー・アーキテクチャーを確認する必要があります。複数

のディレクトリーの使用については、『3.4 複数のディレクトリー』を参照してください。

ディレクトリー・アシスタントは、サーバーがローカルの 1 次 Domino ディレクトリー (NAMES.NSF) 以外のディレクトリー内の情報を検索できるようにする機能です。ディレクト

リー・アシスタントを構成すると、リモート LDAP または別の Domino ディレクトリーのいずれ

かを使用できます。 高のパフォーマンスを得るためにサーバーへのローカル・レプリカを使

用するには、2 次 Domino ディレクトリーの参照を構成する必要があります。管理者は、ディレ

クトリー・アシスタントが有効化されているすべてのサーバーで、参照対象の追加の Domino ディレクトリーのレプリカを作成する必要があります。

次の事項も検討してください。

• 追加の 2 次ディレクトリーが必要ですか。 • 現在使用されているすべてのディレクトリーが必要ですか。 • モバイル・ディレクトリー・カタログや拡張ディレクトリー・カタログを作成する必要があり

ますか。 • サーバー上で使用されているのは、推奨の拡張ディレクトリー・カタログ・アーキテク

チャーではなく、モバイル・ディレクトリー・カタログですか。

個人文書 正常性確認の一環として、個人文書の確認をお勧めします。例えば、個人文書のフィールド妥

当性検査では、「Internet Address (インターネット・アドレス)」フィールドが入力されていること

は指定されていません。外部の送信者からのメール配信は、インターネット・アドレスが「User Name (ユーザー名)」フィールドに保存されている場合に発生する可能性があります。誤った

メール転送を防止するには、Domino メール・ボックスを持つすべてのメンバーが、有効な外部

電子メール・アドレスを「Internet Address (インターネット・アドレス)」フィールドに入力する必要

があります。

ポリシー ポリシーは、管理者がユーザーのクライアント設定を制御できる強力なツールです。ポリ

シーを使用して、単にクライアント・オプション (E メール送信前のスペルチェックなど) を設

178

定することもできます。また、企業ポリシー (E メール・メッセージの免責事項など) を施行

するために使用することも可能です。

正常性確認の一環として、効力のあるポリシーを確認します。また、ユーザーに適用される可能

性のある矛盾したポリシーがないか、ポリシー・ルールを確認します。少なくともデスクトップ・ポ

リシー、セキュリティ・ポリシー、登録ポリシーを次のように設けることをお勧めします。

• Notes クライアントを標準化するためのデスクトップ・ポリシー。電話によるサポートの依

頼が減り、トラブルシューティングが簡単になるというメリットがあります。 • 企業の指示をインラインで遵守するためのパスワードを施行するためのセキュリティ・ポリ

シー。 • 新規ユーザーとそのアカウントの作成を標準化するための登録ポリシー。例えば、す

べての新規ユーザーはメール・ファイルに対して (マネージャーではなく) 編集者のア

クセス権を持つようにします。

ポリシー のトピックは、この wiki で詳しく説明されています。『2.3 ポリシー』を参照してください。

バックアップとリストアの手順 正常性確認の一環として、バックアップとリストアについて、手順の確認と文書化がまだ行

われていなければ行う必要があります。

• 明確に定義されたバックアップ手順は、あらゆるビジネスにとって不可欠です。Domino 環

境のバックアップ・スケジュールは、アーカイブ・トランザクション・ロギングが有効かどうかに

応じて決まります。トランザクション・ロギングのタイプが循環ロギングであったり、無効化さ

れている場合には、Domino データ (NSF / NTF) の日次フルバックアップが必要となる可

能性が高くなります。

• トランザクション・ログがサードパーティーのツールでバックアップされている場合、スケ

ジュールはこれに対応している必要があります。トランザクション・ログは頻繁にバックアッ

プする必要があり、毎晩、増分バックアップにより Domino データが取り込まれます。フル

バックアップは、週 1 回実行する必要があります。

• リストア手順は、バックアップ手順と同様に重要です。バックアップが自動化される傾向に

あるのに対して、通常、リストアはテクニカル操作グループまたは Domino 管理者によっ

て実行されます。したがって、データベースが想定どおりにリストアされており、ビジネスで

要求された場合に手順を円滑に実行できるように、定期的な「予行演習」の実行が役立ち

ます。

4.2. Document Configuration Tuner (DCT)

Domino Configuration Tuner (DCT) は、Domino 8.5.x サーバーと管理クライアントに含ま

れる多くのツールの中の 1 つに過ぎません。Technote 4019358 から無料でダウンロードす

ることも可能です。

DCT には、Domino 管理者による使いやすいセルフサービスの構成分析が用意されていま

す。DCT の目標は、Domino サーバーのパフォーマンスがより安定し向上するように変更でき

る、サーバー文書と NOTES.INI 構成パラメーターを特定することです。

DCT は、IBM が特定した一連のベスト・プラクティス・ルールと照らし合わせて構成を分析しま

す。さらに、ワースト・プラクティスの構成が検出された場合、それを警告します。構成の設定は、

Technote、Redbooks/Redpapers、IBM の開発とサポートからの社内知識、およびお客様の

以前の体験に基づいて、その値が問題を発生することを示している場合にフラグが立てられま

す。予期せぬ動作を防止できるよう、範囲外の値および想定外の値がレポートされます。資料

をサポートするリンクも提供されます。

図 81

DCT ルールは、Lotus Domino サーバー 7.0 以降 (どのバージョンの Domino でも分析は可

能) に合わせてあり、Lotus Notes クライアント (標準またはベーシック) バージョン 8 以降が必

要です。DCT ツールの内部では、ボタンにより 新の更新を DCT テンプレートにインストール

し、 新のルールをダウンロードします。ルールは、通常、毎月更新され、現在の追加事項に

関する 新の詳細は Tuner Blog に記載されます

DCT の評価を実行する際に、実稼働のデプロイメントに対する構成を変更する必要はありませ

ん。完全分析では、業務時間内でも気にならない、環境のごくわずかな負荷も示します。した

がって、分析は常時実行できます。

評価された大半のルールは Notes/Domino wiki に投稿され、DCT のレポートで wiki 投稿に

ついて示されます。検索結果の推奨事項と実際の経験が一致しない場合は特に、結果の

フィードバックに DCT の利用をお勧めします。Notes/Domino wiki のエントリーは、フィード

バックの機能を備えています。

詳しくは、Notes/Domino wiki の『Domino Configuration Tuner』エントリーを参照してください。

4.3. パフォーマンス・ベースラインの確立

管理者は一連のヒストリカル・ベースライン・データから、環境に変化を加える際に比較する参照

ポイントを得ることができます。またベースラインを確立することにより、パフォーマンスのボトル

ネックまたは傾向を明確に識別できます。例えば、CPU は毎週月曜日の朝にピーク・レベルに

達することがあり、またディスクのキューの長さは毎週同じ周期で通常の動作限界を超えている

ことがあります。

正確なヒストリカル・ベースライン・データを収集するには、以下の一連のベスト・プラクティスに

従ってください。

• インフラストラクチャーのパフォーマンスの完全なビューを収集します:カーネル統計

179

180

(CPU、メモリーおよびディスクの使用率)

• 情報を定期的に収集して長期のトレンド分析を行います。チューニング・イベントの実施前は、システムのクイック・スナップショットのみに頼る情報収集は避けてください。

• それらの情報は通常のシステム負荷を表すものと見なされます。通常以外のイベント中 (年始の休暇時期など特に活動の少ない期間) に取得されるデータは記録もしなければ考慮もしないでください。

• 異常なイベント中 (システム障害や大量トランザクション) のデータは含めないでください。

• 所定の期間にわたって (例えば、少なくとも 1 週間、好ましくは 1 カ月間) 記録を取ります。

• データ収集時に個々のサーバーで実行されていたコンポーネントまたはサービス (ServerTasks、バックアップ機能またはウィルス対策機能) の説明を入れます。

主要なチューニング変更またはシステム・アップグレードごとに、システムが安定してから、

一連の新たなベースライン統計を取得します。

4.3.1.推奨されるメトリック

以下のメトリックからベースライン統計を確立するための基準が提供されます。経験の蓄積と共

に他の有用な、あるいは実施したチューニングのタイプ向けのより適したメトリックが見つかるこ

ともあります。

Perfmon

• Memory.Available MBytes • Processor.% Processor Time • LogicalDisk Avg. Disk Seconds Read • LogicalDisk Avg. Disk Seconds Write • LogicalDisk.Avg. Queue Length.

- o/s drive - Notesdata - tx log - DAOS - view rebuild temp. drive - swap

Events4 / Statrep

• Server.AvailabilityIndex • Server.Users • Replica.Cluster.SecondsOnQueue.Avg • Replica.Cluster.WorkQueueDepth.Avg

注: Replica.Cluster 統計は、監視対象のサーバーが Domino クラスターのメンバーの場合

のみ関係します。これらの統計は同期されたレプリカを保守するクラスターの能力の指標を

提供します。

Domino 統計および定義の包括的な解説については、『Lotus Domino Statistics』を参照してく

ださい。

4.3.2. Domino 統計の収集

管理者は COLLECT および EVENT のサーバー・タスクを使用して、Domino ドメイン全体の

サーバー統計の監視および収集をできます。この手順については、IBM Lotus Domino およ

び Notes インフォメーション・センターの説明『統計と Lotus Domino システム』に詳しく記載さ

れています。サンプリング間隔は 15 分以上にしてください。多くの場合、管理者にとって適切

な間隔は 1 時間程度です。

統計の収集はすべての Domino サーバー上で実施できます。統計収集の設定は管理サー

バー上で行い、統計の収集はその他のサーバーからリモートで行うことがベスト・プラクティ

スとなります。

4.3.3.レポート・データベース

図 82 は、カスタマイズした Monitoring Reporting データベース (STATREP.NSF) の例です。

ここには、events4.nsf (統計プロファイル) の頻度設定に対応する各サンプルが含まれていま

す。列の追加や削除を行って、利用可能なすべての統計の中から選択します。これらの統計は

コンマで区切られたボリューム・ファイルとして簡単にエクスポートできるため、グラフの作成も

可能です。

図 82:statrep.nsf でのモニター結果

181

182

4.4. Domino のチューニングのヒント (全プラットフォーム)

以下のヒントは、管理者が Notes/Domino 環境を 適化するのに役立ちます。管理者が、何ら

かの設定変更を行った場合、その効果を詳しくモニターする必要性を理解していることが重要

です。一度に １ つずつ変更を加えることで、悪影響を容易に識別して変更を戻せるようにしま

す。

4.4.1.ビュー索引更新

Domino の更新タスクに対しては、マルチコア・ハードウェアの追加の CPU リソースを活用

するようにチューニングできます。使用可能な NOTES.INI パラメーターは複数あります。

更新タスク (ビュー索引の更新)

システムのリソースに余裕があれば、NOTES.INI にパラメーター (Updaters=[数値]) を追加す

ることにより、サーバーで追加の更新タスクを開始できます。経験則からすると、 大でも更新

タスクの数は CPU 1 個に対して 1 を超えることはできません。例えば、2 つの更新タスクを有

効にするには、以下のパラメーターを適用します。

• Updaters=2

全文索引の更新

全文の更新に対しては、別のスレッドを単独で作成することができます。このスレッドは全文

索引の更新のみを担当するため、大容量の全文索引が再構築されている場合でも、ビューの

更新は引き続き発生します。Domino サーバーに多数の全文索引が存在し、かつ CPU のリ

ソースに十分余裕がある場合には、以下の NOTES.INI パラメーターの適用を検討してくださ

い。

• UPDATE_FULLTEXT_THREAD=1

ビュー索引の保守

データベース設計者が「Design View Attributes (デザイン・ビュー属性)」ダイアログ・ボッ

ク ス で 何 も 選 択 し な か っ た 場 合 、 管 理 者 は NOTES.INI パ ラ メ ー タ ー (DEFAULT_INDEX_LIFETIME_DAYS=[日数]) を使用して、データベース・ビュー索引

のデフォルトの存続期間を設定できます。

このパラメーターのデフォルト値は 45 です。この値を小さくすることには以下の 2 つの利

点があります。

• ディスク・スペースの節約 • 更新タスクが実行する処理量の削減

ビュー索引の作成はディスク集約型であり、CPUおよびメモリーのリソースも必要とするため、

管理者と設計者の間でうまく均衡を取ることが重要です。この値を 14 (2 週間) 未満にするこ

とはお勧めできません。

183

4.4.2. 特定のデータベースに対するトランザクション・ロギングの無効化

トランザクション・ロギングのチューニングは、メールに関係する有効な DAOS 機能に影響を

与えることがあります。ほとんどの場合、トランザクション・ロギングを無効にするとサーバー

の迅速な再起動という利点を失うことになるためお勧めできません。データベースのトランザ

クション・ロギングの無効化は、データベース上での修復実行を引き起こし、再起動の速度が

低下する恐れがあります。 さらに、該当のデータベースについてトランザクション・ログを使用する増分バックアップが実施できなくなります。ただし、一部のデータベースでは、トランザクション・ロギングを有効にする必要がない場合もあります。 これはデータベースがディスク上に追加のトランザクション・ログ・トラフィックを生成し、これによりトランザクション・ログ・ドライブに迅速に書き込まれるためです。 トランザクション・ログの無効化に適したデータベースの例には、次のものがあります。

• メール・ボックス (mail.box) - DAOS の実行中は、Mail.box のトランザクション・ロギングを

無効化しないでください。 • サーバー・ログ (log.nsf) • モニター結果 (statrep.nsf) • メール受信統計 (statmail.nsf) • Web管理 (webadmin.nsf) • スケジュール (clubusy.nsf または busytime.nsf) • クラスター・データベース・ディレクトリー (cldbdir.nsf)

表1 の NOTES.INI パラメーターにより、サーバーの起動時に作成された特定のシステム・

データベースの新しいインスタンスはトランザクション・ロギングが無効になります。これらの

パラメーターは既存のデータベース、または手動で作成されたデータベースにあるトランザク

ション・ロギングは無効化しません。

NOTES.INIパラメーター システム・データベース

MailBoxDisableTXNLogging=1 Mail.box (下の注記参照)

Log_DisableTXNLogging=1 Log.nsf

Schedule_DisableTXNLogging=1 clubusy.nsfまたはbusytime.nsf 表1：データベースのトランザクション・ロギングを無効にする NOTES.INI パラメーター 注:DAOSの実行中は、Mail.box のトランザクション・ロギングを無効化しないでください。

4.4.3.複製

環境に 2 つ以上の Domino サーバーがある場合には、複製をセットアップする必要がありま

す。以下のヒントは、環境全体のデータの複製に必要な時間とリソースを 適化するのに役

立ちます。

複数レプリケーター・タスク サーバー上のデータベース・レプリケーター (replica) タスクは、スケジュール指定された複製

要求を、サーバー接続文書に設定されたとおりに処理する役割を担っています。クラスター・

レプリケーター (clrepl) タスクはイベント駆動型で、データベース内の変化に反応します。そ

れらの変更は次に、他のクラスター・メンバーに複製されます。

各レプリケーター・タスクは一度に 1 つのサーバーとしか複製できません。そのため、 初の複

製が完了するまで次の複製を開始できません。実行する並列レプリケーター・タスクの数は、次

184

の NOTES.INI パラメーターで設定できます。

• Replicators=[数値]

クラスターに 3 つ以上のサーバーが属している環境では、追加の clrepl タスクを有効にでき

ます。実行する並列 clrepl タスクの数は、NOTES.INI パラメーターで設定できます。

• Cluster_Replicators=[数値]

管理者は Replica.Cluster Domino の統計をモニターする必要があります。例えば、

WorkQueueDepth Domino の統計はクラスター・メンバーへの複製を待機している変更の数を

示します。これが継続的に増加する場合は、追加の clrepl タスクを有効にします。以下の統計

は、それぞれ現在、平均およびピーク時のクラスター作業キューの深さを表します。

• Replica.Cluster.WorkQueueDepth • Replica.Cluster.WorkQueueDepth.Avg • Replica.Cluster.WorkQueueDepth.Max

複製の三角化 クライアントまたはサーバーがリモート・サーバーと複製する場合、リモート・サーバーの名前と

時刻および日付のログが複製履歴に残ります。Domino はこの複製履歴を使って、次の複製

の間に変更に関するスキャンをどの文書に対して行うかを判断します。複製の三角化の目的

は、各サーバーが、同じデータベースのレプリカを維持している他のすべてのサーバー、およ

び成功した複製を有する他のすべてのサーバーを認識できるようにすることです。

ドメイン内のサーバーが数百になる大規模な環境では、保持する複製履歴イベントの数が

Domino サーバーのパフォーマンスに大きく影響することがあります。数百あるいは数千のサー

バーにある、データベース複製の三角化履歴の保守には大きなコストがかかります。これは、複

製タスクに要する CPU 使用率の増加といった形で現れることもあります。

以下のサーバー NOTES.INI パラメーターを使用して複製の三角化を無効にできます。 (Domino 7.0 以降で使用可能)。

• NSF_REPLHIST_NO_TRI=1 • REPL_NO_WS_TRI_HIST=1 • REPL_NO_REMOTE_TRI_HIST=1

ローカル・レプリカの場合は、以下の Notes Client NOTES.INI パラメーターを使用します。

• NSF_REPLHIST_NO_TRI=1 [これによって、既存の三角化されたエントリーの読み

取りが防止されます] • REPL_NO_WS_TRI_HIST=1 [これによって、新規の三角化されたエントリーの書き込

みが防止されます]

注:これらの NOTES.INI パラメーターを設定したら、影響を受けたデータベースの各レプリ

カから複製履歴を消去する必要があります。

詳しくは、Technote 1270104 を参照してください。

185

4.4.4. 内部キャッシュ

Domino では、キャッシュは、データがディスクから継続的に読み取られることを防ぐために、

メモリーの頻繁な検索の保存に使用されます。機械的なハード・ディスクは一般的にサー

バーで も遅いコンポーネントであるため、キャッシュを使用することによって、パフォーマン

スおよびユーザー操作に対する応答を向上できます。以下のセクションでは、キャッシュ・サ

イズが適切に設定されていることを管理者が確認する際のヒントを示します。

NLCache NLCache は、名前検索キャッシュです。Domino 8.5.2 より前では、デフォルト値は 16 MB です。Domino 8.5.2 から、デフォルト値は 64 MB です。必要に応じて 4 GB まで拡大できます。

NLCache を拡大する必要があるかどうか判断するには、show stat データベース・コマンドまた

は show NLcache コンソール・コマンドを使用します。 例: Database.NAMELookupCacheCacheSize = 16,447,205 (キャッシュの現在のサイズ) Database.NAMELookupCacheLookups = 1,879,903 Database.NAMELookupCacheMaxSize = 16,777,216 (デフォルトの 大サイズ) Database.NAMELookupCacheMisses = 1,362,746

検索数に比べて見つからなかった数が比較的多いことは、許可する 大キャッシュ・サイズを大

きくする必要があることを示します。 管理者は、NLCache のサイズを徐々に大きくしていく必要があるため、必要に応じて、 初は

デフォルト値を倍にしてみます。ini パラメーターを使用して、次のように変更します。

• NLCache_Size= 例えば、67108864 に設定します。これによって NLCache_Size が 64 MB に設定されます。

グループ・キャッシュ サーバーでグループのメンバーを参照する必要がある場合 (例えば、認証要求の場合)、サーバーではグループ・キャッシュが 初に確認されます。サーバーは、パフォーマンスを

適化するために、グループ・キャッシュに結果を保存します。グループは、更新時またはキャッ

シュがいっぱいのときには、無効になります。デフォルトのサイズは 4 MB で、15 MB まで拡

大できます。

十分なデータをキャッシュできないためにキャッシュを頻繁に再構築する必要がある場合、これ

によってグループ検索が遅くなる可能性があります。このため、頻繁な、または大規模のグルー

プ更新によって、サーバーが遅くなる可能性があります。

「Show stat net」を使用して GroupCache 統計を確

認します。NET.GroupCache.Hits = 155 NET.GroupCache.Misses = 10 NET.GroupCache.NumEntries = 9 NET.GroupCache.Size = 65,406 NET.GroupCache.Used = 2,716

NET.GroupCache.Misses は、キャッシュ内にグループが見つからなかったためディスクか

ら読み取る必要があった回数を示しています。管理者は、見つからなかった回数が減るま

で、グループ・キャッシュのサイズを徐々に拡大する必要があります。NOTES.INI パラメー

ターを使用して、次のようにサイズを変更します。

• Group_Cache_Size= 例えば、15360 に設定します。これによって Group_Cache_Size が 15 MB に設定されます。

186

Unified Buffer Manager (UBM)

UBM (以前の NSF バッファー・プール) は、サーバー上のすべてのデータベースに対するディ

スク I/O 要求をキャッシュすることによってパフォーマンスを向上する際に使用されます。UBM は通常、サーバー上の共有メモリー使用量の 大要因です。

Domino の以前のリリースでは、UMB の 大サイズはサーバーの物理 RAM の 8 分の 3 として自動的に計算されていました。RAM が数ギガバイトもあるサーバーでは、これによって UMB の上限値が許容できないほど大きくなっていました。4 GB の RAM がインストールされ

ているサーバーがあるとします。

大 UMB サイズ = (4 x 3/8) = 1.5 GB。

UMB が 大サイズの 1.5 GB まで大きくなると、共有メモリーがプロセス制限値を超え

て、サーバーが不安定になるリスクがあります。

Domino 8 では、Windows32、Linux、AIX、Solaris、i5/OS、および z/OS の各プラットフォー

ムで、デフォルトで 大 UBM サイズが 512 MB に強制されるようになりました。64 ビットの Domino では、 大 UBM サイズは 1024 MB です。 このため、Domino 8 では、UBM のサイズを適切に設定する措置を取る必要はありません。

この新規動作について詳しくは、Technote 1268988 を参照してください。

NSF_BUFFER_POOL_SIZE_MB の設定に関する推奨事項については、Technote 1286171 を参照してください。

NSF_DbCache_MaxEntries NSF_DbCache_MaxEntries では、サーバーがデータベース・キャッシュに一度に保持できる

データベース数が指定されます。サーバーに十分なメモリーがある場合は、Lotus Domino がメ

モリーに一度にキャッシュできるデータベース数を増やすことによって、サーバーのパフォーマ

ンスを向上できます。デフォルト値は、25 と NSF_Buffer_Pool_Size を 300 KB で割った値の

いずれか大きい方になります。

サーバー上の Database.DbCache.Hits 統計をモニターする必要があります。この統計は、

データベースのオープン要求が、キャッシュ内のデータベース検索によって実現できた回数を

示します。この数値が大きいと、データベース・キャッシュが効率的に動作していることになり

ます。InitialDbOpen に対する Database.DbCache.Hits の比率が低い場合は、

NSF_DbCache_Maxentries の増加を検討することをお勧めします。

Lotus Domino で同時にキャッシュするデータベースの数を設定する方法について詳しくは、 Technote 1279893 を参照してください。

NSF モニター・プール このモニター・プールでは、サーバーおよびクライアントのメール・ルールが含まれるイベント・モ

ニターがキャッシュされます。モニター・プールの設定値が小さすぎると、いっぱいになる可能性

があります。副作用として、「Calendar (カレンダー)」ミニ・ビューに新規カレンダー通知が表示

されなくなります。

デフォルトのプール・サイズは 40 MB です。このプールの 大値は、256/512 MB で

す。現在の値をチェックするには、以下の統計を確認します。 Database.MonitorPool.Event.Used = 52309 Database.MonitorPool.Monitors.Used = 1184 Database.MonitorPool.Size = 41943040

187

LOG.NSF で、「Insufficient memory – NSF monitor pool is full」というエラーがないかどうかチ

ェックし、Domino サーバーに対してこのプールを拡大する必要があるかどうか確認します。多く

のユーザーで、80 ～ 100 MB の値が 適であることが確認されています。

大値に近付いている場合は、NOTES.INI 設定を使用して、この値を増やします。

• NSF_MONITOR_POOL_SIZE_MB=

4.4.5. 複数のメール・ボックス

サーバーで追加のメールボックスが必要になるのは、メール・トラフィックの量によってルー

ターがメール・ボックス・ファイルに効率的にアクセスできなくなり、アクセス競合が発生した場

合のみです。アクセス競合は、その他のスレッドまたはプロセスによってメールボックスがロッ

クされているときに、別のエントリーがそのメールボックスにアクセスしようとして拒否された場

合に発生します。

1 つのメール・サーバー上のメール・ボックスの数は通常、メールの量によって 1 ～ 4 つです。

Technote 1148438 には、負荷の多いサーバーに追加のメールボックスが必要かどうかを判

断するための管理者向けの手順が記載されています。追加のメールボックスが必要と思われる

場合は、サーバー構成を 2 つのメール・ボックスに変更してください。

4.4.6. サーバー・ベースのメール・ルール に関するヒント

ビジネス要件に基づいて、数値を絶対 小値に保ちます。メール・ルーターがメールを配信する

たびに、メール・ルーターでルールを処理する必要があります。このため、ルール数およびサー

バー・リソース数を少なくする必要があります。 トリガーされる可能性が も高いルールをリストの 上部に置き、「Stop processing further mail rules (メール・ルール処理の中断)」オプションを使用します。 メール本文の検索は、CPU を集中的に使用するため、SMTP タスクで使用する CPU で消費

量が増加することになります。

以下の NOTES.INI パラメーターを使用して、ユーザーのメールファイルまたはサー

バーのメール・ボックス当たりのメール・ルールの数を制限します。

• MailMaxFilters=<1 to 100>

この IBM ケース・スタディーは、メール・ルールがサーバーに及ぼす影響について管理者に

示唆しています。

4.4.7. ユーザー・セッションのチューニング

サーバーで同時にオープンしておけるクライアント・ユーザー・セッション数および 1 つのセッショ

ンをオープンしておける時間をそれぞれ定義する 2 つの NOTES.INI パラメーターがあります。

セッションをオープンしたままにするには、サーバーにメモリーが必要です。一方で、新規セッ

ションをオープンする場合に消費される CPU リソースは少量です。 このため、バランスを取る必要があります。

• Server_MaxSessions=[数値] (同時にオープンしているセッションの 大数) • Server_Session_Timeout=[数値 (分)] (Domino サーバーによってセッションが終了される

までのアイドル・アクティビティーの 大継続時間)

188

ほとんどのユーザーに対して、30 ～ 45 分のタイムアウト値を設定することをお勧めし

ます。詳しくは、Technote 1089879 を参照してください。

4.4.8.Domino Configuration Tuner (DCT)

Domino Configuration Tuner (DCT) は、Domino サーバーのインストールをより堅牢にし、

Domino サーバーのパフォーマンスを向上するための、簡単に使用できるセルフサービスの

設定分析を提供します。DCT を定期的に更新することによって、Lotus Domino から提示され

る変更で環境を 新の状態に保持しておく必要があります。詳しくは、「Domino Configuration Tuner (DCT) provides easy-to-use self-service configuration」(Technote

4019358) を参照してください。

4.5. 仮想化環境のチューニング

組織がハードウェアおよびインフラストラクチャー環境の 適化と活用に継続的に取り組んで

いる中で、仮想化はメールおよびアプリケーション・サーバーの多くのデプロイメントにとって、

より大きなフットプリントとなりつつあります。仮想化は、1 つの TCO (総所有コスト) 削減方法

になり得ます。この記事では、Domino サーバーを仮想化 VMware アーキテクチャーにデプ

ロイするためのベスト・プラクティスおよびガイダンスを示します。

仮想化のみでは TCO 削減を実現する可能性は低いことを指摘しておく価値があります。これ

は、Domino サーバーの数は同じままで、必要な管理作業も同じままだからです。さらに、

チューニングと保守管理が必要な (ホスト) オペレーティング・システムが 1 つ増えます。組織

は、DAOS や ID ボールトなどの Domino の新機能や、Domino サーバー統合 (同一サー

バーでより多くのユーザーをホストする) を実装することによって、より効果的に TCO 削減を実

現できることがわかるかもしれません。

4.5.1. 仮想化の長所と短所

Domino を仮想化環境にデプロイする場合に生じる可能性のある利点は、次のとおりです。

• 組織は、サーバー統合作業のサポートに必要な物理フットプリントを削減できます。1

つの物理サーバー上で 2 つのメール・サーバーを実行できます。 • 組織が利用できるサーバーのリソース総量が多くなります • 物理ハードウェアから仮想ハードウェアへのマイグレーションによるユーザーへの影響

はほとんどありません。一方、統合 Domino サーバーへのユーザーのマイグレーショ

ンでは、テンプレート変更からハード・コーディングされたサーバー参照までが必要に

なったり、ユーザーのデスクトップ構成の変更が必要になったりする可能性があります。 • ディザスター・リカバリーの観点から、イメージを別の VMWare サーバーにすぐにアッ

プロードし、Domino Data、DAOS、およびトランザクション・ロギング・ストレージと同じ

物理サーバー上にあるかのように通信できるようにします。

ただし、これらの利点には、コストがかかります。組織は以下の事項を考慮する必要がありま

す。

• 仮想化を提供するにはハードウェア・リソースのオーバーヘッドが生じます。 • 通常、Domino サーバー仮想マシン (VM) が増えるほど、単一の物理サーバー

に伝わるディスクおよびネットワークの I/O が増加します。 • 構成によっては動的ゲスト・リソース・アロケーションにつながります。これによって

複数の VM でリソースを共有することになります。

189

4.5.2.静的リソース

Domino サーバーの活性化には、仮想化システム内のアーキテクチャーが静的で専用であ

ることを確実にすることが重要です。例えば、トランザクション・ログのディスク I/O、DAOS、

ユーザーのメール・ファイル、およびネットワーク機能はすべて各 Domino サーバー専用にし

ます。これは I/O パフォーマンス・チャネルを 適化し、仮想ノード (またはゲスト) に対して仮

想化が与える影響を 小化するためです。

ハードウェア・リソースが分離され、VM ゲスト専用になっていることを確認してください。メ

モリー・オーバー・コミット、バルーニング、または動的 VM バランシングなどの VMware 構成を使用しないでください。Domino アプリケーションの安定性やパフォーマンスにかか

わる問題につながる場合があります。

4.5.3.ゲスト VM に関するベスト・プラクティス

以下の点は、Domino メール・サーバーのサイジングで開始点のテンプレートとして設計さ

れています。

仮想 CPU

• VM 当たりの vCPU 数はサポートされるユーザー数によります • Domino ゲストの vCPU を過剰供給しないようにしてください。 ほとんどの場合、CPU

は 4 つで十分です。

仮想 RAM

Domino の RAM はより多くのデータをキャッシュできます。オペレーティング・システムも I/O キャッシュを行うため、全体のパフォーマンスが向上します。IBM Software Services for Lotus は Domino Server 当たり 4GB の RAM を推奨しています。

• 64 ビット OS でメモリー制限が改善されたため、より多くのデータをキャッシュしてディスク

IO を回避することができます。 応答時間の短縮によりユーザー数を増やします。

• 64 ビットのゲスト OS を実行する場合は VM メモリーを増やします。各 VM にゲスト OS および Domino アプリケーション・サービスのために 8GB を割り振ることをお勧めします。

ストレージ

LUN 当たりのサーバー数およびボリューム数によってストレージ・アーキテクチャーがボトル

ネックになる場合があります。ストレージ・アーキテクチャーを 適化するために、共有 LUN を使用しないでください。つまり、各ボリューム (Notes データやトランザクション・ログ・ドライブな

ど) は 1 セットのスピンドルにマップされ、各 Domino サーバー固有のものです。 ファイバー・チャネル・ディスクを使用し、可能な限り 4Gb 以上をお勧めします。2Gb もサ

ポートされますが、Domino Mail サーバーで帯域幅が制限されます。

パーティションのアライメント

• VMFS および仮想センターを使用してパーティションを作成します。

OS/Domino、データ、およびトランザクション・ログに対して個別の専用 LUN を使用します。

• 論理 LUN ではなく、物理ディスク・レベルで IO を分離します。

190

• これらの LUN が IO 要求のサポートに十分なスピンドルを備えていることを確認します。 • 1 つの VMFS LUN にスピンドルが足りない場合や VMDK ファイルが多すぎる場合

は、ディスク IO 待ち時間が大幅に増加する可能性があります。

RAID 構成

• データに RAID 1+0 およびログに RAID 0 を使用した 高のパフォーマンス • RAID 5 では、iSCSI、ハードウェア・ストレージ、またはソフトウェア・ベース RAID などの処

理速度が遅いストレージ・ソリューションに書き込みキューが蓄積される可能性があります。

ネットワーク構成

ネットワーク・アクセスを 適化するために、物理ネットワーク・インターフェース・コントローラー (NIC) を異なる Domino サーバー間で共有しないでください。 ネットワーク・トラフィックに基づいて専用 NIC を使用します。

• メールおよびクラスター複製トラフィックには個別の NIC を使用します。 • TSO および ジャンボ・フレームをサポートする拡張 VMXNET 2 または 3 ドライバーあ

るいはそれ以上を使用します。 • 利用可能な場合は NIC チーミングおよび VLAN トランキングを使用します。ただし、

ネットワーク・チーミングは常に 適な方法というわけではありません。

注：コロケーション VM の物理的なネットワーク速度は 1Gbps を超えます。

VM の時刻同期

• 仮想マシン内で VMware Tools の時刻同期を使用します。 • NTP デーモンを外部 NTP ソースと同期できるようにします (vSphere クライアントを使用) • OS タイム・サービスを無効にします。 • Windowsの場合：w32time service • Linux の場合：NTP デーモン

リソース予約

Domino リソースに制限を設定しないでください。Domino サーバーが仮想化されると、

各 Domino Mail Server に対して静的リソースとして実行する必要があります。

バルーニング

Domino サーバーに対してバルーニングを使用しないでください。Domino は起動時に認識し

たとおりにメモリーを割り振り、使用します。つまり、Domino サーバーはメモリー全体の物理

的割り振りに基づいてキャッシュ・プールを構築します。バルーニングを使用すると、これらの

構成を削除または損なう可能性があり、Domino の処理速度の低下、停止、またはクラッシュ

の原因になります。

• 実稼働環境では、 適なパフォーマンスのためにバルーニングは常に 0 に設定してください。

191

4.6. Windows 上の Domino のヒント

この記事では、Windows ベースの Domino サーバーを運用する管理者向けのヒントを説明しま

す。

4.6.1.システム・ページ・プール

数百ギガバイトの Domino データを扱う大規模環境は、Windows の一般的な問題の影響

を受ける可能性があります。

Domino はアクセスを迅速にするために 近使用したファイルを開いた状態にして、データ

ベース・キャッシュを維持し、パフォーマンスを向上させます。これらのキャッシュは Windows のページ・プールに保存され、クライアントがデータベースを閉じてもキャッシュがページ・

プールに残る場合があります。大きなデータベースが多数開いていると、ページ・プール制限

を超えてしまい Domino サーバーに問題が発生する可能性があります。詳細については、

Technote 1093511 をお読みください。

Windows 2003 (32 ビット) サーバーの問題に対処し影響を軽減させるには、次のステップ

を実行して 2 つのレジストリー・キーを修正します (ステップの内容はMicrosoft document Q312362 から流用しています)。

1. Registry Editor (Regedt32.exe) を起動します。

2. レジストリーで次のキーを検索してクリックします。

•HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\Memory Management

3. 「編集」メニューで「値の追加」をクリックし、次のレジストリー値を追加します。

値名:PoolUsageMaximum データ・タイプ: REG_DWORD Base: Decimal 値データ: 60

値を 60 に設定することで、PagedPoolMax の デフォルト設定の 80% ではなく 60% でMemory Manager がトリミング・プロセスを開始します。 アクティビティーのスパイクに対処する際に、しきい値が 60% では不十分な場合は、この

設定を 50% または 40% に下げます。

値名: PagedPoolSize データ・タイプ:REG_DWORD Base: Hex 値データ: 0xFFFFFFFF

PagedPoolSize を 0xFFFFFFFF に設定すると、 大ページ・プールを他のリソースの代

わりにコンピューターに割り振ります (500 MB まで)。

注意: PagedPoolSize に 0xFFFFFFFF を設定することは、64GB RAM を搭載した 32 ビッ

ト Windows Server 2003 ベースのコンピューターには推奨されません。 これにより Free System PTE エントリーがダウンし、コンピューターがリブートし続ける可

能性があります。この構成については、要件および利用可能なリソースに基づいて慎重に

192

値を選択してください。

4.6.2.Windows サーバーに関するその他のチューニングのヒント

Technote 1234550 は、Windows ベースの Domino サーバーについて重点的に説明して

いる、管理者向けの参考文献です。

4.6.3 その他の参照先

Domino Wiki の Knowledge Collection: Hardware or Operating System error - "Insufficient system resources exist to complete the requested service 不足は Windows Paged Pool に関する問題について詳細に説明しています。本書に記載された

領域だけでなくその他の領域についても説明しています。

また、Windows 2008 に特化した記事もあり、修正を適用して実行していない場合に生

じる一般的なパフォーマンスの問題について説明しています。

• Technote 1449825

「Windows 2008 64-bit can cause a significant CPU increase and I/O degradation when Domino opens many databases」

• Technote 1427348 「Windows 2008 64-bit hangs/slows dramatically when Domino server is shut down」

4.7. Linux 上の Domino のヒント

Domino for AIX および Domino for Linux はいくつか共通する特徴があるので、これらのプラッ

トフォームでのチューニング方法も共通する部分があります。

4.7.1.サーバーリソースのモニター

4.3 パフォーマンス・ベースラインの設定では、チューニングの変更を行う前にベースラインを設定

することの重要性について既に説明しています。nmon ツールは、CPU およびメモリーの使用率、

ディスク I/O メトリックスおよびカーネル統計などのパフォーマンス・データを分析およびモニター

するように設計されています。nmon パフォーマンス・ツールは、後で分析およびレポートのため

のグラフ作成を行うためにデータをテキスト・ファイルに収集することができます。出力はスプレッ

ドシート形式 (.csv) です。

4.7.2.オペレーティング・システムの制限

開いたファイルの 大許容数のデフォルト設定は、通常小さすぎる値に設定されています。この

パラメーターの設定値が小さすぎる場合は、ファイルを開いたとき、または接続を確立したとき

にエラーが発生することがあります。この値によりサーバー・プロセスが開くファイル記述子の数

が制限されるので、値が小さすぎると、 適なパフォーマンスが妨げられる場合があります。

/etc/security/limits.conf をチェックし、nofile エントリーを以下のように追加します。

• notes soft nofile 49152 • notes hard nofile 49152

注:上記の例では、notes は Domino が実行されるユーザー・アカウントです。使用環境に

従ってこれを設定します。

開いたファイルと同様に、プロセス/スレッドの 大数も小さすぎる値に設定されること

193

があります。nproc 属性は各ユーザーが作成できる 大プロセス数を表します。

/etc/security/limits.conf をチェックし、nproc エントリーを次のように追加します。

• notes soft nproc 12500 • notes hard nproc 12500

注:上記の例では、notes は Domino が実行されるユーザー・アカウントです。環境に従って

これを設定します。

4.7.3.Linux サービス

(Red Hat Enterprise Linux に固有):updatedb コマンドは検索データベースを更新します。こ

のプロセスはディスクに非常に負荷が集中するので、営業時間外にのみ実行してください。

mlocate.cron スクリプト (通常 /etc/cron.daily/mlocate.cron) が通常の営業時間外に実行さ

れていることを確認します。

Domino Server 上で有効になっている場合は、ポートの競合を防止するために、これらのサー

ビスを無効にします。

httpd/apache (HTTP) sendmail (SMTP)

4.7.4.TuneKrnl

Domino for Linux には、「tunekrnl」ツールが付属しています。このツールは Domino の開始

時に動的カーネル・パラメーターを設定する際に自動的に実行されます。これによって Domino サーバーは、自動的にカーネル・パラメーターを調整することができます。

4.7.5. トラブルシューティングとデバッグのヒント

• Linux の場合、gdb (GNU プロジェクトのデバッガー) の 新バージョンがインストール済み

であることを確認します。 • AIX の場合、dbx (AIX の標準コマンド・ライン・デバッガー) の 新バージョンがイ

ンストール済みであることを確認します。 • AIX の場合、procstack (AIX のもう 1 つのデバッガー。プロセス内のすべてのスレッドの

16 進アドレスとシンボル名を表示します) の 新バージョンがインストール済みであること

を確認します。

注: AIX の場合、Domino は 状況によって dbx と procstack の両方を使用する場合がありま

す。 両方とも、 新バージョンである必要があります。

194

4.7.6. AIX 上のDominoサーバーでの並列 I/O とダイレクト I/O の 無効化

Domino サーバーは CIO 機能との連携をサポートしていません。Domino がアクセスするファ

イル・システムにおいて、このオプションを有効にしないでください。詳しくは、インフォメーション・

センターのこちら記事を参照してください。

4.7.7. AIX 上の Domino での Java のチューニング

以下の Technote 1451336 には、Agent Manager のスレッドによって過剰に CPU が使用され

ることを防ぐためのガイダンスが記載されています。

4.7.8. AIX 用の Perfpmr

Perfpmr は、固有のパフォーマンス・データをシステムから収集する AIX 用のツールです。こ

のツールは、他の複数のスクリプトを実行するシェル・スクリプトです。それらのスクリプトは、シ

ステム・パフォーマンスの情報を取得するためにさまざまなツールを実行します。Perfpmr が収

集した情報を確認すると、パフォーマンス問題のトラブルシューティングを行う場合や、IBM サポートからシステムのデバッグの支援を受ける場合に役立ちます。システムの通常運用中、ま

たはシステムの構成変更やフィックスパックのアップグレードなどの実施前後にパフォーマンス

問題が発生した場合に、このツールを実行できます。 Perfpmr および役立つ AIX ツールの一覧について詳しくは、「Performance Monitoring Tips and Techniques」を参照してください。

4.8. IBM i 上の Domino のヒント 4.8.1. 概要

IBM i 上で Domino を実行する場合の概要について述べます。以下に、IBM i 上で Domino を実行する場合に知っておくべきことをいくつか示します。

• IBM i 上では、Domino はすべて分割インストールされます。Domino 製品のコードは、常

に Domino サーバーのデータとは別に格納されます。Domino 製品のコードは、

/QIBM/ProdData/Lotus/DominoXXX ディレクトリーにあります。ここで、XXX はご使用の

リリースを表しており、例えば、/QIBM/ProdData/Lotus/Domino852 のようになります。

• IBM i 上の Domino では、複数リリースの実行をサポートしています。 例えば、アップグ

レードを計画する場合、プライマリー dpar (Domino パーティション・サーバー) を 8.5.1 にしたままで、テスト用の dpar を 8.5.2 にアップグレードすることができます。複数バージョン

について詳しくは、古いけれどもまだ関連性のある IBM Redbooks 資料「Lotus Domino 6

Multi-Versioning Support on the IBM eServer iSeries Server」を参照してください。

• IBM i 上でのDomino のインストールとアップグレードは、別ステップで行うことができます。

つまり、製品のインストールを営業日の間に行い、サーバーのアップグレードを後で行うこ

とができます。これによって、アップグレードに必要な停止時間が減少します。サーバーの

アップグレードに使用されるコマンドは、UPDDOMSVR です。UPDDOMSVR コマンドにつ

いて詳しくは、インフォメーション・センターの「UPDDOMSVR」のトピックを参照してください。

• 正しく動作するためには、すべての Domino データを QNOTES ユーザーのプロファイルで

所有する必要があります。 これは、Domino サーバーのデータ・ディレクトリーにあるすべてのオブジェクトに対して特に重要です。IFS ファイルの所有者を更新するには、CHGOWN コマンドを使用します。ネイティブ・オブジェクトの所有者を更新するには、CHGOBJOWN コマンドを使用します。

• IBM i は EBCIDIC システムです。プラットフォーム間でのデータ転送時のパフォーマンス問

題を防止するには、常にバイナリー・モードで FTP を使用します。言い換えると、Windows 環境で Domino データベースをドラッグ・アンド・ドロップしないということです。FTP の使用

について詳しくは、Technote 1447140 を参照してください。

• IBM i は、Windows とは異なるファイル・ロック・メカニズムを使用します。したがって、ファ

イル・アクセスによるデータ破壊の問題を防止するために、ネットワーク・ドライブを Domino サーバーのデータ・ディレクトリーに割り当てないようにしてください。

• System i Navigator と IBM Systems Director を含む、IBM i オペレーティング・システム

で使用可能なグラフィカル・ユーザー・インターフェースがあります。Domino 管理者に

も使われるネイティブ CL コマンドについて知りたい場合は、Technote 1321770 を参照

してください。

• IBM i に固有のバックアップとリカバリーについては、IBM Support Assistant を通じて

使用可能なバックアップとリカバリー戦略に関する教育モジュールを参照してください。

• ネットワークの変更や問題に注意してください。ネットワークの応答が遅いと、ユーザーに対

して遅延とエラーが発生します。また、Domino は、メールを転送するために、機能している DNS サーバーに常にアクセスする必要があります。環境内で DNS サーバーの IP アドレ

スが変更された場合、IBM i 内の DNS サーバーのエントリーについても、CHGTCPDMN コマンドを使用して更新する必要があります。

4.8.2. パフォーマンス

システム・パフォーマンスの分析を始める場合、以下が必要です。

• 使用しているシステムが、使用するワークロードをサポートするように設計されていることを

確認します。使用するワークロードの 小システム要件を決定するには、IBM Workload Estimator を使用します。

• Domino のワークロードについてシステムを比較するには、システムの MCU (メールとカレ

ンダーのユーザー) 評価を使用する必要があります。CPW は従来のワークロード用ですが、

Domino には使用しないでください。現在のシステムの MCU 評価を決定するには、以下の

各『Performance Capabilities』マニュアルの付録 D を参照してください。 • バージョン 5、リリース 3 • バージョン 6、リリース 1 • IBM i 7.1

応答時間はシステム・パフォーマンスの 良の指標になります。このセクションでは、ほとんど

の顧客が環境の応答時間の低下を訴え始める限界について、一般的なガイドラインを示しま

す。システムごとに条件が異なるため、応答時間が影響を受ける正確なしきい値は、ハード

ウェアとシステムの使用方法によって上下する場合があります。

195

196

モニター・ツール

システム・パフォーマンスを収集するために使用可能な複数のツールがあります。

• 収集サービス • IBM i Job Watcher • IBM i Disk Watcher • System i ナビゲーター

これらのツールについての詳細な説明と使用方法は、この記事の範囲外です。 パフォーマン

スの統計データ収集についての概要は、『IBM Redbooks Domino 6 for iSeries Best Practices Guide』の第 4 章を参照してください。

CPU

• シングル・プロセッサー・システムの場合、CPU 使用率は 85% 以下を保ってください。

• マルチプロセッサー・システムの場合、CPU 使用率は 90% 以下を保ってください。

• CPU 使用率が 100% を示す前に、システムが CPU 性能の限界に達する場合があることに

注意してください。 これはどのようにして起きるのでしょうか。ここで、4 プロセッサー・システムを仮定します。1 つのプロセッサーは活発に動作しているが他はアイドル状態にある場合、システム全体の CPU 使用率は 25% になります。 シングル・スレッドが存在する場合、集中的な CPU 動作がゆっくりと進行するため、CPU の問題が明確に示されないまま CPU が性能限界に達する可能性があります。 シングル・スレッドの CPU 使用率を確認する必要があります。1 つのスレッドが 1 つのプロ

セッサーを 100% 使用している場合、すなわち、この例では CPU 全体で 25% を使用して

いる場合に、システムは CPU 制約を受けます。ヒント: IBM Performance Tools for i5/OS の WRKSYSACT コマンドを使用して、スレッド・レベルで CPU 使用率を確認します。

• デフォルトでは、Domino のジョブはすべて同じジョブ優先度、すなわち 優先度 20 で実行さ

れます。ところが、一部のタスクの優先度を変更したい場合があります。例えば、CPU 制約

を受けているシステムにおいて、どのジョブがより CPU を使用するかを試行して管理する

ような場合です。実行優先度の変更は、Technote 1099547 の手順に従って行うことができ

ます。ジョブ優先度を変更することで、ビューの索引更新、エージェント、adminp などの集

中的な処理の優先度を、サーバーや HTTP などのユーザー・インターフェースを実行するタ

スクよりも強制的に下げることが可能です。

メモリー

• マシン・プールのフォールト率は 1 秒当たり 5 回以下に、ページング率は 1 秒当たり

10 回以下にする必要があります。

• Domino サーバーのメモリー・プール (デフォルトは BASE プール) は、非データベースの

フォールト率とページング率を、プロセッサーあたり 100 回以下と 300 回 以下に維持する

必要があります。 そのため、2 つの完全にアクティブなプロセッサーを備える 1 つの論理

パーティションまたはシステム上で動作する 5 つのdpar の場合、データベース以外の

フォールト率とページング率を 1 秒当たり 200 回と 600 回に保つのに十分なメモリーを備

える必要があります。

197

• システムに必要なメモリー量を正確に決定することは困難です。大体の目安は、 大の

データベースの も複雑なビューを確認することで得られます。Domino サーバー専用の

アプリケーションに含まれるビューに必要なサイズの 2 倍が、 低限必要です。

例えば、合計 2 GB のサイズの複数のビューを含むアプリケーション・データベースが存在

する場合、ビューの更新中に 適なメモリー性能を保証するには、Domino サーバー専用

に 低 4 GB のメモリーを確保する必要があります。

• メモリー制約を受けているシステムでは、追加メモリーが購入されるまで、NSF バッファー・

プールのサイズを減らすことでパフォーマンスを改善できます。 NSF バッファー・プールを減らすとルーターのスレッド数も減る可能性がありますので、注意してください。メール転送速度の低下を防ぐため、手動でその数を増やすことが必要な場合があります。 ルーターがスレッドを割り当てる仕組みについて詳しくは、Technote 1093562 を参照してく

ださい。

ディスク

• ディスク I/O とディスク・ビジー率を確認する場合、ディスク・ビジー率が 35% 以下であること

を確認してください。

• ディスク容量を使い切らないようにしてください。理想的なドライブの使用率は 90% 未満です。

• 使用済みのスペース (%used) は、すべてのドライブで一貫している必要があります。

• ドライブ間のバランスを取る場合は Domino サーバーを終了する必要があります。

• 保護/ミラーリング・ステータスがアクティブになっており、低下になっていないことが必

要です。ステータスが低下というのは、ドライブのパフォーマンスが低下しているか、

ディスクやハードウェアのエラーが発生している可能性があることを示す場合がある

からです。

Domino タスク

パフォーマンス全体に役立つまたは影響を与える可能性のある Domino 固有の事項があります。

• ODS レベルを 新の状態に保ちます。Domino 8.5 にアップグレードする際に ODS レベル

を 51 に更新する必要はありません。ただし、サーバー・パフォーマンスに影響を与えるパ

フォーマンスの改善点が多数あるため、できるだけ早くアップグレードすることが重要です。

• 不要なタスクを無効にします。 管理サーバーまたはハブ・サーバーで SMTP を実行してい

ますか。複数の dpar で COLSRV400 を実行していますか。DECS を実行しているものの、未使用ではありませんか。 Domino サーバーの下で実行されるあらゆるタスクは、何らかのシステム・リソースを使用するため、不要なタスクをなくすことはシステム全体のパフォーマンスの向上につながります。

• トランザクション・ロギングは、すべての顧客にとって有益なリソースとなりました。

ただし、トランザクション・ログを有効にすると、パフォーマンスに影響します。ほとんどのインプリメンテーションでは、CPU の使用率に 3% の上昇が見られます。例えば、トランザクション・ロギング開始前に Domino サーバーによる CPU の使用率が 38% であった場合、ロギング開始後には約 41% になります。 また、通常は I/O 速度に 5 ～ 15% の上昇があります。したがって、ディスクのビジー率 (%) が通常 10% である場合は、トランザクション・ロギングの有効化後にはドライブのビジー率

(%) が 10.5 ～ 11.5% になる場合があります。

• その他のパフォーマンス全体の情報については、「Sizing Large-Scale Domino Workloads on

iSeries」を参照してください。

4.9. Domino HTTP サーバーのチューニングのヒント

デフォルトの設定は、「One Size Fits All (一つのサイズですべてに対応)」のアプローチです。こ

の設定は出荷時のまま機能しますが、Domino サーバーの使用方法に基づいてマイナー変更

をいくつか行うと、サーバーのパフォーマンスと効率を向上させることができます。サーバー 適

化のために実行可能な事項を以下に示します。

4.9.1.HTTP サーバー・スレッド

サーバーを適切に機能させるために、受け取った要求をすべて処理できる必要があります。 Domino には、Domino Web サーバーの正常性を判断するのに役立つ統計が多数用意されて

います。例えば、Web サーバーで使用されるピーク時のスレッド数を決定するには、統計 Domino.Threads.Active.Peak を確認してください。 デフォルトでは、アクティブなスレッドの数

は 40 です。ただし、使用可能なスレッドをすべて使用している状態で、追加のスレッド用に使用

可能なメモリーがある場合は、図 83 に示すように、サーバー文書の「Internet Protocols... (インターネットプロトコル...)」•「HTTP」タブの「Number active threads (アクティブスレッド数:)」パ

ラメーターでこの値を増やします。

図 83

Domino Web サーバーは送信されてきた要求をキューに入れるので、これらを HTTP サー

バー・スレッドによって処理することができます。場合によっては、使用されるキュー・メソッドを

変更するとパフォーマンスを向上させることができます。詳しくは、Technote 1201715 を参照

してください。

198

4.9.2.HTTP リクエスト

サーバーを調整する場合は、どのような要求がサーバーで処理されるのかを把握しておくと役

に立ちます。これは、Domino Web サーバー要求をロギングすることで対応できます。した

がって、アクセス・ログあるいは Web ログ・データベース domlog.nsf を確認することにより、

処理された要求の情報にアクセスできます。サーバーのロギングは、図 84 に示すように、

サーバー文書の「Internet Protocols (インターネットプロトコル...)」タブで有効にできます。

図 84

どの要求がリアルタイムで処理されているのかを確認するために、Domino コマンド tell http show thread state を使用できます。このコマンドにより、すべてのアクティブなスレッ

ドのリストと、スレッドがアイドルでない場合には現在処理されている URL が表示されます。

以下にサンプルのエントリーを 2 つ示します。 初のスレッドはアイドルで、2 番目のスレッ

ドは User One (uone.nsf) の受信ボックスを開いています。

11/18/2010 12:09:28 Http Worker Thread ID [1c7]: [Thread State is Idle] 11/18/2010 11:18:12 Http Worker Thread ID [2425]: Working session [9a732]: Session State [Processing Request] : GET /mail/uone.nsf/iNotes/Proxy/?OpenDocument&Form=s_ReadViewEntries&PresetFields= DBQuotaInfo;1,FolderName;($Inbox),hc;%24Sender1%7C%2498,UnreadOnly;1&TZType =UTC&Start=1&Count=23&resortdescending=1 HTTP/1.1

データベース競合、ビュー索引の再構築またはデータベースの破損が原因で、サーバーがす

べての要求を処理しようとしている場合は、すべての要求で同一のデータベース、ビューまたは

ドキュメントが表示されます。これは、管理者にとって、潜在的なデータベースの問題を識別す

るための迅速かつ簡単な方法です。また、保留中のすべての要求がエージェントである場合が

あります。デフォルトでは、一度に 1 つのエージェントのみ処理を実行できます。ただし、サー

バー上で実行中のエージェントがスレッド・セーフである場合は、複数の Web エージェントを同

時に実行できるようにサーバーの構成を変更できます。 変更を行うには、サーバー文書を開き、「Internet protocols... (インターネットプロトコル...)」• 「Domino Web Engine」タブにアクセスします。 図 85 に示すように、「Run web agents and web services concurrently (Web エージェントと Web サービスを同時に実行しますか?)」を「

Enabled (有効)」に変更します。

図 85

4.9.3.JVM のヒープ

デフォルトの JVM のヒープは NOTE.INI パラメーター HTTPJVMMaxHeapSize を使用して

変更できます。Xpages を使用している場合、8.5.2 以降ではヒープのサイズを増やすことがで

きます。Xpages を使用しておらず、8.5.1 を実行している場合は、デフォルトのサイズを小さく

することができます。詳しくは、Technote 1377202 を参照してください。

199

200

4.9.4. データベースのパフォーマンス

Domino Web サーバーとアプリケーションを使用して作業している場合は、Lotus Notes クライ

アントからデータベースのパフォーマンスを向上させる場合と同じ手法を Web サーバーに使用

することができます。データベースのパフォーマンス低下の も一般的な原因については、

Technote 1174563 のリストを参照してください。