DataCore SANsymphony auf Supermicro-Servern – Software-defined Storage

Was ist Software-defined Storage mit DataCore SANsymphony?

Bei Software-defined Storage (SDS) werden zentrale Speicherfunktionen durch Software bereitgestellt und von der zugrunde liegenden Speicherhardware weitgehend entkoppelt.

DataCore SANsymphony virtualisiert Blockspeicher, der aus internen Serverlaufwerken, externen Storage-Systemen oder einer Kombination verschiedener Speicherressourcen stammen kann. Die Software stellt daraus virtuelle Datenträger für angeschlossene Hosts bereit.

Ein wesentlicher Vorteil ist, dass vorhandene Speichersysteme verschiedener Hersteller unter einer gemeinsamen Virtualisierungsschicht verwaltet werden können. Dadurch können Hardwarewechsel, Datenmigrationen und Erweiterungen vereinfacht werden.

Drei typische Bereitstellungsvarianten

1. Neuer Storage-Server mit internen Laufwerken:
SANsymphony wird auf einem geeigneten x86-64-Server installiert. Die internen Laufwerke bilden die Speicherbasis. Der Server stellt die virtuellen Datenträger beispielsweise über iSCSI oder Fibre Channel bereit.

Diese Variante eignet sich für Umgebungen, in denen ein dedizierter Storage-Server ausreicht. Bei nur einem Server ist dessen Ausfall allerdings ein Single Point of Failure.

2. Virtualisierung vorhandener Storage-Systeme:
Bereits eingesetzte Speicherarrays verschiedener Hersteller werden über geeignete Schnittstellen an SANsymphony angebunden. Die DataCore-Server übernehmen die Virtualisierung und stellen die Speicherressourcen an die Hosts bereit.

So können beispielsweise Daten von einem alten auf ein neues Array migriert werden, ohne dass die Hosts zwingend direkt auf das neue Storage-System umgestellt werden müssen. Voraussetzung ist eine passende Architektur mit kompatiblen Komponenten.

3. Hyperkonvergente Bereitstellung (HCI):
In einer entsprechend unterstützten Virtualisierungsumgebung können die Storage-Dienste in virtuellen Maschinen betrieben werden. Dabei werden lokale Speicherressourcen der Virtualisierungshosts eingebunden.

Diese Lösung kann beispielsweise für Außenstellen und kleinere Installationen sinnvoll sein. Die konkrete Implementierung hängt von den unterstützten Hypervisoren und den jeweiligen Lizenz- und Hardwarevoraussetzungen ab.

Konfigurationen von DataCore SANsymphony

Einzelner SANsymphony-Server

In der einfachsten Konfiguration läuft SANsymphony auf einem einzelnen Server. Die Daten können auf internen Laufwerken oder extern angeschlossenem Storage liegen. Der Server stellt die virtuellen Datenträger über das gewählte Block-Storage-Protokoll bereit.

RAM kann als schneller Cache eingesetzt werden. Das verbessert bei geeigneten Zugriffsmustern die I/O-Leistung. Die tatsächliche Wirkung hängt unter anderem von Datenzugriffen, Cache-Größe und Backend-Performance ab.

Eine redundante Host-Anbindung über mehrere Netzwerk- oder Fibre-Channel-Pfade kann einzelne Verbindungsfehler abfangen. Sie beseitigt aber nicht den einzelnen Storage-Server als Ausfallpunkt.

Hochverfügbarer SANsymphony-Cluster

Für höhere Verfügbarkeit lassen sich zwei SANsymphony-Server mit synchroner Spiegelung konfigurieren. Schreibvorgänge werden dabei auf die beteiligten Speicherkopien abgestimmt, bevor sie gemäß dem konfigurierten Verfahren bestätigt werden.

Fällt ein Storage-Server aus, kann der verbleibende Server die virtuellen Datenträger weiterhin bereitstellen. Dafür müssen die Hosts geeignete redundante Verbindungen und korrekt konfiguriertes Multipathing besitzen.

