ibm sametime ldap構成の hint & tips 報告資料 lotus sametime 8.5 以降では...

© 2014 IBM Corporation

IBM Sametime LDAP構成の Hint & Tips報告資料

2016年10月20日

| © 2014 IBM Corporation

Agenda1. はじめに2. 知っておくべき Sametime LDAP 構成の知識3. 設計・構築のヒント4. 運用のヒント5. パフォーマンスについて

2


はじめに■ 当資料では、LDAPサーバーとしてDomino LDAPを使用したSametime

環境を構築する際の Hint & Tips をまとめています。

■ 注意事項─ IBM Lotus Sametime 8.5 以降では WAS/DB2/SSCのインストールが前提となり、

⼀部の例外的な構成を除いて LDAP サーバーの導入が必要となりました。─ IBM Sametime 9.0.1 以降では LDAP サーバーの代替として、ネイティブDomino

ディレクトリーはユーザー管理⽤としてサポートされなくなりました。Sametimeサーバーの構成に関わらず LDAP サーバーが必須となります (ネイティブDominoディレクトリーを使⽤している場合には移⾏作業が必要です。製品マニュアルを参照してください)。

■ 参考資料─ [参考] IBM Sametime Limited Use 9.0 導入時の注意点と IBM Sametime Entry 8.5.2 以前の

リリースとの違いについてhttp://www-01.ibm.com/support/docview.wss?uid=swg21668277

─ [参考] IBM Sametime 9.0.1 今回のリリースの新機能http://www.ibm.com/support/knowledgecenter/ja/SSKTXQ_9.0.1/admin/overview/over_whatsnew.html

3

| © 2014 IBM Corporation4

知っておくべき Sametime LDAP構成の知識知っておくべき Sametime LDAP構成の知識


Domino LDAP のビュー検索と全⽂検索■ Domino LDAPの検索の仕組み

─ Domino LDAP サービスは、要求で指定された検索フィルターに応じて、ビュー検索または全⽂検索を実⾏します。

─ ビュー検索は全⽂検索より⾼速であり、全⽂検索はビュー検索の10倍以上の時間を要します。

─ 標準的なLDAP要求の場合には、ビュー検索で処理ができるようにビューの設計がされています。

■ ディレクトリ設計の注意点─ LDAPへの要求においてはフィルター項目として標準的なもの（sn, cn, mailなど）

を利⽤することが重要です。社員番号を検索対象として含める場合には cn フィールドに入れるようにします。社員番号フィールドをフィルターに組み込むと、DominoLDAP サーバーは全⽂検索でのユーザー検索を⾏います。

─ 事情により、ユーザー⽂書の任意のフィールドをフィルター項⽬として利⽤することがありますが、そのような場合は全⽂検索が実⾏され、スループットが低下する原因となります。ただし、LDAPサーバーに格納されたエントリー数があまり多くない場合にはその影響は限定的ですので、⼀概に全⽂検索を避けるべきとは⾔えません。

─ 検索ベースとして「o=」を設定すると、グループがヒットしなくなります。これはDomino LDAP サーバーの仕様によるものです。

5


Domino LDAP の並列処理について■ Domino LDAP の並列処理の仕組み

─ Domino LDAPでは、効率的に検索要求を処理するために、並列的に処理を⾏う仕組みを採用しています。これを実現するのがスレッドです。

─ スレッド数はサーバーが自動調整します。デフォルトの最大スレッド数は 40 ですが、notes.ini パラメーターのLDAPMaxWorkerThreadsにより調整可能です。ただし、最大数を引き上げても実際のスレッド数はサーバー側が調整する点は変わりません。

─ LDAPへの要求はいったんプールされたうえで、それらのスレッドに割り当てられて処理されます。つまり、要求はスレッドのキューに並ぶ形となります。

─ ひとつの要求処理が⻑い場合には、複数スレッドにまたがって処理される場合もあります。そうすることで、スループット時間 (要求の受理から応答までの実際かかった時間) が平準化されるようになっています。

■ スレッド調整の考え方─ スレッドの設定値を引き上げても Domino LDAP サーバーが適宜判断してスレッド数

を設定します。設定を変更しても実際のスレッド数に変化がみられない場合があります。─ スレッド数を引き上げても、CPUの処理能⼒に余裕がなければパフォーマンスは改善し

