Difference between revisions of "Celerra data migration service"

Revision as of 13:52, 19 July 2011

Benvenuti nella pagina Wiki di Simone Giustetti.

Languages: English - Italiano

Celerra Data Migration Service

Il CDMS è un servizio che consente di migrare dischi e file system condivisi da sorgenti eterogenee verso un Celerra attraverso i protocolli NFS e CIFS. L'impiego di CDMS consente di minimizzare i tempi di indisponibilità del dato, garantendo nel contempo la possibilità di leggere da e scrivere su le share per l'intera durata della migrazione. Molti attributi dei file quali i permessi, l'ultima modifica, l'ultimo accesso, ed altri ancora sono preservati durante la migrazione.

Nel seguito del presente articolo verrà esposta la sequenza di operazioni necessarie a migrare un file system condiviso attraverso il protocollo NFS da un generico file server ad un Celerra. A titolo di esempio si supponga di migrare una share avente le caratteristiche esposte di seguito:

Nome: app_doc
Dimensione: 200 Gb
Sistema Operativo: Linux
Esportata come: nfs001.pro.nas:/SHARE/app_doc
Visibile ai soli host db01acvs e db01bcvs attraverso il dominio pro.nas
Montata sul mountpoint: /mnt/SHARE/app

Che verrà migrata su:

Nome: cvs_app_doc
Dimensione: 300 Gb
Residente su: Il secondo Data Mover del Celerra cl001nas
Esportata attraverso l'interfaccia: cl001nas.fe.pro.nas
Esportata verso gli host db01acvs e db01bcvs

Preparazione alla migrazione

Prima di procedere con la migrazione vera e propria è necessario eseguire alcune verifiche preventive: soprattutto controlli circa l'infrastruttura e la sorgente dei dati da migrare.

Connettività di rete

Il controllo forse più importante riguarda la connettività di rete tra gli apparati. Sarà opportuno non solo verificare che gli stessi colloquino correttamente, ma anche che l'infrastruttura sia in grado di sopportare il carico dei dati che si intende migrare. E' fondamentale eseguire un controllo sull'ampiezza di banda disponibile soprattutto se non si disponesse di una rete dedicata e si prevedesse di far passare il traffico attraverso quella di produzione. Se la banda risultasse strozzata il tempo di migrazione si dilaterebbe e le macchine attestate sulla medesima rete potrebbero risentirne negativamente. In un simile scenario sarebbe opportuno valutare altre forme di trasferimento dei file ad esempio la classica sequenza back-up / restore.

Il secondo controllo sull'infrastruttura riguarda l'eventuale presenza di firewall. È bene che non siano presenti apparati che filtrino il traffico dati tra gli attori della migrazione. La mole di dati movimentata potrebbe essere tale da causare un crash dei firewall con evidenti ripercussioni alla sicurezza della rete.

Verificata la capacità dell'infrastruttura, si proceda con i controlli a più alto livello. Il Celerra dovrà essere in grado leggere i dati condivisi via NFS, perciò sarà necessario aggiungere all'elenco delle macchine aventi accesso alla share il Fully Qualified Domain Name o l'indirizzo IP del Data Mover designato a contenere i dati migrati. Durante la fase di copia dei dati, inoltre, gli stessi non dovranno essere modificati dal lato della sorgente, ma solo da quello del Celerra. La share sorgente dei dati dovrà essere esportata in sola lettura. La modifica dei parametri di esportazione può essere posticipata in modo da minimizzare il periodo di fermo del file system condiviso. La configurazione dovrà comunque essere aggiornata obbligatoriamente prima che venga avviato il processo di copia dei dati; dopo sarebbe troppo tardi.

Nel caso in cui i dati vengano modificati lato sorgente l'operazione di copia andrà comunque a termine, ma falliranno i successivi controlli di congruenza ed il file system non potrà di fatto essere utilizzato dal Celerra. Nel migliore dei casi la migrazione risulterà un fallimento e dovrà essere ripetuta in toto.

Nel proseguo dell'articolo si darà per assodato che:

La connettività ed i servizi di rete in genere funzionino e siano configurati a dovere.
Il server DNS sia attivo e i nomi macchina vengano risolti in indirizzi IP e viceversa.
La banda passante sia dimensionata correttamente per la mole dei dati da migrare.
Sia possibile scrivere sulla share sorgente fino all'ultimo momento utile.

Calcolo della dimensione del file system

Il file system di destinazione dovrà avere dimensioni maggiori uguali di quello sorgente. Nel caso si sottostimassero le dimensioni, la copia dei dati e conseguentemente la migrazione fallirebbero. Per evitare l'inconveniente il Celerra mette a disposizione uno script Perl in grado di valutare la dimensione minima del file system di destinazione: diskUsage.pl. Lo script diskUsage.pl deve essere lanciato sulla macchina su cui risiede il file system sorgente. Per la sintassi del comando e una descrizione dettagliata delle opzioni si rimanda alla documantazione ufficiale.

