レプリケーションの設定および管理

Red Hat Directory Server 12

他の Directory Server インスタンスへのデータの複製

Red Hat Customer Content Services

概要

ある Directory Server インスタンスから別の Directory Server インスタンスにデータを自動的に同期するには、単一サプライヤー、マルチサプライヤー、およびカスケードレプリケーションメカニズムを使用できます。レプリケーション変更ログを管理するには、トリミングと暗号化を使用できます。

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

Red Hat ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があればお知らせください。これを行うには、以下を行います。

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

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

    1. Bugzilla の Web サイトに移動します。
    2. Component として Documentation を使用します。
    3. Description フィールドに、ドキュメントの改善に向けたご提案を記入してください。ドキュメントの該当部分へのリンクも追加してください。
    4. Submit Bug をクリックします。

第1章 コマンドラインを使用した単一サプライヤーレプリケーションの設定

単一サプライヤーレプリケーション環境では、1 つの書き込み可能なサプライヤーが、データを 1 つまたは複数の読み取り専用のコンシューマーに複製します。たとえば、接尾辞が多数の検索要求を受け取るが、書き込み要求数が少ない場合などに、単一サプライヤーレプリケーションを設定します。負荷を分散するために、クライアントは読み取り専用のコンシューマーで接尾辞を検索し、書き込み要求をサプライヤーに送信します。

本セクションでは、既存の Directory Server インスタンスが supplier.example.com という名前のホストで実行されていることを前提としています。このホストは、レプリケーショントポロジーに設定されるサプライヤーとして機能します。手順では、consumer.example.com という名前の読み取り専用コンシューマーをトポロジーに追加する方法と、dc=example,dc=com 接尾辞に単一サプライヤーレプリケーションを設定する方法を説明します。

1.1. コマンドラインを使用した新しいコンシューマーの準備

consumer.example.com ホストを準備するには、レプリケーションを有効にします。このプロセスでは、以下を行います。

  • レプリケーショントポロジーでこのサーバーのロールを設定します。
  • レプリケートされる接尾辞を定義します。
  • このホストへの接続にサプライヤーが使用するレプリケーションマネージャーアカウントを作成します。

レプリケーショントポロジーに追加するコンシューマーで、以下の手順を実行します。

前提条件

  • Directory Server インスタンスがインストールされている。
  • dc=example,dc=com 接尾辞のデータベースが存在する。

手順

  • dc=example,dc=com 接尾辞のレプリケーションを有効にします。

    # dsconf -D "cn=Directory Manager" ldap://consumer.example.com replication enable --suffix "dc=example,dc=com" --role "consumer" --bind-dn "cn=replication manager,cn=config" --bind-passwd "password"

    このコマンドは、consumer.example.com ホストを dc=example,dc=com 接尾辞のコンシューマーとして設定します。また、このコマンドは、指定したパスワードを持つ cn=replication manager,cn=config ユーザーを作成し、このアカウントが接尾辞の変更をこのホストに複製するのを許可します。

検証

  • レプリケーション設定を表示します。

    # dsconf -D "cn=Directory Manager" ldap://consumer.example.com replication get --suffix "dc=example,dc=com"
    dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
    ...
    nsDS5ReplicaBindDN: cn=replication manager,cn=config
    nsDS5ReplicaRoot: dc=example,dc=com
    nsDS5ReplicaType: 2
    ...

    これらのパラメーターは以下を示しています。

    • nsDS5ReplicaBindDN はレプリケーションマネージャーアカウントを指定します。
    • nsDS5ReplicaRoot は、レプリケートされる接尾辞を設定します。
    • nsDS5ReplicaType2 に設定して、このホストがコンシューマーであることを定義します。

1.2. コマンドラインを使用した、既存サーバーのコンシューマーに対するサプライヤーとしての設定

supplier.example.com ホストを準備するには、次のことを行う必要があります。

  • 接尾辞のレプリケーションを有効にします。
  • コンシューマーへのレプリカ合意を作成します。
  • コンシューマーを初期化します。

レプリケーショントポロジーの既存のサプライヤーでこの手順を実行します。

前提条件

  • コンシューマーで dc=example,dc=com 接尾辞のレプリケーションを有効にしている。

手順

  1. dc=example,dc=com 接尾辞のレプリケーションを有効にします。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com replication enable --suffix "dc=example,dc=com" --role "supplier" --replica-id 1

    このコマンドは、supplier.example.com ホストを dc=example,dc=com 接尾辞のサプライヤーとして設定し、このエントリーのレプリカ ID を 1 に設定します。

    重要

    トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。

  2. レプリカ合意を追加し、コンシューマーを初期化します。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt create --suffix "dc=example,dc=com" --host "consumer.example.com" --port 389 --conn-protocol=LDAP --bind-dn "cn=replication manager,cn=config" --bind-passwd "password" --bind-method=SIMPLE --init example-agreement

    このコマンドは、example-agreement という名前のレプリカ合意を作成します。レプリカ合意は、コンシューマーのホスト名、プロトコル、このコンシューマーへのデータの接続や複製時にサプライヤーが使用する認証情報などの設定を定義します。

    この合意の作成後、Directory Server は consumer.example.com を初期化します。複製するデータ量によっては、初期化に時間がかかる場合があります。

検証

  1. レプリケーション設定を表示します。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com replication get --suffix "dc=example,dc=com"
    dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
    ...
    nsDS5ReplicaRoot: dc=example,dc=com
    nsDS5ReplicaType: 3
    ...

    これらのパラメーターは以下を示しています。

    • nsDS5ReplicaRoot は、レプリケートされる接尾辞を設定します。
    • nsDS5ReplicaType3 に設定して、このホストがサプライヤーであることを定義します。
  2. 初期化が成功したかどうかを確認します。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt init-status --suffix "dc=example,dc=com" example-agreement
    Agreement successfully initialized.
  3. レプリケーションのステータスを表示します。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt status --suffix "dc=example,dc=com" example-agreement
    Status For Agreement: "example-agreement" (consumer.example.com:389)
    Replica Enabled: on
    Update In Progress: FALSE
    Last Update Start: 20210330075608Z
    Last Update End: 20210330075608Z
    Number Of Changes Sent: 1:3/0
    Number Of Changes Skipped: None
    Last Update Status: Error (0) Replica acquired successfully: Incremental update succeeded
    Last Init Start: 20210330074603Z
    Last Init End: 20210330074606Z
    Last Init Status: Error (0) Total update succeeded
    Reap Active: 0
    Replication Status: Not in Synchronization: supplier (6062d73c000000010000) consumer (Unavailable) State (green) Reason (error (0) replica acquired successfully: incremental update succeeded)
    Replication Lag Time: Unavailable

    Replication Status フィールドおよび Last Update Status フィールドを確認します。

トラブルシューティング

  1. デフォルトでは、サーバー上のすべての合意に対するレプリケーションアイドルタイムアウトは 1 時間です。タイムアウトが原因で大規模なデータベースの初期化が失敗する場合は、nsslapd-idletimeout パラメーターをより高い値に設定します。たとえば、パラメーターを 7200(2 時間) に設定するには、次のコマンドを実行します。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com config replace nsslapd-idletimeout=7200

    無制限の期間を設定するには、nsslapd-idletimeout0 に設定します。

第2章 Web コンソールを使用した単一サプライヤーレプリケーションの設定

単一サプライヤーレプリケーション環境では、1 つの書き込み可能なサプライヤーが、データを 1 つまたは複数の読み取り専用のコンシューマーに複製します。たとえば、接尾辞が多数の検索要求を受け取るが、書き込み要求数が少ない場合などに、単一サプライヤーレプリケーションを設定します。負荷を分散するために、クライアントは読み取り専用のコンシューマーで接尾辞を検索し、書き込み要求をサプライヤーに送信します。

本セクションでは、既存の Directory Server インスタンスが supplier.example.com という名前のホストで実行されていることを前提としています。このホストは、レプリケーショントポロジーに設定されるサプライヤーとして機能します。手順では、consumer.example.com という名前の読み取り専用コンシューマーをトポロジーに追加する方法と、dc=example,dc=com 接尾辞に単一サプライヤーレプリケーションを設定する方法を説明します。

2.1. Web コンソールを使用した新しいコンシューマーの準備

consumer.example.com ホストを準備するには、レプリケーションを有効にします。このプロセスでは、以下を行います。

  • レプリケーショントポロジーでこのサーバーのロールを設定します。
  • レプリケートされる接尾辞を定義します。
  • このホストへの接続にサプライヤーが使用するレプリケーションマネージャーアカウントを作成します。

レプリケーショントポロジーに追加するコンシューマーで、以下の手順を実行します。

前提条件

  • Directory Server インスタンスがインストールされている。
  • dc=example,dc=com 接尾辞のデータベースが存在する。
  • Web コンソールでインスタンスにログインしている。

手順

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. Enable Replication をクリックします。
  4. Replication Role フィールドで Consumer を選択し、作成するレプリケーションマネージャーアカウントおよびパスワードを入力します。

    コンシューマーでのレプリケーションの有効化

    この設定により、ホストを dc=example,dc=com 接尾辞のコンシューマーとして設定します。さらに、サーバーは指定のパスワードで cn=replication manager,cn=config ユーザーを作成し、このアカウントがこのホストに接尾辞の変更を複製することができます。

  5. Enable Replication をクリックします。

検証

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. Replica Role フィールドに値 Consumer が含まれている場合、レプリケーションが有効になり、ホストがコンシューマーとして設定されます。

2.2. Web コンソールを使用した、既存サーバーのコンシューマーに対するサプライヤーとしての設定

supplier.example.com ホストを準備するには、次のことを行う必要があります。

  • 接尾辞のレプリケーションを有効にします。
  • コンシューマーへのレプリカ合意を作成します。
  • コンシューマーを初期化します。

レプリケーショントポロジーの既存のサプライヤーでこの手順を実行します。

前提条件

  • コンシューマーで dc=example,dc=com 接尾辞のレプリケーションを有効にしている。
  • Web コンソールでインスタンスにログインしている。

手順

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. レプリケーションを有効にします。

    1. Enable Replication をクリックします。
    2. Replication Role フィールドで Supplier を選択し、レプリカ ID、レプリケーションマネージャーの認証情報を入力して、Bind Group DN フィールドを空のままにします。

      単一サプライヤーレプリケーション用にサプライヤーのレプリケーションの有効化

      この設定により、ホストを dc=example,dc=com 接尾辞のサプライヤーとして設定し、このエントリーのレプリカ ID を 1 に設定します。

      重要

      トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。

    3. Enable Replication をクリックします。
  4. レプリカ合意を追加し、コンシューマーを初期化します。

    1. Agreements タブで、Create Agreement をクリックし、次のフィールドに入力します。

      レプリカ同意の作成 (単一サプライヤー)

      この設定により、example-agreement という名前のレプリカ合意が作成されます。レプリカ合意は、コンシューマーのホスト名、プロトコル、このコンシューマーへのデータの接続や複製時にサプライヤーが使用する認証情報などの設定を定義します。

    2. Consumer Initialization フィールドで Do Online Initialization を選択し、合意の保存後にコンシューマーを自動的に初期化します。
    3. Save Agreement をクリックします。

      この合意の作成後、Directory Server は consumer.example.com を初期化します。複製するデータ量によっては、初期化に時間がかかる場合があります。

検証

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. Agreements タブで、テーブルの State 列での契約のステータスを確認。

    レプリカ合意の正常な初期化

第3章 コマンドラインを使用したマルチサプライヤーレプリケーションの設定

マルチサプライヤーレプリケーション環境では、2 つ以上の書き込み可能なサプライヤーが互いにデータを複製します。たとえば、マルチサプライヤーレプリケーションを設定してフェイルオーバー環境を提供し、複数のサーバーに負荷を分散します。その後、クライアントは読み取り/書き込みレプリカである任意のホストで読み取り/書き込み操作を実行できます。

本セクションでは、既存の Directory Server インスタンスが supplier1.example.com という名前のホストで実行されていることを前提としています。この手順では、supplier2.example.com という名前の別の読み取り/書き込みレプリカをトポロジーに追加する方法と、dc=example,dc=com 接尾辞のマルチサプライヤーレプリケーションを設定する方法を説明します。

3.1. コマンドラインを使用した新しいサプライヤーの準備

supplier2.example.com ホストを準備するには、レプリケーションを有効にします。このプロセスでは、以下を行います。

  • レプリケーショントポロジーでこのサーバーのロールを設定します。
  • レプリケートされる接尾辞を定義します。
  • このホストへの接続にサプライヤーが使用するレプリケーションマネージャーアカウントを作成します。

レプリケーショントポロジーに追加するサプライヤーで、以下の手順を実行します。

前提条件

  • Directory Server インスタンスがインストールされている。
  • dc=example,dc=com 接尾辞のデータベースが存在する。

手順

  • dc=example,dc=com 接尾辞のレプリケーションを有効にします。

    # dsconf -D "cn=Directory Manager" ldap://supplier2.example.com replication enable --suffix "dc=example,dc=com" --role "supplier" --replica-id 1 --bind-dn "cn=replication manager,cn=config" --bind-passwd "password"

    このコマンドは、supplier2.example.com ホストを dc=example,dc=com 接尾辞のサプライヤーとして設定し、このエントリーのレプリカ ID を 1 に設定します。また、このコマンドは、指定したパスワードを持つ cn=replication manager,cn=config ユーザーを作成し、このアカウントが接尾辞の変更をこのホストに複製するのを許可します。

    重要

    トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。

検証

  • レプリケーション設定を表示します。

    # dsconf -D "cn=Directory Manager" ldap://supplier2.example.com replication get --suffix "dc=example,dc=com"
    dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
    ...
    nsDS5ReplicaBindDN: cn=replication manager,cn=config
    nsDS5ReplicaRoot: dc=example,dc=com
    nsDS5ReplicaType: 3
    ...

    これらのパラメーターは以下を示しています。

    • nsDS5ReplicaBindDN はレプリケーションマネージャーアカウントを指定します。
    • nsDS5ReplicaRoot は、レプリケートされる接尾辞を設定します。
    • nsDS5ReplicaType3 に設定して、このホストがサプライヤーであることを定義します。

3.2. コマンドラインを使用した、既存サーバーの新規サーバーに対するサプライヤーとしての設定

既存のサーバー supplier1.example.com をサプライヤーとして準備するには、次のことを行う必要があります。

  • 接尾辞のレプリケーションを有効にします。
  • 新規サプライヤーへのレプリカ合意を作成します。
  • 新しいサプライヤーを初期化します。

