クラウド時代の 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 Noｔes、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,000～2,000 Dominoサーバー設定 細かいチューニングは行わない メールDB ○ DBサイズだけでなく文書もなるべく実環境に近く × 500MBの添付ファイルを貼った文書を数文書 – H/W・S/W構成は１パターン バージョン等による比較は目的としない – 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構成は１パターン ・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構成は１パターン ・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構成は１パターン ・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構成は１パターン ・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構成は１パターン ・H/Wリソースは潤沢に Server.load「Initialization」 シナリオで生成できますが、時間がかかるため、今回は 以下のようにして作成しました。 1. メールDBを1つ作成（手動） – メールテンプレートから新規作成 2. １文書を作成（手動） – 適当なサイズになるようにテキストやリンクを記入 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