Changes

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

Lingue: [[en/celerra_data_migration_service | English]] - '''Italiano'''

----

----

== Preparazione alla migrazione ==

== 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.

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 ===

=== 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 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.

* Sia possibile scrivere sulla share sorgente fino all'ultimo momento utile.

* Sia possibile scrivere sulla share sorgente fino all'ultimo momento utile.

=== Calcolo della dimensione del file system ===

=== 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.

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 documentazione ufficiale.

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

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 ===

=== 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.

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 ===

=== 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]].

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:

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

   '''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 '''-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.

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:

Si proceda alla creazione del '''mount point''' ed al successivo mount del file system:

   '''server_mountpoint''' server_2 -c /cvs_app_doc

   '''server_mountpoint''' server_2 ''-c'' /cvs_app_doc

   '''server_mount''' server_2 -o rw cvs_app_doc /cvs_app_doc

   '''server_mount''' server_2 ''-o'' rw cvs_app_doc /cvs_app_doc

----

----

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.

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 ===

=== Fasi Preliminari ===

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

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

   '''server_setup''' server_2 ''-Protocol'' cdms ''-option'' start

Eseguire un'ultima verifica della connettività di rete:

Eseguire un'ultima verifica della connettività di rete:

   '''server_ping''' server_2 nfs001.pro.nas

   '''server_ping''' server_2 nfs001.pro.nas

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

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

   '''server_cdms''' server_2 -info cvs_app_doc

   '''server_cdms''' server_2 ''-info'' cvs_app_doc

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

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

   server_2 :

   server_2 :

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

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

=== Modifiche sul sorgente ===

=== 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:

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

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

Dovrà essere aggiornata in:

Dovrà essere aggiornata in:

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

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

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

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

   '''service''' nfs restart

   '''service''' nfs restart

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.

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 ===

=== Associazione tra File System ===

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

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

   '''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:

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

   '''server_cdms''' server_2 -info cvs_app_doc

   '''server_cdms''' server_2 ''-info'' cvs_app_doc

    

    

   server_2 :

   server_2 :

   nfs=nfs001.pro.nas:/SHARE/app_doc proto=TCP

   nfs=nfs001.pro.nas:/SHARE/app_doc proto=TCP

=== Filtrare i dati ===

=== 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:

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>

   f /<path>/<file>

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

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

   d /cvs_app_doc/cvs_app_doc/backup

Ove "backup" &egrave; appunto la directory contenente i dati inutili ai fini della migrazione.

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'''.

'''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'''.

   '''server_log''' server_2

   '''server_log''' server_2

=== Esclusione di eventuali snapshot ===

=== 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:

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

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

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

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

=== Avvio della migrazione ===

=== Avvio della Migrazione ===

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

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

   '''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:

Lo stato dell'operazione potr&agrave; essere monitorato attraverso il comando:

   '''server_cdms''' server_2 -info cvs_app_doc

   '''server_cdms''' server_2 ''-info'' cvs_app_doc

    

    

   server_2 :

   server_2 :

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''.

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 ===

=== 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:

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'' 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'' 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

   '''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:

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

   '''server_export''' server_2 | grep cvs_app_doc

   '''server_export''' server_2 | '''grep''' cvs_app_doc

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

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

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

   '''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:

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

   '''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

   /mnt/SHARE/app

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

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

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.

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 ===

=== Copia dei Dati Ultimata ===

Come accennato in precedenza il comando

Come accennato in precedenza il comando

   '''server_cdms''' server_2 -info cvs_app_doc

   '''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.

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 ==

== 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:

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_cdms''' server_2 ''-C'' cvs_app_doc

    

    

   server_2 : done

   server_2 : done

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.

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

   '''nas_ckpt_schedule''' ''-create'' cvs_app_doc_daily ''-filesystem'' cvs_app_doc ''-recurrence'' daily ''-every'' 1 ''-runtimes''

   02:30 -keep 7

   02:30 ''-keep'' 7

----

----

Link externi

Link esterni

----

----

----

----

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

Lingue: [[en/celerra_data_migration_service | English]] - '''Italiano'''