Data Grid クロスサイトレプリケーション

Data Grid は、地理的に分散したデータセンターで実行されているクラスター間および異なるクラウドプロバイダー間でデータをバックアップできます。クロスサイトレプリケーションは、Data Grid にグローバルクラスタービューを提供し、以下を提供します。

図1.1 クロスサイトレプリケーション

リレーノードは、Data Grid クラスターのノードであり、バックアップの場所から要求を送受信します。

ノードがリレーノードではない場合、バックアップリクエストをローカルのリレーノードに転送する必要があります。リレーノードのみが、バックアップロケーションにリクエストを送信できます。

最適なパフォーマンスを得るには、すべてのノードをリレーノードとして設定する必要があります。これにより、クラスター内の各ノードがバックアップ要求をローカルリレーノードに転送しなくても、リモートサイトに直接バックアップできるため、バックアップ要求の速度が向上します。

Data Grid キャッシュには、リモートサイトをバックアップの場所として命名できるようにする backups 設定が含まれます。

たとえば、以下の図では、3 つのキャッシュ "customers"、"eu-orders"、および "us-orders" を示しています。

Data Grid は、キャッシュへの書き込みが発生すると同時に、クラスター間でデータを複製します。たとえば、クライアントが LON に "k1" と書き込む場合、Data Grid は同時に "k1" を NYC バックアップします。

別のクラスターにデータのバックアップを作成するには、Data Grid は同期または非同期ストラテジーを使用します。

同期ストラテジー

Data Grid がデータをバックアップの場所に複製するとき、ローカルクラスターのキャッシュとリモートクラスターのキャッシュに同時に書き込みます。同期ストラテジーでは、Data Grid は両方の書き込み操作が完了するのを待ってから戻ります。

バックアップ操作が失敗した場合に、Data Grid がローカルクラスターのキャッシュへの書き込みを処理する方法を制御できます。Data Grid は以下を行うことができます。

同期バックアップは、楽観的なトランザクションに参加するキャッシュを持つ 2 フェーズコミットもサポートします。バックアップの最初のフェーズはロックを取得します。2 番目のフェーズは変更をコミットします。

非同期ストラテジー

Data Grid がデータをバックアップ場所に複製する場合、操作が完了するのを待たずにローカルキャッシュに書き込みます。

非同期バックアップ操作およびローカルキャッシュへの書き込みは、互いに独立しています。バックアップ操作が失敗した場合は、ローカルキャッシュへの書き込み操作は続行され、例外は発生しません。これが発生すると、Data Grid は、リモートクラスターがクロスサイトビューから切断されるまで、書き込み操作も再試行します。

同期バックアップと非同期バックアップの比較

同期バックアップは、サイト全体でのデータの一貫性を最も強力に保証します。strategy=sync の場合、cache.put() 呼び出しが返されると、ローカルキャッシュとバックアップの場所で値が最新の状態であることがわかります。

この一貫性のために犠牲となるのがパフォーマンスです。同期バックアップは、非同期バックアップと比較すると、レイテンシーが大幅に高くなります。

一方、非同期バックアップは、クライアントリクエストにレイテンシーを追加しないので、パフォーマンスに影響を及ぼすことはありません。ただし、strategy=async の場合、cache.put() 呼び出しが返されると、バックアップの場所の値がローカルキャッシュの値と同じであるかどうかを確認できません。

クラスター全体でデータをレプリケートする操作は、RAM および CPU を過剰に使用して、リソースを大量に消費します。特定の期間後にリクエストの受け入れを停止する際に、Data Grid がバックアップの場所をオフラインにすることで、リソースの浪費を避けることができます。

Data Grid は、失敗した順次要求の数と最初の失敗からの経過時間に基づいて、リモートサイトをオフラインにします。ターゲットクラスターにクロスサイトビュー (JGroups ブリッジ) のノードがない場合や、ターゲットクラスターが要求を確認する前にタイムアウトが期限切れになる場合は、要求は失敗します。

バックアップのタイムアウト

バックアップ設定には、クラスター間でデータを複製する操作のタイムアウト値が含まれます。タイムアウトが終了する前に操作が完了しない場合、Data Grid は失敗としてそれらを記録します。

