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

Consola

Contacto Empezar gratis

Esta página se ha traducido con Cloud Translation API.

Despliegue multirregional

En este tema se describe un despliegue multirregional de Apigee hybrid en GKE, Anthos GKE desplegado on-premise, Red Hat OpenShift y Microsoft® Azure Kubernetes Service (AKS). Selecciona tu plataforma en los requisitos y procedimientos.

Las topologías de implementación multirregional incluyen las siguientes:

Activo-activo: cuando tienes aplicaciones implementadas en varias ubicaciones geográficas y necesitas una respuesta de API de baja latencia para tus implementaciones. Tiene la opción de implementar una solución híbrida en varias ubicaciones geográficas cercanas a sus clientes. Por ejemplo: costa oeste de EE. UU., costa este de EE. UU., Europa o Asia-Pacífico.
Activo-Pasivo: cuando tienes una región principal y una región de conmutación por error o de recuperación tras 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 la opción híbrida para varias regiones, debes cumplir los siguientes requisitos:

Configurar clústeres de Kubernetes en varias regiones con diferentes bloques CIDR
Configurar la comunicación entre regiones
Requisitos de Cassandra multirregión:
- Asegúrate de que el espacio de nombres de la red de pods tenga conectividad en todas las regiones, incluidos los cortafuegos, la VPN, el emparejamiento de VPCs y el emparejamiento de VNet. Este es el caso de la mayoría de las instalaciones de GKE.
- Si el espacio de nombres de la red de pods no tiene conectividad entre clústeres (los clústeres se ejecutan en el modo de red aislada), habilita la función hostNetwork de Kubernetes definiendo cassandra.hostNetwork: true en el archivo de anulaciones de todas las regiones de tu instalación multirregión de Apigee híbrido.
  Para obtener información sobre la función hostNetwork de Kubernetes, consulta la sección Espacios de nombres de host de la documentación de Kubernetes.
- Habilita hostNetwork en los clústeres que ya tengas antes de ampliar tu configuración multirregión a otras regiones.
- Cuando hostNetwork esté habilitado, asegúrate de que los nodos de trabajo puedan realizar peticiones de DNS invertidas. Apigee Cassandra usa tanto la petición de DNS directa como la inversa para obtener la IP del host al iniciarse.
  Nota: Si la resolución de DNS no funciona, prueba esta solución alternativa.
  Añade una entrada de host estática en el archivo /etc/hosts de cada nodo de trabajador de Cassandra similar a la 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 de todas las regiones para que los nodos de trabajador de las regiones y los centros de datos puedan comunicarse. Consulta Configurar puertos.

Para obtener información detallada, consulta la documentación de Kubernetes.

GKE On‑Prem

Antes de configurar la opción híbrida para varias regiones, debes cumplir los siguientes requisitos:

Configurar clústeres de Kubernetes en varias regiones con diferentes bloques CIDR
Configurar la comunicación entre regiones
Requisitos de Cassandra multirregión:
- Si el espacio de nombres de la red de pods no tiene conectividad entre clústeres (los clústeres se ejecutan en el modo de red aislada, que es el predeterminado en las instalaciones de GKE On-Prem), habilita la función hostNetwork de Kubernetes definiendo cassandra.hostNetwork: true en el archivo de anulaciones de todas las regiones de tu instalación multirregión híbrida de Apigee.
  Para obtener información sobre la función hostNetwork de Kubernetes, consulta la sección Espacios de nombres de host de la documentación de Kubernetes.
- Habilita hostNetwork en los clústeres que ya tengas antes de ampliar tu configuración multirregión a otras regiones.
- Cuando hostNetwork esté habilitado, asegúrate de que los nodos de trabajo puedan realizar peticiones de DNS invertidas. Apigee Cassandra usa tanto la petición de DNS directa como la inversa para obtener la IP del host al iniciarse.
  Nota: Si la resolución de DNS no funciona, prueba esta solución alternativa.
  Añade una entrada de host estática en el archivo /etc/hosts de cada nodo de trabajador de Cassandra similar a la 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 de todas las regiones para que los nodos de trabajador de las regiones y los centros de datos puedan comunicarse. Consulta Configurar puertos.

