En esta sección, se explica cómo configurar la copia de seguridad y recuperación de datos para el anillo de base de datos de Apache Cassandra instalado en el plano del entorno de ejecución Apigee Hybrid. Consulta también Almacén de datos de Cassandra.
¿Por qué son importantes las copias de seguridad de Cassandra?
Las copias de seguridad son una medida importante de protección contra situaciones de desastre. Cada copia de seguridad es una instantánea coherente de los datos actuales de Cassandra que existían en el momento en que se creó la copia de seguridad. Esto incluye los datos de Cassandra junto con el esquema o los metadatos dentro del clúster de Cassandra. Las copias de seguridad permiten a los usuarios restablecer su instancia de Apigee Hybrid a un estado adecuado conocido, un paso fundamental para volver a conectar una instancia de Hybrid en caso de que ocurra un desastre. Según el tamaño de la instancia de Hybrid, puede haber uno o varios archivos de copia de seguridad para un solo conjunto de copia de seguridad. Por ejemplo, si la instancia de Hybrid tiene tres nodos de Cassandra, el conjunto de copia de seguridad contiene tres archivos de copia de seguridad. Si la instancia de Hybrid tiene treinta nodos de Cassandra, el conjunto de copia de seguridad contiene treinta archivos de copia de seguridad. Esto significa que el tiempo para restablecer una instancia de Hybrid desde una copia de seguridad depende de la cantidad de archivos de copia de seguridad de un conjunto de copia de seguridad que se deben restablecer.
Qué necesitas saber sobre las copias de seguridad de Cassandra
Cassandra es una base de datos replicada que está configurada para tener al menos 3 copias de tus datos en cada región o centro de datos. Cassandra usa la replicación de transmisión y las reparaciones de lectura para mantener las réplicas de datos en cada región o el centro de datos en un momento determinado.
En Hybrid, las copias de seguridad de Cassandra no están habilitadas de forma predeterminada. Sin embargo, se recomienda habilitar las copias de seguridad de Cassandra en caso de que los datos se pierdan debido a una falla catastrófica. Las copias de seguridad de Cassandra están diseñadas para su uso en casos de recuperación ante desastres y no para la pérdida de datos causada por la eliminación accidental.
Las copias de seguridad se crean según el programa que se establece en el archivo overrides.yaml. Consulta la sección Programa copias de seguridad de Cassandra para obtener instrucciones sobre cómo programar copias de seguridad. Una vez que se aplicó una programación de copia de seguridad al clúster de Hybrid, se ejecuta de forma periódica un trabajo de copia de seguridad de Kubernetes según la programación. El trabajo activa una secuencia de comandos de copia de seguridad en cada nodo de Cassandra del clúster de Hybrid que recopila todos los datos del nodo, crea un archivo de datos y envía el archivo al bucket de Google Cloud Storage especificado en la configuración de copia de seguridad de Cassandra en tu archivo overrides.yaml.
¿Qué elementos tiene una copia de seguridad?
La configuración de copia de seguridad descrita en este tema crea una copia de seguridad de las siguientes entidades:
- Esquema de Cassandra que incluye el esquema del usuario (definiciones del espacio de claves de Apigee)
- Información del token de partición de Cassandra por nodo
- Una instantánea de los datos de Cassandra
¿Dónde se almacenan los datos de la copia de seguridad?
Los datos de copia de seguridad se almacenan en un bucket de Google Cloud Storage que debes crear. En este tema, se describe la creación y configuración de buckets.
Programa las copias de seguridad de Cassandra
Las copias de seguridad se programan como trabajos cron
cron en el plano del entorno de ejecución. Para programar copias de seguridad de Cassandra, sigue estos pasos:
- Ejecuta el siguiente comando de
create-service-account
para crear una cuenta de servicio de Google Cloud con la función estándarroles/storage.objectAdmin
. Esta función de la cuenta de servicio te permite escribir datos de copia de seguridad en Cloud Storage. Ejecuta el siguiente comando en el directorio raíz de instalación híbrida:../tools/create-service-account --env prod \ --profile apigee-cassandra \ --name CASSANDRA_BACKUP_SA_NAME \ --dir OUTPUT_DIR
Aquí:
- CASSANDRA_BACKUP_SA_NAME es el nombre de la cuenta de servicio.
- OUTPUT_DIR es el directorio donde la herramienta monstrará el archivo
.json
de la cuenta de servicio.
Para obtener más información sobre las cuentas de servicio de Google Cloud, consulta Crea y administra cuentas de servicio../tools/create-service-account --env prod \ --profile apigee-cassandra \ --name my-cassandra-backup-sa --dir ./service-accounts
- El comando
create-service-account
guarda un archivo JSON que contiene la clave privada de la cuenta de servicio. El archivo se guarda en el mismo directorio en el que se ejecuta el comando. Necesitarás la ruta a este archivo en los siguientes pasos. - Crea depósitos de almacenamiento. Especifica una política de retención de datos razonable para el bucket. Apigee recomienda una política de retención de datos de 15 días.
- Abre el archivo
overrides.yaml
. - Agrega las siguientes propiedades de
cassandra.backup
para habilitar la copia de seguridad. No quites ninguna de las propiedades que ya están configuradas.Parámetros
cassandra: ... backup: enabled: true serviceAccountPath: SA_JSON_FILE_PATH dbStorageBucket: CLOUD_STORAGE_BUCKET_PATH schedule: BACKUP_SCHEDULE_CODE ...
Ejemplo
... cassandra: storage: type: gcepd capacity: 50Gi gcepd: replicationType: regional-pd sslRootCAPath: "/Users/myhome/ssh/cassandra.crt" sslCertPath: "/Users/myhome/ssh/cassandra.crt" sslKeyPath: "/Users/myhome/ssh/cassandra.key" auth: default: password: "abc123" admin: password: "abc234" ddl: password: "abc345" dml: password: "abc456" nodeSelector: key: cloud.google.com/gke-nodepool value: apigee-data backup: enabled: true serviceAccountPath: "/Users/myhome/.ssh/my-cassandra-backup-sa.json" dbStorageBucket: "gs://myname-cassandra-backup" schedule: "45 23 * * 6" ...
Aquí:
- Aplica los cambios de configuración al clúster nuevo. Por ejemplo:
./apigeectl apply -f overrides.yaml
- Verifica el trabajo de copia de seguridad. Por ejemplo:
kubectl get cronjob -n apigee
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE apigee-cassandra-backup 33 * * * * False 0 <none> 94s
Propiedad | Descripción |
---|---|
backup:enabled |
La copia de seguridad está inhabilitada de forma predeterminada. Debes establecer esta propiedad en true . |
backup:serviceAccountPath |
SA_JSON_FILE_PATH La ruta de tu sistema de archivos al archivo JSON de la cuenta de servicio que se descargó cuando ejecutaste |
backup:dbStorageBucket |
CLOUD_STORAGE_BUCKET_PATH Ruta de acceso del bucket de Cloud Storage con este formato: |
backup:schedule |
BACKUP_SCHEDULE_CODE El momento en el que se inicia la copia de seguridad, especificado en sintaxis de crontab estándar. Predeterminada: |
Restablecer las copias de seguridad
Usa copias de seguridad para restablecer la infraestructura de Apigee desde cero en caso de fallas catastróficas, como la pérdida irrecuperable de todos los datos en la instancia de Apigee Hybrid debido a un desastre. Ten en cuenta que, si tienes una implementación multirregión, la recuperación ante una falla de una sola región debe utilizar el retiro de servicio para limpiar la región afectada y, luego, usar la expansión de DN en la región afectada. Las implementaciones de Apigee Cassandra y la arquitectura operativa se encargan de la redundancia y la tolerancia a errores para una sola región. Como se recomienda implementar Apigee Hybrid en una configuración multirregional para casos de uso de producción, una falla de región se puede recuperar de una de las otras regiones live con los procedimientos documentados de retiro de servicio y expansión de la región en lugar de recuperarse de una copia de seguridad.
No uses copias de seguridad por las siguientes razones:
- Fallas en los nodos de Cassandra
- Eliminación accidental de datos como aplicaciones, desarrolladores y api_credentials.
- Una o más regiones fallan en una implementación multirregional.
Consideraciones para tener en cuenta cuando restablezcas:
- Tiempo de inactividad: se producirá tiempo de inactividad durante el restablecimiento.
- Pérdida de datos: se producirá una pérdida de datos entre la última copia de seguridad válida y el momento en que se completa el restablecimiento.
- Tiempo de restablecimiento: el tiempo de restablecimiento depende del tamaño de los datos y el clúster.
- Datos de selección: no puedes seleccionar solo datos específicos para restablecer. El restablecimiento restablece toda la copia de seguridad que seleccionaste.
El restablecimiento toma tus datos de la ubicación de la copia de seguridad y los restablece en un clúster de Cassandra nuevo con la misma cantidad de nodos. No se toman datos del clúster anterior de Cassandra.
Las siguientes instrucciones de restablecimiento se aplican a implementaciones de una sola región que usan Google Cloud Storage para copias de seguridad. Para otras implementaciones, consulta lo siguiente:
- Para implementaciones de una sola región que no usan Google Cloud Storage para copias de seguridad, consulta Copia de seguridad y recuperación sin Google Cloud.
- Para implementaciones multirregionales, consulta Implementación multirregional en GKE y GKE On-Prem.
Para restablecer copias de seguridad de Cassandra, haz lo siguiente:
- Crea un clúster de Kubernetes nuevo con un espacio de nombres nuevo en el que se restablezca la implementación del entorno de ejecución híbrido. No puedes usar el mismo clúster o espacio de nombres que usaste para la instalación híbrida original.
- En el directorio raíz de la instalación híbrida, crea un archivo
overrides-restore.yaml
nuevo. - Copia la configuración completa del archivo
overrides.yaml
original al archivooverrides-restore.yaml
nuevo. Por ejemplo:cp ./overrides.yaml ./overrides-restore.yaml
- En el nuevo
overrides-restore.yaml
, agrega los elementosnamespace
yrestore
y asegúrate de que las credenciales de autenticación TLS en las propiedadescassandra
sean correctas.Parámetros
namespace: YOUR_RESTORE_NAMESPACE cassandra: ... sslRootCAPath: PATH_TO_ROOT_CA_FILE sslCertPath: PATH_TO_SSL_CERT_FILE sslKeyPath: PATH_TO_SSL_KEY_FILE ... restore: enabled: true snapshotTimestamp: TIMESTAMP serviceAccountPath: SA_JSON_FILE_PATH dbStorageBucket: CLOUD_STORAGE_BUCKET_PATH image: pullPolicy: Always ...
Ejemplo
... namespace: cassandra-restore cassandra: storage: type: gcepd capacity: 50Gi gcepd: replicationType: regional-pd sslRootCAPath: "/Users/myhome/ssh/cassandra.crt" sslCertPath: "/Users/myhome/ssh/cassandra.crt" sslKeyPath: "/Users/myhome/ssh/cassandra.key" auth: default: password: "abc123" admin: password: "abc234" ddl: password: "abc345" dml: password: "abc456" nodeSelector: key: cloud.google.com/gke-nodepool value: apigee-data restore: enabled: true snapshotTimestamp: "20210203213003" serviceAccountPath: "/Users/myhome/.ssh/my_cassandra_backup.json" dbStorageBucket: "gs://myname-cassandra-backup" image: pullPolicy: Always ...
Aquí:
Propiedad Descripción sslRootCAPath
sslCertPath
sslKeyPath
PATH_TO_ROOT_CA_FILE
PATH_TO_SSL_CERT_FILE
PATH_TO_SSL_KEY_FILEUsa las mismas credenciales de autenticación TLS que usaste para crear la base de datos original de Cassandra.
namespace
YOUR_RESTORE_NAMESPACE
El nombre del espacio de nombres nuevo que creaste en el paso 1 para el clúster de Cassandra nuevo. No uses el mismo espacio de nombres que usaste para tu clúster original.
restore:enabled
La opción para restablecer está inhabilitada de forma predeterminada. Debes establecer esta propiedad en true
.restore:snapshotTimestamp
TIMESTAMP
La marca de tiempo de la instantánea de la copia de seguridad que se restablecerá. Para comprobar qué marcas de tiempo se pueden usar, ve a
dbStorageBucket
y consulta los archivos que están presentes en el bucket. Cada nombre de archivo contiene un valor de marca de tiempo como el siguiente:backup_20210203213003_apigee-cassandra-default-0.tgz
En el ejemplo anterior, 20210203213003 es el valor
snapshotTimestamp
que usarías si quisieras restablecer las copias de seguridad creadas en ese momento.restore:serviceAccountPath
SA_JSON_FILE_PATH
La ruta de acceso del sistema de archivos a la cuenta de servicio que creaste para la copia de seguridad.
restore:dbStorageBucket
CLOUD_STORAGE_BUCKET_PATH
La ruta del bucket de Cloud Storage en la que se almacenan tus datos de copia de seguridad en el siguiente formato:
gs://BUCKET_NAME
gs://
es obligatorio. - Cambia la etiqueta
app
en todos los nodos de Cassandra en el espacio de nombres antiguo mediante la ejecución del siguiente comando:kubectl label pods --overwrite --namespace=OLD_NAMESPACE -l app=apigee-cassandra app=apigee-cassandra-old
- Crea una nueva implementación de entorno de ejecución híbrido. Esto creará un nuevo clúster de Cassandra y comenzará a restablecer los datos de copia de seguridad en el clúster:
./apigeectl init -f ../overrides-restore.yaml
./apigeectl apply -f ../overrides-restore.yaml
-
Una vez que se completa el restablecimiento, se debe cambiar el tráfico para usar el clúster de Cassandra en el espacio de nombres nuevo. Ejecuta los siguientes comandos para cambiar el tráfico:
kubectl get rs -n OLD_NAMESPACE # look for the 'apigee-connect' replicaset
kubectl patch rs -n OLD_NAMESPACE APIGEE_CONNECT_RS_NAME -p '{"spec":{"replicas" : 0}}'
- Una vez que finalice el cambio del tráfico, puedes volver a configurar las copias de seguridad en el clúster restablecido si quitas la configuración
restore
y agregas la configuraciónbackup
al archivooverrides-restore.yaml
. Reemplaza YOUR_RESTORE_NAMESPACE por el nombre del espacio de nombres nuevo que creaste en el paso 1.namespace: YOUR_RESTORE_NAMESPACE cassandra: ... backup: enabled: true serviceAccountPath: SA_JSON_FILE_PATH dbStorageBucket: CLOUD_STORAGE_BUCKET_PATH schedule: BACKUP_SCHEDULE_CODE ...
Luego, aplica la configuración
backup
con el siguiente comando:./apigeectl apply -f ../overrides-restore.yaml
Visualiza los registros de restablecimiento
Puedes verificar los registros de trabajos de restablecimiento y usar grep
para buscar error
con el fin de asegurarte de que el registro de restablecimiento no tenga errores.
Verifica si se completó el restablecimiento
Usa el siguiente comando para comprobar si la operación de restablecimiento se completó:
kubectl get pods
El resultado es similar al siguiente:
NAME READY STATUS RESTARTS AGE apigee-cassandra-default-0 1/1 Running 0 1h apigee-cassandra-default-1 1/1 Running 0 1h apigee-cassandra-default-2 1/1 Running 0 59m apigee-cassandra-restore-b4lgf 0/1 Completed 0 51m
Visualiza los registros de restablecimiento
Usa el siguiente comando para ver los registros de restablecimiento:
kubectl logs -f apigee-cassandra-restore-b4lgf
El resultado es similar al siguiente:
Restore Logs: Activated service account credentials for: [apigee-cassandra-backup-svc@gce-myusername.iam.gserviceaccount.com] to download file gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1/backup_20190405011309_schema.tgz INFO: download successfully extracted the backup files from gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1 finished downloading schema.cql to create schema from 10.32.0.28 Warnings : dclocal_read_repair_chance table option has been deprecated and will be removed in version 4.0 dclocal_read_repair_chance table option has been deprecated and will be removed in version 4.0 Warnings : dclocal_read_repair_chance table option has been deprecated and will be removed in version 4.0 dclocal_read_repair_chance table option has been deprecated and will be removed in version 4.0 INFO: the schema has been restored starting apigee-cassandra-default-0 in default starting apigee-cassandra-default-1 in default starting apigee-cassandra-default-2 in default 84 95 106 waiting on waiting nodes $pid to finish 84 Activated service account credentials for: [apigee-cassandra-backup-svc@gce-myusername.iam.gserviceaccount.com] Activated service account credentials for: [apigee-cassandra-backup-svc@gce-myusername.iam.gserviceaccount.com] Activated service account credentials for: [apigee-cassandra-backup-svc@gce-myusername.iam.gserviceaccount.com] INFO: restore downloaded tarball and extracted the file from gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1 INFO: restore downloaded tarball and extracted the file from gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1 INFO: restore downloaded tarball and extracted the file from gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1 INFO 12:02:28 Configuration location: file:/etc/cassandra/cassandra.yaml …... INFO 12:02:41 [Stream #e013ee80-5863-11e9-8458-353e9e3cb7f9] All sessions completed Summary statistics: Connections per host : 3 Total files transferred : 2 Total bytes transferred : 0.378KiB Total duration : 5048 ms Average transfer rate : 0.074KiB/s Peak transfer rate : 0.075KiB/s progress: [/10.32.1.1.6]0:1/1 100% 1:1/1 100% [/10.32.0.28]1:1/1 100% 0:1/1 100% [/10.32.3.220]0:1/1 100% 1:1/1 100% total: 100% 0.000KiB/s (avg: 0.074KiB/s) INFO 12:02:41 [Stream #e013ee80-5863-11e9-8458-353e9e3cb7f9] All sessions completed progress: [/10.32.1.1.6]0:1/1 100% 1:1/1 100% [/10.32.0.28]1:1/1 100% 0:1/1 100% [/10.32.3.220]0:1/1 100% 1:1/1 100% total: 100% 0.000KiB/s (avg: 0.074KiB/s) INFO 12:02:41 [Stream #e013ee80-5863-11e9-8458-353e9e3cb7f9] All sessions completed INFO 12:02:41 [Stream #e013ee80-5863-11e9-8458-353e9e3cb7f9] All sessions completed INFO: ./apigee/data/cassandra/data/ks1/user-9fbae960571411e99652c7b15b2db6cc restored successfully INFO: Restore 20190405011309 completed INFO: ./apigee/data/cassandra/data/ks1/user-9fbae960571411e99652c7b15b2db6cc restored successfully INFO: Restore 20190405011309 completed waiting on waiting nodes $pid to finish 106 Restore finished
Verifica el trabajo de la copia de seguridad
También puedes verificar el trabajo de copia de seguridad después de que se programe tu trabajo cron de copia de seguridad. Después de programar el trabajo cron, deberías ver algo como lo siguiente:
kubectl get pods
El resultado es similar al siguiente:
NAME READY STATUS RESTARTS AGE apigee-cassandra-default-0 1/1 Running 0 2h apigee-cassandra-default-1 1/1 Running 0 2h apigee-cassandra-default-2 1/1 Running 0 2h apigee-cassandra-backup-1.6451.680-pff6s 0/1 Running 0 54s
Revisa los registros de copia de seguridad
El trabajo de copia de seguridad, haz lo siguiente:
- Crea un archivo
schema.cql
. - Lo sube a tu bucket de almacenamiento.
- Repite el nodo para realizar una copia de seguridad de los datos y subirlos al mismo tiempo.
- Espera hasta que se suban todos los datos.
kubectl logs -f apigee-cassandra-backup-1.6451.680-pff6s
El resultado es similar a este:
myusername-macbookpro:cassandra-backup-utility myusername$ kubectl logs -f apigee-cassandra-backup-1.64577680-f9sc4 starting apigee-cassandra-default-0 in default starting apigee-cassandra-default-1 in default starting apigee-cassandra-default-2 in default 35 46 57 waiting on process 35 Activated service account credentials for: [apigee-cassandra-backup-svc@gce-myusername.iam.gserviceaccount.com] Activated service account credentials for: [apigee-cassandra-backup-svc@gce-myusername.iam.gserviceaccount.com] Activated service account credentials for: [apigee-cassandra-backup-svc@gce-myusername.iam.gserviceaccount.com] Requested creating snapshot(s) for [all keyspaces] with snapshot name [20190406190808] and options {skipFlush=false} Snapshot directory: 20190406190808 INFO: backup created cassandra snapshot 20190406190808 tar: Removing leading `/' from member names /apigee/data/cassandra/data/ks1/mytest3-37bc2df0587811e98e8d875b0ed64754/snapshots/ /apigee/data/cassandra/data/ks1/mytest3-37bc2df0587811e98e8d875b0ed64754/snapshots/20190406190808/ /apigee/data/cassandra/data/ks1/mytest3-37bc2df0587811e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-Data.db Requested creating snapshot(s) for [all keyspaces] with snapshot name [20190406190808] and options {skipFlush=false} Requested creating snapshot(s) for [all keyspaces] with snapshot name [20190406190808] and options {skipFlush=false} Snapshot directory: 20190406190808 INFO: backup created cassandra snapshot 20190406190808 tar: Removing leading `/' from member names /apigee/data/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/snapshots/ /apigee/data/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/snapshots/20190406190808/ /apigee/data/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/snapshots/20190406190808/manifest.json /apigee/data/cassandra/data/system/prepared_statements-18a9c2576a0c3841ba718cd529849fef/snapshots/ /apigee/data/cassandra/data/system/prepared_statements-18a9c2576a0c3841ba718cd529849fef/snapshots/20190406190808/ /apigee/data/cassandra/data/system/prepared_statements-18a9c2576a0c3841ba718cd529849fef/snapshots/20190406190808/manifest.json /apigee/data/cassandra/data/system/range_xfers-55d764384e553f8b9f6e676d4af3976d/snapshots/ /apigee/data/cassandra/data/system/range_xfers-55d764384e553f8b9f6e676d4af3976d/snapshots/20190406190808/ /apigee/data/cassandra/data/system/range_xfers-55d764384e553f8b9f6e676d4af3976d/snapshots/20190406190808/manifest.json /apigee/data/cassandra/data/system/peer_events-59dfeaea8db2334191ef109974d81484/snapshots/ /apigee/data/cassandra/data/system/peer_events-59dfeaea8db2334191ef109974d81484/snapshots/20190406190808/ /apigee/data/cassandra/data/system/peer_events-59dfeaea8db2334191ef109974d81484/snapshots/20190406190808/manifest.json /apigee/data/cassandra/data/system/built_views-4b3c50a9ea873d7691016dbc9c38494a/snapshots/ /apigee/data/cassandra/data/system/built_views-4b3c50a9ea873d7691016dbc9c38494a/snapshots/20190406190808/ /apigee/data/cassandra/data/system/built_views-4b3c50a9ea873d7691016dbc9c38494a/snapshots/20190406190808/manifest.json …… /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/ /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/ /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-3-big-Filter.db /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-2-big-CompressionInfo.db /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-2-big-Index.db /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-3-big-Statistics.db /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-2-big-Data.db /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-Index.db /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-Statistics.db /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-2-big-TOC.txt /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-2-big-Statistics.db /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-Summary.db /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-Filter.db /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-2-big-Summary.db /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-3-big-Index.db /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/manifest.json /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-2-big-Filter.db /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-2-big-Digest.crc32 /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-3-big-Summary.db /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-3-big-Data.db /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-TOC.txt /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/schema.cql /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-3-big-CompressionInfo.db /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-Digest.crc32 /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-3-big-TOC.txt /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-Data.db /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-3-big-Digest.crc32 /apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-CompressionInfo.db …… /tmp/tokens.txt / [1 files][ 0.0 B/ 0.0 B] Operation completed over 1 objects. / [1 files][ 0.0 B/ 0.0 B] Operation completed over 1 objects. INFO: backup created tarball and transferred the file to gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1 INFO: removing cassandra snapshot INFO: backup created tarball and transferred the file to gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1 INFO: removing cassandra snapshot Requested clearing snapshot(s) for [all keyspaces] INFO: Backup 20190406190808 completed waiting on process 46 Requested clearing snapshot(s) for [all keyspaces] INFO: Backup 20190406190808 completed Requested clearing snapshot(s) for [all keyspaces] waiting on process 57 INFO: Backup 20190406190808 completed waiting result to get schema from 10.32.0.28 INFO: /tmp/schema.cql has been generated Activated service account credentials for: [apigee-cassandra-backup-svc@gce-myusername.iam.gserviceaccount.com] tar: removing leading '/' from member names tmp/schema.cql Copying from <TDIN>... / [1 files][ 0.0 B/ 0.0 B] Operation completed over 1 objects. INFO: backup created tarball and transferred the file to gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1 finished uploading schema.cql
Validación
Para validar el restablecimiento, prueba la dirección IP de Ingress y pruébala con algo de tráfico.
- Obtén el
EXTERNAL-IP
con el siguiente comando:kubectl get svc -n istio-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-ingressgateway LoadBalancer 10.11.123.45 34.56.78.90 15021:32225/TCP,80:32208/TCP,443:31942/TCP,15012:32689/TCP,15443:31936/TCP 1d
-
En la línea de comandos, obtén o actualiza las credenciales de autenticación de gcloud, como se muestra en el siguiente ejemplo:
TOKEN=$(gcloud auth print-access-token)
- Prueba Ingress mediante un apiproxy existente implementado en tu entorno de Apigee junto con la clave de API o el token de acceso:
Curl -v https://EXTERNAL-IP/basepath -H 'envgroup hostalias'
Por ejemplo:
curl -v 'https://example.com/oauth/client_credential' \ --resolve edgehybrid-staging-func-runtime-wf.hybrid.e2e.apigeeks.net:443:34.56.78.90 \ -H 'Authorization: Bearer ${TOKEN}'
Configuración de DNS para la migración de sistemas del clúster y el tráfico nuevos
Una vez que estés satisfecho con la validación, redirecciona el tráfico al clúster nuevo y cambia la entrada de DNS a la dirección EXTERNAL-IP
de Ingress nueva.