Como escalonar o Cassandra

Neste tópico, discutimos como escalonar o Cassandra horizontal e verticalmente e como reduzir seu escalonamento.

Como escalonar o Cassandra horizontalmente

Para escalonar o Cassandra horizontalmente

Verifique se o pool de nós apigee-data tem capacidade adicional, conforme necessário, antes de escalonar o Cassandra. Consulte também Como configurar pools de nós dedicados.
Defina o valor da propriedade de configuração cassandra.replicaCount no seu arquivo de modificações. 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.
Para informações sobre essa propriedade, leia a Referência de propriedades de configuração. Consulte também Gerenciar componentes do plano de execução.

Observação: o fator de replicação padrão para todos os keyspaces é três. Como resultado, recomendamos escalonar as réplicas por um fator de três.
Aplique as alterações. Exemplo:
```
helm upgrade datastore apigee-datastore/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f OVERRIDES_FILE.yaml
```
Observação: se você encontrar um erro que diz Error: UPGRADE FAILED: "datastore" has no deployed releases, substitua upgrade por install e repita o comando.

Como escalonar o Cassandra verticalmente

Nesta seção, explicamos como escalonar os pods do Cassandra verticalmente para acomodar requisitos maiores de CPU e memória.

Visão geral

Para uma implantação de produção híbrida da Apigee, recomendamos criar pelo menos dois pools de nós separados: um para serviços com estado (Cassandra) e outro para serviços sem estado (tempo de execução). Por exemplo, consulte Requisitos do cluster de produção do GKE.

Para o pool de nós com estado do Cassandra, recomendamos começar com 8 núcleos de CPU e 30 GB de memória. Depois que o pool de nós estiver provisionado, essas configurações não podem ser alteradas. Consulte também Configurar o Cassandra para produção.

Se precisar escalonar verticalmente os pods do Cassandra para acomodar requisitos maiores de CPU e memória, siga as etapas descritas neste tópico.

Como escalonar verticalmente os pods do Cassandra

Siga estas etapas para aumentar a CPU e a memória do pool de nós com estado usado no Cassandra:

Siga as instruções da plataforma Kubernetes para adicionar um novo pool de nós ao cluster. As plataformas compatíveis estão listadas nas instruções de instalação.

Verifique se o novo pool de nós está pronto:

kubectl get nodes -l NODE_POOL_LABEL_NAME=NODE_POOL_LABEL_VALUE

Exemplo de comando:

kubectl get nodes -l cloud.google.com/gke-nodepool=apigee-data-new

Exemplo de saída:

NAME                                                STATUS   ROLES    AGE     VERSION
gke-apigee-data-new-441387c2-2h5n   Ready    <none>   4m28s   v1.14.10-gke.17
gke-apigee-data-new-441387c2-6941   Ready    <none>   4m28s   v1.14.10-gke.17
gke-apigee-data-new-441387c2-nhgc   Ready    <none>   4m29s   v1.14.10-gke.17

Atualize seu arquivo de modificações para usar o novo pool de nós no Cassandra e atualize os recursos do pod para o tamanho maior da contagem de CPU e da memória que você quer usar. Por exemplo, para um cluster do GKE, use uma configuração semelhante à seguinte. Se estiver em outra plataforma do Kubernetes, precisará ajustar o valor apigeeData.key adequadamente:

nodeSelector:
  requiredForScheduling: true
  apigeeData:
    key: "NODE_POOL_LABEL_NAME"
    value: "NODE_POOL_LABEL_VALUE"

cassandra:
  resources:
    requests:
      cpu: NODE_POOL_CPU_NUMBER
      memory: NODE_POOL_MEMORY_SIZE

Exemplo:

nodeSelector:
  requiredForScheduling: true
  apigeeData:
    key: "cloud.google.com/gke-nodepool"
    value: "apigee-data-new"

cassandra:
  resources:
    requests:
      cpu: 14
      memory: 16Gi

Aplique o arquivo de modificações ao cluster:

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