Auch das Quorum beziehungsweise der Schutz vor Split-Brain-Situationen muss berücksichtigt werden. Es muss verhindert werden, dass beide Seiten eines getrennten Clusters gleichzeitig widersprüchliche Schreibzugriffe zulassen.

Synchrone Spiegelung kann über geeignete Fibre-Channel- oder iSCSI-Verbindungen realisiert werden. Entscheidend sind vor allem stabile Latenzen, ausreichende Bandbreite, Redundanz und eine zur Anwendung passende Architektur.

Fibre Channel bietet häufig gut kontrollierbare Storage-Fabrics. Ein sorgfältig geplantes Ethernet-Netzwerk kann für iSCSI jedoch ebenfalls eine geeignete Lösung sein. Die Wahl sollte nicht allein anhand des Protokolls erfolgen.

Storage-Virtualisierung mit externen Arrays

Eine weitere Konfiguration verwendet SANsymphony als Virtualisierungsschicht vor externen Storage-Systemen. Die Arrays stellen Speicher an die DataCore-Server bereit, die daraus virtuelle Datenträger für die Hosts erzeugen.

So lassen sich beispielsweise Arrays von Dell, Fujitsu, HPE, IBM, NetApp oder anderen Herstellern in eine gemeinsame Umgebung integrieren, sofern die eingesetzten Modelle und Schnittstellen unterstützt werden.

SANsymphony kann Speicherressourcen verschiedener Hersteller nutzen und synchron zwischen geeigneten Backend- Speichersystemen spiegeln. Damit lassen sich zusätzliche Verfügbarkeitsfunktionen bereitstellen, die nicht von einer gemeinsamen Produktfamilie der Arrays abhängen.

Auch Datenmigrationen zwischen unterschiedlichen Storage-Systemen sind möglich. Bei korrekt geplanter Virtualisierung kann der Zugriffspfad der Hosts dabei unverändert bleiben.

Die maximal erreichbare Performance hängt von den Storage-Servern, Host-Verbindungen, Backend-Arrays, Controllern und den jeweiligen I/O-Mustern ab. Durch eine zusätzliche Virtualisierungsschicht entsteht außerdem ein weiterer Bestandteil, der überwacht und betrieben werden muss.

Einsatzbereiche und Datendienste von DataCore SANsymphony

SANsymphony kann zur Konsolidierung vorhandener Speicherressourcen, für hochverfügbaren Blockspeicher, zur Datenmigration und für die Bereitstellung zentraler Datendienste eingesetzt werden.

Synchrone Spiegelung und Hochverfügbarkeit

Bei der synchronen Spiegelung werden die Daten auf zwei geeigneten Speicherkopien konsistent gehalten. Dadurch kann bei bestimmten Ausfällen weiterhin auf eine verfügbare Kopie zugegriffen werden.

Eine solche Architektur kann auch über zwei räumlich getrennte Brandabschnitte oder nahe beieinander liegende Rechenzentrumsstandorte verteilt werden.

Die maximal geeignete Entfernung ist nicht pauschal festgelegt, sondern hängt unter anderem von Netzwerklatenz, Verbindungstechnik, Fehlerdomänen und Applikationsanforderungen ab.

Synchrone Spiegelung schützt jedoch nicht automatisch vor versehentlichem Löschen, logischer Datenkorruption oder Ransomware. Solche Veränderungen können auf beide Kopien übertragen werden.

Asynchrone Replikation und Disaster Recovery

Bei der asynchronen Replikation werden Datenänderungen zeitversetzt an ein weiteres System oder einen entfernten Standort übertragen. Dadurch eignen sich auch Verbindungen, bei denen die Latenz für eine synchrone Spiegelung zu hoch ist.

Da der Zielstand nicht zwingend dem aktuellen Stand des Quellsystems entspricht, muss bei einem Katastrophenfall mit einem möglichen Datenverlust gerechnet werden.

Der maximal akzeptable Datenverlust wird über das Recovery Point Objective (RPO) beschrieben. Die angestrebte Wiederanlaufzeit ist das Recovery Time Objective (RTO).

