Nuestros clientes turcos nos pidieron que configuremos correctamente la copia de seguridad para su centro de datos. Estamos realizando proyectos similares en Rusia, pero aquí la historia se centró más en investigar la mejor manera de hacerlo.
Dado: hay un almacenamiento S3 local, está Veritas NetBackup, que ha adquirido una nueva funcionalidad ampliada para mover datos al almacenamiento de objetos, ahora con soporte para deduplicación, y hay un problema con el espacio libre en este almacenamiento local.
Tarea: hacer todo para que el proceso de almacenamiento de copias de seguridad sea rápido y económico.
En realidad, antes de esto, todo en S3 eran simplemente archivos, y estos eran moldes completos de las máquinas críticas del centro de datos. Es decir, no está muy optimizado, pero todo funcionó al principio. Ahora es el momento de resolverlo y hacerlo bien.
La imagen muestra a lo que llegamos:
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.
De hecho, más adelante hay un poco más de detalles sobre qué características hay.
Registros de respaldo para aquellos que están listos para leer media página del volcadoCompleto con reescaneo
18 de diciembre de 2018 12:09:43 p. m. - El acelerador de información bpbkar (pid = 4452) envió 14883996160 bytes de 14883994624 bytes al servidor, optimización 0.0%
18 de diciembre de 2018 12:10:07 p. m. - Información NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Informe=Estadísticas de PDDO (secuencia multiproceso utilizada) para (NBCC): escaneado: 14570817 KB, CR enviado: 1760761 KB, CR enviado a través de FC: 0 KB, deduplicación: 87.9 %, caché deshabilitada
Full
18 de diciembre de 2018 12:13:18 p. m. - El acelerador de información bpbkar (pid = 2864) envió 181675008 bytes de 14884060160 bytes al servidor, optimización 98.8%
18 de diciembre de 2018 12:13:40 p. m. - Información NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Informe=Estadísticas de PDDO para (NBCC): escaneado: 14569706 KB, CR enviado: 45145 KB, CR enviado a través de FC: 0 KB, deduplicación: 99.7 %, caché deshabilitada
Incremental
18 de diciembre de 2018 12:15:32 p. m. - El acelerador de información bpbkar (pid = 792) envió 9970688 bytes de 14726108160 bytes al servidor, optimización 99.9%
18 de diciembre de 2018 12:15:53 p. m. - Información NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Informe=Estadísticas de PDDO para (NBCC): escaneado: 14383788 KB, CR enviado: 15700 KB, CR enviado a través de FC: 0 KB, deduplicación: 99.9 %, caché deshabilitada
Full
18 de diciembre de 2018 12:18:02 p. m. - El acelerador de información bpbkar (pid = 3496) envió 171746816 bytes de 14884093952 bytes al servidor, optimización 98.8%
18 de diciembre de 2018 12:18:24 p. m. - Información NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Informe=Estadísticas de PDDO para (NBCC): escaneado: 14569739 KB, CR enviado: 34120 KB, CR enviado a través de FC: 0 KB, deduplicación: 99.8 %, caché deshabilitada
Cuál es el problema
Los clientes quieren realizar copias de seguridad con la mayor frecuencia posible y almacenarlas lo más barato posible. Es mejor almacenarlos de forma económica en almacenamientos de objetos como S3, porque son los más baratos en términos de costo de servicio por megabyte, desde donde puede revertir una copia de seguridad en un tiempo razonable. Cuando hay muchas copias de seguridad, no resultan muy baratas, porque la mayor parte del almacenamiento está ocupada por copias de los mismos datos. En el caso del HaaS de sus colegas turcos, el almacenamiento se puede densificar aproximadamente entre un 80 y un 90 %. Está claro que esto se relaciona específicamente con sus detalles, pero definitivamente contaría con al menos un 50% de abuelo.
Para solucionar el problema, los principales proveedores llevan tiempo creando puertas de enlace a Amazon S3. Todos sus métodos son compatibles con S3 local siempre que admitan la API de Amazon. En el centro de datos turco se realiza una copia de seguridad en nuestro S3, así como en el “Compresor” T-III en Rusia, ya que este esquema de trabajo nos ha funcionado bien.
Y nuestro S3 es totalmente compatible con los métodos de copia de seguridad de Amazon S3. Es decir, todas las herramientas de respaldo que admiten estos métodos le permiten copiar todo a dicho almacenamiento "listo para usar".
Veritas NetBackup agregó la función CloudCatalyst:
Es decir, entre las máquinas de las que se debe realizar una 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 SRK y se deduplica sobre la marcha antes de transferirlo a S3. Si antes había 30 copias de seguridad de 20 GB con compresión, ahora (debido a la similitud de las máquinas) su volumen se ha reducido en un 90%. El motor de deduplicación se usa igual que cuando se almacena en discos normales usando Netbackup.
Esto es lo que sucede antes del servidor intermedio:
Probamos y llegamos a la conclusión de que, cuando se implementa en nuestros centros de datos, esto ahorra espacio en el almacenamiento S3 para nosotros y para los clientes. Como propietarios de centros de datos comerciales, por supuesto, cobramos según el volumen ocupado, pero también es muy rentable para nosotros, porque empezamos a ganar dinero con lugares más escalables en software, y no con el alquiler de hardware. Bueno, y esto es una reducción de costes internos.
Registros228 trabajos (0 en cola 0 activos 0 en espera de reintento 0 suspendidos 0 incompletos 228 completados: 13 seleccionados)
(Filtro aplicado [13])
Tipo de ID de trabajo Estado Detalles de estado Estado Política de trabajo Programación de trabajos Cliente Servidor de medios Hora de inicio Tiempo transcurrido Hora de finalización Intento de unidad de almacenamiento Operación Kilobytes Archivos Nombre de ruta % completado (estimado) Propietario de PID del trabajo Copiar ID de trabajo principal KB/Seg Inicio activo Activo Transcurrido Perfil de Robot Vault Sesión ID Medios para expulsar movimiento de datos Tipo fuera del host Prioridad maestra Tasa de deduplicación Acelerador de transporte Optimización Instancia o base de datos Host compartido
- 1358 Instantánea hecha 0 VMware - NGNCloudADC NBCC 18 de diciembre de 2018 12:16:19 p. m. 00:02:18 18 de diciembre de 2018 12:18:37 p. m. STU_DP_S3_****backup 1 100% root 1358 18 de diciembre de 2018 12 :16:27 PM 00:02:10 Disco de recuperación instantánea Estándar WIN-*********** 0
1360 Copia de seguridad realizada 0 VMware Full NGNCloudADC NBCC 18 de diciembre de 2018 12:16:48 p. m. 00:01:39 18 de diciembre de 2018 12:18:27 p. m. STU_DP_S3_****backup 1 14,535,248 149654 100% 23858 root 1358 335,098 18 2018 de diciembre , 12 16:48:00 p.m. 01:39:0 Disco de recuperación instantánea Estándar WIN-*********** 99.8 99% XNUMX%
1352 Instantánea hecha 0 VMware - NGNCloudADC NBCC 18 de diciembre de 2018 12:14:04 p. m. 00:02:01 18 de diciembre de 2018 12:16:05 p. m. STU_DP_S3_****backup 1 100% raíz 1352 18 de diciembre de 2018 12: 14:14 p.m. 00:01:51 Disco de recuperación instantánea Estándar WIN-*********** 0
1354 Copia de seguridad realizada 0 VMware Incremental NGNCloudADC NBCC 18 de diciembre de 2018 12:14:34 p. m. 00:01:21 18 de diciembre de 2018 12:15:55 p. m. STU_DP_S3_****copia de seguridad 1 14,380,965 147 100% 23617 raíz 1352 500,817 ,18 2018 de diciembre , 12 14:34:00 p.m. 01:21:0 Disco de recuperación instantánea Estándar WIN-*********** 99.9 100% XNUMX%
1347 Instantánea hecha 0 VMware - NGNCloudADC NBCC 18 de diciembre de 2018 12:11:45 p. m. 00:02:08 18 de diciembre de 2018 12:13:53 p. m. STU_DP_S3_****backup 1 100% raíz 1347 18 de diciembre de 2018 12: 11:45 p.m. 00:02:08 Disco de recuperación instantánea Estándar WIN-*********** 0
1349 Copia de seguridad realizada 0 VMware Full NGNCloudADC NBCC 18 de diciembre de 2018 12:12:02 p. m. 00:01:41 18 de diciembre de 2018 12:13:43 p. m. STU_DP_S3_****backup 1 14,535,215 149653 100% 23508 root 1347 316,319 18 2018 de diciembre , 12 12:02:00 p.m. 01:41:0 Disco de recuperación instantánea Estándar WIN-*********** 99.7 99% XNUMX%
1341 Instantánea hecha 0 VMware - NGNCloudADC NBCC 18 de diciembre de 2018 12:05:28 p. m. 00:04:53 18 de diciembre de 2018 12:10:21 p. m. STU_DP_S3_****backup 1 100% raíz 1341 18 de diciembre de 2018 12: 05:28 p.m. 00:04:53 Disco de recuperación instantánea Estándar WIN-*********** 0
1342 Copia de seguridad realizada 0 VMware Full_Rescan NGNCloudADC NBCC 18 de diciembre de 2018 12:05:47 p. m. 00:04:24 18 de diciembre de 2018 12:10:11 p. m. STU_DP_S3_****copia de seguridad 1 14,535,151 149653 100% 22999 raíz 1341 70,380 18 2018 dic 12, 05 47:00:04 p.m. 24:0:87.9 Disco de recuperación instantánea Estándar WIN-********** 0 XNUMX% XNUMX%
1339 Instantánea realizada 150 VMware - NGNCloudADC NBCC 18 de diciembre de 2018 11:05:46 a. m. 00:00:53 18 de diciembre de 2018 11:06:39 a. m. STU_DP_S3_****backup 1 100% root 1339 18 de diciembre de 2018 11: 05:46 AM 00:00:53 Disco de recuperación instantánea Estándar WIN-*********** 0
1327 Instantánea realizada 0 VMware - *******.*********.cloud NBCC 17 de diciembre de 2018 12:54:42 p. m. 05:51:38 17 de diciembre de 2018 6:46:20 p. m. STU_DP_S3_****backup 1 100% raíz 1327 17 de diciembre de 2018 12:54:42 p.m. 05:51:38 Instant Recovery Disk Estándar WIN-*********** 0
1328 Copia de seguridad realizada 0 VMware completo *******.********.cloud NBCC 17 de diciembre de 2018 12:55:10 p. m. 05:29:21 17 de diciembre de 2018 6:24:31 p. m. STU_DP_S3_****backup 1 222,602,719 258932 100% 12856 root 1327 11,326 17 de diciembre de 2018 12:55:10 p. m. 05:29:21 Instant Recovery Disk Standard WIN-*********** 0 87.9% 0%
1136 Instantánea realizada 0 VMware - *******.*********.cloud NBCC 14 de diciembre de 2018 4:48:22 p. m. 04:05:16 14 de diciembre de 2018 8:53:38 p. m. STU_DP_S3_****backup 1 100% raíz 1136 14 de diciembre de 2018 4:48:22 p.m. 04:05:16 Instant Recovery Disk Estándar WIN-*********** 0
1140 Copia de seguridad realizada 0 VMware Full_Scan *******.********.cloud NBCC 14 de diciembre de 2018 4:49:14 p. m. 03:49:58 14 de diciembre de 2018 8:39:12 p. m. STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 14 de diciembre de 2018 4:49:14 p.m. 03:49:58 Instant Recovery Disk Standard WIN-*********** 0 45.2% 0%
El acelerador le permite reducir el tráfico de los agentes, porque Sólo se transmiten los cambios de datos, es decir, ni siquiera las copias de seguridad completas se cargan en su totalidad, ya que el servidor de medios recopila las copias de seguridad completas posteriores a partir de copias de seguridad incrementales.
El servidor intermedio tiene su propio almacenamiento, donde escribe un "caché" de datos y mantiene una base de datos para la deduplicación.
La arquitectura completa se ve así:
- El servidor maestro gestiona la configuración, actualizaciones, etc. y está ubicado en la nube.
- El servidor de medios (máquina intermedia *nix) debe ubicarse lo más cerca posible de los sistemas redundantes en términos de accesibilidad a la red. Aquí se realiza la deduplicación de las copias de seguridad de todas las máquinas reservadas.
- En las máquinas respaldadas hay agentes que generalmente envían al servidor de medios solo lo que no está en su almacenamiento.
Todo comienza con un análisis completo: se trata de una copia de seguridad completa. En este punto, el servidor de medios toma todo, lo deduplica y lo transfiere a S3. La velocidad hacia el servidor de medios es baja, pero desde allí es mayor. La principal limitación es la potencia informática del servidor.
Las siguientes copias de seguridad se realizan completas desde el punto de vista de todos los sistemas, pero en realidad son algo así como copias de seguridad completas sintéticas. Es decir, la transferencia y grabación real al servidor de medios ocurre solo de aquellos bloques de datos que aún no se han encontrado en las copias de seguridad de VM anteriormente. Y sólo aquellos bloques de datos cuyo hash no está en la base de datos de deduplicación del servidor de medios se transfieren y registran en S3. En palabras más simples, esto es algo que nunca antes se había visto en ninguna copia de seguridad de una sola máquina virtual.
Durante la restauración, el servidor de medios solicita los objetos deduplicados necesarios de S3, los rehidrata y los transfiere a los agentes IRB, 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án restaurando.
Así es como se ve:
Y aquí hay otro trozo de troncos.169 trabajos (0 en cola 0 activos 0 en espera de reintento 0 suspendidos 0 incompletos 169 completados: 1 seleccionados)
Tipo de ID de trabajo Estado Detalles de estado Estado Política de trabajo Programación de trabajos Cliente Servidor de medios Hora de inicio Tiempo transcurrido Hora de finalización Intento de unidad de almacenamiento Operación Kilobytes Archivos Nombre de ruta % completado (estimado) Propietario de PID del trabajo Copiar ID de trabajo principal KB/Seg Inicio activo Activo Transcurrido Perfil de Robot Vault Sesión ID Medios para expulsar movimiento de datos Tipo fuera del host Prioridad maestra Tasa de deduplicación Acelerador de transporte Optimización Instancia o base de datos Host compartido
- 1372 Restaurar hecho 0 NBPR01 NBCC 19 de diciembre de 2018 1:05:58 p.m. 00:04:32 19 de diciembre de 2018 1:10:30 p.m. 1 14,380,577 1 100% 8548 ROOT 1372 70,567 19 de diciembre de 2018 1:06 :00 PM 00:04:30 GANAR-*********** 90000
La integridad de los datos está garantizada por la protección del propio S3: existe una buena redundancia para proteger contra fallas de hardware, como un eje de disco duro muerto.
El servidor de medios necesita 4 TB de caché; esta es la recomendación de tamaño mínimo de Veritas. Más es mejor, pero eso es lo que hicimos.
Total
Cuando un socio invirtió 3 GB en nuestro S20, almacenamos 60 GB, porque brindamos triple reserva geográfica de datos. Ahora hay mucho menos tráfico, lo que es bueno tanto para el canal como para las tarifas de almacenamiento.
En este caso, las rutas más allá de la "gran Internet" están cerradas, pero puede dirigir el tráfico a través de VPN L2 a través de Internet, pero es mejor instalar el servidor de medios antes de la entrada del proveedor.
Si está interesado en conocer estas características en nuestros centros de datos rusos o tiene preguntas sobre la implementación en casa, pregunte en los comentarios o por correo electrónico. [email protected].
Fuente: habr.com