レプリケーショントポロジーの既存のサプライヤーでこの手順を実行します。

前提条件

  • 参加するサプライヤーで dc=example,dc=com 接尾辞のレプリケーションを有効にしている。

手順

  1. dc=example,dc=com 接尾辞のレプリケーションを有効にします。

    # dsconf -D "cn=Directory Manager" ldap://supplier1.example.com replication enable --suffix "dc=example,dc=com" --role "supplier" --replica-id 2 --bind-dn "cn=replication manager,cn=config" --bind-passwd "password"

    このコマンドは、supplier1.example.com ホストを dc=example,dc=com 接尾辞のサプライヤーとして設定し、このエントリーのレプリカ ID を 2 に設定します。また、このコマンドは、指定したパスワードを持つ cn=replication manager,cn=config ユーザーを作成し、このアカウントが接尾辞の変更をこのホストに複製するのを許可します。

    重要

    トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。

  2. レプリカ合意を追加し、新規サーバーを初期化します。

    # dsconf -D "cn=Directory Manager" ldap://supplier1.example.com repl-agmt create --suffix "dc=example,dc=com" --host "supplier2.example.com" --port 389 --conn-protocol LDAP --bind-dn "cn=replication manager,cn=config" --bind-passwd "password" --bind-method SIMPLE --init example-agreement-supplier1-to-supplier2

    このコマンドは、example-agreement-supplier1-to-supplier2 という名前のレプリカ合意を作成します。レプリカ合意は、新規サプライヤーのホスト名、プロトコル、新規サプライヤーへのデータの接続や複製時にサプライヤーが使用する認証情報などの設定を定義します。

    この合意の作成後、Directory Server は supplier2.example.com を初期化します。複製するデータ量によっては、初期化に時間がかかる場合があります。

検証

  1. レプリケーション設定を表示します。

    # dsconf -D "cn=Directory Manager" ldap://supplier1.example.com replication get --suffix "dc=example,dc=com"
    dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
    ...
    nsDS5ReplicaBindDN: cn=replication manager,cn=config
    nsDS5ReplicaRoot: dc=example,dc=com
    nsDS5ReplicaType: 3
    ...

    これらのパラメーターは以下を示しています。

    • nsDS5ReplicaBindDN はレプリケーションマネージャーアカウントを指定します。
    • nsDS5ReplicaRoot は、レプリケートされる接尾辞を設定します。
    • nsDS5ReplicaType3 に設定して、このホストがサプライヤーであることを定義します。
  2. 初期化が成功したかどうかを確認します。

    # dsconf -D "cn=Directory Manager" ldap://supplier1.example.com repl-agmt init-status --suffix "dc=example,dc=com" example-agreement-supplier1-to-supplier2
    Agreement successfully initialized.
  3. レプリケーションのステータスを表示します。

    # dsconf -D "cn=Directory Manager" ldap://supplier1.example.com repl-agmt status --suffix "dc=example,dc=com" example-agreement-supplier1-to-supplier2
    Status For Agreement: "example-agreement-supplier1-to-supplier2" (supplier2.example.com:389)
    Replica Enabled: on
    Update In Progress: FALSE
    Last Update Start: 20210331071545Z
    Last Update End: 20210331071546Z
    Number Of Changes Sent: 2:1/0
    Number Of Changes Skipped: None
    Last Update Status: Error (0) Replica acquired successfully: Incremental update succeeded
    Last Init Start: 20210331071541Z
    Last Init End: 20210331071544Z
    Last Init Status: Error (0) Total update succeeded
    Reap Active: 0
    Replication Status: Not in Synchronization: supplier (6064219e000100020000) consumer (Unavailable) State (green) Reason (error (0) replica acquired successfully: incremental update succeeded)

    Replication Status フィールドおよび Last Update Status フィールドを確認します。

トラブルシューティング

  1. デフォルトでは、サーバー上のすべての合意に対するレプリケーションアイドルタイムアウトは 1 時間です。タイムアウトが原因で大規模なデータベースの初期化が失敗する場合は、nsslapd-idletimeout パラメーターをより高い値に設定します。たとえば、パラメーターを 7200(2 時間) に設定するには、次のコマンドを実行します。

    # dsconf -D "cn=Directory Manager" ldap://supplier1.example.com config replace nsslapd-idletimeout=7200

    無制限の期間を設定するには、nsslapd-idletimeout0 に設定します。

3.3. コマンドラインを使用した、新規サーバーの既存サーバーに対するサプライヤーとしての設定

新しいサーバー supplier2.example.com をサプライヤーとして準備するには、次のいずれかの方法を使用します。

  • 接尾辞のレプリケーションを有効にします。
  • 既存サーバーへのレプリカ合意を作成します。
警告

新しいサーバーから既存のサプライヤーを初期化しないでください。それ以外の場合は、新規サーバーの空のデータベースは、既存のサプライヤーのデータベースを上書きします。

既存のサプライヤーに以下の手順を適用します。

  • 新しいサーバーへのレプリカ合意を作成します。
  • 新しいサーバーを初期化します。

前提条件

  • 新規サーバーで dc=example,dc=com 接尾辞のレプリケーションを有効にしている。
  • 既存のサーバーで dc=example,dc=com 接尾辞のレプリケーションを有効にしている。
  • 参加する新しいサーバーが正常に初期化されている。

手順

  • レプリカ合意を既存のインスタンスに追加します。

    # dsconf -D "cn=Directory Manager" ldap://supplier2.example.com repl-agmt create --suffix "dc=example,dc=com" --host "supplier1.example.com" --port 389 --conn-protocol LDAP --bind-dn "cn=replication manager,cn=config" --bind-passwd "password" --bind-method SIMPLE example-agreement-supplier2-to-supplier1
  • --init オプションを使用して、新しいインスタンスにレプリカ合意を追加します。

    # dsconf -D "cn=Directory Manager" ldap://supplier1.example.com repl-agmt create --suffix "dc=example,dc=com" --host "supplier2.example.com" --port 389 --conn-protocol LDAP --bind-dn "cn=replication manager,cn=config" --bind-passwd "password" --bind-method SIMPLE --init example-agreement-supplier1-to-supplier2

検証

  1. 合意のステータスを表示します。

    # dsconf -D "cn=Directory Manager" ldap://supplier2.example.com repl-agmt init-status --suffix "dc=example,dc=com" example-agreement-supplier2-to-supplier1
    Agreement successfully initialized.
  2. レプリケーションのステータスを表示します。

    # dsconf -D "cn=Directory Manager" ldap://supplier2.example.com repl-agmt status --suffix "dc=example,dc=com" example-agreement-supplier2-to-supplier1
    Status For Agreement: ""example-agreement-supplier2-to-supplier1 (supplier1.example.com:389)
    Replica Enabled: on
    Update In Progress: FALSE
    Last Update Start: 20210331073540Z
    Last Update End: 20210331073540Z
    Number Of Changes Sent: 7:1/0
    Number Of Changes Skipped: None
    Last Update Status: Error (0) Replica acquired successfully: Incremental update succeeded
    Last Init Start: 20210331073535Z
    Last Init End: 20210331073539Z
    Last Init Status: Error (0) Total update succeeded
    Reap Active: 0
    Replication Status: Not in Synchronization: supplier (60642649000000070000) consumer (Unavailable) State (green) Reason (error (0) replica acquired successfully: incremental update succeeded)
    Replication Lag Time: Unavailable

    Replication Status フィールドおよび Last Update Status フィールドを確認します。

トラブルシューティング

  1. デフォルトでは、サーバー上のすべての合意に対するレプリケーションアイドルタイムアウトは 1 時間です。タイムアウトが原因で大規模なデータベースの初期化が失敗する場合は、nsslapd-idletimeout パラメーターをより高い値に設定します。たとえば、パラメーターを 7200(2 時間) に設定するには、次のコマンドを実行します。

    # dsconf -D "cn=Directory Manager" ldap://supplier2.example.com config replace nsslapd-idletimeout=7200

    無制限の期間を設定するには、nsslapd-idletimeout0 に設定します。

第4章 Web コンソールを使用したマルチサプライヤーレプリケーションの設定

マルチサプライヤーレプリケーション環境では、2 つ以上の書き込み可能なサプライヤーが互いにデータを複製します。たとえば、マルチサプライヤーレプリケーションを設定してフェイルオーバー環境を提供し、複数のサーバーに負荷を分散します。その後、クライアントは読み取り/書き込みレプリカである任意のホストで読み取り/書き込み操作を実行できます。

本セクションでは、既存の Directory Server インスタンスが supplier1.example.com という名前のホストで実行されていることを前提としています。この手順では、supplier2.example.com という名前の別の読み取り/書き込みレプリカをトポロジーに追加する方法と、dc=example,dc=com 接尾辞のマルチサプライヤーレプリケーションを設定する方法を説明します。

4.1. Web コンソールを使用した新しいサプライヤーの準備

supplier2.example.com ホストを準備するには、レプリケーションを有効にします。このプロセスでは、以下を行います。

  • レプリケーショントポロジーでこのサーバーのロールを設定します。
  • レプリケートされる接尾辞を定義します。
  • このホストへの接続にサプライヤーが使用するレプリケーションマネージャーアカウントを作成します。

レプリケーショントポロジーに追加するサプライヤーで、以下の手順を実行します。

前提条件

  • Directory Server インスタンスがインストールされている。
  • dc=example,dc=com 接尾辞のデータベースが存在する。
  • Web コンソールでインスタンスにログインしている。

手順

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. レプリケーションを有効にします。

    1. Enable Replication をクリックします。
    2. Replication Role フィールドで Supplier を選択し、レプリカ ID を入力し、作成するレプリケーションマネージャーアカウントの識別名 (DN) およびパスワードを入力します。

      マルチサプライヤーレプリケーション用にサプライヤーのレプリケーションの有効化 1

      この設定により、ホストを dc=example,dc=com 接尾辞のサプライヤーとして設定し、このエントリーのレプリカ ID を 1 に設定します。

      重要

      トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。

      レプリケーションマネージャー DN を設定しない場合は、バインドグループ DN を設定します。その後、レプリカ合意でこのグループの任意のメンバーを使用できます。

    3. Enable Replication をクリックします。

検証

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. Replica Role フィールドに値 Supplier が含まれている場合、レプリケーションが有効になり、ホストがサプライヤーとして設定されます。

4.2. Web コンソールを使用した、既存サーバーの新規サーバーに対するサプライヤーとしての設定

既存のサーバー supplier1.example.com をサプライヤーとして準備するには、次のことを行う必要があります。

  • 接尾辞のレプリケーションを有効にします。
  • 新規サプライヤーへのレプリカ合意を作成します。
  • 新しいサプライヤーを初期化します。

レプリケーショントポロジーの既存のサプライヤーでこの手順を実行します。

前提条件

  • 参加するサプライヤーで dc=example,dc=com 接尾辞のレプリケーションを有効にしている。
  • Web コンソールでインスタンスにログインしている。

手順

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. レプリケーションを有効にします。

    1. Enable Replication をクリックします。
    2. Replication Role フィールドで Supplier を選択し、レプリカ ID を入力し、作成するレプリケーションマネージャーアカウントの識別名 (DN) およびパスワードを入力します。

      マルチサプライヤーレプリケーション用にサプライヤーのレプリケーションの有効化 2

      この設定により、ホストを dc=example,dc=com 接尾辞のサプライヤーとして設定し、このエントリーのレプリカ ID を 2 に設定します。

      重要

      トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。

    3. Enable Replication をクリックします。
  4. レプリカ合意を追加し、新規サーバーを初期化します。

    1. Agreements タブで、Create Agreement をクリックし、次のフィールドに入力します。

      レプリカ同意の作成 (マルチサプライヤー)1

      この設定により、example-agreement-supplier1-to-supplier2 という名前のレプリカ合意が作成されます。レプリカ合意は、新規サプライヤーのホスト名、プロトコル、新規サプライヤーへのデータの接続や複製時にサプライヤーが使用する認証情報などの設定を定義します。

    2. Consumer Initialization フィールドで Do Online Initialization を選択し、合意の保存後に新規サーバーを自動的に初期化します。
    3. Save Agreement をクリックします。

      この合意の作成後、Directory Server は supplier2.example.com を初期化します。複製するデータ量によっては、初期化に時間がかかる場合があります。

検証

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. Agreements タブで、テーブルの State 列での契約のステータスを確認。

    レプリカ合意の正常な初期化

4.3. Web コンソールを使用した、新規サーバーの既存サーバーに対するサプライヤーとしての設定

新しいサーバー supplier2.example.com をサプライヤーとして準備するには、次のことを行う必要があります。

  • 接尾辞のレプリケーションを有効にします。
  • 既存サーバーへのレプリカ合意を作成します。
  • 既存サーバーを初期化します。

レプリケーショントポロジーの既存のサプライヤーでこの手順を実行します。

警告

既存のサーバーでレプリカ合意を初期化していない場合は、続行しないでください。それ以外の場合は、新規サーバーの空のデータベースは、既存のサプライヤーのデータベースを上書きします。

前提条件

  • 新規サーバーで dc=example,dc=com 接尾辞のレプリケーションを有効にしている。
  • 既存のサーバーで dc=example,dc=com 接尾辞のレプリケーションを有効にしている。
  • 参加する新しいサーバーが正常に初期化されている。
  • Web コンソールでインスタンスにログインしている。

手順

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. レプリカ合意を追加し、既存のサーバーを初期化します。

    1. Agreements タブで、Create Agreement をクリックし、次のフィールドに入力します。

      レプリカ同意の作成 (マルチサプライヤー)2

      この設定により、example-agreement-supplier2-to-supplier1 という名前のレプリカ合意が作成されます。レプリカ合意は、既存サーバーのホスト名、プロトコル、既存サプライヤーへのデータの接続や複製時にサプライヤーが使用する認証情報などの設定を定義します。

    2. Consumer Initialization フィールドで Do Online Initialization を選択し、合意の保存後に新規サーバーを自動的に初期化します。
    3. Save Agreement をクリックします。

      この合意の作成後、Directory Server は supplier1.example.com を初期化します。複製するデータ量によっては、初期化に時間がかかる場合があります。

検証

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. Agreements タブで、テーブルの State 列での契約のステータスを確認。

    レプリカ合意の正常な初期化

第5章 証明書ベースの認証を使用したマルチサプライヤーレプリケーションの設定

