IBM Lotus Dominoパーティション・サーバー(DPAR)を新しいハードウェア上にインストール、統合、または移行するために各要件の規模を見積もりました。しかし、ある程度の期間が経過すると、予測した見積もりよりも多くのCPUリソースをDPARが消費していることに気付くことになります。既存のユーザーをどのように新しいDPARに合わせるのでしょうか。なぜ初めに規模を小さく見積もってしまったのでしょうか。

この記事では、Lotus Dominoの規模の見積もりが2、3カ月経過すると現状と合わなくなる理由と、見積もりの要件(DPARのCPUリソースなど)への影響について説明します。DPARのモニター方法と、DPARが見積もりとワークロードに合ったCPUリソースを消費しているかどうかを評価する方法にも言及します。

Lotus Dominoのプラットフォームごとに見積もりのツールとプロセスが異なるため、この記事では、見積もりの定式は提示しません。代わりに、各ツールおよびプロセスでさらに正確に見積もりができるように、サイジング情報の有効性を大幅に向上させる方法について説明します。具体的には次の内容について説明します。

• 現在の見積もり方法を検証する
• 見積もりに影響を与える要素を見直す
• 新しいDPARのCPU要件の見積もりに役立てるために、既存のDPARからデータを収集する方法を知る
• 見積もりのケース・スタディーとサンプルを検討する

この記事は、Lotus Dominoの各種機能に精通した経験豊富なLotus Domino管理者を対象にしています。この記事では、任意のプラットフォーム上で稼働するリリース6以降のDomino DPARを取り扱います。

「どうしてこの設定にしたのか」

これは、DPAR要件の規模を見積もった後で(実装の直後のことも、実装から2、3カ月経ちCPUリソースの問題が発生するときのこともありますが)、多くの管理者が自問する問いかけです。サーバーの統合やプラットフォームの変更を伴う場合は、通常、新しいプラットフォーム上のLotus Dominoが従来のプラットフォームと同等のパフォーマンスを発揮していないと想定されます。あるいは、以前よりも高いユーザーのレートで稼働するDPARの数が少ないため、Lotus Dominoの規模が効率的に拡大されていない可能性が想定されます。

ここに至るまでの経緯を振り返るときに、何が起こったかを理解する重要な要素は、管理対象のデータです。通常、CPUビジーなど、CPUリソース使用率の数値は収集しても、Lotus Domino統計を収集して管理することはあまりありません。DPARには、日ごとに変化するだけでなく、分ごとにも変化する動的なワークロードがあります。特定の時点で、ご使用のDPARにエンド・ユーザーからどのようなワークロードがかかっているかはわかりません。

DPAR全体でのワークロードを測定する方法として、Lotus Dominoのトランザクション数(server.trans.total)を使用する傾向があります。しかし、Lotus Domino Serverから提供されるLotus Dominoのトランザクション数は、サーバー全体のワークロードを測定する基準となるものではありません。正確に言うと、DPARとLotus Notes Clientの間、または他のLotus Domino DPARとの間のNRPCトラフィックを測定するものです。Lotus Notes/Dominoのリリースをアップグレードすると(サーバー側またはクライアント側で)、同じワークロードを実行していても、トランザクション数が変わる可能性があります。

また、ユーザーは同じアクションを実行していても、稼働中の他のLotus Dominoタスク(複製、AdminP、索引作成など)の変更によって、トランザクション数が影響を受けます。さらに、NRPC以外のプロトコル(HTTP、IMAP、POP3など)のクライアントが、トランザクション数にはほとんど変化がなくても、リソース使用量を大幅に変える可能性もあります。実際に、DPARのトランザクション数とCPU使用率の間には、直接の相関関係はありません。この事実の詳細な分析については、developerWorksの記事 『Lotus Domino 7 on the IBM zSeries(US)』 の『Measuring a production DPAR』セクションを参照してください。記事では、数カ月間に3倍のユーザーが追加されているにもかかわらず、同じDPARが同じトランザクションの比率を示しています。

DPAR上のユーザーの数(登録数、接続数、15分間隔でアクティブな数)を把握するだけでなく、ユーザーがDPARに実行を要求するワークロードについても理解することが重要です。IBMのキャパシティー・プランナーは、規模を見積もるために通常、メール・ユーザーをワークロードの特性に基づいてライト・ユーザー、ミディアム・ユーザー、ヘビー・ユーザー、パワー・ユーザーの4つのカテゴリーに分類します。各カテゴリーは、CPU使用に関して異なる特徴があるため、ユーザーがどのカテゴリーに属するのか、複数のカテゴリーがどのように混成しているかを把握していないと、ユーザー・コミュニティーに必要なリソース量の計算を誤ることがあります。

上に戻る

見積もりに影響を与える要素

DPARのCPU使用量の見積もりに影響を与える可能性のある要素はたくさんあります。以降でそのいくつかを取り上げます。

エージェント

DPAR上でユーザー作成のエージェントの実行を許可すると、ユーザーはサーバー上のCPUリソースを無制限に利用できるも同然になります。ユーザー作成のエージェントに何ができるか、どのくらいの頻度で実行されるか、何人のユーザーが実行するかはわからないため、消費するリソースを予測する方法はありません。エージェントは、組織内の多くのユーザーの間で共有され、素早く広がる傾向があります。特に、便利だと思われる機能のあるエージェントは、1人から2人、4人、8人、16人と急速に広まることがあります。

