Ein Unternehmen braucht All-Flash Storage vor allem dann, wenn Anwendungen dauerhaft niedrige Latenzen, hohe IOPS, hohen Datendurchsatz oder eine sehr hohe Verfügbarkeit benötigen. Entscheidend ist dabei nicht allein die Geschwindigkeit des Speichermediums. Auch Konsolidierung, Wiederherstellung, Datenreduktion und der Lifecycle der Storage-Plattform spielen eine Rolle.
Die wichtigsten Punkte:
Storage ist für viele Unternehmen längst mehr als ein Ablageort für Daten. Datenbanken, virtuelle Maschinen, ERP-Systeme und moderne Anwendungen greifen permanent auf Daten zu. Verzögerungen im Storage können deshalb unmittelbar die Anwendungen beeinflussen.
Gleichzeitig bedeutet das nicht, dass jede Anwendung den schnellstmöglichen Speicher benötigt. Die zentrale Frage lautet daher nicht: „Brauchen wir Flash?“ Sie lautet: „Welche Anforderungen stellen unsere Anwendungen an Latenz, IOPS, Durchsatz, Verfügbarkeit, Wiederherstellung und Skalierung?„. Erst wenn diese Anforderungen bekannt sind, lässt sich beurteilen, welche Storage-Architektur sinnvoll ist.
All-Flash Storage bezeichnet Storage-Systeme, die Daten ausschließlich auf Flash-Speicher statt auf rotierenden Festplatten speichern. Flash benötigt keine mechanischen Schreib- und Leseköpfe. Zugriffe auf Daten können deshalb mit wesentlich geringeren Zugriffszeiten erfolgen als bei klassischen HDD-basierten Systemen.
Im Enterprise-Umfeld geht es allerdings um mehr als das Speichermedium. Ein modernes All-Flash-Array umfasst typischerweise auch Funktionen für Datenmanagement, Hochverfügbarkeit, Snapshots, Replikation, Datenreduktion und Administration. Bei Everpure FlashArray übernimmt das Betriebssystem Purity einen wesentlichen Teil dieser Funktionen. Die aktuelle FlashArray-Familie umfasst unterschiedliche Systeme für verschiedene Anforderungen an Performance, Kapazität und Skalierung.
Everpure positioniert beispielsweise FlashArray//X und FlashArray//XL für performancekritische Enterprise-Workloads. Daneben existieren kapazitätsorientiertere Varianten wie FlashArray//C und FlashArray//E. All-Flash bedeutet daher nicht automatisch, dass jedes System für denselben Anwendungsfall ausgelegt ist.
Eine Storage-Architektur kommt an ihre Grenzen, wenn sie die Anforderungen der Anwendungen nicht mehr zuverlässig innerhalb der vereinbarten Service Levels erfüllen kann. Das kann sich unterschiedlich bemerkbar machen.
Typische Anzeichen sind:
Wichtig ist dabei die Ursachenanalyse. Eine langsame Anwendung bedeutet nicht automatisch, dass der Storage das Problem verursacht. Engpässe können ebenso im Netzwerk, in der CPU, im Arbeitsspeicher, in der Datenbankkonfiguration oder in der Anwendung selbst entstehen. Vor einer Storage-Entscheidung sollten deshalb reale Messdaten ausgewertet werden.
Vier technische Größen sind bei der Bewertung besonders relevant: Latenz, IOPS, Durchsatz und Verfügbarkeit. Keine dieser Größen sollte isoliert betrachtet werden.
Latenz: Wie schnell reagiert der Storage?
Die Latenz beschreibt die Zeit zwischen einer I/O-Anfrage und ihrer Verarbeitung durch das Storage-System. Niedrige und vor allem konsistente Latenzen sind wichtig, wenn Anwendungen sehr häufig kleine Datenmengen lesen oder schreiben.
Das betrifft beispielsweise:
Die aktuelle FlashArray-Familie zeigt, wie stark sich selbst All-Flash-Systeme unterscheiden können. Everpure nennt im aktuellen Familien-Datenblatt unter anderem 250 Mikrosekunden Latenz für FlashArray//X R5 und 150 Mikrosekunden für FlashArray//XL R5. FlashArray//ST ist für noch stärker I/O-orientierte Einsatzgebiete vorgesehen. Solche Herstellerwerte sind jedoch keine Garantie für die Latenz einer konkreten Anwendung. Netzwerk, Protokoll, I/O-Muster, Queue Depth, Server und Workload beeinflussen die tatsächliche Antwortzeit.
IOPS steht für Input/Output Operations per Second. Die Kennzahl beschreibt, wie viele I/O-Operationen ein Storage-System pro Sekunde verarbeitet. Hohe IOPS sind besonders bei Anwendungen mit vielen kleinen und parallelen Zugriffen relevant. Dazu gehören beispielsweise Datenbanken, große Virtualisierungsumgebungen und VDI-Infrastrukturen. Auch hier gilt: Die maximale IOPS-Zahl eines Arrays reicht für eine Bewertung nicht aus.
Relevant sind unter anderem:
Ein Storage-System kann theoretisch hohe IOPS erreichen und trotzdem für eine konkrete Anwendung ungeeignet sein, wenn dabei die Latenz zu stark steigt.
Der Durchsatz beschreibt die Datenmenge, die pro Zeiteinheit übertragen werden kann. Er wird typischerweise in MB/s oder GB/s angegeben. Hoher Durchsatz ist unter anderem wichtig für:
Everpure gibt beispielsweise für FlashArray//XL R5 im aktuellen Familien-Datenblatt bis zu 45 GB/s Durchsatz unter der dort definierten Testkonfiguration an. Auch dieser Wert sollte nicht direkt als erwartete Anwendungsperformance interpretiert werden. Entscheidend ist die gesamte Datenstrecke vom Server über das Netzwerk bis zum Storage.
Für geschäftskritische Anwendungen ist Performance nur ein Teil der Storage-Planung. Ebenso wichtig ist die Frage: Wie lange darf die Anwendung ausfallen und wie viele Daten dürfen im Fehlerfall verloren gehen? Daraus ergeben sich RTO und RPO. RTO, Recovery Time Objective, beschreibt die angestrebte Wiederherstellungszeit. RPO, Recovery Point Objective, beschreibt den maximal tolerierbaren Datenverlust gemessen in Zeit.
Everpure bietet mit ActiveCluster eine synchrone Active-Active-Replikation zwischen FlashArray-Systemen. Laut Hersteller ist die Lösung für Szenarien mit RPO 0 und RTO 0 zwischen zwei entsprechend ausgelegten FlashArray-Systemen konzipiert. Das setzt jedoch eine passende Gesamtarchitektur voraus. Storage-Replikation allein macht eine Anwendung noch nicht automatisch hochverfügbar.
All-Flash Storage ist besonders für Workloads interessant, bei denen Storage-Performance, konsistente Antwortzeiten oder schnelle Wiederherstellung geschäftlich relevant sind.
Datenbanken gehören zu den klassischen Einsatzgebieten für leistungsfähigen All-Flash Storage. Vor allem OLTP-Systeme erzeugen häufig viele kleine, zufällige I/O-Operationen. Niedrige Storage-Latenzen können hier unmittelbar relevant sein. Typische Beispiele sind:
Vor einer Dimensionierung sollten reale Datenbank- und Storage-Metriken ausgewertet werden. Dazu gehören Peak-IOPS, Read-/Write-Verhältnis, Blockgrößen, Durchsatz und Latenz.
SAP HANA stellt definierte Anforderungen an die zugrunde liegende Infrastruktur. SAP verweist für produktive HANA-Umgebungen auf zertifizierte beziehungsweise unterstützte Hardware und stellt eigene Hardware- und Cloud-Measurement-Tools zur Prüfung der Mindestanforderungen bereit.Everpure dokumentiert FlashArray//X und FlashArray//XL für SAP-HANA-Szenarien. Für konkrete Projekte muss jedoch immer geprüft werden, welche aktuelle Konfiguration von SAP zertifiziert beziehungsweise unterstützt wird. Die Entscheidung sollte daher nicht allein aufgrund des Produktnamens erfolgen. Bei SAP HANA sind die jeweils gültigen SAP-Vorgaben und das SAP HANA Hardware Directory maßgeblich.
Große VMware-Umgebungen können viele unterschiedliche I/O-Profile auf einem Storage-System bündeln. Das macht Virtualisierung zu einem typischen Konsolidierungsszenario für All-Flash Storage. FlashArray unterstützt verschiedene Integrationsmöglichkeiten für VMware vSphere. Dazu gehören klassische Block-Protokolle sowie VMware Virtual Volumes, kurz vVols. vVols ermöglichen eine stärker VM-bezogene Storage-Verwaltung. Virtuelle Datenträger können dabei direkt mit Storage-Objekten des Arrays verknüpft werden. Das erleichtert unter anderem die granulare Analyse von Kapazität und Performance einzelner virtueller Maschinen.
Virtual Desktop Infrastructure kann ausgeprägte Lastspitzen erzeugen. Viele virtuelle Desktops greifen gleichzeitig auf Storage-Ressourcen zu. Typische Situationen sind:
Diese Lastprofile können hohe IOPS und gleichzeitig niedrige Antwortzeiten verlangen. All-Flash Storage kann deshalb bei größeren oder performancekritischen VDI-Umgebungen sinnvoll sein. Die Dimensionierung sollte jedoch anhand realistischer Benutzer- und Lastprofile erfolgen.
Container sind nicht grundsätzlich auf zentralen All-Flash Storage angewiesen. Sobald jedoch zustandsbehaftete Anwendungen betrieben werden, wird persistenter Storage relevant. Das betrifft beispielsweise:
Everpure kombiniert FlashArray unter anderem mit Portworx für Kubernetes-Datenservices. Portworx stellt Funktionen für persistenten Storage, Datenschutz und Disaster Recovery für containerisierte Anwendungen bereit. Ob ein zentrales FlashArray dafür sinnvoll ist, hängt stark von Architektur, Persistenzanforderungen und Performanceprofilen der Anwendungen ab.
Eine leistungsfähige Storage-Plattform kann unterschiedliche Workloads auf einer gemeinsamen Infrastruktur zusammenführen. Das kann die Anzahl separater Storage-Silos reduzieren. Beispielsweise können auf einer Plattform gleichzeitig laufen:
Die Herausforderung liegt in unterschiedlichen Lastprofilen. Eine Datenbank kann viele kleine Random-I/Os erzeugen. Eine andere Anwendung benötigt hohen sequenziellen Durchsatz. Gleichzeitig können virtuelle Maschinen kurzfristige Lastspitzen verursachen. Deshalb sollte Konsolidierung nicht nur anhand der Gesamtkapazität geplant werden. Entscheidend sind insbesondere:
Je heterogener die Anwendungen sind, desto wichtiger wird eine belastbare Analyse vor der Konsolidierung.
Deduplizierung und Kompression reduzieren den physischen Speicherbedarf von Daten. Bei der Deduplizierung werden identische Dateninhalte nicht mehrfach physisch gespeichert. Kompression reduziert dagegen die Größe der zu speichernden Daten. FlashArray führt Datenreduktion unter anderem über Deduplizierung und Kompression durch. Everpure definiert die Data Reduction Ratio als Verhältnis der vom Host geschriebenen Datenmenge zum tatsächlich nach Kompression und Deduplizierung belegten physischen Speicher.
Wie hoch die Einsparung ausfällt, hängt stark von den Daten ab. Gut reduzierbar sind häufig Umgebungen mit vielen ähnlichen Datenblöcken, beispielsweise bestimmte virtualisierte Infrastrukturen. Bereits komprimierte oder verschlüsselte Daten können sich dagegen deutlich schlechter reduzieren lassen. Deshalb sollte bei einem Sizing nicht pauschal mit einer theoretischen Datenreduktionsrate gerechnet werden. Die Datenstruktur des konkreten Unternehmens ist entscheidend.
Hochverfügbarkeit soll verhindern, dass der Ausfall einzelner Komponenten unmittelbar zum Ausfall einer geschäftskritischen Anwendung führt. Bei Storage betrifft das unter anderem:
Für besonders kritische Anwendungen kann zusätzlich eine synchrone Replikation zwischen zwei Storage-Systemen sinnvoll sein. Everpure ActiveCluster stellt dafür Active-Active-Replikation zwischen FlashArray-Systemen bereit. Nach Herstellerangaben ist damit bei entsprechend ausgelegter Architektur RPO 0 und RTO 0 möglich.
Für die Planung reicht es jedoch nicht, lediglich zwei Storage-Systeme zu installieren. Auch Hosts, Netzwerk, Multipathing, Applikation, Quorum-Mechanismen und Standorte müssen zur gewünschten Verfügbarkeitsarchitektur passen. Hochverfügbarkeit ist daher immer eine Ende-zu-Ende-Eigenschaft der Infrastruktur.
FlashArray kann mit Snapshots, Replikation und SafeMode Snapshots einen Baustein einer Cyber-Resilience-Strategie bilden. SafeMode Snapshots sind darauf ausgelegt, Snapshots gegen ungewolltes oder böswilliges Löschen zu schützen. Das ist beispielsweise bei Ransomware relevant. Wird ein produktiver Datenbestand verschlüsselt oder gelöscht, können geschützte Wiederherstellungspunkte eine zusätzliche Recovery-Option darstellen.
Wichtig ist die Abgrenzung:
SafeMode Snapshots verhindern keine Ransomware-Infektion. Sie ersetzen auch keine vollständige Backup-Strategie. Cyber Resilience sollte mehrere Ebenen umfassen. Dazu gehören beispielsweise Zugriffsschutz, Netzwerksegmentierung, Backup, unveränderbare Wiederherstellungspunkte, Replikation, Monitoring und getestete Recovery-Prozesse. Storage kann die Wiederherstellung unterstützen. Die Sicherheitsstrategie muss jedoch deutlich weiter reichen.
Die Evergreen-Architektur verfolgt das Ziel, Storage-Systeme über längere Zeiträume weiterzuentwickeln, ohne bei jedem Technologie-Refresh eine klassische vollständige Datenmigration durchführen zu müssen. Everpure beschreibt dafür nicht-disruptive Hardware- und Software-Upgrades über mehrere Produktgenerationen hinweg. Das unterscheidet sich vom traditionellen Storage-Lifecycle.
Dort sieht der Ablauf häufig so aus:
Beschaffung → Betrieb → Kapazitätserweiterung → Hardware-Ende → neues System → Datenmigration → Außerbetriebnahme.
Mit Evergreen sollen Controller, Kapazität und Software schrittweise modernisiert werden können, während die Daten auf der Plattform verbleiben. Für Unternehmen kann das relevant sein, weil Storage-Migrationen nicht nur technischen Aufwand verursachen. Sie benötigen häufig auch Projektplanung, Tests, Wartungsfenster und personelle Ressourcen. Evergreen sollte dennoch nicht mit „Storage ohne Lifecycle-Planung“ verwechselt werden. Kapazität, Performance, Support, technische Abhängigkeiten und zukünftige Anforderungen müssen weiterhin regelmäßig bewertet werden.
FlashArray ist besonders dann sinnvoll, wenn mehrere Anforderungen gleichzeitig auftreten.
Typische Indikatoren sind:
| Anforderung | Relevanz für FlashArray |
| dauerhaft niedrige Storage-Latenz | hoch |
| viele parallele I/O-Operationen | hoch |
| geschäftskritische Datenbanken | hoch |
| große Virtualisierungsumgebung | häufig hoch |
| SAP HANA | abhängig von zertifizierter Konfiguration |
| VDI mit ausgeprägten Lastspitzen | häufig hoch |
| persistente, performancekritische Container | abhängig vom Workload |
| Konsolidierung mehrerer kritischer Workloads | hoch |
| hohe Anforderungen an Verfügbarkeit | hoch |
| schnelle Snapshot-basierte Recovery | hoch |
| Schutz von Recovery-Punkten gegen Manipulation | relevant |
| selten genutzte Daten ohne Performancebedarf | eher gering |
All-Flash Storage ist dagegen nicht automatisch die wirtschaftlich sinnvollste Lösung, wenn Daten nur selten gelesen werden, geringe I/O-Anforderungen bestehen oder hauptsächlich große Datenmengen möglichst kosteneffizient gespeichert werden sollen. Allerdings ist auch hier eine differenzierte Betrachtung notwendig. Die FlashArray-Familie umfasst inzwischen nicht nur Systeme für maximale Performance. FlashArray//C und FlashArray//E adressieren beispielsweise stärker kapazitätsorientierte Einsatzgebiete. Die eigentliche Entscheidung lautet deshalb nicht mehr ausschließlich „Flash oder Disk?“. Sie lautet zunehmend: Welche Storage-Klasse erfüllt die Anforderungen des jeweiligen Datenbestands wirtschaftlich und technisch?
Die Planung sollte mit den Anwendungen beginnen und nicht mit einem bestimmten Storage-Modell. Als Concat unterstützen wir Sie deshalb zunächst dabei, die bestehende Infrastruktur und die Anforderungen Ihrer Workloads zu erfassen.
Eine belastbare Planung umfasst typischerweise folgende Schritte:
Gerade bei geschäftskritischen Workloads sollte das Sizing nicht ausschließlich anhand der vorhandenen Terabyte erfolgen. Ein Unternehmen mit 50 TB hochtransaktionalen Daten kann andere Anforderungen haben als ein Unternehmen mit mehreren hundert Terabyte wenig aktiver Daten. Kapazität ist deshalb nur eine Dimension der Storage-Planung.
Als Concat betrachten wir Storage im Zusammenhang mit Anwendungen, Servern, Virtualisierung, Netzwerk, Datensicherung und Betriebsmodell. So lässt sich beurteilen, wo FlashArray einen technischen oder betrieblichen Vorteil bietet und wo eine andere Storage-Klasse sinnvoller ist.
All-Flash Storage ist besonders dort sinnvoll, wo Storage unmittelbar die Performance oder Verfügbarkeit geschäftskritischer Anwendungen beeinflusst.
Für die Entscheidung reichen Kapazität und maximale IOPS-Werte jedoch nicht aus. Latenz, Durchsatz, Lastprofile, RTO, RPO, Datenwachstum, Datenreduktion und Recovery-Anforderungen müssen gemeinsam betrachtet werden.
Everpure FlashArray deckt innerhalb einer Produktfamilie unterschiedliche Performance- und Kapazitätsanforderungen ab. Funktionen wie Datenreduktion, ActiveCluster, SafeMode Snapshots und die Evergreen-Architektur erweitern die Betrachtung über reine Storage-Performance hinaus.
Ob FlashArray für eine konkrete Umgebung sinnvoll ist, sollte deshalb anhand realer Workloads und klar definierter Service Levels entschieden werden.
All-Flash Storage ist eine Storage-Architektur, die Daten vollständig auf Flash-Speicher statt auf rotierenden Festplatten speichert. Im Enterprise-Umfeld kommen zusätzlich Funktionen wie Snapshots, Replikation, Datenreduktion und Hochverfügbarkeit hinzu.
Ein Unternehmen benötigt All-Flash Storage vor allem bei Anwendungen mit hohen Anforderungen an Latenz, IOPS, Durchsatz oder Verfügbarkeit. Typische Einsatzgebiete sind Datenbanken, große Virtualisierungsumgebungen, SAP HANA, VDI und andere I/O-intensive Anwendungen.
FlashArray ist die All-Flash-Storage-Produktfamilie von Everpure, dem seit Februar 2026 unter diesem Namen firmierenden früheren Pure Storage. Die Produktfamilie umfasst Systeme für unterschiedliche Anforderungen an Performance, Kapazität und Skalierung.
FlashArray kann für SAP HANA eingesetzt werden, sofern die jeweilige Konfiguration die aktuellen SAP-Anforderungen erfüllt. SAP verweist für produktive Systeme auf zertifizierte beziehungsweise unterstützte Hardware und das SAP HANA Hardware Directory. Die konkrete Konfiguration muss daher vor der Implementierung geprüft werden.
FlashArray unterstützt VMware-vSphere-Umgebungen und kann unter anderem über Fibre Channel, iSCSI, NFS, NVMe-oF und VMware vVols eingebunden werden. Welche Anbindung sinnvoll ist, hängt von der vorhandenen Infrastruktur und dem jeweiligen Architekturkonzept ab.
Deduplizierung und Kompression reduzieren die physisch benötigte Speicherkapazität. Die tatsächlich erreichbare Datenreduktion hängt jedoch vom Datenbestand ab. Bereits komprimierte oder verschlüsselte Daten lassen sich typischerweise schlechter reduzieren.
FlashArray verhindert keine Ransomware-Infektion. SafeMode Snapshots können jedoch geschützte Wiederherstellungspunkte bereitstellen und damit die Recovery-Strategie unterstützen. Sie sollten Teil eines mehrstufigen Cyber-Resilience- und Backup-Konzepts sein
FlashArray ist nicht automatisch die beste Wahl, wenn ein Workload geringe Performance- und Verfügbarkeitsanforderungen hat oder ausschließlich sehr kostengünstige Kapazität benötigt wird. Entscheidend ist eine Bewertung von Performance, Kapazität, Verfügbarkeit, Recovery, Wachstum und Gesamtkosten.
Sie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie müssen den Inhalt von Turnstile laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr Informationen