ません。まずは、デフォルト値で運用を開始し、サーバー統計情報やCPUの使⽤率に応じて、スレッド数を調整することをお勧めします。

※ パフォーマンスチューニングについては4章で詳しく説明しています。6


リソース⾒積もりのポイント一般的なDominoサーバーでは、CPUは2ないしは4 CPU、メモリは4GB(Domino 32-bit) ないしは8GB (Domino 64-bit) 程度を必要とします。Domino LDAPサーバーについては、次のような点を踏まえてリソース⾒積もりを⾏います。■ CPU

─ LDAPサーバーはビューの検索と全⽂検索を⾏うため、⽐較的 CPU を消費する傾向にあります。しかし、CPU の並列処理のリニアリティーには限界があるため、4 コア程度までが妥当です。

─ 4 コアより 8コアの⽅がより⾼い性能が出ますが、冗⻑性などの観点から 4 コア構成の OS を複数配置してクラスタリングする方が、全体設計のバランスとして望ましい場合が多いです。

■ ストレージ─ 検索データの殆どはキャッシュに⼊ってしまうため、あまり⾼速なストレージを投⼊

する必要性はありません。

■ メモリー─ 64-bit 版の Domino でも経験上 4 GB前後の消費で頭打ちとなりますので、通常の

Dominoサーバーと同様、8 GB程度のメモリがあれば問題ありません。7


ディレクトリ・アシスタントの設定（1/2）■ ディレクトリ・アシスタント（DA）の利⽤について

─ Domino サーバーをLDAPサーバーとして使った場合、参照されるデータはnames.nsf が基本です。

─ 別の names.nsf 相当のデータベースをディレクトリーとして参照させたい場合、DAを使用します。例）人事データからディレクトリーを作成した場合や、複数の names.nsf を統合させて作成したディレクトリーの場合など

■ ディレクトリ・アシスタント設定のポイント─ DAを設定すると、Domino は自動的に、names.nsf とDAに追加されたディレクト

リーを参照するようになります。そのため、names.nsf の中⾝は管理者のみとして、追加設定したディレクトリー内のエントリーと被らないようにする必要があります。

例）両ディレクトリーに Taro Yamada が存在した場合、Domino サーバーはnames.nsf を最初に参照するため、先に names.nsf の Taro Yamada を⾒つけます。

（認証が意図した通り⾏われなかったり、ユーザー検索結果として意図したものが返ってこない場合が発生します。）

8


ディレクトリ・アシスタントの設定（2/2）

9

■ ディレクトリ・アシスタント設定のポイント（つづき）─ names.nsf のデータが参照先として不要ならば、names.nsf を参照しないように設

定することを推奨します。da.nsf に names.nsf を設定し、このディレクトリを「無効」に設定します（下図参照）。これでローカルの names.nsf はLDAPサーバーとして参照しないようになります。

─ 「このドメインを利⽤可能にする対象」設定では、「Notes クライアントとインターネットの認証/許可」のみにチェックを入れ、「LDAP クライアント」のチェックは外します。LDAP クライアントとしてアクセスした場合には、多くの属性を返すことになり、処理時間がより⻑くなります。


設計・構築のヒント設計・構築のヒント


LDAPサーバーの構成について（1/2）■ Domino LDAPサーバー構成の注意点

─ IBM Sametime Community サーバーが稼動しているDominoサーバーでLDAPタスクを⽴ち上げ、その Community サーバー用の DominoサーバーをLDAPサーバーとすることはサポートされていません。(参考) IBM Sametime Community サーバーが稼働している Lotus Domino サーバーでのLDAP タスクの起動についてhttp://www-01.ibm.com/support/docview.wss?uid=swg21594752

─ その他のDominoサーバー（メールサーバー、アプリケーションサーバー等）上でLDAPタスクを⽴ち上げてLDAPサーバーとして使用することについても、パフォーマンス、および、運用（メンテナンス、バージョンアップやトラブル発生時の問題判別など）の観点からお勧めできません。例えばDominoアプリサーバーとLDAPサーバーを同居させた場合、アプリサーバーの障害時に、LDAPサービスにも影響が発生します。つまりアプリサーバーの障害がSametimeサービスにも影響が発生することになります。逆も同様で、LDAPサービスとしての障害発生時に、アプリサービスにも影響が生じることになります。

