Red Hat Training

A Red Hat training course is available for Red Hat Directory Server

第7章 レプリケーションプロセスの設計

ディレクトリーの内容を複製すると、ディレクトリーサービスの可用性やパフォーマンスが向上します。4章ディレクトリーツリーの設計 および 6章ディレクトリートポロジーの設計 で、ディレクトリーツリーとディレクトリートポロジーの設計について説明しています。本章では、データの物理的および地理的な場所について、特に、必要なときに必要な場所でデータを利用できるようにするためのレプリケーションの利用方法について説明します。
本章では、レプリケーションの使用方法を説明し、ディレクトリー環境のレプリケーションストラテジーの設計に関するアドバイスを提供します。

7.1. レプリケーションの概要

レプリケーションは、自動的にディレクトリーデータを Red Hat Directory Server から別の Red Hat Directory Server にコピーするメカニズムです。レプリケーションを使用すると、(独自のデータベースに格納されている) 任意のディレクトリーツリーまたはサブツリーをサーバー間でコピーすることができます。情報のマスターコピーを保持している Directory Server は、すべてのレプリカに更新情報を自動的にコピーします。
レプリケーションは高可用性ディレクトリーサービスを提供し、データを地理的に分散できます。現実的には、レプリケーションには以下のようなメリットがあります。
  • フォールトトレランスおよびフェイルオーバー - ディレクトリーツリーを複数のサーバーに複製することで、ハードウェア、ソフトウェア、ネットワークの問題により、ディレクトリークライアントアプリケーションが特定のディレクトリーサーバーにアクセスできない場合でも、ディレクトリーサービスを利用できます。クライアントは、読み取りと書き込み操作のために、別の Directory Server を参照します。
    注記
    書き込みフェイルオーバーは、マルチマスターのレプリケーションでのみ可能です。
  • 負荷分散: サーバー全体でディレクトリーツリーを複製すると、指定したマシンのアクセス負荷が減り、サーバーの応答時間が改善します。
  • パフォーマンスの向上とレスポンスタイムの短縮 - ディレクトリーエントリーをユーザーに近い場所に複製することで、ディレクトリーのレスポンスタイムが大幅に向上します。
  • ローカルデータ管理: レプリケーションにより、企業全体で他の Directory Server と情報を共有しながら、ローカルで情報を所有および管理することができます。

7.1.1. レプリケーションの概念

レプリケーションの計画は、常に以下の基本的な決定を行うことから始めます。
  • 複製する情報。
  • その情報のマスターコピー (読み取り/書き込みレプリカ) を保持するサーバー。
  • その情報の読み取り専用コピー (読み取り専用レプリカ) を保持するサーバー。
  • 読み取り専用のレプリカが更新要求を受け取ったときに何をすべきか、つまり、どのサーバにその要求を参照すべきか。
これらの決定は、Directory Server がこれらの概念をどのように処理するかを理解せずに効果的に行うことはできません。たとえば、複製する情報を決定するには、Directory Server が処理できる最小レプリケーションユニットを認識してください。Directory Server が使用するレプリケーションの概念は、必要なグローバルな決定について考えるためのフレームワークを提供します。

7.1.1.1. レプリケーションのユニット

レプリケーションの最小単位はデータベースです。データベース全体はレプリケートできますが、データベース内のサブツリーは複製できません。したがって、ディレクトリーツリーを定義する際には、常にレプリケーションを考慮してください。ディレクトリーツリーの設定方法に関する詳細は、4章ディレクトリーツリーの設計 を参照してください。
レプリケーションメカニズムでは、1 つのデータベースが 1 つの接尾辞に対応する必要もあります。2 つ以上のデータベース上で分散される接尾辞 (または namespace) は複製できません。

7.1.1.2. 読み取り/書き込みレプリカおよび読み取り専用レプリカ

レプリケーションに参加するデータベースは、レプリカ として定義されます。Directory Server は、2 種類のレプリカ (読み取り/書き込みおよび読み取り専用) をサポートします。読み取り/書き込みレプリカには、ディレクトリー情報のマスターコピーが含まれており、更新可能です。読み取り専用レプリカは、すべての更新操作を読み取り/書き込みレプリカに参照します。

7.1.1.3. サプライヤーとコンシューマー

別のサーバーにコピーされたレプリカを保存するサーバーは サプライヤー と呼ばれます。別のサーバーからコピーしたレプリカを保存するサーバーは、コンシューマー と呼ばれます。通常、サプライヤーサーバーのレプリカは読み取り/書き込みレプリカで、コンシューマーサーバーのレプリカは読み取り専用レプリカになります。ただし、以下の例外が適用されます。
  • カスケードレプリケーション の場合、ハブサプライヤー はコンシューマーに提供する読み取り専用レプリカを保持します。詳細は、「カスケードレプリケーション」 を参照してください。
  • マルチマスターのレプリケーション の場合、サプライヤーは、同じ読み取り/書き込みレプリカのサプライヤーとコンシューマーの両方として機能します。詳細は、「マルチマスターレプリケーション」 を参照してください。
