English
Deutsch
Español – América Latina
Français
Indonesia
Italiano
Português – Brasil
中文 – 简体
日本語
한국어

Comunícate con nosotros Empezar gratis

Implementación multirregional

En este tema, se describe una implementación multirregional de Apigee Hybrid en GKE, Anthos GKE implementado de forma local y en Microsoft® Azure Kubernetes Service (AKS). Selecciona tu plataforma en los requisitos previos y procedimientos.

Las topologías para la implementación multirregión incluyen lo siguiente:

Activa-Activa: Cuando tienes aplicaciones implementadas en varias ubicaciones geográficas y necesitas una respuesta de API con baja latencia para tus implementaciones. Tienes la opción de implementar Hybrid en varias ubicaciones geográficas más cercanas a tus clientes. Por ejemplo, la costa oeste de EE.UU., la costa este de EE.UU., Europa y APAC.
Activo-pasivo: Cuando tienes una región principal y una de conmutación por error o una de recuperación ante desastres.

Las regiones de una implementación híbrida multirregional se comunican a través de Cassandra, como se muestra en la siguiente imagen:

Requisitos previos

GKE

Antes de configurar Hybrid para varias regiones, debes completar los siguientes requisitos:

Configura los clústeres de Kubernetes en varias regiones con diferentes bloques CIDR
Configura la comunicación entre regiones
Requisitos multirregionales de Cassandra:
- Asegúrate de que el espacio de nombres de la red del Pod tenga conectividad en todas las regiones, incluidos los firewalls, la VPN, el intercambio de tráfico entre VPC y el intercambio de tráfico de vNet. Este es el caso de la mayoría de las instalaciones de GKE.
- Si el espacio de nombres de la red del Pod no tiene conectividad entre clústeres (los clústeres se ejecutan en “modo de red de islas”), habilita la función hostNetwork de Kubernetes mediante la configuración de cassandra.hostNetwork: true en el archivo de anulaciones para todas las regiones en la instalación multirregional de Apigee Hybrid.
  Para obtener información sobre la función hostNetwork de Kubernetes, consulta Espacios de nombres de host en la documentación de Kubernetes.
- Habilita hostNetwork en clústeres existentes antes de expandir la configuración multirregional a regiones nuevas.
- Cuando hostNetwork esté habilitado, asegúrate de que los nodos trabajadores puedan realizar la búsqueda de DNS inversa. Apigee Cassandra usa la búsqueda de DNS directa e inversa para obtener la IP del host durante el inicio.
  Sugerencia: Si la resolución de DNS no funciona, prueba esta solución alternativa.
  Agrega una entrada de host estática en el archivo /etc/hosts de cada nodo trabajador de Cassandra similar a lo siguiente:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  o
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Abre los puertos 7000 y 7001 de Cassandra entre los clústeres de Kubernetes en todas las regiones para permitir que se comuniquen los nodos trabajadores en las regiones y los centros de datos. Consulta Configura puertos.

Consulta la documentación de Kubernetes para obtener información detallada.

GKE On‑Prem

Antes de configurar Hybrid para varias regiones, debes completar los siguientes requisitos:

Configura los clústeres de Kubernetes en varias regiones con diferentes bloques CIDR
Configura la comunicación entre regiones
Requisitos multirregionales de Cassandra:
- Si el espacio de nombres de la red del Pod no tiene conectividad entre clústeres (los clústeres se ejecutan en “modo de red de islas”, que es el caso predeterminado en las instalaciones de GKE On-Prem), habilita la función hostNetwork de Kubernetes mediante la configuración de cassandra.hostNetwork: true en el archivo de anulaciones para todas las regiones en la instalación multirregional de Apigee Hybrid.
  Para obtener información sobre la función hostNetwork de Kubernetes, consulta Espacios de nombres de host en la documentación de Kubernetes.
- Habilita hostNetwork en clústeres existentes antes de expandir la configuración multirregional a regiones nuevas.
- Cuando hostNetwork esté habilitado, asegúrate de que los nodos trabajadores puedan realizar la búsqueda de DNS inversa. Apigee Cassandra usa la búsqueda de DNS directa e inversa para obtener la IP del host durante el inicio.
  Sugerencia: Si la resolución de DNS no funciona, prueba esta solución alternativa.
  Agrega una entrada de host estática en el archivo /etc/hosts de cada nodo trabajador de Cassandra similar a lo siguiente:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  o
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Abre los puertos 7000 y 7001 de Cassandra entre los clústeres de Kubernetes en todas las regiones para permitir que se comuniquen los nodos trabajadores en las regiones y los centros de datos. Consulta Configura puertos.

Consulta la documentación de Kubernetes para obtener información detallada.

AKS

Antes de configurar Hybrid para varias regiones, debes completar los siguientes requisitos:

Antes de pasar a los pasos de configuración del clúster, sigue la guía de instalación de Hybrid para conocer los requisitos previos, como Google Cloud y la configuración de la organización.
Requisitos multirregionales de Cassandra:
- Si el espacio de nombres de la red del Pod no tiene conectividad entre clústeres (los clústeres se ejecutan en “modo de red de islas”, que es el caso predeterminado de las instalaciones de AKS), habilita la función hostNetwork de Kubernetes mediante la configuración de cassandra.hostNetwork: true en el archivo de anulaciones para todas las regiones en la instalación multirregional de Apigee Hybrid.
  Para obtener información sobre la función hostNetwork de Kubernetes, consulta Espacios de nombres de host en la documentación de Kubernetes.
- Habilita hostNetwork en clústeres existentes antes de expandir la configuración multirregional a regiones nuevas.
- Cuando hostNetwork esté habilitado, asegúrate de que los nodos trabajadores puedan realizar la búsqueda de DNS inversa. Apigee Cassandra usa la búsqueda de DNS directa e inversa para obtener la IP del host durante el inicio.
  Sugerencia: Si la resolución de DNS no funciona, prueba esta solución alternativa.
  Agrega una entrada de host estática en el archivo /etc/hosts de cada nodo trabajador de Cassandra similar a lo siguiente:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  o
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Abre los puertos 7000 y 7001 de Cassandra entre los clústeres de Kubernetes en todas las regiones para permitir que se comuniquen los nodos trabajadores en las regiones y los centros de datos. Consulta Configura puertos.

Consulta la documentación de Kubernetes para obtener información detallada.

EKS

Antes de configurar Hybrid para varias regiones, debes completar los siguientes requisitos:

Antes de pasar a los pasos de configuración del clúster, sigue la guía de instalación de Hybrid para conocer los requisitos previos, como Google Cloud y la configuración de la organización.
Requisitos multirregionales de Cassandra:
- Si el espacio de nombres de la red del Pod no tiene conectividad entre clústeres (los clústeres se ejecutan en “modo de red de islas”, que es el caso predeterminado en las instalaciones de EKS), habilita la función hostNetwork de Kubernetes mediante la configuración de cassandra.hostNetwork: true en el archivo de anulaciones para todas las regiones en la instalación multirregional de Apigee Hybrid.
  Para obtener información sobre la función hostNetwork de Kubernetes, consulta Espacios de nombres de host en la documentación de Kubernetes.
- Habilita hostNetwork en clústeres existentes antes de expandir la configuración multirregional a regiones nuevas.
- Cuando hostNetwork esté habilitado, asegúrate de que los nodos trabajadores puedan realizar la búsqueda de DNS inversa. Apigee Cassandra usa la búsqueda de DNS directa e inversa para obtener la IP del host durante el inicio.
  Sugerencia: Si la resolución de DNS no funciona, prueba esta solución alternativa.
  Agrega una entrada de host estática en el archivo /etc/hosts de cada nodo trabajador de Cassandra similar a lo siguiente:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  o
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Abre los puertos 7000 y 7001 de Cassandra entre los clústeres de Kubernetes en todas las regiones para permitir que se comuniquen los nodos trabajadores en las regiones y los centros de datos. Consulta Configura puertos.

Consulta la documentación de Kubernetes para obtener información detallada.

OpenShift

Antes de configurar Hybrid para varias regiones, debes completar los siguientes requisitos:

Antes de pasar a los pasos de configuración del clúster, sigue la guía de instalación de Hybrid para conocer los requisitos previos, como Google Cloud y la configuración de la organización.
Requisitos multirregionales de Cassandra:
- Si el espacio de nombres de la red del Pod no tiene conectividad entre clústeres (los clústeres se ejecutan en “modo de red de islas”, que es el caso predeterminado en las instalaciones de OpenShift), habilita la función hostNetwork de Kubernetes mediante la configuración de cassandra.hostNetwork: true en el archivo de anulaciones para todas las regiones en la instalación multirregional de Apigee Hybrid.
  Para obtener información sobre la función hostNetwork de Kubernetes, consulta Espacios de nombres de host en la documentación de Kubernetes.
- Habilita hostNetwork en clústeres existentes antes de expandir la configuración multirregional a regiones nuevas.
- Cuando hostNetwork esté habilitado, asegúrate de que los nodos trabajadores puedan realizar la búsqueda de DNS inversa. Apigee Cassandra usa la búsqueda de DNS directa e inversa para obtener la IP del host durante el inicio.
  Sugerencia: Si la resolución de DNS no funciona, prueba esta solución alternativa.
  Agrega una entrada de host estática en el archivo /etc/hosts de cada nodo trabajador de Cassandra similar a lo siguiente:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  o
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Abre los puertos 7000 y 7001 de Cassandra entre los clústeres de Kubernetes en todas las regiones para permitir que se comuniquen los nodos trabajadores en las regiones y los centros de datos. Consulta Configura puertos.

