Ottimizzare le prestazioni dei PDM su reti remote

La possibilità di interfacciarsi con il sistema PDM del proprio cliente può costituire un importante vantaggio competitivo per uno studio tecnico esterno. Per l’azienda cliente infatti la possibilità di verificare, valutare ed eventualmente correggere il lavoro del consulente esterno in tempo reale è considerata importantissima e quindi l’azienda stessa, a parità di altre condizioni, tenderà invariabilmente a scegliere il fornitore di progettazione che abbia deciso di dotarsi di questa infrastruttura per il trattamento dei dati di progetto.

Dal suo ufficio il progettista esterno potrà quindi operare quasi come se fosse un interno: salvare i progetti direttamente sul database, interrogare l’archivio e le anagrafiche di pezzi simili a quelli che sta disegnando, eseguire check-in e check-out e tutte le altre attività che chi usa sistemi PDM conosce benissimo.

Ho scritto “quasi come” e non “come”, perché? Il perché sta ovviamente nelle lentezze dovuta alla latenza delle reti ADSL italiane, che nominalmente viaggiano attorno ai 7M ma spesso offrono prestazioni reali notevolissimamente inferiori, e quindi si capisce bene la problematica che affligge il progettista esterno se comparato all’interno che di solito lavora su reti a 1 GB o, se va male, a 100 MB. A questo si aggiunga poi che spesso le reti WAN non sono sufficientemente stabili e subiscono sconnessioni e riconessioni automatiche di cui come normali utenti di internet neanche ci accorgeremmo; purtroppo però, ogni volta che la linea si disconnette, si interrompe anche la pipe TCP che ci collega al router del nostro cliente e quindi è necessario chiudere il client PDM e rilanciarlo di nuovo, fino alla prossima disconessione.

Cosa possiamo fare per mitigare questi punti deboli delle nostre linee ADSL? Sulla stabilità possiamo fare ben poco in quanto dipende dal provider che amministra la nostra linea. Dobbiamo quindi solo sperare di essere agganciati ad una centrale dotata di apparecchiatura moderne e con sufficienti capacità in rapporto alla popolazione gestita. Sul traffico di rete invece possiamo operare in maniera più profittevole, ma come nel concreto?

Esistono diverse tecnologie, da quelle piu’ complesse ad altre molto più semplici e a buon mercato. Queste sono, in ordine di costo decrescente:

  1. Sistemi di discretizzazione atomica dei dati e uso di cache (esempio: tecnologie Riverbed)
  2. Sistemi di replicazione dei filesystem e/o dei database su ambo i lati
  3. Compressione dei dati prima dell’invio

1) I sistemi tipo Riverbed operano in questo modo: ogni pacchetto inviato dall’altro lato viene prima analizzato e salvato in una cache locale su un computer sulla nostra LAN, e lo stesso accadrà in un altro computer dal lato del nostro cliente. Al successivo invio il pacchetto viene rianalizzato e di esso si inviano dall’altro lato solo i bit realmente diversi e poi, a destinazione, il sistema accoppiato a quello di partenza si preoccuperà di ricomporre il file completo aggiungendo la differenza alla cache che lui aveva salvato al primo invio. Facciamo un esempio concreto: ho salvato una tavola da 10 MB e ci ho messo i miei bei dieci minuti, ma poi mi accorgo che dovevo aggiungere un segno di rugosità che mancava: andando a risalvare, il sistema tipo riverbed invierà solo i pochi bit relativi al simbolo aggiunto, mentre gli altri 9,99 MB verrano recuperati dalla cache locale dal lato aziendale. Bello vero? Peccato che i costi siano improponibili per un piccolo studio tecnico, visto che andiamo sicuramente sopra i 10.000 euro per un sistema completo point-to-point! Inoltre si tratta di una tecnologia ancora molto poco usata nel nostro paese, che quindi non e’ in genere vista di buon occhio dagli IT Manager che dovrebbero giustificare la spesa ai loro organi dirigenziali.

2) La replicazione dei file system e’ una tecnica già più comune. I file vengono salvati su un file-server locale, e viene tenuto traccia di questo sul server SQL del cliente che sa, momento per momento, su quale computer si trova un certo file. Nelle ore di basso carico poi, tipicamente di notte, avviene il trasferimento massivo dei file in modo da riallineare gli archivi. Se dovesse capitare durante il giorno che da parte dell’azienda venga richiesto un file non ancora trasferito, perché generato dal progettista esterno nel corso della stessa giornata, il database SQL ne ordinerà il trasferimento in anticipo sul lavoro programmato notturno, in modo completamente trasparente agli utenti sui due lati della rete WAN. Queste sono tecnologie che già si possono trovare negli studi tecnici esterni di una certa dimensione, trattandosi di un costo affrontabile. Per una licenza Multi-Site della CoCreate per esempio, si parla di alcune migliaia di euro per ogni punto della stella (quindi una licenza per l’azienda al centro della stella, e una ciascuna per ogni ufficio tecnico esterno).

3) La compressione dei dati è una tecnica a costo zero. Facciamo sempre l’esempio del PDM della Cocreate. I file che viaggiano avanti e indietro sulla rete sono di solito:

  1. Query SQL –> file di testo
  2. Thumbnails dei file –> immagini
  3. Dati di disegno 2d –> file in formato mi
  4. Dati di modello 3d –> file in formato 3d-data

Tutti questi file viaggiano in modalità nativa in quanto il sistema e’ progettato per lavorare su LAN locali. Se li andassimo a comprimere potremmo aspettarci una riduzione di volume del 90% nel caso a), del 75% nel caso d) e praticamente nulli nei casi b) e c). La compressione non è una buona idea quando lavoriamo su reti locali, in quanto il tempo risparmiato nella compressione viene poi pagato con gli interessi nelle operazioni di zip e unzip ai due lati della linea. Se viaggiamo su reti lente diventa invece una possibilità molto interessante!

MM-SSH

Da test effettuati dallo scrivente i benefici di questa tecnica sono reali e si tratta di tecnologia alla portata di tutti in quanto attuabile con il solo utilizzo di software opensource, senza necessità di acquisto di hardware dedicato o di specifiche licenze software.

Come attuare nella pratica tutto ciò? Molto semplice a dirsi: dato che i sistemi pdm in genere lavorano su connessioni TCP/IP, possiamo pensare di instradare tutto il traffico di rete su un tunnel SSH con compressione zlib attiva. Dovremo poi configurare il client PDM in modo da fargli credere di lavorare su un server locale 127.0.0.1, e sarà poi il client SSH locale a occuparsi di tutto il resto (compressione e instradamento dei dati). Un altro vantaggio di inserire il traffico dati in un tunnel è la possibilità di criptare il tutto con algoritmi più o meno complessi. Da tenere ben presente però che la criptazione provoca un aumento enorme del traffico di rete, e va quindi contro il buon funzionamento del sistema, se ci troviamo a combattere con reti WAN poco prestanti e un po’ ballerine.

MM-SSH_2Nel documento allegato quì sotto tutta la tecnicalità di come realizzare il tunnel, lato client e lato server. Buona lettura!

How-To-SSH-TUNNEL

 

I commenti sono chiusi.