Salve, Sostanzialmente, ora noi abbiamo circa 16 TB di spazio disco su SAN agganciati montati su una SAN acceduta in fibre-channel da un datastore VMWARE i nostri colleghi del CED ci stanno proponendo di modificare la nostra infrastruttura geografica. che fornisce tale spazio a una nostra virtual-machine. Poiche' la ditta esterna che fornisce il supporto hardware ai nostri colleghi del CED ci dice che lei non e' in grado di incrementare su questa macchina piu' di 16TB di spazio disco da SAN, ci ha controproposto di modificare la nostra architettura e appoggiare tutti i nostri dati GIS su un aggeggione esterno che condividebbe i dati tramite protocolli peer-to-peer e nello specifico trattandosi di linux ci propongono di accederli montando una cartella tramite protocollo NFS che e' tra quelli supportati da questo aggeggione esterno. (!!) Ho obiettato che a me serviva un accesso ad alta velocita' (le velocita' di un disco rigido via bus per intendersi), e una connessione via peer NFS non fornisce tali livelli prestazionali. Il tecnico mi ha risposto che che questa era una storia passata, ma che gli attuali protocolli NFS garantiscono prestazioni eccezionali. Ho chiesto quindi documentazione, a ma tutti i fogli pervenutimi, parlano genericamente di protocollo NFS senza alcun dettaglio in mertio alle velocità di canale che riescono a fornire.Difficile in queste condizioni decidere e capire se la cosa conviene oppure no. Quindi sono alla ricerca di ulteriori informazioni relative all'impiego del NFS per accedere dati ad alte prestazioni (in termini di velocita') Mi domando se qualcuno ha avuto occasione di utilizzare una architettura in cui i dati GIS sono collocati su una cartella remota, condivisa via NFS , montata sul proprio server alla stregua di una cartella di un disco rigido e da li' accedere a tali dati per servirli via WMS. Sarei interessato a sapere che risultati ha avuto. E se è vero che si riesce ad avere prestazioni paragonabili a un accesso a disco rigido. Grazie,
-- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Il 04/02/2014 17:22, Andrea Peri ha scritto: > Sarei interessato a sapere che risultati ha avuto. > E se è vero che si riesce ad avere prestazioni paragonabili a un accesso a disco rigido. Tutta la mia esperienza di NFS mi consiglia di diffidare, non solo per le prestazioni. Ma e' vero che ho abbandonato l'uso di NFS (salvo poche cose) da qualche anno, e non ho piu' seguito gli sviluppi. Saluti. - -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlLxFHEACgkQ/NedwLUzIr51awCgj3bIpzURQdvUVAj56GzemePT OCUAn3DvFbVednNveLtOMCKvHjrgL3PR =1/Ov -----END PGP SIGNATURE----- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
Questa è la principale delle architetture che ci hanno proposto. Un ocumentoche esprime tanti discorsi , ma poi le cose serie sono scritte in piccolino...http://en.wikipedia.org/wiki/Dell_Fluid_File_System I dati si accedono via NFS o CIFS e tra le piieghe dei discorsi ho trovato scritto che per aumentare le prestazioni si fa' ricorso a sistemi di cache. > It also includes features to prevent data-loss or corruption and uses caching to increase performance.[2] Il che significa che se crescono i dati in TB alla fine se non aumenti la cache finisci per affossare le prestazioni. Ho cercato anche ulteriori informazioni , in questo altro documento: http://i.dell.com/sites/doccontent/shared-content/data-sheets/en/Documents/FluidFS_v3_Technical_Overview_white_paper_June_2013.pdf Ma sempre si resta vaghi sul fronte prestazionale. >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. L'unica è provarlo, ma per provarlo come fai' ? Dove lo trovi un NFS4 per metterci in piedi una infrastruttura e testarlo. E poi ti dicono che li' è una altra cosa, è tutto iper-ottimizzato.... Sistemi altamente moderni ed efficienti, etc.... Alte prestazioni, niente di apragonabile a cio'o che normalmente si conosce... E con questo sei servito. O gli credi o non gli credi. Il giorno 04 febbraio 2014 17:25, Paolo Cavallini <[hidden email]> ha scritto: -----BEGIN PGP SIGNED MESSAGE----- -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
Il giorno 04 febbraio 2014 17:56, Andrea Peri <[hidden email]> ha scritto:
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 _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
Grazie per le informazioni. E' quello che cerco.Informazioni su casi di uso con CIFS e roba simile. A. Il giorno 04 febbraio 2014 18:00, Stefano Iacovella <[hidden email]> ha scritto:
-- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
In reply to this post by Andrea Peri
Io sono rimasto stupito dalle prestazioni del sistema NFS che stiamo utilizzando recentemente.
Dico di più: ero convinto si trattasse di un comune disco esterno (tra l'altro molto grande...). Invece, con mio stupore ho scoperto si tratta di uno con protocollo NFS... Mi informerò per avere maggiori dettagli. Comunque, non è una "sóla" ( come dicono a Roma ) Ciao Roberto Inviato da iPhone Il giorno 04/feb/2014, alle ore 17:22, Andrea Peri <[hidden email]> ha scritto: > Salve, > i nostri colleghi del CED ci stanno proponendo di modificare la nostra infrastruttura geografica. > > Sostanzialmente, ora noi abbiamo circa 16 TB di spazio disco su SAN agganciati montati su una SAN acceduta in fibre-channel da un datastore VMWARE > che fornisce tale spazio a una nostra virtual-machine. > Che quella che fornisce i servizi WMS: > > Poiche' la ditta esterna che fornisce il supporto hardware ai nostri colleghi del CED ci dice che lei non e' in grado di incrementare su questa macchina piu' di 16TB di spazio disco da SAN, ci ha controproposto di modificare la nostra architettura e appoggiare tutti i nostri dati GIS su un aggeggione esterno che condividebbe i dati tramite protocolli peer-to-peer e nello specifico trattandosi di linux ci propongono di accederli montando una cartella tramite protocollo NFS che e' tra quelli supportati da questo aggeggione esterno. (!!) > > Sinceramente, quando mi hanno proposto una cosa del genere sulle prime credevo di sognare. > > Ho obiettato che a me serviva un accesso ad alta velocita' (le velocita' di un disco rigido via bus per intendersi), e una connessione via peer NFS non fornisce tali livelli prestazionali. > > Il tecnico mi ha risposto che che questa era una storia passata, ma che gli attuali protocolli NFS garantiscono prestazioni eccezionali. > > Ho chiesto quindi documentazione, a ma tutti i fogli pervenutimi, parlano genericamente di protocollo NFS senza alcun dettaglio in mertio alle velocità di canale che riescono a fornire. > > Difficile in queste condizioni decidere e capire se la cosa conviene oppure no. > > Quindi sono alla ricerca di ulteriori informazioni relative all'impiego del NFS per accedere dati ad alte prestazioni (in termini di velocita') > > Mi domando se qualcuno ha avuto occasione di utilizzare una architettura in cui i dati GIS sono collocati su una cartella remota, condivisa via NFS , montata sul proprio server alla stregua di una cartella di un disco rigido e da li' accedere a tali dati per servirli via WMS. > > Sarei interessato a sapere che risultati ha avuto. > E se è vero che si riesce ad avere prestazioni paragonabili a un accesso a disco rigido. > > Grazie, > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty àèìòù > ----------------- > _______________________________________________ > [hidden email] > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > Questa e' una lista di discussione pubblica aperta a tutti. > I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. > 666 iscritti al 22.7.2013 [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
In reply to this post by Stefano Iacovella
non mi occupavo della scelta hardware ma dovendo creare l'infrastruttura per fornire i processamenti in tempo reale dei Ground Segment delle Sentinel s'era escluso categoricamente l'uso di NFS. questo almeno fino a 1 anno fa... era stata individuato la scelta ma ero troppo preso da altre parti del codice. a presto Luigi Pirelli 2014-02-04 Stefano Iacovella <[hidden email]>:
_______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
In reply to this post by Andrea Peri
Scusami Andrea --------------------------------------------------- http://www.linkedin.com/in/stefanoiacovella http://twitter.com/#!/Iacovellas Il 04/feb/2014 18:38 "Andrea Peri" <[hidden email]> ha scritto:
_______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
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. Infatti quello che a noi prospetterebbero è proprio l'accesso tramite una connessione remota (in NFS) In mertio al numero:Per cui anche considerando l'overhead del VMWARE e del datastore (ammesso che ne abbia) siamo sempre su connessioni punto-punto a 1GB/s. 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. 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, 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. Se invece questo mitico NFS4 quadruplicasse la larghezza del canale rispetto al NFS2, allora sarebbe una altra storia.Perche' questo aggeggione esterno sarebbe topologicamente collocato su una rete ove transita di tutto... A. Il giorno 04 febbraio 2014 19:08, Stefano Iacovella <[hidden email]> ha scritto:
-- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
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 <[hidden email]> ha scritto:
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.
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.
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?
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.
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.
Si è una configurazione molto diffusa perchè è estremamente flessibile.
_______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
Free forum by Nabble | Edit this page |