Configure o Cassandra para produção

Este tópico descreve os passos obrigatórios e recomendados para configurar o componente da base de dados Cassandra para uma instalação de produção do Apigee Hybrid.

Configurações necessárias

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

Garantir alta disponibilidade

Os clusters do Cassandra precisam de três zonas de disponibilidade para manter a disponibilidade num ambiente de produção. Se uma zona ficar inativa, as zonas restantes continuam a responder aos pedidos enquanto a zona inativa volta a ficar online. Se duas ou mais zonas ficarem inativas, o Cassandra não consegue responder a pedidos até que, pelo menos, duas zonas estejam online. A Apigee recomenda que volte a colocar as zonas online no prazo de três horas para minimizar o risco de perder atualizações de dados.

Configure as definições de armazenamento do Cassandra

Para uma instalação de produção do Apigee hybrid, a Google recomenda que adicione as seguintes definições de armazenamento e memória dinâmica ao seu ficheiro de substituições e as aplique 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 ao Cassandra com o seguinte comando: 

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

replicaCount

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

  • Estime as exigências de tráfego para os seus proxies.
  • Faça um teste de carga e previsões razoáveis da utilização da CPU.
  • Pode especificar valores replicaCount diferentes em regiões diferentes.
  • Pode expandir o replicaCount no futuro no ficheiro de substituições.

storageclass

Para a produção, o armazenamento do Cassandra tem de ser uma StorageClass de SSD. Defina o valor de storageclass se não estiver a usar a StorageClass do Kubernetes predefinida para o seu cluster. Pode verificar a StorageClass predefinida com o seguinte comando.

kubectl get storageclass

O resultado deve ter um aspeto semelhante ao seguinte: 

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 na configuração StorageClass se quiser alterar a StorageClass do Kubernetes predefinida.

Para verificar a definição storageclass atual, 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, a Google recomenda um tamanho de armazenamento de, pelo menos, 500 Gi (gibibytes). Pode alterar o tamanho do armazenamento em função das necessidades de armazenamento do cluster. Consulte as instruções em Expanda os volumes persistentes do Cassandra para alterar o tamanho do armazenamento.

Para verificar a definição de tamanho de armazenamento 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, a Google recomenda, pelo menos, 7 CPUs e um mínimo de 15 Gi (gibibytes) por pod. Quando especificar cassandra.resources.requests.cpu e cassandra.resources.requests.memory, considere o volume de tráfego e as exigências de CPU e memória dos seus proxies.

Para verificar a definiçã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 definiçã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

Estas propriedades determinam a quantidade máxima de memória atribuída aos processos do Cassandra e a quantidade pela qual a memória é aumentada, respetivamente, em megabytes (os tamanhos da memória atribuída são especificados em megabytes, e não em mebibytes). Para ambientes de produção, a Google recomenda os seguintes valores:

  • maxHeapSize: 8192M
  • heapNewSize: 1200M

Consulte a documentação do fornecedor da plataforma Kubernetes para ver os valores ideais do tamanho da memória dinâmica.

Para verificar a definição maxHeapSize atual, 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 definição heapNewSize atual, 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 estas definições da propriedade, consulte a referência da propriedade de configuração.

Use armazenamento SSD para implementações de produção

Para a base de dados Cassandra, o tempo de execução híbrido só suporta a utilização de volumes persistentes criados dinamicamente para armazenar dados. Os discos rígidos (SSD) locais não são suportados.

Se não tiver atualmente o SSD configurado para o Cassandra, tem de configurar uma definição de StorageClass com base num disco de estado sólido (SSD) e torná-la na classe predefinida. Consulte a configuração de StorageClass para ver os passos detalhados.

Siga as instruções na configuração StorageClass se quiser alterar a StorageClass do Kubernetes predefinida.

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

Configure um agendamento de cópias de segurança diário

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

Para evitar a perda de dados, configure um horário de cópia de segurança diário. Monitorize os tamanhos e a frequência das cópias de segurança e certifique-se de que recebe uma notificação quando o pipeline de cópias de segurança falha.

Aderir aos requisitos mínimos do cluster do Cassandra

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

Trate todos os ambientes virados para o cliente como produção

Mesmo que a sua instalação híbrida seja considerada "não de produção", ainda pode precisar de definições prontas para produção. Por exemplo, as indisponibilidades nas instalações de testes de aceitação do utilizador (UAT) devem acionar incidentes de prioridade elevada.

Use definições prontas para produção, mesmo para instalações híbridas viradas para o cliente "não de produção". Recomendamos que siga os mesmos princípios para todos os ambientes virados para o cliente que para os 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 o artigo Configure as definições de armazenamento do Cassandra para ver detalhes.