Las 9 mejores soluciones de copia de seguridad y restauración de OpenShift ETCD

RedHat OpenShift permite a los usuarios aprovisionar, instanciar, ejecutar y gestionar un paquete modular compuesto por una plataforma informática y una serie de aplicaciones, lo que reduce significativamente la complejidad de construir y mantener la infraestructura que probablemente estaría asociada al desarrollo y lanzamiento de las aplicaciones y servicios necesarios.

OpenShift representa un enfoque específico de cómo las máquinas virtuales, los contenedores y los entornos de plataforma como servicio pueden funcionar juntos; la plataforma en su conjunto suele ser útil tanto para las empresas como para los particulares que están en condiciones de explotarlos.

Dado que OpenShift consiste en una familia de software, es importante mencionar su buque insignia: OpenShift Container Platform.

OpenShift Container Platform, u OSCP, es una plataforma de nube híbrida como servicio que funciona con contenedores Linux gestionados por Kubernetes. La mayoría de las veces se hace referencia a ella como «OpenShift», aunque hay otros muchos productos disponibles dentro de esa misma familia, como OpenShift Online, OpenShift Dedicated y otros. En aras de la continuidad, vamos a referirnos a la plataforma de contenedores OpenShift simplemente como «OpenShift» durante el resto de este artículo, porque la mayoría de los servicios y soluciones siguientes funcionan con OSCP.

OpenShift está diseñado para ser modular y flexible, lo que aporta una serie de ventajas a las distintas implantaciones que utilizan OpenShift. Sin embargo, este enfoque flexible y versátil tiene sus propias advertencias. La primera es que este enfoque, aunque puede ser muy eficaz, también puede ser propenso a errores y fallos. Como tal, un buen sistema de copia de seguridad es un requisito para la mayoría, si no todos, los despliegues de OpenShift, especialmente cuando se están creando y/o procesando datos valiosos y persistentes.

La necesidad de un sistema de copia de seguridad crea otro problema significativo para los despliegues OpenShift – no todas las soluciones de copia de seguridad son capaces de proteger adecuadamente los entornos OpenShift – y algunos son simplemente incapaces de hacerlo en absoluto.

Como tal, una solución de copia de seguridad y restauración debe ser totalmente compatible con OpenShift en primer lugar. Por lo general, las funciones de copia de seguridad como la automatización de copias de seguridad, la compatibilidad con diferentes ubicaciones y medios de copia de seguridad y las capacidades de migración de datos son una adición importante a la capacidad existente de copia de seguridad y recuperación de OpenShift.

Capacidades integradas de copia de seguridad de OpenShift

No hay tantas soluciones de copia de seguridad completas en el mercado que también sean capaces de realizar operaciones de copia de seguridad y restauración de OpenShift – pero primero, tenemos que ver cuánto puede hacer el propio RedHat. Esta funcionalidad de copia de seguridad incorporada es lo que vamos a ampliar en primer lugar.

Copia de seguridad y recuperación del clúster OpenShift

Aquí existen dos caminos posibles: las operaciones de copia de seguridad y recuperación para los clústeres y esas mismas operaciones para las aplicaciones. Las operaciones de copia de seguridad de clústeres dependen en su totalidad de los datos etcd – un almacén clave-valor de OSCP (OpenShift Container Platform) que contiene información sobre todos los objetos de recursos dentro de un clúster.

Un administrador de clústeres puede tener que apagar o reiniciar clústeres en situaciones específicas, ya sea por motivos de mantenimiento o simplemente para ahorrar recursos ejecutando menos clústeres a la vez. El proceso de apagado de un clúster OpenShift se denomina a veces «apagado graceful», e incluye el apagado de los nodos del clúster con un comando de apagado dedicado, así como el apagado de todas las dependencias que ya no se utilizan con el clúster apagado.

También existe otro proceso llamado «reinicio graceful», que naturalmente es directamente opuesto a un apagado graceful, ya que está iniciando el clúster en lugar de pararlo. Este proceso en particular, sin embargo, puede ser un poco más complicado que su opuesto, con pasos como:

• Encender cualquier dependencia del clúster previamente desactivada;
• Encender el clúster.
• Iniciar la propia máquina de clúster;
• Verificar si los nodos del plano de control están listos;
• Verificar si los nodos trabajadores están listos;
• Verificar si el clúster en su conjunto arrancó correctamente o no.