2 つの Directory Server インスタンス間のレプリケーションを設定する場合、バインド DN とパスワードを使用してレプリケーションパートナーを認証する代わりに、証明書ベースの認証を使用できます。

これを行うには、新しいサーバーをレプリケーショントポロジーに追加し、証明書ベースの認証を使用して新しいホストと既存のサーバーの間にレプリケーションアグリーメントを設定します。

重要

証明書ベースの認証には、TLS 暗号化接続が必要です。

5.1. 証明書ベースの認証による複製合意で使用するためのアカウントとバインドグループの準備

複製合意で証明書ベースの認証を使用するには、まずアカウントを準備し、クライアント証明書をこれらのアカウントの userCertificate 属性に保存します。さらに、この手順では、後で複製合意で使用するバインドグループを作成します。

この手順は、既存のホスト server1.example.com で実行します。

前提条件

  • Directory Server で TLS 暗号化を有効にしています。
  • /root/server1.der ファイルと /root/server2.der ファイルにクライアント証明書を識別名エンコーディングルール (DER) 形式で保存しました。

    クライアント証明書の詳細と、認証局 (CA) から証明書を要求する方法については、CA のドキュメントを参照してください。

手順

  1. ou=services エントリーが存在しない場合は作成します。

    # ldapadd -D "cn=Directory Manager" -W -H ldaps://server1.example.com -x
    
    dn: ou=services,dc=example,dc=com
    objectClass: organizationalunit
    objectClass: top
    ou: services
  2. cn=server1,ou=services,dc=example,dc=com および cn=server1,ou=services,dc=example,dc=com など、両方のサーバーのアカウントを作成します。

    # ldapadd -D "cn=Directory Manager" -W -H ldaps://server1.example.com -x
    
    dn: cn=server1,ou=services,dc=example,dc=com
    objectClass: top
    objectClass: person
    objectClass: inetOrgPerson
    sn: server1
    cn: server1
    userPassword: password
    userCertificate:< file:///root/server1.der
    
    adding new entry "cn=server1,ou=services,dc=example,dc=com"
    
    dn: cn=server2,ou=services,dc=example,dc=com
    objectClass: top
    objectClass: person
    objectClass: inetOrgPerson
    sn: server2
    cn: server2
    userPassword: password
    userCertificate:< file:///root/server2.der
    
    adding new entry "cn=server2,ou=services,dc=example,dc=com"
  3. cn=repl_servers,dc=groups,dc=example,dc=com などのグループを作成します。

    # dsidm -D "cn=Directory Manager" ldaps://server1.example.com -b "dc=example,dc=com" group create --cn "repl_servers"
  4. 2 つのレプリケーションアカウントをメンバーとしてグループに追加します。

    # dsidm -D "cn=Directory Manager" ldaps://server1.example.com -b "dc=example,dc=com" group add_member repl_servers "cn=server1,ou=services,dc=example,dc=com"
    
    # dsidm -D "cn=Directory Manager" ldaps://server1.example.com -b "dc=example,dc=com" group add_member repl_servers "cn=server2,ou=services,dc=example,dc=com"

5.2. 一時レプリケーションマネージャーアカウントを使用した新しいサーバーの初期化

証明書ベースの認証では、ディレクトリーに格納されている証明書が使用されます。ただし、新しいサーバーを初期化する前は、server2.example.com のデータベースは空であり、関連付けられた証明書を持つアカウントは存在しません。したがって、データベースの初期化前に、証明書を使用してレプリケーションすることはできません。この問題は、server2.example.com を一時的なレプリケーションマネージャーアカウントで初期化することで解決できます。

前提条件

  • Directory Server インスタンスを server2.example.com にインストールした。
  • dc=example,dc=com 接尾辞のデータベースが存在する。
  • server1.example.comserver2.example.com の両方のサーバーの Directory Server で TLS 暗号化を有効にした。

手順

  1. server2.example.com で、dc=example,dc=com 接尾辞のレプリケーションを有効にします。

    # dsconf -D "cn=Directory Manager" ldaps://server2.example.com replication enable --suffix "dc=example,dc=com" --role "supplier" --replica-id 2 --bind-dn "cn=replication manager,cn=config" --bind-passwd "password"

    このコマンドは、server2.example.com ホストを dc=example,dc=com 接尾辞のサプライヤーとして設定し、このホストのレプリカ ID を 2 に設定します。さらに、このコマンドは、指定されたパスワードで一時的な cn=replication manager,cn=config ユーザーを作成し、このアカウントが接尾辞の変更をこのホストに複製できるようにします。

    トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。

  2. server1.example.com 上で:

    1. レプリケーションを有効にします。

      # dsconf -D "cn=Directory Manager" ldaps://server1.example.com replication enable --suffix="dc=example,dc=com" --role="supplier" --replica-id="1"
    2. 認証用に直前の手順で一時的なアカウントを使用する一時的なレプリカ合意を作成します。

      # dsconf -D "cn=Directory Manager" ldaps://server1.example.com repl-agmt create --suffix="dc=example,dc=com" --host="server1.example.com" --port=636 --conn-protocol=LDAPS --bind-dn="cn=Replication Manager,cn=config" --bind-passwd="password" --bind-method=SIMPLE --init temporary_agreement

検証

  1. 初期化が成功したことを確認します。

    # dsconf -D "cn=Directory Manager" ldaps://server1.example.com repl-agmt init-status --suffix "dc=example,dc=com" temporary_agreement
    Agreement successfully initialized.

5.3. 証明書ベースの認証を使用したマルチサプライヤーレプリケーションの設定

証明書ベースの認証を使用するマルチサプライヤーレプリケーション環境では、レプリカは証明書を使用して相互に認証します。

前提条件

  • server1.example.comserver2.example.com の両方のホストで証明書ベースの認証を設定します。
  • Directory Server は、クライアント証明書を発行する認証局 (CA) を信頼します。
  • クライアント証明書は、サーバーの /etc/dirsrv/slapd-instance_name/certmap.conf で設定された要件を満たしています。

手順

  1. server1.example.com 上で:

    1. 一時的なレプリカ合意を削除します。

      # dsconf -D "cn=Directory Manager" ldaps://server1.example.com repl-agmt delete --suffix="dc=example,dc=com" temporary_agreement
    2. cn=repl_servers,dc=groups,dc=example,dc=com バインドグループをレプリケーション設定に追加します。

      # dsconf -D "cn=Directory Manager" ldaps://server1.example.com replication set --suffix="dc=example,dc=com" --repl-bind-group "cn=repl_servers,dc=groups,dc=example,dc=com"
    3. バインドグループの変更を自動的にチェックするように Directory Server を設定します。

      # dsconf -D "cn=Directory Manager" ldaps://server1.example.com replication set --suffix="dc=example,dc=com" --repl-bind-group-interval=0
  2. server2.example.com 上で:

    1. 一時的なレプリケーションマネージャーアカウントを削除します。

      # dsconf -D "cn=Directory Manager" ldaps://server2.example.com replication delete-manager --suffix="dc=example,dc=com" --name="Replication Manager"
    2. cn=repl_servers,dc=groups,dc=example,dc=com バインドグループをレプリケーション設定に追加します。

      # dsconf -D "cn=Directory Manager" ldaps://server2.example.com replication set --suffix="dc=example,dc=com" --repl-bind-group "cn=repl_servers,dc=groups,dc=example,dc=com"
    3. バインドグループの変更を自動的にチェックするように Directory Server を設定します。

      # dsconf -D "cn=Directory Manager" ldap://server2.example.com replication set --suffix="dc=example,dc=com" --repl-bind-group-interval=0
    4. 証明書ベースの認証を使用して複製合意を作成します。

      dsconf -D "cn=Directory Manager" ldaps://server2.example.com repl-agmt create --suffix="dc=example,dc=com" --host="server1.example.com" --port=636 --conn-protocol=LDAPS --bind-method="SSLCLIENTAUTH" --init server2-to-server1
  3. server1.example.com で、証明書ベースの認証を使用して複製合意を作成します。

    dsconf -D "cn=Directory Manager" ldaps://server1.example.com repl-agmt create --suffix="dc=example,dc=com" --host="server2.example.com" --port=636 --conn-protocol=LDAPS --bind-method="SSLCLIENTAUTH" --init server1-to-server2

検証

  1. 初期化が成功したことを各サーバーで確認します。

    # dsconf -D "cn=Directory Manager" ldaps://server1.example.com repl-agmt init-status --suffix "dc=example,dc=com" server1-to-server2
    Agreement successfully initialized.
    
    # dsconf -D "cn=Directory Manager" ldaps://server2.example.com repl-agmt init-status --suffix "dc=example,dc=com" server2-to-server1
    Agreement successfully initialized.

第6章 コマンドラインを使用したカスケードレプリケーションの設定

カスケードレプリケーションのシナリオでは、ハブとなる 1 台のサーバーがコンシューマーとサプライヤーの両方のロールを果たします。ハブは、変更ログを維持する読み取り専用のレプリカです。サプライヤーから更新を受け取り、これらの更新をコンシューマーに提供します。カスケードレプリケーションは、負荷の高いトラフィックのバランスをとる場合や、地理的に分散した環境でサプライヤーをローカルに配置する場合に使用します。

6.1. コマンドラインを使用した新しいハブサーバーの準備

hub.example.com ホストを準備するには、レプリケーションを有効にします。このプロセスでは、以下を行います。

  • レプリケーショントポロジーでこのサーバーのロールを設定します。
  • レプリケートされる接尾辞を定義します。
  • このホストへの接続にサプライヤーが使用するレプリケーションマネージャーアカウントを作成します。

レプリケーショントポロジーに追加するハブで、以下の手順を実行します。

前提条件

  • Directory Server インスタンスがインストールされている。
  • dc=example,dc=com 接尾辞のデータベースが存在する。

手順

  • dc=example,dc=com 接尾辞のレプリケーションを有効にします。

    # dsconf -D "cn=Directory Manager" ldap://hub.example.com replication enable --suffix "dc=example,dc=com" --role "hub" --bind-dn "cn=replication manager,cn=config" --bind-passwd "password"

    このコマンドは、dc=example,dc=com 接尾辞のハブとして hub.example.com ホストを設定します。また、このコマンドは、指定したパスワードを持つ cn=replication manager,cn=config ユーザーを作成し、このアカウントが接尾辞の変更をこのホストに複製するのを許可します。

検証

  • レプリケーション設定を表示します。

    # dsconf -D "cn=Directory Manager" ldap://hub.example.com replication get --suffix "dc=example,dc=com"
    dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
    ...
    nsDS5ReplicaBindDN: cn=replication manager,cn=config
    nsDS5ReplicaRoot: dc=example,dc=com
    nsDS5ReplicaType: 2
    nsDS5ReplicaId: 65535
    ...

    これらのパラメーターは以下を示しています。

    • nsDS5ReplicaBindDN はレプリケーションマネージャーアカウントを指定します。
    • nsDS5ReplicaRoot は、レプリケートされる接尾辞を設定します。
    • nsDS5ReplicaType2 に設定して、このホストがコンシューマーで、ハブにも有効であることを定義します。
    • nsDS5ReplicaId65535 に設定して、このホストがハブであることを定義します。--role "hub" オプションを定義すると、dsconf ユーティリティーはこの値を自動的に設定します。

6.2. コマンドラインを使用した、既存サーバーのハブサーバーに対するサプライヤーとしての設定

既存のサーバーをサプライヤーとして準備するには、以下を行う必要があります。

  • 接尾辞のレプリケーションを有効にします。
  • ハブへのレプリカ合意を作成します。
  • ハブを初期化します。

レプリケーショントポロジーの既存のサプライヤーでこの手順を実行します。

前提条件

  • 参加するハブで dc=example,dc=com 接尾辞のレプリケーションを有効にしている。

手順

  1. dc=example,dc=com 接尾辞のレプリケーションを有効にします。

    # [command]`dsconf -D "cn=Directory Manager" ldap://supplier.example.com replication enable --suffix "dc=example,dc=com" --role "supplier" --replica-id 1

    このコマンドは、supplier.example.com ホストを dc=example,dc=com 接尾辞のサプライヤーとして設定し、このエントリーのレプリカ ID を 1 に設定します。

    重要

    トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。

  2. レプリカ合意を追加し、新規サーバーを初期化します。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt create --suffix "dc=example,dc=com" --host "hub.example.com" --port 389 --conn-protocol LDAP --bind-dn "cn=replication manager,cn=config" --bind-passwd "password" --bind-method SIMPLE --init example-agreement-supplier-to-hub

    このコマンドは、example-agreement-supplier-to-hub という名前のレプリカ合意を作成します。レプリカ合意は、ハブのホスト名、プロトコル、ハブへのデータの接続や複製時にサプライヤーが使用する認証情報などの設定を定義します。

    この合意の作成後、Directory Server は hub.example.com を初期化します。複製するデータ量によっては、初期化に時間がかかる場合があります。

検証

  1. レプリケーション設定を表示します。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com replication get --suffix "dc=example,dc=com"
    dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
    ...
    nsDS5ReplicaRoot: dc=example,dc=com
    nsDS5ReplicaType: 3
    ...

    これらのパラメーターは以下を示しています。

    • nsDS5ReplicaRoot は、レプリケートされる接尾辞を設定します。
    • nsDS5ReplicaType3 に設定して、このホストがサプライヤーであることを定義します。
  2. 初期化が成功したかどうかを確認します。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt init-status --suffix "dc=example,dc=com" example-agreement-supplier-to-hub
    Agreement successfully initialized.
  3. レプリケーションのステータスを表示します。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt status --suffix "dc=example,dc=com" example-agreement-supplier-to-hub
    Status For Agreement: "example-agreement-supplier-to-hub" (hub.example.com:389)
    Replica Enabled: on
    Update In Progress: FALSE
    Last Update Start: 20210331105030Z
    Last Update End: 20210331105030Z
    Number Of Changes Sent: 0
    Number Of Changes Skipped: None
    Last Update Status: Error (0) Replica acquired successfully: Incremental update succeeded
    Last Init Start: 20210331105026Z
    Last Init End: 20210331105029Z
    Last Init Status: Error (0) Total update succeeded
    Reap Active: 0
    Replication Status: Not in Synchronization: supplier (Unknown) consumer (Unknown) State (green) Reason (error (0) replica acquired successfully: incremental update succeeded)
    Replication Lag Time: Unavailable

    Replication Status フィールドおよび Last Update Status フィールドを確認します。

