Recuperación ante desastres de CSO
En caso de fallas, puede recuperar la versión 6.2.0 de CSO. Para recuperar la versión 6.2.0 de CSO, debe haber realizado ya una copia de seguridad y guardado el archivo de respaldo.
Para recuperar la versión 6.2.0 de CSO:
- En función del hipervisor que esté utilizando, realice una de las siguientes acciones:
Si utiliza KVM como hipervisor:
-
Copie la carpeta de respaldo CSO 6.2.0 en el servidor sin sistema operativo.
-
Desde la carpeta de respaldo, copie el archivo _topology.conf a la carpeta Contrail_Service_Orchestration_6.2.0/topology/ .
Por ejemplo:
cp /root/backups/backupfordr/2020-06-19T17:27:05/config_backups/_topology.conf /root/Contrail_Service_Orchestration_6.2.0/topology/
Aprovisionar las máquinas virtuales. Para obtener más información sobre el aprovisionamiento del hipervisor KVM, consulte Aprovisionar máquinas virtuales en servidores contrail Service Orchestration en la Guía de instalación y actualización de CSO.
-
Copie el archivo de carpeta de copia de seguridad desde el servidor sin sistema operativo a la VM startupserver1.
user@server>scp -r /root/backups/backupfordr/ startupserver1:
-
Inicie sesión en la VM startupserver1 como usuario raíz.
-
Expanda el paquete del instalador.
root@startupserver1:~/# tar –xvzf Contrail_Service_Orchestration_6.2.0.tar.gz
El paquete expandido es un directorio que tiene el mismo nombre que el paquete del instalador y contiene los archivos de instalación.
-
Desde la carpeta de respaldo, copie el archivo _topology.conf a la carpeta Contrail_Service_Orchestration_6.2.0/topology/ .
cp /root/backups/backupfordr/2020-06-19T17:27:05/config_backups/_topology.conf /root/Contrail_Service_Orchestration_6.2.0/topology/
-
Si usa ESXi como hipervisor:
-
Copie la carpeta de copia de seguridad en la VM startupserver1.
-
Expanda el paquete del instalador.
root@startupserver1:~/# tar –xvzf Contrail_Service_Orchestration_6.2.0.tar.gz
El paquete expandido es un directorio que tiene el mismo nombre que el paquete del instalador y contiene los archivos de instalación.
-
Desde la carpeta de respaldo, copie el archivo _topology.conf a la carpeta Contrail_Service_Orchestration_6.2.0/topology/ en la VM startupserver1.
Por ejemplo:
cp /root/backups/backupfordr/2020-06-19T17:27:05/config_backups/_topology.conf /root/Contrail_Service_Orchestration_6.2.0/topology/
-
- Ejecute el comando deploy.sh .
root@host:~/Contrail_Service_Orchestration_6.2.0./deploy.sh
- Ejecute el siguiente comando:
cso_backupnrestore -b backup -s backup62new
- Ejecute la secuencia de comandos de recuperación de pre_disaster.
python /usr/local/bin/pre_disaster_recovery.py
Enter the old backup path: /root/backups/backupfordr/2020-10-29T06:45:11:45:11 Enter the new backup path: /backups/backup62new/2020-10-30T03:47:51 COMPONENTS: ('cassandra', 'elasticsearch', 'etcd', 'arangodb', 'icinga', 'swift', 'config_backups') Start cassandra pre restore task... Get old and new backup path for component cassandra cassandra pre restore task successfully done *Do you want to redeploy cassandra container to apply tokens. *This process will delete all the existing data from cassnadra Please enter yes to process [yes/no]:Ingrese yes en el indicador.
Start elasticsearch pre restore task... Get old and new backup path for component elasticsearch Get Elasticsearch user id for permission Set permission for elasticsearch dir. elasticsearch pre restore task successfully done Start etcd pre restore task... Get old and new backup path for component etcd etcd pre restore task successfully done Start arangodb pre restore task... Get old and new backup path for component arangodb arangodb pre restore task successfully done Start mariadb pre restore task... Get old and new backup path for component mariadb mariadb pre restore task successfully done Start icinga pre restore task... Get old and new backup path for component icinga icinga pre restore task successfully done Start swift pre restore task... Get old and new backup path for component swift swift pre restore task successfully done Start config_backups pre restore task... config_backups pre restore task successfully done Pre restore task completed for all components.
- Restaure los datos de la nueva copia de seguridad creada en el paso 3 mediante la secuencia de comandos cso_backupnrestore.
#cso_backupnrestore -b restore -s backuppath -t '*' -c ‘cassandra' -r ‘yes’ #cso_backupnrestore -b restore -s backuppath -t '*' -c ‘elasticsearch' -r ‘yes’ #cso_backupnrestore -b restore -s backuppath -t '*' -c ‘arangodb' -r ‘yes’ #cso_backupnrestore -b restore -s backuppath -t '*' -c ‘icinga' -r ‘yes’ #cso_backupnrestore -b restore -s backuppath -t '*' -c ‘swift' -r ‘yes’ #cso_backupnrestore -b restore -s backuppath -t '*' -c ‘mariadb' -r ‘yes’
dónde
backuppathestá la nueva ruta de respaldo.Si se produce un error en el procedimiento de restauración para cualquiera de los componentes anteriores, debe intentarlo para restaurar solo esos componentes. A veces, la restauración de mariadb falla en el primer intento, pero se realiza correctamente en el segundo intento.
- Sincronice los datos entre nodos.
cso_backupnrestore -b nodetool_repair
IF Cluster nodetool status is UP/Normal(UN) please proceed for nodetool repair (Y/n):
Ingrese y en el indicador.
- Copie el certificado de la carpeta de copia de seguridad al proxy HA de equilibrio de carga basado en SDN (SBLB).
salt-cp -G "roles:haproxy_confd_sblb" /root/backups/backupfordr/2020-06-19T17:27:05/config_backups/haproxycerts/minions/minions/csp-central-proxy_sblb1.NH5XCS.central/files/etc/pki/tls/certs/ssl_cert.pem /etc/pki/tls/certs
salt-cp -G "roles:haproxy_confd_sblb" /root/backups/backupfordr/2020-06-19T17:27:05/config_backups/haproxycerts/minions/minions/csp-central-proxy_sblb1.NH5XCS.central/files/etc/pki/tls/certs/ssl_cert.crt /etc/pki/tls/certs
- Reinicie el proxy SBLB HA.
salt -C "G@roles:haproxy_confd_sblb" cmd.run "service haproxy restart"
- Copie el certificado de la carpeta de copia de seguridad en el proxy DE central.
salt-cp -G "roles:haproxy_confd" /root/backups/backupfordr/2020-06-19T17:27:05/config_backups/haproxycerts/minions/minions/csp-central-proxy1.NH5XCS.central/files/etc/pki/tls/certs/ssl_cert.pem /etc/pki/tls/certs
salt-cp -G "roles:haproxy_confd" /root/backups/backupfordr/2020-10-29T06:45:11/config_backups/haproxycerts/minions/minions/csp-central-proxy1.NH5XCS.central/files/etc/pki/tls/certs/ssl_cert.crt /etc/pki/tls/certs
- Reinicie el proxy HA central.
salt -C "G@roles:haproxy_confd" cmd.run "service haproxy restart"
- Ejecute los siguientes comandos en la máquina virtual del instalador para actualizar los certificados Nginx.
kubectl get secret -n central | grep cso-ingress-tls cso-ingress-tls kubernetes.io/tls 2 17d kubectl delete secret cso-ingress-tls -n central kubectl create secret tls cso-ingress-tls --key /root/backups/backupfordr/2020-10-29T06:45:11/config_backups/haproxycerts/minions/minions/csp-central-proxy1.NH5XCS.central/files/etc/pki/tls/certs/ssl_cert.key --cert /root/backups/backupfordr/2020-10-29T06:45:11/config_backups/haproxycerts/minions/minions/csp-central-proxy1.NH5XCS.central/files/etc/pki/tls/certs/ssl_cert.crt -n central
- Implemente microservicios.
/python.sh micro_services/deploy_micro_services.py
- Vuelva a indexar la búsqueda elástica.
Abra el archivo de implementación regional csp.csp-ems.
kubectl edit deployment -n regional csp.csp-ems-regional
Cambie las réplicas a 2 y aumente la memoria de 500Mi a 2048Mi (2Gi).
Guarde el archivo.
Inicie el proceso de reindexación.
cso_backuprestore -b reindex
-
Con el token de administrador, ejecute la siguiente API para crear los índices de política:
curl --location --request POST 'https://AdminPortalIP/policy-mgmt/_index' \ --header 'x-auth-token: XXXXXXX‘\ --data-raw ‘'
- Cree la cola FMPM de RabbitMQ.
./python.sh upgrade/migration_scripts/common/rabbitmq_fmpm_queue_creation.py
- Cargue los datos.
./python.sh micro_services/load_services_data.py
- Sincronice el reflector de ruta virtual (VRR). Use el token de administrador. No use el token cspadmin.
-
Obtenga el topo-uuid para el VRR.
GET: https://<IP Address>/topology-service/device
Sincronice el VRR mediante la API POST https://<ip>/routing-manager/synchronize-vrr.
{ "input": { "recover_vrr": true, "uuid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx” } }
-
- Restaure los informes de seguridad y RAEDS.
cso_backupnrestore -b restore -s backuppath -t '*' -c 'swift_report' -r 'yes'
dónde
backuppathestá la nueva ruta de respaldo. - Reinicie todos los pods fmpm-provider-api y fmpm-provider-core eliminando los pods existentes.
root@startupserver1:~# kubectl get pods -n central|grep fmpm-provider csp.csp-fmpm-provider-6644bc8b94-7pvfn 1/1 Running 0 9d csp.csp-fmpm-provider-6644bc8b94-c2psl 1/1 Running 0 9d csp.csp-fmpm-provider-6644bc8b94-gzkht 1/1 Running 1 9d csp.csp-fmpm-provider-6644bc8b94-hz8f5 1/1 Running 0 9d csp.csp-fmpm-provider-6644bc8b94-nsqfs 1/1 Running 0 9d csp.csp-fmpm-provider-6644bc8b94-rq9xq 1/1 Running 0 9d csp.csp-fmpm-provider-core-797f7c48c9-7nm8q 1/1 Running 0 9d csp.csp-fmpm-provider-core-797f7c48c9-7zj67 1/1 Running 0 9d csp.csp-fmpm-provider-core-797f7c48c9-8njsq 1/1 Running 0 9d csp.csp-fmpm-provider-core-797f7c48c9-rh2jr 1/1 Running 0 9d csp.csp-fmpm-provider-core-797f7c48c9-sswbg 1/1 Running 0 9d csp.csp-fmpm-provider-core-797f7c48c9-zvhps 1/1 Running 0 9d
- Elimine todos los pods mostrados en el paso anterior.
kubectl delete pods csp.csp-fmpm-provider-6644bc8b94-7pvfn csp.csp-fmpm-provider-6644bc8b94-c2psl csp.csp-fmpm-provider-6644bc8b94-gzkht csp.csp-fmpm-provider-6644bc8b94-hz8f5csp.csp-fmpm-provider-6644bc8b94-nsqfs csp.csp-fmpm-provider-6644bc8b94-rq9xq csp.csp-fmpm-provider-core-797f7c48c9-7nm8q csp.csp-fmpm-provider-core-797f7c48c9-7zj67 csp.csp-fmpm-provider-core-797f7c48c9-8njsq csp.csp-fmpm-provider-core-797f7c48c9-rh2jr csp.csp-fmpm-provider-core-797f7c48c9-sswbg csp.csp-fmpm-provider-core-797f7c48c9-zvhps
- Restaure la base de datos del nodo Contrail Analytics (CAN).
Nota:
Solo puede restaurar la base de datos si hay una copia de seguridad disponible. La copia de seguridad can está deshabilitada de forma predeterminada. Para incluir datos CAN en la copia de seguridad, comente
contrail_analyticsen la siguiente configuración:root@startupserver1:~# cat /etc/salt/master.d/backup.conf backups: keep: 10 timeout: 1200 path: /backups enabled_roles: • cassandra • mariadb • kubemaster • elasticsearch # - redis • icinga • helm_manager # - contrail_analytics
Para restaurar la base de datos de configuración can, ejecute la siguiente secuencia de comandos:
./python.sh upgrade/migration_scripts/common/can_migration.py
Para restaurar la base de datos de CAN Analytics, realice los siguientes pasos:
Los archivos de respaldo de analyticsdb se encuentran en /backups/daily/2021-06-07T06:46:37/central/can/contrail_analytics<x>, donde x indica el número de nodo contrail analytics. El valor de x varía del 1 al 3.
En los tres nodos de Contrail Analytics:
-
Copie los archivos de copia de seguridad de CAN desde el servidor de inicio a cada VM CAN:
rsync -a<can-backup-files>root@<can-ip>:<created-backup-folder>
-
Ejecute el siguiente comando en las máquinas virtuales CAN:
docker cp 0000/ analytics_database_cassandra_1:/root
docker exec -it analytics_database_cassandra_1 bash mv /root/mc-* /var/lib/cassandra/data/ContrailAnalyticsCql/statstablev4-d5b63590a7f011eba080c3eb6817d254
#The ruta puede ser diferente según uuid.
cd /var/lib/cassandra/data/ContrailAnalyticsCql/statstablev4-d5b63590a7f011eba080c3eb6817d254 chown -R cassandra:cassandra * nodetool -p 7200 refresh -- ContrailAnalyticsCql statstablev4
-
Después de una actualización correcta, la versión 6.2.0 de CSO es funcional y puede iniciar sesión en el Portal de administrador y en el Portal del cliente.