none
Windows 2008 R2 - Network Drive Volume su NAS RRS feed

  • Domanda

  • Buongiorno a tutti,

    su un server virtuale Windows 2008 R2 è presente un'applicazione che lavora file (immagini, doc, etc..) su un volume esterno mappato in rete gestito da uno storage nas; quindi, scrive su \\mionas\applicationfolder.

    Ora, nel tempo tale volume ha raggiunto quota 4TB; al momento non rileviamo rallentamenti o altro degrado nelle prestazioni, ma mi domandavo se;

    1) C'è un limite nel size entro il quale Windows 2008 R2 può gestire network volume così grandi o magari nel numero di file e cartelle;

    2) Se è il caso di "agganciare" una LUN, anche in iscsi, per gestire meglio i dati;

    3) Se è meglio "splittare" i dati magari spostando su altro volume lo "storico" delle attività;

    Grazie per il supporto


    • Modificato SysAdmin_IT sabato 22 settembre 2018 07:30
    sabato 22 settembre 2018 07:29

Risposte

  • >> Se è il caso di "agganciare" una LUN, anche in iscsi, per gestire meglio i dati;

    Secondo me decisamente Si, meglio su un'interfaccia di rete dedicata. Dipende anche da quanto la NAS sia "brava" a gestire iscsi.

    • Contrassegnato come risposta SysAdmin_IT martedì 25 settembre 2018 12:50
    sabato 22 settembre 2018 08:19
  • Diffcile consigliarti non conoscendo le tue esigenze attuali e prospettive di crescita, devi essere tu a decidere, cerco di instradarti su i vari pro e contro.

    1. Ci troviamo in un caso dove alcune limitazioni possono essere introdotte anche dal file system della NAS o dall'esposizione dello stesso a w2008, es. se la nas è un linux potresti avere zfs e samba ultima versione (in questo caso 4TB sono nulla, se il fs non è di ultima generazione  e samba risulta  datata, son problemi). Se guardi i limiti di ntfs ti puoi fare un idea.
      Avere i files su di un fs gestito dalla nas ti offre dei vantaggi, come sistemi di backup, sincronizzazione, snapshot, mirroring o copia granulare su più dispositivi esterni (ottimi per evitare le conseguenze dei cryptolocker, se almeno uno sta in una cassaforte)
    2. Usare iSCSI ha altri vantaggi, "dovrebbe" essere più performante, gestione nativa da parte di windows, gestione delle versioni precedenti dei file nelle share (comodissima!), gestione interna da windows ...
    3. Se riesci a spostre una parte dei dati meno acceduti/importanti in uno storico,  non scrivibile ti risparmieresti tanti grattacapi.
      Metti il bk dello storico  in due dischi, in due cassaforti, in luoghi diversi, quindi lo togli dalle procedure di backup, così diventano più veloci e ti occupano meno spazio. Questo le lo "storico" sia di dimensioni apprezzabli rispetto il corrente...

    L'opzione 3. a me piace particolarmente e rimane valida sia con iSCSI che con i dati condivisi da NAS. Inutile andare in giro con un treno pieno di cose inutili e ogni volta che ci vuole spazio aggiungere un vagone, prima o poi i limiti si raggiungono (treno troppo pesante per la motrice, troppo lungo per gli interscambi e  il ricovero, smorzatori e respingenti non più adeguati etc. etc.)

    Ciao Gastone


    Gastone Canali >http://www.armadillo.it


    Se alcuni post rispondono al tuo quesito(non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili. GRAZIE! Ricorda di dare un occhio ai link Click Here andHere





    sabato 22 settembre 2018 16:59
    Moderatore

Tutte le risposte

  • >> Se è il caso di "agganciare" una LUN, anche in iscsi, per gestire meglio i dati;

    Secondo me decisamente Si, meglio su un'interfaccia di rete dedicata. Dipende anche da quanto la NAS sia "brava" a gestire iscsi.

    • Contrassegnato come risposta SysAdmin_IT martedì 25 settembre 2018 12:50
    sabato 22 settembre 2018 08:19
  • Diffcile consigliarti non conoscendo le tue esigenze attuali e prospettive di crescita, devi essere tu a decidere, cerco di instradarti su i vari pro e contro.

    1. Ci troviamo in un caso dove alcune limitazioni possono essere introdotte anche dal file system della NAS o dall'esposizione dello stesso a w2008, es. se la nas è un linux potresti avere zfs e samba ultima versione (in questo caso 4TB sono nulla, se il fs non è di ultima generazione  e samba risulta  datata, son problemi). Se guardi i limiti di ntfs ti puoi fare un idea.
      Avere i files su di un fs gestito dalla nas ti offre dei vantaggi, come sistemi di backup, sincronizzazione, snapshot, mirroring o copia granulare su più dispositivi esterni (ottimi per evitare le conseguenze dei cryptolocker, se almeno uno sta in una cassaforte)
    2. Usare iSCSI ha altri vantaggi, "dovrebbe" essere più performante, gestione nativa da parte di windows, gestione delle versioni precedenti dei file nelle share (comodissima!), gestione interna da windows ...
    3. Se riesci a spostre una parte dei dati meno acceduti/importanti in uno storico,  non scrivibile ti risparmieresti tanti grattacapi.
      Metti il bk dello storico  in due dischi, in due cassaforti, in luoghi diversi, quindi lo togli dalle procedure di backup, così diventano più veloci e ti occupano meno spazio. Questo le lo "storico" sia di dimensioni apprezzabli rispetto il corrente...

    L'opzione 3. a me piace particolarmente e rimane valida sia con iSCSI che con i dati condivisi da NAS. Inutile andare in giro con un treno pieno di cose inutili e ogni volta che ci vuole spazio aggiungere un vagone, prima o poi i limiti si raggiungono (treno troppo pesante per la motrice, troppo lungo per gli interscambi e  il ricovero, smorzatori e respingenti non più adeguati etc. etc.)

    Ciao Gastone


    Gastone Canali >http://www.armadillo.it


    Se alcuni post rispondono al tuo quesito(non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili. GRAZIE! Ricorda di dare un occhio ai link Click Here andHere





    sabato 22 settembre 2018 16:59
    Moderatore
  • Buonasera e grazie per le risposte.

    Precederemo dedicando una scheda LAN a iSCSI per l'accesso al volume e sposteremo lo "storico" su altro filesystem; intanto così vediamo come risponde l'applicazione, magari già con queste modifiche guadagna in performance.

    Ci aggiorniamo, ancora grazie per i preziosi consigli.

    martedì 25 settembre 2018 12:50