Neste tópico, descrevemos uma implantação multirregional para Apigee híbrida no GKE, o Anthos GKE implantado no local, Microsoft® Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) e no RedHat OpenShift. Selecione sua plataforma nos pré-requisitos e procedimentos.
As topologias para implantação de várias regiões incluem:
- Ativo-Ativo: quando você tem aplicativos implantados em vários locais geográficos e requer uma resposta de baixa latência da API para suas implantações. Você tem a opção de implantar a Apigee híbrida em várias localizações geográficas mais próximas de seus clientes. Por exemplo: Costa Oeste dos EUA, Costa Leste dos EUA, Europa, APAC.
- Ativo-Passivo: quando você tem uma região principal e uma região de recuperação de desastres ou failover.
As regiões em uma implantação híbrida multirregional se comunicam por meio do Cassandra, como mostrado na imagem a seguir:
Pré-requisitos
Antes de configurar a implantação híbrida para várias regiões, é preciso atender aos seguintes pré-requisitos:
GKE
- Ao instalar implantações multirregionais da Apigee entre diferentes redes, por exemplo, provedores de nuvem, redes VPC diferentes, na nuvem e no local etc., é preciso fornecer conectividade interna entre essas redes separadas que o Cassandra pode usar para a comunicação entre nós. Isso pode ser feito com VPNs ou soluções de conectividade específicas da nuvem.
- Se você estiver usando a Identidade da carga de trabalho em um cluster para autenticar contas de serviço, , recomendamos o uso dela para cada cluster em que você expandir. Consulte Como ativar a Identidade da carga de trabalho no GKE ou Como ativar a federação de identidade da carga de trabalho no AKS e EKS.
- Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR.
- Verifique se o cert-manager está instalado em cada cluster.
- Configurar a comunicação entre regiões
- Verifique se todos os pods do Cassandra conseguem resolver seus próprios nomes de host. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do pod do Cassandra. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do host do nó do Kubernetes executando o pod do Cassandra.
- Requisitos da multirregião Cassandra:
- Verifique se o namespace da rede do pod tem conectividade entre as regiões, incluindo firewalls, vpn, peering vpc e vNet. Esse é o caso da maioria das instalações do GKE.
- Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters
estão sendo executados no "modo de rede ilha"), ative o recurso
hostNetwork
do Kubernetes definindocassandra.hostNetwork: true
no arquivo de substituições para todas as regiões na instalação multirregional híbrida da Apigee.Para mais informações sobre a necessidade de
hostNetwork
, consulte Clusters no modo de ilha e hostNetwork abaixo. - Ative
hostNetwork
nos clusters atuais antes de expandir a configuração multirregional para novas regiões. - Quando
hostNetwork
estiver ativado, verifique se os nós de trabalho podem realizar buscas DNS de nomes do host. O Cassandra da Apigee usa a busca DNS direta para obter o IP do host durante a inicialização. - Abra a porta TCP 7001 entre os clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho em regiões e data centers se comuniquem. Consulte Configurar portas para informações sobre os números de portas do Cassandra.
Para informações detalhadas, consulte a documentação do Kubernetes.
GKE On-Prem
- Ao instalar implantações multirregionais da Apigee entre diferentes redes, por exemplo, provedores de nuvem, redes VPC diferentes, na nuvem e no local etc., é preciso fornecer conectividade interna entre essas redes separadas que o Cassandra pode usar para a comunicação entre nós. Isso pode ser feito com VPNs ou soluções de conectividade específicas da nuvem.
- Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR.
- Verifique se o cert-manager está instalado em cada cluster.
- Configurar a comunicação entre regiões
- Verifique se todos os pods do Cassandra conseguem resolver seus próprios nomes de host. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do pod do Cassandra. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do host do nó do Kubernetes executando o pod do Cassandra.
- Requisitos da multirregião Cassandra:
- Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters
estão sendo executados no "modo de rede ilha", o caso padrão nas instalações do GKE On-Prem), ative
o recurso
hostNetwork
do Kubernetes definindocassandra.hostNetwork: true
no arquivo de substituições para todas as regiões na instalação multirregional híbrida da Apigee.Para mais informações sobre a necessidade de
hostNetwork
, consulte Clusters no modo de ilha e hostNetwork abaixo. - Ative
hostNetwork
nos clusters atuais antes de expandir a configuração multirregional para novas regiões. - Quando
hostNetwork
estiver ativado, verifique se os nós de trabalho conseguem realizar buscas DNS de nomes do host. O Cassandra da Apigee usa a busca DNS direta para obter o IP do host durante a inicialização. - Abra as portas do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho de todas as regiões e data centers se comuniquem. Consulte os números de porta do Cassandra em Configurar portas.
- Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters
estão sendo executados no "modo de rede ilha", o caso padrão nas instalações do GKE On-Prem), ative
o recurso
Para informações detalhadas, consulte a documentação do Kubernetes.
AKS
- Ao instalar implantações multirregionais da Apigee entre diferentes redes, por exemplo, provedores de nuvem, redes VPC diferentes, na nuvem e no local etc., é preciso fornecer conectividade interna entre essas redes separadas que o Cassandra pode usar para a comunicação entre nós. Isso pode ser feito com VPNs ou soluções de conectividade específicas da nuvem.
- Siga o guia de instalação híbrida para pré-requisitos como o Google Cloud e a configuração organizacional antes de passar para as etapas de configuração do cluster.
- Verifique se o cert-manager está instalado em cada cluster.
- Verifique se todos os pods do Cassandra conseguem resolver seus próprios nomes de host. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do pod do Cassandra. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do host do nó do Kubernetes que executa o pod do Cassandra.
- Requisitos da multirregião Cassandra:
- Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters
estão sendo executados no "modo de rede ilha", o caso padrão em instalações AKS), ative
o recurso
hostNetwork
do Kubernetes definindocassandra.hostNetwork: true
no arquivo de substituições para todas as regiões na instalação multirregional híbrida da Apigee.Para mais informações sobre a necessidade de
hostNetwork
, consulte Clusters no modo de ilha e hostNetwork abaixo. - Ative
hostNetwork
nos clusters atuais antes de expandir a configuração multirregional para novas regiões. - Quando
hostNetwork
estiver ativado, verifique se os nós de trabalho podem realizar buscas DNS de nomes do host. O Cassandra da Apigee usa a busca DNS direta para obter o IP do host durante a inicialização. - Abra as portas do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho de todas as regiões e data centers se comuniquem. Consulte os números de porta do Cassandra em Configurar portas.
- Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters
estão sendo executados no "modo de rede ilha", o caso padrão em instalações AKS), ative
o recurso
Para informações detalhadas, consulte a documentação do Kubernetes.
EKS
- Ao instalar implantações multirregionais da Apigee entre diferentes redes, por exemplo, provedores de nuvem, redes VPC diferentes, na nuvem e no local etc., é preciso fornecer conectividade interna entre essas redes separadas que o Cassandra pode usar para a comunicação entre nós. Isso pode ser feito com VPNs ou soluções de conectividade específicas da nuvem.
- Siga o guia de instalação híbrida para pré-requisitos como o Google Cloud e a configuração organizacional antes de passar para as etapas de configuração do cluster.
- Verifique se o cert-manager está instalado em cada cluster.
- Verifique se todos os pods do Cassandra conseguem resolver seus próprios nomes de host. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do pod do Cassandra. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do host do nó do Kubernetes que executa o pod do Cassandra.
- Requisitos da multirregião Cassandra:
- Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters
estão sendo executados no "modo de rede ilha"), ative o recurso
hostNetwork
do Kubernetes definindocassandra.hostNetwork: true
no arquivo de substituições para todas as regiões na instalação multirregional híbrida da Apigee. O Amazon EKS usa o modelo de rede totalmente integrado por padrão.Para mais informações sobre a necessidade de
hostNetwork
, consulte Clusters no modo de ilha e hostNetwork abaixo. - Ative
hostNetwork
nos clusters atuais antes de expandir a configuração multirregional para novas regiões. - Quando
hostNetwork
estiver ativado, verifique se os nós de trabalho podem realizar buscas DNS de nomes do host. O Cassandra da Apigee usa a busca DNS direta para obter o IP do host durante a inicialização. - Abra as portas do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho de todas as regiões e data centers se comuniquem. Consulte os números de porta do Cassandra em Configurar portas.
- Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters
estão sendo executados no "modo de rede ilha"), ative o recurso
Para informações detalhadas, consulte a documentação do Kubernetes.
OpenShift
- Ao instalar implantações multirregionais da Apigee entre diferentes redes, por exemplo, provedores de nuvem, redes VPC diferentes, na nuvem e no local etc., é preciso fornecer conectividade interna entre essas redes separadas que o Cassandra pode usar para a comunicação entre nós. Isso pode ser feito com VPNs ou soluções de conectividade específicas da nuvem.
- Siga o guia de instalação híbrida para pré-requisitos como o Google Cloud e a configuração organizacional antes de passar para as etapas de configuração do cluster.
- Verifique se o cert-manager está instalado em cada cluster.
- Verifique se todos os pods do Cassandra conseguem resolver seus próprios nomes de host. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do pod do Cassandra. Se hostNetwork estiver definido como hostNetwork, o nome do host será o nome do host do nó do Kubernetes que executa o pod do Cassandra.
- Requisitos da multirregião Cassandra:
- Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters
estão sendo executados no "modo de rede de ilha", o caso padrão nas instalações do OpenShift), ative
o recurso
hostNetwork
do Kubernetes definindocassandra.hostNetwork: true
no arquivo de substituições para todas as regiões na instalação multirregional híbrida da Apigee.Para mais informações sobre a necessidade de
hostNetwork
, consulte Clusters no modo de ilha e hostNetwork abaixo. - Ative
hostNetwork
nos clusters atuais antes de expandir a configuração multirregional para novas regiões. - Quando
hostNetwork
estiver ativado, verifique se os nós de trabalho podem realizar buscas DNS de nomes do host. O Cassandra da Apigee usa a busca DNS direta para obter o IP do host durante a inicialização. - Abra as portas do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho de todas as regiões e data centers se comuniquem. Consulte os números de porta do Cassandra em Configurar portas.
- Se o namespace da rede do pod não tiver conectividade entre clusters (os clusters
estão sendo executados no "modo de rede de ilha", o caso padrão nas instalações do OpenShift), ative
o recurso
Para informações detalhadas, consulte a documentação do Kubernetes.
Clusters no modo de ilha e hostNetwork
Há dois modelos de rede principais para clusters do Kubernetes: totalmente integrado (ou simples) e no modo de ilha. A Apigee recomenda o uso do modelo de rede simples sempre que possível, porque ele simplifica a conectividade multirregional do Cassandra. Quando um cluster do Kubernetes é configurado no modo de ilha, a rede do pod fica isolada. Os pods não conseguem se comunicar diretamente com outros em execução em outros clusters usando o endereço IP deles. Consulte Implementações típicas de modelos de rede para mais informações sobre as diferenças entre esses dois modelos de rede e exemplos de cada um.
Quando a Apigee híbrida está em execução em dois ou mais clusters do Kubernetes usando um modelo de rede
de modo de ilha, é necessário ativar a configuração hostNetwork
para o Cassandra por meio da propriedade
cassandra.hostNetwork. Por padrão, os pods do Kubernetes são isolados em namespaces de rede individuais,
o que os impede de usar o IP do nó de trabalho do Kubernetes. Quando hostNetwork
é definido como
true
, o pod não é isolado no próprio namespace de rede. Em vez disso, ele usa
o endereço IP e o nome de host do nó de trabalho do Kubernetes em que ele está programado. Isso permite
que o Cassandra use nativamente o IP do nó de trabalho do Kubernetes como o próprio IP, o que fornece a ele um meio para
estabelecer uma malha completa entre todos os pods dele que estão em vários clusters em execução no
modo de ilha.
Resolução do nome de host do Cassandra
Um pod do Cassandra não resolve outros pods do Cassandra por nome de host. No entanto, durante a inicialização, o Cassandra
verifica se o próprio nome de host pode ser resolvido por DNS. Como o nome de host do pod é igual ao
nome de host do nó de trabalho do Kubernetes quando hostNetwork
é definido como verdadeiro, o nome de host do
nó de trabalho precisa ser resolvido para um endereço IP por meio do serviço DNS do cluster. Se o nome de host do nó de trabalho
do Kubernetes não puder ser resolvido, o pod do Cassandra não será totalmente iniciado. Portanto,
é importante que os nomes de host dos nós de trabalho do Kubernetes possam ser resolvidos por meio de pods no cluster
ao definir hostNetwork
como true
.
Configurar o híbrido da Apigee para multirregião
Nesta seção, descrevemos como configurar a Apigee híbrida para várias regiões.
GKE
Configurar o host de propagação multirregional
Esta seção descreve como expandir o cluster existente do Cassandra para uma nova região. Essa configuração permite que a nova região inicialize o cluster e participe do data center atual. Sem essa configuração, os clusters multirregionais do Kubernetes não sabem da existência uns dos outros.
-
Para a primeira região criada, acesse os pods no namespace da Apigee:
kubectl get pods -o wide -n APIGEE_NAMESPACE
- Identifique o endereço do host de semente multirregional para Cassandra nesta região, por exemplo,
10.0.0.11
. -
Prepare o arquivo
overrides.yaml
para a segunda região e adicione o endereço IP do host de semente da seguinte maneira:cassandra: multiRegionSeedHost: "SEED_HOST_IP_ADDRESS" datacenter: "DATACENTER_NAME" rack: "RACK_NAME" hostNetwork: false clusterName: CLUSTER_NAME
Substitua:
- SEED_HOST_IP_ADDRESS pelo endereço IP do host de semente, por exemplo,
10.0.0.11
. - DATACENTER_NAME pelo nome do data center. Por exemplo,
dc-2
. - RACK_NAME pelo nome do rack, por exemplo,
ra-1
. - CLUSTER_NAME pelo nome do cluster da Cassandra. Por padrão, o valor é
apigeecluster
. Se você usar um nome de cluster diferente, será preciso especificar um valor para cassandra.clusterName. É possível escolher o próprio valor, mas ele precisa ser o mesmo em todas as regiões.
- SEED_HOST_IP_ADDRESS pelo endereço IP do host de semente, por exemplo,
Configurar a segunda região
Para configurar a nova região:
-
Instale o cert-manager na segunda região.
- Copie o certificado do cluster atual para o novo cluster.
A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS.
Portanto, é essencial ter certificados consistentes em todo o cluster.
-
Defina o contexto como o namespace original:
kubectl config use-context ORIGINAL_CLUSTER_NAME
-
Exporte a configuração atual do namespace para um arquivo:
kubectl get namespace APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml
-
Exporte o secret
apigee-ca
para um arquivo:kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
-
Defina o contexto para o nome do cluster da nova região
kubectl config use-context NEW_CLUSTER_NAME
-
Importe a configuração do namespace para o novo cluster. Atualize o namespace no arquivo se estiver usando um namespace diferente na nova região:
kubectl apply -f apigee-namespace.yaml
-
Importe o secret para o novo cluster:
kubectl -n cert-manager apply -f apigee-ca.yaml
-
-
Siga as etapas para instalar os CRDs da Apigee híbrida na nova região.
-
Agora use gráficos do Helm para instalar a Apigee híbrida na nova região com os seguintes comandos do gráfico do Helm (como feito na região 1):
helm upgrade operator apigee-operator \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade datastore apigee-datastore \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade telemetry apigee-telemetry \ --install \ --namespace APIGEE_NAMESPACE> \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade redis apigee-redis \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade ingress-manager apigee-ingress-manager \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade ORG_NAME apigee-org \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env mentioned on the overrideshelm upgrade ENV_NAME apigee-env/ \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ --set env=ENV_NAME \ -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env group mentioned on the overrideshelm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ --set envgroup=ENV_GROUP_NAME \ -f overrides-DATACENTER_NAME.yaml
- Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos.
kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE \ -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
Exemplo de configuração concluída:
Datacenter: dc-1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.132.87.93 68.07 GiB 256 ? fb51465c-167a-42f7-98c9-b6eba1de34de c UN 10.132.84.94 69.9 GiB 256 ? f621a5ac-e7ee-48a9-9a14-73d69477c642 b UN 10.132.84.105 76.95 GiB 256 ? 0561086f-e95b-4232-ba6c-ad519ff30336 d Datacenter: dc-2 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.132.0.8 71.61 GiB 256 ? 8894a98b-8406-45de-99e2-f404ab10b5d6 c UN 10.132.9.204 75.1 GiB 256 ? afa0ffa3-630b-4f1e-b46f-fc3df988092e a UN 10.132.3.133 68.08 GiB 256 ? 25ae39ab-b39e-4d4f-9cb7-de095ab873db b
- Configurar o Cassandra em todos os pods nos novos data centers.
- Receba
apigeeorg
do cluster com o seguinte comando:kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
Exemplo:
Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" "rg-hybrid-b7d3b9c"
- Crie um arquivo de recurso personalizado de replicação de dados do Cassandra (
YAML
). O arquivo pode ter qualquer nome. Nos exemplos a seguir, o arquivo terá o nomedatareplication.yaml
.O arquivo deve conter o seguinte:
apiVersion: apigee.cloud.google.com/v1alpha1 kind: CassandraDataReplication metadata: name: REGION_EXPANSION namespace: NAMESPACE spec: organizationRef: APIGEEORG_VALUE force: false source: region: SOURCE_REGION
Em que:
- REGION_EXPANSION é o nome que você está fornecendo aos metadados. Use qualquer nome.
- NAMESPACE é o mesmo namespace fornecido em
overrides.yaml
. Geralmente é "apigee
". - APIGEEORG_VALUE é a saída de valor do comando
kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
na etapa anterior. Por exemplo,rg-hybrid-b7d3b9c
- SOURCE_REGION é a região de origem, o valor do data center na seção Cassandra das modificações da região de origem.yaml
Exemplo:
apiVersion: apigee.cloud.google.com/v1alpha1 kind: CassandraDataReplication metadata: name: region-expansion namespace: apigee spec: organizationRef: rg-hybrid-b7d3b9c force: false source: region: "dc-1"
- Aplique o
CassandraDataReplication
com o seguinte comando:kubectl apply -f datareplication.yaml
- Receba
- Verifique o status de recriação usando o comando a seguir.
kubectl -n APIGEE_NAMESPACE get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
Os resultados terão esta aparência:
{ "rebuildDetails": { "apigee-cassandra-default-0": { "state": "complete", "updated": 1623105760 }, "apigee-cassandra-default-1": { "state": "complete", "updated": 1623105765 }, "apigee-cassandra-default-2": { "state": "complete", "updated": 1623105770 } }, "state": "complete", "updated": 1623105770 }
- Depois que a replicação de dados for concluída e verificada, atualize os hosts de origem:
-
Remova
multiRegionSeedHost: 10.0.0.11
deoverrides-DATACENTER_NAME.yaml
-
Reaplique a alteração para atualizar a resposta automática do repositório de dados da Apigee:
helm upgrade datastore apigee-datastore/ \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
-
Remova
- Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o comando
nodetool status
. .kubectl logs apigee-cassandra-default-0 -f -n APIGEE_NAMESPACE
kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
O exemplo a seguir mostra entradas de registro de exemplo:
INFO 01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens) INFO 01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild INFO 01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB) INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22 INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB) INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22 INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB) INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed
Verificar o status do cluster do Cassandra
O comando a seguir é útil para conferir se a configuração do cluster foi bem-sucedida nos dois data centers. O comando verifica o status de nodetool das duas regiões.
kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status Datacenter: dc-1 ======================= Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.12.1.45 112.09 KiB 256 100.0% 3c98c816-3f4d-48f0-9717-03d0c998637f ra-1 UN 10.12.4.36 95.27 KiB 256 100.0% 0a36383d-1d9e-41e2-924c-7b62be12d6cc ra-1 UN 10.12.5.22 88.7 KiB 256 100.0% 3561f4fa-af3d-4ea4-93b2-79ac7e938201 ra-1 Datacenter: us-west1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.4.33 78.69 KiB 256 100.0% a200217d-260b-45cd-b83c-182b27ff4c99 ra-1 UN 10.0.0.21 78.68 KiB 256 100.0% 9f3364b9-a7a1-409c-9356-b7d1d312e52b ra-1 UN 10.0.1.26 15.46 KiB 256 100.0% 1666df0f-702e-4c5b-8b6e-086d0f2e47fa ra-1
GKE On-Prem
Configurar o host de propagação multirregional
Esta seção descreve como expandir o cluster existente do Cassandra para uma nova região. Essa configuração permite que a nova região inicialize o cluster e participe do data center atual. Sem essa configuração, os clusters multirregionais do Kubernetes não sabem da existência uns dos outros.
-
Para a primeira região criada, acesse os pods no namespace da Apigee:
kubectl get pods -o wide -n APIGEE_NAMESPACE
- Identifique o endereço do host de semente multirregional para Cassandra nesta região, por exemplo,
10.0.0.11
. -
Prepare o arquivo
overrides.yaml
para a segunda região e adicione o endereço IP do host de semente da seguinte maneira:cassandra: multiRegionSeedHost: "SEED_HOST_IP_ADDRESS" datacenter: "DATACENTER_NAME" rack: "RACK_NAME" hostNetwork: false clusterName: CLUSTER_NAME
Substitua:
- SEED_HOST_IP_ADDRESS pelo endereço IP do host de semente, por exemplo,
10.0.0.11
. - DATACENTER_NAME pelo nome do data center. Por exemplo,
dc-2
. - RACK_NAME pelo nome do rack, por exemplo,
ra-1
. - CLUSTER_NAME pelo nome do cluster da Cassandra. Por padrão, o valor é
apigeecluster
. Se você usar um nome de cluster diferente, será preciso especificar um valor para cassandra.clusterName. É possível escolher o próprio valor, mas ele precisa ser o mesmo em todas as regiões.
- SEED_HOST_IP_ADDRESS pelo endereço IP do host de semente, por exemplo,
Configurar a segunda região
Para configurar a nova região:
-
Instale o cert-manager na segunda região.
- Copie o certificado do cluster atual para o novo cluster.
A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS.
Portanto, é essencial ter certificados consistentes em todo o cluster.
-
Defina o contexto como o namespace original:
kubectl config use-context ORIGINAL_CLUSTER_NAME
-
Exporte a configuração atual do namespace para um arquivo:
kubectl get namespace APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml
-
Exporte o secret
apigee-ca
para um arquivo:kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
-
Defina o contexto para o nome do cluster da nova região
kubectl config use-context NEW_CLUSTER_NAME
-
Importe a configuração do namespace para o novo cluster. Atualize o namespace no arquivo se estiver usando um namespace diferente na nova região:
kubectl apply -f apigee-namespace.yaml
-
Importe o secret para o novo cluster:
kubectl -n cert-manager apply -f apigee-ca.yaml
-
-
Siga as etapas para instalar os CRDs da Apigee híbrida na nova região.
-
Agora use gráficos do Helm para instalar a Apigee híbrida na nova região com os seguintes comandos do gráfico do Helm (como feito na região 1):
helm upgrade operator apigee-operator \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade datastore apigee-datastore \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade telemetry apigee-telemetry \ --install \ --namespace APIGEE_NAMESPACE> \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade redis apigee-redis \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade ingress-manager apigee-ingress-manager \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade ORG_NAME apigee-org \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env mentioned on the overrideshelm upgrade ENV_NAME apigee-env/ \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ --set env=ENV_NAME \ -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env group mentioned on the overrideshelm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ --set envgroup=ENV_GROUP_NAME \ -f overrides-DATACENTER_NAME.yaml
- Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos.
kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE \ -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
Exemplo de configuração concluída:
Datacenter: dc-1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.132.87.93 68.07 GiB 256 ? fb51465c-167a-42f7-98c9-b6eba1de34de c UN 10.132.84.94 69.9 GiB 256 ? f621a5ac-e7ee-48a9-9a14-73d69477c642 b UN 10.132.84.105 76.95 GiB 256 ? 0561086f-e95b-4232-ba6c-ad519ff30336 d Datacenter: dc-2 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.132.0.8 71.61 GiB 256 ? 8894a98b-8406-45de-99e2-f404ab10b5d6 c UN 10.132.9.204 75.1 GiB 256 ? afa0ffa3-630b-4f1e-b46f-fc3df988092e a UN 10.132.3.133 68.08 GiB 256 ? 25ae39ab-b39e-4d4f-9cb7-de095ab873db b
- Configurar o Cassandra em todos os pods nos novos data centers.
- Receba
apigeeorg
do cluster com o seguinte comando:kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
Exemplo:
Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" "rg-hybrid-b7d3b9c"
- Crie um arquivo de recurso personalizado de replicação de dados do Cassandra (
YAML
). O arquivo pode ter qualquer nome. Nos exemplos a seguir, o arquivo terá o nomedatareplication.yaml
.O arquivo deve conter o seguinte:
apiVersion: apigee.cloud.google.com/v1alpha1 kind: CassandraDataReplication metadata: name: REGION_EXPANSION namespace: NAMESPACE spec: organizationRef: APIGEEORG_VALUE force: false source: region: SOURCE_REGION
Em que:
- REGION_EXPANSION é o nome que você está fornecendo aos metadados. Use qualquer nome.
- NAMESPACE é o mesmo namespace fornecido em
overrides.yaml
. Geralmente é "apigee
". - APIGEEORG_VALUE é a saída de valor do comando
kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
na etapa anterior. Por exemplo,rg-hybrid-b7d3b9c
- SOURCE_REGION é a região de origem, o valor do data center na seção Cassandra das modificações da região de origem.yaml
Exemplo:
apiVersion: apigee.cloud.google.com/v1alpha1 kind: CassandraDataReplication metadata: name: region-expansion namespace: apigee spec: organizationRef: rg-hybrid-b7d3b9c force: false source: region: "dc-1"
- Aplique o
CassandraDataReplication
com o seguinte comando:kubectl apply -f datareplication.yaml
- Receba
- Verifique o status de recriação usando o comando a seguir.
kubectl -n APIGEE_NAMESPACE get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
Os resultados terão esta aparência:
{ "rebuildDetails": { "apigee-cassandra-default-0": { "state": "complete", "updated": 1623105760 }, "apigee-cassandra-default-1": { "state": "complete", "updated": 1623105765 }, "apigee-cassandra-default-2": { "state": "complete", "updated": 1623105770 } }, "state": "complete", "updated": 1623105770 }
- Depois que a replicação de dados for concluída e verificada, atualize os hosts de origem:
-
Remova
multiRegionSeedHost: 10.0.0.11
deoverrides-DATACENTER_NAME.yaml
-
Reaplique a alteração para atualizar a resposta automática do repositório de dados da Apigee:
helm upgrade datastore apigee-datastore/ \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
-
Remova
- Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o comando
nodetool status
. .kubectl logs apigee-cassandra-default-0 -f -n APIGEE_NAMESPACE
kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
O exemplo a seguir mostra entradas de registro de exemplo:
INFO 01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens) INFO 01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild INFO 01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB) INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22 INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB) INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22 INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB) INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed
Verificar o status do cluster do Cassandra
O comando a seguir é útil para conferir se a configuração do cluster foi bem-sucedida nos dois data centers. O comando verifica o status de nodetool das duas regiões.
kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status Datacenter: dc-1 ======================= Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.12.1.45 112.09 KiB 256 100.0% 3c98c816-3f4d-48f0-9717-03d0c998637f ra-1 UN 10.12.4.36 95.27 KiB 256 100.0% 0a36383d-1d9e-41e2-924c-7b62be12d6cc ra-1 UN 10.12.5.22 88.7 KiB 256 100.0% 3561f4fa-af3d-4ea4-93b2-79ac7e938201 ra-1 Datacenter: us-west1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.4.33 78.69 KiB 256 100.0% a200217d-260b-45cd-b83c-182b27ff4c99 ra-1 UN 10.0.0.21 78.68 KiB 256 100.0% 9f3364b9-a7a1-409c-9356-b7d1d312e52b ra-1 UN 10.0.1.26 15.46 KiB 256 100.0% 1666df0f-702e-4c5b-8b6e-086d0f2e47fa ra-1
AKS
Criar uma rede virtual em cada região
Siga as recomendações do Azure para estabelecer a comunicação entre regiões aqui: VNet-to-VNet: como conectar redes virtuais no Azure em diferentes regiões.
Criar clusters multirregionais
Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR. Consulte também a Etapa 1: criar um cluster. Use os locais e os nomes das redes virtuais que você criou anteriormente.
Abra as portas do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho de todas as regiões e data centers se comuniquem. Consulte os números de porta do Cassandra em Configurar portas.
Configurar o host de propagação multirregional
Esta seção descreve como expandir o cluster existente do Cassandra para uma nova região. Essa configuração permite que a nova região inicialize o cluster e participe do data center atual. Sem essa configuração, os clusters multirregionais do Kubernetes não sabem da existência uns dos outros.
-
Para a primeira região criada, acesse os pods no namespace da Apigee:
kubectl get pods -o wide -n APIGEE_NAMESPACE
- Identifique o endereço do host de semente multirregional para Cassandra nesta região, por exemplo,
10.0.0.11
. -
Prepare o arquivo
overrides.yaml
para a segunda região e adicione o endereço IP do host de semente da seguinte maneira:cassandra: multiRegionSeedHost: "SEED_HOST_IP_ADDRESS" datacenter: "DATACENTER_NAME" rack: "RACK_NAME" hostNetwork: false clusterName: CLUSTER_NAME
Substitua:
- SEED_HOST_IP_ADDRESS pelo endereço IP do host de semente, por exemplo,
10.0.0.11
. - DATACENTER_NAME pelo nome do data center. Por exemplo,
dc-2
. - RACK_NAME pelo nome do rack, por exemplo,
ra-1
. - CLUSTER_NAME pelo nome do cluster da Cassandra. Por padrão, o valor é
apigeecluster
. Se você usar um nome de cluster diferente, será preciso especificar um valor para cassandra.clusterName. É possível escolher o próprio valor, mas ele precisa ser o mesmo em todas as regiões.
- SEED_HOST_IP_ADDRESS pelo endereço IP do host de semente, por exemplo,
Configurar a segunda região
Para configurar a nova região:
-
Instale o cert-manager na segunda região.
- Copie o certificado do cluster atual para o novo cluster.
A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS.
Portanto, é essencial ter certificados consistentes em todo o cluster.
-
Defina o contexto como o namespace original:
kubectl config use-context ORIGINAL_CLUSTER_NAME
-
Exporte a configuração atual do namespace para um arquivo:
kubectl get namespace APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml
-
Exporte o secret
apigee-ca
para um arquivo:kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
-
Defina o contexto para o nome do cluster da nova região
kubectl config use-context NEW_CLUSTER_NAME
-
Importe a configuração do namespace para o novo cluster. Atualize o namespace no arquivo se estiver usando um namespace diferente na nova região:
kubectl apply -f apigee-namespace.yaml
-
Importe o secret para o novo cluster:
kubectl -n cert-manager apply -f apigee-ca.yaml
-
-
Siga as etapas para instalar os CRDs da Apigee híbrida na nova região.
-
Agora use gráficos do Helm para instalar a Apigee híbrida na nova região com os seguintes comandos do gráfico do Helm (como feito na região 1):
helm upgrade operator apigee-operator \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade datastore apigee-datastore \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade telemetry apigee-telemetry \ --install \ --namespace APIGEE_NAMESPACE> \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade redis apigee-redis \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade ingress-manager apigee-ingress-manager \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade ORG_NAME apigee-org \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env mentioned on the overrideshelm upgrade ENV_NAME apigee-env/ \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ --set env=ENV_NAME \ -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env group mentioned on the overrideshelm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ --set envgroup=ENV_GROUP_NAME \ -f overrides-DATACENTER_NAME.yaml
- Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos.
kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE \ -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
Exemplo de configuração concluída:
Datacenter: dc-1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.132.87.93 68.07 GiB 256 ? fb51465c-167a-42f7-98c9-b6eba1de34de c UN 10.132.84.94 69.9 GiB 256 ? f621a5ac-e7ee-48a9-9a14-73d69477c642 b UN 10.132.84.105 76.95 GiB 256 ? 0561086f-e95b-4232-ba6c-ad519ff30336 d Datacenter: dc-2 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.132.0.8 71.61 GiB 256 ? 8894a98b-8406-45de-99e2-f404ab10b5d6 c UN 10.132.9.204 75.1 GiB 256 ? afa0ffa3-630b-4f1e-b46f-fc3df988092e a UN 10.132.3.133 68.08 GiB 256 ? 25ae39ab-b39e-4d4f-9cb7-de095ab873db b
- Configurar o Cassandra em todos os pods nos novos data centers.
- Receba
apigeeorg
do cluster com o seguinte comando:kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
Exemplo:
Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" "rg-hybrid-b7d3b9c"
- Crie um arquivo de recurso personalizado de replicação de dados do Cassandra (
YAML
). O arquivo pode ter qualquer nome. Nos exemplos a seguir, o arquivo terá o nomedatareplication.yaml
.O arquivo deve conter o seguinte:
apiVersion: apigee.cloud.google.com/v1alpha1 kind: CassandraDataReplication metadata: name: REGION_EXPANSION namespace: NAMESPACE spec: organizationRef: APIGEEORG_VALUE force: false source: region: SOURCE_REGION
Em que:
- REGION_EXPANSION é o nome que você está fornecendo aos metadados. Use qualquer nome.
- NAMESPACE é o mesmo namespace fornecido em
overrides.yaml
. Geralmente é "apigee
". - APIGEEORG_VALUE é a saída de valor do comando
kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
na etapa anterior. Por exemplo,rg-hybrid-b7d3b9c
- SOURCE_REGION é a região de origem, o valor do data center na seção Cassandra das modificações da região de origem.yaml
Exemplo:
apiVersion: apigee.cloud.google.com/v1alpha1 kind: CassandraDataReplication metadata: name: region-expansion namespace: apigee spec: organizationRef: rg-hybrid-b7d3b9c force: false source: region: "dc-1"
- Aplique o
CassandraDataReplication
com o seguinte comando:kubectl apply -f datareplication.yaml
- Receba
- Verifique o status de recriação usando o comando a seguir.
kubectl -n APIGEE_NAMESPACE get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
Os resultados terão esta aparência:
{ "rebuildDetails": { "apigee-cassandra-default-0": { "state": "complete", "updated": 1623105760 }, "apigee-cassandra-default-1": { "state": "complete", "updated": 1623105765 }, "apigee-cassandra-default-2": { "state": "complete", "updated": 1623105770 } }, "state": "complete", "updated": 1623105770 }
- Depois que a replicação de dados for concluída e verificada, atualize os hosts de origem:
-
Remova
multiRegionSeedHost: 10.0.0.11
deoverrides-DATACENTER_NAME.yaml
-
Reaplique a alteração para atualizar a resposta automática do repositório de dados da Apigee:
helm upgrade datastore apigee-datastore/ \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
-
Remova
- Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o comando
nodetool status
. .kubectl logs apigee-cassandra-default-0 -f -n APIGEE_NAMESPACE
kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
O exemplo a seguir mostra entradas de registro de exemplo:
INFO 01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens) INFO 01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild INFO 01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB) INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22 INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB) INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22 INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB) INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed
Verificar o status do cluster do Cassandra
O comando a seguir é útil para conferir se a configuração do cluster foi bem-sucedida nos dois data centers. O comando verifica o status de nodetool das duas regiões.
kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status Datacenter: dc-1 ======================= Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.12.1.45 112.09 KiB 256 100.0% 3c98c816-3f4d-48f0-9717-03d0c998637f ra-1 UN 10.12.4.36 95.27 KiB 256 100.0% 0a36383d-1d9e-41e2-924c-7b62be12d6cc ra-1 UN 10.12.5.22 88.7 KiB 256 100.0% 3561f4fa-af3d-4ea4-93b2-79ac7e938201 ra-1 Datacenter: us-west1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.4.33 78.69 KiB 256 100.0% a200217d-260b-45cd-b83c-182b27ff4c99 ra-1 UN 10.0.0.21 78.68 KiB 256 100.0% 9f3364b9-a7a1-409c-9356-b7d1d312e52b ra-1 UN 10.0.1.26 15.46 KiB 256 100.0% 1666df0f-702e-4c5b-8b6e-086d0f2e47fa ra-1
EKS
Criar uma rede virtual em cada região
Siga as recomendações da AWS para estabelecer comunicação entre regiões, conforme descrito em: O que é peering de VPC?. O termo da AWS para usar regiões diferentes é peering de VPC entre regiões.
Criar clusters multirregionais
Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR. Consulte também a Etapa 1: criar um cluster. Use os locais e os nomes das redes virtuais que você criou anteriormente.
Abra as portas do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho de todas as regiões e data centers se comuniquem. Consulte os números de porta do Cassandra em Configurar portas.
Configurar o host de propagação multirregional
Esta seção descreve como expandir o cluster existente do Cassandra para uma nova região. Essa configuração permite que a nova região inicialize o cluster e participe do data center atual. Sem essa configuração, os clusters multirregionais do Kubernetes não sabem da existência uns dos outros.
-
Para a primeira região criada, acesse os pods no namespace da Apigee:
kubectl get pods -o wide -n APIGEE_NAMESPACE
- Identifique o endereço do host de semente multirregional para Cassandra nesta região, por exemplo,
10.0.0.11
. -
Prepare o arquivo
overrides.yaml
para a segunda região e adicione o endereço IP do host de semente da seguinte maneira:cassandra: multiRegionSeedHost: "SEED_HOST_IP_ADDRESS" datacenter: "DATACENTER_NAME" rack: "RACK_NAME" hostNetwork: false clusterName: CLUSTER_NAME
Substitua:
- SEED_HOST_IP_ADDRESS pelo endereço IP do host de semente, por exemplo,
10.0.0.11
. - DATACENTER_NAME pelo nome do data center. Por exemplo,
dc-2
. - RACK_NAME pelo nome do rack, por exemplo,
ra-1
. - CLUSTER_NAME pelo nome do cluster da Cassandra. Por padrão, o valor é
apigeecluster
. Se você usar um nome de cluster diferente, será preciso especificar um valor para cassandra.clusterName. É possível escolher o próprio valor, mas ele precisa ser o mesmo em todas as regiões.
- SEED_HOST_IP_ADDRESS pelo endereço IP do host de semente, por exemplo,
Configurar a segunda região
Para configurar a nova região:
-
Instale o cert-manager na segunda região.
- Copie o certificado do cluster atual para o novo cluster.
A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS.
Portanto, é essencial ter certificados consistentes em todo o cluster.
-
Defina o contexto como o namespace original:
kubectl config use-context ORIGINAL_CLUSTER_NAME
-
Exporte a configuração atual do namespace para um arquivo:
kubectl get namespace APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml
-
Exporte o secret
apigee-ca
para um arquivo:kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
-
Defina o contexto para o nome do cluster da nova região
kubectl config use-context NEW_CLUSTER_NAME
-
Importe a configuração do namespace para o novo cluster. Atualize o namespace no arquivo se estiver usando um namespace diferente na nova região:
kubectl apply -f apigee-namespace.yaml
-
Importe o secret para o novo cluster:
kubectl -n cert-manager apply -f apigee-ca.yaml
-
-
Siga as etapas para instalar os CRDs da Apigee híbrida na nova região.
-
Agora use gráficos do Helm para instalar a Apigee híbrida na nova região com os seguintes comandos do gráfico do Helm (como feito na região 1):
helm upgrade operator apigee-operator \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade datastore apigee-datastore \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade telemetry apigee-telemetry \ --install \ --namespace APIGEE_NAMESPACE> \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade redis apigee-redis \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade ingress-manager apigee-ingress-manager \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade ORG_NAME apigee-org \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env mentioned on the overrideshelm upgrade ENV_NAME apigee-env/ \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ --set env=ENV_NAME \ -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env group mentioned on the overrideshelm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ --set envgroup=ENV_GROUP_NAME \ -f overrides-DATACENTER_NAME.yaml
- Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos.
kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE \ -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
Exemplo de configuração concluída:
Datacenter: dc-1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.132.87.93 68.07 GiB 256 ? fb51465c-167a-42f7-98c9-b6eba1de34de c UN 10.132.84.94 69.9 GiB 256 ? f621a5ac-e7ee-48a9-9a14-73d69477c642 b UN 10.132.84.105 76.95 GiB 256 ? 0561086f-e95b-4232-ba6c-ad519ff30336 d Datacenter: dc-2 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.132.0.8 71.61 GiB 256 ? 8894a98b-8406-45de-99e2-f404ab10b5d6 c UN 10.132.9.204 75.1 GiB 256 ? afa0ffa3-630b-4f1e-b46f-fc3df988092e a UN 10.132.3.133 68.08 GiB 256 ? 25ae39ab-b39e-4d4f-9cb7-de095ab873db b
- Configurar o Cassandra em todos os pods nos novos data centers.
- Receba
apigeeorg
do cluster com o seguinte comando:kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
Exemplo:
Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" "rg-hybrid-b7d3b9c"
- Crie um arquivo de recurso personalizado de replicação de dados do Cassandra (
YAML
). O arquivo pode ter qualquer nome. Nos exemplos a seguir, o arquivo terá o nomedatareplication.yaml
.O arquivo deve conter o seguinte:
apiVersion: apigee.cloud.google.com/v1alpha1 kind: CassandraDataReplication metadata: name: REGION_EXPANSION namespace: NAMESPACE spec: organizationRef: APIGEEORG_VALUE force: false source: region: SOURCE_REGION
Em que:
- REGION_EXPANSION é o nome que você está fornecendo aos metadados. Use qualquer nome.
- NAMESPACE é o mesmo namespace fornecido em
overrides.yaml
. Geralmente é "apigee
". - APIGEEORG_VALUE é a saída de valor do comando
kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
na etapa anterior. Por exemplo,rg-hybrid-b7d3b9c
- SOURCE_REGION é a região de origem, o valor do data center na seção Cassandra das modificações da região de origem.yaml
Exemplo:
apiVersion: apigee.cloud.google.com/v1alpha1 kind: CassandraDataReplication metadata: name: region-expansion namespace: apigee spec: organizationRef: rg-hybrid-b7d3b9c force: false source: region: "dc-1"
- Aplique o
CassandraDataReplication
com o seguinte comando:kubectl apply -f datareplication.yaml
- Receba
- Verifique o status de recriação usando o comando a seguir.
kubectl -n APIGEE_NAMESPACE get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
Os resultados terão esta aparência:
{ "rebuildDetails": { "apigee-cassandra-default-0": { "state": "complete", "updated": 1623105760 }, "apigee-cassandra-default-1": { "state": "complete", "updated": 1623105765 }, "apigee-cassandra-default-2": { "state": "complete", "updated": 1623105770 } }, "state": "complete", "updated": 1623105770 }
- Depois que a replicação de dados for concluída e verificada, atualize os hosts de origem:
-
Remova
multiRegionSeedHost: 10.0.0.11
deoverrides-DATACENTER_NAME.yaml
-
Reaplique a alteração para atualizar a resposta automática do repositório de dados da Apigee:
helm upgrade datastore apigee-datastore/ \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
-
Remova
- Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o comando
nodetool status
. .kubectl logs apigee-cassandra-default-0 -f -n APIGEE_NAMESPACE
kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
O exemplo a seguir mostra entradas de registro de exemplo:
INFO 01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens) INFO 01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild INFO 01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB) INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22 INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB) INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22 INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB) INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed
Verificar o status do cluster do Cassandra
O comando a seguir é útil para conferir se a configuração do cluster foi bem-sucedida nos dois data centers. O comando verifica o status de nodetool das duas regiões.
kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status Datacenter: dc-1 ======================= Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.12.1.45 112.09 KiB 256 100.0% 3c98c816-3f4d-48f0-9717-03d0c998637f ra-1 UN 10.12.4.36 95.27 KiB 256 100.0% 0a36383d-1d9e-41e2-924c-7b62be12d6cc ra-1 UN 10.12.5.22 88.7 KiB 256 100.0% 3561f4fa-af3d-4ea4-93b2-79ac7e938201 ra-1 Datacenter: us-west1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.4.33 78.69 KiB 256 100.0% a200217d-260b-45cd-b83c-182b27ff4c99 ra-1 UN 10.0.0.21 78.68 KiB 256 100.0% 9f3364b9-a7a1-409c-9356-b7d1d312e52b ra-1 UN 10.0.1.26 15.46 KiB 256 100.0% 1666df0f-702e-4c5b-8b6e-086d0f2e47fa ra-1
OpenShift
Configurar o host de propagação multirregional
Esta seção descreve como expandir o cluster existente do Cassandra para uma nova região. Essa configuração permite que a nova região inicialize o cluster e participe do data center atual. Sem essa configuração, os clusters multirregionais do Kubernetes não sabem da existência uns dos outros.
-
Para a primeira região criada, acesse os pods no namespace da Apigee:
kubectl get pods -o wide -n APIGEE_NAMESPACE
- Identifique o endereço do host de semente multirregional para Cassandra nesta região, por exemplo,
10.0.0.11
. -
Prepare o arquivo
overrides.yaml
para a segunda região e adicione o endereço IP do host de semente da seguinte maneira:cassandra: multiRegionSeedHost: "SEED_HOST_IP_ADDRESS" datacenter: "DATACENTER_NAME" rack: "RACK_NAME" hostNetwork: false clusterName: CLUSTER_NAME
Substitua:
- SEED_HOST_IP_ADDRESS pelo endereço IP do host de semente, por exemplo,
10.0.0.11
. - DATACENTER_NAME pelo nome do data center. Por exemplo,
dc-2
. - RACK_NAME pelo nome do rack, por exemplo,
ra-1
. - CLUSTER_NAME pelo nome do cluster da Cassandra. Por padrão, o valor é
apigeecluster
. Se você usar um nome de cluster diferente, será preciso especificar um valor para cassandra.clusterName. É possível escolher o próprio valor, mas ele precisa ser o mesmo em todas as regiões.
- SEED_HOST_IP_ADDRESS pelo endereço IP do host de semente, por exemplo,
Configurar a segunda região
Para configurar a nova região:
-
Instale o cert-manager na segunda região.
- Copie o certificado do cluster atual para o novo cluster.
A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS.
Portanto, é essencial ter certificados consistentes em todo o cluster.
-
Defina o contexto como o namespace original:
kubectl config use-context ORIGINAL_CLUSTER_NAME
-
Exporte a configuração atual do namespace para um arquivo:
kubectl get namespace APIGEE_NAMESPACE -o yaml > apigee-namespace.yaml
-
Exporte o secret
apigee-ca
para um arquivo:kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
-
Defina o contexto para o nome do cluster da nova região
kubectl config use-context NEW_CLUSTER_NAME
-
Importe a configuração do namespace para o novo cluster. Atualize o namespace no arquivo se estiver usando um namespace diferente na nova região:
kubectl apply -f apigee-namespace.yaml
-
Importe o secret para o novo cluster:
kubectl -n cert-manager apply -f apigee-ca.yaml
-
-
Siga as etapas para instalar os CRDs da Apigee híbrida na nova região.
-
Agora use gráficos do Helm para instalar a Apigee híbrida na nova região com os seguintes comandos do gráfico do Helm (como feito na região 1):
helm upgrade operator apigee-operator \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade datastore apigee-datastore \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade telemetry apigee-telemetry \ --install \ --namespace APIGEE_NAMESPACE> \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade redis apigee-redis \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade ingress-manager apigee-ingress-manager \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
helm upgrade ORG_NAME apigee-org \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env mentioned on the overrideshelm upgrade ENV_NAME apigee-env/ \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ --set env=ENV_NAME \ -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env group mentioned on the overrideshelm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ --set envgroup=ENV_GROUP_NAME \ -f overrides-DATACENTER_NAME.yaml
- Verifique a configuração do cluster do Cassandra executando o comando a seguir. A saída mostrará os data centers novos.
kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE \ -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
Exemplo de configuração concluída:
Datacenter: dc-1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.132.87.93 68.07 GiB 256 ? fb51465c-167a-42f7-98c9-b6eba1de34de c UN 10.132.84.94 69.9 GiB 256 ? f621a5ac-e7ee-48a9-9a14-73d69477c642 b UN 10.132.84.105 76.95 GiB 256 ? 0561086f-e95b-4232-ba6c-ad519ff30336 d Datacenter: dc-2 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.132.0.8 71.61 GiB 256 ? 8894a98b-8406-45de-99e2-f404ab10b5d6 c UN 10.132.9.204 75.1 GiB 256 ? afa0ffa3-630b-4f1e-b46f-fc3df988092e a UN 10.132.3.133 68.08 GiB 256 ? 25ae39ab-b39e-4d4f-9cb7-de095ab873db b
- Configurar o Cassandra em todos os pods nos novos data centers.
- Receba
apigeeorg
do cluster com o seguinte comando:kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
Exemplo:
Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" "rg-hybrid-b7d3b9c"
- Crie um arquivo de recurso personalizado de replicação de dados do Cassandra (
YAML
). O arquivo pode ter qualquer nome. Nos exemplos a seguir, o arquivo terá o nomedatareplication.yaml
.O arquivo deve conter o seguinte:
apiVersion: apigee.cloud.google.com/v1alpha1 kind: CassandraDataReplication metadata: name: REGION_EXPANSION namespace: NAMESPACE spec: organizationRef: APIGEEORG_VALUE force: false source: region: SOURCE_REGION
Em que:
- REGION_EXPANSION é o nome que você está fornecendo aos metadados. Use qualquer nome.
- NAMESPACE é o mesmo namespace fornecido em
overrides.yaml
. Geralmente é "apigee
". - APIGEEORG_VALUE é a saída de valor do comando
kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name"
na etapa anterior. Por exemplo,rg-hybrid-b7d3b9c
- SOURCE_REGION é a região de origem, o valor do data center na seção Cassandra das modificações da região de origem.yaml
Exemplo:
apiVersion: apigee.cloud.google.com/v1alpha1 kind: CassandraDataReplication metadata: name: region-expansion namespace: apigee spec: organizationRef: rg-hybrid-b7d3b9c force: false source: region: "dc-1"
- Aplique o
CassandraDataReplication
com o seguinte comando:kubectl apply -f datareplication.yaml
- Receba
- Verifique o status de recriação usando o comando a seguir.
kubectl -n APIGEE_NAMESPACE get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
Os resultados terão esta aparência:
{ "rebuildDetails": { "apigee-cassandra-default-0": { "state": "complete", "updated": 1623105760 }, "apigee-cassandra-default-1": { "state": "complete", "updated": 1623105765 }, "apigee-cassandra-default-2": { "state": "complete", "updated": 1623105770 } }, "state": "complete", "updated": 1623105770 }
- Depois que a replicação de dados for concluída e verificada, atualize os hosts de origem:
-
Remova
multiRegionSeedHost: 10.0.0.11
deoverrides-DATACENTER_NAME.yaml
-
Reaplique a alteração para atualizar a resposta automática do repositório de dados da Apigee:
helm upgrade datastore apigee-datastore/ \ --install \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides-DATACENTER_NAME.yaml
-
Remova
- Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o comando
nodetool status
. .kubectl logs apigee-cassandra-default-0 -f -n APIGEE_NAMESPACE
kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status
O exemplo a seguir mostra entradas de registro de exemplo:
INFO 01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens) INFO 01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild INFO 01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB) INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22 INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB) INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22 INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB) INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed
Verificar o status do cluster do Cassandra
O comando a seguir é útil para conferir se a configuração do cluster foi bem-sucedida nos dois data centers. O comando verifica o status de nodetool das duas regiões.
kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status Datacenter: dc-1 ======================= Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.12.1.45 112.09 KiB 256 100.0% 3c98c816-3f4d-48f0-9717-03d0c998637f ra-1 UN 10.12.4.36 95.27 KiB 256 100.0% 0a36383d-1d9e-41e2-924c-7b62be12d6cc ra-1 UN 10.12.5.22 88.7 KiB 256 100.0% 3561f4fa-af3d-4ea4-93b2-79ac7e938201 ra-1 Datacenter: us-west1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.4.33 78.69 KiB 256 100.0% a200217d-260b-45cd-b83c-182b27ff4c99 ra-1 UN 10.0.0.21 78.68 KiB 256 100.0% 9f3364b9-a7a1-409c-9356-b7d1d312e52b ra-1 UN 10.0.1.26 15.46 KiB 256 100.0% 1666df0f-702e-4c5b-8b6e-086d0f2e47fa ra-1
Solução de problemas
Consulte Falha na replicação de dados do Cassandra.