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, Microsoft® Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) y Red Hat OpenShift. Selecciona tu plataforma en los requisitos y procedimientos.

Las topologías de implementación multirregión 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:

Arquitectura de implementación multirregión de Apigee Hybrid

Requisitos previos

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

GKE

Cuando instales implementaciones de Apigee multirregión entre diferentes redes (por ejemplo, diferentes proveedores de la nube, diferentes redes de VPC, la nube y on-premise, etc.), debes proporcionar conectividad interna entre estas redes independientes para que Cassandra pueda comunicarse entre nodos. Esto se puede conseguir con VPNs o soluciones de conectividad específicas de la nube.
Si usas Workload Identity en un clúster para autenticar cuentas de servicio, te recomendamos que lo uses en todos los clústeres que añadas. Consulta Habilitar Workload Identity en GKE o Habilitar la federación de identidades de cargas de trabajo en AKS y EKS.
Configura clústeres de Kubernetes en varias regiones con diferentes bloques CIDR.
Asegúrate de que cert-manager esté instalado en cada clúster.
Configura la comunicación entre regiones.
Asegúrate de que todos los pods de Cassandra puedan resolver sus propios nombres de host. Si hostNetwork se define como false, el nombre de host es el nombre del pod de Cassandra. Si hostNetwork se define como true, el nombre de host es el nombre de host del nodo de Kubernetes que ejecuta el pod de Cassandra.
Nota: Para comprobar si la resolución de nombres de host funciona, usa estos comandos.

Si hostNetwork tiene el valor false, usa el comando 1. Si hostNetwork tiene el valor true, usa el comando 2.

Si la resolución de nombres de host funciona, el resultado mostrará una dirección IP. Si no se puede resolver el nombre de host, el resultado incluirá "Host not found" (Host no encontrado).

Comando 1:
```
kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i
```
Comando 2:
```
kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i
```
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 hybrid.
  Para obtener más información sobre la necesidad de hostNetwork, consulta la sección sobre los clústeres en modo aislado y hostNetwork más abajo.
- 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 una búsqueda de DNS directa de sus nombres de host. Apigee Cassandra usa la petición de DNS directa 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 el puerto TCP 7001 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 sobre los números de puerto de Cassandra.

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

GKE On‑Prem

Cuando instales implementaciones de Apigee multirregión entre diferentes redes (por ejemplo, diferentes proveedores de la nube, diferentes redes de VPC, la nube y on-premise, etc.), debes proporcionar conectividad interna entre estas redes independientes para que Cassandra pueda comunicarse entre nodos. Esto se puede conseguir con VPNs o soluciones de conectividad específicas de la nube.
Configura clústeres de Kubernetes en varias regiones con diferentes bloques CIDR.
Asegúrate de que cert-manager esté instalado en cada clúster.
Configura la comunicación entre regiones.
Asegúrate de que todos los pods de Cassandra puedan resolver sus propios nombres de host. Si hostNetwork se define como false, el nombre de host es el nombre del pod de Cassandra. Si hostNetwork se define como true, el nombre de host es el nombre de host del nodo de Kubernetes que ejecuta el pod de Cassandra.
Nota: Para comprobar si la resolución de nombres de host funciona, usa estos comandos.

Si hostNetwork tiene el valor false, usa el comando 1. Si hostNetwork tiene el valor true, usa el comando 2.

Si la resolución de nombres de host funciona, el resultado mostrará una dirección IP. Si no se puede resolver el nombre de host, el resultado incluirá "Host not found" (Host no encontrado).

Comando 1:
```
kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i
```
Comando 2:
```
kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i
```
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 híbrida multirregión de Apigee.
  Para obtener más información sobre la necesidad de hostNetwork, consulta la sección sobre los clústeres en modo aislado y hostNetwork más abajo.
- 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 una búsqueda de DNS directa de sus nombres de host. Apigee Cassandra usa la petición de DNS directa 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 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 ver los números de puerto de Cassandra.

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

AKS

