none
Problema virtualizzazione e terminal server RRS feed

  • Domanda

  • Ciao a tutti,

    un cliente con 2 sedi distinte mi ha chiesto di implementare la loro situazione informatica (fino ad oggi gestita da terzi), qui di seguito rapidamente l'obbiettivo da raggiungere:

    i client delle 2 sedi attualmente utilizzano un software Solidworks per la progettazione in 3d, ogni client salva i file sul proprio server aziendale e la sera i 2 server si sincronizzano, questa procedura non va bene in quanto per ovvi motivi si perde sempre qualcosa per strada e c'è sempre il rischio che 2 utenti nelle 2 sedi utilizzino lo stesso file lo aggionino e la mattina dopo la sincronizzazione notturna non trovino più le modifiche effettuate ma quelle dell'altro.(follia pura)

    Io avevo pensato di unificare i server nella sede centrale, e dedicarne uno per virtualizzare i client della sede remota facendoli così lavorare in tempo reale sulla stessa rete e su un unico file di archiviazione (evitando doppioni o smarrimento di file) o al limite in terminal server tanto il concetto non cambia.

    Bene l'assistenza solidwork dice che gli unici OS supportati sono quelli client Windows 8 X64 compreso ma non OS Server, quindi escludiamo TS, e che per la virtualizzazione il software non è certificato, traduzione potrebbe funzionare ma se non funziona non ti diamo il supporto.

    Cosa posso fare? avrebbe senso proporre 10 nuovi client (tanti sono gli utenti della sede remota che si collegano) da installare nella sede principale e farli collegare ognuno su un client vero fisico e farli lavorare così?? a prescindere dagli eventuali costi potrebbe funzionare?

    Con un unico IP Pubblico e cambiando la porta di connessione per ciascun client ci potrebbero essere problemi?

    Attendo vostre sapienti proposte alternative

    Grazie mille

     

    mercoledì 6 febbraio 2013 15:42

Risposte

  • ora è tutto più chiaro e il problema si pone diversamente.

    a questo punto io opterei per una buona banda e una robusta vpn tra le due sedi con il server archivio dati messo solo nella sede principale.


    Edoardo Benussi
    Microsoft MVP
    edo[at]mvps[dot]org

    giovedì 7 febbraio 2013 10:07
    Moderatore