注記
Red Hat Directory Server の現行バージョンでは、レプリケーションは常にサプライヤーサーバーによって開始され、コンシューマーによって開始されることはありません。これは、コンシューマーで開始されるレプリケーション (コンシューマーサーバーがサプライヤーサーバーからデータを取得することができる) を許可した Directory Server の以前のバージョンとは異なります。

サプライヤー

特定のレプリカの場合は、サプライヤーサーバーでは以下を行う必要があります。

  • ディレクトリークライアントからの読み取りリクエストや更新リクエストへの対応。
  • レプリカの状態情報と changelog を維持します。
  • コンシューマーサーバーへのレプリケーションを開始します。
サプライヤーサーバーは管理する読み取り/書き込みレプリカに加えられた変更を常に記録するため、サプライヤーサーバーは、変更が確実にコンシューマーサーバーに複製されるようにします。

コンシューマー

コンシューマーサーバーは、以下を行う必要があります。

  • 読み取りのリクエストに応える。
  • レプリカのサプライヤーサーバーへの更新リクエストを参照する。
コンシューマーサーバーがエントリーの追加、削除、または変更の要求を受信するたびに、要求はレプリカのサプライヤーに参照されます。サプライヤーサーバーはリクエストを実行し、変更を複製します。

ハブサプライヤー

レプリケーションをカスケードする特殊なケースでは、ハブサプライヤーは以下を行う必要があります。

  • 読み取りのリクエストに応える。
  • レプリカのサプライヤーサーバーへの更新リクエストを参照する。
  • コンシューマーサーバーへのレプリケーションを開始します。
カスケードレプリケーションに関する詳細は、「カスケードレプリケーション」 を参照してください。

7.1.1.4. レプリケーションとチェンジログ

すべてのサプライヤーサーバーは changelog を維持します。changelog とは、レプリカで発生した変更の記録のことです。次に、サプライヤーサーバーは、マルチマスターレプリケーションの場合には、コンシューマーサーバーに保存されているレプリカまたは他のサプライヤーにこの変更を再生します。
エントリーが変更されると、実行された LDAP 操作を記述する変更レコードが changelog に記録されます。
changelog サイズは、nsslapd-changelogmaxage または nsslapd-changelogmaxentries の 2 つの属性で維持されます。これらの属性は古い changelog をトリミングして、changelog サイズを妥当な状態に維持します。

7.1.1.5. レプリカ合意

Directory Server はレプリカ合意を使用してレプリケーションを定義します。レプリカ合意は、1 つのサプライヤーと 1 つのコンシューマーとの間のレプリケーションのみを説明します。この合意は、サプライヤーサーバーで設定します。以下を識別します。
  • 複製するデータベース。
  • データがプッシュされるコンシューマーサーバー。
  • レプリケーションが実行される時間。
  • サプライヤーサーバーがバインドする際に使用しなければならない DN (サプライヤーバインド DN と呼びます)。
  • 接続のセキュリティーを確保する方法 (TLS、Start TLS、クライアント認証、SASL、または簡易認証)。
  • レプリケートされない属性 (「一部レプリケーションで選択された属性を複製する」 を参照)

7.1.2. データの整合性

一貫性とは、複製されたデータベースの内容が、ある時点でどれだけ一致しているかを意味します。サーバー間のレプリケーションの設定の一部として、更新のスケジューリングがあります。サプライヤーサーバーは、コンシューマーサーバーをいつ更新する必要があるかを常に判断し、レプリケーションを開始します。
Directory Server には、レプリカを常に同期させるオプション、または特定の時刻または曜日の更新をスケジュールするオプションがあります。
レプリカを常に同期させておくことで、データの一貫性が保たれるというメリットがあります。ただし、更新作業が頻繁に行われることにより、ネットワークトラフィックが犠牲となります。このソリューションは、以下の場合に最適なオプションとなります。
  • サーバー間に、信頼できる高速接続があります。
  • ディレクトリーサービスが提供するクライアント要求は主に検索、読み取り、および比較操作でであり、更新操作は比較的少ないです。
データの一貫性が低くても問題ない場合は、ネットワークの使用パターンに合わせて、あるいはネットワークトラフィックへの影響を少なくするような更新頻度を選択してください。常にアップデートを行うのではなく、定期的にアップデートを行うことが最良の解決策である場合がいくつかあります。
  • 信頼できないネットワーク接続、または断続的に利用可能なネットワーク接続があります。
  • ディレクトリーサービスが提供するクライアントリクエストは主に更新操作です。
  • 通信コストを低くする必要があります。
マルチマスターレプリケーションの場合、各サプライヤーに保存されているデータにはいつでも違いが生じる可能性があるため、各サプライヤーのレプリカは 大まかに一貫性がある と言われています。以下の 2 つの理由から、レプリカが完全に同期されている場合でも、これは当てはまります。
  • サプライヤー間の更新操作の伝播にはレイテンシーがあります。
  • 更新操作を処理したサプライヤーは、2 番目のサプライヤーが更新操作を検証するのを待たずに、「operation successful」というメッセージをクライアントに返します。