Lotus Notes管理者グループの作成した最善の意図を持つエージェントでも、意図しない動きをすることもあります。例えば、IBM内部でメールDPARの1つのリソース使用率を観察していたところ、サーバーが使用可能かどうかを検証するポーリング・エージェントが、サーバーがメールの配信に使用しているリソースより多くのリソースを消費していることを発見しました。エージェントを書き直すと、CPU使用量は劇的に減少しました。

書き方を間違えたエージェントが、DPARに大損害を与える可能性もあります。別の例ですが、1時間おきに実行されるエージェントを見つけたこともありました。しかし、記述のしかたのせいで、目的の文書のみを対象とするのでなく、すべてのビューのすべての文書を先頭から終わりまで次々に読み込んでいました。その結果、このエージェントの実行には1時間以上かかりました。1時間おきに実行されるようスケジュールされているため、エージェントは終わることなく、1日24時間週7日稼働し続けました。1つのDPARのこの1つのエージェントだけで、4WayのCPUボックス上のほぼ1つのエンジンに相当するCPUサイクル、つまり全CPU能力のほぼ25％を消費していました。

サーバー上で無制限にエージェントを許可し、また実稼働環境のDPAR上でエージェントを許可する前にテストを実施しない場合は、全ユーザーの間から現れては消えるこのようなエージェントが、瞬間的にCPU使用率の大幅な急上昇を引き起こすのを覚悟しなければなりません。サーバー上で個人エージェントの実行を許可する必要がある場合、少なくとも、どのようなエージェントが、どれだけの数、どのユーザーにあるかを把握するレビュー・プロセスを設け、それを考慮してDPARを見積もることをお勧めします。

受信ボックスとデータベース・サイズ

ユーザーのメール・ファイルのサイズも、ユーザー・コミュニティーのサポートに必要なリソースの総量に影響を及ぼします。developerWorksの記事 『Lotus Notesの大きなメール・ファイルに対するベスト・プラクティス』 は、メール・ファイル・サイズの影響、「受信ボックス」ビューの文書数、ユーザー・コミュニティーのサポートに必要なリソースについて論じています。この記事では、データベースのサイズと受信ボックスで管理するエントリー数の両方が、ユーザーのサポートに必要なリソースの量を決定する重要な要素であること、受信ボックス内の文書が多くなると、メール・ファイルが大容量であるよりコストがかかることが明確に示されています。

クラスタリングと複製

DPAR間にクラスタリングまたは複製を設定すると、ユーザーのサポートに必要なリソースの量に影響があります。クラスタリングのオーバーヘッドはある程度(イベント・ドリブンのアクティビティーなので、メール・ボリュームに基づいて)予測可能です。ユーザーをサポートする要件への複製の影響は予測不可能です。クラスタリングでは、変更のあるデータベースのみがプッシュされ、複製されます。ただし、スケジュールされた複製を使用する場合、(データベースを開くことや、相違点を検索することも含み)変更が行われたかどうかには関係なく、複製の対象であるすべてのデータベースが複製されます。また、複製の間隔が短いほど、DPARへのリソースの影響は大きくなります。これは、複製対象がないことを検出するために頻繁にCPUサイクルが使用されるためです。

クラスタリングを使用している場合でも、やはり複製のスケジューリングは推奨されます。こうすると、DPARが随時クラスターの各サイドのデータベースと同期をとり、同一であることを確認します。プログラム文書を使用して、DPARの開始時に複製を起動することもできます。これによって、万が一に備えて1時間おきにスケジューリングするのではなく、DPARの再始動時にイベント・ドリブンの複製が可能になります。秘訣は、クラスタリングでは複製は1日に数回のみにすることです。

クラスタリングと複製の受信側は、サーバー・タスクです。したがって、これらの機能のサイクル/コストの大部分は、クラスター/複製タスクではなく、サーバー・タスクに含まれます。サーバー・タスクでクラスター/複製のサイクルへの考慮を怠ると、これらの機能の要件が小さく見積もられる結果になります。

全文索引

DPARで全文索引の使用を許可すると、全文索引の管理だけでなく、全文索引で実行される検索への考慮も必要になります。多くのリソースを必要とするのは、全文索引の管理ではなく、実際の検索です。索引に対して実行される検索の数を把握する必要があります。

トランザクション・ログ

トランザクション・ログを使用する場合、トランザクション・ログの実行に必要な追加のサイクルを考慮に入れる必要があります。追加のメリットのある他の機能(データの整合性の向上、サーバー再始動の高速化、DPARのスケーラビリティーの向上)と同様に、CPUリソース要件の計画が必要です。

他の要素

リソース要件に影響を与える可能性のある他のLotus Domino機能、アドイン機能、サード・パーティー製品についても考慮が必要です。例えば、ウィルス・スキャン、バックアップと復旧、RIM/Blackberryの使用、シングル・コピー・テンプレート、メッセージ・トラッキング、ネットワーク圧縮、メールと連動するユーザー作成のアプリケーションなどを検討します。このようなアクティビティーはすべて、程度の差はあっても、ユーザー・コミュニティーのサポートに必要なCPUの量に影響を及ぼします。

上に戻る

サーバーの管理方法

