Hanutaminator

Ähm ja. stimmt - DC2 (Hyper-V Client) ist auch Fileserver. Meine Workstation (Win10, Hyper-V Server für DC2), hat den DC2 als aktiven Partner. Gedanke dahinter war, beides lokal auf dem gleichen Rechner = maximaler Speed. Fehlanzeige wegen Beschränkung auf 1GB... Die Sync (also DFS-R) läuft doch im Hintergrund "hinterher". Gedanke war, schneller Zugriff auf das Raid 0, dieses syncronisiert sich im Hintergrund in aller Ruhe mit dem Raid 5 auf dem anderen PC Noch einmal zusammenfassend: 1ter physischer PC - DC1 (Server 2016) mit Raid 5 2ter physicher PC - Win10, Hyper-V Host, Raid 0, Festplatte deaktivert, als physischer Datenträger durchgereicht in - DC2 (Server 2016) als Hyper-V Client Das Win10 soll maximal mögliche Performance bekommen, daher das Raid 0 Würde Win10 direkt DFS-R unterstützen, würde ich mir den Server (DC2 mit DFS-R) natürlich sparen... Ich hoffe, ich konnte mich klar ausdrücken.

Hi, danke erstmal für die Resonanz! Also... Klare Antwort: NEIN ;-) Es ging mir aber primär um die Verbindung zwischen Hyper-V Host und seinem Clienten. Dieser Verkehr wird doch wohl nicht über die NIC laufen?! Ansonsten war mein Gedanke ja, 2te NIC im Client, Internen Switch konfigurieren. Nur wie sage ich ihm, dass er für Verbindungen zum Host nur diesen nutzt? Müsste über eine Route doch machbar sein, oder?! Hättest Du mir nicht sagen können dass ich kein DFS-R möchte? ;-) Böse Frage: WARUM nicht? Ich fange grade an mich mit Namespace anzufreunden, das ist doch die logische Konsequenz daraus? Replikationsprobleme hatte ich schon genug, das geht inzwischen. Habe mir jetzt extra 2x 24/7 Platten geholt, die Redundanz habe ich doch auf dem anderen Rechner mit Raid 5 - Unterbau. Es geht um ca. 4GB Daten, das wird böse mit SSD - auch wenn ich sie sehr mag. Wie gesagt, es geht um die Kommunikation Hyper-V Host <--> Client Und allgemein, mich interessiert wieso es Gebastel wäre? Ich fand die Idee dieser Konstruktion an sich eigentlich ganz nett ;-))) Fehleranfälligkeit zu hoch, weil zu viele Komponenten zusammenspielen (müssen)?

Moin Nils, es handelt sich um private "Basteleien" für den Lerneffekt, wenn Datensicherheit und gute Performance mit abfallen, gerne ;-) Das Ziel habe ich ja schon definiert, Datensicherheit durch das Raid 5 in Kombination mit dem DFRS, Performance durch das Raid 0. Wieso definierst Du es als wildes Gebastel, was genau stört daran so? Was wäre die bessere Lösung bei den genannten Hardwarevoraussetzungen? Gruß, Stefan

Hallo erstmal liebes Forum, ich möchte einen Hyper-V Client als Fileserver mit möglichst schneller Anbindung an den Host betreiben. Folgendes Scenario: 1 physikalischer Server (DC, Windows 2016) mit Raid 5 1 physikalischer Win10-PC mit Hyper-V, auf diesem ein virtueller zweiter DC (auch 2016), der ein physisches Raid 0 durchgereicht bekommt Beide PCs besitzen 2x1GB NIC. Der virtuelle DC hängt an einem auf extern konfigurierten virtuellen Switch, dieser bekommt eine eigene NIC. Ich möchte jetzt beide Plattensysteme mit DFRS syncronisieren lassen, daher auch die physische Festplatte im Hyper-V Clienten (also dem 2. DC). Der Win10-Host (die primäre Arbeitsstation) bekommt die Daten dann als DFS-Namespace vom 2. DC geliefert. Klappt auch alles bestens, nur ist die Verbindung zwischen dem Win10-Host und dem dort aufsetzenden Clienten auf 1GB beschränkt. Kann ich nicht irgendwie die Anbindung verbessern? Eine zweite virtuelle NIC auf dem 2.DC mit internem Switch z.B.? Läuft der Netzwerkverkehr zwischen Hyper-V Host und dem eigenen Clienten wirklich über die physikalische NIC? Das ist doch der absolute Flaschenhals. Ich hoffe ich konnte mich verständlich ausdrücken, was haltet ihr von diesem Konstrukt, wie könnte ich es verbessern? Es geht mir um die Kombination aus Datensicherheit (Syncronisation zwischen Raid 5 und 0 mittels DFRS, daher zwei Server 2016) und gleichzeitigem maximalem Speed auf dem Host (deshalb dort Raid 0). Es bringt mir nur leider gar nichts wenn ich danach das Raid 0 über 1GB LAN schaufeln muss... Danke schon einmal für eure Gedanken ;-)