Un caso real de

Disaster Recovery

​

Tech Party - Septiembre 2019

hola *

STR Sistemas - 2019

@txetxuvel

Disclaimer

• La solución expresada no es la mejor ni la única, es la que hemos implementado en base a los requisitos de negocio, a la tecnología existente y que a día de hoy sigue evolucionando

​

• Los esquemas y demás información mostrada, aunque se aproximan mucho, no son reflejo exacto de la realidad. Por temas de seguridad y confidencialidad se han omitido datos confidenciales

​

​

STR Sistemas - 2019

​

HA != DR

LB != HA

​

STR Sistemas - 2019

​

DISASTER

RECOVERY

STR Sistemas - 2019

STR Sistemas - 2019

STR Sistemas - 2019

MOLA,

¿LO IMPLEMENTO?

STR Sistemas - 2019

NO

STR Sistemas - 2019

Razones reales para implementarlo

• exigencia de certificación y/o legal

​

• pierdes cientos de miles de euros/dólares por hora de caída no recuperables

• exigencia de certificación y/o legal

​

• pierdes cientos de miles de euros/dólares por hora de caída no recuperables

• te estás convirtiendo en uno de los grandes de Internet

STR Sistemas - 2019

Soluciones intermedias

• backup en otra región/hoster con accesos mínimos

​

• sistemas totalmente automatizados (infraestructura como código y gestión de la configuración) que permitan levantar un sistema en horas/días a partir de los backups

STR Sistemas - 2019

CONTEXTO

DR

Giros postales

• Mercado regulado

​

• Movimientos de dinero real

​

• Los clientes son los bancos

​

• Cada vez que fallas, pierdes una operación y por tanto la comisión

STR Sistemas - 2019

Requisitos negocio (I)

​

• Contratos de SLA y exigencias del regulador

​

• Prueba sin cambio de servicio semestral
• Prueba total anual

​

• Recuperación manual en 2 horas

STR Sistemas - 2019

Requisitos negocio (II)

• Gabinete de crisis

​

• Disaster Recovery bidireccional

​

• Persistencia de ciertos datos durante 10 años

STR Sistemas - 2019

Requisitos técnicos (I)

• Que funcione

​

• No duplicar coste infraestructura

​

• Mantenimiento liviano

​

• Total independencia de los sistemas en las regiones

STR Sistemas - 2019

Requisitos técnicos (II)

• Datos estáticos superiores a 10TB con crecimiento anual de cientos de gigas

​

• Bases de datos relacionales de cientos de gigas

​

• Bases de datos nosql de varios teras con crecimiento exponencial

STR Sistemas - 2019

Disclaimer (II)

Imagen de http://www.gen2phen.org/blogs/gt50/2009-05/too-much-data-causes-server-crash

STR Sistemas - 2019

GABINETE

DE CRISIS

STR Sistemas - 2019

• Departamentos de dirección, negocio, técnico y atención al cliente

​

• Lo convoca el equipo de sistemas => definir el proceso

​

• Aprueba la ejecución efectiva del Plan de Disaster Recovery

STR Sistemas - 2019

• Comunicación continua entre los departamentos con transparencia del proceso de ejecución

​

• Valida la ejecución y decide el cambio de servicio real

​

• Posteriormente decide también la ejecución de la restauración del sistema original

​

STR Sistemas - 2019

ANÁLISIS Y SOLUCIONES

STR Sistemas - 2019

Global - Análisis (I)

​

• Sistemas totalmente independientes

​

• Minimizar que el acceso a una región comprometa la otra

​

• Evitar dependencias de personas

STR Sistemas - 2019

Global - Análisis (II)

​

• Contención de costes

​

• Plan C para pérdida de datos

STR Sistemas - 2019

Global - Solución adoptada (I)

​

• Cuentas y recursos de AWS independientes para cada región

​

• Trabajo en modo 2x2 en todos los procesos y niveles

​

• Documentar todo a nivel necesario de manera operacional

STR Sistemas - 2019

Global - Solución adoptada (II)

​

• Plan C
• Toda transacción se tracea en log, se centraliza, se sube a S3 y se centraliza en servicios SAAS de terceros
• Disponemos de un proveedor ajeno a AWS con una copia actualizada de todo que permitiría generar una nueva plataforma

STR Sistemas - 2019

STR Sistemas - 2019

DNS - Análisis

• ¿Requiero Disaster Recovery DNS?

​

• ¿Control de los dominios?

​

• Control de cambios de DNS en Plan de Disaster Recovery

STR Sistemas - 2019

DNS - Solución adoptada (I)

​

• Dado que no se puede controlar al 100% ciertos TTL:
• se asume la caída de DNS de Route 53 como caso de fuerza mayor, no redundando este servicio inicialmente
• actualmente en proceso de replicación en segundo proveedor, automatizado por terraform, pendiente de decidir balanceo de DNS
• se separa el registro de dominios y se limita el acceso