Nel proseguo dell'articolo si darà per assodato che il file system di destinazione sia in grado di contenere abbondantemente quello sorgente.

Verifica del block size

Un altro controllo che è bene eseguire riguarda la dimensione del block size configurato sul file system da migrare. Quando non è specificato altrimenti, i nuovi fils system creati su Celerra utilizzano un block size di 8 Kb. Il file system sorgente potrebbe invece utilizzare un block size di dimensione inferiore. La differenza potrebbe risultare in una eccessiva frammentazione del file system migrato con conseguente perdita di prestazioni. Per ovviare il problema si consiglia di forzare il block size del file system creato sul Celerra alla medesima dimensione utilizzata dal sorgente.

Creazione del file system di destinazione

Eseguite le verifiche si può procedere a creare il nuovo file system che verrà in seguito esportato dal Celerra. Nel proseguo dell'articolo verranno utilizzati i comandi messi a disposizione dalla Command Line Interface attraverso un terminale. Per una descrizione dettagliata della procedura si faccia riferimento al mio precedente articolo: celerra_share_nfs.

Dopo essersi collegati alla Control Station mediante l'utenza nasadmin, si lancino i comandi:

  nas_fs -name cvs_app_doc -type mgfs -create size=300G pool=clar_r5_performance -option nbpi=4096

L'opzione -type mgfs impone la creazione di un file system di una tipologia specifica per le migrazioni. All'avvio della migrazione il nuovo file system indicizzerà il contenuto di quello vecchio e controllerà il processo di copia in modo che i dati acceduti vengano migrati per primi. Di conseguenza il periodo di indisponibilità della condivisione risulterà minimo.

L'opzione -option nbpi=4096, invece, impone un block size di 4 Kb. Si proceda alla creazione del mount point ed al successivo mount del file system:

  server_mountpoint server_2 -c /cvs_app_doc
  server_mount server_2 -o rw cvs_app_doc /cvs_app_doc

Migrazione

Una volta ultimati i controlli e le operazioni propedeutiche, si può procedere con la copia dei dati dal file system sorgente a quello di destinazione.

Fasi preliminari

Prima di procedere con la copia dei dati è necessario avviare il servizio CDMS sul Data Mover attraverso il comando:

  server_setup server_2 -Protocol cdms -option start

Eseguire un'ultima verifica della connettività di rete:

  server_ping server_2 nfs001.pro.nas

Verificare che il file system di destinazione sia stato correttamente montato sul Data Mover:

  server_cdms server_2 -info cvs_app_doc

In caso affermativo l'output del comando dovrebbe assomigliare al seguente:

  server_2 :
  cvs_app_doc:

Tutti i comandi elencati in precedenza possono essere lanciati dall'utente nasadmin collegato alla Control Station del Celerra.

Modifiche sul sorgente

E' necessario, nel caso non sia stato possibile provvedere in precedenza, modificare la configurazione della share sulla macchina sorgente imponendo una condivisione in sola lettura per tutti i client. Così facendo i dati non potranno più essere modificati. L'operazione comporta obbligatoriamente un fermo dei servizi che usufruiscono del file system condiviso e dovrà perciò essere concordata con gli opportuni gruppi applicativi. Nel caso di un server Red Hat Linux, sarà necessario modificare il contenuto del file /etc/exports. Supponendo che la riga dedicata alla condivisione sia:

  /SHARE/app_doc -rw db01acvs.pro.nas db01bcvs.pro.nas

Dovrà essere aggiornata in:

  /SHARE/app_doc -ro db01acvs.pro.nas db01bcvs.pro.nas cl001nas.be.pro.nas

Per rendere definitive le modifiche è necessario riavviare il demone NFS:

  service nfs restart

Operazioni che devono essere eseguite dall'utente root o da altro utente con sufficienti permessi.

Onde evitare problemi ai client db01acvs.pro.nas e db01bcvs.pro.nas sarebbe opportuno smontar loro la share prima di aggiornare la configurazione sul server nfs001.pro.nas.

Associazione tra file system

Tutto è ormai pronto per associare il file system di destinazione a quello sorgente tramite il comando:

  server_cdms server_2 -c cvs_app_doc -t nfsv3 -p /cvs_app_doc -s nfs001.pro.nas:/SHARE/app_doc

Interrogando nuovamente lo stato del servizio, l'output reso dovrebbe assomigliare a:

  server_cdms server_2 -info cvs_app_doc
  
  server_2 :
  cvs_app_doc:
  path    = /cvs_app_doc
   cid    = 0
   type   = nfs
   source = nfs001.pro.nas:/SHARE/app_doc
  options =