Cuando instales implementaciones de Apigee multirregión entre diferentes redes (por ejemplo, diferentes proveedores de la nube, diferentes redes de VPC, la nube y on-premise, etc.), debes proporcionar conectividad interna entre estas redes independientes para que Cassandra pueda comunicarse entre nodos. Esto se puede conseguir con VPNs o soluciones de conectividad específicas de la nube.
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.
Asegúrate de que cert-manager esté instalado en cada clúster.
Asegúrate de que todos los pods de Cassandra puedan resolver sus propios nombres de host. Si hostNetwork se define como false, el nombre de host es el nombre del pod de Cassandra. Si hostNetwork se define como true, el nombre de host es el nombre de host del nodo de Kubernetes que ejecuta el pod de Cassandra.
Nota: Para comprobar si la resolución de nombres de host funciona, usa estos comandos.

Si hostNetwork tiene el valor false, usa el comando 1. Si hostNetwork tiene el valor true, usa el comando 2.

Si la resolución de nombres de host funciona, el resultado mostrará una dirección IP. Si la resolución de nombre de host falla, el resultado incluirá "Host not found" (Host no encontrado).

Comando 1:
```
kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i
```
Comando 2:
```
kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i
```
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 más información sobre la necesidad de hostNetwork, consulta la sección sobre los clústeres en modo aislado y hostNetwork más abajo.
- 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 una búsqueda de DNS directa de sus nombres de host. Apigee Cassandra usa la petición de DNS directa 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 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 ver los números de puerto de Cassandra.

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

EKS

Cuando instales implementaciones de Apigee multirregión entre diferentes redes (por ejemplo, diferentes proveedores de la nube, diferentes redes de VPC, la nube y on-premise, etc.), debes proporcionar conectividad interna entre estas redes independientes para que Cassandra pueda comunicarse entre nodos. Esto se puede conseguir con VPNs o soluciones de conectividad específicas de la nube.
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.
Asegúrate de que cert-manager esté instalado en cada clúster.
Asegúrate de que todos los pods de Cassandra puedan resolver sus propios nombres de host. Si hostNetwork se define como false, el nombre de host es el nombre del pod de Cassandra. Si hostNetwork se define como true, el nombre de host es el nombre de host del nodo de Kubernetes que ejecuta el pod de Cassandra.
Nota: Para comprobar si la resolución de nombres de host funciona, usa estos comandos.

Si hostNetwork tiene el valor false, usa el comando 1. Si hostNetwork tiene el valor true, usa el comando 2.

Si la resolución de nombres de host funciona, el resultado mostrará una dirección IP. Si la resolución de nombre de host falla, el resultado incluirá "Host not found" (Host no encontrado).

Comando 1:
```
kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i
```
Comando 2:
```
kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i
```
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), 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. Amazon EKS usa el modelo de red totalmente integrado de forma predeterminada.
  Para obtener más información sobre la necesidad de hostNetwork, consulta la sección sobre los clústeres en modo aislado y hostNetwork más abajo.
- 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 una búsqueda de DNS directa de sus nombres de host. Apigee Cassandra usa la petición de DNS directa 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 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 ver los números de puerto de Cassandra.

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

OpenShift

Cuando instales implementaciones de Apigee multirregión entre diferentes redes (por ejemplo, diferentes proveedores de la nube, diferentes redes de VPC, la nube y on-premise, etc.), debes proporcionar conectividad interna entre estas redes independientes para que Cassandra pueda comunicarse entre nodos. Esto se puede conseguir con VPNs o soluciones de conectividad específicas de la nube.
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.
Asegúrate de que cert-manager esté instalado en cada clúster.
Asegúrate de que todos los pods de Cassandra puedan resolver sus propios nombres de host. Si hostNetwork se define como false, el nombre de host es el nombre del pod de Cassandra. Si hostNetwork se define como true, el nombre de host es el nombre de host del nodo de Kubernetes que ejecuta el pod de Cassandra.
Nota: Para comprobar si la resolución de nombres de host funciona, usa estos comandos.

Si hostNetwork tiene el valor false, usa el comando 1. Si hostNetwork tiene el valor true, usa el comando 2.

Si la resolución de nombres de host funciona, el resultado mostrará una dirección IP. Si la resolución de nombre de host falla, el resultado incluirá "Host not found" (Host no encontrado).