Si el clúster no arrancara correctamente, la única solución sería utilizar una copia de seguridad etcd para restaurar el estado anterior del clúster.

Si bien es cierto que el apagado graceful debería permitir reiniciar el clúster con el mínimo esfuerzo, debería realizarse una copia de seguridad de etcd antes de todos y cada uno de los eventos de apagado del clúster. Las copias de seguridad de etcd desempeñan un papel importante en los escenarios de recuperación de desastres, y no sería posible restaurar un OSCP defectuoso sin una copia de seguridad de etcd involucrada en el proceso.

El proceso de copia de seguridad de etcd en sí es bastante sencillo e incluye tres pasos principales: iniciar una sesión de depuración, cambiar su directorio raíz a /host, y lanzar un script llamado «cluster-backup.sh«, al tiempo que se introduce la ubicación de la copia de seguridad.

El proceso de restauración del clúster, por otro lado, es algo más complicado, principalmente porque las restauraciones del clúster a través de la copia de seguridad de etcd se consideran una «opción de último recurso» que normalmente sólo debería utilizarse cuando nada más funciona para recuperar el estado de funcionamiento del clúster. Implica varios pasos, como

• Selección de un host de plano de control que vaya a realizar las operaciones de restauración;
• Configuración de la conectividad SSH con todos los nodos del plano de control, incluido el que se va a utilizar para la recuperación;
• Copiar manualmente la copia de seguridad de etcd al único host que se ha elegido como de recuperación;
• Acceder al host en cuestión;
• Ejecutar el script de restauración «cluster-restore.sh«;
• Comprobando si los nodos están en estado «listo»;
• Reinicio del servicio kubelet para todos los hosts del plano de control, incluido el de recuperación;
• Aprobar las CSR pendientes, verificando si el plano de control de un solo miembro está en funcionamiento;
• Borrar y volver a crear todos los equipos del plano de control, con la exclusión del elegido para la recuperación.

Esto nos lleva a la segunda parte de este largo proceso: comienza con el mismo usuario iniciando sesión en una ventana de terminal independiente con el rol «cluster-admin«. Las operaciones siguientes son:

• Forzar la redistribución de etcd;
• Verificar si los nodos están actualizados;
• Forzando nuevos despliegues en el plano de control (esto debería reinstalar la API de Kubernetes en todos los nodos ya que se utiliza un equilibrador de carga interno para conectar el kubelet con el servidor API);
• Y por último, pero no por ello menos importante, se verifica que todos los hosts del plano de control recién instalados funcionan y se han unido al clúster.
• Los nodos de la API de Kubernetes se reinstalan en el plano de control.

Es fácil ver cómo el proceso de restauración de la copia de seguridad de etcd es bastante largo y difícil, que es una de las razones por las que se trata como una opción de último recurso.

Ahora que hemos cubierto cómo funciona la copia de seguridad y recuperación de contenedores, veamos el proceso de copia de seguridad y recuperación de aplicaciones.

Copia de seguridad y recuperación de aplicaciones en OpenShift

El proceso de creación de copias de seguridad de aplicaciones en OpenShift también puede ser bastante complicado, pero no vamos a profundizar especialmente en él, ya que los puntos principales de este artículo son etcd y los clústeres. No obstante, vamos a examinar su lógica.

Las operaciones de copia de seguridad y restauración de aplicaciones dentro de OpenShift pueden realizarse con la ayuda de OADP, u OpenShift API for Data Protection. Utiliza Velero para realizar las tareas de copia de seguridad y restauración tanto de los recursos como de las imágenes internas, a la vez que es capaz de trabajar con volúmenes persistentes a través de Restic o con instantáneas.

Existe una lista muy específica de variantes de almacenamiento de las que se pueden realizar copias de seguridad con OADP: esta lista incluye MS Azure, AWS, GCP, Multicloud Object Gateway, así como varias variantes de almacenamiento de objetos compatibles con S3 (Minio, Noobaa, etc.). Al mismo tiempo, las copias de seguridad de instantáneas sólo pueden realizarse para AWS, Azure, GCP y el almacenamiento en la nube compatible con instantáneas CSI (Ceph FS, Ceph RBD, etc.), ya que sólo esos soportan la API de instantáneas de nivel nativo necesaria.

