In Ti abbiamo raccontato delle nuove funzionalità nel rilascio di gennaio dell'Update 4 per Veeam Backup & Replication 9.5 (VBR), dove consapevolmente non abbiamo menzionato i backup su nastro magnetico. Raccontare di quest'area merita un articolo a parte, perché ci sono state davvero molte nuove funzionalità.
– Ragazzi del QA, scrivete un articolo?
– Perché no!
Unità a nastro nel XXI secolo
Archiviazione dei dati su nastri magnetici (cassette, "tape" come li chiamiamo noi in R&D) non si limita al computer ZX-Spectrum, ormai fuori produzione, il cui gioco poteva essere caricato nella memoria RAM di 48 kb da in pochi minuti. Negli ultimi venticinque anni, le velocità e le capacità delle cassette sono aumentate di 6-7 ordini di grandezza. Questo non è del tutto un confronto corretto, e secondo standard. non riesce a stare al passo. Tuttavia, la tecnologia attuale consente di registrare su un chilometro di nastro di una cassetta 12 terabyte di dati (fino a 30 terabyte in modalità compressa), per cui l'unità da 160 dollari supera i concorrenti in termini di costo per un'archiviazione a lungo termine di grandi volumi di dati, anche considerando gli investimenti nell'equipaggiamento per la registrazione/lettura. I dati su tali cassette sono conservati in modo sicuro per 15-30 anni.
Approccio da un'altra angolazione. Negli ultimi tempi, hanno raggiunto un nuovo livello. Possono attendere in silenzio nell'infrastruttura di una grande azienda per settimane e mesi, e con l'emergere di una nuova vulnerabilità zero-day, possono distruggere (non senza l'aiuto umano, dal momento che sono in gioco grosse somme di denaro) non solo tutti i dati, ma anche tutti i backup che possono raggiungere. Ecco , quando l'azienda ha dovuto pagare i riscattatori. I cosiddetti air gap, cioè backup fisicamente isolati dall'infrastruttura, sono diventati di fatto l'unico salvataggio sicuro da tali situazioni. Il nastro magnetico qui è una delle soluzioni che non invecchiano.
Ma una sola specifica e le nuove tecnologie in ferro e bario da parte dei principali produttori (IBM, HPE, Oracle, Dell) non sono sufficienti per una protezione efficace dei dati, serve anche un buon software. Da noi in Veeam, c'è un intero team che si occupa dei backup su nastro, circa 10 persone analizzano, pianificano, ricercano, sviluppano e testano ogni giorno. I risultati di questo lavoro li hai visti negli articoli precedenti., ). Cosa è stato fatto nell'ultimo anno?
Glossario
Si pone la scelta tra la libertà riguardo alla lingua madre e i burocratismi che complicano la leggibilità. Preferisco la prima opzione, quindi chiedo anticipatamente scusa se alcune parole gergali presenti nella lista qui sotto possano sembrare poco gradevoli. Qui di seguito ricordo brevemente cosa significa ciascun termine.
I guru di VBR possono saltare questa parteJob – job – un incarico di backup. In effetti, tutto VBR è costruito sui job. Oltre a backup e replica, può trattarsi anche di copia su nastro magnetico (backup to tape job, tape-job). Preciso che il ripristino da un backup (restore) è anch'esso un job, ma in questo articolo il termine sarà riferito specificamente al backup.
Storage – storage – un termine storicamente consolidato. Questi sono i file in repository (repository – deposito), che contengono copie di backup – completi e incrementali. In un storage possono esserci sia una singola che più macchine virtuali.
Catena – chain – una sequenza di storage collegati tra loro. Per recuperare dati da un n-esimo storage incrementale sono necessari tutti quelli precedenti dall'(n-1)-esimo al 1° e lo storage completo a cui fa riferimento il primo incrementale.
Source, Target – source, target. Source – l'entità originale elaborata dal job. Nel caso di backup/repliche si tratta generalmente di una macchina virtuale in un hypervisor. Nel caso di un tape-job, il source è il job di backup stesso (o i file nel caso di un file to tape-job). Il target per il job di backup è il repository dove vengono archiviati i backup. Per un tape-job è un media pool.
Media pool – – un pool di supporti, nel nostro caso – cassette. Un contenitore logico, creato dall'utente, che contiene cassette di una o più biblioteche. Quindi, un tape-job avrà sempre un media pool come target, il che significa che i dati non vengono scritti su una specifica cassetta o su qualsiasi cassetta nella biblioteca, ma su un insieme specifico di esse. Il media pool ha un'impostazione per il tempo di conservazione dei dati, trascorso il quale la cassetta può essere sovrascritta. L'utente può creare pool ordinari (standard) e . Ciascuno di questi tipi può ora essere WORM o non-WORM, di questo parlerò in seguito.
Media set – – set di cassette in un media pool, su cui vengono continuamente scritti backup/file. Per i pool GFS, i set di media sono anche legati all'intervallo (ad esempio, annuale – yearly), le cassette ruotano solo all'interno del loro intervallo.
– elementi della libreria a nastro. L'unità legge e riavvolge la cassetta, il cambiator è un robot che sposta le cassette tra le fessure di stoccaggio, le fessure di scarico e l'unità. Ci sono anche unità standalone (standalone – autonomo), qui il ruolo del cambiator è svolto dall'uomo. Per l'unità è essenziale avere il driver corretto installato sulla macchina Windows a cui è collegata la libreria; possiamo lavorare con il cambiator anche senza driver, tramite SCSI nativo.
Tenant to tape. Provider sicuro – clienti sicuri
Subito le carte sul tavolo. La caratteristica più grande del nostro aggiornamento, destinata a , che utilizzano VBR nella loro infrastruttura. Lo sviluppo è iniziato due anni fa. Presto abbiamo capito che non saremmo stati in grado di affrontare un compito così importante per la prossima release, abbiamo preso una breve pausa e alla fine abbiamo rilasciato la funzione nel 9.5 Update 4.
In breve, ora i provider hanno la possibilità di copiare i backup dei loro clienti su cassette tramite job di nastro in un pool GFS. Questo offre ai provider – e sono ragazzi molto importanti per noi e per il nostro reparto commerciale – due opportunità:
- proteggere i loro clienti (tenant, tenant – affittuario) dalla perdita di dati a causa di cancellazioni accidentali o problemi infrastrutturali («inondazione nel server»);
- fornire ai tenant un servizio aggiuntivo di recupero dati da un vecchio backup, che è già stato rimosso dal repository cloud secondo la politica di conservazione dei dati, ma che è ancora presente sulle cassette.
Dal punto di vista del marketing, la funzionalità è molto «allettante», mentre dal nostro – altrettanto complessa da implementare.
Sviluppo
Il principale problema emerso è la crittografia dei dati. La maggior parte dei backup cloud è crittografata, le statistiche parlano di ⅔ dell'importo totale. Per noi questa cifra è stata una sorpresa, pensavamo che quasi tutto fosse criptato, ma non è così – molti clienti, a quanto pare, sono fermamente sicuri dei loro provider.
La paradigma è semplice: il provider non deve essere in grado di decrittare i dati dei propri tenant. Inoltre, nell'ambito della nuova funzionalità è necessario che il provider apra gli storage con i backup. Questo è necessario per spostare i blocchi di dati, ad esempio, per la creazione . L'importante è che questo debba essere fatto indipendentemente dal tenant, quando le chiavi necessarie non vengono trasferite al provider durante l'esecuzione del job.
La soluzione di questo problema, è bene sottolineare, viene utilizzata anche in un'altra funzionalità fondamentale dell'aggiornamento – – consiste nell'aggiungere una chiave di crittografia aggiuntiva. La chiave di archivio (Archive key) è conservata nel database del provider in forma crittografata. Attraverso un meccanismo astuto, il provider può usarla per aprire lo storage, spostare e ri-crittografare blocchi di dati tra gli storage (dal momento che ognuno ha la propria chiave), ma non può decrittare i dati stessi.
Meccanismo astuto (versione operativa)
Aggiungo che tutti gli ingegneri nel R&D amano molto la crittografia nel nostro prodotto, anche se nessuno sa nei dettagli come funzioni. (C'era anche una battuta "e perché funziona in generale", ma gli editori non l'hanno approvata.)
Test
Per la funzionalità sono stati registrati centinaia di bug. Le aree più complesse sono state la crittografia, l'interfaccia utente e i problemi durante il ripristino.
Dal punto di vista del testing, la difficoltà era rappresentata dalla grande variabilità, dalla "combinatoria" dei tipi di lavori e repository dei tenant – intendo sia la sorgente che l'obiettivo durante il ripristino dei backup nell'infrastruttura. Tutto ciò si intreccia con la logica all'interno della (inclusa la nuova – parallelismo e set media giornalieri, di questo parlerò più avanti), e in generale sulla specificità cloud poco conosciuta per i tape. Non dimenticate di condire abbondantemente con crittografia. Se continuiamo la metafora, ci siamo riempiti a sufficienza di questo piatto – ma lo abbiamo assaporato da ogni angolazione.
Frammento del piano di testing
Di conseguenza
Una descrizione dettagliata può essere trovata nel (al momento in inglese): , . Mi fermerò sui punti principali.
Backup
Il provider aggiunge i tenant al job tape con il pool GFS come obiettivo. Se esiste una licenza cloud, nella seconda fase della procedura guidata è disponibile l'opzione Tenants. È possibile aggiungere tutti i tenant contemporaneamente o singolarmente, oppure scegliere solo una quota specifica (ma non una sottquota) di un tenant separato. Non è possibile mescolare backup tenant e backup locali in un'unica operazione.
Le altre impostazioni sono quasi completamente identiche a quelle di un'operazione normale nel pool GFS.
Il ripristino dei dati è possibile sia dal lato del provider che dal lato del tenant stesso.
Ripristino dal lato del provider
Viene eseguito tramite una nuova procedura guidata. Qui è possibile scendere fino a un'operazione singola, ripristinando l'intera catena presente nel repository in un determinato giorno.
Ci sono tre opzioni di ripristino:
- Nella posizione originale. In questo caso, il backup originale, se presente, viene eliminato; le operazioni del tenant vengono automaticamente riconfigurate sulla catena ripristinata. Si presume che tale ripristino sia completamente invisibile per il cliente, sebbene ci sia un breve periodo in cui sarà disconnesso dal repository cloud.
- In una nuova quota/repository. Il provider può, ad esempio, creare un account temporaneo separato per questo scopo, che successivamente verrà eliminato. Il backup appare nell'infrastruttura del tenant dopo la sincronizzazione con il database del provider.
- Semplicemente su un disco di un server Linux o Windows registrato nell'infrastruttura del provider. Successivamente, questa catena può essere registrata su una chiavetta USB e inviata al tenant.
Ripristino dal lato del tenant
Questa opzione implica che il cliente abbia la propria infrastruttura di tape e un gran volume di dati da ripristinare. Il provider può fisicamente inviare al cliente una cassetta con backup registrati tramite un servizio di consegna; il cliente la catalogherà sul proprio hardware, decodificherà le cassette e i backup e lavorerà con le copie di sicurezza come se le avesse registrate lui stesso su nastro. Un trucco del mestiere per evitare di scaricare terabyte tramite WAN.
Miglioramenti significativi del pool GFS
-media pool sono stati introdotti in VBR due anni fa, nella versione 9.5. Nell'aggiornamento rilasciato, sia in relazione all'introduzione della funzionalità Tenant to tape che su richiesta degli utenti, abbiamo notevolmente migliorato questa funzionalità.
Set di media giornalieri
È stata introdotta una nuova giornaliera (daily) media set. Ora nel pool GFS è possibile archiviare backup per ogni giorno, e non solo completi, ma anche incrementali. Questi ultimi occupano notevolmente meno spazio, ed è stato fatto per risparmiare nastro. Si presume che queste cassette vengano continuamente ruotate nella libreria, senza essere portate al deposito remoto. In questo caso, per il ripristino da un punto incrementale saranno necessarie cassette di uno dei media set superiori (settimanale, mensile, trimestrale o annuale). Non è possibile attivare il media set giornaliero senza attivare quello settimanale affinché, nella maggior parte dei casi, per il recupero da una copia incrementale siano necessarie cassette settimanali. Queste sono sempre nella libreria o conservate in un magazzino non troppo remoto.
Logica di funzionamento dei job tape nel pool media GFS , i tecnici redattori non smentiranno. In poche parole, tralasciando i dettagli, nel media set settimanale e superiori vengono copiati solo backup completi (inclusi i backup completi virtuali), uno per ogni data, mentre nel media set giornaliero – tutti i backup presenti nel repository per il giorno corrente, poiché il job di backup può essere avviato più volte al giorno.
Parallelismo, ora di avvio e attesa nei pool GFS
Ora è possibile la registrazione parallela di più chain o job su più drive della libreria anche nei pool media GFS (in precedenza solo in quelli normali). Si attiva al passo Opzioni del pool media.
Importante precisazione: lo stesso file viene sempre scritto in un solo stream, quindi in caso di più macchine virtuali grandi è consigliato attivare , affinché il backup consista in più chain.
Oltre a ciò, è diventato possibile scegliere l'ora di avvio del job GFS stesso. A molti utenti non piaceva l'avvio a mezzanotte e l'attesa successiva di quasi un giorno, fino al termine del job sorgente. Ora questo orario può, ad esempio, essere impostato per una tarda serata, quando c'è già qualcosa da copiare sul nastro. Inoltre, su richiesta degli utenti, abbiamo spostato nelle impostazioni avanzate l'opzione che prima era attivabile solo tramite una chiave di registro. È sufficiente selezionare Elimina il punto di ripristino più recente invece di attendere – e sulla cassetta viene copiato ciò che è presente nel repository al momento dell'avvio del job di registrazione (il punto del giorno precedente, ad esempio), non ci sono aspettative.
Lavoro avanzato con più librerie
Si parlerà della situazione in cui più di una libreria è stata aggiunta a un pool di media. Lo abbiamo supportato anche in passato, ma di tanto in tanto i clienti si sono lamentati di un comportamento non del tutto prevedibile.
Era
Ad esempio, è stato avviato un job di registrazione, ha occupato due drive nella prima libreria, ma le impostazioni di parallelismo consentono di utilizzare subito 4 drive. Questo job dovrebbe passare alla seconda libreria del pool media e utilizzarla anch'essa, o sarebbe uno spreco di risorse?
Un altro caso. È stata selezionata l'opzione di passare in base alla condizione "nessun nastro disponibile", nella prima libreria c'è solo un nastro, ma su di esso possono essere potenzialmente inseriti tutti i dati. Tuttavia, le impostazioni consentono di scrivere parallelamente su due nastri. Dobbiamo coinvolgere la seconda libreria in questo caso?
Abbiamo deciso di mettere ordine in quest'area, dando la possibilità di configurare il comportamento in modo esplicito.
Diventato
hanno ruoli – attivo e passivo. E il pool media stesso ha due modalità: resistente ai guasti, oppure failover (failover) e scrittura parallela (paralleling). Ora, a seconda delle esigenze, è possibile configurare il pool media in modi diversi.
- Se hai più librerie uguali e hai bisogno di parallelizzare la scrittura su di esse – attivi la modalità di scrittura parallela, e per questo tutte le librerie devono avere ruoli attivi. In questo caso, nuovi nastri e drive verranno utilizzati immediatamente, non appena ce ne sarà necessità, indipendentemente da quale libreria si trovano. Tuttavia, ci sarà comunque una priorità – prima cercheremo di trovare risorse nella libreria situata più in alto nell'elenco.
- Se invece hai una libreria principale e un vecchio drive staccato come riserva, attivi la modalità di failover, posizionando la libreria principale in cima all'elenco e selezionando il ruolo passivo per i dispositivi di riserva. Il passaggio a tale dispositivo avverrà solo quando sarà davvero necessario, affinché il job funzioni in qualche modo. Questa situazione sarà considerata anomala, e verrà inviata una notifica via email.
Esiste una situazione più complessa che al momento non supportiamo: diverse librerie attive in presenza di librerie passive. Il feedback mostrerà se c'è esigenza di tali configurazioni e se sarà necessario "rifinire" la funzionalità in futuro. Pratica standard.
Supporto WORM
WORM – Write Once Read Many – cassette che non possono essere cancellate o riscritte , è possibile solo aggiungere dati. Il loro utilizzo obbligatorio è regolato dalle normative di alcune organizzazioni, ad esempio, quelle che operano nel campo medico. Il problema principale con tali cassette era in passato che VBR durante o registrava un'intestazione che non poteva essere cancellata successivamente e i tape job fallivano con un errore in caso di tentativo di farlo.
Nella versione 9.5 Update 4 è stata implementata un'assistenza completa per tali cassette. Sono stati aggiunti pool di media WORM, normali e GFS, nei quali è possibile inserire solo cassette di questo tipo.
Le nuove cassette hanno un'icona blu e "congelata". Dal punto di vista dell'utente, lavorare con le cassette WORM non è diverso dal lavorare con quelle normali.
La "Wormness" delle cassette è inizialmente determinata dal suffisso , se il codice a barre su di esse è normale o illeggibile, il driver fornisce l'informazione al primo inserimento della cassetta. Non sarà possibile inserire cassette WORM in un normale pool di media e scrivervi sopra. Curiosamente, alcuni utenti hanno già apposto codici a barre WORM su cassette normali e sono rimasti sorpresi dalle modifiche nella loro infrastruttura dopo l'aggiornamento.
Chip della cassetta
Contemporaneamente all'introduzione di cassette non riscrivibili, siamo iniziati a lavorare con . Prima non utilizzavamo gli attributi standard nel chip, ora scriviamo e leggiamo alcuni di essi, ma non li consideriamo come la fonte principale di dati. Il principale punto di riferimento rimane, come sempre, l'intestazione della cassetta. Questa decisione si è rivelata corretta: dopo un mese dal rilascio, vediamo come il "zoo" dell'hardware degli utenti presenta sorprese in termini di utilizzo del chip.
Backup dei volumi NDMP su nastro
In conclusione, riguardo la funzionalità più richiesta in base al numero di feedback. È stato reso disponibile il backup dei volumi NDMP su cassette. Nella infrastruttura VBR è necessario , dopo di che sarà possibile scegliere i volumi da questo host nel file tape job. Vengono scritti su nastri come file con un attributo speciale, per distinguerli da quelli normali durante la catalogazione.
Nella prima implementazione ci sono delle limitazioni: non sono supportate le estensioni, inoltre è possibile eseguire il backup e il ripristino solo dell'intero volume, ma non di file singoli. Il backup funziona tramite (nel caso di NetApp - ), ci sono delle peculiarità: il numero massimo di punti incrementali è 9, dopodiché viene forzato un backup completo.
In conclusione
Questi erano solo i principali cambiamenti nel settore del backup su nastro in VBR 9.5 Update 4. Altre modifiche saranno elencate:
- possibilità di impostare l'ordine delle sorgenti e dei file nei tape job;
- aggiunta del ruolo di Tape Operator (l'utente può fare tutto, tranne il ripristino da nastro – per questo c'è l'operatore di ripristino);
- aggiunte delle maschere include/exclude complete nei file tape job (escluso NDMP);
- migliorato il ripristino nei file tape job (la cartella viene ripristinata con i file che erano lì al momento del backup, e non con tutti quelli che ci sono stati nella sua storia di backup – molto richiesta, tra l'altro);
- aumentata la velocità di ripristino di un numero molto elevato di file da nastri;
- ottimizzato l'algoritmo di selezione del successivo nastro da registrare, tenendo conto, a parità di altre condizioni, del volume di dati scritti/letto per tutta la sua vita, prendendo il più recente;
- migliorata la stabilità del prodotto.
Link utili
Per varietà, fornirò alcuni link anche su risorse in lingua russa:
- E siamo tornati nel punto di partenza con i video panoramici «Come funziona» (per ora solo in inglese) – possono essere visionati . Si parla di nastri nelle diapositive 95 – 102.
Fonte: habr.com
