Technischer Überblick über die Qumulo Hybrid Cloud-Datei

Moderner, hoch skalierbarer Speicher

Qumulo File Fabric (QF2) ist ein modernes, hoch skalierbares Dateispeichersystem, das das Rechenzentrum und die öffentliche Cloud umfasst. Es lässt sich auf Milliarden von Dateien skalieren, kostet weniger und hat niedrigere Gesamtbetriebskosten als herkömmliche Speichergeräte. Es ist außerdem das leistungsstärkste Dateispeichersystem vor Ort und in der Cloud. Dank der integrierten Echtzeitanalyse können Administratoren Daten problemlos verwalten, unabhängig von der Größe des Speicherbereichs oder dem globalen Standort.

QF2 verschiebt Dateidaten dorthin, wo sie benötigt werden, zum Beispiel zwischen lokalen Clustern und Clustern, die in der Cloud ausgeführt werden. Mit QF2 können Sie riesige Datensätze in mehreren Umgebungen überall auf der Welt speichern und verwalten. Die Software von QF2 läuft auf branchenüblicher Hardware vor Ort oder auf Cloud-Instanzen und Cloud-Speicherressourcen. QF2 wurde von Grund auf so konzipiert, dass es den heutigen Anforderungen an Skalierung und Datenmobilität gerecht wird. Es ist das weltweit erste universelle Dateispeichersystem.

Qumulo ist ein neuartiges Speicherunternehmen, das ausschließlich auf fortschrittlicher Software basiert. Qumulo ist Teil eines größeren Branchentrends, bei dem Software im Vergleich zu Hardware an Wert gewinnt. Standardhardware, auf der fortschrittliche, verteilte Software ausgeführt wird, ist die unangefochtene Grundlage für moderne, kostengünstige und skalierbare Datenverarbeitung. Dies gilt ebenso für die Dateispeicherung im großen Maßstab.

Wenn Leute QF2 zum ersten Mal in Aktion sehen, fragen sie sich oft: „Wie kann das so sein?“ Die Beantwortung dieser Frage ist der Grund für dieses Papier. Wir gehen unter die Haube und erklären einige der fortgeschrittenen Techniken, die QF2 seine einzigartigen Fähigkeiten verleihen.

Datenmobilität, lineare Skalierbarkeit und globale Reichweite

Aus Gründen der Skalierbarkeit verfügt QF2 über eine verteilte Architektur, in der viele einzelne Rechenknoten zusammenarbeiten, um einen Cluster mit skalierbarer Leistung und einem einzigen, einheitlichen Dateisystem zu bilden. QF2-Cluster wiederum arbeiten zusammen, um eine global verteilte, aber hochgradig vernetzte Speicherstruktur zu bilden, die durch kontinuierliche Replikationsbeziehungen miteinander verbunden ist.

Kunden interagieren mit QF2-Clustern über branchenübliche Dateiprotokolle, die QF2 REST API und eine webbasierte grafische Benutzeroberfläche (GUI) für Speicheradministratoren.

Dieses Diagramm zeigt die Verbindungen zwischen Clients, QF2-Clustern, die aus Knoten bestehen, auf denen Qumulo Core ausgeführt wird, und mehreren QF2-Clustern, die die Fabric bilden und in mehreren Umgebungen und geografischen Standorten ausgeführt werden.

QF2 ist ein modulares System. Wenn die Anforderungen an einen QF2-Cluster steigen, fügen Sie einfach Knoten oder Instanzen hinzu. Kapazität und Leistung skalieren linear, und zwar unabhängig davon, ob der QF2-Cluster in einem Rechenzentrum vor Ort oder in der öffentlichen Cloud betrieben wird.

Was ist in QF2 enthalten?

QF2 besteht sowohl aus Software als auch aus Diensten. Es ist mit einfachen und transparenten Abonnementpreisen erhältlich. Hier ist ein Diagramm, was in einem QF2-Abonnement enthalten ist. Qumulo Core ist die Software, die auf jedem Knoten eines QF2-Clusters läuft. Es umfasst leistungsstarke Echtzeitanalysen und Kapazitätskontingente sowie kontinuierliche Replikation und Snapshots. Diese Funktionen basieren auf dem hoch skalierbaren QF2-Dateisystem, das im Gegensatz zu anderen Systemen eine integrierte Echtzeit-Aggregation von Dateimetadaten umfasst.

Das QF2-Dateisystem basiert auf einem leistungsstarken, hochmodernen Datenverwaltungssystem namens Qumulo Scalable Block Store (SBS). SBS nutzt die Prinzipien massiv skalierbarer verteilter Datenbanken und ist für die speziellen Anforderungen dateibasierter Daten optimiert. Der Scalable Block Store ist die Blockschicht des QF2-Dateisystems, wodurch dieses Dateisystem einfacher zu implementieren und äußerst robust ist. SBS verleiht dem Dateisystem außerdem enorme Skalierbarkeit, optimierte Leistung und Datenschutz.

QF2 bietet im Rahmen des QF2-Abonnements cloudbasierte Überwachung und Trendanalyse sowie umfassenden Kundensupport. Die Cloud-Überwachung umfasst die proaktive Erkennung von Ereignissen wie Festplattenausfällen, um Probleme zu verhindern, bevor sie auftreten. Der Zugriff auf historische Trends hilft, Kosten zu senken und Arbeitsabläufe zu optimieren, um Ihre Speicherinvestition optimal zu nutzen.

Ihre Wahl der Betriebsumgebungen

Die Qumulo Core-Software läuft in der öffentlichen Cloud und auf branchenüblicher Hardware in Ihrem Rechenzentrum. Qumulo Core läuft derzeit auf Qumulos eigener QC-Serie von White-Box-Servern und auf Apollo-Servern von Hewlett-Packard Enterprise (HPE). Da QF2 hardwareunabhängig ist, ist es nicht auf einen einzelnen Hardware-Anbieter angewiesen. Tatsächlich können Sie davon ausgehen, dass Qumulo Unterstützung für Server mehrerer OEMs hinzufügt.

Der reine Software-Ansatz von QF2 bedeutet, dass keine Abhängigkeiten von teuren, proprietären Komponenten wie NVRAM, InfiniBand-Switches und proprietärem Flash-Speicher bestehen. Stattdessen setzt QF2 auf Festplattenlaufwerke (HDD) und Solid-State-Laufwerke (SSD) mit Standard-Firmware, die von den Laufwerksherstellern erhältlich ist. Die Kombination aus Standard-SSDs und HDDs für die automatische Einstufung heißer und kalter Daten ist einer der Gründe dafür, dass QF2 Flash-Leistung zum Preis von Archivspeicher bietet.

Sie können QF2-Cluster auch in der öffentlichen Cloud (derzeit AWS) erstellen. Auf den Knoten cloudbasierter QF2-Cluster wird dieselbe Qumulo Core-Software ausgeführt wie bei lokalen QF2-Clustern. Im Gegensatz zu anderen cloudbasierten Dateispeichersystemen gibt es für einen QF2-Cluster, der in der öffentlichen Cloud läuft, keine strengen Leistungs- und Kapazitätsgrenzen. Beides kann durch das Hinzufügen von Knoten (Recheninstanzen und Blockspeicher) erhöht werden. QF2 ist die einzige Lösung für die Cloud, mit der Sie sowohl Kapazität als auch Leistung flexibel skalieren können.

Beim Betrieb in der Cloud nutzt QF2 Cloud-Blockspeicher auf ähnliche Weise wie die SSD/HDD-Kombination vor Ort. QF2 verwendet Blockspeicher mit niedriger Latenz als Cache vor kostengünstigem Blockspeicher mit höherer Latenz. Im Rest des Artikels werden wir über SSDs und HDDs sprechen, aber die besprochenen Konzepte gelten gleichermaßen für QF2-Benutzer von Blockspeicherressourcen mit niedrigerer und höherer Latenz in der öffentlichen Cloud.