Ao concluir essas etapas, os pods do Cassandra começarão a ser transferidos para o novo pool de nós.

Como reduzir o escalonamento do Cassandra

O híbrido da Apigee emprega um anel de nós do Cassandra como um StatefulSet. O Cassandra fornece armazenamento persistente para determinadas entidades da Apigee no plano de ambiente de execução. Para mais informações sobre o Cassandra, consulte Sobre o plano de ambiente de execução.

O Cassandra é um serviço de uso intensivo de recursos e não pode ser implantado em um pod com outros serviços híbridos. Dependendo da carga, convém escalonar o número de nós do Cassandra no anel do seu cluster.

O processo geral para escalonamento de um anel do Cassandra é:

Verifique se o cluster do Cassandra está íntegro e tem armazenamento suficiente para suportar a redução do escalonamento vertical.
Atualize a propriedade cassandra.replicaCount em overrides.yaml.
Aplique a atualização de configuração.
Exclua a reivindicação ou o volume do volume permanente, dependendo da configuração do cluster.

Algumas informações importantes

Se algum nó que não seja os nós a serem desativados não estiver íntegro, não continue. O Kubernetes não poderá diminuir o escalonamento vertical dos pods do cluster.
Sempre aumente ou diminua o escalonamento com um fator de três nós.

Redução do escalonamento vertical do Cassandra

Verifique se o cluster está íntegro e se todos os nós estão em execução, conforme o exemplo a seguir:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

NAME                 READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h
apigee-cassandra-default-3   1/1     Running   0          16m
apigee-cassandra-default-4   1/1     Running   0          14m
apigee-cassandra-default-5   1/1     Running   0          13m
apigee-cassandra-default-6   1/1     Running   0          9m
apigee-cassandra-default-7   1/1     Running   0          9m
apigee-cassandra-default-8   1/1     Running   0          8m

kubectl -n APIGEE_NAMESPACE exec -it apigee-cassandra-default-0 nodetool status
Datacenter: dc-us-east1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.16.2.6    690.17 KiB  256          48.8%             b02089d1-0521-42e1-bbed-900656a58b68  ra-1
UN  10.16.4.6    705.55 KiB  256          51.6%             dc6b7faf-6866-4044-9ac9-1269ebd85dab  ra-1 to
UN  10.16.11.11  674.36 KiB  256          48.3%             c7906366-6c98-4ff6-a4fd-17c596c33cf7  ra-1
UN  10.16.1.11   697.03 KiB  256          49.8%             ddf221aa-80aa-497d-b73f-67e576ff1a23  ra-1
UN  10.16.5.13   703.64 KiB  256          50.9%             2f01ac42-4b6a-4f9e-a4eb-4734c24def95  ra-1
UN  10.16.8.15   700.42 KiB  256          50.6%             a27f93af-f8a0-4c88-839f-2d653596efc2  ra-1
UN  10.16.11.3   697.03 KiB  256          49.8%             dad221ff-dad1-de33-2cd3-f1.672367e6f  ra-1
UN  10.16.14.16  704.04 KiB  256          50.9%             1feed042-a4b6-24ab-49a1-24d4cef95473  ra-1
UN  10.16.16.1   699.82 KiB  256          50.6%             beef93af-fee0-8e9d-8bbf-efc22d653596  ra-1


CUIDADO: se o cluster não estiver saudável ou pelo menos um nó
não estiver ativo, não prossiga com este processo.

Determine se o cluster do Cassandra tem armazenamento suficiente para suportar a redução do escalonamento vertical. Depois da redução do escalonamento vertical, os nós do Cassandra não podem ter mais de 75% do armazenamento disponível.
Por exemplo, se o cluster tiver seis nós do Cassandra e todos eles estiverem com o armazenamento, aproximadamente, 50% cheio, a redução do escalonamento vertical para três nós deixaria todos os três em 100%, o que não deixaria espaço para operação contínua.

