DFSR oder BranchCache?

[jostrn 13]

Hallo,

 

in einem Netzwerk wurden alle Server in ein RZ verlagert. Der Hauptstandort mit bis zu 20 Nutzern, an dem früher die Server standen, hat eine dedizierte 10er SDSL-Leitung ins RZ. Die Nutzer klagen wiederholt über lange Öffnungszeiten bei Dateien, teilweise crasht eine Office-Anwendung beim Speichern - insbesondere Excel. Daneben gibt es in der Fibu-Software teils recht lange Wartezeiten beim Ausfüllen der Buchungsmasken.

 

Die pings zwischen Standort und RZ auf der SDSL-Leitung liegen relativ konstant zw. 10 und 15ms. Die 10er Leitung wird in den nächsten Wochen geupgradet, schnellerer Storage für den Dateispeicher ist angefragt. Da aber die alten Server noch am Standort sind plane ich, einen davon für die BH-Software zu reaktivieren (erledigt ca. 50% der Beschwerden) und diesen auch für die Serverlaufwerke einzuspannen. Würdet ihr in dem Szenario BranchCache oder DFSR bevorzugen?

 

Es gibt eine Hand voll Mitarbeiter an anderen Standorten, die weiterhin direkt auf den RZ-Servern arbeiten würden. Es ist unwahrscheinlich, dass eine Datei gleichzeitig bearbeitet würde, aber in diesem Fall hätte DFSR ein Problem, oder?

 

BranchCache würde nur beim Öffnen der Dateien, nicht jedoch beim Speichern, Vorteile bringen?

 

 

Vielen Dank und viele Grüße

Josef

[testperson 1.729]

Hi,

 

wäre es hier nicht sinnvoller auf Remote Desktop Session Hosts (Den guten alten Terminalserver) im RZ zu setzen?

 

Gruß

Jan

[Nobbyaushb 1.487]

Ergänzend zu Jan: BrancheCache willst du nicht wirklich einsetzten, glaube mir.

 

10 Mbit bei 20 Usern? Zuwenig.

 

Kalkulatorisch ist man aktuell bei 1,5 (eher 2,0) Mbit / Symmetrisch per User.

 

Bei 20 Leuten bin ich also so schon mal bei 30Mbit, minimal bei einer MPLS Leitung.

 

Schneller Server oder Storage hilft dir im RZ nur, wenn dort der SQL von der BuHa steht.

Btw: welche Software ist das?

 

Ich würde auch lieber auf RDS Host gehen.

 

;)

[ChrisRa 42]

Mit welchen Dateitypen geht die Fibusoftware um? Ich sehe beide Technologien in deinem Szenario nicht.

 

Alternative wäre die Fibusoftware an dem Standort laufen zu lassen und die Daten mittels DFS-R zusätlich im RZ abzulegen (aus Gründen der Datensicherung oder was auch immer).

 

Bei Branchecache hast du nur Vorteile, wenn es sich um Dateien handelt, die ständig von vielen Benutzern aufgerufen werden und selten gespeichert werden.

 

Grüße

bearbeitet 23. Juli 2015 von ChrisRa

[Necron 71]

Hi,

 

wäre es hier nicht sinnvoller auf Remote Desktop Session Hosts (Den guten alten Terminalserver) im RZ zu setzen?

 

Gruß

Jan

Hi,

 

das wollte ich gerade auch vorschlagen. Schreit ja fast förmlich danach. :D

[Dominik Weber 19]

Gerade bei Cloud und RZ Installation würde ich das ganze nur noch mir RDS/Citrix aufbauen, der Rest ist nicht sinnvoll und die Performance lässt zu wünschen übrig

[jostrn 13]

Alternative wäre die Fibusoftware an dem Standort laufen zu lassen und die Daten mittels DFS-R zusätlich im RZ abzulegen (aus Gründen der Datensicherung oder was auch immer).

 

Genau so mein Gedanke, nur fehlt mir einschlägige Erfahrung sowohl mit DFS-R als auch mit BranchCache.

 

 

 

RDS und Citrix waren ursprünglich in der Diskussion. Die maßgeblichen Anwender wollen vor allem mobil arbeiten, nicht selten auch ohne Datenverbindung. Außerdem wirkte das Lieblingszahlentool (eine JNLP-Anwendung von Lucanet, mit Excel-Addin) der Entscheider via RDS weit weniger geschmeidig als bei lokaler Ausführung.

 

Die FiBu-Software ist Lexware FinancialOffice Pro, die Clientanwendung läuft im RZ und kommt per RDP zu den Anwendern. Für RDP wurde 1 MBit/s reserviert, die anderen haben also max. 9 MBit/s Bandbreite ins RZ. Lexware-Client- und Server-VM laufen im selben Cluster und wurden nach den Beschwerden aufgerüstet, obwohl sie kaum Last hatten. Trotzdem kommen aus der BH praktisch jede Woche Beschwerden (hohe Antwortzeit beim Dialogbuchen, langsamer Aufbau von Berichten, ...).

Da die Beschwerden auf der alten Hardware on premise nie auftraten, Hardware und Lizenzen vorhanden und die Umstellung höchstens einen halben Tag dauern würde bevorzuge ich diesen Weg gegenüber weiterer Optimierung im RZ. In den letzten Monaten wurde für die Fehlersuche und Diagnostik deutlich mehr ausgegeben, als der Rückzug gekostet hätte, der sehr sicher zum Erfolg führen würde.

 

Von den theoretisch 20 Anwendern sind im Regelfall nur 7-8 am Standort, so wurden wohl damals die 10 MBit errechnet. Ich habe einen 300/60er LWL-Anschluss (M-net Premium Glasfaser-DSL) geordert, der die SDSL-Leitung ins RZ und die VDSL-Leitung ins Internet ersetzen soll. Damit sollte der Standort genug Kapazität haben, oder?

 

Durch ChrisRas Antwort wird es wohl auf DFS-R rauslaufen. Habt ihr da negative Erfahrungen mit zeitgleich gespeicherten Dateien auf den verschiedenen Servern? Laut MSDN soll das ein (theoretisches?) Problem sein?

[Necron 71]

Durch ChrisRas Antwort wird es wohl auf DFS-R rauslaufen. Habt ihr da negative Erfahrungen mit zeitgleich gespeicherten Dateien auf den verschiedenen Servern? Laut MSDN soll das ein (theoretisches?) Problem sein?

 

Das ist kein theoretisches Problem. Ein Beispiel User A öffnet Dokument C auf Server A und User B öffnet ebenfalls dasselbe Dokument C auf Server B. Der User der zuletzt speichert gewinnt an dieser Stelle mit seinen Änderungen. DFS-R bietet kein File-Locking. Ärgerlich für den User der seine Änderungen verliert.

 

-> http://blogs.technet.com/b/askds/archive/2009/02/20/understanding-the-lack-of-distributed-file-locking-in-dfsr.aspx

 

Ach ja und noch etwas geöffnete Dateien, also Dateien die sich im Zugriff befinden, werden nicht repliziert.

[NilsK 2.969]

Moin,

 

DFS ist für gemeinsam genutzte Daten nicht geeignet. Punkt. Such nach "Last Writer Wins".

 

Gruß, Nils

[NorbertFe 2.099]

Manch einer mag das erst glauben wenn er es selbst erlebt hat. ;)