Como compactar o almacenamento de copias de seguridade no almacenamento de obxectos ata o 90 %

Os nosos clientes turcos pedíronnos que configuremos correctamente a copia de seguridade do seu centro de datos. Estamos a facer proxectos similares en Rusia, pero aquí a historia trataba máis de investigar como facelo mellor.

Dado: hai un almacenamento S3 local, hai Veritas NetBackup, que adquiriu unha nova funcionalidade ampliada para mover datos ao almacenamento de obxectos, agora con soporte para a deduplicación, e hai un problema co espazo libre neste almacenamento local.

Tarefa: facer todo para que o proceso de almacenamento das copias de seguridade sexa rápido e barato.

En realidade, antes disto, todo en S3 eran simplemente ficheiros, e estes eran elencos completos das máquinas críticas do centro de datos. É dicir, non está moi optimizado, pero todo funcionou ao principio. Agora toca descubrilo e facelo ben.

A imaxe mostra a que chegamos:

Como compactar o almacenamento de copias de seguridade no almacenamento de obxectos ata o 90 %

Como vedes, a primeira copia de seguridade fíxose lentamente (70 Mb/s), e as posteriores dos mesmos sistemas foron moito máis rápidas.

De feito, máis adiante hai un pouco máis de detalles sobre as características que hai.

Rexistros de copia de seguranza para aqueles que estean preparados para ler media páxina de volcadoCheo con reescaneo
18 de decembro de 2018 12:09:43 — O acelerador de información bpbkar (pid=4452) enviou 14883996160 bytes de 14883994624 bytes ao servidor, optimización 0.0 %
18 de decembro de 2018 12:10:07 - Información NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Informe=Estadísticas do PDDO (se usa un fluxo multiproceso) para (NBCC): escaneado: 14570817 KB, CR enviado: 1760761 KB, CR enviado por FC: 0 KB, eliminación de datos: 87.9 %, caché desactivada

Completo
18 de decembro de 2018 12:13:18 — O acelerador de información bpbkar (pid=2864) enviou 181675008 bytes de 14884060160 bytes ao servidor, optimización 98.8 %
18 de decembro de 2018 12:13:40 - Información NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Informe=Estadísticas do PDDO para (NBCC): escaneado: 14569706 KB, CR enviado: 45145 KB, CR enviado por FC: 0 KB, eliminación de datos: 99.7 %, caché desactivada

Incremental
18 de decembro de 2018 12:15:32 — O acelerador de información bpbkar (pid=792) enviou 9970688 bytes de 14726108160 bytes ao servidor, optimización 99.9 %
18 de decembro de 2018 12:15:53 - Información NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Informe=Estadísticas do PDDO para (NBCC): escaneado: 14383788 KB, CR enviado: 15700 KB, CR enviado por FC: 0 KB, eliminación de datos: 99.9 %, caché desactivada

Completo
18 de decembro de 2018 12:18:02 — O acelerador de información bpbkar (pid=3496) enviou 171746816 bytes de 14884093952 bytes ao servidor, optimización 98.8 %
18 de decembro de 2018 12:18:24 - Información NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Informe=Estadísticas do PDDO para (NBCC): escaneado: 14569739 KB, CR enviado: 34120 KB, CR enviado por FC: 0 KB, eliminación de datos: 99.8 %, caché desactivada

Cal é o problema

Os clientes queren facer copias de seguridade coa maior frecuencia posible e almacenalas o máis barato posible. O mellor é almacenalos de xeito económico en almacenamentos de obxectos como o S3, porque son os máis baratos polo custo do servizo por megabyte desde onde podes facer unha copia de seguridade nun tempo razoable. Cando hai moita copia de seguridade, non se fai moi barato, porque a maior parte do almacenamento está ocupado por copias dos mesmos datos. No caso de HaaS de colegas turcos, o almacenamento pódese densificar aproximadamente nun 80-90%. Está claro que isto se relaciona especificamente coas súas particularidades, pero definitivamente contaría con polo menos o 50% do avó.

Para resolver o problema, os principais provedores fixeron dende hai tempo pasarelas para Amazon S3. Todos os seus métodos son compatibles con S3 local sempre que admitan a API de Amazon. No centro de datos turco, a copia de seguridade realízase no noso S3, así como no "Compresor" T-III en Rusia, xa que este esquema de traballo funcionou ben para nós.

