Identity Management でのパフォーマンスの調整


Red Hat Enterprise Linux 9

パフォーマンスを向上させるための IdM サービス (Directory Server、KDC、SSSD など) の最適化

Red Hat Customer Content Services

概要

Red Hat は、ほとんどのデプロイメントで適切に動作するように Identity Management (IdM) を調整します。ただし、特定のシナリオでは、レプリケーションアグリーメント、Directory Server、Kerberos Key Distribution Center (KDC)、または System Security Services Daemon (SSSD) などの IdM コンポーネントを調整すると有益な場合があります。

Red Hat ドキュメントへのフィードバック (英語のみ)

Red Hat ドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。

Jira からのフィードバック送信 (アカウントが必要)

  1. Jira の Web サイトにログインします。
  2. 上部のナビゲーションバーで Create をクリックします。
  3. Summary フィールドにわかりやすいタイトルを入力します。
  4. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
  5. ダイアログの下部にある Create をクリックします。

第1章 IdM のチューニングにおける重要な考慮事項

Identity Management のコンポーネントサービスは、ほとんどのデプロイメントで最適に機能するように調整されています。システム管理者は、特定の環境でのニーズに合わせて、IdM サービスのパフォーマンスを調整できます。

重要な留意事項

  • IdM デプロイメントはそれぞれ、ハードウェア、ソフトウェア、ネットワーク、データ、ワークロード、およびその他の要因を一意に組み合わせます。ある環境で調整が有効であっても、別の環境では悪影響がある場合があります。
  • パフォーマンスの調整は、反復的で実験的なプロセスです。Red Hat は、1 回に調整する変数は 1 つだけにして、ご使用の環境への影響を監視することを推奨します。変数 1 つの調整で目的とする結果が得られた場合には、これまでの調整によるパフォーマンスの監視を継続しつつ、次の変数を調整します。

第2章 ハードウェア推奨事項

ハードウェアでは、RAM の容量を適切に確保することが最も重要になります。システムに十分な RAM があるようにしてください。一般的な RAM の要件は次のとおりです。

  • 10,000 ユーザーおよび 100 グループには、最低 4 GB の RAM と 4 GB のスワップ領域を割り当てます。
  • 100,000 ユーザーおよび 50,000 グループには、最低 16 GB の RAM と 4 GB のスワップ領域を割り当てます。

大規模なデプロイメントでは、データの多くがキャッシュに保存されるため、ディスク容量を増やすよりも RAM を増やす方が効果的です。通常、メモリーを増やすと、キャッシュ機能により、サイズが大きいデプロイメントでパフォーマンスが改善されます。仮想化環境では、メモリーバルーニングを無効にするか、ゲスト IdM サーバー用に RAM 全体を予約する必要があります。

注記

基本的なユーザーエントリーまたは証明書のあるシンプルなホストエントリーのサイズは、約 5 - 10 KB です。

第3章 IdM サーバーのパフォーマンスに関する推奨事項

安定したパフォーマンスを確保するために、Identity Management (IdM) では、IdM サーバーに同時に追加または登録できるユーザーとクライアントの最大数に制限が適用されます。

Expand
表3.1 IdM 操作の制限
アクション説明数値

クライアントの登録

登録に失敗することなく、IdM サーバーに同時に登録できる IdM クライアントの最大数。

130

ユーザーの追加

ユーザーの追加に失敗することなく、ipa user-add[] コマンドを使用してさまざまな IdM クライアントから同時に追加できるユーザーの最大数。

IdM API batch コマンドを使用すると、同じ時間でさらに多くのユーザーを追加できます。ユーザーは 100 ユーザー単位で追加することを推奨します。

325

クライアントの認証

認証に失敗することなく、同時に認証できる IdM クライアントの最大数。

800

ユーザーグループへのメンバーの追加

グループに新しいメンバーを追加するための時間を超過することなく追加できる、グループのメンバーの推奨数。IdM には、メンバーをグループに追加するための通常の時間枠を 2 秒とするルールがあります。さらにメンバーを追加することもできますが、アクションの時間は徐々に延長されます。

1500

第4章 IdM でのフェイルオーバー、負荷分散、高可用性

Identity Management (IdM) には、IdM クライアント向けのフェイルオーバーメカニズムと、IdM サーバー向けの負荷分散および高可用性機能があります。

クライアント側のフェイルオーバー機能

デフォルトでは、IdM クライアント上の SSSD サービスが DNS サービス (SRV) のリソースレコードを使用するように設定されています。そのため、クライアントは接続する最適な IdM サーバーを自動的に決定できます。

プライマリーサーバーとバックアップサーバーの設定

サーバー解決の動作は、/etc/sssd/sssd.conf ファイルの ipa_server パラメーターの _srv_ オプションによって制御されます。

/etc/sssd/sssd.conf の例

[domain/<idm_domain_name>]
id_provider = ipa
ipa_server = _srv_, <primary_idm_server1>, <primary_idm_server2>
ipa_backup_server = <backup_idm_server1>, <backup_idm_server2>
...
Copy to Clipboard Toggle word wrap

_srv_ オプションが指定されている場合、SSSD は優先度順に並んだ IdM サーバーのリストを取得します。プライマリーサーバーがオフラインになった場合、IdM クライアント上の SSSD サービスが、利用可能な別の IdM サーバーに自動的に接続します。

プライマリーサーバーは ipa_server パラメーターで指定します。SSSD は、まずプライマリーサーバーへの接続を試みます。プライマリーサーバーが利用できない場合にのみ、バックアップサーバーに切り替えます。

_srv_ オプションはバックアップサーバーではサポートされていません。

注記

SSSD は DNS サーバーから SRV レコードを照会します。デフォルトでは、SSSD は別の DNS サーバーに照会する前に、DNS リゾルバーからの応答を 6 秒間待機します。どの DNS サーバーにも到達できない場合、ドメインはオフラインモードで動作し続けます。dns_resolver_timeout オプションを使用すると、クライアントが DNS リゾルバーからの応答を待機する時間を長くすることができます。

パフォーマンス上の理由から DNS ルックアップをバイパスする場合は、ipa_server パラメーターから _srv_ エントリーを削除し、クライアントが接続すべき IdM サーバーを優先順に指定します。

/etc/sssd/sssd.conf の例

[domain/<idm_domain_name>]
id_provider = ipa
ipa_server = <primary_idm_server1>, <primary_idm_server2>
ipa_backup_server = <backup_idm_server1>, <backup_idm_server2>
...
Copy to Clipboard Toggle word wrap

IdM サーバーおよびサービスのフェイルオーバー動作

SSSD のフェイルオーバーメカニズムは、IdM サーバーとそのサービスを別々に扱います。サーバーのホスト名解決が成功すると、SSSD はマシンがオンラインであると見なし、そのマシン上の必要なサービスへの接続を試みます。サービスへの接続が失敗した場合、SSSD はマシン全体やマシン上の他のサービスではなく、その特定のサービスだけをオフラインと見なします。

ホスト名の解決に失敗した場合、SSSD はマシン全体をオフラインと見なし、そのマシン上のどのサービスにも接続を試行しません。

すべてのプライマリーサーバーが利用できない場合、SSSD は設定されたバックアップサーバーへの接続を試みます。バックアップサーバーに接続している間、SSSD は定期的にプライマリーサーバーの 1 つに再接続を試み、プライマリーサーバーが利用可能になるとすぐに接続します。これらの試行の間隔は、failover_primary_timeout オプションによって制御されます。デフォルトは 31 秒です。

すべての IdM サーバーにアクセスできなくなった場合、SSSD はオフラインモードに切り替わります。この状態では、SSSD はサーバーが利用可能になるまで 30 秒ごとに接続を再試行します。

サーバー側の負荷分散およびサービスの可用性

複数の IdM レプリカをインストールして、IdM で負荷分散および高可用性を実行できます。

  • 地理的に分散したネットワークがある場合には、データセンターごとに複数の IdM レプリカを設定することで、IdM クライアントと、最寄りのアクセス可能なサーバーとの間のパスを短くできます。
  • Red Hat は、最大 60 のレプリカを持つ環境に対応します。
  • IdM レプリケーションメカニズムでは、アクティブ/アクティブのサービスの可用性 (全 IdM レプリカのサービスを同時利用可) を提供します。
注記

Red Hat では、IdM と他の負荷分散ソフトウェアまたは高可用性 (HA) ソフトウェアを組み合わせることを推奨していません。

サードパーティーの高可用性ソリューションの多くは、アクティブ/パッシブのシナリオを想定しており、IdM へのサービスが不要に中断されてしまう可能性があります。他のソリューションでは、クラスター化されたサービスごとに仮想 IP または単一のホスト名を使用します。このような方法はすべて、通常、IdM ソリューションが提供するタイプのサービスの可用性では適切に機能しません。また、Kerberos との統合性が非常に低く、デプロイメントのセキュリティーと安定性が全体的に低下します。

第5章 レプリカトポロジーの最適化

