CMG Brasil

Pomegranate ist ein neuartiges verteiltes Dateisystem, das auf einem verteilten Tabellenspeicher aufbaut und sich sehr ähnlich wie ein NoSQL-System verhält. Es zielt darauf ab, die Leistung des Zugriffs auf winzige Objekte zu erhöhen, um Anwendungen wie Online-Foto- und Mikroblog-Dienste zu unterstützen, die eine hohe Gleichzeitigkeit, einen hohen Durchsatz und eine geringe Latenzzeit erfordern. Ihre Tests scheinen darauf hinzuweisen, dass es funktioniert:

Wir haben gezeigt, dass das Dateisystem über Tabellenspeicher bei hochgradig gleichzeitigem Zugriff gut funktioniert. In unserem Testcluster haben wir einen linearen Anstieg von mehr als 100.000 aggregierten Lese- und Schreibanforderungen pro Sekunde (RPS) beobachtet.

Anstatt wie fast alle anderen K-V-Speicher auf dem Dateisystem zu sitzen, ist Pomegranate in das Dateisystem integriert. Die Idee ist, dass die Dateisystem-API für jede Plattform gleich ist, so dass keine separate API erforderlich ist. Jede Anwendung könnte es ohne weiteres verwenden.

Die Funktionen von Pomegranate sind:

• Es handhabt Milliarden von kleinen Dateien effizient, sogar in einem Verzeichnis;
• Es bietet eine separate und skalierbare Caching-Schicht, die Snapshot-fähig ist;
• Die Speicherschicht verwendet einen strukturierten Log-Speicher, um kleine Dateischreibvorgänge zu absorbieren und die Festplattenbandbreite zu nutzen;
• Ein globaler Namensraum für kleine und große Dateien;
• Spaltenweiser Speicher, um zeitliche und räumliche Lokalität auszunutzen;
• Verteilter erweiterbarer Hash, um Metadaten zu indizieren;
• Snapshot-fähiges und rekonfigurierbares Caching, um Parallelität und Fehlertoleranz zu erhöhen;
• Pomegranate sollte das erste Dateisystem sein, das über Tabellenspeicher aufgebaut ist, und die Aufbauerfahrung sollte für die Dateisystemgemeinschaft wertvoll sein.

Can Ma, der die Forschung an Pomegranate leitet, war so freundlich, einem kurzen Interview zuzustimmen.

Können Sie bitte einen Überblick über die Architektur geben und darüber, was Sie tun, das cool und anders ist?

Grundsätzlich gibt es kein verteiltes oder paralleles Dateisystem, das Milliarden von kleinen Dateien effizient handhaben kann. Es ist jedoch absehbar, dass Webanwendungen (wie E-Mail, Fotos und sogar Videos) und Bio-Computing (Gensequenzierung) massive Zugriffe auf kleine Dateien benötigen. In der Zwischenzeit ist die Dateisystem-API allgemein genug und wird von den meisten Programmierern gut verstanden.

Daher wollen wir ein Dateisystem entwickeln, das Milliarden kleiner Dateien verwalten kann und einen hohen Durchsatz bei gleichzeitigen Zugriffen bietet. Obwohl Pomegranate für den Zugriff auf kleine Dateien konzipiert ist, unterstützt es auch große Dateien. Es baut auf anderen verteilten Dateisystemen wie Lustre auf und verwaltet nur den Namespace und kleine Dateien. Wir wollen einfach auf den „Schultern von Giganten“ stehen. Siehe die Abbildung unten:

Pomegranate hat viele Metadatenserver und Metadatenspeicherserver, um Metadatenanforderungen und Lese-/Schreibanforderungen für kleine Dateien zu bedienen. Die MDSs sind nur eine Caching-Schicht, die Metadaten aus dem Speicher laden und Speicher-Snapshots in den Speicher übertragen. Das Herzstück von Pomegranate ist ein verteiltes Tabellenspeichersystem namens xTable. Es unterstützt schlüsselindizierte mehrspaltige Suchvorgänge. Wir verwenden einen verteilten, erweiterbaren Hash, um den Server anhand des Schlüssels zu lokalisieren, da ein erweiterbarer Hash anpassungsfähiger ist, um nach oben und unten zu skalieren.