以下の例では、データを NYC に複製する操作は、10 秒以内に完了しない場合、失敗として記録されます。

<distributed-cache>
  <backups>
    <backup site="NYC"
            strategy="ASYNC"
            timeout="10000" />
  </backups>
</distributed-cache>

{
  "distributed-cache": {
    "backups": {
      "NYC" : {
        "backup" : {
          "strategy" : "ASYNC",
          "timeout" : "10000"
        }
      }
    }
  }
}

distributedCache:
  backups:
    NYC:
      backup:
        strategy: "ASYNC"
        timeout: "10000"

失敗の数

バックアップの場所がオフラインになる前に発生する可能性のある 連続する 失敗の数を指定できます。

以下の例では、クラスターが NYC にデータを複製しようとし、5 回連続して操作が失敗すると、NYC は自動的にオフラインになります。

<distributed-cache>
  <backups>
    <backup site="NYC"
            strategy="ASYNC"
            timeout="10000">
      <take-offline after-failures="5"/>
    </backup>
  </backups>
</distributed-cache>

{
  "distributed-cache": {
    "backups": {
      "NYC" : {
        "backup" : {
          "strategy" : "ASYNC",
          "timeout" : "10000",
          "take-offline" : {
            "after-failures" : "5"
          }
        }
      }
    }
  }
}

distributedCache:
  backups:
    NYC:
      backup:
        strategy: "ASYNC"
        timeout: "10000"
        takeOffline:
          afterFailures: "5"

待機時間

バックアップ操作の失敗時に、サイトをオフラインにするまで待機する時間を指定することもできます。待機時間がなくなる前にバックアップ要求が成功した場合、Data Grid はサイトをオフラインにしません。

バックアップの場所を自動的にオフラインにするまでの待機時間は、通常、1、2 分が適切とされています。待機時間が短すぎると、バックアップの場所はすぐにオフラインになります。次に、クラスターをオンラインに戻し、状態遷移操作を実行して、クラスター間でデータが同期されていることを確認します。

失敗数の負の値またはゼロの値は 1 の値と同等です。Data Grid は、障害が発生した後、バックアップの場所がオフラインになるのを待つために最小限の時間のみを使用します。以下に例を示します。

<take-offline after-failures="-1"
              min-wait="10000"/>

以下の例では、クラスターが NYC にデータを複製しようとし、6 つ以上の連続した失敗があり、最初の失敗した操作から 15 秒が経過すると、NYC は自動的にオフラインになります。

<distributed-cache>
  <backups>
    <backup site="NYC"
            strategy="ASYNC"
            timeout="10000">
      <take-offline after-failures="5" min-wait="15000"/>
    </backup>
  </backups>
</distributed-cache>

{
  "distributed-cache": {
    "backups": {
      "NYC" : {
        "backup" : {
          "strategy" : "ASYNC",
          "timeout" : "10000",
          "take-offline" : {
            "after-failures" : "5",
            "min-wait" : "15000"
          }
        }
      }
    }
  }
}

distributedCache:
  backups:
    NYC:
      backup:
        strategy: "ASYNC"
        timeout: "10000"
        takeOffline:
          afterFailures: "5"
          minWait: "15000"

状態遷移は、サイト間でデータを同期する管理操作です。

たとえば、LON がオフラインになると、NYC がクライアント要求の処理を開始します。LON をオンラインに戻すと、LON の Data Grid クラスターには NYC のクラスターと同じデータはありません。

LON と NYC の間でデータの一貫性を保つには、NYC から LON に状態をプッシュできます。

自動状態遷移

デフォルトでは、CLI を使用して、または JMX や REST 経由で、クロスサイトの状態遷移操作を手動で実行する必要があります。

ただし、非同期バックアップストラテジーを使用すると、Data Grid はクロスサイト状態遷移操作を自動的に実行できます。バックアップの場所がオンラインになり、ネットワーク接続が安定していることを検知すると、Data Grid はバックアップの場所の間で双方向状態遷移を開始します。たとえば、Data Grid は、状態を LON から NYC に、NYC から LONに同時に遷移します。

クライアントは、Active/Passive または Active/Active 設定のいずれかで Data Grid クラスターに書き込みできます。