Una ulteriore verifica circa il successo dell'operazione può essere ottenuta attraverso l'analisi dei log:

  server_log server_2

La parte finale dell'output reso dovrebbe contenere righe simili a:

  2011-07-05 17:58:04: ADMIN: 4: Command succeeded: connect fsid=02 type=nfsv3 path=/cvs_app_doc
  nfs=nfs001.pro.nas:/SHARE/app_doc proto=TCP

Filtrare i dati

Non sempre è necessario o desiderabile migrare tutti i dati pertanto il servizio CDMS consente di filtrare il contenuto presente nella share sorgente escludendone una parte durante il processo di copia. Il filtraggio viene effettuato sulla base di un file di esclusione contenente una lista di tutti i file e le directory da ignorare. Ogni riga della lista contenuta nel file rappresenta un elemento da ignorare. Il primo carattere delle riga specifica invece se si tratti di un singolo file oppure una directory. Segue un esempio di formattazione della lista:

  f /<path>/<file>
  d /<path>/<directory>

Il file di esclusione dovrà essere salvato in una directory leggibile dal servizio CDMS sul Data Mover interessato dalla migrazione. Nel nostro esempio si supponga che la directory di log abbia nome cdms_log_2. Il file può essere creato e modificato tramite un qualsiasi editor di testo ad esempio vi:

  vi /nas/quota/slot_2/cdms_log_2/exclude_cvs_20110706.txt

Supponendo di voler escludere una directory contenente alcuni back-up estemporanei eseguiti sulla share sorgente, la lista avrà il seguente contenuto:

  d /cvs_app_doc/cvs_app_doc/backup

Ove "backup" è appunto la directory contenente i dati inutili ai fini della migrazione.

Per creare il file di esclusione sono necessari privilegi elevati; quelli dell'utenza nasadmin non sono sufficienti. Si può ovviare alla limitazione utilizzando il comando su - e digitando l'opportuna password per assumere l'identita' dell'utenza root, oppure aprendo una seconda connessione alla Control Station tramite l'utenza root.

Il percorso delle directory ha origine dal file system creato sul Celerra. Il nome del file system è ripetuto due volte poichè il servizio CDMS crea una directory con stesso nome del file system all'interno dello stesso e lì copia i dati. Per verificare che il percorso di esclusione sia corretto è possibile utilizzare uno strumento fornito dal Celerra: specialCmd. Nel nostro esempio la verifica può essere ottenuta lanciando il comando:

  /nas/tools/cdms/specialCmd getOnline server_2 /cvs_app_doc/cvs_app_doc/backup

Il comando non produrrà un output vero e proprio, ma l'esito potrà essere estratto analizzando le ultime righe del log di sistema mediante il comando:

  server_log server_2

Esclusione di eventuali snapshot

Può capitare di migrare dati a partire da apparati che utilizzino snapshot per eseguire back-up dei dati. Gli snapshot devono sempre essere esclusi durante la migrazione a meno che non si voglia incorrere nel rischio di saturare il file system di destinazione facendo fallire il processo. Si supponga di voler migrare un file system tra due Celerra. Se sul sorgente fosse stato configurato un checkpoint (uno snapshot nella terminologia del Celerra) giornaliero con ritenzione settimanale, l'ammontare complessivo dei dati movimentati risulterebbe pari a circa otto volte quello effettivamente necessario. I dati del file system più le sette copie giornaliere della settimana pecedente. Il filtro da inserire nel file di esclusione sarebbe:

  d /<file system>/<file system>/.ckpt

Analogo discorso nel caso di apparati NetApp. Il filtro in questo caso dovrebbe contenere la riga:

  d /<file system>/<file system>/.snapshot

Avvio della migrazione

Per dare il via all'effettiva copia dei dati si lanci il comando:

  server_cdms server_2 -start cvs_app_doc -p /cvs_app_doc -l /cdms_log_2 -e /cdms_log_2/exclude_cvs_20110706.txt

Lo stato dell'operazione potrà essere monitorato attraverso il comando:

  server_cdms server_2 -info cvs_app_doc
  
  server_2 :
  cvs_app_doc:
  path     = /cvs_app_doc
   cid     = 0
   type    = nfs
   source  = nfs001.pro.nas:/SHARE/app_doc
  options  =
  threads:
   path    =
    state  = ON_GOING
    log    = /cdms_log_2

Lo stato ON_GOING indica che la copia dei dati è stata correttamente avviata e sta procedendo.

