RawDR

Vorteile

  • Kostenlos für jegliche Verwendung (Privat und Kommerziell)
  • Basierend auf den zuverlässigsten Speichertechnologien
  • Benutzerfreundliche grafische Benutzeroberfläche für Setup und Administration
  • Echte Hochverfügbarkeit (HA)
  • Unabhängig von Hardware und Hypervisor
  • Beschleunigung von vorhandenem Speicher
  • Verwendung von lokalem Speicher im Hypervisor
  • Snapshots ohne Performanceverlust für asynchrone Replizierung an andere Standorte
  • Keine Einbahnstrasse, da Migrationen auf andere ZFS basierte Lösungen jederzeit möglich sind

Features

Die zuverlässigste und sicherste Platform zur Aufbewahrung und Bereitstellung von Daten. Bewährt im Enterprise Umfeld ist es in Performance und Kapazität skalierbar (www.open-zfs.org).

Der RawDR Softwarestack macht dies zur derzeit einzigen auf ZFS basierenden Lösung, die alle Enterprise Features kostenlos anbietet. Es bietet eine grafische Oberfläche (GUI) mit der man die virtuellen Appliances aufsetzen und administrieren kann. Es lässt sich HA aktivieren, es zeigt Probleme und Reparaturmöglichkeiten an und es lassen sich Reboot und Shutdown unter Beachtung der Abhängigkeiten durchführen (bspw. zur Vorbreitung für Wartungstasks beim Hypervisor).

Wird NFS zur Speicherung von virtuelle Maschinen verwendet, führt dies zu einem synchronen Datentransfer, d.h. jeder Schreibzugriff muss vom NFS-Server als «abgespeichert» bestätigt werden. ZFS ist ein transaktionales Dateisystem, dass Schreibzugriffe zu Transaktionsgruppen zusammengefasst. Um diesen Performancevorteil auch bei Sync-Writes zu ermöglichen, werden die Daten in einem sog. ZIL (ZFS Intent Log) abgelegt, dass sich entweder verteilt über alle Spiegel der vdevs oder in einem SLOG (Seperated LOG Device) befindet. Befindet sich das ZIL verteilt auf den vdevs kann dies die Performance deutlich verringern, befindet es sich dagegen auf einem lokalen SLOG würde man den jeweiligen Zpool nicht mehr ohne Datenverlust auf einem anderen Gerät starten können. RawDR kann die flüchtigen Daten im RAM eines anderen Knotens spiegeln und ermöglicht dadurch eine echte Hochverfügbarkeit (HA) ohne Anpassungen auf der Clientseite. Obwohl dieses Verhalten deutlich schneller als das Standardverhalten ist, kann der Transfermodus auch auf einen asynchronen geändert werden (nennt sich «Performance Mode» innerhalb von RawDR), um die maximale Geschwindigkeit zu erhalten. Bei einem Ausfall führt dies zum Verlust einiger Daten (einige Sekunden während die Integrität durch ZFS sichergestellt ist) wodurch ein anderer Knoten den Zpool nicht ohne Shutdown der dazugehörigen VMs übernehmen kann. Lässt man die VMs zusammen mit dem Zpool auf dem gleichen Hypervisor laufen, erhält man die maximale Performance während ein Ausfall des Hypervisors neben dem NFS-Share auch die darauf befindlichen VMs betrifft. Die VMs müssen danach ohnehin neu gestartet werden (entweder auf dem reparierten Hypervisor oder auf einem anderen Hypervisor zusammen mit dem Zpool) und führen eine Konsistenzprüfung ihrer Dateisysteme durch, was heutzutage alle gängigen Dateisysteme können. Dies entspricht dem Zustand eines Online Snapshots.

Zudem haben wir einen «PathChecker» entwickelt, der kontinuierlich die Qualität jedes einzelnen Pfads der Disks prüft. Wird ein Ausfall oder eine schlechte Qualität erkannt (bspw. wenn eine Disk langsam kaputt geht), wird der Pfad oder die ganze Disks aus dem System entfernt, wodurch die Performance sichergestellt ist. Dieser Prozess findet innerhalb weniger Sekunden statt, wodurch die VMs weiterlaufen. Da der «PathChecker» die Latenz in Echtzeit überprüft, können diese Werte auch von Monitoringsysteme ausgewertet werden.

