Eine neue Storage-Architektur sollte nicht mit der Auswahl eines Storage-Systems beginnen. Entscheidend sind zunächst die Anforderungen der Anwendungen und Daten.
Unternehmen sollten ihre Storage-Architektur überprüfen, wenn die bestehende Umgebung technische, wirtschaftliche oder betriebliche Anforderungen nicht mehr zuverlässig erfüllt. Ein Hardware-Refresh ist dafür nur ein möglicher Anlass. Auch neue Anwendungen, steigende Datenmengen oder veränderte Anforderungen an Verfügbarkeit und Wiederherstellung können eine Neubewertung erforderlich machen.
Typische Auslöser sind:
Die entscheidende Frage lautet deshalb nicht nur: Ist unser Storage alt? Wichtiger ist: Passt unsere Storage-Architektur noch zu den aktuellen und absehbaren Anforderungen des Unternehmens?
Eine Storage-Planung benötigt belastbare Messwerte aus der bestehenden Umgebung. Reine Kapazitätsangaben reichen dafür nicht aus. Wir betrachten bei einer Bestandsanalyse insbesondere Kapazität, IOPS, Durchsatz, Latenz, Datenwachstum und Verfügbarkeitsanforderungen.
Kapazität: Wie viele Daten müssen tatsächlich gespeichert werden?
Zunächst muss zwischen vorhandener, belegter und tatsächlich benötigter Kapazität unterschieden werden.
Relevant sind beispielsweise:
Gerade bei Systemen mit Deduplizierung und Kompression darf die physisch belegte Kapazität nicht isoliert betrachtet werden. Auch bei Everpure FlashArray wird die effektive Kapazität unter Berücksichtigung von Datenreduktion betrachtet. Dazu gehören unter anderem Inline-Deduplizierung, Kompression und Pattern Removal. Die tatsächlich erreichbare Datenreduktion hängt vom jeweiligen Datenbestand ab.
IOPS: Wie viele Storage-Operationen entstehen?
IOPS steht für „Input/Output Operations per Second“. Der Wert beschreibt, wie viele Ein- und Ausgabeoperationen ein Storage-System pro Sekunde verarbeitet. Ein Durchschnittswert allein reicht für die Planung jedoch nicht aus.
Interessanter sind:
Eine Umgebung mit kurzen, hohen Lastspitzen muss anders dimensioniert werden als ein System mit gleichmäßiger Belastung.
Latenz: Wie schnell reagiert der Storage?
Latenz beschreibt vereinfacht die Zeit zwischen einer Storage-Anfrage und ihrer Verarbeitung. Besonders relevant ist sie für transaktionsorientierte Anwendungen und Datenbanken. Auch Virtualisierungsplattformen können empfindlich auf steigende Storage-Latenzen reagieren. Deshalb sollten nicht nur Durchschnittswerte betrachtet werden. Auch Spitzenwerte und die Latenz während hoher Last sind relevant.
Datenwachstum: Wie entwickelt sich die Umgebung?
Die heutige Kapazität beschreibt nur den Ausgangspunkt. Für die Planung sollte deshalb die historische Entwicklung betrachtet werden. Daraus lassen sich Szenarien für die kommenden Jahre ableiten. Dabei sollten auch geplante Veränderungen berücksichtigt werden. Ein neues Analytics-Projekt, zusätzliche virtuelle Maschinen oder neue Aufbewahrungsrichtlinien können das bisherige Wachstum deutlich verändern.
Verfügbarkeit: Welche Ausfälle sind akzeptabel?
Nicht jede Anwendung benötigt dieselbe Verfügbarkeit. Geschäftskritische Datenbanken können sehr hohe Anforderungen haben. Entwicklungsumgebungen oder Archive lassen häufig längere Unterbrechungen zu. Deshalb sollten Anwendungen bereits in der Analyse nach ihrer Kritikalität eingestuft werden.
Storage sollte nach den Anforderungen der Workloads geplant werden und nicht nur nach der Gesamtmenge der Daten. Dafür gruppieren wir Anwendungen nach ihren technischen und betrieblichen Anforderungen.
Datenbanken
Datenbanken benötigen häufig niedrige und möglichst konstante Latenzen. Gleichzeitig können hohe IOPS-Werte und ein hoher Durchsatz erforderlich sein.
Bei der Analyse betrachten wir deshalb beispielsweise:
Everpure positioniert insbesondere FlashArray//X und FlashArray//XL für geschäftskritische und performanceintensive Workloads. Zu den vom Hersteller genannten Einsatzbereichen gehören unter anderem Datenbanken und Workload-Konsolidierung.
VMware und andere Virtualisierungsplattformen
Virtualisierte Umgebungen bündeln viele unterschiedliche Anwendungen auf einer gemeinsamen Infrastruktur. Das kann zu stark schwankenden Storage-Lasten führen. Deshalb sollten nicht nur Anzahl und Größe der virtuellen Maschinen betrachtet werden. Wichtig sind auch:
Die FlashArray-Plattform ist bestens geeignet für Virtualisierung.
SAP
Bei SAP-Umgebungen muss die Storage-Planung eng an der eingesetzten Plattform und Datenbank ausgerichtet werden. Entscheidend sind unter anderem Performance, Verfügbarkeit, Backup, Recovery und die konkrete Systemarchitektur. Ein Storage-Projekt für SAP sollte deshalb nicht isoliert geplant werden. Datenbank, Compute, Netzwerk, Backup und Storage müssen gemeinsam betrachtet werden.
Kubernetes
Container-Plattformen verändern die Anforderungen an Storage. Container selbst können kurzlebig sein. Persistente Anwendungsdaten müssen dagegen dauerhaft gespeichert und zuverlässig bereitgestellt werden. Bei Kubernetes-Projekten sollten deshalb unter anderem folgende Fragen beantwortet werden:
Backup
Backup-Storage wird häufig primär anhand der Kapazität bewertet. Für die Wiederherstellung ist jedoch auch die Performance entscheidend. Das gilt besonders nach größeren Störungen oder Cyberangriffen. Dann müssen unter Umständen große Datenmengen innerhalb kurzer Zeit wieder verfügbar sein. Deshalb sollte die Planung sowohl das Backup-Fenster als auch das Restore-Fenster berücksichtigen.
AI und Analytics
AI- und Analytics-Workloads können hohe Anforderungen an Durchsatz, Skalierbarkeit und den parallelen Zugriff auf große Datenbestände stellen. Nicht jeder AI-Workload benötigt jedoch dieselbe Storage-Architektur. Training, Inferenz, Retrieval-Augmented Generation, Analytics und Datenaufbereitung erzeugen unterschiedliche Zugriffsmuster.
Deshalb sollte zunächst das konkrete Daten- und I/O-Profil untersucht werden. Innerhalb des Everpure-Portfolios stehen neben FlashArray auch Plattformen für große Datei- und Objekt-Workloads zur Verfügung. Everpure positioniert beispielsweise FlashBlade für unstrukturierte Daten sowie AI- und Analytics-Anforderungen.
RPO und RTO legen fest, wie viel Datenverlust und Ausfallzeit ein Unternehmen im Störungsfall akzeptieren kann.
RPO – Recovery Point Objective beschreibt, bis zu welchem Datenstand eine Wiederherstellung möglich sein muss.
Ein RPO von 30 Minuten bedeutet beispielsweise, dass im definierten Störungsfall höchstens die Änderungen seit dem letzten Wiederherstellungspunkt innerhalb dieses Zeitfensters verloren gehen dürfen.
RTO – Recovery Time Objective beschreibt dagegen, innerhalb welcher Zeit ein Dienst nach einer Störung wiederhergestellt sein soll.
Beide Werte sollten pro Anwendung oder Service definiert werden.
Eine mögliche Klassifizierung ist:
| Kritikalität | RPO | RTO | Beispiel |
| sehr hoch | sehr geringer Datenverlust akzeptabel | sehr kurze Wiederherstellungszeit | zentrale Produktionsdatenbank |
| hoch | begrenzter Datenverlust akzeptabel | kurze Wiederherstellungszeit | wichtige Geschäftsanwendung |
| mittel | größerer Datenverlust tolerierbar | mehrere Stunden möglich | internes System |
| niedrig | längere Intervalle möglich | längere Wiederherstellung akzeptabel | Archiv oder Testsystem |
Die konkreten Werte müssen aus den Geschäftsanforderungen abgeleitet werden. Sie sollten nicht pauschal aus den technischen Möglichkeiten eines Storage-Systems entstehen.
Cyber-Resilience bedeutet, dass Daten und Anwendungen nicht nur geschützt, sondern nach einem Sicherheitsvorfall auch zuverlässig wiederhergestellt werden können. Das ist ein wichtiger Unterschied. Ein modernes Storage-Konzept sollte deshalb mehrere Ebenen berücksichtigen:
Welche Rolle spielen unveränderliche Snapshots?
Unveränderliche Snapshots können dabei helfen, Wiederherstellungspunkte vor nachträglicher Manipulation zu schützen.
Everpure bietet hierfür SafeMode Snapshots. Laut Hersteller können mit SafeMode geschützte Snapshots nicht gelöscht, verändert oder verschlüsselt werden. Dies gilt laut Everpure auch dann, wenn Administrator-Zugangsdaten kompromittiert wurden. SafeMode steht für FlashArray und FlashBlade zur Verfügung.
Wichtig ist jedoch: Eine solche Funktion verhindert keinen Cyberangriff. Unveränderliche Snapshots sind vielmehr ein Baustein für die Wiederherstellung nach einem Angriff. Storage-Sicherheit ersetzt deshalb weder Endpoint Security noch Netzwerksegmentierung, Identity Management, Monitoring oder eine belastbare Backup-Strategie.
Eine Storage-Architektur sollte nicht nur den heutigen Bedarf abdecken. Gleichzeitig ist eine großzügige Überdimensionierung nicht automatisch wirtschaftlich. Für die Planung benötigen wir daher mehrere Szenarien.
Neben der reinen Datenmenge sollte auch die Performanceentwicklung berücksichtigt werden. Mehr Kapazität bedeutet nicht zwangsläufig proportional mehr IOPS. Umgekehrt kann eine Anwendung deutlich mehr Performance benötigen, ohne dass ihr Datenbestand stark wächst. Kapazität und Performance sollten deshalb getrennt prognostiziert werden.
Unternehmen können Enterprise-Storage klassisch beschaffen oder als Service beziehen. Welches Modell besser passt, hängt von den finanziellen, technischen und organisatorischen Anforderungen ab. Beim klassischen Modell wird Storage beschafft und über einen definierten Zeitraum betrieben. Investitionszyklen, Reserven und Erweiterungen müssen entsprechend geplant werden. Storage-as-a-Service verschiebt den Ansatz stärker in Richtung laufender Nutzung und definierter Service-Level.
| Kriterium | Klassischer Kauf | Storage-as-a-Service |
| Finanzierung | Investition in Infrastruktur | laufendes Nutzungs- oder Servicemodell |
| Kapazitätsplanung | stärkere Vorabplanung | stärker verbrauchsorientiert |
| Hardware-Lifecycle | muss eingeplant werden | stärker Bestandteil des Services |
| Skalierung | Erweiterungen planen und beschaffen | abhängig vom Service flexibler |
| Betrieb | stärker beim Unternehmen | Aufgaben können teilweise auf den Anbieter verlagert werden |
| Kostenmodell | Investitions- und Betriebskosten | laufende Servicekosten |
Diese Gegenüberstellung beschreibt die grundsätzlichen Unterschiede. Die tatsächlichen Leistungen, Kosten und Verantwortlichkeiten hängen vom jeweiligen Vertrag ab.
Wo passt Everpure in eine solche Architektur?
Everpure kann unterschiedliche Rollen innerhalb einer Enterprise-Storage-Architektur übernehmen. Welche Plattform sinnvoll ist, hängt vom jeweiligen Workload ab. Deshalb sollte die Entscheidung nicht mit der Frage „Welches Everpure-System benötigen wir?“ beginnen. Die bessere Reihenfolge lautet:
Workload → Anforderungen → Service-Level → Architektur → Plattform
FlashArray für geschäftskritische Workloads
FlashArray ist die Storage-Plattform von Everpure für Block-, Datei- und Objekt-Storage. Innerhalb der Produktfamilie stehen unterschiedliche Systeme für verschiedene Performance- und Kapazitätsanforderungen zur Verfügung.
Dazu gehören unter anderem:
Welche Variante passt, sollte nicht allein anhand der benötigten Terabyte-Zahl entschieden werden. Entscheidend sind das I/O-Profil, die benötigte Kapazität, Latenzanforderungen, Verfügbarkeit, Datenwachstum und Recovery-Anforderungen.
Für Unternehmen, die Storage nicht ausschließlich klassisch beschaffen möchten, bietet Everpure mit Evergreen//One ein Storage-as-a-Service-Modell. Evergreen//One stellt die Everpure-Plattform als Service bereit. Das Angebot kombiniert ein nutzungsorientiertes Modell mit definierten Service-Level-Agreements. Je nach gewähltem Service unterscheiden sich unter anderem Performance, Kapazitätsanforderungen und weitere SLA-Bedingungen.
Das aktuelle Evergreen//One Product Guide definiert beispielsweise unterschiedliche Performance-Tiers für Unified Block and File sowie weitere Angebote für File und Object, Data Repository und AI. Für Unternehmen bedeutet das: Die Entscheidung zwischen klassischer Beschaffung und Evergreen//One sollte nicht allein anhand der monatlichen Kosten getroffen werden.
Relevant sind unter anderem:
Als Concat betrachten wir ein Storage-Projekt nicht erst bei der Produktauswahl. Wir unterstützen Sie dabei, aus den technischen und betrieblichen Anforderungen eine passende Zielarchitektur abzuleiten. Dazu betrachten wir bestehende Infrastruktur, Anwendungen, Datenwachstum, Performance, Verfügbarkeit, Recovery-Anforderungen und das gewünschte Betriebsmodell.
Ein möglicher Projektablauf umfasst folgende Schritte:
Everpure ist dabei nicht automatisch für jeden Workload die richtige Antwort. Entscheidend ist, ob Plattform, Architektur und Betriebsmodell zu Ihren Anforderungen passen. Genau deshalb steht am Anfang eines Storage-Projekts die Analyse und nicht die Produktauswahl.
Bevor Sie eine neue Storage-Architektur festlegen, sollten mindestens diese zehn Fragen beantwortet sein:
Sind diese Fragen belastbar beantwortet, lässt sich die Produktauswahl wesentlich zielgerichteter durchführen.
Eine belastbare Storage-Architektur entsteht aus den Anforderungen der Anwendungen und des Unternehmens. Die Auswahl eines konkreten Systems folgt erst danach.
Kapazität, IOPS und Latenz bilden die technische Basis. Workload-Kritikalität, Datenwachstum, RPO, RTO und Cyber-Resilience ergänzen diese Betrachtung. Anschließend kann entschieden werden, welche Plattform und welches Betriebsmodell die Anforderungen erfüllen.
Everpure bietet dafür unterschiedliche Ansätze. FlashArray adressiert verschiedene Enterprise-Workloads. Evergreen//One stellt die Everpure-Plattform als Storage-as-a-Service bereit.
Als Concat unterstützen wir Sie dabei, diese Möglichkeiten anhand Ihrer tatsächlichen Anforderungen zu bewerten und daraus eine passende Storage-Architektur abzuleiten.
Am Anfang sollten Kapazität, IOPS, Durchsatz, Latenz, Datenwachstum, Verfügbarkeit und die vorhandenen Workloads analysiert werden. Diese Werte bilden die Grundlage für die Dimensionierung und das Architekturdesign.
IOPS beschreiben die Anzahl der Ein- und Ausgabeoperationen, während die Latenz die Reaktionszeit des Storage beschreibt. Für eine belastbare Planung sollten Durchschnittswerte, Lastspitzen und das jeweilige I/O-Profil untersucht werden.
RPO und RTO bestimmen die Anforderungen an Wiederherstellung und Data Protection. Das RPO beschreibt den tolerierbaren Datenverlust in zeitlicher Hinsicht. Das RTO definiert, innerhalb welcher Zeit ein Dienst wiederhergestellt werden soll.
Cyber-Resilience sollte Snapshots, Backup, Replikation, unveränderliche Wiederherstellungspunkte, Zugriffsschutz und getestete Recovery-Prozesse kombinieren. Einzelne Storage-Funktionen ersetzen keine ganzheitliche Security- und Backup-Strategie.
SafeMode Snapshots sind geschützte, unveränderliche Snapshots. Laut Everpure können sie nicht gelöscht, verändert oder verschlüsselt werden, selbst wenn Administrator-Zugangsdaten kompromittiert wurden. SafeMode steht für FlashArray und FlashBlade zur Verfügung.
Everpure positioniert FlashArray unter anderem für Datenbanken, Virtualisierung, Workload-Konsolidierung, File-Workloads sowie Backup und Recovery. Innerhalb der FlashArray-Familie gibt es unterschiedliche Systeme für performance- und kapazitätsorientierte Anforderungen.
Evergreen//One ist das Storage-as-a-Service-Angebot von Everpure. Die Everpure-Plattform wird dabei als Service mit nutzungsorientiertem Modell und definierten Service-Level-Agreements bereitgestellt.
Storage-as-a-Service kann sinnvoll sein, wenn Kapazitätsbedarf schwer vorhersehbar ist, klassische Hardware-Refresh-Zyklen reduziert werden sollen oder ein stärker nutzungs- und SLA-orientiertes Betriebsmodell gewünscht ist. Ob das Modell wirtschaftlich passt, sollte anhand der konkreten Anforderungen und Vertragsbedingungen geprüft werden.
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