Beide Werte müssen aus den Geschäftsanforderungen abgeleitet, technisch geplant und durch Wiederanlauftests überprüft werden. Replikation allein garantiert keinen sofortigen Wiederanlauf aller Anwendungen.

Snapshots und Continuous Data Protection

Snapshots halten den Zustand virtueller Datenträger zu einem bestimmten Zeitpunkt fest. Sie können zur schnellen Wiederherstellung eines früheren Datenzustands eingesetzt werden.

Beispiele sind die Absicherung vor einem Software-Upgrade oder das Zurücksetzen einer fehlerhaften Änderung.

Für konsistente Sicherungen laufender Anwendungen oder Datenbanken sind gegebenenfalls zusätzliche Maßnahmen zur Applikationskonsistenz notwendig.

Continuous Data Protection kann weitere Wiederherstellungspunkte bereitstellen. Die Möglichkeiten hängen von der Konfiguration, der Aufbewahrung und den verfügbaren Ressourcen ab.

Wichtig: Weder Snapshots noch synchrone Spiegelung ersetzen ein unabhängiges Backup.

Adaptives Caching

SANsymphony kann den Arbeitsspeicher des Storage-Servers zum Caching verwenden. RAM besitzt eine geringe Zugriffslatenz und kann häufig benötigte Daten beschleunigt bereitstellen.

Die Wirksamkeit ist abhängig vom Verhältnis zwischen Cache-Größe und aktivem Datenbestand, vom Zugriffsmuster und von der Backend-Performance.

Gerade bei zufälligen Zugriffen und wiederholt gelesenen Daten kann ein ausreichend dimensionierter Cache Vorteile bieten. Bei überwiegend sequenziellen Workloads oder sehr großen wechselnden Datenbeständen kann der Nutzen geringer sein.

Auto-Tiering

Beim automatischen Tiering werden Speicherressourcen verschiedener Leistungsklassen zu einem Pool zusammengefasst.

Häufig verwendete Datenbereiche können auf schnelle Medien, beispielsweise SSDs, verschoben werden. Selten benötigte Datenbereiche lassen sich auf kapazitätsoptimierten Medien speichern.

Die Einordnung erfolgt anhand der unterstützten Analyse- und Platzierungsmechanismen. Ziel ist es, schnelle Speicherklassen dort zu nutzen, wo sie den größten Nutzen bringen.

Wie stark Tiering die Kosten und Performance beeinflusst, hängt vom Datenbestand, den Zugriffsmustern und den verfügbaren Medien ab.

Thin Provisioning

Mit Thin Provisioning kann einem Host eine virtuelle Speicherkapazität bereitgestellt werden, ohne dass diese vollständig auf physischen Datenträgern reserviert wird.

Beispielsweise kann eine virtuelle LUN mit 10 TB präsentiert werden, obwohl anfangs nur ein kleiner Teil davon physisch belegt ist. Die benötigte Kapazität wächst mit dem tatsächlich genutzten Datenbestand.

Die Speicherauslastung muss kontinuierlich überwacht werden. Sind physische Pools vollständig belegt, können Schreibfehler und Anwendungsausfälle auftreten.

Zusätzlich sind die Unterstützung von Space-Reclamation-Funktionen, beispielsweise UNMAP, und das Verhalten der angebundenen Hosts zu beachten.

Deduplizierung und Komprimierung

Deduplizierung erkennt identische Datenbereiche und kann deren mehrfache physische Speicherung vermeiden. Komprimierung reduziert die Datenmenge durch geeignete Kodierungsverfahren.

Besonders ähnliche Datenbestände, etwa wiederholt gespeicherte Betriebssystemabbilder, können von Deduplizierung profitieren.

Bereits komprimierte oder verschlüsselte Daten lassen sich häufig nur eingeschränkt weiter reduzieren. Auch die Größe der Datenblöcke, das Änderungsverhalten und das jeweilige Verfahren beeinflussen die erzielbare Einsparung.

Beide Funktionen benötigen Rechen- und Speicherressourcen. Ob sie für Datenbanken, virtuelle Maschinen oder andere Workloads sinnvoll sind, sollte anhand von Messwerten geprüft werden.

Storage-Pooling und Datenmigration

