10
Brainstorming: SAN Performance verbessern
Situation:
Wir haben eine HP P2000 G3 iSCSI als SAN Backend im Einsatz. Verbunden ist sie über 2 Controller a 4 Ports per Gigabit iSCSI mit 2 SAN Switches, welche wiederrum mit je einer Leitung pro Switch mit einem ESXi 5.1 Host verbunden sind (also 2x 1 Gigabit Leitungen pro Host auf je einen SAN Switch). Das SAN ist redundant angelegt und funktioniert (MTU 9000). Insgesamt hängen drei ESXi Hosts und ein Backupserver am SAN.
Die P2000 hat 2x RAID 50 a 8x 450 GB SAS 10k. Inhalt sind 3 Linux VMs und 21 Windows VMs. Davon eine mit Exchange 2013, zwei RD-Session Hosts, zwei mit "richtigen" MS SQL Instanzen und 5x MS SQL Express. Die beiden "richtigen" MS SQL Instanzen sind lizenztechnisch an das jeweilige Produkt gebunden, einmal DATEV, einmal ELO DMS.
Die Arbeitsgeschwindigkeit auf den Windows 2012 R2 RD-Session Host ist eigentlich angenehm. Die Meisten Anwendungen laufen flott oder zumindest akzeptabel schnell. Die DATEV Anwendungen sind bekannter Maßen eher langsam, könnten aber nach meinem Eindruck schneller sein. Ich vermute die Probleme zum einen in der Software selbst, zum Anderen aber auch in einer zu geringen SQL / SAN-Performance.
Ziel:
Mein Ziel ist eine spübar bessere Performance im DATEV Umfeld, ohne große Invesitionen in ein neues SAN. Ich weiß nicht, ob das realistisch möglich ist, würde hier aber gerne zwei konkrete Vorschläge meiner Seits zur Diskussion stellen. Wenn ihr noch Ideen habt, höre ich mir die auch gerne an.
Ich kann nicht alle DBs auf einen dedizierten SQL Server auslagern, dazu fehlen mir die passenden Lizenzen, auf dem DATEV System die Rechte und auch die Erfahrungen. Diese Überlegung würde ich also erstmal außen vor lassen. Genauso scheiden neues SAN und 10 GBit wegen der Kosten zunächst mal aus.
Idee #1:
Ich hätte zusätzliche HP NICs zur Verfügung, könnte also weitere LAN Verbindungen in meinen ESXi Servern nutzen.Nach meinen derzeitigen Kenntnisstand ist aber die Lastenverteilung bei iSCSI auf mehrere NICs nicht möglich. Gibt es hier eine Lösung zusätzliche Verbindungen per Round-Robin oder dergleichen sinnvoll zu nutzen?
Idee #2:
7 Einschübe in der SAN sind nicht belegt. Man könnte mit SSDs hier sicher einen schnellen und vor allem für DATEV dedizierten RAID anlegen. Bevor ich aber jetzt ein paar teure HP SSDs einkaufe und am Ende feststelle, das mein GBit iSCSI das eigentliche Problem ist:
Wie langlebig und empfehlenswert sind SSDs als Speicher für SQL Datenbanken?
Hat jemand schonmal nicht HP zertifizierte SSDs in einer HP SAN verwendet? Die Geschwindigkeitsangaben der HP SSDs sind den Datenblättern nach gar nicht so prikelnd, meine Desktop SSD schaft da schon mehr.
Zusatzfrage #1:
Wie bestimme ich meine SQL bzw. meine SAN Performance am besten? Bisher habe ich selbst nur Tests aus einer VM z.B. mit ATTO Benchmark gefahren.
Zusatzfrage #2:
Wie unterscheide ich Geschwindigkeit der SAN-Verbindung und des SAN-Speichers als Engpass?
Danke für eure Anregungen.
Wir haben eine HP P2000 G3 iSCSI als SAN Backend im Einsatz. Verbunden ist sie über 2 Controller a 4 Ports per Gigabit iSCSI mit 2 SAN Switches, welche wiederrum mit je einer Leitung pro Switch mit einem ESXi 5.1 Host verbunden sind (also 2x 1 Gigabit Leitungen pro Host auf je einen SAN Switch). Das SAN ist redundant angelegt und funktioniert (MTU 9000). Insgesamt hängen drei ESXi Hosts und ein Backupserver am SAN.
Die P2000 hat 2x RAID 50 a 8x 450 GB SAS 10k. Inhalt sind 3 Linux VMs und 21 Windows VMs. Davon eine mit Exchange 2013, zwei RD-Session Hosts, zwei mit "richtigen" MS SQL Instanzen und 5x MS SQL Express. Die beiden "richtigen" MS SQL Instanzen sind lizenztechnisch an das jeweilige Produkt gebunden, einmal DATEV, einmal ELO DMS.
Die Arbeitsgeschwindigkeit auf den Windows 2012 R2 RD-Session Host ist eigentlich angenehm. Die Meisten Anwendungen laufen flott oder zumindest akzeptabel schnell. Die DATEV Anwendungen sind bekannter Maßen eher langsam, könnten aber nach meinem Eindruck schneller sein. Ich vermute die Probleme zum einen in der Software selbst, zum Anderen aber auch in einer zu geringen SQL / SAN-Performance.
Ziel:
Mein Ziel ist eine spübar bessere Performance im DATEV Umfeld, ohne große Invesitionen in ein neues SAN. Ich weiß nicht, ob das realistisch möglich ist, würde hier aber gerne zwei konkrete Vorschläge meiner Seits zur Diskussion stellen. Wenn ihr noch Ideen habt, höre ich mir die auch gerne an.
Ich kann nicht alle DBs auf einen dedizierten SQL Server auslagern, dazu fehlen mir die passenden Lizenzen, auf dem DATEV System die Rechte und auch die Erfahrungen. Diese Überlegung würde ich also erstmal außen vor lassen. Genauso scheiden neues SAN und 10 GBit wegen der Kosten zunächst mal aus.
Idee #1:
Ich hätte zusätzliche HP NICs zur Verfügung, könnte also weitere LAN Verbindungen in meinen ESXi Servern nutzen.Nach meinen derzeitigen Kenntnisstand ist aber die Lastenverteilung bei iSCSI auf mehrere NICs nicht möglich. Gibt es hier eine Lösung zusätzliche Verbindungen per Round-Robin oder dergleichen sinnvoll zu nutzen?
Idee #2:
7 Einschübe in der SAN sind nicht belegt. Man könnte mit SSDs hier sicher einen schnellen und vor allem für DATEV dedizierten RAID anlegen. Bevor ich aber jetzt ein paar teure HP SSDs einkaufe und am Ende feststelle, das mein GBit iSCSI das eigentliche Problem ist:
Wie langlebig und empfehlenswert sind SSDs als Speicher für SQL Datenbanken?
Hat jemand schonmal nicht HP zertifizierte SSDs in einer HP SAN verwendet? Die Geschwindigkeitsangaben der HP SSDs sind den Datenblättern nach gar nicht so prikelnd, meine Desktop SSD schaft da schon mehr.
Zusatzfrage #1:
Wie bestimme ich meine SQL bzw. meine SAN Performance am besten? Bisher habe ich selbst nur Tests aus einer VM z.B. mit ATTO Benchmark gefahren.
Zusatzfrage #2:
Wie unterscheide ich Geschwindigkeit der SAN-Verbindung und des SAN-Speichers als Engpass?
Danke für eure Anregungen.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 288212
Url: https://administrator.de/forum/brainstorming-san-performance-verbessern-288212.html
Ausgedruckt am: 28.03.2025 um 10:03 Uhr
10 Kommentare
Neuester Kommentar
Hallo.
Nur so als Anmerkung.
Da geht es gar nicht so sehr um die Geschwindigkeit. Schau dir einfach einmal den Unterschied zwischen einer zertifizierten Server SSD und einer Desktop SSD an.
Spätestens wenn du nach ca. einem Jahr die SSD tauschen musst (mein Fall aus der Praxis), weil die Performance am Boden ist, weißt du warum man auf einem Server keine Desktop SSD einsetzt
LG Günther
Nur so als Anmerkung.
Hat jemand schonmal nicht HP zertifizierte SSDs in einer HP SAN verwendet? Die Geschwindigkeitsangaben der HP SSDs sind den Datenblättern
nach gar nicht so prikelnd, meine Desktop SSD schaft da schon mehr.
nach gar nicht so prikelnd, meine Desktop SSD schaft da schon mehr.
Da geht es gar nicht so sehr um die Geschwindigkeit. Schau dir einfach einmal den Unterschied zwischen einer zertifizierten Server SSD und einer Desktop SSD an.
Spätestens wenn du nach ca. einem Jahr die SSD tauschen musst (mein Fall aus der Praxis), weil die Performance am Boden ist, weißt du warum man auf einem Server keine Desktop SSD einsetzt
LG Günther
Ich habe mit SSD allgemein wenig Erfahrungen, verschlechtert sich die Performance konstant? Muss ich bei einer HP SSD davon ausgehen das die nach einem Jahr getauscht werden muss?
Alternativ könnte ich mir auch ein paar 15k HDDs rein hängen, der Server würde davon profitieren und hätte seinen dedizierten Speicher. Aber lohnt sich das?
Alternativ könnte ich mir auch ein paar 15k HDDs rein hängen, der Server würde davon profitieren und hätte seinen dedizierten Speicher. Aber lohnt sich das?
Hi
nein, 15k HDDs sind nicht mehr das Maß der Dinge und IO+Latenz im Vergleich zu einer Server SSD ist auch besch*. Wenn dann investiere in Server SSDs bzw. in SSDs die von HP für das Storage angeboten werden. Bei 7 x 15k Platten wirst keinen nennenswerten Geschwindigkeitsvorteil haben, die bringen im Regel "nur" ~350iops - SSDs bis zu 100k (4k Blöcke...), 10k Festplatten sollten so bei 200-250iops liegen. Und neine Server SSD's halten länger, wir haben die SAN Bereich (Dell Equallogic) im Einsatz, seit mehr als 4 Jahren und von denen ist noch keine ausgefallen, von den 10k Platten >5.
Server SSDs sind anders gebaut, die haben mehr "Reserven" du kaufst eine 200Gb Platte diese ist aber "real" 400Gb und "tote"/nicht TRIM'bare Sektoren werden einfach verschoben, aus dem Grund sind die auch so teuer (so hat es mir der Dell Techniker mal erklärt).
Am besten ermittelst du erst einmal was du überhaupt benötigst: mehr schreiben oder mehr lesen und danach kannst dann die SSD's beschaffen (write oder read intensive SSD's). Wenn es denn überhaupt an den Festplatten liegt und nicht etwas anderes...
DATEV läuft selbst auf dedizierten Kisten mit 8Gb RAM und SSDs total besch* die Software ist einfach nicht toll :>
Gruß
@clSchak
nein, 15k HDDs sind nicht mehr das Maß der Dinge und IO+Latenz im Vergleich zu einer Server SSD ist auch besch*. Wenn dann investiere in Server SSDs bzw. in SSDs die von HP für das Storage angeboten werden. Bei 7 x 15k Platten wirst keinen nennenswerten Geschwindigkeitsvorteil haben, die bringen im Regel "nur" ~350iops - SSDs bis zu 100k (4k Blöcke...), 10k Festplatten sollten so bei 200-250iops liegen. Und neine Server SSD's halten länger, wir haben die SAN Bereich (Dell Equallogic) im Einsatz, seit mehr als 4 Jahren und von denen ist noch keine ausgefallen, von den 10k Platten >5.
Server SSDs sind anders gebaut, die haben mehr "Reserven" du kaufst eine 200Gb Platte diese ist aber "real" 400Gb und "tote"/nicht TRIM'bare Sektoren werden einfach verschoben, aus dem Grund sind die auch so teuer (so hat es mir der Dell Techniker mal erklärt).
Am besten ermittelst du erst einmal was du überhaupt benötigst: mehr schreiben oder mehr lesen und danach kannst dann die SSD's beschaffen (write oder read intensive SSD's). Wenn es denn überhaupt an den Festplatten liegt und nicht etwas anderes...
DATEV läuft selbst auf dedizierten Kisten mit 8Gb RAM und SSDs total besch* die Software ist einfach nicht toll :>
Gruß
@clSchak
Okay also wären SSDs schon eine Option zumal ich dann wirklich nur den DATEV Server darauf legen würde und die wenn ich mich nicht irre wird das Carepack auch nicht teurer sondern ich habe reine Anschaffungskosten.
Natürlich weiß ich jetzt noch nicht ob mein Problem eher in der HDD Performance oder im iSCSI Durchsatz liegt, da bin ich auch noch am grübeln. Was DATEV angeht möchte ich einfach eine Abstuffung auf etwas weniger besch* erreichen
Natürlich weiß ich jetzt noch nicht ob mein Problem eher in der HDD Performance oder im iSCSI Durchsatz liegt, da bin ich auch noch am grübeln. Was DATEV angeht möchte ich einfach eine Abstuffung auf etwas weniger besch* erreichen
HP bietet sicherlich Tools mit dem man das Storage messen kann um auch ermitteln zu können wo der Flaschenhals ist, da würde ich ansetzen. Aus reinen Vermutungen wird die Wahrscheinlichkeit nur hoch, dass man das falsche beschafft und keinerlei Besserung hat.
Mal ne doofe Frage, wieviele User hängen an Datev und welche Anwendungen, wieviel Cores, wieviel GHz und wieviel RAM haben die RDS?
Der Thread ist ja schon was älter, hast du auch DATEV im Einsatz oder warum fragst du?
An der Hardware hat sich seit meinem Thread noch nicht viel geändert da die P2000 keine SSDs unterstützt. Bisher wurde Softwre und das Netzwerk aufgerüstet, neue Server kommen vermutlich irgendwann dieses Jahr.
An der Hardware hat sich seit meinem Thread noch nicht viel geändert da die P2000 keine SSDs unterstützt. Bisher wurde Softwre und das Netzwerk aufgerüstet, neue Server kommen vermutlich irgendwann dieses Jahr.
Ach sorry, hab das Datum jetzt erst bemerkt
Nein, die von uns betreuten Datevumgebungen haben in der Regel keine Performanceprobleme.
Nein, die von uns betreuten Datevumgebungen haben in der Regel keine Performanceprobleme.
Um Performance-"Probleme" geht es auch nicht sondern einfach um Performance-Optimierung und -Messung. Ich gehe davon aus das habt auch ihr in euren Umgebungen.
Haben wir in der Regel tatsächlich nicht, denn die Regel sind kleine Netze mit übersichtlicher Benutzeranzahl. Das läuft meist über gefühlte Performance und das ist im Datevumfeld ja bekanntlich oft schwierig.