Comando 1:
```
kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i
```
Comando 2:
```
kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i
```
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 más información sobre la necesidad de hostNetwork, consulta la sección sobre los clústeres en modo aislado y hostNetwork más abajo.
- 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 una búsqueda de DNS directa de sus nombres de host. Apigee Cassandra usa la petición de DNS directa 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 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 ver los números de puerto de Cassandra.

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

Clústeres en modo Isla y hostNetwork

Hay dos modelos de red principales para los clústeres de Kubernetes: el totalmente integrado (o plano) y el modo aislado. Apigee recomienda usar el modelo de red plana siempre que sea posible, ya que simplifica la conectividad de Cassandra multirregión. Cuando un clúster de Kubernetes se configura en modo aislado, la red de pods se aísla. Los pods no pueden comunicarse directamente con los pods que se ejecutan en otros clústeres mediante la dirección IP del pod. Consulta Implementaciones típicas de modelos de red para obtener más información sobre las diferencias entre estos dos modelos de red y ejemplos de cada uno.

Cuando Apigee Hybrid se ejecuta en dos o más clústeres de Kubernetes con un modelo de red en modo aislado, es necesario habilitar el ajuste hostNetwork para Cassandra mediante la propiedad cassandra.hostNetwork. De forma predeterminada, los pods de Kubernetes se aíslan en espacios de nombres de red individuales, lo que les impide usar la IP del nodo de trabajo de Kubernetes. Cuando hostNetwork se define como true, el pod no se aísla en su propio espacio de nombres de red, sino que usa la dirección IP y el nombre de host del nodo de trabajador de Kubernetes en el que se ha programado el pod. De esta forma, Cassandra puede usar de forma nativa la IP del nodo de trabajo de Kubernetes como su IP, lo que permite que Cassandra establezca una malla completa entre todos los pods de Cassandra de varios clústeres que se ejecutan en modo aislado.

Resolución de nombres de host de Cassandra

Aunque un pod de Cassandra no resuelve otros pods de Cassandra por nombre de host, al iniciarse, Cassandra comprueba que su propio nombre de host se pueda resolver mediante DNS. Como el nombre de host del pod es el mismo que el nombre de host del nodo de trabajo de Kubernetes cuando hostNetwork se define como true, el nombre de host del nodo de trabajo debe poder resolverse en una dirección IP a través del servicio DNS del clúster. Si no se puede resolver el nombre de host del nodo de trabajo de Kubernetes, el pod de Cassandra no se iniciará por completo. Por lo tanto, es importante que los nombres de host de los nodos de trabajo de Kubernetes se puedan resolver desde los pods del clúster al definir hostNetwork como true.

Configurar Apigee Hybrid para varias regiones

En esta sección se describe cómo 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í.

En la primera región creada, obtén los pods de tu espacio de nombres de apigee:
```
kubectl get pods -o wide -n APIGEE_NAMESPACE
```
Identifica la dirección del host de inicialización de multirregión de Cassandra en esta región. Por ejemplo, 10.0.0.11.
Prepara el archivo overrides.yaml de la segunda región y añade la dirección IP del host de inicialización de la siguiente manera:
```
cassandra:
  multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
  datacenter: "DATACENTER_NAME"
  rack: "RACK_NAME"
  hostNetwork: false
  clusterName: CLUSTER_NAME
```
Haz los cambios siguientes:
- SEED_HOST_IP_ADDRESS con la dirección IP del host de la semilla, por ejemplo, 10.0.0.11.
- DATACENTER_NAME con el nombre del centro de datos (por ejemplo, dc-2).
- RACK_NAME con el nombre del estante, por ejemplo, ra-1.
- CLUSTER_NAME por el nombre de tu clúster de Cassandra. De forma predeterminada, el valor es apigeecluster. Si usas otro nombre de clúster, debes especificar un valor para cassandra.clusterName. Puede elegir el valor que quiera, pero debe ser el mismo en todas las regiones.

Configurar la segunda región

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

