マルチクラスター環境の構築

IBM® Sterling Intelligent Promising マルチクラスター設定により、複数のデータセンター間でデータの複製が可能になり、可用性と一貫性が向上します。

覚えておいてください:マルチクラスター設定を実装することは必須ではありません。ただし、本番環境ではマルチクラスタのセットアップを推奨する。

コンテキスト

Sterling Intelligent Promisingは主に2つのデータベースに依存している：CassandraとElasticsearchです。データの種類によっては、片方または両方のデータベースに保存されることもある。

在庫データ（供給、需要、予約）：最初はCassandraに格納され、その後Elasticsearchと同期される。
在庫監査データ：Elasticsearchにのみ保存されます。
ルールの設定データ：Elasticsearchにのみ保存されます。
カタログデータ：Elasticsearchにのみ保存されています。

マルチクラスターセットアップにおけるデータレプリケーションの必要性: マルチクラスターのセットアップでは、通常2つのデータセンターが利用できる。一方のデータセンターで問題が発生した場合、APIトラフィックをもう一方のデータセンターに迂回させることで、ビジネスの継続性を確保し、サービスの可用性を維持することができる。そのためには、両データセンター間でデータベースを同期させておくことが重要だ。

Cassandraデータ・レプリケーション: Cassandraはマルチデータ・センター（DC）クラスターのセットアップをネイティブにサポートします。 Cassandraのクロス・データ・センター（DC）データ・レプリケーションが有効になっていることを確認します。複数のデータセンター間でデータの一貫性を確保し、可用性を高めることが不可欠だ。

Elasticsearchデータレプリケーション: Elasticsearch をデプロイすることで、異なるElasticsearch クラスタ間でネイティブにデータを複製することができます。しかし、各 Kubernetes クラスタ内に、2つの独立した Elasticsearch クラスタをセットアップすれば、独立して運用することができます。 Sterling Intelligent Promisingは、これら2つのクラスタ間でほぼリアルタイムにデータを複製するメカニズムを提供する。
Elasticsearch におけるデータの取り込みは、Kafka トピックを通して行われます。 Sterling Intelligent Promising は Kafka のデータのレプリケーションをサポートしており、Elasticsearch に Kafka MirrorMaker 経由でデータを送ることができます。ミラートピックを設定することで、Elasticsearch のデータを複数のデータセンターでリアルタイムにレプリケートすることができます。したがって、クラスタ間で一貫したトピックデータを維持することができる。これにより、1つのデータセンターがダウンしても、Elasticsearchに依存している機能は、別のデータセンターのレプリケートされたデータを通じて稼動し続け、ビジネスの継続性を維持し、シームレスなユーザーエクスペリエンスを提供します。

このタスクについて

マルチクラスター設定を行うには、ミラー化された Kafka トピックを設定し、Elasticsearch データをレプリケートするために必要なカスタムリソース定義を更新します。

手順

次のセクションで示すように、各サービスの Kafka トピックをミラーリングします。
以下の手順に従って、カスタムリソース定義を設定する。
1. Elasticsearchのデータ・レプリケーションを有効にするには、multiDCEnabledとreplicationEnabledをtrueに設定する。
```
apiVersion: apps.sip.ibm.com/v1beta1
kind: SIPEnvironment
metadata:
  name: sip
  namespace: test
spec:
  multiDCEnabled: true
  externalServices:
    elasticSearch:
      replicationEnabled: true
```
  覚えておいてください: デプロイのために選んだクラウドプロバイダがElasticsearchデータレプリケーションを提供していて、それを使うことを選択した場合、elasticSearch の replicationEnabled を false に設定することができます。また、Elasticsearch データレプリケーションのためにミラートピックを作成する必要はありません。しかし、この条件下ではElasticsearch のデータはレプリケートされません。
```
apiVersion: apps.sip.ibm.com/v1beta1
kind: SIPEnvironment
metadata:
  name: sip
  namespace: test
spec:
  multiDCEnabled: true
  externalServices:
    elasticSearch:
      replicationEnabled: false
```
2. Kafkaトピックをミラーリングするには、異なるデータセンター間で使用されるトピックに以下のKafka接頭辞を定義します。
  1. topicPrefix：現在のデータセンターのKafkaトピックに使用されるプレフィックス。すべてのクラスターに同じtopicPrefixを使うことをお勧めします。
  2. mirrorTopicPrefix：Kafka MirrorMaker で、複製先クラスタの複製トピックにラベルを付けるために使用するプレフィックス。この属性を使用すると、レプリケーション中に指定した接頭辞を名前に付加することで、ミラー化されたトピックを識別できます。
    例topicPrefixがsipで、mirrorTopicPrefixがdc1の場合、ソースクラスタではsip-catalog-update-attributeという名前のトピックが、デスティネーションクラスタではdc1.sip-catalog-update-attributeとしてレプリケートされます。この明確なラベル付けは、ミラーリングされるトピックと、それがどのソース・データ・センターから発信されたかを特定するのに役立つ。
    注意: Kafka MirrorMakerを自分でセットアップして、実際のレプリケーション処理を行います。 Sterling Intelligent Promisingは、指定された命名規則を使って、これらのミラー化されたトピックからデータを読み込む。
  3. crossDCTopicPrefix：他のデータセンターのKafkaトピック専用に使用されるオプションのプレフィックス。指定されていない場合は、topicPrefixがミラートピックに使われます。
3. オプションのenvironmentパラメータを設定して、トピック名の環境コンテキストを指定します。指定する場合は、すべてのクラスタで同じでなければならないことを確認してください。
  次の例は、Kafka のプレフィックスと、SIPEnvironment で設定されている環境パラメータを示しています。
```
apiVersion: apps.sip.ibm.com/v1beta1
kind: SIPEnvironment
metadata:
  name: sip
  namespace: test
spec:
  environment: ""
  externalServices:
    kafka:
      topicPrefix: ""
      mirrorTopicPrefix: ""
      crossDCTopicPrefix: ""
```