Support

Tutorials

Setup RawDR Active/Active HA Storage with ZFS and NFS Shared Storage

RawDR live HA Failover and live move of a Zpool between 2 physical servers

Setup RawDR HA Storage on free Citrix XenServer on 2 Hetzner Dedicated PX92

RawDR HA behavior caused by hardware reset of a Hetzner Server running Citrix XenServer

RawDR Max Performance Hyper-Converged Setup on 2 Hetzner PX92 with free Citrix XenServer

FAQs

Raw + D + R [rɔːdia:(r)]

Wir sind Speziallisten in VDI-Technologien von Citrix und VMware, wodurch wir ständig in direkten oder indirekten Kontakt mit den davon abhängigen Technologien wie Storage, Netzwerk, Sicherheit und Datenbanken stehen. Dadurch haben wir ein sehr tiefgreifendes und vernetztes Wissen was den VDI-spezifischen Datenfluss angeht. RawDR wurde daher aus der Sicht eines VDI-Architekten und nicht aus der Sicht eines Storage-Architekten entwickelt, wodurch völlig andere Ansprüche abdeckt werden. Beispielsweise stehen für uns die VDI-Zugriffsmuster bestehend aus einem konstanten 80% 4K Random Write Load im Fokus.

Enterprise Storage muss sicherstellen, dass die Daten auf nicht-flüchtigen Datenträgern (HDDs, SSDs oder NVMe) dauerhaft abgelegt werden. All-Flash Lösungen nutzen lediglich SSDs oder NVMe, oftmals lediglich durch RAID geschützt. Der hierfür eingesetzt Flash-Speicher muss Enterprise tauglich sein, benötigt erweiterte Fehlerkorrekturen, Power-Loss-Protection und muss für den Dauerbetrieb ausgelegt sein, was ihn gegenüber Desktop/Workstation Flash Speicher oder auch Enterprise Festplatten 5-10 Mal teurer macht.

Hybrid-Storage kombiniert die Stärken von günstigerem Flash Speicher und Festplatten. ZFS greift auf die Festplatten nur sequentiell zu, was einen ca. 100-fachen Datendurchsatz gegenüber verteilten Zugriffen entspricht. Bei Hybrid-Speicher wird der Flash-Speicher nur als Readcache verwendet, die Enterprise Funktionalitäten sind daher nicht zwingend nötig und auch muss dieser Cache nicht redundant ausgelegt werden. Daher können günstigere Lösungen wie bspw. M.2 Module oder auch die Intel Optane verwendet werden. ZFS sorgt implizit für die Datenintegrität und für die Langlebigkeit des Flashspeichers.

RawDR ermöglicht die Performance von Flash-Speicher zu den Kosten von Festplattenspeicher, ist daher um ein Vielfaches günstiger als All-Flash Lösungen und bietet einen deutlichen höheren Schutz der Daten

ZFS unterstützt zwar Online Deduplizierung, was auf Dataset-Ebene innerhalb von RawDR aktiviert werden kann, es benötigt allerdings sehr viel RAM und kostet Schreibperformance. Daher raten wir generell vom Einsatz von Deduplizierung in Verbindung mit virtuellen Maschinen und RawDR ab. Der Grossteil der Einsparungen wird ohnehin durch Thin-Provisioning erreicht (was implizit von RawDR verwendet wird). In Kombination mit der LZ4-Kompression erreicht man eine sehr grosse Einsparung. Es sollte erwähnt werden, dass Deduplizierung sehr gut in Präsentationen und Testlabs funktioniert, die Ergebnisse nach 1 Jahr mit echten Daten ernüchternd ausfallen können.

Die Spitzenleistung einer Storage Lösung, die nicht ausgelastet ist, hängt im Wesentlichen von der Latenz ab. Während Hyper-Converged Lösungen, aufgrund Ihrer Nähe von Storage-Controller und VMs, eine minimale Latenz vermuten lassen, kann diese gegenüber einer mehreren KM entferntem System höher ausfallen. Im Regelfall erhöhen die Softwareswitches innerhalb des Hypervisor die Latenz drastisch. Dies kann mit einem einfachen Beispiel getestet werden, bei dem die Latenz zwischen 2 VMs auf dem gleichen Hypervisor mit der Latenz zwischen 2 physischen Systemen verglichen wird. Für die Messung der Peak Performance eines einzelnen Clients ist daher lediglich die Latenz ausschlaggebend.