堅牢なレプリカトポロジーはワークロードを分散し、レプリケーションの遅延を減らします。以下のガイドラインに従って、レプリカトポロジーのレイアウトを最適化します。

5.1. トポロジー内の IdM レプリカの適切な数を決定するためのガイドライン

組織の要件に合わせて IdM トポロジーを計画し、最適なパフォーマンスとサービスの可用性を確保してください。

各データセンターに少なくとも 2 つのレプリカをセットアップする
各データセンターに少なくとも 2 つのレプリカをデプロイして、1 台のサーバーに障害が発生した場合にレプリカが引き継いで要求を処理できるようにします。
クライアントにサービスを提供するために十分な数のサーバーをセットアップする
1 台の Identity Management (IdM) サーバーで 2000 - 3000 台のクライアントにサービスを提供できます。ここでは、クライアントがサーバーに対して 1 日に複数回クエリーする (毎分ではありません) ことを想定しています。頻繁なクエリーが予想される場合は、サーバーの追加を計画してください。
十分な数の認証局 (CA) レプリカを設定します。
CA ロールがインストールされているレプリカのみが、証明書データを複製できます。IdM CA を使用する場合は、環境に、証明書のレプリカ合意がある CA レプリカが 2 つ以上あることを確認します。
1 つの IdM ドメインに最大 60 台のレプリカを設定
Red Hat は、最大 60 のレプリカを持つ環境に対応します。

5.2. トポロジーで IdM レプリカを接続するためのガイドライン

1 台のレプリカを少なくとも 2 つのレプリカに接続
これにより、最初のレプリカと最初にインストールしたサーバー間だけでなく、他のレプリカ間でも情報が複製されるようになります。
レプリカを、その他のレプリカ (最大 4 つ) に接続 (必須要件ではありません)

サーバーごとに多数のレプリカ合意を設定しても、大きな利点はありません。受信側のレプリカは、一度に 1 つの他のレプリカによってのみ更新できます。その間、その他のレプリカ合意はアイドル状態になります。通常、レプリカごとに 4 つ以上のレプリカ合意があると、リソースが無駄になります。

注記

この推奨事項は、証明書のレプリカ合意とドメインのレプリカ合意の両方に適用されます。

レプリカごとに 4 つのレプリカ合意という制限は、次の 2 つの場合には、例外として適用されません。

  • 特定のレプリカがオンラインでない場合や応答していない場合にフェイルオーバーパスが必要な場合
  • 大規模デプロイメントで、特定のノード間に追加の直接リンクが必要な場合

レプリカ合意を多数設定すると、全体のパフォーマンスに悪影響が及ぶ可能性があります。トポロジー内の複数のレプリカ合意が更新を送信すると、特定のレプリカの changelog データベースファイル上で、受信する更新と送信する更新の間の競合が増大することがあります。

レプリカごとにさらに多くのレプリカ合意を使用する場合は、レプリケーションの問題やレイテンシーが発生しないようにしてください。距離が長く、中間ノードの数が多いと、レイテンシーの問題が発生する場合があることに注意してください。

データセンター内のレプリカを互いに接続
これにより、データセンター内のドメインレプリケーションが確実になります。
各データセンターを少なくとも 2 つの他のデータセンターに接続
これにより、データセンター間のドメインレプリケーションが確実になります。
少なくとも一対のレプリカ合意を使用してデータセンターを接続
データセンター A および B に、A1 への B1 までのレプリカ合意がある場合は、A2 から B2 へのレプリカ合意があれば、いずれかのサーバーがダウンしても、2 つのデータセンター間でレプリケーションを続行できます。

5.3. レプリカトポロジーの例

次のいずれかの例を使用して、信頼性の高いレプリカトポロジーを作成できます。

図5.1 4 つのデータセンターで構成されるレプリカトポロジー。各データセンターに、レプリカ合意で接続された 4 台のサーバーがある



図5.2 3 つのデータセンターで構成されるレプリカトポロジー。各データセンターに異なる数のサーバーがあり、それらがすべてレプリカ合意を通じて相互接続されている

5.4. IdM サーバーからの IdM CA サービスのアンインストール

トポロジー内に CA ロール を持つ Identity Management (IdM) レプリカが 5 つ以上あり、冗長な証明書のレプリケーションが原因でパフォーマンスの問題が発生する場合は、IdM レプリカから冗長な CA サービスインスタンスを削除します。これを行うには、該当する IdM レプリカの使用を完全に停止してから、CA サービスなしで IdM を再インストールする必要があります。

注記

IdM レプリカに CA ロールを 追加 することはできますが、IdM では、IdM レプリカから CA ロールのみを 削除 する方法はありません。ipa-ca-install コマンドには --uninstall オプションがありません。

前提条件

  • トポロジー内の 5 つ以上の IdM サーバーに IdM CA サービスがインストールされている。

手順

  1. 冗長な CA サービスを特定し、当該サービスをホストする IdM レプリカで IdM サーバーのアンインストール の手順を実行します。
  2. 同じホストで、IdM サーバーのインストール: 統合 DNS があり外部 CA がない場合 の手順に従います。

第6章 検索サイズおよび時間制限の調整

IdM ユーザーのリストを要求するなど、一部のクエリーでは、エントリー数が大量に返される場合があります。この検索操作を調整して、ipa user-find などの ipa *-find コマンドの実行時や、Web UI で対応するリストを表示する際に、全体的なサーバーのパフォーマンスを向上できます。

検索サイズ制限

クライアントの CLI または IdM Web UI にアクセスするブラウザーからサーバーに送信されるリクエストで返される最大エントリー数を定義します。

デフォルト - 100 エントリー

検索時間の制限

検索の実行までにサーバーが待機する最大時間 (秒) を定義します。検索がこの制限に到達したら、サーバーは検索を停止し、停止するまでの期間に検出されたエントリーを返します。

デフォルト - 2 秒

この値が -1 に設定されていると、IdM は、検索時に制限を適用しません。

重要

検索のサイズや時間制限を高く設定しすぎると、サーバーのパフォーマンスに影響を及ぼすことがあります。

6.1. コマンドラインで検索サイズおよび時間制限の調整

検索サイズと時間制限をグローバルに、または特定のエントリーに合わせて調整して、検索のパフォーマンスと応答性を最適化できます。

手順

  1. 現在の検索時間およびサイズ制限を CLI で表示するには、ipa config-show コマンドを使用します。

    $ ipa config-show
    
    Search time limit: 2
    Search size limit: 100
    Copy to Clipboard Toggle word wrap
  2. すべてのクエリーに対して グローバルに 制限を調整するには、ipa config-mod コマンドを使用して、--searchrecordslimit および --searchtimelimit のオプションを追加します。以下に例を示します。

    $ ipa config-mod --searchrecordslimit=500 --searchtimelimit=5
    Copy to Clipboard Toggle word wrap
  3. 特定のクエリーに対してのみ 一時的に 制限を調整するには、コマンドに --sizelimit または --timelimit オプションを追加してください。以下に例を示します。

    $ ipa user-find --sizelimit=200 --timelimit=120
    Copy to Clipboard Toggle word wrap

6.2. Web UI で検索サイズおよび時間制限の調整

IdM Web UI を使用してグローバル検索のサイズと時間制限を調整し、検索のパフォーマンスと応答性を最適化できます。

手順

  1. IdM Web UI にログインします。
  2. IPA Server をクリックします。
  3. IPA Server タブで、Configuration をクリックします。
  4. Search Options エリアに必要な値を設定します。

    デフォルト値は以下の通りです。

    • 検索サイズの制限 - 100 エントリー
    • 検索時間の制限 - 2 秒
  5. ページ上部にある Save をクリックします。

第7章 IdM Directory Server のパフォーマンスの調整

Directory Server のリソースと動作を制御する LDAP 属性を調整して、Identity Management のデータベースのパフォーマンスをチューニングできます。

以下の項目を微調整できます。

  • Directory Server が データをキャッシュ する方法を調整する。
  • Directory Server の リソース制限 を調整する。
  • パフォーマンスに最も影響を与える タイムアウト を調整する。
  • LDIF ファイルのカスタム Directory Server 設定を使用して IdM サーバーまたはレプリカをインストールする。

7.1. IdM Directory Server のエントリーキャッシュサイズの調整

重要

カスタム値を適用する必要性が高い場合を除き、この設定を変更しないでください。IdM Directory Server は、パフォーマンスを最適化するために、組み込みのキャッシュ自動サイズ調整機能を使用します。

nsslapd-cachememsize 属性は、エントリーキャッシュで利用可能なメモリー領域のサイズ (バイト単位) を指定します。この属性は、Directory Server が使用する物理 RAM の量を制御するための最も重要な値の 1 つです。

エントリーキャッシュサイズが小さすぎる場合、/var/log/dirsrv/slapd-<instance_name>/errors ログファイルの Directory Server エラーログに次のエラーが表示されることがあります。

REASON: entry too large (83886080 bytes) for the import buffer size (67108864 bytes).  Try increasing nsslapd-cachememsize.
Copy to Clipboard Toggle word wrap