Auf jedem Knoten eines QF2-Clusters läuft Qumulo Core im Linux-Benutzerbereich und nicht im Kernelbereich. Der Kernelmodus ist hauptsächlich für Gerätetreiber gedacht, die mit bestimmter Hardware funktionieren. Durch den Betrieb im Benutzerbereich kann QF2 in einer Vielzahl von Konfigurationen und Umgebungen ausgeführt werden und bietet außerdem Funktionen viel schneller.

Die Ausführung im Benutzerbereich bedeutet auch, dass QF2 über eigene Implementierungen wichtiger Protokolle wie SMB, NFS, LDAP und Active Directory verfügen kann. Beispielsweise läuft die NFS-Implementierung von QF2 als Systemdienst und verfügt über eigene Vorstellungen von Benutzern und Gruppen, die vom zugrunde liegenden Betriebssystem, auf dem sie ausgeführt wird, getrennt sind.

Die Ausführung im Benutzerbereich verbessert auch die Zuverlässigkeit von QF2. Als unabhängiger User-Space-Prozess ist QF2 von anderen Systemkomponenten isoliert, die zu Speicherbeschädigungen führen könnten, und die QF2-Entwicklungsprozesse können fortschrittliche Speicherüberprüfungstools nutzen, die es ermöglichen, speicherbezogene Codierungsfehler vor der Software-Veröffentlichung zu erkennen. Durch die Verwendung einer Dual-Partitions-Strategie für Software-Upgrades kann Qumulo sowohl das Betriebssystem als auch die Qumulo Core-Software automatisch aktualisieren, um schnelle und zuverlässige Upgrades zu ermöglichen. Sie können QF2 ganz einfach neu starten, ohne das Betriebssystem, den Knoten oder den Cluster neu starten zu müssen.

Massiv skalierbare Dateien und Verzeichnisse

Wenn Sie eine große Anzahl von Dateien haben, werden die Verzeichnisstruktur und die Dateiattribute selbst zu Big Data. Infolgedessen sind sequentielle Prozesse wie Baumwanderungen, die für die Legacy-Speicherung von grundlegender Bedeutung sind, rechnerisch nicht mehr realisierbar. Stattdessen erfordert die Abfrage und Verwaltung eines großen Dateisystems einen neuen Ansatz, der parallele und verteilte Algorithmen verwendet.

QF2 macht genau das. Es ist einzigartig in der Art und Weise, wie es das Problem der Skalierbarkeit angeht. Sein Design implementiert ähnliche Prinzipien wie moderne, große, verteilte Datenbanken. Das Ergebnis ist ein Dateisystem mit unübertroffenen Skalierungseigenschaften. Im Gegensatz dazu waren ältere Speichergeräte einfach nicht für die Bewältigung des enormen Datenvolumens von heute ausgelegt.

Das QF2-Dateisystem sitzt auf einer virtualisierten Blockschicht namens SBS. In QF2 erfolgen zeitaufwändige Arbeiten wie Schutz, Neuerstellungen und die Entscheidung, welche Festplatten welche Daten enthalten, in der SBS-Schicht unterhalb des Dateisystems. (Wir werden später in diesem Artikel mehr über geschützte virtuelle Blöcke und Transaktionen sprechen.)

Die virtualisierte Protected-Block-Funktionalität von SBS ist ein großer Vorteil für das QF2-Dateisystem. In älteren Speichersystemen ohne SBS erfolgt der Schutz dateiweise oder mithilfe fester RAID-Gruppen, was viele schwierige Probleme wie lange Wiederherstellungszeiten, ineffiziente Speicherung kleiner Dateien und kostspielige Verwaltung von Festplattenlayouts mit sich bringt. Ohne eine virtualisierte Blockschicht müssen ältere Speichersysteme auch den Datenschutz innerhalb der Metadatenschicht selbst implementieren, und diese zusätzliche Komplexität schränkt die Fähigkeit dieser Systeme ein, verteilte Transaktionen für ihre Verzeichnisdatenstrukturen und Metadaten zu optimieren.

Für die Skalierbarkeit von Dateien und Verzeichnissen nutzt das QF2-Dateisystem in großem Umfang Indexdatenstrukturen, die als bekannt sind B-Bäume. B-Bäume eignen sich besonders gut für Systeme, die eine große Anzahl von Datenblöcken lesen und schreiben, da es sich um „flache“ Datenstrukturen handelt, die den für jede Operation erforderlichen E/A-Umfang bei zunehmender Datenmenge minimieren. Mit B-Bäumen als Grundlage wächst der Rechenaufwand für das Lesen oder Einfügen von Datenblöcken mit zunehmender Datenmenge sehr langsam. B-Bäume eignen sich beispielsweise ideal für Dateisysteme und sehr große Datenbankindizes.

In QF2 sind B-Bäume blockbasiert. Jeder Block ist 4096 Bytes groß. Hier ist ein Beispiel, das die Struktur eines B-Baums zeigt.

Jeder 4K-Block kann Zeiger auf andere 4K-Blöcke haben. Dieser spezielle B-Baum hat einen Verzweigungsfaktor von 3, wobei ein Verzweigungsfaktor die Anzahl der untergeordneten Knoten (Unterknoten) an jedem Knoten im Baum ist.

Selbst wenn es Millionen von Blöcken gibt, beträgt die Höhe eines B-Baums in SBS von der Wurzel bis zum Speicherort der Daten möglicherweise nur zwei oder drei Ebenen. Um beispielsweise im Diagramm nach der Bezeichnung q mit dem Indexwert 1 zu suchen, durchläuft das System nur zwei Ebenen des Baums.

Das QF2-Dateisystem verwendet B-Bäume für viele verschiedene Zwecke.

Da ist ein Inode B-Baum, der als Index aller Dateien fungiert. Die Inode-Liste ist eine Standardtechnik zur Implementierung von Dateisystemen, die die Überprüfung der Konsistenz des Dateisystems unabhängig von der Verzeichnishierarchie ermöglicht. Inodes tragen auch dazu bei, Aktualisierungsvorgänge wie Verzeichnisverschiebungen effizient zu gestalten.

Dateien und Verzeichnisse werden als B-Bäume mit eigenen Schlüssel/Wert-Paaren dargestellt, z. B. dem Dateinamen, seiner Größe und seiner Zugriffskontrollliste (ACL) oder POSIX-Berechtigungen.

Konfigurationsdaten sind ebenfalls ein B-Baum und enthalten Informationen wie die IP-Adresse und den Cluster.

Tatsächlich kann man sich das QF2-Dateisystem als einen Baum von Bäumen vorstellen. Hier ist ein Beispiel.

Der Baum der obersten Ebene wird Super-B-Baum genannt. Wenn das System startet, beginnt dort die Verarbeitung. Der Stamm wird immer an der ersten Adresse („paddr 1.1“) des Arrays virtueller geschützter Blöcke gespeichert. Der Wurzelbaum verweist auf andere B-Bäume. Wenn das QF2-Dateisystem beispielsweise auf Konfigurationsdaten zugreifen muss, geht es zum Konfigurations-B-Baum. Um eine bestimmte Datei zu finden, fragt das System den Inode-B-Baum ab und verwendet dabei die Inode-Nummer als Index. Das System durchläuft den Inode-Baum, bis es den Zeiger auf den Datei-B-Baum findet. Von dort aus kann das Dateisystem alles über die Datei nachschlagen. Verzeichnisse werden genauso behandelt wie Dateien.

Das Vertrauen auf B-Bäume, die auf virtualisierten geschützten Blockspeicher in SBS verweisen, ist einer der Gründe dafür, dass in QF2 ein Dateisystem mit einer Billion Dateien machbar ist.

Echtzeit-Sichtbarkeit und Kontrolle mit QumuloDB

