Configurar o Cassandra para produção

Neste tópico, descrevemos as etapas necessárias e recomendadas para configurar o componente de banco de dados do Cassandra para uma instalação de produção híbrida da Apigee.

Configurações necessárias

As configurações a seguir são obrigatórias.

Garanta alta disponibilidade

Os clusters do Cassandra precisam de três zonas de disponibilidade para manter a disponibilidade em um ambiente de produção. Se uma zona ficar inativa, as restantes continuarão respondendo a solicitações até a zona remanescente ficar on-line novamente. Se duas ou mais zonas ficarem inativas, o Cassandra não responderá a solicitações até que pelo menos duas zonas fiquem on-line. A Apigee recomenda colocar as zonas on-line novamente em três horas para minimizar o risco de perda de atualizações de dados.

Definir as configurações de armazenamento do Cassandra

Para uma instalação de produção da Apigee híbrida, o Google recomenda que você adicione as seguintes configurações de armazenamento e heap ao arquivo de modificações e aplique-as ao cluster: 

cassandra:
  ...
  replicaCount: 3
  storage:
    storageclass: your-preferred-ssd-storage #If not using default storage for your cluster
    capacity: 500Gi
  resources:
    requests:
      cpu: 7
      memory: 15Gi
  maxHeapSize: 8192M
  heapNewSize: 1200M

Aplique as alterações no cassandra com o seguinte comando: 

helm upgrade datastore apigee-datastore/ \
--namespace apigee \
--atomic \
-f OVERRIDES_FILE.yaml

replicaCount

O valor de replicaCount precisa ser um múltiplo de 3. Para determinar o valor replicaCount desejado, considere o seguinte:

  • Estime as demandas de tráfego dos proxies.
  • Carregue o teste e faça previsões razoáveis de uso da CPU.
  • É possível especificar valores replicaCount diferentes em regiões diferentes.
  • Você pode expandir o replicaCount no futuro no arquivo de modificações.

storageclass

Para produção, o armazenamento do Cassandra precisa ser um StorageClass SSD. Defina o valor de storageclass se você não estiver usando o StorageClass padrão do Kubernetes para o cluster. Você pode verificar o StorageClass padrão com o comando a seguir.

kubectl get storageclass

A resposta será semelhante a esta: 

NAME                     PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
premium-rwo              pd.csi.storage.gke.io   Delete          WaitForFirstConsumer   true                   6d23h
standard                 kubernetes.io/gce-pd    Delete          Immediate              true                   6d23h
standard-rwo (default)   pd.csi.storage.gke.io   Delete          WaitForFirstConsumer   true                   6d23h

Siga as instruções em Configuração do StorageClass se você quiser alterar o StorageClass padrão do Kubernetes.

Para verificar a configuração atual do storageclass, execute o seguinte comando no cluster: 

kubectl get pvc -n NAMESPACE cassandra-data-apigee-cassandra-default-0 -o=jsonpath="{['.spec.storageClassName', '.metadata.annotations.volume\.beta\.kubernetes\.io/storage-class']}"

storageSize

Para instalações de produção, o Google recomenda um tamanho de armazenamento de pelo menos 500 Gi (gibibytes). É possível alterar o tamanho de armazenamento de acordo com as necessidades do cluster. Consulte as instruções em Expandir volumes permanentes do Cassandra para alterar a capacidade de armazenamento.

Para verificar a configuração de tamanho atual, execute o seguinte comando no cluster: 

kubectl get pvc -n NAMESPACE cassandra-data-apigee-cassandra-default-0 -o=jsonpath='{.spec.resources.requests.storage}'

cpu e memory

Para instalações de produção, o Google recomenda pelo menos 7 CPUs e um mínimo de 15 Gi (gibibytes) por pod. Ao especificar cassandra.resources.requests.cpu e cassandra.resources.requests.memory, considere o volume de tráfego e as demandas de CPU e memória dos proxies.

Para verificar a configuração atual da CPU, execute o seguinte comando no cluster: 

kubectl get pods -n NAMESPACE apigee-cassandra-default-0 -o=jsonpath='{.spec.containers[].resources.requests.cpu}'

Para verificar a configuração de memória atual, execute o seguinte comando no cluster: 

kubectl get pods -n NAMESPACE apigee-cassandra-default-0 -o=jsonpath='{.spec.containers[].resources.requests.memory}'

maxHeapSize e heapNewSize

Essas propriedades determinam o heap máximo de memória alocado para os processos do cassandra e a quantidade pela qual a memória é aumentada, respectivamente, em megabytes (os tamanhos de heap são especificados em megabytes, não em mebibytes). Para ambientes de produção, o Google recomenda os seguintes valores:

  • maxHeapSize: 8192M
  • heapNewSize: 1200M

Consulte a documentação do seu provedor da plataforma Kubernetes para ver os valores de tamanho de heap ideais.

Para verificar a configuração atual do maxHeapSize, execute o seguinte comando no cluster: 

kubectl get sts -n NAMESPACE apigee-cassandra-default -o=jsonpath='{.spec.template.spec.containers[].env[?(@.name=="MAX_HEAP_SIZE")]}'

Para verificar a configuração atual do heapNewSize, execute o seguinte comando no cluster: 

kubectl get sts -n NAMESPACE apigee-cassandra-default -o=jsonpath='{.spec.template.spec.containers[].env[?(@.name=="HEAP_NEWSIZE")]}'

Para mais informações sobre essas configurações de propriedades, consulte a Referência da propriedades de configuração.

Usar o armazenamento SSD para implantações de produção

Para o banco de dados do Cassandra, o ambiente de execução híbrido aceita apenas o uso de volumes permanentes criados dinamicamente para armazenar dados. As unidades de disco de estado sólido (SSD) locais não são compatíveis.

Se você não tiver o SSD configurado para o Cassandra atualmente, precisará configurar uma definição do StorageClass que seja apoiada por uma unidade de estado sólido (SSD) e torná-la o padrão. Consulte as etapas detalhadas em Configuração de StorageClass.

Siga as instruções em Configuração do StorageClass se você quiser alterar o StorageClass padrão do Kubernetes.

Esta seção descreve as configurações recomendadas para o Cassandra.

Configurar uma programação de backup diária

Em caso de um problema multirregional do Cassandra após uma configuração incorreta, o Google não poderá restaurar os dados de execução, o que resultará na perda permanente de dados.

Para evitar a perda de dados, configure uma programação de backup diária. Monitore os tamanhos e a frequência dos backups e garanta que você seja notificado quando o pipeline de backup falhar.

Seguir os requisitos mínimos de cluster do Cassandra

Siga a configuração mínima do cluster para o Cassandra.

Tratar todos os ambientes voltados ao cliente como produção

Mesmo que sua instalação híbrida seja considerada "não produção", talvez seja necessário definir configurações prontas para produção. Por exemplo, interrupções em instalações de testes de aceitação do usuário (UAT, na sigla em inglês) devem acionar incidentes de alta prioridade.

Use configurações prontas para produção mesmo para instalações híbridas voltadas ao cliente "não produção". Recomendamos que você siga os mesmos princípios para todos os ambientes voltados ao cliente, assim como para servidores de produção, conforme descrito neste artigo. Em particular, siga os princípios de recuperação de desastres usando replicaCount e regiões. Consulte Configurar as configurações de armazenamento do Cassandra para mais detalhes.