2014_nd9_bigsizemail_test.pdf

クラウド時代の IBM Dominoメール
2014年10月20日 Technical Update Workshop
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
ソーシャル&モバイル 高橋靖子
© 2014 IBM Corporation
© IBM Corporation 2014. All Rights Reserved.
ワークショップ、セッション、および資料は、IBMまたはセッション発表者によって準備され、それぞれ独自の見解を反映したものです。それらは情報提供の
目的のみで提供されており、いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく、またそのような結果を生むものでもありま
せん。本プレゼンテーションに含まれている情報については、完全性と正確性を帰するよう努力しましたが、「現状のまま」提供され、明示または暗示にかか
わらずいかなる保証も伴わないものとします。本プレゼンテーションまたはその他の資料の使用によって、あるいはその他の関連によって、いかなる損害が生
じた場合も、IBMは責任を負わないものとします。 本プレゼンテーションに含まれている内容は、IBMまたはそのサプライヤーやライセンス交付者からいかな
る保証または表明を引きだすことを意図したものでも、IBMソフトウェアの使用を規定する適用ライセンス契約の条項を変更することを意図したものでもなく
、またそのような結果を生むものでもありません。
本プレゼンテーションでIBM製品、プログラム、またはサービスに言及していても、IBMが営業活動を行っているすべての国でそれらが使用可能であることを
暗示するものではありません。本プレゼンテーションで言及している製品リリース日付や製品機能は、市場機会またはその他の要因に基づいてIBM独自の決定
権をもっていつでも変更できるものとし、いかなる方法においても将来の製品または機能が使用可能になると確約することを意図したものではありません。本
資料に含まれている内容は、参加者が開始する活動によって特定の販売、売上高の向上、またはその他の結果が生じると述べる、または暗示することを意図し
たものでも、またそのような結果を生むものでもありません。
パフォーマンスは、管理された環境において標準的なIBMベンチマークを使用した測定と予測に基づいています。ユーザーが経験する実際のスループットやパ
フォーマンスは、ユーザーのジョブ・ストリームにおけるマルチプログラミングの量、入出力構成、ストレージ構成、および処理されるワークロードなどの考
慮事項を含む、数多くの要因に応じて変化します。したがって、個々のユーザーがここで述べられているものと同様の結果を得られると確約するものではあり
ません。
記述されているすべてのお客様事例は、それらのお客様がどのようにIBM製品を使用したか、またそれらのお客様が達成した結果の実例として示されたもので
す。実際の環境コストおよびパフォーマンス特性は、お客様ごとに異なる場合があります。
IBM、IBM ロゴ、ibm.com、IBM Notes、IBM Domino、IBM iNotes、IBM Sametime は、世界の多くの国で登録されたInternational Business Machines
Corporationの商標です。
他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。
現時点での IBM の商標リストについては、www.ibm.com/legal/copytrade.shtmlをご覧ください。
他の会社名、製品名およびサービス名などはそれぞれ各社の商標です。
2
© 2014 IBM Corporation
目次
• 背景
• ベンチマーク検証方針
• ベンチマーク検証環境
• ベンチマーク検証シナリオ
• ベンチマーク検証結果
• まとめ
このセッションの目標
大容量メールDB要件に対するIBM Dominoメールサーバー(オンプレミス)
構成を検討できるようになる
3
© 2014 IBM Corporation
目次
• 背景
–メールボックスの制限容量の拡大
–IBM Dominoでの大容量メールサーバー構成
• ベンチマーク検証方針
• ベンチマーク検証環境
• ベンチマーク検証シナリオ
• ベンチマーク検証結果
• まとめ
4
© 2014 IBM Corporation
背景:メールボックスの制限容量の拡大
昔は数十MB 数百MBに 数GB、それ以上へ
クラウド普及に伴い
容量拡大の流れが加速
(参考)IBM SmarterCloud Notes
では 1人25GB利用可
5
© 2014 IBM Corporation
背景:IBM Dominoでの大容量メールサーバー構成
• アーカイブを併用
–メールDBサイズの最大は運用実績で500MB程度
–それ以上はアーカイブDBを併用
メール
DB
+
アーカイブ
DB
•アーカイブしない構成
–例えば5GBのメールDBの場合、
ユーザーレスポンスは大丈夫?
メンテナンスタスクはどれくらい
時間がかかる?
?
メールDB
ベンチマーク検証
6
© 2014 IBM Corporation
目次
• 背景
• ベンチマーク検証方針
–検証環境方針
–検証シナリオ方針
• ベンチマーク検証環境
• ベンチマーク検証シナリオ
• ベンチマーク検証結果
• まとめ
7
© 2014 IBM Corporation
IBM Domino 9 ベンチマーク検証方針 (1/2)
基本方針:「サーバー構成検討・性能見積の参考となるデータ取得を目的とする」
•
検証環境方針
– 実環境でありそうなS/W構成(限界値の検証ではない)
 ユーザー数