QF2 ist darauf ausgelegt, mehr als nur Dateidaten zu speichern. Außerdem können Sie Ihre Daten und Benutzer in Echtzeit verwalten. Administratoren älterer Speichergeräte werden durch „Datenblindheit“ behindert. Sie können sich kein genaues Bild davon machen, was in ihrem Dateisystem passiert. QF2 ist darauf ausgelegt, genau diese Sichtbarkeit zu bieten, unabhängig davon, wie viele Dateien und Verzeichnisse vorhanden sind. Sie können beispielsweise sofort einen Einblick in Durchsatztrends und Hotspots erhalten. Sie können auch Kapazitätskontingente in Echtzeit festlegen, wodurch der zeitaufwändige Aufwand für die Kontingentbereitstellung von Altspeicher vermieden wird. Der Zugriff auf Informationen erfolgt über eine grafische Benutzeroberfläche und es gibt auch eine REST-API, die Ihnen den programmgesteuerten Zugriff auf die Informationen ermöglicht.

Die integrierten Analysefunktionen des QF2-Dateisystems werden von einer Komponente namens QumuloDB bereitgestellt.

Wenn Menschen mit den Echtzeitanalysen von QF2 vertraut gemacht werden und ihnen dabei zusehen, wie sie in großem Maßstab arbeiten, lautet ihre erste Frage normalerweise: „Wie kann es so schnell gehen?“ Die bahnbrechende Leistung der Echtzeitanalyse von QF2 ist aus drei Gründen möglich.

Erstens sind im QF2-Dateisystem QumuloDB-Analysen integriert und vollständig in das Dateisystem selbst integriert. In Legacy-Systemen werden Metadatenabfragen außerhalb des Kerndateisystems von einer unabhängigen Softwarekomponente beantwortet.

Zweitens kann die QumuloDB-Analyse ein innovatives System von Echtzeitaggregaten nutzen, das wir im nächsten Abschnitt beschreiben, da das QF2-Dateisystem auf B-Bäumen basiert.

Schließlich sind QumuloDB-Analysen möglich, da das QF2-Dateisystem aufgrund der Verwendung der B-Tree-Indizes und der virtualisierten geschützten Blöcke und Transaktionen des Qumulo Scalable Block Store (SBS) ein optimiertes Design aufweist.

Echtzeit-Aggregation von Metadaten

Im QF2-Dateisystem werden Metadaten wie verwendete Bytes und Dateianzahlen aggregiert, wenn Dateien und Verzeichnisse erstellt oder geändert werden. Dies bedeutet, dass die Informationen für eine zeitnahe Verarbeitung verfügbar sind, ohne dass kostspielige Baumwanderungen im Dateisystem erforderlich sind.

QumuloDB verwaltet aktuelle Metadatenzusammenfassungen. Es nutzt die B-Bäume des Dateisystems
um Informationen über das Dateisystem zu sammeln, wenn Änderungen auftreten. Verschiedene Metadatenfelder werden innerhalb des Dateisystems zu einem virtuellen Index zusammengefasst. Die Leistungsanalysen, die Sie in der GUI sehen und mit der REST-API abrufen können, basieren auf Sampling-Mechanismen, die in das QF2-Dateisystem integriert sind. Statistisch gültige Stichprobenverfahren sind möglich, da aktuelle Metadatenzusammenfassungen verfügbar sind, die es Stichprobenalgorithmen ermöglichen, größeren Verzeichnissen und Dateien mehr Gewicht zu verleihen.

Die Aggregation von Metadaten in QF2 erfolgt nach einem Bottom-Up- und Top-Down-Ansatz.

Wenn jede Datei (oder jedes Verzeichnis) mit neuen aggregierten Metadaten aktualisiert wird, wird das übergeordnete Verzeichnis als „verschmutzt“ markiert und ein weiteres Aktualisierungsereignis wird für das übergeordnete Verzeichnis in die Warteschlange gestellt. Auf diese Weise werden Dateisysteminformationen gesammelt und aggregiert, während sie im Baum nach oben weitergeleitet werden. Die Metadaten breiten sich vom einzelnen Inode auf der untersten Ebene bis zum Stammverzeichnis des Dateisystems aus, während auf die Daten in Echtzeit zugegriffen wird. Jeder Datei- und Verzeichnisvorgang wird berücksichtigt, und diese Informationen werden schließlich bis zum Kern des Dateisystems weitergegeben. Hier ist ein Beispiel.

Der Baum auf der linken Seite fasst Datei- und Verzeichnisinformationen zusammen und integriert sie in die Metadaten. Anschließend wird eine Aktualisierung für das übergeordnete Verzeichnis in die Warteschlange gestellt. Die Informationen wandern nach oben, von den Blättern zur Wurzel.

Parallel zur Bottom-up-Weitergabe von Metadatenereignissen beginnt eine periodische Durchquerung oben im Dateisystem und liest die in den Metadaten vorhandenen aggregierten Informationen. Wenn die Durchquerung kürzlich aktualisierte aggregierte Informationen findet, beschneidet sie ihre Suche und fährt mit dem nächsten Zweig fort. Dabei wird davon ausgegangen, dass aggregierte Informationen im Dateisystembaum von diesem Punkt bis zu den Blättern (einschließlich aller enthaltenen Dateien und Verzeichnisse) aktuell sind und für zusätzliche Analysen nicht tiefer gehen müssen. Der Großteil der Metadatenzusammenfassung wurde bereits berechnet, und im Idealfall muss bei der Durchquerung nur eine kleine Teilmenge der Metadaten für das gesamte Dateisystem zusammengefasst werden. Tatsächlich treffen die beiden Teile des Aggregationsprozesses in der Mitte aufeinander, ohne dass einer von beiden den gesamten Dateisystembaum von oben bis unten durchsuchen muss.

Stichproben- und Metadatenabfragen

Ein Beispiel für die Echtzeitanalyse von QF2 sind die Berichte zu Leistungs-Hotspots. Hier ist ein Beispiel aus der GUI.

In großen Dateisystemen wäre es nicht möglich, alle Durchsatzvorgänge und IOPS innerhalb der GUI darzustellen. Stattdessen verwenden QumuloDB-Abfragen probabilistische Stichproben, um eine statistisch gültige Annäherung an diese Informationen bereitzustellen. Gesamtwerte für IOPS-Lese- und Schreibvorgänge sowie Lese- und Schreibvorgänge mit E/A-Durchsatz werden aus Stichproben generiert, die aus einem speicherinternen Puffer mit 4,096 Einträgen gesammelt werden, der alle paar Sekunden aktualisiert wird.

Der hier angezeigte Bericht zeigt die Vorgänge an, die die größte Auswirkung auf den Cluster haben. Diese werden als Hotspots in der GUI dargestellt.

Die Fähigkeit von QF2, statistisch gültige probabilistische Stichproben zu verwenden, ist nur aufgrund der zusammengefassten Metadaten für jedes Verzeichnis (verwendete Bytes, Dateianzahlen) möglich, die von QumuloDB kontinuierlich auf dem neuesten Stand gehalten werden. Dies ist ein einzigartiger Vorteil der fortschrittlichen Softwaretechniken von QF2, der in keinem anderen Dateispeichersystem zu finden ist.

Echtzeitkontingente

So wie die Echtzeit-Aggregation von Metadaten die Echtzeitanalyse von QF2 ermöglicht, ermöglicht sie auch Echtzeit-Kapazitätskontingente. Mit Kontingenten können Administratoren festlegen, wie viel Kapazität ein bestimmtes Verzeichnis für Dateien verwenden darf. Wenn ein Administrator beispielsweise feststellt, dass ein betrügerischer Benutzer dafür sorgt, dass ein Unterverzeichnis zu schnell wächst, kann der Administrator sofort die Kapazität des Verzeichnisses dieses Benutzers begrenzen.

In QF2 werden Kontingente sofort bereitgestellt und müssen nicht bereitgestellt werden. Sie werden in Echtzeit durchgesetzt und Änderungen ihrer Kapazitäten werden sofort umgesetzt. Ein Nebeneffekt besteht darin, dass den Verzeichnissen zugewiesene Kontingente mit verschoben werden und die Verzeichnisse selbst in Kontingentdomänen verschoben und aus diesen heraus verschoben werden können.