E o noso S3 é totalmente compatible cos métodos de copia de seguridade de Amazon S3. É dicir, todas as ferramentas de copia de seguridade que admiten estes métodos permítenche copiar todo a ese almacenamento "fóra da caixa".

Veritas NetBackup engadiu a función CloudCatalyst:

Como compactar o almacenamento de copias de seguridade no almacenamento de obxectos ata o 90 %

É dicir, entre as máquinas das que hai que facer unha copia de seguridade e a pasarela, hai un servidor Linux intermedio polo que pasa o tráfico de copia de seguridade dos axentes SRK e se desduplica sobre a marcha antes de transferilo a S3. Se antes había 30 copias de seguridade de 20 GB con compresión, agora (debido á semellanza das máquinas) o seu volume reduciuse nun 90%. O motor de deduplicación úsase igual que cando se almacena en discos normais mediante Netbackup.

Isto é o que ocorre antes do servidor intermedio:

Como compactar o almacenamento de copias de seguridade no almacenamento de obxectos ata o 90 %

Probamos e chegamos á conclusión de que cando se implementa nos nosos centros de datos, isto aforra espazo no almacenamento S3 para nós e para os clientes. Como propietario de centros de datos comerciais, por suposto, cobramos segundo o volume ocupado, pero tamén é moi rendible para nós, porque comezamos a gañar cartos en lugares máis escalables en software, e non en aluguer de hardware. Ben, e isto é unha redución dos custos internos.

Rexistros228 traballos (0 en cola 0 activos 0 en espera de reintento 0 suspendidos 0 incompletos 228 feitos — 13 seleccionados)
(Filtro aplicado [13])

Tipo de ID de traballo Estado Detalles de estado Estado Política de traballo Programación de traballos Cliente Media Server Hora de inicio Tempo transcorrido Hora de finalización Unidade de almacenamento Intento Operación Kilobytes Nome de ruta de ficheiros % completado (estimado) PID de traballo Propietario Copiar ID do traballo principal KB/seg Inicio activo Activo Transcorrido Sesión de perfil de Robot Vault Medios de identificación para expulsar Movemento de datos Tipo fóra do host Prioridade principal Tasa de deduplicación Acelerador de transporte Optimización Instancia o base de datos Compartir Host
— 1358 Instantánea Feito 0 VMware — NNGNCloudADC NBCC 18 de decembro de 2018 12:16:19 00 de decembro de 02 18:18:2018 12:18:37 STU_DP_S3_****copia de seguranza 1 100 % raíz 1358 de decembro de 18, 2018 % :12:16 PM 27:00:02 Estándar de disco de recuperación instantánea WIN-*********** 10
Copia de seguranza 1360 feita 0 VMware completa NGNCloudADC NBCC 18 de decembro de 2018 12:16:48 00 de decembro de 01 39:18:2018 12:18:27 3 de decembro de 1 14,535,248:149654:100 STU_DP_S23858_****copia de seguranza 1358 335,098 18 2018 12 16 48 00, 01 de decembro , 39 0:99.8:99 XNUMX:XNUMX:XNUMX Estándar de disco de recuperación instantánea WIN-********** XNUMX XNUMX % XNUMX %
1352 Instantánea Feito 0 VMware - NGNCloudADC NBCC 18 de decembro de 2018 12:14:04 00 de decembro de 02 01:18:2018 12:16:05 3 de decembro de 1 100:1352:18 STU_DP_S2018_****copia de seguranza 12 14 % raíz 14 de decembro de 00, 01 % 51:0 PM XNUMX:XNUMX:XNUMX Estándar de disco de recuperación instantánea WIN-*********** XNUMX
1354 Copia de seguranza feita 0 VMware incremental NGNCloudADC NBCC 18 de decembro de 2018 12:14:34 00 de decembro de 01 21:18:2018 12:15:55 3 de decembro de 1 14,380,965:147:100 STU_DP_S23617_****copia de seguranza 1352 500,817 18 2018 12 14 34 00 01 de decembro , 21 0:99.9:100 XNUMX:XNUMX:XNUMX Estándar de disco de recuperación instantánea WIN-********** XNUMX XNUMX % XNUMX %
1347 Instantánea Feito 0 VMware - NGNCloudADC NBCC 18 de decembro de 2018 12:11:45 00 de decembro de 02 08:18:2018 12:13:53 3 de decembro de 1 100:1347:18 STU_DP_S2018_****copia de seguranza 12 11 % raíz 45 de decembro de 00, 02 % 08:0 PM XNUMX:XNUMX:XNUMX Estándar de disco de recuperación instantánea WIN-*********** XNUMX
Copia de seguranza 1349 feita 0 VMware completa NGNCloudADC NBCC 18 de decembro de 2018 12:12:02 00 de decembro de 01 41:18:2018 12:13:43 3 de decembro de 1 14,535,215:149653:100 STU_DP_S23508_****copia de seguranza 1347 316,319 18 2018 12 12 02 00, 01 de decembro , 41 0:99.7:99 XNUMX:XNUMX:XNUMX Estándar de disco de recuperación instantánea WIN-********** XNUMX XNUMX % XNUMX %
1341 Instantánea Feito 0 VMware - NGNCloudADC NBCC 18 de decembro de 2018 12:05:28 00 de decembro de 04 53:18:2018 12:10:21 3 de decembro de 1 100:1341:18 STU_DP_S2018_****copia de seguranza 12 05 % raíz 28 de decembro de 00, 04 % 53:0 PM XNUMX:XNUMX:XNUMX Estándar de disco de recuperación instantánea WIN-*********** XNUMX
1342 Copia de seguranza feita 0 VMware Full_Rescan NGNCloudADC NBCC 18 de decembro de 2018 12:05:47 00 de decembro de 04 24:18:2018 12:10:11 3 de decembro de 1 14,535,151:149653:100 STU_DP_S22999_****copia de seguranza 1341 70,380 % 18 2018 12 05 Dec 47 , 00 04:24:0 PM 87.9:0:XNUMX Instant Recovery Disk Standard WIN-*********** XNUMX XNUMX % XNUMX %