Bei RawDR werden die Daten immer mindestens auf 2 unabhängige Storage Backends geschrieben. Da sich diese Backends in unterschiedlichen Datacenter befinden können, kann man implizit eine "standortübergreifende synchrone Datenreplikation" erhalten.

Im Downloadbereich befindet sich unter Addons ein Script mit dem man volle und inkrementelle Snapshots auf einen Netzwerkshare durchführen kann. Da ZFS ein transaktionales Dateisystem ist, haben Snapshots keinen Performancenachteil (Im Gegensatz zu Copy-on-Write Dateisystemen, die von den meisten Hypervisor genutzt werden). Auf der Roadmap befindet sich zudem ein Feature namens "Warehouse", das ein fortgeschrittenes Snapshot Management ermöglicht. Hiermit werden u.a. automatisch inkrementelle Snapshots erstellt, diese auf einem separaten ZFS-basiertem System eingespielt und entsprechender konfigurierter Policy vorgehalten bzw. gelöscht. Hierdurch wird implizit die Konsistenz der ausgelagerten Snapshots geprüft und es kann ein Point in Time Recovery erfolgen, mit dessen Hilfe man bspw. die gewünschte VHD Datei in das Originalsystem umkopieren kann.

RawDR kann auf jedem Hypervisor bereitgestellt werden. Es können verschiedene Hypervisors parallel verwendet werden, zum Beispiel VMware und XenServer. KVM wird demnächst verfügbar sein.

Da die vDisk als Dateien per NFS bereitgestellt werden, bietet RawDR implizit Thin-Provisioning. Zudem bietet ZFS mit dem LZ4-Algorithmus eine Echtzeitkompression. Neben der Platzersparnis und der Entlastung der Backends ist dies die Voraussetzung für die Speicherfreigabe durch das Schreiben von "Nullen" innerhalb des Dateisystems der VM.

Alle Schreibzugriffe werden mit einer Prüfsumme abgesichert, wodurch ein maximaler Schutz gegenüber "Silent Data Corruption" oder auch "Bit Rot" gewährleistet wird. Mit der zunehmenden Speicherdichte von Festplatten und dem Einsatz von NAND-Flashspeicher erhalten die Prüfsummen eine immer grössere Bedeutung. Hierzu gibt es mehrere Langzeitstudien von Google und Facebook die von BER (Bit Error Rate) und Silent Data Corruption handeln. Zusammengefasst spielt man mit seinen Daten "Russisch Roulette" wenn die Storagelösung keine Prüfsummen verwendet. Die folgende Artikel liefern mehr Informationen hierzu:

Durch den Einsatz von ZFS entfällt die Notwendigkeit von teuren All-Flash-Lösungen, da günstige NVMe Module für unter 0.40USD/Gigabyte genutzt werden können. Während man diese günstigen Module niemals als Backendspeicher verwenden sollte, eignen sich diese perfekt als Lesecache. Das IO-Zugriffsmuster zeigt einen Mix aus verteilten Lesezugriffen und sequentiellen Schreibzugriffen, daher optimal in Bezug auf die Performance und Langlebigkeit von Flash-Speicher, zumal die Daten komprimiert innerhalb des mehrstufigen Cache abgelegt werden. ZFS kennt zudem zwei Cachebereiche, den LRU (least recently used) und den MFU (most frequently used).

Da es sich bei ZFS um ein transaktionales Dateisystem handelt, werden verteilte Schreibzugriffe in Transaktionsgruppen zusammengefasst und als sequenzieller Datenstrom auf das Storage Backend geschrieben. Durch den effizienten Read-Cache finden kaum Lesezugriffe auf das Speicherbackend statt.

Die meisten Installationen haben ein RAID1 mit mehreren 100GB an Festplattenkapazität. Während der Hypervisor unter 50GB benötigt, bleibt bereits hiermit genügend Kapazität übrig, um mittels RawDR einen hochverfügbare und performante NFS-Speicherlösung ohne Hard- und Softwarekosten aufzubauen.

