Seite 1 von 1
Virtueller Fileserver - Performance Probleme beim Speichern
Verfasst: 06.05.2008, 10:22
von d.kreuter
Hallo zusammen
Haben einen virtuelle Fileserver (windows 2003) - > BusLogic Controller.
Der Server läuft in einem VLAN und eigentlich ohne Probleme
Auffällig ist folgendes:
Das öffnen von Datenfiles geht sehr schnell. Das Speichern von Dateien ist deutlich verlangsamt.
Der Fileserver besitzt ein LUN auf einr HP SAN.
Merci für eure Inputs
Verfasst: 06.05.2008, 10:33
von Heros
Da musst du schon mehr Input liefern.
Verfasst: 06.05.2008, 10:36
von angoletti1
Na hier direkt die erste Frage: Wieso bei nem 2k3 nen Buslogic und nicht LSI

re:
Verfasst: 06.05.2008, 10:45
von d.kreuter
Wir hatten bei der LSI Config Probleme bei Grossen Datentransfers / Netzwerkunterbrüche. Bei Buslogic komischerweise nicht.
Guru: Welche Infos brauchst du noch?
Verfasst: 06.05.2008, 11:17
von Tschoergez
Die Fragen

:
was für HP SAN?
wie viele platten?
RAID-Konfiguration?
schreibcache aktiviert?
Wie groß ist das VMFS?
welche anderen VMs laufen noch drauf?
Spanning verwendet?
iSCSI oder FC SAN?
Soweit mal fürs erste, damit können wir uns dann ein Bild machen....
Viele Grüße,
Jörg
Verfasst: 06.05.2008, 11:31
von bla!zilla
Öffnen ist read IO, Speichern von Dateien ist write IO. Klingt also schon mal logisch, dass das Speichern von Dateien langsamer ist.
Bitte poste, wie im vorangegangenen Posting gefordert, mehr Informationen.
re: weitere Daten
Verfasst: 06.05.2008, 12:08
von d.kreuter
Zunächst schon mal danke für eure Unterstützung. Versuche mal die Fragen soweit mir möglich zu beantworten:
Wir verwenden eine EVA 4000, aktuell 12 HDs (je 149GB)
Der virt. Server greift auf ein Daten LUN mit 200GB zu. Das LUN ist grundsätzlich RAID1
Schreibcache ist auf der EVA aktiviert.
Das Daten Volume ist nur für den Fileserver. Auf dem ESX an sich laufen noch 8 weitere VMs, allerdings nur kleine W2K Server (Monitoring, Management etc.)
Spanning ? -> Spanning Tree ? = Ja
FC SAN
Verfasst: 06.05.2008, 12:13
von Tschoergez
mit spanning war die konfiugration der VMFS-Partition gemeint...
verwendest Du Raw Device Mappings für diese VM? (Weil Du Daten-LUN schreibst)?
Oder ist das auch eine normale virtuelle Festplatte, die physikalisch als vmdk-Datei auf ner VMFS-Partition liegt?
Viele grüße,
jörg
re:
Verfasst: 06.05.2008, 13:34
von d.kreuter
Es handelt sich um eine virtuelle Festplatte die als vmdk Datei auf einer VMFS Partition liegt. Soweit ich weiss wird kein Spanning verwendet (kann ich dies kontrollieren ?).
Gruss Dominik
Verfasst: 07.05.2008, 10:48
von bla!zilla
12 Platten und EVA4000 sollten schnell genug sein. Ich habe bei einem von mir betreuten System 4 ESXer mit rund 20 Gästen auf einer EVA 4000 2C2D mit 16x 146GB/15k absolut ohne Probleme. Welches XCS läuft auf den Controllern? Macht die EVA gerade was anderes? Leveling z.B.?
Verfasst: 07.05.2008, 10:58
von Tschoergez
noch weitere Gedanken:
Betrifft das nur diese eine VM? oder hast Du in anderen VMs ähnliche Verhaltensmuster?
Und: Du hast doch nicht etwa nen Snapshot für diese VM aktiv?
Viele Grüße,
Jörg
re:
Verfasst: 07.05.2008, 12:18
von d.kreuter
Es betrifft nur diese Fileserver VmWare. Snapshots sind nicht aktiv.
Meine Idee war nun doch auf LSI zu wechseln. Fraglich ist hier ob ich einfach den Controller tauschen kann, oder hier noch etwas zu beachten wäre.
Denke einfach als Referenz wäre dieser Test dennoch sinnvoll.
Verfasst: 07.05.2008, 12:27
von Tschoergez
Du musst im Gast den passenden Treiber installieren, sonst gibts nen Bluescreen beim Booten.
(Geht natürlich einfacher, wenn die Datenplatte ungleich der Systemplatte ist

).
Hast Du eigentlich irgendwelche Zahlen für das "verlangsamt" im ersten Post? Dann liese sich das auf jeden Fall besser vergleichen bei einem Test.
re:
Verfasst: 07.05.2008, 13:35
von d.kreuter
Nun die Datenplatte ist separat. Soweit ich weiss wird LSI unterstütz somit müsste ich keinen Treiber installieren.
Konkrete Zahlen zur Performance gibt es leider nicht, Diese sind laut Überwachung i.O.
Es gibt einfach Probleme beim Speichern und teilweise beim Öffnen der Daten (Useraussagen).