Red Hat では、エントリーキャッシュとデータベースインデックスエントリーキャッシュをメモリー内に収めることを推奨しています。

Expand
表7.1 nsslapd-cachememsize 属性値

デフォルト値

209715200 (200 MiB)

有効な範囲

500000 - 18446744073709551615 (500 kB - (264-1))

エントリー DN の場所

cn=<database_name>,cn=ldbm database,cn=plugins,cn=config

前提条件

  • LDAP Directory Manager のパスワード

手順

  1. 自動キャッシュチューニングを無効にします。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> backend config set --cache-autosize=0
    Copy to Clipboard Toggle word wrap
  2. データベースの接尾辞と、対応するバックエンドを表示します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> backend suffix list
    cn=changelog (changelog)
    dc=example,dc=com (userroot)
    o=ipaca (ipaca)
    Copy to Clipboard Toggle word wrap

    このコマンドにより、各接尾辞の横にバックエンドデータベースが表示されます。次の手順では、接尾辞のデータベース名を使用します。

  3. データベースのエントリーキャッシュサイズを設定します。この例では、userroot データベースのエントリーキャッシュを 2 ギガバイトに設定します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> backend suffix set --cache-memsize=2147483648 userroot
    Copy to Clipboard Toggle word wrap
  4. Directory Server を再起動します。

    [root@server ~]# systemctl restart dirsrv.target
    Copy to Clipboard Toggle word wrap
  5. IdM Directory Server のパフォーマンスを監視します。改善されない場合は、この手順を繰り返して cache-memsize を別の値に調整するか、キャッシュの自動サイズ調整を再度有効にします。

検証

  • nsslapd-cachememsize 属性の値を表示し、希望の値に設定されていることを確認します。

    [root@server ~]# ldapsearch -D "cn=Directory Manager" -w <directory_manager_password> -b "cn=userroot,cn=ldbm database,cn=plugins,cn=config" | grep nsslapd-cachememsize
    nsslapd-cachememsize: 2147483648
    Copy to Clipboard Toggle word wrap

7.2. IdM Directory Server のデータベースインデックスキャッシュサイズの調整

重要

カスタム値を適用する必要性が高い場合を除き、この設定を変更しないでください。IdM Directory Server は、パフォーマンスを最適化するために、組み込みのキャッシュ自動サイズ調整機能を使用します。

nsslapd-dbcachesize 属性は、データベースインデックスが使用するメモリー量を制御します。このキャッシュサイズは、エントリーキャッシュサイズと比べ、Directory Server のパフォーマンスに与える影響は大きくありません。しかし、エントリーキャッシュサイズの設定後に使用可能な RAM がある場合は、データベースキャッシュに割り当てるメモリーの量を増やすことを推奨します。

データベースキャッシュのメモリーの上限は 1.5 GB で、これ以上の値を指定してもパフォーマンスが改善されないためです。

Expand
表7.2 nsslapd-dbcachesize 属性値

デフォルト値

10000000 (10 MB)

有効な範囲

500000 - 1610611911 (500 kB - 1.5GB)

エントリー DN の場所

cn=config,cn=ldbm database,cn=plugins,cn=config

前提条件

  • LDAP Directory Manager のパスワード

手順

  1. 自動キャッシュチューニングを無効にし、データベースキャッシュのサイズを設定します。この例では、データベースキャッシュを 256 メガバイトに設定します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> backend config set --cache-autosize=0 --dbcachesize=268435456
    Copy to Clipboard Toggle word wrap
  2. Directory Server を再起動します。

    [root@server ~]# systemctl restart dirsrv.target
    Copy to Clipboard Toggle word wrap
  3. IdM Directory Server のパフォーマンスを監視します。改善されない場合は、この手順を繰り返して dbcachesize を別の値に調整するか、キャッシュの自動サイズ調整を再度有効にします。

検証

  • nsslapd-dbcachesize 属性の値を表示し、希望の値に設定されていることを確認します。

    [root@server ~]# ldapsearch -D "cn=Directory Manager" -w <directory_manager_password> -b "cn=config,cn=ldbm database,cn=plugins,cn=config" | grep nsslapd-dbcachesize
    nsslapd-dbcachesize: 2147483648
    Copy to Clipboard Toggle word wrap
重要

パフォーマンスを最適化するには、組み込みキャッシュの自動サイジング機能を使用します。キャッシュサイズは手動で設定しないでください。

デフォルトでは、IdM Directory Server は、データベースキャッシュとエントリーキャッシュに最適なサイズを自動的に判断します。自動サイズ調整は、空きメモリーの一部だけを残し、インスタンスの起動時にサーバーのハードウェアリソースに基づいて、出たベースおよびエントリー両方のキャッシュのサイズを最適化します。

以下の手順を使用して、カスタムのデータベースキャッシュおよびエントリーキャッシュの値を元に戻し、キャッシュの自動サイズ調整機能をデフォルト値に戻します。

Expand
表7.3 nsslapd-cache-autosize 属性値

nsslapd-cache-autosize

この設定では、データベースおよびエントリーキャッシュの自動サイズ調整に割り当てる空きメモリー容量を制御します。値が 0 の場合は、自動サイズ調整が無効になります。

デフォルト値

10 (空きメモリーの 10%)

有効な範囲

0 - 100

エントリー DN の場所

cn=config,cn=ldbm database,cn=plugins,cn=config

Expand
表7.4 nsslapd-cache-autosize-split 属性値

nsslapd-cache-autosize-split

この値は、nsslapd-cache-autosize で決定する空きメモリーの割合を設定します。この値は、データベースキャッシュに使用されます。残りのメモリーはエントリーキャッシュに使用されます。

デフォルト値

25 (データベースキャッシュに 25%、エントリーキャッシュに 60%)

有効な範囲

0 - 100

エントリー DN の場所

cn=config,cn=ldbm database,cn=plugins,cn=config

前提条件

  • 以前にデータベースおよびエントリーキャッシュの自動調整を無効にしている。

手順

  1. Directory Server を停止します。

    [root@server ~]# systemctl stop dirsrv.target
    Copy to Clipboard Toggle word wrap
  2. さらに変更を加える前に、/etc/dirsrv/slapd-<instance_name>/dse.ldif ファイルをバックアップします。

    [root@server ~]# cp /etc/dirsrv/slapd-<instance_name>/dse.ldif \ /etc/dirsrv/slapd-<instance_name>/dse.ldif.bak.$(date "+%F_%H-%M-%S")
    Copy to Clipboard Toggle word wrap
  3. /etc/dirsrv/slapd-<instance_name>/dse.ldif ファイルを編集します。

    1. データベースおよびエントリーキャッシュに使用する空きシステムメモリーの割合を、デフォルトの空きメモリー 10% に戻します。

      nsslapd-cache-autosize: 10
      Copy to Clipboard Toggle word wrap
    2. データベースキャッシュのシステムメモリーから使用する割合をデフォルトの 25% に設定します。

      nsslapd-cache-autosize-split: 25
      Copy to Clipboard Toggle word wrap
  4. /etc/dirsrv/slapd-instance_name/dse.ldif ファイルへの変更を保存します。
  5. Directory Server を起動します。

    [root@server ~]# systemctl start dirsrv.target
    Copy to Clipboard Toggle word wrap

検証

  • nsslapd-cache-autosize および nsslapd-cache-autosize-split 属性の値を表示して、任意の値に設定されていることを確認します。

    [root@server ~]# ldapsearch -D "cn=Directory Manager" -w <directory_manager_password> -b "cn=config,cn=ldbm database,cn=plugins,cn=config" | grep nsslapd-cache-autosize nsslapd-cache-autosize: *10
    nsslapd-cache-autosize-split: 25
    Copy to Clipboard Toggle word wrap

7.4. IdM Directory Server の DN キャッシュサイズの調整

重要

カスタム値を適用する必要性が高い場合を除き、この設定を変更しないでください。IdM Directory Server は、パフォーマンスを最適化するために、組み込みのキャッシュ自動サイズ調整機能を使用します。

nsslapd-dncachememsize 属性は、識別名 (DN) キャッシュで利用可能なメモリー領域のサイズ (バイト単位) を指定します。DN キャッシュはデータベースのエントリーキャッシュと似ていますが、テーブルにはエントリー ID とエントリー DN のみが保存され、rename および moddn 操作のルックアップ時間を短縮できます。

Expand
表7.5 nsslapd-dncachememsize 属性値

デフォルト値

10485760 (10 MB)

有効な範囲

500000 - 18446744073709551615 (500 kB - (264-1))

エントリー DN の場所

cn=database-name,cn=ldbm database,cn=plugins,cn=config

前提条件

  • LDAP Directory Manager のパスワード