Active/Passive

以下の図は、Data Grid が 1 つのサイトのみからのクライアント要求を処理する Active/Passive を示しています。

上記のイメージでは、以下のようになります。

Active/Passive では、NYC はデータの冗長性を提供します。LON の Data Grid クラスターが何らかの理由でオフラインになると、クライアントは NYC への要求の送信を開始できます。LON をオンラインに戻すと、NYC とデータを同期し、クライアントを LON に戻すことができます。

Active/Active

以下の図は、Data Grid が 2 つのサイトでクライアント要求を処理する Active/Active を示しています。

上記のイメージでは、以下のようになります。

Active/Active では、NYC と LON の両方は、クライアント要求の処理中にデータをリモートキャッシュに複製します。NYC または LON のいずれかがオフラインになると、クライアントはオンラインサイトへの要求の送信を開始できます。その後、オフラインサイトをオンラインに戻し、状態をプッシュしてデータを同期し、必要に応じてクライアントを切り替えることができます。

バックアップストラテジーおよびクライアント接続

複数のクライアントが同じエントリーに同時に書き込もうとし、バックアップストラテジーが同期 (strategy=sync) の場合、デッドロックが発生します。ただし、両方のサイトが異なるデータセットにアクセスする場合、Active/Passive 設定で同期バックアップストラテジーを使用できます。この場合、同時書き込みによるデッドロックのリスクはありません。

            LON       NYC

k1=(n/a)    0,0       0,0

k1=2        1,0  -->  1,0   k1=2

k1=3        1,1  <--  1,1   k1=3

k1=5        2,1       1,2   k1=8

                 -->  2,1 (conflict)
(conflict)  1,2  <--

有効期限は、時間に基づいてキャッシュエントリーを削除します。Data Grid では、エントリーの有効期限を設定する方法は 2 つあります。

JGroups RELAY2 をトランスポート層に追加して、Data Grid がキャッシュをバックアップの場所に複製できるようにします。

JGroups RELAY2 スタック

以下の設定は、以下の JGroups RELAY2 スタックを示しています。

<infinispan>
  <jgroups>
    <stack name="xsite" extends="udp">
      <relay.RELAY2 xmlns="urn:org:jgroups"
                    site="LON"
                    max_site_masters="1000"/>
      <remote-sites default-stack="tcp">
        <remote-site name="LON"/>
        <remote-site name="NYC"/>
      </remote-sites>
    </stack>
  </jgroups>
  <cache-container>
    <transport cluster="${cluster.name}" stack="xsite"/>
  </cache-container>
</infinispan>

<infinispan>
  <jgroups>
    <stack name="relay-global" extends="tcp">
      <TCPPING initial_hosts="192.0.2.0[7800]"
               stack.combine="REPLACE"
               stack.position="MPING"/>
    </stack>
    <stack name="xsite" extends="udp">
      <relay.RELAY2 site="LON" xmlns="urn:org:jgroups"
                    max_site_masters="10"
                    can_become_site_master="true"/>
      <remote-sites default-stack="relay-global">
        <remote-site name="LON"/>
        <remote-site name="NYC"/>
      </remote-sites>
    </stack>
  </jgroups>
</infinispan>

Data Grid がこれらのクラスターのキャッシュにデータを複製できるように、リモートサイトの名前を指定します。

バックアップの設定

以下の例は、LON クラスターの "customers" キャッシュ設定を示しています。

<replicated-cache name="customers">
  <backups>
    <backup site="NYC"
            strategy="ASYNC" />
  </backups>
</replicated-cache>

{
  "replicated-cache": {
    "name": "customers",
    "backups": {
      "NYC": {
        "backup" : {
          "strategy" : "ASYNC"
        }
      }
    }
  }
}

replicatedCache:
  name: "customers"
  backups:
    NYC:
      backup:
        strategy: "ASYNC"

以下の例は、NYC クラスターの "customers" キャッシュ設定を示しています。

<distributed-cache name="customers">
  <backups>
    <backup site="LON"
            strategy="ASYNC" />
  </backups>
</distributed-cache>

{
  "distributed-cache": {
    "name": "customers",
    "backups": {
      "LON": {
        "backup": {
          "strategy": "ASYNC"
        }
      }
    }
  }
}