Instala cert-manager en la segunda región.
Copia el certificado del clúster actual al nuevo. Cassandra y otros componentes híbridos usan la nueva raíz de CA para mTLS. Por lo tanto, es fundamental que los certificados sean coherentes en todo el clúster.
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 APIGEE_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 espacio de nombres del archivo si usas otro espacio de nombres 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
```
Sigue los pasos para instalar los CRDs de Apigee hybrid en la nueva región.

Ahora, usa los charts de Helm para instalar Apigee hybrid en la nueva región con los siguientes comandos de chart de Helm (como se hizo en la región 1):

Nota: Puedes usar los mismos CRDs para mantener la coherencia usando la misma carpeta en la que has descargado los gráficos. También puedes mantener tu archivo de anulaciones único entre las regiones 1 y 2 asignándole un nombre único, como overrides-region_name.yaml, etc.

helm upgrade operator apigee-operator \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade datastore apigee-datastore \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade telemetry apigee-telemetry \
  --install \
  --namespace APIGEE_NAMESPACE> \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade redis apigee-redis \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade ingress-manager apigee-ingress-manager \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade ORG_NAME apigee-org \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env mentioned on the overrides
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=ENV_RELEASE_NAME \
  -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env group mentioned on the overrides
helm upgrade apigee-virtualhost-ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=ENV_GROUP_RELEASE_NAME \
  -f overrides-DATACENTER_NAME.yaml

ENV_RELEASE_NAME y ENV_GROUP_RELEASE_NAME son nombres que se usan para hacer un seguimiento de la instalación y las actualizaciones de los gráficos apigee-env y apigee-virtualhost. Los nombres de las versiones de Helm deben ser únicos en tu instalación de Apigee hybrid. Si el nombre de tu entorno es único, puede ser el mismo que ENV_NAME. Sin embargo, si el entorno y el grupo de entornos tienen el mismo nombre, asegúrate de introducir un nombre de lanzamiento de Helm único para cada uno. Por ejemplo, si ambos se llaman dev, puedes usar algo como dev-env-release y dev-envgroup-release.

Puedes ver una lista de nombres de versiones con el comando helm list:

helm list -n APIGEE_NAMESPACE

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_NAMESPACE  \
-- nodetool -u APIGEE_JMX_USER -pw APIGEE_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_NAMESPACE -o json | jq ".items[].metadata.name"
```
  Por ejemplo:
```
Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -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 se obtiene del comando kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" del paso anterior. Por ejemplo, rg-hybrid-b7d3b9c
  - SOURCE_REGION es la región de origen, el valor del centro de datos de la sección de Cassandra de overrides.yaml de la región de origen.
  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
```

Verifica el estado de la recompilación con el siguiente comando.

kubectl -n APIGEE_NAMESPACE 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
}

Una vez que se haya completado y verificado la replicación de datos, actualiza los hosts de inicialización:
1. Quita multiRegionSeedHost: 10.0.0.11 de overrides-DATACENTER_NAME.yaml.
2. Vuelve a aplicar el cambio para actualizar el CR de almacén de datos de Apigee:
```
helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
```

Verifica los procesos de recompilación en los registros. Además, comprueba el tamaño de los datos con el comando nodetool status.

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

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

Nota: APIGEE_JMX_USER y APIGEE_JMX_PASSWORD suelen definirse en las variables de entorno $APIGEE_JMX_USER y $APIGEE_JMX_PASSWORD.

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

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_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status


Datacenter: dc-1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

GKE On‑Prem

Configurar el host de seed multirregional

En la primera región creada, obtén los pods de tu espacio de nombres de apigee:
```
kubectl get pods -o wide -n APIGEE_NAMESPACE
```
Identifica la dirección del host de inicialización de multirregión de Cassandra en esta región. Por ejemplo, 10.0.0.11.
Prepara el archivo overrides.yaml de la segunda región y añade la dirección IP del host de inicialización de la siguiente manera:
```
cassandra:
  multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
  datacenter: "DATACENTER_NAME"
  rack: "RACK_NAME"
  hostNetwork: false
  clusterName: CLUSTER_NAME
```
Haz los cambios siguientes:
- SEED_HOST_IP_ADDRESS con la dirección IP del host de la semilla, por ejemplo, 10.0.0.11.
- DATACENTER_NAME con el nombre del centro de datos (por ejemplo, dc-2).
- RACK_NAME con el nombre del estante, por ejemplo, ra-1.
- CLUSTER_NAME por el nombre de tu clúster de Cassandra. De forma predeterminada, el valor es apigeecluster. Si usas otro nombre de clúster, debes especificar un valor para cassandra.clusterName. Puede elegir el valor que quiera, pero debe ser el mismo en todas las regiones.

