Red Hat Summit9.4. キャッシュへのバックアップの場所の追加
Data Grid クラスターをクロスサイトのレプリケーションを実行するように設定するには、バックアップの場所をキャッシュ設定に追加できます。
手順
各サイトに同じ名前のキャッシュ設定を作成します。
各サイトのキャッシュ設定では、異なるキャッシュモードとバックアップストラテジーを使用できます。Data Grid は、キャッシュ名に基づいてデータを複製します。
take-offline要素を使用して、バックアップの場所を自動的にオフラインになるように設定します。-
min-wait属性で、バックアップの場所がオフラインになるまでの時間をミリ秒単位で設定します。
-
- その他の有効なキャッシュ設定を定義します。
バックアップの場所を、グローバルクラスターのすべてのサイトの名前付きキャッシュに追加します。
たとえば、NYC のバックアップとして LON を追加する場合、LON のバックアップとして NYC を追加する必要があります。
以下の設定例は、キャッシュのバックアップの場所を示しています。
NYC
<infinispan> <cache-container> <distributed-cache name="customers"> <encoding media-type="application/x-protostream"/> <backups> <backup site="LON" strategy="SYNC"> <take-offline min-wait="120000"/> </backup> </backups> </distributed-cache> </cache-container> </infinispan>LON
<infinispan> <cache-container> <replicated-cache name="customers"> <encoding media-type="application/x-protostream"/> <backups> <backup site="NYC" strategy="ASYNC" > <take-offline min-wait="120000"/> </backup> </backups> </replicated-cache> </cache-container> </infinispan>
9.4.1. バックアップの場所をオフラインにする時のパフォーマンスに関する考慮事項
リモートサイトが使用できなくなった場合、バックアップの場所は自動的にオフラインになります。これにより、ノードがオフラインのバックアップの場所にデータを複製しようとする (エラーが発生してクラスターのパフォーマンスに影響を及ぼす可能性がある) ことを防ぎます。
バックアップの場所がオフラインになるまでの待機時間を設定できます。経験則として、1、2 分が適しています。ただし、さまざまな待機期間をテストし、それらのパフォーマンスへの影響を評価して、デプロイメントに適した値を決定する必要があります。
たとえば、OpenShift がサイトマスター Pod を終了すると、Data Grid Operator が新規のサイトマスターを選択するまでの短時間、そのバックアップの場所は利用できなくなります。この場合、最小の待機時間が十分な長さではない場合、バックアップの場所はオフラインになります。そこで、これらのバックアップの場所をオンライン状態にし、状態転送操作を実行して、データが同期していることを確認する必要があります。
同様に、最小の待機時間が長すぎる場合は、バックアップの試行が失敗することでノードの CPU 使用率が増大し、パフォーマンスが低下する可能性があります。
