En este artículo aprenderás sobre la planificación de la continuidad del negocio, la recuperación de desastres (disaster recovery) y sobre el backup en la plataforma Cloudera Data Platform (CDP) y en sus servicios de datos.
Contenidos
Conceptos de Disaster Recovery en Cloudera CDP
Antes de comenzar a ver las soluciones de disaster recovery en la plataforma Cloudera, es recomendable comprender los conceptos de recuperación de desastres. Puedes encontrar más información en los siguientes artículos. Por ejemplo, de la definición de RTO y RPO y sobre las arquitecturas multi-cluster:
Backup
Los backups o copias de seguridad comprenden los procedimientos necesarios para recuperar los datos. Los tiempos asociados a esta recuperación de datos desde un backup suelen ser mayores a los tiempos que necesita la organización (RTO), por tanto, no debe ser el único mecanismo de disaster recovery para los servicios de Cloudera CDP.
Por otro lado, las copias de seguridad son un mecanismo excelente para recuperar datos borrados o corruptos. Además, pueden usarse ante problemas de propagación a varios clusters de estos datos corruptos.
Alta Disponibilidad
También debemos entender las maneras de implementar alta disponibilidad o HA (High Availability) en nuestros sistemas. En general, la alta disponibilidad se puede conseguir de dos formas. Por un lado, eliminando los puntos únicos de fallo en los componentes, por ejemplo activando varios NameNodes para el servicio de HDFS. De esta forma se evita que el servicio falle en su totalidad dejando al clúster inoperativo.
Por otro lado, podemos implementar alta disponibilidad entre clusters con el uso de balanceadores de carga e ingestando los datos por duplicado en ambas instalaciones. Es recomendable usar ambos mecanismos de alta disponibilidad siempre que tenga sentido en el plan de continuidad de negocio valorando su coste.
Como veremos más adelante, muchos servicios de Cloudera CDP tienen ambas opciones y podremos configurarlos para que tengan HA intra-cluster e inter-cluster.
Stretch Cluster
Un Stretch Cluster es un mismo clúster lógico desplegado en diferentes localizaciones físicas separadas entre sí. De esta forma se separan físicamente los componentes configurados con alta disponibilidad. Este tipo de despliegues tienen varias desventajas frente al despliegue de clusters independientes.
La desventaja principal es la latencia. Algunos servicios de Cloudera, como HDFS o Zookeeper ven degradado su servicio significativamente cuando existe una alta latencia entre sus componentes. En el caso de HDFS y Yarn, el impacto en tiempos de ejecución puede ser muy alto si los trabajos ejecutan en nodos que no están próximos a los que contienen los datos sobre los que trabajan.
Tipos de Fallo en Cloudera CDP
Para analizar los fallos y el riesgo que puede sufrir nuestro sistema tenemos que contemplar su impacto en las operaciones. Muchos componentes de un clúster de Cloudera CDP han sido construidos para soportar determinados tipos de fallos. Cloudera comparte la siguiente tabla que refleja el tipo de fallo y el impacto que tiene:
| Tipo de Fallo | Impacto | Failover |
|---|---|---|
| Un disco (Nodo Líder) | Bajo a Moderado | Intra-cluster failover entre servicios de alta disponibilidad |
| Un disco (Nodo Worker) | Bajo | Funciones automatizadas de recuperación de clusters |
| Varios discos (Nodo Líder) | Bajo a Moderado | Intra-cluster failover entre servicios de alta disponibilidad |
| Varios discos (Nodo Worker) | Bajo | Funciones automatizadas de recuperación de clusters |
| Un nodo (Nodo Líder) | Bajo a Moderado | Intra-cluster failover entre servicios de alta disponibilidad |
| Un nodo (Nodo Worker) | Bajo | Funciones automatizadas de recuperación de clusters |
| Varios nodos (Nodo Líder) | Moderado a Alto | Disaster recovery failover si no es posible la recuperación en el período RTO |
| Varios nodos (Nodo Worker) | Bajo a Moderado | Funciones automatizadas de recuperación de clusters Disaster recovery failover si no es posible la recuperación en el período RTO |
| Comunicaciones de red entre entornos | Moderado a Alto | Disaster recovery failover si no es posible la recuperación en el período RTO |
| Un entorno | Alto | Disaster recovery failover al entorno secundario |
| Varios entornos | Muy Alto | Recuperación de un entorno y Disaster recovery failover |
Elementos de Disaster Recovery en Cloudera CDP
Un entorno CDP consta de varios servicios. En algunos casos, podemos utilizar la replicación de datos del servicio (como HBase), y en otros casos deberemos replicar los datos con una herramienta externa como Replication Manager para HDFS. Los elementos que debemos analizar para planificar los escenarios de disaster recovery son los siguientes:
Datos
Los datos se almacenan en varias ubicaciones. Por un lado, tenemos servicios de almacenamiento de datos como HDFS y Ozone. Por otro lado, existen servicios que usan HDFS como capa de almacenamiento de archivos (Solr) y servicios que almacenan los datos localmente (Kafka, Kudu).
HDFS debe configurarse con HA en sus tres componentes: NameNode, DataNode y JournalNode. Estos servicios ejecutarán en varios nodos líder. Los DataNodes proporcionarán la replicación de datos en varios nodos. Para replicar datos entre clusters, HDFS usa la herramienta distcp y para replicar las políticas de los directorios de forma asíncrona usa Replication Manager.
Ozone también debe configurarse con HA en sus tres componentes: Ozone Manager, Storage Container Manager, y DataNode. Para este servicio, la replicación de datos también se realiza con la herramienta distcp, que se puede planificar para su ejecución periódica.
HBase también tiene un mecanismo de HA con nodos líder de backup. Además tiene un mecanismo de replicación entre clusters que permite su funcionamiento en activo-activo.
Kudu utiliza los discos locales para almacenar los datos y no tiene replicación integrada entre clusters. Debemos configurar por tanto la doble ingesta de datos, una para cada instancia en cada clúster.
Solr sigue un mecanismo similar. Debemos crear backups y snapshots de las colecciones, y en caso de fallo o necesidad restaurar estas copias. Para escenarios de disaster recovery, se recomienda configurar la doble ingesta de datos.
Hive e Impala tienen dos mecanismos para replicar datos que residen en HDFS. Por un lado, las tablas externas podemos repicarlas con Replication Manager. Las tablas gestionadas deberemos replicarlas con el mecanismo integrado de Hive. Replication Manager copia el esquema y los datos, pero no los metadatos asociados ni políticas de Ranger y Atlas.
Metadatos
Los metadatos contienen los esquemas, las estructuras y el contexto de los datos. Se encuentran en servicios como Hive Metastore y Atlas. Ambos servicios se pueden configurar con HA añadiendo nodos adicionales. Apache Atlas depende de otros servicios como Solr, HBase y Kafka, que 5qmgideben estar configurados de igual manera con HA.
Los datos de negocio almacenados en Atlas relacionados con linaje y tags no se sincroniza de manera automática entre los entornos de disaster recovery de Cloudera CDP. Para hacer esto, se deben implementar manualmente trabajos de exportación e importación usando la API Rest de Apache Atlas.
Cargas de Trabajo
Los trabajos son el conjunto de los datos, metadatos, políticas y aplicaciones que ejecutan en el clúster. Pueden ser de tipo streaming o de tipo batch. Estas aplicaciones deben contemplar en su diseño e implementación los escenarios de disaster recovery, y evaluar el impacto que tendrían en su ejecución los mecanismos de HA.
Siguientes pasos y Cursos de Cloudera
Aprende Cloudera CDP a fondo y mantente al día con el siguiente curso recomendado. Además, podrás preparar sus certificaciones, una forma excelente de aportar valor y destacar:
Curso de Especialización en Big Data de Cloudera
Esta especialización de Coursera ofrecida directamente por Cloudera es muy completa y se compone de cuatro módulos de aprendizaje para dominar la plataforma de análisis de datos y si estás interesado, también preparar la certificación:
Artículos Relacionados: Seguridad en Hadoop y Cloudera Data Platform (CDP)
Arquitecto de Datos con más de 6 años de experiencia en el sector del Big Data. Autor de cursos de formación en tecnologías Big Data, Cloud y Streaming completados por más de 5000 alumnos en Udemy y otras plataformas. Miembro de la Apache Software Foundation desde 2019.
![Lee más sobre el artículo Mejores Libros de Arquitectura de Software [Actualizado]](https://aprenderbigdata.com/wp-content/uploads/mejores-libros-arquitectura-software-300x169.jpg)