前述のリストには個々の機能やワークロード特性が挙げられていますが、DPARを設定して管理する方法もCPU使用率およびDPARの見積もり要件に影響を与える可能性があります。例えば、プライム・シフト時にDPAR上でAdminPまたはDominoディレクトリの複製の実行を許可する場合は、ユーザーのワークロードに加えて、この機能のサポートに必要なサイクルを計画する必要があります。プライム・シフト中にDominoディレクトリの複製は排除できませんが、発生する頻度は制御できます。明らかに、DPAR上のDominoディレクトリの変更を頻繁にプッシュするほど、リソースへの影響が大きくなります。

プライム・シフト中にAdminPを実行すると、AdminPの更新がいくつのリソースを要求するか正確にわからないエージェントを実行するのと同じ状態になります。例えば、名前またはグループを変更し、データベースでフィールド・レベルのセキュリティーを有効にすると、各データベースのすべての文書が検索され、該当の名前が該当のフィールドに存在するかどうかを確認します。これを実行すると、非常にCPUに負荷のかかるプロセスになる可能性があります。同時に、他のAdminPの変更は実行にあまりコストがかからず、即座に終わる可能性もあります。ここでのポイントは、次のAdminP要求が必要とするリソースは決してわからないということです。一般的な経験則から、DPARからのCPU使用量の瞬間的な増大を排除するには、プライム・シフト・ユーザー・ウィンドウ以外でAdminPを実行することを推奨します。そうでない場合、これに追加のリソースを割り当てるよう計画する必要があります。

さらに、プライム・シフトの間にCompact、Updall、Fixupまたは他のメンテナンス・タスクを実行すると、リソースに多大な影響を与える可能性があるため、注意が必要です。

上に戻る

クライアント・タイプ

ユーザーが実行するクライアント・タイプは、ユーザー・コミュニティーをサポートするCPU要件に影響を与えます。ただし、クライアントのコストはLotus Dominoのリリースによって変わるため、ここで正確なクライアント・コスト値を提示するのは不可能です。

例えば、現在のリリースでNRPCクライアントが100 CPU単位を使用し、クライアントXが200単位を使用すると仮定すると、2:1の割合となります。次のリリースで、NRPCが30％向上し、クライアントXが15％向上した場合、割合は2.45:1となります。これは、クライアントXが新しいリリースで悪化したわけではありません(実際は15％向上しています)。ただし、新しいリリースでのNRPCクライアントのコストを比較すると、クライアントXは以前より比例的に多くのリソースを使用しています。向上の割合を逆にして、NRPCが15％、クライアントXが30％向上した場合、割合は1.65:1となります。

さらに、NRPCクライアントについて、クライアントごとにコストが異なるだけでなく、プラットフォームによっても差が出る可能性があります。例えば、リリース7において、Linux on IntelではNRPCクライアントがリリース6.xと比べて劇的に機能が向上しましたが、Linux for System Zではこのように向上しませんでした。これは、Linuxのスケーリングに関する大きな変更は、最初にリリース6.5のLinux for System Z用に開発されて組み込まれたためです。Linux for System Zのリリース7ではこの劇的な変更の反映はありませんでした。これは、拡張機能が開発されたときにすべてのプラットフォームで起こることです。実現可能な場合、コア・コードに戻って他のプラットフォームに移植されます。Lotus Dominoの多様なプラットフォームでサポートされるさまざまなクライアントの機能が向上することによる変動も考慮に入れる必要があります。

HTTPユーザーは、DPAR上でNRPCクライアントよりかなり多くのCPUサイクルを使用することを予測できます。これは、Lotus Domino Web AccessまたはWebメールを使用するかどうかによって、NRPCユーザーの6倍を上限に変化します。理由は、Lotus Notes Clientが実行していた処理が、この場合ではサーバー上で実行されるためです。Lotus Notes Clientの場合は、サーバーがデータを転送し、Lotus Notes Clientが結果をフォーマットして表示できます。しかし、HTTPクライアントの場合、サーバーはさらにデータのフォーマットと表示の処理の大部分または全部を実行しなければなりません。

POP3ユーザーは、NRPCクライアントと比べてCPU使用量が約20％少なくなっています。デフォルトで、POP3はクライアント中心のプロトコルです。メールはサーバーからクライアントにダウンロードされると、サーバーからは削除され、クライアント側で管理して、ナビゲートできます。ただし、POP3の設定で、メールをサーバー上に残し、サーバー中心型のプロトコルと同じように実行することもできます。これにより、DPARに対してPOP3クライアントを実行するコストが変わります。

IMAPユーザーは、NRPCクライアントより約60％多くCPUを使用する可能性があります。デフォルトで、IMAPはサーバー中心のプロトコルです。メールはサーバー上に残され、ユーザーがメール間をナビゲートする間、クライアントは継続的にサーバーと通信する必要があります。一部のIMAPクライアントはサーバーからメールをダウンロードしてクライアント側で実行するよう設定できますが、利用できる機能と潜在的な影響について理解する必要があります。

上に戻る

ユーザーは何をするか

DPAR上に登録されたユーザー数を知るだけでは、DPARが使用するリソースの量は正確にはわかりません。2つのDPARがあり、登録ユーザー数とアクティブ・ユーザー数が同じで、同じタイプのクライアントを持つとしても、リソース使用率に大幅な開きがある可能性はあります。登録ユーザーはバックアップとポーリングのアクティビティーに、アクティブ・ユーザーはCPU使用率に、接続ユーザーはメモリーの使用率に影響を与える可能性があります。

