BranchCache für VPN-Dateifreigaben: wann es hilft, wann nicht

Jemand im Team sagt, die Dateifreigabe über das VPN sei langsam, und der erste Vorschlag ist immer ein Cache. Bevor BranchCache in das Fernzugriffsdesign aufgenommen wird, zerlegen Sie die Beschwerde in eine von drei Formen: wiederholte Downloads unveränderter Inhalte, Uploads oder metadatenlastiges Durchblättern von Ordnern mit Tausenden Einträgen. BranchCache adressiert die erste Form bei unterstützten Inhalten und leistet für die anderen beiden nichts Nützliches. Das ist keine Einschränkung, die man umgehen müsste; es ist der Vergleich, den Sie anstellen sollten, bevor Sie eine Woche in die Bereitstellung stecken.

Dieselbe Freigabe, drei verschiedene Beschwerden

Eine Zweigstelle, in der acht Personen dasselbe unveränderte Schulungsvideo öffnen, ist der Fall, für den das Feature entworfen wurde. Der erste Abruf überquert das WAN, der Inhalt wird in der Nähe der Leser zwischengespeichert, und spätere Abrufe derselben unveränderten Datei werden lokal bedient. Der Nutzen ist real und schmal: gleicher Inhalt, unverändert, mehrere Leser.

Ein Laptop, der eine neue Aufnahme über einen Heimanschluss hochlädt, ist der entgegengesetzte Fall. Es gibt keine zuvor zwischengespeicherte Kopie einer Datei, die noch nicht existiert, also folgt der Upload demselben eingeschränkten Pfad wie immer. Ein Download-Cache beseitigt keinen Upload, und keine Platzierungswahl ändert daran etwas.

Die dritte Form ist die, die Menschen enttäuscht, weil sie wie ein Download-Problem aussieht. Ein Verzeichnis mit Zehntausenden Dateien zu öffnen, es zu sortieren und Metadaten zu lesen, ist ein Strom kleiner Operationen, kein wiederholter Transfer eines großen Objekts. Die Dateikörper zwischenzuspeichern hilft bei der Aufzählung nicht.

Verteilter Cache: ein VPN-Pool ist kein Zweigstellen-LAN

Im verteilten Modus teilen Clientcomputer zwischengespeicherte Inhalte miteinander, und Microsoft dokumentiert diesen Modus als innerhalb eines einzelnen Subnetzes arbeitend. Ein VPN-Client-Pool ist in diesem Sinne kein Subnetz, selbst wenn alle Adressen zusammenhängend aussehen: Peer-Erkennung, Erreichbarkeit von Client zu Client und die Berechtigung zum Austausch von Cache-Daten sind getrennte Fragen, und das übliche Fernzugriffsdesign beantwortet alle drei mit „nein“.

Sie können den Pool wie ein Zweigstellen-LAN verhalten lassen, indem Sie Client-zu-Client-Verkehr erlauben, aber das ist eine Sicherheitsentscheidung, keine Caching-Entscheidung. Die meisten Fernzugriffsdesigns isolieren Clients gerade deshalb voneinander, damit ein kompromittierter Laptop keinen anderen erreicht, und diese Isolation gegen einen Cache-Treffer zu tauschen ist ein schlechter Handel, es sei denn, die Peers sind bereits vertrauenswürdige Gleichgestellte.

Für einen einzelnen mobilen Benutzer gibt es im verteilten Modus niemanden zum Teilen. Der Cache kann immer noch die wiederholten Lesezugriffe dieses einen Clients bedienen, aber das ist ein clientseitiger Cache-Nutzen, kein Nutzen der Zweigstellenplatzierung, und das sollte man sagen, bevor jemand erwartet, dass das Büro schneller wird.

Gehosteter Cache: die Platzierung entscheidet, ob er hilft

Ein gehosteter Cache legt den gemeinsamen Cache auf einen Server, was der einzige Modus ist, der über Subnetze hinweg sinnvoll ist, und der einzige, der funktioniert, wenn Clients nicht miteinander sprechen können. Die unmittelbare Frage ist, wo dieser Server steht. Ein gehosteter Cache, der über dieselbe eingeschränkte Strecke wie das Origin erreicht wird, hat die Bytes verschoben, nicht das Problem.