Tutte le risposte

  • Domanda: Ma la sincronizzazione in che termini avveniva? Premesso che non conosco il programma quando dici che ogni utente lavora con il file sul proprio server lasci intendere che un utente dell'altra sede non lo utilizzi.

    Domanda: I tuoi client necessitano di grafica o di calcolo?

    Saluti

    Nino

    mercoledì 6 febbraio 2013 16:38
    Moderatore
  • Domanda: Ma la sincronizzazione in che termini avveniva?

    i 2 server controllavano il file piu aggiornato (quindi l'ora dell'utlima modifica) e lo sincronizzavano nel più vecchio

    Lasciamo stare questa che è una realtà da cui si vogliono togliere al più presto e per cui ci hanno chiamato

    Premesso che non conosco il programma quando dici che ogni utente lavora con il file sul proprio server lasci intendere che un utente dell'altra sede non lo utilizzi.

    Le 2 sedi lavorano ognuna sul proprio server e quindi sui propri file che però in fondo condividono, ovveroes user 1 sede 1 e user 2 sede 2 lavorano sullo stesso progetto e sugli stessi file, archiviati su 2 server separati che la sera sincronizzano, ma sincronizzando il più delle volte sei user1 e 2 non comunicano precedentemente telefonicamente cancellano l'uno il lavoro dell'altro, loro vogliono (con la mia benedizione un archivio unico) che non sarebbe proprio nulla di trascendentale se non avessi queste piccole limitazioni sul software utilizzato.

    Domanda: I tuoi client necessitano di grafica o di calcolo?

    i client che utilizzano il software devono essere ben carrozzati di cpu memoria e scheda grafica

    mercoledì 6 febbraio 2013 16:44
  • Ciao, con SolidWorks (come con altri software di progettazione 3D) non è consigliato l'utilizzo di soluzioni di virtualizzazione client o di terminal services. E' vero che si potrebbe tentare di implementare RemoteFX su RDP, ma per esperienza personale ti consiglio di abbandonare questa strada e credo che non risolveresti comunque il problema di fondo.

    La precedente implementazione con sincronizzazione a mio parere era solo il tentativo di aggirare la reale necessità di un software di team work (la maggior parte sono a pagamento) che, integrandosi direttamente con i software interessati, permette la collaborazione simultanea di più utenti sullo stesso file e la gestione dei relativi conflitti. Una semplice condivisione centralizzata a mio parere potrebbe non essere sufficiente per lavorare in quel modo.





    mercoledì 6 febbraio 2013 17:25
    Moderatore
  • Ciao Fabrizo,

    quindi all'atto pratico cosa mi consiglieresti di fare? di che software parli?

    giovedì 7 febbraio 2013 08:23
  • da come descrivi la situazione non credo esista nulla di magico perchè non troverai mai qualcosa che possa fare il merge delle modifiche come, ad esempio, una serie di transazioni di cui viene fatto il commit simultaneo su un database. nel tuo scenario la sola sincronizzazione possibile è quella che l'ultimo a fare le modifiche vince.

    un qualcosa che tiene conto delle modifche in tempo reale è Visual Studio di Microsoft, il tool di sviluppo chepuò essere multiutenza sul medesimo sorgente perchè ogni utente che sta utilizzando e modificando lo stesso sorgente viene notificato delle modifche apportate da altri e invitato a ricaricare il progetto per vedere quali sono le modifche apportate.

    come vedi in quest'ultimo esempio, il tutto viene però demandato ad un software di altissimo livello e pensato per lavorare in team, cosa che certamente questo Solidworks non fa.

    ciao


    Edoardo Benussi
    Microsoft MVP
    edo[at]mvps[dot]org

    giovedì 7 febbraio 2013 08:26
    Moderatore
  • grazie edoardo per la risposta esaustiva e sconfortante per me...ma la soluzione arcaica che ho menzionato nel mio primo post non è percorribile secondo te?

    avrebbe senso proporre 10 nuovi client (tanti sono gli utenti della sede remota che si collegano) da installare nella sede principale e farli collegare ognuno al proprio client vero fisico e farli lavorare così?? a prescindere dagli eventuali costi potrebbe funzionare?

    Con un unico IP Pubblico e cambiando la porta di connessione per ciascun client ci potrebbero essere problemi?

    giovedì 7 febbraio 2013 08:35
  • mi spiace deluderti ma non è questione di mettere hardware migliore o una connessione con banda migliore. nel tuo caso è proprio l'architettura del software che non si presta a un risultato soddisfacente. in pratica, chi sviluppa Solidworks, dovrebbe fare il reenginering del proprio software prevedendo la multiutenza e la sincronizzazione dei files in tempo reale.

    mi spiace.


    Edoardo Benussi
    Microsoft MVP
    edo[at]mvps[dot]org

    giovedì 7 febbraio 2013 08:42
    Moderatore
  • scusa se insisto edoardo ma ho bisogno di capire...se ho 20 client su la sede principale che lavora con questo maledetto software in modalita stand alone elaborando file e poi salvandoli sul server locale e predispongo 3 macchine (ho chiesto stamani quanti precisamente dalla sede remota useranno solidworks) sempre nella sede principale a cui fa collegare via VPN gli uenti della sede remota che lo utilizzano, perchè potrei avere problemi?

    "da come descrivi la situazione non credo esista nulla di magico perchè non troverai mai qualcosa che possa fare il merge delle modifiche come, ad esempio, una serie di transazioni di cui viene fatto il commit simultaneo su un database. nel tuo scenario la sola sincronizzazione possibile è quella che l'ultimo a fare le modifiche vince"

    Forse non mi sono spiegato bene io NON voglio e devo percorrere la via del merge o della sincronizzazione come attualmente fanno, ma devo centralizzare il loro lavoro con l'archiviazione su unico server mettendo quindi in condizione di chi lavora dalla sede remota di poter lavorare su questo software possibilmente su una macchina della sede locale per non far eccessivo traffico di rete sulla eventuale vpn, le soluzioni di base TS e Virtual non sono percorribili per limitazioni del software stesso, quindi mi rimane solo l'idea di farli collegare a macchine fisiche ad hoc

    • Modificato IT AM giovedì 7 febbraio 2013 09:09
    giovedì 7 febbraio 2013 08:59
  • facciamo una pausa.

    mentre io mi prendo un caffè tu potresti raccontarmi per cortesia

    non come e quante mecchine nuove o software nuovo vuoi vendere al tuo cliente

    ma quale sia l'esigenza lavorativa effettiva di questo cliente ?

    se il cliente lavora con questo software e due utenti aprono contemporaneamente lo stesso file modificandolo, l'ultimo che chiuderà il file salverà le sue modifche e sovrascrivendo quelle dell'altro utente. qualsiasi arzigogolo tecnologico tu metta, softaware, hardware, servers, sistemi ridondati, fiber channel, razzi nucleari, non servirà a niente. l'ultimo che salva continuerà a sovrascrivere le modifche dell'altro utente.


    Edoardo Benussi
    Microsoft MVP
    edo[at]mvps[dot]org

    giovedì 7 febbraio 2013 09:35
    Moderatore
  • ok ho capito che non ci siamo capiti...rimuovi completamente la parte riguardante l'utilizzo in contemporanea dello stesso file, mi sono espresso male, non esiste questa esigenza, devono lavorare semplicemente come tutti i comuni mortali 1 server un archivio dati di solidworks e utenti che li utilizzano 1 per volta. (il problema sinora era che avendo 2 server con 2 archivi dati magari 2 utenti modificavano lo stesso file presente nei 2 server distinti e la sera quando questi sincronizzavano succedeva quello che abbiamo già detto. Lavorando invece come se fossero tutti in un'unica sede ciò non accadrebbe perchè se il secondo utente prova ad aprire un file che è in uso gli verrebbe notificatoe negato l'accesso...ed è proprio ciò che vogliamo.

    Il problema vero quindi non era quello di far lavorare simultaneamente 2 utenti sullo stesso file ma di come farli accedere avendo un impatto minore possibile sulle linee utilizzate e le performance massime sull'aspetto utilizzo del software, tenendo conto che non posso usare Terminal e che la virtualizzazione dei client può funzionare ma in caso di problemi non danno il supporto di assistenza perchè non certificato dal software.

    Spero di essermi spiegato 

    giovedì 7 febbraio 2013 09:46
  • Ho letto le tue risposte (tutte) e credo che tu sei orientato su una sorta di PC-Farm.

    Vano analizzati alcuni aspetti:

    • Velocità connessione tra le sedi
    • Ridondanza connessione su tutte e due le sedi

    In particolare il secondo aspetto dipende da quanto è critica questa attività e quanto tempo di down può permettersi il tuo cliente. Perché passi da una situazione con dati distribuiti tra due sedi, che al massimo possono non essere sincronizzati per un paio di giorni ma localmente on-line.

    Non ho capito se il tuo cliente ha l'infrastruttura per attivare una VDI o se deve crearla. I problemi evidenziati da Fabrizio Giammarini potrebbero essere verificati se hai già disponibile una infrastruttura o se comunque non ti costa molto effettuare una implementazione di test.

    Per quanto riguarda la gestione accessi, ovviamente implementando una VPN ogni singolo utente della sede 2 avrebbe disponibilità di accesso diretto al desktop remoto senza problemi di porte.

    IBM dovrebbe avere a listino una lama Blade specifica per virtualizzare client con esigenze grafiche come appunto workstation grafiche. Ma percorrendo questa strada significa, a mio avviso, avere un impatto economico non indifferente.

    Potresti postare le attuali caratteristiche dell'infrastruttura, giusto per capire di cosa stiamo parlando. Comunque la prova finale è quella di mettere su un PC (per iniziare) ed eseguire dei test.

    Saluti

    Nino 

    giovedì 7 febbraio 2013 09:53
    Moderatore
  • Ciao Nino,

    • "Velocità connessione tra le sedi"

          SI

    • "Ridondanza connessione su tutte e due le sedi"

          SI

    "In particolare il secondo aspetto dipende da quanto è critica questa attività"

    Ho già previsto un FW che gestisca le 2 linee di 2 gestori diversi con regole di trunk e fail over

    "Non ho capito se il tuo cliente ha l'infrastruttura per attivare una VDI o se deve crearla"

    Dovrebbe crearla ma non virtualizzo i client su un server Hyper-V se poi non mi danno l'assistenza in caso di problemi i tecnici del software

    Ora comunque ho messo su un server Fujitsu che avevo a disposizione e sto provando a montare la demo di solidworks 2013 e vediamo che succede.

    giovedì 7 febbraio 2013 10:03
  • ora è tutto più chiaro e il problema si pone diversamente.

    a questo punto io opterei per una buona banda e una robusta vpn tra le due sedi con il server archivio dati messo solo nella sede principale.


    Edoardo Benussi
    Microsoft MVP
    edo[at]mvps[dot]org

    giovedì 7 febbraio 2013 10:07
    Moderatore
  • ottimo grazie a tutti per le risposte e la pazienza, ultima domanda, proprio riguardo all'occupazione della banda tra le 2 sedi se io tiro su una vpn e i client della sede remota lavorano direttamente sui propri client richiamando i file di progettazione 3d dal server della sede centrale avrò sicuramente un traffico superiore a quello che avrò se invece farò collegare gli utenti remoti ai client dedicati nella sede centrale e li farò lavorare direttamente da li? giusto?
    giovedì 7 febbraio 2013 10:15
  • se gli utenti utilizzano i client nella sede remota e una connessione vpn: prendono il file dal server occupando la banda, quando il file arriva sul client e lo lavorano la connessione non viene utilizzata e viene riutilizzata solo al termine quando salvano nuovamente il file sul server

    se gli utenti lavorano in rdp su un client nella sede centrale tengono la banda occupata per tutto il tempo della sessione rdp.


    Edoardo Benussi
    Microsoft MVP
    edo[at]mvps[dot]org

    giovedì 7 febbraio 2013 10:29
    Moderatore
  • Da una tua precedente risposta mi era sembrato di capire che non ti supportano se il programma è installato in "Terminal Server" (scusa il termine...) non su un PC virtualizzato.

    Per quanto riguarda l'occupazione di banda ovviamente se lavori sui client remoti (fisici o virtuali) non hai transito di dati. Penso sia poco plausibile gestire i dati direttamente dai client in remoto.

    Saluti

    Nino   

    giovedì 7 febbraio 2013 10:32
    Moderatore
  • Ciao Fabrizo,

    quindi all'atto pratico cosa mi consiglieresti di fare? di che software parli?

    Come dicevo se l'idea è quella di far lavorare più utenti con gli stessi file di Solidworks dovresti implementare un software di team works compatibile (ad esempio con la versione 2007 mi sembra di ricordare che c'era un software chiamato InnoCielo TeamWork) altrimenti l'unico modo è ricorrere alle sincronizzazioni come già veniva fatto, ma come hai visto è comunque rischioso.

    In qualsiasi caso vorrei nuovamente sottolineare che con software del genere ti sconsiglio di implementare virtualizzazioni o soluzioni con RDS, se non strettamente necessario: anche avendo hardware di alto livello RemoteFX ha comunque dei limiti e potresti ritrovarti con una soluzione di costo elevato non adatta alle esigenze del cliente. Non ho mai verificato le prestazioni con SolidWorks ma sul forum ufficiale viene sconsigliato e non sono sicuro che sia comunque una soluzione supportata.

    giovedì 7 febbraio 2013 10:36
    Moderatore
  • ok perfetto grazie mille
    giovedì 7 febbraio 2013 10:38
  • Purtroppo sono arrivato tardi e mi dispiace perchè ho un cliente che ha una struttura identica e lavora con Solidworks e SolidEdge nello stesso modo.

    Confermo quindi la soluzione di Edoardo è quella che viene adottata. VPN con ampia banda e file server nella sede "centrale", file aperti in rete. Siccome i file generati sono davvero molto corposi il mio cliente ha una 100Mbit in sede (Milano) ed una 20Mbit in sede staccata. Così funzia tutto egregiamente. Tutto il discorso di backup e AD è poi di contorno.

    Spero di essere stato utile anche se in ritardo.

    Ciao a tutti.

    A.

    giovedì 7 febbraio 2013 13:21
    Moderatore
  • Sì, abbandonando l'idea iniziale della collaborazione contemporanea degli utenti sugli stessi file, è sicuramente la soluzione più economica e veloce.
    giovedì 7 febbraio 2013 13:28
    Moderatore
  • Grazie mille prenderò questa via, io avevo pensato fastweb fibra 100 con banda minima garantita SHDSL 2/512 o 4/1 (dimmi se sbaglio o se tu hai optato per altre opzioni), il problema mi nasce per la sede remota che è in una zona dove le coperture dei servizi non sono il massimo, comunque anche sarà possibile una 20 mega con banda minima garantita o una 20 mega standard?
    venerdì 8 febbraio 2013 09:21