No entanto, se você tiver nove nós do Cassandra, todos com o armazenamento aproximadamente 50% cheio, reduzir o escalonamento vertical para 6 nós deixaria cada nó restante aproximadamente 75% cheio. Portanto, é possível reduzir o escalonamento vertical.

Observação: é recomendado manter os nós do Cassandra em múltiplos de três.
Atualize ou adicione a propriedade cassandra.replicaCount ao arquivo overrides.yaml. Por exemplo, se a contagem atual de nós for 9, altere-a para 6:
```
cassandra:
  replicaCount: 6 # 
```

Aplique a alteração de configuração ao seu cluster:

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

Verifique se todos os nós restantes do Cassandra estão em execução:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

NAME                 READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          3h
apigee-cassandra-default-1   1/1     Running   0          3h
apigee-cassandra-default-2   1/1     Running   0          2h
apigee-cassandra-default-3   1/1     Running   0          25m
apigee-cassandra-default-4   1/1     Running   0          24m
apigee-cassandra-default-5   1/1     Running   0          23m

Verifique se o valor de cassandra.replicaCount é igual ao número de nós retornados pelo comando nodetool status.

Por exemplo, se você reduziu o escalonamento vertical do Cassandra para três nós:

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE -- nodetool -u JMX_USER -pw JMX_PASSWORD status

Datacenter: us-east1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load         Tokens       Owns (effective)  Host ID                               Rack
UN  10.16.2.6    1009.17 KiB  256          73.8%             b02089d1-0521-42e1-bbed-900656a58b68  ra-1
UN  10.16.4.6    1.65.55 KiB  256          75.6%             dc6b7faf-6866-4044-9ac9-1269ebd85dab  ra-1 to
UN  10.16.11.11  999.36 KiB   256          72.8%             c7906366-6c98-4ff6-a4fd-17c596c33cf7  ra-1
UN  10.16.1.11   1017.03 KiB  256          74.2%             ddf221aa-80aa-497d-b73f-67e576ff1a23  ra-1
UN  10.16.5.13   1061.64 KiB  256          75.9%             2f01ac42-4b6a-4f9e-a4eb-4734c24def95  ra-1
UN  10.16.8.15   1049.42 KiB  256          74.9%             a27f93af-f8a0-4c88-839f-2d653596efc2  ra-1

Depois que o cluster do Cassandra tiver o escalonamento vertical reduzido, verifique se os pvcs (PersistentVolumeClaim) correspondem aos nós restantes do Cassandra.

Veja os nomes dos pvcs:

kubectl get pvc -n APIGEE_NAMESPACE

NAME                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
cassandra-data-apigee-cassandra-default-0   Bound    pvc-f9c2a5b9-818c-11e9-8862-42010a8e014a   100Gi      RWO            apigee-gcepd   7h
cassandra-data-apigee-cassandra-default-1   Bound    pvc-2956cb78-818d-11e9-8862-42010a8e014a   100Gi      RWO            apigee-gcepd   7h
cassandra-data-apigee-cassandra-default-2   Bound    pvc-79de5407-8190-11e9-8862-42010a8e014a   100Gi      RWO            apigee-gcepd   7h
cassandra-data-apigee-cassandra-default-3   Bound    pvc-d29ba265-81a2-11e9-8862-42010a8e014a   100Gi      RWO            apigee-gcepd   5h
cassandra-data-apigee-cassandra-default-4   Bound    pvc-0675a0ff-81a3-11e9-8862-42010a8e014a   100Gi      RWO            apigee-gcepd   5h
cassandra-data-apigee-cassandra-default-5   Bound    pvc-354afa95-81a3-11e9-8862-42010a8e014a   100Gi      RWO            apigee-gcepd   5h

Neste exemplo, você não verá pvcs correspondentes aos três nós que tiveram o escalonamento vertical reduzido:

cassandra-data-apigee-cassandra-8
cassandra-data-apigee-cassandra-7
cassandra-data-apigee-cassandra-6