─ LDAPサーバーは別途専用のサーバーとして構築することを推奨します。─ 既存の Domino LDAP サーバーを Sametime 用に使用する場合には、ビジネスカー

ドに表示するデータの格納が許容されるかについて確認してください。企業全体のディレクトリーとして存在する LDAP では、一般的に格納するデータ項目が厳格に指定されていて、変更が容易ではない場合が存在します。Sametime のビジネス・カードに表示する内容 (写真を含む) 内容が格納されているか、追加可能であるかを確認してください。11


LDAPサーバーの構成について（2/2）■ Domino LDAP サーバーのDominoドメインについて

ドメインの構成に関する制限・制約事項はありませんが、一般的に多く採用されている構成を以下に示します。必ずしもこれに従う必要はありません。

─ 既存Dominoサーバー環境があり既に Domino LDAP サーバーが構成されている場合にはそれ、またはその LDAP ディレクトリー・リポジトリーを複製した別のSametime 専用 LDAP サーバーを使用します。

─ 新規に Domino LDAP サーバーを構築する場合には判断が分かれます。ドメインが単一などシンプルな Domino ディレクトリー構成の場合は既存と同じDominoドメインで構築する。ドメインが多数あるため (ディレクトリー・カタログを使用して) ディレクトリーの集約が必要な場合には別ドメインで構成します。

─ Communityサーバーについては、既存とは別のDominoドメインで構築します。

12


その他設計上のヒント（1/2）■ 写真の格納先について

─ ビジネスカードに写真を使用する場合、原則としてディレクトリに格納するのではなく、Notes DBやファイルシステムに格納することを推奨します。

─ 写真データを格納するとデータベースサイズは大きくなります。LDAPで参照するディレクトリのサイズが大きくなることは一般的にお勧めできません。

─ アプリケーションがLDAP参照ではなくURLで写真データを要求する場合もあり（例：SametimeのWebクライアントでビジネスカードを表示する場合）、HTTPアクセスを前提とした格納方法にする必要があります。

（参考）LDAP ディレクトリとカスタム IBM Notes アプリケーションhttp://www.ibm.com/support/knowledgecenter/ja/SSKTXQ_9.0.1/admin/admin/st_adm_buscard_dualreposldapcustom_t.html

13


その他設計上のヒント（2/2）■ *%s* などの部分⼀致検索のフィルターの利⽤について

─ Domino LDAP の場合には全⽂検索が実⾏され、*%s* などの部分⼀致検索はパフォーマンスが劇的に低下しますので強く推奨しません。

─ パフォーマンスについては様々な条件により異なります。事前によく検討を⾏い、パフォーマンス測定を⾏うようにしてください。

─ Domino LDAP の場合は前⽅⼀致の場合はビュー検索が⽤いられます。部分⼀致のクエリーが要求された場合には全⽂検索が実施されます。全⽂検索でもそこそこのパフォーマンスが出ますが、1000人を越える、数千、数万のユーザーからのクエリーが⾏われると処理が追い付かなくなる可能性があります。

■ 社員番号の利⽤について─ CNとして社員番号が設定されている場合、前⽅⼀致検索で数百、数千、数万ものヒッ

トが発生する場合あります。─ 100件までの応答制限をしている場合でも、検索処理⾃体は全数⾏われるため、ス

ループットの大幅な低下を招きます。─ 検索最小文字数を10に設定すると今度は姓や名での検索に⽀障を来します。─ 対策は個別対応となり、このような場合には、Javaカスタム・クエリーを作成して、

⼊⼒⽂字列内容に応じた、検索処理の分岐動作が⾏われるようにします。

14


Domino LDAPサーバーの基本設定（1/2）Domino LDAP サーバーの基本設定として、以下を設定することをお勧めします。■ サーバー設定文書 - [LDAP]タブ

─ タイムアウト - 最初は10秒程度に設定し、統計情報を⾒ながら短くしていきます。─ 検索結果の最⼤数 - デフォルトでは0（無制限）となっているため、あらかじめ制限

を設定しておきます。─ ワイルドカード検索の最⼩⽂字数 - 2,3に設定することをお勧めします。（英語圏で