SANsymphony kann geeignete physische Speicherressourcen zu logischen Pools zusammenfassen. Das erleichtert die Bereitstellung virtueller Datenträger und die Kapazitätsverwaltung.

Bei einer Hardwareerneuerung können Daten zwischen unterschiedlichen Backend-Systemen migriert werden. Damit lässt sich der Austausch vorhandener Speichersysteme vereinfachen.

Ob eine Migration ohne Anwendungsunterbrechung möglich ist, hängt von der konkreten Konfiguration und den erforderlichen Umstellungsschritten ab.

Vorteile, Grenzen und Alternativen zu SANsymphony

Welche Vorteile bietet die Storage-Virtualisierung?

Eine softwarebasierte Virtualisierungsschicht kann unterschiedliche Speichersysteme gemeinsam verwalten und einheitliche Datendienste bereitstellen.

Das kann insbesondere bei heterogenen Storage-Umgebungen, Storage-Migrationen und Anforderungen an herstellerübergreifende Hochverfügbarkeit sinnvoll sein.

Welche Grenzen gibt es?

Die zusätzliche Software- und Serverschicht erhöht die Anforderungen an Architektur, Lizenzierung, Monitoring und Betrieb.

Auch Host-Kompatibilität, Redundanz und ein durchdachtes Multipathing müssen berücksichtigt werden. Ein nicht redundant aufgebauter Virtualisierungsserver kann selbst zum Single Point of Failure werden.

Welche Alternativen kommen infrage?

Abhängig von den Anforderungen können auch klassische SAN-Arrays mit eigenen Hochverfügbarkeitsfunktionen, softwaredefinierte Clusterlösungen oder hyperkonvergente Storage-Architekturen geeignete Alternativen sein.

Entscheidend sind Verfügbarkeitsanforderungen, vorhandene Hardware, Performance, Support, Betriebsaufwand und Gesamtkosten.

Erweiterungsmöglichkeiten einer SANsymphony-Lösung

Eine SANsymphony-Umgebung kann von einem einzelnen Storage-Server ausgehend erweitert werden. Je nach Lizenzedition und unterstützter Architektur lassen sich zusätzliche Server, Speichersysteme und Kapazitäten einbinden.

Interner Speicher kann durch zusätzliche Laufwerke oder geeignete externe Storage-Systeme ergänzt beziehungsweise ersetzt werden. Auch ein Herstellerwechsel im Backend kann über Datenmigrationen erfolgen.

Die Hosts greifen in einer solchen Architektur auf die virtuellen Datenträger von SANsymphony zu und müssen nicht jedes zugrunde liegende Speichersystem direkt kennen.

Dadurch kann der Austausch einer Backend-Plattform vereinfacht werden. Voraussetzung ist eine durchgehend kompatible und ausreichend redundante Infrastruktur.

Stor IT Back unterstützt bei der Auswahl einer geeigneten Serverplattform, der Dimensionierung, der Planung der Speicheranbindung und der gewünschten Verfügbarkeitsarchitektur.

Im Preis enthaltene Dienstleistungen

Alle DataCore SANsymphony Lösungen werden von uns nach Ihrem Wunsch vorkonfiguriert, die neuste Firmware auf der Hardware ist installiert und Grundeinstellungen sind vorgenommen. Im Falle von DataCore-Systemen sind die Festplatten in den Einschubrahmen verschraubt, der Transport der Festplatten erfolgt aus Sicherheitsgründen nicht im Grundgerät eingebaut, sondern in dafür vorgesehenen Transportvorrichtungen. Sie müssen die Festplatten nur noch ins Grundgerät einschieben. Alle Komponenten sind eindeutig bezeichnet.
Jedes SANsymphony System wird vor der Auslieferung einem mindestens 24-Stunden-Dauertest unterzogen. Hierbei werden die Festplatten zweimal komplett beschrieben, der sogenannte DOA (Dead On Arrival, Gerät kommt schon defekt an) kann nahezu vermieden werden. Eine detaillierte Beschreibung der im Preis enthaltenen Dienstleistungen finden Sie hier.