IBM Lotus Dominoサーバー上の データベース数の影響 （メンテナンスを考慮したユーザー登録について） IBM Software Group
by user
Comments
Transcript
IBM Lotus Dominoサーバー上の データベース数の影響 （メンテナンスを考慮したユーザー登録について） IBM Software Group
® IBM Software Group IBM Lotus Dominoサーバー上の データベース数の影響 （メンテナンスを考慮したユーザー登録について） IBM Software Group | Lotus software 特記事項 本資料の記載内容は、正式な IBM のテストやレビューを受けておりません。 内容について、できる限り正確を期すよう努めてはおりますが、いかなる明示 または暗黙の保証も責任も負いかねます。本資料の情報は、使用先の責任 において使用されるべきものであることを、あらかじめご了承ください。 掲載情報は不定期に変更されることもあります。他のメディア等に無断で転載 する事はご遠慮ください。 本資料の著作権は日本アイ・ビー・エムにあります。非営利目的の個人利用 の場合において、自由に使用してもかまいませんが、営利目的の使用は禁止 させていただきます。 IBM、AIX、WebSphere、Lotus、Lotus Domino、Lotus Notesは IBM Corporation の商標。 その他、記載された社名および製品名は、それぞれ各社の商標または登録商 標です。 2 IBM Software Group | Lotus software はじめに Lotus Dominoメールサーバーを構築するにあたり、まずはサーバーの ハードウェアを確定させます。この過程で、1サーバーに登録するユー ザー数を決定します。 サイジングでは、ベンチマークデータが重要視されています。 ベンチマークデータとは、Lotus Dominoサーバーが特定のハードウェア 上で何ユーザーのアクセスシナリオを処理出来たかの負荷テストの結果 です。 近年では、ハードウェア性能の向上により、6,000名を超えるような同時 アクセスが可能な負荷テスト結果もあります。 しかし、登録ユーザー数が増えるということは、サーバー上のメールデー タベース数が増えることを意味します。さらに近年では、ディスク容量の 増加に伴い、1データベースあたりの容量が増えてきた傾向もあります。 この資料では、ベンチマーク結果以外の側面を含め、1サーバーあたりに 登録するユーザー数、すなわちデータベース数の影響を記述します。 3 IBM Software Group | Lotus software 近年のベンチマークデータより(1) 例：NotesBenchコンソーシアム(http://www.notesbench.org/ )のレポートより R7.0 ReportのBy Company IBMより • • • 例：IBM System p5 560Q (POWER5+ 1.8GHz; 64GB RAM) パーティションサーバー4台にて測定 (R6iNotesシナリオ) ユーザー登録 110,000 人の環境にて、同時アクセス 55,000ユーザー − ( 1 Dominoサーバーあたり、約 13750 ユーザーの同時アクセス) developerWorks記事「Lotus Domino 7 サーバーパフォーマンス Part 1」 より (http://www.ibm.com/jp/software/lotus/developer/library/nd7-perform/index.html) 例： AIX p670 LPAR (Power4 1.4GHz x8 ; 32GB RAM) 1サーバーあたり、15,000ユーザーの同時アクセスが可能 最大限にチューニングされたハードウェア上のDomino 最大限にチューニングされたハードウェア上のDomino7では、1 7では、1サーバー サーバー あたり、10,000ユーザー以上もの同時アクセスが可能です あたり、10,000ユーザー以上もの同時アクセスが可能です 4 IBM Software Group | Lotus software 近年のベンチマークデータより(2) IBM社内で行った、Domino 7に対する計測参考値 p595 (POWER5 1.9GHz 4way, Memory 8GB) ESS-800：72.8GB×32(RAID 5) / 32GB Cache 2Gbps FiberChannel(IBM FC 2105)×16 AIX 5.3 / Domino 7.0.0 → R7Mailシナリオで 6,500 ユーザーの同時アクセスが可能 (*) NotesBenchコンソーシアムのデータは、最高のチューニングと潤沢なディ NotesBenchコンソーシアムのデータは、最高のチューニングと潤沢なディ スク装置を使い、システムの限界性能値を計測した数値です。 スク装置を使い、システムの限界性能値を計測した数値です。 一方、そうでないケースも、強力なエンタープライズ・ストレージなどを使う 一方、そうでないケースも、強力なエンタープライズ・ストレージなどを使う ことで、ある程度大規模な同時ユーザー数がサポート可能です。 ことで、ある程度大規模な同時ユーザー数がサポート可能です。 (*)このデータは参考値です 5 IBM Software Group | Lotus software ベンチマークデータを使ったサーバーのサイジング ユーザーアクセスのピーク時間帯の負荷を処理出来るかどうか ベンチマークデータを、「同時アクセスユーザー数」として参照 例： 2,000ユーザー登録、同時アクセス率50％の場合、ベンチマーク上、同時 アクセス1,000人が可能なハードウェアを利用すればよい。 実際には、様々な要素を考慮 1ユーザーあたりのシナリオ負荷（ヘビーユーザーかどうか、など） 実行タスク（アンチウイルスなど）、クラスタ構成、SSL利用・・・ 参考(英語) Sizing your IBM Lotus Domino mail servers http://www.ibm.com/developerworks/lotus/library/domino-mail-sizing/index.html では、しかし・・・ 登録ユーザー 10,000人 に対して、同時アクセスが 10％（1,000人）であるよう な環境に、潤沢なディスク容量だけ用意すれば、Dominoサーバー1台でよいの か。（＝1サーバー上に10,000DBが存在する構成でよいのか。） 6 IBM Software Group | Lotus software ベンチマーク結果だけでは考慮出来ない点 ベンチマークで測定しているもの ユーザー同時アクセス処理時の、サーバー負荷 主に、ユーザーの読み込み、書き込み、サーバーのメールルーティング処 理、データベースの索引更新など 日中のDominoメールサーバーのユーザー利用、ピーク時を 想定した負荷テスト ベンチマーク結果だけでは不足しているもの ユーザーアクセス以外のサーバーへの影響 • サーバーに配置されるデータベースの数 − ユーザーがメール処理する上でのパフォーマンスはクリア − ユーザーのメール処理以外の影響がベンチマークでは不明 夜間・休日のメンテナンス時間など、考慮点はないか 7 IBM Software Group | Lotus software Dominoサーバー上のデータベース数の影響 製品仕様としては、データベース数に上限はない。円滑な運用が出来る数が上限 夜間、休日のメンテナンスタスク • • • • 夜間、休日など、オフピーク時にデータベースに実行するメンテナンスタスクの処理時間 主にupdall, compact やバックアップ処理など 実行速度は、ハードウェア能力（特にディスク処理速度）や、データベースの文書数にも依存 定期的な自動再起動を行っている場合、再起動処理までにメンテナンスタスクが終了しない とその後の処理がスキップされたまま再起動されるため、以降のデータベースのメンテナン スが全く行われない 移行時、アップグレード時などのメンテナンスタスク • • 主に convert や updall –r -x、 compact (-c) など 移行作業時間や移行時のシステム停止時間へも影響 サーバークラッシュ時の復旧速度 • • • サーバークラッシュ後の起動時に、開いていたデータベースへ整合性チェックが自動実行 整合性チェック処理が終了するまで、対象データベースが開けない データベースが多いことは、クラッシュ時の復旧速度への影響も意味する その他 • 8 同時アクセスがない場合も、インバウンド受信メールの配信処理の影響など IBM Software Group | Lotus software Dominoサーバーへの、大量ユーザー登録の考え方 まずはベンチマーク結果などを参考にしたサイジング 同時アクセスのピークを意識したサイジングを実施する 結果的に、1台への登録ユーザー数（＝データベース数）が非常に多くなった場合は、 ピーク時以外のことも考慮が必要 • • 「非常に多い」の数は、ハードウェア環境や利用形態などに依存 AIX環境での大規模事例として、例えば1 Dominoサーバーあたり2,000-3,000 ユーザー程度の登録を目安にしているケースなどがある DB数が多すぎる場合は、パーティションサーバーの有効活用 1つのOS上に複数のDominoサーバー（パーティションサーバー）を起動し、1 Dominoサーバーあたりのデータベース数を減らす CPU、メモリは共有するが、物理ディスク領域をパーティション単位に用意することで、 メンテナンスタスク処理のボトルネックとなるディスク負荷を分散させることが可能 メンテナンスタスクのスケジュールもサーバーごとに分散が出来る。また、複数の サーバー上のタスクが同時に実行することになった場合も、利用する物理ディスクが 分散していることで、処理時間（パフォーマンス）の影響を最小化出来る 9 IBM Software Group | Lotus software 主なメンテナンスタスク(1) Designタスク DBの設計をテンプレートに基づく最新のものにする。 運用方針次第だが、必ずしも毎日実施する必要はない。 デフォルトでは、notes.ini のServerTasksAt1に設定されており、夜1時に実行 Catalogタスク DBの情報を取得する。DB運用のため、定期的に実行することを推奨。 DBあたりの実行速度は、DBサイズにかかわらずほぼ同じ デフォルトでは、notes.ini のServerTasksAt1に設定されており、夜1時に実行 Statlogタスク DBの情報を取得する。DB運用のため、定期的に実行することを推奨。 DBあたりの実行速度は、DBサイズにかかわらずほぼ同じ デフォルトでは、notes.ini のServerTasksAt5に設定されており、夜5時に実行 10 IBM Software Group | Lotus software 主なメンテナンスタスク(2) Compactタスク データベースの未使用領域を開放し、データベースサイズを減少する 定期的に実施することで、データベースの使用率を維持することが可能。デフォルトでは実行さ れないため、プログラム文書などにて設定が必要。 -s オプションを使うことで、未使用領域が多いデータベースのみの実効が可能。また、-cオプ ション（オフライン圧縮）を利用した場合、データベースを新規ファイルとして再作成するためデー タベースの安定化につながる Fixupタスク 破損したデータベースの修復を行う デフォルトでは定期的に実行されない。定期実行することでデータベースの破損による悪影響 の予防になる。 Updallタスク ビュー、全文索引の保守（更新・再作成）を行う デフォルトでは深夜2時に実行。ビュー、全文索引の更新のためには必須。 -R , -X オプションを使うことで、ビュー、全文索引の再構築を行う。これは破損予防に有効。た だし、データベースのビューの数・構造・文書数によって実行時間に大きく影響がある。 11 IBM Software Group | Lotus software メンテナンスタスクまとめ 12 design catalog statlog compact fixup updall デフォルト 1時 1時 5時 なし なし 2時 必要性 必須ではない DB管理のた めに推奨 DB管理のた めに推奨 DBサイズ管 理のために 必須 DB破損予防 のために必 須 ビュー保守の ため必須 1DBあたりの 実行速度 DBの設計に 依存 DBに依存せ ず一定 DBに依存せ ず一定 主にDBの文 書数、サイズ に依存 主にDBの文 書数、サイズ に依存 主にDBの文 書数、ビュー の数、設計に 依存 その他 実施しない場合、 設計変更時に 管理者が手動 実行させる必要 あり -sオプションを 使った実行時間 の削減も可能。 -cオプションを 使うと時間はか かるが、DB破 損予防になる 定期的に実行 することでDBの 破損予防、破損 検知になる ビュー、全文索 引の更新のた め必要 - r , -x オプショ ンは時間は非 常にかかるが、 ビュー、全文索 引破損防止に なる。 IBM Software Group | Lotus software メンテナンスタスク Hint & Tips メンテナンスタスクスケジュールの決定 ハードウェア性能やデータベースの中身（文書数・サイズなど）にも大きく依存する ため、実データで実測の上でプランニングが最も推奨されます。 基本的にはデフォルトを中心とした考えでよく、compact –s タスクのタイミングを検 討します。また、安定化を重視する場合、fixup や、 updall –r -x 、 compact –c の 定期実行スケジュールを検討します。 本番運用開始後、log.nsf もしくはコンソールログを確認し、1サイクルの処理時間 を確認しておくことを強く推奨します。 目標とする実行時間に対して、実際のタスク実行時間が長すぎる場合は、見直し が必要です。このとき、インダイレクトファイル(.ind)を利用して、実行対象データ ベースをコントロールし、実行時間を調整することも可能です。 サーバーの定期再起動のタイミングに注意が必要です。メンテナンスタスク処理が 終了する前に再起動が定期的にかかると、特定のデータベースにはその処理が 毎回スキップされることになります。 Catalog, Statlogなど文書数に影響しないタスクは、経験的に、1秒/データベース で見積もることがおおよそ可能です。（ハードウェア性能による前後はあります） 13 IBM Software Group | Lotus software （参考）メンテナンスタスクにかかる時間の実例 データの状況や他の処理との並行同時状況にも依存します。あくまでの以下の所要時間は参考程度にして下さい 14 事例A 事例B サーバーOS Windows 2003 Windows 2003 Dominoリリース Lotus Domino 6.5.x Lotus Domino 6.5.x データベース数（登録ユー ザー数） 2500DB程度 2000DB程度 Updall の実行時間 2時間程度 - Updall –R の実行時間 5時間程度 9時間30分程度 Fixup の実行時間 3時間30分程度 3時間30分程度 Compact の実行時間 3時間程度(-s 5) 18時間程度 (full) Statlog の実行時間 50分程度 40分程度 その他 CPU : 4way 1DB平均100MB程度 CPU :1way IBM Software Group | Lotus software (参考) notes.ini とプログラム文書 メンテナンスタスクを定期的に実行する方法 notes.iniの ServerTasksAt[n] パラメータ • 例：ServerTasksAt2=Updall − 「毎日、2:00に updall タスクが起動する」 という設定 • 毎日実行するタスクを記述 Dominoディレクトリのプログラム文書 • 曜日単位での設定、1分単位での設定が可能 プログラム文書の例 15 IBM Software Group | Lotus software (参考)インダイレクトファイル (.ind) インダイレクトファイル 処理対象のディレクトリやデータベース名を一行ずつ記載したテキストファイル 拡張子は .ind として設定 実行例： • load compact weekly.ind プログラム文書と組み合わせることで、柔軟な運用スケジュールを組むことも 可能 • DB数が多く、運用スケジュールに調整が必要な場合など SALES.NSF DEV.NSF SALES¥USER1.NSF SALES¥NEW 例：weekly.indの中身 16 IBM Software Group | Lotus software データベース数に関するまとめ サイジングとサーバーへのユーザー登録について 基本的にはベンチマークデータから導かれる、同時アクセス可能数をベース とした、登録ユーザー数の考慮 同時アクセス率が低い場合など、データベース数が非常に多くなってしまう 場合は、規模にあわせてパーティションサーバーなどで分割する 定期的な運用の考慮 メンテナンスタスクの実行スケジュールを要検討 • その環境における現実的なスケジュールを作成するためには、実デー タでの実測も重要 運用開始後の実行状況の確認、および調整 移行時にも注意 ユーザー数（＝データベース数）が多い場合、移行時のメンテナンス処理に 時間がかかる 停止可能な時間帯に処理が終わるよう、対象ハードウェアで実データサンプ ルを使っての事前のプランニングが重要 17 IBM Software Group | Lotus software （補足）サーバー安定化のためのヒント Title: Title: Doc Doc#:#: URL: URL: Lotus LotusDomino Dominoserver servermaintenance maintenancetips tips 1248830 1248830 http://www.ibm.com/support/docview.wss?rs=203&uid=swg21248830 http://www.ibm.com/support/docview.wss?rs=203&uid=swg21248830 上記Technote(英語)では、月次のサーバー再起動を安定化のために推 奨しております。 サーバーシャットダウン時の、names.nsf, log.nsf, cldbdir.nsf へのメン テナンスタスク実行 (compact, updall , fixup) を推奨しています。 スケジュール次第ですが、 updall –r , compact –c を推奨します。 log.nsf は、サーバー終了時に一度別ディレクトリなどへ mv する方法もあり ます。（サーバー再起動時に自動的に新規にlog.ntfから再作成される） 18