トラブルシューティング

  1. デフォルトでは、サーバー上のすべての合意に対するレプリケーションアイドルタイムアウトは 1 時間です。タイムアウトが原因で大規模なデータベースの初期化が失敗する場合は、nsslapd-idletimeout パラメーターをより高い値に設定します。たとえば、パラメーターを 7200(2 時間) に設定するには、次のコマンドを実行します。

    # dsconf -D "cn=Directory Manager" ldap://supplier1.example.com config replace nsslapd-idletimeout=7200

    無制限の期間を設定するには、nsslapd-idletimeout0 に設定します。

6.3. コマンドラインを使用したハブの新しいコンシューマーの準備

consumer.example.com ホストを準備するには、レプリケーションを有効にします。このプロセスでは、以下を行います。

  • レプリケーショントポロジーでこのサーバーのロールを設定します。
  • レプリケートされる接尾辞を定義します。
  • このホストへの接続にハブが使用するレプリケーションマネージャーアカウントを作成します。

レプリケーショントポロジーに追加するコンシューマーで、以下の手順を実行します。

前提条件

  • Directory Server インスタンスがインストールされている。
  • dc=example,dc=com 接尾辞のデータベースが存在する。

手順

  • dc=example,dc=com 接尾辞のレプリケーションを有効にします。

    # dsconf -D "cn=Directory Manager" ldap://consumer.example.com replication enable --suffix "dc=example,dc=com" --role "consumer" --bind-dn "cn=replication manager,cn=config" --bind-passwd "password"

    このコマンドは、consumer.example.com ホストを dc=example,dc=com 接尾辞のコンシューマーとして設定します。また、このコマンドは、指定したパスワードを持つ cn=replication manager,cn=config ユーザーを作成し、このアカウントが接尾辞の変更をこのホストに複製するのを許可します。

検証

  • レプリケーション設定を表示します。

    # dsconf -D "cn=Directory Manager" ldap://consumer.example.com replication get --suffix "dc=example,dc=com"
    dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
    ...
    nsDS5ReplicaBindDN: cn=replication manager,cn=config
    nsDS5ReplicaRoot: dc=example,dc=com
    nsDS5ReplicaType: 2
    ...

    これらのパラメーターは以下を示しています。

    • nsDS5ReplicaBindDN はレプリケーションマネージャーアカウントを指定します。
    • nsDS5ReplicaRoot は、レプリケートされる接尾辞を設定します。
    • nsDS5ReplicaType2 に設定して、このホストがコンシューマーであることを定義します。

6.4. コマンドラインを使用した、ハブサーバーのコンシューマーに対するサプライヤーとしての設定

ハブを準備するには、以下を行う必要があります。

  • コンシューマーへのレプリカ合意を作成します。
  • コンシューマーを初期化します。

レプリケーショントポロジーのハブでこの手順を実行します。

前提条件

  • ハブが初期化され、サプライヤーからハブへのレプリケーションが機能する。
  • ハブで dc=example,dc=com 接尾辞のレプリケーションを有効にしている。

手順

  • レプリカ合意を追加し、コンシューマーを初期化します。

    # dsconf -D "cn=Directory Manager" ldap://hub.example.com repl-agmt create --suffix "dc=example,dc=com" --host "consumer.example.com" --port 389 --conn-protocol LDAP --bind-dn "cn=replication manager,cn=config" --bind-passwd "password" --bind-method SIMPLE --init example-agreement-hub-to-consumer

    このコマンドは、example-agreement-hub-to-consumer という名前のレプリカ合意を作成します。レプリカ合意は、コンシューマーのホスト名、プロトコル、このコンシューマーへのデータの接続や複製時にサプライヤーが使用する認証情報などの設定を定義します。

    この合意の作成後、Directory Server は consumer.example.com を初期化します。複製するデータ量によっては、初期化に時間がかかる場合があります。

検証

  1. 初期化が成功したかどうかを確認します。

    # dsconf -D "cn=Directory Manager" ldap://hub.example.com repl-agmt init-status --suffix "dc=example,dc=com" example-agreement-hub-to-consumer
    Agreement successfully initialized.
  2. レプリケーションのステータスを表示します。

    # dsconf -D "cn=Directory Manager" ldap://hub.example.com repl-agmt status --suffix "dc=example,dc=com" example-agreement-hub-to-consumer
    Status For Agreement: "example-agreement-hub-to-consumer" (consumer.example.com:389)
    Replica Enabled: on
    Update In Progress: FALSE
    Last Update Start: 20210331131534Z
    Last Update End: 20210331131534Z
    Number Of Changes Sent: 0
    Number Of Changes Skipped: None
    Last Update Status: Error (0) Replica acquired successfully: Incremental update succeeded
    Last Init Start: 20210331131530Z
    Last Init End: 20210331131533Z
    Last Init Status: Error (0) Total update succeeded
    Reap Active: 0
    Replication Status: Not in Synchronization: supplier (Unknown) consumer (Unknown) State (green) Reason (error (0) replica acquired successfully: incremental update succeeded)
    Replication Lag Time: Unavailable

    Replication Status フィールドおよび Last Update Status フィールドを確認します。

トラブルシューティング

  1. デフォルトでは、サーバー上のすべての合意に対するレプリケーションアイドルタイムアウトは 1 時間です。タイムアウトが原因で大規模なデータベースの初期化が失敗する場合は、nsslapd-idletimeout パラメーターをより高い値に設定します。たとえば、パラメーターを 7200(2 時間) に設定するには、次のコマンドを実行します。

    # dsconf -D "cn=Directory Manager" ldap://hub .example.com config replace nsslapd-idletimeout=7200

    無制限の期間を設定するには、nsslapd-idletimeout0 に設定します。

第7章 Web コンソールを使用したカスケードレプリケーションの設定

カスケードレプリケーションのシナリオでは、ハブとなる 1 台のサーバーがコンシューマーとサプライヤーの両方のロールを果たします。ハブは、変更ログを維持する読み取り専用のレプリカです。サプライヤーから更新を受け取り、これらの更新をコンシューマーに提供します。カスケードレプリケーションは、負荷の高いトラフィックのバランスをとる場合や、地理的に分散した環境でサプライヤーをローカルに配置する場合に使用します。

7.1. Web コンソールを使用した新しいハブサーバーの準備

hub.example.com ホストを準備するには、レプリケーションを有効にします。このプロセスでは、以下を行います。

  • レプリケーショントポロジーでこのサーバーのロールを設定します。
  • レプリケートされる接尾辞を定義します。
  • このホストへの接続にサプライヤーが使用するレプリケーションマネージャーアカウントを作成します。

レプリケーショントポロジーに追加するハブで、以下の手順を実行します。

前提条件

  • Directory Server インスタンスがインストールされている。
  • dc=example,dc=com 接尾辞のデータベースが存在する。
  • Web コンソールでインスタンスにログインしている。

手順

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. レプリケーションを有効にします。

    1. Enable Replication をクリックします。
    2. Replication Role フィールドで Consumer を選択し、作成するレプリケーションマネージャーアカウントおよびパスワードを入力します。

      ハブでのレプリケーションの有効化

      この設定により、ホストを dc=example,dc=com 接尾辞のハブとして設定します。

    3. Enable Replication をクリックします。

検証

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. Replica Role フィールドに値 Hub が含まれている場合、レプリケーションが有効になり、ホストがコンシューマーとして設定されます。

7.2. Web コンソールを使用した、既存サーバーのハブサーバーに対するサプライヤーとしての設定

既存のサーバーをサプライヤーとして準備するには、以下を行う必要があります。

  • 接尾辞のレプリケーションを有効にします。
  • ハブへのレプリカ合意を作成します。
  • ハブを初期化します。

レプリケーショントポロジーの既存のサプライヤーでこの手順を実行します。

前提条件

  • 参加するハブで dc=example,dc=com 接尾辞のレプリケーションを有効にしている。
  • Web コンソールでインスタンスにログインしている。

手順

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. レプリケーションを有効にします。

    1. Enable Replication をクリックします。
    2. Replication Role フィールドで Supplier を選択し、レプリカ ID を入力し、作成するレプリケーションマネージャーアカウントの識別名 (DN) およびパスワードを入力します。

      マルチサプライヤーレプリケーション用にサプライヤーのレプリケーションの有効化 1

      この設定により、ホストを dc=example,dc=com 接尾辞のサプライヤーとして設定し、このエントリーのレプリカ ID を 1 に設定します。

      重要

      トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。

    3. Enable Replication をクリックします。
  4. レプリカ合意を追加し、新規サーバーを初期化します。

    1. Agreements タブで、Create Agreement をクリックし、次のフィールドに入力します。

      レプリカ同意の作成 (カスケードレプリケーション (サプライヤーからハブへ))

      この設定により、example-agreement-supplier-to-hub という名前のレプリカ合意が作成されます。レプリカ合意は、ハブのホスト名、プロトコル、このハブへのデータの接続や複製時にサプライヤーが使用する認証情報などの設定を定義します。

    2. Consumer Initialization フィールドで Do Online Initialization を選択し、合意の保存後に新規サーバーを自動的に初期化します。
    3. Save Agreement をクリックします。

      この合意の作成後、Directory Server は hub.example.com を初期化します。複製するデータ量によっては、初期化に時間がかかる場合があります。

検証

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. Agreements タブで、テーブルの State 列での契約のステータスを確認。

    レプリカ合意の正常な初期化

7.3. Web コンソールを使用したハブの新規コンシューマーの準備

consumer.example.com ホストを準備するには、レプリケーションを有効にします。このプロセスでは、以下を行います。

  • レプリケーショントポロジーでこのサーバーのロールを設定します。
  • レプリケートされる接尾辞を定義します。
  • このホストへの接続にサプライヤーが使用するレプリケーションマネージャーアカウントを作成します。

レプリケーショントポロジーに追加するコンシューマーで、以下の手順を実行します。

前提条件

  • Directory Server インスタンスがインストールされている。
  • dc=example,dc=com 接尾辞のデータベースが存在する。
  • Web コンソールでインスタンスにログインしている。

手順

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. Enable Replication をクリックします。
  4. Replication Role フィールドで Consumer を選択し、作成するレプリケーションマネージャーアカウントおよびパスワードを入力します。

    コンシューマーでのレプリケーションの有効化

    この設定により、ホストを dc=example,dc=com 接尾辞のコンシューマーとして設定します。さらに、サーバーは指定のパスワードで cn=replication manager,cn=config ユーザーを作成し、このアカウントがこのホストに接尾辞の変更を複製することができます。

  5. Enable Replication をクリックします。

検証

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. Replica Role フィールドに値 Consumer が含まれている場合、レプリケーションが有効になり、ホストがコンシューマーとして設定されます。

7.4. Web コンソールを使用した、ハブサーバーのコンシューマーに対するサプライヤーとしての設定

ハブを準備するには、以下を行う必要があります。

  • コンシューマーへのレプリカ合意を作成します。
  • コンシューマーを初期化します。

レプリケーショントポロジーのハブでこの手順を実行します。

前提条件

  • ハブが初期化され、サプライヤーからハブへのレプリケーションが機能する。
  • ハブで dc=example,dc=com 接尾辞のレプリケーションを有効にしている。
  • Web コンソールでインスタンスにログインしている。

手順

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. レプリカ合意を追加し、コンシューマーを初期化します。

    1. Agreements タブで、Create Agreement をクリックし、次のフィールドに入力します。

      レプリカ同意の作成 (カスケードレプリケーション (ハブからコンシューマーへ))

      この設定により、example-agreement-hub-to-consumer という名前のレプリカ合意が作成されます。レプリカ合意は、コンシューマーのホスト名、プロトコル、このコンシューマーへのデータの接続や複製時にハブが使用する認証情報などの設定を定義します。

    2. Consumer Initialization フィールドで Do Online Initialization を選択し、合意の保存後にコンシューマーを自動的に初期化します。
    3. Save Agreement をクリックします。

      この合意の作成後、Directory Server は consumer.example.com を初期化します。複製するデータ量によっては、初期化に時間がかかる場合があります。

検証

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. Agreements タブで、テーブルの State 列での契約のステータスを確認。

    レプリカ合意の正常な初期化

第8章 マルチサプレットレプリケーション環境でのレイテンシーの改善

特定の複数サプレーレプリケーション環境では (たとえば、サーバーがワイドエリアネットワーク (WAN) を介して接続されている場合)、複数のサプライヤーが同時に更新を受け取ると、レプリケーションのレイテンシーが高くなる可能性があります。これは、1 つのサプライヤーがレプリカを長期間解放せずにレプリカのみにアクセスした場合に発生します。このような場合は、他のサプライヤーがこのコンシューマーに更新を送信できないため、レプリケーションのレイテンシーが増加します。

一定期間の経過後にレプリカを解放するには、レプリケーションサプライヤーとハブに nsds5ReplicaReleaseTimeout パラメーターを設定します。

注記

ほとんどの環境では 60 秒のデフォルト値が適しています。設定した値が高すぎるまたは低すぎると、レプリケーションのパフォーマンスに影響を及ぼす可能性があります。設定した値が低すぎると、レプリケーションサーバーは常に相互に再取得し、サーバーは多くの更新を送信できなくなります。トラフィックの多いレプリケーション環境では、タイムアウトが長いと 1 つのサプライヤーのみがレプリカにアクセスする状況を改善できます。ただし、ほとんどの場合、120 秒よりも高い値を設定するとレプリケーションの速度が低下します。

8.1. コマンドラインを使用したレプリケーション解放タイムアウトの設定

マルチサプレットレプリケーション環境でレプリケーションの効率を向上させるには、すべてのハブおよびサプライヤーでレプリケーションリリースのタイムアウト値を更新します。

前提条件

  • 複数のサプライヤーとハブ間でレプリケーションを設定している。

手順

  1. 接尾辞のタイムアウト値を設定します。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com replication set --suffix="dc=example,dc=com" --repl-release-timeout=70

    このコマンドは、example,dc=com の接尾辞のレプリケーションタイムアウトを 70 秒に変更します。

  2. インスタンスを再起動します。

    # dsctl instance_name restart

8.2. Web コンソールを使用したレプリケーション解放タイムアウトの設定

マルチサプレットレプリケーション環境でレプリケーションの効率を向上させるには、すべてのハブおよびサプライヤーでレプリケーションリリースのタイムアウト値を更新します。

前提条件

  • 複数のサプライヤーとハブ間でレプリケーションを設定している。

手順

  1. Replication タブで、接尾辞エントリーを選択します。
  2. Show Advanced Settings をクリックします。
  3. Replication Release Timeout フィールドの値を更新します。
  4. Save Configuration をクリックします。