は3を設定することが多くなっています。）─ 検索リクエスト時にエイリアス⾮参照を許可しますか? - 「いいえ」を設定します。

（「非参照...」は誤植となります。正しくは「被参照」です。）

15


Domino LDAPサーバーの基本設定（2/2）■ 全⽂索引の作成

─ ディレクトリにあらかじめ全⽂索引を作成しておきます。

■ notes.ini設定─ LDAP_QRCACHE_SIZE=536870912, NLCACHE_SIZE=536870912 （512MB）

Domino LDAPサーバーが保持するキャッシュのサイズ（デフォルト16MB）です。─ FT_FLY_INDEX_OFF=1

デフォルトでは、エージェントが全⽂索引を必要としたときに全⽂索引がない場合、全⽂索引が作成されますが、このパラメータにより全⽂索引の動的な作成を禁⽌します。

─ Update_Fulltext_Thread=1デフォルトでは全⽂索引の更新もビューの更新も同じスレッドで⾏われますが、このパラメータにより全⽂索引のためのUpdateタスクを別スレッドで実⾏できます。そのため、全⽂索引の更新がビューの更新に影響しません。

16


LTPAトークンの設定（1/2）WASベースのアプリケーションとSametimeを組み合わせて利⽤する場合には、SSOのためのLTPAトークンをWAS側からエクスポートして、そのトークンをDomino ディレクトリへインポートする必要があります。

■ 設定の注意点─ DominoとWASでLTPAトークンの有効期限に同じ時間を設定してください。─ LTPAトークンにはLTPA1とLTPA2があります。アプリケーションによって利⽤でき

るトークンがどちらか、あるいは、両方の場合がありますので、注意してください。─ WAS側の設定で、属性のプロパゲーション設定がSSOの障害になることがあるので、

「Webインバウンド・セキュリティー属性の伝播」は無効に設定してください。

17


LTPAトークンの設定（2/2）■ SSO環境においてデュアルディレクトリ構成をおこなう場合

SSOを⾏うアプリケーションによっては、参照しているLDAPが異なる場合があります。例えば、WebSphere PortalとSametimeでSSOを⾏う場合に、PortalがITDSを参照し、SametimeがDomino LDAPを参照している場合、などのケースです。このような場合、ITDSのLDAP DN（識別名）とDominoのユーザー名が異なるため、ユーザー名がマッチせずSSOを⾏うことができません。上記のように、LDAP ディレクトリと Domino LDAP を併用しているデュアルディレクトリ構成という特殊な環境下で、SSO させることが必須な場合には、以下の設定を⾏うことでSSOを実現することができます。─ Domino LDAPのユーザー文書のFullNameフィールドにLDAP DN形式の名前

（uid=zzzzz,o=yyy,dc=ibm,dc=com）を追加します。─ Sametime Community サーバーのsametime.iniの[Directory]セクションに

ST_DB_LDAP_ALLOW_SEARCH_ON_DN=1を設定します。この設定により、設定された認証フィルターを利⽤して、ユーザーDNの検索処理を実施することができます。

─ Sametimeの他のWASベースのサーバーで、allowDNPrincipalNameAsLiteralプロパティをtrueに設定します。

※ Domino LDAPの設定（サーバー設定⽂書）で、「検索リクエスト時にエイリアス⾮参照を許可しますか?」の設定は「無効」とします。

（参考）PM55588: ADD A CUSTOM PROPERTY TO ALLOW DN TO BE TREATED AS LITERALhttp://www-01.ibm.com/support/docview.wss?uid=swg1PM5558818


運用のヒント運用のヒント


Domino LDAP サーバーの監視■ Domino LDAPサーバーの監視の考え方

─ Domino LDAPサーバー単体でのパフォーマンスを⾒ることは特に意味はなく、Domino LDAPサーバーを利⽤しているSametimeからみて問題があるかどうかが重要となります。そのため、まずはSametimeの統計情報（詳しくは「4.パフォーマンスについて」を参照）で問題があるかどうかを確認します。

─ パフォーマンスチューニングや問題発生時の情報収集のために、Dominoサーバー統計情報の取得を有効にしておくことも重要となります。

