Com compactar l'emmagatzematge de còpies de seguretat a l'emmagatzematge d'objectes fins a un 90%

Els nostres clients turcs ens van demanar que configurem correctament la còpia de seguretat del seu centre de dades. Estem fent projectes similars a Rússia, però aquí la història tractava més d'investigar com fer-ho millor.

Donat: hi ha un emmagatzematge S3 local, hi ha Veritas NetBackup, que ha adquirit una nova funcionalitat ampliada per traslladar dades a l'emmagatzematge d'objectes, ara amb suport per a la deduplicació, i hi ha un problema amb l'espai lliure en aquest emmagatzematge local.

Tasca: fer-ho tot perquè el procés d'emmagatzematge de còpies de seguretat sigui ràpid i econòmic.

En realitat, abans d'això, tot a S3 eren simplement fitxers, i es tractava de càlculs complets de les màquines crítiques del centre de dades. És a dir, no està molt optimitzat, però tot va funcionar al principi. Ara és el moment d'esbrinar-ho i fer-ho bé.

La imatge mostra a què vam arribar:

Com compactar l'emmagatzematge de còpies de seguretat a l'emmagatzematge d'objectes fins a un 90%

Com podeu veure, la primera còpia de seguretat es va fer lentament (70 Mb/s), i les posteriors còpies de seguretat dels mateixos sistemes van ser molt més ràpides.

De fet, més endavant hi ha una mica més de detalls sobre quines funcions hi ha.

Registres de còpia de seguretat per a aquells que estiguin preparats per llegir mitja pàgina d'abocamentPle amb rescaneig
18 de desembre de 2018 12:09:43 — L'accelerador d'informació bpbkar (pid=4452) ha enviat 14883996160 bytes de 14883994624 bytes al servidor, optimització 0.0%
18 de desembre de 2018 12:10:07 - Informació NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Informe=Estadístiques PDDO (seqüència multiprocés utilitzat) per a (NBCC): escanejat: 14570817 KB, CR enviat: 1760761 KB, CR enviat a través de FC: 0 KB, desduplicació: 87.9%, memòria cau desactivada

Complet
18 de desembre de 2018 12:13:18 — L'accelerador d'informació bpbkar (pid=2864) ha enviat 181675008 bytes de 14884060160 bytes al servidor, optimització 98.8%
18 de desembre de 2018 12:13:40 - Informació NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Informe=Estadístiques PDDO per a (NBCC): escanejat: 14569706 KB, CR enviat: 45145 KB, CR enviat a través de FC: 0 KB, deduplicació: 99.7%, memòria cau desactivada

Incremental
18 de desembre de 2018 12:15:32 — L'accelerador d'informació bpbkar (pid=792) ha enviat 9970688 bytes de 14726108160 bytes al servidor, optimització 99.9%
18 de desembre de 2018 12:15:53 - Informació NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Informe=Estadístiques PDDO per a (NBCC): escanejat: 14383788 KB, CR enviat: 15700 KB, CR enviat a través de FC: 0 KB, deduplicació: 99.9%, memòria cau desactivada

Complet
18 de desembre de 2018 12:18:02 — L'accelerador d'informació bpbkar (pid=3496) ha enviat 171746816 bytes de 14884093952 bytes al servidor, optimització 98.8%
18 de desembre de 2018 12:18:24 - Informació NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Informe=Estadístiques PDDO per a (NBCC): escanejat: 14569739 KB, CR enviat: 34120 KB, CR enviat a través de FC: 0 KB, deduplicació: 99.8%, memòria cau desactivada

Quin és el problema

Els clients volen fer còpies de seguretat tan sovint com sigui possible i emmagatzemar-les el més barat possible. El millor és emmagatzemar-los de manera econòmica en emmagatzematge d'objectes com ara S3, perquè són els més barats pel preu del servei per megabyte des d'on podeu tornar a fer una còpia de seguretat en un temps raonable. Quan hi ha molta còpia de seguretat, no és gaire barata, perquè la major part de l'emmagatzematge està ocupada per còpies de les mateixes dades. En el cas de HaaS de col·legues turcs, l'emmagatzematge es pot densificar aproximadament un 80-90%. Està clar que això es relaciona específicament amb les seves especificitats, però definitivament comptaria amb almenys el 50% de l'avi.