手順

  1. オプション: データベースの接尾辞とそれに対応するデータベース名を表示します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> backend suffix list
    dc=example,dc=com (userroot)
    Copy to Clipboard Toggle word wrap

    このコマンドにより、各接尾辞の横にバックエンドデータベースが表示されます。次の手順では、接尾辞のデータベース名を使用します。

  2. データベースの DN キャッシュサイズを設定します。この例では、DN キャッシュを 20 メガバイトに設定します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> backend suffix set --dncache-memsize=20971520 userroot
    Copy to Clipboard Toggle word wrap
  3. Directory Server を再起動します。

    [root@server ~]# systemctl restart dirsrv.target
    Copy to Clipboard Toggle word wrap
  4. IdM Directory Server のパフォーマンスを監視します。改善されない場合は、この手順を繰り返し、dncache-memsize を別の値に調整するか、デフォルトの 10 MB に戻します。

検証

  • nsslapd-dncachememsize 属性の新しい値を表示し、希望の値に設定されていることを確認します。

    [root@server ~]# ldapsearch -D "cn=Directory Manager" -w <directory_manager_password> -b "cn=userroot,cn=ldbm database,cn=plugins,cn=config" | grep nsslapd-dncachememsize
    nsslapd-dncachememsize: 20971520
    Copy to Clipboard Toggle word wrap

7.5. IdM Directory Server の正規化された DN キャッシュサイズの調整

重要

カスタム値を適用する必要性が高い場合を除き、この設定を変更しないでください。IdM Directory Server は、パフォーマンスを最適化するために、組み込みのキャッシュ自動サイズ調整機能を使用します。

nsslapd-ndn-cache-max-size 属性は、正規化された識別名 (NDN) を格納するキャッシュのサイズ (バイト単位) を制御します。この値を増やすと、メモリーに頻繁に使用される DN を確保します。

Expand
表7.6 nsslapd-ndn-cache-max-size 属性値

デフォルト値

20971520 (20 MB)

有効な範囲

0 - 2147483647

エントリー DN の場所

cn=config

前提条件

  • LDAP Directory Manager のパスワード

手順

  1. NDN キャッシュが有効になっていることを確認します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config get nsslapd-ndn-cache-enabled
    Enter password for cn=Directory Manager on ldap://server.example.com:
    nsslapd-ndn-cache-enabled: on
    Copy to Clipboard Toggle word wrap

    キャッシュが オフ の場合は、次のコマンドで有効にします。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config replace nsslapd-ndn-cache-enabled=on
    Enter password for cn=Directory Manager on ldap://server.example.com:
    Successfully replaced "nsslapd-ndn-cache-enabled"
    Copy to Clipboard Toggle word wrap
  2. nsslapd-ndn-cache-max-size パラメーターの現在の値を取得して、復元する必要がある場合に備え、調整を行う前にこの値をメモします。プロンプトが表示されたら、Directory Manager のパスワードを入力します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config get nsslapd-ndn-cache-max-size
    Enter password for cn=Directory Manager on ldap://server.example.com:
    nsslapd-ndn-cache-max-size: 20971520
    Copy to Clipboard Toggle word wrap
  3. nsslapd-ndn-cache-max-size 属性の値を変更します。この例では 41943040 (40 MB) に値を増やします。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config replace nsslapd-ndn-cache-max-size=41943040
    Copy to Clipboard Toggle word wrap
  4. IdM Directory Server のパフォーマンスを監視します。改善されない場合は、この手順を繰り返して、nsslapd-ndn-cache-max-size を別の値に調整するか、キャッシュの自動サイズ設定を再度有効にします。

検証

  • nsslapd-ndn-cache-max-size 属性の新しい値を表示し、希望の値に設定されていることを確認します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config get nsslapd-ndn-cache-max-size
    Enter password for cn=Directory Manager on ldap://server.example.com:
    nsslapd-ndn-cache-max-size: 41943040
    Copy to Clipboard Toggle word wrap

7.6. IdM Directory Server の最大メッセージサイズの調整

nsslapd-maxbersize 属性は、受信メッセージまたは LDAP 要求での最大許容サイズをバイト単位で設定します。要求のサイズを制限すると、さまざまな DoS 攻撃を防ぎます。

最大メッセージサイズが小さすぎる場合、/var/log/dirsrv/slapd-<instance_name>/errors にある Directory Server エラーログに次のエラーが表示されることがあります。

Incoming BER Element was too long, max allowable is 2097152 bytes. Change the nsslapd-maxbersize attribute in cn=config to increase.
Copy to Clipboard Toggle word wrap

この制限の対象は LDAP 要求の合計サイズです。たとえば、エントリーの追加要求で、要求のエントリーがデフォルトの設定値よりも大きい場合に、この追加要求は拒否されます。ただし、この制限はレプリケーションプロセスには適用されません。この属性の変更には細心の注意を払ってください。

Expand
表7.7 nsslapd-maxbersize 属性値

デフォルト値

2097152 (2 MB)

有効な範囲

0 - 2147483647 (0 から 2 GB)

エントリー DN の場所

cn=config

前提条件

  • LDAP Directory Manager のパスワード

手順

  1. nsslapd-maxbersize パラメーターの現在の値を取得して、復元する必要がある場合に備え、調整を行う前にこの値をメモします。プロンプトが表示されたら、Directory Manager のパスワードを入力します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config get nsslapd-maxbersize
    Enter password for cn=Directory Manager on ldap://server.example.com:
    nsslapd-maxbersize: 2097152
    Copy to Clipboard Toggle word wrap
  2. nsslapd-maxbersize 属性の値を変更します。この例では 4194304 (4 MB) に値を増やします。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config replace nsslapd-maxbersize=4194304
    Copy to Clipboard Toggle word wrap
  3. Directory Manager として認証し、設定の変更を行います。

    Enter password for cn=Directory Manager on ldap://server.example.com:
    Successfully replaced "nsslapd-maxbersize"
    Copy to Clipboard Toggle word wrap
  4. IdM Directory Server のパフォーマンスを監視します。改善されない場合は、この手順を繰り返し、nsslapd-maxbersize を別の値に調整するか、デフォルトの 2097152 に戻します。

検証

  • nsslapd-maxbersize 属性の値を表示し、希望の値に設定されていることを確認します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config get nsslapd-maxbersize
    Enter password for cn=Directory Manager on ldap://server.example.com:
    nsslapd-maxbersize: 4194304
    Copy to Clipboard Toggle word wrap

7.7. IdM Directory Server のファイル記述子最大数の調整

/etc/systemd/system.conf ファイルの DefaultLimitNOFILE パラメーターに値を定義できます。root 権限を持つ管理者は、setrlimit コマンドを使用して、ns-slapd プロセスの DefaultLimitNOFILE パラメーターをより低い値に設定できます。この値は /etc/systemd/system.conf の値よりも優先され、Identity Management (IdM) Directory Server (DS) によって nsslapd-maxdescriptors 属性の値として受け入れられます。

nsslapd-maxdescriptors 属性は、IdM LDAP が使用するファイル記述子の最大数 (プラットフォームに依存) を設定します。ファイル記述子は、クライアント接続、ログファイル、ソケットなどのリソースに使用されます。

/etc/systemd/system.conf または setrlimit のいずれにも値が定義されていない場合、IdM DS は nsslapd-maxdescriptors 属性を 1048576 に設定します。

IdM DS 管理者が後で nsslapd-maxdescriptors に新しい値を手動で設定した場合、IdM DS は新しい値を、setrlimit または /etc/systemd/system.conf でローカルに定義された値と比較します。その結果に応じて、以下を実行します。

  • nsslapd-maxdescriptors の新しい値がローカルで定義されている値よりも大きい場合、サーバーは新しい値の設定を拒否し、ローカルの制限値を高基準値として引き続き適用します。
  • 新しい値がローカルで定義されている値よりも小さい場合、新しい値が使用されます。

この手順では、nsslapd-maxdescriptors に新しい値を設定する方法を説明します。

前提条件

  • LDAP Directory Manager のパスワード

手順

  1. nsslapd-maxdescriptors パラメーターの現在の値を取得して、復元する必要がある場合に備え、調整を行う前にこの値をメモします。プロンプトが表示されたら、Directory Manager のパスワードを入力します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config get nsslapd-maxdescriptors
    Enter password for cn=Directory Manager on ldap://server.example.com:
    nsslapd-maxdescriptors: 4096
    Copy to Clipboard Toggle word wrap
  2. nsslapd-maxdescriptors 属性の値を変更します。この例では、値を 8192 に増やします。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config replace nsslapd-maxdescriptors=8192
    Copy to Clipboard Toggle word wrap
  3. Directory Manager として認証し、設定の変更を行います。

    Enter password for cn=Directory Manager on ldap://server.example.com:
    Successfully replaced "nsslapd-maxdescriptors"
    Copy to Clipboard Toggle word wrap
  4. IdM Directory Server のパフォーマンスを監視します。改善されない場合は、この手順を繰り返し、nsslapd-maxdescriptors を別の値に調整するか、デフォルトの 4096 に戻します。

検証

  • nsslapd-maxdescriptors 属性の値を表示し、希望の値に設定されていることを確認します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config get nsslapd-maxdescriptors
    Enter password for cn=Directory Manager on ldap://server.example.com:
    nsslapd-maxdescriptors: 8192
    Copy to Clipboard Toggle word wrap