─ Domino LDAPサーバーの監視については、Dominoサーバーとしての死活監視を⾏う以外にも、Dominoが提供するDomino Domain Monitoring (DDM)によってLDAPプロセスの監視を⾏うことが可能です。

20


Domino LDAP サーバーのデバッグDomino LDAPサーバーに問題があることが疑われる場合、さらに調査を⾏うためにデバッグパラメータを設定したデバッグを⾏うことが可能です。■ LDAPDEBUGによるデバッグ

─ notes.iniにLDAPDEBUGパラメータを設定することで、LDAPの操作の詳細ログをDominoコンソールに出⼒させることができます。

─ 注意点– デバッグを実⾏している間はCPU消費が大幅に増加します。常時有効化するので

はなく必要時にのみ使用することを推奨します。また、パフォーマンス計測時には必ず無効化しておいてください。

– ⼤量のログが console.log に出⼒されます。Domino 9.0 では、デフォルトのコンソールログサイズが10MBで、10MBを越えたものは記録されないまま破棄されます。21

たとえば、LDAPDEBUG=7ではLDAP検索のエントリの詳細を出力させることができます。

LDAP> Found matching entry, Note ID: 5310LDAP> Entry:LDAP> dn: CN=Polar Bear,O=org3LDAP> cn: Polar BearLDAP> fullname: CN=Polar Bear,O=org3LDAP> fullname: CN=Polar BearLDAP> mail: [email protected]> SendSearchEntry, sending entry CN=Polar Bear,O=org3


パフォーマンスについてパフォーマンスについて


性能評価・ベンチマークテストについて（1/3）■ 性能評価の考え方

─ LDAPのベンチマークには単純な参照回数能⼒を検証する⽅法がありますが、実際の利⽤を考えると、アプリケーションから⾒た場合のスループットを測定することを推奨します｡アプリケーション側から⾒て、要求発出から処理完了までの時間と、⼀定時間あたりの処理能⼒です。

