À partir d'une entreprise technologique axée sur le traitement de la parole et du langage, Yunzhisheng a développé sa pile technologique pour disposer de capacités d'IA complètes telles que l'image, le traitement du langage naturel et le signal.C'est la principale entreprise de licorne d'intelligence artificielle en Chine. La société adopte le cloud computing et propose des solutions correspondantes dans les domaines de la santé intelligente, des hôtels intelligents et de l'éducation intelligente.
Atlas est la plate-forme technologique sous-jacente d'Unisound, prenant en charge l'itération de tous les modèles Unisound :
La première couche est la couche métier, principalement les métiers de l'entreprise tels que le traitement de la voix, le traitement des images, le traitement du langage naturel, etc.
La deuxième couche est le centre de contrôle, qui peut être complété en un seul arrêt depuis la production de données, l'accès aux données jusqu'à la publication du modèle.
La troisième couche est la couche informatique centrale, qui prend principalement en charge l'apprentissage en profondeur et le prétraitement des données.
La couche inférieure est la couche d'infrastructure, qui est principalement composée d'un cluster GPU, d'un cluster CPU et d'un stockage distribué.Toutes les machines sont connectées par un réseau haut débit InfiniBand de 100 Gbps.
Scénarios de stockage et exigences
L'objectif de construction initial d'Unisound est de construire une plate-forme d'IA à guichet unique, comprenant la production de modèles d'IA, le prétraitement des données, le développement de modèles, la formation de modèles et le lancement du modèle final.
Comme le montre la figure ci-dessus, chaque étape doit interagir avec les données, et le prétraitement des données et la formation du modèle nécessitent des E/S relativement importants .
• Le prétraitement des données, principalement le traitement de la parole, extraira les caractéristiques de la parole et convertira les caractéristiques de la parole en fichiers au format numpy ; dans le processus de traitement d'image, les images seront prétraitées et la conversion de format des données de formation sera effectuée ; • Développement de modèles, principalement C'est l'algorithme ingénieur qui édite le code et débogue l'algorithme du modèle ; • Pour la formation du modèle, plusieurs cycles de lecture de données seront nécessaires en cours de route, et le modèle sera sorti vers le stockage correspondant. L'IO requis pour cette étape est très important ; , le service lira les fichiers de modèle dans le système de stockage. Pour résumer nos besoins de stockage :
- Le lien complet qui peut être connecté à l'ensemble du développement du modèle doit être pris en charge dans plusieurs blocs fonctionnels de base ;
- Prend en charge les tâches de lecture de données CPU et GPU ;
- Nos scénarios sont principalement des données vocales, textuelles et d'image. Ces scénarios se caractérisent par des tailles de fichiers relativement petites, de sorte qu'un traitement haute performance dans des scénarios de petits fichiers doit être pris en charge.
- Notre scénario commercial consiste principalement à lire plus et à écrire moins. Pendant la formation du modèle, la plupart des données sont lues et, fondamentalement, aucune donnée n'est écrite. Sur la base des exigences ci-dessus, nous avons besoin d'un système de stockage distribué performant et fiable.
Histoire de la construction du stockage Unisound
Au début, nous n'avions qu'une douzaine de GPU et nous utilisions NFS pour créer un cluster à petite échelle. Dans le même temps, l'environnement de test CephFS a été introduit en 2016. À cette époque, les performances de cette version de CephFS n'étaient pas très bonnes dans le scénario de petit fichier, de sorte que CephFS n'a pas été intégré à l'environnement de production.
Plus tard, nous avons continué à faire des recherches et avons découvert que Lustre est le système de fichiers hautes performances le plus couramment utilisé dans le domaine HPC. Les tests montrent que Lustre fonctionne bien en termes de construction et de performances à grande échelle, donc de 2017 à 2022, nous utiliserons Lustre pour transporter tous les services de données.
Cependant, comme de plus en plus de GPU sont utilisés et disposent désormais d'une capacité de traitement en virgule flottante d'environ 570 exaflops/s, les E/S du stockage sous-jacent ne peuvent plus suivre la capacité de calcul de la couche supérieure . Par conséquent, nous avons commencé à explorer de nouveaux stockages et à les mettre à niveau pour une extension ultérieure du stockage.Dans le même temps, nous avons également rencontré des problèmes lors de l'utilisation de Lustre.
Premièrement : la méthode d'exploitation et de maintenance . Lustre est principalement basé sur le noyau et est directement intégré dans le noyau. Parfois, le problème de positionnement impliquera des opérations telles que le redémarrage de la machine ;
Deuxièmement : stack technologique , car le développement de notre plateforme cloud est principalement basé sur golang, nous préférons donc utiliser un stockage plus compatible avec le langage de développement. Lustre utilise le langage C, qui nécessite plus de main-d'œuvre en termes de personnalisation et d'optimisation.
Troisièmement : la fiabilité des données . Lustre s'appuie principalement sur la fiabilité du matériel (comme la technologie RAID), et la couche logicielle implémente principalement la solution HA des nœuds de métadonnées et des nœuds d'objets et de données. Par rapport à ceux-ci, nous préférons toujours utiliser des solutions logicielles plus fiables telles que trois copies ou codes d'effacement.
Quatrième : Les exigences fonctionnelles de la mise en cache multi-niveaux . En 2021, nous utiliserons Fluid + Alluxio comme accélération distribuée de Lustre. Alluxio peut mieux accélérer le calcul de notre cluster et réduire la pression sur le stockage sous-jacent. Cependant, nous avons exploré la possibilité d'effectuer une mise en cache côté client directement à partir du système de stockage, afin que l'opération puisse être plus transparente pour les utilisateurs.
Lorsque JuiceFS a été ouvert pour la première fois en 2021, nous avons mené des recherches sur ses fonctionnalités.
Tout d'abord, les fonctionnalités du produit : JuiceFS prend en charge l'interface POSIX et peut être monté sous la forme de HostPath. Cette méthode est exactement la même que la façon dont nous utilisons le NAS, et les utilisateurs n'ont fondamentalement pas besoin d'apporter de modifications lors de son utilisation ; les métadonnées et l'objet JuiceFS stockage , il existe de nombreuses alternatives, telles que Redis et TiKV sont plus adaptées dans le domaine de l'IA. Le Ceph sous-jacent, MinIO et certains utilisateurs de stockage d'objets de cloud public peuvent choisir eux-mêmes.
Deuxièmement, la planification de la couche supérieure : JuiceFS prend non seulement en charge HostPath, mais prend également en charge le mode lecteur CSI, qui permet aux utilisateurs d'accéder au stockage correspondant d'une manière plus native du cloud.
Troisièmement, l'adaptation du framework métier : l'interface POSIX est adaptée au framework d'apprentissage profond. Quatrièmement, exploitation et maintenance : le moteur de métadonnées et le stockage d'objets sont relativement matures dans l'industrie, et il existe de nombreux choix, et JuiceFS dispose de fonctions de sauvegarde automatique des métadonnées et de corbeille. JuiceFS correspond bien à l'entreprise, nous avons donc effectué un test POC.
L'environnement de test est illustré dans la figure ci-dessus. Par rapport à JuiceFS, on constate que JuiceFS utilise directement le cache de la page du noyau, et par rapport à l'accès direct de Lustre au disque mécanique, les performances sont grandement améliorées (comme indiqué dans la figure ci-dessous, plus c'est petit, mieux c'est).
Après le test POC, nous avons décidé d'intégrer JuiceFS dans l'environnement de production. À l'heure actuelle, tous les nœuds de calcul GPU de l'ensemble du cluster Atlas, ainsi que tous les nœuds de développement et de débogage, ont installé le client JuiceFS.
JuiceFS se connecte directement au cluster redis et à ceph, et la plupart des nœuds informatiques utilisent HostPath pour y accéder. Dans le même temps, le pilote JuiceFS CSI est également déployé dans le cluster Atlas, et les utilisateurs peuvent y accéder de manière native dans le cloud.
Comment JuiceFS est utilisé dans Atlas
Afin d'assurer la sécurité des données, chaque groupe sur la plate-forme de supercalcul appartient à un répertoire différent, chaque répertoire est les membres du groupe ou du département respectif, et les répertoires entre les différents groupes sont invisibles .
Les autorisations de répertoire sont basées sur le mécanisme de contrôle des autorisations Linux. Lorsqu'un utilisateur soumet une tâche de formation dans le cluster Atlas, l'outil de soumission de tâche du cluster lit automatiquement les informations UID et GID de l'utilisateur sur le système, puis les injecte dans le champ SecurityContext du pod de tâches soumis par l'utilisateur, puis le conteneur Le pod s'exécutant sur le cluster Atlas Les UID des processus en cours d'exécution de tous les conteneurs sont cohérents avec les informations sur le système de stockage pour garantir que les autorisations ne franchissent pas la limite.
Les nœuds accèdent à JuiceFS pour implémenter la mise en cache à plusieurs niveaux :
-
Le premier niveau : le cache est le cache de pages de la mémoire.
-
Niveau 2 : plusieurs SSD sur tous les nœuds de calcul offrent des capacités d'accélération de niveau 2.
-
Le troisième niveau : utilisez Ceph. Si trois SSD 1t ne peuvent toujours pas prendre en charge les données utilisateur, elles seront lues à partir de Ceph.
Début 2021, Unisound et l'équipe JuiceFS intégreront JuiceFSRuntime dans Fluid. Parce que le cache est utilisé de manière nue, nous avons constaté que la visibilité du cache n'est pas bonne pour les utilisateurs. Le système nettoie automatiquement le cache et la contrôlabilité de l'utilisateur n'est pas si élevée. C'est pourquoi nous avons intégré JuiceFS dans Fluide.
Fluid démarrera les composants liés à JuiceFS, y compris FUSE et Worker Pod. Parmi eux, le FUSE Pod fournit la capacité de cache du client JuiceFS, et le Worker Pod réalise la gestion du cycle de vie du cache.La tâche d'entraînement hors ligne de l'IA de la plate-forme Atlas interagit avec le client FUSE Pod pour lire les données d'entraînement de l'IA. .
Grâce aux capacités de planification de cache fournies par Fluid et à l'observabilité des ensembles de données, les utilisateurs de la plate-forme peuvent déployer des caches sur des nœuds informatiques spécifiques grâce à la planification d'affinité, et en même temps, les utilisateurs peuvent voir intuitivement l'utilisation des caches (comme les données mises en cache sets) taille, pourcentage de cache, capacité de cache, etc.).
Pratique de construction de JuiceFS
Actuellement, Atlas ne peut pas accéder au réseau public et se trouve dans un réseau isolé dédié, donc tous nos déploiements sont privatisés.
Le moteur de métadonnées de notre environnement de production utilise Redis. En 2020, la connexion entre TiKV et JuiceFS n'est pas très mature. Nous prévoyons d'utiliser Redis pour la transition dans un premier temps, et d'utiliser Ceph pour le stockage d'objets. Le disque système du nœud Redis est configuré avec RAID1 et les données persistantes de Redis seront périodiquement synchronisées avec un autre nœud de sauvegarde. Pour la persistance des données Redis, nous utilisons la solution AOF + RDB pour persister les données chaque seconde.
Le stockage d'objets utilise un cluster Ceph auto-construit, et le cluster Ceph est déployé à l'aide de Cephadm. L'environnement de production actuel utilise la version Octopus. À cette époque, nous avons emprunté de nombreuses solutions à l'industrie, optimisé la mémoire au niveau de la mémoire et effectué les ajustements correspondants au niveau du logiciel, principalement comme suit :
Niveau serveur (référence) : • 42 cœurs 256 Go 24 disques durs 18T • Disque système : 2 960G SAS SSD • BlueStore • Désactiver NUMA • Mettre à jour le noyau : 5.4.146 Activer io_uring • Kernel pid max, modifier /proc/sys/kernel/pid_max
Configuration de Ceph : • Ceph RADOS : appeler directement l'interface librados, ne pas utiliser le protocole S3 • Bucket shard • Désactiver la fonction d'ajustement automatique de pg • Stockage des logs OSD (en utilisant bluestore, le ratio recommandé de capacité brute - block : block.db : block.wal = 100:1:1, SSD ou NVMe SSD est recommandé pour les deux derniers) • 3 copies
Il est important de mentionner que le noyau du cluster Ceph doit être mis à niveau vers une version plus récente, puis la fonction io_uring doit être activée, afin que les performances soient grandement améliorées. En termes de logiciel, nous appelons directement l'interface rados au lieu d'utiliser le protocole S3, et l'efficacité sera légèrement supérieure.Tous les nœuds sont interconnectés avec le réseau haut débit 100G InfiniBand.
Le stockage objet connecté à JuiceFS dans l'environnement Yunzhisheng est Ceph RADOS. JuiceFS utilise librados pour interagir avec Ceph, le client JuiceFS doit donc être recompilé. Il est recommandé que la version de librados corresponde à celle de Ceph. Veuillez prêter attention à ceci indiquer. Si vous utilisez CSI Driver, il sera lu lors de la création de PV/PVC, et vous devez /etc/ceph/ceph.confégalement faire attention à la prise en charge de la version.
Système de surveillance parfait
Maintenant, le lien entier est relativement long. La couche inférieure comprend des clusters de moteurs de métadonnées, des clusters de stockage d'objets Ceph et des clients et services de couche supérieure. Chaque couche doit avoir une solution de surveillance correspondante.
Pour le nœud client, nous collectons principalement les journaux. Il convient de noter que les journaux client JuiceFS de chaque point de montage doivent être agrégés et que des alarmes d'erreur sont nécessaires pour empêcher les journaux d'exploser le disque système ou le nœud ne peut pas être écrit.
Chaque client JuiceFS doit également avoir des méthodes de surveillance correspondantes, telles que vérifier si les fichiers .stat et les indicateurs d'observation de journal de chaque point de montage sont normaux, puis vérifier les E/S et les journaux des clusters Redis et Ceph pour s'assurer que l'intégralité du lien est contrôlable Oui , il est plus pratique de localiser le problème de cette manière.
L'image ci-dessus est l'image de surveillance de Ceph, car nos nœuds clients utilisent le cache SSD, et maintenant les données ne sont pratiquement pas lues sur Ceph, la plupart des données sont lues à partir du cache, donc le trafic de Ceph n'est pas important.
L'image ci-dessus représente les données interceptées par la surveillance JuiceFS. On peut voir que 100 % à 90 % des nœuds peuvent être touchés. Le taux de réussite du cache est encore relativement élevé et la plupart des données sont toujours dans le cache.
Participer au développement de la communauté JuiceFS
UniSound a participé activement au développement de la communauté au cours du processus d'utilisation de JuiceFS Community Edition. En 2021, j'ai travaillé avec l'équipe JuiceData pour développer le Runtime Fluid JuiceFS mentionné ci-dessus. Récemment, nous avons constaté que le quota basé sur le répertoire de la version communautaire n'avait pas encore été développé, nous avons donc développé une version il y a quelques mois, qui limite le nombre de fichiers dans le répertoire et la taille du fichier. travaille maintenant avec la communauté JuiceFS Faites le travail de fusion.
Scénarios d'utilisation et avantages de JuiceFS dans Atlas
Le cache multiniveau du client JuiceFS est actuellement principalement utilisé dans nos scénarios de reconnaissance de texte, de réduction du bruit de la parole et de reconnaissance vocale. Étant donné que la lecture des données de la formation du modèle AI se caractérise par plus de lecture et moins d'écriture, nous utilisons pleinement le cache du client JuiceFS pour apporter les avantages d'accélération de la lecture IO.
Avantage 1 : Accélérer la formation des modèles d'IA
1) Test de réduction du bruit de la parole
Les fichiers dispersés sont utilisés dans le test du modèle de scène de réduction du bruit. Chaque donnée est au format wav, un petit fichier vocal inférieur à 100 Ko. Dans la scène de réduction du bruit, nous avons testé les données d'E/S dans l'étape de chargement des données, et le mémoire du nœud client JuiceFS. Le cache est de 512 Go et le test est effectué avec une taille de lot de 40 sous les données de l'échelle 500h.
D'après les résultats des tests, en termes d'efficacité de lecture de données uniquement, en termes de petits fichiers wav, JuiceFS est de 6,45 it/s, tandis que Lustre est de 5,15 it/s, et les performances sont améliorées de 25 %. JuiceFS a effectivement accéléré notre formation de modèle de bout en bout et raccourci le temps de sortie global du modèle.
2) Scène de reconnaissance de texte
Dans le scénario de reconnaissance de texte, le modèle est la dorsale CRNN et MobileNet v2, et l'environnement de test est le suivant :
Un grand fichier de données de LMDB est généré.À ce moment, IO a des exigences de bande passante relativement élevées au lieu d'exigences de performances pour les petits fichiers. Le cache mémoire de 200 Go peut prendre en charge l'intégralité des données. Ainsi, au lieu d'utiliser le stockage sous-jacent, nous lisons directement à partir du client, et les performances globales ont également été considérablement améliorées.
Dans ce test, la comparaison de vitesse entre JuiceFS et Lustre est principalement effectuée. Selon les résultats expérimentaux, il faut 1,5 s pour lire chaque lot depuis Lustre, et 1,1 s pour lire chaque lot depuis JuiceFS, soit une augmentation de 36 %. Du point de vue du temps de convergence du modèle, des 96 heures de Lustre aux 86 heures de JuiceFS, l'utilisation de JuiceFS peut raccourcir le temps de sortie du modèle CRNN de 10 heures.
Débogage du modèle et traitement des données
Lors du débogage de code, plusieurs utilisateurs exécuteront des tests de modèle et une traversée de code sur une machine de débogage en même temps. À ce moment-là, la plupart des utilisateurs utiliseraient des IDE distants, se connecteraient à des nœuds de débogage, puis créeraient leur propre environnement virtuel, installerait un grand nombre de packages d'installation sur Lustre à l'avance.
La plupart d'entre eux sont de petits fichiers de dizaines de k ou de centaines de k, et nous devons importer ces packages dans notre mémoire. Lors de l'utilisation de Lustre auparavant, car il y a trop d'utilisateurs, le débit requis est élevé. Dans le même temps, les exigences de performances pour les petits fichiers sont relativement élevées. J'ai trouvé que l'effet n'est pas très bon. Lors de l'importation de packages, ce sera relativement bloqué, ce qui entraîne un débogage de code lent et une efficacité globale relativement faible.
Plus tard, le cache du client JuiceFS a été utilisé, et la première compilation était également relativement lente, mais la deuxième compilation car toutes les données avaient été placées dans le cache, la vitesse et l'efficacité étaient plus élevées, et le saut de code était plus rapide. les importations d'indices sont également plus rapides. Après les tests de l'utilisateur, il y a environ 2 à 4 fois plus de vitesse.
épilogue
De Lustre à JuiceFS
De 2017 à 2021, lorsque nous utilisons Lustre, il est également relativement stable.Lorsque la capacité de stockage du cluster est inférieure à 50%, la stabilité du logiciel est relativement élevée.
En tant que système de stockage dans le domaine HPC vétéran, Lustre a alimenté plusieurs des plus grands systèmes de supercalcul au monde et possède de nombreuses années d'expérience dans les environnements de production. Il présente les avantages de se conformer à la norme POSIX, de supporter divers réseaux hautes performances et à faible latence, et de permettre un accès RDMA.Il est adapté au calcul haute performance dans le domaine HPC traditionnel et est compatible avec l'interface d'apprentissage en profondeur. Toutes les entreprises n'ont pas besoin de se faire modifier le code. Mais il y a aussi quelques inconvénients :
Premièrement, Lustre ne peut pas prendre en charge le pilote CSI natif du cloud.
Deuxièmement, Lustre a des exigences relativement élevées pour le personnel d'exploitation et de maintenance, car tout est écrit en langage C, parfois certains bogues ne peuvent pas être résolus rapidement et la communauté dans son ensemble n'est pas très ouverte et active.
JuiceFS a de telles fonctionnalités :
Tout d'abord, JuiceFS est un produit de système de stockage distribué dans le domaine du cloud natif Il fournit CSI Driver et Fluid pour mieux s'intégrer à Kubernetes.
Deuxièmement, le schéma de déploiement de JuiceFS est relativement flexible et le moteur de métadonnées est hautement facultatif. Si le réseau de l'utilisateur autorise le stockage d'objets, il est en fait préférable de se connecter au stockage d'objets du cloud public.
Troisièmement, il est relativement simple en termes d'opération et de maintenance d'extension de stockage . Entièrement compatible avec la norme POSIX, l'application d'apprentissage en profondeur peut être migrée de manière transparente, mais en raison des caractéristiques du stockage d'objets back-end, JuiceFS aura un retard élevé dans l'écriture aléatoire.
Quatrièmement, JuiceFS prend en charge le cache local et le cache de page du noyau, qui réalise la superposition et l'accélération des données chaudes et froides . C'est ce que nous apprécions le plus, c'est plus adapté à nos scénarios d'entreprise, mais ce n'est pas adapté à l'écriture aléatoire. La fonction de cache distribué de la version communautaire n'est pas encore disponible.
Planification ultérieure
• Mise à niveau du moteur de métadonnées, TiKV convient aux scénarios avec plus de 100 millions de fichiers (peut prendre en charge jusqu'à 10 milliards de fichiers) et a des exigences élevées en matière de performances et de sécurité des données. À l'heure actuelle, nous avons terminé le test interne de TiKV et nous sommes activement y travailler Pour suivre les progrès de la communauté, le moteur de métadonnées sera migré vers TiKV à l'avenir. • Optimisation des quotas d'annuaire. À l'heure actuelle, les fonctions de la version de base ont été intégrées dans la version de la communauté JuiceFS. Des discussions ont également été menées avec la communauté JuiceFS. Dans certains scénarios, certaines performances doivent être optimisées. • J'espère effectuer certaines fonctions non root. Maintenant, tous les nœuds ont l'autorité root pour accéder à toutes les données. L'autorité est trop grande. Nous espérons n'ouvrir l'autorité root que sur des nœuds spécifiques. • Enfin, nous vérifierons s'il existe une solution QoS dans la communauté, telle qu'une limitation de vitesse basée sur l'UID ou le GID.
Si vous êtes utile, veuillez prêter attention à notre projet Juicedata/JuiceFS ! (0ᴗ0✿)