7.8. IdM Directory Server の接続バックログサイズの調整

listen サービスは、受信接続を受け付けるソケット数を設定します。nsslapd-listen-backlog-size の値は、接続を拒否する前の sockfd ソケットのキューの最大長を設定します。

IdM 環境で大量の接続を処理する場合は、nsslapd-listen-backlog-size の値を増やすことを検討してください。

Expand
表7.8 nsslapd-listen-backlog-size 属性値

デフォルト値

キュースロット 128

有効な範囲

0 - 9223372036854775807

エントリー DN の場所

cn=config

前提条件

  • LDAP Directory Manager のパスワード

手順

  1. nsslapd-listen-backlog-size パラメーターの現在の値を取得して、復元する必要がある場合に備え、調整を行う前にこの値をメモします。プロンプトが表示されたら、Directory Manager のパスワードを入力します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config get nsslapd-listen-backlog-size
    Enter password for cn=Directory Manager on ldap://server.example.com:
    nsslapd-listen-backlog-size: 128
    Copy to Clipboard Toggle word wrap
  2. nsslapd-listen-backlog-size 属性の値を変更します。この例では、値を 192 に増やします。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config replace nsslapd-listen-backlog-size=192
    Copy to Clipboard Toggle word wrap
  3. Directory Manager として認証し、設定の変更を行います。

    Enter password for cn=Directory Manager on ldap://server.example.com:
    Successfully replaced "nsslapd-listen-backlog-size"
    Copy to Clipboard Toggle word wrap

検証

  • nsslapd-listen-backlog-size 属性の値を表示し、希望の値に設定されていることを確認します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config get nsslapd-listen-backlog-size
    Enter password for cn=Directory Manager on ldap://server.example.com:
    nsslapd-listen-backlog-size: 192
    Copy to Clipboard Toggle word wrap

7.9. IdM Directory Server のデータベースロック最大数の調整

ロックメカニズムでは、同時に実行できる Directory Server プロセスのコピー数を制御し、nsslapd-db-locks パラメーターは最大ロック数を設定します。

/var/log/dirsrv/slapd-<instance_name>/errors ログファイルに次のエラーメッセージが表示される場合は、ロックの最大数を増やしてください。

libdb: Lock table is out of available locks
Copy to Clipboard Toggle word wrap
Expand
表7.9 nsslapd-db-locks 属性値

デフォルト値

ロック数 50000

有効な範囲

0 - 2147483647

エントリー DN の場所

cn=bdb,cn=config,cn=ldbm database,cn=plugins,cn=config

前提条件

  • LDAP Directory Manager のパスワード

手順

  1. nsslapd-db-locks パラメーターの現在の値を取得して、復元する必要がある場合に備え、調整を行う前にこの値をメモします。

    [root@server ~]# ldapsearch -D "cn=Directory Manager" -w <directory_manager_password> -b "cn=bdb,cn=config,cn=ldbm database,cn=plugins,cn=config" | grep nsslapd-db-locks
    nsslapd-db-locks: 50000
    Copy to Clipboard Toggle word wrap
  2. locks 属性の値を変更します。この例では、ロックの値を 2 倍の 100000 に設定します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> backend config set --locks=100000
    Copy to Clipboard Toggle word wrap
  3. Directory Manager として認証し、設定の変更を行います。

    Enter password for cn=Directory Manager on ldap://server.example.com:
    Successfully updated database configuration
    Copy to Clipboard Toggle word wrap
  4. Directory Server を再起動します。

    [root@server ~]# systemctl restart dirsrv.target
    Copy to Clipboard Toggle word wrap

検証

  • nsslapd-db-locks 属性の値を表示し、希望の値に設定されていることを確認します。

    [root@server ~]# ldapsearch -D "cn=directory manager" -w <directory_manager_password> -b "cn=bdb,cn=config,cn=ldbm database,cn=plugins,cn=config" | grep nsslapd-db-locks
    nsslapd-db-locks: 100000
    Copy to Clipboard Toggle word wrap

7.10. IdM Directory Server の Transparent Huge Pages 機能の無効化

Linux のメモリー管理機能である Transparent Huge Pages (THP) は、RHEL ではデフォルトで有効になっています。DS にはスパースメモリーアクセスパターンがあるため、THP 機能は IdM Directory Server (DS) のパフォーマンスが低下する可能性があります。

この機能を無効にする方法は、Red Hat Directory Server ドキュメントの Transparent Huge Pages 機能の無効化 を参照してください。

7.11. IdM Directory Server の入出力ブロックタイムアウトの調整

nsslapd-ioblocktimeout 属性は、停止した LDAP クライアントへの接続が切断されるまでの時間をミリ秒単位で設定します。LDAP クライアントは、読み取りまたは書き込み操作の I/O の進捗が全くない場合には停止されたと見なされます。

nsslapd-ioblocktimeout 属性の値を減らして、できるだけ早い段階で接続のロックを解除します。

Expand
表7.10 nsslapd-ioblocktimeout 属性値

デフォルト値

10000 ミリ秒

有効な範囲

0 - 2147483647

エントリー DN の場所

cn=config

前提条件

  • LDAP Directory Manager のパスワード

手順

  1. nsslapd-ioblocktimeout パラメーターの現在の値を取得して、復元する必要がある場合に備え、調整を行う前にこの値をメモします。プロンプトが表示されたら、Directory Manager のパスワードを入力します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config get nsslapd-ioblocktimeout
    Enter password for cn=Directory Manager on ldap://server.example.com:
    nsslapd-ioblocktimeout: 10000
    Copy to Clipboard Toggle word wrap
  2. nsslapd-ioblocktimeout 属性の値を変更します。この例では、値が 8000 まで減らします。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config replace nsslapd-ioblocktimeout=8000
    Copy to Clipboard Toggle word wrap
  3. Directory Manager として認証し、設定の変更を行います。

    Enter password for cn=Directory Manager on ldap://server.example.com:
    Successfully replaced "nsslapd-ioblocktimeout"
    Copy to Clipboard Toggle word wrap
  4. IdM ディレクトリーサーバーのパフォーマンスを監視します。改善されない場合は、この手順を繰り返し、nsslapd-ioblocktimeout を別の値に調整するか、デフォルトの 10000 に戻します。

検証

  • nsslapd-ioblocktimeout 属性の値を表示し、希望の値に設定されていることを確認します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config get nsslapd-ioblocktimeout
    Enter password for cn=Directory Manager on ldap://server.example.com:
    nsslapd-idletimeout: 8000
    Copy to Clipboard Toggle word wrap

7.12. IdM Directory Server のアイドル接続タイムアウトの調整

nsslapd-idletimeout 属性は、アイドル状態の LDAP クライアントの接続が IdM サーバーにより切断されるまでの時間を秒単位で設定します。値が 0 の場合は、サーバーはアイドル状態の接続を切断しません。

Red Hat では、古い接続だけを閉じ、アクティブな接続を途中で閉じないようにこの値を調整することを推奨しています。

Expand
表7.11 nsslapd-idletimeout 属性値

デフォルト値

3600(1 時間)

有効な範囲

0 - 2147483647

エントリー DN の場所

cn=config

前提条件

  • LDAP Directory Manager のパスワード

手順

  1. nsslapd-idletimeout パラメーターの現在の値を取得して、復元する必要がある場合に備え、調整を行う前にこの値をメモします。プロンプトが表示されたら、Directory Manager のパスワードを入力します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config get nsslapd-idletimeout
    Enter password for cn=Directory Manager on ldap://server.example.com:
    nsslapd-idletimeout: 3600
    Copy to Clipboard Toggle word wrap
  2. nsslapd-idletimeout 属性の値を変更します。この例では、値が 1800 (30 分) まで減らします。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config replace nsslapd-idletimeout=1800
    Copy to Clipboard Toggle word wrap
  3. Directory Manager として認証し、設定の変更を行います。

    Enter password for cn=Directory Manager on ldap://server.example.com:
    Successfully replaced "nsslapd-idletimeout"
    Copy to Clipboard Toggle word wrap
  4. IdM ディレクトリーサーバーのパフォーマンスを監視します。改善されない場合は、この手順を繰り返し、nsslapd-idletimeout を別の値に調整するか、デフォルトの 3600 に戻します。

検証

  • nsslapd-idletimeout 属性の値を表示し、希望の値に設定されていることを確認します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> config get nsslapd-idletimeout
    Enter password for cn=Directory Manager on ldap://server.example.com:
    nsslapd-idletimeout: 3600
    Copy to Clipboard Toggle word wrap

7.13. レプリケーションリリースタイムアウトの調整

IdM レプリカは、別のレプリカでのレプリケーションセッション中は同時に使用できないのでロックされます。一部の環境では、大規模な更新やネットワークの輻輳により、レプリカが長時間ロックされるため、レプリケーションのレイテンシーが増加します。