In Dateisystemen sind die Verzeichnistabelle und die Inodetabelle immer getrennt, um zwei verschiedene Arten von Nachschlagen zu unterstützen. Die Suche nach dem Pfadnamen wird in der Verzeichnistabelle durchgeführt, während die Suche nach der Inode-Nummer in der Inode-Tabelle durchgeführt wird. Es ist nicht trivial, diese beiden Indizes ständig zu aktualisieren, insbesondere in einem verteilten Dateisystem. Durch die Verwendung von zwei Indizes erhöht sich die Suchlatenz, was für den Zugriff auf kleine Dateien inakzeptabel ist. Normalerweise gibt es im Speicher Caches für dentry und inode, die jedoch nicht einfach erweitert werden können. Bei der Änderung von Metadaten müssen mehrere Speicherorte aktualisiert werden. Um die Konsistenz zu wahren, wird ein Operationsprotokoll eingeführt. Dabei ist das Operationsprotokoll immer ein serieller Punkt für Anfrageströme.

Pomegranate verwendet eine tabellenartige Verzeichnisstruktur, um Verzeichnis- und Inodetabelle zusammenzuführen. Zwei verschiedene Arten von Suchvorgängen werden zu Suchvorgängen nach Schlüssel vereinheitlicht. Für das Dateisystem ist der Schlüssel der Hash-Wert des Eintragsnamens. Hash-Konflikte werden durch eine globale eindeutige ID für jede Datei gelöst. Für jede Aktualisierung müssen wir nur eine Tabelle durchsuchen und aktualisieren. Um das Betriebsprotokoll zu eliminieren, entwickeln und unterstützen wir Speicher-Snapshots, um ein konsistentes Bild zu erhalten. Die schmutzigen Bereiche jedes Snapshots können sicher in den Speicher geschrieben werden, ohne gleichzeitige Änderungen zu berücksichtigen (die gleichzeitigen Aktualisierungen sind COWed.)

Es gibt jedoch einige komplexe Dateisystemoperationen wie mkdir, rmdir, hard link und rename, die berücksichtigt werden sollten. Diese Operationen müssen mindestens zwei Tabellen aktualisieren. Wir implementieren einen zuverlässigen Multisite-Aktualisierungsdienst, um Deltas von einer Tabelle zur anderen zu übertragen. Bei mkdir zum Beispiel wird das Delta(„nlink +1“) an die übergeordnete Tabelle weitergegeben.

Gibt es einzelne Fehlerpunkte?

Es gibt keinen SPOF im Design. Wir verwenden einen Cluster von MDSs, um Metadatenanfragen zu bedienen. Wenn ein MDS abstürzt, werden die Anfragen an andere MDS weitergeleitet (konsistenter Hash und Heartbeats werden verwendet). Metadaten und kleine Dateien werden ebenfalls auf mehrere Knoten repliziert. Diese Replikation wird jedoch durch externe Sync-Tools ausgelöst, die asynchron zu den Schreibvorgängen sind.

Kleine Dateien sind in der Regel der Tod von Dateisystemen, weil die Verzeichnisstruktur nicht gepflegt wird. Wie umgehen Sie das?

Ja, der Zugriff auf kleine Dateien ist in traditionellen Dateisystemen tödlich langsam. Wir ersetzen die traditionelle Verzeichnistabelle (B+-Baum oder Hash-Tree) durch eine verteilte, erweiterbare Hash-Tabelle. Der Name des Verzeichnisses und die Inode-Metadaten werden als Spalten der Tabelle behandelt. Suchanfragen von Clients werden an den richtigen MDS gesendet (oder bei Bedarf weitergeleitet). Um auf eine kleine Datei zuzugreifen, müssen wir also nur auf eine Tabellenzeile zugreifen, um den Speicherort der Datei zu finden. Wir speichern jede kleine Datei sequentiell im nativen Dateisystem. Daher kann ein E/A-Zugriff zum Lesen einer kleinen Datei verwendet werden.

Welche Posix-Api werden unterstützt? Können Dateien gesperrt, gemappt, Symlinks usw. werden?

Zurzeit ist die POSIX-Unterstützung in der Entwicklung. Wir unterstützen Symlinks und mmap-Zugriff. Während flock nicht unterstützt wird.

Warum ein Dateisystem auf Kernel-Ebene und nicht ein K-V-Speicher darüber?

