クラスタ内のレプリカの数と配置を決定する

クラスタにデータベースのレプリカを作成する主な理由は、データの安定した可用性を提供することと、複数のサーバー間でワークロードを分散することの 2 つです。クラスタにレプリカを作成する前に、ユーザーがデータベースにアクセスする頻度とデータの冗長性に対するニーズを検討します。データベースの利用頻度が極めて高い場合や、その可用性が非常に重要な場合は、レプリカを複数作成して最も信頼性のあるサーバーに配置します。利用頻度がそれほど高くなく安定した可用性も必要ないデータベースの場合は、レプリカを作成する必要はありません。たとえば、サーバーのログファイルなどのレプリカを他のサーバーに作成する必要はありません。

データベースのレプリカが増えると、データにアクセスしやすくなります。しかし、レプリカを作成しすぎると、システムの保守管理のオーバーヘッドが不必要に増え、パフォーマンスに悪影響を及ぼします。クラスタを計画する際は、データの可用性に対するユーザーの要件とクラスタ内の各サーバーの物理的な性能が釣り合うようにして増加するワークロードに対応します。1 つのデータベースに対してレプリカを 4 つ以上作成しても、可用性が大幅に増加するとは限りません。1 台か 2 台のサーバーでユーザーが快適にデータベースにアクセスできる場合は、クラスタ内のレプリカを増やさないようにします。

特定のデータベースに安定した可用性が必要な場合は、クラスタにある各サーバーにレプリカを配置することを検討します。ただし、十分なディスク容量とリソースがあることが条件となります。

利用頻度が最も高いデータベースはそれぞれ異なるサーバーに分散配置し、1 台のサーバーに集中しないようにします。クラスタ内のサーバーが、すべて同等の処理能力を持っている場合は、フェイルオーバー用の予備の処理能力も含めて、各サーバーにワークロードを均等に分散できます。あるサーバーの処理能力が他のサーバーに比べて著しく異なる場合は、このサーバーに配置するデータベースの数とこのサーバーにフェイルオーバーできるデータベースの数を変更することを検討します。メールファイルもクラスタ全体に分散させるか、メール用に独立したサーバーやクラスタを設定します。

クラスタ内で利用頻度の高いデータベースでは複製イベントが数多く生成されるため、クラスタで最も高速なハードディスクにこれらデータベースのレプリカを配置することをお勧めします。できれば、これらのレプリカは、オペレーティングシステムのスワップファイルがないパーティションなど、他のプロセスと競合しない場所に配置します。

クラスタ内に既に存在するデータベースとそのレプリカを参照するには、クラスタデータベースディレクトリ (CLDBDIR.NSF) を開きます。クラスタデータベースディレクトリーには、クラスタにあるデータベースとレプリカに関する情報を保存した文書があります。

注: 選択複製式の動作は、クラスタでは異なったものになります。

作成するレプリカの数

次のリストは、作成するレプリカの数を検討するための要件を説明したものです。

  • 作成するデータベースのレプリカ数は、そのデータベースが使用できることの重要度とデータベースの使用頻度に依存します。
  • データベースにデータの冗長性が必要な場合は、そのデータベースのレプリカを少なくとも 1 つ作成します。データベースが使用できなくなっても、ユーザーはそのレプリカにフェイルオーバーできます。
  • データベースを常時使用できるようにする場合は、複数のレプリカを作成します。データベースが使用できることの重要度が増すにつれて、作成するレプリカ数を増やす必要があります。本当に重要なデータベースのみに、複数のレプリカを作成します。必要のないレプリカを作成すると、クラスタとネットワークのリソースが浪費されます。
  • ほとんどのデータベースについては、1 つのレプリカで十分です。本当にミッションクリティカルなデータベースではないかぎり、4 つ以上のレプリカが必要になることはほとんどありません。
  • レプリカを作成する際は、システムの性能と帯域幅を検討してください。データベースへのアクセスが増えるほど、レプリカの更新に必要なネットワークトラフィックや処理能力が増大します。システムの性能と帯域幅に制限がある場合は、それらに余裕がある場合よりも、アクセスが多いデータベースのレプリカを少なくします。サーバーにプロセッサや他のリソースを追加する方法もあります。クラスタのリソースに制限がある場合、アクセスが多いデータベースのレプリカを作成すると、クラスタ複製に追加のリソースが必要になるため、逆効果になる場合があります。(クラスタリングは、不十分なリソースの解決策とはなりません。) アクセスが比較的少ないデータベースの場合は、そのデータベースを最新の状態に保つために発生するオーバーヘッドは少なくなります。
  • 作成するレプリカの数が分からない場合は、1 つのレプリカから始めてクラスタ統計の変化を追跡します。この統計からサーバーが使用できなくなることや、パフォーマンス上の問題が発生することが分かれば、レプリカの数を増やすことにより問題を解決できます。
  • 可用性の維持やワークロードの均衡化を必要としないデータベースではレプリカを作成しないようにします。