1サーバーのユーザー数は1,000~2,000
 Dominoサーバー設定 細かいチューニングは行わない
 メールDB
○ DBサイズだけでなく文書もなるべく実環境に近く
× 500MBの添付ファイルを貼った文書を数文書
– H/W・S/W構成は1パターン
 バージョン等による比較は目的としない
– H/Wリソースは潤沢に
 H/Wがボトルネックで結果が悪かった場合、
S/Wとしての限界なのか、H/Wリソースを積めば対応可能なのか、判別できない。
 実際に必要なリソースは、リソース使用率などから推察
8
© 2014 IBM Corporation
IBM Domino 9 ベンチマーク検証方針 (2/2)
•
検証シナリオ方針
– ユーザーアクセスの負荷シミュレータはServer.loadの主に iNotesシナリオ
を使用
 一般的にWebアクセスのほうがNotesクライアントアクセスよりも負荷が高い
→ iNotes シナリオで大丈夫ならNotesでも大丈夫、と考えられる
– メンテナンスタスクは通常運用を想定
 コマンドは、日次や週次運用でよく使われるタスクを実施
Updall、Updall –R、Compact、Compact –c
 移行時などに行う convert や ODSアップグレードは対象外
ベンチマークの目的を予め明確化しておくことは重要
→構成やシナリオ検討の指針、結果の評価・考察の前提に。
9
© 2014 IBM Corporation
目次
• 背景
• ベンチマーク検証方針
• ベンチマーク検証環境
• ベンチマーク検証シナリオ
• ベンチマーク検証結果
• まとめ
10
© 2014 IBM Corporation
検証環境方針
・実環境でありそうなS/W構成
・H/W、S/W構成は1パターン
・H/Wリソースは潤沢に
H/W、S/W構成
Dominoサーバー
Domino 9.0.1 64bit +日本語LP
Windows 2012 Server R2
Standard Edition 64bit
CPU:Quad Core Xeon 5504
2.0GHz x 2
メモリ:12GB
Server. load
Domino Administrator 9.0.1
Windows 2008 Server R2
Standard Edition 64bit
11
ディスク
C:
600GB HDD
D:
600GB HDD x15本 RAID0
SA-SCSI 15K RPM
Server. load
Domino Administrator 9.0.1
Windows 2008 Server R2
Standard Edition 64bit
© 2014 IBM Corporation
検証環境方針
・実環境でありそうなS/W構成
・H/W、S/W構成は1パターン
・H/Wリソースは潤沢に
H/W構成補足
• クラウド(IaaS)環境「Softlayer」上に構築
–一般的にIaaSといえば仮想サーバーですが、Softlayerでは物理サーバーも選択可能。
–今回、十分なディスク性能を確保するため、物理サーバーを使用しました。
ベアメタル・サーバ
(物理サーバー)
ライベート・クラウド環境
(仮想サーバー:占有)
パブリック・クラウド環境
(仮想サーバー:共有)
–ネットワークがボトルネックにならないよう、シミュレータ端末も同一データセンターに
構成
• ディスクは、以下の観点によりRAID0で構成
–今回の検証で利用可能なHDD数に制約があり、RAID5等にすることでユーザー数やDBサ
イズが減ってしまうことの回避
–H/Wボトルネックとなることの回避
12
© 2014 IBM Corporation
Dominoサーバーの環境設定
検証環境方針
・実環境でありそうなS/W構成
・H/W、S/W構成は1パターン
・H/Wリソースは潤沢に
• 登録ユーザー数は 2,000
–メールDB 5GBの時のみ 1,300ユーザー(ディスク容量の制約のため)
• サーバー設定は、基本的にデフォルトもしくは一般的な設定値
–DAOS無効
–トランザクションログ無効
–Mail.box の数は 2
–HTTP のスレッド数は 80
–HTTP ログはテキスト形式で取得
• メモリのチューニングは行わず
–NSF_Buffer_Pool_Size_MB などの設定はデフォルト通り
13
© 2014 IBM Corporation
利用したメールDB
検証環境方針
・実環境でありそうなS/W構成
・H/W、S/W構成は1パターン
・H/Wリソースは潤沢に
• メールテンプレート
–製品標準メールテンプレート(9.0.1) 日本語版
• メールDBのサイズと中身
–1GB あたり、15,000 文書を標準と定義
実利用のメールファイルの統計値より算出
–2GB:30,000文書
–3GB:45,000文書
–5GB:75,000文書
14
© 2014 IBM Corporation
(参考)テスト用メールDB生成方法
•
検証環境方針
・実環境でありそうなS/W構成
・H/W、S/W構成は1パターン
・H/Wリソースは潤沢に
Server.load「Initialization」 シナリオで生成できますが、時間がかかるため、今回は
以下のようにして作成しました。
1. メールDBを1つ作成(手動)
–
メールテンプレートから新規作成
2. 1文書を作成(手動)
–
適当なサイズになるようにテキストやリンクを記入
3. 文書をコピー(LotusScript)
4. 「NotesBench」フォルダを作成、ACLでデフォルト管理者に設定(手動)
–
–
負荷シナリオの中で「フォルダに移動する」処理が行われます。
その際のフォルダ名が「NotesBench」であるため、作成しておく必要があります。
「Initialization」シナリオで生成する場合は、Initializationの処理にて作成されます。
5. DBをOSコピー(バッチ)
6. レプリカIDをセット(Server.loadカスタムスクリプト)
–
–
15
OSコピーではレプリカIDが同一。レプリカIDが同一であることの、テストへの明確な影響は確認
されていませんが、念のため変更しました。
Server.loadの「SetReplID」コマンドを実行するスクリプトを作成して実行。
© 2014 IBM Corporation
目次
• 背景
• ベンチマーク検証方針
• ベンチマーク検証環境
• ベンチマーク検証シナリオ
–ユーザーアクセスの検証
–メンテナンスタスクの検証
• ベンチマーク検証結果
• まとめ
16
© 2014 IBM Corporation
ユーザーアクセスの検証:シミュレータ (1/2)
• Server.load標準のシナリオを使用
–「DWA85」=iNotes および「N85Mail」=Notesメール
 いずれも「9 」のシナリオはなく、「85」を使用しました