─ Sametime では、STResolveタスク(LDAPサーバーへの検索要求を⾏うタスク）が出⼒する統計情報が保存されています。この統計情報は、SametimeサーバーからLDAPサーバーへの接続やパフォーマンスに問題がある場合に有用です。

─ アプリケーションのシミュレーターを使って実際の利⽤環境負荷をかけて、Sametime、および、LDAPの性能を測定します。Sametimeのシミュレーションを⾏うためのツールには以下のようなものがあります。

– IBM Lotus Server.load/NotesBench - Communityサーバー経由のチャットをシミュレートするために使用します。

– JMeter等のWebアプリケーションのパフォーマンス測定ツール - Proxyサーバー経由（Webクライアント）でのチャットをシミュレートするために使用します。

– Watchit - Communityサーバーにログインし、IM機能の利⽤をシミュレートするために使用します。（参考）Watchit ツールを使用した IBM Lotus Sametime 実稼働環境のパフォーマンス測定http://www.ibm.com/developerworks/jp/lotus/library/2011_st_watchit_tool/

23


性能評価・ベンチマークテストについて（2/3）■ IBM Lotus Server.load/NotesBench を使用したテストについて

─ あらかじめ用意されたSametimeの利⽤シナリオ（Sametime Workload）を使用して、ユーザーのログイン、ログアウト、チャットといった操作をシミュレートできます。

– （参考）Sametime Workloadhttp://www.ibm.com/support/knowledgecenter/ja/SSKTMJ_9.0.1/admin/tune_thesametimeworkloads_t.html

– IBM Lotus Server.Load: IBM Lotus Sametime の新しいワークロードhttps://www.ibm.com/developerworks/jp/lotus/library/sametime-workloads/

■ テスト実施時の注意点─ 「Create NotesBench Person Documents」エージェントを使用したユーザー文書

作成を⾏うと、mail1…mail20000というように、桁数の異なるユーザーが作成されます。この場合、"mail1"で前⽅⼀致検索を⾏うとヒットするユーザー数が多くなり、検索時間が⻑くなります。これは現実的には発生しないケースであり、パフォーマンステストとしては適切ではありません。

─ エージェントでユーザーを作成する際には、開始No「Starting Value to Create MailUsers」を10000（mail10000）からとするなど、ユーザー名の桁数を全ユーザーで揃えてください。

24


性能評価・ベンチマークテストについて（3/3）■ Sametimeの統計情報について

─ STResolveタスク(LDAPサーバーへの検索要求を⾏うタスク）が出⼒する統計情報は、デフォルトで60分間隔で取得されます。

─ Traceフォルダーの STResolve_<年⽉⽇時間>.csvとして出⼒され、単位時間あたりの要求数と処理完了数・仕掛かり数、応答時間平均と最⼤が統計情報として保存されています。

─ 例えば、次のような値を確認します。– APP_ReqQueueSize - 0が望ましく、この値が増加しているとLDAPサーバーへ

の検索において問題が発⽣していることが懸念されます。– STLDAP_RespAvgTime_SEARCH_serverName - 平均応答時間。この値が最

大応答時間（STLDAP_RespAvgTime_SEARCH_ldapserver.ibm.com_MAX）に近くなっていると、全体的に応答時間が⻑くなっている傾向にあることがわかります。

（参考）IBM Sametime 9 Community サーバー：ディレクトリー・アプリケーションの診断データの機能強化http://www-01.ibm.com/support/docview.wss?uid=swg21882656

25


パフォーマンスの最適化Sametimeでは、利⽤ユーザーが最⼤になるまでの間 (徐々に利⽤ユーザーが増える場合) とその後一定期間は注意深く Domino LDAPサーバーの統計情報およびアプリケーションの統計情報を確認する必要があります。実際の利⽤では思わぬことが発⽣します。■ Domino LDAP サーバーの統計情報確認

─ Dominoサーバーコンソールで以下を実⾏すると、検索パターン毎に、平均処理時間、回数、ヒット数等が出⼒されます。

26

> Show stat ladpLDAP.Search.Longest.AverageTime.01 = 0.062:LDAP.Search.Longest.Count.01 = 78:

LDAP.Search.Longest.Entries.01 = 0:

LDAP.Search.Longest.Pattern.01 = ?cn?sub?(&(:

LDAP.Average LDAP Search time = 0.003LDAP.Longest LDAP Search request = Base: , Filter: (&(objectclass=dominoPerson)(|(mail=CN=μ│oμ￡-O≫Rμ--/O=IBM*)(cn=CN=μ│oμ￡-O≫Rμ--/O=IBM*)(sn=CN=μ│oμ￡-O≫Rμ--/O=IBM*))), Scope: 2, Entries Found: 0LDAP.Longest LDAP Search time = 14.864LDAP.Total LDAP Timeouts = 1819


パフォーマンスに関するTips■ ディレクトリー・データの更新について

─ ディレクトリーのデータが更新されるとビューの更新が発⽣し、パフォーマンスに著しい劣化をもたらします。複製回数、時刻を深夜帯などのみに⾏うことで、⽇中のビュー更新発⽣を防⽌してください。

■ パフォーマンスに関連するSametime.iniパラメータについて─ ST_DB_LDAP_CONNECTIONS_NUMBER

SametimeモジュールごとのLDAPサーバーへの同時接続数です。Domino LDAPサーバーのリソースにゆとりがある場合、この値を増やす（2以上、最大5程度）ことでパフォーマンスはよくなります。特に、LDAPサーバーが冗⻑化されているケースでは、1のままでは冗⻑化構成でもパフォーマンスは出ないため、2以上に設定することをお勧めします。

─ ST_DB_LDAP_PENDING_MAX/ST_DB_LDAP_PENDING_LOW保留キューで接続ごとに保留されている LDAP 要求の最大数および最小数です。Sametime Communityサーバーは特定の接続で ST_DB_LDAP_PENDING_MAX に達すると、保留中の操作の数が減りST_DB_LDAP_PENDING_LOW 設定で指定された値の数になるまで、この接続で新しい LDAP 要求を送信しません。これらの値はキューの要求数を制限するために有用ですが、一方で頻繁に要求の送信停⽌が発⽣すると、処理全体に遅れが発⽣したり、サーバーに負荷がかかる可能性があります。そのため、ST_DB_LDAP_PENDING_MAXに対して、ST_DB_LDAP_PENDING_LOWを低めに設定することをお勧めします。（例：ST_DB_LDAP_PENDING_MAX=160, ST_DB_LDAP_PENDING_LOW=120など）27