Configurar la segunda región

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

Instala cert-manager en la segunda región.
Copia el certificado del clúster actual al nuevo. Cassandra y otros componentes híbridos usan la nueva raíz de CA para mTLS. Por lo tanto, es fundamental que los certificados sean coherentes en todo el clúster.
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 APIGEE_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 espacio de nombres del archivo si usas otro espacio de nombres 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
```
Sigue los pasos para instalar los CRDs de Apigee hybrid en la nueva región.

Ahora, usa los charts de Helm para instalar Apigee hybrid en la nueva región con los siguientes comandos de chart de Helm (como se hizo en la región 1):

helm upgrade operator apigee-operator \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade datastore apigee-datastore \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade telemetry apigee-telemetry \
  --install \
  --namespace APIGEE_NAMESPACE> \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade redis apigee-redis \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade ingress-manager apigee-ingress-manager \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade ORG_NAME apigee-org \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env mentioned on the overrides
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=ENV_RELEASE_NAME \
  -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env group mentioned on the overrides
helm upgrade apigee-virtualhost-ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=ENV_GROUP_RELEASE_NAME \
  -f overrides-DATACENTER_NAME.yaml

Puedes ver una lista de nombres de versiones con el comando helm list:

helm list -n APIGEE_NAMESPACE

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_NAMESPACE  \
-- nodetool -u APIGEE_JMX_USER -pw APIGEE_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_NAMESPACE -o json | jq ".items[].metadata.name"
```
  Por ejemplo:
```
Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -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 se obtiene del comando kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" del paso anterior. Por ejemplo, rg-hybrid-b7d3b9c
  - SOURCE_REGION es la región de origen, el valor del centro de datos de la sección de Cassandra de overrides.yaml de la región de origen.
  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
```

Verifica el estado de la recompilación con el siguiente comando.

kubectl -n APIGEE_NAMESPACE 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
}

Una vez que se haya completado y verificado la replicación de datos, actualiza los hosts de inicialización:
1. Quita multiRegionSeedHost: 10.0.0.11 de overrides-DATACENTER_NAME.yaml.
2. Vuelve a aplicar el cambio para actualizar el CR de almacén de datos de Apigee:
```
helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
```

Verifica los procesos de recompilación en los registros. Además, comprueba el tamaño de los datos con el comando nodetool status.

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

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

Nota: APIGEE_JMX_USER y APIGEE_JMX_PASSWORD suelen definirse en las variables de entorno $APIGEE_JMX_USER y $APIGEE_JMX_PASSWORD.

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

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_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status


Datacenter: dc-1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

AKS

Crea 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 entre 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 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 los números de puerto de Cassandra.

Configurar el host de seed multirregional

En la primera región creada, obtén los pods de tu espacio de nombres de apigee:
```
kubectl get pods -o wide -n APIGEE_NAMESPACE
```
Identifica la dirección del host de inicialización de multirregión de Cassandra en esta región. Por ejemplo, 10.0.0.11.
Prepara el archivo overrides.yaml de la segunda región y añade la dirección IP del host de inicialización de la siguiente manera:
```
cassandra:
  multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
  datacenter: "DATACENTER_NAME"
  rack: "RACK_NAME"
  hostNetwork: false
  clusterName: CLUSTER_NAME
```
Haz los cambios siguientes:
- SEED_HOST_IP_ADDRESS con la dirección IP del host de la semilla, por ejemplo, 10.0.0.11.
- DATACENTER_NAME con el nombre del centro de datos (por ejemplo, dc-2).
- RACK_NAME con el nombre del estante, por ejemplo, ra-1.
- CLUSTER_NAME por el nombre de tu clúster de Cassandra. De forma predeterminada, el valor es apigeecluster. Si usas otro nombre de clúster, debes especificar un valor para cassandra.clusterName. Puede elegir el valor que quiera, pero debe ser el mismo en todas las regiones.