repl-release-timeout パラメーターを調整すると、一定時間が経過すると、レプリカをリリースできます。Red Hat では、この値を 30 - 120 に設定することを推奨しています。

  • 値を低く設定しすぎると、レプリカ間でお互いを取得しあうため、大規模な更新を送信できなくなります。
  • タイムアウトが長くなると、サーバーが長時間 1 つのレプリカだけにアクセスするのが最適な場合など、トラフィックが多い状況が改善されますが、120 秒よりも長く設定すると、レプリケーションに時間がかかります。
Expand
表7.12 repl-release-timeout 属性値

デフォルト値

60

有効な範囲

0 - 2147483647

推奨される範囲

30 - 120

前提条件

  • LDAP Directory Manager のパスワード

手順

  1. データベースの接尾辞と、対応するバックエンドを表示します。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> backend suffix list
    cn=changelog (changelog)
    dc=example,dc=com (userroot)
    o=ipaca (ipaca)
    Copy to Clipboard Toggle word wrap

    このコマンドにより、接尾辞の横にバックエンドデータベースの名前が表示されます。次の手順でこの接尾辞名を使用します。

  2. メインの userroot データベースの repl-release-timeout 属性の値を変更します。この例では、値を 90 秒に増やします。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> replication set --suffix="dc=example,dc=com" --repl-release-timeout=90
    Copy to Clipboard Toggle word wrap
  3. Directory Manager として認証し、設定の変更を行います。

    Enter password for cn=Directory Manager on ldap://server.example.com:
    Successfully replaced "repl-release-timeout"
    Copy to Clipboard Toggle word wrap
  4. オプション: IdM 環境で IdM 認証局 (CA) を使用している場合は、CA データベースの repl-release-timeout 属性の値を変更できます。この例では、値を 90 秒に増やします。

    [root@server ~]# dsconf -D "cn=Directory Manager" ldap://<server_fqdn> replication set *--suffix="o=ipaca" --repl-release-timeout=90*
    Enter password for cn=Directory Manager on ldap://server.example.com:
    Successfully replaced "repl-release-timeout"
    Copy to Clipboard Toggle word wrap
  5. Directory Server を再起動します。

    [root@server ~]# systemctl restart dirsrv.target
    Copy to Clipboard Toggle word wrap
  6. IdM Directory Server のパフォーマンスを監視します。改善されない場合は、この手順を繰り返し、repl-release-timeout を別の値に調整するか、デフォルトの 60 秒に戻します。

検証

  • nsds5ReplicaReleaseTimeout 属性の値を表示し、希望の値に設定されていることを確認します。

    [root@server ~]# ldapsearch -D "cn=Directory Manager" -w <directory_manager_password> -b "cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" | grep nsds5ReplicaReleaseTimeout
    nsds5ReplicaReleaseTimeout: 90
    Copy to Clipboard Toggle word wrap
注記

この例では、接尾辞の識別名は dc=example,dc=com ですが、ldapsearch コマンドでは等号記号 (=) とコンマ (,) をエスケープする必要があります。

接尾辞 DN を cn=dc\3Dexample\2Cdc\3Dcom に変換します。ここでは、以下のエスケープ文字を使用します。

  • =\3D に、
  • ,\2C に置き換えます。

第8章 KDC のパフォーマンスの調整

ユーザー、ホスト、およびサービスの認証を担当する Kerberos Key Distribution Center (KDC) のパフォーマンスを最適化するには、デプロイメントのトラフィックパターンに基づいて主なパラメーターを調整します。

8.1. KDC リッスンキューの長さの調整

/var/kerberos/krb5kdc/kdc.conf ファイルの [kdcdefaults] セクションで kdc_tcp_listen_backlog オプションを設定することにより、KDC デーモンのリッスンキューの長さのサイズを調整できます。5 のデフォルト値は、大量の Kerberos トラフィックが発生する IdM デプロイメントでは低すぎる可能性がありますが、この値を高く設定しすぎるとパフォーマンスが低下します。

Expand

デフォルト値

5

有効な範囲

1 - 10

手順

  1. テキストエディターで /var/kerberos/krb5kdc/kdc.conf ファイルを開きます。
  2. TCP リッスンバックログを 7 などの目的の値に設定します。

    [kdcdefaults]
     ...
     kdc_tcp_listen_backlog = 7
    Copy to Clipboard Toggle word wrap
  3. /var/kerberos/krb5kdc/kdc.conf ファイルを保存して閉じます。
  4. KDC を再起動して、新しい設定を読み込みます。

8.2. レルムごとの KDC の動作制御オプション

KDC は認証の成功および失敗後にデータベースに書き込み、各 Kerberos レルムのユーザーアカウントのロックとロック解除を追跡します。/etc/krb5.conf ファイルの [dbmodules] セクションで以下のオプションを調整すると、KDC の情報の書き込みの頻度を最小限して、パフォーマンスを向上させることができます。

disable_last_success

true に設定すると、事前認証が必要なプリンシパルエントリーの 最後の正常な認証 フィールドまで KDC の更新が行われないようにします。

Expand

デフォルト値

false

有効な範囲

true または false

disable_lockout

true に設定すると、事前認証が必要なプリンシパルエントリーの 最後に失敗した認証パスワードの失敗試行回数 フィールドまで KDC の更新が行われないようにします。このフラグを設定するとパフォーマンスが向上しますが、アカウントロックアウトを無効にすると、セキュリティーリスクと見なされる可能性があります。

Expand

デフォルト値

false

有効な範囲

true または false

8.3. レルムごとの KDC 設定の調整

/etc/krb5.conf ファイルを変更して、特定の Kerberos レルムの KDC 設定を調整します。

手順

  1. テキストエディターで /etc/krb5.conf ファイルを開きます。
  2. [dbmodules] セクションとそれぞれの Kerberos レルムに、オプションと任意の値を指定します。この例では、EXAMPLE.COM の <kerberos_realm>disabled_last_success 変数を設定しています。

    [dbmodules]
        <kerberos_realm> = {
            disable_last_success = true
        }
    Copy to Clipboard Toggle word wrap
  3. /etc/krb5.conf ファイルを保存して閉じます。
  4. KDC を再起動して、新しい設定を読み込みます。

8.4. krb5kdc プロセス数の調整

Key Distribution Center (KDC) が着信接続を処理するために起動するプロセスの数を手動で調整できます。

デフォルトでは、IdM インストーラーは CPU コアの数を検出し、その値を /etc/sysconfig/krb5kdc ファイルに入力します。たとえば、ファイルには次のエントリーが含まれている場合があります。

KRB5KDC_ARGS='-w 2'
[...]
Copy to Clipboard Toggle word wrap

この例では、KRB5KDC_ARGS パラメーターを -w 2 に設定すると、KDC は 2 つの別個のプロセスを開始して、メインプロセスからの着信接続を処理します。特に、要件に基づいて仮想 CPU の数を簡単に追加または削除できる仮想環境では、この値を調整することが推奨されます。ポート 88 の TCP/IP キューが増え続けてパフォーマンスの問題が発生したり、IdM サーバーが応答しなくなったりするのを防ぐには、KRB5KDC_ARGS パラメーターを手動で高い値に設定して、より多くのプロセスをシミュレートします。

手順

  1. /etc/sysconfig/krb5kdc ファイルをテキストエディターで開きます。
  2. KRB5KDC_ARGS パラメーターの値を指定します。この例では、プロセスの数を 10 に設定しています。

    KRB5KDC_ARGS='-w 10'
    [...]
    Copy to Clipboard Toggle word wrap
  3. /etc/sysconfig/krb5kdc ファイルを保存して閉じます。
  4. systemd 設定をリロードします。

    # systemctl daemon-reload
    Copy to Clipboard Toggle word wrap
  5. krb5kdc サービスを再起動します。

    # systemctl restart krb5kdc.service
    Copy to Clipboard Toggle word wrap
注記

IdM Healthcheck ユーティリティーを使用して、KDC が最適な数のワーカープロセスを使用するように設定されていることを確認できます。IdM Healthcheck を使用した KDC ワーカープロセスの最適な数の検証 を参照してください。

第9章 大規模な IdM-AD 信頼デプロイメントのための SSSD パフォーマンスの調整

ユーザーおよびグループ情報の取得は、特に AD (System Security Services Daemon) ドメイン、つまり大規模な Active Directory (AD) ドメインへの信頼を持つ IdM デプロイメントでは、データ集中型の操作です。SSSD がアイデンティティプロバイダーから取得する情報とその期間を調整することで、このパフォーマンスを向上させることができます。

9.1. 大規模な IdM-AD 信頼デプロイメント向けの IdM サーバーでの SSSD の調整

IdM サーバーの SSSD サービスの設定にチューニングオプションを適用して、大規模な AD 環境から情報を取得する際の応答時間を改善します。

前提条件

  • /etc/sssd/sssd.conf 設定ファイルを編集するには、root パーミッションが必要です。