Studiando invece lo stato di occupazione del file system di destinazione si potrà ottenere una stima grossolana dello stato di avanzamento e della velocità di copia. Per ottenere tale stima si lanci il comando:

  while true; do server_df server_2 /cvs_app_doc;sleep 60;done

Che renderà lo sato di occupazione del file system minuto per minuto. Il comando dovrà essere interrotto premendo la combinazione di tasti CTRL+c.

Esportazione del nuovo file system

Una volta iniziata la copia dei dati, il file system potrà essere esportato dal Celerra in modo che le macchine client possano ricominciare ad utilizzare la risorsa condivisa. Per esportare il file system verso i client designati è necessario lanciare la seguente sequenza di comandi:

  server_export server_2 -Protocol nfs -option rw=db01acvs.pro.nas:db01bcvs.pro.nas /cvs_app_doc/cvs_app_doc
  server_export server_2 -Protocol nfs -option root=db01acvs.pro.nas:db01bcvs.pro.nas /cvs_app_doc/cvs_app_doc
  server_export server_2 -Protocol nfs -option access=db01acvs.pro.nas:db01bcvs.pro.nas /cvs_app_doc/cvs_app_doc

Per verificare dalla Control Station l'avvenuta condivisione si lanci il comando:

  server_export server_2 | grep cvs_app_doc

Per eseguire la verifica dai client invece si utilizzi il comando:

  showmount -e cl001nas.fe.pro.nas | grep cvs_app_doc

Il file system dovrà essere esplicitamente montato sui client db01acvs.pro.nas e db01bcvs.pro.nas. Per farlo ci si colleghi come utente root alle macchine e si esegua il comando:

  mount -t nfs -o rw,bg,hard,intr,nfsvers=3,rsize=8192,wsize=8192,proto=tcp cl001nas.fe.pro.nas:/cvs_app_doc/cvs_app_doc
  /mnt/SHARE/app

L'operazione di mount potrà essere resa automatica all'avvio delle macchine aggiornando il file /etc/fstab modificando la riga

  nfs001.pro.nas:/SHARE/app_doc /mnt/SHARE/app nfs rw,bg,hard,intr,nfsvers=3,rsize=8192,wsize=8192,proto=tcp 0 0

in

  cl001nas.fe.pro.nas:/cvs_app_doc/cvs_app_doc /mnt/SHARE/app nfs rw,bg,hard,intr,nfsvers=3,rsize=8192,wsize=8192,proto=tcp 0 0

Da quanto esposto sin qui si evince che il periodo di indisponibilità dei servizi si estende dal momento in cui viene modificata in sola lettura l'esportazione della share origine al successivo mount della nuova share sulle macchine client.

Copia dei dati ultimata

Come accennato in precedenza il comando

  server_cdms server_2 -info cvs_app_doc

fornisce un resoconto sull'andamento della migrazione e della copia di file e directory. Qualora il comando rendesse come stato SUCCEED la fase di copia potrà considerarsi felicemente conclusa e sarà possibile passare alla fase di configurazione posteriore alla migrazione.

Configurazione post migrazione

Una volta conclusa la copia dei dati, la tipologia di file system deve essere convertita da mgfs al formato standard. Per farlo è necessario collegarsi alla Control Station del Celerra mediante l'utenza nasadmin e lanciare il comando:

  server_cdms server_2 -C cvs_app_doc
  
  server_2 : done

L'operazione non interferisce con l'esportazione del file system e può pertanto essere eseguita a caldo senza ripercussioni sugli utenti o i processi che si appoggiano sulla risorsa condivisa.

Come ultimo passo è possibile mettere in sicurezza i dati aggionando la configurazione dei back-up oppure schedulando un checkpoint per il nuovo file system. Il comando che segue, ad esempio, schedula un checkpoint alle 2:30 di notte, ogni notte, con una ritenzione settimanale.

  nas_ckpt_schedule -create cvs_app_doc_daily -filesystem cvs_app_doc -recurrence daily -every 1 -runtimes
  02:30 -keep 7

Conclusioni

Nel corso del presente articolo sono state elencate e sviscerate le fasi principali di una migrazione di share condivisa attraverso protocollo NFS. Il file system condiviso è stato traslocato da una sorgente NFS generica ad uno storage array appartenente alla famiglia Celerra di Emc². Per eseguire la migrazione ci si è appoggiati al servizio CDMS di cui sono dotati i Celerra.

Per approfondire l'argomento si invitano gli interessati a consultare la documentazione ufficiale di Emc².

Per commenti, consigli, domande inviate una e-mail all'indirizzo studiosg [chiocciola] giustetti [punto] net.

Link externi

Protocollo NFS (FreeBsd Handbook)

Protocollo NFS (Linux FAQ)

Protocollo NFS (wikipedia)

Home page di Emc²

Home page del Celerra

Home page di NetApp