distributedCache:
  name: "customers"
  backups:
    LON:
      backup:
        strategy: "ASYNC"

デフォルトでは、Data Grid は同じ名前のキャッシュ間でデータを複製します。Data Grid を別の名前でキャッシュ間で複製する場合は、キャッシュごとにバックアップを明示的に宣言できます。

設定のバックアップ

以下の例では、LON クラスターの "customers" キャッシュから更新を受信するように、"eu-customers" キャッシュを設定します。

<distributed-cache name="eu-customers">
  <backups>
    <backup site="LON"
            strategy="ASYNC" />
  </backups>
  <backup-for remote-cache="customers"
              remote-site="LON" />
</distributed-cache>

{
  "distributed-cache": {
    "name": "eu-customers",
    "backups": {
      "LON": {
        "backup": {
          "strategy": "ASYNC"
        }
      }
    },
    "backup-for" : {
      "remote-cache" : "customers",
      "remote-site" : "LON"
    }
  }
}

distributedCache:
  name: "eu-customers"
  backups:
    LON:
      backup:
        strategy: "ASYNC"
  backupFor:
    remoteCache: "customers"
    remoteSite: "LON"

クロスサイト状態遷移設定を変更し、パフォーマンスを最適化して、操作を手動で行うか自動で行うかを指定します。

状態遷移の設定

<distributed-cache name="eu-customers">
  <backups>
    <backup site="LON"
            strategy="ASYNC">
      <state-transfer chunk-size="600"
                      timeout="2400000"
                      max-retries="30"
                      wait-time="2000"
                      mode="AUTO"/>
    </backup>
  </backups>
</distributed-cache>

{
  "distributed-cache": {
    "name": "eu-customers",
    "backups": {
      "LON": {
        "backup": {
          "strategy": "ASYNC",
          "state-transfer": {
            "chunk-size": "600",
            "timeout": "2400000",
            "max-retries": "30",
            "wait-time": "2000",
            "mode": "AUTO"
          }
        }
      }
    }
  }
}

distributedCache:
  name: "eu-customers"
  backups:
    LON:
      backup:
        strategy: "ASYNC"
        stateTransfer:
          chunkSize: "600"
          timeout: "2400000"
          maxRetries: "30"
          waitTime: "2000"
          mode: "AUTO"

別のアルゴリズムを使用してバックアップの場所間の競合するエントリーを解決するように Data Grid を設定します。

Data Grid アルゴリズム

以下の設定例では、両方のサイトから競合するエントリーを削除する ALWAYS_REMOVE アルゴリズムを使用します。

<distributed-cache>
   <backups merge-policy="ALWAYS_REMOVE">
      <backup site="LON" strategy="ASYNC"/>
   </backups>
</distributed-cache>

{
  "distributed-cache": {
    "backups": {
      "merge-policy": "ALWAYS_REMOVE",
      "LON": {
        "backup": {
          "strategy": "ASYNC"
        }
      }
    }
  }
}

distributedCache:
  backups:
    mergePolicy: "ALWAYS_REMOVE"
    LON:
      backup:
        strategy: "ASYNC"

カスタム競合解決アルゴリズム

カスタムの XSiteEntryMergePolicy 実装を作成する場合は、完全修飾クラス名をマージポリシーとして指定することができます。

<distributed-cache>
   <backups merge-policy="org.mycompany.MyCustomXSiteEntryMergePolicy">
      <backup site="LON" strategy="ASYNC"/>
   </backups>
</distributed-cache>

{
  "distributed-cache": {
    "backups": {
      "merge-policy": "org.mycompany.MyCustomXSiteEntryMergePolicy",
      "LON": {
        "backup": {
          "strategy": "ASYNC"
        }
      }
    }
  }
}

distributedCache:
  backups:
    mergePolicy: "org.mycompany.MyCustomXSiteEntryMergePolicy"
    LON:
      backup:
        strategy: "ASYNC"

非同期バックアップ戦略では、Data Grid は、キーを削除するときに、廃棄 (Tombstone) と呼ばれるメタデータを格納します。Data Grid は定期的にタスクを実行して、これらの Tombstone を削除し、バックアップの場所でメタデータが不要になったときに過剰なメモリー使用量を減らします。Tombstone マップのターゲットサイズとタスク実行間の最大遅延を定義することで、このタスクの頻度を設定できます。

