GTRDRIVER 17 Geschrieben 3. Dezember 2015 Melden Teilen Geschrieben 3. Dezember 2015 Hallo zusammen ich habe hier einen Dell Server mit SSD RAID 10 Verbund - darauf läuft 2012R2 mit HyperV Soweit rennt das ding echt gut - folgendes ist mir aufgefallen: HD Benchmark auf Hyper-V Host: Lesen: 897MB/s Schreiben: 876MB/s HD Benchmark auf Virtuellem 2012R2 (auf diesem Host) Lesen: 814MB/s Schreiben: 824MB/s Soweit so gut - Werte können sich sehen lassen (für einen Hypervisor) finde ich zumindest - wäre aber über eine Meinung von euch froh: Andere Situation: Ich gebe auf dem Hyper-V Host einen Ordner per Netzwerkfreigabe frei und mounte diesen als Laufwerk in der bereits beschriebenen Virtuellen Maschine auf diesem Host. (also Netzwerkverkehr nur über das Virtuelle - nicht physische - Netzwerk. Lesen: 805MB/s Schreiben: 310MB/s Hier war ich zum einen überrascht dass lesend annähernd der gleich wert über das Netzwerklaufwerk erreicht wird wie über den Hypervisor - was ich mir nicht erklären kann warum die Schreibrate über das Netzwerklaufwerk dann nur knapp 50% der leserate beträgt. Hier würde mich eure Erfahrung oder Meinung interessieren. CU GTR Zitieren Link zu diesem Kommentar
NilsK 2.969 Geschrieben 4. Dezember 2015 Melden Teilen Geschrieben 4. Dezember 2015 Moin, was genau erhoffst du dir denn von dieser Messung? Das ist doch ein völlig unrealistisches Szenario. Abgesehen davon, ist das Kopieren von Dateien ohnehin so gut wie nie als Benchmark geeignet, daher halte ich eine nähere Analyse jetzt für weitgehend überflüssg. Was soll die Umgebung denn später mal machen? Gruß, Nils Zitieren Link zu diesem Kommentar
GTRDRIVER 17 Geschrieben 4. Dezember 2015 Autor Melden Teilen Geschrieben 4. Dezember 2015 Hallo Prinzipiell erhoffe ich mir von dieser Messung eine grundsätzliche Aussage über die Performance des RAID Systems. Zum messen habe ich auch nicht einfach Daten kopiert sondern mittels eines Benchmark Tools mehrere Tests (sequenzelles Lesen/schreiben etc..) gefahren - das sollte eigentlich schon vergleichbare Werte liefern. Zum Hintergrund: Auf diesem System laufen viele Access Anwendungen die als BAckend auch Access Datenbanken nutzen (kein SQL Server) - das wiederum führt zu einer hohen Last auf den Netzwerklaufwerken - von daher ist es vor allem bei Access schon relevant was das Raid / das Netzwerk leistet. (auch wenn es sich hier nur um ein Virtuelles Netzwerk handelt) Zitieren Link zu diesem Kommentar
NilsK 2.969 Geschrieben 4. Dezember 2015 Melden Teilen Geschrieben 4. Dezember 2015 Moin, bei deinem Zugriff testest du aber nicht "das virtuelle Netzwerk". Um aussagefähige Werte zu bekommen, müsstest du schon von einem externen Rechner aus auf die Freigabe zugreifen. Selbst dann nützt dir ein Test, der per SMB Daten schreibt, aber für dein Szenario nichts. Ein Zugriff auf eine Jet-Datenbank ist dann doch etwas anderes. Zu den Hintergründen des Netzwerks in Hyper-V siehe: [Hyper-V und Netzwerke | faq-o-matic.net]http://www.faq-o-matic.net/2012/04/23/hyper-v-und-netzwerke/ Das bezieht sich zwar noch auf Windows 2008 R2, aber insbesondere an der Architektur hat sich hier nichts geändert. Welche Besonderheiten des SMB-Protokolls dir da jetzt noch in die Suppe spucken, kann ich nicht sagen. Aber wenn, dann solltest du mit realistischen Szenarien testen, nicht mit unrealistischen. Was genau meinst du mit "Auf diesem System laufen viele Access Anwendungen"? Ist das der Dateiserver, wo die Datenbanken liegen, die übers Netz genutzt werden? Oder soll das ein Terminalserver sein? Und wenn es auf Performance ankommt: Warum dann kein SQL Server? Das wäre eine der ersten zu empfehlenden Maßnahmen. Gruß, Nils Zitieren Link zu diesem Kommentar
GTRDRIVER 17 Geschrieben 4. Dezember 2015 Autor Melden Teilen Geschrieben 4. Dezember 2015 Hallo 1: Auf die Frage "SQL Server oder JET" habe ich keinen Einfluss - das muss ich als gegeben hinnehmen 2: Das NEtzwerk wird aufgeteilt in 1-2 Terminalserver und 1 Fileserver Da die Terminalserver einen möglichst performanten Zugriff auf die Fileserver bekommen sollen (via SMB) brauche ich entweder 3 physische Server mit 10GB NIC und 10GB Switches oder ich lasse alles auf einer SUPER Performanten Maschine unter HyperV (oder einem anderen Virtualisierer) laufen. Dann müssen die Datenpakete nicht in ein Physisches Netzwerk sondern bleiben innerhalb des virtuellen Netzwerks Oder sehe ich das falsch ? Zitieren Link zu diesem Kommentar
NilsK 2.969 Geschrieben 4. Dezember 2015 Melden Teilen Geschrieben 4. Dezember 2015 Moin, also ... für mich klingt das Konzept nicht gut. Der Jet-Zugriff hat neben der Performance derart viele Einschränkungen in einem Multi-User-Szenario, dass das Geld in einer Umstellung auf ein SQL-Backend mit Sicherheit besser investiert wäre. In der Regel sind das auch keine riesigen Aufwände. Wenn der Zugriff tatsächlich von einer RDS-VM auf eine Dateiserver-VM erfolgen soll, dann sollte der Zugriff auf demselben Host in der Tat performanter sein als wenn du über das LAN gehst. In dem Fall läuft der Traffic ja nur über den VMBus. Dabei wäre es dann evtl. sogar sinnvoll, die RDS-Server und den Dateiserver für die interne Kommunikation an einen "internen" vSwitch anzubinden. Meine Vermutung ist, wie gesagt, dass deine Beobachtung auf das SMB-Protokoll zurückzuführen sind. Dazu kann ich nichts Näheres sagen. Mein Favorit bliebe aber die sinnvolle Datenbankarchitektur ... Gruß, Nils Zitieren Link zu diesem Kommentar
GTRDRIVER 17 Geschrieben 4. Dezember 2015 Autor Melden Teilen Geschrieben 4. Dezember 2015 Hallo JA - du sprichst mir aus der seele - dieses JET Gedöns ist ja ganz nett - aber sobald die DAtenbanken größer werden wird das teilweise unerträglich langsam ... Ich werde nochmals anstoßen dass man hier doch mal auf SQL umstellt ..... Aber wie das halt so in spezialumgebungen ist.... Ich hab da noch so ein Schmankerl bei diesem Projekt - das poste ich aber in einem neuen Thread wegen der Übersichtlichkeit... CU GTR Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.