Configurar la segunda región

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

Instala cert-manager en la segunda región.
Copia el certificado del clúster actual al nuevo. Cassandra y otros componentes híbridos usan la nueva raíz de CA para mTLS. Por lo tanto, es fundamental que los certificados sean coherentes en todo el clúster.
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 APIGEE_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 espacio de nombres del archivo si usas otro espacio de nombres 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
```
Sigue los pasos para instalar los CRDs de Apigee hybrid en la nueva región.

Ahora, usa los charts de Helm para instalar Apigee hybrid en la nueva región con los siguientes comandos de chart de Helm (como se hizo en la región 1):

helm upgrade operator apigee-operator \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade datastore apigee-datastore \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade telemetry apigee-telemetry \
  --install \
  --namespace APIGEE_NAMESPACE> \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade redis apigee-redis \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade ingress-manager apigee-ingress-manager \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade ORG_NAME apigee-org \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env mentioned on the overrides
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=ENV_RELEASE_NAME \
  -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env group mentioned on the overrides
helm upgrade apigee-virtualhost-ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=ENV_GROUP_RELEASE_NAME \
  -f overrides-DATACENTER_NAME.yaml

Puedes ver una lista de nombres de versiones con el comando helm list:

helm list -n APIGEE_NAMESPACE

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_NAMESPACE  \
-- nodetool -u APIGEE_JMX_USER -pw APIGEE_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_NAMESPACE -o json | jq ".items[].metadata.name"
```
  Por ejemplo:
```
Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -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 se obtiene del comando kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" del paso anterior. Por ejemplo, rg-hybrid-b7d3b9c
  - SOURCE_REGION es la región de origen, el valor del centro de datos de la sección de Cassandra de overrides.yaml de la región de origen.
  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
```

Verifica el estado de la recompilación con el siguiente comando.

kubectl -n APIGEE_NAMESPACE 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
}

Una vez que se haya completado y verificado la replicación de datos, actualiza los hosts de inicialización:
1. Quita multiRegionSeedHost: 10.0.0.11 de overrides-DATACENTER_NAME.yaml.
2. Vuelve a aplicar el cambio para actualizar el CR de almacén de datos de Apigee:
```
helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
```

Verifica los procesos de recompilación en los registros. Además, comprueba el tamaño de los datos con el comando nodetool status.

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

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

Nota: APIGEE_JMX_USER y APIGEE_JMX_PASSWORD suelen definirse en las variables de entorno $APIGEE_JMX_USER y $APIGEE_JMX_PASSWORD.

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

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_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status


Datacenter: dc-1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

EKS

Crea una red virtual en cada región

Sigue las recomendaciones de AWS para establecer la comunicación entre regiones, tal como se describe en el artículo ¿Qué es el peering de VPC?. El término de AWS para usar diferentes regiones es emparejamiento entre VPCs de diferentes regiones.

Crear clústeres multirregionales

Configurar el host de seed multirregional

En la primera región creada, obtén los pods de tu espacio de nombres de apigee:
```
kubectl get pods -o wide -n APIGEE_NAMESPACE
```
Identifica la dirección del host de inicialización de multirregión de Cassandra en esta región. Por ejemplo, 10.0.0.11.
Prepara el archivo overrides.yaml de la segunda región y añade la dirección IP del host de inicialización de la siguiente manera:
```
cassandra:
  multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
  datacenter: "DATACENTER_NAME"
  rack: "RACK_NAME"
  hostNetwork: false
  clusterName: CLUSTER_NAME
```
Haz los cambios siguientes:
- SEED_HOST_IP_ADDRESS con la dirección IP del host de la semilla, por ejemplo, 10.0.0.11.
- DATACENTER_NAME con el nombre del centro de datos (por ejemplo, dc-2).
- RACK_NAME con el nombre del estante, por ejemplo, ra-1.
- CLUSTER_NAME por el nombre de tu clúster de Cassandra. De forma predeterminada, el valor es apigeecluster. Si usas otro nombre de clúster, debes especificar un valor para cassandra.clusterName. Puede elegir el valor que quiera, pero debe ser el mismo en todas las regiones.