既に述べたように、ユーザーをライト・ユーザー、ミディアム・ユーザー、ヘビー・ユーザー、パワー・ユーザーの4つのカテゴリーに分類します。容易に予測できることですが、1,000人のライト・ユーザーをサポートするCPUの総量は、1,000人のヘビー・ユーザーのサポートに必要な量よりずっと少なくなっています。以下に定義する各ユーザー・タイプは、Lotus Domino for zSeriesチームが見積もりの観点から使用しているものです。表1はその要約です。

ライト・ユーザー

ライト・ユーザーは電子メールのみ使用し、カレンダーのスケジュール機能は使用しません。このタイプのユーザーは、ときどき予約の通知を受け取ることはありますが、自分でミーティングをスケジュールすることはありません。電子メールの添付ファイルは送受信せず、メッセージのサイズは10 KB未満です。送受信するメッセージは1日10件以内で(インターネット・メールも含む)、一日中均等に配信されます。ライト・ユーザーのメール・ファイルは50 MB未満です。ライト・ユーザーとしてスタートしたユーザーは、すぐに製品に慣れ、ミディアム・ユーザーに昇格します。適切な見積もりのためには、ライト・ユーザーの数を過大に評価するべきではありません。

ミディアム・ユーザー

ミディアム・ユーザーは、カレンダーとスケジュール(C&S)機能をメールと組み合わせて使用します(予約は多くても1日に1件程度)。小容量の添付ファイルまたは画像付きのメールを送受信することもあります。平均メッセージ・サイズは25 KBで、大部分のメッセージは100 KB未満です。1日に10から25件のメッセージを送受信します。メール・ファイル・サイズは、50 MBから200 MBの範囲です。ユーザーの大部分がこのカテゴリーに入ります。ユーザーの仕事上の習慣がわからない場合、ユーザーの使用状況としてこのカテゴリーを選択します。

ヘビー・ユーザー

ヘビー・ユーザーは、ミディアム・ユーザーよりもさらに、電子メールおよびカレンダーとスケジュール(C&S)機能を活用しています(予約は週に5件以上)。メッセージ・サイズは比較的大きく(平均50 KB)、大部分のメール・メッセージは500 KB未満です。ヘビー・ユーザーは、1日に26から40件のメッセージを送受信します。メール・ファイル・サイズは200 MBを超えます。

パワー・ユーザー

パワー・ユーザーは、Lotus Notes/Dominoの中心的なジョブ機能を使用します。パワー・ユーザーの一例は、複数のカレンダーを管理し、ミーティングを予約するために空き時間を検索する管理職のアシスタントです。あるいは、メールやC&Sだけでなく、Lotus Dominoのその他の機能、例えば、全文索引/検索、メール・エージェント、複雑なルールなどを使いこなす技術専門職のユーザーです。パワー・ユーザーの平均メッセージ・サイズは75 KBですが、通常のメッセージ・サイズは100 KB以上です。パワー・ユーザーは、週に10件以上の予約を入れ、1日に40件超のメッセージを送受信します。メール・ファイル・サイズは200 MBを超えます。一般に、企業内でこのカテゴリーに入るユーザーはそれほど多くありません。

これらの分類に加えて、ローカル・メール複製やディレクトリー・カタログなど、どのワークロードをLotus Notes Clientに振り分けられるかも把握する必要があります。Lotus Notes Clientでローカル・メール・ファイルを使用すると、クライアントは大部分のクライアント・アクティビティーについてローカル・メール・ファイルでナビゲートするため、クライアントとDPAR間のトラフィックの多くが削減されます。クライアントでディレクトリー・カタログを使用すると、メールに宛先を指定するときに発生するDominoディレクトリ検索の負荷も削減できます。ネットワーク経由のDPARへのアドレスの先行入力機能の代わりに、Lotus Notes Client上でローカルに使用できるディレクトリー・カタログを指定することができます。

これらの機能を使用して、通常はサーバー上で実行されるアクティビティーをクライアントに振り分け、DPARのCPUリソースのコストを削減することができます。ただし、ローカル・メールの複製間隔を短く設定すると、Lotus Notes Clientが数分おきにDPARに新着メールの到着を確認してCPU使用率を押し上げるため、逆効果になります。クライアントの複製間隔を15分未満に設定するべきではありません。複製間隔を15分未満にする必要がある場合、CPUコストを下げるためには、クライアント複製を使用せず、DPAR上のユーザー・メール・ファイルを使用することを検討します。

ユーザーを前述の4つのカテゴリーに当てはめるのが難しい場合、代わりに、ユーザーを業種(工員、事務員、IT、学生、教師、銀行の窓口係、株式仲買人など)で分類します。次に、それぞれの業種をユーザー・カテゴリーのいずれかに対応付けて、ユーザーの分布と予測されるワークロードを大まかに把握します。理解が深まると、定義の精度が上がります。

上に戻る

成長

ユーザー・コミュニティーの成長パターンを考慮に入れないと、最初にどのような見積もりをしていても、ユーザーが増え、メールやメール・ファイルの容量が増えるとすぐに不十分になります。

あるケースでは、DPARのCPU使用量が毎月5％の複合成長率を示しました。前年比に置き換えるとサーバー要件でほぼ80％の成長となります。ユーザーのメールボックスのサイズの制限値(上限)、個人エージェントの制限、全文索引または検索の制限はありませんでした。さらに、古いメールのアーカイブや管理の方針もなく、ユーザーはすべてを受信ボックスに残していました。

これは極端なDPARの例ですが、見積もりで成長を考慮に入れないと、計画したハードウェアで環境をサポートできる期間に影響があります。

ピーク時の負荷と平均の負荷