Consulta la documentación de Kubernetes para obtener información detallada.

Configura Apigee Hybrid para varias regiones

GKE

Configura el host de origen de varias regiones

En esta sección, se describe cómo expandir el clúster existente de Cassandra a una región nueva. Esta configuración permite que la región nueva inicie el clúster y se una al centro de datos existente. Sin esta configuración, los clústeres de Kubernetes multirregionales no se reconocerían entre sí.

Configure el contexto de kubectl en el clúster original antes de recuperar el nombre de origen:
```
kubectl config use-context original-cluster-name
```

Ejecuta el siguiente comando kubectl para identificar una dirección de host de origen de Cassandra en la región actual.

Una dirección de host de origen permite que una instancia regional nueva encuentre el clúster original en el primer startup para obtener la topología del clúster. La dirección del host de origen se designa como el punto de contacto en el clúster.

kubectl get pods -o wide -n apigee

NAME                      READY   STATUS      RESTARTS   AGE   IP          NODE                                          NOMINATED NODE
apigee-cassandra-default-0        1/1     Running     0          5d    10.0.0.11   gke-k8s-dc-2-default-pool-a2206492-p55d
apigee-cassandra-default-1        1/1     Running     0          5d    10.0.2.4    gke-k8s-dc-2-default-pool-e9daaab3-tjmz
apigee-cassandra-default-2        1/1     Running     0          5d    10.0.3.5    gke-k8s-dc-2-default-pool-e589awq3-kjch

Decide cuál de las IP que se mostraron en el comando anterior será el host de origen de varias regiones.
En el centro de datos 2, configura cassandra.multiRegionSeedHost y cassandra.datacenter en Administra componentes del plano de entorno de ejecución, en el que multiRegionSeedHost es una de las IP que muestra el comando anterior:
```
cassandra:
  multiRegionSeedHost: seed_host_IP
  datacenter: data_center_name
  rack: rack_name
  hostNetwork: false
```
Por ejemplo:
```
cassandra:
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"
  rack: "ra-1"
  hostNetwork: false
```
Antes de instalar Hybrid, en el centro de datos o la región nuevos, configura los mismos certificados TLS y las credenciales en overrides_your_cluster_name.yaml que configuraste en la primera región.
NOTA: Asegúrate de usar los mismos certificados y credenciales TLS de Cassandra en el segundo centro de datos, como lo hiciste para el centro de datos original. Las credenciales que establezcas en el archivo de anulación del primer centro de datos deben coincidir con las que especifiques en el archivo de anulación del segundo centro de datos. Si quieres obtener más detalles, consulta Configura TLS para Cassandra.

Configura la región nueva

Después de configurar el host de origen, puedes configurar la región nueva.

Para configurar la región nueva, haz lo siguiente:

Copia tu certificado del clúster existente en el clúster nuevo. Cassandra y otros componentes híbridos para mTLS usan la raíz de CA nueva. Por lo tanto, es fundamental tener certificados coherentes en todo el clúster.
1. Establece el contexto en el espacio de nombres original:
```
kubectl config use-context original-cluster-name
```
2. Exporta la configuración del espacio de nombres actual a un archivo:
```
kubectl get namespace namespace -o yaml > apigee-namespace.yaml
```
3. Exporta el Secret apigee-ca a un archivo:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Establece el contexto en el nombre del clúster de la región nueva:
```
kubectl config use-context new-cluster-name
```
5. Importa la configuración del espacio de nombres al clúster nuevo. Asegúrate de actualizar el “espacio de nombres” en el archivo si usas un espacio de nombres diferente en la región nueva:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importa el secreto al clúster nuevo:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instala el híbrido en la nueva región. Asegúrate de que el archivo overrides_your_cluster_name.yaml incluya los mismos certificados TLS que se configuraron en la primera región, como se explica en la sección anterior.
Ejecuta los siguientes dos comandos para instalar el servicio híbrido en la región nueva:

Importante: Cuando expandas Apigee Hybrid a un nuevo centro de datos regional, asegúrate de instalar la misma versión híbrida que tienes en tu centro de datos existente. Evita ejecutar diferentes versiones de Hybrid en varios centros de datos.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Ejecuta el siguiente comando para verificar que la instalación híbrida se realice de forma correcta:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Ejecuta el siguiente comando para verificar la configuración del clúster de Cassandra. El resultado debería mostrar los centros de datos nuevos y existentes.

kubectl exec apigee-cassandra-default-0 -n apigee  \
  -- nodetool -u JMX_user -pw JMX_password status

Ejemplo que muestra una configuración realizada correctamente:

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

Configura Cassandra en todos los Pods de los nuevos centros de datos.
1. Obtén apigeeorg del clúster con el siguiente comando:
```
kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
```
  Por ejemplo:
```
Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
"rg-hybrid-b7d3b9c"
```
2. Crea un archivo de recurso personalizado de replicación de datos de Cassandra (YAML). El archivo puede tener cualquier nombre. En los siguientes ejemplos, el archivo tendrá el nombre datareplication.yaml.
  El archivo debe contener la siguiente información:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Aquí:
  - REGION_EXPANSION es el nombre que le asignas a estos metadatos. Puedes usar cualquier nombre.
  - NAMESPACE es el mismo espacio de nombres que se proporciona en overrides.yaml. Por lo general, es “apigee”.
  - APIGEEORG_VALUE es el valor de salida del comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name en el paso anterior. Por ejemplo: rg-hybrid-b7d3b9c
  - SOURCE_REGION es el nombre del centro de datos en la región de origen. Este es el valor establecido para cassandra:datacenter: en tu overrides.yaml.
  Por ejemplo:
```
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"
```
3. Aplica CassandraDataReplication con el siguiente comando:
```
kubectl apply -f datareplication.yaml
```
4. Verifica el estado de recompilación con el siguiente comando.
  Nota: La operación de recompilación puede demorar varias horas en función del tamaño de los datos.
```
kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication
```
  El resultado debería ser similar a lo siguiente:
```
{
  "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
}
```

Verifica los procesos de recompilación de los registros. Además, verifica el tamaño de los datos mediante el comando nodetool status:

kubectl logs apigee-cassandra-default-0 -f -n apigee

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status

El siguiente ejemplo muestra entradas de registro de ejemplo:

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

Actualiza los hosts de origen. Quita multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml y vuelve a enviar la solicitud.
Los hosts de origen son miembros del clúster local. Debes tener un host de origen externo para iniciar una nueva región. Una vez que se inicia una región, debes cambiar los hosts de origen a sus clústeres locales en overrides.yaml y, luego, volver a aplicar la configuración.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Comprueba el estado del clúster de Cassandra

El siguiente comando es útil para ver si la configuración del clúster se realizó de forma correcta en dos centros de datos. El comando comprueba el estado de la herramienta del nodo de las dos regiones.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw 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: dc-2
================
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          0.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          0.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          0.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

GKE On‑Prem

Configura el host de origen de varias regiones

En esta sección, se describe cómo expandir el clúster existente de Cassandra a una región nueva. Esta configuración permite que la región nueva inicie el clúster y se una al centro de datos existente. Sin esta configuración, los clústeres de Kubernetes multirregionales no se reconocerían entre sí.

En el archivo overrides.yaml de tu clúster original, asegúrate de que cassandra:hostNetwork esté configurado como true. Por ejemplo:
```
cassandra:
  hostNetwork: true
```
Configure el contexto de kubectl en el clúster original antes de recuperar el nombre de origen:
```
kubectl config use-context original-cluster-name
```

Ejecuta el siguiente comando kubectl para identificar una dirección de host de origen de Cassandra en la región actual.

Una dirección de host de origen permite que una instancia regional nueva encuentre el clúster original en el primer startup para obtener la topología del clúster. La dirección del host de origen se designa como el punto de contacto en el clúster.

kubectl get pods -o wide -n apigee

NAME                      READY   STATUS      RESTARTS   AGE   IP          NODE                                          NOMINATED NODE
apigee-cassandra-default-0        1/1     Running     0          5d    10.0.0.11   gke-k8s-dc-2-default-pool-a2206492-p55d
apigee-cassandra-default-1        1/1     Running     0          5d    10.0.2.4    gke-k8s-dc-2-default-pool-e9daaab3-tjmz
apigee-cassandra-default-2        1/1     Running     0          5d    10.0.3.5    gke-k8s-dc-2-default-pool-e589awq3-kjch

Decide cuál de las IP que se mostraron en el comando anterior será el host de origen de varias regiones.

En el centro de datos 2, configura cassandra.multiRegionSeedHost en tu archivo de anulaciones, en el que multiRegionSeedHost es una de las IP que muestra el comando anterior:

cassandra:
  hostNetwork: true
  multiRegionSeedHost: seed_host_IP
  datacenter: data_center_name

Por ejemplo:

cassandra:
  hostNetwork: true
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"

Antes de instalar Hybrid, en el centro de datos o la región nuevos, configura los mismos certificados TLS y las credenciales en overrides_your_cluster_name.yaml que configuraste en la primera región.
NOTA: Asegúrate de usar los mismos certificados y credenciales TLS de Cassandra en el segundo centro de datos, como lo hiciste para el centro de datos original. Las credenciales que establezcas en el archivo de anulación del primer centro de datos deben coincidir con las que especifiques en el archivo de anulación del segundo centro de datos. Si quieres obtener más detalles, consulta Configura TLS para Cassandra.

Configura la región nueva

Después de configurar el host de origen, puedes configurar la región nueva.

Para configurar la región nueva, haz lo siguiente:

Copia tu certificado del clúster existente en el clúster nuevo. Cassandra y otros componentes híbridos para mTLS usan la raíz de CA nueva. Por lo tanto, es fundamental tener certificados coherentes en todo el clúster.
1. Establece el contexto en el espacio de nombres original:
```
kubectl config use-context original-cluster-name
```
2. Exporta la configuración del espacio de nombres actual a un archivo:
```
kubectl get namespace namespace -o yaml > apigee-namespace.yaml
```
3. Exporta el Secret apigee-ca a un archivo:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Establece el contexto en el nombre del clúster de la región nueva:
```
kubectl config use-context new-cluster-name
```
5. Importa la configuración del espacio de nombres al clúster nuevo. Asegúrate de actualizar el “espacio de nombres” en el archivo si usas un espacio de nombres diferente en la región nueva:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importa el secreto al clúster nuevo:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instala el híbrido en la nueva región. Asegúrate de que el archivo overrides_your_cluster_name.yaml incluya los mismos certificados TLS que se configuraron en la primera región, como se explica en la sección anterior.
Ejecuta los siguientes dos comandos para instalar el servicio híbrido en la región nueva:

Importante: Cuando expandas Apigee Hybrid a un nuevo centro de datos regional, asegúrate de instalar la misma versión híbrida que tienes en tu centro de datos existente. Evita ejecutar diferentes versiones de Hybrid en varios centros de datos.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Ejecuta el siguiente comando para verificar que la instalación híbrida se realice de forma correcta:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Ejecuta el siguiente comando para verificar la configuración del clúster de Cassandra. El resultado debería mostrar los centros de datos nuevos y existentes.

kubectl exec apigee-cassandra-default-0 -n apigee  \
  -- nodetool -u JMX_user -pw JMX_password status

Ejemplo que muestra una configuración realizada correctamente:

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

Configura Cassandra en todos los Pods de los nuevos centros de datos.
1. Obtén apigeeorg del clúster con el siguiente comando:
```
kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
```
  Por ejemplo:
```
Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
"rg-hybrid-b7d3b9c"
```
2. Crea un archivo de recurso personalizado de replicación de datos de Cassandra (YAML). El archivo puede tener cualquier nombre. En los siguientes ejemplos, el archivo tendrá el nombre datareplication.yaml.
  El archivo debe contener la siguiente información:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Aquí:
  - REGION_EXPANSION es el nombre que le asignas a estos metadatos. Puedes usar cualquier nombre.
  - NAMESPACE es el mismo espacio de nombres que se proporciona en overrides.yaml. Por lo general, es “apigee”.
  - APIGEEORG_VALUE es el valor de salida del comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name en el paso anterior. Por ejemplo: rg-hybrid-b7d3b9c
  - SOURCE_REGION es el nombre del centro de datos en la región de origen. Este es el valor establecido para cassandra:datacenter: en tu overrides.yaml.
  Por ejemplo:
```
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"
```
3. Aplica CassandraDataReplication con el siguiente comando:
```
kubectl apply -f datareplication.yaml
```
4. Verifica el estado de recompilación con el siguiente comando.
  Nota: La operación de recompilación puede demorar varias horas en función del tamaño de los datos.
```
kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication
```
  El resultado debería ser similar a lo siguiente:
```
{
  "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
}
```

Verifica los procesos de recompilación de los registros. Además, verifica el tamaño de los datos mediante el comando nodetool status:

kubectl logs apigee-cassandra-default-0 -f -n apigee

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status

El siguiente ejemplo muestra entradas de registro de ejemplo:

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

Actualiza los hosts de origen. Quita multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml y vuelve a enviar la solicitud.
Los hosts de origen son miembros del clúster local. Debes tener un host de origen externo para iniciar una nueva región. Una vez que se inicia una región, debes cambiar los hosts de origen a sus clústeres locales en overrides.yaml y, luego, volver a aplicar la configuración.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Comprueba el estado del clúster de Cassandra

El siguiente comando es útil para ver si la configuración del clúster se realizó de forma correcta en dos centros de datos. El comando comprueba el estado de la herramienta del nodo de las dos regiones.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw 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: dc-2
================
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          0.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          0.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          0.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

AKS

Crea una red virtual en cada región

Sigue las recomendaciones de Azure para establecer comunicación entre regiones aquí: De VNet a VNet: Conecta redes virtuales en Azure en diferentes regiones.

Crea clústeres multirregionales

Configura clústeres de Kubernetes en varias regiones con diferentes bloques CIDR. Consulta también el Paso 1: Crea un clúster. Usa las ubicaciones y los nombres de las redes virtuales que creaste antes.

Abre los puertos de Cassandra 7000 y 7001 entre clústeres de Kubernetes en todas las regiones (7000 se puede usar como opción de copia de seguridad durante la solución de problemas)

Configura el host de origen de varias regiones