Configurar la segunda región

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

Instala cert-manager en la segunda región.
Copia el certificado del clúster actual al nuevo. Cassandra y otros componentes híbridos usan la nueva raíz de CA para mTLS. Por lo tanto, es fundamental que los certificados sean coherentes en todo el clúster.
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 APIGEE_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 espacio de nombres del archivo si usas otro espacio de nombres 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
```
Sigue los pasos para instalar los CRDs de Apigee hybrid en la nueva región.

Ahora, usa los charts de Helm para instalar Apigee hybrid en la nueva región con los siguientes comandos de chart de Helm (como se hizo en la región 1):

helm upgrade operator apigee-operator \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade datastore apigee-datastore \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade telemetry apigee-telemetry \
  --install \
  --namespace APIGEE_NAMESPACE> \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade redis apigee-redis \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade ingress-manager apigee-ingress-manager \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade ORG_NAME apigee-org \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env mentioned on the overrides
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=ENV_RELEASE_NAME \
  -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env group mentioned on the overrides
helm upgrade apigee-virtualhost-ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=ENV_GROUP_RELEASE_NAME \
  -f overrides-DATACENTER_NAME.yaml

Puedes ver una lista de nombres de versiones con el comando helm list:

helm list -n APIGEE_NAMESPACE

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_NAMESPACE  \
-- nodetool -u APIGEE_JMX_USER -pw APIGEE_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_NAMESPACE -o json | jq ".items[].metadata.name"
```
  Por ejemplo:
```
Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -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 se obtiene del comando kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" del paso anterior. Por ejemplo, rg-hybrid-b7d3b9c
  - SOURCE_REGION es la región de origen, el valor del centro de datos de la sección de Cassandra de overrides.yaml de la región de origen.
  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
```

Verifica el estado de la recompilación con el siguiente comando.

kubectl -n APIGEE_NAMESPACE 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
}

Una vez que se haya completado y verificado la replicación de datos, actualiza los hosts de inicialización:
1. Quita multiRegionSeedHost: 10.0.0.11 de overrides-DATACENTER_NAME.yaml.
2. Vuelve a aplicar el cambio para actualizar el CR de almacén de datos de Apigee:
```
helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
```

Verifica los procesos de recompilación en los registros. Además, comprueba el tamaño de los datos con el comando nodetool status.

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

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

Nota: APIGEE_JMX_USER y APIGEE_JMX_PASSWORD suelen definirse en las variables de entorno $APIGEE_JMX_USER y $APIGEE_JMX_PASSWORD.

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

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_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status


Datacenter: dc-1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

OpenShift

Configurar el host de seed multirregional

En la primera región creada, obtén los pods de tu espacio de nombres de apigee:
```
kubectl get pods -o wide -n APIGEE_NAMESPACE
```
Identifica la dirección del host de inicialización de multirregión de Cassandra en esta región. Por ejemplo, 10.0.0.11.
Prepara el archivo overrides.yaml de la segunda región y añade la dirección IP del host de inicialización de la siguiente manera:
```
cassandra:
  multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
  datacenter: "DATACENTER_NAME"
  rack: "RACK_NAME"
  hostNetwork: false
  clusterName: CLUSTER_NAME
```
Haz los cambios siguientes:
- SEED_HOST_IP_ADDRESS con la dirección IP del host de la semilla, por ejemplo, 10.0.0.11.
- DATACENTER_NAME con el nombre del centro de datos (por ejemplo, dc-2).
- RACK_NAME con el nombre del estante, por ejemplo, ra-1.
- CLUSTER_NAME por el nombre de tu clúster de Cassandra. De forma predeterminada, el valor es apigeecluster. Si usas otro nombre de clúster, debes especificar un valor para cassandra.clusterName. Puede elegir el valor que quiera, pero debe ser el mismo en todas las regiones.