DPARの見積もりを検討するときには、平均のワークロードではなく、DPARが処理しなければならないピーク時のワークロードに合わせて見積もっていることを確認する必要があります。例えば、連休が明けた最初の日は、DPARがプライム・シフトの最中に再始動したり、大量のメールが発生してCPUのピークの山が通常より大きくなったりすることがあります。このような状況に対処する十分なリソースがない場合、DPARはCPU負荷の高い状態に陥って正常に動作しなくなり、ユーザーの応答時間が悪化し、クラスター内の他のDPARにフェイル・オーバーすることもあります。

統計から実際に読み取れるのは何かを把握してください。24時間全体を見ているのでしょうか、プライム・シフトの間隔を見ているのでしょうか。データのサンプル・ビューを変えるだけで、レポートの値が大幅に変わることがあります。例えば、サーバーは終日60％の平均的なCPU使用率で稼働しています。しかし、同じデータでも、プライム・シフト中のピーク時の負荷でフィルタリングすると、平均使用率が85％で、瞬間的に95％から100％に近づくことが何度かあるとわかります。60％という数値は24時間全体を見た場合に妥当ですが、実際のピーク時のワークロードを正確に表してはいません。新しいサーバーの計画にこの数値を使用すると、95から100％の急増が発生した場合に、すぐにこのボックスの容量を使い果たしてしまいます。

Lotus Domino統計を見るときにも、同じように理解する必要があります。統計値の多くは累積して増えていく性質があります。このデータは、show statコマンドから、またはStatrep.nsfデータベースを参照して取得します。サーバーが始動したときから、または値が最後にリセットされたときから、値は常に増加しています。このデータを定期的に収集せずに、不定期に参照しているのみの場合、DPARで何が発生しているかだけでなく、いつ、どのような頻度で発生しているかも見落とすことになります。

データを収集するタイミング

どのサーバーも、ワークロード・アクティビティーに何らかの周期があります。例えば、夏期の間は、年間の他の期間と比べると多くの人が休暇をとります。8月中のDPARに基づいてサーバーを見積もると、要件を過小評価する可能性があります。

業務サイクルによっては、DPAR上のアクティビティーのレベルが高くなったり低くなったりすることもあります。例えば、新規リリース出荷前または四半期/年次の業務報告書の発表前の数週間は、新規リリースの次の週よりも、DPARの稼働率は上がると予想できます。DPARでピーク時の負荷に対処するには、どのような業務サイクルがあるか、どの時間帯にピーク時の負荷が現れるかを把握する必要があります。

アプリケーションとメールのワークロード

IBMが提供する見積もりとベンチマークの数値は、メールのワークロードを中心にしています。メールは繰り返し処理できるので、一貫性のあるテストが可能になるからです。Lotus Dominoでは、メール以外にユーザー作成のアプリケーション・ワークロードを実行できます。このようなワークロードではさまざまなLotus Domino機能を固有の組み合わせで使用するため、見積もりはほぼ不可能です。この場合、カスタム・アプリケーションの規模を正確に見積もるには、通常、ベンチマークが必要です。見積もりに基づいて、アプリケーションのパイロットを実行し、このパイロットの実際の使用量を提示することも可能です。ただし、アプリケーションや、Lotus Domino、サーバーに固有の制限があり、1つのLotus Dominoのイメージをそのまま拡大することはできず、複数のコピーを実行しなければならない場合もあります。

例えば、Lotus Dominoの新しいリリースで、CPUリソースのパフォーマンスが25％向上しているとします。これにより、購入予定の新しいハードウェア上で2つのDPARを1つに統合できる可能性があります。ただし、セマフォーのロック(あるいは、他の制限の要素)の発生など、アプリケーションが非効率に作成されていたり、Lotus Dominoの設定が不適切であったりする場合、ボトルネックが発生するまで、1つのDPAR内でCPU使用率がフルにならないことがあります。

上に戻る

サーバーのモニター

サーバーの見積もり時には検討すべき情報量の多さに圧倒されるかもしれませんが、このデータの多くはLotus Dominoが提供できます。成長パターンを把握し、新しい機能による影響を判断するためには、少なくともDPAR上で常にモニター・データを収集する必要があります。これは、現在の使用率と、予測より多くのリソースを使用している理由を知るために役立ちます。

統計の収集を有効にした場合、既出の『見積もりに影響を与える要素』セクションで挙げた項目についての情報は、Statrep.nsfデータベースに記録されています。デフォルトで、このデータベースにはイベントのみが格納されます。Collectタスクを有効にしない限り、DPAR統計情報は格納されません。複数のDPARから統計情報を収集する単一のDPARを設定することもできます。こうすると、Statrep.nsfデータベースが複数にならずに1つに統合できます。すべてのDPARでCollectタスクを有効にする必要はありません。情報を収集するDPARでのみ有効にします。

図1は、Lotus Domino 7の統計データが格納されたサンプルのStatrep.nsfデータベースを示しています。

図2では、レコードの領域のサンプルとして、1つのレコードを開いています。

この統計情報をLotus Dominoからフラット・ファイルにエクスポートし、他のデータベースまたはスプレッドシートにロードできます。図3は、エクスポートされたファイルのサンプルを示しています。

上に戻る

Statrep.nsfのデータの分析

ここで取り扱うグラフは、IBM社内の実稼働DPARのStatrep.nsfデータベースから取得したデータを基に作成したものです。これらのグラフは、次のビューのデータを表しています。

