Cómo compactar hasta un 90% de almacenamiento de copias de seguridad en el almacenamiento de objetos

Nuestros clientes turcos nos pidieron que configuremos la copia de seguridad para el centro de datos correctamente. Estamos haciendo proyectos similares en Rusia, pero fue aquí donde la historia fue más sobre investigar la mejor manera de hacerlo.

Dado: hay un almacenamiento local S3, hay Veritas NetBackup, que ha adquirido una nueva funcionalidad avanzada para mover datos a tiendas de objetos ahora con soporte de deduplicación, y hay un problema con el espacio libre en este almacenamiento local.

Objetivo: hacer todo para que el proceso de almacenamiento de respaldo sea rápido y económico.

En realidad, antes de eso, en S3 todo eran solo archivos, y estos eran modelos completos de máquinas críticas de centros de datos. No es que esté muy optimizado, pero todo funcionó desde el principio. Ahora es el momento de resolverlo y hacerlo bien.

En la imagen, a lo que hemos llegado:



Como puede ver, la primera copia de seguridad se realizó lentamente (70 Mb / s), y las copias de seguridad posteriores de los mismos sistemas fueron mucho más rápidas.

En realidad, un poco más de detalles sobre qué características hay.

Cual es el problema

Los clientes desean realizar copias de seguridad con la mayor frecuencia posible y almacenar de la manera más económica posible. Es barato almacenarlos mejor en el almacenamiento de objetos de tipo S3, porque son los más baratos al precio de mantenimiento por megabyte desde donde puede retroceder en un período de tiempo razonable. Cuando hay muchas copias de seguridad, no es muy barato, porque la mayor parte del almacenamiento está ocupado por copias de los mismos datos. En el caso de HaaS de colegas turcos, el almacenamiento puede densificarse en aproximadamente un 80-90%. Está claro que esto se aplica específicamente a sus detalles, pero definitivamente contaría con al menos el 50% de la deducción.

Para resolver el problema, los principales proveedores han creado puertas de enlace en Amazon S3. Todos sus métodos son compatibles con S3 local si son compatibles con la API de Amazon. En el centro de datos turco, la copia de seguridad se realiza en nuestro S3, así como en el "Compresor" T-III en Rusia, ya que dicho esquema de trabajo demostró ser bueno con nosotros.

Y nuestro S3 es totalmente compatible con los métodos de copia de seguridad en Amazon S3. Es decir, todas las herramientas de respaldo que admiten estos métodos le permiten copiar todo a ese almacenamiento "listo para usar".

Veritas NetBackup creó una característica de CloudCatalyst:



Es decir, entre las máquinas que necesitan copia de seguridad y la puerta de enlace hay un servidor Linux intermedio a través del cual pasa el tráfico de copia de seguridad de los agentes de CPC y la deduplicación se realiza sobre la marcha antes de transferirlos a S3. Si antes había 30 copias de seguridad de 20 GB cada una con compresión, ahora (debido a la similitud de las máquinas) se han vuelto un 90% más pequeñas en volumen. El motor de deduplicación se usa igual que cuando se almacena en discos normales con Netbackup.

Esto es lo que sucede antes del servidor provisional:



Probamos y llegamos a la conclusión de que cuando se implementa en nuestros centros de datos, esto ahorra espacio en los almacenes S3 para nosotros y para los clientes. Como propietario de los centros de datos comerciales, por supuesto, cobramos por el volumen ocupado, pero aún así es muy rentable para nosotros, porque comenzamos a ganar lugares más escalables en el software y no en el alquiler de hierro. Bueno, esto es una reducción en los costos internos.


El acelerador le permite reducir el tráfico de los agentes, porque solo se transmiten los cambios de datos, es decir, incluso las copias de seguridad completas no se vuelven completas, ya que el servidor de medios recopila las copias de seguridad completas posteriores de las copias de seguridad incrementales.

El servidor intermedio tiene su propio repositorio donde escribe un "caché" de datos y contiene la base para la deduplicación.

En arquitectura completa, se ve así:

1. El servidor maestro administra la configuración, las actualizaciones y más, y se encuentra en la nube.
2. El servidor de medios (máquina intermedia * nix) debe ubicarse más cerca de los sistemas redundantes en términos de disponibilidad de red. Aquí las copias de seguridad se deduplican de todas las máquinas redundantes.
3. Hay agentes en las máquinas redundantes que generalmente envían al servidor de medios solo lo que no está en su almacenamiento.

Todo comienza con un escaneo completo: esta es una copia de seguridad completa. En este punto, el servidor de medios toma todo, lo deduplica y lo transfiere a S3. La velocidad para el servidor de medios es baja, desde allí, más alta. La principal limitación es la potencia de procesamiento del servidor.

Las siguientes copias de seguridad se completan desde el punto de vista de todos los sistemas, pero en realidad es algo así como copias de seguridad completas sintéticas. Es decir, la transferencia y la grabación reales en el servidor de medios son solo aquellos bloques de datos que aún no se han visto en las copias de seguridad de VM. Y la transferencia y grabación a S3 son solo aquellos bloques de datos cuyo hash no está en la base de datos de deduplicación del servidor de medios. En palabras más simples, que antes no había máquinas virtuales en ninguna copia de seguridad.

Al restaurar, el servidor de medios solicita los objetos deduplicados necesarios de S3, los rehidrata y los pasa a los agentes de CPC, es decir Es necesario tener en cuenta el volumen de tráfico durante la restauración, que será igual al volumen real de datos que se está restaurando.

Así es como se ve:




La integridad de los datos está garantizada por la protección de S3 en sí misma: existe una buena redundancia para proteger contra fallas de hardware, como un eje muerto del disco duro.

El servidor de medios necesita 4 terabytes de caché; esta es la recomendación de Veritas para el tamaño mínimo. Mejor aún, pero acabamos de hacer eso.

Resumen

Cuando un socio lanzó 20 GB a nuestro S3, almacenamos 60 GB, porque proporcionamos tres veces la geo-reserva de datos. Ahora el tráfico es mucho menor, lo cual es bueno tanto para el canal como para la carga de almacenamiento.

En este caso, las rutas se cierran más allá de la "gran Internet", pero puede conducir el tráfico a través de VPN L2 a través de Internet, pero es mejor configurar el servidor de medios en la entrada del proveedor.

Si está interesado en conocer estas características en nuestros centros de datos rusos o si tiene preguntas sobre su implementación, pregunte en los comentarios o ekorotkikh@croc.ru.