Per resoldre el problema, els principals venedors fa temps que fan passarel·les a Amazon S3. Tots els seus mètodes són compatibles amb S3 local sempre que admetin l'API d'Amazon. Al centre de dades turc, es fa una còpia de seguretat al nostre S3, així com al "Compressor" T-III a Rússia, ja que aquest esquema de treball ens ha funcionat bé.

I el nostre S3 és totalment compatible amb els mètodes de còpia de seguretat d'Amazon S3. És a dir, totes les eines de còpia de seguretat que admeten aquests mètodes us permeten copiar-ho tot a aquest emmagatzematge "des de la caixa".

Veritas NetBackup ha afegit la funció CloudCatalyst:

Com compactar l'emmagatzematge de còpies de seguretat a l'emmagatzematge d'objectes fins a un 90%

És a dir, entre les màquines que cal fer una còpia de seguretat i la passarel·la, hi ha un servidor Linux intermedi pel qual passa el trànsit de còpia de seguretat dels agents SRK i es desduplica sobre la marxa abans de transferir-lo a S3. Si abans hi havia 30 còpies de seguretat de 20 GB amb compressió, ara (per la similitud de les màquines) el seu volum s'ha reduït un 90%. El motor de deduplicació s'utilitza igual que quan s'emmagatzema en discs normals mitjançant Netbackup.

Això és el que passa abans del servidor intermedi:

Com compactar l'emmagatzematge de còpies de seguretat a l'emmagatzematge d'objectes fins a un 90%

Vam provar i vam arribar a la conclusió que quan s'implementa als nostres centres de dades, això estalvia espai a l'emmagatzematge S3 per a nosaltres i per als clients. Com a propietaris de centres de dades comercials, per descomptat, cobrem segons el volum ocupat, però també ens resulta molt rendible, perquè comencem a guanyar diners en llocs més escalables en programari, i no amb el lloguer de maquinari. Bé, i això és una reducció de costos interns.

Registres228 treballs (0 a la cua 0 actius 0 esperant un nou intent 0 suspesos 0 incomplets 228 fets — 13 seleccionats)
(Filtre aplicat [13])

Tipus d'identificador del treball Estat Detalls de l'estat Estat Política del treball Programació del treball Temps d'inici del servidor multimèdia del client Temps transcorregut Hora de finalització Unitat d'intent d'operació Kilobytes Camí de fitxers % Complet (estimat) Propietari del PID del treball Còpia ID del treball principal KB/Seg Inici actiu Transcorregut Sessió de perfil del robot de robot Mitjans d'identificació per expulsar Moviment de dades fora de l'amfitrió Tipus de prioritat Mestra Taxa de deduplicació Accelerador de transport Optimització Instància o base de dades compartida Amfitrió
— 1358 Instantània feta 0 VMware — NNGNCloudADC NBCC 18 de desembre de 2018 12:16:19 00:02:18 18 de desembre de 2018 12:18:37 STU_DP_S3_****còpia de seguretat 1 100% arrel 1358, 18% des. :2018:12 PM 16:27:00 Estàndard de disc de recuperació instantània WIN-*********** 02
Còpia de seguretat 1360 feta 0 VMware Full NGNCloudADC NBCC 18 de desembre de 2018 12:16:48 00 de desembre de 01 39:18:2018 12:18:27 3:1:14,535,248 STU_DP_S149654_****còpia de seguretat 100 23858% root 1358 335,098 de desembre , 18 2018:12:16 48:00:01 Instant Recovery Disk Standard WIN-********** 39 0% 99.8%
1352 Instantània feta 0 VMware - NGNCloudADC NBCC 18 de desembre de 2018 12:14:04 00:02:01 18 de desembre de 2018 12:16:05 STU_DP_S3_****còpia de seguretat 1 100% arrel 1352 de desembre de 18, 2018% 12:14 PM 14:00:01 Estàndard de disc de recuperació instantània WIN-*********** 51
Còpia de seguretat 1354 feta 0 VMware incremental NGNCloudADC NBCC 18 de desembre de 2018 12:14:34 00 de desembre de 01 21:18:2018 12:15:55 3 de desembre de 1 14,380,965:147:100 STU_DP_S23617_****còpia de seguretat 1352 500,817 18 % 2018 12 14 de desembre , 34 00:01:21 0:99.9:100 Instant Recovery Disk Standard WIN-********** XNUMX XNUMX% XNUMX%
1347 Instantània feta 0 VMware - NGNCloudADC NBCC 18 de desembre de 2018 12:11:45 00:02:08 18 de desembre de 2018 12:13:53 STU_DP_S3_****còpia de seguretat 1 100% arrel 1347 de desembre de 18, 2018% 12:11 PM 45:00:02 Estàndard de disc de recuperació instantània WIN-*********** 08
Còpia de seguretat 1349 feta 0 VMware Full NGNCloudADC NBCC 18 de desembre de 2018 12:12:02 00 de desembre de 01 41:18:2018 12:13:43 3:1:14,535,215 STU_DP_S149653_****còpia de seguretat 100 23508% root 1347 316,319 de desembre , 18 2018:12:12 02:00:01 Instant Recovery Disk Standard WIN-********** 41 0% 99.7%
1341 Instantània feta 0 VMware - NGNCloudADC NBCC 18 de desembre de 2018 12:05:28 00:04:53 18 de desembre de 2018 12:10:21 STU_DP_S3_****còpia de seguretat 1 100% arrel 1341 de desembre de 18, 2018% 12:05 PM 28:00:04 Estàndard de disc de recuperació instantània WIN-*********** 53
Còpia de seguretat 1342 feta 0 VMware Full_Rescan NGNCloudADC NBCC 18 de desembre de 2018 12:05:47 00 de desembre de 04 24:18:2018 12:10:11 3 de desembre de 1 14,535,151:149653:100 STU_DP_S22999_****còpia de seguretat 1341 70,380% 18 2018 12 desembre 05 , 47 00:04:24 0:87.9:0 Instant Recovery Disk Standard WIN-*********** XNUMX XNUMX% XNUMX%