• 間隔 ： すべての値は7×24時間ベースでプロットされます。
• シフト間隔　： すべての値はプライム・シフトの範囲内でプロットされます。これは、月曜日から金曜日の8 AMから4 PMに定義されています。
• デイリー ： 1日ごとに1ポイント。それぞれの日のポイントは、その日の24時間全体のビューを表します。ただし、データのタイプによっては、データの合計値、最大値、最小値、または平均値である場合もあります。
• シフト・デイリー ： 1日ごとに1ポイント。それぞれの日のポイントは、その日のプライム・シフト・ビューを表します。ここでも、データのタイプによって、データの合計値、最大値、最小値、または平均値である場合があります。

メモ： 一部のグラフでは、値の大きさに開きのある複数の項目の関係をグラフ上に示すために、2つのY軸を使用してデータを表示することもあります。それぞれのグラフの凡例には、どちらのY軸を使用しているかが明確に示されます。

図4は、NRPCで接続されたユーザー数(server.user)と、このDPARで15分間隔でアクティブなNRPCユーザー数(server.users.active15)を示しています。

ピークの時間帯に15分間隔でアクティブなNRPCユーザーの数を調べると、登録されているコミュニティー全体の数と関連付けて、全ユーザーの何パーセントがDPARでアクティブであるかがわかります。

アクティブ数の割合を調べるには、接続されたユーザー数(server.user)ではなく、15分間隔でアクティブなNRPCユーザー数(server.users.active15)を使用することをお勧めします。接続されたユーザー数は、DPARのNotes.iniのサーバー・セッション・タイムアウト値の影響を受けます。DPARのサーバー・セッション・タイムアウト値によっては、同一のワークロードが、異なる2つの接続されたNRPCユーザー数の値を生成する可能性があります。15分間隔でアクティブなNRPCユーザーの数は変動せず、ユーザーのアクティビティーに直接関連しています。

ユーザー数など、Statrep.nsfの統計値の一部は各文書から直接取得できますが、2つの間隔の差を比較することによって導き出す必要のある統計値もあります。

図2の2,100万件のトランザクションは多いように思われますが、前述のとおりこの値は、DPARが始動したときからの合計、またはこの統計値が明示的にリセットされたときからの合計です。このサーバーが1日または2日間稼働している場合にはこのトランザクション数は多いと言えますが、サーバーが1カ月間稼働している場合には必ずしも多いわけではありません。Statrep.nsfのさまざまな文書を比較すると、DPARの運用中にこれらの統計値がどのように累計されていくか、間隔ごとの履歴を作成できます。

図5は、このDPARでの3週間にわたるLotus Dominoトランザクション数の間隔ビューのサンプルを表しています。

これをデイリー・プライム・シフト・ビューに変更すると(図6参照)、同じ期間のプライム・シフトの時間帯でのトランザクションの比率を簡単に参照できます。また、このデータを集計できるようにすると、DPARのワークロード、リソース使用率、変動を表す正確なビューを作成できます。

既に述べたように、DPARのワークロードを把握することが、正確な見積もりを行う鍵となります。ユーザーだけでなく、Lotus Dominoのさまざまな機能が行っている処理を知るために、Statrep.nsfデータベースのデータを参照できます。例えば、図7は、数週間にわたるプライム・シフトの間にこのDPAR上でローカルに配信されたメール・メッセージ数をメール・サイズ別に示しています。

図7では、サイズが1 KBから10 KB(青いライン)の範囲でメール数の瞬間的な急増がいくつか見られます。しかし、さらに興味深いのは、100 KB超の範囲(黒、ピンク、青緑色のライン)に見られる急増です。上位2つのメッセージ・サイズの詳細は、同じグラフで2番目のY軸を基にプロットされています(グラフの凡例を参照)。これらの量が緑のラインよりもずっと小さくても、メッセージのサイズは実際にこのDPARでCPUリソースの急増を引き起こす可能性があります。この情報を日次のグラフに(図6のように)プロットすると、このDPARにローカルに配信されるメッセージのサイズと数が時間とともに変化するかどうかを観察できます。DPAR上のワークロードの増加が表れていた場合は、リソースの追加を計画する必要があります。

図8は、1つのDPARで発生するクラスタリング・アクティビティーの量の例です。

図7のメール配信データと同様に、これはクラスタリング・アクティビティーの経時変化を明確に表します。ワークロードがどのような割合でどのように変化するかを把握すると、DPARのサーバー要件の規模見積もりに役立ちます。

この記事の『見積もりに影響を与える要素』セクションで言及したほとんどすべての項目は、この方法でStatrep.nsfデータベースからデータを取り込み、分析し、グラフ化できます。

Statrep.nsfに加えて、(Lotus Dominoプラットフォーム統計だけでなく)プラットフォームのネイティブ統計情報も参照してください。ここから、サーバー/DPARで稼働しているプロセスについての、Lotus Dominoのビュー以外のさらに詳細な情報が得られます。図9は、DPARの上位12プロセスとCPUの関係と、サーバー・タスクとの関連を示しています。このDPARはLotus Notes Clientをサポートしていて、NRPCクライアント要求はすべてサーバー・タスクで処理されるため、例にはサーバー・タスクを選択しました。これらのタスクをサーバー・タスクに関連付けると、このDPARを構成するさまざまなタスクでCPUリソースがどのように消費されるかを把握できます。