En esta sección, se describe cómo expandir el clúster existente de Cassandra a una región nueva. Esta configuración permite que la región nueva inicie el clúster y se una al centro de datos existente. Sin esta configuración, los clústeres de Kubernetes multirregionales no se reconocerían entre sí.

En el archivo overrides.yaml de tu clúster original, asegúrate de que cassandra:hostNetwork esté configurado como true. Por ejemplo:
```
cassandra:
  hostNetwork: true
```
Configure el contexto de kubectl en el clúster original antes de recuperar el nombre de origen:
```
kubectl config use-context original-cluster-name
```
Ejecuta el siguiente comando kubectl para identificar una dirección de host de origen de Cassandra en la región actual.

Una dirección de host de origen permite que una instancia regional nueva encuentre el clúster original en el primer startup para obtener la topología del clúster. La dirección del host de origen se designa como el punto de contacto en el clúster.
```
kubectl get pods -o wide -n apigee | grep apigee-cassandra
```
```
apigee-cassandra-default-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000
```
Decide cuál de las IP que se mostraron en el comando anterior será el host de origen de varias regiones. En este ejemplo, en el que solo se ejecuta un clúster de Cassandra de nodo, el host de origen es 120.38.1.9.
En el centro de datos 2, copia tu archivo de anulación a un archivo nuevo cuyo nombre incluya el nombre del clúster. Por ejemplo, overrides_your_cluster_name.yaml.

En el centro de datos 2, configura cassandra.multiRegionSeedHost y cassandra.datacenter en overrides_your_cluster_name.yaml, en el que multiRegionSeedHost es una de las IP que muestra el comando anterior:

cassandra:
     multiRegionSeedHost: seed_host_IP
     datacenter: data_center_name
     rack: rack_name
     hostNetwork: true

Por ejemplo:

cassandra:
  multiRegionSeedHost: 120.38.1.9
  datacenter: "dc-2"
  rack: "ra-1"
  hostNetwork: true

Antes de instalar Hybrid, en el centro de datos o la región nuevos, configura los mismos certificados TLS y las credenciales en overrides_your_cluster_name.yaml que configuraste en la primera región.
NOTA: Asegúrate de usar los mismos certificados y credenciales TLS de Cassandra en el segundo centro de datos, como lo hiciste para el centro de datos original. Las credenciales que establezcas en el archivo de anulación del primer centro de datos deben coincidir con las que especifiques en el archivo de anulación del segundo centro de datos. Si quieres obtener más detalles, consulta Configura TLS para Cassandra.

Configura la región nueva

Después de configurar el host de origen, puedes configurar la región nueva.

Para configurar la región nueva, haz lo siguiente:

Copia tu certificado del clúster existente en el clúster nuevo. Cassandra y otros componentes híbridos para mTLS usan la raíz de CA nueva. Por lo tanto, es fundamental tener certificados coherentes en todo el clúster.
1. Establece el contexto en el espacio de nombres original:
```
kubectl config use-context original-cluster-name
```
2. Exporta la configuración del espacio de nombres actual a un archivo:
```
kubectl get namespace namespace -o yaml > apigee-namespace.yaml
```
3. Exporta el Secret apigee-ca a un archivo:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Establece el contexto en el nombre del clúster de la región nueva:
```
kubectl config use-context new-cluster-name
```
5. Importa la configuración del espacio de nombres al clúster nuevo. Asegúrate de actualizar el “espacio de nombres” en el archivo si usas un espacio de nombres diferente en la región nueva:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importa el secreto al clúster nuevo:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instala el híbrido en la nueva región. Asegúrate de que el archivo overrides_your_cluster_name.yaml incluya los mismos certificados TLS que se configuraron en la primera región, como se explica en la sección anterior.
Ejecuta los siguientes dos comandos para instalar el servicio híbrido en la región nueva:

Importante: Cuando expandas Apigee Hybrid a un nuevo centro de datos regional, asegúrate de instalar la misma versión híbrida que tienes en tu centro de datos existente. Evita ejecutar diferentes versiones de Hybrid en varios centros de datos.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Ejecuta el siguiente comando para verificar que la instalación híbrida se realice de forma correcta:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Ejecuta el siguiente comando para verificar la configuración del clúster de Cassandra. El resultado debería mostrar los centros de datos nuevos y existentes.

kubectl exec apigee-cassandra-default-0 -n apigee  \
  -- nodetool -u JMX_user -pw JMX_password status

Ejemplo que muestra una configuración realizada correctamente:

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

Configura Cassandra en todos los Pods de los nuevos centros de datos.
1. Obtén apigeeorg del clúster con el siguiente comando:
```
kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
```
  Por ejemplo:
```
Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
"rg-hybrid-b7d3b9c"
```
2. Crea un archivo de recurso personalizado de replicación de datos de Cassandra (YAML). El archivo puede tener cualquier nombre. En los siguientes ejemplos, el archivo tendrá el nombre datareplication.yaml.
  El archivo debe contener la siguiente información:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Aquí:
  - REGION_EXPANSION es el nombre que le asignas a estos metadatos. Puedes usar cualquier nombre.
  - NAMESPACE es el mismo espacio de nombres que se proporciona en overrides.yaml. Por lo general, es “apigee”.
  - APIGEEORG_VALUE es el valor de salida del comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name en el paso anterior. Por ejemplo: rg-hybrid-b7d3b9c
  - SOURCE_REGION es el nombre del centro de datos en la región de origen. Este es el valor establecido para cassandra:datacenter: en tu overrides.yaml.
  Por ejemplo:
```
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"
```
3. Aplica CassandraDataReplication con el siguiente comando:
```
kubectl apply -f datareplication.yaml
```
4. Verifica el estado de recompilación con el siguiente comando.
  Nota: La operación de recompilación puede demorar varias horas en función del tamaño de los datos.
```
kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication
```
  El resultado debería ser similar a lo siguiente:
```
{
  "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
}
```

Verifica los procesos de recompilación de los registros. Además, verifica el tamaño de los datos mediante el comando nodetool status:

kubectl logs apigee-cassandra-default-0 -f -n apigee

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status

El siguiente ejemplo muestra entradas de registro de ejemplo:

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

Actualiza los hosts de origen. Quita multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml y vuelve a enviar la solicitud.
Los hosts de origen son miembros del clúster local. Debes tener un host de origen externo para iniciar una nueva región. Una vez que se inicia una región, debes cambiar los hosts de origen a sus clústeres locales en overrides.yaml y, luego, volver a aplicar la configuración.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Comprueba el estado del clúster de Cassandra

El siguiente comando es útil para ver si la configuración del clúster se realizó de forma correcta en dos centros de datos. El comando comprueba el estado de la herramienta del nodo de las dos regiones.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw 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: dc-2
================
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          0.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          0.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          0.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

OpenShift

Configura el host de origen de varias regiones

En esta sección, se describe cómo expandir el clúster existente de Cassandra a una región nueva. Esta configuración permite que la región nueva inicie el clúster y se una al centro de datos existente. Sin esta configuración, los clústeres de Kubernetes multirregionales no se reconocerían entre sí.

En el archivo overrides.yaml de tu clúster original, asegúrate de que cassandra:hostNetwork esté configurado como true. Por ejemplo:
```
cassandra:
  hostNetwork: true
```
Configure el contexto de kubectl en el clúster original antes de recuperar el nombre de origen:
```
kubectl config use-context original-cluster-name
```

Ejecuta el siguiente comando kubectl para identificar una dirección de host de origen de Cassandra en la región actual.

Una dirección de host de origen permite que una instancia regional nueva encuentre el clúster original en el primer startup para obtener la topología del clúster. La dirección del host de origen se designa como el punto de contacto en el clúster.

kubectl get pods -o wide -n apigee

NAME                      READY   STATUS      RESTARTS   AGE   IP          NODE                                          NOMINATED NODE
apigee-cassandra-default-0        1/1     Running     0          5d    10.0.0.11   gke-k8s-dc-2-default-pool-a2206492-p55d
apigee-cassandra-default-1        1/1     Running     0          5d    10.0.2.4    gke-k8s-dc-2-default-pool-e9daaab3-tjmz
apigee-cassandra-default-2        1/1     Running     0          5d    10.0.3.5    gke-k8s-dc-2-default-pool-e589awq3-kjch

Selecciona la dirección IP de tu host de Cassandra de origen para usar como host de origen multirregión. En este ejemplo, este es el clúster de apigee-cassandra-default-0 en ejecución, el host de origen es 10.0.0.11.
En el centro de datos 2, copia tu archivo de anulación a un archivo nuevo cuyo nombre incluya el nombre del clúster. Por ejemplo, overrides_your_cluster_name.yaml.

En el centro de datos 2, configura cassandra.multiRegionSeedHost y cassandra.datacenter en overrides_your_cluster_name.yaml, en el que multiRegionSeedHost es una de las IP que muestra el comando anterior:

cassandra:
     hostNetwork: true
     multiRegionSeedHost: seed_host_IP # Cassandra pod IP address from the source region.
     datacenter: data_center_name

Por ejemplo:

cassandra:
  hostNetwork: true
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"

Antes de instalar Hybrid, en el centro de datos o la región nuevos, configura los mismos certificados TLS y las credenciales en overrides_your_cluster_name.yaml que configuraste en la primera región.
NOTA: Asegúrate de usar los mismos certificados y credenciales TLS de Cassandra en el segundo centro de datos, como lo hiciste para el centro de datos original. Las credenciales que establezcas en el archivo de anulación del primer centro de datos deben coincidir con las que especifiques en el archivo de anulación del segundo centro de datos. Si quieres obtener más detalles, consulta Configura TLS para Cassandra.