El proceso de copia de seguridad en sí implica la creación de un CR, o recurso personalizado, ya sea con fines de copia de seguridad o de restauración. Esta opción puede utilizarse para realizar copias de seguridad Restic, copias de seguridad programadas y para configurar ganchos de copia de seguridad/restauración que se ejecutarán antes o después de que se complete el proceso de copia de seguridad/restauración.

Opciones de copia de seguridad de terceros para OpenShift

Aunque el método de copia de seguridad/recuperación mencionado anteriormente es realmente posible, tiene problemas potenciales asociados, principalmente porque carece de funciones adicionales y puede resultar algo complicado para muchos usuarios. Por eso vamos a repasar también las soluciones de copia de seguridad ETCD de OpenShift de terceros, empezando por IBM Spectrum.

IBM Spectrum Protect Plus

IBM Spectrum Protect Plus es una solución integral de protección de datos que ofrece una gran variedad de funciones en el campo de la seguridad de los datos, como la copia de seguridad, la recuperación, la retención y la replicación para todo tipo de ubicaciones de destino, ya sean bases de datos, aplicaciones, máquinas virtuales, cargas de trabajo SaaS o incluso contenedores.

IBM Spectrum Protect es una solución bastante versátil, por lo que también puede funcionar con sistemas OpenShift. La solución de IBM es capaz de proteger no solo los volúmenes persistentes, sino también otros recursos dependientes del clúster de OpenShift. Aunque tiene una serie de requisitos para que las copias de seguridad de OpenShift funcionen en primer lugar, los requisitos en sí no son especialmente estrictos y en su mayoría incluyen un único requisito para que las diferentes partes del sistema de virtualización estén actualizadas en un grado específico.

IBM Spectrum Protect permite a sus usuarios registrar los clústeres de OpenShift manualmente, crear copias de seguridad de los datos de los contenedores de OpenShift y restaurarlos a partir de una instantánea o de una copia de seguridad normal, y también puede restaurar recursos específicos del espacio de nombres y del clúster o incluso anular la configuración de retención de copias de seguridad o instantáneas específicas mediante la caducidad de las sesiones del trabajo de copia de seguridad de OpenShift.

CronJob

A diferencia del resto de esta lista, CronJob no es exactamente una solución de copia de seguridad por sí misma. Un CronJob es una tarea que puede realizar acciones específicas siguiendo una programación concreta en sistemas basados en Unix. En este contexto concreto, un usuario de GitHub utiliza CronJob para realizar una serie de operaciones que tienen como resultado la creación de una copia de seguridad de OpenShift con el mismo método que hemos mencionado anteriormente (ejecutando cluster-backup.sh).

Este CronJob específico crea un pod que ejecuta el script mencionado para crear la copia de seguridad propiamente dicha. También copia toda la copia de seguridad a un PV preconfigurado y después expira el propio trabajo de copia de seguridad para evitar futuros conflictos. Crea dos archivos separados – uno es la colección de los pods estáticos en su conjunto con sus claves privadas y certificados, y el otro es la instantánea etcd. Como tal, este «método» en particular puede ser apodado como una solución de copia de seguridad ETCD de OpenShift.

Kasten K10

Kasten K10 es una plataforma de gestión de datos nativa de la nube como tipo de almacenamiento, que ofrece una variedad de opciones diferentes, tales como copias de seguridad, recuperación, movilidad de aplicaciones y recuperación de desastres a las aplicaciones Kubernetes, mientras que también es capaz de integrarse con una variedad de diferentes tipos de bases de datos, soporta múltiples proveedores de almacenamiento en la nube y puede trabajar con la mayoría de las distribuciones Kubernetes.

K10 también puede realizar operaciones de copia de seguridad y recuperación de OpenShift con relativa sencillez. La mayor diferencia aquí sería la creación de un Secreto – la versión propia de Kasten de una lista de copias de seguridad que incluye información sobre las etiquetas de pods etcd, el punto final del clúster etcd y todo lo demás de lo que hay que hacer una copia de seguridad. Aparte de eso, su proceso es algo similar a cómo K10 suele realizar las copias de seguridad – creando un Blueprint y utilizando un Secreto con un Blueprint para ejecutar la tarea de copia de seguridad. El proceso de restauración, por otro lado, es similar al que hemos tratado en la sección «métodos incorporados» de este artículo.

