Este tópico aborda como aumentar a escala do Cassandra horizontal e verticalmente, e como diminuir a escala do Cassandra.
Escalar o Cassandra horizontalmente
Para aumentar a escala do Cassandra horizontalmente
- Certifique-se de que o seu conjunto de nós
apigee-datatem capacidade adicional, conforme necessário, antes de dimensionar o Cassandra. Consulte também o artigo Configurar pools de nós dedicados. - Defina o valor da propriedade de configuração
cassandra.replicaCountno ficheiro de substituições. O valor dereplicaCounttem de ser um múltiplo de3. Para determinar o valorreplicaCountpretendido, 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
replicaCountdiferentes em regiões diferentes. - Pode expandir o
replicaCountno futuro no ficheiro de substituições.
Para obter informações acerca desta propriedade, consulte a referência da propriedade de configuração. Consulte também o artigo Faça a gestão dos componentes do plano de tempo de execução.
- Aplique as alterações. Por exemplo:
helm upgrade datastore apigee-datastore/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE.yaml
Dimensionar o Cassandra verticalmente
Esta secção explica como dimensionar verticalmente os pods do Cassandra para acomodar requisitos de CPU e memória mais elevados.
Vista geral
Para uma implementação de produção híbrida do Apigee, recomendamos que crie, pelo menos, dois conjuntos 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 os requisitos do cluster de produção do GKE.
Para o conjunto de nós do Cassandra com estado, recomendamos que comece com 8 núcleos de CPU e 30 GB de memória. Após o aprovisionamento do conjunto de nós, não é possível alterar estas definições. Consulte também o artigo Configure o Cassandra para produção.
Se precisar de aumentar a escala dos pods do Cassandra para satisfazer requisitos de CPU e memória mais elevados, siga os passos descritos neste tópico.
Aumentar a escala dos pods do Cassandra
Siga estes passos para aumentar a CPU e a memória do conjunto de nós com estado usado para o Cassandra:
- Siga as instruções da sua plataforma Kubernetes para adicionar um novo conjunto de nós ao cluster. As plataformas compatíveis estão listadas nas instruções de instalação.
- Verifique se o novo conjunto 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 resultado:
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 o ficheiro de substituições para usar o novo conjunto de nós para o Cassandra e
atualize os recursos do pod para a quantidade de CPUs e o tamanho da memória aumentados que
quer usar. Por exemplo, para um cluster do GKE, use uma configuração semelhante à seguinte.
Se estiver noutra plataforma Kubernetes, tem de ajustar o valor
apigeeData.keyem conformidade: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
Por exemplo:
nodeSelector: requiredForScheduling: true apigeeData: key: "cloud.google.com/gke-nodepool" value: "apigee-data-new" cassandra: resources: requests: cpu: 14 memory: 16Gi
- Aplique o ficheiro de substituições ao cluster:
helm upgrade datastore apigee-datastore/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE.yaml
Quando concluir estes passos, os pods do Cassandra começam a ser implementados no novo conjunto de nós.
Reduzir a escala do Cassandra
O Apigee Hybrid usa um anel de nós do Cassandra como um StatefulSet. O Cassandra oferece armazenamento persistente para determinadas entidades do Apigee no plano de tempo de execução. Para mais informações sobre o Cassandra, consulte o artigo Acerca do plano de tempo de execução.
O Cassandra é um serviço com utilização intensiva de recursos e não deve ser implementado num pod com outros serviços híbridos. Consoante a carga, é recomendável reduzir o número de nós do Cassandra no anel no seu cluster.
O processo geral para reduzir um anel do Cassandra é o seguinte:
- Certifique-se de que o cluster do Cassandra está em bom estado e tem armazenamento suficiente para suportar a redução da escala.
- Atualize a propriedade
cassandra.replicaCountemoverrides.yaml. - Aplique a atualização da configuração.
- Elimine a reivindicação de volume persistente ou o volume, consoante a configuração do cluster.
O que precisa de saber
- Se qualquer nó que não seja um dos nós a desativar estiver em mau estado, não avance. O Kubernetes não vai conseguir reduzir a escala dos pods do cluster.
- Reduza ou aumente sempre por um fator de três nós.
Reduza a escala do Cassandra
- Valide se o cluster está em bom estado e se todos os nós estão em funcionamento, conforme mostra o exemplo seguinte:
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
- Determine se o cluster do Cassandra tem armazenamento suficiente para suportar a redução da escala. Após a redução, os nós do Cassandra não devem ter mais de 75% do respetivo armazenamento cheio.
Por exemplo, se o seu cluster tiver 6 nós do Cassandra e todos estiverem aproximadamente 50% cheios, a redução para três nós deixaria os três a 100%, o que não deixaria espaço para a operação contínua.
No entanto, se tiver 9 nós do Cassandra, todos com cerca de 50% de capacidade, a redução para 6 nós deixaria cada nó restante com cerca de 75% de capacidade. Pode reduzir a escala.
- Atualize ou adicione a propriedade
cassandra.replicaCountno ficheirooverrides.yaml. Por exemplo, se o número atual de nós for 9, altere-o para 6:cassandra: replicaCount: 6 #
- Aplique a alteração de configuração ao cluster:
helm upgrade datastore apigee-datastore/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE.yaml
- Certifique-se de que todos os nós do Cassandra restantes 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 devolvidos pelo comandonodetool status.Por exemplo, se reduzir a escala do Cassandra para seis 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 de reduzir a escala do cluster do Cassandra, verifique se os PVCs (PersistentVolumeClaim)
correspondem aos nós restantes do Cassandra.
Obtenha 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, não deve ver PVCs correspondentes aos três nós reduzidos:
cassandra-data-apigee-cassandra-8cassandra-data-apigee-cassandra-7cassandra-data-apigee-cassandra-6