Platzieren Sie ihn nahe bei den Lesern, geben Sie ihm einen Eigentümer und dimensionieren Sie seine Festplatte für das Arbeitsset statt für die gesamte Freigabe. Die BranchCache-Übersicht von Microsoft beschreibt beide Modi und das Clientverhalten, einschließlich des Teils, den Leute vergessen: Clients kontaktieren das Origin weiterhin für die Autorisierung und die Inhaltsinformationen, bevor sie zwischengespeicherte Daten verwenden.

Die Bereitstellung besteht aus drei gemeinsam geplanten Rollen, nicht aus einem Häkchen. Der Origin-Server veröffentlicht Hashes für den Inhalt, der gehostete Cache wird aktiviert und ist auffindbar, und die Clients werden für seine Nutzung konfiguriert. Auf der Serverseite ist das in PowerShell erkennbar:

Enable-BCHostedServer -RegisterSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode, HostedCacheServerList

Auf dem Client verweisen Sie entweder auf benannte Server oder lassen ihn sie über den Dienstverbindungspunkt ermitteln; bestätigen Sie dann den tatsächlich gewählten Modus, statt anzunehmen, die Richtlinie sei angewendet worden:

Enable-BCHostedClient -ServerNames cache1.corp.example -UseSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode

Was das Origin weiterhin erreicht

Caching hebt die Autorisierung nicht auf. Ein Client ohne Leseberechtigung für eine Datei erhält keinen Zugriff, weil jemand anderes sie zwischengespeichert hat, und das Origin beantwortet weiterhin die Autorisierungsfrage und liefert die Inhaltsinformationen, die den Cache-Lookup ermöglichen. Ist das Origin nicht erreichbar, wird die zwischengespeicherte Kopie allein keine Offline-Freigabe.

Inhaltsänderungen durchbrechen die Annahme ebenfalls still. Eine Datei, die erneut gespeichert, neu kodiert oder von einem Backup-Produkt angefasst wird, passt möglicherweise nicht mehr zum zwischengespeicherten Hash, und der nächste Lesezugriff geht zurück zum Origin. Das ist korrektes Verhalten, und deshalb liefert ein Cache, dessen Arbeitsset stündlich wechselt, wenig.

Die Verdrängung ist die dritte Grenze. Der Cache ist endlich, also schiebt ein großes Arbeitsset ältere Inhalte hinaus, und der Nutzen hängt davon ab, dass erneute Lesezugriffe vor der Verdrängung stattfinden und nicht danach. Den Cache für die gesamte Freigabe zu dimensionieren ist der übliche Weg, von einer technisch korrekten Bereitstellung enttäuscht zu werden.

Akzeptieren Sie es mit zwei Abrufen und einem Upload

Testen Sie die richtigen drei Abläufe und schreiben Sie auf, was jeder zeigt. Erster Abruf einer repräsentativen Datei von einem Client, gemessen an der Origin-Strecke sowie an der Uhr des Benutzers. Zweiter Abruf derselben unveränderten Datei von einem zweiten Client in derselben Platzierungsgruppe. Ein Upload einer neuen Datei, der keine Verbesserung zeigen sollte und bestätigt, dass dem Cache nichts zugeschrieben wird, was er nie getan hat.

Wenn der zweite Abruf die Origin-Strecke noch für den Großteil der Bytes überquert, wird der Cache nicht genutzt, und die Ursache ist meist ein Client im falschen Modus, eine fehlende Hash-Veröffentlichung am Origin oder ein gehosteter Cache auf der falschen Seite der eingeschränkten Strecke. Das sind drei verschiedene Korrekturen, und nur eine davon betrifft die Netzwerkplatzierung.

Formulieren Sie die Schlussfolgerung dann in derselben Form wie die ursprüngliche Beschwerde: wiederholte Downloads unveränderter Inhalte von diesem Origin zu diesen Lesern werden von diesem Cache bedient. Alles andere an der Freigabe bleibt unberührt, einschließlich Uploads, Ordneraufzählung und der Offline-Geschichte, die weiterhin eine eigene Antwort braucht.