Storware Backup and Recovery

Storware Backup and Recovery es un software de protección de datos nativo de la nube que funciona muy bien cuando se trata de crear copias de seguridad de volúmenes persistentes o metadatos adjuntos a pods OpenShift. Tiene el estatus de Operador certificado de Red Hat OpenShift, lo que proporciona consistencia en sus esfuerzos de protección de datos, combinados con características como programación, modificación de políticas de copia de seguridad, automatización de copias de seguridad, etc. Es una gran solución de copia de seguridad y restauración OpenShift ETCD que cubre múltiples planos diferentes de los datos de OpenShift – el ya mencionado etcd, metadatos, volúmenes persistentes, y más.

Portworx Backup

Portworx es una plataforma de servicios de datos que se centra en el desarrollo de soluciones para los usuarios de Kubernetes para ayudar con la ejecución de aplicaciones en contenedores sin interrupciones y eventos de pérdida de datos. Ofrece un acceso más fácil a las copias de seguridad de las aplicaciones con coherencia y múltiples funciones, como la programación de copias de seguridad, RBAC, gestión de usuarios y mucho más. Portworx también puede ofrecer capacidades de recuperación de desastres, implementación de CSI, cifrado en todo el clúster, instantáneas, así como muchas otras características para clústeres y aplicaciones OpenShift.

Cloudcasa

Cloudcasa es un servicio de copia de seguridad resistente y potente con una gran escalabilidad y una interfaz fácil de usar. Puede ofrecer protección de datos multi-nube, múltiples opciones de ciber-resiliencia y varios tipos diferentes de copias de seguridad dentro de sus entornos OpenShift (recursos Kubernetes, copias de seguridad etcd e instantáneas CSI). Cloudcasa también puede realizar varios niveles diferentes de operaciones de recuperación, ya sea granular o a nivel de clúster, lo que la convierte en una solución de copia de seguridad y restauración de ETCD de OpenShift bastante cómoda y útil.

Dell EMC PowerProtect Data Manager

Dell EMC es una potencia tecnológica que ofrece una gran variedad de productos y servicios para múltiples mercados diferentes. PowerProtect Data Manager de Dell EMC es una solución versátil de protección de datos que admite varios tipos de entornos y puede trabajar con multitud de ubicaciones de almacenamiento diferentes. También es compatible con entornos OpenShift, ofreciendo protección para sus cargas de trabajo, además de ser una solución de copia de seguridad y restauración fiable y útil. Integra los entornos de OpenShift en su propia interfaz centralizada, proporcionando la capacidad de asignar políticas de protección a espacios de nombres, clústeres y todo lo demás que tiene OpenShift.

Bacula Enterprise

Bacula Enterprise es una solución de copia de seguridad empresarial única y altamente segura que admite una gama especialmente amplia de entornos y funciones a través de su sistema de «módulos». Uno de estos módulos fue creado específicamente para las operaciones integrales de copia de seguridad y restauración de OpenShift, proporcionando una variedad de características de protección de datos a los entornos OpenShift. Este módulo en concreto ofrece funciones como la salvaguarda del estado del clúster, la redistribución eficaz de los recursos del clúster, capacidades de recuperación de aplicaciones, restauración de datos de FV específicos, transferencia de configuraciones para otras operaciones, etc. Bacula Enterprise no sólo puede ser útil para salvaguardar sus datos OpenShift en su conjunto, sino que también puede facilitar los planes de recuperación ante desastres, ofrecer seguridad adicional a sus datos, ayudar con las tareas de migración de clústeres, ofrecer capacidades de replicación de entornos y mucho más. Cabe destacar que su modelo de licencia basado en suscripciones y su alta escalabilidad lo hacen ventajoso para despliegues medianos y grandes.

Conclusión

Los entornos OpenShift son extremadamente útiles en áreas y ámbitos de aplicación específicos, pero también es relativamente nuevo, lo que significa que salvaguardar los datos en él puede ser algo problemático. Dado que cada vez se despliegan más entornos Kubernetes de cualquier tipo, realizar copias de seguridad de sus datos -especialmente de sus datos persistentes- es cada vez más importante. En este artículo se analizan diferentes soluciones de copia de seguridad de OpenShift, incluidas las opciones integradas y de terceros que están disponibles, y puede resultar útil para encontrar una solución para un caso de uso específico del usuario.