Para obtener información detallada, consulta la documentación de Kubernetes.

AKS

Antes de configurar la opción híbrida para varias regiones, debes cumplir los siguientes requisitos:

Sigue la guía de instalación híbrida para consultar los requisitos previos, como la configuración de Google Cloud y de la organización, antes de pasar a los pasos de configuración del clúster.
Requisitos de Cassandra multirregión:
- Si el espacio de nombres de la red de pods no tiene conectividad entre clústeres (los clústeres se ejecutan en el modo de red aislada, que es el predeterminado en las instalaciones de AKS), habilita la función hostNetwork de Kubernetes configurando cassandra.hostNetwork: true en el archivo de anulaciones de todas las regiones de tu instalación multirregión de Apigee Hybrid.
  Para obtener información sobre la función hostNetwork de Kubernetes, consulta la sección Espacios de nombres de host de la documentación de Kubernetes.
- Habilita hostNetwork en los clústeres que ya tengas antes de ampliar tu configuración multirregión a otras regiones.
- Cuando hostNetwork esté habilitado, asegúrate de que los nodos de trabajo puedan realizar peticiones de DNS invertidas. Apigee Cassandra usa tanto la petición de DNS directa como la inversa para obtener la IP del host al iniciarse.
  Nota: Si la resolución de DNS no funciona, prueba esta solución alternativa.
  Añade una entrada de host estática en el archivo /etc/hosts de cada nodo de trabajador de Cassandra similar a la 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 de todas las regiones para que los nodos de trabajador de las regiones y los centros de datos puedan comunicarse. Consulta Configurar puertos.

Para obtener información detallada, consulta la documentación de Kubernetes.

EKS

Antes de configurar la opción híbrida para varias regiones, debes cumplir los siguientes requisitos:

Sigue la guía de instalación híbrida para consultar los requisitos previos, como la configuración de Google Cloud y de la organización, antes de pasar a los pasos de configuración del clúster.
Requisitos de Cassandra multirregión:
- Si el espacio de nombres de la red de pods no tiene conectividad entre clústeres (los clústeres se ejecutan en el modo de red aislada, que es el predeterminado en las instalaciones de EKS), habilita la función hostNetwork de Kubernetes configurando cassandra.hostNetwork: true en el archivo de anulaciones de todas las regiones de tu instalación multirregión de Apigee Hybrid.
  Para obtener información sobre la función hostNetwork de Kubernetes, consulta la sección Espacios de nombres de host de la documentación de Kubernetes.
- Habilita hostNetwork en los clústeres que ya tengas antes de ampliar tu configuración multirregión a otras regiones.
- Cuando hostNetwork esté habilitado, asegúrate de que los nodos de trabajo puedan realizar peticiones de DNS invertidas. Apigee Cassandra usa tanto la petición de DNS directa como la inversa para obtener la IP del host al iniciarse.
  Nota: Si la resolución de DNS no funciona, prueba esta solución alternativa.
  Añade una entrada de host estática en el archivo /etc/hosts de cada nodo de trabajador de Cassandra similar a la 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 de todas las regiones para que los nodos de trabajador de las regiones y los centros de datos puedan comunicarse. Consulta Configurar puertos.

Para obtener información detallada, consulta la documentación de Kubernetes.

OpenShift

Antes de configurar la opción híbrida para varias regiones, debes cumplir los siguientes requisitos:

Sigue la guía de instalación híbrida para consultar los requisitos previos, como la configuración de Google Cloud y de la organización, antes de pasar a los pasos de configuración del clúster.
Requisitos de Cassandra multirregión:
- Si el espacio de nombres de la red de pods no tiene conectividad entre clústeres (los clústeres se ejecutan en el modo de red aislada, que es el predeterminado en las instalaciones de OpenShift), habilita la función hostNetwork de Kubernetes configurando cassandra.hostNetwork: true en el archivo de anulaciones de todas las regiones de tu instalación multirregión de Apigee hybrid.
  Para obtener información sobre la función hostNetwork de Kubernetes, consulta la sección Espacios de nombres de host de la documentación de Kubernetes.
