Von einem Technologieunternehmen, das sich auf Sprach- und Sprachverarbeitung konzentriert, hat Yunzhisheng seinen Technologie-Stack so entwickelt, dass er über umfassende KI-Funktionen wie Bildverarbeitung, Verarbeitung natürlicher Sprache und Signale verfügt. Es ist das führende Unicorn-Unternehmen für künstliche Intelligenz in China. Das Unternehmen setzt auf Cloud Computing und verfügt über entsprechende Lösungen in den Bereichen Smart Healthcare, Smart Hotels und Smart Education.
Atlas ist die zugrunde liegende Technologieplattform von Unisound und unterstützt die Iteration aller Unisound-Modelle:
Die erste Schicht ist die Geschäftsschicht, hauptsächlich das Geschäft des Unternehmens wie Sprachverarbeitung, Bildverarbeitung, Verarbeitung natürlicher Sprache usw.
Die zweite Schicht ist das Kontrollzentrum, das von der Datenproduktion, dem Datenzugriff bis zur Modellfreigabe in einem Schritt abgeschlossen werden kann.
Die dritte Schicht ist die Core-Computing-Schicht, die hauptsächlich Deep Learning und Datenvorverarbeitung unterstützt.
Die unterste Schicht ist die Infrastrukturschicht, die hauptsächlich aus GPU-Clustern, CPU-Clustern und verteiltem Speicher besteht.Alle Maschinen sind über ein 100-Gbit/s-InfiniBand-Hochgeschwindigkeitsnetzwerk verbunden.
Speicherszenarien und Anforderungen
Das anfängliche Konstruktionsziel von Unisound ist der Aufbau einer KI-Plattform aus einer Hand, einschließlich KI-Modellerstellung, Datenvorverarbeitung, Modellentwicklung, Modelltraining und endgültiger Modellstart.
Wie in der obigen Abbildung gezeigt, muss jeder Schritt mit Daten interagieren, und die Datenvorverarbeitung und das Modelltraining erfordern relativ große IO .
• Datenvorverarbeitung, hauptsächlich Sprachverarbeitung extrahiert Sprachmerkmale und wandelt Sprachmerkmale in Numpy-Format-Dateien um, im Prozess der Bildverarbeitung werden Bilder vorverarbeitet und Formatkonvertierung von Trainingsdaten wird durchgeführt • Modellentwicklung, hauptsächlich Es ist der Algorithmus Ingenieur, der den Code bearbeitet und den Modellalgorithmus debuggt; • Für das Modelltraining sind unterwegs mehrere Datenleserunden erforderlich, und das Modell wird an den entsprechenden Speicher ausgegeben. Die für diesen Schritt erforderliche IO ist sehr groß; , Der Dienst liest die Modelldateien im Speichersystem. Um unsere Speicheranforderungen zusammenzufassen:
- Die vollständige Verknüpfung, die mit der gesamten Modellentwicklung verbunden werden kann, muss in mehreren Kernfunktionsblöcken unterstützt werden;
- Unterstützung von Aufgaben zum Lesen von CPU- und GPU-Daten;
- Unsere Szenarien stellen hauptsächlich Sprach-, Text- und Bilddaten dar. Diese Szenarien zeichnen sich durch relativ kleine Dateigrößen aus, sodass eine hochperformante Verarbeitung in Szenarien mit kleinen Dateien unterstützt werden muss.
- Unser Geschäftsszenario besteht hauptsächlich darin, mehr zu lesen und weniger zu schreiben: Während des Modelltrainings werden die meisten Daten gelesen und im Grunde keine Daten geschrieben. Basierend auf den oben genannten Anforderungen benötigen wir ein leistungsstarkes und zuverlässiges verteiltes Speichersystem.
Geschichte des Unisound-Speicherbaus
In den frühen Tagen hatten wir nur etwa ein Dutzend GPUs und wir verwendeten NFS, um einen kleinen Cluster aufzubauen. Gleichzeitig wurde 2016 die CephFS-Testumgebung eingeführt. Damals war die Leistung dieser Version von CephFS im Small-File-Szenario nicht sehr gut, sodass CephFS nicht in die Produktionsumgebung gebracht wurde.
Später forschten wir weiter und stellten fest, dass Lustre das am häufigsten verwendete Hochleistungs-Dateisystem im HPC-Bereich ist. Tests zeigen, dass Lustre in Bezug auf groß angelegte Konstruktion und Leistung gut abschneidet, daher werden wir von 2017 bis 2022 Lustre verwenden, um alle Datendienste zu übertragen.
Da jedoch immer mehr GPUs zum Einsatz kommen und mittlerweile eine Floating-Point-Verarbeitungsleistung von etwa 570 Exaflops/s haben, kann die IO des zugrunde liegenden Speichers nicht mehr mit der Rechenleistung der oberen Schicht mithalten . Daher begannen wir, neuen Speicher zu erkunden und für eine spätere Speichererweiterung aufzurüsten.Gleichzeitig stießen wir auch auf einige Probleme bei der Verwendung von Lustre.
Erstens: die Betriebs- und Wartungsmethode.Luster basiert hauptsächlich auf dem Kernel und ist direkt in den Kernel eingebettet.Manchmal beinhaltet das Positionierungsproblem Vorgänge wie das Neustarten der Maschine;
Zweitens: Technologie-Stack , da die Entwicklung unserer Cloud-Plattform hauptsächlich auf Golang basiert, sodass wir lieber Speicher verwenden, der mit der Entwicklungssprache besser kompatibel ist. Lustre verwendet die C-Sprache, die mehr Arbeitskraft in Bezug auf Anpassung und Optimierung erfordert.
Drittens: Datenzuverlässigkeit Lustre stützt sich hauptsächlich auf Hardwarezuverlässigkeit (wie RAID-Technologie), und die Softwareschicht implementiert hauptsächlich die HA-Lösung von Metadatenknoten und Objekt- und Datenknoten. Im Vergleich dazu verwenden wir immer noch lieber zuverlässigere Softwarelösungen wie drei Kopien oder Löschcodes.
Viertens: Die funktionalen Anforderungen des Multi-Level-Cachings . Im Jahr 2021 werden wir Fluid + Alluxio als verteilte Beschleunigung von Lustre verwenden. Alluxio kann die Berechnung unseres Clusters besser beschleunigen und den Druck auf den zugrunde liegenden Speicher verringern. Wir haben jedoch die Möglichkeit untersucht, clientseitiges Caching direkt vom Speichersystem aus durchzuführen, damit der Vorgang für Benutzer transparenter ist.
Als JuiceFS 2021 zum ersten Mal Open Source wurde, haben wir seine Funktionen untersucht.
Zunächst die Produktmerkmale : JuiceFS unterstützt die POSIX-Schnittstelle und kann in Form von HostPath gemountet werden. Diese Methode ist genau die gleiche wie die Art und Weise, wie wir NAS verwenden, und Benutzer müssen im Grunde keine Änderungen vornehmen, wenn sie es verwenden; JuiceFS-Metadaten und -Objekt Speicher gibt es viele Alternativen, wie Redis und TiKV sind im Bereich KI besser geeignet. Das zugrunde liegende Ceph, MinIO und einige öffentliche Cloud-Objektspeicher können Benutzer selbst auswählen.
Zweitens, Upper-Layer-Scheduling : JuiceFS unterstützt nicht nur HostPath, sondern auch den CSI-Laufwerksmodus, der es Benutzern ermöglicht, auf den entsprechenden Speicher auf Cloud-nativere Weise zuzugreifen.
Drittens Anpassung des Business-Frameworks : Die POSIX-Schnittstelle wird an das Deep-Learning-Framework angepasst. Viertens, Betrieb und Wartung: Die Metadaten-Engine und der Objektspeicher sind in der Branche relativ ausgereift, und es gibt viele Möglichkeiten, und JuiceFS verfügt über automatische Metadaten-Backup- und Papierkorbfunktionen. JuiceFS passt gut zum Geschäft, also haben wir einen POC-Test durchgeführt.
Die Testumgebung ist in der obigen Abbildung dargestellt. Im Vergleich zu JuiceFS wird festgestellt, dass JuiceFS den Kernel-Seitencache direkt verwendet, und im Vergleich zum direkten Zugriff von Luster auf die mechanische Festplatte ist die Leistung erheblich verbessert (wie in der Abbildung unten gezeigt). je kleiner desto besser).
Nach dem POC-Test haben wir uns entschieden, JuiceFS in die Produktionsumgebung zu bringen. Derzeit haben alle GPU-Rechenknoten des gesamten Atlas-Clusters sowie alle Entwicklungs- und Debugging-Knoten den JuiceFS-Client installiert.
JuiceFS stellt eine direkte Verbindung zum Redis-Cluster und Ceph her, und die meisten Rechenknoten verwenden HostPath für den Zugriff. Gleichzeitig wird der JuiceFS-CSI-Treiber auch im Atlas-Cluster bereitgestellt, und Benutzer können auf Cloud-native Weise darauf zugreifen.
Wie JuiceFS in Atlas verwendet wird
Um die Datensicherheit zu gewährleisten, gehört jede Gruppe auf der Supercomputing-Plattform zu einem anderen Verzeichnis, jedes Verzeichnis enthält die Mitglieder der jeweiligen Gruppe oder Abteilung, und die Verzeichnisse zwischen verschiedenen Gruppen sind unsichtbar .
Die Verzeichnisberechtigungen basieren auf dem Linux-Berechtigungskontrollmechanismus. Wenn ein Benutzer eine Trainingsaufgabe im Atlas-Cluster sendet, liest das Aufgabenübermittlungstool des Clusters automatisch die UID- und GID-Informationen des Benutzers auf dem System und fügt sie dann in das SecurityContext-Feld des vom Benutzer gesendeten Aufgaben-Pods und dann in den Container ein Pod, der auf dem Atlas-Cluster ausgeführt wird, werden die UIDs der laufenden Prozesse aller Container mit den Informationen auf dem Speichersystem übereinstimmen, um sicherzustellen, dass die Berechtigungen nicht die Grenze überschreiten.
Knoten greifen auf JuiceFS zu, um mehrstufiges Caching zu implementieren:
-
Die erste Ebene: Der Cache ist der Seiten-Cache des Speichers.
-
Stufe 2: Mehrere SSDs auf allen Rechenknoten bieten Stufe-2-Beschleunigungsfähigkeiten.
-
Die dritte Ebene: Verwenden Sie Ceph. Wenn drei 1t-SSDs immer noch keine Benutzerdaten unterstützen können, werden sie von Ceph gelesen.
Anfang 2021 werden Unisound und das JuiceFS-Team JuiceFSRuntime in Fluid integrieren. Da der Cache auf Bare-Metal-Weise verwendet wird, haben wir festgestellt, dass die Sichtbarkeit des Caches für Benutzer nicht gut ist. Das System bereinigt den Cache automatisch und die Kontrollierbarkeit des Benutzers ist nicht so hoch. Deshalb haben wir JuiceFS integriert in Flüssigkeit.
Fluid startet JuiceFS-bezogene Komponenten, einschließlich FUSE und Worker Pod. Darunter stellt der FUSE-Pod die Cache-Fähigkeit des JuiceFS-Clients bereit, und der Worker-Pod realisiert die Verwaltung des Cache-Lebenszyklus.Die KI-Offline-Trainingsaufgabe der Atlas-Plattform interagiert mit dem FUSE-Pod-Client, um KI-Trainingsdaten zu lesen .
Durch die von Fluid bereitgestellten Cache-Planungsfunktionen und die Beobachtbarkeit von Datensätzen können Benutzer der Plattform Caches auf bestimmten Rechenknoten durch Affinitätsplanung bereitstellen, und gleichzeitig können Benutzer die Verwendung von Caches (z. B. die zwischengespeicherten Daten) intuitiv sehen Sets), Größe, Cache-Prozentsatz, Cache-Kapazität usw.).
Baupraxis von JuiceFS
Derzeit kann Atlas nicht auf das öffentliche Netzwerk zugreifen und befindet sich in einem dedizierten isolierten Netzwerk, sodass alle unsere Bereitstellungen privatisiert sind.
Die Metadaten-Engine unserer Produktionsumgebung verwendet Redis. 2020 ist die Verbindung zwischen TiKV und JuiceFS noch nicht sehr ausgereift. Wir planen, zuerst Redis für den Übergang zu verwenden und Ceph für die Objektspeicherung zu verwenden. Die Systemfestplatte des Redis-Knotens ist mit RAID1 konfiguriert, und die persistenten Daten von Redis werden regelmäßig mit einem anderen Sicherungsknoten synchronisiert. Für die Redis-Datenpersistenz verwenden wir die AOF + RDB-Lösung, um Daten jede Sekunde zu speichern.
Der Objektspeicher verwendet einen selbst erstellten Ceph-Cluster, und der Ceph-Cluster wird mit Cephadm bereitgestellt.Die aktuelle Produktionsumgebung verwendet die Octopus-Version. Wir haben uns damals viele Lösungen aus der Industrie ausgeliehen, den Arbeitsspeicher auf Speicherebene optimiert und entsprechende Anpassungen auf Softwareebene vorgenommen, hauptsächlich wie folgt:
Serverebene (Referenz) : • 42 Kerne 256 GB 24 18T HDD • Systemfestplatte: 2 960G SAS SSD • BlueStore • NUMA deaktivieren • Kernel aktualisieren: 5.4.146 io_uring aktivieren • Kernel pid max, /proc/sys/kernel/pid_max ändern
Ceph-Konfiguration : • Ceph RADOS: Rufen Sie direkt die librados-Schnittstelle auf, verwenden Sie nicht das S3-Protokoll • Bucket-Shard • Deaktivieren Sie die automatische Anpassungsfunktion von pg • OSD-Protokollspeicherung (unter Verwendung von Bluestore, dem empfohlenen Verhältnis von Rohkapazität - Block : block.db : block.wal = 100:1:1, SSD oder NVMe SSD wird für die beiden letzteren empfohlen) • 3 Kopien
Es ist wichtig zu erwähnen, dass der Kernel des Ceph-Clusters auf eine neuere Version aktualisiert werden sollte und dann die io_uring-Funktion aktiviert werden sollte, damit die Leistung erheblich verbessert wird. In Bezug auf die Software rufen wir direkt die Rados-Schnittstelle auf, anstatt das S3-Protokoll zu verwenden, und die Effizienz wird etwas höher sein.Alle Knoten sind mit einem 100G-InfiniBand-Hochgeschwindigkeitsnetzwerk verbunden.
Der mit JuiceFS verbundene Objektspeicher in der Yunzhisheng-Umgebung ist Ceph RADOS. JuiceFS verwendet Librados, um mit Ceph zu interagieren, daher muss der JuiceFS-Client neu kompiliert werden. Es wird empfohlen, dass die Version von Librados der von Ceph entspricht. Bitte beachten Sie dies Punkt. Wenn Sie CSI-Treiber verwenden, wird dieser bei der Erstellung von PV/PVC ausgelesen, und Sie sollten /etc/ceph/ceph.confauch auf die Versionsunterstützung achten.
Perfektes Überwachungssystem
Jetzt ist die gesamte Verbindung relativ lang. Die unterste Schicht hat Metadaten-Engine-Cluster, Ceph-Objektspeicher-Cluster und Clients und Dienste der oberen Schicht. Jede Schicht muss über eine entsprechende Überwachungslösung verfügen.
Für den Client-Knoten sammeln wir hauptsächlich Protokolle. Es sollte beachtet werden, dass die JuiceFS-Client-Protokolle jedes Einhängepunkts aggregiert werden müssen und Fehleralarme erforderlich sind, um zu verhindern, dass die Protokolle die Systemfestplatte sprengen oder der Knoten nicht geschrieben werden kann.
Jeder JuiceFS-Client muss auch über entsprechende Überwachungsmethoden verfügen, z. B. das Überprüfen, ob die .stat-Dateien und Protokollbeobachtungsindikatoren jedes Einhängepunkts normal sind, und dann das Überprüfen der IO und Protokolle von Redis- und Ceph-Clustern, um sicherzustellen, dass die gesamte Verbindung steuerbar ist. Ja , ist es bequemer, das Problem auf diese Weise zu lokalisieren.
Das obige Bild ist das Überwachungsbild von Ceph, da unsere Client-Knoten den SSD-Cache verwenden und die Daten jetzt im Grunde nicht in Ceph gelesen werden, sondern die meisten Daten aus dem Cache gelesen werden, sodass der Datenverkehr von Ceph nicht groß ist.
Das obige Bild stellt die von der JuiceFS-Überwachung abgefangenen Daten dar. Es ist ersichtlich, dass 100 % bis 90 % der Knoten getroffen werden können. Die Cache-Trefferrate ist immer noch relativ hoch und die meisten Daten befinden sich noch im Cache.
Beteiligen Sie sich am Aufbau der JuiceFS-Community
UniSound hat sich während der Nutzung der JuiceFS Community Edition aktiv am Community-Aufbau beteiligt. Im Jahr 2021 habe ich mit dem JuiceData-Team zusammengearbeitet, um die oben erwähnte Fluid JuiceFS Runtime zu entwickeln. Kürzlich haben wir festgestellt, dass das verzeichnisbasierte Kontingent der Community-Version noch nicht entwickelt wurde, daher haben wir vor einigen Monaten eine Version entwickelt, die die Anzahl der Dateien im Verzeichnis und die Dateigröße begrenzt.Die PR wurde eingereicht und arbeitet jetzt mit der JuiceFS-Community zusammen.
Anwendungsszenarien und Vorteile von JuiceFS in Atlas
Der Multi-Level-Cache des JuiceFS-Clients wird derzeit hauptsächlich in unseren Szenarien für Texterkennung, Sprachrauschunterdrückung und Spracherkennung verwendet. Da das Datenlesen des KI-Modelltrainings durch mehr Lesen und weniger Schreiben gekennzeichnet ist, nutzen wir den Cache des JuiceFS-Clients voll aus, um die Beschleunigungsvorteile des IO-Lesens zu nutzen.
Vorteil 1: Beschleunigen Sie das KI-Modelltraining
1) Sprachrauschunterdrückungstest
Beim Test des Rauschunterdrückungsszenenmodells werden verstreute Dateien verwendet. Alle Daten sind im WAV-Format, eine kleine Sprachdatei, die kleiner als 100 KB ist. In der Rauschunterdrückungsszene haben wir die E/A-Daten in der Datenladephase getestet und die Speicher des JuiceFS-Client-Knotens Der Cache ist 512 GB groß, und der Test wird mit einer Stapelgröße von 40 unter den Daten einer 500-Stunden-Skala durchgeführt.
Aus den Testergebnissen geht allein in Bezug auf die Datenleseeffizienz in Bezug auf kleine WAV-Dateien hervor, dass JuiceFS 6,45 it/s beträgt, während Lustre 5,15 it/s beträgt und die Leistung um 25 % verbessert wird. JuiceFS hat unser End-to-End-Modelltraining effektiv beschleunigt und die Gesamtmodellausgabezeit verkürzt.
2) Texterkennungsszene
Im Texterkennungsszenario ist das Modell CRNN-Backbone und MobileNet v2, und die Testumgebung ist wie folgt:
Eine große Datendatei von LMDB wird generiert. Zu diesem Zeitpunkt hat IO relativ hohe Bandbreitenanforderungen anstelle von Leistungsanforderungen für kleine Dateien. Der 200-GB-Speicher-Cache kann die gesamten Daten unterstützen, sodass wir, anstatt den zugrunde liegenden Speicher zu verwenden, direkt vom Client lesen, und auch die Gesamtleistung wurde erheblich verbessert.
In diesem Test wird hauptsächlich der Geschwindigkeitsvergleich zwischen JuiceFS und Lustre durchgeführt.Den experimentellen Ergebnissen zufolge dauert es 1,5 Sekunden, um jeden Stapel von Lustre zu lesen, und 1,1 Sekunden, um jeden Stapel von JuiceFS zu lesen, was einer Steigerung von 36 % entspricht. Aus der Perspektive der Modellkonvergenzzeit, von 96 Stunden von Luster auf 86 Stunden von JuiceFS, kann die Verwendung von JuiceFS die Ausgabezeit des CRNN-Modells um 10 Stunden verkürzen.
Modell-Debugging und Datenverarbeitung
Beim Code-Debuggen führen mehrere Benutzer gleichzeitig Modelltests und Code-Traversal auf einem Debugging-Computer aus. Zu diesem Zeitpunkt würden die meisten Benutzer einige Remote-IDEs verwenden, sich mit Debugging-Knoten verbinden und dann ihre eigene virtuelle Umgebung erstellen und installieren eine große Anzahl von Installationspaketen auf Lustre im Voraus.
Die meisten von ihnen sind kleine Dateien von Dutzenden von k oder Hunderten von k, und wir müssen diese Pakete in unseren Speicher importieren. Bei früherer Verwendung von Lustre ist der erforderliche Durchsatz aufgrund zu vieler Benutzer hoch. Gleichzeitig sind die Leistungsanforderungen für kleine Dateien relativ hoch. Ich habe festgestellt, dass der Effekt nicht sehr gut ist. Beim Importieren von Paketen wird dies der Fall sein relativ hängengeblieben, was zu langsamem Code-Debugging und relativ geringer Gesamteffizienz führt.
Später wurde der Cache des JuiceFS-Clients verwendet, und die erste Kompilierung war auch relativ langsam, aber die zweite Kompilierung, weil alle Daten im Cache abgelegt wurden, war die Geschwindigkeit und Effizienz höher und der Codesprung war schneller Hinting-Importe sind ebenfalls schneller. Nach Benutzertests gibt es eine etwa 2- bis 4-fache Geschwindigkeitssteigerung.
Epilog
Von Lustre bis JuiceFS
Von 2017 bis 2021, wenn wir Lustre verwenden, ist es auch relativ stabil.Wenn die Cluster-Speicherkapazität weniger als 50% beträgt, ist die Stabilität der Software relativ hoch.
Als Speichersystem im erfahrenen HPC-Bereich hat Lustre viele der weltweit größten Supercomputing-Systeme betrieben und verfügt über langjährige Erfahrung in Produktionsumgebungen. Es hat die Vorteile, dass es dem POSIX-Standard entspricht, verschiedene Netzwerke mit hoher Leistung und geringer Latenz unterstützt und RDMA-Zugriff ermöglicht, es eignet sich für Hochleistungsrechnen im traditionellen HPC-Bereich und ist mit der Schnittstelle von Deep Learning kompatibel. Alle Unternehmen müssen nicht Code-Änderung durchgeführt werden. Aber es gibt auch einige Nachteile:
Erstens kann Lustre keinen Cloud-nativen CSI-Treiber unterstützen.
Zweitens stellt Lustre relativ hohe Anforderungen an das Betriebs- und Wartungspersonal, da alles in C geschrieben ist, einige Fehler manchmal nicht schnell behoben werden können und die gesamte Community nicht sehr offen und aktiv ist.
JuiceFS hat solche Funktionen:
Erstens ist JuiceFS ein verteiltes Speichersystemprodukt im Cloud-nativen Bereich , das CSI-Treiber und Fluid zur besseren Integration mit Kubernetes bereitstellt.
Zweitens ist das Deployment-Schema von JuiceFS relativ flexibel und die Metadaten-Engine ist höchst optional.Wenn das Benutzernetzwerk Objektspeicherung zulässt, ist es tatsächlich besser, sich mit dem Objektspeicher der öffentlichen Cloud zu verbinden.
Drittens ist es in Bezug auf den Speichererweiterungsbetrieb und die Wartung relativ einfach . Die Anwendung von Deep Learning ist vollständig kompatibel mit dem POSIX-Standard und kann nahtlos migriert werden, aber aufgrund der Eigenschaften des Back-End-Objektspeichers hat JuiceFS eine hohe Verzögerung beim zufälligen Schreiben.
Viertens unterstützt JuiceFS den lokalen Cache und den Kernel-Page-Cache, wodurch die Schichtung und Beschleunigung heißer und kalter Daten realisiert wird . Darauf legen wir mehr Wert, es eignet sich besser für unsere Geschäftsszenarien, aber nicht für wahlloses Schreiben. Die verteilte Cache-Funktion der Community-Version ist noch nicht verfügbar.
Nachträgliche Planung
• Upgrade der Metadaten-Engine, TiKV eignet sich für Szenarien mit mehr als 100 Millionen Dateien (kann bis zu 10 Milliarden Dateien unterstützen) und stellt hohe Anforderungen an Leistung und Datensicherheit Derzeit haben wir den internen Test von TiKV abgeschlossen und sind aktiv daran arbeiten Um den Fortschritt der Community zu verfolgen, wird die Metadaten-Engine in Zukunft auf TiKV migriert. • Optimierung des Verzeichniskontingents: Derzeit wurden die Funktionen der Basisversion in die Community-Version von JuiceFS integriert.Es wurden auch Gespräche mit der JuiceFS-Community geführt.In einigen Szenarien muss die Leistung optimiert werden. • Hoffe, einige Nonroot-Funktionen ausführen zu können. Jetzt haben alle Knoten Root-Berechtigung für den Zugriff auf alle Daten. Die Berechtigung ist zu groß. Wir hoffen, Root-Berechtigung nur auf bestimmten Knoten zu öffnen. • Abschließend prüfen wir, ob es eine QoS-Lösung in der Community gibt, zB Geschwindigkeitsbegrenzung nach UID oder GID.
Wenn Sie hilfreich sind, beachten Sie bitte unser Projekt Juicedata/JuiceFS ! (0ᴗ0✿)