データベースを分析してレプリカの数を決定する

作成するレプリカの数を決定するときに考慮すべき要素がいくつかあります。これら要素の中には、レプリカの数を増やすことを推奨するものもありますが、逆に減らすことを推奨するものもあります。こうした要素がクラスタトラフィックとパフォーマンスにどのように影響するかを以下に説明します。

クラスタ内にデータベースを分散させるにあたって、データベースとクラスタのハードウェアの情報を表にすると便利です。この表を使用して、特定のデータベースの重要度や、リソースが十分であるかを判断します。次の項目の一部またはすべてを表に含めてください。

  • データベース名

    データベースを識別します。

  • 各データベースのサイズ

    大きなデータベースほど大きなディスク容量を必要とします。ディスク容量に応じて、大きなデータベースほど作成するレプリカ数を少なくし、レプリカを保存するディスクで使用する領域を節約します。

  • データベースユーザーの数と分散状況

    ユーザー数が多い場合は、ユーザーを複数のサーバーに分散すると、良好なパフォーマンスが得られます。そのためには、複数のレプリカが必要です。ユーザー数が少ない場合は、レプリカを追加してもパフォーマンスが目に見えて向上することはありません。

  • ユーザートランザクションの発生頻度

    トランザクションの発生率が高い場合は、複数のレプリカを作成するとパフォーマンスが向上します。

    データベースでの作業量を確認するには、HCL Notes® のログファイルを参照してください。

  • 新規データの予想量

    データベースに膨大な量の新規データを入力する場合は、レプリカを追加するとパフォーマンスが低下することがあります。これは、クラスタ複製によって追加のトラフィックが大量に発生するからです。高性能のサーバーと十分な帯域幅がある場合は、このような問題は発生しません。

  • HCL Domino® サーバーハードウェアの容量

    サーバーの性能が上がりディスク容量が増えれば増えるほど、パフォーマンスに影響せずに作成できるアクティブなレプリカ数が増えます。

  • サーバー間のネットワーク接続タイプ

    帯域幅が不十分なネットワークでは、クラスタ複製がボトルネックになることがあります。したがって、帯域幅が広くなるほど、作成できるレプリカ数は増えます。

  • 企業経営にとってのデータベースの重要度

    ミッションクリティカルなデータベースには、複数のレプリカを作成します。可用性がそれほど重要ではないデータベースの場合は、作成するレプリカ数を減らすか、まったく作成しません。

表の例

この表により、高い可用性を必要とするデータベース、最もアクセスが多いデータベース、将来必要な追加ディスク容量が分かりやすくなります。この例では、重要なデータベースが 2 つあり、そこでは急速にデータが増加しています。この 2 つのデータベースが常時使用できるようにそのレプリカを十分に作成しておく必要があります。この 2 つのデータベースのレプリカがあるサーバーでは、データの増加に備えて十分なディスク容量を確保しておく必要があります。表には重要度が中でデータもあまり急速に増加せず、それほど頻繁には利用されないデータベースが 1 つあります。このデータベースを使用できない期間が発生すると業務に悪影響が出る場合に、そのレプリカを 1 つだけ作成します。表の最後のデータベースは重要ではないため、クラスタにレプリカは不要です。

同時に使用するユーザーの最大数は、ワークロードの均衡化の必要性を判断する上で役立ちます。

次の表では、前述の情報の一部を使用して必要なレプリカ数を決めています。

1. 組織に固有のデータベース情報についての表の例

データベースタイトル

サイズ

最大同時ユーザー数

トランザクション速度

成長率

可用性の必要性

推奨レプリカ数

製品開発

4GB

600<nozeros>

2<nozeros>

セールストラッキング

1GB

200<nozeros>

クリティカル

2 以上

企業研究

2GB

20<nozeros>

0 または 1

項目別広告

1GB

50<nozeros>

0<nozeros>