手順

  1. テキストエディターで /etc/sssd/sssd.conf 設定ファイルを開きます。
  2. Identity Management (IdM) ドメインの [domain] セクションに次のオプションを追加します。

    [domain/<idm_domain_name>]
    ignore_group_members = true
    subdomain_inherit = ignore_group_members
    ...
    Copy to Clipboard Toggle word wrap
    注記

    subdomain_inherit オプションに指定した設定は、メイン (IdM) ドメインと信頼された AD ドメインの両方に適用されます。

  3. サーバーの /etc/sssd/sssd.conf ファイルを保存して閉じます。
  4. SSSD サービスを再起動して、設定の変更を読み込みます。

    [root@client ~]# systemctl restart sssd
    Copy to Clipboard Toggle word wrap

9.2. IdM サーバーでの ipa-extdom プラグインの設定タイムアウトの調整

IdM クライアントは Active Directory (AD) からユーザーとグループに関する情報を直接受信できないため、IdM サーバーは ipa-extdom プラグインを使用して AD ユーザーとグループに関する情報を受信し、その情報は要求元のクライアントに転送されます。

ipa-extdom プラグインは、AD ユーザーのデータに要求を SSSD に送信します。情報が SSSD キャッシュにない場合、SSSD は AD ドメインコントローラー (DC) にデータを要求します。config タイムアウト値を調整できます。これは、プラグインが接続をキャンセルして発信者にタイムアウトエラーを返す前に、ipa-extdom プラグインが SSSD からの応答を待機する時間を定義します。デフォルト値は 10000 ミリ秒 (10 秒) です。

次の例では、設定タイムアウトを 20 秒 (20000 ミリ秒) に調整します。

警告

設定タイムアウトを調整するときは注意してください。

  • 設定する値が小さすぎる (例: 500 ミリ秒) と、SSSD に応答するのに十分な時間がない可能性があり、要求は常にタイムアウトを返します。
  • 設定する値が大きすぎる (例: 30000 ミリ秒 (30 秒)) と、1 つの要求が、この期間、SSSD への接続をブロックする可能性があります。一度に SSSD に接続できるのは 1 つのスレッドであるため、プラグインからの他のリクエストはすべて待機する必要があります。
  • IdM クライアントから送信された要求が多い場合、IdM サーバー上の Directory Server 用に設定された使用可能なすべてのワーカーをブロックできます。その結果、サーバーはしばらくの間、どのような種類の要求にも応答できない可能性があります。

以下の状況で設定のタイムアウトを変更します。

  • AD ユーザーおよびグループに関する情報を要求する際に、独自の検索タイムアウトが発生する前に IdM クライアントが頻繁にタイムアウトエラーを受け取ると、設定のタイムアウト値が 小さすぎ ます。
  • IdM サーバーで Directory Server がロックされていることが多く、pstack ユーティリティーは、この時点で多数またはすべてのワーカースレッドが ipa-extdom 要求を処理していることを報告する場合は、値が 大きすぎ ます。

前提条件

  • LDAP Directory Manager のパスワード

手順

  • 次のコマンドを使用して、設定タイムアウトを 20000 ミリ秒に調整します。

    # ldapmodify -D "cn=Directory Manager" -W
    dn: cn=ipa_extdom_extop,cn=plugins,cn=config
    changetype: modify
    replace: ipaExtdomMaxNssTimeout
    ipaExtdomMaxNssTimeout: 20000
    Copy to Clipboard Toggle word wrap

9.3. IdM サーバー上の ipa-extdom プラグインの最大バッファーサイズの調整

IdM クライアントは Active Directory (AD) からユーザーとグループに関する情報を直接受信できないため、IdM サーバーは ipa-extdom プラグインを使用して AD ユーザーとグループに関する情報を受信し、その情報は要求元のクライアントに転送されます。

ipa-extdom プラグインの最大バッファーサイズを調整できます。これにより、SSSD が受信するデータを保存できるバッファーのサイズが調整されます。バッファーが小さすぎると、SSSD は ERANGE エラーを返し、プラグインはより大きなバッファーで要求を再試行します。デフォルトのバッファーサイズは 134217728 バイト (128 MB) です。

次の例では、最大バッファーサイズを 256 MB (268435456 バイト) に調整します。

前提条件

  • LDAP Directory Manager のパスワード

手順

  • 次のコマンドを使用して、最大バッファーサイズを 268435456 バイトに設定します。

    # ldapmodify -D "cn=Directory Manager" -W
    dn: cn=ipa_extdom_extop,cn=plugins,cn=config
    changetype: modify
    replace: ipaExtdomMaxNssBufSize
    ipaExtdomMaxNssBufSize: 268435456
    Copy to Clipboard Toggle word wrap

9.4. IdM サーバー上の ipa-extdom プラグインの最大インスタンス数の調整

IdM クライアントは Active Directory (AD) からユーザーとグループに関する情報を直接受信できないため、IdM サーバーは ipa-extdom プラグインを使用して AD ユーザーとグループに関する情報を受信し、その情報は要求元のクライアントに転送されます。

デフォルトでは、ipa-extdom プラグインは LDAP ワーカースレッドの最大 80% を使用して IdM クライアントからのリクエストを処理するように設定されています。IdM クライアントの SSSD サービスが AD 信頼ユーザーおよびグループに関する大量の情報を要求した場合に、LDAP スレッドのほとんどを使用すると、この操作によって LDAP サービスが停止する可能性があります。このような問題が発生した場合、AD ドメインの SSSD ログファイル (/var/log/sssd/sssd__<your-ad-domain-name.com>_.log) に同様のエラーが表示されることがあります。

