Branchcache di Windows Server 2012 vs. DFS-R


8

Attenzione, domanda soggettiva a venire! Ma si spera che una buona che non sarà possibile ottenere chiusa.

SCENARIO:

Ho una filiale che al momento non ha un server locale. Accedono a tutto, incluso un controller di dominio attraverso un collegamento WAN (MPLS) a 12 Mbps. Il collegamento non è saturo, con una media di circa il 20% di utilizzo. Il circuito è molto stabile e ha un alto SLA e un eccellente tempo di attività.

Tuttavia, i trasferimenti di file di grandi dimensioni (principalmente letture, non scritture) dal file server attraverso la WAN possono essere lenti. Al momento non utilizziamo DFS.

RICERCA FATTA:

Sono a conoscenza dell'accelerazione WAN, ad esempio utilizzando hardware dedicato (Riverbed) o un software virtuale dedicato (Silver Peak). Ma il prezzo è al di fuori del nostro budget attuale e la necessità non è ancora del tutto dalla nostra prospettiva (poiché il problema è principalmente in uno scenario "pull" non necessariamente push / pull).

Sto principalmente cercando di distribuire un server Windows in questa filiale e utilizzare DFS-R o BranchCache. Guardando un confronto tra tabelle e supponendo che stiamo osservando un "server branchcache ospitato" e non semplicemente distribuito:

inserisci qui la descrizione dell'immagine

Sembrerebbe che ci siano vantaggi per entrambi, anche se entrambi sono "ospitati" su un server.

DOMANDE CHE HO REALMENTE:

  • In quali scenari brilla ciascuna di queste tecnologie e dove scegli una rispetto all'altra?
  • Guardando un server Branchcache ospitato, è possibile impostare il "pre-recupero" di determinate cartelle / file sul file server centrale in modo che siano immediatamente accessibili localmente nella filiale? Devi farlo secondo un programma (se è possibile)?
  • Guardando a DFS-R la mia preoccupazione (e apparentemente risolta con app di terze parti) è il blocco dei file e assicurarmi che il file venga aggiornato correttamente durante un'operazione di scrittura (cioè, assicurandomi che sia possibile accedere a entrambe le copie e scrivere entrambe, su quale file richiede precedenza e cosa succede ai cambiamenti?). L'ideale sembrerebbe sarebbe bloccare eventuali repliche alternative dei dati, ma è davvero un grosso problema?
  • Branchcache blocca il file centrale per la modifica?
  • Branchcache trasmette i delta solo al file centrale di ciò che è cambiato?
  • Una delle due tecnologie sarebbe sconsigliata se il server della filiale fosse utilizzato anche come controller di dominio?

Risposte:


4

BranchCache è di sola lettura e non precache. Viene utilizzato principalmente per cose come la distribuzione degli aggiornamenti, ecc. - È un CACHE.

DFS non blocca. NESSUNA tecnologia WAN resiliente fa il blocco perché il blocco non è possibile se / quando il collegamento WAN non funziona - quindi è resilienza o blocco.

Se è necessario il controllo delle versioni / blocco per funzionare correttamente, è possibile utilizzare solo un server centrale. BranchCache in questo momento PUO 'aiutare con la velocità di download per i download REPEATED. Solo.

Se non si dispone di uno dei due, ovvero è necessario eseguire molti aggiornamenti da molti punti (il che è uno scenario abbastanza insolito) la maggior parte delle volte i file non vengono bloccati in questo modo nelle aziende), è necessario pagare per maggiore larghezza di banda quando il se ne presenta la necessità. Oppure puoi usare qualche elemento DFS-R di terze parti, ma poi hai UN ALTRO problema .... che si sta assicurando che la larghezza di banda non diminuisca replicando tonnellate di cose inutilizzate perché la replica DFS è totalmente lungo le linee di condivisione dei file, non un elemento su richiesta.

Questo è davvero uno scenario "Accidenti se lo fai, accidenti se non lo fai". Soprattutto con una LAN (alta latenza, certa inaffidabilità) in atto.

BranchCache brilla ad esempio come cache di aggiornamento - non è necessario disporre di un server WSUS locale in una filiale. Non esiste alcun blocco in quanto si tratta di un puro meccanismo di memorizzazione nella cache: non è possibile modificare un file BranchCache. Detto questo, poiché non esiste alcun blocco, una scrittura bloccherà il file CENTRAL e la versione aggiornata si propagherà, quindi potrebbe effettivamente funzionare per te;)

DFS è ottimo per contenuti di sola lettura (immagini di installazione, immagini di software per l'installazione, documenti politici che vengono modificati centralmente ecc.). Abbastanza divertente LA MAGGIOR PARTE dei file che ricadono in questa categoria - le cose che modifichiamo qui sono principalmente in traslazioni centrali con altre tecnologie di sincronizzazione (gestione dei documenti sharepoint). DFS è un'ottima soluzione tecnica per le esigenze di replica tecnica.

http://pertorben.wordpress.com/2012/05/29/dfs-r-or-branchcache/

ha una spiegazione molto approfondita.

BranchCache potrebbe funzionare ... non interromperà la latenza di download singolo ma gestirà letture ripetute. Inoltre consente il blocco.


Modifica: su forther chechking sembra che ora sia possibile precaricare. Per favore riferisci a

http://technet.microsoft.com/en-us/library/jj127252.aspx


Grazie TomTom. Nell'articolo dice "DFS-R avrà una replica completa di tutti i file e dopo la sincronizzazione iniziale quando si configura DFS-R solo i blocchi di file modificati attraverseranno nuovamente la WAN" - una delle mie domande era come branchcache salva eventuali aggiornamenti. Deve ritrasmettere il file completo al server centrale per scrivere o solo le modifiche?
TheCleaner,

technet.microsoft.com/en-us/library/jj127252.aspx - 2012: piccole modifiche a file di grandi dimensioni producono risparmi sulla larghezza di banda (+ spiegazione).
TomTom,

Grazie, non avevo ancora guardato quell'articolo. Un grosso problema però (almeno per noi), avevo dimenticato che BranchCache richiede che il client sia su Enterprise / Ultimate ... nessun Pro consentito. Ciò richiede di esaminare DFS-R o qualche altra opzione di terze parti.
TheCleaner,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.