Im Gegensatz zu einigen anderen Systemen erfordern Qumulo-Kontingente keine Aufteilung des Dateisystems in Volumes. Außerdem erfordert das Verschieben eines Kontingents oder das Verschieben von Verzeichnissen über Kontingentdomänen hinweg mit QF2 keine langwierigen Baumwanderungen, Jobplanung oder umständlichen, mehrstufigen Prozesse. Kontingente in QF2 können auf jedes Verzeichnis angewendet werden, auch auf verschachtelte. Wenn eine Zuweisung aufgrund verschachtelter Verzeichnisse über mehr als ein Kontingent verfügt, müssen alle Kontingente erfüllt sein, um den angeforderten Speicherplatz zuzuweisen.

Da Kontingentgrenzen in QF2 als Metadaten auf Verzeichnisebene aufgezeichnet werden, können Kontingente auf jeder Ebene des Verzeichnisbaums angegeben werden. Bei einem Schreibvorgang müssen alle relevanten Kontingente erfüllt sein. Das sind harte Grenzen. Die Präzision und Agilität der Echtzeitkontingente von QF2 sind möglich, weil der integrierte Aggregator die Zusammenfassung der insgesamt pro Verzeichnis genutzten Speichermenge kontinuierlich auf dem neuesten Stand hält.

Snapshots

Mithilfe von Snapshots können Systemadministratoren den Status eines Dateisystems oder Verzeichnisses zu einem bestimmten Zeitpunkt bewahren. Wenn eine Datei oder ein Verzeichnis unbeabsichtigt geändert oder gelöscht wird, können Benutzer oder Administratoren sie auf den gespeicherten Zustand zurücksetzen.

Snapshots in QF2 verfügen über eine äußerst effiziente und skalierbare Implementierung. Ein einzelner QF2-Cluster kann eine praktisch unbegrenzte Anzahl gleichzeitiger Snapshots ohne Leistungs- oder Kapazitätseinbußen haben.

Snapshots werden als Out-of-Place-Blockschreibvorgänge implementiert. Wenn ein Snapshot erstellt und Blöcke geändert werden, werden sie in einen neuen Spine von B-Tree-Blöcken geschrieben. Vorhandene Blöcke, die nicht geändert wurden, werden mit dem neuen Spine verknüpft und werden nun gemeinsam genutzt. Der neue modifizierte Spine wurde „fehl am Platz“ geschrieben, verweist aber immer noch auf vorhandene Daten und teilt die unveränderten Blöcke. Der Snapshot verbraucht keinen Speicherplatz, bis Daten geändert oder gelöscht werden.

Angenommen, Sie fügen dem QF4-Dateisystem eine 2-MB-Datei hinzu und erstellen dann einen Snapshot. Nachdem der Snapshot erstellt wurde, beträgt die genutzte Kapazität immer noch nur 4 MB. Anschließend ändern Sie einen 1 MB großen Bereich Ihrer Datei. Die neuen Daten (1 MB) werden falsch geschrieben und mit der „Live“-Version der Datei verknüpft. 3 MB der ursprünglichen 4 MB Daten werden zwischen der Live-Version und der im Snapshot erfassten Version geteilt. Die Gesamtspeichernutzung für diese Datei beträgt jetzt 5 MB.

Snapshots sind eine Sicherheitsfunktion, die dazu beiträgt, das Dateisystem widerstandsfähig zu machen, falls Benutzer versehentlich Dateidaten löschen oder ändern. Wenn beispielsweise einige Daten versehentlich gelöscht werden, können Benutzer Dateien aus einem zuvor erstellten Snapshot wiederherstellen. Einzelne Dateien oder ganze Verzeichnisse können durch Zurückkopieren in das Live-Dateisystem wiederhergestellt werden.

Wenn der Speicherplatz knapp wird, entscheiden sich Administratoren oft dafür, Snapshots zu löschen, um Speicherplatz freizugeben. Da Snapshots Daten gemeinsam nutzen, wird durch das Löschen eines Snapshots normalerweise nicht die gleiche Menge an Speicherplatz wiederhergestellt, die der Summe aller darin enthaltenen Dateien entspricht. In Altsystemen ist es schwierig zu wissen, wie viel Speicherplatz tatsächlich zurückgewonnen würde.

Snapshots in QF2 nutzen die im Dateisystem integrierte Intelligenz. Administratoren können berechnen, wie viel Speicher tatsächlich zurückgewonnen würde, wenn sie eine Reihe von Snapshots löschen.

Kontinuierliche Replikation

QF2 bietet kontinuierliche Replikation über Speichercluster hinweg, egal ob vor Ort oder in der öffentlichen Cloud. Sobald eine Replikationsbeziehung zwischen einem Quellcluster und einem Zielcluster eingerichtet und synchronisiert wurde, sorgt QF2 automatisch für die Konsistenz der Daten.

Die kontinuierliche Replikation in QF2 nutzt die erweiterten Snapshot-Funktionen von QF2, um konsistente Datenreplikate sicherzustellen. Bei QF2-Snapshots reproduziert ein Replikat auf dem Zielcluster den Status des Quellverzeichnisses zu exakten Zeitpunkten. QF2-Replikationsbeziehungen können für maximale Flexibilität verzeichnisweise eingerichtet werden.

Qumulo wendet intelligente Algorithmen an, um die Replikation zu verwalten, sodass Sie dies nicht tun müssen. QF2 repliziert so oft wie möglich, ohne die Gesamtleistung des Clusters negativ zu beeinflussen. Die kontinuierliche Replikation in QF2 ist ab heute einseitig asynchron; das heißt, es gibt eine Quelle und ein schreibgeschütztes Ziel. Änderungen am Quellverzeichnis werden asynchron an das Ziel weitergegeben.

Der skalierbare Blockspeicher (SBS) von Qumulo

Nachdem wir uns nun die Interna des QF2-Dateisystems angesehen haben, wenden wir uns den erweiterten Strategien von QF2 für die verteilte Blockverwaltung zu, die im Qumulo Scalable Block Store zu finden sind. Hier finden Sie eine Übersicht darüber, was in SBS enthalten ist.

SBS bietet eine transaktionale virtuelle Schicht geschützter Speicherblöcke. Anstelle eines Systems, in dem jede Datei ihren Schutz selbst herausfinden muss, existiert Datenschutz unterhalb des Dateisystems auf Blockebene.

Der blockbasierte Schutz von QF2, wie er von SBS implementiert wird, bietet hervorragende Leistung in Umgebungen mit Petabytes an Daten und Arbeitslasten mit gemischten Dateigrößen.

SBS bietet viele Vorteile, darunter:

• Schnelle Wiederherstellungszeiten bei einem ausgefallenen Laufwerk
• Die Möglichkeit, normale Dateivorgänge während der Neuerstellungsvorgänge fortzusetzen
• Keine Leistungseinbußen aufgrund von Konflikten zwischen normalen Dateischreibvorgängen und Neuaufbau-Schreibvorgängen
• Gleiche Speichereffizienz für kleine Dateien wie für große Dateien
• Genaue Berichterstattung über den nutzbaren Raum
• Effiziente Transaktionen, die eine Skalierung von QF2-Clustern auf viele Hundert Knoten ermöglichen
• Integriertes Tiering von heißen/kalten Daten, das Flash-Leistung zu Archivpreisen bietet.

Um zu verstehen, wie SBS diese Vorteile erreicht, müssen wir uns ansehen, wie es funktioniert.

Geschützte virtuelle Blöcke

Die gesamte Speicherkapazität eines QF2-Clusters ist konzeptionell in einem einzigen, geschützten virtuellen Adressraum organisiert, wie hier gezeigt.

Jede geschützte Adresse in diesem Bereich speichert einen 4-KB-Block an Bytes. Mit „geschützt“ meinen wir, dass alle Blöcke wiederherstellbar sind, selbst wenn mehrere Festplatten ausfallen sollten. Der Schutz wird später in diesem Dokument ausführlicher erläutert.