STR Sistemas - 2019

DNS - Solución adoptada

​

• Cambios de DNS:
• Se minimiza el número de registros a cambiar usando en cada región hosts diferentes y adaptando los despliegues para ello
• Documentar y automatizar cambios de DNS necesarios

STR Sistemas - 2019

STR Sistemas - 2019

Volúmenes NFS y Buckets S3 - Análisis

• Distintos volúmenes NFS ¿necesitamos todos?

​

• Distintos buckets S3 ¿necesitamos todos?

​

• Requisito de no dependencia ni acceso entre regiones

​

• Requisito de almacenamiento de datos hasta por 10 años

​

STR Sistemas - 2019

Volúmenes NFS y Buckets S3 - Solución

• Copiar sólo lo necesario (prácticamente todo), se asume no disponibilidad últimos datos

​

• Replicación nativa S3 ¡tener en cuenta las limitaciones!

​

• Volcar contenido NFS a buckets locales y replicación nativa S3, evitando rsync y similares

STR Sistemas - 2019

STR Sistemas - 2019

Aplicaciones tomcat - Análisis

• ¿Grupos de autoscaling comunes?
• ¿Diferencia de aplicaciones?
• ¿Despliegues?

​

• ¿Grupos de autoscaling independientes?
• ¿Mantenimiento del grupo sin uso y su validación de funcionamiento?

​

​

STR Sistemas - 2019

Aplicaciones tomcat - Solución adoptada

• Grupos de autoscaling comunes
• despliegues de cada aplicación por duplicado, sólo cuando existen en el repo de despliegue
• aplicaciones con sufijos de región y configuraciones automatizadas listas y operativas en todo momento
• redimensionado si es necesario
• sistemas de despliegue basado en war con S3, automatizado con jenkins por región y entorno

​

STR Sistemas - 2019

STR Sistemas - 2019

SQL Server (viejuno) - Análisis (I)

​

• Backups
• ¿Podemos usar backups?
• ¿Tiempo de puesta en marcha?
• ¿Pérdida de datos?

​

STR Sistemas - 2019

SQL Server (viejuno) - Análisis (II)

​

• Replicación
• ¿Podemos replicar en tiempo real?
• ¿Podemos usar sistemas nativos de replicación?
• ¿Tiempo de puesta en marcha?
• ¿La base de datos replicada puede estar operativa?
• ¿Pérdida de datos?

STR Sistemas - 2019

SQL Server (viejuno) - Solución adoptada (I)

• Generación de backups diarios más log transaccional y subida a S3

​

• Replicación nativa de S3 a otra región de los backups diarios y log transaccional

​

• Instancia pequeña que se aumentará en el proceso de aplicación del Plan de Disaster Recovery

STR Sistemas - 2019

SQL Server (viejuno) - Solución adoptada (II)

• Base de datos Disaster Recovery:
• Base de datos en estado recovery
• Sistema de carga propio log transaccional desde S3 local

​

• Asumimos pérdida de datos de 15 minutos recuperable mediante log

​

• Monitorización que asegure el estado correcto de la replicación y permita la reinicialización en caso necesario

STR Sistemas - 2019

STR Sistemas - 2019

RDS MySQL - Análisis

• ¿Sistema de réplicas de RDS?

​

• ¿Replicación nativa MySQL?
• ¿Tiempo de recuperación?
• ¿Riesgos?

STR Sistemas - 2019

RDS MySQL - Solución adoptada

• Replicación nativa de MySQL mediante RDSs independientes en cada región

​

• Tiempo de pérdida de datos tiende a cero

​

• Asumimos riesgo borrado de base de datos pero no de acceso a ambas regiones. El riesgo es minimizado por snapshots de RDS y la opción de recovery in time

​

STR Sistemas - 2019

STR Sistemas - 2019

Web corporativas/Mantenimiento - Análisis

• Páginas
• de mantenimiento estáticas
• corporativas sólo cambian con nuevas versiones
• deben funcionar en la ejecución el Plan de Disaster Recovery

​

• ¿Necesito replicación en tiempo real?

​

• ¿Gestión de DNS?

​

​

STR Sistemas - 2019

Web corporativas/Mantenimiento - Solución

• Replicadas entre sí, delegado al equipo de desarrollo cuando se despliegan nuevas versiones

​

• Cambio de DNS manual (TTL bajo siempre), no queremos de momento que funcionen de manera automática aunque se plantea uso de healthchecks en Route 53 a futuro

STR Sistemas - 2019

STR Sistemas - 2019

SFTP - Análisis

• En la nueva empresa no necesitamos, de momento, SFTP

​

• ¿Necesitamos los datos en escenario de crisis?

​

• ¿Control de accesos SFTP entrante?

​

• ¿Control de accesos SFTP saliente?

STR Sistemas - 2019

