Personal tools
Come stimare la migrazione degli allegati a Plone4

Un metodo per migliorare le stime

Oct 05, 2012

Come stimare la migrazione degli allegati a Plone4

In questo articolo illustreremo un approccio per stimare il tempo necessario per la migrazione di contenuti da Plone3 a Plone4

L'attività di stima è sempre un argomento complesso da trattare e non di rado capita che stime errate siano fonte di conflitto tra Project Manager e Developers. Ciò avviene, il più delle volte, perché il tempo necessario espresso con valori precisi è noto solo a lavoro finito. Accade quindi di frequente che quest'ultimo non coincida con quello stimato.

Recentemente ci è stato chiesto di stimare la migrazione di contenuti da Plone3 a Plone4, nel caso specifico in cui l'operazione sia ulteriormente condizionata dall'utilizzo di prodotti diversi per la gestione del FileSystemStorage (FSS) nelle due installazioni Plone.

Una valutazione iniziale spannometrica si sarebbe potuta ottenere velocemente consultando l'esperto del gruppo, ma questo approccio ha il grosso problema di affidarsi completamente all'esperienza e alla competenza del singolo, il quale senza test concreti, non ha la possibilità di essere preciso.
Interessante risulta essere quindi l'idea di fare uno studio. Questo offre la possibilità di produrre una stima più accurata, oltre ad avere il vantaggio di poter essere delegato a collaboratori meno esperti.

Ottimo! Allora avanti :-)

Lo studio

La procedura si basa sull’osservazione dell’andamento del grafico ottenuto analizzando i valori risultanti da processi di migrazione successivi di siti con dimensioni FSS diverse, e la conseguente estrapolazione e stima.

Come prima cosa è necessario dare qualche indicazione sull'applicazione utilizzata come caso di studio. Le caratteristiche sono brevemente riassunte come segue.

Plone 3.3.5
iw.fss (strategia site1)
redturtle.fss
70 GB~ data storage su file-system (/var/fss_storage_site)

Come procedere

Primo passo: creare l'ambiente 3.3.5.

Per l'attività da svolgere è sufficiente generare un buildout base:

paster create -t plone3_buildout plone3
virtualenv --distribute -p /home/opt/bin/python2.4 --no-site-packages .
bin/python bootstrap.py
Per il nostro studio è necessario inserire nel buildout tutti i prodotti coinvolti nella gestione FSS, quindi:
  • iw.fss
  • redturtle.fss (per la gestione tipi base Plone)
  • collective.contentgenerator

Nella versione 3.3.5 viene aggiunto anche collective.contentGenerator.
Questo prodotto viene utilizzato per popolare siti Plone con contenuti random.
A tal proposito, per snellire il processo, conviene portare i parametri per la generazione dei contenuti al massimo desiderato nel primo sito (per il nostro esempio i parametri sono tali da generare uno storage di circa 2.0 GB): risulta più semplice, infatti, creare siti intermedi semplicemente cancellando i dati direttamente da istanza, evitando quindi download successivi.

Per modificare i parametri per lo scarico dati, è stata utilizzata la versione trunk del prodotto e modificato direttamente il metodo "setupIntranet" nel file. collective/contentgenerator/setuphandlers.py. Si consiglia inoltre di modificare solo il parametro "multiply".

def setupIntranet(context):
    """ Run this content / user creation after standard generic setup handling
        Default settings for intranet ~ 10 mins ~ 200 Mb """
    users = {'groups':10,
             'memberships':10,
             'local':False,
             'users':100
             }
    content = {'sectioncount':3,
               'foldercount':5,
               'itemcount':10,
               'imagecount':5,
               'bigimagecount':5,                              
               'multiply'20,
               'profile':'intranet'
               }
    runSetup(context,content,users) 

Ora è possibile lanciare Plone e creare un sito. Durante il processo di creazione vengono scaricati direttamente i contenuti, è opportuno però ricordarsi di scegliere il profilo "Internet" precedentemente personalizzato prima di lanciare la creazione.
Questa fase potrebbe richiedere qualche minuto; nel frattempo si può procede con la configurazione dell'ambiente Plone 4.2

paster create -t plone4_buildout plone4
virtualenv --distribute --no-site-packages .
./bin/python bootstrap.py

Come per la versione precedente bisogna personalizzare il buildout:

  • iw.fss
  • redturtle.fss (per la gestione tipi base Plone)

iw.fss ha un problema con la versione 4 di Plone. Per una soluzione rapida, allo scopo di non modificare il prodotto come consigliato in questa guida, è possibile inserire Products.CMFCore nella sezione "eggs" in buildout.cfg.

Riporto qui parte del buildout per la versione 4.2:

[buildout]
extends=base.cfg
parts+=
fss
[instance] eggs += iw.fss redturtle.fss zcml+= Products.CMFCore iw.fss redturtle.fss
[fss] recipe = iw.recipe.fss storages = global / directory plone /site site1 ${buildout:directory}/var/fss_storage_site ${buildout:directory}/var/fss_backup_site

A questo punto, con i due ambienti correttamente installati e configurati, tutto dovrebbe essere pronto per i test.

Secondo passo: sincronizzazione dei dati.

La copia avviene a istanze ferme, lanciata direttamente su file-system dalla directory plone3 a plone4 con rsync. La via più semplice è quella di sincronizzare l’intera directory /var.

Il primo sito test in ambiente Plone3 avrà uno storage di circa 2.0 GB, le successive versioni dovranno quindi occupare via via uno spazio di disco minore.

Per determinare le dimensioni lanciare il comando du sulle directory di storage:

du -sh /var/fss*

Terzo passo: raccolta dei tempi.

Terminata la copia, bisogna lanciare l'istanza Plone4 e procedere con l'upgrade del sito. 
Dai log generati in console raccogliere e trascrivere i tempi di inizio e fine migrazione dei dati.
Importante! La copia e l'upgrade vanno ripetuti per tutte le dimensioni del sito che si è deciso di misurare.

Stima

Per brevità per il caso studio illustrato sono stati presi soltanto 3 campioni:

131 MG in 51 sec

1017 MG in 497 sec

1900 MG in 929 sec

Per una stima più accurata si consiglia di aumentare il numero di punti di misurazione e/o di incrementare la dimensione della base dati sulla quale lanciare i test di migrazione.

grafico

Il grafico generato dalle misurazioni raccolte mostra una crescita pressoché lineare.
Questo ci permette di stimare facilmente il tempo richiesto per l'upgrade dei contenuti, che nel nostro studio corrisponde a circa 10/11 ore (~70GB).

In conclusione, in un tempo ragionevolmente ridotto, applicando alcuni semplici metodi è possibile fare stime accurate. Ovviamente rimangono irrisolte le incognite, come per esempio il blocco del processo di migrazione o problemi hardware, ma del resto è possibile stimare solo il conosciuto.

I benefici non si fermano al solo valore determinato dallo studio_ rilevante infatti è anche il coinvolgimento del team nei processi di analisi.

Filed under: , , , ,
comments powered by Disqus