Configuração de um ambiente multicluster

A configuração de IBM® Sterling Intelligent Promising multicluster permite a replicação de dados em vários data centers para garantir maior disponibilidade e consistência.

Lembre-se:Não é obrigatório implementar uma configuração de vários clusters. No entanto, recomenda-se uma configuração de vários clusters para ambientes de produção.
Contexto

O Sterling Intelligent Promising depende principalmente de dois bancos de dados: Cassandra e Elasticsearch. Dependendo do tipo de dados, eles podem ser armazenados em um ou em ambos os bancos de dados.

  • Dados de inventário (oferta, demanda, reserva): Inicialmente armazenados em Cassandra, depois sincronizados com Elasticsearch.
  • Dados de auditoria de inventário: Armazenados exclusivamente no Elasticsearch.
  • Dados de configuração de regras: Armazenados exclusivamente no Elasticsearch.
  • Dados do catálogo: Armazenados exclusivamente no Elasticsearch.
Necessidade de replicação de dados em uma configuração de vários clusters
Em uma configuração de vários clusters, geralmente há dois data centers disponíveis. Se ocorrer um problema em um data center, o tráfego da API poderá ser desviado para o outro data center para garantir a continuidade dos negócios e manter a disponibilidade dos serviços. Para isso, é fundamental manter os bancos de dados sincronizados entre os dois data centers.
Cassandra replicação de dados
O Cassandra oferece suporte nativo à configuração de um cluster de vários centros de dados (DC). Certifique-se de que a replicação de dados entre centros de dados (DC) para Cassandra esteja ativada. É essencial garantir a consistência dos dados e manter uma maior disponibilidade em vários data centers.
Elasticsearch replicação de dados
Você pode implantar o Elasticsearch para replicar dados nativamente em diferentes Elasticsearch. No entanto, se você configurar dois clusters Elasticsearch independentes dentro de cada cluster Kubernetes, eles poderão operar de forma independente. O Sterling Intelligent Promising fornece um mecanismo para replicação de dados quase em tempo real entre esses dois clusters.

A ingestão de dados no Elasticsearch é conduzida por meio de tópicos do Kafka. O Sterling Intelligent Promising suporta a replicação de dados do Kafka e, portanto, de dados para o Elasticsearch por meio do Kafka MirrorMaker. A configuração de tópicos espelhados garante a replicação em tempo real dos dados do Elasticsearch em vários data centers. Assim, mantendo dados de tópicos consistentes em todos os clusters. Isso garante que, mesmo que um data center fique inoperante, os recursos dependentes do Elasticsearch permaneçam operacionais por meio dos dados replicados em outro data center, o que mantém a continuidade dos negócios e proporciona uma experiência de usuário perfeita.

Sobre esta tarefa

Para implementar a configuração de vários clusters, configure os tópicos espelhados do Kafka e atualize as definições de recursos personalizados necessários para replicar os dados do Elasticsearch.

Procedimento

  • Mirrorize os tópicos do Kafka para cada serviço, conforme demonstrado nas seções a seguir.
  • Configure as definições de recursos personalizados conforme mostrado nas etapas a seguir.
    1. Para ativar a replicação de dados do Elasticsearch, configure multiDCEnabled e replicationEnabled como true.
      apiVersion: apps.sip.ibm.com/v1beta1
kind: SIPEnvironment
metadata:
  name: sip
  namespace: test
spec:
  multiDCEnabled: true
  externalServices:
    elasticSearch:
      replicationEnabled: true
      Lembre-se: Se o provedor de nuvem que você escolheu para a implantação oferecer Elasticsearch e você optar por usá-la, poderá definir replicationEnabled em elasticSearch para false. Além disso, você não precisa criar tópicos espelhados para a replicação de dados do Elasticsearch. No entanto, o aplicativo não replicará os dados do Elasticsearch nessas condições.
      apiVersion: apps.sip.ibm.com/v1beta1
kind: SIPEnvironment
metadata:
  name: sip
  namespace: test
spec:
  multiDCEnabled: true
  externalServices:
    elasticSearch:
      replicationEnabled: false
    2. Para espelhar tópicos do Kafka, defina os seguintes prefixos do Kafka para os tópicos usados em diferentes data centers.
      1. topicPrefix: Um prefixo usado para tópicos do Kafka no data center atual. Recomenda-se usar o mesmo topicPrefix para todos os clusters.
      2. mirrorTopicPrefix: Um prefixo usado no Kafka MirrorMaker para rotular tópicos replicados em clusters de destino. Com esse atributo, você pode identificar tópicos espelhados acrescentando um prefixo especificado aos seus nomes durante a replicação.
        Exemplo: Se topicPrefix for sip e mirrorTopicPrefix for dc1, um tópico denominado sip-catalog-update-attribute no cluster de origem será replicado como dc1.sip-catalog-update-attribute no cluster de destino. Essa rotulagem clara ajuda a identificar os tópicos que são espelhados e de quais data centers de origem eles são originados.
        Nota: Configure o Kafka MirrorMaker por conta própria para lidar com o processo de replicação real. O Sterling Intelligent Promising lê dados desses tópicos espelhados usando a convenção de nomenclatura especificada.
      3. crossDCTopicPrefix: Um prefixo opcional usado especificamente para tópicos do Kafka em outros data centers. Se não for fornecido, topicPrefix será usado para tópicos espelhados.
    3. Configure o parâmetro opcional environment para especificar o contexto do ambiente para nomes de tópicos. Certifique-se de que, se você especificá-lo, ele deve ser o mesmo para todos os clusters.
      O exemplo a seguir mostra os prefixos Kafka e o parâmetro de ambiente que estão configurados em SIPEnvironment.
      apiVersion: apps.sip.ibm.com/v1beta1
kind: SIPEnvironment
metadata:
  name: sip
  namespace: test
spec:
  environment: ""
  externalServices:
    kafka:
      topicPrefix: ""
      mirrorTopicPrefix: ""
      crossDCTopicPrefix: ""