–約15分間で以下の操作を行うシミュレーションを繰り返します
(“2回に1回”とある場合は、30分に1回行う操作となります)
5文書を読む
2 文書を削除
1つのメールに返信 (2回に1回)
1つのメールを送信。宛先は 1 人。
1つのメールを送信。宛先は 3 人。(2回に1回)
1文書をフォルダに移動
1つの予定を作成、 1つの会議招集を送信、会議招集に返信(24回に1回)
17
© 2014 IBM Corporation
ユーザーアクセスの検証:シミュレータ (2/2)
–Server.loadの
パラメータも
基本的にデフォルト
18
© 2014 IBM Corporation
ユーザーアクセスの検証:ケース一覧
ケース# ユーザー数
1
2
3
4
5
2,000
2,000
2,000
2,000
1,300
シナリオ
DWA85
DWA85
N85Mail
DWA85
DWA85
DBサイズ
2GB
2GB
2GB
3GB
5GB
文書数
30,000
30,000
30,000
45,000
75,000
Inbox
ODS
文書数
30,000
52
5,000
52
30,000
52
45,000
43
75,000
52
• ケース#1, 5 基本ケース:メールDBサイズ 2GB, 5GB をターゲット
• ケース#2 Inboxの文書数で大きな差があるか検証
• ケース#3 念のためNotesメールシナリオも確認
• ケース#4 ODSで大きな差があるか検証
19
© 2014 IBM Corporation
メンテナンスタスクの検証:ケース一覧
• 対象DB
–ベンチマーク実施後のメールDBに対してメンテナンスタスクを実行
–ベンチマーク環境の全量ではなく各ケース100DBを対象
2プロセスの場合は50DBずつ、4プロセスの場合は25DBずつを並列処理
例えば2,000DBの場合は所要時間が20倍になると推察
•ケース一覧
対象DB
20
プロセス数
Updall
Updall -R
Compact
Compact -c
2GB:30,000文書
1
○
○
○
○
3GB:45,000文書
1
○
○
○
○
5GB:75,000文書
1
○
○
○
○
5GB:75,000文書
2
-
○
-
○
5GB:75,000文書
4
-
○
-
○
© 2014 IBM Corporation
目次
• 背景
• ベンチマーク検証方針
• ベンチマーク検証環境
• ベンチマーク検証シナリオ
• ベンチマーク検証結果
–ユーザーアクセスの検証
–メンテナンスタスクの検証
• まとめ
21
© 2014 IBM Corporation
ユーザーアクセスの検証:結果
•レスポンスタイム(msec)とリソース利用状況(10分間の平均)
ケース#
レスポンス
CPU
メモリ
タイム(msec) 使用率 空き容量
ディスク
Idle率 転送量KB/s
IOPS
IOPS/user
1
82 6.2% 6,136 MB
76%
4,271
311
0.16
2
67 6.3% 6,963 MB
88%
4,738
353
0.18
3
74 1.4% 4,580 MB
83%
3,798
321
0.16
4
92 6.7% 6,411 MB
50%
7,073
450
0.23
5
88 4.6% 8,498 MB
83%
2,709
210
0.16
※サーバーレスポンスであり、ユーザー体感レスポンスではありません
参考:ケース一覧(前述)
ケース#
22
ユーザー数
シナリオ
DBサイズ
文書数
Inbox文書数
ODS
1
2,000
DWA85
2GB
30,000
30,000
52
2
2,000
DWA85
2GB
30,000
5,000
52
3
2,000
N85Mail
2GB
30,000
30,000
52
4
2,000
DWA85
3GB
45,000
45,000
43
5
1,300
DWA85
5GB
75,000
75,000
52
© 2014 IBM Corporation
ユーザーアクセスの検証:結果考察 (1/3)
• いずれのケースも良好なレスポンスタイム
–閾値とされる msec
200msec を
200
下回りました。
【レスポンスタイム】
100
0
1 2 3 4 5 ケース#
–Inbox(受信ボックス)の文書数によってレスポンスタイムに若干の影響(ケース#1, 2)
が見られましたが、全体的に今回の結果から見ると、大きな影響はなさそうです。
適切なH/Wリソースがあれば、1人 5GB の構成でも適切なレスポンスタイム
23
© 2014 IBM Corporation
ユーザーアクセスの検証:結果考察 (2/3)
•ディスクI/O性能見積の指標として「ユーザー数 x 0.25」IOPS
–IBM DominoサーバーにおいてディスクI/O性能は重要
–見積の指標としては IOPS が有用
IOPS/user
【IOPS/user】
0.25
0.2
0.15
0.1
0.05
0
1 2 3 4 5 ケース#
「ユーザー数 x 0.25」IOPS のディスクI/O性能を確保することをお勧め
24
© 2014 IBM Corporation
ユーザーアクセスの検証:結果考察 (3/3)
•物理メモリは8GB以上が好ましい
–過去の負荷テストにおいて、物理メモリ4GBの環境と8GBの環境(他の条件は同一)で
、ディスクI/O負荷に差が見られました。
 Domino 8.0.1 32bit、AIX環境における結果。いずれも2400user
搭載
メモリ
4GB
シナリオ
ODS
N8MailBasic
48
8GB
N8MailBasic
48
設計圧縮
有効
ディスク
転送量(KB/s)
8,633
ディスク
IO数(IO/s)
630
有効
6,678
476
IOPS/user
0.26
0.20
–今回12GBの環境で IOPS/user は上記8GBのケースに近いと言えます。
–OSによってリソースの使い方に違いはありますが、いずれにしても物理メモリが十分な
環境では、ファイルキャッシュによってディスクI/Oが軽減すると推測されます。
ユーザー数やメールサイズが大きい環境では、物理メモリ8GB以上をお勧め
25
© 2014 IBM Corporation
メンテナンスタスクの検証:結果 (1/2)
• Updall
対象DB
※環境や条件によって結果には差異が生じますので、参考として捉えてください
。
プロセス数 所要時間(秒/DB)
2GB:30,000文書
1
3GB:45,000文書
1
5GB:75,000文書
1
0.61秒
0.56秒
オプションなしUpdallは、全体の所要時間が
1,2分程度と短く、パフォーマンスモニタが
1分間隔で有用なデータとならないため、リ
ソース利用状況については割愛します。
• Updall –R
対象DB
プロセス数 所要時間(秒/DB) CPU使用率 メモリ使用量 ディスクIdle率
2GB:30,000文書
1
26.14秒
6.9%
5,651MB
70.2%
3GB:45,000文書
1
38.13秒
7.0%
5,801MB
70.5%
5GB:75,000文書
1
59.65秒
7.7%
5,486MB
73.8%
5GB:75,000文書
2
34.96秒
13.1%
5,689MB
42.5%
5GB:75,000文書
4
21.94秒
21.3%
5,081MB
24.5%
–CPU使用率およびディスクIdle率は、タスク実行中の平均、
メモリ使用量は、処理中の空き容量の(最大値 - 最小値)を記載
26
© 2014 IBM Corporation
メンテナンスタスクの検証:結果 (2/2)
• Compact
対象DB
2GB:30,000文
書
3GB:45,000文
書
5GB:75,000文
• Compact -c 書
対象DB
2GB:30,000文
書
3GB:45,000文
書
5GB:75,000文
書
5GB:75,000文
書
5GB:75,000文
書
27
※環境や条件によって結果には差異が生じますので、参考として捉えてください
。
プロセス数 所要時間(秒/DB)
CPU使用率 メモリ使用量 ディスクIdle率
1
9.70秒
2.1%
1,170MB
18.0%
1
13.67秒
2.2%
1,201MB
17.0%
1
21.94秒
2.7%
プロセス数 所要時間(秒/DB)
-
16.4%
CPU使用率 メモリ使用量 ディスクIdle率
1
36.34秒
5.1%
1,341MB
46.7%
1
58.85秒
5.6%
1,165MB
52.5%
1
77.89秒
5.7%
1,455MB
51.4%
2
45.08秒
9.6%
2,957MB
27.2%
4
43.14秒
10.2%
2,240MB
2.0%
© 2014 IBM Corporation
メンテナンスタスクの検証:結果考察 (1/3)
シングルプロセスでの所要時間は、概ねDBサイズに比例
•
– 2GB、3GB、5GBのケース比較より
– ただし元となるデータより小さいサイズの場合、時間は多めに見てください
(例えば1GBなら2GBの半分の時間、とはなりません)
【DBサイズおよびシングルプロセスでのタスク所要時間/DB の比率】
比率
2.5
2
1.5
2GB
1
3GB
0.5
5GB
0
28
対象DB
DBサイズ Compact Compact –c Updall -R
© 2014 IBM Corporation
メンテナンスタスクの検証:結果考察 (2/3)
• マルチプロセス処理で、H/Wリソースがボトルネックになると、プロセス数を
増やしても時間短縮しない
タスク所要時間
(msec)
【プロセス数とタスク所要時間/DB】
90
– Compact –c
 プロセス数 2 と 4 で所要時間がほとんど同じ
 4プロセスのケースはディスクがボトルネックと見られる
– Updall –R
60
Compact -c
 プロセス増加に応じて所要時間が短縮
 ボトルネックが特に発生していない
Compact -c
30
Updall -R
0
1 2 4
プロセス数
対象DB プロセス
数
5GB
1
CPU
メモリ
使用率
使用量
5.7% 1,455MB
ディスク
Idle率
51.4%
5GB
2
9.6% 2,957MB
27.2%
5GB
4 10.2% 2,240MB
2.0%
H/Wリソースを十分に確保することは、メンテナンス処理でも有用
29
© 2014 IBM Corporation
メンテナンスタスクの検証:結果考察 (3/3)
•
運用スケジュール検討例:5GB x 1500 DB
– 平日:updall(日次)、compact(週次)
– 週末:updall –R、 compact –c (週次)
– 前述の結果から色付きセル箇所を基に所要時間を算出(単位:秒/DB)
対象DB




プロセス数
Updall
2GB:30,000文書
1
0.60秒
3GB:45,000文書
1
5GB:75,000文書
Compact
Updall -R
Compact –c
9.70秒
26.14秒
36.34秒
-
13.67秒
38.13秒
58.85秒
1
0.56秒
21.94秒
59.65秒
77.89秒
5GB:75,000文書
2
-
-
34.96秒
45.08秒
5GB:75,000文書
4
-
-
21.94秒
43.14秒
Updall
0.56秒 x 1500DB ≒ 0.2時間
Compact 21.94秒 x 1500DB ÷ 平日5days ≒ 1.8時間
Updall –R 21.94秒 x 1500DB ÷ 週末2days ≒ 4.6時間
Compact –c 43.14秒 x 1500DB ÷ 週末2days ≒ 9.4時間
平日 2時間
週末15時間
環境や要件によるがメンテナンスタスクもスケジュール可能なレベル
30
© 2014 IBM Corporation
目次
• 背景
• ベンチマーク検証方針
• ベンチマーク検証環境
• ベンチマーク検証シナリオ
• ベンチマーク検証結果
• まとめ
このセッションの目標
大容量メールDB要件に対するIBM Dominoメールサーバー(オンプレミス)
構成を検討できるようになる
31
© 2014 IBM Corporation
まとめ
• IBM Dominoサーバーで、数GBのメールDBのサービスは可能
– 十分なH/Wリソースは必要
見積指標「ディスクI/O:ユーザー数 x 0.25 IOPS」「メモリ:8GB」
– メンテナンスタスクはオプションや実行頻度、並列処理などを工夫して
運用スケジュールを組み立て
当検証データも参考に
• ベンチマーク検証実施の参考情報
– 予め検証の目的を明確化することが重要
 目的を基に環境やシナリオを決定
– クラウド環境の利用でパフォーマンスを事前検証しやすくなるのでは
 従来:サーバー構築するまで、パフォーマンス検証する環境がない
 クラウド利用:月額または日額で本番相当の環境を一時的に利用可能
32
© 2014 IBM Corporation
参考情報
IBM Domino関連:
• IBM Lotus Notes ユーザー向け IBM Lotus Domino 8.5 のパフォーマンス
http://www.ibm.com/developerworks/jp/lotus/library/domino85-performance/
• IBM Lotus Domino 8.5 サーバーパフォーマンス, part 2: iNotes パフォーマンス
http://www.ibm.com/developerworks/jp/lotus/library/domino85-inotes/
• IBM Lotus Domino 8.5 サーバーパフォーマンス, part 3: エンタープライズクラスター
メールパフォーマンス
http://www.ibm.com/developerworks/jp/lotus/library/domino85-cluster/
• Lotus Notes の大きなメール・ファイルに対するベスト・プラクティス
http://www.ibm.com/developerworks/jp/lotus/library/notes-mail-files/
Softlayer関連:
• http://www.softlayer.com/
• http://www.ibm.com/cloud-computing/jp/ja/softlayer.html
33
© 2014 IBM Corporation
Similar pages