Wieviele IOPS sind genug? Und warum gibt es im RZ davon so wenig?

Moin,


Spannende Thematik.
Durch die Virtualisierung müssen ja nunmehr mehr Systeme (Datenbanken) auf das selbe Storage zugreifen. Als man noch schnelle Datenspeicher auf Basis von HDDs (mit 10k oder gar 15k) brauchte, hat man eben solche Systeme auf eigenen BareMetal Systemen betrieben. Der Rest lief dann als VM normal weiter.

Je mehr „Doppelwums“ die Storages unten drunter aber haben, desto schneller schiebt man auch mal eine VM mit schnellem Festspeicher in den Virtualisierung. Und dann braucht es eben ordentlich IOPS.

Wie @avatin schon schrieb: viele IaaS-Provider haben vermutlich (wissen tue ich das auch nicht) SAN-Infrastrukturen etabliert. Jeder neue Host wird dann angebunden und gut. So ist man als Provider sehr flexibel. Besser, als wenn ich jeden physischen Server mit Festspeicher ausstatte.


Und die IOPS lassen keine eindeutigen und vorallem Herstellerübergreifenden Eückschlüsse auf MByte/S zu. Das ist die Krux an den IOPS.


Und dann kommen noch andere Faktoren hinzu. Wurde das SAN per 128G FibreChannel angebunden oder oder 400G iSCSI? Wie wie Cache haben die einzelnen Storages?
Mal als zusätzlich offene Frage (weil ich das bisweilen nicht getestet habe/ testen konnte/ testen wollte): wie „performant“ sichhsind vSANs ggü. phys. SANs?

Performance am aktuellen Live System protokollieren (perfmon) und dann beim Cloudanbieter passend raussuchen?

Die Antwort ist doch ganz einfach:

Wenn dein Server/ dein Dienstleister NICHT die nötige Leistung für deine Anwendung bringt: wechseln.

Ansonsten: keine Diskussion: Preis/Leistung OK!?

Was ist eigentlich schnell? Hohe Datentransferraten? Viele IOPS? Niedrige Latenzen?
Wir haben z.B. ein System, dass nur wenige DB-Datensätze liest/ schreibt. Wenn aber die Verbindung selbst mal für > 1Sekunde hustet, muss der ganze Client neu gestartet werden..
Da sind bei uns die Latenzen wichtig…
Eine andere Applikation nimmt Maschinen Messdaten per OPC entgegen und schreibt die in eine MSSQL-DB. Da sind IOPS/ schnelle Reaktionszeiten wichtig…
Schwierig...

Habe gerade mal nach measuring IOPS gesucht und folgendes gefunden: How to Measure Disk IOPS Values
Selbst habe ich es nicht getestet. Vielleicht kann man es auf einem Live-System ja mal laufen lassen?

Hallo, die Frage ist auch ob die Software überhaupt geeignet ist über die Cloud zu laufen. Wenn du Fat Client's hast, die direkt ihre SQL abfragen machen und das noch auf ungünstige Art, dann helfen die so viele IOPS wie's nur geht kein Stück weiter.

Dazu schreibt man sich ein Testscript oder GUI Automation die man dann auf mehrere VMs verteilt laufen lässt.
https://de.m.wikipedia.org/wiki/Liste_von_Software_f%C3%BCr_automatisier ...

Also bei 50 Usern und einer WAWI sehe ich das eher unkritisch. Mächtig viel IOPS brauchst du bspw. bei einem Webserver der von tausenden Besuchern gleichzeitig Last generiert, da ist ne WaWi ehrlich gesagt PillePalle im Belastungsranking bei der geringen Useranzahl.
Und wenn Latenz wirklich eine kritische Rolle spielt nimmt man halt eine In-Memory DB die im RAM läuft.

Gruß gastric

Das mit InMemory DB ist schön und gut nur kann man sich die DB bei ERP Systemen nicht aussuchen.

Moin @StefanKittel,


so pauschal, also, dass ein HA Storage generell schneller wie ein DAS ist, kann man das nun auch nicht behaupten.

Im Gegenteil, gerade bei kleinen Lese.- oder gar Schreibanforderungen, kann ein DAS (ohne RAID) machmal deutlich schneller als ein SAN oder gar NAS sein. Das liegt mitunter daran, dass ein DAS nativ mit 4K, oder gar noch 512B angesprochen werden kann, die meisten SAN's die ich kennen, verarbeiten intern jedoch immer mindestens 64K und haben auch deshalb, grundsätzlich eine etwas höhere Latenz, vor allem bei kleinen random IO's, als ein vergleichbares DAS.
Mitunter aus diesem Grund, setzen wir übrigens nur Infortrend SAN's bei unseren Projekten ein, weil diese nicht mit min. 64K, sondern mit min. 16K arbeiten. 😁