Unser anfängliches Ziel ist es, ein Dateisystem zu implementieren, das mehr bestehende Anwendungen unterstützt. Allerdings unterstützen wir jetzt die K/V-Schnittstelle über xTable. Der AMC-Client ist der Key/Value-Client für Pomegranate (siehe Abbildung der Architektur). Wir unterstützen einfache Prädikate auf Schlüssel oder Wert, z.B. „select * from table where key < 10 and ‚xyz‘ in value“, um die K/V-Paare zu erhalten, deren Wert „xyz“ und Schlüssel < 10 enthält.

Wie sieht es im Vergleich zu anderen verteilten Dateisystemen aus?

Wir wollen die Leistung der kleinen Dateien mit anderen Dateisystemen vergleichen. Allerdings haben wir es noch nicht getestet. Wir werden dies im nächsten Monat tun. Wir glauben jedoch, dass die meisten verteilten Dateisysteme nicht in der Lage sind, massive Zugriffe auf kleine Dateien effizient zu bewältigen.

Werden Indizes und jegliche Art von Abfragen unterstützt?

Im Moment sind diese Unterstützungen noch nicht richtig berücksichtigt.

Funktioniert es über Rechenzentren hinweg, d.h. wie geht es mit Latenzzeiten um?

Pomegranate funktioniert nur in einem Rechenzentrum. WAN-Unterstützung wurde noch nicht in Betracht gezogen.

Es sieht so aus, als ob Sie eine In-Memory-Architektur für Geschwindigkeit verwenden. Können Sie das erläutern?

Wir verwenden eine dedizierte Speicher-Cache-Schicht für Geschwindigkeit. Tabellenzeilen werden als Tabellenscheiben gruppiert. Im Speicher werden die Tabellensl
ices in einer lokalen, erweiterbaren Hash-Tabelle gehasht, um sowohl die Leistung als auch den Platzbedarf zu erhöhen. Wie die folgende Abbildung zeigt,

Klienten stellen eine Anfrage, indem sie den Dateinamen hashen und in der Bitmap nachschlagen. Dann wird ein konsistenter Hash-Ring verwendet, um den Cache-Server (MDS) oder den Storage-Server (MDSL) zu finden. Jede Aktualisierung erhält zunächst die *geöffnete* Transaktionsgruppe und kann nur auf die Tabellenzeile im Speicher angewendet werden. Jede Änderung der Transaktionsgruppe ist atomar. Nachdem alle anstehenden Aktualisierungen abgeschlossen sind, kann die Transaktionsgruppe sicher in den Speicher übertragen werden. Dieser Ansatz ist ähnlich wie Suns ZFS.

Wie wird Hochverfügbarkeit gehandhabt?

Der zentrale Server für die konsistente Hash-Ring-Verwaltung und den Ausfallkoordinator sollte durch den Paxos-Algorithmus repliziert werden. Wir planen, ZooKeeper für einen hochverfügbaren zentralen Dienst zu verwenden.
Andere Komponenten sind so konzipiert, dass sie fehlertolerant sind. Abstürze von MDS und MDSL können so konfiguriert werden, dass sie sofort wiederhergestellt werden, indem Anfragen an neue Server weitergeleitet werden (durch Auswahl des nächsten Punktes in einem konsistenten Hash-Ring).

Wie funktioniert das System operativ? Wie werden Knoten zum System hinzugefügt?

Das Hinzufügen von Knoten zur Caching-Schicht ist einfach. Der zentrale Server (R2) fügt den neuen Knoten in den konsistenten Hash-Ring ein. Alle Cache-Server sollten auf diese Änderung reagieren und ihre zwischengespeicherten Tabellenslices einfach ungültig machen, wenn sie von dem neuen Knoten verwaltet werden. Anfragen von Clients werden an den neuen Server weitergeleitet, und eine CH-Ring-Änderungsbenachrichtigung wird huckepack an den Client gesendet, um den neuen Ring vom zentralen Server zu ziehen.

Wie gehen Sie mit großen Dateien um? Ist es für das Streaming von Videos geeignet?

Wie bereits beschrieben, werden große Dateien an andere verteilte Dateisysteme weitergeleitet. Unsere Caching-Schicht wird durch die Streaming-Videodaten nicht belastet.

Noch etwas, was Sie hinzufügen möchten?

Eine weitere Abbildung für das Zusammenspiel der Pomegranate-Komponenten.