I nostri clienti turchi ci hanno chiesto di configurare correttamente il backup per il data center. Realizziamo progetti simili in Russia, ma qui la storia riguardava più la ricerca su come fare meglio.
Dati: c'è uno storage S3 locale, c'è Veritas NetBackup che ha acquisito nuove funzionalità avanzate per il trasferimento dei dati negli storage oggettivi, ora con supporto per la deduplicazione, e c'è un problema di spazio libero in questo storage locale.
Obiettivo: fare in modo che il processo di archiviazione dei backup sia veloce ed economico.
In effetti, prima in S3 tutto era organizzato semplicemente in file, e si trattava di copie complete di macchine critiche del data center. Non era quindi molto ottimizzato, ma tutto funzionava all'inizio. Ora però è tempo di capire e fare le cose per bene.
Nella figura ciò a cui siamo arrivati:
Come si può vedere, il primo backup è stato eseguito lentamente (70 MB/s), mentre i backup successivi degli stessi sistemi sono stati significativamente più rapidi.
In effetti, qui ci sono un po' più di dettagli sulle sue caratteristiche.
Log dei backup per chi è pronto a leggere mezzo pagina di dumpCompleto con nuova scansione
18 dic 2018 12:09:43 PM — Info bpbkar (pid=4452) accelerator ha inviato 14883996160 byte di 14883994624 byte al server, ottimizzazione 0,0%
18 dic 2018 12:10:07 PM — Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Report=PDDO Stats (stream multi-thread utilizzato) per (NBCC): scansionati: 14570817 KB, CR inviati: 1760761 KB, CR inviati via FC: 0 KB, dedup: 87,9%, cache disabilitata
Completo
18 dic 2018 12:13:18 PM — Info bpbkar (pid=2864) accelerator ha inviato 181675008 byte di 14884060160 byte al server, ottimizzazione 98,8%
18 dic 2018 12:13:40 PM — Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Report=PDDO Stats per (NBCC): scansionati: 14569706 KB, CR inviati: 45145 KB, CR inviati via FC: 0 KB, dedup: 99,7%, cache disabilitata
Incrementale
18 dic 2018 12:15:32 PM — Info bpbkar (pid=792) accelerator ha inviato 9970688 byte di 14726108160 byte al server, ottimizzazione 99,9%
18 dic 2018 12:15:53 PM — Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Report=PDDO Stats per (NBCC): scansionati: 14383788 KB, CR inviati: 15700 KB, CR inviati via FC: 0 KB, dedup: 99,9%, cache disabilitata
Completo
18 dic 2018 12:18:02 PM — Info bpbkar (pid=3496) accelerator ha inviato 171746816 byte di 14884093952 byte al server, ottimizzazione 98,8%
18 dic 2018 12:18:24 PM — Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Report=PDDO Stats per (NBCC): scansionati: 14569739 KB, CR inviati: 34120 KB, CR inviati via FC: 0 KB, dedup: 99,8%, cache disabilitata
Qual è il problema
I clienti vogliono fare backup il più frequentemente possibile e conservarli al minor costo. È più economico conservarli negli storage a oggetti come S3, poiché costano meno per megabyte per il ripristino del backup in tempi ragionevoli. Quando ci sono molti backup, diventa meno conveniente, poiché gran parte dello spazio di archiviazione è occupata da copie degli stessi dati. Nel caso di HaaS dei colleghi turchi, è possibile comprimere lo storage di circa l'80-90%. È ovvio che questo si riferisce alla loro specificità, ma almeno un 50% di deduplicazione mi aspetterei sicuramente.
Per risolvere il problema, i principali fornitori hanno già realizzato gateway per S3 di Amazon da tempo. Tutti i loro metodi sono compatibili con S3 locali, se supportano l'API di Amazon. Nel data center turco, il backup viene effettuato nel nostro S3, proprio come nel T-III "Compressore" in Russia, poiché questo modello di lavoro si è dimostrato efficace per noi.
Il nostro S3 è completamente compatibile con i metodi di backup di Amazon S3. In altre parole, tutti gli strumenti di backup che supportano questi metodi permettono di copiare tutto in uno storage simile "out of the box".
In Veritas NetBackup hanno creato la funzione CloudCatalyst:
Cioè, tra le macchine da sottoporre a backup e il gateway, è stato inserito un server Linux intermedio, attraverso il quale passa il traffico di backup dagli agenti SRK e viene eseguita la deduplicazione "al volo" prima di trasferirli nel S3. Se prima c'erano 30 backup da 20 Gb con compressione, ora (a causa della somiglianza delle macchine) il loro volume è diminuito del 90%. Il motore di deduplicazione utilizzato è lo stesso di quello impiegato per l'archiviazione su dischi normali tramite Netbackup.
Ecco cosa succede prima del server intermedio:
Abbiamo testato e concluso che l'implementazione nei nostri data center offre un risparmio di spazio negli storage S3 sia per noi che per i clienti. In qualità di proprietario di data center commerciali, ovviamente, fatturiamo in base al volume occupato, ma è comunque molto vantaggioso anche per noi — perché iniziamo a guadagnare su spazi più scalabili nel software, e non sull'affitto dell'hardware. Inoltre, ciò comporta una riduzione dei costi interni.
Log228 Jobs (0 in coda 0 attivi 0 in attesa di ripetizione 0 sospesi 0 incompleti 228 completati — 13 selezionati)
(Filtro applicato [13])
ID lavoro Tipo Stato Dettagli Stato Stato Politica Lavoro Programma Lavoro Clienti Media Server Orario di inizio Tempo trascorso Orario di fine Unità di archiviazione Tentativo Operazione Kilobyte File Nome del percorso % Completo (Stimato) ID processo di lavoro Proprietario Copia ID lavoro padre KB/Sec Attivo Inizio Attivo Trascorso Robot Vault Profilo ID sessione Media da espellere Movimento dati Off-Host Tipo Master Priorità Tasso di deduplicazione Ottimizzazione Trasporto Istanze o Database Condivisione Host
— 1358 Snapshot Completato 0 VMware — NGNCloudADC NBCC 18 dicembre 2018 12:16:19 PM 00:02:18 18 dicembre 2018 12:18:37 PM STU_DP_S3_****backup 1 100% root 1358 18 dicembre 2018 12:16:27 PM 00:02:10 Ripristino istantaneo Disco Standard WIN-*********** 0
1360 Backup Completato 0 VMware Completo NGNCloudADC NBCC 18 dicembre 2018 12:16:48 PM 00:01:39 18 dicembre 2018 12:18:27 PM STU_DP_S3_****backup 1 14.535.248 149654 100% 23858 root 1358 335.098 18 dicembre 2018 12:16:48 PM 00:01:39 Ripristino istantaneo Disco Standard WIN-*********** 0 99.8% 99%
1352 Snapshot Completato 0 VMware — NGNCloudADC NBCC 18 dicembre 2018 12:14:04 PM 00:02:01 18 dicembre 2018 12:16:05 PM STU_DP_S3_****backup 1 100% root 1352 18 dicembre 2018 12:14:14 PM 00:01:51 Ripristino istantaneo Disco Standard WIN-*********** 0
1354 Backup Completato 0 VMware Incrementale NGNCloudADC NBCC 18 dicembre 2018 12:14:34 PM 00:01:21 18 dicembre 2018 12:15:55 PM STU_DP_S3_****backup 1 14.380.965 147 100% 23617 root 1352 500.817 18 dicembre 2018 12:14:34 PM 00:01:21 Ripristino istantaneo Disco Standard WIN-*********** 0 99.9% 100%
1347 Snapshot Completato 0 VMware — NGNCloudADC NBCC 18 dicembre 2018 12:11:45 PM 00:02:08 18 dicembre 2018 12:13:53 PM STU_DP_S3_****backup 1 100% root 1347 18 dicembre 2018 12:11:45 PM 00:02:08 Ripristino istantaneo Disco Standard WIN-*********** 0
1349 Backup Completato 0 VMware Completo NGNCloudADC NBCC 18 dicembre 2018 12:12:02 PM 00:01:41 18 dicembre 2018 12:13:43 PM STU_DP_S3_****backup 1 14.535.215 149653 100% 23508 root 1347 316.319 18 dicembre 2018 12:12:02 PM 00:01:41 Ripristino istantaneo Disco Standard WIN-*********** 0 99.7% 99%
1341 Snapshot Completato 0 VMware — NGNCloudADC NBCC 18 dicembre 2018 12:05:28 PM 00:04:53 18 dicembre 2018 12:10:21 PM STU_DP_S3_****backup 1 100% root 1341 18 dicembre 2018 12:05:28 PM 00:04:53 Ripristino istantaneo Disco Standard WIN-*********** 0
1342 Backup Completato 0 VMware Scansione Completa NGNCloudADC NBCC 18 dicembre 2018 12:05:47 PM 00:04:24 18 dicembre 2018 12:10:11 PM STU_DP_S3_****backup 1 14.535.151 149653 100% 22999 root 1341 70.380 18 dicembre 2018 12:05:47 PM 00:04:24 Ripristino istantaneo Disco Standard WIN-*********** 0 87.9% 0%
1339 Snapshot Completato 150 VMware — NGNCloudADC NBCC 18 dicembre 2018 11:05:46 AM 00:00:53 18 dicembre 2018 11:06:39 AM STU_DP_S3_****backup 1 100% root 1339 18 dicembre 2018 11:05:46 AM 00:00:53 Ripristino istantaneo Disco Standard WIN-*********** 0
1327 Snapshot Completato 0 VMware — *******.********.cloud NBCC 17 dicembre 2018 12:54:42 PM 05:51:38 17 dicembre 2018 6:46:20 PM STU_DP_S3_****backup 1 100% root 1327 17 dicembre 2018 12:54:42 PM 05:51:38 Ripristino istantaneo Disco Standard WIN-*********** 0
1328 Backup Completato 0 VMware Completo *******.********.cloud NBCC 17 dicembre 2018 12:55:10 PM 05:29:21 17 dicembre 2018 6:24:31 PM STU_DP_S3_****backup 1 222.602.719 258932 100% 12856 root 1327 11.326 17 dicembre 2018 12:55:10 PM 05:29:21 Ripristino istantaneo Disco Standard WIN-*********** 0 87.9% 0%
1136 Snapshot Completato 0 VMware — *******.********.cloud NBCC 14 dicembre 2018 4:48:22 PM 04:05:16 14 dicembre 2018 8:53:38 PM STU_DP_S3_****backup 1 100% root 1136 14 dicembre 2018 4:48:22 PM 04:05:16 Ripristino istantaneo Disco Standard WIN-*********** 0
1140 Backup Completato 0 VMware Scansione Completa *******.********.cloud NBCC 14 dicembre 2018 4:49:14 PM 03:49:58 14 dicembre 2018 8:39:12 PM STU_DP_S3_****backup 1 217.631.332 255465 100% 26438 root 1136 15.963 14 dicembre 2018 4:49:14 PM 03:49:58 Ripristino istantaneo Disco Standard WIN-*********** 0 45.2% 0%
L'acceleratore consente di ridurre il traffico dagli agenti, poiché vengono trasmessi solo i cambiamenti dei dati, quindi anche i backup completi non vengono trasferiti completamente, poiché il server multimediale raccoglie i successivi backup completi dalle copie incrementali.
Il server intermedio ha il proprio storage, dove scrive la "cache" dei dati e mantiene il database per la deduplicazione.
Nell'architettura completa appare così:
- Il server principale gestisce la configurazione, gli aggiornamenti e altro ed è situato nel cloud.
- Il server multimediale (una macchina *nix intermedia) deve trovarsi il più vicino possibile ai sistemi da riservare in termini di accessibilità di rete. Qui viene eseguita la deduplicazione dei backup da tutte le macchine riservate.
- Sulle macchine riservate ci sono agenti che, in generale, inviano al server multimediale solo ciò che non è presente nel suo storage.
Tutto inizia con una scansione completa: è un backup completo a tutti gli effetti. In questo momento, il server multimediale recupera tutto, esegue la deduplicazione e invia in S3. La velocità verso il server multimediale è bassa, da esso è più alta. La principale limitazione è la potenza di calcolo del server.
I backup successivi vengono effettuati come se fossero completi da tutti i sistemi, ma in realtà sono qualcosa di simile a backup completi sintetici. Cioè, la trasmissione e la registrazione effettiva sul server multimediale avviene solo per i blocchi di dati che non sono già stati incontrati nei backup delle VM in precedenza. E la trasmissione e la registrazione in S3 avvengono solo per i blocchi di dati i cui hash non sono presenti nel database di deduplicazione del server multimediale. In parole più semplici: solo ciò che non è stato mai incontrato in un backup di nessuna VM prima.
Durante il ripristino, il server multimediale richiede gli oggetti deduplicati necessari da S3, li rigenera e li trasmette agli agenti SRK, ovvero è necessario considerare il volume del traffico durante il ripristino, che sarà pari al reale volume dei dati da ripristinare.
Ecco come appare:
Ecco un altro pezzo di log169 Lavori (0 In coda 0 Attivi 0 In attesa di ripetere 0 Sospesi 0 Incompleti 169 Completati — 1 selezionato)
ID lavoro Tipo Stato Dettagli Stato Stato Politica Lavoro Programma Lavoro Clienti Media Server Orario di inizio Tempo trascorso Orario di fine Unità di archiviazione Tentativo Operazione Kilobyte File Nome del percorso % Completo (Stimato) ID processo di lavoro Proprietario Copia ID lavoro padre KB/Sec Attivo Inizio Attivo Trascorso Robot Vault Profilo ID sessione Media da espellere Movimento dati Off-Host Tipo Master Priorità Tasso di deduplicazione Ottimizzazione Trasporto Istanze o Database Condivisione Host
— 1372 Ripristino Completato 0 nbpr01 NBCC 19 dic 2018 13:05:58 00:04:32 19 dic 2018 13:10:30 1 14.380.577 1 100% 8548 root 1372 70.567 19 dic 2018 13:06:00 00:04:30 WIN-*********** 90000
L'integrità dei dati è garantita dalla protezione stessa di S3: c'è una buona ridondanza per proteggere da guasti hardware, come un disco rigido guasto.
Multimedia-server è necessario 4 TB di cache — questa è la raccomandazione di Veritas per il volume minimo. Meglio di più, ma abbiamo fatto esattamente così.
Risultato
Quando il partner ha caricato 20 GB sul nostro S3, noi ne conservavamo 60 GB, poiché garantiamo un backup dei dati triplo. Ora il traffico è molto diminuito, il che è positivo sia per il canale che per la fatturazione dello storage.
In questo caso le route sono chiuse al di fuori del «grande Internet», ma è possibile instradare il traffico anche attraverso VPN L2 via Internet, ma è meglio posizionare il server multimediale prima dell'ingresso del fornitore.
Se sei interessato a conoscere queste funzionalità nei nostri data center russi o hai domande su come implementarle da te, chiedi nei commenti o scrivi a ekorotkikh@croc.ru.
Fonte: habr.com
