Como escalonar o Cassandra

Version 1.13 (latest)

Versões com suporte:

• v1.12 (mais recente)
• v1.11
• v1.10
• Lista de versões com suporte

Versões sem suporte:

• v1.9
• v1.8
• v1.7
• v1.6
• v1.5
• v1.4
• v1.3
• v1.2
• v1.1

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

1. 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.
2. 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.
3. Aplique as alterações. Exemplo:

   helm upgrade datastore apigee-datastore/ \
     --namespace apigee \
     --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:

1. 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.
2. 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
   

3. 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
   

4. Aplique o arquivo de modificações ao cluster:

   helm upgrade datastore apigee-datastore/ \
     --namespace apigee \
     --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

ATENÇÃO: reduzir o escalonamento vertical dos clusters do Cassandra é mais invasivo do que escalonar verticalmente. Tenha cautela ao fazer isso

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 é:

1. Verifique se o cluster do Cassandra está íntegro e tem armazenamento suficiente para suportar a redução do escalonamento vertical.
2. Atualize a propriedade cassandra.replicaCount em overrides.yaml.
3. Aplique a atualização de configuração.
4. 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

1. 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 yourNamespace -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 yourNamespace exec -it apigee-cassandra-default-0 nodetool 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    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 íntegro ou pelo menos um nó não estiver funcionando, não continue com esse processo.
2. 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.
3. 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 # 

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

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

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

   kubectl get pods -n yourNamespace -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
   
   

6. 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  -- 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
   
   

7. 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 yourNamespace
   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