Nuestros clientes turcos nos pidieron que configuráramos correctamente la copia de seguridad para el centro de datos. Realizamos proyectos similares en Rusia, pero aquí la historia se trató más de investigar cómo hacerlo de la mejor manera.
Dado: hay un almacenamiento S3 local, hay Veritas NetBackup, que ha adquirido una nueva funcionalidad avanzada para mover datos a almacenamiento de objetos ahora con soporte de deduplicación, y hay un problema con el espacio libre en este almacenamiento local.
Tarea: hacer todo de manera que el proceso de almacenamiento de copias de seguridad sea rápido y económico.
De hecho, antes en S3 todo se almacenaba como archivos, siendo copias completas de las máquinas críticas del centro de datos. No era lo más optimizado, pero al menos funcionaba desde el inicio. Ahora ha llegado el momento de entender y hacerlo bien.
En la imagen está lo que hemos logrado:
Como se puede ver, la primera copia de seguridad se realizó lentamente (70 MB/s), mientras que las copias de seguridad subsiguientes de los mismos sistemas fueron significativamente más rápidas.
De hecho, aquí hay un poco más de detalles sobre las características allí.
Registros de copias de seguridad para aquellos que están listos para leer la mitad de una página de volcado.Completo con reescaneo
18 de diciembre de 2018 12:09:43 PM — Info bpbkar (pid=4452) el acelerador envió 14883996160 bytes de 14883994624 bytes al servidor, optimización 0.0%
18 de diciembre de 2018 12:10:07 PM — Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Informe=Estadísticas PDDO (stream multicore usado) para (NBCC): escaneado: 14570817 KB, CR enviado: 1760761 KB, CR enviado por FC: 0 KB, deduplicación: 87.9%, caché desactivada
Completo
18 de diciembre de 2018 12:13:18 PM — Info bpbkar (pid=2864) el acelerador envió 181675008 bytes de 14884060160 bytes al servidor, optimización 98.8%
18 de diciembre de 2018 12:13:40 PM — Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Informe=Estadísticas PDDO para (NBCC): escaneado: 14569706 KB, CR enviado: 45145 KB, CR enviado por FC: 0 KB, deduplicación: 99.7%, caché desactivada
Incremental
18 de diciembre de 2018 12:15:32 PM — Info bpbkar (pid=792) el acelerador envió 9970688 bytes de 14726108160 bytes al servidor, optimización 99.9%
18 de diciembre de 2018 12:15:53 PM — Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Informe=Estadísticas PDDO para (NBCC): escaneado: 14383788 KB, CR enviado: 15700 KB, CR enviado por FC: 0 KB, deduplicación: 99.9%, caché desactivada
Completo
18 de diciembre de 2018 12:18:02 PM — Info bpbkar (pid=3496) el acelerador envió 171746816 bytes de 14884093952 bytes al servidor, optimización 98.8%
18 de diciembre de 2018 12:18:24 PM — Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Informe=Estadísticas PDDO para (NBCC): escaneado: 14569739 KB, CR enviado: 34120 KB, CR enviado por FC: 0 KB, deduplicación: 99.8%, caché desactivada
¿Cuál es el problema?
Los clientes quieren hacer copias de seguridad tan a menudo como sea posible y almacenarlas de la manera más económica. Es más rentable almacenarlas en almacenes de objetos como S3, ya que son los más asequibles en términos de costo de mantenimiento por megabyte, desde donde se puede restaurar la copia de seguridad en un tiempo razonable. Cuando hay muchas copias de seguridad, esto se vuelve un poco caro, ya que la mayor parte del almacenamiento se ocupa por copias de los mismos datos. En el caso de HaaS, los colegas turcos pueden lograr una compresión del almacenamiento de aproximadamente el 80-90%. Es evidente que esto se refiere a su especificidad, pero al menos un 50% de deduplicación definitivamente se puede considerar.
Para abordar el problema, los principales proveedores han creado gateways para Amazon S3 desde hace tiempo. Todos sus métodos son compatibles con S3 locales, siempre que soporten la API de Amazon. En el centro de datos turco, la copia de seguridad se realiza en nuestro S3, al igual que en T-III 'Compresor' en Rusia, ya que este esquema de trabajo ha demostrado ser eficaz para nosotros.
Nuestro S3 es completamente compatible con los métodos de copia de seguridad en Amazon S3. Es decir, todas las herramientas de copia de seguridad que soportan estos métodos permiten copiar todo a un almacenamiento similar 'de serie'.
En Veritas NetBackup, implementaron una función llamada CloudCatalyst:
Es decir, entre las máquinas que necesitan ser respaldadas y el gateway se coloca un servidor intermedio con Linux, a través del cual pasa el tráfico de copia de seguridad de los agentes SRK y se realiza la deduplicación 'sobre la marcha' antes de enviarlos a S3. Si anteriormente 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%. Se utiliza el mismo motor de deduplicación que al almacenar en discos normales con las herramientas de NetBackup.
Esto es lo que sucede antes del servidor intermedio:
Hemos probado y concluido que al implementar esto en nuestros centros de datos, se obtiene un ahorro de espacio en los almacenes S3 tanto para nosotros como para los clientes. Como propietario de centros de datos comerciales, por supuesto, cobramos según el volumen ocupado, pero sigue siendo muy beneficioso para nosotros también, ya que comenzamos a obtener ganancias en lugares más escalables en software, y no en el alquiler de hardware. Además, esto reduce los costos internos.
Registros228 Jobs (0 en cola 0 activos 0 esperando reintento 0 suspendidos 0 incompletos 228 completos — 13 seleccionados)
(Filtro aplicado [13])
ID de trabajo Tipo Estado Detalles del estado Estado Política de trabajo Programación del trabajo Cliente Medios Servidor Hora de inicio Tiempo transcurrido Hora de finalización Unidad de almacenamiento Intento Operación Kilobytes Archivos Nombre de ruta % Completado (Estimado) PID del trabajo Propietario Copiar ID del trabajo padre KB/Sec Activo Inicio Activo Transcurrido Robot Perfil de bóveda ID de sesión Medios a expulsar Movimiento de datos Fuera del host Tipo Maestro Prioridad Tasa de desduplicación Acelerador de transporte Optimización Instancia o base de datos Compartir Host
— 1358 Instantánea Hecha 0 VMware — NGNCloudADC NBCC 18 de diciembre de 2018 12:16:19 PM 00:02:18 18 de diciembre de 2018 12:18:37 PM STU_DP_S3_****backup 1 100% root 1358 18 de diciembre de 2018 12:16:27 PM 00:02:10 Recuperación Instantánea Disco Estándar WIN-*********** 0
1360 Copia de seguridad Hecha 0 VMware Completa NGNCloudADC NBCC 18 de diciembre de 2018 12:16:48 PM 00:01:39 18 de diciembre de 2018 12:18:27 PM STU_DP_S3_****backup 1 14,535,248 149654 100% 23858 root 1358 335,098 18 de diciembre de 2018 12:16:48 PM 00:01:39 Recuperación Instantánea Disco Estándar WIN-*********** 0 99.8% 99%
1352 Instantánea Hecha 0 VMware — NGNCloudADC NBCC 18 de diciembre de 2018 12:14:04 PM 00:02:01 18 de diciembre de 2018 12:16:05 PM STU_DP_S3_****backup 1 100% root 1352 18 de diciembre de 2018 12:14:14 PM 00:01:51 Recuperación Instantánea Disco Estándar WIN-*********** 0
1354 Copia de seguridad Hecha 0 VMware Incremental NGNCloudADC NBCC 18 de diciembre de 2018 12:14:34 PM 00:01:21 18 de diciembre de 2018 12:15:55 PM STU_DP_S3_****backup 1 14,380,965 147 100% 23617 root 1352 500,817 18 de diciembre de 2018 12:14:34 PM 00:01:21 Recuperación Instantánea Disco Estándar WIN-*********** 0 99.9% 100%
1347 Instantánea Hecha 0 VMware — NGNCloudADC NBCC 18 de diciembre de 2018 12:11:45 PM 00:02:08 18 de diciembre de 2018 12:13:53 PM STU_DP_S3_****backup 1 100% root 1347 18 de diciembre de 2018 12:11:45 PM 00:02:08 Recuperación Instantánea Disco Estándar WIN-*********** 0
1349 Copia de seguridad Hecha 0 VMware Completa NGNCloudADC NBCC 18 de diciembre de 2018 12:12:02 PM 00:01:41 18 de diciembre de 2018 12:13:43 PM STU_DP_S3_****backup 1 14,535,215 149653 100% 23508 root 1347 316,319 18 de diciembre de 2018 12:12:02 PM 00:01:41 Recuperación Instantánea Disco Estándar WIN-*********** 0 99.7% 99%
1341 Instantánea Hecha 0 VMware — NGNCloudADC NBCC 18 de diciembre de 2018 12:05:28 PM 00:04:53 18 de diciembre de 2018 12:10:21 PM STU_DP_S3_****backup 1 100% root 1341 18 de diciembre de 2018 12:05:28 PM 00:04:53 Recuperación Instantánea Disco Estándar WIN-*********** 0
1342 Copia de seguridad Hecha 0 VMware Respaldo Completo NGNCloudADC NBCC 18 de diciembre de 2018 12:05:47 PM 00:04:24 18 de diciembre de 2018 12:10:11 PM STU_DP_S3_****backup 1 14,535,151 149653 100% 22999 root 1341 70,380 18 de diciembre de 2018 12:05:47 PM 00:04:24 Recuperación Instantánea Disco Estándar WIN-*********** 0 87.9% 0%
1339 Instantánea Hecha 150 VMware — NGNCloudADC NBCC 18 de diciembre de 2018 11:05:46 AM 00:00:53 18 de diciembre de 2018 11:06:39 AM STU_DP_S3_****backup 1 100% root 1339 18 de diciembre de 2018 11:05:46 AM 00:00:53 Recuperación Instantánea Disco Estándar WIN-*********** 0
1327 Instantánea Hecha 0 VMware — *******.********.cloud NBCC 17 de diciembre de 2018 12:54:42 PM 05:51:38 17 de diciembre de 2018 6:46:20 PM STU_DP_S3_****backup 1 100% root 1327 17 de diciembre de 2018 12:54:42 PM 05:51:38 Recuperación Instantánea Disco Estándar WIN-*********** 0
1328 Copia de seguridad Hecha 0 VMware Completa *******.********.cloud NBCC 17 de diciembre de 2018 12:55:10 PM 05:29:21 17 de diciembre de 2018 6:24:31 PM STU_DP_S3_****backup 1 222,602,719 258932 100% 12856 root 1327 11,326 17 de diciembre de 2018 12:55:10 PM 05:29:21 Recuperación Instantánea Disco Estándar WIN-*********** 0 87.9% 0%
1136 Instantánea Hecha 0 VMware — *******.********.cloud NBCC 14 de diciembre de 2018 4:48:22 PM 04:05:16 14 de diciembre de 2018 8:53:38 PM STU_DP_S3_****backup 1 100% root 1136 14 de diciembre de 2018 4:48:22 PM 04:05:16 Recuperación Instantánea Disco Estándar WIN-*********** 0
1140 Copia de seguridad Hecha 0 VMware Escaneo Completo *******.********.cloud NBCC 14 de diciembre de 2018 4:49:14 PM 03:49:58 14 de diciembre de 2018 8:39:12 PM STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 14 de diciembre de 2018 4:49:14 PM 03:49:58 Recuperación Instantánea Disco Estándar WIN-*********** 0 45.2% 0%
El acelerador permite reducir el tráfico de los agentes, ya que solo se transmiten los cambios de datos, es decir, ni siquiera las copias de seguridad completas se transfieren 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 el «caché» de datos y mantiene la base para la deduplicación.
En la arquitectura completa se ve así:
- El servidor maestro gestiona la configuración, las actualizaciones y otros aspectos y se encuentra en la nube.
- El servidor de medios (máquina intermedia *nix) debe estar lo más cerca posible de los sistemas a respaldar en términos de disponibilidad de red. Aquí se realiza la deduplicación de las copias de seguridad de todas las máquinas que se respaldan.
- En las máquinas que se respaldan hay agentes que, en general, envían al servidor de medios solo lo que no está en su almacenamiento.
Todo comienza con un escaneo completo: esto es una copia de seguridad completa. En este momento, el servidor de medios recoge todo, realiza la deduplicación y lo envía a S3. La velocidad hacia el servidor de medios es baja, desde él es mayor. La principal limitación es la potencia de cálculo del servidor.
Las siguientes copias de seguridad se realizan desde el punto de vista de todos los sistemas como completas, pero en realidad son algo así como copias de seguridad completas sintéticas. Es decir, la transferencia y grabación real en el servidor de medios solo incluyen los bloques de datos que aún no se han encontrado en las copias de seguridad de la máquina virtual anteriormente. Y la transmisión y grabación en S3 solo involucra aquellos bloques de datos cuyo hash no está en la base de deduplicación del servidor de medios. En términos más simples, se refiere a lo que no se ha encontrado en ninguna copia de seguridad de ninguna máquina virtual anteriormente.
Durante la restauración, el servidor de medios solicita los objetos deduplicados necesarios a S3, los regenera y los envía a los agentes SRK, es decir, se debe considerar 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 fragmento de registros169 trabajos (0 en cola, 0 activos, 0 esperando reintento, 0 suspendidos, 0 incompletos, 169 realizados — 1 seleccionado)
ID de trabajo Tipo Estado Detalles del estado Estado Política de trabajo Programación del trabajo Cliente Medios Servidor Hora de inicio Tiempo transcurrido Hora de finalización Unidad de almacenamiento Intento Operación Kilobytes Archivos Nombre de ruta % Completado (Estimado) PID del trabajo Propietario Copiar ID del trabajo padre KB/Sec Activo Inicio Activo Transcurrido Robot Perfil de bóveda ID de sesión Medios a expulsar Movimiento de datos Fuera del host Tipo Maestro Prioridad Tasa de desduplicación Acelerador de transporte Optimización Instancia o base de datos Compartir Host
— 1372 restauraciones completas 0 nbpr01 NBCC 19 de diciembre de 2018 1:05:58 PM 00:04:32 19 de diciembre de 2018 1:10:30 PM 1 14,380,577 1 100% 8548 root 1372 70,567 19 de diciembre de 2018 1:06:00 PM 00:04:30 WIN-*********** 90000
La integridad de los datos se asegura con la protección del propio S3; allí hay una buena redundancia para protegerse contra fallos de hardware como la falla de un disco duro.
Medios -servidor se requieren 4 TB de caché — esta es la recomendación de Veritas sobre el volumen mínimo. Es mejor tener más, pero nosotros lo hicimos de esta manera.
Summary
Cuando un socio cargó 20 GB en nuestro S3, almacenamos 60 GB, porque garantizamos un triplicado de la georreserva de datos. Ahora el tráfico es mucho menor, lo que es bueno tanto para el canal como para la facturación del almacenamiento.
En este caso, las rutas están cerradas fuera de la «gran Internet», pero se puede dirigir el tráfico a través de VPN L2 a través de Internet, aunque es mejor colocar el servidor de medios antes de la entrada del proveedor.
Si tienes interés en conocer estas características en nuestros centros de datos rusos o tienes preguntas sobre la implementación en tu caso, pregunta en los comentarios o por correo a ekorotkikh@croc.ru.
Fuente: habr.com