第9章 レプリケーショントポロジーからのインスタンスの削除

ハードウェアの停止や構造の変更など、特定の状況では、管理者はレプリケーショントポロジーから Directory Server インスタンスを削除します。インスタンスを削除する手順は、削除するレプリカのロールによって異なります。

9.1. レプリケーショントポロジーからのコンシューマーまたはハブの削除

レプリケーショントポロジーでコンシューマーまたはハブが不要になった場合は、これを削除します。

前提条件

  • 削除するインスタンスがコンシューマーまたはハブである。
  • 削除するホストがハブであり、トポロジー内の他のサーバーのサプライヤーとしても機能する場合、分離しないように、これらのサーバーにデータを複製するように他のサプライヤーまたはハブを設定している。

手順

  1. 削除するコンシューマーまたはハブ:

    1. 接尾辞とそれに対応するデータベースをリスト表示します。

      # dsconf -D "cn=Directory Manager" ldap://host-to-remove.example.com backend suffix list
      dc=example,dc=com (userroot)

      データベースの名前を書き留めます。

    2. データベースを読み取り専用モードに設定して、追加の更新を回避します。

      # dsconf -D "cn=Directory Manager" ldap://host-to-remove.example.com backend suffix set --enable-readonly "userroot"
  2. 削除するコンシューマーまたはハブとレプリカ合意を結んでいるすべてのサプライヤーで以下を実行します。

    1. レプリケートされる接尾辞のレプリカ合意をリスト表示します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt list --suffix "dc=example,dc=com"
      dn: cn=example-agreement,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
      cn: example-agreement
      ...

      cn 属性には、次の手順に必要なレプリカ合意名が含まれます。

    2. レプリカ合意を削除します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt delete --suffix "dc=example,dc=com" example-agreement
  3. コンシューマーまたはハブで、すべての接尾辞のレプリケーションを無効にします。

    # dsconf -D "cn=Directory Manager" ldap://host-to-remove.example.com replication disable --suffix "dc=example,dc=com"

    このホストがハブの場合は、レプリケーションを無効にすると、このサーバーのこの接尾辞のすべてのレプリカ合意も自動的に削除されます。

次のステップ

  • 削除されたインスタンスをテスト目的に使用する場合は、読み取り専用モードを無効にします。

    # dsconf -D "cn=Directory Manager" ldap://host-to-remove.example.com backend suffix set --disable-readonly userroot
    重要

    テスト目的でトポロジーから削除したインスタンスを使用する場合は、クライアントが引き続き使用していないことを確認してください。

  • インスタンスを削除します。

    # dsctl instance_name remove --do-it

9.2. レプリケーショントポロジーからのサプライヤーの削除

レプリケーショントポロジーからサプライヤーをきれいに削除することは、ハブまたはシューマーを削除するよりも複雑です。これは、トポロジー内のすべてのサプライヤーが他のサプライヤーに関する情報を保存し、サプライヤーが利用できない状態になった場合でも、その情報を保持するためです。

Directory Server は、レプリカ更新ベクトル (RUV) と呼ばれるメタデータセットに、レプリケーショントポロジーに関する情報を維持します。RUV には、ID と URL 等のサプライヤーに関する情報、ローカルサーバー上の最新の変更状態番号 (CSN)、および最初の変更の CSN などが含まれています。サプライヤーとコンシューマーはいずれも RUV 情報を保存し、これを使用してレプリケーションの更新を制御します。

サプライヤーを完全に削除するには、設定エントリーと共にそのメタデータを削除する必要があります。

前提条件

  • 削除するインスタンスがサプライヤーである。
  • 削除するホストがトポロジー内の他のサーバーのサプライヤーとしても機能する場合、分離しないように、これらのサーバーにデータを複製するように他のサプライヤーまたはハブを設定している。

