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 kleinstes 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. Und dann gibt es natürlich auch noch die Leseköpfe und die Drehung der Festplatte. Während bei Durchsatzraten von Festplatten in MB/Sek gerechnet und oft die Obergrenze angegeben wird (also "bis xxx MByte), die aber nur beim sequentiellen optimierten Schreiben erreichen wird, ist die Formel bei IOPS einfacher. Damit ein IO ausgeführt wird, muss der Schreib/Lese-Kopf zu der entsprechenden Spur fahren und dann im Schnitt eine halbe umdrehung warten, bis der Speicherplatz unter ihm angekommen ist. Erst dann wird gelesen oder geschrieben und der IO ist erfolgt.

Und damit ist auch klar, welche Werte einer Festplatte maßgeblich sind:

  • Suchzeit
    Das ist mit mittlere Zugriffszeit der Köpfe und mechanisch vorgegeben. In der Regel sind kleine (2,5") Festplatten hier schneller da die Wege kürzer sind. Es gab sogar Festplatten mit mehreren "Armen" um die IOPS zu erhöhen. Mehr Festplatten oder Köpfe am gleichen Arm bringen hingegen wenig, da sie ja alle an der gleichen Stelle laufen.
    Die Suchzeit ist allerdings abhängig von der aktuellen und Zielposition. Ein Wechsel zur nächsten Spur ist deutlich schneller als ein Sprung von einer Seite zu anderen. Zudem dauert die Zeit bis zum Schreiben etwas Länger als zum Lesen. Beim Lesen muss man nicht so "genau" an der Stelle stehen wie beim Schreiben.
    Zeiten liegen hier meist zwischen 3,5ms bis zu 10ms für langsame Disks.
  • Drehzahl
    Die Drehzahl ist der zweite Faktor und eine Verdopplung der Drehzahl halbiert die Latenzzeit. Es ist irrelevant, ob die Festplatte dabei groß oder klein ist. Bei größeren Festplatten ist nur die Geschwindigkeit am äußeren Rand sehr hoch, so dass meist die Drehzahl nicht endlos gesteigert werden kann. 2,5" Disks können also schneller drehen.
    15k Disks haben ca. 2ms. 7200U/Min etwas über 5ms

Die Werte für eine Festplatten wird speziell für Serverfestplatten veröffentlicht:

Entsprechend kann man anhand der umdrehung und der durchschnittlichen Positionierungszeit die IOPS aufzeigen. Nehmen wir mal 3,5-4ms als Positionierungszeit bei Serverfestplatten an, dann ergeben sich folgende IOPS

Drehzahl IOPS
7200 75-100
10000 125-150
15000 175-210
SSD 2500-100.000 und mehr

Quelle: http://en.wikipedia.org/wiki/IOPS

Die Anzahl der möglichen IOPS nimmt mit der Drehzahl zu. Die "Kapazität", die Anschlusstechnik oder andere Feinheiten gehen also gar nicht die Berechnung der IOPS ein. Aber ganz unberücksichtigt bleiben darf dies dennoch nicht, weil eben die "Sprung"-Zeit der Köpfe durchaus ein Thema ist.

Wenn man als Anwendung (Exchange 2010 schreibt 64k), Dateisystem (NTFS hat 4k per Default), Stripe-Size des RAID-Controllers und Blocksize der Disk (512byte) gut aufeinander abstimmt, dann ist die Performance höher, als wenn man hier nicht drauf achtet.

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 512 Byte 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 (IOPS) aufgeteilt werden. Allerdings sind diese 128 Sektoren idealerweise "am Stück", d.h. eigentlich als ein etwas längerer IO zu zählen, der wenige Millisekunden länger dauert aber ohne mehrmalige Positionierung auskommt.

Insofern müssen andere Faktoren dennoch berücksichtig werden, um ein effektives Storagesystem zu erhalten.

  • 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

Einfluss der Festplattengröße

Auch wenn es auf den ersten Blick zu Erstaunen führt. Die Größe einer Festplatte in Gigabyte bzw. Terabyte ist für die IOPS nicht relevant. Es ist tatsächlich nur die Positionierungszeit und die Drehzahl. Aber die "Dichte" der Daten auf der Festplatte wirkt sich auf die Übertragungsleistung aus. Wenn auf einer Spur durch engeres Beschreiben quasi doppelt so viele "Bits/qm" abgelegt sind, dann kann die Festplatte beim Lesen und Schreiben die doppelte Datenmenge übertragen. Aber es ändert nichts an der IOPS Rate.

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

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