11
Direkter Storage Access aus der VM?
Hallo,
wir sind weiterhin bei der Suche eines „möglichen“ Performance-Bottlenecks bei der Storageanbindung.
(Hierzu hatte ich bereits 2 Threads zu Benchmarks und Jumboframes erstellt)
Der Hersteller unseres ERP-Systems meint nun, dass die Datenbank-Applikation am OS/Windows vorbei und an VMWare vorbei direkt auf das Storage zugreift und dort das Write-Acknowledge abwartet.
Das was der Kollege erklärt hat, hörte sich für mich nach Buffer und Unbuffered IO an.
Aber damit kommt man nicht an dem VM Layer vorbei… oder?
Wir haben ein ESXi-Cluster, welches per iSCSI an ein Fullflash angebunden ist.
Ausser DirectPath I/O ist mir da nichts bekannt. Und das haben wir auch nicht im Einsatz.
Gibt es da noch andere Techniken?
Nachtrag: RDM oder iSCSI aus der VM nutzen wir auch nicht.
Danke und Gruß
wir sind weiterhin bei der Suche eines „möglichen“ Performance-Bottlenecks bei der Storageanbindung.
(Hierzu hatte ich bereits 2 Threads zu Benchmarks und Jumboframes erstellt)
Der Hersteller unseres ERP-Systems meint nun, dass die Datenbank-Applikation am OS/Windows vorbei und an VMWare vorbei direkt auf das Storage zugreift und dort das Write-Acknowledge abwartet.
Das was der Kollege erklärt hat, hörte sich für mich nach Buffer und Unbuffered IO an.
Aber damit kommt man nicht an dem VM Layer vorbei… oder?
Wir haben ein ESXi-Cluster, welches per iSCSI an ein Fullflash angebunden ist.
Ausser DirectPath I/O ist mir da nichts bekannt. Und das haben wir auch nicht im Einsatz.
Gibt es da noch andere Techniken?
Nachtrag: RDM oder iSCSI aus der VM nutzen wir auch nicht.
Danke und Gruß
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 6148232480
Url: https://administrator.de/contentid/6148232480
Printed on: July 27, 2024 at 00:07 o'clock
11 Comments
Latest comment
Hallo
dann schaue dir mal Nutanix an. Da sitzt der Storage direkt unterhalb der ESX.
Info: ERP Anbieter schieben Performance Probleme oft auf die Hardware.
Eine einfachere Ausrede gibt es nicht.
Welches ERP Lösung ist das?
Wurde diese sauber Programmiert?
Unterstützt diese ESX?
Gibt es sonst Performance Probleme in der ESX Welt?
dann schaue dir mal Nutanix an. Da sitzt der Storage direkt unterhalb der ESX.
Info: ERP Anbieter schieben Performance Probleme oft auf die Hardware.
Eine einfachere Ausrede gibt es nicht.
Welches ERP Lösung ist das?
Wurde diese sauber Programmiert?
Unterstützt diese ESX?
Gibt es sonst Performance Probleme in der ESX Welt?
Hallo,
es handelt sich dabei um eine Progress DB.
Ob sauber programmiert, kann ich nicht beurteilen.
Ja, ESX ist supported. Und nein, dies ist die einzige Applikation die von Performance Problemen berichtet.
Allerdings fehlen uns bei anderen Applikationen die Vergleichswerte um dies neutral beantworten zu können.
Wir sind vor einigen Jahren von einer NetApp mit drehenden Platten auf ein FullFlash umgezogen. Der Unterschied war/ist riesig. Ob es noch schneller sein müsste weiß ich daher nicht.
Aber an diesem Thema sind wir schon dran.
Mir geht es expliziet um die Aussagen, dass die Applikation direkt auf das Storage zugreifen würde. Und das kann ich nicht nachvollziehen.
Nunatix müsste ich mir mal genauer ansehen, aber ein wechsel des Storage ist mal nicht eingeplant.
Danke und Gruß
es handelt sich dabei um eine Progress DB.
Ob sauber programmiert, kann ich nicht beurteilen.
Ja, ESX ist supported. Und nein, dies ist die einzige Applikation die von Performance Problemen berichtet.
Allerdings fehlen uns bei anderen Applikationen die Vergleichswerte um dies neutral beantworten zu können.
Wir sind vor einigen Jahren von einer NetApp mit drehenden Platten auf ein FullFlash umgezogen. Der Unterschied war/ist riesig. Ob es noch schneller sein müsste weiß ich daher nicht.
Aber an diesem Thema sind wir schon dran.
Mir geht es expliziet um die Aussagen, dass die Applikation direkt auf das Storage zugreifen würde. Und das kann ich nicht nachvollziehen.
Nunatix müsste ich mir mal genauer ansehen, aber ein wechsel des Storage ist mal nicht eingeplant.
Danke und Gruß
Du meinst vermutlich PostgreSQL? Und die Performance Probleme sollen wirklich nur aus der DB resultieren?
Hast du vollen Zugriff auf die Datenbank und kannst dort direkt die Performance Probleme nachvollziehen? Eventuell mal @akretschmer fragen.
Hast du vollen Zugriff auf die Datenbank und kannst dort direkt die Performance Probleme nachvollziehen? Eventuell mal @akretschmer fragen.
Zitat von @ElmerAcmeee:
Der Hersteller unseres ERP-Systems meint nun, dass die Datenbank-Applikation am OS/Windows vorbei und an VMWare vorbei direkt auf das Storage zugreift und dort das Write-Acknowledge abwartet.
Das was der Kollege erklärt hat, hörte sich für mich nach Buffer und Unbuffered IO an.
Der Hersteller unseres ERP-Systems meint nun, dass die Datenbank-Applikation am OS/Windows vorbei und an VMWare vorbei direkt auf das Storage zugreift und dort das Write-Acknowledge abwartet.
Das was der Kollege erklärt hat, hörte sich für mich nach Buffer und Unbuffered IO an.
Wurde das so eingerichtet? Einfach so kann Windows oder die Datenbank nicht direkt auf das Storage zugreifen,
Was anderes: Progress DB - Die DB kenne ich nicht. Ist diese dateibasierend?
Eine Datenbank sollte hauptsächlich über den RAM arbeiten.
Ich glaube ich würden diesen Herstelle mal fragen, wie sie das geschafft haben wollen.
Aus der VM raus, am Hypervisor vorbei direkt auf die Hardware?
Hört sich für mich nach einer Sicherheitslücke an :D
bzw nach ner saudummen Ausrede.
Aus der VM raus, am Hypervisor vorbei direkt auf die Hardware?
Hört sich für mich nach einer Sicherheitslücke an :D
bzw nach ner saudummen Ausrede.
Das geht auf jeden Fall nur über eine Funktion des Hypervisors die dann von der Anwendung (DB) auch unterstützt wird oder mit direkter Anbindung des Storage an das OS in der VM selbst. Ich kenne auch keine solche Technik (aus meinem kleinen Teich hier) nicht und glaube auch nicht das so ein kleines ERP mit so einem Enterprise Killer Feature aufwarten würde.
Wie ist der direkte Zugriff zu verstehen? RDM-LUN?
Ohne detaillierte Konfig des ESXI und des Storage-LANs können wir eh nicht helfen.
Mann kann sehr viel bezüglich Storage einstellen und auch falsch machen.
Kennst du ioMeter?
Ohne detaillierte Konfig des ESXI und des Storage-LANs können wir eh nicht helfen.
Mann kann sehr viel bezüglich Storage einstellen und auch falsch machen.
Kennst du ioMeter?
Zitat von @ElmerAcmeee:
Wir haben ein ESXi-Cluster, welches per iSCSI an ein Fullflash angebunden ist.
Gäbe es denn überhaupt ausreichend lokalen Storage in einem Host?
Die Clusterfunktionalität würde dadurch eh ad absurdum geführt.
Moin,
also...
Nein, es ist nicht PostgressSQL sondern wirklich Progress (OpenEdge).
Die Aussage wurde getroffen, ohne dass der Kollege unsere Umgebung genau kannte. Daher war ich extremst verwundert.
Das genau Konzept bzw die Technik wie diese DB arbeitet ist mir noch nicht 100% geläufig, aber ist wohl extremst Abhängig vom Schreibzugriff. Neben der DB wird noch ein Log geschrieben, Erst wenn dieser Commit durch ist erhält auch die DB im RAM den Commit. (Hier hat ein interner Kollege mehr KnowHow als ich)
Der Tenor scheint aber hier zu sein, dass dieser direkte Storage-Zugriff so nicht funktioneren kann. Hätte mich auch sehr gewundert.
Bzgl der restlichen Fragen:
Ja IOMeter nutzen wir. Hilft aber nix, da die erzeugte Last der DB zu gering ist um das Storage auszulasten (QueueDepth=4 ist das Problem). Mit entsprechenden Workern kommen wir auch an die 300k ran.
Unser Storage Hersteller hat uns gestern die Ergebnisse ihres InHouse Systems zukommen lassen. Diese sind mit unseren identisch. Daher erübrigt sich eine weitere Fehlersuche bei der Anbindung.
Wir prüfen aktuell noch ob wir von 10 auf 25GBit wechseln können oder ob ein Umbau auf FC geplant werden kann.
Das ist aber hier bei dieser Frage OffTopic.
Danke@All
also...
Nein, es ist nicht PostgressSQL sondern wirklich Progress (OpenEdge).
Die Aussage wurde getroffen, ohne dass der Kollege unsere Umgebung genau kannte. Daher war ich extremst verwundert.
Das genau Konzept bzw die Technik wie diese DB arbeitet ist mir noch nicht 100% geläufig, aber ist wohl extremst Abhängig vom Schreibzugriff. Neben der DB wird noch ein Log geschrieben, Erst wenn dieser Commit durch ist erhält auch die DB im RAM den Commit. (Hier hat ein interner Kollege mehr KnowHow als ich)
Der Tenor scheint aber hier zu sein, dass dieser direkte Storage-Zugriff so nicht funktioneren kann. Hätte mich auch sehr gewundert.
Bzgl der restlichen Fragen:
Ja IOMeter nutzen wir. Hilft aber nix, da die erzeugte Last der DB zu gering ist um das Storage auszulasten (QueueDepth=4 ist das Problem). Mit entsprechenden Workern kommen wir auch an die 300k ran.
Unser Storage Hersteller hat uns gestern die Ergebnisse ihres InHouse Systems zukommen lassen. Diese sind mit unseren identisch. Daher erübrigt sich eine weitere Fehlersuche bei der Anbindung.
Wir prüfen aktuell noch ob wir von 10 auf 25GBit wechseln können oder ob ein Umbau auf FC geplant werden kann.
Das ist aber hier bei dieser Frage OffTopic.
Danke@All
Wenn du 300k IOPS mit 10G schaffst, dann wird 25GB nicht viel Unterschied machen, außer das LAN schafft weniger Latenzen hinzuzuaddieren. FC analog.
Das Storage ist für 300k ausgelegt?
Kannst du aus einer VM deiner Wahl die 300k abrufen? Wenn ja, wie ist dieser Workload aufgeteilt?
Das Storage ist für 300k ausgelegt?
Kannst du aus einer VM deiner Wahl die 300k abrufen? Wenn ja, wie ist dieser Workload aufgeteilt?
Hallo,
ich würde den Thread nun für mich als erledigt markieren.
Dennoch gehe ich gerne auf die Fragen ein
Kannst du aus einer VM deiner Wahl die 300k abrufen? Wenn ja, wie ist dieser Workload aufgeteilt?
Nein, ich habe dazu mehrere VMs nutzen müssen.
Zusammenfassend: die einzige Anwedung die "angeblich" langsam ist, ist dieses ERP System. Hier fehlt uns aber der Vergleich, da die Performance auch von den Prozessen und der Datenmenge abhängig ist. Dies lässt sich dann mit anderen Kunden, die diese Software einsetzen schwer vergleichen.
Und die eingesetzten Benchmarks sind sehr fragwürdig.
Gruß
ich würde den Thread nun für mich als erledigt markieren.
Dennoch gehe ich gerne auf die Fragen ein
Zitat von @2423392070:
Wenn du 300k IOPS mit 10G schaffst, dann wird 25GB nicht viel Unterschied machen, außer das LAN schafft weniger Latenzen hinzuzuaddieren. FC analog.
Ja, die Hoffung ist, dass die Latenz weiter fällt. Ich bin aktuell an einem Testaufbau dran. Wird aber noch ein paar Tage dauernWenn du 300k IOPS mit 10G schaffst, dann wird 25GB nicht viel Unterschied machen, außer das LAN schafft weniger Latenzen hinzuzuaddieren. FC analog.
Das Storage ist für 300k ausgelegt?
Ja, 300.000 IOP/s bei 32k und QD=256 laut Herstellerangabe. Peaks von mehr als 10k habe ich jedoch bei uns im normalen Betrieb noch nie gesehen.Kannst du aus einer VM deiner Wahl die 300k abrufen? Wenn ja, wie ist dieser Workload aufgeteilt?
Zusammenfassend: die einzige Anwedung die "angeblich" langsam ist, ist dieses ERP System. Hier fehlt uns aber der Vergleich, da die Performance auch von den Prozessen und der Datenmenge abhängig ist. Dies lässt sich dann mit anderen Kunden, die diese Software einsetzen schwer vergleichen.
Und die eingesetzten Benchmarks sind sehr fragwürdig.
Gruß