[Gfoss] Informazioni su le prestazioni di un accesso a dati GIS via NFS.

Stefano Iacovella stefano.iacovella a gmail.com
Mar 4 Feb 2014 22:52:30 CET


Ciao Andrea,

ti rispondo sotto per precisare quanto ho raccontato prima e condividere le
mie poche informazioni.

Il giorno 04 febbraio 2014 20:15, Andrea Peri <aperi2007 a gmail.com> ha
scritto:

> Intendi dire che il mapserver accede i dati direttamente sul repository e
> non tramite una connessione remota ?
> Grazie della precisazione.
> E' importante capire questi dettagli.
>

No mi sono spiegato in fretta e probabilmente male. Nel nostro caso  la sAN
ospita dati di vario tipo, in larga parte datset spaziali ratser e
vettoriali ma anche altre tipologie di dati, e viene acceduta sia dai map
server sia dai client degli utenti.
Sia i server che i client vedono lo storage su protocollo CIFS.


> Infatti quello che a noi prospetterebbero è proprio l'accesso tramite una
> connessione remota (in NFS)
>
> In mertio al numero:
>
> Ho ricontrollato i conti che avevo fatto per stimare l'infrastruttura
> all'epoca.
>
> Avevo stimato una banda minima di 500 Mbit/s e quindi andava bene con i
> dischi sata.
> La nostra infrastruttura è partita su macchine fisiche in fibre-channel
> (che garantiva una connettività punto-punto di 1GB/s) e poi si è spostata
> su una macchina virtuale VMWARE che forniva spazio disco tramite un
> datastore che accedeva a uno spazio SAN in fibre-channle.
> Per cui anche considerando l'overhead del VMWARE e del datastore (ammesso
> che ne abbia) siamo sempre su connessioni punto-punto a 1GB/s.
> E sono valori minimi perche' se la scheda è dual-channel la banda
> raddoppiava.
>
> Ora invece ci prospettano una NFS "evoluta".
> Che per partire non è una connessione punto-punto. Poi, è un protocollo di
> rete che viaggia su ethernet e come si sa l'ethernet è una rete che si
> satura e va in ritrasmissione.
>
Corretto, sia su NFS che su CIFS viaggi su ethernet. Quindi la massima
banda teorica è data da quella disponibile sugli apparati di rete, poi
ovviamente la banda utile per il trasporto dei dati è sensibilmente
inferiore.


> Ho cercato su internet , ma non sono riuscito a trovare stime su questo
> protocollo NFS4.
> Ho trovato informazioni sul NFS2 che dicono arriva a 75MBit/s.
>
> Il che vuol dire che in un caso reale, in cui il nostro WMS accede circa 1
> GByte di dati tra raster e vettoriali per generare una mappa,
>

Questa tua affermazione non mi convince. La mappa che il tuo map server
deve produrre dubito che tipicamente richieda una tale quantità di dati.
Quella può essere la stima dello spazio occupato dai dataset visualizzati
nella mappa ma tipicamente a te ne basta una frazione. Se il raster è
ottimizzato, leggi piramidi, tra storage e map server non viaggia tutto il
raster ma solo una sua porzione, ricampionata. Sul vettoriale avrai degli
indici spaziali e in alcuni casi puoi avere delle ottimizzazioni simili a
quelle delle piramidi raster, ad esempio in GeoServer le pregeneralize
feature. Sei sicuro che viaggino davvero tutti quei dati per ogni map
request?

solo per permettere al mapserver di accedere i dati che sono ospitati su
> cartella remota e ipotizzando che il protocollo NFS viaggi a 100MB/s ci
> impiega 20 secondi.
>
> Per cui io stimerei un tempo di risposta di almeno 20-30 secondi, contro i
> 4 secondi di ora.
>

Continuando quanto espresso sopra io dubito che quei 4 sec siano tutti di
trasferimento dati. IMHO oltre il 50% sono di assemblaggio della mappa e
sua serializzazione.


>
> Se invece questo mitico NFS4 quadruplicasse la larghezza del canale
> rispetto al NFS2, allora sarebbe una altra storia.
>
> Ma resterebbe sempre il problema del transito su ethernet, che non essendo
> un protocollo punto-punto tende a saturarsi.
> E quindi a ridurre drasticamente le prestazioni in base al numero di
> utenze sulla rete ethernet.
>