Tombstone のクリーンアップタスクの設定

<distributed-cache>
   <backups tombstone-map-size="512000" max-cleanup-delay="30000">
      <backup site="LON" strategy="ASYNC"/>
   </backups>
</distributed-cache>

{
  "distributed-cache": {
    "backups": {
      "tombstone-map-size": 512000,
      "max-cleanup-delay": 30000,
      "LON": {
        "backup": {
          "strategy": "ASYNC"
        }
      }
    }
  }
}

distributedCache:
  backups:
    tombstoneMapSize: 512000
    maxCleanupDelay: 30000
    LON:
      backup:
        strategy: "ASYNC"

クロスサイトレプリケーションを実行するように Data Grid を設定する場合、ログファイルを確認して、Data Grid クラスターがクロスサイトビューを正常に形成したことを確認する必要があります。

たとえば、LON の Data Grid クラスターが NYC の Data Grid クラスターとクロスサイトビューを形成している場合、ログには以下のメッセージが含まれます。

INFO  [org.infinispan.XSITE] (jgroups-5,<server-hostname>) ISPN000439: Received new x-site view: [NYC]
INFO  [org.infinispan.XSITE] (jgroups-7,<server-hostname>) ISPN000439: Received new x-site view: [LON, NYC]

異なるサイトで Data Grid クラスターを使用するように Hot Rod クライアントを設定します。

# Servers at the active site
infinispan.client.hotrod.server_list = LON_host1:11222,LON_host2:11222,LON_host3:11222

# Servers at the backup site
infinispan.client.hotrod.cluster.NYC = NYC_hostA:11222,NYC_hostB:11222,NYC_hostC:11222,NYC_hostD:11222

ConfigurationBuilder builder = new ConfigurationBuilder();
builder.addServers("LON_host1:11222;LON_host2:11222;LON_host3:11222")
       .addCluster("NYC")
       .addClusterNodes("NYC_hostA:11222;NYC_hostB:11222;NYC_hostC:11222;NYC_hostD:11222")

バックアップ場所を手動でオフラインにし、オンラインに戻します。

詳細と例については、help site コマンドを実行してください。

バックアップの場所がオンラインになったことを DataGrid が検出したときに自動的に発生するように、サイト間の状態転送操作を設定できます。または、状態遷移を手動で実行するデフォルトのモードを使用できます。

キャッシュの状態をバックアップの場所に転送します。

詳細と例については、help site コマンドを実行してください。

GET リクエストですべてのバックアップロケーションのステータスを取得します。

GET /rest/v2/caches/{cacheName}/x-site/backups/

Data Grid は、以下の例のように、各バックアップロケーションのステータスを JSON 形式で応答します。

{
  "NYC": {
    "status": "online"
  },
  "LON": {
    "status": "mixed",
    "online": [
      "NodeA"
    ],
    "offline": [
      "NodeB"
    ]
  }
}

GET リクエストでバックアップロケーションのステータスを取得する。

GET /rest/v2/caches/{cacheName}/x-site/backups/{siteName}

Data Grid は、以下の例のように、サイト内の各ノードのステータスを JSON 形式で応答します。

{
  "NodeA":"offline",
  "NodeB":"online"
}

POST リクエストと ?action=take-offline パラメーターを使用して、バックアップの場所をオフラインにします。

POST /rest/v2/caches/{cacheName}/x-site/backups/{siteName}?action=take-offline

?action=bring-online パラメーターを使用してバックアップ場所をオンラインにします。

POST /rest/v2/caches/{cacheName}/x-site/backups/{siteName}?action=bring-online

?action=start-push-state パラメーターを使用して、キャッシュ状態をバックアップ場所にプッシュします。

POST /rest/v2/caches/{cacheName}/x-site/backups/{siteName}?action=start-push-state

?action=cancel-push-state パラメーターを使用して状態転送操作をキャンセルします。

POST /rest/v2/caches/{cacheName}/x-site/backups/{siteName}?action=cancel-push-state