この図を理解する鍵は、これはCPUリソースの比例関係であるということです。言い換えると、同じワークロードを実行するユーザーが多くなっても、このグラフ上のラインは変化しません。このDPAR上のアクティビティーの割合が変化すると(例えば、エージェント、索引検索、複製の実行される件数が増えた場合)、このグラフ上のラインも変化し、さまざまなワークロードで注目すべき領域を示します。

このグラフからAgent Managerタスクがサーバー・タスクよりも多くのサイクルを消費していることがわかる場合、この追加のCPUリソースを見積もりに加えます。（Agent Manager、AdminP、Update、Replica、および他のLotus DominoタスクによるCPU消費が多いことがわかっています。）さまざまなタスクがどのような処理をしているかを理解すると、自社のユーザー・コミュニティーのサポートに必要なリソースがわかるようになります。

例えば、図9の下部の中央を見ると、Compactタスク(青緑色のライン)がプライム・シフトの時間帯に稼働していたことがわかります。これはこのサンプルでは1度しか出現しませんが、見積もりのためには、このようなタスクがプライム・シフトの時間帯に実行される頻度を調べる必要があります。このタイプのグラフでは、素早くDPAR使用状況の特徴を描き出し、実行されているタスク間の関係を把握できます。Routerタスクの瞬間的な急増は、大量のメールによるもので、これも、計画に入れる必要のあるワークロードの急増の一例です。

このグラフを作成するには、それぞれのタスクが使用するCPUを、各間隔ごとにサーバー・タスクが使用するCPUに分割します。HTTP、IMAP、またはPOP3がプライマリー・クライアントである場合、それぞれのタスクを基本のタスクとして簡単に選択できます。ハブDPARの場合は、基本のタスクとしてRouterタスクを使用します。

上に戻る

ケース・スタディー： サーバー統合の見積もり

このケース・スタディーでは、CPUの能力を上限まで使用しているハードウェア環境の既存のLotus Domino DPARでサーバー統合の可能性を調査します。計画では、ユーザー・コミュニティーを、現在より大規模な新しいハードウェア・サーバー群に整理統合します。DPARの数もまとめる予定です。見積もりを検証するために、既存のLotus Notesユーザー・コミュニティーの約10％を新しいハードウェア上の新規DPARに移行したパイロット環境を設定しました。

ユーザー・コミュニティーから対象とした10％を新しいDPAR上に移行した後、このユーザーは全ユーザー・コミュニティーのCPUリソース全体のほぼ50％を使用していることがわかりました。何が起こっているかを理解するために、既存のすべてのDPARと新たに作成したDPARからデータを取り込んで比較しました。

表2に、このデータを分析した結果を示します。2番目の列は、新たに統合したDPARの分析です。3番目の列はユーザー全体90％が残る元のDPARの分析です。元のDPARはLotus Dominoの旧リリースが稼働しているため、15分間隔でアクティブなユーザー数のデータは使用できません。

これを見る限り、新たに統合されたDPARでのユーザーの使用量は、元のDPARと比べてかなり多くなっています。2つのDPARのワークロードの比較は、4番目の列に示されています。ワークロードのこの差を理解するために、パイロットDPARに移行したユーザーを分析します。

まず、元のDPARでは、CPUとディスクの両方のリソースが逼迫していました。Lotus Notes管理者は、ディスクの問題を軽減するために、最大のデータベースを持つユーザーを新たに統合したDPARに移行する決定をしました。しかし、不用意に、全社のすべてのパワー・ユーザーとヘビー・ユーザーを新たに統合したDPARに集約してしまいました。このヘビー/パワー・ユーザーのグループをサポートするリソース使用量は、残りのユーザー・コミュニティーをサポートするリソース使用量よりもはるかに大きいものでした。

この現象のもう1つの兆候は、最近登録したユーザーまたはライト・ユーザーは元のDPARの1つに配置されているということです。この単独のDPARの分析は、5番目の列に示しています。このサーバーと新たに統合したDPARを比較すると、結果(6番目の列)の差は劇的とさえ言えます。

このDPARからパイロット・ユーザーを移行していた場合、新しいDPAR上でまったく異なるCPU使用量の曲線を描いていたはずです。この場合、このパイロット・ユーザーのグループは予測した量と比べてあまりCPUを使用していないのに、なぜこれほど多くのCPUの規模を見積もったのかと、疑問に思っていたことでしょう。

ここでポイントとなるのは、これらのグループのユーザー(ヘビー/パワー・ユーザー、あるいはライト・ユーザー)のいずれも、単独ではユーザー・コミュニティー全体の予測としては不正確になるということです。これが、同じクライアントで同じ数のユーザーを持つDPARでも、リソース使用率がまったく異なる可能性がある理由です。

また、旧DPARには潜在的なワークロードがありました。DPARからの応答時間が悪化していたため、ユーザーは極力DPARを使用しないようにしていました。しかし、新しいDPARへの移行後、ユーザーが応答時間の改善に気付くと、送信するメールの量が増えました。さらに、既存のDPARでも、応答時間が改善されて残りのユーザーの使用量が上がったため、ワークロードが増加しました。

既存のサーバーを調査する場合、現在リソースの制約がないかどうかを判断する必要があります。そのサーバーに対する潜在的な要求は、制約が取り除かれた後で明らかになるからです。

見積もりのサンプル演習

このサンプル演習で、一定のユーザー群をサポートするために必要なハードウェア・リソース量に、ワークロード定義がどれほど大きな影響を与えるかを理解することができます。これは見積もりの例ですが、IBMの見積もりツールでは、導き出されたベンチマーク・データのみに頼るのではなく、お客様と社内の両方の実稼働環境からの分析とフィードバックもより所にしています。