1339 Instantánea Feito 150 VMware - NGNCloudADC NBCC 18 de decembro de 2018 11:05:46 00 de decembro de 00 53:18:2018 11:06:39 3 de decembro de 1 100:1339:18 STU_DP_S2018_****copia de seguranza 11 05 % 46 de decembro de 00, 00 de dez. 53:0 AM XNUMX:XNUMX:XNUMX Estándar de disco de recuperación instantánea WIN-*********** XNUMX
1327 Instantánea Feito 0 VMware - ******.********.cloud NBCC 17 de decembro de 2018 12:54:42 05:51:38 17 de decembro de 2018 6:46:20 STU_DP_S3_****copia de seguranza 1 100 % raíz 1327 17 de decembro de 2018 12:54:42 05:51:38 Estándar do disco de recuperación instantánea WIN-*********** 0
Copia de seguranza 1328 feita 0 VMware completo ******.********.cloud NBCC 17 de decembro de 2018 12:55:10 05:29:21 17 de decembro de 2018 6:24:31 STU_DP_S3_****backup 1 222,602,719 258932 100% 12856 root 1327 11,326 Decembro 17, 2018 12:55:10 PM 05:29:21 Instant Recovery Disk Standard. 0% WIN-****87.9******* 0 %
1136 Instantánea Feito 0 VMware - ******.********.cloud NBCC 14 de decembro de 2018 4:48:22 04:05:16 14 de decembro de 2018 8:53:38 STU_DP_S3_****copia de seguranza 1 100 % raíz 1136 14 de decembro de 2018 4:48:22 04:05:16 Estándar do disco de recuperación instantánea WIN-*********** 0
Copia de seguranza 1140 feita 0 VMware Full_Scan *******.********.cloud NBCC 14 de decembro de 2018 4:49:14 03:49:58 14 de decembro de 2018 8:39:12 STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 Decembro 14, 2018 4:49:14 PM 03:49:58 Instant Recovery Disk Standard WIN-0. 45.2 %

O acelerador permítelle reducir o tráfico dos axentes, porque Só se transmiten os cambios de datos, é dicir, nin sequera as copias de seguridade completas se cargan por completo, xa que o servidor multimedia recolle as posteriores copias de seguridade completas das copias de seguridade incrementais.