?action=push-state-status パラメーターを使用して状態転送操作のステータスを取得します。

GET /rest/v2/caches/{cacheName}/x-site/backups?action=push-state-status

Data Grid は、以下の例のように、各バックアップ拠点の状態移行の状況を JSON 形式で応答します。

{
   "NYC":"CANCELED",
   "LON":"OK"
}

?action=clear-push-state-status パラメーターを使用して送信サイトの状態転送ステータスをクリアします。

POST /rest/v2/caches/{cacheName}/x-site/local?action=clear-push-state-status

特定の条件が満たされると、サイトはオフラインになります。オフラインにするパラメーターを変更して、バックアップロケーションが自動的にオフラインになるタイミングを制御します。

2 つのバックアップ場所間の接続が切断された場合、プッシュを受信しているサイトでの状態転送をキャンセルできます。

?action=cancel-receive-state パラメーターで、リモートサイトからの状態転送をキャンセルし、ローカルキャッシュの現在の状態を維持する。

POST /rest/v2/caches/{cacheName}/x-site/backups/{siteName}?action=cancel-receive-state

GET 要求により、キャッシュ・マネージャーからすべてのバックアップ・ロケーションのステータスを取得します。

GET /rest/v2/cache-managers/{cacheManagerName}/x-site/backups/

Data Grid は、以下の例のように JSON 形式でステータスを応答します。

{
   "SFO-3":{
      "status":"online"
   },
   "NYC-2":{
      "status":"mixed",
      "online":[
         "CACHE_1"
      ],
      "offline":[
         "CACHE_2"
      ],
      "mixed": [
         "CACHE_3"
      ]
   }
}

GET /rest/v2/cache-managers/{cacheManagerName}/x-site/backups/{site}

1 つのバックアップの場所のステータスを返します。

?action=take-offline パラメーターで、バックアップロケーションをオフラインにします。

POST /rest/v2/cache-managers/{cacheManagerName}/x-site/backups/{siteName}?action=take-offline

?action=bring-online パラメーターを使用してバックアップ場所をオンラインにします。

POST /rest/v2/cache-managers/{cacheManagerName}/x-site/backups/{siteName}?action=bring-online

GET リクエストで状態転送モードを確認してください。

GET /rest/v2/caches/{cacheName}/x-site/backups/{site}/state-transfer-mode

?action=set パラメーターを使用して状態転送モードを設定します。

POST /rest/v2/caches/{cacheName}/x-site/backups/{site}/state-transfer-mode?action=set&mode={mode}

?action=start-push-state パラメーターを使用して、すべてのキャッシュの状態をリモートサイトにプッシュします。

POST /rest/v2/cache-managers/{cacheManagerName}/x-site/backups/{siteName}?action=start-push-state

?action=cancel-push-state パラメーターを使用して、進行中の状態転送操作をキャンセルします。

POST /rest/v2/cache-managers/{cacheManagerName}/x-site/backups/{siteName}?action=cancel-push-state

Data Grid は、統計の収集と管理操作の実行に使用できる JMX MBean を登録できます。統計を有効にする必要もあります。そうしないと、Data Grid は JMX MBean のすべての統計属性に 0 値を提供します。

JMX の設定

<infinispan>
  <cache-container statistics="true">
    <jmx enabled="true"
         domain="example.com"/>
  </cache-container>
</infinispan>

{
  "infinispan" : {
    "cache-container" : {
      "statistics" : "true",
      "jmx" : {
        "enabled" : "true",
        "domain" : "example.com"
      }
    }
  }
}

infinispan:
  cacheContainer:
    statistics: "true"
    jmx:
      enabled: "true"
      domain: "example.com"

JMX クライアントを使用してクロスサイト操作を実行します。

Data Grid は、統計を収集し、リモート操作を実行できるクロスサイトレプリケーションに JMX MBean を提供します。

org.infinispan:type=Cache コンポーネントは、以下の JMX MBean を提供します。

org.infinispan:type=CacheManager コンポーネントには以下の JMX MBean が含まれます。

JMX MBean および利用可能な操作および統計の説明に関する詳細は、Data Grid JMX Components のドキュメントを参照してください。

クロスサイトレプリケーションに関連するログメッセージのユーザーアクションを検索します。