Configurar la segunda región

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

Instala cert-manager en la segunda región.
Copia el certificado del clúster actual al nuevo. Cassandra y otros componentes híbridos usan la nueva raíz de CA para mTLS. Por lo tanto, es fundamental que los certificados sean coherentes en todo el clúster.
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 APIGEE_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 espacio de nombres del archivo si usas otro espacio de nombres 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
```
Sigue los pasos para instalar los CRDs de Apigee hybrid en la nueva región.

Ahora, usa los charts de Helm para instalar Apigee hybrid en la nueva región con los siguientes comandos de chart de Helm (como se hizo en la región 1):

helm upgrade operator apigee-operator \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade datastore apigee-datastore \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade telemetry apigee-telemetry \
  --install \
  --namespace APIGEE_NAMESPACE> \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade redis apigee-redis \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade ingress-manager apigee-ingress-manager \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
helm upgrade ORG_NAME apigee-org \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env mentioned on the overrides
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=ENV_RELEASE_NAME \
  -f overrides-DATACENTER_NAME.yaml
# repeat the below command for each env group mentioned on the overrides
helm upgrade apigee-virtualhost-ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=ENV_GROUP_RELEASE_NAME \
  -f overrides-DATACENTER_NAME.yaml

Puedes ver una lista de nombres de versiones con el comando helm list:

helm list -n APIGEE_NAMESPACE

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_NAMESPACE  \
-- nodetool -u APIGEE_JMX_USER -pw APIGEE_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_NAMESPACE -o json | jq ".items[].metadata.name"
```
  Por ejemplo:
```
Ex: kubectl get apigeeorg -n APIGEE_NAMESPACE -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 se obtiene del comando kubectl get apigeeorg -n APIGEE_NAMESPACE -o json | jq ".items[].metadata.name" del paso anterior. Por ejemplo, rg-hybrid-b7d3b9c
  - SOURCE_REGION es la región de origen, el valor del centro de datos de la sección de Cassandra de overrides.yaml de la región de origen.
  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
```

Verifica el estado de la recompilación con el siguiente comando.

kubectl -n APIGEE_NAMESPACE 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
}

Una vez que se haya completado y verificado la replicación de datos, actualiza los hosts de inicialización:
1. Quita multiRegionSeedHost: 10.0.0.11 de overrides-DATACENTER_NAME.yaml.
2. Vuelve a aplicar el cambio para actualizar el CR de almacén de datos de Apigee:
```
helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides-DATACENTER_NAME.yaml
```

Verifica los procesos de recompilación en los registros. Además, comprueba el tamaño de los datos con el comando nodetool status.

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

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

Nota: APIGEE_JMX_USER y APIGEE_JMX_PASSWORD suelen definirse en las variables de entorno $APIGEE_JMX_USER y $APIGEE_JMX_PASSWORD.

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

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_NAMESPACE  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status


Datacenter: dc-1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

Solución de problemas

Consulta Error de replicación de datos de Cassandra.

Despliegue multirregional Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Requisitos previos

GKE

GKE On‑Prem

AKS

EKS

OpenShift

Clústeres en modo Isla y hostNetwork

Resolución de nombres de host de Cassandra

Configurar Apigee Hybrid para varias regiones

GKE

Configurar el host de seed multirregional

Configurar la segunda región

Comprobar el estado del clúster de Cassandra

GKE On‑Prem

Configurar el host de seed multirregional

Configurar la segunda región

Comprobar el estado del clúster de Cassandra

AKS

Crea una red virtual en cada región

Crear clústeres multirregionales

Configurar el host de seed multirregional

Configurar la segunda región

Comprobar el estado del clúster de Cassandra

EKS

Crea una red virtual en cada región

Crear clústeres multirregionales

Configurar el host de seed multirregional

Configurar la segunda región

Comprobar el estado del clúster de Cassandra

OpenShift

Configurar el host de seed multirregional

Configurar la segunda región

Comprobar el estado del clúster de Cassandra

Solución de problemas

Despliegue multirregional