第36章 エントリーの一括プロビジョニングのパフォーマンスチューニング

ユーザーの追加 (11章ユーザーアカウントの管理) など、通常のワークフローを使用して大量のエントリーを追加すると、非常に時間がかかる可能性があります。本章では、プロビジョニングをできるだけ早く完了できるようにプロセスを調節する方法を説明します。
手順には以下が含まれます。
  • Identity Management (IdM) は LDIF ファイルからプロビジョニングされたエントリーを読み込み、対象の IdM LDAP インスタンスにインポートします。
  • 管理者は、キャッシュサイズなど特定の属性のカスタム値を設定し、MemberOf および Schema Compatibility プラグインを無効化します。この手順では、MemberOf が無効になったことに対応するため、プロビジョニングされたエントリーで fixup-memberof.pl プラグインを実行します。
この手順は、以下のエントリータイプ (ユーザー、ユーザーグループ、ホスト、ホストグループ、sudo ルール、ホストベースのアクセス制御 (HBAC)) をプロビジョニングするために、設計、テストされました。

一括プロビジョニングの推奨事項と前提条件

推奨事項:
  • 大量のエントリー (10,000 件以上) をプロビジョニングする場合には、LDAP クライアントが、エントリーのプロビジョニング先のサーバーにアクセスしたり、サーバーの情報に依存したりできないようにします。たとえば、これはサーバーのポート 389 および 636 を無効にするか、Unix ソケットで機能する LDAPI を使用することで実現できます。
    理由: MemberOf プラグインはサーバー上で無効になっているのでサーバーのメンバーシップの情報は無効です。
  • プロビジョニング中に実行しておく必要がないアプリケーションは停止します。
    理由: これにより、できるだけマシン上のメモリーを開放されます。ファイルシステムのキャッシュが空いたメモリーを使用することで、プロビジョニングのパフォーマンスを向上します。
    以下の手順にはすでに IdM サービスを停止して、Directory Server (DS) インスタンスのみを再起動する手順が含まれている点に注意してください。tomcat などの IdM サービスは大量のメモリーを消費しますが、プロビジョニング中には使用されません。
  • 新規インストールされた IdM デプロイメントで、サーバーが 1 台のみ含まれている場合に、この手順を実行してください。プロビジョニングの完了後のみ、レプリカを作成します。
    理由: プロビジョニングのスループットは、レプリケーションよりもはるかに早いので、デプロイメントに 1 台以上含まれていると、レプリカの情報が大幅に古くなってしまいます。
前提条件:
  • プロビジョニングするエントリーが含まれる LDIF ファイルを生成します。たとえば、既存の IdM デプロイメントを移行する場合には、ldapsearch ユーティリティーを使用して全エントリーをエクスポートし、LDIF ファイルを作成します。
    LDIF 形式の詳細は、『Red Hat Directory Server Administration Guide』の「About the LDIF File Format」を参照してください。

現在の DS チューニングパラメーター値のバックアップ

  1. DS チューニングパラメーターの現在の値を取得します。
    • データベースのキャッシュサイズおよびデータベースのロック 
      # ldapsearch -D "cn=directory manager" -w secret -b "cn=config,cn=ldbm database,cn=plugins,cn=config" nsslapd-dbcachesize nsslapd-db-locks
						
...
nsslapd-dbcachesize: 10000000
nsslapd-db-locks: 50000
...
    • エントリーのキャッシュサイズと DN キャッシュサイズ 
      # ldapsearch -D "cn=directory manager" -w secret -b "cn=userRoot,cn=ldbm database,cn=plugins,cn=config" nsslapd-cachememsize nsslapd-dncachememsize

...
nsslapd-cachememsize: 10485760
nsslapd-dncachememsize: 10485760
...
  2. 取得した値をメモします。プロビジョニングが完了したら、パラメーターをこれらの値にリセットします。

データベース、ドメインエントリー、DN キャッシュサイズの調節