Configura la región nueva

Después de configurar el host de origen, puedes configurar la región nueva.

Para configurar la región nueva, haz lo siguiente:

Copia tu certificado del clúster existente en el clúster nuevo. Cassandra y otros componentes híbridos para mTLS usan la raíz de CA nueva. Por lo tanto, es fundamental tener certificados coherentes en todo el clúster.
1. Establece el contexto en el espacio de nombres original:
```
kubectl config use-context original-cluster-name
```
2. Exporta la configuración del espacio de nombres actual a un archivo:
```
kubectl get namespace namespace -o yaml > apigee-namespace.yaml
```
3. Exporta el Secret apigee-ca a un archivo:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Establece el contexto en el nombre del clúster de la región nueva:
```
kubectl config use-context new-cluster-name
```
5. Importa la configuración del espacio de nombres al clúster nuevo. Asegúrate de actualizar el “espacio de nombres” en el archivo si usas un espacio de nombres diferente en la región nueva:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importa el secreto al clúster nuevo:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instala el híbrido en la nueva región. Asegúrate de que el archivo overrides_your_cluster_name.yaml incluya los mismos certificados TLS que se configuraron en la primera región, como se explica en la sección anterior.
Ejecuta los siguientes dos comandos para instalar el servicio híbrido en la región nueva:

Importante: Cuando expandas Apigee Hybrid a un nuevo centro de datos regional, asegúrate de instalar la misma versión híbrida que tienes en tu centro de datos existente. Evita ejecutar diferentes versiones de Hybrid en varios centros de datos.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Ejecuta el siguiente comando para verificar que la instalación híbrida se realice de forma correcta:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Ejecuta el siguiente comando para verificar la configuración del clúster de Cassandra. El resultado debería mostrar los centros de datos nuevos y existentes.

kubectl exec apigee-cassandra-default-0 -n apigee  \
  -- nodetool -u JMX_user -pw JMX_password status

Ejemplo que muestra una configuración realizada correctamente:

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

Configura Cassandra en todos los Pods de los nuevos centros de datos.
1. Obtén apigeeorg del clúster con el siguiente comando:
```
kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
```
  Por ejemplo:
```
Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
"rg-hybrid-b7d3b9c"
```
2. Crea un archivo de recurso personalizado de replicación de datos de Cassandra (YAML). El archivo puede tener cualquier nombre. En los siguientes ejemplos, el archivo tendrá el nombre datareplication.yaml.
  El archivo debe contener la siguiente información:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Aquí:
  - REGION_EXPANSION es el nombre que le asignas a estos metadatos. Puedes usar cualquier nombre.
  - NAMESPACE es el mismo espacio de nombres que se proporciona en overrides.yaml. Por lo general, es “apigee”.
  - APIGEEORG_VALUE es el valor de salida del comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name en el paso anterior. Por ejemplo: rg-hybrid-b7d3b9c
  - SOURCE_REGION es el nombre del centro de datos en la región de origen. Este es el valor establecido para cassandra:datacenter: en tu overrides.yaml.
  Por ejemplo:
```
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"
```
3. Aplica CassandraDataReplication con el siguiente comando:
```
kubectl apply -f datareplication.yaml
```
4. Verifica el estado de recompilación con el siguiente comando.
  Nota: La operación de recompilación puede demorar varias horas en función del tamaño de los datos.
```
kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication
```
  El resultado debería ser similar a lo siguiente:
```
{
  "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
}
```

Verifica los procesos de recompilación de los registros. Además, verifica el tamaño de los datos mediante el comando nodetool status:

kubectl logs apigee-cassandra-default-0 -f -n apigee

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status

El siguiente ejemplo muestra entradas de registro de ejemplo:

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

Actualiza los hosts de origen. Quita multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml y vuelve a enviar la solicitud.
Los hosts de origen son miembros del clúster local. Debes tener un host de origen externo para iniciar una nueva región. Una vez que se inicia una región, debes cambiar los hosts de origen a sus clústeres locales en overrides.yaml y, luego, volver a aplicar la configuración.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Comprueba el estado del clúster de Cassandra

El siguiente comando es útil para ver si la configuración del clúster se realizó de forma correcta en dos centros de datos. El comando comprueba el estado de la herramienta del nodo de las dos regiones.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw 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: dc-2
================
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          0.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          0.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          0.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

Soluciona problemas

Consulta Fallos en la replicación de datos de Cassandra.

Salvo que se indique lo contrario, el contenido de esta página está sujeto a la licencia Atribución 4.0 de Creative Commons, y los ejemplos de código están sujetos a la licencia Apache 2.0. Para obtener más información, consulta las políticas del sitio de Google Developers. Java es una marca registrada de Oracle o sus afiliados.

Última actualización: 2023-12-09 (UTC)