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 dereplicaCount
precisa ser um múltiplo de3
. Para determinar o valorreplicaCount
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.
- Aplique as alterações. Por exemplo:
helm upgrade datastore apigee-datastore/ \ --namespace apigee \ --atomic \ -f OVERRIDES_FILE.yaml
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 \ --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
emoverrides.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 mostra:
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
- 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.
- Atualize ou adicione a propriedade
cassandra.replicaCount
ao arquivooverrides.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 \ --atomic \ -f OVERRIDES_FILE.yaml
- 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
- Verifique se o valor de
cassandra.replicaCount
é igual ao número de nós retornados pelo comandonodetool 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
- 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