Migrazione dati per sistemi di backup e archiving - Parte2

Introduzione

Con questo articolo riprendiamo la discussione sulle migrazioni dei sistemi di archiving o long-term retention iniziate a metà dicembre scorso. Nell’articolo precedente [leggi l'articolo] abbiamo visto quali sono le ragioni che possono o devono portare alla migrazione di un sistema di archiviazione. Affronteremo ora invece quelle che sono le situazioni e le problematiche più comuni che si riscontrano in tali progetti di migrazione.

Queste si possono raggruppare in tre categorie principali:

  • problemi di dimensionamento / bandwidth
  • aspetti di analisi, individuazione e filtering dei dati da migrare
  • problemi di disponibilità o funzionamento dell’hardware o software legacy

Ogni progetto di migrazione presenta uno o più di questi elementi che, quando non previsti, possono portare al fallimento dell’intero progetto. Andiamo ad analizzare più in dettaglio queste categorie di problematiche.

Dimensionamento e bandwidth hardware e software

Uno degli aspetti principali che caratterizzano qualsiasi progetto di migrazione è la “velocità di banda” (bandwidth) richiesta all’hardware e software per portare a termine il processo. Infatti, qualsiasi sistema di gestione dati è solitamente dimensionato per gestire il carico di lavoro (giornaliero, mensile, annuale, etc) previsto al momento di installazione + X % di crescita annua. Durante una migrazione invece, allo stesso sistema verrà chiesto di gestire un flusso di dati più grande di decine o centinaia di volte.

Prendiamo come esempio un’azienda con un job di archiviazione settimanale di uno o più NAS, con retention di 10 anni. A 5 anni dall’installazione del sistema i dati da archiviare sono cresciuti di un fattore 10. Se il job inizialmente impiegava 2 ore per il completamento, ora ne richiederà 20. L’azienda decide quindi di installare un nuovo sistema di archiviazione per ridurre la finestra di backup e meglio affrontare la crescita futura.

Per ridurre i costi, i tempi di recupero e la complessità di gestione dati, l’azienda decide di migrare gli archivi gestiti dal sistema storico (legacy) a quello nuovo. Utilizzando il sistema legacy, il solo passaggio di “restore” richiederà:

una media di 10 ore /archivio x 52 archivi settimanali /anno x 5 anni = 2600 ore o 108 giorni

E tale valore è calcolato con l’utilizzo esclusivo 24/7 non-stop del sistema legacy! A questo va aggiunto il tempo di backup sul nuovo sistema. Ma sorge un nuovo problema: dove vengono “parcheggiati” tutti quei dati prima di esser ri-archiviati? Occorre definire un processo adeguato che permetta di trasferire tale mole di dati. Può bastare un processo “manuale”?

Il processo restore + backup “manuale” e l’errore umano

Il processo di migrazione più immediato da implementare è quello manuale, dove un operatore effettua selettivamente una restore di ogni sessione originale, ridirigendolo ad un percorso temporaneo e poi lancia un job di backup con il nuovo sistema di archiviazione, impostando eventuali parametri di retention come presenti nel sistema legacy.

Per qualche decina di sessioni, questo può essere un metodo attuabile, ma quando queste diventano centinaia o migliaia, diventa subito tedioso, lungo e facilmente suscettibile a errori umani di impostazione dei parametri.

Analisi e filtering dei dati da migrare

Alle problematiche viste finora si aggiunge un’esigenza molto comune: dato che nella maggior parte dei casi il sistema di archiviazione è lo stesso utilizzato per i backup di disaster-recovery, occorre selezionare il sottoinsieme di dati d’archiviazione e quindi, da migrare. Inoltre, può essere richiesto di applicare altri filtri per ridurre ulteriormente la quantità di dati migrati.

I report con i dati necessari a definire questi filtri e le funzionalità per applicare i filtri vengono forniti dalle applicazioni di backup, ma per analisi più complesse occorre quasi sempre sfruttare degli strumenti esterni. I risultati delle analisi dovranno poi essere utilizzati per automatizzare la migrazione dei set di dati corrispondenti.

Backup tramite agent e backup NDMP

Nelle migrazioni dei sistemi di backup ci si trova molte volte a che fare con sessioni create da agent: dei moduli specifici per applicazioni o formati particolari, come ad esempio i database server, i server di posta elettronica, Microsoft Sharepoint Server, etc.

Queste sessioni non possono essere migrate così come sono poiché incapsulano una serie di informazioni sullo specifico ambiente protetto da backup. Occorre prima preparare un ambiente applicativo identico a quello di partenza, fare il restore e configurare il corrispondente agent nell’ambiente di destinazione. Queste sono operazioni che possono richiedere giornate o settimane intere di lavoro.

Altro caso importante è quello dei backup NDMP. Il Network Data Management Protocol permette di trasferire i dati da un NAS direttamente verso un dispositivo di backup, senza passare dal o sovraccaricare il server di backup. Questo consente di ottenere prestazioni migliori e ridurre il carico del lavoro del server. Il rovescio della medaglia è che il formato dei dati sul dispositivo è proprietario del NAS che lo ha generato. Ciò significa che potrà essere letto solo da un dispositivo con la stessa versione del sistema operativo del NAS originario. Non è quindi ad esempio supportato il restore su un NAS NetApp di un backup NDMP generato da un EMC Celerra o viceversa.

Sistema legacy non più disponibile o funzionante

Fino a questo momento abbiamo parlato di situazioni particolari con le quali ci si deve confrontare durante le migrazioni tra sistemi diversi, ma ambedue ancora attivi e perfettamente funzionanti. E se invece il sistema legacy non esistesse più o fosse in parte o completamente non funzionante?

In questo caso le difficoltà si moltiplicano, alcuni esempi:

  • malfunzionamenti dei drive e/o dei media causanti rallentamenti, continui interventi correttivi manuali, errori di lettura
  • incompatibilità del software legacy con l’hardware e software attualmente a disposizione
  • incompatibilità dell’hardware legacy (ad esempio le varianti di SCSI interface o adapter) con l’hardware a disposizione
  • hardware completamente non funzionante

Senza gli opportuni strumenti ed un approccio collaudato, la risoluzione di tali problemi spesso diventa così onerosa in termini di tempi e di costi da portare alla decisione di rinunciare al progetto e di conseguenza ai benefici della migrazione stessa.