データベースのキャッシュサイズの場合:
  1. 必要な値を決定します。
    推奨の値は通常 200 MB から 500 MB の間となっています。各ユースケースに適した値は、システムで利用できるメモリーにより異なります。
    • メモリー 8 GB 以上 → 500 MB
    • メモリー 8 GB - 4 GB → 200 MB
    • メモリー 4 GB 未満 → 100 MB
  2. 以下のテンプレートを使用して、決定した値を設定します。 
    dn: cn=config,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-dbcachesize
nsslapd-dbcachesize: db_cache_size_in_bytes
    ldapmodify ユーティリティーを使用して LDAP 属性を変更する例は、例36.1「ldapmodify を使用した LDAP 属性の変更」を参照してください。

例36.1 ldapmodify を使用した LDAP 属性の変更

  1. ldapmodify コマンドを実行して、属性値を変更するステートメントを追加します。以下に例を示します。 
    # ldapmodify -D "cn=directory manager" -w secret -x
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-dbcachesize
nsslapd-dbcachesize: 200000000
  2. Ctrl+D を押して、サーバーへの変更を確定、送信します。操作が正常に完了したら、以下のメッセージが表示されます。 
    modifying entry "cn=config,cn=ldbm database,cn=plugins,cn=config"
ドメインエントリーのキャッシュサイズの場合:
  1. 必要な値を決定します。
    推奨の値は 100 MB から 400 MB の間となっています。適切な値は、お使いのシステムで利用可能なメモリーにより異なります。
    • メモリー 4 GB 以上 → 400 MB
    • メモリー 2 GB - 4 GB → 200 MB
    • メモリー 2 GB 未満 → 100 MB
    大規模な静的グループをプロビジョニングする場合には、エントリーキャッシュに、グループおよびメンバーなど全エントリーが格納できるサイズにすることを推奨します。
  2. 以下のテンプレートを使用して、決定した値を設定します。 
    dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-cachememsize
nsslapd-cachememsize: entry_cache_size_in_bytes
ドメイン名 (DN) のキャッシュサイズの場合:
  1. 最適なパフォーマンスを得るには、DN キャッシュに、プロビジョニングしたエントリーの DN すべてを格納できるようにすることを推奨します。ユースケースに適した値を見積もるには以下を行ってください。
    1. ファイル内の全 DN エントリー数を確認します。DN エントリーは、dn: で始まる行に含まれます。たとえば、# grep、sed、wc を使用して確認します。 
      # grep '^dn: ' ldif_file | sed 's/^dn: //' | wc -l
92200
    2. LDIF ファイルに含まれる全 DN エントリーの文字列のサイズを確認します。 
      # grep '^dn: ' ldif_file | sed 's/^dn: //' | wc -c
9802460
    3. 平均の DN サイズの取得: ファイル内の全 DN エントリー数で、全 DN エントリーの文字列のサイズを除算します。
      例: 9,802,460 / 92,200 ≈ 106
    4. 平均のメモリーサイズの取得: 平均の DN サイズに 2 を乗算した数値に、32 を加算します。
      例: (106 * 2) + 32 = 244
    5. 適切な DN のキャッシュサイズを取得: 平均メモリーサイズで LDIF ファイルの DN エントリーの総数を乗算します。
      例: 244 * 92,200 = 22,496,800
  2. 以下のテンプレートを使用して、決定した値を設定します。 
    dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
changetype: modify
Replace: nsslapd-dncachememsize
Nsslapd-dncachememsize: dn_cache_size