1339 Instantània feta 150 VMware - NGNCloudADC NBCC 18 de desembre de 2018 11:05:46 a.m. 00:00:53 18 de desembre de 2018 11:06:39 a.m. STU_DP_S3_****còpia de seguretat 1 100 % d'arrel 1339 dec. 18:2018 AM 11:05:46 Estàndard de disc de recuperació instantània WIN-*********** 00
1327 Instantània feta 0 VMware - *******.********.cloud NBCC 17 de desembre de 2018 12:54:42 05:51:38 17 de desembre de 2018 6:46:20 STU_DP_S3_****còpia de seguretat 1 100% root 1327 17 de desembre de 2018 12:54:42 05:51:38 Instant Recovery Disk Standard WIN-*********** 0
Còpia de seguretat 1328 feta 0 VMware complet ******.********.cloud NBCC 17 de desembre de 2018 12:55:10 05:29:21 17 de desembre de 2018 6:24:31 STU_DP_S3_****còpia de seguretat 1 222,602,719 258932 100% 12856 arrel 1327 11,326 17 de desembre de 2018 12:55:10 05:29:21 Disc de recuperació instantània estàndard 0% WIN-****87.9**** 0%
1136 Instantània feta 0 VMware - *******.********.cloud NBCC 14 de desembre de 2018 4:48:22 04:05:16 14 de desembre de 2018 8:53:38 STU_DP_S3_****còpia de seguretat 1 100% root 1136 14 de desembre de 2018 4:48:22 04:05:16 Instant Recovery Disk Standard WIN-*********** 0
Còpia de seguretat 1140 feta 0 VMware Full_Scan *******.********.cloud NBCC 14 de desembre de 2018 4:49:14 03:49:58 14 de desembre de 2018 8:39:12 STU_DP_S3_****còpia de seguretat 1 217,631,332 255465 100% 26438 arrel 1136 15,963 14 de desembre de 2018 4:49:14 03:49:58 Disc de recuperació instantània estàndard WIN-0******* 45.2% WIN-0. XNUMX%

L'accelerador permet reduir el trànsit dels agents, perquè Només es transmeten els canvis de dades, és a dir, fins i tot les còpies de seguretat completes no es carreguen completament, ja que el servidor multimèdia recull còpies de seguretat completes posteriors a partir de còpies de seguretat incrementals.

