IOPS unabhängig von Speicherkapazitäten bereitstellen
Kapazität, Storage und IOPS sind bei klassischem Speicher aus physikalischen Gründen nur abhängig voneinander optimierbar. Softwaredefiniertes Storage kann dieses Problem lösen.
Beim Storage-Design müssen immer drei konkurrierende Parameter berücksichtigt werden: Kapazität, Durchsatz und IOPS. Die drei Parameter hängen direkt miteinander zusammen, weil dies die Physik der Storage-Systeme nun einmal vorgibt. Sie können also nicht unabhängig voneinander optimiert werden – zumindest nicht bei einer Realisierung in Hardware.
Die Abhängigkeit der Parameter voneinander zwingt Ingenieure, zwischen Kapazität und Leistung zu wählen. Ist mehr Durchsatz nötig, baut man mehr Spindeln oder SSD-Controller ein. Mit den Überkapazitäten, die aus diesem Ansatz resultieren, muss man leben.
An Workloads, die einen hohen I/O-Durchsatz für kleine Datensätze brauchen, lässt sich das verzwickte Verhältnis zwischen IOPS und Kapazität besonders gut zeigen. So lässt sich bei Microsoft Azure beispielsweise mehr Leistung nicht unabhängig von mehr gemanagter Azure-Disk-Kapazität realisieren.
Software-definiertes Storage (SDS) entkoppelt diese Parameter, indem eine logische Abstraktionsschicht zwischen Storage-Ressourcen und Komponenten geschoben wird. Außerdem ermöglicht eine zentrale Softwaresteuerungsebene den Cloud Storage Services, die Kapazität granular zu verteilen, indem die logischen Block Volumes und File Shares über Storage-Knoten und Laufwerke verteilt werden.
Obwohl hyperskalierend, ermöglichen auch verteilte Storage-Systeme keine unabhängige Optimierung. Warum, wird nachstehend genauer beschrieben. Nur wenige Systeme sind für solche Abwägungen konzipiert. Das liegt wahrscheinlich an den hohen Bereitstellungskosten und geringer Nachfrage.
Die Ursache des Problems und Lösungsvorschläge
Die wechselseitige Abhängigkeit zwischen IOPS und Kapazität liegt in den mechanischen Begrenzungen rotierender Festplatten begründet. Dazu kommen Schreib-/Leseköpfe, die nur vier Wege der Leistungssteigerung bereitstellen:
den durch den eingebetteten Micro-Controller, die Memory-Puffer, NAND-I/O und die SATA-Schnittstellen begrenzten Durchsatz des Schreib-Controllers
Sie begrenzen den SSD-Durchsatz und die IOPS nach oben, insbesondere bezüglich zufälliger Schreibzugriffe, die die zehnfache Latenz sequentieller Schreibvorgänge haben können.
Es gibt eine traditionelle Methode, Workloads mit hohem Ein-/Ausgabebedarf (I/O) mit passendem Storage zu versorgen. Sie besteht darin, die Storage Volumes über so viele RAID-Laufwerke wie nötig zu verteilen und mehr RAM-Caches als Ein-/Ausgabepuffer hinzuzufügen.
SDS und Cloud Services skalieren IOPS unabhängig von der Kapazität
Das möglicherweise erste Produkt, das die Storage-Kapazität unabhängig vom Durchsatz machte, entwickelte Solidfire. Die Firma wurde 2015 von NetApp 2015 aufgekauft. SolidFire bot als erster Hersteller eine QoS (Quality of Service)-Funktion an, mit der Anwender einen Minimal-, Maximal- und Burst-Level für Durchsatz und IOPS festlegen konnten. SolidFire ordnete also jedem Volume unabhängig voneinander Leistung und Kapazität zu.
Viele Details zu der Technologie sind nicht bekannt, aber jeder 1-HE-Knoten des Scale-Out-Systems gehörte zu einem verteilten Controller, der durch ein dediziertes Hochgeschwindigkeitsnetz im Hintergrund miteinander verbunden war. Die Software konnte die vorhandene Kapazität über so viele Knoten verteilen, wie nötig waren, um die QoS-Garantien einzuhalten.
Cloud Provider machen ein großes Geheimnis aus ihrer physischen Hardware sowie der Provisioning- und Management-Software, die ihren Services zugrunde liegen. Im Grunde verwenden sie aber den technologischen Ansatz von SolidFire für Scale-Out-Arrays mit verteilten Controllern bis zum Rack- oder Pod-Format. Provider nutzen üblicherweise Hunderte identischer Storage-Server, die in Ressourcen-Pools zusammengefasst sind, um Storage-Services unterschiedlicher Kategorien wie Block-, File- oder Object Storage sowie diverse Leistungsklassen anzubieten. Amazon Elastic Block Storage (EBS) etwa kommt in mehreren Varianten. Dazu gehören breit anwendbare SSDs (gp2 und gp3) und SSD mit definierten IOPS (io1 und io2).
Üblich ist, dass Cloud-Storage-Produkte Speicherschichten mit definierten IOPS mit unterschiedlichen Kapazitätsgrenzen nach oben und unten offerieren. Im Gegensatz dazu ermöglichen die gp3-Instanzen den Awendern, ihren Durchsatz und IPOS unabhängig voneinander zu skalieren. Dafür ist keine zusätzlichen Block-Storage-Kapazität mehr nötig.
Mehrere AWS-Wettbewerber bieten eine ähnliche Flexibilität, die IOPS unabhängig von der Kapazität bereitzustellen und zu skalieren.
Die Instanzen gp2 und gp3 haben weiche Grenzwerte für die IOPS-Leistung. Sie weichen aber laut Amazon innerhalb eines Jahres 99 Prozent der Zeit nicht mehr als 10 Prozent von der genannten Leistung ab, und dies bei weniger als 10 ms Latenz. Gp2-Volumes unter 1000 GB haben eine Burst-Leistung von bis zu 3000 IOPS für mindestens 30 Minuten. Gp3-Volumens bieten mindestens 3000 IPOS, aber keine Burst-Möglichkeiten. Werden io2-Volumes mit AMD-basierten Elastic-Compute-r5-Instanzen kombiniert, schaffen sie bei Volumes mit nicht mehr als 4 GB Speicherkapazität bis zu 260.000 IOPS.
Mehrere AWS-Wettbewerber bieten ihren Kunden IOPS ebenfalls unabhängig von Kapazitäten an:
Azure Ultra disks, kommen in mehreren festen Größen von 4 Gibibytes (GiB) bis 64 Tebitytes (TiB). Die Anwender können Grenzwerte bis zu 300 IOPS pro GiB bestimmen, maximal 160.000 IOPS pro Disk. Ein 32-GiB-Volume kann also für 100 bis 9600 IOPS konfiguriert werden.
IBM Cloud Adjustable IOPS unterstützt die unterbrechungsfreie, dynamische Anpassung der IOPS-Kapazität in den Grenzen seiner zwei Service-Tiers: Endurance-Volumes bieten IOPS-Einstellungen größer als 0,25 IOPS pro GB, Performance (oder fest zugewiesene) Volumes zwischen 100 und 48.000 IOPS.
Anders als diese Beispiele skalieren die meisten Cloud Services die IOPS-Leistung nahezu direkt mit der Größe der Volumes. Die SSD Persistent Disks von GCP (Google Cloud Platform) beispielsweise bieten 30 Schreib- und Lese-IOPS pro Gigabyte bis zu einem Maximum von 60.000 Lese-IOPS. Dieser Wert hängt ab von der Zahl der angeschlossenen vCPUs, der Blockgröße und anderen Werten.
Ganz ähnlich Oracle Cloud Infrastructure (OCI) Block High Performance Volumes: Sie bieten 75 IOPS pro Gigabyte für 4.000 Blocks und bis zu 35.000 IOPS pro Volume. Braucht also eine Applikation nur ein Volume von 128 GB, können GCP SSCs maximal 3.840 IOPS bereitstellen, OCI Higher Performance 9.600 IOPS, während Amazon EBS io2 sich für bis zu 64.000 IOPS konfigurieren lässt.
Aspekte der Serviceauswahl
Die meisten Cloud Storage Services und Array-Anbieter skalieren IOPS mit der Kapazität. Der Grund sind technische Begrenzungen der Laufwerks- und Controller-Technologie. Deshalb muss man mehr oder größere Devices einsetzen, um mehr Durchsatz und IOPS-Kapazität zu erreichen. Für einige Applikationen allerdings skalieren das Arbeitsdatenset und die Ein-/Ausgabeanforderungen nicht linear.
Als Beispiel nennt AWS in einem Blogbeitrag über EBS gp3 Volumes, einige Apps wie MySQL und Hadoop. Sie brauchen hohe Leistung, aber keine große Storage-Kapazität. Ganz ähnlich ist es bei Mikroservice-basierte Applikationen mit kleinen Arbeitsdatensätzen und vielen Transaktionen auf einen gemeinsam genutzten Storage-Pool: Sie lassen sich beschleunigen, indem man die Storage-Latenz verringert und die IOPS hochfährt. In solchen Fällen bringen ein Cloud Service wie EBS io2 oder gp3 oder ein Storage-Produkt wie NetApp SolidFire, das mehr IOPS nicht an größere Volumes koppelt, bessere Leistungen fürs Geld.
