J'ai transformé du stockage cloud bon marché en un disque local de 1 Po (avec JuiceFS)
BBetter Stack
Computing/SoftwareInternet Technology
Transcript
00:00:00Voici Juice.FS. C'est un système de fichiers distribué open source haute performance conçu pour offrir l'évolutivité infinie du stockage objet cloud avec toutes les fonctionnalités et la vitesse d'un système de fichiers local.
00:00:14Dans cette vidéo, nous allons découvrir Juice.FS, voir comment il fonctionne, et je vous montrerai comment configurer votre propre solution de stockage réseau local haute performance avec Juice.FS.
00:00:24Ça va être très amusant, alors plongeons dans le vif du sujet.
00:00:30Les stockages objet standard comme S3, Google Cloud Storage ou Backblaze B2 sont extrêmement économiques, mais interagir avec eux nécessite généralement des API ou des outils spécialisés qui brisent les workflows applicatifs traditionnels.
00:00:48Juice.FS agit comme une couche d'abstraction transparente.
00:00:51Il sépare vos données de vos métadonnées, en poussant les blocs de données brutes directement vers votre fournisseur cloud tout en gérant la disposition du système de fichiers, les permissions et les structures de répertoires au sein d'une base de données rapide comme Redis, Postgres ou TiKV.
00:01:07Ce qui rend Juice.FS totalement différent des passerelles cloud traditionnelles ou des partages de fichiers réseau standard, c'est cette séparation architecturale stricte et son moteur de mise en cache multi-niveaux agressif.
00:01:19Au lieu de forcer vos applications à attendre des requêtes réseau cloud à haute latence à chaque accès à un fichier,
00:01:26Juice.FS découpe les fichiers en petits blocs optimisés et utilise une partition NVMe ou SSD locale comme espace de travail rapide (scratch space).
00:01:35La première fois qu'une application lit ou écrit des données, elle communique via le réseau, mais la seconde fois que ces données sont demandées, elles sont servies instantanément depuis le stockage local à la vitesse du matériel.
00:01:47Cela permet aux applications existantes (legacy), aux bases de données, aux pipelines d'entraînement en machine learning et aux environnements de conteneurs de fonctionner directement sur le stockage objet sans réécrire une seule ligne de code.
00:01:59Tout cela semble génial, mais testons-le par nous-mêmes pour voir comment cela fonctionne.
00:02:04Pour cette démonstration, je vais configurer un stockage réseau (NAS) local, qui hébergera toutes mes données dans mon propre bucket S3 distant et utilisera Redis comme moteur de métadonnées.
00:02:16La toute première chose à faire est de lancer une instance Redis avec Docker, et vous pouvez facilement le faire avec cette commande.
00:02:24Ensuite, nous devons initialiser le système de fichiers en exécutant la commande “juicefs format”.
00:02:29Cette étape indique exactement à Juice.FS comment mapper notre base de données à notre bucket de stockage.
00:02:34Nous lui passons notre chaîne de connexion Redis, le nom de notre bucket AWS S3 et nos identifiants d'accès cloud.
00:02:41Mais avant de faire tout cela, assurez-vous d'avoir créé un bucket S3, ainsi qu'une clé d'accès et une clé secrète avant d'exécuter cette commande.
00:02:48J'avais déjà créé les miens au préalable.
00:02:50Donc maintenant, lorsque je lance cela, Juice.FS ne modifie en fait rien à l'intérieur de notre bucket S3 pour l'instant.
00:02:56Il configure simplement le schéma de stockage dans Redis et attribue un UUID unique à notre nouveau système de fichiers virtuel.
00:03:03Une fois l'étape de formatage terminée, nous montons le périphérique sur notre machine locale en utilisant la commande “juicefs mount”.
00:03:10Nous pointons Juice.FS vers notre instance Redis et fournissons un chemin de répertoire local.
00:03:15Dans mon cas, un dossier dans mon répertoire personnel.
00:03:18Et avant de l'exécuter, il y a un avertissement important.
00:03:21Si vous êtes sur Mac, comme macOS ne prend pas en charge les systèmes de fichiers personnalisés nativement, vous devez d'abord installer un utilitaire d'extension du noyau appelé MacFUSE.
00:03:30Cela fournit les hooks logiciels sous-jacents dont Juice.FS a besoin pour communiquer avec le système d'exploitation Mac.
00:03:37Ensuite, j'ajoute également ce flag avec le ratio d'espace libre, car par défaut, il est réglé sur 20 % de votre disque, ce qui est assez élevé.
00:03:47En gros, cela indique à Juice.FS que si le disque local hébergeant votre cache descend en dessous d'un certain pourcentage de sa capacité totale,
00:03:55il doit arrêter d'écrire de nouveaux fichiers de cache et commencer à purger agressivement les blocs les plus anciens et les moins consultés.
00:04:01Cela évite à votre système d'exploitation local de manquer totalement d'espace disque.
00:04:05Très bien.
00:04:06Maintenant, lançons cette commande.
00:04:07Dès qu'elle s'exécute, le système d'exploitation enregistre un montage de système de fichiers conforme POSIX.
00:04:15Pour l'ordinateur, c'est comme si nous venions de brancher un énorme disque dur externe avec un téraoctet d'espace disponible.
00:04:23Et maintenant, je peux facilement glisser-déposer des fichiers dans ce répertoire comme s'il s'agissait d'un disque externe.
00:04:28Et si nous allons maintenant sur le tableau de bord du bucket S3, nous voyons que Juice.FS a stocké nos fichiers et les a divisés en blocs de données.
00:04:37Tout cela se passe en coulisses, sans que nous ayons à faire le moindre effort.
00:04:42Et pour vous montrer comment fonctionne la mise en cache, nous allons évaluer le système de fichiers en utilisant la commande classique “dd”.
00:04:49Si vous n'avez jamais utilisé “dd” auparavant, c'est un utilitaire intégré utilisé pour la copie de données brutes.
00:04:55Dans cette commande spécifique, “if” signifie fichier d'entrée, qui pointe vers l'un de nos gros fichiers vidéo que j'ai ajoutés à notre disque Juice.FS.
00:05:03Et “of” signifie fichier de sortie.
00:05:06Nous redirigeons ces données vers “/dev/null”, qui est en fait un trou noir dans notre système d'exploitation qui ignore instantanément les données, car nous ne copions pas réellement les fichiers.
00:05:17Nous faisons juste un benchmark dans cet exemple.
00:05:19Nous définissons également la taille du bloc à 4 mégaoctets pour correspondre à la façon dont Juice.FS découpe les blocs de données.
00:05:25Enfin, nous préfixons toute la ligne avec l'utilitaire “time” afin de voir exactement combien de temps prend le transfert de fichier.
00:05:32La première fois que nous appuyons sur Entrée, c'est ce qu'on appelle une lecture à froid (cold read), car le fichier vient d'être téléchargé.
00:05:38Notre machine locale n'en a pas encore de copie.
00:05:41Donc Juice.FS doit atteindre notre bucket S3 via Internet, récupérer tous ces blocs de données de 4 Mo un par un et les diffuser.
00:05:50Et sur ma connexion, la première exécution prend, comme vous pouvez le voir, un temps considérable.
00:05:55Mais regardez ce qui se passe lorsque nous exécutons exactement la même commande une seconde fois.
00:05:59Boum.
00:06:00Et voilà.
00:06:01L'invite de commande revient presque instantanément.
00:06:03La deuxième exécution a pris moins d'une seconde, car maintenant c'est dans notre cache et nous le lisons de manière organique.
00:06:10C'est ainsi que fonctionne le moteur de mise en cache multi-niveaux en action.
00:06:14Pendant que Juice.FS était occupé à télécharger ces blocs lors de notre première exécution, il les copiait silencieusement sur notre disque NVMe local.
00:06:22Mais lors du deuxième passage, le système a totalement ignoré Internet, tirant les données directement du matériel local à pleine vitesse.
00:06:29Vous bénéficiez donc de la capacité de stockage infinie et bon marché du cloud combinée à la vitesse sans latence d'un disque local.
00:06:37Dans cette démonstration, j'ai utilisé des fichiers vidéo pour illustrer la fonctionnalité, mais cela s'applique à presque tous les scénarios d'infrastructure réels.
00:06:45Si vous êtes un ingénieur DevOps gérant des environnements de conteneurs, vous pouvez simplement utiliser Juice.FS pour fournir un stockage persistant partagé sur un cluster Kubernetes.
00:06:54Au lieu de payer pour un stockage bloc cloud coûteux pour chaque nœud, tous vos pods peuvent monter le même volume Juice.FS simultanément.
00:07:03Partageant ainsi globalement des fichiers de configuration, des ressources applicatives ou des téléchargements utilisateurs tout en gardant les coûts incroyablement bas.
00:07:10C'est aussi une victoire massive pour les pipelines de machine learning et de science des données.
00:07:14Car si vous avez un jeu de données massif, disons des centaines de gigaoctets d'images d'entraînement ou de données textuelles dans un bucket S3, entraîner un modèle de ML nécessite généralement de télécharger tout ce jeu de données localement d'abord, ce qui gaspille du temps et de l'espace de stockage.
00:07:30Mais avec Juice.FS, votre script d'entraînement peut commencer à s'exécuter instantanément.
00:07:35Le pipeline lit les données séquentiellement via le montage et Juice.FS gère le streaming haut débit et la mise en cache locale en arrière-plan, gardant vos GPU pleinement saturés sans goulots d'étranglement de stockage local.
00:07:49Et il y a une autre chose sympa que je veux vous montrer.
00:07:51Vous pouvez également facilement connecter des métriques à votre système de fichiers avec Better Stack.
00:07:55Chaque fois que vous montez un volume Juice.FS, il lance silencieusement un serveur de métriques compatible Prometheus en arrière-plan.
00:08:03Si vous ouvrez votre navigateur et allez à cette URL, vous pouvez voir toutes les métriques ici en texte brut, qui suivent chaque succès de cache, durée de lecture et erreur de requête S3 en temps réel.
00:08:13Et pour envoyer ces données de télémétrie directement dans notre tableau de bord, nous pouvons utiliser la fonctionnalité de scraping Prometheus native de Better Stack.
00:08:21D'abord, nous devons aller dans “Sources” et connecter notre Juice.FS comme source.
00:08:25Choisissons “Prometheus scrape” dans l'onglet métriques et cliquons sur “Connect source”.
00:08:31Maintenant, nous devons ingérer nos logs.
00:08:33Mais avant de le faire, nous devons ouvrir un tunnel public sécurisé vers notre port de métriques local en utilisant un outil comme ngrok, puis coller notre URL ngrok.
00:08:43Mais pour que cela fonctionne avec ngrok, nous devons aussi aller dans les options avancées et ajouter un en-tête HTTP personnalisé nommé “ngrok-skip-browser-warning” et le régler sur “true”.
00:08:53Cela indique à ngrok de contourner entièrement la page d'avertissement, permettant à Better Stack de scraper les métriques brutes en toute sécurité toutes les quelques secondes.
00:09:01Et maintenant, nos métriques devraient commencer à s'ingérer automatiquement.
00:09:05Laissez-moi vous montrer la partie la plus cool.
00:09:07Si nous allons maintenant sur l'AI SRE de Better Stack, nous pouvons simplement demander à l'IA de nous créer un tableau de bord qui surveille les performances du cache, la latence et le débit de notre système.
00:09:19Et en quelques secondes, l'AI SRE nous confectionnera un magnifique tableau de bord personnalisé avec toutes les métriques provenant de Juice.FS.
00:09:27Et nous pouvons aussi voir qu'il se met à jour en temps réel.
00:09:32N'est-ce pas génial ?
00:09:34J'espère que cette petite démo vous montre à quel point Juice.FS peut être puissant quand vous le combinez avec une surveillance d'infrastructure moderne.
00:09:41Nous avons réussi à prendre un bucket de stockage cloud standard bon marché, à le transformer en un disque local infiniment évolutif fonctionnant à la vitesse du matériel et à le connecter à un tableau de bord d'observabilité entièrement automatisé en quelques minutes seulement.
00:09:57Et voilà, les amis.
00:09:58C'est Juice.FS en quelques mots.
00:10:00Que pensez-vous de Juice.FS ?
00:10:02L'avez-vous essayé ?
00:10:03Allez-vous l'utiliser ?
00:10:04Faites-le nous savoir dans la section des commentaires ci-dessous.
00:10:06Et les amis, si vous aimez ce genre d'analyses techniques, faites-le moi savoir en explosant ce bouton “J'aime” sous la vidéo.
00:10:12Et n'oubliez pas non plus de vous abonner à notre chaîne.
00:10:15C'était Andrus de Better Stack, et je vous verrai dans les prochaines vidéos.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video