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 riguarda principalmente la ricerca del modo migliore per procedere.
Condizioni: esiste uno storage locale S3, c'è Veritas NetBackup, che ha acquisito una nuova funzionalità avanzata per spostare i dati negli storage oggetto ora con supporto per la deduplicazione, e c'è un problema di spazio libero in questo storage locale.
Obiettivo: assicurarsi che il processo di archiviazione dei backup sia rapido ed economico.
In precedenza, in S3 venivano semplicemente accumulati file, anche se si trattava di copie complete delle macchine critiche del data center. Non era una soluzione molto ottimizzata, ma tutto funzionava all'inizio. Ora è il momento di capire e procedere correttamente.
Nell'immagine ciò a cui siamo giunti:
Come si può vedere, il primo backup veniva eseguito lentamente (70 Mb/s), mentre i backup successivi delle stesse macchine risultavano significativamente più rapidi.
Infatti, qui ci sono ulteriori dettagli sulle peculiarità.
Log dei backup per chi è pronto a leggere mezza pagina di dumpCompleto con riscan
18 Dic 2018 12:09:43 PM — Info bpbkar (pid=4452) l'acceleratore ha inviato 14883996160 byte su 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=Statistiche PDDO (stream multi-thread utilizzato) per (NBCC): scansionato: 14570817 KB, CR inviati: 1760761 KB, CR inviati su FC: 0 KB, dedup: 87,9%, cache disabilitata
Completo
18 Dic 2018 12:13:18 PM — Info bpbkar (pid=2864) l'acceleratore ha inviato 181675008 byte su 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=Statistiche PDDO per (NBCC): scansionato: 14569706 KB, CR inviati: 45145 KB, CR inviati su FC: 0 KB, dedup: 99,7%, cache disabilitata
Incremental
18 Dic 2018 12:15:32 PM — Info bpbkar (pid=792) l'acceleratore ha inviato 9970688 byte su 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=Statistiche PDDO per (NBCC): scansionato: 14383788 KB, CR inviati: 15700 KB, CR inviati su FC: 0 KB, dedup: 99,9%, cache disabilitata
Completo
18 Dic 2018 12:18:02 PM — Info bpbkar (pid=3496) l'acceleratore ha inviato 171746816 byte su 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=Statistiche PDDO per (NBCC): scansionato: 14569739 KB, CR inviati: 34120 KB, CR inviati su FC: 0 KB, dedup: 99,8%, cache disabilitata
Qual è il problema
I clienti vogliono eseguire backup il più frequentemente possibile e conservarli al costo più basso. Il modo migliore per conservare a basso costo è utilizzare archivi oggetto come S3, poiché offrono la tariffa di gestione più bassa per megabyte da cui è possibile ripristinare il backup in tempi ragionevoli. Quando ci sono molti backup, ciò può diventare relativamente costoso, poiché la maggior parte dello spazio di archiviazione è occupata da copie delle stesse informazioni. Nel caso dell'HaaS dei colleghi turchi, è possibile comprimere lo stoccaggio di circa l'80-90%. È evidente che questo si riferisce proprio alla loro specificità, ma almeno una deduplicazione del 50% ci si può sicuramente aspettare.
Per risolvere questo problema, i principali fornitori hanno da tempo sviluppato gateway per S3 di Amazon. Tutti i loro metodi sono compatibili con S3 locali, a condizione che supportino l'API di Amazon. Nel data center turco, il backup viene fatto nel nostro S3, così come nel T-III 'Compressore' in Russia, poiché questo modello di lavoro ha dimostrato di funzionare bene da noi.
Il nostro S3 è completamente compatibile con i metodi di backup di Amazon S3. Questo significa che tutti gli strumenti di backup che supportano questi metodi consentono di copiare tutto in un'archiviazione simile 'out-of-the-box'.
In Veritas NetBackup è stata implementata la funzione CloudCatalyst:
Quindi, tra le macchine da sottoporre a backup e il gateway si è interposto un server Linux intermedio, attraverso il quale passa il traffico di backup dagli agenti SRK e avviene la deduplicazione "al volo" prima della loro trasmissione in S3. Se prima c'erano 30 backup da 20 GB con compressione, ora (a causa della somiglianza delle macchine) il volume è diminuito del 90%. Il motore di deduplicazione utilizzato è lo stesso impiegato per lo storage su normali dischi tramite Netbackup.
Ecco cosa succede prima del server intermedio:
Abbiamo effettuato dei test e siamo giunti alla conclusione che, implementando questa soluzione nei nostri data center, otteniamo un risparmio di spazio nel storage S3 sia per noi che per i clienti. Come proprietari di data center commerciali, naturalmente applichiamo tariffe in base allo spazio occupato, ma questo è comunque molto vantaggioso anche per noi — perché iniziamo a guadagnare in spazi più scalabili nel software, anziché nell'affitto dell'hardware. Inoltre, questa soluzione riduce anche i costi interni.
Log228 Job (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 Programma Lavoro Cliente Media Server Ora Inizio Tempo Trascorso Ora Fine Unità di Archiviazione Tentativo Operazione Kilobytes File Nome Percorso % Completo (Stimato) Job PID Proprietario Copia ID Lavoro Genitore KB/Sec Attivo Inizio Attivo Trascorso Robot Profilo Vault ID Sessione Media da Espellere Movimento Dati Tipo Off-Host Master Priorità Tasso di Deduplicazione Ottimizzazione Trasporto Istanza o Database Condivisione Host
— 1358 Istante Completato 0 VMware — NGNCloudADC NBCC 18 Dic 2018 12:16:19 PM 00:02:18 18 Dic 2018 12:18:37 PM STU_DP_S3_****backup 1 100% root 1358 18 Dic 2018 12:16:27 PM 00:02:10 Ripristino Istantaneo Disco Standard WIN-*********** 0
1360 Backup Completato 0 VMware Completo NGNCloudADC NBCC 18 Dic 2018 12:16:48 PM 00:01:39 18 Dic 2018 12:18:27 PM STU_DP_S3_****backup 1 14.535.248 149654 100% 23858 root 1358 335.098 18 Dic 2018 12:16:48 PM 00:01:39 Ripristino Istantaneo Disco Standard WIN-*********** 0 99.8% 99%
1352 Istante Completato 0 VMware — NGNCloudADC NBCC 18 Dic 2018 12:14:04 PM 00:02:01 18 Dic 2018 12:16:05 PM STU_DP_S3_****backup 1 100% root 1352 18 Dic 2018 12:14:14 PM 00:01:51 Ripristino Istantaneo Disco Standard WIN-*********** 0
1354 Backup Completato 0 VMware Incrementale NGNCloudADC NBCC 18 Dic 2018 12:14:34 PM 00:01:21 18 Dic 2018 12:15:55 PM STU_DP_S3_****backup 1 14.380.965 147 100% 23617 root 1352 500.817 18 Dic 2018 12:14:34 PM 00:01:21 Ripristino Istantaneo Disco Standard WIN-*********** 0 99.9% 100%
1347 Istante Completato 0 VMware — NGNCloudADC NBCC 18 Dic 2018 12:11:45 PM 00:02:08 18 Dic 2018 12:13:53 PM STU_DP_S3_****backup 1 100% root 1347 18 Dic 2018 12:11:45 PM 00:02:08 Ripristino Istantaneo Disco Standard WIN-*********** 0
1349 Backup Completato 0 VMware Completo NGNCloudADC NBCC 18 Dic 2018 12:12:02 PM 00:01:41 18 Dic 2018 12:13:43 PM STU_DP_S3_****backup 1 14.535.215 149653 100% 23508 root 1347 316.319 18 Dic 2018 12:12:02 PM 00:01:41 Ripristino Istantaneo Disco Standard WIN-*********** 0 99.7% 99%
1341 Snapshot Eseguito 0 VMware — NGNCloudADC NBCC 18 Dic 2018 12:05:28 PM 00:04:53 18 Dic 2018 12:10:21 PM STU_DP_S3_****backup 1 100% root 1341 18 Dic 2018 12:05:28 PM 00:04:53 Ripristino Istantaneo Disco Standard WIN-*********** 0
1342 Backup Eseguito 0 VMware Full_Rescan NGNCloudADC NBCC 18 Dic 2018 12:05:47 PM 00:04:24 18 Dic 2018 12:10:11 PM STU_DP_S3_****backup 1 14.535.151 149653 100% 22999 root 1341 70.380 18 Dic 2018 12:05:47 PM 00:04:24 Ripristino Istantaneo Disco Standard WIN-*********** 0 87.9% 0%
1339 Snapshot Eseguito 150 VMware — NGNCloudADC NBCC 18 Dic 2018 11:05:46 AM 00:00:53 18 Dic 2018 11:06:39 AM STU_DP_S3_****backup 1 100% root 1339 18 Dic 2018 11:05:46 AM 00:00:53 Ripristino Istantaneo Disco Standard WIN-*********** 0
1327 Snapshot Eseguito 0 VMware — *******.********.cloud NBCC 17 Dic 2018 12:54:42 PM 05:51:38 17 Dic 2018 6:46:20 PM STU_DP_S3_****backup 1 100% root 1327 17 Dic 2018 12:54:42 PM 05:51:38 Ripristino Istantaneo Disco Standard WIN-*********** 0
1328 Backup Eseguito 0 VMware Full *******.********.cloud NBCC 17 Dic 2018 12:55:10 PM 05:29:21 17 Dic 2018 6:24:31 PM STU_DP_S3_****backup 1 222.602.719 258932 100% 12856 root 1327 11.326 17 Dic 2018 12:55:10 PM 05:29:21 Ripristino Istantaneo Disco Standard WIN-*********** 0 87.9% 0%
1136 Snapshot Eseguito 0 VMware — *******.********.cloud NBCC 14 Dic 2018 4:48:22 PM 04:05:16 14 Dic 2018 8:53:38 PM STU_DP_S3_****backup 1 100% root 1136 14 Dic 2018 4:48:22 PM 04:05:16 Ripristino Istantaneo Disco Standard WIN-*********** 0
1140 Backup Eseguito 0 VMware Full_Scan *******.********.cloud NBCC 14 Dic 2018 4:49:14 PM 03:49:58 14 Dic 2018 8:39:12 PM STU_DP_S3_****backup 1 217.631.332 255465 100% 26438 root 1136 15.963 14 Dic 2018 4:49:14 PM 03:49:58 Ripristino Istantaneo Disco Standard WIN-*********** 0 45.2% 0%
L'acceleratore riduce il traffico dagli agenti, poiché vengono trasmessi solo i cambiamenti dei dati, quindi anche i backup completi non vengono trasferiti interamente, poiché il server multimediale raccoglie i successivi backup completi dai backup incrementali.
Il server intermedio ha il proprio storage, dove scrive la «cache» dei dati e tiene il database per la deduplicazione.
Nella architettura completa appare così:
- Il server master gestisce la configurazione, gli aggiornamenti e altro, ed è situato nel cloud.
- Il server multimediale (macchina intermedia *nix) deve essere il più vicino possibile ai sistemi da salvaguardare in termini di accessibilità di rete. Qui avviene la deduplicazione dei backup da tutte le macchine in fase di salvataggio.
- Sulle macchine da salvaguardare 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 vero e proprio backup completo. In questo momento, il server multimediale acquisisce tutto, effettua la deduplicazione e trasmette in S3. La velocità verso il server multimediale è bassa, mentre da esso è più alta. La principale limitazione è la potenza di elaborazione del server.
I prossimi backup sono considerati completi da tutte le prospettive di sistema, ma in realtà sono simili a backup completi sintetici. Ciò significa che la trasmissione e la scrittura effettiva sul server multimediale avvengono solo per i blocchi di dati che non sono già stati incontrati in precedenti copie di sicurezza della VM. Inoltre, la trasmissione e la scrittura in S3 avvengono solo per i blocchi di dati il cui hash non è presente nel database di deduplicazione del server multimediale. In altre parole, si tratta di dati non riscontrati in nessun backup di nessuna VM precedentemente.
Durante il ripristino, il server multimediale richiede gli oggetti deduplicati necessari da S3, li rigenera e li trasferisce agli agenti SRK; è quindi necessario considerare il volume di traffico durante il ripristino, che sarà equivalente al reale volume dei dati recuperati.
Ecco come appare:
Ecco anche un altro pezzo di log169 Lavori (0 in coda, 0 attivi, 0 in attesa di ripetizione, 0 sospesi, 0 incompleti, 169 completati — 1 selezionato)
ID Lavoro Tipo Stato Dettagli Stato Stato Politica Programma Lavoro Cliente Media Server Ora Inizio Tempo Trascorso Ora Fine Unità di Archiviazione Tentativo Operazione Kilobytes File Nome Percorso % Completo (Stimato) Job PID Proprietario Copia ID Lavoro Genitore KB/Sec Attivo Inizio Attivo Trascorso Robot Profilo Vault ID Sessione Media da Espellere Movimento Dati Tipo Off-Host Master Priorità Tasso di Deduplicazione Ottimizzazione Trasporto Istanza o Database Condivisione Host
— 1372 Ripristino completato 0 nbpr01 NBCC 19 dicembre 2018 13:05:58 00:04:32 19 dicembre 2018 13:10:30 1 14,380,577 1 100% 8548 root 1372 70,567 19 dicembre 2018 13:06:00 00:04:30 WIN-*********** 90000
L'integrità dei dati è garantita dalla protezione di S3 stesso — presenta una buona ridondanza per proteggere da guasti hardware come il malfunzionamento di un disco rigido.
Multimedia-server Serve 4 TB di cache — questa è la raccomandazione di Veritas per il volume minimo. È meglio avere di più, ma abbiamo fatto proprio così.
Risultato
Quando il partner ha caricato 20 GB nel nostro S3, noi ne abbiamo conservati 60 GB, poiché garantiamo una triplice geo-riserva dei dati. Ora il traffico è molto minore, il che è positivo sia per il canale sia per la tariffazione dello storage.
In questo caso, i percorsi sono chiusi rispetto al "grande Internet", ma è possibile instradare il traffico anche attraverso VPN L2 attraverso Internet, ma è meglio posizionare il server multimediale prima dell'ingresso del provider.
Se sei interessato a conoscere queste funzionalità nei nostri data center russi o hai domande sulla loro implementazione — chiedi nei commenti o via email a ekorotkikh@croc.ru.
Fonte: habr.com