El servidor intermedi té el seu propi emmagatzematge, on escriu una "caché" de dades i manté una base de dades per a la desduplicació.

L'arquitectura completa té aquest aspecte:

  1. El servidor mestre gestiona la configuració, les actualitzacions, etc. i es troba al núvol.
  2. El servidor multimèdia (màquina *nix intermèdia) s'ha d'ubicar més a prop dels sistemes redundants pel que fa a l'accessibilitat de la xarxa. Aquí, es fa la desduplicació de les còpies de seguretat de totes les màquines reservades.
  3. A les màquines amb còpia de seguretat hi ha agents que generalment envien al servidor multimèdia només allò que no està al seu emmagatzematge.

Tot comença amb una exploració completa: aquesta és una còpia de seguretat completa. En aquest punt, el servidor multimèdia ho pren tot, ho desduplica i ho transfereix a S3. La velocitat al servidor multimèdia és baixa, però a partir d'ell és més alta. La principal limitació és la potència de càlcul del servidor.

Les següents còpies de seguretat es completen des del punt de vista de tots els sistemes, però en realitat són una cosa semblant a còpies de seguretat completes sintètiques. És a dir, la transferència i l'enregistrament reals al servidor multimèdia només es produeixen d'aquells blocs de dades que encara no s'han trobat abans a les còpies de seguretat de VM. I només es transfereixen i es registren a S3 aquells blocs de dades el hash dels quals no es troba a la base de dades de deduplicació del servidor multimèdia. En paraules més senzilles, això és una cosa que mai s'havia vist abans en cap còpia de seguretat d'una única màquina virtual.

Durant la restauració, el servidor multimèdia sol·licita a S3 els objectes desduplicats necessaris, els rehidrata i els transfereix als agents IRB, és a dir. cal tenir en compte el volum de trànsit durant la restauració, que serà igual al volum real de dades que s'estan restaurant.

Això és el que sembla:

Com compactar l'emmagatzematge de còpies de seguretat a l'emmagatzematge d'objectes fins a un 90%

I aquí hi ha un altre tros de registres169 treballs (0 a la cua 0 actius 0 esperant un nou intent 0 suspesos 0 incomplets 169 fets — 1 seleccionats)

Tipus d'identificador del treball Estat Detalls de l'estat Estat Política del treball Programació del treball Temps d'inici del servidor multimèdia del client Temps transcorregut Hora de finalització Unitat d'intent d'operació Kilobytes Camí de fitxers % Complet (estimat) Propietari del PID del treball Còpia ID del treball principal KB/Seg Inici actiu Transcorregut Sessió de perfil del robot de robot Mitjans d'identificació per expulsar Moviment de dades fora de l'amfitrió Tipus de prioritat Mestra Taxa de deduplicació Accelerador de transport Optimització Instància o base de dades compartida Amfitrió
- 1372 Restaurar fet 0 NBPR01 NBCC 19 de desembre de 2018 1:05:58 00:04:32 19 de desembre de 2018 1:10:30 1 14,380,577 1 100% 8548 ROOT 1372 70,567 :19 PM 2018:1:06 GUANYA-*********** 00

La integritat de les dades està assegurada per la protecció del propi S3: hi ha una bona redundància per protegir-se de fallades de maquinari, com ara un eix de disc dur mort.

El servidor multimèdia necessita 4 TB de memòria cau; aquesta és la recomanació de mida mínima de Veritas. Més és millor, però això és el que vam fer.

Total

Quan un soci va llançar 3 GB al nostre S20, vam emmagatzemar 60 GB, perquè proporcionem una triple reserva geogràfica de dades. Ara hi ha molt menys trànsit, que és bo tant per al canal com per a les tarifes d'emmagatzematge.

En aquest cas, les rutes es tanquen més enllà de la "gran Internet", però podeu conduir trànsit a través de VPN L2 a Internet, però és millor instal·lar el servidor multimèdia abans de l'entrada del proveïdor.

Si esteu interessats a conèixer aquestes funcions als nostres centres de dades russos o teniu preguntes sobre la implementació a casa, pregunteu-ho als comentaris o per correu electrònic [protegit per correu electrònic].

Font: www.habr.com

Afegeix comentari