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@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@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@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.
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
Il giorno 04 febbraio 2014 18:00, Stefano Iacovella <stefano.iacovella@gmail.com> ha scritto:
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
Il giorno 04 febbraio 2014 17:56, Andrea Peri <aperi2007@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