O servidor intermedio ten o seu propio almacenamento, onde escribe unha "caché" de datos e mantén unha base de datos para a deduplicación.

A arquitectura completa ten o seguinte aspecto:

  1. O servidor mestre xestiona a configuración, actualizacións, etc. e está situado na nube.
  2. O servidor multimedia (máquina intermedia *nix) debería estar o máis próximo aos sistemas redundantes en termos de accesibilidade á rede. Aquí faise a deduplicación das copias de seguridade de todas as máquinas reservadas.
  3. Nas máquinas de copia de seguranza hai axentes que xeralmente envían ao servidor multimedia só o que non está no seu almacenamento.

Todo comeza cunha exploración completa: esta é unha copia de seguridade completa. Neste punto, o servidor multimedia tómao todo, desduplica e transfire a S3. A velocidade ao servidor multimedia é baixa, pero a partir del é maior. A principal limitación é a potencia de cálculo do servidor.

As seguintes copias de seguridade realízanse completas desde o punto de vista de todos os sistemas, pero en realidade son algo así como copias de seguridade completas sintéticas. É dicir, a transferencia real e a gravación ao servidor multimedia prodúcense só daqueles bloques de datos que aínda non se atoparon nas copias de seguridade de VM antes. E só se transfiren e rexistran en S3 aqueles bloques de datos cuxo hash non estea na base de datos de deduplicación do servidor multimedia. En palabras máis sinxelas, isto é algo que nunca antes se viu en ningunha copia de seguridade dunha única máquina virtual.

Durante a restauración, o servidor multimedia solicita a S3 os obxectos deduplicados necesarios, rehidrataos e transfire aos axentes IRB, é dicir. é necesario ter en conta o volume de tráfico durante a restauración, que será igual ao volume real de datos que se restauran.

Aquí ten o aspecto:

Como compactar o almacenamento de copias de seguridade no almacenamento de obxectos ata o 90 %

E aquí tes outro anaco de rexistros169 traballos (0 en cola 0 activos 0 en espera de reintento 0 suspendidos 0 incompletos 169 feitos — 1 seleccionados)

Tipo de ID de traballo Estado Detalles de estado Estado Política de traballo Programación de traballos Cliente Media Server Hora de inicio Tempo transcorrido Hora de finalización Unidade de almacenamento Intento Operación Kilobytes Nome de ruta de ficheiros % completado (estimado) PID de traballo Propietario Copiar ID do traballo principal KB/seg Inicio activo Activo Transcorrido Sesión de perfil de Robot Vault Medios de identificación para expulsar Movemento de datos Tipo fóra do host Prioridade principal Tasa de deduplicación Acelerador de transporte Optimización Instancia o base de datos Compartir Host
- 1372 Restaurar Feito 0 NBPR01 NBCC 19 de decembro de 2018 1:05:58 00:04:32 19 de decembro de 2018 1:10:30 1 14,380,577 1 100 % 8548 1372 % 70,567 RAÍZ 19 de decembro de 2018 :1 PM 06:00:00 WIN-*********** 04

A integridade dos datos está garantida pola propia protección do S3: hai unha boa redundancia para protexerse contra fallos de hardware, como un eixe de disco duro morto.

O servidor multimedia necesita 4 TB de caché; esta é a recomendación de tamaño mínimo de Veritas. Máis é mellor, pero iso foi o que fixemos.

Total

Cando un compañeiro arroxou 3 GB ao noso S20, almacenábamos 60 GB, porque proporcionamos unha xeo-reserva de datos tripla. Agora hai moito menos tráfico, o que é bo tanto para a canle como para as tarifas de almacenamento.

Neste caso, as rutas están pechadas despois da "gran Internet", pero pode dirixir o tráfico a través da VPN L2 a través de Internet, pero é mellor instalar o servidor multimedia antes da entrada do provedor.

Se estás interesado en coñecer estas funcións nos nosos centros de datos rusos ou tes preguntas sobre a implementación na casa, pregunta nos comentarios ou por correo electrónico [protexido por correo electrónico].

Fonte: www.habr.com

Engadir un comentario