Das gesamte Dateisystem wird im geschützten virtuellen Adressraum von SBS gespeichert, einschließlich Benutzerdaten, Dateimetadaten, Verzeichnisstruktur, Analysen und Konfigurationsinformationen. Mit anderen Worten: Der geschützte Speicher fungiert als Schnittstelle zwischen dem Dateisystem und blockbasierten Daten, die auf angeschlossenen Blockgeräten aufgezeichnet werden. Bei diesen Geräten kann es sich um virtuelle Festplatten handeln, die durch die Kombination von SSDs und HDDs entstehen, oder um Blockspeicherressourcen in der Cloud.

Beachten Sie, dass die Blöcke im geschützten Adressraum auf alle Knoten oder Instanzen des QF2-Clusters verteilt sind. Das QF2-Dateisystem sieht jedoch nur eine lineare Anordnung vollständig geschützter Blöcke.

Datenschutz auf Basis von Löschcodierung

Der Schutz vor Datenverlust im Falle eines Festplattenausfalls umfasst immer eine Form der Redundanz oder Duplizierung von Informationen auf mehreren Speichergeräten. Die einfachste Form des Datenschutzes ist die Spiegelung. Spiegelung bedeutet, dass zwei oder mehr vollständige Kopien der zu schützenden Daten vorhanden sind. Jede Kopie befindet sich auf einer anderen Festplatte, sodass sie wiederhergestellt werden kann, wenn eine der Festplatten ausfällt.

Spiegelung ist einfach zu implementieren, hat jedoch Nachteile im Vergleich zu moderneren Schutztechniken. Die Spiegelung verschwendet den zum Schutz der Daten erforderlichen Speicherplatz und behandelt nur den Ausfall einer einzelnen Festplatte, was im Allgemeinen kein ausreichend hohes Maß an Sicherheit darstellt, da die Knotendichte und die Clustergröße zunehmen.

Weitere Strategien zum Datenschutz sind: RAID-Striping. RAID ist mit einer äußerst komplexen Verwaltung und langsamen Wiederherstellungszeiten verbunden, die den Administrator dazu zwingen, zwischen einer unannehmbar langen Wiederherstellung und einer unannehmbaren Speichereffizienz zu wählen.5

SBS implementiert seinen blockbasierten Datenschutz mit einer effizienten Technik namens Löschcodierung (EG). SBS verwendet Reed-Solomon-Codes. EC ist schneller, konfigurierbarer und platzsparender als Alternativen wie Spiegelung und RAID-Striping.

EC kodiert Blockdaten mithilfe redundanter Segmente, die auf verschiedenen physischen Medien gespeichert werden. Aufgrund der Effizienz von EC steht im Vergleich zu RAID- und Spiegelungsschemata mehr Speicherplatz für Daten zur Verfügung, was die Kosten pro nutzbarem TB senkt.

Erasure Coding kann mit Kompromissen hinsichtlich Leistung, Wiederherstellungszeit bei ausgefallenen physischen Medien und der Anzahl zulässiger gleichzeitiger Ausfälle konfiguriert werden. In diesem Artikel verwenden wir die Notation (m, n), um eine bestimmte EC-Konfiguration anzugeben, wobei m die Gesamtzahl der Blöcke physischer Medien angibt, die zum sicheren Codieren von n Benutzerblöcken verwendet werden. Die Kodierung hat die Eigenschaft, dass bis zu m – n Blöcke ohne Verlust von Nutzdaten zerstört werden können. Mit anderen Worten: Das Überleben einer beliebigen Sammlung von n Festplatten reicht aus, um alle Benutzerdaten wiederherzustellen, selbst wenn einige der ausgefallenen Festplatten Benutzerdaten enthielten. Die Effizienz der Kodierung kann als Anzahl n/m oder als Verhältnis der Benutzerblöcke geteilt durch alle Blöcke berechnet werden.

EC ist am einfachsten mit Beispielen zu verstehen. Hier ist ein einfaches Beispiel namens (3,2)-Kodierung.

Eine (3,2)-Codierung erfordert drei Blöcke (m = 3), die auf drei verschiedenen physischen Geräten gespeichert sind, um zwei Blöcke (n = 2) sicher zu codieren. Zwei der Blöcke enthalten die Benutzerdaten, die wir schützen möchten, und der dritte wird als Paritätsblock bezeichnet. Der Inhalt des Paritätsblocks wird durch den Löschcodierungsalgorithmus berechnet. Sogar dieses einfache Schema ist effizienter als das Spiegeln – Sie schreiben nur einen Paritätsblock für jeweils zwei Datenblöcke. Bei einer (3, 2)-Codierung sind die Benutzerdaten in den Blöcken 1 und 2 sicher, wenn die Platte, die einen der drei Blöcke enthält, ausfällt.

So funktioniert das. Wenn Datenblock 1 verfügbar ist, lesen Sie ihn einfach aus. Das Gleiche gilt für Datenblock 2. Wenn jedoch Datenblock 1 ausgefallen ist, liest das EC-System Datenblock 2 und den Paritätsblock und rekonstruiert den Wert von Datenblock 1 mithilfe der Reed-Solomon-Formel (was in diesem speziellen Beispiel der Fall ist). nur bitweises XOR). Wenn sich Datenblock 2 auf der ausgefallenen Festplatte befindet, lesen die Systeme gleichermaßen Datenblock 1 und den Paritätsblock. SBS stellt sicher, dass sich die Blöcke auf verschiedenen Spindeln befinden, sodass das System gleichzeitig aus Blöcken lesen kann.

Eine (3,2)-Kodierung hat eine Effizienz von 2/3 (n/m) oder 67 %. Obwohl die 50-prozentige Effizienz der Spiegelung in Bezug auf die Datenspeicherung besser ist, kann die (3,2)-Kodierung immer noch nur vor einem Ausfall einer einzelnen Festplatte schützen.

QF2 verwendet mindestens (6, 4)-Kodierung, die ein Drittel mehr Benutzerdaten im gleichen Speicherplatz wie bei der Spiegelung speichert, aber zwei Festplattenausfälle tolerieren kann, statt nur einem, wie dies bei der Spiegelung der Fall ist. Selbst wenn zwei Blöcke mit Benutzerdaten nicht verfügbar sind, muss das System nur die beiden verbleibenden Datenblöcke und die beiden Paritätsblöcke lesen, um die fehlenden Daten wiederherzustellen.

Verteilung geschützter virtueller Blöcke auf Knoten

Bei der Implementierung von EC in Systemen mit enormer Skalierbarkeit sind viele praktische Überlegungen zu berücksichtigen. Um das Schreiben der erforderlichen Paritätsblöcke zu vereinfachen (und um Daten wiederherzustellen, wenn eine Festplatte ausfällt), unterteilt SBS seinen virtuellen Adressraum aus 4-KByte-Blöcken in logische Segmente, die als geschützte Geschäfte oder Pstores bezeichnet werden.

SBS verwaltet jeden Pstore einzeln, wodurch das Zuordnungsschema, das den geschützten Adressraum den Festplatten zuordnet, flexibler wird. Alle Pstores haben die gleiche Größe. Der Datenschutz wird vollständig auf der Pstore-Ebene des Systems implementiert.

Ein Pstore kann man sich als eine Tabelle vorstellen, die Bereiche geschützter virtueller Blockadressen zusammenhängenden Speicherbereichen zuordnet, die sich auf virtuellen Festplatten der Knoten des QF2-Clusters befinden. Die angrenzenden Regionen werden Bstores genannt.

Die Zuordnung von Pstores zu Bstores wird von jedem Knoten des Clusters gespeichert. Aus Gründen der Zuverlässigkeit verwenden die Knoten des Clusters einen verteilten Algorithmus namens Paxos um den Konsens über global geteiltes Wissen wie die Pstore-to-Bstore-Karte aufrechtzuerhalten. Der Cluster bildet ein Quorum von Knoten, um die Sicherheit der kritischen Datenstrukturen des Clusters zu gewährleisten.

