Ich habe billigen Cloud-Speicher in ein 1-PB-Laufwerk verwandelt (mit JuiceFS)
BBetter Stack
Computing/SoftwareInternet Technology
Transcript
00:00:00Das ist Juice.FS. Es ist ein hochleistungsfähiges, quelloffenes, verteiltes Dateisystem, das die unendliche Skalierbarkeit von Cloud-Objektspeichern mit der vollen Funktionalität und Geschwindigkeit eines lokalen Dateisystems verbindet.
00:00:14In diesem Video werfen wir einen Blick auf Juice.FS, schauen uns an, wie es funktioniert, und ich zeige Ihnen, wie Sie Ihre eigene lokale, hochleistungsfähige Netzwerkspeicherlösung (NAS) mit Juice.FS aufbauen können.
00:00:24Das wird sicher spannend, also legen wir direkt los.
00:00:30Standard-Objektspeicher wie S3, Google Cloud Storage oder Backblaze B2 sind unglaublich kosteneffizient, aber die Arbeit damit erfordert normalerweise spezielle APIs oder Werkzeuge, die herkömmliche Anwendungs-Workflows unterbrechen.
00:00:48Juice.FS fungiert hierbei als transparente Abstraktionsschicht.
00:00:51Es trennt Ihre Daten von den Metadaten, leitet Rohdatenblöcke direkt an Ihren Cloud-Anbieter weiter und verwaltet das Dateisystem-Layout, Berechtigungen sowie Verzeichnisstrukturen in einer schnellen Datenbank wie Redis, Postgres oder TiKV.
00:01:07Was Juice.FS von herkömmlichen Cloud-Gateways oder Standard-Netzwerkfreigaben unterscheidet, ist diese strikte architektonische Trennung und die aggressive, mehrstufige Caching-Engine.
00:01:19Anstatt Ihre Anwendungen bei jedem Dateizugriff auf Cloud-Netzwerkanfragen mit hoher Latenz warten zu lassen,
00:01:26zerlegt Juice.FS Dateien in kleine, optimierte Blöcke und nutzt eine lokale NVMe- oder SSD-Partition als schnellen Zwischenspeicher.
00:01:35Beim ersten Lesen oder Schreiben einer Datei kommuniziert die Anwendung über das Netzwerk, aber beim zweiten Zugriff werden die Daten sofort vom lokalen Speicher mit Hardware-Geschwindigkeit bereitgestellt.
00:01:47Dadurch können Legacy-Anwendungen, Datenbanken, Machine-Learning-Trainings-Pipelines und Container-Umgebungen direkt auf Objektspeichern laufen, ohne dass auch nur eine Zeile Code geändert werden muss.
00:01:59Das klingt alles großartig, aber lassen Sie uns das selbst testen und sehen, wie es funktioniert.
00:02:04Für diese Demo richte ich einen lokalen NAS ein, der alle meine Daten in meinem eigenen S3-Bucket speichert und Redis als Metadaten-Engine verwendet.
00:02:16Als Erstes müssen Sie eine Redis-Instanz mit Docker starten, was mit diesem Befehl ganz einfach geht.
00:02:24Anschließend initialisieren wir das Dateisystem mit dem juice.FS format-Befehl.
00:02:29Dieser Schritt weist Juice.FS genau an, wie unsere Datenbank auf unseren Speicher-Bucket gemappt werden soll.
00:02:34Wir übergeben den Redis-Verbindungsstring, unseren AWS S3-Bucket-Namen und unsere Cloud-Zugangsdaten.
00:02:41Stellen Sie aber vorher sicher, dass Sie einen S3-Bucket sowie einen Access Key und einen Secret Key erstellt haben, bevor Sie diesen Befehl ausführen.
00:02:48Ich hatte meine bereits im Vorfeld erstellt.
00:02:50Wenn ich das jetzt ausführe, ändert Juice.FS noch nichts direkt in unserem S3-Bucket.
00:02:56Es konfiguriert lediglich das Speicher-Schema innerhalb von Redis und weist unserem neuen virtuellen Dateisystem eine eindeutige UUID zu.
00:03:03Sobald der Formatierungsschritt abgeschlossen ist, binden wir das Gerät mit dem juice.FS mount-Befehl auf unserem lokalen Rechner ein.
00:03:10Wir verweisen Juice.FS auf unsere Redis-Instanz und geben einen lokalen Verzeichnispfad an.
00:03:15In meinem Fall ist das ein Ordner innerhalb meines Home-Verzeichnisses.
00:03:18Bevor Sie diesen Befehl ausführen, gibt es ein wichtiges Detail zu beachten.
00:03:21Wenn Sie einen Mac verwenden, müssen Sie zuerst das Kernel-Extension-Dienstprogramm namens MacFuse installieren, da macOS keine benutzerdefinierten Dateisysteme von Haus aus unterstützt.
00:03:30Dies stellt die grundlegenden Software-Schnittstellen bereit, die Juice.FS benötigt, um mit dem Mac-Betriebssystem zu kommunizieren.
00:03:37Zusätzlich verwende ich hier ein Flag für das Verhältnis des freien Speicherplatzes, da standardmäßig 20 % der Festplattenkapazität reserviert werden, was ziemlich hoch ist.
00:03:47Das weist Juice.FS an, dass es keine neuen Cache-Dateien mehr schreiben darf, sobald der lokale Speicherplatz unter einen bestimmten Prozentsatz der Gesamtkapazität fällt,
00:03:55und stattdessen damit beginnen soll, die ältesten und am wenigsten genutzten Blöcke aggressiv zu löschen.
00:04:01Das verhindert, dass Ihrem lokalen Betriebssystem der Festplattenspeicher vollständig ausgeht.
00:04:05Alles klar.
00:04:06Führen wir den Befehl also aus.
00:04:07Sobald der Befehl ausgeführt wird, registriert das Betriebssystem ein standardmäßiges POSIX-konformes Dateisystem-Mount.
00:04:15Für den Computer sieht es so aus, als hätten wir gerade eine riesige externe Festplatte mit einem Terabyte Speicherplatz angeschlossen.
00:04:23Jetzt kann ich einfach Dateien in dieses Verzeichnis ziehen, als wäre es ein externes Laufwerk.
00:04:28Wenn wir nun zum S3-Bucket-Dashboard gehen, sehen wir, dass Juice.FS unsere Dateien gespeichert und sie in Datenblöcke aufgeteilt hat.
00:04:37All dies geschieht hinter den Kulissen, ohne dass wir schwer arbeiten müssen.
00:04:42Um zu zeigen, wie das Caching funktioniert, führen wir einen Benchmark mit dem klassischen Terminal-Befehl “dd” durch.
00:04:49Falls Sie “dd” noch nicht kennen: Es ist ein eingebautes Werkzeug zum Kopieren von Rohdaten.
00:04:55In diesem speziellen Befehl steht “if” für “input file”, was auf eine der großen Videodateien verweist, die ich auf unser Juice.FS-Laufwerk kopiert habe.
00:05:03Und “of” steht für “output file”.
00:05:06Wir leiten die Daten direkt nach /dev/null weiter. Das ist sozusagen ein schwarzes Loch in unserem Betriebssystem, das Daten sofort verwirft, weil wir sie nicht wirklich kopieren wollen.
00:05:17Wir führen in diesem Beispiel nur einen Benchmark durch.
00:05:19Außerdem setzen wir die Blockgröße auf vier Megabyte, passend dazu, wie Juice.FS die Datenblöcke zerlegt.
00:05:25Schließlich stellen wir dem Befehl das “time”-Utility voran, damit wir sehen, wie lange die Dateiübertragung exakt dauert.
00:05:32Beim ersten Ausführen nennen wir das einen “Cold Read”, da die Datei gerade erst hochgeladen wurde.
00:05:38Unser lokaler Rechner besitzt noch keine Kopie davon.
00:05:41Also muss Juice.FS über das Internet auf unseren S3-Bucket zugreifen, alle diese Vier-Megabyte-Datenblöcke einzeln abrufen und herunterladen.
00:05:50Wie Sie sehen können, dauert der erste Durchlauf bei meiner Verbindung ziemlich lange.
00:05:55Aber sehen Sie, was passiert, wenn wir denselben Befehl ein zweites Mal ausführen.
00:05:59Bum.
00:06:00Da haben wir es.
00:06:01Das Terminal kehrt fast augenblicklich zurück.
00:06:03Der zweite Durchlauf dauerte weniger als eine Sekunde, weil die Daten nun im Cache liegen und wir sie direkt lokal lesen.
00:06:10So funktioniert die mehrstufige Caching-Engine in der Praxis.
00:06:14Während Juice.FS beim ersten Lauf damit beschäftigt war, die Blöcke herunterzuladen, hat es sie stillschweigend auf unsere lokale NVMe-Festplatte kopiert.
00:06:22Beim zweiten Durchlauf wurde das Internet komplett umgangen und die Daten wurden mit lokaler Hardware-Geschwindigkeit abgerufen.
00:06:29So erhalten Sie die unendliche, günstige Speicherkapazität der Cloud kombiniert mit der Latenzfreiheit eines lokalen Laufwerks.
00:06:37In dieser Demo habe ich Videodateien verwendet, aber dies lässt sich auf fast jedes reale Infrastrukturszenario anwenden.
00:06:45Wenn Sie als DevOps-Ingenieur Container-Umgebungen verwalten, können Sie Juice.FS nutzen, um gemeinsamen persistenten Speicher für einen Kubernetes-Cluster bereitzustellen.
00:06:54Anstatt für jeden Knoten teuren Cloud-Block-Speicher zu bezahlen, können alle Ihre Pods gleichzeitig dasselbe Juice.FS-Volume einbinden.
00:07:03Das ermöglicht das Teilen von Konfigurationsdateien, Assets oder Benutzer-Uploads weltweit bei extrem niedrigen Kosten.
00:07:10Es ist zudem ein großer Gewinn für Machine-Learning- und Data-Science-Pipelines.
00:07:14Wenn Sie einen riesigen Datensatz haben, zum Beispiel hunderte Gigabyte an Trainingsbildern in einem S3-Bucket, erfordert das Trainieren eines Modells normalerweise das vorherige Herunterladen des gesamten Datensatzes, was Zeit und Speicherplatz verschwendet.
00:07:30Mit Juice.FS kann Ihr Trainingsskript jedoch sofort starten.
00:07:35Die Pipeline liest die Daten sequenziell durch das Mount-Verzeichnis und Juice.FS übernimmt das Hochdurchsatz-Streaming und lokales Caching im Hintergrund, ohne lokale Speicherengpässe.
00:07:49Und es gibt noch eine coole Sache, die ich Ihnen zeigen möchte.
00:07:51Sie können auch ganz einfach Metriken mit Better Stack mit Ihrem Dateisystem verbinden.
00:07:55Jedes Mal, wenn Sie ein Juice.FS-Volume einbinden, startet es im Hintergrund automatisch einen lokalen Prometheus-kompatiblen Metrik-Server.
00:08:03Wenn Sie diese URL im Browser aufrufen, sehen Sie alle Metriken im Klartext, die jeden Cache-Treffer, die Lesedauer und S3-Anfragefehler in Echtzeit erfassen.
00:08:13Um diese Telemetriedaten direkt in unser Dashboard zu leiten, nutzen wir das native Prometheus-Scraping von Better Stack.
00:08:21Zuerst gehen wir zu “Sources” und verbinden Juice.FS als Quelle.
00:08:25Wählen Sie “Prometheus scrape” auf dem Metrik-Tab und klicken Sie auf “Connect Source”.
00:08:31Nun müssen wir unsere Logs einlesen.
00:08:33Davor müssen wir jedoch einen sicheren öffentlichen Tunnel zu unserem lokalen Metrik-Port mit einem Werkzeug wie ngrok öffnen und die entsprechende URL einfügen.
00:08:43Um mit ngrok zu funktionieren, müssen wir in den erweiterten Optionen einen benutzerdefinierten HTTP-Header namens “ngrok-skip-browser-warning” hinzufügen und auf “true” setzen.
00:08:53Das weist ngrok an, die Warnseite komplett zu umgehen, sodass Better Stack alle paar Sekunden sicher Rohmetriken abrufen kann.
00:09:01Jetzt sollten unsere Metriken automatisch importiert werden.
00:09:05Und jetzt zeige ich Ihnen den coolsten Teil.
00:09:07Wenn wir jetzt zur KI-SRE von Better Stack gehen, können wir die KI bitten, uns ein Dashboard zur Überwachung der Cache-Leistung, Latenz und des System-Durchsatzes zu erstellen.
00:09:19Innerhalb weniger Sekunden erstellt die KI-SRE ein wunderschönes, benutzerdefiniertes Dashboard mit allen Metriken von Juice.FS.
00:09:27Wir können außerdem sehen, dass es in Echtzeit aktualisiert wird.
00:09:32Ist das nicht cool?
00:09:34Ich hoffe, diese kleine Demo zeigt Ihnen, wie leistungsfähig Juice.FS in Kombination mit moderner Infrastrukturüberwachung sein kann.
00:09:41Wir haben es geschafft, einen günstigen Cloud-Speicher-Bucket in ein skalierbares lokales Laufwerk mit Hardware-Geschwindigkeit zu verwandeln und es in nur wenigen Minuten mit einem voll automatisierten Beobachtungs-Dashboard zu verbinden.
00:09:57Da haben Sie es, Leute.
00:09:58Das ist Juice.FS auf den Punkt gebracht.
00:10:00Was halten Sie von Juice.FS?
00:10:02Haben Sie es schon ausprobiert?
00:10:03Werden Sie es nutzen?
00:10:04Lassen Sie es uns unten in den Kommentaren wissen.
00:10:06Und Leute, wenn euch solche technischen Analysen gefallen, lasst es mich wissen, indem ihr den “Gefällt mir”-Button unter dem Video drückt.
00:10:12Und vergesst auch nicht, unseren Kanal zu abonnieren.
00:10:15Das war Andrus von Better Stack, und wir sehen uns in den nächsten Videos.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video