メモ： このサンプルは、説明のみを目的としています。この見積もりは、特定のプラットフォーム上でのLotus Dominoの特定のリリースに適用することを意図したものではありません。

登録された10,000ユーザー全員がクライアントとしてLotus Notesを使用していると仮定します。ユーザーの20％は、15分間隔でアクティブです（ミディアム・ユーザーとして分類されます）。トランザクション・ログとウィルス・スキャンは有効になっています。これ以外のアドイン・タスクまたはサード・パーティー製品は、この最初の見積もりでは稼働していません。この情報を基に、ユーザー・コミュニティーをサポートするために、単一エンジンのプロセッサーの97％を必要とすると予測します。これではワークロードの瞬間的な急増に対応する余地がほとんどないため、CPUを2つ持つボックスの2番目のエンジンを割り当てて余裕を持たせると、予測される使用率は50％となります。

登録ユーザーのうち、アクティブ・ユーザーの割合を20％から30％に増やします。これは、一見小さい変更に思われますが、実際には全体のワークロード要件を50％増大させます。この結果、予測されるCPU使用率は2Wayボックスでは76％、3Wayボックスでは52％になります。

ここで、すべてのユーザーをミディアム・ユーザーからヘビー・ユーザーに変更すると、予測されるCPU使用率は4Wayボックスでは77％、5Wayボックスでは62％になります。次に、全ユーザーの100％が無計画な不定期の複製でクラスタリングされるよう、クラスタリングを追加します。これにより、予測されるCPU使用率は5Wayボックスでは81％、6Wayボックスでは68％になります。次に、ユーザーの25％をLotus NotesからHTTP/Lotus Domino Web Accessに移行します。これにより、予測されるCPU使用率は8Wayボックスでは82％、9Wayボックスでは74％になります。

この簡単な例は、ユーザーが実行するクライアント、ワークロード、追加機能を変更するだけで、同じ10,000ユーザーに対してリソース使用率がどれほど変動するかを示しています。サポートするユーザー数は同じでも、「簡単な」変更を加えるだけで、1Wayボックスから9Wayボックスまで変化しました。これは極端な例だと思われるかもしれませんが、ご使用のDPARでもこのような変化がゆっくり進行する可能性はあります。ユーザーのアクティビティーが複雑さを増したりLotus Dominoの機能に精通したりする、ユーザーが異なるプロトコル/クライアントに切り替える、DPARの管理方法を変える、といった理由で、リソース使用量は影響を受けます。

上に戻る

まとめ

要約すると、DPAR上の登録ユーザー数やアクティブ・ユーザー数ではなく、ユーザーのワークロードの量に基づいて、DPARの規模を見積もる必要があります。少数のパワー・ユーザーやヘビー・ユーザーが、サーバーのリソースを消費してパフォーマンスの問題を引き起す一方で、同じサーバーでもっと多くのライト・ユーザーやミディアム・ユーザーをサポートできる可能性があります。

DPARのリソースを予測し、将来の見積もりをするときには、ユーザー全体を代表するサンプルを選択することが重要です。個々のDPARは見積もりの予測と違うこともありますが、予測する見積もりがコミュニティー全体に適合しているかどうかを把握するために、すべてのDPARの全体の使用量を調べる必要があります。

DPARをモニターし、見積もりの予測に対して、実際のワークロードとリソースの使用量を関連付ける必要があります。ワークロードとリソース使用量がどの程度予測と異なるかを理解すると、現在のサーバーが現在の環境をどのくらいの期間サポートできるかを予測できるようになります。ユーザーのワークロードと傾向を掴めるようになると、次回のサーバーの見積もりがいっそう適切になります。

参考文献

学ぶために

• developerWorks Japan: Lotus: Lotusの日本の技術情報サイトです
  
  
• developerWorks: Lotus(US) : Lotusの英語の技術情報サイトです
  
  
• developerWorksのLotus記事はこちらからご覧になれます。Lotus Domino 7 on the IBM zSeries(US)
  
  
• developerWorksのLotus記事はこちらからご覧になれます。Lotus Notes の大きなメール・ファイルに対するベスト・プラクティス
  
  
• developerWorksのLotus記事はこちらからご覧いただけます。IBMのプロダクション環境における pSeriesサーバーでのLotus Dominoのパフォーマンス
  
  
• developerWorksのLotus記事はこちらからご覧いただけます。Lotus Domino 7.0の新機能
  
  
• developerWorksの記事はこちらからご覧いただけます。Lotus Performance(US)
  
  

製品や技術を入手するために

• developerWorksより trial version of Lotus Domino 7(US) がダウンロードできます。
  
  
• developerWorksより trial version of Lotus Notes 7(US) がダウンロードできます。
  
  

議論するために

• ディスカッション・フォーラムにご参加ください。Participate in the discussion forum (US)
  
  
• developerWorks ブログ（US） を通してdeveloperWorksコミュニティーにご参加ください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• 「どうしてこの設定にしたのか」
• 見積もりに影響を与える要素
• サーバーの管理方法
• クライアント・タイプ
• ユーザーは何をするか
• 成長
• サーバーのモニター
• Statrep.nsfのデータの分析
• ケース・スタディー： サーバー統合の見積もり
• まとめ
• 参考文献
• 著者について
• コメント