Jeder Bstore verwendet ein Segment einer bestimmten virtuellen Festplatte (d. h. der Bstore ist einem bestimmten SSD- und HDD-Paar zugeordnet). Jedem Bstore wird zusammenhängender Speicherplatz auf der zugehörigen Festplatte zugewiesen, während der Speicherplatz auf der zugehörigen SDD des Bstore dynamisch zugewiesen wird. Metadaten zu einem Bstore sind auch auf der zugehörigen SSD vorhanden. Bstore-Metadaten umfassen Informationen wie die verwendeten Adressen und eine Karte, die angibt, welche Blockadressen im Bstore auf den SSD-Speicher verweisen und welche sich auf der Festplatte befinden.

Beim Lesen oder Schreiben entscheidet der Pstore, auf welche Bstores zugegriffen werden muss.

Wenn ein Client des Dateisystems einen Schreibvorgang initiiert, geht dieser als Rohdatenstrom an SBS. Das System ermittelt, in welche Bstores die Daten geschrieben werden sollen, berechnet die Paritätsdaten und schreibt sowohl die Rohdaten als auch die Paritätsdaten gleichzeitig auf die SSDs, selbst wenn sich die SSDs auf vielen verschiedenen Knoten befinden. Sobald die Daten geschrieben wurden, erhält der Client eine Bestätigung, dass der Schreibvorgang stattgefunden hat.

Datenblöcke, die Benutzerdaten und Paritätsblöcke enthalten, werden beide in Bstores geschrieben. Ein bestimmter Bstore enthält während seiner Lebensdauer entweder Paritätsblöcke oder Datenblöcke, aber nicht beides. Da EC auf der Pstore-Ebene von SBS implementiert ist, verhalten sich Bstores, die Paritätsblöcke enthalten, und Bstores, die Datenblöcke enthalten, identisch.

Die einem Bstore zugewiesene Speichermenge hängt von der Wahl des EC ab. Um die Pstore-Größe konsistent zu halten, ändert sich die Bstore-Größe des Systems entsprechend dem Codierungsschema. Wenn der Pstore beispielsweise 70 GB groß ist, dann ist bei (6,4)-Kodierung jeder Bstore etwa 17.5 GB groß, was den Pstore in 4 Bstores aufteilt. Bei der (10, 8)-Kodierung sind die Bstores etwa halb so groß.

In der Cloud verwendet QF2 mit einer Ausnahme dasselbe Datenschutzschema wie vor Ort. Vor Ort erfordert das Datenschutzschema, dass sich in einem Cluster mindestens vier Knoten befinden. In der Cloud ist es möglich, einen Einzelknoten-Cluster zu haben, da QF2 die integrierte Spiegelung nutzen kann, die in jedem elastischen Speicherblock vorhanden ist. QF2-Cluster mit einem Knoten in der Cloud verwenden (5, 4) Erasure Coding.

Schnelle Umbauzeiten

Die Wiederherstellungszeiten von QF2 werden in Stunden gemessen. Im Gegensatz dazu betragen die Wiederherstellungszeiten bei älteren Speichersystemen, die für Workloads mit deutlich weniger Datenmengen ausgelegt sind, Tage. Große Mengen an Dateien, gemischte Arbeitslasten und eine zunehmende Festplattendichte haben alle zu der Krise bei den Wiederherstellungszeiten für ältere Speichergeräte beigetragen. Der dramatische Vorteil von QF2 bei den Wiederherstellungszeiten ist ein direktes Ergebnis des fortschrittlichen blockbasierten Schutzes von SBS.

Blockbasierter Schutz ist ideal für die modernen Arbeitslasten von heute, bei denen es Petabytes an Daten und Millionen von Dateien gibt, von denen viele klein sind. Das SBS-Schutzsystem muss keine zeitaufwändigen Baumdurchläufe oder Datei-für-Datei-Neuerstellungsvorgänge durchführen. Stattdessen funktionieren die Wiederherstellungsvorgänge auf den Pstores. Das Ergebnis ist, dass die Wiederherstellungszeiten nicht von der Dateigröße beeinflusst werden. Kleine Dateien werden genauso effizient verarbeitet wie große Dateien, und der Schutz von Millionen von Dateien ist durchaus machbar.

Darüber hinaus ist QF2 so konzipiert, dass die Wiederherstellungszeiten nicht durch die Clustergröße beeinträchtigt werden. Tatsächlich ist das Gegenteil der Fall. In QF2 haben größere Cluster schnellere Wiederherstellungszeiten als kleinere Cluster. Der Grund dafür ist, dass SBS den Aufwand für die Wiederherstellungsberechnung auf die Knoten des Clusters verteilt. Je mehr Knoten, desto weniger Arbeit muss jeder Knoten während einer Neuerstellung leisten.

Ältere Speichergeräte mit langsamen Wiederherstellungszeiten sind anfällig für zusätzliche Ausfälle, die während des längeren Wiederherstellungsprozesses auftreten können. Mit anderen Worten: Langsame Wiederherstellungszeiten wirken sich negativ auf die Zuverlässigkeit aus. In der Regel kompensieren Administratoren dies durch Überbereitstellung (d. h. Verringerung der Effizienz durch Hinzufügen von Datenredundanz). Dank der schnellen Wiederherstellungszeiten von QF2 können Administratoren ihre MTTDL-Ziele (Mean Time To Data Loss) ohne große Redundanz einhalten, was sowohl Geld als auch Zeit spart.

Wiederaufbau der Pstores

Wenn eine Festplatte ausfällt, ist der geschützte Speicher weiterhin vorhanden. Es kann jederzeit gelesen und geschrieben werden. Bei einigen Pstores fehlen jedoch oder sind beschädigte Bstores. Diese werden als degradierte Pstores bezeichnet. Aufgrund von EC können Sie die beeinträchtigten Pstores weiterhin lesen, die Daten sind jedoch nicht mehr vollständig geschützt. Mit anderen Worten: Beim ersten Ausfall haben Sie zwar immer noch die Datenintegrität, sind aber dem Datenverlust um eine Festplatte näher.

Um die Daten erneut zu schützen, arbeitet das System Pstore für Pstore (und nicht Datei für Datei mit RAID-Gruppen, wie in älteren Systemen), um die Bstores wiederherzustellen, die sich auf dem ausgefallenen Festplattenlaufwerk befanden. SBS weist eine kleine Menge zusätzlichen Speicherplatz zu, sodass hierfür Platz vorhanden ist. Dies nennt man Sparen.

Da die globale Pstore-zu-Bstore-Zuordnung die ID der dem Bstore zugeordneten virtuellen Festplatte enthält, können Sie anhand dieser Informationen leicht erkennen, welche Pstores verarbeitet werden müssen, wenn eine bestimmte Festplatte ausfällt. Da die Karte, die pstores mit bstores verknüpft, klein genug ist, um im Speicher jedes Knotens zu liegen, können Knoten virtuelle Blockadressen schnell von pstore in bstore übersetzen.

Während des Wiederherstellungsprozesses liest und schreibt SBS nacheinander Bstores. Da Bstores zusammenhängend auf der Festplatte angeordnet sind, können beschädigte Pstores sehr schnell wiederhergestellt werden. Sequentielle Vorgänge sind viel schneller als viele kleine E/A-Vorgänge, die langsam sein und zu Festplattenkonflikten führen können. Der Wiederherstellungsprozess von SBS ist effizient – ​​Festplatten sind während des Wiederherstellungsprozesses jeweils an genau einem Lese- oder Schreibstrom beteiligt. Es ist kein Random-I/O erforderlich. Außerdem sind Bstores klein genug, sodass die Arbeit zum erneuten Schützen effizient über den gesamten Cluster verteilt wird.

Normale Dateivorgänge, die von Neuerstellungen nicht betroffen sind

In älteren Dateisystemen wirken sich Sperrenkonflikte auf die Wiederherstellungszeiten aus und verlangsamen die Standardvorgänge des Dateisystems während der Wiederherstellung. Dies liegt daran, dass diese Dateivorgänge mit den Rebuild-/Reprotect-Threads konkurrieren. QF2 verwendet Schreibebenen mit unabhängigen Sperrschemata, sodass Wiederherstellungsvorgänge nicht mit der normalen Nutzung des Dateisystems in Konflikt geraten.