Das grösste Problem bei der Performanceermittlung sind jedoch die Werkzeuge. Die meisten Tools sind dafür ausgelegt, lokale Hardware zu testen, eignen sich aber wegen der vielen Layer nicht für virtuelle Umgebungen. Die Tools erzeugen im Regelfall eine grosse Datei innerhalb des Dateisystems gegenüber dieser dann die einzelnen Benchmarks ausgeführt werden. Dieses Zugriffsverhalten wiederspricht komplett jedem realen Zugriffsmuster innerhalb virtuellen Umgebungen und kann daher nicht aussagekräftig angesehen werden.

Darüber hinaus stellt sich dann die Frage, was überhaupt geprüft werden soll. Sollen die Caches geprüft werden oder sollen diese vermieden werden? Beide Varianten entsprechen keinesfalls der Realität. Sollen Peaks gemessen werden oder interessiert doch eher die Performance bei Dauerlast? Wird die Einzelperformance einer VM gemessen oder die Gesamtlast von mehreren 100 VMs?

Im Endeffekt wird RawDR das Maximum aus der Hardware bei maximaler Datensicherheit (Prüfsummen, Snapshots, usw.) herausholen. Ein einfaches Consumer M.2 NVMe Modul, dass sich nicht um diese Art der Datensicherheit und Datenverfügbarkeit kümmern braucht, wird daher die meisten Enterprise Lösungen in den gängigen Benchmarks besiegen.

Eine Reaper VM stellt einem oder mehreren Grinder die lokalen Storage Ressourcen des Hypervisors per iSCSI bereit. Entweder als einzelne vDisk(s) oder als Striped vDisk(s).

Auf einem RawDR Grinder laufen ein oder mehrere Zpools. Ein Zpool spiegelt die vDisks, die von den Reaper oder von anderen iSCSI-Targets (bspw. LUNs von einer bereits vorhandenen Storage Lösung). Innerhalb des Zpools können ZFS Datasets erzeugt werden, die per NFS (in Kürze auch per CIFS) exportiert werden und dann bspw. innerhalb der Virtualisierungslösung als Datastore oder Storage Repository eingebunden werden können. Jedes Dataset kann unterschiedliche Eigenschaften haben (Quotas, Kompression, IP-Beschränkungen, usw.), auch können Snapshots unabhängig voneinander erstellt werden. Jeder Zpool hat eine eigene IP-Adresse, wodurch dieser (transparent für die Clients) zwischen den Grinder verschoben werden kann. Auch kann ein Inspector bei einem Ausfall eines Grinders den Zpool automatisch auf einem anderen Grinder starten, wodurch RawDR eine echte Hochverfügbarkeit liefert. Ein RawDR Grinder kümmert sich auch um das mehrstufige Readcaching und um die Absicherung der flüchtigen Daten, die noch nicht auf permanentem Storage runtergeschrieben wurden.

Ein RawDR Inspector kümmert sich um die Hochverfügbarkeit von Zpools. Bei einem Ausfall eines Grinder werden alle nötigen Schritte durchgeführt, damit der jeweilige Zpool auf einem anderen funktionierenden Grinder läuft und die Clients nichts davon mitbekommen. Um Dateninkonsistenz oder einen Split-Brain Zustand zu verhindern, wird der fehlerhafte Grinder ggf. vom Storage Layer isoliert.

Der Inspector bietet den Zpools zudem die Möglichkeit, eine Kopie der noch nicht auf permanentem Speicher runtergeschrieben Daten aufzubewahren. Bei einem automatischen Failover werden diese Daten dann zuerst auf den permanenten Storage geschrieben, wodurch die Konsistenz mit den Clients gewahrt wird und diese transparent weiterarbeiten können.

Beim Importieren der RawDR Appliance kann das Default-Passwort aus der Lizenz-Datei entnommen werden.

Für einen RawDR Reaper empfehlen wir 2 vCPUs und 512MB RAM. Für den RawDR Inspector empfehlen wir 2vCPUs und 6GB RAM. Für einen RawDR Grinder hängt es von dem Einsatzzweck ab: Für dedizierte VMs empfehlen wir 4vCPUs und so viel RAM, wie entbehrt werden kann, mindestens jedoch 8GB RAM. Falls nicht ausreichend RAM zur Verfügung stehen sollte, kann auch die Erweiterung um Flash-Speicher erwogen werden. Hierdurch lässt sich auch ein Hybridspeicher aufbauen. Bei einer Recordsize von 32KB sollte der Read-Cache das 20-fache des RAM nicht übersteigen.