In Vi abbiamo parlato delle nuove funzionalità dell'aggiornamento di gennaio Update 4 per Veeam Backup & Replication 9.5 (VBR), dove consapevolmente non abbiamo menzionato i backup su nastro magnetico. Un racconto su quest'area merita un articolo a parte, perché ci sono state davvero molte nuove funzionalità.
- Ragazzi del QA, scriverete un articolo?
- Perché no!
Unità a nastro nel XXI secolo
Lo storage dei dati su nastri magnetici (cassette, "nastri", come li chiamiamo in R&D) non è limitato al computer del passato ZX-Spectrum, il cui gioco poteva caricarsi in memoria con 48 kb da per diversi minuti. Negli ultimi venticinque anni, la velocità e la capacità delle cassette sono aumentate di 6-7 ordini di grandezza. Questo non è proprio un confronto corretto, e secondo standard Non riesce a stare al passo. Tuttavia, le tecnologie moderne consentono di registrare su una cassetta a nastro lunga chilometri 12 terabyte di dati (fino a 30 terabyte in modalità compressa), quindi, un'unità da 160 dollari supera i concorrenti in termini di costo per la conservazione a lungo termine di grandi volumi di dati, anche tenendo conto degli investimenti nell'attrezzatura per la registrazione/lettura. I dati su tali cassette sono conservati in modo affidabile per 15-30 anni.
Affronterò la questione da un'altra angolazione. Negli ultimi tempi hanno raggiunto un nuovo livello. Possono aspettare il loro momento all'interno dell'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, poiché ci sono grandi somme in gioco) non solo tutti i dati, ma anche tutti i backup, fino a quelli accessibili. Ecco un , quando un'azienda ha dovuto pagare i riscatto. I cosiddetti air gap, ovvero backup fisicamente isolati dall'infrastruttura, sono diventati, di fatto, l'unica salvezza affidabile da tali eventi. Il nastro magnetico è qui una delle soluzioni intramontabili.
Ma una sola specifica e le novità tecnologiche in ferro e ferrite di bario dei principali produttori (IBM, HPE, Oracle, Dell) non sono sufficienti per garantire una protezione affidabile dei dati; è necessario un buon software. Da Veeam, abbiamo un intero team dedicato ai backup su nastro; circa 10 persone analizzano, pianificano, ricercano, sviluppano e testano ogni giorno. I risultati di questo lavoro sono stati evidenziati nei precedenti articoli (, ). Cosa è stato fatto nell'ultimo anno?
Glossario
Si pone la scelta tra libertà rispetto alla lingua madre e formule burocratiche che complicano la leggibilità. Io preferisco la prima opzione, quindi mi scuso in anticipo se alcune espressioni gergali nel seguente elenco possano risultare fastidiose. Qui ricorderò brevemente il significato di ciascun termine.
I veterani di VBR possono saltare questa parteJob – job – è l'incarico di backup. In effetti, tutto il VBR si basa su job. Oltre al backup e alla replica, può trattarsi anche di copia su nastro (backup to tape job, tape job). Preciso che il ripristino da un backup (restore) è anch'esso un job, ma in questo articolo con questo termine ci si riferirà specificamente al backup.
Storage – storage – un termine storico. Si tratta di file in repository (repository – archivio), che contengono backup – completi e incrementali. In uno storage possono esserci sia una che più macchine virtuali.
Catena – chain – una sequenza di storage interconnessi. Per il ripristino dei dati da un certo storage incrementale n, sono necessari tutti i precedenti da (n-1) a 1 e lo storage completo a cui fa riferimento il primo incrementale.
Source, Target – source, target. Source – l'entità originale che viene elaborata dal job. Nel caso di backup/repliche, è generalmente una macchina virtuale nel hypervisor. Nel caso di un job di tape, il source è il job di backup stesso (o i file nel caso di un job file to tape). Target per il job di backup è il repository in cui vengono conservati i backup. Per il job di tape, invece, è il media pool.
Media pool – – pool di supporti, nel nostro caso – cassette. Un contenitore logico creato dall'utente che contiene cassette di una o più librerie. Quindi, il tape job ha sempre un media pool come target, il che significa che i dati non vengono scritti su una specifica cassetta o su qualsiasi cassetta nella libreria, ma su un insieme specifico di esse. Il media pool ha una configurazione del tempo di conservazione dei dati, dopo il quale la cassetta può essere sovrascritta. L'utente può creare cassette normali (standard) e . Ciascuno di questi tipi può ora essere WORM o non WORM, di cui parleremo più avanti.
Media set – – un insieme di cassette nel media pool, su cui vengono continuamente scritti backup/file. Per i GFS pool, i media set sono anche collegati a un intervallo (ad esempio, annuale – yearly), le cassette ruotano solo all'interno del proprio intervallo.
– elementi della tape library. Il drive legge e riavvolge la cassetta, il changer è un robot che sposta le cassette tra gli slot di archiviazione, gli slot di scarico e il drive. Ci sono anche drive standalone (standalone – standalone), il ruolo di changeover è svolto da una persona. Per il driver è necessario un driver correttamente installato del produttore su una macchina Windows a cui è collegata la libreria; con il changeover, invece, possiamo operare anche senza driver, tramite native SCSI.
Inquilino su nastro. Il provider è protetto – i clienti sono protetti.
Subito gli assi sul tavolo. La funzione più significativa del nostro aggiornamento, progettata per , 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ì serio per il prossimo rilascio, abbiamo preso una piccola pausa e alla fine abbiamo rilasciato la funzione in 9.5 Update 4.
In breve, ora i provider hanno la possibilità di copiare i backup dei propri clienti su nastri utilizzando job di tape nel pool GFS. Questo offre ai provider – e sono ragazzi molto importanti per noi e per il nostro dipartimento commerciale – due opportunità:
- proteggere i propri clienti (inquilini, tenant – locatario) dalla perdita di dati a causa di cancellazione accidentale o problemi infrastrutturali ("un'inondazione nel server");
- fornire ai clienti un servizio aggiuntivo di recupero dati da un vecchio backup, che è stato a lungo rimosso dal repository cloud secondo la politica di conservazione dei dati, ma è ancora presente su nastri.
Dal punto di vista del marketing, la funzionalità è molto "gustosa"; mentre per noi è altrettanto complessa da implementare.
Sviluppo
Il principale problema emerso è la crittografia dei dati. La maggior parte dei backup cloud è crittografata; le statistiche indicano circa i ⅔ del numero totale. Questa cifra è stata una sorpresa per noi, pensavamo che quasi tutto fosse crittografato, ma no: molti clienti sembrano avere una fiducia incondizionata nei loro fornitori.
La paradigma è semplice: il fornitore non deve essere in grado di decrittografare i dati dei propri clienti. Allo stesso tempo, nell'ambito della nuova funzionalità, è necessario aprire gli storage con i backup da parte del fornitore. Questo è richiesto per mantenere i blocchi di dati, ad esempio, per creare . La cosa principale è che questo deve essere fatto indipendentemente dal cliente, quando le chiavi necessarie non vengono trasferite al fornitore durante l'esecuzione del lavoro.
La soluzione a questo problema, utilizzata anche in un'altra funzionalità chiave dell'ultimo aggiornamento, consiste nell'aggiunta di una chiave di crittografia aggiuntiva. La chiave di archiviazione (Archive key) è memorizzata nel database del provider in forma crittografata. Con un sistema ingegnoso sul lato del provider, è possibile aprire lo storage, spostare e riscrivere blocchi di dati tra gli storage (dato che ciascuno ha la propria chiave), ma non è possibile decrittare i dati stessi.
Schema ingegnoso (versione operativa)
Aggiungo che tutti gli ingegneri del R&D amano molto la crittografia nel nostro prodotto, anche se nessuno conosce in dettaglio come funziona. (C'era anche una battuta «e perché funzioni davvero», ma non è passata agli editori.)
Test
Per la funzionalità sono stati registrati centinaia di bug. Le aree più complesse sono quelle legate alla crittografia, all'interfaccia utente e ai problemi durante il ripristino.
Dal punto di vista del testing, la difficoltà proveniva dall'alta variabilità, dalla «combinatoria» di tipi e categorie di lavori tenant e repository – mi riferisco sia alla fonte che all'obiettivo durante il ripristino dei backup nell'infrastruttura. Tutto questo si intreccia nella logica all'interno (incluse la nuova - parallelismo e set di media giornalieri, di cui parleremo più avanti), e in generale sulla specificità cloud inconsueta per i tape. Non dimenticate di condire abbondantemente con la crittografia. Continuando la metafora, ci siamo davvero sazietà di questo piatto - ma lo abbiamo assaporato da tutti i lati.
Frammento del piano di test
Di conseguenza
Una descrizione dettagliata è disponibile in (per ora in inglese): , . Mi concentrerò sui punti principali.
Backup
Il fornitore aggiunge i tenant nel job tape con il pool GFS come target. Con una licenza cloud disponibile, al secondo passo della procedura guidata è disponibile l'opzione Tenant. Puoi aggiungere tutti i tenant insieme o uno alla volta, o selezionare solo una quota specifica (ma non una subquota) di un singolo tenant. Non è possibile mescolare i backup dei tenant in un unico job con i backup locali normali.
Le altre impostazioni sono quasi completamente identiche a quelle di un normale job nel pool GFS.
Il ripristino dei dati è possibile sia dal lato del fornitore che dal lato del tenant stesso.
Ripristino dal lato del fornitore
Viene eseguito tramite una nuova procedura guidata. Qui è già possibile scendere a un lavoro separato, ripristinando completamente la catena presente nel repository in un determinato giorno.
Ci sono tre opzioni di ripristino:
- Nella posizione originale. In questo caso, il backup originale, se esiste, viene eliminato; i lavori del tenant vengono automaticamente riavviati sulla catena ripristinata. Si presume che un tale ripristino sarà del tutto invisibile per il cliente, poiché sarà disconnesso dal repository cloud solo per un breve periodo.
- In una nuova quota/repository. Il provider può, ad esempio, creare un account temporaneo separato per questo scopo, che verrà successivamente 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 scritta su una chiavetta USB e inviata al tenant.
Ripristino lato tenant
Questa opzione prevede che il cliente disponga della propria infrastruttura tape e di grandi volumi di dati per il ristorante. Il fornitore può fisicamente inviare al cliente una cassetta con i backup registrati tramite un servizio di consegna, il cliente la catalogherà sul proprio hardware, decifrerà le cassette e i backup e gestirà le copie di sicurezza come se le avesse registrate lui stesso su nastro. Ecco un trucco per evitare di scaricare terabyte tramite WAN.
Miglioramenti significativi al pool GFS
-media pools sono stati introdotti in VBR due anni fa, con la versione 9.5. Nell'aggiornamento rilasciato, sia con l'introduzione della funzione Tenant to tape, sia per le richieste degli utenti, abbiamo migliorato notevolmente questa funzionalità.
Set di media giornalieri
È stato introdotto un nuovo set giornaliero (giornaliero) set di media. Ora nel pool GFS è possibile memorizzare backup per ogni giorno, non solo completi ma anche incrementali. Questi ultimi occupano notevolmente meno spazio, e ciò è stato fatto per risparmiare banda. Si presume che queste cassette siano costantemente ruotate in biblioteca, senza essere trasferite per lo stoccaggio remoto. Per un ripristino da un punto incrementale sarà necessario utilizzare cassette di uno dei set di media più grandi (settimanali, mensili, trimestrali o annuali). È impossibile attivare il set di media giornaliero senza attivare quello settimanale per garantire che, nella maggior parte dei casi, il ripristino da una copia incrementale richieda precisamente cassette settimanali. Queste ultime si trovano sempre in biblioteca o sono conservate in un magazzino non troppo distante.
Logica di funzionamento del job tape nel pool di media GFS , gli scrittori tecnici non possono mentire. In breve, senza entrare nei dettagli, nei set multimediali settimanali e superiori vengono copiati solo i backup completi (inclusi i backup virtuali completi), uno per ogni data, mentre nel set giornaliero – tutti i backup del giorno corrente presenti nel repository, poiché il processo di backup può essere avviato più di una volta al giorno.
Parallelismo, tempo di avvio e attesa nei pool GFS
Ora è possibile registrare parallelamente più catene o job su più dischi della libreria anche nei pool multimediali GFS (prima era possibile solo in quelli normali). È attivato nella fase Opzioni del pool multimediale.
Importante precisazione: lo stesso file viene sempre scritto in un unico flusso, quindi nel caso di più macchine virtuali grandi è consigliabile attivare , in modo che il backup consista in più catene.
Inoltre, è diventato possibile scegliere il tempo di avvio del job GFS stesso.. A molti utenti non piaceva il lancio a mezzanotte e l'attesa di quasi un'intera giornata affinché il job di sorgente si completasse. Ora è possibile impostare questo tempo, ad esempio, per tardi in serata, quando ci sono già dati da copiare sulla nastro. Inoltre, su richiesta degli utenti, abbiamo portato nelle impostazioni avanzate un'opzione che prima poteva essere attivata solo tramite chiave di registro. Basta selezionare Elimina il punto di ripristino più recente anziché aspettare – e sulla cassetta viene copiato ciò che è presente nel repository al momento dell'avvio del job tape (il punto di ieri, ad esempio), l'attesa è completamente assente.
Migliorato il lavoro con più librerie
Parleremo della situazione in cui più di una libreria è stata aggiunta a un singolo media pool. Lo abbiamo supportato anche in passato, ma di tanto in tanto ricevevamo reclami da clienti riguardo comportamenti non del tutto prevedibili.
C'era
Ad esempio, è stata avviata un'attività di tape-job che ha utilizzato due drive nella prima libreria, ma le impostazioni di parallelismo consentono di utilizzarne fino a 4. Dovrebbe questa job passare alla seconda libreria del media pool e utilizzarla anch'essa, o sarebbe uno spreco di risorse?
Un altro caso. È stata selezionata l'opzione di passaggio in base alla condizione "nessun nastro disponibile", nella prima libreria c'è solo un nastro, ma potenzialmente può contenere tutti i dati. Tuttavia, le impostazioni consentono di scrivere contemporaneamente su due nastri. Dovremmo coinvolgere la seconda libreria in questo caso?
Abbiamo deciso di mettere ordine in quest'area, offrendo la possibilità di configurare il comportamento in modo esplicito.
Diventato
hanno ricevuto ruoli – attivo e passivo. E per il media pool stesso – ci sono due modalità: tollerante ai guasti, o failover (failover) e scrittura parallela (paralleling). Ora, a seconda delle esigenze, è possibile configurare il media pool in modi diversi.
- Se hai più librerie equivalenti e hai bisogno di parallelizzare la scrittura in esse, attiva la modalità di scrittura parallela, assegnando ruoli attivi a tutte le librerie. In questo caso, nuove cassette e driver saranno utilizzati immediatamente, non appena se ne presenterà la necessità, indipendentemente dalla libreria in cui si trovano. Tuttavia, esiste comunque una priorità: prima cercheremo di trovare risorse nella libreria che si trova più in alto nella lista.
- Se hai una libreria principale e un'unità più vecchia o un'unità standalone di riserva, attiva la modalità failover, posizionando la libreria principale in cima alla lista e selezionando un ruolo passivo per le unità di riserva. Il passaggio a tale dispositivo avverrà solo quando sarà realmente necessario, affinché il lavoro possa continuare in qualche modo. Questa situazione sarà considerata anomala e verrà inviata una notifica via email.
Esiste una situazione più complessa che attualmente non supportiamo: più librerie attive mentre sono presenti librerie passive. Il feedback indicherà se c'è bisogno di tali configurazioni e se è necessario perfezionare la funzionalità in futuro. È una prassi standard.
Supporto WORM
WORM – Write Once Read Many – cassette che non possono essere cancellate o riscritte , è possibile solamente aggiungere dati. Il loro utilizzo obbligatorio è regolamentato da alcune organizzazioni, ad esempio quelle operanti nel settore medico. Il problema principale con queste cassette era in passato che il VBR durante o registrava un'intestazione che non poteva più essere cancellata, e i job del nastro fallivano con un errore in caso di tale tentativo.
Nell'Update 4 della versione 9.5 è stata implementata un'assistenza completa per queste cassette. Sono stati aggiunti pool di media WORM, sia normali che GFS, in cui è possibile inserire solo cassette di questo tipo.
Le nuove cassette hanno un'icona blu, "congelata". Dal punto di vista dell'utente, il lavoro con cassette WORM non si differenzia da quello con cassette normali.
La "Wormness" delle cassette è inizialmente determinata dal suffisso , se il codice a barre è normale o illeggibile, il driver fornisce informazioni al primo inserimento della cassetta. Non sarà possibile inserire le cassette WORM in un pool media normale e scriverci sopra. Curiosamente, alcuni utenti hanno già attaccato codici a barre WORM a cassette normali, sorprendendosi dei cambiamenti nella loro infrastruttura dopo l'aggiornamento.
Chip della cassetta
Contemporaneamente all'implementazione delle cassette non riscrivibili, abbiamo iniziato a lavorare con . Inizialmente non utilizzavamo gli attributi standard nel chip, ma ora scriviamo e leggiamo in alcuni di essi, senza considerarli come la fonte principale di dati. La principale guida rimane comunque l'etichetta della cassetta. Questa decisione si è rivelata corretta: dopo un mese dal rilascio, vediamo come il «zoo» dell'hardware degli utenti ci riserva sorprese alla luce del lavoro con il chip.
Backup dei volumi NDMP su nastro
In conclusione, parliamo della funzione più richiesta in base al numero di recensioni di questo aggiornamento. È stato reso disponibile il backup dei volumi NDMP su cassette. Nella infrastruttura VBR è necessario , dopodiché sarà possibile scegliere i volumi da questo host nel job di tape. Vengono salvati su nastri come file con un attributo speciale per distinguerli da quelli normali durante la catalogazione.
Nella prima implementazione ci sono alcune limitazioni: non sono supportate le estensioni, e il backup e il ripristino sono possibili solo per l'intero volume, non per file singoli. Il backup funziona attraverso (nel caso di NetApp – ), ci sono delle peculiarità: il numero massimo di punti incrementali è 9, dopodiché viene forzato un backup completo.
In conclusione
Queste erano solo le principali novità nel campo del backup su nastro in VBR 9.5 Update 4. Altre modifiche le elencherò:
- possibilità di impostare l'ordine dei job sorgente e dei file nei job di nastro;
- aggiunto il ruolo di Tape Operator (l'utente può fare tutto tranne il ripristino da nastro – per questo esiste il Restore Operator);
- aggiunti maschere complete include/exclude nel job di tape file (escluso NDMP);
- è stato migliorato il recupero nel lavoro di tape (la cartella viene ripristinata con i file che erano presenti al momento del backup, invece di tutti quelli che sono mai stati in essa durante la sua storia di backup — una funzione molto richiesta, tra l'altro);
- è stata aumentata la velocità di ripristino di un numero molto elevato di file da nastri;
- è stato migliorato l'algoritmo di selezione del nastro successivo da registrare, in particolare, a parità di condizioni, teniamo conto del volume totale di dati scritti / letti nel corso della sua vita, scegliendo il più recente;
- è stata migliorata la stabilità del prodotto.
Link utili
Per variare, fornisco alcuni link a risorse in lingua russa:
- E siamo tornati ai video introduttivi «Come funziona» (anche se, al momento, in lingua inglese) – è possibile guardarli . Nei diapositive 95 – 102 si parla dei nastri.
Fonte: habr.com
