コンテンツにスキップ

LDAP ユーザ管理チューニング （LDAP 機能設定）

はじめに

用途

この文書には、下記の情報が記載されています：

  • TeamFile のユーザ管理を LDAP にて管理するに当たり、技術的な内容、並びにチューニング。

対象者

既存 LDAP サーバへ対する管理者によるゕクセスが可能な方、並びに TeamFile のサーバの管理者。 また、ある程度の LDAP に関する知識も必要となります。

LDAP ユーザ管理のチューニング

チューニングで必要となるファイルとディレクティブ

TeamFile での LDAP 接続で設定が可能なファイルと項目について説明します。

ファイル（/usr/local/teamfile/www/conf/conf.d/mod_dav_tf.conf）

このファイルは、TeamFile サーバ全体の仕組みについて記述してあるファイルです。複数ロケーション関わらず全体に影響を受けます。設定変更後には TeamFile のサービスの再起動が必要です。

また、このファイルは、/usr/local/teamfile/www/conf/conf.d/mod_dav_tf.conf.default と呼ばれるファイルを読み込んでから上書きする形になっています。決して、mod_dav_tf.conf.default のファイルを編集しないでください。アップデート時に上書きされてしまいます。

ディレクティブ

以下のディレクティブが該当になります。

  • TfLDAPCacheByte（デフォルト０ | 1048576 ）
    LDAP 共有メモリのサイズを指定します。未指定の場合は０となり、LDAP 機能そのものが動作しません。共有メモリがないと管理ができません。

  • TfLDAPCacheTTL（デフォルト 30 秒）
    LDAP の情報がキャッシュされて有効とされる秒数です。この秒数が過ぎた情報は更新対象となりリフレッシュされます。

  • TfLDAPMarkPercentage（デフォルト 75 ％）
    LDAP の共有メモリの開放を行うときにマーキングのパーセンテージを指定します。

  • TfLDAPPurgePercentage（デフォルト 90 ％）
    LDAP の共有メモリの開放が行われるパーセンテージを指定します。

  • TfLDAPMaxMemBlocks（デフォルト 1024 ）
    LDAP の共有メモリのブロックサイズを指定します。

ディレクティブと役割

前述のディレクティブは、以下のイメージで動作を行います。

TF01058-0001.png

TeamFile では共有メモリの領域を、TfLDAPCacheByte と TfLDAPMaxMemBlocks で LDAP の共 有メモリが利用できる容量を決定しています。

「TfLDAPMarkPercentage」と「TfLDAPPurgePercentage」は以下の働きがあります。

TfLDAPMarkPercentage
　　共有メモリの利用容量がこの値に到達した時点でマーキングされ開放される領域を
　　決定します。
TfLDAPPurgePercentage
　　メモリがこのパーセンテージになると開放されメモリの領域を確保します。

つまり、「TfLDAPMarkPercentage」でマーキングされ「TfLDAPPurgePercentage」の時にそのマーキン グまで領域が開放される事になります。

また、上記の説明は、メモリの利用容量によって動きますが、「TfLDAPCacheTTL」は異なり、共有メモリに キャッシュされてからの時間に応じて自動的に再取得を行うことを行います。

チューニングが必要となるケース

基本的に、TeamFile の LDAP 機能は、デフォルトの設定であっても、効率的なメモリ管理を行う為にチュ ーニングはあまり問題にはなりませんが、次に挙げるケースの場合にはチューニングによって更に効率的な 管理を行うことができます。

大量ユーザの場合のチューニング

サービスの停止まで、大量のユーザがログインを行うような場合には、共有メモリにユーザにおさめることができずにメモリのパージ処理（開放）が繰り返されてしまいます。メモリのパージ（開放）は、処理に時間がかかります。その為、なるべくこのパージ処理を減らすように行うことが望ましいです。

変更が必要なディレクティブは TfLDAPCacheByte と TfLDAPMaxMemBlocks です。 TfLDAPCacheByte は標準の１M 程度で問題はありませんが、TfLDAPMaxMemBlocks がデフォルト では値が小さい為に頻繁にパージ処理が行なわれる可能性があります。この TfLDAPMaxMemBlocks の値を変更してみます。デフォルトでは 1024 ですが、これを「10000」に変更して様子を見てみます。さほ どパージ処理が行なわれなくなればその数値を利用してください。 例えば、OpenSSL サーバを利用していればこれだけでサービス停止まで 1000 人程度はパージ処理が 行なわれなくなります。

LDAP 情報の更新サイクルによるチューニング

LDAP サーバの属性情報の変更期間がさほど無い場合、属性の取得でリクエストを行う事は LDAP サーバへの負荷となり、更に同情報の取得を行うことが無駄になります。「TfLDAPCacheTTL」はその為の値 で、一件ごとのキャッシュ時間を指定します。頻繁な更新が予想される LDAP サーバの場合、デフォルトの 30 秒でも問題ありません。しかし、ほぼ更新される事が無いのであれば、この値を LDAP の変更サイクル に合わせておけばキャッシュのパージ（開放）処理が抑えられます。

通常一般的に LDAP サーバの情報は変更されるケースが少ない情報ですので 30 秒ではなく、 12 時間 や 24 時間ぐらいのリフレッシュ動作にすると LDAP サーバへの問い合わせの負荷が軽減され、パフォー マンスが改善する可能性があります。

参考
　　12 時間： 43,200
　　24 時間： 86,400

エラーメッセージ

LDAP 関係のエラーログ（/usr/local/teamfile/www/logs/）で出力される内容と説明です。

  • “out of mem (pURLNode)”
    このエラーは、基本的な情報としてのキャッシュができなかったエラーです。この場合は、 TfLDAPCacheByte を見直してください。

  • "Give up. Insert attributes.(out of mem)"
    LDAP の属性の格納中にメモリオーバーが発生したエラーです。一度は失敗してエラーとなりますが、 再度認証を行うと正常となるケースがあります。このエラーは大量のユーザが一度にログインしてきた 時に出る可能性がありますが可能性は低いです。

  • "The inquiry failed in LDAP. Processing is continued without using LDAP.[result = msg]”
    LDAP サーバがダウンしているが、そのまま TeamFile のユーザ情報を元に接続を行ったことを示し ます。「msg」には LDAP のネイティブなエラーメッセージが含まれます。このエラーは接続の都度、表 示されますが、正常に LDAP 接続が行われた際には表示されなくなります。
    この状態の場合、LDAP に存在して TeamFile サーバに存在しないユーザはログインできません。 あくまで暫定的な救済処置を行うだけです。

  • "Failed LDAP Password for user ユーザ ID not found. (auth failed or object not found.) [result = msg]"
    対象のユーザが LDAP サーバの認証に失敗した事を示します。Msg にはネイティブなエラーが含まれます。通常認証エラーか必要なオブジェクト（ユーザ名など）が足りなかったことが原因です。
    もし、今までログインできていて多量にこのエラーが出る場合には、LDAP サーバがメンテナンス中か を調べてください。

  • "Failed to LDAP Server. [result = msg]"
    致命的なエラーです。何かしらの障害が LDAP に発生して認証が失敗した事を示します。ネイティブ なエラーは msg に含まれています。