Achte bitte insbesondere bei SQL nicht so sehr auf die IO's oder gar die Datenraten, sondern eher auf Dinge wie Latenz. 😉


Wie schon oben angedeutet, bei einem SQL Server sind zwar auch IO's wichtig, viel wichtiger ist jedoch, mit welcher Latenz die IO's abgearbeitet/qutiert werden.


Ja, wenn du genug RAM in deinem SQL Server hast, damit dieser die ganze DB cachen kann, dann spielt die Performance des Storages, insbesondere bei lesenden Anforderungen, eher eine untergeordnete Rolle, weil die meisten dieser Zugriffe, bereits schon durch den RAM bedient werden.


Alle SQL Server unserer Kunden laufen als VM's, aber auf Servern und SAN vor Ort.


Nö keineswegs, sonst hätte uns schon so gut wie jeder Kunde schon längst die Leviten gelesen.


Ähm, Vorsicht, ein DB Backup vor allem ein Vollbackup oder auch Restore, ist ein rein sequentieller Workload, der so eben nur beim Backup oder Restore der Datenbank vorkommt.
Im Tagesbetrieb ist jedoch meistens eher die Randomperformance entscheidend und nicht die sequentielle. 😉

Teste lieber mal mit DISKSPD ...

https://learn.microsoft.com/de-de/azure/azure-local/manage/diskspd-overv ...
https://github.com/Microsoft/diskspd/releases/latest/download/DiskSpd.zi ...

... und zwar mit den folgenden Parametern ...

Lesend:

Schreibend:

Oder für einen 80%lesend und 20% schreibend Mix:

... und vergleiche mal diese Ergebnisse gegeneinander. 😉

By the way, wenn es geht solltest du die Testdateigrösse "-c10G" = 10GByte, genau so gross machen, wie die angepeilte DB gross ist.

Gruss Alex

Moin @em-pie,


das finde ich auch.


Das ist so nur bedingt richtig, denn IO's lassen sich generell schon 1:1 in Durchsatz umrechnen.

Beispiel.

Wenn ein Storage 1.000.000 4K IO's leistet, dann muss es auch einen Durchsatz von min. 4K * 1.000.000 IO's = 4.000.000K/s = 3.906,25 MB/s = ~3,814 GB/s liefern.

Das Problem dabei ist jedoch, dass die Hersteller weder die IO noch die Durchsatzleistung mit denselben Kriterien ermitteln und genau deshalb, kann man deren Angaben leider auch nicht wirklich miteinander vergleichen. 😔

Zudem gibt so gut wie kein Hersteller an, bei weilcher Latenz die entsprechende Performance ermittelt wurde. 😭
Denn 1.000.000 IO's mit einer Latenz von 5ms, sind ganz sicher nicht dasselber wie 1.000.000 IO's mit einer Latenz von 0,1ms.


Definitiv 128G FC, die sind latenztechnisch auf jeden Fall viel flinker wie die 400G iSCSI, vor allem bei Windows.


Na ja, auch das ist leider nicht ganz so einfach zu beantworten. Denn ein vSAN ist nicht gleich ein vSAN und ein SAN ist leider auch nicht gleich SAN. 😔

Selbst und insbesondere vSAN's vom selben Hersteller, kannst du nicht wirklich 1:1 miteinander vergleichen, weil deren Leistung extrem von den verwendeten Host-CPU's, den RAM, den verwendeten NIC's, den SSD's und insbesondere auch der Konfiguration abhängt.

Und bei SAN's ist es leider ähnlich.
Erst vor ein paar Monaten meinte ein vorlauter HPE Verkäufer bei einem unserer Kunden, dass deren neue Alletra MP auf jeden Fall um Welten besser währe, als das was wir angeboten haben und vor allem das, was der Kunde jetzt schon besitzt. Dann hat der Kunde auf mein Anraten um eine Leihstellung gebetten, damit er sich von der sagenhaften performance selbst überzeugen kann und kurz danach hat er sein neues SAN bei uns bestellt, weil diese sagenhafte Alletra MP, es nicht mal mit seinem bisherigem, über 6 Jahre altem Infortrend SAN aufnehmen konnte. 🙃

Ach so, ja by the way, in der DS4000 die er davor hatte, werkelte lediglich eine 6 Kern CPU pro Controller und die Alletra MP die er zum Testen bekommen hat, war mit 16 Kernen pro Kontroller bestückt. 😁

OK, gut, die Alletra MP hat eine KI und die Infortrend nicht. 😔
Vielleicht ist aber auch deshalb, selbst die alte Infortrend ja auch etwas flinker gewesen. 🤪

Gruss Alex