Ovviamente una connessione punto-punto sarà sempre superiore, ma non
necessariamente una soluzione su Ethernet, qule ad esempio CIFS, è un
disastro. Nel tuo caso la connessione punto-punto è una opzione
percorribile perchè lo storage è a servizio esclusivo del cluster di map
server, nel mio caso non è ipotizzabile perchè lo storage è a servizio di
numerosi server e client.
In passato, in altre situazioni, avevo usato anche GFS (
http://en.wikipedia.org/wiki/GFS2) con buone prestazioni. E si basa sempre
su Ethernet.


> Perche' questo aggeggione esterno sarebbe topologicamente collocato su una
> rete ove transita di tutto...
>

Si è una configurazione molto diffusa perchè è estremamente flessibile.


>
> Prevedo tempi cupi....
>
> A.
>
>
>
> Il giorno 04 febbraio 2014 19:08, Stefano Iacovella <
> stefano.iacovella a gmail.com> ha scritto:
>
> Scusami Andrea
>> Intendi 500 Mbit o Mbyte?
>> Avevamo fatto dei test in passato ma non ricordo esattamente i risultati.
>> Il nostro caso di uso è abbastanza diverso. Si tratta di un repository di
>> dati che serve sia map server che client per l'accesso ai dati condivisi.
>> Stefano
>>
>> ---------------------------------------------------
>> 41.95581N 12.52854E
>>
>> http://www.linkedin.com/in/stefanoiacovella
>>
>> http://twitter.com/#!/Iacovellas
>> Il 04/feb/2014 18:38 "Andrea Peri" <aperi2007 a gmail.com> ha scritto:
>>
>> Grazie per le informazioni.
>>> E' quello che cerco.
>>> Informazioni su casi di uso con CIFS e roba simile.
>>>
>>> Nel mio caso, il client sarebbe un server WMS che accederebbe a immagini
>>> TIFF o a vettoriali posti su queste cartelle remotizzate e accedute via
>>> CIFS. Tramite questi dati remotizzati produrrebbe mappe WMS al volo.
>>>
>>> Avevo fatto qualche conto ed ero arrivato a stimare come banda minima
>>> 500MB/s.
>>> Per l'accesso ai dati raster e vector.
>>>
>>> A.
>>>
>>>
>>>
>>> Il giorno 04 febbraio 2014 18:00, Stefano Iacovella <
>>> stefano.iacovella a gmail.com> ha scritto:
>>>
>>>>
>>>> Il giorno 04 febbraio 2014 17:56, Andrea Peri <aperi2007 a gmail.com> ha
>>>> scritto:
>>>>
>>>> >The Fluid FS architecture is  an open-standardsbasednetwork attached
>>>>> storage (NAS) file system that supports industry standard protocols
>>>>> >including NFS v4 and CIFS/SMB v2.1
>>>>>
>>>>> Quindi sono alla versione 4 di NFS.
>>>>> Il che ci dicono lo rende incommensurabialmente piu' veloce del
>>>>> vecchio protocollo NFS.
>>>>>
>>>>> Io il protocollo NFS lo conosco e fa' schifo, ma non conosco il NFS4.
>>>>> :)
>>>>> E vai a sappi te come funziona.
>>>>>
>>>>
>>>> Ciao Andrea,
>>>>
>>>> e se provi SMB v. 2.1?
>>>> Da Linux dovresti comunque avere accesso senza problemi con Samba.
>>>> A breve, o forse è gia uscito, dovrebbe essere diponibile la v3 del
>>>> protocollo ma magari quello scatolotto li non la supporta.
>>>> Cmq dove lavoro usiamo smb 2.1, anche se con server Windows, e le
>>>> prestazioni sono soddisfacenti con moltossimi client in accesso.
>>>>
>>>> Stefano
>>>>
>>>> ---------------------------------------------------
>>>> 41.95581N 12.52854E
>>>>
>>>>
>>>> http://www.linkedin.com/in/stefanoiacovella
>>>>
>>>> http://twitter.com/#!/Iacovellas
>>>>
>>>
>>>
>>>
>>> --
>>> -----------------
>>> Andrea Peri
>>> . . . . . . . . .
>>> qwerty àèìòù
>>> -----------------
>>>
>>
>
>
> --
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -----------------
>
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20140204/92802ffd/attachment.html>


Maggiori informazioni sulla lista Gfoss