Mit RawDR kann sogar ein lokales Hardware-RAID5 oder TLC-basierte Enterprise SSD (wie die Samsung SM/PM863a) verwendet werden. Grundsätzlich sollte ein lokales Hardware-RAID, insbesondere RAID5 oder RAID6 niemals in Verbindung mit ZFS eingesetzt werden, da die Self-Healing Funktionalität von RawDR nicht mehr funktionieren würde. Silent Data Corruption würde zwar erkannt werden, könnte jedoch nicht mehr behoben werden. Da RawDR die Backend Devices (wie bspw. RAID5 Volumes) immer mindestens 1 Mal spiegelt, trifft diese Limitierung hier nicht zu. Dadurch können weiterhin die Hardware-Replacement Features der RAID-Controller genutzt werden. Während sich RAID5 wegen der schlechten Random-Write Leistung normalerweise überhaupt nicht für VMs, vor allem VDIs eignet (macht 80% der IO-Last aus), kompensiert das transaktionale Dateisystem ZFS dieses Problem durch die Gruppierung in einen sequentiellen Datenstrom. Hier kann RAID5 dann seine Stärken ausspielen.

Falls ein lokales Hardware RAID zu kostspielig sein sollte, bieten sich auch lokale SATA Enterprise SSDs an. Die einzige Voraussetzung, diese als Backendspeicher nutzen zu können, stellt die Power-Loss-Protection dar. Die folgenden Studien zeigen, dass sich SSD Defekte komplett anders abspielen als Festplattenausfälle. Die Studien sollten sorgsam durchgelesen werden, um zu verstehen, weshalb man «Russisch Roulette» mit seinen Daten spielt, wenn man einfach nur klassische RAID-Lösungen mit SSDs kombiniert, die keine Prüfsummen verwenden. Daher vertreten wir den Standpunkt: Besser man verwendet TLC-SSDs mit ZFS statt SLC-SSDs mit konventionellem RAID. Mittlerweile gibt es die Enterprise TLC-SSDs mit einger Grösse von bis zu 4TB für unter 0.50$/GB.
Unter dem Schutz von ZFS vermeiden Sie folgende Risiken:

 

RawDR bietet eine echte HA-Lösung und die Möglichkeit einer Online Migration der NFS Shares zwischen den Nodes. Es entstehen keine Downtimes der Shares durch Firmware Upgrades oder durch den Austausch von Nodes.

Roadmap

Planned new features

Auto-Actions
Autorefresh, Autoconnect and Autosave instead of current manual way
Changelog Version 2.3.6
Multi-User Unterstützung

Unterstützung von parallelem Zugriff der GUI aus unterschiedlichen Instanzen auf den selben RawDR Storage Layer

Performancedaten

Anzeige von Echtzeit- und historischen Performancedaten, sowie Möglichkeit zur Email -Alarmierung

Warehouse

GUI-basierte Snapshot Verwaltung (derzeit über Command Line möglich)

Unterstützung von CIFS mit AD-Integration

Unterstützung vom CIFS-Protokoll auf Dataset-Ebene mit echter Hochverfügbarkeit (HA) und Integration in Active-Directory

Link-Checker

Erweiterung von LAGG durch einen LinkChecker (vergleichbar mit dem implementierten PathChecker) um mit dem unterschiedlichen Verhalten der NIC Treiber umzugehen (bspw. bei SR-IOV)

Unterstützung von SR-IOV

Unterstützung von SR-IOV innerhalb der RawDR GUI (derzeit verfügbar über die Kommandozeile)

Hypervisor Erweiterung

Erweiterung des Wartungsmodus durch Gruppierung der Knoten in Abhängigkeitsgruppen (bspw. Gruppierung in Hypervisor, Pool/Cluster oder Datacenter)

Hypervisor Integration

RawDR Integration mit Hypervisor, um PCI-Passthrough und SR-IOV über die RawDR GUI zu ermgölichen (derzeit über Kommandozeile verfügbar)

Unterstützung von automatischer Reparatur

Unterstützung einer automatisierten Reparatur von fehlerhaften Knoten durch Konfiguration von Spare-Nodes

Screenshots

RawDR Setup

Create a new node item
Grinder, Reaper, Inspector
Create Reaper Disk and select iSCSI multipath networks
Create SyncMemory on Inspector
Create new ZPool, select Reaper Disks, and new LAGG network
Create Dataset within ZPool to activate NFS

RawDR Management

 
 
 
 
 
 
 

Architektur

RawDR Storage Layer

RawDR Storage Layer

RawDR Network Layer

RawDR Hyperconverged Layered

RawDR Hyper-converged Layered

RawDR Accelerator Layered

RawDR Accelerator Layered

RawDR Hyperconverged Direct

RawDR Hyper-converged Direct

RawDR Accelerator Direct

RawDR Accelerator Direct