1,415
edits
Changes
From Studiosg
Jump to navigationJump to searchCelerra data migration service (view source)
Revision as of 13:52, 19 July 2011
, 13:52, 19 July 2011Created page with 'Benvenuti nella pagina Wiki di Simone Giustetti. Languages: [http://www.giustetti.net/wiki/index.php?title=En/celerra_data_migration_service English] - '''Italiano''' ---- =…'
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 è 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
----
[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²]
[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'''
Languages: [http://www.giustetti.net/wiki/index.php?title=En/celerra_data_migration_service 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
----
[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²]
[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'''