SFTP - Solución adoptada

• Duplicar usuarios y accesos y automatizar para mantener sistemas equivalentes

​

• Los datos de los SFTP no son necesarios pues son temporales

​

• Comunicar en todo caso ambas regiones para SFTP saliente

STR Sistemas - 2019

STR Sistemas - 2019

VPNs - Análisis

• En la nueva empresa no requerimos de momento VPNs site to site

​

• ¿Se requieren las VPNs en un escenario de crisis?
• ¿Todas?
• ¿Podemos duplicarlas?

​

STR Sistemas - 2019

VPNs - Solución adoptada

• VPN roadwarrior independiente en cada región y entorno

​

• Cada túnel IPSec site to site crítico se ha duplicado en cada región funcionando de manera independiente y se monitoriza

​

• Se requiere cambios en llamadas a servicios desde entornos remotos para usar host (DNS privado pasa a ser público) en vez de IPs

STR Sistemas - 2019

STR Sistemas - 2019

Cassandra - Análisis

• ¿Nos vale soporte nativo multiregión de cassandra?

​

• ¿Cómo conectamos los nodos?

STR Sistemas - 2019

Cassandra - Solución adoptada

• Soporte nativo con multidatacenter y factor de replicación 3 en cada data center

​

• Conectividad entre regiones por VPC peering (antes VPN)

​

• Limitación en el uso del tipo de consistencia en las queries, usar LOCAL_QUORUM

STR Sistemas - 2019

STR Sistemas - 2019

Aplicaciones Kubernetes - Análisis

• En kubernetes todas las aplicaciones desplegadas son stateless y no necesitan persistencia de datos (paradigma contenedores)

​

• ¿Debemos replicar?

​

• Las aplicaciones usarán sufijos como en las aplicaciones de tomcat

​

STR Sistemas - 2019

Aplicaciones Kubernetes - Solución adoptada

• Duplicar cluster kubernetes de manera independiente

​

• Duplicar imágenes docker en registry (ECR) personalizadas por región/entorno (automatizar con jenkins)

​

• Duplicar deployments, pods, etc. en ambas regiones con tamaño de pod igual 0 en definiciones de la región remota

​

STR Sistemas - 2019

PRUEBAS

STR Sistemas - 2019

Día a día

• Validación de recuperación de backups y replicación

​

• Revisión de los monitores relativos al Plan de Disaster Recovery

​

• Revisión de sistemas de despliegue y versionado de aplicaciones

STR Sistemas - 2019

Simulacro semestral (I)

• Convocatoria del gabinete de crisis sin preaviso

​

• Ejecución real de todo el proceso

​

• Validación real del entorno

​

• No se realiza cambio de servicio

STR Sistemas - 2019

Simulacro semestral (II)

• Se continúa hasta que se completa el proceso y se miden los tiempos de todo

​

• Si se cumplen los tiempos (correcciones incluidas) se da por bueno, si no se repite

STR Sistemas - 2019

Simulacro anual

• Igual al semestral pero

​

• Se simula una caída del servicio real, vamos que tiramos todo

​

• Si no se recupera el servicio en 2 horas se hace rollback y se repite con pruebas semestrales hasta validar y realizar una nueva anual

STR Sistemas - 2019

Resultados

• La primera vez tardamos poco más de 3 horas, una vez intermedia tuvimos que hacer rollback

​

• Ya hemos pasado satisfactoriamente tres semestrales y una anual en la nueva región

​

• Dado que la plataforma está viva en cada nueva prueba salen cosas nuevas y mejoramos

STR Sistemas - 2019

TIPS

STR Sistemas - 2019

• No hay que volverse loco, pon límites y no sentencies tu muerte con unos requisitos inasumibles

​

• Lo que pueda hacer el proveedor de infraestructura que lo haga el proveedor de infraestructura

​

• Lo que pueda hacerse con un software comercial que no dispare el coste que lo haga dicho software

​

STR Sistemas - 2019

• Una solución de Disaster Recovery siempre va a ser más sencilla en un proveedor de cloud público como AWS, GCP, Azure, IBM, etc.

​

• Si estás a tiempo de elegir tecnologías, piensa en tecnologías que te permitan montar multiregión el día que lo necesites de manera sencilla

​

• Es necesario que se implique todo el equipo técnico para la implantación del Plan de Disaster Recovery sea viable

​

STR Sistemas - 2019

• Las pruebas son necesarias y siempre va a surgir algo nuevo

​

• Simplifica tus comunicaciones y accesos críticos

​

• La clave del éxito técnico es la automatización y la documentación de los procesos, para improvisar e innovar elige otro momento

​

• No menosprecies la parte no técnica: gabinete de crisis, pruebas, comunicación, etc.

​

STR Sistemas - 2019

GRACIAS

@txetxuvel

www.strsistemas.com

STR Sistemas - 2019