IOPS - Input Output Operations per Seconds
Privatkunden interessiert bei Festplatten eigentlich immer nur der Preis pro Gigabyte und die Gesamtkapazität. Und immer wieder kommen fragen, warum 1 TB nicht 1.000 Gigabyte sind und daher ein 1 TB Disk nur 953 oder noch weniger Megabyte groß ist. Für Server Administratoren sind das aber nur "Peanuts", da neben der Nettokapazität bei Servern ganz andere Faktoren zählen wie z.B.:
- Verfügbarkeit, Replikation und Rebuild-Rate
Daten sollten nicht verloren gehen und RAID gehört daher zur Pflicht aber auch gibt es feine Unterschiede bezüglich der Performance und auch der Rebuild-Rate, wenn eine Disk ersetzt werden muss. Größere Storage Systeme können sogar Daten auf andere Systeme replizieren oder kopieren und erlauben damit auch eine Absicherung gegen Ausfälle eines kompletten Chassis oder Racks. - Flexibilität und Erweiterbarkeit
Moderne Storage-Systeme erlauben aber auch Dinge wie "Thin Provisioning", d.h. nur der tatsächlich belegte Platz wird auf den Disks allokiert wird, was gerade im SAN mit vielen Servern Kosten sparen kann. Auch können moderne Betriebssysteme problemlos damit umgehen, wenn LUNs plötzlich "größer" werden. Auch Windows kann den neuen Platz im laufenden Betrieb ohne Neustart verwenden. - Snapshot, Cloning Techniken
Wer schon die Daten etwas vom Server entfernt aufstellt, kann natürlich auch z.B. eine Sicherung ohne den Server durchführen, vor einem Update einen "Schnappschuss" anlegen um schnell wieder zurück zu können.
Aber bei all den sonstigen Funktionen zählt für die Betreiber von Servern ein Punkt, den man in Anlehnung an eine Aussage der Automobilbranche etwa so formulieren kann:
IOPS sind durch nichts zu ersetzen außer durch noch mehr IOPS.
Was sind IOPS ?
Die kleines Einheit, die eine Festplatte quasi "verarbeiten" kann, ist ein Datenblock. Dieser kann geschrieben oder gelesen werden. Intern sind die meisten Festplatten mit 512-byte-Sektoren ausgestattet. Erst modernere Festplatten arbeiten auch intern mit größeren Sektoren, z.B. 4KByte. Was die Festplattenelektronik aber letztlich dem Betriebssystem anzeigt, ist wieder etwas anderes. Wenn Windows also NTFS mit 4k Blöcken nutzt, dann wäre es ja nur logisch, wenn die Disk auch diese Größe mit einem Zugriff statt 8 kleinen Zugriffen bedienen könnte. Wenn oben nun Exchange mit 64k Blöcken in der Datenbank arbeiten, dann bedeutet eine "Dirty Page" natürlich auch 16x4k-IOs, die in 128x512Bytes-Sektoroperationen aufgeteilt werden.
Neben der reinen Performance beim sequentiellen Lesen und Schreiben, die von Testzeitschriften gerne als Leistungsmessung für Desktop-Festplatten heran gezogen wird, ist für Server-Systeme die Anzahl der IOs wichtiger, die ein Subsystem bedienen kann. Aber das ist vereinfacht gesagt eine "IO-Operation" von denen eine Festplatte nur eine gewisse Anzahl pro Zeiteinheit umsetzen kann.
- Blockgröße und Ausrichtung (Alignment)
Neben der Blockgröße ist auch die Ausrichtung der Sektoren wichtig. Wenn eine Festplatte z.B. 128 Sektoren a 512byte auf einer Spur ablegt, dann sind das genau 64k. Schreibt Windows nun Daten, dann ist es aus Performancegründen ungeschickt, mitten im Schreiben oder Lesen eine Spurwechsel durchführen zu müssen. Siehe auch Diskpar. - Drehzahl der Disks und Positionierung
Viel Zeit geht auch beim Positionieren auf den Disks verloren. Hier stehen wir immer noch seit vielen Jahren im Beriech von Millisekunden für die Positionierung, was Welten gegenüber den Gigaherz darstellt. Auch bestimmt die Drehzahl, wie lange ein Kopf auf der Spur durchschnittlich warten muss, bis der geforderte Block zum Lesen oder Schreiben drunter durchfliegt. - Anbindung (SAS, SATA)
Auch wenn die Datenraten von SAS und SATA auf vergleichbar hohem Niveau liegen und theoretisch höher als die Nenngeschwindigkeit der Festplatten sind, gibt es doch unterschiede bei der Verarbeitung der Befehle. Viele Dinge sind in SATA wohl noch nicht enthalten oder günstiger ausgeführt - Cache ist nur kurzfristig
Wer nun mit Ram zum Cache auf der Disk, dem Controller oder im Server die Situation entschärfen will, vergisst, dass IOs sich damit nicht vermeiden lassen. Transaktionslogs schreiben "Synchron" unter Umgehung der Caches und meist ist der Speicher deutlich kleiner als die übertragenen Datenmengen. - RAID-Level
Niemand nutzt heute in Servern einfach eine Disk. Es ist auch vom RAID-Controller abhängig, wie effektiv er IOs verarbeitet und auch das RAID-Level hat maßgeblich Einfluss auf die IOPS eines Subsystems
Wir brauchen als eine Maßgabe für IOPS, die ein bestimmtes System bereit stellen kann.
Festplatten aus RAM oder SRAM
Solche Festplatten werden immer größer und sind relativ schnell, da sie
ohne Leseköpfe keine Zeit für die Positionierung verlieren. Allerdings
sind sie immer noch kleiner als echte Festplatten und lassen sich nicht
so oft überschreiben wie klassische Festplatten. Wer zudem nur eine
Teilinformation ändert, verursacht erst einen Lesezugriff auf den
Speicher, damit die Änderungen durchgeführt und der gesamte Block wieder
geschrieben wird.
Die folgenden Werte habe ich aus verschiedenen Quellen und aufgrund der schnellen technischen Entwicklung sollten Sie diese nicht als Basis für ein Sizing verwenden. Letztlich liegt es am Lieferanten des Storage-Systems ihnen diese Daten zu liefen oder gemäß ihrer IOPS-Anforderung ein passendes Storage-System zu konfigurieren
Leistung pro Disk
Aus diversen Quellen gibt es natürlich verschiedene Angaben. Auch Festplatten entwickeln sich weiter aber als Faustregel können folgende Zahlen genommen werden
| Umdrehung | IOPS |
|---|---|
| Single Disk 15k rpm | 180-210 IOPS |
| Single Disk 10k rpm | 130-150 IOPS |
| Single Disk 7200 rpm | 80-100 IOPS |
| Single Disk 5400 rpm | 50-80 IOPS |
| Intel X25 Speicherdisk | 8,600 write IOPS, 35,000 read IOPS |
| OCZ Z-Drive e84, a PCI Express SLC Solid State Drive | 16,000 IOPS |
Die IOPS für eine einzelne Disk sind für Lesen und Schreiben gleich. (Quelle u.a. http://en.wikipedia.org/wiki/IOPS). Der deutliche Sprung bei den Disks mit Speicherbausteinen ist natürlich eine effektive Möglichkeit, z.B.: Transaktionsprotokolle deutlich zu beschleunigen.
Einfluss von RAID
Die effektiv verfügbare IOPS-Leistung ist natürlich anhängig vom RAID-Level, bei dem mehrere Disks zusammen geschaltet werden. Für eine IO-Operation werden mehrere Zugriffe auf Disks benötigt:
| Raid Level | Erforderliche Schreibvorgänge / Lesevorgänge | Formel: erforderliche DiskIOs abhängig von der Verwendung | ||
|---|---|---|---|---|
| RAID0 | 1/1 Ein Lesezugriff bzw. Schreibzugriff betrifft immer nur die Disk, auf der der angeforderte Block liegt |
Disk IOPS = Read IOPS + Write IOPS | ||
| RAID5 (aus 3 Disks) | 3/3 Beim Schreiben auf ein RAID5 aus 3 Disks müssen die Daten halb auf DISK1 und halb auf Disk2 geschrieben werden und die errechnete Parity auf Disk 3 landen. Daher sind drei Schreib-IOs erforderlich. Beim Lesen würde es genau genommen reichen, auch nur N-1 Disks zu Lesen aber anscheinend lesen alle Controller alle Disks um die Parity zu prüfen. Daher auch hier drei IOs |
Disk IOPS = Read IOPS + (3 * Write IOPS) Die Formel bei RAID5 kann ich mir nicht ganz erklären, denn ich hätte da auch bei den Read IOPS den Faktor 3 addiert. Aber so steht sie im Microsoft Dokument. |
||
| RAID1 oder 10 | 2/1 Beim Schreiben muss die Information auf beide Disks geschrieben werden, während beim Lesen der Zugriff auf eine Disk ausreichend ist. Allerdings soll es auch Controller geben, die dennoch beide Disks Lesen um die Gültigkeit der Daten (müssen identisch sein) zu prüfen. |
Disk IOPS = Read IOPS + (2 * Write IOPS) |
Beachten Sie aber auch hier, dass diese Zahlen nur annähernd für die normale Hardware-RAIDs gelten. StorageSysteme, SANs, iSCSI haben hier eventuell ganz andere Werte. An anderer Stelle habe ich folgende Formel gefunden, bei der aber keine Angaben zum "RAID Penalty Factor" standen
Total IOPS = #Disks x IOPS/Disk x RAID Penalty factor
Insofern ist diese Formel nicht weiter hilfreich. Zumal größere Server und Speichervirtualisierung hier ebenfalls einen Einfluss hat.
Der Einzige, der ihnen genau die IO-Leistung eines Subsystems nennen, kann ist der Hersteller/Lieferant. Dieser wird aber immer mit "hängt von ... ab" antworten, so dass Sie vielleicht besser umgekehrt an die Sache rangehen und ihrerseits einfach den Bedarf ermitteln und damit dann an den Hersteller gehen
- Optimieren von Speichersystemen für Microsoft
http://download.microsoft.com/download/8/7/9/879964bc-457f-48c5-9845-af5c2d5001f4/StoragePerformance.doc - Tips for Designing a Well Performing Exchange Disk
Subsystem
http://technet.microsoft.com/de-de/library/bb219049%28EXCHG.65%29.aspx
Exchange und IOPS Ermittlung
Die Bedarfsermittlung für ihren Server hängt natürlich auch wieder von mehreren Faktoren ab. Natürlich ist die eingesetzte Software ein Thema, wobei ich mich hier nun doch auf Exchange beschränke. Für SQL, Dateiserver etc. gelten andere Werte. Und es ist auch ein Unterschied, welche Zusatzdienste auf dem Server noch ausgeführt werden. Der von Microsoft bereit gestellte Mailbox Storage Calculator ist eine gute Ausgangssituation, um die IOPS für ein Exchange System zu ermitteln, wobei er sich nur auf die Mailboxrolle bezieht
Achtung:
Der gängigen Sizer von Microsoft beziehen sich nur auf die
Postfachrolle. IO-Bedarf, der sich durch Hub/Transport oder CAS-Rollen
ergibt, ist her nicht berücksichtigt !!
Für die Dimensionierung von Postfachspeichern werden mehrere Schritte durchlaufen:
Ermitteln der Postfachverwendung
Sie müssen möglichst zutreffend ermitteln, wie viele Mails die Anwender pro Tag senden und empfangen und wie groß diese Mails sind. Das ist gar nicht mal so einfach, da Termineinladungen und Quittungen sehr klein sind aber ein paar große Mails mit Anlagen die Durchschnittswerte stark anheben können. Gut, wenn jemand diese Daten von einem Bestehenden System ablegen kann. Dabei helfen :
- Messagetracking
Diese zeigen sie übertragenen Mailmengen und deren Größe. Allerdings werden hier Änderungen an Kontakten und eigenen Terminen nicht erfasst. Trotzdem ist dies der vermutlich beste Indikator für das aktuelle Belastungsniveau. Schade nur, dass es keine einfachen Auswertetools von Microsoft hierzu gibt. Also bleibt nur selbst skripten. (z.B.: MsgTrackSum) - Datenbank Transaktionsprotokolle
Ein zweiter Indikator, welcher sogar interne Änderungen (z.B. Kontakte, Termine, Notizen etc.) beinhaltet, sind die Transaktionsprotokolle der Datenbank. Sie zeigen das Volumen der Änderungen auf DB-Level an. Auch hier fehlen aber die Werkzeuge seitens Microsoft, So dass Sie entweder selbst Auswertetools schreiben müssen, z.B.: Get224Log oder24hlog oder mit DIR und EXCEL sich eine Momentaufnahme kurz vor dem Backup als Quelle zusammenbauen. - Netzwerkaktivität und Performancedaten des
Disksystem
Wenn beide ersten Daten nicht verfügbar sind, könnten sie über diese Werte nur grob schätzen, was ihr System so macht. Ein Stück weit gelingt dies über Performance Counter ihres aktuellen Systems
Weitere Hinweise zum Sizing finden Sie auch auf Sizingdaten ermitteln.
Ermitteln der IOPS pro Mailbox
Diese Daten werden dann als Quelle heran gezogen, um die erforderlichen IOPS pro Mailbox zu ermitteln. Diese Formel ist von der Exchange Version abhängig, d.h. aufgrund der veränderten Datenbankstrukturen und Blockgrößen werden hier unterschiedliche Ansätze in Rechnung gestellt:
| 1000 Mailboxen | Exchange 2003 | Exchange 2007 | Exchange 2010 |
|---|---|---|---|
| 5/20 a 75k | ? | DB: 0,096 IOPS/Mailbox LOG: 0,034 IOPS/Mailbox |
0,03 IOPS/Mailbox |
| 20/80 a 75k | ? | DB: 0,385 IOPS/Mailbox LOG: 137 IOPS/Mailbox |
0,12 IOPS/Mailbox |
Sie sehen auch, dass Exchange 2010 aufgrund interner Änderungen an der Datenbank mit weniger IOPS auskommt. Wer im Sizer mal mit der Nachrichtengröße spielt, sieht, dass diese Angabe in die IOPS gar nicht relevant ist. Was aber nicht heißt, dass es dann nicht bei der Datenmenge noch einen Engpass geben kann
IOPS auf Disks aufteilen
Nun müssen Sie natürlich wissen, wie viele IOPS ihr geplantes Disk-Subsystem pro LUN "aushalten" kann. Diese Daten kann ihnen nur ihr Lieferant des Storagesystems liefern. Mit der bekannten Größe der Mailboxen und der Zielgröße der Datenbanken, die sie noch sinnvoll betreiben können (Backup, Restore, Replikation) bestimmen Sie die Anzahl an Postfächern pro Datenbank und reduzieren die Zahl dann so lange, bis die IOPS (pro Mailbox mal Mailbox) von der LUN, auf der die Datenbank liegen wird, bedient werden kann.
Weitere Links
- JetStress
- Exchange Sizing - Wie dimensioniere ich die Hardware ?
- How to Calculate Your Disk I/O Requirements
- 'http://technet.microsoft.com/en-us/library/bb125019(EXCHG.65).aspx
- Storage Technologies
http://www.microsoft.com/whdc/device/storage/default.mspx - Optimieren von Speichersystemen für Microsoft
http://download.microsoft.com/download/8/7/9/879964bc-457f-48c5-9845-af5c2d5001f4/StoragePerformance.doc - Horde Hardware Requirements
http://wiki.horde.org/HardwareRequirements - Optimizing Storage for Microsoft Exchange Server
2003
http://www.microsoft.com/downloads/details.aspx?familyid=c6084d20-9730-4ffc-805d-b957327604c6&displaylang=en - 10 Tips to Optimize Exchange 2003 Performance (Part
1)
http://www.msexchange.org/tutorials/Optimize-Exchange-2003-Performance-Part1.html