不必要なサービスの無効化およびデータベースロックの調節

  1. MemberOf および Schema Compatibility プラグインを無効にします。 
    dn: cn=MemberOf Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: off
    dn: cn=Schema Compatibility,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: off
    MemberOf を無効にすると、プロビジョニングが大幅に加速されます。また、 Schema Compatibility を無効にすると、操作の時間を短縮することができます。
    ldapmodify ユーティリティーを使用して LDAP 属性を変更する例は、例36.1「ldapmodify を使用した LDAP 属性の変更」を参照してください。
  2. トポロジーにレプリカがインストールされていない場合には (「一括プロビジョニングの推奨事項と前提条件」で推奨)、Content Synchronization および Retro Changelog プラグインを無効にします。 
    dn: cn=Content Synchronization,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: off
    dn: cn=Retro Changelog Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: off
    これらのプラグインを無効にすると、プロビジョニングのパフォーマンス向上に役立ちます。
  3. IdM サーバーを停止します。これにより、DS インスタンスも停止されます。 
    # ipactl stop
    次の手順でデータベースのロックの数を設定するには、DS を停止する必要があります。後で DS を再起動します。
  4. データベースロックの数を調節します。プロビジョニングのエントリー数の半分が適切な値です。
    • 最小値は 10,000 です。
    • 最大値は 200,000 です。
    DS が停止されたので、/etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif ファイルを編集して値を設定する必要があります。 
    dn: cn=config,cn=ldbm database,cn=plugins,cn=config
...
nsslapd-db-locks: db_lock_number
    IdM は、メンバーシップのコンピューティングの際には、大容量のデータベースページにアクセスします。アクセスするページが多いと、プロビジョニングに必要なロックも増えます。
  5. DS を起動します。 
    # systemctl start dirsrv.target

エントリーのインポート

LDIF ファイルから IdM LDAP インスタンスに新規エントリーをインポートするには、ldapadd ユーティリティーなどを使用します。 
# ldapadd -D "binddn" -y password_file -f ldif_file
ldapadd の使用方法については、ldapadd(1) の man ページを参照してください。

無効にしたサービスの再有効化および元の属性値の復元

  1. MemberOf を有効にします。 
    dn: cn=MemberOf Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on
    ldapmodify ユーティリティーを使用して LDAP 属性を変更する例は、例36.1「ldapmodify を使用した LDAP 属性の変更」を参照してください。
  2. DS を再起動します。 
    # systemctl restart dirsrv.target
    MemberOf を以前の手順で有効化したので、この時点で DS を再起動する必要があります。
  3. fixup-memberof.pl のスクリプトに (objectClass=*) フィルターを使用して実行し、全プロビジョニングエントリーの memberOf 属性を再生成、更新します。以下に例を示します。 
    # fixup-memberof.pl -D "cn=directory manager" -j password_file -Z server_id -b "suffix" -f "(objectClass=*)" -P LDAP
    エントリーのインポートの際に、MemberOf プラグインを無効にしたので、fixup-memberof.pl を実行する必要があります。スクリプトが正しく完了しないと、プロビジョニングを続行できません。
    fixup-memberof.pl の詳細は、fixup-memberof.pl(8) の man ページを参照してください。
  4. Schema Compatibility プラグインを有効にします。 
    dn: cn=Schema Compatibility,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on
  5. Content Synchronization および Retro Changelog プラグインを「不必要なサービスの無効化およびデータベースロックの調節」で無効にした場合には、有効化しなおしてください。 
    dn: cn=Content Synchronization,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on
    dn: cn=Retro Changelog Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on
  6. 「現在の DS チューニングパラメーター値のバックアップ」でバックアップしたデータベースキャッシュ、エントリーキャッシュ、DN キャッシュサイズの元の値を復元します。 
    dn: cn=config,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-dbcachesize
nsslapd-dbcachesize: backup_db_cache_size

dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
changetype: modify
Replace: nsslapd-dncachememsize
Nsslapd-dncachememsize: backup_dn_cache_size
-
replace: nsslapd-cachememsize
nsslapd-cachememsize: backup_entry_cache_size
  7. DS を停止します。 
    # systemctl stop dirsrv.target
  8. 「現在の DS チューニングパラメーター値のバックアップ」でバックアップしたデータベースロックの元の値を復元します。DS が停止されたので、/etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif ファイルを編集して値を設定する必要があります。 
    dn: cn=config,cn=ldbm database,cn=plugins,cn=config
...
nsslapd-db-locks: backup_db_lock_number
  9. IdM サーバーを起動します。 
    # ipactl start
    これにより、DS を含むすべての IdM サービスが起動します。