- Habilita hostNetwork en los clústeres que ya tengas antes de ampliar tu configuración multirregión a otras regiones.
- Cuando hostNetwork esté habilitado, asegúrate de que los nodos de trabajo puedan realizar peticiones de DNS invertidas. Apigee Cassandra usa tanto la petición de DNS directa como la inversa para obtener la IP del host al iniciarse.
  Nota: Si la resolución de DNS no funciona, prueba esta solución alternativa.
  Añade una entrada de host estática en el archivo /etc/hosts de cada nodo de trabajador de Cassandra similar a la 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 de todas las regiones para que los nodos de trabajador de las regiones y los centros de datos puedan comunicarse. Consulta Configurar puertos.

Para obtener información detallada, consulta la documentación de Kubernetes.

Configurar Apigee Hybrid para varias regiones

GKE

Configurar el host de seed multirregional

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

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

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

Una dirección de host de inicialización permite que una nueva instancia regional encuentre el clúster original en el primer inicio para conocer la topología del clúster. La dirección del host de inicio se designa como punto de contacto del 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 IPs devueltas por el comando anterior será el host de seed multirregión.

En el centro de datos 2, configure cassandra.multiRegionSeedHost y cassandra.datacenter en Gestionar componentes del plano de tiempo de ejecución, donde multiRegionSeedHost es una de las IPs devueltas por 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

En el nuevo centro de datos o región, antes de instalar la opción híbrida, define los mismos certificados TLS y las mismas credenciales en overrides_your_cluster_name.yaml que en la primera región.
NOTA: Asegúrate de usar los mismos certificados y credenciales TLS de Cassandra en el segundo centro de datos que en el centro de datos original. Las credenciales que defina en el archivo de anulaciones del primer centro de datos deben coincidir con las que especifique en el archivo de anulaciones del segundo centro de datos. Para obtener más información, consulta Configurar TLS para Cassandra.

Configurar la nueva región

Una vez que hayas configurado el host de origen, podrás configurar la nueva región.

Para configurar la nueva región, sigue estos pasos:

Copia el certificado del clúster actual al nuevo. La nueva raíz de CA la usan Cassandra y otros componentes híbridos para mTLS. Por lo tanto, es fundamental que los certificados del clúster sean coherentes.
1. Define 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 secreto de apigee-ca a un archivo:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Define el contexto con el nombre del clúster de la nueva región:
```
kubectl config use-context new-cluster-name
```
5. Importa la configuración del espacio de nombres al nuevo clúster. Asegúrate de actualizar el "namespace" del archivo si usas otro en la nueva región:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importa el secreto al nuevo clúster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instala la versión híbrida en la nueva región. Asegúrate de que el archivo overrides_your_cluster_name.yaml incluya los mismos certificados TLS que se hayan configurado en la primera región, tal como se explica en la sección anterior.
Ejecuta los dos comandos siguientes para instalar Hybrid en la nueva región:

Importante: Cuando amplíes Apigee Hybrid a un nuevo centro de datos regional, asegúrate de instalar la misma versión de Hybrid que tengas en tu centro de datos. Evita ejecutar diferentes versiones de híbrido en varios centros de datos.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Para comprobar que la instalación híbrida se ha realizado correctamente, ejecuta el siguiente comando:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Verifica la configuración del clúster de Cassandra ejecutando el siguiente comando. La salida debería mostrar tanto los centros de datos actuales como los nuevos.

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

Ejemplo de configuración correcta:

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 se llamará datareplication.yaml.
  El archivo debe contener lo siguiente:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Donde:
  - REGION_EXPANSION es el nombre que le asignas a estos metadatos. Puedes usar el nombre que quieras.
  - NAMESPACE es el mismo espacio de nombres que se proporciona en overrides.yaml. Normalmente es "apigee".
  - APIGEEORG_VALUE es el valor que devuelve el comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name del paso anterior. Por ejemplo, rg-hybrid-b7d3b9c
  - SOURCE_REGION es el nombre del centro de datos de la región de origen. Este es el valor definido para cassandra:datacenter: en su 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 el comando CassandraDataReplication con el siguiente comando:
```
kubectl apply -f datareplication.yaml
```
4. Verifica el estado de la recompilación con el siguiente comando.
  Nota: La operación de reconstrucción puede tardar varias horas en función del tamaño de los datos.
```
kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication
```
  Los resultados deberían ser similares a los siguientes:
```
{
  "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 en los registros. Además, compruebe el tamaño de los datos con 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

En el siguiente ejemplo se muestran 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 inicialización. Quita multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml y vuelve a aplicarlo.
Los hosts de inicialización son miembros del clúster local. Para iniciar una nueva región, se necesita un host de seed externo. Una vez que se haya iniciado una región, debes cambiar los hosts de semillas a sus clústeres locales en overrides.yaml y, a continuación, volver a aplicar la configuración.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Comprobar el estado del clúster de Cassandra

El siguiente comando es útil para comprobar si la configuración del clúster se ha realizado correctamente en dos centros de datos. El comando comprueba el estado de nodetool 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

Configurar el host de seed multirregional

En esta sección se describe cómo ampliar el clúster de Cassandra a una nueva región. Esta configuración permite que la nueva región arranque el clúster y se una al centro de datos. 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é definido como true. Por ejemplo:
```
cassandra:
  hostNetwork: true
```
Define el contexto de kubectl en el clúster original antes de recuperar el nombre de la semilla:
```
kubectl config use-context original-cluster-name
```

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

Una dirección de host de inicialización permite que una nueva instancia regional encuentre el clúster original en el primer inicio para conocer la topología del clúster. La dirección del host de inicio se designa como punto de contacto del 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 IPs devueltas por el comando anterior será el host de seed multirregión.

En el centro de datos 2, configure cassandra.multiRegionSeedHost en el archivo de anulaciones, donde multiRegionSeedHost es una de las IPs devueltas por 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"

En el nuevo centro de datos o región, antes de instalar la opción híbrida, define los mismos certificados TLS y las mismas credenciales en overrides_your_cluster_name.yaml que en la primera región.
NOTA: Asegúrate de usar los mismos certificados y credenciales TLS de Cassandra en el segundo centro de datos que en el centro de datos original. Las credenciales que defina en el archivo de anulaciones del primer centro de datos deben coincidir con las que especifique en el archivo de anulaciones del segundo centro de datos. Para obtener más información, consulta Configurar TLS para Cassandra.

Configurar la nueva región

Una vez que hayas configurado el host de origen, podrás configurar la nueva región.

Para configurar la nueva región, sigue estos pasos:

Copia el certificado del clúster actual al nuevo. La nueva raíz de CA la usan Cassandra y otros componentes híbridos para mTLS. Por lo tanto, es fundamental que los certificados del clúster sean coherentes.
1. Define 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 secreto de apigee-ca a un archivo:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Define el contexto con el nombre del clúster de la nueva región:
```
kubectl config use-context new-cluster-name
```
5. Importa la configuración del espacio de nombres al nuevo clúster. Asegúrate de actualizar el "namespace" del archivo si usas otro en la nueva región:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importa el secreto al nuevo clúster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instala la versión híbrida en la nueva región. Asegúrate de que el archivo overrides_your_cluster_name.yaml incluya los mismos certificados TLS que se hayan configurado en la primera región, tal como se explica en la sección anterior.
Ejecuta los dos comandos siguientes para instalar Hybrid en la nueva región:

Importante: Cuando amplíes Apigee Hybrid a un nuevo centro de datos regional, asegúrate de instalar la misma versión de Hybrid que tengas en tu centro de datos. Evita ejecutar diferentes versiones de híbrido en varios centros de datos.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Para comprobar que la instalación híbrida se ha realizado correctamente, ejecuta el siguiente comando:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Verifica la configuración del clúster de Cassandra ejecutando el siguiente comando. La salida debería mostrar tanto los centros de datos actuales como los nuevos.

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

Ejemplo de configuración correcta:

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 se llamará datareplication.yaml.
  El archivo debe contener lo siguiente:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Donde:
  - REGION_EXPANSION es el nombre que le asignas a estos metadatos. Puedes usar el nombre que quieras.
  - NAMESPACE es el mismo espacio de nombres que se proporciona en overrides.yaml. Normalmente es "apigee".
  - APIGEEORG_VALUE es el valor que devuelve el comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name del paso anterior. Por ejemplo, rg-hybrid-b7d3b9c
  - SOURCE_REGION es el nombre del centro de datos de la región de origen. Este es el valor definido para cassandra:datacenter: en su 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 el comando CassandraDataReplication con el siguiente comando:
```
kubectl apply -f datareplication.yaml
```
4. Verifica el estado de la recompilación con el siguiente comando.
  Nota: La operación de reconstrucción puede tardar varias horas en función del tamaño de los datos.
```
kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication
```
  Los resultados deberían ser similares a los siguientes:
```
{
  "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 en los registros. Además, compruebe el tamaño de los datos con 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

En el siguiente ejemplo se muestran 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 inicialización. Quita multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml y vuelve a aplicarlo.
Los hosts de inicialización son miembros del clúster local. Para iniciar una nueva región, se necesita un host de seed externo. Una vez que se haya iniciado una región, debes cambiar los hosts de semillas a sus clústeres locales en overrides.yaml y, a continuación, volver a aplicar la configuración.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Comprobar el estado del clúster de Cassandra

El siguiente comando es útil para comprobar si la configuración del clúster se ha realizado correctamente en dos centros de datos. El comando comprueba el estado de nodetool 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

Crear una red virtual en cada región

Sigue las recomendaciones de Azure para establecer la comunicación entre regiones: De red virtual a red virtual: Connecting Virtual Networks in Azure across Different Regions (Conectar redes virtuales en Azure en diferentes regiones).

Crear 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 los nombres de las ubicaciones y de las redes virtuales que hayas creado anteriormente.

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

Configurar el host de seed multirregional

En esta sección se describe cómo ampliar el clúster de Cassandra a una nueva región. Esta configuración permite que la nueva región arranque el clúster y se una al centro de datos. 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é definido como true. Por ejemplo:
```
cassandra:
  hostNetwork: true
```
Define el contexto de kubectl en el clúster original antes de recuperar el nombre de la semilla:
```
kubectl config use-context original-cluster-name
```
Ejecuta el siguiente comando kubectl para identificar una dirección de host de inicialización de Cassandra en la región actual.

Una dirección de host de inicialización permite que una nueva instancia regional encuentre el clúster original en el primer inicio para conocer la topología del clúster. La dirección del host de inicio se designa como punto de contacto del 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 IPs devueltas por el comando anterior será el host de seed multirregión. En este ejemplo, en el que solo se ejecuta un clúster de Cassandra de un solo nodo, el host de la semilla es 120.38.1.9.
En el centro de datos 2, copie el archivo de anulaciones en un archivo nuevo cuyo nombre incluya el nombre del clúster. Por ejemplo, overrides_your_cluster_name.yaml.

En el centro de datos 2, configure cassandra.multiRegionSeedHost y cassandra.datacenter en overrides_your_cluster_name.yaml, donde multiRegionSeedHost es una de las IPs devueltas por 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

En el nuevo centro de datos o región, antes de instalar la opción híbrida, define los mismos certificados TLS y las mismas credenciales en overrides_your_cluster_name.yaml que en la primera región.
NOTA: Asegúrate de usar los mismos certificados y credenciales TLS de Cassandra en el segundo centro de datos que en el centro de datos original. Las credenciales que defina en el archivo de anulaciones del primer centro de datos deben coincidir con las que especifique en el archivo de anulaciones del segundo centro de datos. Para obtener más información, consulta Configurar TLS para Cassandra.

Configurar la nueva región

Una vez que hayas configurado el host de origen, podrás configurar la nueva región.

Para configurar la nueva región, sigue estos pasos:

Copia el certificado del clúster actual al nuevo. La nueva raíz de CA la usan Cassandra y otros componentes híbridos para mTLS. Por lo tanto, es fundamental que los certificados del clúster sean coherentes.
1. Define 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 secreto de apigee-ca a un archivo:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Define el contexto con el nombre del clúster de la nueva región:
```
kubectl config use-context new-cluster-name
```
5. Importa la configuración del espacio de nombres al nuevo clúster. Asegúrate de actualizar el "namespace" del archivo si usas otro en la nueva región:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importa el secreto al nuevo clúster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instala la versión híbrida en la nueva región. Asegúrate de que el archivo overrides_your_cluster_name.yaml incluya los mismos certificados TLS que se hayan configurado en la primera región, tal como se explica en la sección anterior.
Ejecuta los dos comandos siguientes para instalar Hybrid en la nueva región:

Importante: Cuando amplíes Apigee Hybrid a un nuevo centro de datos regional, asegúrate de instalar la misma versión de Hybrid que tengas en tu centro de datos. Evita ejecutar diferentes versiones de híbrido en varios centros de datos.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Para comprobar que la instalación híbrida se ha realizado correctamente, ejecuta el siguiente comando:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Verifica la configuración del clúster de Cassandra ejecutando el siguiente comando. La salida debería mostrar tanto los centros de datos actuales como los nuevos.

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

Ejemplo de configuración correcta:

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 se llamará datareplication.yaml.
  El archivo debe contener lo siguiente:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Donde:
  - REGION_EXPANSION es el nombre que le asignas a estos metadatos. Puedes usar el nombre que quieras.
  - NAMESPACE es el mismo espacio de nombres que se proporciona en overrides.yaml. Normalmente es "apigee".
  - APIGEEORG_VALUE es el valor que devuelve el comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name del paso anterior. Por ejemplo, rg-hybrid-b7d3b9c
  - SOURCE_REGION es el nombre del centro de datos de la región de origen. Este es el valor definido para cassandra:datacenter: en su 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 el comando CassandraDataReplication con el siguiente comando:
```
kubectl apply -f datareplication.yaml
```
4. Verifica el estado de la recompilación con el siguiente comando.
  Nota: La operación de reconstrucción puede tardar varias horas en función del tamaño de los datos.
```
kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication
```
  Los resultados deberían ser similares a los siguientes:
```
{
  "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 en los registros. Además, compruebe el tamaño de los datos con 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

En el siguiente ejemplo se muestran 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 inicialización. Quita multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml y vuelve a aplicarlo.
Los hosts de inicialización son miembros del clúster local. Para iniciar una nueva región, se necesita un host de seed externo. Una vez que se haya iniciado una región, debes cambiar los hosts de semillas a sus clústeres locales en overrides.yaml y, a continuación, volver a aplicar la configuración.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Comprobar el estado del clúster de Cassandra

El siguiente comando es útil para comprobar si la configuración del clúster se ha realizado correctamente en dos centros de datos. El comando comprueba el estado de nodetool 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

Configurar el host de seed multirregional

En esta sección se describe cómo ampliar el clúster de Cassandra a una nueva región. Esta configuración permite que la nueva región arranque el clúster y se una al centro de datos. 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é definido como true. Por ejemplo:
```
cassandra:
  hostNetwork: true
```
Define el contexto de kubectl en el clúster original antes de recuperar el nombre de la semilla:
```
kubectl config use-context original-cluster-name
```

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

Una dirección de host de inicialización permite que una nueva instancia regional encuentre el clúster original en el primer inicio para conocer la topología del clúster. La dirección del host de inicio se designa como punto de contacto del 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 usarla como host de seed multirregión. En este ejemplo, el clúster apigee-cassandra-default-0 se está ejecutando y el host de la semilla es 10.0.0.11.
En el centro de datos 2, copie el archivo de anulaciones en un archivo nuevo cuyo nombre incluya el nombre del clúster. Por ejemplo, overrides_your_cluster_name.yaml.

En el centro de datos 2, configure cassandra.multiRegionSeedHost y cassandra.datacenter en overrides_your_cluster_name.yaml, donde multiRegionSeedHost es una de las IPs devueltas por 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"

En el nuevo centro de datos o región, antes de instalar la opción híbrida, define los mismos certificados TLS y las mismas credenciales en overrides_your_cluster_name.yaml que en la primera región.
NOTA: Asegúrate de usar los mismos certificados y credenciales TLS de Cassandra en el segundo centro de datos que en el centro de datos original. Las credenciales que defina en el archivo de anulaciones del primer centro de datos deben coincidir con las que especifique en el archivo de anulaciones del segundo centro de datos. Para obtener más información, consulta Configurar TLS para Cassandra.

Configurar la nueva región

Una vez que hayas configurado el host de origen, podrás configurar la nueva región.

Para configurar la nueva región, sigue estos pasos:

Copia el certificado del clúster actual al nuevo. La nueva raíz de CA la usan Cassandra y otros componentes híbridos para mTLS. Por lo tanto, es fundamental que los certificados del clúster sean coherentes.
1. Define 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 secreto de apigee-ca a un archivo:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Define el contexto con el nombre del clúster de la nueva región:
```
kubectl config use-context new-cluster-name
```
5. Importa la configuración del espacio de nombres al nuevo clúster. Asegúrate de actualizar el "namespace" del archivo si usas otro en la nueva región:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importa el secreto al nuevo clúster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instala la versión híbrida en la nueva región. Asegúrate de que el archivo overrides_your_cluster_name.yaml incluya los mismos certificados TLS que se hayan configurado en la primera región, tal como se explica en la sección anterior.
Ejecuta los dos comandos siguientes para instalar Hybrid en la nueva región:

Importante: Cuando amplíes Apigee Hybrid a un nuevo centro de datos regional, asegúrate de instalar la misma versión de Hybrid que tengas en tu centro de datos. Evita ejecutar diferentes versiones de híbrido en varios centros de datos.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Para comprobar que la instalación híbrida se ha realizado correctamente, ejecuta el siguiente comando:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Verifica la configuración del clúster de Cassandra ejecutando el siguiente comando. La salida debería mostrar tanto los centros de datos actuales como los nuevos.

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

Ejemplo de configuración correcta:

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 se llamará datareplication.yaml.
  El archivo debe contener lo siguiente:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Donde:
  - REGION_EXPANSION es el nombre que le asignas a estos metadatos. Puedes usar el nombre que quieras.
  - NAMESPACE es el mismo espacio de nombres que se proporciona en overrides.yaml. Normalmente es "apigee".
  - APIGEEORG_VALUE es el valor que devuelve el comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name del paso anterior. Por ejemplo, rg-hybrid-b7d3b9c
  - SOURCE_REGION es el nombre del centro de datos de la región de origen. Este es el valor definido para cassandra:datacenter: en su 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 el comando CassandraDataReplication con el siguiente comando:
```
kubectl apply -f datareplication.yaml
```
4. Verifica el estado de la recompilación con el siguiente comando.
  Nota: La operación de reconstrucción puede tardar varias horas en función del tamaño de los datos.
```
kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication
```
  Los resultados deberían ser similares a los siguientes:
```
{
  "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 en los registros. Además, compruebe el tamaño de los datos con 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

En el siguiente ejemplo se muestran 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 inicialización. Quita multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml y vuelve a aplicarlo.
Los hosts de inicialización son miembros del clúster local. Para iniciar una nueva región, se necesita un host de seed externo. Una vez que se haya iniciado una región, debes cambiar los hosts de semillas a sus clústeres locales en overrides.yaml y, a continuación, volver a aplicar la configuración.
```
apigeectl apply -f overrides/overrides-DC_name.yaml
```

Comprobar el estado del clúster de Cassandra

El siguiente comando es útil para comprobar si la configuración del clúster se ha realizado correctamente en dos centros de datos. El comando comprueba el estado de nodetool 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

Solución de problemas

Consulta Error de replicación de datos de Cassandra.

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

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