Wenn ein Fehler auftritt, macht es keinen Sinn, in die unvollständigen Bstores in den beeinträchtigten Pstores zu schreiben. Die neuen Schreibvorgänge wären nicht vollständig geschützt und würden die Arbeit zur Wiederherstellung des Bstores erschweren. Während des Wiederherstellungsvorgangs darf es jedoch zu keinen Ausfallzeiten des Clusters kommen. Daher können vom Benutzer initiierte Schreibvorgänge nicht darauf warten, dass ein Pstore erneut geschützt wird.

Um diese Schreibvorgänge durchzuführen, fügt das System dem beeinträchtigten Pstore eine neue Ebene virtueller Bstores hinzu. Dies wird als „Verschieben einer Ebene“ bezeichnet. Schreibvorgänge gehen in die neue Ebene von Bstores und Lesevorgänge kombinieren die Werte aus jeder Ebene. Hier ist ein Beispiel.

Neue Schreibvorgänge werden in die oberste Ebene der Bstores verschoben. Ein Lesevorgang kombiniert die Werte der oberen und unteren Ebene mithilfe von EC. Sobald der Bstore wiederhergestellt ist, verschwindet die Push-Schicht. Die Schichten werden unter Verwendung von Komponenten des SBS-Transaktionssystems so aufgebaut, dass sie nicht blockierend sind.

Kleine Dateien sind genauso effizient wie große Dateien

Da das QF2-Dateisystem blockbasierten Schutz verwendet, sind kleine Dateien genauso effizient wie große Dateien. Sie können Stripes mit anderen Dateien teilen und den Schutz teilen. Jede Datei besteht aus den Datenblöcken, mindestens einem Inode-Block und allen anderen erforderlichen Blöcken. Sehr kleine Dateien werden in den Inode-Block eingebunden. Das System verwendet 4K-Blöcke und alle Blöcke sind mit dem Systemschutzverhältnis geschützt.

Die Effizienz von QF2 bei kleinen Dateien ist ein großer Vorteil im Vergleich zu älteren Speichergeräten, die eine ineffiziente Spiegelung für kleine Dateien und Systemmetadaten verwenden.

Die gesamte bereitgestellte Kapazität ist für Benutzerdateien verfügbar

QF2-Benutzerdateien können 100 % der bereitgestellten Kapazität belegen, während beim Legacy-Scale-Out nur die Verwendung von 80 % bis 85 % empfohlen wird. Der blockbasierte Schutz von QF2 erfordert keine vom Benutzer bereitgestellte Kapazität für den erneuten Schutz, abgesehen von einer kleinen Menge Speicherplatz zum Sparen, der von der vom Benutzer bereitgestellten Kapazität ausgeschlossen ist. Im Gegensatz dazu implementieren ältere Speichergeräte den Schutz entweder mit festen RAID-Gruppen oder mit Erasure Coding auf Datei-für-Datei-Basis, was bedeutet, dass der erneute Schutz auch auf Dateiebene erfolgt und für die Wiederherstellung vom Benutzer bereitgestellte Kapazität erforderlich ist.

Darüber hinaus meldet das QF2-Dateisystem genau die für Benutzerdateien verfügbare Kapazität. Auch diese Vorhersehbarkeit ist eine Folge des blockbasierten Schutzes. In älteren Systemen hängt die Speichernutzung von der Dateigröße ab, daher können diese Systeme nur über den Rohspeicherplatz berichten – Administratoren müssen raten, wie viel Speicherplatz sie tatsächlich haben.

Wenn Sie QF2 mit älteren Systemen vergleichen, sollten Sie berücksichtigen, wie viel vom Benutzer bereitgestellte Kapazität tatsächlich für die Nutzung in den einzelnen Systemtypen verfügbar ist.

Transaktionen

In SBS sind Lese- und Schreibvorgänge im geschützten virtuellen Adressraum transaktional. Das bedeutet, dass beispielsweise, wenn eine QF2-Dateisystemoperation eine Schreiboperation erfordert, die mehr als einen Block umfasst, die Operation entweder alle relevanten Blöcke oder keinen davon schreibt. Atomare Lese- und Schreibvorgänge sind für die Datenkonsistenz und die korrekte Implementierung von Dateiprotokollen wie SMB und NFS unerlässlich.

Für eine optimale Leistung verwendet SBS Techniken, die Parallelität und verteiltes Rechnen maximieren und gleichzeitig die Transaktionskonsistenz von E/A-Vorgängen aufrechterhalten. SBS ist beispielsweise darauf ausgelegt, serielle Engpässe zu vermeiden, bei denen Vorgänge in einer Reihenfolge und nicht parallel ablaufen würden.

Das Transaktionssystem von SBS nutzt Prinzipien des ARIES-Algorithmus für nicht blockierende Transaktionen, einschließlich der Vorabschreibprotokollierung, der Wiederholung des Verlaufs bei Rückgängig-Aktionen und der Protokollierung von Rückgängig-Aktionen. Allerdings weist die Implementierung von Transaktionen durch SBS mehrere wichtige Unterschiede zu ARIES auf.

SBS macht sich die Tatsache zunutze, dass vom QF2-Dateisystem initiierte Transaktionen vorhersehbar kurz sind, im Gegensatz zu Allzweckdatenbanken, bei denen Transaktionen möglicherweise langlebig sind. Ein Nutzungsmuster mit kurzlebigen Transaktionen ermöglicht es SBS, das Transaktionsprotokoll aus Effizienzgründen häufig zu kürzen. Kurzlebige Transaktionen ermöglichen eine schnellere Auftragsbestellung.

Außerdem sind die Transaktionen von SBS stark verteilt und erfordern keine global definierte Gesamtreihenfolge von Sequenznummern im ARIES-Stil für jeden Transaktionsprotokolleintrag. Stattdessen sind Transaktionsprotokolle in jedem der Bstores lokal sequentiell und werden auf globaler Ebene mithilfe eines partiellen Ordnungsschemas koordiniert, das Einschränkungen bei der Commitment-Reihenfolge berücksichtigt.

Qumulo DB verwendet ein Two-Phase Locking (2PL)-Protokoll, um Serialisierbarkeit für eine konsistente Commitment-Reihenfolge zu implementieren. Serialisierbare Operationen werden von verteilten Verarbeitungseinheiten (bstores) ausgeführt und haben die Eigenschaft, dass die beabsichtigte Reihenfolge der Operationen im Nachhinein rekonstruiert werden kann. Der Vorteil des SBS-Ansatzes besteht darin, dass für transaktionale E/A-Vorgänge nur ein absolutes Minimum an Sperren verwendet wird, wodurch QF2-Cluster auf viele Hundert Knoten skaliert werden können.

Hot/Cold-Tiering zur Lese-/Schreiboptimierung

SBS umfasst integriertes Tiering von heißen und kalten Daten, um die Lese-/Schreibleistung zu optimieren.

Beim Betrieb vor Ort nutzt QF2 die Geschwindigkeit von Solid-State-Laufwerken (SSDs) und die Kosteneffizienz von Festplattenlaufwerken (HDDs). SSDs werden auf jedem Knoten mit handelsüblichen Festplatten gepaart. Dieses Paar wird als virtuelle Festplatte bezeichnet. Für jede Festplatte im System gibt es eine virtuelle Festplatte.

Daten werden immer zuerst auf die SSDs geschrieben. Da Lesevorgänge typischerweise auf kürzlich geschriebene Daten zugreifen, fungieren die SSDs auch als Cache. Wenn die SSDs zu etwa 80 % voll sind, werden weniger häufig aufgerufene Daten auf die Festplatten verschoben. Die Festplatten bieten Kapazität und sequentielles Lesen/Schreiben großer Datenmengen.

Bei der Ausführung in der Cloud optimiert QF2 die Nutzung von Blockspeicherressourcen, indem es leistungsstarken Blockspeicher mit kostengünstigem Blockspeicher mit geringerer Leistung kombiniert.

Schauen wir uns die folgenden Aspekte der Hot/Cold-Stufe von SBS an:

• Wie und wo Daten geschrieben werden
• Wo Metadaten geschrieben werden
• Wie Daten abgelaufen sind
• Wie Daten zwischengespeichert und gelesen werden

Das erste Schreiben

Um in einen Cluster zu schreiben, sendet ein Client einige Daten an einen Knoten. Dieser Knoten wählt einen Pstore oder mehrere Pstores aus, in denen die Daten gespeichert werden sollen, und schreibt in Bezug auf die Hardware immer auf die SSDs oder in den Blockspeicher mit niedriger Latenz, wenn Cloud-Ressourcen verwendet werden. (Denken Sie daran, dass wir mit „SSD“ sowohl lokale SSDs als auch Blockspeicher mit geringer Latenz in der öffentlichen Cloud meinen. Das Verhalten ist ähnlich.) Diese SSDs befinden sich auf mehreren Knoten.

Alle Schreibvorgänge erfolgen auf SSDs; SBS schreibt nie direkt auf die Festplatte. Selbst wenn eine SSD voll ist, schafft das System Platz für die neuen Daten, indem es zuvor zwischengespeicherte Daten löscht.

Umgang mit Metadaten

Im Allgemeinen verbleiben Metadaten auf der SSD. Daten werden normalerweise an der niedrigsten verfügbaren Adresse in einen Bstore geschrieben, sodass die Daten vom Anfang des Bstores bis zum Ende wachsen. Metadaten beginnen am Ende des Bstores und wachsen zum Anfang hin. Das bedeutet, dass sich alle Metadaten rechts von den Daten befinden. Hier ist eine Darstellung, wo sich Metadaten in einem Bstore befinden.

QF2 weist bis zu 1 % des Bstores auf der SSD den Metadaten zu und lässt diese nie ablaufen. Nichts von diesem 1 % geht an die Festplatte. Wenn die Metadaten jemals über 1 % anwachsen, könnten sie ablaufen, aber bei einer typischen Arbeitslast sind etwa 0.1 % Metadaten vorhanden. Der Platz wird nicht verschwendet, wenn nicht genügend Metadaten vorhanden sind, um ihn zu füllen. Auch Daten können diesen Platz nutzen.

Ablaufende Daten

Irgendwann benötigt das System mehr Speicherplatz auf der SSD, sodass einige Daten abgelaufen sind oder von der SSD auf die Festplatte verschoben wurden. Die Daten werden von der SSD auf die Festplatte kopiert und dann, sobald sie auf der Festplatte sind, von der SSD gelöscht.

Der Ablauf beginnt, wenn eine SSD zu mindestens 80 % voll ist, und stoppt, wenn sie wieder weniger als 80 % voll ist. Der 80 %-Schwellenwert ist eine Heuristik, die die Leistung optimiert – Schreibvorgänge sind schneller, wenn die SSDs zwischen 0 % und 80 % liegen und nicht gleichzeitig Abläufe stattfinden.

Wenn Daten von einer SSD auf die Festplatte verschoben werden, optimiert SBS die Schreibvorgänge sequentiell auf die Festplatte, um die Festplattenleistung zu optimieren. Bursts großer, zusammenhängender Bytes sind die effizienteste Methode zum Schreiben auf HDD.t

Daten zwischenspeichern

Die folgende Abbildung zeigt alle QF2-Caches. Alles in Grün ist ein Ort, an dem Daten gespeichert werden können, und zwar auf SSD oder HDD.

QF2-E/A-Operationen verwenden drei verschiedene Arten von Caches. Der Client hat immer etwas Cache auf seiner Seite und es gibt zwei Arten von Caches auf den Knoten. Einer davon ist der Transaktionscache, der als Dateisystemdaten betrachtet werden kann, die der Client direkt anfordert. Der andere Typ ist der Festplatten-Cache, bei dem es sich um Blöcke dieser Festplatte handelt, die im Speicher gehalten werden.

Nehmen wir als Beispiel an, dass ein Client, der mit Knoten 1 verbunden ist, einen Lesevorgang für Datei der SSDs von Knoten 1. Knoten 2 liest die Daten und legt sie in den Festplatten-Cache ab, der dieser SSD zugeordnet ist. Knoten 2 antwortet Knoten 2 und sendet die Daten. Zu diesem Zeitpunkt gelangen die Daten in den Transaktionscache von Knoten 2, der den Client darüber benachrichtigt, dass er über die Daten für Datei X verfügt.

Der Festplatten-Cache wird auf dem Knoten aufgefüllt, an den die Festplatte angeschlossen ist. Der Transaktionscache wird auf dem Knoten aufgefüllt, mit dem der Client verbunden ist. Der Festplattencache enthält immer Blöcke und der Transaktionscache enthält Daten aus den tatsächlichen Dateien. Der Transaktionscache und der Festplattencache teilen sich den Speicher, obwohl beiden keine bestimmte Menge zugewiesen ist.

Industriestandardprotokolle

QF2 verwendet die Standardprotokolle NFSv3 und SMBv2.1.

REST API

QF2 enthält eine umfassende REST-API. Tatsächlich werden alle in der QF2-GUI dargestellten Informationen aus Aufrufen der QF2-REST-API generiert. Eine Registerkarte innerhalb der GUI bietet eine selbstdokumentierende Ressource der verfügbaren REST-API-Aufrufe. Sie können mit der API experimentieren, indem Sie Aufrufe für den Live-Cluster ausführen und die Anforderungen und Ergebnisse in Echtzeit überprüfen. Hier ist ein Beispiel-Screenshot.

Alle auf der Registerkarte „Analytics“ in der GUI angezeigten Informationen können programmgesteuert mit REST-Aufrufen der API abgerufen und extern in einer Datenbank gespeichert oder an eine andere Anwendung wie Splunk oder Tableau gesendet werden. Die meisten Dateisystemvorgänge können auch mit der REST-API aufgerufen werden.

Zusammenfassung

Wir hoffen, dass dieser Artikel das Innenleben von QF2 entmystifiziert hat und Ihnen einen Einblick gegeben hat, warum Durchbrüche bei Leistung und Skalierbarkeit von QF2 möglich sind. Wenn Sie weitere Informationen wünschen, wenden Sie sich bitte an uns kontaktieren Sie uns.

Wichtige Punkte

Hier sind die wichtigsten Punkte, die in diesem Papier angesprochen werden.

• Die Datenmengen nehmen explosionsartig zu und moderne Workloads haben eine Größe von Petabyte, können Milliarden von Dateien umfassen, und diese Dateien haben unterschiedliche Größen.
• Die meisten Speichersysteme nutzen jahrzehntealte Technologien, die nie für die Bewältigung moderner Arbeitslasten gedacht waren.
• QF2 ist ein modernes Speichersystem, das speziell für moderne Workloads entwickelt wurde.
• QF2 läuft auf Standard-Hardware vor Ort und in der Cloud.
• QF2 verfügt über eine Hybridarchitektur, die SSDs und HDDs verwendet.
• QF2 verwendet ein Blockschutzschema, das unterhalb des eigentlichen Dateisystems arbeitet.
• QF2 verfügt über schnelle Wiederherstellungszeiten, gemessen in Stunden. Sie sind mit Abstand die schnellsten in der Branche.
• Benutzerdateien können bis zu 100 % der bereitgestellten Kapazität beanspruchen.
• Kleine Dateien sind genauso effizient wie große Dateien.
• Das gesamte Dateisystem liegt als einzelnes Volume vor.
• QF2 wendet auf sein Dateisystem dieselben Techniken an, die von großen, verteilten Datenbanken verwendet werden.
• Echtzeitanalysen geben Einblick in das, was gerade im Dateisystem passiert.
• Es gibt genaue Berichte darüber, wie viel nutzbarer Raum verfügbar ist.
• Administratoren können Kontingente in Echtzeit anwenden.
• Administratoren wissen, wie viel Speicherplatz sie durch das Löschen von Snapshots tatsächlich sparen.
• QF2 umfasst asynchrone Datenreplikation im großen Maßstab.
• QF2 nutzt Standardprotokolle wie NFS und SMB und beinhaltet eine REST-API.