(2022-05-22  5:00:13): [be[ad.example.com]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed.
(2022-05-22  5:00:13): [be[ad.example.com]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed.
(2022-05-22  5:00:13): [be[ad.example.com]] [ipa_s2n_exop_done] (0x0040): ldap_extended_operation result: Server is busy(51), Too many extdom instances running.
Copy to Clipboard Toggle word wrap

ipaExtdomMaxInstances オプションの値を設定することで、ipa-extdom インスタンスの最大数を調整できます。この値は、0 より大きく、ワーカースレッドの総数より小さい整数でなければなりません。

前提条件

  • LDAP Directory Manager のパスワード

手順

  1. ワーカースレッドの総数を取得します。

    # ldapsearch -xLLLD cn=Directory\ Manager -W -b cn=config -s base nsslapd-threadnumber
    Enter LDAP Password:
    dn: cn=config
    nsslapd-threadnumber: 16
    Copy to Clipboard Toggle word wrap

    これは、ipaExtdomMaxInstances の現在の値が 13 であることを意味します。

  2. インスタンスの最大数を調整します。この例では、値を 14 に変更します。

    # ldapmodify -D "cn=Directory Manager" -W
    dn: cn=ipa_extdom_extop,cn=plugins,cn=config
    changetype: modify
    replace: ipaExtdomMaxInstances
    ipaExtdomMaxInstances: 14
    Copy to Clipboard Toggle word wrap
  3. ipaExtdomMaxInstances の現在の値を取得します。

    # ldapsearch -xLLLD "cn=Directory Manager" -W -b "cn=ipa_extdom_extop,cn=plugins,cn=config" |grep ipaextdommaxinstances
    
    Enter LDAP Password:
    
    ipaextdommaxinstances: 14
    Copy to Clipboard Toggle word wrap
  4. IdM Directory Server のパフォーマンスを監視します。改善されない場合は、この手順を繰り返して、ipaExtdomMaxInstances 変数の値を調整します。

9.5. IdM-AD 信頼デプロイメント向けに IdM サービス SSSD の調整

IdM クライアントの SSSD サービス設定にチューニングオプションを適用して、大規模な AD 環境から情報を取得する際の応答時間を改善します。

前提条件

  • /etc/sssd/sssd.conf 設定ファイルを編集するには、root パーミッションが必要です。

手順

  1. キャッシュされていないログイン 1 回にかかる秒数を決定します。

    1. IdM クライアントで SSSD キャッシュをクリアします。

      [root@client_hostname ~]# sss_cache -E
      Copy to Clipboard Toggle word wrap
    2. time コマンドを使用して、AD ユーザーのログイン時間を測定します。IdM クライアントから、同じホストにログインして、AD ユーザーとしてローカルで認証します。

      [root@client_hostname ~]# time ssh <ad_username>@<ad_domain>@<client_fqdn>
      Copy to Clipboard Toggle word wrap
    3. できるだけ早くパスワードを入力します。

      Password:
      Last login: Sat Jan 23 06:29:54 2021 from 10.0.2.15
      [ad_username@ad_domain@client_fqdn ~]$
      Copy to Clipboard Toggle word wrap
    4. できるだけ早くログアウトして経過時間を表示します。この例では、キャッシュされていないログインに約 9 秒かかります。

      [ad_username@ad_domain@client_fqdn /]$ exit
      logout
      Connection to client.example.com closed.
      
      real 0m8.755s
      user    0m0.017s
      sys     0m0.013s
      Copy to Clipboard Toggle word wrap
  2. テキストエディターで /etc/sssd/sssd.conf 設定ファイルを開きます。
  3. Active Directory ドメインの [domain] セクションに以下のオプションを追加します。pam_id_timeout オプションおよび krb5_auth_timeout オプションを、キャッシュを使用しないログインにかかる秒数に設定します。AD ドメインにドメインセクションがない場合は作成します。

    [domain/<idm_domain>/<ad_domain>]
    krb5_auth_timeout = 9
    ldap_deref_threshold = 0
    ...
    Copy to Clipboard Toggle word wrap
  4. [pam] セクションに次のオプションを追加します。

    [pam]
    pam_id_timeout = 9
    Copy to Clipboard Toggle word wrap
  5. サーバーの /etc/sssd/sssd.conf ファイルを保存して閉じます。
  6. SSSD サービスを再起動して、設定の変更を読み込みます。

    [root@client_hostname ~]# systemctl restart sssd
    Copy to Clipboard Toggle word wrap

9.6. tmpfs での SSSD キャッシュのマウント

SSSD (System Security Services Daemon) は、常に LDAP オブジェクトをキャッシュに書き込みます。これらの内部 SSSD トランザクションは、データをディスクに書き込みますが、これは Random-Access Memory (RAM) からの読み取りと書き込みよりもはるかに遅くなります。

このパフォーマンスを改善するには、RAM に SSSD キャッシュをマウントします。

留意事項

  • SSSD キャッシュが RAM にある場合には、再起動後にキャッシュされた情報は保持されません。
  • IdM サーバーの SSSD インスタンスは、同じホストの Directory Server への接続が切断されないので、IdM サーバーではこの変更を安全に実行できます。
  • IdM クライアントでこの調整を実行し、IdM サーバーへの接続が切断されると、再起動後のユーザー認証は、接続を再確立するまでできません。

前提条件

  • /etc/fstab 設定ファイルを編集するには、root 権限が必要になります。

手順

  1. tmpfs 一時ファイルシステムを作成します。

    1. SSSD ユーザーが config.ldb ファイルを所有していることを確認します。

      # ls -al /var/lib/sss/db/config.ldb
      -rw-------. 1 sssd sssd 1286144 Jun  8 16:41 /var/lib/sss/db/config.ldb
      Copy to Clipboard Toggle word wrap
    2. 次のエントリーを /etc/fstab ファイルに 1 行で追加します。

      tmpfs /var/lib/sss/db/ tmpfs size=300M,mode=0700,uid=sssd,gid=sssd,rootcontext=system_u:object_r:sssd_var_lib_t:s0 0 0
      Copy to Clipboard Toggle word wrap

      この例では、300MB キャッシュを作成します。IdM および AD ディレクトリーサイズにあわせて size を調整します (LDAP エントリー 1 万につき 100 MB 想定)。

  2. 新しい SSSD キャッシュディレクトリーをマウントします。

    [root@host ~]# mount /var/lib/sss/db/
    Copy to Clipboard Toggle word wrap
  3. SSSD を再起動して、この設定の変更を反映します。

    [root@host ~]# systemctl restart sssd
    Copy to Clipboard Toggle word wrap

/etc/sssd/sssd.conf 設定ファイルで次のオプションを使用して、IdM-AD の信頼が大規模にデプロイされている場合に、IdM サーバーおよびクライアントで SSSD のパフォーマンスを調整できます。

9.7.1. IdM サーバーのチューニングオプション

ignore_group_members

ユーザーの認証および承認時には、グループに所属する全ユーザーではなく、あるユーザーがどのグループに所属するかを把握することが重要です。ignore_group_memberstrue に設定すると、SSSD はメンバーではなくグループオブジェクトに関する情報のみを取得するので、パフォーマンスが大幅に向上します。

注記

id user@ad-domain.com コマンドはそのまま正しいグループリストを返しますが、getent group ad-group@ad-domain.com は空のリストを返します。

Expand

デフォルト値

false

推奨値

true

注記

デプロイメントで compat ツリーを持つ IdM サーバーがある場合は、このオプションを true に設定しないでください。

subdomain_inherit

subdomain_inherit オプションを使用すると、ignore_group_members の設定を、信頼できる AD ドメインの設定に適用できます。subdomain_inherit オプションに記載されている設定は、メイン (IdM) ドメインと AD サブドメインの両方に適用されます。

Expand

デフォルト値

none

推奨値

subdomain_inherit = ignore_group_members

9.7.2. IdM クライアントのチューニングオプション

pam_id_timeout

このパラメーターは、ID ルックアップ時にアイデンティティープロバイダーへのラウンドトリップが過剰になることを回避するために PAM セッションからの結果がキャッシュされる時間を制御します。デフォルト値の 5 秒を使用する場合には、複雑なグループメンバーシップが IdM サーバーおよび IdM クライアント側で設定されていない環境では不十分な可能性があります。Red Hat は、キャッシュされていない場合の 1 回のログインにかかる秒数に、pam_id_timeout を設定することを推奨します。

Expand

デフォルト値

5

推奨値

キャッシュされていないログインが 1 回にかかる秒数

krb5_auth_timeout

krb5_auth_timeout を増やすと、ユーザーが多数のグループに所属する環境で、複雑なグループ情報を処理する時間数を増やすことができます。Red Hat は、キャッシュされていない場合の 1 回のログインにかかる秒数に、このタイムアウトの値を設定することを推奨します。

Expand

デフォルト値

6

推奨値

キャッシュされていないログインが 1 回にかかる秒数

ldap_deref_threshold

逆参照ルックアップを使用して、1 回の LDAP 呼び出しで全グループメンバーを取得します。ldap_deref_threshold の値は、内部キャッシュに含まれないグループメンバー数を指定し、逆参照ルックアップをトリガーします。見つからないメンバーが少ない場合には、個別に検索します。大規模な環境では、逆参照ルックアップに時間がかかり、パフォーマンスが低下する可能性があります。逆参照検索を無効にするには、このオプションを 0 に設定します。

Expand

デフォルト値

10

推奨値

0

第10章 WSGI プロセスのチューニング

長時間実行される API プロセスが原因で要求が失敗する場合は、それらの API プロセスをチューニングすると効果が得られます。

デフォルトでは、IPA は 64 ビットシステム上の API サービスに Web Server Gateway Interface (WSGI) プロセスを 4 つ割り当てます。この 4 プロセスというデフォルトの制限は、メモリー節約のために実装されています。WSGI プロセスの数を増やすと、CPU 使用率とメモリー消費量は増加しますが、より多くの要求を受け入れることができます。デフォルトでは、IPA は WSGI プロセスごとに約 100 - 110 MB の常駐メモリーを API に使用します。これを推奨される上限である 16 プロセスに調整すると、消費量が約 1.3 GB になります。

手順

  • /etc/httpd/conf.d/ipa.conf ファイルの processes 値を変更します。

    WSGIDaemonProcess ipa processes=<4> threads=1 maximum-requests=500 \
    Copy to Clipboard Toggle word wrap

長時間実行される API エンドポイントは、いずれもチューニングによる効果を得ることができます。このチューニングの決定はユーザーが行う必要があります。

たとえば、OpenStack インストールは、複数のサービスを含む複数のコントローラーで構成されています。各サービスは、すべての内部通信が Transport Layer Security (TLS) 経由で行われるように、証明書を要求します。コントローラーまたはコンピュートノードをインストールまたは更新するときに、これらの証明書が要求または更新されることがあります。複数のコントローラーまたはコンピュートノードが関係する状況では、証明書要求の量がかなり多くなることがあります。これらの要求は自動化されているため、同時またはほぼ同時に発生します。WSGI スレッドの数を増やすと、インストールを完了することができます。

10.1. IPA サーバーパフォーマンスの向上のための CPU 使用率の最適化

大量の証明書発行タスク中にパフォーマンスの制限が発生する場合は、CPU と Web Server Gateway Interface (WSGI) プロセスの数を調整すると、IPA サーバーの同時リクエスト処理能力が大幅に向上します。

4 つの CPU で設定されたサーバーに、70 台のクライアントがそれぞれ 7 つの証明書 (合計 490 の証明書) を要求したところ、要求量がサーバーの処理能力を超えたため、サーバータイムアウトが発生しました。

CPU の数を 8 に増やし、それに合わせて WSGI プロセスの数を 8 にすると、証明書処理能力が 630 個の証明書まで増加しました。CPU の数を 100% 増やしても、増加した処理能力は 4 CPU 設定に比べて 28% でした。CPU の数をさらに 16 に増やしても、WSGI プロセスが 8 つの場合、パフォーマンスは向上しませんでした。ただし、WSGI プロセスの数を 16 に増やすと、サーバーは 110 台のクライアントからの 770 個の証明書を処理しました。つまり、8 CPU 設定に比べて 22% の改善が見られました。

CPU の数を 2 倍にした場合、WSGI プロセスをそれに応じて調整すれば、証明書発行能力は平均 25% 増加しました。これは、ボトルネックを防ぎ、サーバーのパフォーマンスを最適化するために、CPU プロセスと WSGI プロセスの両方を一緒にスケーリングする必要性を明確に示しています。

法律上の通知

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat