IOPS, etc. Aspekte zur Performance bei der Storageplanung in virtualisierten Umgebungen v.0, Stand 25. August 20
Einleitendes Wesentliches In den letzten Jahren zeichnete sich eine stetige Verschiebung der Flaschenhälse im Virtualisierungsumfeld ab: Aktuelle Prozessoren sind im Durchschnitt weitaus leistungsfähiger als benötigt und Speicher ist so günstig, dass voll ausgebaute Virtualisierungshosts keine Seltenheit sind. Oft ist bei der Planung von Virtualisierungsclustern das Storage unter den Servern das eigentliche Problem, da meist nur bekannt ist, wie viel Platz für die Ablage von Betriebssystemen, Anwendungen und Daten notwendig ist, jedoch nicht welche Geschwindigkeit die Anwendung den Festplatten (oder SSDs) tatsächlich abverlangt. In vielen Fällen wird dann blind, nur nach Platzbedarf geplant, was unter Umständen stark an der Realität vorbei geht. Dieses Dokument begleitet Sie durch die verschiedenen Planungsstufen, liefert Anregungen für eine durchdachte Planung, macht auf wenig bekannte Fakten aufmerksam und vermittelt ein Grundverständnis für die Hintergründe bei der Wahl des richtigen Storage-Arrays. Für die Bemessung von Storage-Performance müssen verschiedene Faktoren berücksichtigt werden: Latenzzeiten: Sowohl zwischen Host und Storage als auch in den einzelnen HDDs diktieren durch die Hardware vorgegebene Latenzzeiten die früheste Antwortzeit bzw. die Zeit zwischen Anfragen an das Storage IO-Vorgänge per Sekunde (IOPS): Basierend auf der Umdrehungsgeschwindigkeit der Festplatte und deren Suchzeiten (bzw. den NAND Chips bei SSDs) ergibt sich eine Maximale Anzahl von Vorgängen, welche die HDD innerhalb einer Sekunde abarbeiten kann. Datentransferrate: Abhängig von den verwendeten Blockgrößen als Übertragungseinheit ergibt sich in Kombination mit den I- OPS eine maximale Transferrate in MB/s. 2
Scheibchenlogistik Die Storageplanung beginnt bereits bei der einzelnen Festplatte. Unterschiedliche Laufwerkstechnologien bieten unterschiedliche Symbiosen aus Geschwindigkeit, Platzgebot und Kosten. Entscheidend für die Geschwindigkeit sind dabei die IOPS für random I/O. Ermittlung der IOPS durch Herstellerspezifikationen: Anhand von Festplatten-Datenblättern können die zu erwartenden IOPS berechnet werden. Benötigt werden folgende Kennzahlen aus den Datenblättern des Herstellers: tt Average latency (Durchschnittliche Latenzzeit) in ms tt Average read seek time (Durschnittliche Lese-Suchzeit) in ms tt Average write seek time (Durschnittliche Schreib-Suchzeit) in ms. Ermittlung durchschnittl. Gesamt-Suchzeit: 2. Ermittlung IOPS tt = (tt + tt ) IIIIIIII = tt 2 + tt 000 Beispielsweise angewendet auf gängige Festplattenmodelle: Seagate ST350048AS 7.2krpm 500GB 3gbit SATA: = 8.5mmmm + 9.5mmmm 4.6mmmm + 2 000 4.6mmmm + 8mmmm 2 000 Seagate ST3600057SS 5krpm 600GB 6gbit SAS: = 3.4mmmm + 3.9mmmm 2mmmm + 2 000 Erfahrungswerte: 2mmmm + 7.3mmmm 2 000 7777 IIIIIIII 0.036ss IIIIIIII 0.00565 Basierend auf den vorher gewonnen Zahlen und Langzeiterfahrung kann typischerweise von folgenden Werten ausgegangen werden: Traditionelle Medien SSD Umdrehungen Typ IOPS Typ IOPS 5'000 rpm SAS 75 Intel X25-M (MLC) 8 000 0 000 rpm SAS 25 Intel X25-E (SLC) 5 000 7 200 rpm SAS/SATA 75 OCZ Vertex 3 60 000 5'400 rpm SATA 50 OCZ Z-Drive R4 PCIe 500 000 5'000 rpm SAS + NCQ* 400 * Unter Idealvorraussetzungen. Für Berechnungen sollte vom Basiswert (75) ausgegangen werden. Datendurchsatz (MB/s): Der Datendurchsatz ergibt sich durch Multiplikation der Request-Größe (Blocktransfer-Größe der Anwendung) mit den IOPS, die zur Verfügung stehen. Bei Virtualisierungslösungen im SMB-Umfeld spielt der Datendurchsatz oft eine untergeordnete Rolle da meist das verwendete Interface (z.b. FC, SAS) nicht durch die Anwendung gesättigt werden kann. Weiterhin wird nahezu allen Fällen bei optimaler IOP-Planung auch ausreichende Durchsatzleistung gewährleistet. 3
Strafbank für RAID-Level Sobald die Geschwindigkeit einer Festplatte bekannt ist, muss als nächster Schritt ermittelt werden, welches RAID- Level eingesetzt werden soll und wie sich das RAID-Level auf die Performance auswirkt. Im folgenden wird auf die gängigen RAID-Level, 5, 6 sowie die Kombinationen mit RAID 0 eingegangen. Der Begriff Redundanz impliziert, dass Daten mehrfach vorhanden sind und daher auch mehrfach abgelegt werden müssen. Dem zufolge vervielfältigen sich Schreibvorgänge im RAID je nach Redundanzstufe. Im RAID bedeutet dies, dass jeder Block Daten zweimal geschrieben werden muss, da auf zwei Festplatten gespiegelt wird. Im RAID 5 (und im weitestgehenden Sinne auch RAID 6) ist der Sachverhalt komplizierter: Abhängig von der Datenmenge die geschrieben wird und der kleinsten Blockgröße, die der RAID-Controller bedient, ist die Schreibperformance unterschiedlich. Generell geht man vom ungüstigeren Fall aus: Es werden nicht Blöcke auf allen Festplatten gleichzeitig komplett geschrieben sondern nur verändert, da die zu schreibenden Daten nicht ausreichend groß sind um sie über alle Festplatten zu verteilen. Ein Beispiel: Bei einem RAID 5 bestehend aus 3 HDDs, also eine Paritätsaufteilung 2 Nutzdaten zu Paritätsdaten, mit einer Blockgröße von 52 Byte können 024 Byte Daten mit minimalem Performanceverlust von 3 geschrieben werden, da die Nutzdaten über 2 HDDs aufgeteilt werden und auf der 3. HDD ein Paritätsblock von 52 Byte geschrieben wird. Wenn nun weniger oder mehr Daten geschrieben werden sollen, ändert sich der Sachverhalt dahingehend, dass der RAID-Controller nun Blöcke auf den HDDs teilweise modifizieren muss: wenn nur 256 Byte verändert werden sollen, aber die kleinste Einheit für den Controller 52 Byte ist, müssen zuerst die auf den HDDs vorhandenen 52 Byte und der dazugehörige Paritätsblock eingelesen werden, bevor die Daten und die Paritätsdaten verändert werden können. Daraus ergeben sich nun 2 Lese- und 2 Schreibvorgänge für einen Schreibvorgang. Diese Theorie ist gleichermaßen auf RAID 6 übertragbar, unter Berücksichtigung des erhöhten Paritätsaufwands für 2 Paritätsblöcke. Hierbei ergibt sich ein Overhead von 6 I/O-Vorgängen. In Verbindung mit RAID-0 ergibt sich kein weiterer Schreiboverhead, da keine weitere Redundanz hinzugefügt wird. Zusammengefasst ergeben sich daraus folgende Performanceverschlechterungen (RAID penalties): RAID-Typ Multiplikator RAID-Typ Multiplikator 0 2 0 2 5 4 50 4 6 6 60 6 Beispiel: aus einem Schreibvorgang innerhalb der Anwendung werden im RAID 5 bis zu 4 Schreibvorgange auf den Festplatten. 4
Bitter im Abgang Mit allen redundanten RAID-Levels kommen auch Geschwindigkeitsnachteile im Falle eines Rebuilds/ Festplattenfehlers. Durch die Unterschiedlichkeit der verschiedenen Level muss einzeln auf die Unterschiede eingegangen werden. Zwei unterschiedliche Situationen müssen dabei berücksichtigt werden: Der Betrieb nach dem Ausfall einer HDD und der Betrieb während dem Rebuild. Die tatsächlich zur Verfügung stehende Performance ist jedoch abhängig vom verwendeten RAID-Controller und dessen Priorisierung während des Rebuild! Im folgenden ist nn die Gesamtzahl der HDDs im RAID (ursprüngliche RAID-Größe vor dem Ausfall). RAID /0: RAID 5: RAID 6: Festplattenausfall: Im betroffenen Stripeset kann nur noch von einer HDD gelesen werden. Die Anzahl ansprechbarer Festplatten für Read-IO reduziert sich um. Zusätzlich während des Rebuild: Das betroffene Stripeset produziert zusätzliche Last von x Lesen, x Schreiben. Festplattenausfall: Durch das Fehlen eines Mitglieds im Stripeset müssen statistisch gesehen nn Lesezugriffe mithilfe von Paritätsinformationen wiederhergestellt werden, wofür wiederum nn Read-IOs notwendig sind. Beim Schreiben verhält es sich ähnlich, statistisch ist jeder nn -te Schreibzugriff ein Paritätsblock welcher nur durch Auslesen der zugehörigen Datenblöcke verändert werden kann. Zusätzlich während des Rebuild: Für den neu-aufbau der Paritätsinformationen müssen für jeden Paritätsblock nn Datenblöcke ausgelesen werden. Der Controller bestimmt dabei wieviel Priorität dieser Aufgabe zugesprochen wird. Die meisten Enterprise-RAID Controller geben dem normalen Traffic-Aufkommen die größtmögliche Priorität und führend den Rebuild im Hintergrund durch bzw. erlauben eine manuelle Priorisierung. Die Performance-Implikationen beim Ausfall einer HDD sind typischerweise gleich derer im RAID 5. Beim Ausfall von zwei HDDs bzw. beim Rebuild ist der Geschwindigkeitsverlust jedoch stark abhängig von der jeweiligen RAID 6 Implementation, da unterschiedliche Verfahren für die doppelte Paritätsberechnung zur Verfügung stehen (neben Reed-Solomon z.b. RDOR-RDP, RDOR-EVENODD, P-Code) Empfehlenswerte, weiterführende Lektüre zu diesem Thema ist: A Hybrid Approach of Failed Disk Recovery Using RAID-6 Codes: Algorithms and Performance Evaluation http://www.cse.cuhk.edu.hk/~cslui/publication/tos.pdf P-Code: A New RAID-6 Code with Optimal Properties http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=54&context=cseconfwork&seiredir= 5
Detektivausbildung Da nun bekannt ist, welche Leistung im RAID-Array zur Verfügung gestellt werden kann, muss jetzt ermittelt werden, welche Leistung tatsächlich benötigt wird. Der Schwierigkeitsgrad dabei reicht von einfach (bestehende Serverumgebung oder gute Dokumentation des Softwareherstellers) bis schwierig (Aufbau einer neuen Serverumgebung from scratch ). Für gängige Anwendungen wie z.b. Datenbanken oder Mailserver finden sich unter Umständen im Web (z.b. Benutzerforen) Anhaltspunkte zu den Anforderungen. Weiterhin gibt es von manchen Herstellern Dokumente die eine konkrete Planung ermöglichen (z.b. für Microsoft Exchange Server 2007 auf MS Technet: http://technet.microsoft.com/en-us/library/bb73847(exchg.80).aspx) Weiterhin können Leistungsanforderungen anhand von bestehenden Anwendungsinstallationen erfasst werden. Dies natürlich unter der Prämisse, dass in der aktuellen Installation ausreichend Leistung vorhanden ist, um die Anwendung optimal zu bedienen. IOPS-Ermittlung bei bestehenden Installationen (Windows): Unter Microsoft Windows kann der Performance Monitor (perfmon.exe) zur Ermittlung der aktuell benutzten IOPS herangezogen werden. Im Performance Monitor sollten folgende Counter über einen längeren Zeitraum überwacht werden: \LogicalDisk\Disk Reads/Sec \LogicalDisk\Disk Writes/Sec Auf diesem Weg kann auch die Verteilung der Zugriffe (Lesen/Schreiben) ermittelt werden, was später noch von Nutzen sein wird. IOPS-Ermittlung bei bestehenden Installationen (Linux): Unter Linux kann iostat zum Messen der Leistung verwendet werden. Folgender Aufruf kann z.b. verwendet werden: iostat dkx 5 wobei -d die Ausgabe auf HDDs beschränkt -k Durchsatzwerte in Kbytes angibt -x erweiterte Reports zeigt 5 eine Kontinuierliche Messung mit einem Intervall von 5 Sekunden durchführt In der Ausgabe sollten dann r/s (Leseoperationen/Sekunde) und w/s (Schreiboperationen/Sekunde) erfasst werden. IOPS-Ermittlung in VMware-Umgebungen (vsphere Client): Für bestehende VMware-VMs können die IOPS über den vsphere Client abgelesen werden. In den erweiterten Performancediagrammen für die entsprechende VM muss der Graph umkonfiguriert werden. Unter Disk > Realtime (Echtzeit) müssen folgende Counter eingeschaltet und überwacht werden: Average read requests per second Average write requests per second 6
Baukastensystem Nachdem alle benötigten Variablen ermittelt sind, kann damit begonnen werden, die Anforderungen an das Storage-System zu berechnen. Abhängig von der Umgebungsgröße und dem zur Verfügung stehenden Budget ist es unter Umständen sinnvoll, VMs zu priorisieren und in Gruppen zusammenzufassen, welche dann auf Festplatten unterschiedlicher Qualität abgelegt werden um ein Höchstmaß von Kosteneffizienz zu erreichen. Die ermittelten Werte können nun entweder aufaddiert werden oder jede VM kann einzeln berechnet werden. Um zu berechnen, wie viele IOPS dem Storage durch die Anwendung abverlangt werden, gelten folgende Formeln: Berechnung mit prozentualem Read-/Write-Anteil: Benötigte Variablen: IIIIIIII Durch die Anwendung benötigte/generierte IOPS PP Prozentualer Anteil Read IOPS PP Prozentualer Anteil Write IOPS RR RAID Penalty (Multiplikator) Formel: BBBBBBötttttttttt IIIIIIII = IIIIIIII PP + IIIIIIII PP RR Beispiel: Ein Datenbankserver generiert 500 IOPS mit 60% Schreib-Anteil und 40% Lesen-Anteil. Der Server soll innerhalb eines RAID 6 für maximale Ausfallsicherheit betrieben werden. Berechnung: (500 40%) + (500 60%) 6 = 2000 IIIIIIII Demzufolge müssen mindestens 2 SAS 5krpm HDDs ( 22222222 ) oder 27 SATA HDDs ( 22222222 7777) für optimale Performance zur Verfügung gestellt werden. Alternativ: Berechnung mit absolutem Read-/Write-Anteil: Neue Variablen: IIIIIIII Durch die Anwendung generierte Lese-IOPS IIIIIIII Durch die Anwendung generierte Write-IOPS Geänderte Formel: BBBBBBötttttttttt IIIIIIII = IIIIIIII + IIIIIIII RR Beispiel: Ein Fileserver generiert 600 Read IOPS und 00 Write IOPS und soll auf einem RAID 0 betrieben werden. Berechnung: 600 + (00 2) = 800 IIIIIIII 5 SAS 5krpm HDDs ( 888888 ) oder SATA HDDs ( 888888 7777) werden benötigt. 7
Anmerkungen zum Hardwaredesign Wie oft im technischen Umfeld unterscheidet sich die Theorie etwas von der Praxis. Verschiedene zusätzliche Faktoren nehmen Einfluss auf die tatsächliche Performance im RAID-Array: Native Command Queueing (NCQ), Read-/Write-Caches im Storage Array sowohl als auch die Unterschiedlichkeit der Anfragen an das Storage: Random-/Sequentielle Datenübertragung und unterschiedliche Blockgrößen im Anwendungsbereich. Alle Berechnungen/Empfehlungen beziehen sich auf Worst-Case-Szenarios, d.h. Performancesteigernde Maßnahmen werden nicht berücksichtigt, da ihre Effektivität nicht in allen Situationen garantiert oder vorrausberechnet werden kann. Eine Ausnahme hierzu könnten fallbezogen Read-IOs sein, da hier üblicherweise Caching- Maßnahmen gut greifen. Bei dem mit Snapshot verbundenem Mehraufwand sollte z.b. mehr Augenmerk auf Write- als auf Read-IOs gelegt werden. Extrawurst (Snapshots) Snapshots spielen eine besondere Rolle in Bezug auf Storage I/O. VMware verwendet für VM-Snapshots das Copy-On-Write Verfahren: Blöcke werden erst in das Snapshot-Delta kopiert, wenn Veränderungen daran durchgeführt werden. Dadurch ergibt sich eine besonders hohe Last für das zu Grunde liegende Storage: Bei Leseoperationen müssen zuerst Metadaten gelesen werden, um zu ermitteln ob die zu lesenden Daten aus dem Snapshot oder der Base Disk kommen. Bei Schreiboperationen muss die Metadatentabelle aktualisiert werden, um das Snapshot-Delta zu referenzieren, dann erst können die Daten selbst geschrieben werden. Dadurch ergibt sich ein Multiplikator von 2, sowohl für Lese- als auch Schreiboperationen! Effektiv bedeutet dies, dass die für eine Anwendung ermittelten IOPS (lesend und schreibend) zu verdoppeln sind, wenn Snapshots verwendet werden. Angenommen der Datenbankserver aus dem ersten Beispiel der vorherigen Seite würde mit einem Snapshot betrieben werden, so sähe die Rechnung wie folgt aus: (500 2) 40% + (500 2) 60% 6 = 4000 IIIIIIII Demzufolge würden nun mindestens 23 SAS 5krpm HDDs ( 44444444 ) oder 54 SATA HDDs ( 44444444 7777) benötigt werden. 8
XXL-Extrawurst (VDI) Für die Planung von VDI, Virtuellen Desktop Infrastrukturen gelten ganz besondere Spielregeln. Anders als bei Serveranwendungen muss berücksichtigt werden, dass virtuelle Desktops nicht permanent in Betrieb sind und ein komplett unterschiedliches Lastprofil haben. VDI sollten komplett getrennt von Server-VMs betrieben werden und auch einer separaten Planung unterliegen. Das Worst-Case-Szenario in diesem Fall ist ein so genannter Bootstorm, also die Zeit in der die meisten Mitarbeiter mit der Arbeit beginnen und die virtuelle Infrastruktur gebootet wird. Wichtig: Hierbei wird von schlichten virtualisierten Desktops ausgegangen. Für Linked Clones müssten zusätzlich Snapshots berücksichtigt werden! Für die Ermittlung der notwendigen IOPS müssen verschiedene Variablen gesammelt werden: tt benötigte Zeit für die Anmeldung des Benutzers (laden des Profils, Autostart, ) in s. tt erwartete Sturm-Dauer (z.b. zwischen 8. 00 und 9. 00 Uhr) in min. PP Prozentualer Anteil an Benutzern, die sich typischerweise während des Sturms anmelden PP Maximaler Spitzenanteil an Benutzern die sich gleichzeitig (z.b. von 8. 05 bis 8. 0 ) während des Sturms anmelden. Empfohlener Erfahrungswert: 250% IIIIIIII Wieviele IOPS werden während der Anmeldung benötigt. Empfohlener Wert: ca. 75 basierend auf x7.2krpm SATA HDD in typischen Arbeitsplatzsystemen. Weiterhin müssen die Benutzer in Workloads ( Nutzungsprofile ) aufgeteilt werden: IIIIIIII Durchschnittliche IOPS für Workload χχ (Typischerweise 5 low, 0 med, 20 high) UUUUUUUUUU Anzahl an Benutzern für Workload χχ Basierend auf den gesammelten Variablen kann durch eine vorgegebene Formelkette ermittelt werden, wieviel Leistung für die VDI benötigt wird:. UUUUUUUUUU = UUUUUUUUUU + UUUUUUUUUU + UUUUUUUUUU + 2. UUUUUUUUUU = 3. IIIIIIII = UUUUUUUUUU IIIIIIII 4. EEEEEEEEEEEEEEEEEEEEEEEEEE = UUUUUUUUUU UUUUUUUUUU IIIIIIII 5. TTTTTTTTTTIIIIIIII = IIIIIIII + EEEEEEEEEEEEEEEEEEEEEEEEEE + EEEEEEEEEEEEEEEEEEEEEEEEEE + TTTTTTTTTTTTTTTTTT ist dabei die Gesamtanforderung an das Storage. Ein Rechenbeispiel: 20s Anmeldezeit, 60min Sturm-Dauer, 75% Sturm-Anmeldungen. Zwei Lastgruppen: 90 Factory Worker mit 5 IOPS, 50 Verwaltungsangestellte mit 20 IOPS:. UUUUUUUUUU = 90 + 50 = 40 2. UUUUUUUUUU = % = 8.75 % 3. IIIIIIII = 8.75 75 = 656.25 4. EEEEEEEEEEEEEEEEEEEEEEEEEE = 90 8.75 5 = 42.875 5. EEEEEEEEEEEEEEEEEEEEEEEEEE = 50 8.75 20 = 937.50 6. TTTTTTTTTTTTTTTTTT = 656.25 + 42.875 + 937.50 = 22222222. 666666 Die theoretische VDI-Umgebung produziert also im Worst-Case eine Last von ca. 206 IOPS. Bei 50/50 Read/Write und RAID 0 entspricht dies ca. 8 SAS 5krpm HDDs. 9
Fazit Je nach Unternehmens- und Serverumgebungsgröße kann sich die Storageplanung zu einem komplexen Thema mit vielen Variablen und Weggabelungen entwickeln. Letztendlich müssen weitere Faktoren wie z.b. Budgetierung, räumliche Gegebenheiten, Vorkenntnisse für die Betreuung, bereits eingesetzte Technologien, besondere Anwendungen berücksichtigt werden, auf die hier nicht eingegangen werden kann. Sollten Sie Hilfe bei der Planung Ihrer Infrastruktur benötigen oder andere Fragen haben, kontaktieren Sie bitte Ihren Vertriebsansprechpartner oder schreiben Sie uns unter: consulting@exone.de Neben der Beratung am Telefon bieten wir auch Consultingdienstleistungen an und gehen mit Ihnen jeden Schritt, angefangen vom ersten Planungsgespräch bis hin zur Einrichtung der letzten Softwarekomponente und der Schulung Ihrer Mitarbeiter. 0
Alexander Bartok (alex@exone.de) EXTRA Computer GmbH Brühlstrasse 2 89537 Giengen-Sachsenhausen www.extracomputer.de