手順

  1. 削除するサプライヤーで、以下を行います。

    1. 接尾辞とそれに対応するデータベースをリスト表示します。

      # dsconf -D "cn=Directory Manager" ldap://host-to-remove.example.com backend suffix list
      dc=example,dc=com (userroot)

      データベースの名前を書き留めます。

    2. データベースを読み取り専用モードに設定して、追加の更新を回避します。

      # dsconf -D "cn=Directory Manager" ldap://host-to-remove.example.com backend suffix set --enable-readonly "userroot"
    3. トポロジー内の他のすべてのサーバーが、このサプライヤーからすべてのデータを受け取るまで待ちます。確認のため、他のサーバーの CSN が、削除するサプライヤーの CSN と同等以上であることを確認します。

      # ds-replcheck online -D "cn=Directory Manager" -w password -m ldap://host-to-remove.example.com:389 -r ldap://server.example.com:389 -b dc=example,dc=com
      ================================================================================
               Replication Synchronization Report  (Tue Mar  5 09:46:20 2021)
      ================================================================================
      
      Database RUV's
      =====================================================
      
      Supplier RUV:
        {replica 1 ldap://host-to-remove.example.com:389} 5c7e8927000100010000 5c7e89a0000100010000
        {replicageneration} 5c7e8927000000010000
      
      Replica RUV:
        {replica 1 ldap://host-to-remove.example.com:389} 5c7e8927000100010000 5c7e8927000400010000
        {replica 2 ldap://server.example.com:389}
        {replicageneration} 5c7e8927000000010000
    4. レプリカ ID を表示します。

      # dsconf -D "cn=Directory Manager" ldap://host-to-remove.example.com replication get --suffix "dc=example,dc=com" | grep -i "nsds5replicaid"
      nsDS5ReplicaId: 1

      この例では、レプリカ ID は 1 です。この手順の最後のステップのレプリカ ID を書き留めます。

  2. 削除するホストとレプリカ合意があるすべてのサプライヤーで、以下を実施します。

    1. レプリケートされる接尾辞のレプリカ合意をリスト表示します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt list --suffix "dc=example,dc=com"
      dn: cn=example-agreement,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
      cn: example-agreement
      ...

      cn 属性には、次の手順に必要なレプリカ合意名が含まれます。

    2. レプリカ合意を削除します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt delete --suffix "dc=example,dc=com" example-agreement
  3. 削除するサプライヤーで、すべての接尾辞のレプリケーションを無効にします。

    # dsconf -D "cn=Directory Manager" ldap://host-to-remove.example.com replication disable --suffix "dc=example,dc=com"

    レプリケーションを無効にすると、このサーバーのこの接尾辞のレプリカ合意もすべて自動的に削除されます。

  4. 次に進む前に、ds-replcheck 出力の Replica RUV セクションにリスト表示されているすべての Directory Server インスタンスがオンラインであることを確認します。
  5. トポロジー内の残りのサプライヤーのいずれかで、レプリカ ID の RUV をクリーンアップします。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-tasks cleanallruv --suffix "dc=example,dc=com" --replica-id 1

    このコマンドでは、この手順の前のステップで表示されるレプリカ ID を指定する必要があります。

検証

  • ds-replcheck コマンドの出力で、削除したホストのレプリカ ID と URL を持つエントリーが残っていないことを確認します。

    # ds-replcheck online -D "cn=Directory Manager" -w password -m ldap://host-to-remove.example.com:389 -r ldap://server.example.com:389 -b dc=example,dc=com

次のステップ

  • 削除されたインスタンスをテスト目的に使用する場合は、読み取り専用モードを無効にします。

    # dsconf -D "cn=Directory Manager" ldap://host-to-remove.example.com backend suffix set --disable-readonly userroot
    重要

    テスト目的でトポロジーから削除したインスタンスを使用する場合は、クライアントが引き続き使用していないことを確認してください。

  • インスタンスを削除します。

    # dsctl instance_name remove --do-it

第10章 マルチサプライヤーレプリケーショントポロジーでのレプリカの独占の防止

マルチサプライヤーレプリケーショントポロジーでは、大規模な更新負荷のサプライヤーが、他のサプライヤーも更新できないようにレプリカを独占する場合があります。

本セクションでは、独占が発生する状況、この問題を特定する方法、独占状態を回避するためにサプライヤーを設定する方法を説明します。

10.1. 独占が発生する場合

マルチサプライヤーレプリケーションの機能の 1 つは、サプライヤーがレプリカへの排他的アクセスを取得することです。ロックアウト時にサプライヤーがアクセスの取得を試みると、レプリカはビジー応答を送り、サプライヤーは nsds5ReplicaBusyWaitTime パラメーターに設定した時間が待機してから次の試行を開始します。その間、サプライヤーは更新を別のレプリカに送信します。最初のレプリカが解放されると、サプライヤーはこのホストに更新を送ります。

ロックアウトされたサプライヤーが大規模な更新負荷の配下にある場合や、変更ログに保留中の更新が多数あると、問題になる場合があります。この状況では、サプライヤーをロックすると更新の送信を終了し、すぐに同じレプリカの再取得を試みます。他のサプライヤーは依然として待機している可能性があるため、このような試行はほとんどの場合で成功します。nsds5ReplicaSessionPauseTime パラメーターで、2 つの更新セッション間で一時停止を設定できます。これにより、単一のサプライヤーが数時間またはそれ以上にわたってレプリカを独占することになります。

10.2. レプリカの独占を識別するためのレプリケーションロギングの有効化

1 つ以上のサプライヤーが頻繁に高い更新負荷にあり、レプリカが頻繁に更新を受信しない場合は、レプリケーションメッセージのロギングを有効にして、独占状態を特定します。

前提条件

  • レプリケーショントポロジーに複数のサプライヤーがある。

手順

  1. レプリケーションロギングを有効にします。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-errorlog-level=8192

    このコマンドは、レプリケーションロギングのみを有効にし、他のエラーメッセージのロギングは無効である点に注意してください。

  2. /var/log/dirsrv/slapd-instance_name/errors ログファイルを監視し、以下のエラーメッセージを検索します。

    Replica Busy! Status: [Error (1) Replication error acquiring replica: replica busy]

    Directory Server がしばしばこのエラーをログに記録することがある点に注意してください。ただし、レプリカが頻繁に更新を受信せず、サプライヤーがこのエラーをログに記録する場合は、設定を更新してこの問題を解決することを検討してください。

10.3. レプリカの独占を回避するためのサプライヤーの設定

この手順では、レプリカの独占を防ぐために、サプライヤーでパラメーターを設定する方法を説明します。

環境と負荷の違いにより、状況に関連するパラメーターのみを設定し、実際の環境に応じて値を調整します。

前提条件

  • レプリケーショントポロジーに複数のサプライヤーがある。
  • Directory Server が頻繁に Replica Busy!Status: [Error (1) Replication error acquiring replica: replica busy] エラーを記録する。

手順

  1. nsds5ReplicaBusyWaitTime パラメーターを設定し、レプリカがビジー応答を送信した後に、サプライヤーが再度レプリカへのアクセスの取得を試みるまでに待機する時間を設定します。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt set --suffix "dc=example,dc=com" --busy-wait-time 5 replication_agreement_name

    このコマンドは、待機時間を 5 秒に設定します。この設定は、指定されたレプリカ合意にのみ適用されます。

  2. nsds5ReplicaSessionPauseTime パラメーターを設定して、2 つの更新セッション間でサプライヤーが待機する時間を設定します。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt set --suffix "dc=example,dc=com" --session-pause-time 15 replication_agreement_name

    このコマンドは、一時停止を 15 秒に設定します。デフォルトでは、nsds5ReplicaSessionPauseTimensds5ReplicaBusyWaitTime の値よりも 1 秒長くなるように設計されています。この設定は、指定されたレプリカ合意にのみ適用されます。

  3. nsds5ReplicaReleaseTimeout パラメーターを設定して、更新の送信が完了したかどうかに関わらず、指定時間後にレプリケーションセッションを終了します。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com replication set --suffix "dc=example,dc=com" --repl-release-timeout 90

    このコマンドは、タイムアウトを 90 秒に設定します。この設定は、指定した接尾辞のすべてのレプリカ合意に適用されます。

  4. オプション: サプライヤーのタイムアウト期間を設定して、低速または切断された接続を介して更新を無限に送信しようとするコンシューマーに接続されたままにならないようにします。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt set --conn-timeout 600 --suffix "dc=example,dc=com" replication_agreement_name

    このコマンドは、タイムアウトを 600 秒 (10 分) に設定します。最適な値を特定するには、アクセスログでレプリケーションプロセスにかかる平均時間を確認し、それに応じてタイムアウト期間を設定します。

第11章 レプリケーション環境のインスタンスがオフラインになった後のレプリケーション更新の強制

通常のメンテナンスでレプリケーションに関連する Directory Server インスタンスを停止する場合、インスタンスがオンラインに戻ったら、サプライヤーは直ちにディレクトリーデータを更新する必要があります。この更新は、コマンドラインおよび Web コンソールを使用して強制できます。

11.1. コマンドラインを使用したレプリケーション更新の強制

サプライヤーで以下の手順を実行し、example-agreementdc=example,dc=com 接尾辞のレプリケーション更新を強制します。

前提条件

  • レプリケーションが設定されている。
  • コンシューマーが初期化されている。

手順

  1. レプリカ合意に更新スケジュールが設定されているかどうかを確認します。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt get --suffix "dc=example,dc=com" example-agreement

    コマンドの出力に nsDS5ReplicaUpdateSchedule: * が含まれている、または nsDS5ReplicaUpdateSchedule パラメーターが存在しない場合、更新スケジュールは設定されていません。

    nsDS5ReplicaUpdateSchedule に、以下のようなスケジュールが含まれる場合には、値を書き留めておきます。

    nsDS5ReplicaUpdateSchedule: 0800-2200 0246
  2. 更新スケジュールが設定されている場合は、以下のコマンドを実行して一時的に無効にします。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt set --schedule \* --suffix "dc=example,dc=com" example-agreement
  3. レプリカ合意を一時的に無効にします。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt disable --suffix "dc=example,dc=com" example-agreement
  4. レプリカ合意を再度有効にして、レプリケーションの更新を強制的に実行します。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt enable --suffix "dc=example,dc=com" example-agreement
  5. この手順の最初にレプリケーションスケジュールが設定されていた場合、スケジュールを以前の値に設定します。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt set --schedule "0800-2200 0246" --suffix "dc=example,dc=com" example-agreement

検証

  • レプリケーションのステータスを表示します。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt status --suffix "dc=example,dc=com" example-agreement
    ...
    Last Update Start: 20210406120631Z
    Last Update End: 20210406120631Z
    Last Update Status: Error (0) Replica acquired successfully: Incremental update succeeded
    ...

11.2. Web コンソールを使用したレプリケーション更新の強制

サプライヤーで以下の手順を実行し、レプリケーション更新を強制します。

前提条件

  • レプリケーションが設定されている。
  • コンシューマーが初期化されている。
  • Web コンソールでインスタンスにログインしている。

手順

  1. Replication メニューを開きます。
  2. dc=example,dc=com 接尾辞を選択します。
  3. Agreements タブを開きます。
  4. レプリカ合意に更新スケジュールが設定されているかどうかを確認します。

    1. 契約の横にあるオーバーフローメニューをクリックし、Edit Agreement を選択します。
    2. Scheduling タブで、現在設定されている値をメモします。

      レプリケーションスケジュール

      Use A Custom Schedule が選択されていない場合、スケジュールは設定されません。

  5. レプリカ合意の横にあるオーバーフローメニューをクリックし、Disable/Enable Agreement を選択して合意を無効にします。

    State 列の合意のステータスが Disabled になります。

  6. レプリカ合意の横にあるオーバーフローメニューをもう一度クリックし、Disable/Enable Agreement を選択して、レプリカ合意を再度有効にし、レプリケーションの更新を適用します。

    State 列の合意のステータスが Enabled になります。

  7. この手順の最初にレプリケーションスケジュールが設定されていた場合、スケジュールを以前の値に設定します。

    1. オーバーフローメニューをクリックし、ActionsEdit Agreement を選択します。
    2. Scheduling タブで、以前の値を設定します。

検証

  • レプリケーションのステータスを表示します。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt status --suffix "dc=example,dc=com" example-agreement
    ...
    Last Update Start: 20210406120631Z
    Last Update End: 20210406120631Z
    Last Update Status: Error (0) Replica acquired successfully: Incremental update succeeded
    ...

第12章 レプリカのロールの変更

レプリケーショントポロジーでは、レプリカのロールを変更できます。たとえば、ハードウェアの停止によりサプライヤーが利用できない場合は、コンシューマーをサプライヤーにプロモートできます。もう 1 つの方法は、ハードウェアリソースが少ないサプライヤーをコンシューマーにデモートし、その後新しいハードウェアを持つ別のサプライヤーを追加できます。

12.1. コマンドラインを使用したレプリカのプロモート

以下のようにプロモートできます。

  • コンシューマーをハブまたはサプライヤーへ
  • ハブをサプライヤーへ

本セクションでは、dc=example,dc=com 接尾辞のレプリカをプロモートする方法を説明します。

前提条件

  • Directory Server インスタンスがレプリケーショントポロジーのメンバーである。
  • プロモートするレプリカがコンシューマーまたはハブである。

手順

  1. プロモートするレプリカがレプリカ合意を持つハブで、ハブがプロモート後にデータを他のホストに送信しないようにするには、レプリカ合意を削除します。

    1. ハブのレプリカ合意をリスト表示します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt list --suffix "dc=example,dc=com"
      dn: cn=example-agreement,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
      cn: example-agreement
      ...

      cn 属性には、次の手順に必要なレプリカ合意名が含まれます。

    2. ハブからレプリカ合意を削除します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt delete --suffix "dc=example,dc=com" example-agreement
  2. インスタンスをプロモートします。

    • コンシューマーまたはハブをサプライヤーにプロモートする場合は、以下を入力します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com replication promote --suffix "dc=example,dc=com" --newrole "supplier" --replica-id 2
      重要

      トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数値である必要があります。

    • コンシューマーをハブにプロモートする場合は、以下を入力します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com replication promote --suffix "dc=example,dc=com" --newrole "hub"
  3. 新しいロールのレプリカがトポロジー内の他のホストに更新を送信する必要がある場合は、レプリカ合意を作成します。

12.2. Web コンソールを使用したレプリカのプロモート

以下のようにプロモートできます。

  • コンシューマーをハブまたはサプライヤーへ
  • ハブをサプライヤーへ

本セクションでは、dc=example,dc=com 接尾辞のレプリカをプロモートする方法を説明します。

前提条件

  • Directory Server インスタンスがレプリケーショントポロジーのメンバーである。
  • プロモートするレプリカがコンシューマーまたはハブである。
  • Web コンソールでインスタンスにログインしている。

手順

  1. プロモートするレプリカがレプリカ合意を持つハブで、ハブがプロモート後にデータを他のホストに送信しないようにするには、レプリカ合意を削除します。

    1. ReplicationAgreements に移動します。
    2. 削除する合意の横にある Actions をクリックし、Delete Agreement を選択します。
  2. ReplicationConfiguration に移動し、Change Role ボタンをクリックします。

    • コンシューマーまたはハブをサプライヤーにプロモートする場合は、Supplier を選択して一意のレプリカ ID を入力します。

      重要

      トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数値である必要があります。

    • コンシューマーをハブにプロモートする場合は、Hub を選択します。
  3. Yes, I am sure. を選択します。
  4. Change Role をクリックします。
  5. 新しいロールのレプリカがトポロジー内の他のホストに更新を送信する必要がある場合は、レプリカ合意を作成します。

12.3. コマンドラインを使用したレプリカのデモート

以下のようにデモートできます。

  • サプライヤーまたはハブをコンシューマーへ
  • ハブをコンシューマーへ

本セクションでは、dc=example,dc=com 接尾辞のレプリカをデモートする方法を説明します。

前提条件

  • Directory Server インスタンスがレプリケーショントポロジーのメンバーである。
  • デモートするレプリカがサプライヤーまたはハブである。

手順

  1. デモートするレプリカに必要なくなったレプリカ合意がある場合は、たとえばレプリカをコンシューマーにデモートする場合、レプリカ合意を削除します。

    1. レプリカのレプリカ合意をリスト表示します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt list --suffix "dc=example,dc=com"
      dn: cn=example-agreement,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
      cn: example-agreement
      ...

      cn 属性には、次の手順に必要なレプリカ合意名が含まれます。

    2. レプリカからレプリカ合意を削除します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt delete --suffix "dc=example,dc=com" example-agreement
  2. インスタンスをデモートします。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com replication demote --suffix "dc=example,dc=com" --newrole "hub_or_consumer"

    設定するロールに応じて --newrole パラメーターを hub または consumer に設定します。

  3. レプリカをハブとして設定していて、トポロジー内の他のホストに更新を送信する必要がある場合は、レプリカ合意を作成します。

12.4. Web コンソールを使用したレプリカのデモート

以下のようにデモートできます。

  • サプライヤーまたはハブをコンシューマーへ
  • ハブをコンシューマーへ

本セクションでは、dc=example,dc=com 接尾辞のレプリカをデモートする方法を説明します。

前提条件

  • Directory Server インスタンスがレプリケーショントポロジーのメンバーである。
  • デモートするレプリカがサプライヤーまたはハブである。
  • Web コンソールでインスタンスにログインしている。

手順

  1. デモートするレプリカに必要なくなったレプリカ合意がある場合は、たとえばレプリカをコンシューマーにデモートする場合、レプリカ合意を削除します。

    1. ReplicationAgreements に移動します。
    2. 削除する合意の横にある Actions をクリックし、Delete Agreement を選択します。
  2. ReplicationConfiguration に移動し、Change Role ボタンをクリックします。
  3. 新しいレプリカロールを選択します。
  4. Yes, I am sure. を選択します。
  5. Change Role をクリックします。
  6. 新しいロールのレプリカがトポロジー内の他のホストに更新を送信する必要がある場合は、レプリカ合意を作成します。

第13章 レプリケーション変更ログのトリミング

Directory Server の changelog は、受け取ったおよび処理された変更のリストを管理します。これには、クライアントの変更やレプリケーションパートナーから受け取った変更が含まれます。

デフォルトでは、Directory Server は 7 日より古い変更ログエントリーを削除します。ただし、次のように設定できます。

  • nsslapd-changelogmaxage パラメーター: 変更ログのエントリーの最大期間
  • nsslapd-changelogmaxentries パラメーター: 変更ログにおけるレコードの合計数。

これらの設定の少なくとも 1 つを有効にした場合、ディレクトリーサーバーはデフォルトで 5 分ごとに変更ログをトリミングします (nsslapd-changelogtrim-interval)。

トリミング設定が有効であっても、どのレコードも、その後に作成されたレコードも、トポロジー内のすべてのサーバーに正常にレプリケートされるまで、changelog に残ります。レプリケーショントポロジーからサプライヤーを削除する の説明に従ってトポロジーからサプライヤーを削除すると、ディレクトリーサーバーはこのサプライヤーのすべての更新を他のサーバーの変更ログから削除します。

13.1. コマンドラインを使用したレプリケーション変更ログトリミングの設定

ディレクトリーサーバーは、デフォルトで 7 日より古い変更ログエントリーを削除します。ただし、ディレクトリーサーバーがエントリーを削除するまでの時間を設定できます。エントリー数が設定値を超えた場合にエントリーを自動的に削除するようにディレクトリーサーバーを設定することもできます。

本セクションでは、dc=example,dc=com 接尾辞の変更ログのトリミングを設定する方法を説明します。

注記

Red Hat は、最大エントリー数ではなく、最長期間を設定することを推奨します。最長期間は、cn=replica,cn=suffixDN,cn=mapping tree,cn=config エントリーの nsDS5ReplicaPurgeDelay パラメーターに設定されたレプリケーションパージ遅延と一致する必要があります。

サプライヤーでこの手順を実行します。

前提条件

  • dc=example,dc=com 接尾辞のレプリケーションを有効にしている。

手順

  1. 変更ログのトリミングを設定します。

    • 変更ログエントリーの最長期間を設定するには、以下を入力します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com replication set-changelog --suffix "dc=example,dc=com" --max-age "4w"

      このコマンドは、最長期間を 4 週間に設定します。パラメーターは、以下の単位をサポートします。

      • s (S) (秒)
      • m (M) (分)
      • h (H) (時間)
      • d (D) (日)
      • w (W) (週)
    • エントリーの最大数を設定するには、以下を入力します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com replication set-changelog --suffix "dc=example,dc=com" --max-entries "100000"

      このコマンドは、変更ログのエントリーの最大数を 100,000 に設定します。

  2. デフォルトでは、Directory Server は変更ログを 5 分 (300 秒) ごとにトリミングします。別の間隔を設定するには、以下を入力します。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com replication set-changelog --suffix "dc=example,dc=com" --trim-interval 600

    このコマンドは、間隔を 10 分 (600 秒) に設定します。

検証

  • 接尾辞の変更ログ設定を表示します。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com replication get-changelog --suffix "dc=example,dc=com"
    dn: cn=changelog,cn=userroot,cn=ldbm database,cn=plugins,cn=config
    cn: changelog
    nsslapd-changelogmaxage: 4w
    nsslapd-changelogtrim-interval: 600
    ...

    このコマンドは、デフォルトとは異なるパラメーターのみを表示します。

13.2. 大規模な変更ログの手動によるサイズ縮小

レプリケーション変更ログのトリミングが有効になっていない場合など、特定の状況では、変更ログが過度に大きなサイズに増大する可能性があります。これを修正するには、変更ログのサイズを手動で減らすことができます。

この手順では、dc=example,dc=com 接尾辞の変更ログをトリミングする方法を説明します。サプライヤーでこの手順を実行します。

前提条件

  • dc=example,dc=com 接尾辞のレプリケーションを有効にしている。

手順

  1. (オプション) 変更ログのサイズを表示します。

    1. dc=example,dc=com 接尾辞のバックエンドデータベースを特定します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list
      dc=example,dc=com (userroot)

      括弧内の名前は、対応する接尾辞のデータを保存するバックエンドデータベースです。

    2. userroot バックエンドの変更ログファイルのサイズを表示します。

      # ls -lh /var/lib/dirsrv/slapd-instance_name/db/userroot/replication_changelog.db
      -rw-------. 1 dirsrv dirsrv 517M Jul  5 12:58 /var/lib/dirsrv/slapd-instance_name/db/userroot/replication_changelog.db
  2. 変更ログサイズを縮小した後にパラメーターをリセットできるようにするには、対応するパラメーターの現在の値を表示して書き留めます。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com replication get-changelog --suffix "dc=example,dc=com"
    dn: cn=changelog,cn=userroot,cn=ldbm database,cn=plugins,cn=config
    cn: changelog
    nsslapd-changelogmaxage: 4w
    nsslapd-changelogtrim-interval: 300

    出力に特定の属性が表示されない場合、ディレクトリーサーバーはデフォルト値を使用します。

  3. 一時的に、トリミングに関連するパラメーターを減らします。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com replication set-changelog --suffix "dc=example,dc=com" --max-age "300s" --max-entries 500 --trim-interval 60
    重要

    パフォーマンス上の理由から、短い間隔設定を永続的に使用しないでください。

  4. --trim-interval パラメーターに設定した時間が経過するのを待ちます。
  5. 変更ログを圧縮して、ディスク領域を再度確保します。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com backend compact-db --only-changelog
  6. 変更ログパラメーターを、一時的に減らす前の値にリセットします。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com replication set-changelog --suffix "dc=example,dc=com" --max-age "4w" --trim-interval 300

検証

  • 変更ログのサイズを表示します。

    # ls -lh /var/lib/dirsrv/slapd-instance_name/db/userroot/replication_changelog.db
    -rw-------. 1 dirsrv dirsrv 12M Jul  5 12:58 /var/lib/dirsrv/slapd-instance_name/db/userroot/replication_changelog.db

第14章 レプリケーション変更ログの暗号化

攻撃者がサーバーのファイルシステムにアクセスできる場合は、レプリケーション changelog を暗号化してインスタンスのセキュリティーを強化します。

changelog 暗号化は、サーバーの TLS 暗号化キーと同じ PIN を使用してキーのロックを解除します。サーバーの起動時に PIN を手動で入力するか、PIN ファイルを使用する必要があります。

Directory Server は、無作為に生成された対称暗号キーを使用して、changelog を暗号化および復号化します。サーバーは、設定された暗号ごとに異なるキーを使用します。これらの鍵は、サーバーの TLS 証明書から公開鍵を使用してラップされ、生成したラップ済みキーがサーバーの設定ファイル内に保存されます。属性暗号化の効果的な強度は、ラップに使用されるサーバーの TLS キーの強度と同じです。サーバーの秘密鍵と PIN にアクセスできないと、ラップ済みのコピーから対称キーを復旧することができません。

14.1. コマンドラインを使用した changelog の暗号化

レプリケーショントポロジーのセキュリティーを向上させるには、サプライヤーおよびハブの changelog を暗号化します。この手順では、dc=example,dc=com 接尾辞に対して changelog 暗号化を有効にする方法を説明します。

前提条件

  • サーバーの TLS 暗号化が有効になっている。
  • ホストは、レプリケーショントポロジー内のサプライヤーまたはハブです。

手順

  1. changelog(例: /tmp/changelog.ldif ファイル) をエクスポートします。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com replication export-changelog to-ldif -o /tmp/changelog.ldif -r "dc=example,dc=com"
  2. dc=example,dc=com 接尾辞の changelog 暗号化を有効にします。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com replication --suffix "dc=example,dc=com" --encrypt
  3. /tmp/changelog.ldif ファイルから changelog をインポートします。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com replication import-changelog from-ldif -r "dc=example,dc=com" /tmp/changelog.ldif
  4. インスタンスを再起動します。

    # dsctl instance_name restart

検証

  1. エントリーの更新など、LDAP ディレクトリーに変更を加えます。
  2. インスタンスを停止します。

    # dsctl instance_name stop
  3. 接尾辞とそれに対応するデータベースをリスト表示します。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list
    dc=example,dc=com (userroot)

    changelog の暗号化を有効にするデータベースの名前を書き留めておきます。

  4. 以下のコマンドを実行して、changelog の一部を表示します。

    # dbscan -f /var/lib/dirsrv/slapd-instance_name/db/userroot/replication_changelog.db | tail -50

    changelog が暗号化されている場合は、暗号化されたデータのみが表示されます。

  5. インスタンスを起動します。

    # dsctl instance_name start

第16章 コマンドラインを使用したレプリケーショントポロジーの監視

サプライヤー、コンシューマー、およびハブの間のディレクトリーデータレプリケーションの状態を監視するには、レプリケーションの進行状況、レプリカ ID、変更の数、およびその他のパラメーターに関する情報を提供するレプリケーショントポロジーレポートを使用できます。レポートをより速く生成して読みやすくするために、独自の認証情報およびエイリアスを設定できます。

16.1. コマンドラインを使用したレプリケーショントポロジーレポートの表示

レプリケーショントポロジー内の各契約のレプリケーションステータスに関する全体的な情報を表示するには、レプリケーショントポロジーレポートを表示できます。これを行うには、dsconf replication monitor コマンドを使用します。

前提条件

  • ホストがレプリケーショントポロジーのメンバーである。
  • コンシューマーを初期化している。

手順

  • レプリケーショントポロジーレポートを表示するには、次のように入力します。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com replication monitor

    dsconf ユーティリティーは、トポロジー内の各インスタンスの認証情報を要求します。

    Enter password for cn=Directory Manager on ldap://supplier.example.com: password
    Enter a bind DN for consumer.example.com:389: cn=Directory Manager
    Enter a password for cn=Directory Manager on consumer.example.com:389: password
    
    Supplier: server.example.com:389
    --------------------------------
    Replica Root: dc=example,dc=com
    Replica ID: 1
    Replica Status: Online
    Max CSN: 5e3acb77001d00010000
    
    Status For Agreement: "example-agreement" (consumer.example.com:1389)
    Replica Enabled: on
    Update In Progress: FALSE
    Last Update Start: 20211209122116Z
    Last Update End: 20211209122116Z
    Number Of Changes Sent: 1:21/0
    Number Of Changes Skipped: None
    Last Update Status: Error (0) Replica acquired successfully: Incremental update succeeded
    Last Init Start: 20211209122111Z
    Last Init End: 20211209122114Z
    Last Init Status: Error (0) Total update succeeded
    Reap Active: 0
    Replication Status: In Synchronization
    Replication Lag Time: 00:00:00
    
    Supplier: consumer.example.com:1389
    -----------------------------------
    Replica Root: dc=example,dc=com
    Replica ID: 65535
    Replica Status: Online
    Max CSN: 00000000000000000000

16.2. .dsrc ファイルでのレプリケーション監視の認証情報の設定

デフォルトでは、dsconf replication monitor コマンドは、リモートインスタンスに対して認証する際に、バインド DN およびパスワードを要求します。将来、レポートをより速く簡単に生成するために、ユーザーの ~/.dsrc ファイルで、トポロジー内のサーバーごとにバインド DN と任意でパスワードを設定できます。

前提条件

  • ホストがレプリケーショントポロジーのメンバーである。
  • コンシューマーを初期化している。

手順

  1. オプション: ~/.dsrc ファイルを作成します。
  2. ~/.dsrc ファイルで、バインド DN およびパスワードを設定します。以下に例を示します。

    [repl-monitor-connections]
    connection1 = server1.example.com:389:cn=Directory Manager:*
    connection2 = server2.example.com:389:cn=Directory Manager:[~/pwd.txt]
    connection3 = hub1.example.com:389:cn=Directory Manager:S3cret

    この例では、connection1 から connection3 を各エントリーのキーとして使用します。ただし、任意の一意のキーを使用できます。

    dsconf replication monitor コマンドを実行すると、dsconf ユーティリティーはインスタンスのレプリカ合意で設定されたすべてのサーバーに接続します。このユーティリティーが ~/.dsrc でホスト名を見つけると、定義された認証情報を使用してリモートサーバーに対して認証されます。上記の例では、dsconf はサーバーへの接続時に以下の認証情報を使用します。

    Hostnameバインド DNパスワードの設定方法

    server1.example.com

    cn=Directory Manager

    パスワードを要求する

    server2.example.com

    cn=Directory Manager

    ~/pwd.txt からパスワードを読み取る

    hub1.example.com

    cn=Directory Manager

    S3cret

検証

16.3. レプリケーショントポロジーモニタリング出力でのエイリアスの使用

レポートを読みやすくするために、レポート出力に表示される独自のエイリアスを設定できます。デフォルトでは、レプリケーション監視レポートにはリモートサーバーのホスト名が含まれています。

前提条件

  • ホストがレプリケーショントポロジーのメンバーである。
  • コンシューマーを初期化している。

手順

レポートにエイリアスを表示する場合は、次のいずれかの方法を使用します。

  • ~/.dsrc ファイルでエイリアスを定義します。

    [repl-monitor-aliases]
    M1 = server1.example.com:389
    M2 = server2.example.com:389
  • -a alias=host_name:port パラメーターを dsconf replication monitor コマンドに渡して、エイリアスを定義します。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com replication monitor -a M1=server1.example.com:389 M2=server2.example.com:389

どちらの場合も、dsconf replication monitor コマンドは出力にエイリアスを表示します。

...
Supplier: M1 (server1.example.com:389)
--------------------------------
Replica Root: dc=example,dc=com

...
Supplier: M2 (server2.example.com:389)
--------------------------------
Replica Root: dc=example,dc=com

第17章 Web コンソールを使用したレプリケーショントポロジーの監視

サプライヤー、コンシューマー、およびハブの間のディレクトリーデータレプリケーションの状態を監視するには、レプリケーションの進行状況、レプリカ ID、変更の数、およびその他のパラメーターに関する情報を提供するレプリケーショントポロジーレポートを使用できます。レポートをより速く生成して読みやすくするために、独自の認証情報およびエイリアスを設定できます。

17.1. Web コンソールを使用したレプリケーショントポロジーレポートの表示

レプリケーショントポロジー内の各契約のレプリケーションステータスに関する全体的な情報を表示するには、レプリケーショントポロジーレポートを表示できます。

前提条件

  • ホストがレプリケーショントポロジーのメンバーである。
  • コンシューマーを初期化している。
  • Web コンソールにログインしている。

手順

  1. MonitoringReplication に移動します。Replication Monitoring ページが開きます。
  2. Generate Report をクリックします。
  3. リモートインスタンスにログインするためのパスワードを入力し、Confirm Credentials Input をクリックします。Directory Server は、既存のレプリケーションアグリーメントのバインド DN 値を使用します。

    レプリケーショントポロジーレポートは、Report Result タブで生成されます。

    注記

    別のレプリケーショントポロジーレポートを生成するには、Prepare Report タブに移動します。

17.2. Web コンソールを使用したレプリケーション監視の認証情報の設定

レプリケーショントポロジーレポートをより迅速かつ簡単に生成するために、認証用のトポロジー内のサーバーごとに、独自のバインド DN と任意でパスワードを設定できます。この場合、レプリケーショントポロジーレポートを生成するたびにレプリケーション認証情報を確認する必要はありません。デフォルトでは、Directory Server は既存のレプリケーションアグリーメントからこれらの認証情報を取得します。

前提条件

  • ホストがレプリケーショントポロジーのメンバーである。
  • コンシューマーを初期化している。
  • Web コンソールにログインしている。

手順

  1. MonitoringReplication に移動します。Replication Monitoring ページが開きます。
  2. Add Credentials をクリックします。
  3. リモートインスタンスへの認証に使用するレプリケーションのログイン認証情報を入力します。

    • Hostname。サーバーが認証するリモートインスタンスのホスト名。
    • Port。リモートインスタンスポート。
    • Bind DN。認証に使用される DN をリモートインスタンスにバインドします。
    • Password。認証に使用されるパスワード。
    • Interactive Input。オンにすると、レプリケーショントポロジーレポートを生成するたびに Directory Server がパスワードを要求します。
  4. Save をクリックします。

検証

レプリケーショントポロジーレポートを生成して、レポートが認証情報を要求するかどうかを確認します。詳しくは、Web コンソールを使用したレプリケーショントポロジーレポートの表示 を参照してください。

17.3. Web コンソールを使用したレプリケーション命名エイリアスの設定

レポートを読みやすくするために、レポート出力に表示される独自のエイリアスを設定できます。デフォルトでは、レプリケーション監視レポートにはサーバーのホスト名が含まれています。

前提条件

  • ホストがレプリケーショントポロジーのメンバーである。
  • コンシューマーを初期化している。
  • Web コンソールにログインしている。

手順

  1. MonitoringReplication に移動します。Replication Monitoring ページが開きます。
  2. Add Alias をクリックします。
  3. エイリアスの詳細を入力します。

    • Alias。レプリケーショントポロジーレポートに表示されるエイリアス。
    • Hostname。インスタンスのホスト名。
    • Port。インスタンスポート。
  4. Save をクリックします。

検証

第18章 2 つの Directory Server インスタンスの比較

ds-replcheck ユーティリティーを使用して、2 つの Directory Server インスタンスが同期されていることを確認できます。オンラインまたはオフラインモードで 2 つの LDIF 形式のファイルを使用して 2 つのサーバーを比較できます。

18.1. 2 つの Directory Server インスタンスのレプリケーションステータス表示

ds-replcheck ユーティリティーを使用して、2 つの Directory Server インスタンスのレプリケーションステータスを表示できます。

手順

  • 次のコマンドを使用して、2 つの Directory Server インスタンスのレプリケーションステータスを表示します。

    # ds-replcheck state -D "cn=Directory Manager" -W -m ldap://server1.example.com:389 -r ldap://server2.example.com:389 -b "dc=example,dc=com"
    Replication State: Replica is behind Supplier by: 264 seconds

18.2. 2 つのオンライン Directory Server インスタンスの比較

2 つのオンラインサーバーを比較すると、負荷が大きい場合、そのデータベースの内容が異なります。この問題を回避するために、ds-replcheck-l time_in_seconds パラメーターを ds-replcheck に渡すことにより、ラグタイム値を使用します。デフォルトでは、この値は 300 秒 (5 分) に設定されます。ユーティリティーがラグタイム内の不整合を検出した場合、ユーティリティーはそれを報告しません。これにより、誤検出が軽減されます。

デフォルトでは、レプリカ合意の特定の属性を複製から除外した場合、ds-replcheck はこれらの属性を異なると報告します。これらの属性を無視するには、ユーティリティーに -i attribute_list パラメーターを渡します。

手順

  • オンラインで、supplier.example.comreplica.example.comdc=example,dc=com 接尾辞を比較するには、次のように入力します。

    # ds-replcheck online -D "cn=Directory Manager" -W -m ldap://supplier.example.com:389 -r ldap://replica.example.com:389 -b "dc=example,dc=com"

    -m パラメーターおよび -r パラメーターは、サプライヤーとレプリカへの URL を設定します。

18.3. オフラインの 2 つの Directory Server インスタンスの比較

2 つのオフライン Directory Server インスタンスを比較するには、両方のホスト上のデータベースをエクスポートし、ds-replcheck を使用してそれらを比較します。

デフォルトでは、レプリカ合意の特定の属性を複製から除外した場合、ds-replcheck はこれらの属性を異なると報告します。これらの属性を無視するには、ユーティリティーに -i attribute_list パラメーターを渡します。

手順

  1. サプライヤーで、接尾辞とそれに対応するデータベースをリストします。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com backend suffix list
    dc=example,dc=com (userroot)
    o=test (test_database)

    比較するデータベースの名前または接尾辞をメモします。

  2. インスタンスの実行中にデータベースをエクスポートします。

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com backend export -r -l /var/lib/dirsrv/slapd-instance_name/ldif/export-supplier.ldif userRoot

    -r パラメーターは、エクスポートにレプリケーション状態情報が含まれるようにし、-l はエクスポートファイルへのパスを設定します。そのファイルを作成するには、dirsrv ユーザーが宛先ディレクトリーへの書き込み権限を持っている必要があることに注意してください。

  3. サプライヤーと比較するレプリカで前の手順を繰り返します。
  4. エクスポートしたファイルを一方のホストからもう一方のホストにコピーします。たとえば、LDIF ファイルを replica.example.com から supplier.example.com にコピーするには、レプリカで次のコマンドを入力します。

    # scp /var/lib/dirsrv/slapd-instance_name/ldif/export-replica.ldif supplier.example.com:/var/lib/dirsrv/slapd-instance_name/ldif/

    このコマンドでは、SSH を使用してサプライヤーにアクセスできる必要があることに注意してください。

  5. サプライヤーで、2 つの LDIF ファイルを比較します。

    # ds-replcheck offline -m /var/lib/dirsrv/slapd-instance_name/ldif/export-supplier.ldif -r /var/lib/dirsrv/slapd-instance_name/ldif/export-replica.ldif -rid 1 -b "dc=example,dc=com"

    -m および -r パラメーターは、サプライヤーとレプリカへのパスを設定し、-rid は、サプライヤーのレプリカ ID を設定します。

18.4. ds-replcheck 出力の説明

ds-replcheck ユーティリティーの出力には、次のセクションが含まれています。

データベース RUV

データベースの Replication Update Vectors (RUV) と、最小および最大の Change Sequence Numbers (CSN) をリスト表示します。以下に例を示します。

  Supplier RUV:
    {replica 1 ldap://supplier.example.com:389} 58e53b92000200010000 58e6ab46000000010000
    {replica 2 ldap://replica.example.com:389} 58e53baa000000020000 58e69d7e000000020000
    {replicageneration} 58e53b7a000000010000

  Replica RUV:
    {replica 1 ldap://supplier.example.com:389} 58e53ba1000000010000 58e6ab46000000010000
    {replica 2 ldap://replica.example.com:389} 58e53baa000000020000 58e7e8a3000000020000
    {replicageneration} 58e53b7a000000010000
エントリー数

tombstone エントリーを含む、両方のサーバー上のエントリーの合計数を表示します。以下に例を示します。

  Supplier:  12
  Replica: 10
Tombstones

各レプリカの tombstone エントリーの数を表示します。これらのエントリーは、合計エントリー数に追加されます。以下に例を示します。

  Supplier:  4
  Replica: 2
競合エントリー

各競合エントリーの識別名 (DN)、競合タイプ、および作成された日付をリスト表示します。以下に例を示します。

  Supplier Conflict Entries: 1

   - nsuniqueid=48177227-2ab611e7-afcb801a-ecef6d49+uid=user1,dc=example,dc=com
      - Conflict:   namingConflict (add) uid=user1,dc=example,dc=com
      - Glue entry: no
      - Created:    Wed Apr 26 20:27:40 2021


  Replica Conflict Entries: 1

   - nsuniqueid=48177227-2ab611e7-afcb801a-ecef6d49+uid=user1,dc=example,dc=com
      - Conflict:   namingConflict (add) uid=user1,dc=example,dc=com
      - Glue entry: no
      - Created:    Wed Apr 26 20:27:40 2021
エントリーがありません

足りない各エントリーの DN と、エントリーが存在する他のサーバーからの作成日をリスト表示します。以下に例を示します。

  Entries missing on Supplier:
   - uid=user2,dc=example,dc=com (Created on Replica at: Wed Apr 12 14:43:24 2021)
   - uid=user3,dc=example,dc=com (Created on Replica at: Wed Apr 12 14:43:24 2021)

  Entries missing on Replica:
   - uid=user4,dc=example,dc=com (Created on Supplier at: Wed Apr 12 14:43:24 2021)
エントリーの不整合

相手のサーバーとは異なる属性を持つエントリーの DN をリスト表示します。状態情報が利用可能な場合は、これも表示されます。属性の状態情報が利用できない場合には、元の値としてリスト表示されます。レプリケーションが初めて初期化されてから、値が更新されていないことを意味します。以下に例を示します。

  cn=group1,dc=example,dc=com
  ---------------------------
  Replica missing attribute "objectclass":

   - Supplier's State Info: objectClass;vucsn-58e53baa000000020000: top
   - Date: Wed Apr  5 14:47:06 2021

   - Supplier's State Info: objectClass;vucsn-58e53baa000000020000: groupofuniquenames
   - Date: Wed Apr  5 14:47:06 2021

第19章 一般的なレプリケーションの問題解決

マルチサプライヤーレプリケーションは、最終的に調整されたレプリケーションモデルを使用します。つまり、同じエントリーを別のサーバーで変更できることを意味します。これらの 2 つのサーバー間でレプリケーションが発生すると、Directory Server は競合する変更を解決する必要があります。多くの場合は、各サーバーでの変更に関連するタイムスタンプに基づいて解決が自動的に行われます。最新の変更が優先されます。ただし、解像度に到達するには、競合を手動で介入する必要があるケースがあります。

19.1. 命名の競合特定および解決

複数のサプライヤーサーバーが同じ識別名 (DN) を持つエントリーを作成する要求を受け取ると、各サーバーはこの DN と異なるエントリーの一意の識別子 (エントリー ID) を使用してエントリーを作成します。エントリー ID は、nsuniqueid 操作属性に保存されます。

たとえば、Server A および Server B は、uid=user_name,ou=people,dc=example,dc=com ユーザーエントリーを作成する要求を受け取ります。その結果、各サーバーに独自のエントリーがあります。

  • Server A では、エントリーには以下が含まれます。

    • uid=user_name,ou=people,dc=example,dc=com
    • nsuniqueid=a7f1758b-512211ec-b115e2e9-7dc2d46b
  • Server B では、エントリーには以下が含まれます。

    • uid=user_name,ou=people,dc=example,dc=com
    • nsuniqueid=643a461e-b61311e1-b23be826-4afeed5f

レプリケーション中に、Server A は新しく作成されたエントリー uid=user_name,ou=people,dc=example,dc=comServer B にレプリケートし、Server B は新しく作成されたエントリーを Server A にレプリケートし、各サーバーで名前の競合が発生します。変更シーケンス番号 (CSN) を比較することにより、各サーバーはどのエントリーが以前に作成されたかを判断します。たとえば、Server B のエントリーが先に作成されました。

自動競合解決手順では、最後に作成されたエントリー (Server A 上のエントリー) が次のように変更されます。

  • 一意でない DN に nsuniqueid 値を追加します。
  • nsds5replconflict 属性と、競合の原因となった操作の説明を追加します。
  • ldapsubentry objectclass を追加します。

現在、次のエントリーが両方のサーバーに存在します。

  • 有効な エントリーには以下が含まれます。

    • uid=user_name,ou=people,dc=example,dc=com
    • nsuniqueid=643a461e-b61311e1-b23be826-4afeed5f
  • 競合 エントリー:

    • nsuniqueid=a7f1758b-512211ec-b115e2e9-7dc2d46b+uid=user_name,ou=people,dc=example,dc=com
    • nsuniqueid=a7f1758b-512211ec-b115e2e9-7dc2d46b

名前の競合を手動で解決するには、各サーバーで次の手順を実行します。

手順

  1. 競合エントリーをリスト表示します。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict list dc=example,dc=com
    dn: nsuniqueid=a7f1758b-512211ec-b115e2e9-7dc2d46b+uid=user_name,ou=people,dc=example,dc=com
    cn: user_name
    displayName: user
    gidNumber: 99998
    homeDirectory: /var/empty
    legalName: user name
    loginShell: /bin/false
    nsds5replconflict: namingConflict (ADD) uid=user_name,ou=people,dc=example,dc=com
    objectClass: top
    objectClass: nsPerson
    objectClass: nsAccount
    objectClass: nsOrgPerson
    objectClass: posixAccount
    objectClass: ldapsubentry
    uid: user_name
    uidNumber: 99998
  2. 競合エントリーが存在する場合は、続行方法を決定します。

    • 有効なエントリー (uid=user_name,ou=people,dc=example,dc=com) を維持し、競合エントリーを削除するには、次のコマンドを実行します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict delete nsuniqueid=a7f1758b-512211ec-b115e2e9-7dc2d46b+uid=user_name,ou=People,dc=example,dc=com
    • 競合エントリー (nsuniqueid=a7f1758b-512211ec-b115e2e9-7dc2d46b+uid=user_name,ou=People,dc=example,dc=com) のみを保持し、有効なエントリーを削除するには、次のように入力します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict swap nsuniqueid=a7f1758b-512211ec-b115e2e9-7dc2d46b+uid=user_name,ou=People,dc=example,dc=com
    • 両方のエントリーを保持するには、新しい相対識別名 (RDN) を指定して、競合エントリーの名前を変更します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict convert --new-rdn=uid=user_name_NEW nsuniqueid=a7f1758b-512211ec-b115e2e9-7dc2d46b+uid=user_name,ou=people,dc=example,dc=com

      上記のコマンドは、競合エントリーの名前を uid=user_name_NEW,ou=people,dc=example,dc=com に変更します。

警告

Directory Server は、競合エントリーに対して実行された LDAP 操作を複製します。通常、レプリケートされた操作は、操作 dn ではなく、元の操作エントリーの nsuniqueid を使用してエントリーを対象としています。ただし、競合エントリーを使用する場合は、動作が異なる場合があります。

19.2. 孤立エントリーの競合特定および解決

Directory Server が削除操作を複製して、コンシューマーサーバーが、削除されるエントリーに子エントリーがあることを検出すると、競合解決の手順により、ディレクトリーに孤立したエントリーが存在しないように glue エントリーが作成されます。

同様に、Directory Server が追加操作を複製し、コンシューマーサーバーが親エントリーを検出できない場合、競合解決の手順で、親の glue エントリーが作成されます。

glue エントリーは、オブジェクトクラス glue および extensibleObject を含む一時エントリーです。チャンネルエントリーは、複数の方法で作成できます。

  • 競合解決手順で、一意識別子が同じエントリーで削除されたものを検出した場合には、glue エントリーには削除されたエントリーと同じ属性がありますが、glue オブジェクトクラスと nsds5ReplConflict 属性が追加されています。

    このような場合は、glue エントリーを変更して glue オブジェクトクラスと nsds5ReplConflict 属性を削除して、エントリーを通常のエントリーとして維持するか、その子エントリーを削除します。

  • サーバーは、glue および extensibleObject オブジェクトクラスを使用してエントリーを作成します。

手順

  1. 孤立したエントリーの競合をリスト表示します。

    # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict list-glue suffix
    dn: ou=parent,dc=example,dc=com
    objectClass: top
    objectClass: organizationalunit
    objectClass: glue
    objectClass: extensibleobject
    ou: parent
  2. 孤立したエントリーの競合が存在する場合は、続行する方法を決定します。

    • glue エントリーおよびその子エントリーを削除するには、次のコマンドを実行します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict delete-glue "ou=parent,dc=example,dc=com"
      dn: ou=parent,dc=example,dc=com
      objectClass: top
      objectClass: organizationalunit
      objectClass: extensibleobject
      ou: parent
    • glue エントリーを通常のエントリーに変換するには、次のコマンドを実行します。

      # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict convert-glue "ou=parent,dc=example,dc=com"

19.3. 廃止または欠落しているサプライヤーに関するエラーの特定および解決

Directory Server は、レプリカ更新ベクトル (RUV) と呼ばれるメタデータのセットとして、他のレプリカに更新を送信する全サプライヤーなどのレプリケーショントポロジーに関する情報を保存します。RUV には、ID と URL、ローカルサーバー上の最新の変更状態番号 (CSN)、最初の変更の CSN などのサプライヤーに関する情報が含まれています。サプライヤーとコンシューマーはいずれも RUV 情報を保存し、これを使用してレプリケーションの更新を制御します。

レプリケーショントポロジーからサプライヤーを削除すると、その情報は別のレプリカの RUV に残る場合があります。cleanallruv タスクを使用して、トポロジー内のすべてのサプライヤーから RUV エントリーを削除できます。

前提条件

  • レプリケーションが 有効である。

手順

  1. /var/log/dirsrv/slapd-instance_name/errors ログファイルを監視し、以下のようなエントリーを検索します。

    [22/Jan/2021:17:16:01 -0500] NSMMReplicationPlugin - ruv_compare_ruv: RUV [changelog max RUV] does not contain element [{replica 8 ldap://server2.example.com:389} 4aac3e59000000080000 4c6f2a02000000080000] which is present in RUV [database RUV]
    ...
    [22/Jan/2021:17:16:01 -0500] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: for replica dc=example,dc=com there were some differences between the changelog max RUV and the database RUV. If there are obsolete elements in the database RUV, you should remove them using the CLEANALLRUV task. If they are not obsolete, you should check their status to see why there are no changes from those servers in the changelog.

    この場合、レプリカ ID 8 が原因でこのエラーが発生します。

  2. 有効な ID と無効なすべての RUV レコードとレプリカ ID を表示します。

    # dsconf -D "cn=Directory Manager" ldap://server1.example.com replication get-ruv --suffix "dc=example,dc=com"
    RUV:        {replica 1 ldap://server1.example.com} 61a4d8f8000100010000 61a4f5b8000000010000
    
    Replica ID: 1
    LDAP URL:   ldap://server1.example.com
    Min CSN:    2021-11-29 13:43:20 1 0 (61a4d8f8000100010000)
    Max CSN:    2021-11-29 15:46:00 (61a4f5b8000000010000)
    RUV:        {replica 2 ldap://server2.example.com} 61a4d8fb000100020000 61a4f550000000020000
    
    Replica ID: 2
    LDAP URL:   ldap://server2.example.com
    Min CSN:    2021-11-29 13:43:23 1 0 (61a4d8fb000100020000)
    Max CSN:    2021-11-29 15:44:16 (61a4f550000000020000)
     RUV:        {replica 8 ldap://server3.example.com} 61a4d903000100080000 61a4d908000000080000
    
    Replica ID: 8
    LDAP URL:   ldap://server3.example.com
    Min CSN:    2021-11-29 13:43:31 1 0 (61a4d903000100080000)
    Max CSN:    2021-11-29 13:43:36 (61a4d908000000080000)

    返されるレプリカ ID のリスト (12、および 8)を書き留めます。

  3. レプリカ ID 8 のクリーンアップタスクを実行します。

    # dsconf -D "cn=Directory Manager" ldap://server1.example.com repl-tasks cleanallruv --suffix="dc=example,dc=com" --replica-id=8

    Directory Server は RUV クリーンアップタスクを複製することに注意してください。したがって、1 つのサプライヤーでのみ、タスクを開始する必要があります。

    レプリカの 1 つがダウンしている場合などに参加できない場合は、--force-cleaning オプションを使用して、RUV の即時クリーンアップを実行できます。

検証

  • RUV レコードおよびレプリカ ID を表示します。

    # dsconf -D "cn=Directory Manager" ldap://server1.example.com replication get-ruv --suffix "dc=example,dc=com"
    RUV:        {replica 1 ldap://server1.example.com} 61a4d8f8000100010000 61a4f5b8000000010000
    
    Replica ID: 1
    LDAP URL:   ldap://server1.example.com
    Min CSN:    2021-11-29 14:02:10 1 0 (61a4d8f8000100010000)
    Max CSN:    2021-11-29 16:00:00 (61a4f5b8000000010000)
    RUV:        {replica 2 ldap://server2.example.com} 61a4d8fb000100020000 61a4f550000000020000
    
    Replica ID: 2
    LDAP URL:   ldap://server2.example.com
    Min CSN:    2021-11-29 14:02:10 1 0 (61a4d8fb000100020000)
    Max CSN:    2021-11-29 15:58:22 (61a4f550000000020000)

    このコマンドは、レプリカ ID 8 の RUV エントリーを返さなくなりました。

法律上の通知

Copyright © 2024 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.