View source for Celerra data migration service

Benvenuti nella pagina Wiki di Simone Giustetti.


Languages: [http://www.giustetti.net/wiki/index.php?title=En/celerra_data_migration_service English] - '''Italiano'''

----


== Celerra Data Migration Service ==
Il CDMS &egrave; 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&agrave; del dato, garantendo nel contempo la possibilit&agrave; 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&agrave; 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&agrave; 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 &egrave; necessario eseguire alcune verifiche preventive: soprattutto controlli circa l'infrastruttura e la sorgente dei dati da migrare.

=== Connettivit&agrave; di rete ===
Il controllo forse pi&ugrave; importante riguarda la connettivit&agrave; di rete tra gli apparati. Sar&agrave; 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'''. &Egrave; 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&agrave; dell'infrastruttura, si proceda con i controlli a pi&ugrave; alto livello. Il Celerra '''dovr&agrave; essere in grado leggere i dati condivisi via NFS''', perci&ograve; sar&agrave; 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&agrave; essere '''esportata in sola lettura'''. La modifica dei parametri di esportazione pu&ograve; essere posticipata in modo da minimizzare il periodo di fermo del file system condiviso. '''La configurazione dovr&agrave; 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&agrave; comunque a termine, ma falliranno i successivi controlli di congruenza ed '''il file system non potr&agrave; di fatto essere utilizzato dal Celerra'''. Nel migliore dei casi la migrazione risulter&agrave; un fallimento e dovr&agrave; essere ripetuta in toto.

Nel proseguo dell'articolo si dar&agrave; per assodato che: 
* La connettivit&agrave; 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&agrave; 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&agrave; per assodato che il file system di destinazione sia in grado di contenere abbondantemente quello sorgente.

=== Verifica del block size ===
Un altro controllo che &egrave; bene eseguire riguarda la dimensione del block size configurato sul file system da migrare. Quando non &egrave; 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&ograve; procedere a creare il nuovo file system che verr&agrave; 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&agrave; il contenuto di quello vecchio e controller&agrave; il processo di copia in modo che i dati acceduti vengano migrati per primi. Di conseguenza il periodo di indisponibilit&agrave; della condivisione risulter&agrave; 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&ograve; procedere con la copia dei dati dal file system sorgente a quello di destinazione.

=== Fasi preliminari ===
Prima di procedere con la copia dei dati &egrave; 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&agrave; 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&igrave; facendo i dati non potranno pi&ugrave; essere modificati. L'operazione '''comporta obbligatoriamente un fermo dei servizi''' che usufruiscono del file system condiviso e dovr&agrave; perci&ograve; essere concordata con gli opportuni gruppi applicativi. Nel caso di un server Red Hat Linux, sar&agrave; 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&agrave; essere aggiornata in:
   /SHARE/app_doc -ro db01acvs.pro.nas db01bcvs.pro.nas cl001nas.be.pro.nas
Per rendere definitive le modifiche &egrave; 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 &egrave; 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&ograve; 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 &egrave; 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&agrave; 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&ograve; 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&agrave; il seguente contenuto:
   d /cvs_app_doc/cvs_app_doc/backup
Ove "backup" &egrave; 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&ograve; 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 &egrave; ripetuto due volte poich&egrave; il servizio CDMS crea una directory con stesso nome del file system all'interno dello stesso e l&igrave; copia i dati. '''Per verificare che il percorso di esclusione sia corretto''' &egrave; possibile utilizzare uno strumento fornito dal Celerra: '''specialCmd'''. Nel nostro esempio la verifica pu&ograve; essere ottenuta lanciando il comando:
   '''/nas/tools/cdms/specialCmd''' getOnline server_2 /cvs_app_doc/cvs_app_doc/backup
Il comando non produrr&agrave; un output vero e proprio, ma l'esito potr&agrave; essere estratto analizzando le ultime righe del log di sistema mediante il comando:
   '''server_log''' server_2

=== Esclusione di eventuali snapshot ===
Pu&ograve; 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&ugrave; 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&agrave; 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 &egrave; stata correttamente avviata e sta procedendo.

Studiando invece lo stato di occupazione del file system di destinazione si potr&agrave; ottenere una stima grossolana dello stato di avanzamento e della velocit&agrave; 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&agrave; lo sato di occupazione del file system minuto per minuto. Il comando dovr&agrave; 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&agrave; 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 &egrave; 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&agrave; 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&agrave; 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&agrave; 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&agrave; considerarsi felicemente conclusa e sar&agrave; 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 &egrave; 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&ograve; pertanto essere eseguita a caldo senza ripercussioni sugli utenti o i processi che si appoggiano sulla risorsa condivisa.

Come ultimo passo &egrave; 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 &egrave; stato traslocato da una sorgente NFS generica ad uno storage array appartenente alla famiglia Celerra di Emc&sup2;. Per eseguire la migrazione ci si &egrave; 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&sup2;.
----


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


Link externi

----

[http://www.freebsd.org/doc/it_IT.ISO8859-15/books/handbook/network-nfs.html Protocollo NFS (FreeBsd Handbook)]

[http://nfs.sourceforge.net/ Protocollo NFS (Linux FAQ)]

[http://it.wikipedia.org/wiki/Network_File_System Protocollo NFS (wikipedia)]

[http://www.emc.com Home page di Emc&sup2;]

[http://italy.emc.com/products/family/celerra-family.htm Home page del Celerra]

[http://www.netapp.com/it/ Home page di NetApp]


----

Languages: [http://www.giustetti.net/wiki/index.php?title=En/celerra_data_migration_service English] - '''Italiano'''